- 1 - AP IX-127-E 8.2.3 Feature activation The purpose of the Feature activation information element is to invoke a supplementary service as identified by the feature identifier number. The service associated with the feature identifier number is dependent on that particular user's service profile. The maximum length of this information element is 4 octets. The Feature activation information element is coded as shown in Figure 8-6/Q.932 and Table 8-21/Q.932. 8 7 6 5 4 3 2 1 旼컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � � Feature activation � � � � � 0 � 0 1 1 1 0 0 0 � Octet 1 � � � � � Information element identifier � 쳐컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Length of feature activation contents � 2 쳐컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � 0/1 � Feature identifier number � 3 � Ext � � 쳐컴컴컵컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � 1 � Feature identifier number (continuation) � 3a � Ext � � 읕컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� FIGURE 8-6/Q.932 Feature activation information element TABLE 8-21/Q.932 Feature activation information element Feature identifier number (octets 3 and 3a) The feature identifier number is a unique number assigned to a feature in a customer account that is coded as part of both the Feature activation and Feature indication information elements. This number identifies the feature that is being requested or updated. The association of a particular number to a particular feature may be different for each user. Bit 8 in octet 3 is used to extend the feature identifier field. If bit 8 is 0, then another octet follows; if bit 8 is 1, then octet 3 is the last octet. The identifier numbers for a one octet field range from 1 to 127. For a multi-octet field, the order of bit values progressively decreases as the octet number increases. 8.2.4 Feature indication (3276) - 2 - AP IX-127-E The purpose of the Feature indication information element is to allow the network to convey feature indications to the user regarding the status of a supplementary service. The maximum length of this information element is 5 octets. The coding of the Feature indication information element is shown in Figure 8-7/Q.932 and Table 8-22/Q.932. 8 7 6 5 4 3 2 1 旼컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � � Feature indication � � � � � 0 � 0 1 1 1 0 0 1 � Octet 1 � � � � � Information element identifier � 쳐컴컴좔컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Length of feature indication contents � 2 쳐컴컴쩡컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � 0/1 � Feature identifier number � 3 � Ext � � 쳐컴컴탠컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � 1 � Feature identifier number (continuation) � 3a � Ext � � 쳐컴컴좔컴컴컴컴컴컴컴컴컴쩡컴컴컴컴컴컴컴컴컴컴컴� � 0 0 0 0 � Status indicator � 4 � Spare � � 읕컴컴컴컴컴컴컴컴컴컴컴컴좔컴컴컴컴컴컴컴컴컴컴컴� FIGURE 8-7/Q.932 Feature indication information element TABLE 8-22a/Q.932 Feature indication information element Feature identifier number (octets 3 and 3a) These fields are coded as described in Table 8-21/Q.932. TABLE 8-22b/Q.932 Feature indication information element Status indicator (octet 4) The status indicator field identifies the current status of a (3276) - 3 - AP IX-127-E supplementary service. Examples of possible user Bits equipment 4 3 2 1 Status Meaning implementation 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� 0 0 0 0 Deactivated Feature is in the Lamp off deactivated state 0 0 0 1 Activated Feature is in the Lamp steady on active state 0 0 1 0 Prompt Feature prompt Lamp steady flash (waiting for user input) 0 0 1 1 Pending Feature is pending Lamp steady wink All other values are reserved. 8.2.5 Information request The purpose of the Information request information element is to provide the capability for requesting additional information and signalling completion of the information request (see Annex B). The Information request information element is coded as shown in Figure 8-8/Q.932 and Table 8-23/Q.932. The default maximum length of the Information request information element is three octets. 8 7 6 5 4 3 2 1 旼컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴커 � � Information request � � � � � 0 � 0 1 1 0 0 1 0 � Octet 1 � � � � � Information element identifier � 쳐컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴캑 � Length of information request contents � 2 쳐컴컴컫컴컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴캑 � 1 � Info. � Type of information � 3 � Ext.� Req. � � � � Ind. � � 읕컴컴컨컴컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴켸 FIGURE 8-8/Q.932 Information request information element TABLE 8-23/Q.932 (3276) - 4 - AP IX-127-E Information request information element Information request indicator (octet 3, bit 7) 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� Bit 7 컴컴� 0 Information request completed 1 Prompt for additional information Type of information (octet 3, bits 1-6) 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 Bits 6 5 4 3 2 1 컴컴컴컴컴컴컴컴 0 0 0 0 0 0 undefined 0 0 0 0 0 1 authorization code 0 0 0 0 1 0 address digits 0 0 0 0 1 1 terminal identification All other values are reserved. 8.2.6 Service profile identification The purpose of the Service profile identification information element is to allow the user to initiate automatic assignment of the user service identifier and terminal identifier (see Annex A). The Service profile identification information element is defined in Figure 8-9/Q.932 and Table 8-24/Q.932. The default maximum length of the Service profile identification information element is 32 octets. 8 7 6 5 4 3 2 1 旼컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � � Service profile identification � � � � � 0 � 0 1 1 1 0 1 0 � Octet 1 � � � � � Information element identifier � 쳐컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � Length of service profile identification � 2 � contents � 쳐컴컴컫컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� � 0 � SPID (IA5 characters) � 3 � � � etc. 읕컴컴컨컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� FIGURE 8-9/Q.932 Service profile identification information element (3276) - 5 - AP IX-127-E TABLE 8-24/Q.932 Service profile identification information element SPID (octet 3, etc.) The service profile identifier parameter is coded in IA5 characters, according to the format specified by the network. ANNEX A (to Recommendation Q.932) User service profiles and terminal identification A.1 Introduction These optional procedures allow an ISDN to support identification and selection of specific terminals on a multi point user-network interface to support multiple user service profiles in those cases in which Recommendation Q.931 information elements are not sufficient for such purposes. A terminal or network which desires to support such multiple profiles for terminals which could not otherwise be distinguished, must support this additional identification procedure. Otherwise, it is completely optional. TABLE A-1/Q.932 Terminology 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 Service profile refers to the information that the network maintains for a given user to characterize the service offered by the network to that user. As an example, this may contain the association of feature identifiers to specific supplementary services. A service profile may be allocated to an access interface or to a particular user equipment or a group of user equipments. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� SPID The Service Profile IDentifier is a parameter carried in a Service profile identification information element that is sent from the user to the network to allow network assignment of a USID and TID. A user's SPID should uniquely identify a specific profile of service characteristics stored within the network. The SPID will allow the network to distinguish between different terminals that would otherwise be indistinguishable (e.g., same ISDN number). The SPID value is provided to the user at subscription (3276) - 6 - AP IX-127-E time. (continued) 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� (3276) - 7 - AP IX-127-E 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 USID User Service IDentifier. A USID uniquely identifies a service profile on an access interface. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴� TID Terminal IDentifier. A TID value is unique within a given USID. If two terminals on an interface subscribe to the same service profile, then the two terminals will be assigned the same USID. However, two different TIDs are required to uniquely identify each of the two terminals. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 EID Endpoint IDentifier. The endpoint identifier information element is used for terminal identification. The endpoint identifier parameters contain a USID and TID and additional information used to interpret them. 컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴컴 Figure A-1/Q.932 shows examples of the relationships of terminals, SPIDs, USIDs, and TIDs and their dynamic relationship to TEIs. In this example, terminals 1, 3, 4 and 5 support the automatic endpoint identifier parameter assignment procedure and terminal 2 does not, but has the endpoint identifier parameters locally entered. Terminal 6 does not support terminal identification, therefore it utilizes the specified default service profile. (3276) - 8 - AP IX-127-E (3276) - 9 - AP IX-127-E FIGURE A-1/Q.932 Relationship of service profile, SPID, USID, TID, and TEI Note - Items in parentheses indicate values or relationships which are dynamically established by initialization procedures (see  A.4). Others are established via administrative actions and stored as a result of manual entry. A user or network that does not recognize the information elements used by this annex shall, if these elements are received, apply the error procedures defined in  5.8 of Recommendation Q.931. A.2 User service profiles The support of user service profiles requires that the service requests from a terminal are associated by the network with a specific profile. A USID is used to identify the profile on an access. The service profile is assigned to a data link connection so that the network can associate all of the service requests from the corresponding Connection Endpoint Suffix (CES) with the required profile (see note). The assignment of a service profile to a data link connection minimizes the per-service request overhead of profile identification. The procedures for assigning service profile to a data link connection are incorporated into the initialization procedures described in  A.4. Note - CES along with SAPI constitute the CEI (Connection Endpoint Identifier) that is used to identify message units passed between the data link layer (as represented by the TEI) and Layer 3. A.3 Terminal identification The support of terminal identification requires that a call sent by the network can be addressed to: - all of the terminals of a user service profile; - one terminal of a user service profile; or - all but one terminal of a user service profile. A USID is used to identify the user service profile with a (set of) terminals on an access interface and a TID is used to identify individual terminals within a user service profile on an access. The USID and TID may be entered into the terminal by the user as arranged at subscription time, or dynamically downloaded to the terminal from the network with an automatic assignment procedure. The USID and TID parameters are used by the terminal to check the compatibility of a call offered by the network. The inclusion of a USID and TID with only access uniqueness minimizes the per-call overhead of supporting terminal addressing. The procedures for downloading the USID and TID to a terminal are incorporated into the automatic endpoint identifier allocation and initialization (3276) - 10 - AP IX-127-E procedures described in  A.4. The procedures for using a USID and TID for terminal identification in an offered call sent by the network are described in  A.5. A.4 Initialization The initialization procedure provides for the association by the network of the service requests from a terminal on a particular data link connection (as represented by the TEI) with a user service profile. A user requested automatic assignment procedure is described to also support automatic assignment of USID and TID parameters and their downloading by the network to a terminal. Since initialization provides the basis for subsequent association of a service profile with a data link connection, normally, user equipment that supports initialization is expected to request the initialization procedure (e.g., on the first Layer 3 message after dynamic assignment of a TEI). However, a request for initialization is allowed at any time. The data link connection is always associated with the most recently identified service profile. Under some circumstances, the network may solicit terminal initialization. A.4.1 Terminal requested initialization a) Terminals may initialize by sending an Endpoint identifier information element (containing a USID and TID) in an INFORMATION message at any time to the network. Subsequent to this, the network may associate the service profile with the data link over which the message was sent. b) For terminals which support automatic assignment of USID and TID parameters, initialization (that is, association of a service profile with a data link connection) is provided as part of the automatic assignment procedure described here. A user may initiate automatic assignment of the endpoint identifier by sending a Service profile identification information element in an INFORMATION message with the dummy call reference. The Service profile identification information element should contain the SPID parameter allocated at the time of subscription. The initialization is acknowledged with an INFORMATION message with the Endpoint identifier information element containing a USID and TID, the values of which are determined by the network. It results in an association of the data link over which it was received with the identified service profile. When a terminal determines that the initialization procedure has failed, it assumes that the network cannot support the procedure and does not repeatedly attempt initialization. A.4.2 Network solicited initialization The network may solicit a request for initialization on a data link connection by sending an Information request information element with codepoint "terminal identification" in an INFORMATION message with the dummy call reference. Upon receiving the request, the terminal may respond as described in the (3276) - 11 - AP IX-127-E previous  A.4.1 a) or b). When a network determines that the initialization procedure has failed, it assumes that the terminal cannot support the procedures and does not repeatedly request initialization. A.4.3 Collision When terminal initialization and network solicitation procedures collide, the terminal ignores the solicitation from the network and the network proceeds as normal upon receipt of the initialization request from the terminal. A.5 Identification procedures When the network offers a call using terminal addressing, the Endpoint identifier information element is included in the SETUP message. When a terminal receives a SETUP message containing the Endpoint identifier information element, it shall: - if it is not supported, handle the Endpoint identifier information element in accordance with  5.8.7 of Recommendation Q.931 and complete normal compatibility checking procedures; or, - test for an address compatibility with the Endpoint identifier information element if it is supported in addition to completing the normal compatibility checking procedures. ANNEX B (to Recommendation Q.932) Information request procedures B.1 Introduction This annex specifies optional procedures to allow a network to request additional information from a user. These procedures do not impact the Recommendation Q.931 call state. This capability shall only be allowed during the Null, Overlap Sending, Outgoing Call Proceeding, Call Delivered, and Activate call states. The capability is intended for use with the Keypad and Feature key management protocols. A user or network that does not recognize the information elements used by this annex shall, if these information elements are received, apply the error recovery procedures defined in  5.8 of Recommendation Q.931. B.2 Procedures B.2.1 Normal procedures (3276) - 12 - AP IX-127-E The network will send an INFORMATION message to the user to request additional information. The INFORMATION message will contain the Information request information element (see  8), with the information request indicator set to "prompt for additional information" and type of information set to the appropriate value. After sending the INFORMATION message, the network will start timer T302. The network will restart timer T302 on the receipt of every INFORMATION message if the requested information is not complete. No Recommendation Q.931 call state changes should occur when the INFORMATION message is sent or received. The user may always send the requested information in keypad facility information elements contained in one or more INFORMATION messages. In addition, if the information requested was a called party number, then the user may also send the requested information in the called party number information element in one or more INFORMATION messages. In both the call associated and non-call associated cases, when the network has determined that sufficient information has been received to proceed, it may send an INFORMATION message to the user, containing an Information request information element, with the information request indicator set to "information request completed" to signal the required information has been received correctly. If the additional information was requested during Overlap Sending state, and no additional information is required before the network can proceed with processing of the call, a CALL PROCEEDING message may suffice to signal the end of information sending. In the call associated case, the network may also indicate that sufficient information has been received by initiating call clearing according to  5.3 of Recommendation Q.931. B.2.2 Abnormal procedures If no response is received from the user, or if the information received is incomplete upon expiry of timer T302, or if the information provided by the user is invalid, then: - in the call associated case, the network shall initiate call clearing according to  5.3 of Recommendation Q.931; - in the non-call associated case, the network shall return an INFORMATION message containing a Cause information element with an appropriate cause value. In the non-call associated case, if the user responds with a RELEASE COMPLETE message to an INFORMATION message containing an Information request information element, then the procedure shall be considered as terminated. APPENDIX I (to Recommendation Q.932) (3276) - 13 - AP IX-127-E I.1 Introduction This appendix is provided as an illustration of the application of the three protocol types defined in this Recommendation. The examples shown should not be taken as definitive examples, since the support of the Keypad and the Feature key management protocols are network dependent. The signalling sequences shown are not exhaustive and are only intended to illustrate possible supplementary service control sequences. I.2 Example use of the Keypad protocol This example shows the application of the Keypad protocol using the Keypad facility and Display information elements to establish a second call while holding the first one. It should be noted that the Keypad protocol does not necessarily allow a supplementary service to be supported to the same degree of functionality as the approach based on the Functional protocol. In addition, this protocol does not impose a need for the terminal to be aware of any states other than those required for basic call control. An objective of the Keypad protocol is to provide for the support of supplementary services in circumstances where a reduced level of functionality can be tolerated. The example in Figure I-1/Q.932 illustrates a user feature request using the Keypad protocol. The network associates the contents of the Keypad information element with the appropriate feature. The user is shown to subsequently enter supplementary service parameters using the Keypad protocol. Feature status information may be provided by the network in the Display information element. The network completes feature processing and the user is shown to clear call reference. Alternatively, depending on the specific feature request, a CALL PROCEEDING message might be returned by the network and normal call processing procedures would continue. The specific example shown in Figure I-2/Q.932 illustrates the support of a hold/retrieve function based on the use of INFORMATION messages for the conveyance of Keypad facility or Display information elements. An enquiry call is established through the conveyance of the called party address digits via a Keypad facility information element within INFORMATION messages. These address digits are sent after putting the existing call on hold through the transfer of a facility request via a Keypad facility information element within an INFORMATION message. (3276) - 14 - AP IX-127-E FIGURE I-1/Q.932 A generic example of the use of the Keypad protocol (3276) - 15 - AP IX-127-E Note 1 -The first call is established using the normal call establishment procedures specified in Recommendation Q.931. Note 2 - The same call reference as that of the active call is used to establish the enquiry call. The characteristics of the second call are assumed to be identical to the first call (e.g. same Bearer capability, High layer compatibility, Low layer compatability, Transit network selection, etc., information elements). FIGURE I-2/Q.932 Specific example of establishing a second (3276) - 16 - AP IX-127-E call while holding the first one using the Keypad protocol (3276) - 17 - AP IX-127-E I.3 Example of use of the Feature key management protocol This example illustrates the use of the Feature key management protocol for the invocation of a supplementary service by a user having initiated a call establishment by sending a SETUP message with incomplete (or no) address information, after having entered the overlap sending state upon receipt of the SETUP ACKNOWLEDGE message. Figure I-3/Q.932 depicts the user providing supplementary service parameters. This is accomplished via the Keypad facility information element within INFORMATION messages after having invoked the request of a supplementary service by sending a Feature activation information element contained in an INFORMATION message to the network. The association of the feature identifier number (provided within the Feature activitation information element) with a given supplementary service has to be arranged between the user and the network at subscription time. FIGURE I-3/Q.932 A generic example of the use of the Feature key management protocol (3276) - 18 - AP IX-127-E I.4 Examples of use of the Functional protocol I.4.1 Call related supplementary service procedures I.4.1.1 Invocation with call establishment The example message sequence shows the initiation of a call establishment simultaneously with a supplementary service invocation. Note 1 - Depending on the invoked supplementary service, and the basic call control procedure one of the Recommendation Q.931 messages in the network-to-user direction may be used to carry return result, return error or reject indication or even an invoke for further information. FIGURE I-4/Q.932 Invocation with call establishment I.4.1.2 Invocation with call clearing The example message sequence shows the initiation of normal call clearing simultaneously with a supplementary service invocation. Note 1 - Assume the signalling association CRa can be cleared together with the connection for the invoked supplementary service, otherwise a FACILITY message may be used instead. FIGURE I-5/Q.932 (3276) - 19 - AP IX-127-E Invocation with call clearing I.4.1.3 Invocation during the active phase of a call The example message sequence shows the initiation of a supplementary service via the established signalling association CRa at any time during the active phase of a call. Note 1 - This sequence may occur several times during the active phase of a call, utilizing the existing signalling association. FIGURE I-6/Q.932 Invocation during the active phase of a call I.4.2 Call independent supplementary service procedures I.4.2.1 Establishment of a user-to-network transaction for supplementary service control Note 1 - Establishment of Layer 2 connection if not yet established. Note 2 - If the procedure is used in the network-to-user direction, additional address information may be required. This requires further study. (3276) - 20 - AP IX-127-E Note 3 - Depending on the invoked supplementary service, the Layer 2 connection may be kept or cleared. FIGURE I-7/Q.932 Establishment of an a user-to-network transaction for supplementary service control I.4.2.2 Clearing of a user-to-network transaction for supplementary service control Note 1 - After receiving the last return result the receiving side may initiate clearing of the layer 2 connection. FIGURE I-8/Q.932 Clearing of a user-to-network transaction for supplementary service control TABLE I-1/Q.932 Key to the Figures I-1/Q.932 to I-8/Q.932 Layer 2 frames: SABME - Set asynchronous balance mode extended UA - Unnumbered acknowledgement frame DISC - Disconnect frame Layer 3 messages: INFO - Information SETUP ACK - Setup acknowledge DISC - Disconnect REL - Release (3276) - 21 - AP IX-127-E REL COMP - Release complete Layer 3 message information elements/parameters: FAC - Facility information element F - Facility identifier Invoke - Invoke operation type RR - Return result operation type RE - Return error operation type CRa - Call reference of an active call CRi - Call reference assigned call independently APPENDIX II (to Recommendation Q.932) Functional reference model for the operation of supplementary services This appendix provides a functional model intended to show how the supplementary services can be operated by combining stimulus or Functional protocol types to interact with a unique supplementary service protocol controller which interfaces with the relevant supplementary functional components which provides and coordinates the required functions associated to each supplementary service (e.g. control of resources). The intermediate feature function performs the necessary conversions between stimulus protocols and the supplementary service functional primitives which are the only ones treated and known from the supplementary service protocol controller. As an example, the intermediate feature function translates an access code received within the Keypad facility information element or a feature identifier number within a Feature activation information element to a supplementary service priority such as hold or retrieve request. (3276) - 22 - AP IX-127-E (3276) CCITT\AP-IX\127E3.TXS - 23 - AP IX-127-E (3276) CCITT\AP-IX\127E3.TXS