Text
"3GPP TS 29.229 V17.2.0 (2022-06) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Cx and Dx interfaces based on the Diameter protocol; Protocol details (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 6 1 Scope 7 2 References 7 3 Definitions, symbols and abbreviations 8 3.1 Definitions 8 3.2 Abbreviations 9 4 General 9 5 Use of the Diameter base protocol 9 5.1 Securing Diameter Messages 9 5.2 Accounting functionality 9 5.3 Use of sessions 9 5.4 Transport protocol 10 5.5 Routing considerations 10 5.6 Advertising Application Support 10 6 Diameter application for Cx interface 11 6.1 Command-Code values 11 6.1.1 User-Authorization-Request (UAR) Command 11 6.1.2 User-Authorization-Answer (UAA) Command 12 6.1.3 Server-Assignment-Request (SAR) Command 12 6.1.4 Server-Assignment-Answer (SAA) Command 13 6.1.5 Location-Info-Request (LIR) Command 14 6.1.6 Location-Info-Answer (LIA) Command 14 6.1.7 Multimedia-Auth-Request (MAR) Command 14 6.1.8 Multimedia-Auth-Answer (MAA) Command 15 6.1.9 Registration-Termination-Request (RTR) Command 15 6.1.10 Registration-Termination-Answer (RTA) Command 16 6.1.11 Push-Profile-Request (PPR) Command 16 6.1.12 Push-Profile-Answer (PPA) Command 17 6.2 Result-Code AVP values 17 6.2.1 Success 17 6.2.1.1 DIAMETER_FIRST_REGISTRATION (2001) 17 6.2.1.2 DIAMETER_SUBSEQUENT_REGISTRATION (2002) 17 6.2.1.3 DIAMETER_UNREGISTERED_SERVICE (2003) 17 6.2.1.4 DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED (2004) 18 6.2.1.5 Void 18 6.2.2 Permanent Failures 18 6.2.2.1 DIAMETER_ERROR_USER_UNKNOWN (5001) 18 6.2.2.2 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) 18 6.2.2.3 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003) 18 6.2.2.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) 18 6.2.2.5 DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED (5005) 18 6.2.2.6 DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED (5006) 18 6.2.2.7 DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (5007) 18 6.2.2.8 DIAMETER_ERROR_TOO_MUCH_DATA (5008) 18 6.2.2.9 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA (5009) 19 6.2.2.10 Void 19 6.2.2.11 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) 19 6.2.2.12 DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED (5012) 19 6.3 AVPs 19 6.3.0 General 19 6.3.1 Visited-Network-Identifier AVP 22 6.3.2 Public-Identity AVP 22 6.3.3 Server-Name AVP 22 6.3.4 Server-Capabilities AVP 23 6.3.5 Mandatory-Capability AVP 23 6.3.6 Optional-Capability AVP 23 6.3.7 User-Data AVP 23 6.3.8 SIP-Number-Auth-Items AVP 23 6.3.9 SIP-Authentication-Scheme AVP 23 6.3.10 SIP-Authenticate AVP 24 6.3.11 SIP-Authorization AVP 24 6.3.12 SIP-Authentication-Context AVP 24 6.3.13 SIP-Auth-Data-Item AVP 24 6.3.14 SIP-Item-Number AVP 25 6.3.15 Server-Assignment-Type AVP 25 6.3.16 Deregistration-Reason AVP 26 6.3.17 Reason-Code AVP 26 6.3.18 Reason-Info AVP 26 6.3.19 Charging-Information AVP 27 6.3.20 Primary-Event-Charging-Function-Name AVP 27 6.3.21 Secondary-Event-Charging-Function-Name AVP 27 6.3.22 Primary-Charging-Collection-Function-Name AVP 27 6.3.23 Secondary-Charging-Collection-Function-Name AVP 27 6.3.24 User-Authorization-Type AVP 27 6.3.25 Void 28 6.3.26 User-Data-Already-Available AVP 28 6.3.27 Confidentiality-Key AVP 28 6.3.28 Integrity-Key AVP 28 6.3.29 Supported-Features AVP 28 6.3.30 Feature-List-ID AVP 29 6.3.31 Feature-List AVP 29 6.3.32 Supported-Applications AVP 29 6.3.33 Associated-Identities AVP 29 6.3.34 Originating-Request AVP 29 6.3.35 Wildcarded-Public-Identity AVP 29 6.3.36 SIP-Digest-Authenticate AVP 29 6.3.37 Digest-Realm AVP 30 6.3.38 Void 30 6.3.39 Digest-Algorithm AVP 30 6.3.40 Digest-QoP AVP 30 6.3.41 Digest-HA1 AVP 30 6.3.42 Line-Identifier AVP 30 6.3.43 Wildcarded-IMPU AVP 30 6.3.44 UAR-Flags AVP 30 6.3.45 Loose-Route-Indication AVP 31 6.3.46 SCSCF-Restoration-Info AVP 31 6.3.47 Path AVP 31 6.3.48 Contact AVP 31 6.3.49 Subscription-Info AVP 31 6.3.49.1 Call-ID-SIP-Header AVP 32 6.3.49.2 From-SIP-Header AVP 32 6.3.49.3 To-SIP-Header AVP 32 6.3.49.4 Record-Route AVP 32 6.3.50 Associated-Registered-Identities AVP 32 6.3.51 Multiple-Registration-Indication 32 6.3.52 Restoration-Info AVP 32 6.3.53 Framed-IP-Address AVP 33 6.3.54 Framed-IPv6-Prefix AVP 33 6.3.55 Framed-Interface-Id AVP 33 6.3.56 Session-Priority AVP 33 6.3.57 Identity-with-Emergency-Registration AVP 33 6.3.58 Priviledged-Sender-Indication AVP 33 6.3.59 LIA-Flags 34 6.3.60 OC-Supported-Features 34 6.3.61 OC-OLR 34 6.3.62 Initial-CSeq-Sequence-Number AVP 34 6.3.63 SAR-Flags 34 6.3.64 Allowed-WAF-WWSF-Identities AVP 34 6.3.65 WebRTC-Authentication-Function-Name AVP 35 6.3.66 WebRTC-Web-Server-Function-Name AVP 35 6.3.67 DRMP AVP 35 6.3.68 Load 35 6.3.69 RTR-Flags 35 6.3.70 P-CSCF-Subscription-Info AVP 35 6.3.71 Registration-Time-Out 35 6.3.72 Alternate-Digest-Algorithm AVP 36 6.3.73 Alternate-Digest-HA1 AVP 36 6.3.74 Failed-PCSCF 36 6.3.75 PCSCF-FQDN 36 6.3.76 PCSCF-IP-Address 36 6.4 Use of namespaces 36 6.4.1 AVP codes 36 6.4.2 Experimental-Result-Code AVP values 36 6.4.3 Command Code values 36 6.4.4 Application-ID value 36 7 Special Requirements 37 7.1 Version Control 37 7.1.1 Defining a new feature 37 7.1.2 Changing the version of the interface 40 7.2 Supported features 40 7.2.1 Dynamic discovery of supported features 40 7.3 Interface versions 41 7.3.1 Discovery of supported interface versions 41 Annex A (informative): Change history 43 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope The present document defines a transport protocol for use in the IP multimedia (IM) Core Network (CN) subsystem based on Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28]. The present document is applicable to: - The Cx interface between the I-CSCF/S-CSCF and the HSS. - The Dx interface between the I-CSCF/S-CSCF and the SLF. Whenever it is possible, this document specifies the requirements for this protocol by reference to specifications produced by the IETF within the scope of Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28]. Where this is not possible, extensions to Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28] are defined within this document. 2 References The following documents contain provisions, which through reference in this text constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPPÊTSÊ29.228: ""IP Multimedia (IM) Subsystem Cx and Dx interface; signalling flows and message contents"". [2] 3GPPÊTSÊ33.210: ""3G Security; Network Domain Security; IP Network Layer Security"". [3] IETFÊRFCÊ3261: ""SIP: Session Initiation Protocol"". [4] IETFÊRFCÊ2396: ""Uniform Resource Identifiers (URI): generic syntax"". [5] Void. [6] Void. [7] IETFÊRFCÊ2234: ""Augmented BNF for syntax specifications"". [8] IETFÊRFCÊ3966: ""The tel URI for Telephone Numbers"". [9] Void. [10] Void. [11] 3GPPÊTSÊ29.329: ""Sh Interface based on the Diameter protocol; protocol details"". [12] IETFÊRFCÊ3589: ""Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5"". [13] 3GPPÊTSÊ23.003: ""Numbering, addressing and identification"". [14] Void. [15] IETFÊRFCÊ4740: ""Diameter Session Initiation Protocol (SIP) Application"". [16] 3GPPÊTSÊ29.328: ""IP Multimedia (IM) Subsystem Sh interface; Signalling flows and message contents"". [17] IETFÊRFCÊ3327: ""Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts"". [18] 3GPPÊTSÊ29.273: ""3GPP EPS AAA interfaces"". [19] IETFÊRFCÊ4005: ""Diameter Network Access Server Application"". [20] IETFÊRFCÊ4590: "" RADIUS Extension for Digest Authentication"". [21] IETFÊRFCÊ4960: ""Stream Control Transmission Protocol"". [22] IETFÊRFCÊ3162: ""RADIUS and IPv6"". [23] IETFÊRFCÊ7683: ""Diameter Overload Indication Conveyance"". [24] 3GPPÊTSÊ23.380: ""IMS Restoration Procedures"". [25] IETF draft-holmberg-sipcore-auth-id-01: ""Authorization server identity"". Editor's note: The above document cannot be formally referenced until it is published as an RFC. [26] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [27] IEFTÊRFCÊ8583: ""Diameter Load Information Conveyance"". [28] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [29] IETFÊRFCÊ7616: ""HTTP Digest Access Authentication"". 3 Definitions, symbols and abbreviations 3.1 Definitions Refer to IETFÊRFCÊ6733Ê[28] for the definitions of some terms used in this document. For the purposes of the present document, the following terms and definitions apply. Attribute-Value Pair: see IETFÊRFCÊ6733Ê[28], it corresponds to an Information Element in a Diameter message. Diameter Multimedia client: a client that implements the Diameter Multimedia application. The client is one of the communicating Diameter peers that usually initiate transactions. Examples in 3GPP are the I-CSCF and S-CSCF. Diameter Multimedia server: a server that implements the Diameter Multimedia application. A Diameter Multimedia server that also supported the NASREQ and MobileIP applications would be referred to as a Diameter server. An example of a Diameter Multimedia server in 3GPP is the HSS. Registration: SIP-registration. Server: SIP-server. User data: user profile data. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AAA Authentication, Authorization and Accounting ABNF Augmented Backus-Naur Form AVP Attribute-Value Pair CN Core Network CSCF Call Session Control Function DSCP Differentiated Services Code Point DRMP Diameter Routing Message Priority HSS Home Subscriber Server IANA Internet Assigned Numbers Authority I-CSCF Interrogating CSCF IETF Internet Engineering Task Force IMS IP Multimedia Subsystem NDS Network Domain Security RFC Request For Comments S-CSCF Serving CSCF SCTP Stream Control Transport Protocol SIP Session Initiation Protocol SLF Server Locator Function UCS Universal Character Set URL Uniform Resource Locator UTF UCS Transformation Formats WAF WebRTC Authentication Function WWSF WebRTC Web Server Function 4 General The Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and event codes specified in clauseÊ5 of this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) are unmodified. 5 Use of the Diameter base protocol With the clarifications listed in the following clauses the Diameter base protocol defined by IETFÊRFCÊ6733Ê[28] shall apply. 5.1 Securing Diameter Messages For secure transport of Diameter messages, see 3GPPÊTSÊ33.210Ê[2]. 5.2 Accounting functionality Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used on the Cx interface. 5.3 Use of sessions Both between the I-CSCF and the HSS and between the S-CSCF and the HSS, Diameter sessions are implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client does not need to send any re-authorization or session termination requests to the server. The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions. The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETFÊRFCÊ6733Ê[28]. As a consequence, the server does not maintain any state information about this session and the client does not need to send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 5.4 Transport protocol Diameter messages over the Cx and the Dx interfaces shall make use of SCTP IETFÊRFCÊ4960Ê[21]. 5.5 Routing considerations This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host. If an I-CSCF or S-CSCF knows the address/name of the HSS for a certain user, both the Destination-Realm and Destination-Host AVPs shall be present in the request. Otherwise, only the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. the SLF or a Diameter Proxy Agent (see 3GPPÊTSÊ29.228Ê[1]), based on the Diameter routing table in the client. If the next Diameter node is an SLF, then once the SLF has returned the address or the destination HSS (using Redirect-Host AVP), the redirected request to the HSS shall include both Destination-Realm and Destination-Host AVPs. If the next Diameter node is a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the destination HSS. The Diameter Proxy Agent, based on the result of this determination of the destination HSS, shall modify the Destination-Realm AVP and Destination-Host AVP of the request appropriately. The Diameter Proxy Agent shall then append a Route-Record AVP to the request and shall send the request to the destination HSS. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an I-CSCF or an S-CSCF. If the response is routed back to a Diameter Proxy Agent, the Diameter Proxy Agent shall send the response back to the I-CSCF or S-CSCF without modifying the Origin-Realm AVP and Origin-Host AVP. The response shall contain the Origin-Realm AVP set to the realm of the HSS together with the Origin-Host AVP set to the HSS that sent the response. The S-CSCF shall store the HSS realm and HSS address for each Public Identity, after the first request sent to the User Identity to HSS resolution function. Requests initiated by the HSS towards an S-CSCF shall include both Destination-Host and Destination-Realm AVPs. The HSS obtains the Destination-Host AVP to use in requests towards an S-CSCF, from the Origin-Host AVP received in previous requests from the S-CSCF. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the HSS. Destination-Realm AVP is declared as mandatory in the ABNF for all requests. 5.6 Advertising Application Support The HSS, S-CSCF and I-CSCF shall advertise support of the Diameter Multimedia Application by including the value of the application identifier (see clauseÊ6) in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The vendor identifier value of 3GPP (10415) and ETSI (13019) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. Note: The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETFÊRFCÊ6733Ê[28]. 6 Diameter application for Cx interface This clause specifies a Diameter application that allows a Diameter Multimedia server and a Diameter Multimedia client: - to exchange location information - to authorize a user to access the IMS - to exchange authentication information - to download and handle changes in the user data stored in the server The Cx interface protocol is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the Cx/Dx interface application is 16777216 (allocated by IANA). 6.1 Command-Code values This clause defines Command-Code values for this Diameter application. Every command is defined by means of the ABNF syntax IETFÊRFCÊ2234Ê[7], according to the Command Code Format (CCF) specification defined in IETFÊRFCÊ6733Ê[28]. Whenever the definition and use of an AVP is not specified in this document, what is stated in IETFÊRFCÊ6733Ê[28] shall apply. NOTE: As the Diameter commands described in this specification have been defined based on the former specification of the Diameter base protocol, the Vendor-Specific-Application-Id AVP is still listed as a required AVP (an AVP indicated as {AVP}) in the command code format specifications defined in this specification to avoid backward compatibility issues, even if the use of this AVP has been deprecated in the new specification of the Diameter base protocol (IETFÊRFCÊ6733Ê[28]). The command codes for the Cx/Dx interface application are taken from the range allocated by IANA in IETFÊRFCÊ3589Ê[12] as assigned in this specification. For these commands, the Application-ID field shall be set to 16777216 (application identifier of the Cx/Dx interface application, allocated by IANA). The following Command Codes are defined in this specification: Table 6.1.1: Command-Code values Command-Name Abbreviation Code Clause User-Authorization-Request UAR 300 6.1.1 User-Authorization-Answer UAA 300 6.1.2 Server-Assignment-Request SAR 301 6.1.3 Server-Assignment-Answer SAA 301 6.1.4 Location-Info-Request LIR 302 6.1.5 Location-Info-Answer LIA 302 6.1.6 Multimedia-Auth-Request MAR 303 6.1.7 Multimedia-Auth-Answer MAA 303 6.1.8 Registration-Termination-Request RTR 304 6.1.9 Registration-Termination-Answer RTA 304 6.1.10 Push-Profile-Request PPR 305 6.1.11 Push-Profile-Answer PPA 305 6.1.12 6.1.1 User-Authorization-Request (UAR) Command The User-Authorization-Request (UAR) command, indicated by the Command-Code field set to 300 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request the authorization of the registration of a multimedia user. Message Format < User-Authorization-Request> ::= < Diameter Header: 300, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } { Visited-Network-Identifier } [ User-Authorization-Type ] [ UAR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.2 User-Authorization-Answer (UAA) Command The User-Authorization-Answer (UAA) command, indicated by the Command-Code field set to 300 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the User-Authorization-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < User-Authorization-Answer> ::= < Diameter Header: 300, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Server-Name ] [ Server-Capabilities ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.3 Server-Assignment-Request (SAR) Command The Server-Assignment-Request (SAR) command, indicated by the Command-Code field set to 301 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request it to store the name of the server that is currently serving the user. Message Format <Server-Assignment-Request> ::= < Diameter Header: 301, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ User-Name ] [ OC-Supported-Features ] *[ Supported-Features ] *[ Public-Identity ] [ Wildcarded-Public-Identity ] { Server-Name } { Server-Assignment-Type } { User-Data-Already-Available } [ SCSCF-Restoration-Info ] [ Multiple-Registration-Indication ] [ Session-Priority ] [ SAR-Flags ] [ Failed-PCSCF ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.4 Server-Assignment-Answer (SAA) Command The Server-Assignment-Answer (SAA) command, indicated by the Command-Code field set to 301 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Server-Assignment-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. If Result-Code or Experimental-Result does not inform about an error, the User-Data AVP shall contain the information that the S-CSCF needs to give service to the user. Message Format <Server-Assignment-Answer> ::= < Diameter Header: 301, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ User-Name ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ User-Data ] [ Charging-Information ] [ Associated-Identities ] [ Loose-Route-Indication ] *[ SCSCF-Restoration-Info ] [ Associated-Registered-Identities ] [ Server-Name ] [ Wildcarded-Public-Identity ] [ Priviledged-Sender-Indication ] [ Allowed-WAF-WWSF-Identities ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.5 Location-Info-Request (LIR) Command The Location-Info-Request (LIR) command, indicated by the Command-Code field set to 302 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request name of the server that is currently serving the user. Message Format <Location-Info-Request> ::= < Diameter Header: 302, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ Originating-Request ] [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } [ User-Authorization-Type ] [ Session-Priority ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.6 Location-Info-Answer (LIA) Command The Location-Info-Answer (LIA) command, indicated by the Command-Code field set to 302 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Location-Info-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format <Location-Info-Answer> ::= < Diameter Header: 302, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Server-Name ] [ Server-Capabilities ] [ Wildcarded-Public-Identity ] [ LIA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.7 Multimedia-Auth-Request (MAR) Command The Multimedia-Auth-Request (MAR) command, indicated by the Command-Code field set to 303 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request security information. Message Format < Multimedia-Auth-Request > ::= < Diameter Header: 303, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Realm } [ Destination-Host ] { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } { SIP-Auth-Data-Item } { SIP-Number-Auth-Items } { Server-Name } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.8 Multimedia-Auth-Answer (MAA) Command The Multimedia-Auth-Answer (MAA) command, indicated by the Command-Code field set to 303 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Multimedia-Auth-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < Multimedia-Auth-Answer > ::= < Diameter Header: 303, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ User-Name ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Public-Identity ] [ SIP-Number-Auth-Items ] *[SIP-Auth-Data-Item ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.9 Registration-Termination-Request (RTR) Command The Registration-Termination-Request (RTR) command, indicated by the Command-Code field set to 304 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter Multimedia client in order to request the de-registration of a user. Message Format <Registration-Termination-Request> ::= < Diameter Header: 304, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Realm } { User-Name } [ Associated-Identities ] *[ Supported-Features ] *[ Public-Identity ] { Deregistration-Reason } RTR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.10 Registration-Termination-Answer (RTA) Command The Registration-Termination-Answer (RTA) command, indicated by the Command-Code field set to 304 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Registration-Termination-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format <Registration-Termination-Answer> ::= < Diameter Header: 304, PXY, 16777216 > < Session-Id > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Associated-Identities ] *[ Supported-Features ] *[ Identity-with-Emergency-Registration ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.11 Push-Profile-Request (PPR) Command The Push-Profile-Request (PPR) command, indicated by the Command-Code field set to 305 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter Multimedia client in order to update the subscription data and for SIP Digest authentication the authentication data of a multimedia user in the Diameter Multimedia client whenever a modification has occurred in the subscription data or digest password that constitutes the data used by the client. Message Format < Push-Profile-Request > ::= < Diameter Header: 305, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] [ User-Data ] [ Charging-Information ] [ SIP-Auth-Data-Item ] [ Allowed-WAF-WWSF-Identities ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.12 Push-Profile-Answer (PPA) Command The Push-Profile-Answer (PPA) command, indicated by the Command-Code field set to 305 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Push-Profile-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < Push-Profile-Answer > ::= < Diameter Header: 305, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.2 Result-Code AVP values This clause defines new result code values that must be supported by all Diameter implementations that conform to this specification. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and Result-Code AVP shall be absent. 6.2.1 Success Result codes that fall within the Success category are used to inform a peer that a request has been successfully completed. 6.2.1.1 DIAMETER_FIRST_REGISTRATION (2001) The HSS informs the I-CSCF that: - The user is authorized to register this public identity; - A S-CSCF shall be assigned to the user. 6.2.1.2 DIAMETER_SUBSEQUENT_REGISTRATION (2002) The HSS informs the I-CSCF that: - The user is authorized to register this public identity; - A S-CSCF is already assigned and there is no need to select a new one. 6.2.1.3 DIAMETER_UNREGISTERED_SERVICE (2003) The HSS informs the I-CSCF that: - The public identity is not registered but has services related to unregistered state; - A S-CSCF shall be assigned to the user. 6.2.1.4 DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED (2004) The HSS informs to the S-CSCF that: - The de-registration is completed; - The S-CSCF name is not stored in the HSS. 6.2.1.5 Void 6.2.2 Permanent Failures Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not be attempted again. 6.2.2.1 DIAMETER_ERROR_USER_UNKNOWN (5001) A message was received for a user or a wildcarded identity that is unknown. 6.2.2.2 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) A message was received with a public identity and a private identity for a user, and the server determines that the public identity does not correspond to the private identity. 6.2.2.3 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003) A query for location information is received for a public identity that has not been registered before. The user to which this identity belongs cannot be given service in this situation. 6.2.2.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) The user is not allowed to roam in the visited network. 6.2.2.5 DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED (5005) The identity has already a server assigned and the registration status does not allow that it is overwritten. 6.2.2.6 DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED (5006) The authentication scheme indicated in an authentication request is not supported. 6.2.2.7 DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (5007) The identity being registered has already the same server assigned and the registration status does not allow the server assignment type or the Public Identity type received in the request is not allowed for the indicated server-assignment-type. 6.2.2.8 DIAMETER_ERROR_TOO_MUCH_DATA (5008) The volume of the data pushed to the receiving entity exceeds its capacity. NOTE: This error code is also used in 3GPPÊTSÊ29.329Ê[11]. 6.2.2.9 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA (5009) The S-CSCF informs HSS that the received subscription data contained information, which was not recognised or supported. 6.2.2.10 Void 6.2.2.11 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) A request application message was received indicating that the origin host requests that the command pair would be handled using a feature which is not supported by the destination host. 6.2.2.12 DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED (5012) This error is used when the HSS supports the P-CSCF-Restoration-mechanism feature, but none of the user serving node(s) supports it, as described by 3GPPÊTSÊ23.380Ê[24] clauseÊ5.4. 6.3 AVPs 6.3.0 General The following table describes the Diameter AVPs defined by 3GPP for the Cx interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415) if not otherwise indicated. Table 6.3.0.1: Diameter Multimedia Application AVPs AVP Flag rules Attribute Name AVP Code Clause defined Value Type Must May Should not Must not May Encr. Visited-Network-Identifier 600 6.3.1 OctetString M, V No Public-Identity 601 6.3.2 UTF8String M, V No Server-Name 602 6.3.3 UTF8String M, V No Server-Capabilities 603 6.3.4 Grouped M, V No Mandatory-Capability 604 6.3.5 Unsigned32 M, V No Optional-Capability 605 6.3.6 Unsigned32 M, V No User-Data 606 6.3.7 OctetString M, V No SIP-Number-Auth-Items 607 6.3.8 Unsigned32 M, V No SIP-Authentication-Scheme 608 6.3.9 UTF8String M, V No SIP-Authenticate 609 6.3.10 OctetString M, V No SIP-Authorization 610 6.3.11 OctetString M, V No SIP-Authentication-Context 611 6.3.12 OctetString M, V No SIP-Auth-Data-Item 612 6.3.13 Grouped M, V No SIP-Item-Number 613 6.3.14 Unsigned32 M, V No Server-Assignment-Type 614 6.3.15 Enumerated M, V No Deregistration-Reason 615 6.3.16 Grouped M, V No Reason-Code 616 6.3.17 Enumerated M, V No Reason-Info 617 6.3.18 UTF8String M, V No Charging-Information 618 6.3.19 Grouped M, V No Primary-Event-Charging-Function-Name 619 6.3.20 DiameterURI M, V No Secondary-Event-Charging-Function-Name 620 6.3.21 DiameterURI M, V No Primary-Charging-Collection-Function-Name 621 6.3.22 DiameterURI M, V No Secondary-Charging-Collection-Function-Name 622 6.3.23 DiameterURI M, V No User-Authorization-Type 623 6.3.24 Enumerated M, V No User-Data-Already-Available 624 6.3.26 Enumerated M, V No Confidentiality-Key 625 6.3.27 OctetString M, V No Integrity-Key 626 6.3.28 OctetString M, V No Supported-Features 628 6.3.29 Grouped V M No Feature-List-ID 629 6.3.30 Unsigned32 V M No Feature-List 630 6.3.31 Unsigned32 V M No Supported-Applications 631 6.3.32 Grouped V M No Associated-Identities 632 6.3.33 Grouped V M No Originating-Request 633 6.3.34 Enumerated M,V No Wildcarded-Public-Identity 634 6.3.35 UTF8String V M No SIP-Digest-Authenticate 635 6.3.36 Grouped V M No Digest-Realm 104 NOTE 3 6.3.37 UTF8String M V No Digest-Algorithm 111 NOTE 3 6.3.39 UTF8String M V No Digest-QoP 110 NOTE 3 6.3.40 UTF8String M V No Digest-HA1 121 NOTE 3 6.3.41 UTF8String M V No UAR-Flags 637 6.3.44 Unsigned32 V M No Loose-Route-Indication 638 6.3.45 Enumerated V M No SCSCF-Restoration-Info 639 6.3.46 Grouped V M No Path 640 6.3.47 OctetString V M No Contact 641 6.3.48 OctetString V M No Subscription-Info 642 6.3.49 Grouped V M No Call-ID-SIP-Header 643 6.3.49.1 OctetString V M No From-SIP-Header 644 6.3.49.2 OctetString V M No To-SIP-Header 645 6.3.49.3 OctetString V M No Record-Route 646 6.3.49.4 OctetString V M No Associated-Registered-Identities 647 6.3.50 Grouped V M No Multiple-Registration-Indication 648 6.3.51 Enumerated V M No Restoration-Info 649 6.3.52 Grouped V M No Session-Priority 650 6.3.56 Enumerated V M No Identity-with-Emergency-Registration 651 6.3.57 Grouped V M No Priviledged-Sender-Indication 652 6.3.58 Enumerated V M No LIA-Flags 653 6.3.59 Unsigned32 V M No OC-Supported-Features 621 NOTE 4 6.3.60 Grouped M, V No OC-OLR 623 NOTE 4 6.3.61 Grouped M, V No Initial-CSeq-Sequence-Number 654 6.3.62 Unsigned32 V M No SAR-Flags 655 6.3.63 Unsigned32 V M No Allowed-WAF-WWSF-Identities 656 6.3.64 Grouped V M No WebRTC-Authentication-Function-Name 657 6.3.65 UTF8String V M No WebRTC-Web-Server-Function-Name 658 6.3.66 UTF8String V M No DRMP 301 NOTE 5 6.3.67 Enumerated M, V No Load NOTE 6 6.3.68 Grouped M, V No RTR-Flags 659 6.3.69 Unsigned32 V M No P-CSCF-Subscription-Info 660 6.3.70 Grouped V M No Registration-Time-Out 661 6.3.71 Time V M No Alternate-Digest-Algorithm 662 NOTEÊ7 6.3.72 UTF8String V M No Alternate-Digest-HA1 663 NOTEÊ7 6.3.73 UTF8String V M No Failed-PCSCF 664 6.3.74 Grouped V M No PCSCF-FQDN 665 6.3.75 DiameterIdentity V M No PCSCF-IP-Address 666 6.3.76 Address V M No NOTE 1: The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETFÊRFCÊ6733Ê[28]. NOTE 1a: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. NOTE 2: Depending on the concrete command. NOTE 3: The value of these attributes is defined in IETFÊRFCÊ4590Ê[20]. NOTE 4: The value of these attributes is defined in IETFÊRFCÊ7683Ê[23]. NOTE 5: The value of this attribute is defined in IETFÊRFCÊ7944Ê[26]. NOTE 6: The value of this attribute is defined in IEFTÊRFCÊ8583Ê[27]. NOTEÊ7: The Alternate-Digest-HA1 AVP is defined in the same way as Digest-HA1 AVP in accordance with IETFÊRFCÊ7616Ê[29]. If the Alternate-Digest-HA1 AVP is present, the Digest-HA1 AVP shall also be present and the Digest-HA1 AVP shall contain the MD5 hash. The algorithm of the Alternate-Digest-HA1 AVP shall be determined by the Alternate-Digest-Algorithm AVP. 6.3.1 Visited-Network-Identifier AVP The Visited-Network-Identifier AVP is of type OctetString. This AVP contains an identifier that helps the HSS to identify the visited network (e.g. the visited network domain name). Coding of octets is H-PLMN operator specific. The I-CSCF maps a received P-Visited-Network-ID onto an Octet String value that is consistently configured in I-CSCF and HSS to uniquely identify the visited network. 6.3.2 Public-Identity AVP The Public-Identity AVP is of type UTF8String. This AVP contains the public identity of a user in the IMS. The syntax of this AVP corresponds either to a SIP URL (with the format defined in IETFÊRFCÊ3261Ê[3] and IETFÊRFCÊ2396Ê[4]) or a TEL URL (with the format defined in IETFÊRFCÊ3966Ê[8]). Both SIP URL and TEL URL shall be in canonical form, as described in 3GPPÊTSÊ23.003Ê[13]. 6.3.3 Server-Name AVP The Server-Name AVP is of type UTF8String. This AVP contains a SIP-URL (as defined in IETFÊRFCÊ3261Ê[3] and IETFÊRFCÊ2396Ê[4]), used to identify a SIP server (e.g. S-CSCF name). 6.3.4 Server-Capabilities AVP The Server-Capabilities AVP is of type Grouped. This AVP contains information to assist the I-CSCF in the selection of an S-CSCF. AVP format Server-Capabilities ::= <AVP header: 603 10415> *[Mandatory-Capability] *[Optional-Capability] *[Server-Name] *[AVP] 6.3.5 Mandatory-Capability AVP The Mandatory-Capability AVP is of type Unsigned32. Each value included in this AVP can be used to represent a single determined mandatory capability or a set of capabilities of an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1] (clauseÊ6.7). 6.3.6 Optional-Capability AVP The Optional-Capability AVP is of type Unsigned32. Each value included in this AVP can be used to represent a single determined optional capability or a set of capabilities of an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1] (clauseÊ6.7). 6.3.7 User-Data AVP The User-Data AVP is of type OctetString."
"This AVP contains the user data required to give service to a user. The exact content and format of this AVP is described in 3GPPÊTSÊ29.228Ê[1]. 6.3.8 SIP-Number-Auth-Items AVP The SIP-Number-Auth-Items AVP is of type Unsigned32. When used in a request, the SIP-Number-Auth-Items indicates the number of authentication vectors the S-CSCF is requesting. This can be used, for instance, when the client is requesting several pre-calculated authentication vectors. In the answer message, the SIP-Number-Auth-Items AVP indicates the actual number of SIP-Auth-Data-Item AVPs provided by the Diameter server. 6.3.9 SIP-Authentication-Scheme AVP The Authentication-Scheme AVP is of type UTF8String and indicates the authentication scheme used in the authentication of SIP messages. The following values are defined: - ""Digest-AKAv1-MD5"": it indicates IMS-AKA authentication scheme. NOTEÊ1: The S-CSCF uses the ""Digest-AKAv1-MD5"" authentication scheme towards the HSS for Digest-AKAv1 and Digest-AKAv2 versions. E.g. digest algorithms ""AKAv1-MD5"" and ""AKAv2-SHA-256"" require from the HSS the same procedures i.e. the same authentication information: random number RAND, authentication token AUTN, expected response XRES, cipher key CK and integrity key IK. NOTEÊ2: The ""AKAv1-MD5"" digest AKA algorithm is only supported for backward compatibility. - ""SIP Digest"": it indicates SIP Digest authentication scheme. - ""NASS-Bundled"": it indicates NASS Bundled authentication scheme. - ""Early IMS Security"": it indicates GPRS-IMS-Bundled authentication scheme. - ""Unknown"": it indicates that the authentication scheme to be used is unknown at this point. 6.3.10 SIP-Authenticate AVP The SIP-Authenticate AVP is of type OctetString and contains specific parts of the data portion of the WWW-Authenticate or Proxy-Authenticate SIP headers that are to be present in a SIP response. It shall contain, binary encoded, the concatenation of the authentication challenge RAND and the token AUTN. See 3GPPÊTSÊ33.203Ê[3] for further details about RAND and AUTN. The Authentication Information has a fixed length of 32 octets; the 16 most significant octets shall contain the RAND, the 16 least significant octets shall contain the AUTN. 6.3.11 SIP-Authorization AVP The SIP-Authorization AVP is of type OctetString and contains specific parts of the data portion of the Authorization or Proxy-Authorization SIP headers suitable for inclusion in a SIP request. When included in an Authentication Request, it shall contain the concatenation of RAND, as sent to the terminal, and AUTS, as received from the terminal. RAND and AUTS shall both be binary encoded. See 3GPPÊTSÊ33.203Ê[3] for further details about RAND and AUTS. The Authorization Information has a fixed length of 30 octets; the 16 most significant octets shall contain the RAND, the 14 least significant octets shall contain the AUTS. When included in an Authentication Request Response, it shall contain, binary encoded, the expected response XRES. See 3GPPÊTSÊ33.203Ê[3] for further details about XRES. 6.3.12 SIP-Authentication-Context AVP The SIP-Authentication-Context AVP is of type OctectString. 6.3.13 SIP-Auth-Data-Item AVP The SIP-Auth-Data-Item is of type Grouped, and contains the authentication and/or authorization information for the Diameter client. AVP format SIP-Auth-Data-Item :: = < AVP Header : 612 10415 > [ SIP-Item-Number ] [ SIP-Authentication-Scheme ] [ SIP-Authenticate ] [ SIP-Authorization ] [ SIP-Authentication-Context ] [ Confidentiality-Key ] [ Integrity-Key ] [ SIP-Digest-Authenticate ] [ Framed-IP-Address ] [ Framed-IPv6-Prefix ] [ Framed-Interface-Id ] *Ê[ Line-Identifier ] *Ê[AVP] 6.3.14 SIP-Item-Number AVP The SIP-Item-Number AVP is of type Unsigned32. 6.3.15 Server-Assignment-Type AVP The Server-Assignment-Type AVP is of type Enumerated, and indicates the type of server update, request or notification being performed in a Server-Assignment-Request operation. The following values are defined: NO_ASSIGNMENT (0) This value is used to request from HSS the user profile assigned to one or more public identities and to retrieve the S-CSCF restoration information for a registered Public User Identity, without affecting the registration state of those identities. REGISTRATION (1) The request is generated as a consequence of a first registration of an identity. RE_REGISTRATION (2) The request corresponds to the re-registration of an identity or update of the S-CSCF Restoration Information. UNREGISTERED_USER (3) The request is generated in the following cases: - The S-CSCF received a request for a Public Identity that is not registered, or - An AS sent an originating request on behalf of a Public Identity that is not registered, or - The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with only one Private User Identity and started the P-CSCF Restoration procedure including the P-CSCF Restoration Indication in the request to the HSS. TIMEOUT_DEREGISTRATION (4) The SIP registration timer of an identity has expired. USER_DEREGISTRATION (5) The S-CSCF has received a user initiated de-registration request. TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) The request is generated in the following cases: The SIP registration timer of an identity has expired. The S-CSCF keeps the user data stored in the S-CSCF and requests HSS to store the S-CSCF name. The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with only one Private User Identity and started the PCRF-based P-CSCF Restoration procedure. USER_DEREGISTRATION_STORE_SERVER_NAME (7) The S-CSCF has received a user initiated de-registration request. The S-CSCF keeps the user data stored in the S-CSCF and requests HSS to store the S-CSCF name. ADMINISTRATIVE_DEREGISTRATION (8) The request is generated in the following cases: - The S-CSCF, due to administrative reasons or network issues, has performed the de-registration of an identity. - The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with more than one Private User Identity and started the P-CSCF Restoration procedure including the P-CSCF Restoration Indication in the request to the HSS. The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with more than one Private User Identity and started the PCRF-based P-CSCF Restoration procedure. AUTHENTICATION_FAILURE (9) The authentication of a user has failed. AUTHENTICATION_TIMEOUT (10) The authentication timeout has occurred. DEREGISTRATION_TOO_MUCH_DATA (11) The S-CSCF has requested user profile information from the HSS and has received a volume of data higher than it can accept. AAA_USER_DATA_REQUEST (12) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. PGW_UPDATE (13) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. RESTORATION (14) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. 6.3.16 Deregistration-Reason AVP The Deregistration-Reason AVP is of type Grouped, and indicates the reason for a de-registration operation. AVP format Deregistration-Reason :: = < AVP Header : 615 10415 > { Reason-Code } [ Reason-Info ] *Ê[AVP] 6.3.17 Reason-Code AVP The Reason-Code AVP is of type Enumerated, and defines the reason for the network initiated de-registration. The following values are defined: PERMANENT_TERMINATION (0) NEW_SERVER_ASSIGNED (1) SERVER_CHANGE (2) REMOVE_S-CSCF (3) The detailed behaviour of the S-CSCF is defined in 3GPPÊTSÊ29.228Ê[1]. 6.3.18 Reason-Info AVP The Reason-Info AVP is of type UTF8String, and contains textual information to inform the user about the reason for a de-registration. 6.3.19 Charging-Information AVP The Charging-Information is of type Grouped, and contains the addresses of the charging functions. AVP format Charging-Information :: = < AVP Header : 618 10415 > [ Primary-Event-Charging-Function-Name ] [ Secondary-Event-Charging-Function-Name ] [ Primary-Charging-Collection-Function-Name ] [ Secondary-Charging-Collection-Function-Name ] *[ AVP] 6.3.20 Primary-Event-Charging-Function-Name AVP The Primary-Event-Charging-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Primary Online Charging Function. The receiving network element shall extract the FQDN of the DiameterURI in this AVP and may use it as content of the Destination-Host AVP for the Diameter accounting requests. The parent domain of the FQDN in the DiameterURI shall be used as Destination-Realm. The number of labels used for the Destination-Realm shall be determined before the Charging Information is provisioned and may be a configuration option. NOTE: A FQDN is an absolute domain name including a subdomain and its parent domain. The subdomain and the parent domain contain one or more labels separated by dots. 6.3.21 Secondary-Event-Charging-Function-Name AVP The Secondary-Event-Charging-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Secondary Online Charging Function. The Destination-Host and Destination-Realm values for the Diameter accounting requests should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.22 Primary-Charging-Collection-Function-Name AVP The Primary-Charging-Collection-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Primary Charging Data Function. The Destination-Host and Destination-Realm values for the Diameter accounting requests should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.23 Secondary-Charging-Collection-Function-Name AVP The Secondary-Charging-Collection-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Secondary Charging Data Function. The Destination-Host and Destination-Realm for the Diameter accounting requests values should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.24 User-Authorization-Type AVP The User-Authorization-Type AVP is of type Enumerated, and indicates the type of user authorization being performed in a User Authorization operation, i.e. UAR command. The following values are defined: REGISTRATION (0) This value is used in case of the initial registration or re-registration. I-CSCF determines this from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is not equal to zero. This is the default value. DE_REGISTRATION (1) This value is used in case of the de-registration. I-CSCF determines this from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is equal to zero. REGISTRATION_AND_CAPABILITIES (2) This value is used when the I-CSCF explicitly requests S-CSCF capability information from the HSS. The I-CSCF shall use this value when the user's current S-CSCF, which is stored in the HSS, cannot be contacted and a new S-CSCF needs to be selected 6.3.25 Void 6.3.26 User-Data-Already-Available AVP The User-Data-Already-Available AVP is of type Enumerated, and indicates to the HSS whether or not the S-CSCF already has the part of the user profile that it needs to serve the user. The following values are defined: USER_DATA_NOT_AVAILABLE (0) The S-CSCF does not have the data that it needs to serve the user. USER_DATA_ALREADY_AVAILABLE (1) The S-CSCF already has the data that it needs to serve the user. 6.3.27 Confidentiality-Key AVP The Confidentiality-Key is of type OctetString, and contains the Confidentiality Key (CK). 6.3.28 Integrity-Key AVP The Integrity-Key is of type OctetString, and contains the Integrity Key (IK). 6.3.29 Supported-Features AVP The Supported-Features AVP is of type Grouped. If this AVP is present it may inform the destination host about the features that the origin host supports for the application. The Feature-List AVP contains a list of supported features of the origin host. The Vendor-Id AVP and the Feature-List-ID AVP shall together identify which feature list is carried in the Supported-Features AVP for the Application-ID present in the command header. Where a Supported-Features AVP is used to identify features that have been defined by 3GPP, the Vendor-Id AVP shall contain the vendor ID of 3GPP. Vendors may define proprietary features, but it is strongly recommended that the possibility is used only as the last resort. Where the Supported-Features AVP is used to identify features that have been defined by a vendor other than 3GPP, it shall contain the vendor ID of the specific vendor in question. If there are multiple feature lists defined by the same vendor and the same application, the Feature-List-ID AVP shall differentiate those lists from one another. The destination host shall use the value of the Feature-List-ID AVP to identify the feature list. AVP format Supported-Features ::= < AVP header: 628 10415 > { Vendor-Id } { Feature-List-ID } { Feature-List } *[AVP] 6.3.30 Feature-List-ID AVP The Feature-List-ID AVP is of type Unsigned32 and it contains the identity of a feature list. 6.3.31 Feature-List AVP The Feature-List AVP is of type Unsigned32 and it contains a bit mask indicating the supported features of an application. When the bit set, indicates the corresponding feature is supported by the application. For the Cx application, the meaning of the bits has been defined in 7.1.1. 6.3.32 Supported-Applications AVP The Supported-Applications AVP is of type Grouped and it contains the supported application identifiers of a Diameter node. AVP format Supported-Applications ::= < AVP header: 631 10415 > *[ Auth-Application-Id ] *[ Acct-Application-Id ] *[ Vendor-Specific-Application-Id ] *[ AVP ] 6.3.33 Associated-Identities AVP The Associated-Identities AVP is of type Grouped and it contains the private user identities associated to an IMS subscription. AVP format Associated-Identities ::= < AVP header: 632, 10415 > *[ User-Name ] *[ AVP ] 6.3.34 Originating-Request AVP The Originating-Request AVP is of type Enumerated. The following value is defined: ORIGINATING (0) This value indicates to the HSS that the request is related to an AS originating SIP request in the Location-Information-Request operation. 6.3.35 Wildcarded-Public-Identity AVP The Wildcarded-Public-Identity AVP is of type UTF8String. This AVP contains a Wildcarded PSI or Wildcarded Public User Identity stored in the HSS. The syntax of the contents of this AVP is described in 3GPPÊTSÊ23.003Ê[13]. 6.3.36 SIP-Digest-Authenticate AVP The SIP-Digest-Authenticate is of type Grouped and it contains a reconstruction of either the SIP WWW-Authenticate or Proxy-Authentication header fields specified in IETFÊRFCÊ7616Ê[29]. AVP format SIP-Digest-Authenticate ::= < AVP Header: 635 10415> { Digest-Realm } Ê[ Digest-Algorithm ] { Digest-QoP } { Digest-HA1} [ Alternate-Digest-Algorithm ] [ Alternate-Digest-HA1 ] *[ AVP ] 6.3.37 Digest-Realm AVP The Digest-Realm AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.38 Void 6.3.39 Digest-Algorithm AVP The Digest-Algorithm AVP is defined in IETFÊRFCÊ4740Ê[15] and contains values as defined in IETFÊRFCÊ7616Ê[29]. NOTE: The MD5 algorithm is only supported for backward compatibility. 6.3.40 Digest-QoP AVP The Digest-QoP AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.41 Digest-HA1 AVP The Digest-HA1 AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.42 Line-Identifier AVP The Line-Identifier AVP is of type OctetString. This AVP has Vendor Id ETSI (13019) and AVP code 500. This AVP contains a fixed broadband access line identifier associated with the user. 6.3.43 Wildcarded-IMPU AVP The Wildcarded-IMPU AVP is of type UTF8String. This AVP contains a Wildcarded Public User Identity stored in the HSS. The syntax of the contents of this AVP is described in 3GPPÊTSÊ23.003Ê[13]. Note: This AVP is used by Sh interface as specified in the 3GPPÊTSÊ29.328Ê[16] and 3GPPÊTSÊ29.329Ê[11]. 6.3.44 UAR-Flags AVP The UAR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in the following table: Table 6.3.44.1: UAR-Flags Bit Name Description 0 IMS Emergency Registration This bit, when set, indicates that the request corresponds to an IMS Emergency Registration. Bits not defined in this table shall be cleared by the sending I-CSCF and discarded by the receiving HSS. 6.3.45 Loose-Route-Indication AVP The Loose-Route-Indication AVP is of type Enumerated and indicates to the S-CSCF whether or not the loose route mechanism is required to serve the registered Public User Identities. The following values are defined: LOOSE_ROUTE_NOT_REQUIRED (0) LOOSE_ROUTE_REQUIRED (1) 6.3.46 SCSCF-Restoration-Info AVP The SCSCF-Restoration-Info AVP is of type Grouped and it contains the information required for an S-CSCF to handle the requests for a user. AVP format SCSCF-Restoration-Info ::= < AVP Header: 639, 10415> { User-Name } 1*{ Restoration-Info } [ Registration-Time-Out ] [ SIP-Authentication-Scheme ] *[ AVP ] 6.3.47 Path AVP The Path AVP is of type OctetString and it contains a comma separated list of SIP proxies in the Path header as defined in IETFÊRFCÊ3327Ê[17]. 6.3.48 Contact AVP The Contact AVP is of type OctetString and it contains the Contact Addresses and Parameters in the Contact header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49 Subscription-Info AVP The Subscription-Info AVP is of type Grouped and it contains the UE's subscription information. The Contact AVP contains the Contact Address and Parameters in the Contact header of the subscription request. AVP format Subscription-Info ::= < AVP Header: 642, 10415> { Call-ID-SIP-Header } { From-SIP-Header } { To-SIP-Header } { Record-Route } {Contact} *[ AVP ] 6.3.49.1 Call-ID-SIP-Header AVP The Call-ID-SIP-Header AVP is of type OctetString and it contains the information in the Call-ID header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.2 From-SIP-Header AVP The From-SIP-Header AVP is of type OctetString and it contains the information in the From header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.3 To-SIP-Header AVP The To-SIP-Header AVP is of type OctetString and it contains the information in the To header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.4 Record-Route AVP The Record-Route AVP is of type OctetString and it contains a comma separated list of Record Route header(s) as defined in IETFÊRFCÊ3261Ê[11]. 6.3.50 Associated-Registered-Identities AVP The Associated-Registered-Identities AVP is of type Grouped and it contains the Private User Identities registered with the Public User Identity received in the request command. AVP format Associated-Registered-Identities ::= < AVP header: 647, 10415 > *[ User-Name ] *[ AVP ] 6.3.51 Multiple-Registration-Indication The Multiple-Registration-Indication AVP is of type Enumerated and indicates to the HSS whether or not the request is related to a multiple registration. The following values are defined: NOT_MULTIPLE_REGISTRATION (0) MULTIPLE_REGISTRATION (1) 6.3.52 Restoration-Info AVP The Restoration-Info AVP is of type Grouped and it contains the information related to a specific registration required for an S-CSCF to handle the requests for a user. The Contact AVP contains the Contact Address and Parameters in the Contact header of the registration request. AVP format Restoration-Info ::= < AVP Header: 649, 10415> { Path } { Contact } [ Initial-CSeq-Sequence-Number ] [ Call-ID-SIP-Header ] [ Subscription-Info ] [ P-CSCF-Subscription-Info ] *[ AVP ] 6.3.53 Framed-IP-Address AVP The Framed-IP-Address AVP is defined in IETFÊRFCÊ4005Ê[19]. 6.3.54 Framed-IPv6-Prefix AVP The Framed-IPv6-Prefix AVP is defined in IETFÊRFCÊ4005Ê[19], and it shall be encoded as defined in IETFÊRFCÊ3162Ê[22]. 6.3.55 Framed-Interface-Id AVP The Framed-Interface-Id AVP is defined in IETFÊRFCÊ4005Ê[19]. 6.3.56 Session-Priority AVP The Session-Priority AVP is of type Enumerated and indicates to the HSS the session's priority. The following values are defined: PRIORITY-0 (0) PRIORITY-1 (1) PRIORITY-2 (2) PRIORITY-3 (3) PRIORITY-4 (4) PRIORITY-0 is the highest priority. The value of the AVP when sent to the HSS is mapped from the value received by the CSCF as described in 3GPPÊTSÊ24.229 table A.162. The mapping is operator specific. This AVP may be placed as close to the Diameter header as possible in order to potentially allow optimized processing at the receiver. 6.3.57 Identity-with-Emergency-Registration AVP The Identity-with-Emergency-Registration AVP is of type Grouped and it contains a pair of private/public user identities which are emergency registered. AVP format Identity-with-Emergency-Registration ::= < AVP header: 651, 10415 > { User-Name } { Public-Identity } *[ AVP ] 6.3.58 Priviledged-Sender-Indication AVP The Priviledged-Sender-Indication AVP is of type Enumerated and indicates to the S-CSCF whether or not the Private User Identity shall be considered as a priviledged sender. The following values are defined: NOT_PRIVILEDGED_SENDER (0)PRIVILEDGED_SENDER (1) 6.3.59 LIA-Flags The LIA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.59.1. Table 6.3.59.1: LIA-Flags Bit Name Description 0 PSI Direct Routing Indication This bit, when set, indicates the request corresponds to PSI Direct Routing, what implies that HSS returns an AS name in Server-Name AVP. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving I-CSCF. 6.3.60 OC-Supported-Features The OC-Supported-Features AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[23]. This AVP is used to support Diameter overload control mechanism. 6.3.61 OC-OLR The OC-OLR AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[23]. This AVP is used to support Diameter overload control mechanism. 6.3.62 Initial-CSeq-Sequence-Number AVP The Initial-CSeq-Sequence-Number AVP is of type Unsigned32, and it contains the sequence number of the CSeq header field contained in the initial successful REGISTER request, as defined in IETFÊRFCÊ3261Ê[11]. 6.3.63 SAR-Flags The SAR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in the following table: Table 6.3.63.1: SAR-Flags Bit Name Description 0 P-CSCF Restoration Indication This bit, when set, indicates that the P-CSCF-Restoration-mechanism feature shall be executed, as described in 3GPPÊTSÊ23.380Ê[24], clauseÊ5.4. This AVP is optionally present only when Server-Assignment-Type takes the value ADMINISTRATIVE_DEREGISTRATION or UNREGISTERED_USER. Note: Bits not defined in this table shall be cleared by the sending S-CSCF and discarded by the receiving HSS. 6.3.64 Allowed-WAF-WWSF-Identities AVP The Allowed-WAF-WWSF-Identities AVP is of type Grouped and contains the addresses of the WAFs and WWSFs allowed for the subscription. AVP format Allowed-WAF-WWSF-Identities :: = < AVP Header : 656 10415 > *[ WebRTC-Authentication-Function-Name ] *[ WebRTC-Web-Server-Function-Name ] *[ AVP] 6.3.65 WebRTC-Authentication-Function-Name AVP The WebRTC-Authentication-Function-Name AVP is of type UTF8String and contains the address of a WAF allowed for the subscription. For the format of the string see IETF draft-holmberg-sipcore-auth-id-01Ê[25]. 6.3.66 WebRTC-Web-Server-Function-Name AVP The WebRTC-Web-Server-Function-Name AVP is of type UTF8String and contains the address of a WWSF allowed for the subscription. For the format of the string see IETF draft-holmberg-sipcore-auth-id-01Ê[25]. 6.3.67 DRMP AVP The DRMP AVP is of type Enumerated and it is defined in IETFÊRFCÊ7944Ê[26]. This AVP allows the HSS/SLF and the S-CSCF/I-CSCF to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message. 6.3.68 Load The Load AVP is of type Grouped and it is defined in IEFTÊRFCÊ8583Ê[27]. This AVP is used to support the Diameter load control mechanism. 6.3.69 RTR-Flags The RTR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.69.1. Table 6.3.69.1: RTR-Flags Bit Name Description 0 Reference Location Information change This bit, when set, indicates the request is sent due to change of Reference Location Information. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving I-CSCF. 6.3.70 P-CSCF-Subscription-Info AVP The P-CSCF-Subscription-Info AVP is of type Grouped and it contains the P-CSCF''s subscription information. The Contact AVP contains the Contact Address and Parameters in the Contact header of the subscription request. AVP format P-CSCF-Subscription-Info ::= < AVP Header: 660, 10415> { Call-ID-SIP-Header } { From-SIP-Header } { To-SIP-Header } { Contact } *[ AVP ] 6.3.71 Registration-Time-Out The Registration-Time-Out AVP is of type Time (see IETFÊRFCÊ6733Ê[28]), and contains the point of time at which the UE's registration expires. 6.3.72 Alternate-Digest-Algorithm AVP The Alternate-Digest-Algorithm AVP contains algorithm values specified in IETFÊRFCÊ7616Ê[29]. NOTE: The MD5 algorithm is only supported for backward compatibility and can only be provided within the Digest-Algorithm AVP. 6.3.73 Alternate-Digest-HA1 AVP The Alternate-Digest-HA1 AVP contains H(A1) value specified in IETFÊRFCÊ7616Ê[29]. 6.3.74 Failed-PCSCF The Failed-PCSCF AVP is of type Grouped and contains the FQDN and/or IP addresses of the failed P-CSCF. AVP format Failed-PCSCF ::= < AVP Header: 664, 10415> [ PCSCF-FQDN ] *[ PCSCF-IP-Address ] *[ AVP ] 6.3.75 PCSCF-FQDN The PCSCF-FQDN AVP is of type DiameterIdentity and contains the FQDN of the P-CSCF. 6.3.76 PCSCF-IP-Address The PCSCF-IP-Address AVP is of type Address and contains the IPv4 or IPv6 address of the P-CSCF. 6.4 Use of namespaces This clause contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA. 6.4.1 AVP codes This specification assigns the AVP values from the AVP Code namespace managed by 3GPP for its Diameter vendor-specific applications. See clauseÊ6.3 for the assignment of the namespace in this specification. 6.4.2 Experimental-Result-Code AVP values This specification has assigned Experimental-Result-Code AVP values 2001-2005 and 5001-5011. See clauseÊ6.2. 6.4.3 Command Code values This specification assigns the values 300-305 from the range allocated by IANA to 3GPP in IETFÊRFCÊ3589Ê[12]. 6.4.4 Application-ID value IANA has allocated the value 16777216 for the 3GPP Cx interface application. 7 Special Requirements 7.1 Version Control New functionality - i.e. functionality beyond the Rel-5 standard - shall be introduced by post-Rel-5 versions of this specification to the Diameter applications as follows: 1. If possible, the new functionality shall be defined optional. 2. If backwards incompatible changes can not be avoided, the new functionality should be introduced as a feature, see 7.1.1. 3. If the change would be backwards incompatible even as if it was defined as a feature, a new version of the interface shall be created by changing the application identifier of the Diameter application, see 7.1.2. 7.1.1 Defining a new feature The base functionality for the Cx is the 3GPP Rel-5 standard and a feature is an extension to that functionality. A feature is a functional entity that has a significant meaning to the operation of a Diameter application i.e. a single new parameter without a substantial meaning to the functionality of the Diameter endpoints should not be defined to be a new feature. If the support for a feature is defined mandatory in a post-Rel-5 versions of this specification, the feature concept enables interworking between Diameter endpoints regardless of whether they support all, some or none of the features of the application. Features should be defined so that they are independent from one another. The content of a feature shall be defined as a part of the specification of the affected application messages. If new AVPs are added to the commands because of the new feature, the new AVPs shall have the 'M' bit cleared and the AVP shall not be defined mandatory in the command ABNF. The support for a feature may be defined to be mandatory behaviour of a node. As an option to defining a feature, an extension to S-CSCF functionality for post-Rel-5 version may be defined as part of the list of mandatory capabilities that is used by the I-CSCF during the process of selecting an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1]. Any new feature should be taken into account in the definition of the list of mandatory and optional S-CSCF capabilities. Guidelines for the definition of S-CSCF Capabilities are described in 3GPPÊTSÊ29.228Ê[1]. The following table of features shall apply to the Cx interface. Table 7.1.1: Features of Feature-List-ID 1 used in Cx Feature bit Feature M/O Description 0 SiFC O Shared iFC sets This feature is applicable for the SAR/SAA and PPR/PPA command pairs. If both the HSS and the S-CSCF support this feature, subsets of Initial Filter Criteria may be shared by several service profiles and the HSS shall download the shared iFC sets implicitly by downloading the unique identifiers of the shared iFC sets to the S-CSCF. By means of a locally administered database, the S-CSCF then maps the downloaded identifiers onto the shared iFC sets. If the DSAI feature, as defined in 3GPPÊTSÊ29.328Ê[16], is also active with the shared iFC sets feature then the HSS shall behave as described below: If the DSAI feature is active with the shared iFC sets feature and if all the iFCs bounding to a Shared iFC set are not masked by the DSAI, the HSS shall download the unique identifier of the shared iFC set to the S-CSCF. If some iFCs or all the iFCs bounding to a shared iFC set are masked by the DSAI, the HSS shall not download the identifier of the shared iFC set. Instead the HSS shall - download the remaining non masked iFCs of the shared iFC set explicitly or - download suitable identifiers of other shared iFC sets, i.e. those covering exactly the remaining non masked iFCs and which do not contain masked iFCs or - download a combination of identifiers of shared iFC sets and explicit iFCs which cover exactly the remaining non masked iFCs. If the S-CSCF does not support this feature, the HSS shall not download identifiers of shared iFC sets. Instead as a default behavior the HSS shall (by means of a locally administered database) download the iFCs of a shared iFC set explicitly. If the HSS does not support this feature, no special default behaviour is required for the S-CSCF. Note: In using this feature option, the network operator is responsible for keeping the local databases in the S-CSCFs and HSSs consistent. 1 AliasInd M Alias Indication This feature is applicable for the SAR/SAA and PPR/PPA command pairs. If both the HSS and the S-CSCF support this feature, different aliases groups may be sent within the same service profile. Identities within the same service profile that are aliases shall be sent with identical alias group ID. If the S-CSCF does not support this feature, the HSS shall send within the service profile only those identities that are aliases. Public User Identities that are not aliases of each other shall be sent in different service profiles even if these service profiles have exactly the same Core Network Service Authorization, Initial Filter Criteria, and Shared iFC Set information and these service profiles only differ in the contained Public User Identities. This is done in order to allow backwards compatibility since part of the handling of aliases in the S-CSCF was there before this indication was required and it applied to identities that share the same service profile and implicit registration set. In this case, the S-CSCF does not provide any additional treatment of aliases than that which existed before this indication was required. If the HSS does not support this feature, no special default behaviour is required for the S-CSCF. Note: All identities included in a single SAA or PPR command are always within one implicit registration set. 2 IMSRestorationInd O IMS Restoration Indication This feature is applicable for the UAR/UAA, LIR/LIA, SAR/SAA command pairs. If both the HSS and the I-CSCF support this feature, in case the S-CSCF currently assigned in the HSS to the Public User Identity cannot be contacted the I-CSCF shall trigger the assignment of a new S-CSCF. If both the HSS and the S-CSCF support this feature, the S-CSCF shall send S-CSCF Restoration Information to the HSS. The HSS shall send this information element in SAA to the S-CSCF when required. If the S-CSCF does not support this feature, the HSS shall not send the IMS Restoration Information to the S-CSCF. 3 P-CSCF-Restoration-mechanism O HSS-based P-CSCF Restoration mechanism. This feature is applicable for the SAR/SAA command pair. If both the HSS and the S-CSCF support this feature, the S-CSCF shall send the P-CSCF-Restoration-Indication in SAR-Flags AVP to the HSS when required as described by 3GPPÊTSÊ23.380Ê[24] clauseÊ5.4. If the HSS does not support this feature, the S-CSCF shall not send the P-CSCF-Restoration-Indication to HSS. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""MOM"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. The origin host may discover the supported features of the destination host with the dynamic discovery mechanism defined in 7.2 or via local O&M interfaces. 7.1.2 Changing the version of the interface The version of an interface shall be changed by a future version of this specification only if there is no technically feasible means to avoid backwards incompatible changes to the Diameter application, i.e. to the current version of the interface. However, if the incompatible changes can be capsulated within a feature, there is no need to change the version of the interface. The versioning of an interface shall be implemented by assigning a new application identifier for the interface. This procedure is in line with the Diameter base protocol (see IETFÊRFCÊ3588) which defines that if an incompatible change is made to a Diameter application, a new application identifier shall be assigned for the Diameter application. The following table shall apply to the Cx interface, column Application identifier lists the used application identifiers on Cx and 3GPP. Table 7.1.2: Application identifiers used in Cx Application identifier First applied 16777216 3GPP Rel-5 The origin host may discover which versions of an interface the destination host supports within the capabilities exchange (i.e. CER/CEA command), via the error messages defined in the clauseÊ7.3 or via local O&M interfaces. 7.2 Supported features Features that are not indicated in the Supported-Features AVPs within a given application message shall not be used to construct that message. A request application message shall always be compliant with the list of supported features indicated in the Supported-Features AVPs within the application message. If a feature does not have an effect on constructing an application message, the message is by definition compliant with the feature. If no features are indicated in the application message, no features - i.e. no extensions to Rel-5 - shall be used to construct the application message. An answer application message shall always indicate in the Supported-Features AVPs the complete set of features supported by the sender of the answer application message. An answer application message shall be compliant with the features commonly supported by the sender of the request and answer application messages. The sender of a request application message shall discover for a given application message pair which features a destination host supports as described in 7.2.1. The discovered features of one command pair may be applicable to other command pairs within the application. Different commands within an application may support a different set of features. After discovering the features a destination host supports for a given application message pair, the sender of the request application message may store the information on the supported features of the destination host and it may use the features the destination host supports to construct the subsequent request application messages sent to the destination host. 7.2.1 Dynamic discovery of supported features When sending a request application message to a destination host whose supported features the sender does not know, the request application message shall include the Supported-Features AVP containing the set of features required to process the request and generate the answer. An exception to this is where the origin host does not use any features to construct the request application message and it is not prepared to accept an answer application message which is constructed by making use of any features. For this exception the origin host need not include the Supported-Features AVP within the message. The Supported-Features AVP within a request application message shall always have the 'M' bit set and within an answer application message the AVP shall never have the 'M' bit set. An exception to this is where the origin host does not use any supported feature to construct the request application message but is prepared to accept an answer application message which is constructed by making use of supported features. For this exception it is optional for the origin host to set the 'M' bit of the Supported-Features AVP within the request application message. On receiving a request application message, the destination host shall do one of the following: - If it supports all features indicated in the Supported-Features AVPs within the request message, the answer application message shall include Supported-Features AVPs identifying the complete set of features that it supports. The Experimental-Result-Code AVP shall not be set to DIAMETER_ERROR_FEATURE_UNSUPPORTED. - If the request application message does not contain any Supported-Features AVPs, the answer application message shall include either Supported-Features AVPs identifying the complete set of features that it supports or, if it does not support any features, no Supported-Features AVPs shall be present. The Experimental-Result-Code AVP shall not be set to DIAMETER_ERROR_FEATURE_UNSUPPORTED. - If it does not support all the features indicated in the Supported-Features AVPs with the 'M' bit set, it shall return the answer application message with the Experimental-Result-Code AVP set to DIAMETER_ERROR_FEATURE_UNSUPPORTED and it shall include also Supported-Features AVPs containing lists of all features that it supports. - If it does not support Supported-Features AVP and it receives a request application message containing Supported-Features AVPs with the 'M' bit set, it will return the answer application message with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED and a Failed-AVP AVP containing at least one Supported-Features AVP as received in the request application message. If an answer application message is received with the Experimental-Result-Code AVP set to DIAMETER_ERROR_FEATURE_UNSUPPORTED or with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED, the sender of the request application message may, based on the information in the received Supported-Features AVP or the lack of the AVP in the message, re-send the Diameter message containing only the common supported features. 7.3 Interface versions The sender of the request application message may discover which versions of an interface a destination host supports together with the capabilities exchange (i.e. CER/CEA command pair) and with error mechanisms defined to the application messages in 7.3.1. The sender of the request application message should store information on all versions of the interface the destination host supports. The sender of the request application message should use the latest common version of the application supported by the destination host to send the request. If the receiver of the request application message itself or the versions of the interface it supports are not yet known, the sender of the request application message should use the latest supported version of the interface of the Diameter peer (i.e. Diameter proxy, redirect or relay agent) discovered during the capabilities exchange. If the Diameter peer is a redirect or relay agent, which advertises the 0xffffffff as an application identifier, the sender of the request application message shall use its own latest supported version of the interface when initiating the request."
"7.3.1 Discovery of supported interface versions When a Diameter agent receives a request application message and the Diameter agent doesn't find any upstream peer that would support the application identifier indicated in the request, the Diameter agent shall return the result code DIAMETER_UNABLE_TO_DELIVER and it may also return the list of the application identifiers, which are supported by the destination host of the request application message. The supported application identifiers are carried in the answer application message in the Supported-Applications grouped AVP. Message format for the answer application message (based on the RFC 3588, clauseÊ7.2) is as follows: <answer-message> ::= < Diameter Header: code, ERRÊ[PXY] > 0*1< Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Reporting-Host ] [ Proxy-Info ] [ Supported-Applications ] *Ê[ AVP ] If the receiver of a request application message does not support the application identifier indicated in the message, it shall return the result code DIAMETER_APPLICATION_UNSUPPORTED and it may also return the list of all application identifiers it supports. The supported application identifiers are carried in the Supported-Applications grouped AVP. The error message format is as specified above. If an answer application message is received with Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER or Experimental-Result-Code AVP set to DIAMETER_APPLICATION_UNSUPPORTED and the message contains the Supported-Applications AVP, the receiver of the answer application message may select, based on the information in the Supported-Applications AVP, the latest common version of the interface with the destination host and re-send the Diameter message with a structure conforming to the ABNF of that release. Annex A (informative): Change history Date TSGÊ# TSG Doc. CR# Rev Cat Subject/Comment Out Jun 2002 CN#16 NP-020265 Version 2.0.0 approved at CN#16 5.0.0 Sep 2002 CN#17 NP-020449 001 - Add a reference to the new IETFÊRFCÊon SCTP checksum 5.1.0 Sep 2002 CN#17 NP-020449 003 - Wrong format of Charging Function Addresses 5.1.0 Sep 2002 CN#17 NP-020449 005 - Editorial mistake in the definition of command MAA 5.1.0 Dec 2002 CN#18 NP-020587 006 - Addition of User-Name AVP to SAA 5.2.0 Dec 2002 CN#18 NP-020587 007 - Editorial correction of SIP-Auth-Data-Item AVP definition 5.2.0 Dec 2002 CN#18 NP-020589 008 1 Clarification of REGISTRATION_AND_CAPABILITIES value 5.2.0 Dec 2002 CN#18 NP-020588 009 - Correction in charging information 5.2.0 Dec 2002 CN#18 NP-020590 010 1 Error handling in S-CSCF when receiving too much data 5.2.0 Mar 2003 CN#19 NP-030101 012 1 Update TS 29.229 after Diameter has become RFC 5.3.0 Mar 2003 CN#19 NP-030101 015 1 Clarification on Re-allocation of S-CSCF 5.3.0 Mar 2003 CN#19 NP-030101 018 1 Handling of non supported data in the S-CSCF when the profile is being updated. 5.3.0 Mar 2003 CN#19 NP-030101 014 - Correction to the values of User-Authorizatin-Type AVP 5.3.0 Mar 2003 CN#19 NP-030101 013 - Replacement of the NAS-Session-Key AVP 5.3.0 Jun 2003 CN#20 NP-030215 019 - Conditionality of User-Name AVP in Server-Assignment-Answer 5.4.0 Sep 2003 CN#21 NP-030383 022 1 Critical Correction on the PPR command code 5.5.0 Dec 2003 CN#22 NP-030500 021 1 The S-CSCF name needs to be checked always in MAR and SAR 5.6.0 Dec 2003 CN#22 NP-030500 027 - User-Authorization-Type 5.6.0 Dec 2003 CN#22 NP-030518 029 - Clarification of inclusion of elements in Charging Information 5.6.0 Dec 2003 CN#22 Application IDs and references updated 5.6.0 Mar 2004 CN#23 NP-040055 035 - Error for no identification in SAR command 6.0.0 Jun 2004 CN#24 NP-040215 037 1 Update of the charging addresses from HSS 6.1.0 Jun 2004 CN#24 NP-040215 043 - Multimedia-Auth-Request (MAR) Command Message Format Corrections 6.1.0 Jun 2004 CN#24 NP-040215 050 2 Use of Vendor-Id by 3GPP 6.1.0 Sep 2004 CN#25 NP-040395 065 2 Application version control 6.2.0 Sep 2004 CN#25 NP-040401 056 - Optimization of User Profile Download 6.2.0 Sep 2004 CN#25 NP-040396 058 - Simplification of the User Profile Split concept 6.2.0 Sep 2004 CN#25 NP-040401 061 - Correction of the Application-Id code 6.2.0 Sep 2004 CN#25 NP-040412 063 1 Re-numbering of 3GPP specific AVP codes 6.2.0 Dec 2004 CN#26 NP-040523 070 - Cx ABNF corrections 6.3.0 Mar 2005 CN#27 NP-050030 078 2 Correction of authentication-related AVPs 6.4.0 Mar 2005 CN#27 NP-050037 079 - TEL-URI reference update 6.4.0 Mar 2005 CN#27 NP-050030 082 1 Introduction of Failed-AVP 6.4.0 Jun 2005 CT#28 CP-050086 087 - Correction of reference 6.5.0 Jun 2005 CT#28 CP-050086 089 1 Editorial corrections 6.5.0 Jun 2005 CT#28 CP-050086 088 2 Corrections to message parameters 6.5.0 Sep 2005 CT#29 CP-050440 091 2 Private identities on the Cx 6.6.0 Sep 2005 CT#29 CP-050282 093 1 Charging-Information correction 6.6.0 Sep 2005 CT#29 CP-050296 094 - Error code cleanup 6.6.0 Dec 2005 CT#30 CP-050611 095 1 Removal of overhead in Private Identities handling in RTR 6.7.0 Dec 2005 CT#30 CP-050611 098 1 Incorrect Definition of Supported-Applications AVP 6.7.0 Jan 2006 Rel-7 version was created because of ETSI TISPAN references. 7.0.0 Mar 2006 CT#31 CP-060084 0099 - Supported Features Text missing 7.1.0 Jun 2006 CT#32 CP-060302 0108 - S-CSCF reselection removal 7.2.0 Jun 2006 CT#32 CP-060308 0110 3 Definition of new Feature for Cx 7.2.0 Sep 2006 CT#33 CP-060417 0114 3 AS originating requests on behalf of a user 7.3.0 Sep 2006 CT#33 CP-060405 0118 2 Correction of discovery of supported features in Sh and Cx 7.3.0 Sep 2006 CT#33 CP-060417 0119 1 Sharing feature support information between command pairs 7.3.0 Dec 2006 CT#34 CP-060566 0124 1 Optimization of handling of Wildcarded PSIs 7.4.0 Mar 2007 CT#35 CP-070020 0125 1 M-bit in SupportedFeatures AVP 7.5.0 Sep 2007 CT#37 CP-070520 0129 - Misalignment of Mandatory Items in the MAR 7.6.0 Nov 2007 CT#38 CP-070744 0132 6 Add alias as a new feature 7.7.0 Nov 2007 CT#38 CP-070755 0130 4 Updates to 29.229 for Digest on the Cx interface 8.0.0 Mar 2008 CT#39 CP-080022 0138 2 Update 29.229 for Supporting NASS-Bundled-Authentication 8.1.0 Mar 2008 CT#39 CP-080019 0139 - SIP Digest password push 8.1.0 Mar 2008 CT#39 CP-080019 0141 2 Wildcarded Public User Identities 8.1.0 Jun 2008 CT#40 CP-080261 0145 1 Correction to the behavior of the HSS defined in the SiFC feature 8.2.0 Jun 2008 CT#40 CP-080261 0146 2 Realm and Host to be used for Charging 8.2.0 Sep 2008 CT#41 CP-080456 0149 1 Emergency Public User Identity Removal 8.3.0 Sep 2008 CT#41 CP-080460 0155 1 Support of ""Loose-Route"" indication from HSS 8.3.0 Sep 2008 CT#41 CP-080463 0156 1 Cx Impacts of IMS Restoration Procedures 8.3.0 Sep 2008 CT#41 CP-080463 0158 Add IMS Restoration as a new feature 8.3.0 Sep 2008 CT#41 CP-080463 0159 1 Addition of Registered Private Identities in SAA 8.3.0 Sep 2008 CT#41 CP-080460 0160 1 Add Assigned S-CSCF name to SAA 8.3.0 Dec 2008 CT#42 CP-080708 0163 Removal of Digest Domain 8.4.0 Dec 2008 CT#42 CP-080708 0166 2 Diameter Proxy Agent - an alternative User Identity to HSS resolution mechanism 8.4.0 Mar 2009 CT#43 CP-090026 0167 Multiple Registrations in Registration 8.5.0 Mar 2009 CT#43 CP-090026 0168 1 Restoration Information for Multiple Registrations 8.5.0 Mar 2009 CT#43 CP-090026 0169 Update for Restoration 8.5.0 Mar 2009 CT#43 CP-090051 0170 1 Definition of Server-Assignment-Type values in Cx 8.5.0 Mar 2009 CT#43 CP-090028 0171 Support for GPRS IMS Bundled Authentication (GIBA) in Cx 8.5.0 Mar 2009 CT#43 CP-090025 0172 Use of canonical form for SIP URI/tel URI in Cx interface 8.5.0 Mar 2009 CT#43 CP-090026 0175 1 Comma separated list for Path, Contact and Record-Route AVPs 8.5.0 Jun 2009 CT#44 CP-090484 0176 2 Contact storage in reg event subscription 8.6.0 Jun 2009 CT#44 CP-090303 0177 1 Comma separated list for path AVP 8.6.0 Sep CT#45 CP-090526 0181 Dx over SCTP 8.7.0 Dec 2009 CT#46 CP-090784 0182 2 SIP Digest AVP Flag Settings 8.8.0 Dec 2009 CT#46 CP-090781 0185 1 Unregistered user clarification 8.8.0 Dec 2009 CT#46 CP-090778 0188 2 Session-Priority AVP 8.8.0 Dec 2009 CT#46 CP-091030 0189 Validity of Feature Bit Value in Feature-List AVP 8.8.0 Dec 2009 CT#46 Upgraded unchanged from Rel-8 9.0.0 Mar 2010 CT#47 CP-100239 0195 1 Wildcarded Public Identity 9.1.0 Mar 2010 CT#47 CP-100031 0199 Wildcarded Public Identities handling 9.1.0 Jun 2010 CT#48 CP-100412 0205 1 Digest AVPs wrongly defined 9.2.0 Sep 2010 CT#49 CP-100447 0207 2 Wildcarded Identities handling 9.3.0 Sep 2010 CT#49 CP-100442 0209 2 Mandatory and optional capabilities handling 9.3.0 Sep 2010 CT#49 CP-100442 0212 Reference to SCTP IETFÊRFCÊobsolete 9.3.0 Sep 2010 CT#49 CP-100463 0213 2 Restoration Data Backup 9.3.0 Sep 2010 CT#49 CP-100447 0216 Encoding of Framed-IPv6-Prefix AVP 9.3.0 2011-03 - - - - Update to Rel-10 version (MCC) 10.0.0 Jun 2011 CT#52 CP-110349 0224 2 Handling of RTR for Emergency Registration 10.1.0 Jun 2011 CT#52 CP-110349 0227 Error in assignment type for backward compatibility scenarios 10.1.0 Jun 2011 CT#52 CP-110349 0230 User-Authorization-Type AVP error in description 10.1.0 Sep 2011 CT#53 CP-110566 0233 1 Priviledged sender 10.2.0 Dec 2011 CT#54 CP-110781 0240 1 Restoration of Wildcarded-IMPU AVP 10.3.0 Dec 2011 CT#54 CP-110812 0235 2 Server Assignment Type AVP definition 11.0.0 Sep 2012 CT#57 CP-120440 0247 1 Emergency registrations do not affect registration status 11.1.0 Dec 2012 CT#58 CP-120743 0251 2 PSI direct routing with restoration procedures 11.2.0 Mar 2013 CT#59 CP-130011 0258 1 Originating-request AVP in LIR 11.3.0 Jun 2013 CT#60 CP-130374 0260 1 Supported-Feature AVP carries list of features specific to the Application-ID 11.4.0 Jun 2013 CT#60 CP-130380 0259 - Visited Network ID coding 12.0.0 Dec 2013 CT#62 CP-130627 0263 1 Session-Priority AVP 12.1.0 Jun 2014 CT#64 CP-140243 0264 2 Diameter Overload Control Over Cx 12.2.0 Sep 2014 CT#65 CP-140515 0265 1 T-GRUU restoration 12.3.0 Sep 2014 CT#65 CP-140506 0266 2 P-CSCF Restoration indication 12.3.0 Dec 2014 CT#66 CP-140794 0268 2 P-CSCF Restoration mechanism new feature 12.4.0 Dec 2014 CT#66 CP-140794 0270 1 P-CSCF Restoration mechanism new error 12.4.0 Dec 2014 CT#66 CP-140773 0269 - M-bit clarification 12.4.0 Mar 2015 CT#67 CP-150023 0273 1 SIP-Authentication-Scheme AVP encoding 12.5.0 Jun 2015 CT#68 CP-150261 0274 - SAR-Flags inclusion in SAR command 12.6.0 Sep 2015 CT#69 CP-150428 0276 1 SIP-Auth-Data-Item sub AVPs clarifications 12.7.0 Sep 2015 CT#69 CP-150436 0275 1 Server-Assignment-Type AVP update to consider P-CSCF Restoration 12.7.0 Dec 2015 CT#70 CP-150754 0279 2 Allowed WAF and/or WWSF Identities 12.8.0 Dec 2015 CT#70 CP-150759 0281 1 Update reference to DOIC new IETF RFC 12.8.0 Dec 2015 CT#70 CP-150768 0282 2 Support of the DRMP AVP over Cx/Dx 13.0.0 2016-12 CT#74 CP-160664 0284 1 Correction to change IETF drmp draft version to official RFC 7944 13.1.0 2016-12 CT#74 CP-160681 0283 1 Load Control 14.0.0 2017-03 CT#75 CP-170048 0285 1 Update of reference for the Diameter base protocol 14.1.0 2017-03 CT#75 CP-170048 0286 - Cardinality of the Failed-AVP AVP in answer 14.1.0 2017-06 CT#76 CP-171018 0288 1 Support for signaling transport level packet marking 14.2.0 2018-06 CT#80 - - - Update to Rel-15 version (MCC) 15.0.0 2019-03 CT#83 CP-190035 0289 1 Reference Location Information change 15.1.0 2019-09 CT#85 CP-192094 0293 2 draft-ietf-dime-load published as RFC 8583 15.2.0 2019-09 CT#85 CP-192125 0291 - Add P-CSCF subscription info to Restoration information 16.0.0 2019-12 CT#86 CP-193040 0294 - S-CSCF restoration after registration timer expiry 16.1.0 2020-06 CT#88e CP-201053 0295 - Support of PCRF-based P-CSCF restoration 16.2.0 2021-12 CT#94e CP-213104 0297 - B Update of SIP Digest Access Authentication 17.0.0 2022-03 CT#95e CP-220052 0300 - F Reference identity for RFC 7616 17.1.0 2022-03 CT#95e CP-220052 0301 2 B Support of the hash value for alternate SIP Digest algorithm 17.1.0 2022-03 CT#95e CP-220054 0298 - B Failed P-CSCF 17.1.0 2022-06 CT#96 CP-221041 0303 - F IMS authentication using AKAv2-SHA-256 digest AKA algorithm 17.2.0 3GPP TS 29.229 V17.2.0 (2022-06) 14 Release 17 3GPP ................. 7...................... 7.......................... 8.......... 9 eoTCAP Format 7 Reference Manual MC versions: 8.0.1 Last update: 2021-06-25 Document revision: 8.0 Revision History Revision Last update Description 1.0 2019-02-06 This Format Reference Manual released for eoTCAP format 7.0. 2.0 2019-04-03 Updated filling Rule of the following fields: - Data Record Type (#111, #113), section 5.2.1.4 Common - Data Record Type - MAP Ð Number of MO SMS, section 5.2.8.2 - MAP Ð MO SMS Success, section 5.2.8.3 - MAP Ð Number of MT SMS, section 5.2.8.4 - MAP Ð MT SMS Success, section 5.2.8.5 Updated filling rule of the fields #111 and #113 in Data Record Type, section 5.2.1.4 Common - Data Record Type 3.0 2019-08-07 Removed filling rules for field description. Updated sections: á5 DR File Structure á5.2.5 CAP Fields áAdded Operator Country Code in section 6.3OperatorE212 6.1 CellAdded section 4 DR File Exchange protocol 4.0 2019-10-25 Description improved for the Common - Success field. 5.0 2020-01-08 Updated sections 3.1.1.8 Common - First Leg Destination Point Code, 3.1.1.17 Common Ð Last Leg Originating Point Code and 3.1.1.18 Common - Last Leg Destination Point Code. ÒMCLS TableÓ column added at Chapter 3 DR Format. 6.0 2020-10-22 Added the following generations to sect. 2.2 List of Generations: - eoTCAP-CAP-DeDup - eoTCAP-INAP-DeDup Updated table in sect. 4.1 Cell Updated sect. 3.2.7.1 Common Ð Success 7.0 2020-11-18 Updated MCLS Cell table in section 4.1 Cell. 8.0 2021-06-25 Updated sections: á 3.2.7.6 Common - Length of SCCP FWD Messages á 3.2.7.7 Common - Length of SCCP BWD Messages á 3.2.7.10 Common - Number of SCCP BWD Messages á 3.2.8.2 MAP Ð Number of MO SMS á 3.2.8.3 MAP Ð MO SMS Success á 3.2.8.4 MAP - Number of MT SMS á 3.2.8.5 MAP Ð MT SMS Success ©2021 Anritsu. All Rights Reserved. Specifications subject to change without notice. Table of Contents ..................................................................................................... 6 1 Introduction ................................................................................................................ 6 List of compatible FIDs Differences with respect to previous eoTCAP 6.0 version References 2 eoTCAP DR Content ..................................................................................................... 8 Scenario List of Generations 2.2.1 eoTCAP-CAP ...................................................................................................................................... 9 2.2.2 eoTCAP-CAP-DeDup ........................................................................................................................ 10 2.2.3 eoTCAP-MAP................................................................................................................................... 10 2.2.4 eoTCAP-INAP .................................................................................................................................. 10 2.2.5 eoTCAP-INAP-DeDup ...................................................................................................................... 11 2.2.6 eoTCAP-AP ...................................................................................................................................... 11 2.2.7 eoTCAP-OP ...................................................................................................................................... 11 2.2.8 eoTCAP-BELL-800 ............................................................................................................................ 11 2.2.9 eoTCAP-BELL-AIN ............................................................................................................................ 11 2.2.10 eoTCAP-BELL-LIDB .......................................................................................................................... 11 2.2.11 eoTCAP-MAP-E2E-SMS ................................................................................................................... 11 DR File Structure ........................................................................................................ 13 DR Format ..................................................................................................................... 13 eoTCAP DR Fields Description ........................................................................................ 41 Common Fields ............................................................................................................................... 41 WHITE TCAP Fields .......................................................................................................................... 81 BELL TCAP Fields ........................................................................................................................... 102 MAP Fields .................................................................................................................................... 110 CAP Fields ..................................................................................................................................... 122 INAP Fields .................................................................................................................................... 139 Common Measures ...................................................................................................................... 157 MAP Measures ............................................................................................................................. 170 4 MCLS Enrichments for eoLive .................................................................................. 173 Cell .............................................................................................................................. 173 Service Key .................................................................................................................. 175 Cause .......................................................................................................................... 175 OperatorE212 .............................................................................................................. 177 Device ......................................................................................................................... 180 CertifiedDevice ............................................................................................................ 181 MobileSubscriber ........................................................................................................ 182 FixedSubscriber ........................................................................................................... 183 Operator Prefix............................................................................................................ 185 IMSIPrefix .................................................................................................................... 186 ISDNPrefix ................................................................................................................... 187 Operator Signalling Point ............................................................................................. 188 5 Monitored procedures ............................................................................................ 190 6 Appendix A. Property field definition ...................................................................... 196 Binary Formats ............................................................................................................ 196 Display Format ............................................................................................................ 196 Text Format ................................................................................................................. 197 Special Property .......................................................................................................... 198 Aggregation Roles ....................................................................................................... 199 1 Introduction This document specifies the eoTCAP TDR File Structure v.7.0 generated by eoXDR server for MasterClaw eoLive, eoSearch, and eoFinder Application. This specification is based on: - MAP_CSDR on any compatible FID. MAP protocol stack is widely used in the world except in USA. - CAP_CSDR on any compatible FID. CAMEL protocol stack is widely used in the world except in USA. - INAP_CSDR on any compatible FID. - TCAP-AP_CSDR on any compatible FID. - BELL_TCAP_OP on any compatible FID. - BELL_TCAP_800 on any compatible FID. - BELL_AIN on any compatible FID. - BELL_LIDB on any compatible FID. List of compatible FIDs CSDR Format Name FID (Value) Protocol Layer CAP_CSDR_FID_693 693 CAP/CAMEL CAP_CSDR_FID_645 645 CAP/CAMEL MAP_CSDR_FID_629 629 MAP INAP_CSDR_FID_694 694 INAP INAP_CSDR_FID_646 646 INAP TCAP-AP_CSDR_FID_630 630 TCAP-AP BELLCORE_TCAP_OP_CSDR_FID_548 548 TCAP-OP BELL_TCAP_800_CSDR_FID_563 563 BELL_TCAP_800 BELLAIN_CSDR_FID_564 564 BELL_AIN BELLCORE_LIDB_CSDR_FID_567 567 BELL_LIDB Differences with respect to previous eoTCAP 6.0 version New fields Common Ð VLR Number Normalization Added field to normalize: Common Ð VLR Number Modified Fields INAP Ð Additional Error Reason (Modified Display Format) New eoTCAP DWH Dimensions VLR NUMBER References CAP_CSDR_693 CAP_CSDR_645 MAP_CSDR_FID_629 INAP_CSDR_FID_694 INAP_CSDR_FID_646 WHITE_TCAP_AP_CSDR_630 BELLCORE_TCAP_OP_CSDR_FID_548 BELL_TCAP_800_CSDR_FID_563 BELLAIN_CSDR_FID_564 BELLCORE_LIDB_CSDR_FID_567 2 eoTCAP DR Content Scenario This section provides a high level description of the DR content in terms of: á Monitored network á Monitored procedure/call/transaction Monitored Network Data is collected from links surrounding the various service elements (SCP etc.) or interconnect links. The services supported in this application are LNP, MNP LIDB, CLASS, TCAP operations, LIDB, IS41, CAP and MAP. Each stored transaction record (TDR) contains data from the lower SCCP protocol layer, the TCAP layer, and some information from the upper service application layer. Two protocol stacks are supported: - CAP/MAP/INAP (over TCAP/SCCP). - TCAP-OP (LNP, MNP LIDB, CLASS, TCAP operations, LIDB, IS41 (over TCAP/SCCP)). - TCAP-AP Monitored procedure/call/transaction The DR provides signalling data from the TCAP protocol focusing on the following procedures: á Voice Call Send Authentication Info Send Routing Info ÔandÕ Provide Roaming Number Mobile Originating Call Mobile Terminating Call á Location Update Location Cancel Location Send Routing Info For LCS Subscriber Location Report á Data Session Update GPRS Location Send Routing Info For GPRS MS Initiated PDP Context Activation NW Initiated PDP Context Activation á Short Message services Send Routing Info For SM Mobile Originating SMS Mobile Terminating SMS E2E SMS á Supplementary Services Register SS Erase SS Activate SS Deactivate SS Interrogate SS Process Unstructured SS Request Unstructured SS Request Unstructured SS Notify á INAP Services List of Generations 2.2.1 eoTCAP-CAP This generation produces data record related to CAP transactions with a one to one relation to the incoming CAP CSDRs (no correlation rules are defined). In case of MEGACSDR option enabled, the information about first and last leg will be filled in the data record. 2.2.2 eoTCAP-CAP-DeDup This generation performs a deduplication process on incoming CAP MEGACSDRs and produces a data record for each leg of the CAP transaction. The MEGACSDR option in CAP must be active in order to produce consistent results. Note: The deduplication process is intended to split only the MEGACSDR into single legs, no need to remove duplicated legs because of the following assumption: If SIGTRAN/TDM linksets around STPs are monitored on different probes, that traffic must be redirected to single probe. 2.2.3 eoTCAP-MAP This generation perform a correlation of MAP CSDRs in order to obtain a single data record with information about the first and last leg of the MAP transaction. This generation could be run: 1. On customer operator internal links only. á If routing is SPC (Signalling Point Code) based, the correlation rule is based on OTID/ LABEL_OPC and DTID /LABEL_DPC (as second look-up). á If routing is Global Title based, then the correlation rule is based on it (see option 2 below). 2. On inter-operator/international links only. OTID, GTCALLING_NO and DTID, BACKCLG_NO (as second look-up). Second look-up is applied as additional rule at same time together with 1st rule. Example, for case 1 two CSDR A and B will be correlated if: OTID/ LABEL_OPC: A.OTID=B.OTID e A.LABEL_OPC= B.LABEL_OPC Or with second lookup DTID /LABEL_DPC: A.OTID=B.DTID e A.LABEL_OPC= B.LABEL_DPC 2.2.4 eoTCAP-INAP This generation produces data record related to INAP transactions with a one to one relation to the incoming INAP CSDRs (no correlation rules are defined). In case of MEGACSDR option enabled, the information about first and last leg will be filled in the data record. 2.2.5 eoTCAP-INAP-DeDup This generation performs a deduplication process on incoming INAP MEGACSDRs and produces a data record for each leg of the INAP transaction. The MEGACSDR option in INAP must be active in order to produce consistent results. Note: The deduplication process is intended to split only the MEGACSDR into single legs, no need to remove duplicated legs because of the following assumption: If SIGTRAN/TDM linksets around STPs are monitored on different probes, that traffic must be redirected to single probe. 2.2.6 eoTCAP-AP This generation produces data record related to TCAP_AP transactions with a one to one relation to the incoming TCAP_AP CSDRs (no correlation rules are defined). 2.2.7 eoTCAP-OP This generation produces data record related to TCAP_OP transactions with a one to one relation to the incoming TCAP_OP CSDRs (no correlation rules are defined). 2.2.8 eoTCAP-BELL-800 This generation produces data record related to BELL_TCAP_800 transactions with a one to one relation to the incoming BELL_TCAP_800 CSDRs (no correlation rules are defined). 2.2.9 eoTCAP-BELL-AIN This generation produces data record related to BELL_AIN transactions with a one to one relation to the incoming BELL_AIN CSDRs (no correlation rules are defined). 2.2.10 eoTCAP-BELL-LIDB This generation produces data record related to BELL_LIDB transactions with a one to one relation to the incoming BELL_ LIDB CSDRs (no correlation rules are defined). 2.2.11 eoTCAP-MAP-E2E-SMS This generation performs a correlation of MAP CSDRs in order to obtain a single data record for an end to end SMS scenario (SMS submit + SMS Delivery) CSDR Filters: The First Dialogue can be any MAP Dialogue with TP_MTI=1 (SMS-SUBMIT) Correlation Keys: [First Dialogue].MSISDN=[Second Dialogue].TP_OA [First Dialogue].PAYLOAD_SZ=[Second Dialogue].PAYLOAD_SZ Time Constraints: Start Time (First Dialogue) < Start time (Second Dialogue) <= 5 minutes (First Dialogue) DR File Structure A eoTCAP DR File contains a list of eoTCAP Transaction Data Records within a time interval [start time, end time). The date and time fields of eoTCAP TDRs within the file refers to the completion time of the transaction and it is always in the interval [start time, end time). eoTCAP TDRs in the file are not ordered w.r.t any of the fields. The file format stores Data Records in a proprietary binary format. DR Format # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path COMMON FIELDS 1 Start_Date_and_time Common - Start Time BF_INTEGER 8 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Measures/Common 2 End_Date_and_time Common - End Time BF_INTEGER 8 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Measures/Common 3 LAYER_TYPE Common Ð DR Generation Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 4 DATA_RECORD_TYPE Common - Data Record Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 5 VIOLATION Common Ð Violation BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 6 TIMEOUT Common Ð Timeout BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 7 LABEL_OPC Common Ð First Leg Originating Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 8 LABEL_DPC Common - First Leg Destination Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 9 SOURCE_IP Common - First Leg Source IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 10 DESTINATION_IP Common - First Leg Destination IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 11 SOURCE_SWITCH Common - First Leg Source Network Node BF_STRING 80 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 12 SOURCE_SWITCH_ROLE Common - First Leg Source Network Node Type BF_STRING 30 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 13 DEST_SWITCH Common - First Leg Destination Network Node BF_STRING 80 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 14 DEST_SWITCH_ROLE Common - First Leg Destination Network Node Type BF_STRING 30 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 15 SOURCE_SP Common - First Leg Source Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 16 DEST_SP Common - First Leg Destination Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 17 LL_LABEL_OPC Common Ð Last Leg Originating Point Code BF_INTEGER 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 18 LL_LABEL_DPC Common - Last Leg Destination Point Code BF_INTEGER 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 19 LL_SOURCE_IP Common Ð Last Leg Source IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 20 LL_DESTINATION_IP Common Ð Last Leg Destination IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 21 LL_SOURCE_SWITCH Common - Last Leg Source Network Node BF_STRING 80 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 22 LL_SOURCE_SWITCH_ROLE Common Ð Last Leg Source Network Node Type BF_STRING 30 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 23 LL_DEST_SWITCH Common Ð Last Leg Destination Network Node BF_STRING 80 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 24 LL_DEST_SWITCH_ROLE Common Ð Last Leg Destination Network Node Type BF_STRING 30 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 25 LL_SOURCE_SP Common Ð Last Leg Source Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 26 LL_DEST_SP Common - Last Leg Destination Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 27 CALLING_NO Common - Calling Party Number BF_STRING 22 DF_DIGITS FixedSubscriber, OperatorPrefix, ISDNPrefix FixedSubscriber, OperatorPrefix, ISDNPrefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 28 CALLED_NO Common - Called Party Number BF_STRING 22 DF_DIGITS FixedSubscriber, OperatorPrefix, ISDNPrefix FixedSubscriber, OperatorPrefix, ISDNPrefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 29 PAYMENT_PLAN Common - Payment Plan BF_INTEGER 1 DF_DEC_ENUM MobileSubscriber Payment Plan AR_AGGREGABLE_ALWAYS Objects/Common 30 LINKSET_NAME Common Ð First Leg Forward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 31 LINKSET_NAME_BACKWARD Common - First Leg Backward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 32 LL_LINKSET_NAME Common - Last Leg Forward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 33 LL_LINKSET_NAME_BACKWARD Common - Last Leg Backward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 34 OTID Common Ð OTID BF_INTEGER 4 DF_HEX AR_AGGREGABLE_NEVER Objects/Common 35 DTID Common Ð DTID BF_INTEGER 4 DF_HEX AR_AGGREGABLE_NEVER Objects/Common 36 BACKCLG_NO Common - SCCP Back Calling Number BF_STRING 22 DF_DIGITS AR_AGGREGABLE_WITHFILTER Objects/Common 37 SCCP_CALLED_PARTY Common - SCCP Called Party Global Title BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/Common 38 SCCP_CALLING_PARTY Common - SCCP Calling Party Global Title BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 39 CALLED_SSN Common - Called SSN BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 40 CALLING_SSN Common - Calling SSN BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 41 SCCP_RETCAUSE Common - SCCP Return Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/Common 42 TCAP_ABORT_CAUSE Common - TCAP Abort Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/Common 43 SIO Common - Service Information Octet BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 44 SERVICE_KEY Common - Service Key BF_STRING 4 BF_STRING ServiceKey ServiceKey AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 45 CONV_TIME_INT Common Ð Conversation Time Interval BF_STRING 64 DF_STRING Conversation Time Interval Conversation Time Interval AR_AGGREGABLE_ALWAYS Objects/Common 46 IMSI Common Ð IMSI BF_STRING 16 DF_DIGITS MobileSubscriber, OperatorE212, IMSIPrefix Mobile Subscriber, Operator E212, IMSI Prefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 47 MSISDN Common Ð MSISDN BF_STRING 22 DF_DIGITS OperatorPrefix,FixedSubscriber OperatorPrefix,FixedSubscriber SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 48 IMEI Common Ð IMEI BF_STRING 16 DF_DIGITS CertifiedDevice Certified Device SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 49 TAC Common - Device TAC BF_STRING 8 DF_DIGITS Device Device SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 50 LOCATION_INFO Common - Location Information BF_STRING 20 DF_DIGITS OperatorPrefix Location Info, OperatorPrefix AR_AGGREGABLE_ALWAYS Objects/Common 51 PLMN_ID Common Ð PLMN ID BF_STRING 6 DF_STRING Operator E212 AR_AGGREGABLE_WITHRANK Objects/Common 52 SCCP_CALLING_OPC Common Ð SCCP Calling Party Number Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 53 SCCP_CALLING_SP Common Ð SCCP Calling Party Number Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 54 SCCP_CALLED_OPC Common Ð SCCP Terminating Party Number Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 55 SCCP_CALLED_SP Common Ð SCCP Called Party Number Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 56 VLR_NUMBER Common Ð VLR Number BF_STRING 22 DF_DIGITS VLR Number AR_AGGREGABLE_ALWAYS Object/Common WHITE TCAP FIELDS 101 TCAPAP_APPL_OP_CODE WHITE TCAP - Application Operation Code BF_INTEGER 2 DF_HEX_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/WHITE TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 102 TCAPAP_APPL_ERROR_CODE WHITE TCAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/WHITE TCAP BELL TCAP FIELDS 150 BTCAP_OPERATION_CODE BELL TCAP - Application Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 151 BTCAP_LAST_OPERATION_CODE BELL TCAP - Last Application Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 152 BTCAP_APPL_ERROR_CODE BELL TCAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 153 BTCAP_REJECT_PROBLEM BELL TCAP Ð Reject Problem BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 154 BTCAP_TRANSLATION_TYPE BELL TCAP Ð Translation Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 155 BTCAP_GTT_REQUESTED BELL TCAP - GTT Requested BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 156 BTCAP_TCAP_800_TERMINATION_INDICATOR BELL TCAP Ð TCAP 800 Termination Indicator BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 157 BTCAP_AINT_ERROR_CAUSE BELL TCAP Ð AIN Error Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 158 BTCAP_TCAP_OP_LINE_SERVICE_TYPE BELL TCAP Ð TCAP OP Line Service Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 159 BTCAP_LIDB_SERVICE_OR_EQUIP_INDICATOR BELL TCAP Ð LIDB Service or Equipment Indicator BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP MAP FIELDS 201 MAP_FL_OP_CODE MAP Ð First Leg Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 202 MAP_FL_ER_CODE MAP - First Leg Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 203 MAP_FL_USRERR_REASON MAP Ð First Leg Additional Error Reason BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 204 MAP_FL_TP_SCTS MAP Ð First Leg SMS Service Centre Time Stamp BF_INTEGER 4 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Objects/MAP 205 MAP_LL_OP_CODE MAP Ð Last Leg Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 206 MAP_LL_ER_CODE MAP - Last Leg Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 207 MAP_LL_USRERR_REASON MAP Ð Last Leg Additional Error Reason BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 208 MAP_LL_TP_SCTS MAP Ð Last Leg SMS Service Centre Time Stamp BF_INTEGER 4 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 209 MAP_TP_MR MAP Ð SMS Message Reference Number BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Objects/MAP 210 MAP_ABSENT_SUBSCRIBER_DIAG_SM MAP - GSM Absent Reason BF_INTEGER 4 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 211 MAP_MSRN MAP ÐMSRN BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/MAP 212 MAP_USSD_STR MAP - USSD String BF_STRING 128 DF_STRING SP_USSD AR_AGGREGABLE_WITHFILTER Objects/MAP 213 MAP_SERVCENT_ADDR MAP - Service Centre Address BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/MAP 214 MAP_SGSN_ADDRESS MAP - SGSN Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 215 MAP_GGSN_ADDRESS MAP - GGSN Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 216 MAP_H_GMLC_ADDRESS MAP - Home GMLC Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 217 MAP_V_GMLC_ADDRESS MAP - Visited GMLC Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 218 MAP_TP_OA_ALPHANUM MAP - TP Origination Address Alphanumeric BF_STRING 12 DF_STRING SMS Service SP_ ENDPOINTDETAILS AR_AGGREGABLE_WITHRANK Objects/MAP 219 MAP_TP_DA_ALPHANUM MAP - TP Destination Address Alphanumeric BF_STRING 12 DF_STRING SP_ ENDPOINTDETAILS AR_AGGREGABLE_WITHRANK Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 220 MAP_TP_MTI MAP Ð TP Message Type Indicator BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 221 MAP_SMS_DELIV_TIME_INT MAP Ð SMS Delivery Time Interval BF_STRING 64 DF_STRING SMSDeliveryTime Interval SMSDeliveryTime Interval AR_AGGREGABLE_ALWAYS Objects/MAP CAP FIELDS 301 CAP_OP_CODE CAP Ð Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 302 CAP_LAST_OPERATION CAP - Last Operation BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 303 CAP_OPERATION_MASK CAP - Operation Mask BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/CAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 304 CAP_ER_CODE CAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 305 CAP_ER_REASON CAP - Additional Error Reason BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 306 CAP_CAUSE CAP - Response Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 307 CAP_DEST_ADDRESS CAP - Destination Routing Address BF_STRING 22 DF_DIGITS Destination Address AR_AGGREGABLE_WITHFILTER Objects/CAP 308 CAP_EVENT_REPORT_CAUSE CAP - Event Report Cause BF_INTEGER 1 DF_ENUM Cause cause AR_AGGREGABLE_ALWAYS Objects/CAP 309 CAP_EVENT_TYPE_MET CAP - Event Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 310 CAP_REPORTED_EVENT CAP - Reported Event BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 311 CAP_CELL_IDENTITY CAP Ð Cell Identity BF_STRING 30 DF_STRING Cell Cell AR_AGGREGABLE_WITHRANK Objects/CAP INAP FIELDS 401 INAP_OP_CODE INAP Ð Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 402 INAP_LAST_OPERATION INAP - Last Operation BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 403 INAP_OPERATION_MASK1 INAP - Operation Mask1 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 404 INAP_OPERATION_MASK2 INAP - Operation Mask2 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 405 INAP_OPERATION_MASK3 INAP - Operation Mask3 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 406 INAP_OPERATION_MASK4 INAP - Operation Mask4 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 407 INAP_ER_CODE INAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP 408 INAP_ER_REASON INAP - Additional Error Reason BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP 409 INAP_CAUSE INAP - Response Cause BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 410 INAP_DEST_ROUT_ADDRESS INAP - Destination Routing Address BF_STRING 22 DF_DIGITS Destination Address AR_AGGREGABLE_WITHFILTER Objects/INAP 411 INAP_EVENT_TYPE_MET INAP - Event Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 412 INAP_REPORTED_EVENT INAP - Reported Event BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 413 INAP_GENERIC_NUMBER INAP - Generic Number BF_STRING 22 DF_DIGITS ISDNPrefix ISDNPrefix AR_AGGREGABLE_WITHFILTER Objects/INAP COMMON MEASURES 501 SUCCESS Common - Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 502 TRANS_TIME Common - Transaction Duration BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 503 RESPONSE_TIME Common - Response Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 504 CONV_TIME Common Ð Conversation Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 505 SCCP_MSGLEN Common - Total Length of SCCP Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 506 TX_SCCP_MSGLEN Common - Total Length of SCCP FWD Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 507 RX_SCCP_MSGLEN Common - Total Length of SCCP BWD Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 508 NUMOF_SCCPMSG Common - Number of SCCP Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 509 NUMOF_TXSCCP_MSGS Common - Number of SCCP FWD Messages BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 510 NUMOF_RXSCCP_MSGS Common - Number of SCCP BWD Messages BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 511 ANSWERED_CALL Common Ð Answered Call BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 512 DROPPED_CALL Common Ð Dropped Call BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common MAP MEASURES 601 MAP_PAYLOAD_SZ MAP - SMS Payload Size BF_INTEGER 2 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 602 MAP_NUMBER_OF_MO_SMS_MESSAGES MAP Ð Number of MO SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 603 MAP_MO_SMS_SUCC MAP Ð MO SMS Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / MAP 604 MAP_NUMBER_OF_MT_SMS_MESSAGES MAP - Number of MT SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 605 MAP_MT_SMS_SUCC MAP Ð MT SMS Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / MAP 606 MAP_NO_CONCA_SMS MAP - Number of Concatenated SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 607 MAP_SMS_SUBMIT_TIME MAP Ð SMS Submit Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / MAP 608 MAP_SMS_DELIV_TIME MAP Ð SMS Delivery Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / MAP SPECIAL FIELDS 705 Call Trace Jump N/A BF_STRING 184 N/A N/A N/A N/A TABLE 1 ATTRIBUTES OF EOTCAP TDR eoTCAP DR Fields Description Common Fields Common - Start Time Applicable Protocols: All This is the time stamp for start of the transaction. The time stamp is UTC time milli seconds since 1 Jan 1970 0:00. This field is computed using the StartTimeStmpSec and StartmsPart CSDR fields. Common - End Time Applicable Protocols: All This is the time stamp for completion of the transaction. The time stamp is UTC time milli seconds since 1 Jan 1970 0:00."
"Common Ð DR Generation Type Applicable Protocols: All This field is an enumerated one used to distinguish the signalling interface of the data record. It can assume the following values depending on the CSDR source: Value Exported Description 1. TCAP-AP 2. MAP 3. CAP 4. INAP 5. TCAP-OP 6. TCAP-800 Value Exported Description 7. AIN 8. LIDB 9. CAP Single Leg 10. INAP Single Leg Common - Data Record Type Applicable Protocols: All It indicates the type of procedure/activity done (or being done) by the user. CSDR Type = CAP Value Name Description 1 CAP Mobile Originating Call Mobile Originating Call 2 CAP Mobile Terminating Call Mobile Terminating Call 3 CAP Mobile Originating SMS Mobile Originating SMS 4 CAP Mobile Terminating SMS Mobile Terminating SMS 5 CAP MS Initiated PDP Context Activation MS Initiated PDP Context Activation 6 CAP NW Initiated PDP Context Activation NW Initiated PDP Context Activation 99 Other CAP procedure CSDR Type = MAP Value Name Description 100 MAP Update Location Location Update procedure is initiated by the VLR towards the HLR in order to update the subscriber location information related to the CS domain. 101 MAP Cancel Location Cancel Location procedure is initiated when the subscriber moves into another VLR area or into another PLMN. 102 MAP Provide Roaming Number MSC initiates this procedure when a mobile terminating call has to be routed towards a roamer subscriber visiting the network. 103 MAP Register SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to register data related to a supplementary service. The VLR will relay the message to the HLR. 104 MAP Erase SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a supplementary procedure. The VLR will relay the message to the HLR. 105 MAP Activate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to activate a supplementary procedure. The VLR will relay the message to the HLR. 106 MAP Deactivate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to deactivate a supplementary procedure. The VLR will relay the message to the HLR. 107 MAP Interrogate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to retrieve information related to a supplementary procedure. The VLR Value Name Description will relay the message to the HLR if necessary. 108 MAP Send Routing Info Send Routing Info procedure is initiated by the MSC/VLR towards the HLR to retrieve subscriber information related to the CS domain. 109 MAP Update GPRS Location Update GPRS Location procedure is initiated by the SGSN/VLR towards the HLR in order to update the subscriber location information related to the PS domain. 110 MAP Send Routing Info For GPRS Send Routing Info For GPRS procedure is initiated by the GGSN towards the HLR to retrieve subscriber information related to the PS domain. 111 MAP Mobile Terminating SMS Mobile Terminating SMS 112 MAP Send Routing Info For SM Send Routing Info For SM procedure is initiated by the Gateway MSC towards the HLR to retrieve information needed for routing the short message to the servicing MSC. 113 MAP Mobile Originating SMS Mobile Originating SMS 114 MAP Authentication VLR may initiate the Authentication procedure (Send Authentication Info). It is used to ensure security and deny services to unauthorized services. This procedure can be done periodically. 115 MAP Process Unstructured SS Request This procedure is used between the MSC and the VLR, between the VLR and the HLR, between the HLR and gsmSCF and between the HLR and HLR to relay information in order to allow unstructured supplementary service operation. Value Name Description 116 MAP Unstructured SS Request This procedure is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires information from the mobile user, in connection with unstructured supplementary service handling. 117 MAP Unstructured SS Notify This procedure is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires a notification to be sent to the mobile user, in connection with unstructured supplementary services handling. 118 MAP Send Routing Info For LCS Send Routing Info For LCS procedure is initiated by the GMLC towards the HLR to retrieve subscriber information related to the Location based Services. 119 MAP Subscriber Location Report Subscriber Location Report procedure is initiated by the SGSN/VLR towards the HLR to provide the GMLC the location of a subscriber. 120 MAP Ð Correlated SMS 199 Other MAP procedure CSDR Type = INAP Value Name Description 200 INAP Initial DP 201 INAP Retrieve/Assist Request Instructions 299 Other INAP procedure CSDR Type = TCAP-AP Value Name Description 300 TCAP-AP traffic CSDR Type =BELL TCAP-OP Value Name Description 400 TCAP OP Query (CNAM Service) CSDR Type = BELL TCAP-800 Value Name Description 500 TCAP 800 Query (Toll Free Call) CSDR Type = BELL TCAP-800 Value Name Description 600 AIN Query CSDR Type = BELL LIDB Value Name Description 700 LIDB Query Common Ð Violation Applicable Protocols: All It indicates if the sequence contains all messages or some error condition happened. Value Name 0 No Violation 1 Missing End or Response Message 2 Only Begin or Query Message 3 Only Continue or Conversation Message Common Ð Timeout Applicable Protocols: All Timeout identifies the type of timeout that occurred during processing of the signalling data. Note that timeout field does not refer to network timeouts but refer only to the timeouts used by the network monitoring system. Value Timeout Description CAP CSDR MAP CSDR INAP CSDR WHITE_TCAP_AP CSDR TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 0 No Timeout 0 0 0 0 0 0 0 0 1 Sequence Timeout 1 1 1 1 1 1 1 1 2 Short Call (Not used in CSR mode) 2 2 2 3 Long Call (Not used in CSR mode) 3 3 3 Value Timeout Description CAP CSDR MAP CSDR INAP CSDR WHITE_TCAP_AP CSDR TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 4 Out of Error State 4 4 4 5 User Timeout 5 5 5 6 More-To-Come Timeout 6 - 6 7 Short Timeout 7 6 - 8 SMS Short Timeout 8 - - 9 Medium Timeout 9 7 - 10 Long Timeout 10 9 11 Wait for End Abort Timeout 11 - - 16 Medium-Long Timeout - 8 - 17 Pre-arranged END Timeout - - 7 Common Ð First Leg Originating Point Code Applicable Protocols: All Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR LABEL_OPC Originating Point Code of transaction MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_AIN_CSDR BELL_LIDB_CSDR Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: LABEL_OPC LABEL_OPC_LEG_2 LABEL_OPC_LEG_3 LABEL_OPC_LEG_4 LABEL_OPC_LEG_5 LABEL_OPC_LEG_6 LABEL_OPC_LEG_7 LABEL_OPC_LEG_8 LABEL_OPC_LEG_9 LABEL_OPC_LEG_10 Common - First Leg Destination Point Code Applicable Protocols: All Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR LABEL_DPC Destination Point Code of transaction MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_AIN_CSDR BELL_LIDB_CSDR Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: LABEL_DPC LABEL_DPC_LEG_2 LABEL_DPC_LEG_3 LABEL_DPC_LEG_4 LABEL_DPC_LEG_5 LABEL_DPC_LEG_6 LABEL_DPC_LEG_7 LABEL_DPC_LEG_8 LABEL_DPC_LEG_9 LABEL_DPC_LEG_10 Common - First Leg Source IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Source IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format. MAP_CSDR SOURCE_IP CAP_CSDR SOURCE_IP INAP_CSDR SOURCE_IP TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_AIN_CSDR - BELL_LIDB_CSDR - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: SOURCE_IP SOURCE_IP_LEG_2 SOURCE_IP_LEG_3 SOURCE_IP_LEG_4 SOURCE_IP_LEG_5 SOURCE_IP_LEG_6 SOURCE_IP_LEG_7 SOURCE_IP_LEG_8 SOURCE_IP_LEG_9 SOURCE_IP_LEG_10 Common - First Leg Destination IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Destination IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format. MAP_CSDR DESTINATION_IP CAP_CSDR DESTINATION_IP INAP_CSDR DESTINATION_IP TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from younger BEGIN (or QUERY) Else itÕs filled from younger CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: DESTINATION_IP DESTINATION_IP_LEG_2 DESTINATION_IP_LEG_3 DESTINATION_IP_LEG_4 DESTINATION_IP_LEG_5 DESTINATION_IP_LEG_6 DESTINATION_IP_LEG_7 DESTINATION_IP_LEG_8 DESTINATION_IP_LEG_9 DESTINATION_IP_LEG_10 Common - First Leg Source Network Node Applicable Protocols: All This field identifies the name of the First Leg Source Network Node by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Network node name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Source Network Node Type Applicable Protocols: All This field identifies the Role of the First Leg Source Network Node by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Network node type is calculated using the same filling rule of the other generations exploiting the following CAP/INAP CSDR fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Network Node Applicable Protocols: All This field identifies the Role of the First Leg Destination Network Node by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. CAP/INAP De-duplicated Generations: First Leg Destination Network node name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Network Node Type Applicable Protocols: All This field identifies the Role of the First Leg Destination Network Node by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Destination IP Address. CAP/INAP De-duplicated Generations: First Leg Destination Network node type is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Source Signalling Point Applicable Protocols: All This field identifies the name of the First Leg Source Signalling Point by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Signalling Point name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Signalling Point Applicable Protocols: All This field identifies the name of the First Leg Destination Signalling Point by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only destination IP Address. CAP/INAP De-duplicated Generations: First Leg Destination Signalling Point name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common Ð Last Leg Originating Point Code Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP Generations CAP, MAP, INAP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Originating Point Code of the last leg of the transaction MAP_CSDR LABEL_OPC CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR LAST_OPC BELL_TCAP_800_CSDR LAST_OPC BELL_LIDB_CSDR LAST_OPC BELL_AIN LAST_OPC Filling criteria: in case of full load sharing it is filled from If BEGIN (or QUERY) present, then it is filled from younger BEGIN (or QUERY) Else it is filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found LABEL_OPC_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Destination Point Code Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Destination Point Code of the last leg of the transaction MAP_CSDR LABEL_DPC CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR LAST_DPC BELL_TCAP_800_CSDR LAST_DPC BELL_LIDB_CSDR LAST_DPC BELL_AIN LAST_DPC Filling criteria: in case of full load sharing it is filled from If BEGIN (or QUERY) present, then it is filled from younger BEGIN (or QUERY) Else it is filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found LABEL_DPC_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Source IP Address Applicable Protocols: MAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Source IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format in the last leg of transaction MAP_CSDR SOURCE_IP CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from: If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found SOURCE_IP_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Destination IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Destination IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format in the last leg of transaction MAP_CSDR DESTINATION_IP CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from younger BEGIN (or QUERY) Else itÕs filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found DESTINATION_IP_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Source Network Node Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Source Network Node by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN The last leg IP Address + VLAN lookup is available only for MAP, CAP and INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP and INAP CSDRs. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Source IP Address. Common - Last Leg Source Network Node Type Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the role of the Last Leg Source Network Node by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDRs. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Source IP Address. Common - Last Leg Destination Network Node Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Destination Network Node by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Destination IP Address. Common - Last Leg Destination Network Node Type Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the role of the Last Leg Destination Network Node by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Common - Last Leg Source Signalling Point Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Source Signalling Point by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last leg Source IP Address. Common Ð Last Leg Destination Signalling Point Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Destination Signalling Point by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last leg Source IP Address. Common - Calling Party Number Applicable Protocols: MAP, CAP, INAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN CSDR Type CSDR field Description TCAP-AP_CSDR - Indicates Calling party number (TCAP-OP, TCAP-800, LIDB, AIN, CAP, INAP CSDRs) or the address of the originating Short Message Entity (MAP CSDR) MAP_CSDR TP_OA CAP_CSDR CALLING_NO INAP_CSDR INAP_CALLING_PARTY_NO TCAP-OP_CSDR CALLING_PARTY or CALLING_DN BELL_TCAP_800_CSDR CALLING_PARTY BELL_LIDB_CSDR LIDB_ANI_CALLING_NUMBER or LIDB_CALLING_DIRECTORY_NUMBER BELL_AIN CALLING_NO Common - Called Party Number Applicable Protocols: MAP, CAP, INAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Generations CAP, MAP, INAP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Indicates Called party number (TCAP-OP, TCAP-800, LIDB, AIN, CAP, INAP CSDRs) or the address of the destinating Short Message Entity (MAP CSDR) MAP_CSDR TP_DA CAP_CSDR CALLED_NO INAP_CSDR INAP_CALLED_PARTY_NO TCAP-OP_CSDR CALLED_PARTY BELL_TCAP_800_CSDR CALLED_PARTY BELL_LIDB_CSDR LIDB_DIALLED_NUMBER BELL_AIN CALLED_NO CAP De-duplicated Generation: It exploits the following CAP fields: CALLED_NO CALLED_NO_LEG_2 CALLED_NO_LEG_3 CALLED_NO_LEG_4 CALLED_NO_LEG_5 CALLED_NO_LEG_6 CALLED_NO_LEG_7 CALLED_NO_LEG_8 CALLED_NO_LEG_9 CALLED_NO_LEG_10 INAP De-duplicated Generation: It exploits the following INAP fields: INAP_CALLED_PARTY_NO INAP_CALLED_PARTY_NO_LEG_2 INAP_CALLED_PARTY_NO_LEG_3 INAP_CALLED_PARTY_NO_LEG_4 INAP_CALLED_PARTY_NO_LEG_5 INAP_CALLED_PARTY_NO_LEG_6 INAP_CALLED_PARTY_NO_LEG_7 INAP_CALLED_PARTY_NO_LEG_8 INAP_CALLED_PARTY_NO_LEG_9 INAP_CALLED_PARTY_NO_LEG_10 Common - Payment Plan Applicable protocol: TCAP, MAP, CAP, INAP It is based on lookup of IMSI on MCLS Mobile Subscriber table (ÒPlanÓ column). This feature is optional. MCLS Table: Mobile Subscriber The lookup will be made on the IMSI CSDR field. Enumeration Value: 0 Pre-paid subscriber 1 Post-paid subscriber Common Ð First Leg Forward Linkset Name Applicable protocol: All The Linkset Name is retrieved from the MasterClaw Configuration database CDB. This is the Linkset Name concerning the BEGIN or QUERY PDU or any message initiating the transaction. Common Ð First Leg Backward Linkset Name Applicable protocol: All The Linkset Name is retrieved from the MasterClaw Configuration database CDB. This is the Linkset Name concerning the first message sent in response to the first message initiating the transaction. Common Ð Last Leg Forward Linkset Name Applicable protocol: All CSDR Type CSDR field Description TCAP-AP_CSDR - This is the Linkset Name of the first forward message in last leg of the sequence. MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR LAST_LINKSET_TXID BELL_TCAP_800_CSDR LAST_LINKSET_TXID CSDR Type CSDR field Description BELL_LIDB_CSDR LAST_LINKSET_TXID BELL_AIN LAST_LINKSET_TXID Common Ð Last Leg Backward Linkset Name Applicable protocol: All CSDR Type CSDR field Description TCAP-AP_CSDR - This is the Linkset Name of the first backward message in last leg of the sequence. MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR LAST_LINKSET_RXID BELL_TCAP_800_CSDR LAST_LINKSET_RXID BELL_LIDB_CSDR LAST_LINKSET_RXID BELL_AIN LAST_LINKSET_RXID Common - OTID Applicable protocol: All 32-Bit long Originating Transaction ID of TCAP. Filled from: Filled with the OTID of BEGIN message or from DTID of END/CONTINUE message whichever comes first in the sequence. CSDR Type CSDR field Description TCAP-AP_CSDR OTID Originating Transaction ID of TCAP MAP_CSDR CAP_CSDR CSDR Type CSDR field Description INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common Ð DTID Applicable protocol: All 32-bit long Destination Transaction ID of TCAP Filled from: Filled with the OTID of CONTINUE message if present in the sequence CSDR Type CSDR field Description TCAP-AP_CSDR DTID Destination Transaction ID of TCAP MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common Ð SCCP Back Calling Number Applicable protocol: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN The 'address information part' of the 'calling party global titleÕ, which is carried in the TCAP CONTINUE/END operation. Also from BEGIN operation if only UDT/XUDT (BEGIN) and UDTS/XUDTS (BEGIN) forms a sequence. Q713 (section 3.4), E164, E214 Generations CAP, MAP, INAP, TCAP-AP, MAP-E2E-SMS CSDR Type CSDR field TCAP-AP_CSDR BACKCLG_NO MAP_CSDR CAP_CSDR See below INAP_CSDR TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - CAP/INAP CSDR Check in this order the following CAP/INAP fields: 1- BACKCLG_NO 2- BACKCLG_NO_LEG_N (for N=2 to N=10, N++) Common Ð SCCP Back Calling Number = the first found CAP/INAP field not NULL If no field is found Common Ð SCCP Back Calling Number = NULL CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: BACKCLG_NO BACKCLG_NO_LEG_2 BACKCLG_NO_LEG_3 BACKCLG_NO_LEG_4 BACKCLG_NO_LEG_5 BACKCLG_NO_LEG_6 BACKCLG_NO_LEG_7 BACKCLG_NO_LEG_8 BACKCLG_NO_LEG_9 BACKCLG_NO_LEG_10 Common - Called Party Global Title Applicable protocol: All The 'address information part' of the 'called party global titleÕ, which is carried in the TCAP BEGIN/CONTINUE/END operation. Q713 (section 3.4), E164, E214 Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field TCAP-AP_CSDR GTCALLED_NO MAP_CSDR GTCALLED_NO CAP_CSDR SCCP_CALLED_PARTY INAP_CSDR SCCP_CALLED_PARTY TCAP-OP_CSDR SCCP_CALLED_PARTY BELL_TCAP_800_CSDR SCCP_CALLED_PARTY BELL_LIDB_CSDR SCCP_CALLED_PARTY BELL_AIN SCCP_CALLED_PARTY CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: SCCP_CALLED_PARTY SCCP_CALLED_PARTY_LEG_2 SCCP_CALLED_PARTY_LEG_3 SCCP_CALLED_PARTY_LEG_4 SCCP_CALLED_PARTY_LEG_5 SCCP_CALLED_PARTY_LEG_6 SCCP_CALLED_PARTY_LEG_7 SCCP_CALLED_PARTY_LEG_8 SCCP_CALLED_PARTY_LEG_9 SCCP_CALLED_PARTY_LEG_10 Common - Calling Party Global Title Applicable protocol: All The 'address information part' of the 'called party global titleÕ, which is carried in the TCAP BEGIN/CONTINUE/END operation. Q713 (section 3.4), E164, E214 Common - Called SSN Applicable protocol: All It represents the Called Sub System Number, Part of SCCP called party sub system. Q.713 (section 3.4.2.2) CSDR Type CSDR field TCAP-AP_CSDR CALLED_SSN MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Value Definition 0 SSN not known not used Value Definition 1 SCCP Management 3 ISDN User Part 4 OMAP 5 MAP 6 HLR 7 VLR 8 MSC 9 EIR 10 AUC 11 ISDN Supplementary Services 12 INAP 13 broadband ISDN Edge To Edge 14 TC Test Responder 15 SINAP 142 RANAP 143 RNSAP 145 GMLC 146 CAP 147 GSMSCF 148 SIWF 149 SGSN 150 GGSN 192 BSSAP 241 INAPCS2 Value Definition 248 MTXMUP 249 HLRMUP 252 BSAP 254 BSSAP Table for MAP/CAP Common - Calling SSN Applicable protocol: All It represents the Calling Sub System Number, part of SCCP called party sub system. Q.713 (section 3.4.2.2) CSDR Type CSDR field TCAP-AP_CSDR CALLING_SSN MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN See Called SSN for value list. Common - SCCP Return Cause Applicable protocol: All This field contains the result of procedure at SCCP layer. Common - TCAP Abort Cause Applicable protocol: All This field contains the result of procedure at TCAP layer. Common - Service Information Octet Applicable protocol: All The service information octet of message contains the service indicator and sub service field (which contains network indicator and spare bits). It is used to distinguish the network service carried in SCCP layer. Value SIO (Enumeration) 0 SNM 1 SNT 3 international SCCP 4 TUP 5 international ISUP 6 DUP 7 DUP1 8 MTUP 9 BISUP 10 SISUP 128 national SNM 129 national SNT 131 national SCCP 132 national TUP 133 national ISUP 192 nSNM* 193 nSNT* 195 nSCCP* 196 nTUP* Value SIO (Enumeration) 197 nISUP 255 undefined field CSDR Type CSDR field Description TCAP-AP_CSDR SIO The service information octet of message signal units contains the service indicator and sub service field (which contains network indicator and spare bits) MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common - Service Key Applicable Protocols: CAP, INAP, MAP CAP: it represents a CAP/CAMEL service descriptor. The interpretation is operator dependent. INAP: it represents an INAP service descriptor. The interpretation is operator dependent. MAP: it defines the ServiceKey field of VLR CAMEL subscription info Common Ð Conversation Time Interval Applicable Protocols: CAP, INAP This field identifies the Conversation Time Interval by means of a lookup of the Conversation Time field on MCLS table Conversation Interval Standard Formatting: Column CTI_INTERVAL_NAME CTI_LOWER_VALUE CTI_UPPER_VALUE Default table value: Conversation Time Interval Name Conversation Time Lower Value (s) Conversation Time Upper Value (s) 0-30 s 0 30 30-60 s 30 60 60-900 s 60 900 900-1800 s 900 1800 1800-3600 s 1800 3600 >=3600 s 3600 Factor conversion: 1000 (from msec to sec) Common - IMSI Applicable protocol: TCAP-AP, MAP, CAP, INAP Common - MSISDN Applicable protocol: TCAP-AP, MAP, CAP, INAP MAP: This field is mandatory only in successful cases because it is contained in the Insert Subscriber Data from HLR that follow the GSM/GPRS Update Location only in case of success. This parameter refers to the Directory number used to call GSM subscriber. The structure of a GSM directory number consists of country code, the national destination code and the subscriber number. MSISDN number (Reference GSM 09.02 V4.6.0, 5.6.2.17) TCAP-AP: IMSI lookup via MICS. CAP: IMSI lookup via MICS. INAP IMSI lookup via MICS. TCAP-OP: N.A. BELL_TCAP_800: N.A. BELL_LIDB: N.A. BELL_AIN: N.A. Common - IMEI Applicable protocol:, MAP, CAP International Mobile Equipment identity number. CAP CSDR: itÕs filled by ÒINITIAL DPÓ, ÒINITIAL DP SMSÓ & ÒINITIAL DP GPRSÓ. MAP CSDR: itÕs filled by ÒPrepare HandoverÓ, ÒUpdate LocationÓ, ÒUpdate GPRS LocationÓ, ÒUE Identity IE from CN INVOKE TRACE message of RANAP layer over MAP Common - Device TAC Applicable protocol: MAP, CAP TAC (Type of Allocation) is composed by the first eight digits of IMEI. TAC code identifies the device manufacturer and the model. Common - Location Information Applicable protocol: TCAP-OP, MAP, INAP Common Ð PLMN ID Applicable protocol: MAP, CAP It conveys the identity of the network to which the UE is attached according to the ITU-T E.212 standard. Common Ð SCCP Calling Party Number Point Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Common Ð SCCP Calling Party Number Signalling Point Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN This field identifies the Calling Party Number signalling point name by means of a lookup of: - SCCP Calling Party Number Point Code Common Ð SCCP Called Party Number Point Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Common Ð SCCP Called Party Number Signalling Point This field identifies the Called Party Number signalling point name by means of a lookup of: - SCCP Called Party Number Point Code - Common Ð VLR Number This field identifies the ISDN Number of the VLR Applicable protocol: MAP, CAP, INAP WHITE TCAP Fields WHITE TCAP - Application Operation Code It represents the first operation invoked at TCAP layer."
"Application Operation Code Opcode Description EINAPV21 0x0101 EINAPV21 Activate Resource 0x0102 EINAPV21 Activity Test 0x0103 EINAPV21 Congestion Control 0x0104 EINAPV21 Create 0x0105 EINAPV21 Event 0x0106 EINAPV21 Free 0x0107 EINAPV21 Generate 0x0108 EINAPV21 Handover 0x0109 EINAPV21 Charging Information 0x010A EINAPV21 Join 0x010B EINAPV21 Monitor 0x010C EINAPV21 Open Special Function 0x010D EINAPV21 Provide Instructions 0x010E EINAPV21 Release Resource 0x010F EINAPV21 Reset Timer Opcode Description 0x0110 EINAPV21 Retrieve 0x0111 EINAPV21 sCF Reset Indication 0x0112 EINAPV21 Split 0x0113 EINAPV21 sSF Reset Indication 0x0114 EINAPV21 Transfer Control 0x0115 EINAPV21 Update 0x0116 EINAPV21 Backward Information 0x0117 EINAPV21 Call Control INAPCS1P 0x0200 INAPCS1P InitialDP 0x0210 INAPCS1P Retrieve / Assist Request Instructions 0x0211 INAPCS1P Establish Temporary Connection 0x0212 INAPCS1P Disconnect Forward Connection 0x0213 INAPCS1P Connect To Resource 0x0214 INAPCS1P Connect 0x0215 INAPCS1P Update 0x0216 INAPCS1P Release Call 0x0217 INAPCS1P Request Report BCSM Event 0x0218 INAPCS1P Event Report BCSM 0x0219 INAPCS1P Request Notification Charging Event 0x021A INAPCS1P Event Notification Charging 0x021B INAPCS1P Collect Information 0x021F INAPCS1P Continue 0x0220 INAPCS1P Initiate Call Attempt Opcode Description 0x0221 INAPCS1P Reset Timer 0x0222 INAPCS1P Furnish Charging Information 0x0223 INAPCS1P Apply Charging 0x0224 INAPCS1P Apply Charging Report 0x0229 INAPCS1P Call Gap 0x022A INAPCS1P Activate Service Filtering 0x022B INAPCS1P Service Filtering Response 0x022C INAPCS1P Call Information Report 0x022D INAPCS1P Call Information Request 0x022E INAPCS1P Send Charging Information 0x022F INAPCS1P Play Announcement 0x0230 INAPCS1P Prompt And Collect User Information 0x0231 INAPCS1P Specialised Resource Report 0x0235 INAPCS1P Cancel 0x0236 INAPCS1P Activity Test 0x02F8 INAPCS1P Signalling Information 0x02FA INAPCS1P Release Call Party Connection 0x02FB INAPCS1P Reconnect 0x02FC INAPCS1P Hold Call Party Connection 0x02FD INAPCS1P HandOver 0x02FE INAPCS1P Dialogue User Information 0x02FF INAPCS1P Call Limit ETSI_INAP 0x0300 ETSI_INAP InitialDP Opcode Description 0x0310 ETSI_INAP Retrieve / Assist Request Instructions 0x0311 ETSI_INAP Establish Temporary Connection 0x0312 ETSI_INAP Disconnect Forward Connection 0x0313 ETSI_INAP Connect To Resource 0x0314 ETSI_INAP Connect 0x0315 ETSI_INAP Update 0x0316 ETSI_INAP Release Call 0x0317 ETSI_INAP Request Report BCSM Event 0x0318 ETSI_INAP Event Report BCSM 0x0319 ETSI_INAP Request Notification Charging Event 0x031A ETSI_INAP Event Notification Charging 0x031B ETSI_INAP Collect Information 0x031F ETSI_INAP Continue 0x0320 ETSI_INAP Initiate Call Attempt 0x0321 ETSI_INAP Reset Timer 0x0322 ETSI_INAP Furnish Charging Information 0x0323 ETSI_INAP Apply Charging 0x0324 ETSI_INAP Apply Charging Report 0x0329 ETSI_INAP Call Gap 0x032A ETSI_INAP Activate Service Filtering 0x032B ETSI_INAP Service Filtering Response 0x032C ETSI_INAP Call Information Report 0x032D ETSI_INAP Call Information Request 0x032E ETSI_INAP Send Charging Information Opcode Description 0x032F ETSI_INAP Play Announcement 0x0330 ETSI_INAP Prompt And Collect User Information 0x0331 ETSI_INAP Specialised Resource Report 0x0335 ETSI_INAP Cancel 0x0336 ETSI_INAP Activity Test ETSI_CAP 0x0400 ETSI_CAP InitialDP 0x0410 ETSI_CAP Assist Request Instructions 0x0411 ETSI_CAP Establish Temporary Connection 0x0412 ETSI_CAP Disconnect Forward Connection 0x0413 ETSI_CAP Connect To Resource 0x0414 ETSI_CAP Connect 0x0416 ETSI_CAP Release Call 0x0417 ETSI_CAP Request Report BCSM Event 0x0418 ETSI_CAP Event Report BCSM 0x041F ETSI_CAP Continue 0x0420 ETSI_CAP Initiate Call Attempt 0x0421 ETSI_CAP Reset Timer 0x0422 ETSI_CAP Furnish Charging Information 0x0423 ETSI_CAP Apply Charging 0x0424 ETSI_CAP Apply Charging Report 0x0429 ETSI_CAP Call Gap 0x042C ETSI_CAP Call Information Report 0x042D ETSI_CAP Call Information Request Opcode Description 0x042E ETSI_CAP Send Charging Information 0x042F ETSI_CAP Play Announcement 0x0430 ETSI_CAP Prompt And Collect User Information 0x0431 ETSI_CAP Specialized Resource Report 0x0435 ETSI_CAP Cancel 0x0437 ETSI_CAP Activity Test 0x0438 ETSI_CAP Continue With Argument 0x043C ETSI_CAP InitialDP SMS 0x043D ETSI_CAP Furnish Charging Information SMS 0x043E ETSI_CAP Connect SMS 0x043F ETSI_CAP Request Report SMS Event 0x0440 ETSI_CAP Event Report SMS 0x0441 ETSI_CAP Continue SMS 0x0442 ETSI_CAP Release SMS 0x0443 ETSI_CAP Reset Timer SMS 0x0446 ETSI_CAP Activity Test GPRS 0x0447 ETSI_CAP Apply Charging GPRS 0x0448 ETSI_CAP Apply Charging Report GPRS 0x0449 ETSI_CAP Cancel GPRS 0x044A ETSI_CAP Connect GPRS 0x044B ETSI_CAP Continue GPRS 0x044C ETSI_CAP Entity Released GPRS 0x044D ETSI_CAP Furnish Charging Information GPRS 0x044E ETSI_CAP InitialDP GPRS Opcode Description 0x044F ETSI_CAP Release GPRS 0x0450 ETSI_CAP Event Report GPRS 0x0451 ETSI_CAP Request Report GPRS Event 0x0452 ETSI_CAP Reset Timer GPRS 0x0453 ETSI_CAP Send Charging Information GPRS 0x045A ETSI_CAP Disconnect Leg 0x045D ETSI_CAP Move Leg 0x045F ETSI_CAP Split Leg 0x0460 ETSI_CAP Entity Released 0x0461 ETSI_CAP Play Tone 0x04FF ETSI_CAP undefined field ETSI_MAP 0x0502 ETSI_MAP Update Location 0x0503 ETSI_MAP Cancel Location 0x0504 ETSI_MAP Provide Roaming Number 0x0505 ETSI_MAP Note Subscriber Data Modified 0x0506 ETSI_MAP Resume Call Handling 0x0507 ETSI_MAP Insert Subscriber Data 0x0508 ETSI_MAP Delete Subscriber Data 0x0509 ETSI_MAP Send Parameters 0x050A ETSI_MAP Register SS 0x050B ETSI_MAP Erase SS 0x050C ETSI_MAP Activate SS 0x050D ETSI_MAP Deactivate SS Opcode Description 0x050E ETSI_MAP Interrogate SS 0x050F ETSI_MAP Authentication Failure Report 0x0511 ETSI_MAP Register Password 0x0512 ETSI_MAP Get Password 0x0513 ETSI_MAP Process Unstructured SS-Data 0x0514 ETSI_MAP Release Resources 0x0515 ETSI_MAP MT Forward SM VGCS 0x0516 ETSI_MAP Send Routing Info 0x0517 ETSI_MAP Update Gprs Location 0x0518 ETSI_MAP Send Routing Info For GPRS 0x0519 ETSI_MAP Failure Report 0x051A ETSI_MAP Note MS Present For GPRS 0x051C ETSI_MAP Perform Handover 0x051D ETSI_MAP Send End Signal 0x051E ETSI_MAP Perform Subsequent Handover 0x051F ETSI_MAP Provide SIWFS Number 0x0520 ETSI_MAP SIW FS Signalling Modify 0x0521 ETSI_MAP Process Access Signalling 0x0522 ETSI_MAP Forward Access Signalling 0x0523 ETSI_MAP Note Internal Handover 0x0525 ETSI_MAP Reset 0x0526 ETSI_MAP Forward Check SS-Indication 0x0527 ETSI_MAP Prepare Group Call 0x0528 ETSI_MAP Send Group Call End Signal Opcode Description 0x0529 ETSI_MAP Process Group Call Signalling 0x052A ETSI_MAP Forward Group Call Signalling 0x052B ETSI_MAP Check IMEI 0x052C ETSI_MAP MT-ForwardSM 0x052D ETSI_MAP Send Routing Info For SM 0x052E ETSI_MAP MO-ForwardSM 0x052F ETSI_MAP Report SM-Delivery Status 0x0530 ETSI_MAP Note Subscriber Present 0x0531 ETSI_MAP Alert Service Centre Without Result 0x0532 ETSI_MAP Activate Trace Mode 0x0533 ETSI_MAP Deactivate Trace Mode 0x0534 ETSI_MAP Trace Subscriber Activity 0x0536 ETSI_MAP Begin Subscriber Activity 0x0537 ETSI_MAP Send Identification 0x0538 ETSI_MAP Send Authentication Info 0x0539 ETSI_MAP Restore Data 0x053A ETSI_MAP Send IMSI 0x053B ETSI_MAP Process Unstructured SS Request 0x053C ETSI_MAP Unstructured SS Request 0x053D ETSI_MAP Unstructured SS Notify 0x053E ETSI_MAP Any Time Subscription Interrogation 0x053F ETSI_MAP Inform Service Centre 0x0540 ETSI_MAP Alert Service Centre 0x0541 ETSI_MAP Any Time Modification Opcode Description 0x0542 ETSI_MAP Ready For SM 0x0543 ETSI_MAP Purge MS 0x0544 ETSI_MAP Prepare Handover 0x0545 ETSI_MAP Prepare Subsequent Handover 0x0546 ETSI_MAP Provide Subscriber Info 0x0547 ETSI_MAP Any Time Interrogation 0x0548 ETSI_MAP SS-Invocation Notification 0x0549 ETSI_MAP Set Reporting State 0x054A ETSI_MAP Status Report 0x054B ETSI_MAP Remote User Free 0x054C ETSI_MAP Register CC-Entry 0x054D ETSI_MAP Erase CC-Entry 0x054E ETSI_MAP Secure Transport Class1 0x054F ETSI_MAP Secure Transport Class2 0x0550 ETSI_MAP Secure Transport Class3 0x0551 ETSI_MAP Secure Transport Class4 0x0552 ETSI_MAP Provide Subscriber Location 0x0553 ETSI_MAP Send Group Call Information 0x0554 ETSI_MAP Send Routing Info For LCS 0x0555 ETSI_MAP Subscriber Location Report 0x0556 ETSI_MAP IST-Alert 0x0557 ETSI_MAP IST-Command 0x0558 ETSI_MAP Note MM-Event 0x05FF ETSI_MAP Undefined Field Opcode Description BEL IS41D 0x0601 BEL IS41D HandOff Measurement Request 0x0602 BEL IS41D Facilities Directive 0x0603 BEL IS41D Mobile on channel 0x0604 BEL IS41D HandOff Back 0x0605 BEL IS41D Facilities Release 0x0606 BEL IS41D Qualification Request 0x0607 BEL IS41D Qualification Directive 0x0608 BEL IS41D Blocking 0x0609 BEL IS41D Unblocking 0x060A BEL IS41D Reset Circuit 0x060B BEL IS41D TrunkTest 0x060C BEL IS41D Trunk Test Disconnect 0x060D BEL IS41D Registration Notification 0x060E BEL IS41D Registration Cancellation 0x060F BEL IS41D Location Request 0x0610 BEL IS41D Routing Request 0x0611 BEL IS41D Feature Request 0x0612 BEL IS41D Service Profile Request 0x0613 BEL IS41D Service Profile Directive 0x0614 BEL IS41D Unreliable Roamer Data Dir 0x0615 BEL IS41D Call Data Request 0x0616 BEL IS41D MS Inactive 0x0617 BEL IS41D Transfer To Number Request Opcode Description 0x0618 BEL IS41D Redirection Request 0x0619 BEL IS41D HandOff To Third 0x061A BEL IS41D Flash Request 0x061B BEL IS41D Authentication Directive 0x061C BEL IS41D Authentication Request 0x061D BEL IS41D Base Station Challenge 0x061E BEL IS41D Authentication Failure Report 0x061F BEL IS41D Count Request 0x0620 BEL IS41D InterSystemPage 0x0621 BEL IS41D Unsolicited Response 0x0622 BEL IS41D Bulk Deregistration 0x0623 BEL IS41D HandOff Measurement Request 2 0x0624 BEL IS41D Facilities Directive 2 0x0625 BEL IS41D HandOff Back 2 0x0626 BEL IS41D HandOff To Third 2 0x0627 BEL IS41D Authentication Directive Forward 0x0628 BEL IS41D Authentication Status Report 0x0629 BEL IS41D Reserved 0x062A BEL IS41D Information Directive 0x062B BEL IS41D Information Forward 0x062C BEL IS41D Inter System Answer 0x062D BEL IS41D Inter System Page 2 0x062E BEL IS41D Inter System Setup 0x062F BEL IS41D Origination Request Opcode Description 0x0630 BEL IS41D Random Variable Request 0x0631 BEL IS41D Redirection Directive 0x0632 BEL IS41D Remote User Interaction Dir 0x0633 BEL IS41D SMS Delivery Backward 0x0634 BEL IS41D SMS Delivery Forward 0x0635 BEL IS41D SMS Delivery Point To Point 0x0636 BEL IS41D SMS Notification 0x0637 BEL IS41D SMS Request 0x0639 BEL IS41D Number Portability Request 0x063A BEL IS41D Analyzed Information 0x063B BEL IS41D Connection Failure Report 0x063C BEL IS41D Connect Resource 0x063D BEL IS41D Disconnect Resource 0x063E BEL IS41D Facility Selected & Available 0x063F BEL IS41D Instruction Request 0x0640 BEL IS41D Modify 0x0641 BEL IS41D Reset Timer 0x0642 BEL IS41D Search 0x0643 BEL IS41D Seize Resource 0x0644 BEL IS41D SRF Directive 0x0645 BEL IS41D T Busy 0x0646 BEL IS41D T No Answer 0x0647 BEL IS41D ServiceRequest 0x0648 BEL IS41D Bulk Disconnection Opcode Description 0x0649 BEL IS41D Call Control Directive 0x064A BEL IS41D O Answer 0x064B BEL IS41D O Disconnect 0x064C BEL IS41D Call Recovery Report 0x064D BEL IS41D T Answer 0x064E BEL IS41D T Disconnect 0x064F BEL IS41D Unreliable Call Data TCAPOP 0x0701 TCAPOP Dequeue Call 0x0702 TCAPOP Queue Call 0x0703 TCAPOP Voice Message Retrieved 0x0704 TCAPOP Voice Message Available 0x0705 TCAPOP Cancel 0x0706 TCAPOP Security 0x0707 TCAPOP Report assist Termination 0x0708 TCAPOP Temporary Handover 0x0709 TCAPOP Automatic Code Gap 0x070A TCAPOP When Party Free 0x070B TCAPOP Indicate Information Provided 0x070C TCAPOP Indicate Information Waiting 0x070D TCAPOP Play announcement abd collect Digits 0x070E TCAPOP Play Announcement 0x070F TCAPOP Forward Disconnect 0x0710 TCAPOP Disconnect Opcode Description 0x0711 TCAPOP Temporary Connect 0x0712 TCAPOP Connect 0x0713 TCAPOP Assist 0x0714 TCAPOP Start 0x0715 TCAPOP Bill Call 0x0716 TCAPOP Set Value 0x0717 TCAPOP Provide Value INAPCS2 0x800 initialDP 0x801 originationAttemptAuthorized 0x802 collectedInformation 0x803 analysedInformation 0x804 routeSelectFailure 0x805 oCalledPartyBusy 0x806 oNoAnswer 0x807 oAnswer 0x808 oDisconnect 0x809 termAttemptAuthorized 0x80A tBusy 0x80B tNoAnswer 0x80C tAnswer 0x80D tDisconnect 0x80E oMidCall 0x80F tMidCall Opcode Description 0x810 assistRequestInstructions 0x811 establishTemporaryConnection 0x812 disconnectForwardConnection 0x813 connectToResource 0x814 connect 0x815 holdCallInNetwork 0x816 releaseCall 0x817 requestReportBCSMEvent 0x818 eventReportBCSM 0x819 requestNotificationChargingEvent 0x81A eventNotificationCharging 0x81B collectInformation 0x81C analyseInformation 0x81D selectRoute 0x81E selectFacility 0x81F continue 0x820 initiateCallAttempt 0x821 resetTimer 0x822 furnishChargingInformation 0x823 applyCharging 0x824 applyChargingReport 0x825 requestCurrentStatusReport 0x826 requestEveryStatusChangeReport 0x827 requestFirstStatusMatchReport Opcode Description 0x828 statusReport 0x829 callGap 0x82A activateServiceFiltering 0x82B serviceFilteringResponse 0x82C callInformationReport 0x82D callInformationRequest 0x82E sendChargingInformation 0x82F playAnnouncement 0x830 promptAndCollectUserInformation 0x831 specializedResourceReport 0x835 cancel 0x836 cancelStatusReportRequest 0x837 activityTest 0x850 facilitySelectedAndAvailable 0x851 originationAttempt 0x852 terminationAttempt 0x853 oAbandon 0x854 oSuspended 0x855 tSuspended 0x856 dFCWithArgument 0x857 authorizeTermination 0x858 continueWithArgument 0x859 createCallSegmentAssociation 0x85A disconnectLeg Opcode Description 0x85B mergeCallSegments 0x85C moveCallSegments 0x85D moveLeg 0x85E reconnect 0x85F splitLeg 0x860 entityReleased 0x861 manageTriggerData 0x862 requestReportUTSI 0x864 sendSTUI 0x865 reportUTSI 0x866 sendFacilityInformation 0x867 requestReportFacilityEvent 0x868 eventReportFacility 0x86B promptAndReceiveMessage 0x86C scriptInformation 0x86D scriptEvent 0x86E scriptRun 0x86F scriptClose 0x870 establishChargingRecord 0x871 handlingInformationRequest 0x872 handlingInformationResult 0x873 networkCapability 0x874 notificationProvided 0x875 confirmedNotificationProvided Opcode Description 0x876 provideUserInformation 0x877 confirmedReportChargingInformation 0x878 reportChargingInformation 0x879 requestNotification 0x87A activationReceivedAndAuthorized 0x87B initiateAssociation 0x87C associationReleaseRequested 0x87D componentReceived 0x87E releaseAssociation 0x87F requestReportBCUSMEvent 0x882 sendComponent NOKIA_INAP 0x900 initialDP 0x910 assistRequestInstructions 0x911 establishTemporaryConnection 0x912 disconnectForwardConnection 0x913 connectToResource 0x914 connect 0x916 releaseCall 0x917 requestReportBCSMEvent 0x918 eventReportBCSM 0x919 requestNotificationChargingEvent 0x91A eventNotificationCharging 0x91B collectInformation Opcode Description 0x91F continue 0x920 initiateCallAttempt 0x921 resetTimer 0x922 furnishChargingInformation 0x923 applyCharging 0x924 applyChargingReport 0x929 callGap 0x92A activateServiceFiltering 0x92B serviceFilteringResponse 0x92C callInformationReport 0x92D callInformationRequest 0x92E sendChargingInformation 0x92F playAnnouncement 0x930 promptAndCollectUserInformation 0x931 specializedResourceReport 0x935 cancel 0x937 activityTest SINAP 0xA00 sinapInitialDP 0xA10 sinapAssistRequestInstructions 0xA11 sinapEstablishTemporaryConnection 0xA12 disconnectForwardConnection 0xA13 sinapConnectToResource 0xA14 sinapConnect Opcode Description 0xA16 sinapReleaseCall 0xA17 sinapRequestReportBCSMEvent 0xA18 sinapEventReportBCSM 0xA19 requestNotificationChargingEvent 0xA1A eventNotificationCharging 0xA1B collectInformation 0xA1F continue 0xA20 sinapInitiateCallAttempt 0xA21 sinapResetTimer 0xA22 furnishChargingInformation 0xA23 sinapApplyCharging 0xA24 sinapApplyChargingReport 0xA29 sinapCallGap 0xA2A activateServiceFiltering 0xA2B serviceFilteringResponse 0xA2C sinapCallInformationReport 0xA2D sinapCallInformationRequest 0xA2E sinapSendChargingInformation 0xA2F sinapPlayAnnouncement 0xA30 sinapPromptAndCollectUserInformation 0xA31 specializedResourceReport 0xA35 sinapCancel 0xA56 sinapDisconnectForwardConnectionWithArgument 0xA58 sinapContinueWithArgument Opcode Description 0xA5A sinapDisconnectLeg 0xA5B sinapMergeCallSegments 0xA5F sinapSplitLeg 0xA60 sinapEntityReleased 0xA62 manageTriggerData 0xA63 releaseLeg 0xA6D sinapScriptEvent 0xA6E sinapScriptRun WHITE TCAP - Application Error Code This field has to be filled with error codes of EINAPV21, INAPCS1P, ETSI_CAP,ETSI_MAP, ETSI_INAP,INAPCS2,NOKIA_INAP,SINAP,BELIS41D,TCAPOP layers when Return Error Component comes with their Error Code Value. BELL TCAP Fields BELL TCAP Ð Application Operation Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 257 Parameter Provide Value X X 258 Parameter Set Value X x 513 Charging Bill Call X X 769 Provide Instructions Start X x X 770 Provide Instructions Assist X X 1025 Connection Control Connect X x X 1026 Connection Control Temporary Connect X X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 1027 Connection Control Disconnect X X 1028 Connection Control Forward Disconnect X X 1281 Caller Interaction Play Announcement X x X 1282 Caller Interaction PA and Collect Digits X X 1283 Caller Interaction Indicate Information Waiting X 1284 Caller Interaction Indicate Information Provided X 1537 Send Notification When Party Free X x X 1793 Network Management Automatic Code Gap X x X 2049 Procedural Temporary Handover X X 2050 Procedural Report Assist Termination X 2051 Procedural Security X x x 2305 Operation Control Cancel X 2561 Report Event Voice Message Available X 2562 Report Event Voice Message Retrieved X 32257 Miscellaneous Queue Call X 32258 Miscellaneous Dequeue Call x 26116 callInfoFromResource X 28161 close X 26118 cTRClear X 25604 failureOutcome X 25603 infoAnalyzed X 25602 infoCollected X 25623 networkBusy X 25611 oAnswer X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 25614 oAbandon X 25607 oCalledPartyBusy X 25626 oDisconnect X 25615 oMidCall X 25609 oNoAnswer X 25625 oSuspended X 25612 oTermSeized X 25624 originationAttempt X 26114 resourceClear X 25617 successOutcome X 25610 tAnswer X 25606 tBusy X 25618 tDisconnect X 25619 tMidCall X 25608 tNoAnswer X 25605 terminationAttempt X 25613 termResourceAvailable X 25620 timeout X 25862 acknowledge X 25857 analyzeRoute X 25858 authorizeTermination X 26115 cancelResourceEvent X 25861 collectInformation X 26117 connectToResource X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 25869 continue X 25863 createCall X 25859 disconnect X 25864 disconnectLeg X 27137 forwardCall X 25865 mergeCall X 25866 moveLeg X 25860 offerCall X 25867 originateCall X 25870 reconnect X 26113 sendToResource X 25868 splitLeg X 26881 acg X 26883 acgGlobalCtrlRestore X 26884 acgOverflow X 26885 controlRequest X 26882 echoRequest X 27649 furnishAMAInformation X 26369 monitorForChange X 26371 monitorSuccess X 27394 nCAData X 27393 nCARequest X 26626 queryRequest X 27905 requestReportBCMEvent X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 26373 sendNotification X 26370 statusReported X 26372 terminationNotification X 26627 update X 26625 updateRequest X 28417 reportError X 25627 oDTMFEnteredArg X 26889 setTimerArg X 25628 tDTMFEnteredArg X 26886c activityTestArg X 26887 callTypeRequestArg X BELL TCAP Ð Last Application Operation Code Applicable protocol: TCAP-OP, BELL LIDB, BELL AIN BELL TCAP Ð Application Error Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP Ð Reject Problem Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP Ð Translation Type Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP - GTT REQUESTED Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB BELL TCAP Ð TCAP 800 Termination Indicator Applicable protocol: BELL TCAP 800 CSDR Type CSDR field Description BELL_TCAP_800_CSDR TERMIN_INDIC This field indicates the termination indicator. BELL TCAP Ð AIN Error Cause Applicable protocol: BELL AIN CSDR Type CSDR field Description BELL_AIN ER_REASON Contains a reason for those transactions having an error carrying additional information. This parameter is sent to identify the application error detected at the SSP or SCP. This field and the ÔErrorCodeÕ field specify the exact error and reason. BELL TCAP Ð TCAP OP Line Service Type Applicable protocol: BELL TCAP OP CSDR Type CSDR field Description BELL_TCAP_OP_CSDR SERVICE_TYPE This field indicates which line service type is associated with a DN and also whether a DN is applicable to both originating and terminating service Value Interpretation 0 Individual 1 Coin 2 Multiline Hunt 3 PBX 4 Choke Value Interpretation 5 Series Completion 6 Unassigned DN 7 Multi-Party 8 Non-specific 9 Temporarily out of Service BELL TCAP Ð LIDB Service or Equipment Indicator Applicable protocol: BELL TCAP OP, BELL LIDB CSDR Type CSDR field Description BELL_LIDB_CSDR LIDB_SERVICE_EQUIPMENT_INDICATOR This parameter indicates the type of service or equipment associated with the line originating the call. Value Interpretation 1 POTS Line (Business/Residential) 2 LEC Public - Standard Interface - Postpay Overtime 3 POTS Line - Residential - Message rate 1 4 POTS Line - Residential - Message rate 2 5 LEC Semi-Public 6 POTS Line - Business - flat rate 7 POTS Line - Business - message rate 1 8 Coinless (non-IPP) 9 Coinless (IPP) 10 LEC Prepaid Telecommunications Card Station 11 POTS Line - Business - message rate 2 Value Interpretation 12 LEC Public - Standard Interface - Prepay Overtime 13 LEC Public - Alternate Interface 14 IC Public - Standard Interface 15 IC Public -Alternate Interface 16 POTS line - Residential - flat rate 17 Voice Quote - without tax 18 Voice Quote - with tax 19 IPP - Standard Interface 20 IPP - Alternate Interface 21 Hospital 22 Prison (non-IPP) 23 Auto Quote - without tax 24 Auto Quote - with tax 25 Dormitory Line 26 Centrex Line 27 PBX Line 28 Prison (IPP) 29 WATS Line 30 Cellular 31 Pager 32 Personal Communication Service (PCS) 33 Feature Group A (FGA) 34 Mobile 35 LEC Public - Special Billing - Postpay Overtime Value Interpretation 36 LEC Public - Special Billing - Prepay Overtime 37 Public - Incompatible Network Interface 38 Cellular-Rate 1 39 Cellular-Rate 2 40 POTS Line - Business - Single-Line 41 POTS Line - Business - Multi-Line 42 Public-Postpay 255 Reserved MAP Fields MAP Ð First Leg Operation Code It represents the first operation invoked at MAP layer related to the first leg of the MAP transaction in case of correlated generation. Value Operation Name 2 updateLocation 3 cancelLocation 4 provideRoamingNumber 5 noteSubscriberDataModified 6 resumeCallHandling 7 insertSubscriberData 8 deleteSubscriberData 9 sendParameters 10 registerSS 11 eraseSS 12 activateSS Value Operation Name 13 deactivateSS 14 interrogateSS 15 authenticationFailureReport 17 registerPassword 18 getPassword 19 processUnstructuredSS-Data 20 ReleaseResources 21 mt-ForwardSM-VGCS 22 sendRoutingInfo 23 updateGprsLocation 24 sendRoutingInfoForGprs 25 failureReport 26 noteMsPresentForGprs 28 performHandover 29 sendEndSignal 30 performSubsequentHandover 31 provideSIWFSNumber 32 SIWFSSignallingModify 33 processAccessSignalling 34 forwardAccessSignalling 35 noteInternalHandover 37 reset 38 forwardCheckSS-Indication 39 prepareGroupCall 40 sendGroupCallEndSignal 41 processGroupCallSignalling 42 forwardGroupCallSignalling 43 checkIMEI Value Operation Name 44 MT-ForwardSM 45 sendRoutingInfoForSM 46 MO-ForwardSM 47 reportSM-DeliveryStatus 48 noteSubscriberPresent 49 alertServiceCentreWithoutResult 50 activateTraceMode 51 deactivateTraceMode 52 traceSubscriberActivity 54 beginSubscriberActivity 55 sendIdentification 56 sendAuthenticationInfo 57 restoreData 58 sendIMSI 59 processUnstructuredSSRequest 60 unstructuredSSRequest 61 unstructuredSSNotify 62 anyTimeSubscriptionInterrogation 63 informServiceCentre 64 alertServiceCentre 65 anyTimeModification 66 readyForSM 67 purgeMS 68 prepareHandover 69 prepareSubsequentHandover 70 provideSubscriberInfo 71 anyTimeInterrogation 72 SS-InvocationNotification 73 setReportingState Value Operation Name 74 statusReport 75 remoteUserFree 76 registerCC-Entry 77 eraseCC-Entry 78 secureTransportClass1 79 secureTransportClass2 80 secureTransportClass3 81 secureTransportClass4 83 provideSubscriberLocation 84 sendGroupCallInfo 85 sendRoutingInfoForLCS 86 subscriberLocationReport 87 IST-Alert 88 IST-Command 89 noteMM-Event 255 undefined field MAP Ð First Leg Application Error Code It represents the error code of the procedure at application layer (MAP) related to the first leg of the transaction in case of correlated generation. Value Error Name 1 unknownSubscriber 8 roamingNotAllowed 13 callBarred 15 cug-Reject 27 absentSubscriber 32 sm-DeliveryFailure Value Error Name 34 systemFailure 37 pw-RegistrationFailure 53 unauthorizedLCSClient 54 positionMethodFailure 21 facilityNotSupported 45 busySubscriber 31 subscriberBusyForMT-SMS 254 Invalid combination of Error Code and User ErrorReason MAP Ð First Leg Additional Error Reason This field specifies the error reason for those MAP transactions having error carrying additional information related to the first leg of the transaction in case of correlated generation. MAP Ð First Leg SMS Service Centre Time Stamp This filed is filled with the absolute time stamp that is offered to the recipient of a short message on when the message arrived at the SM-TL entity of the SC related to the first leg of the transaction in case of correlated generation. MAP Ð Last Leg Operation Code It represents the first operation invoked at MAP layer related to the last leg of the transaction in case of correlated generation. Value Operation Name 2 updateLocation 3 cancelLocation 4 provideRoamingNumber 5 noteSubscriberDataModified 6 resumeCallHandling 7 insertSubscriberData Value Operation Name 8 deleteSubscriberData 9 sendParameters 10 registerSS 11 eraseSS 12 activateSS 13 deactivateSS 14 interrogateSS 15 authenticationFailureReport 17 registerPassword 18 getPassword 19 processUnstructuredSS-Data 20 ReleaseResources 21 mt-ForwardSM-VGCS 22 sendRoutingInfo 23 updateGprsLocation 24 sendRoutingInfoForGprs 25 failureReport 26 noteMsPresentForGprs 28 performHandover 29 sendEndSignal 30 performSubsequentHandover 31 provideSIWFSNumber 32 SIWFSSignallingModify 33 processAccessSignalling 34 forwardAccessSignalling 35 noteInternalHandover 37 reset 38 forwardCheckSS-Indication 39 prepareGroupCall Value Operation Name 40 sendGroupCallEndSignal 41 processGroupCallSignalling 42 forwardGroupCallSignalling 43 checkIMEI 44 MT-ForwardSM 45 sendRoutingInfoForSM 46 MO-ForwardSM 47 reportSM-DeliveryStatus 48 noteSubscriberPresent 49 alertServiceCentreWithoutResult 50 activateTraceMode 51 deactivateTraceMode 52 traceSubscriberActivity 54 beginSubscriberActivity 55 sendIdentification 56 sendAuthenticationInfo 57 restoreData 58 sendIMSI 59 processUnstructuredSSRequest 60 unstructuredSSRequest 61 unstructuredSSNotify 62 anyTimeSubscriptionInterrogation 63 informServiceCentre 64 alertServiceCentre 65 anyTimeModification 66 readyForSM 67 purgeMS 68 prepareHandover Value Operation Name 69 prepareSubsequentHandover 70 provideSubscriberInfo 71 anyTimeInterrogation 72 SS-InvocationNotification 73 setReportingState 74 statusReport 75 remoteUserFree 76 registerCC-Entry 77 eraseCC-Entry 78 secureTransportClass1 79 secureTransportClass2 80 secureTransportClass3 81 secureTransportClass4 83 provideSubscriberLocation 84 sendGroupCallInfo 85 sendRoutingInfoForLCS 86 subscriberLocationReport 87 IST-Alert 88 IST-Command 89 noteMM-Event 255 undefined field MAP Ð Last Leg Application Error Code It represents the error code of the procedure at application layer (MAP) related to the first leg of the transaction in case of correlated generation. Value Error Name 1 unknownSubscriber 8 roamingNotAllowed Value Error Name 13 callBarred 15 cug-Reject 27 absentSubscriber 32 sm-DeliveryFailure 34 systemFailure 37 pw-RegistrationFailure 53 unauthorizedLCSClient 54 positionMethodFailure 21 facilityNotSupported 45 busySubscriber 31 subscriberBusyForMT-SMS 254 Invalid combination of Error Code and User ErrorReason MAP Ð Last Leg Additional Error Reason This field specifies the error reason for those MAP transactions having error carrying additional information related to the last leg of the transaction in case of correlated generation. MAP Ð Last Leg SMS Service Centre Time Stamp This filed is filled with the absolute time stamp that is offered to the recipient of a short message on when the message arrived at the SM-TL entity of the SC related to the last leg of the transaction in case of correlated generation. MAP - SMS Message Reference Number The TP Message Reference field gives an integer representation of a reference number of the SMS SUBMIT or SMS COMMAND submitted to the Service Centre by the Mobile station. MAP - GSM Absent Reason This parameter represents the reason why the subscriber is absent MAP - MSRN A Mobile Station Roaming Number (MSRN) is an E.164 defined telephone number used to route telephone calls in a mobile network from a GMSC (Gateway Mobile Switching Centre) to the target MSC. It can also be defined as a directory number temporarily assigned to a mobile for a mobile terminated call. (Reference GSM 09.02 V5.3.0, 8.3.3) MAP - USSD String This fields contains a string of unstructured information in an Unstructured Supplementary Service Data operation ItÕs filled by: Process Unstructured SS, Unstructured SS Request and Unstructured SS Notify whichever comes first in the sequence. Note: This field would be filled only in case of dcs value indicating 7-bit and will not be filled if in case dcs value is 8-bit/UCS2 as the support in application is temporarily not available. MAP - Service Centre Address This parameter designates the address of a short message service centre. This field may also be carried by SM-RP-DA and SM-RP-OA parameters. SMS Service Centre Address (Reference GSM 09.02, 5.6.2.27). MAP - SGSN Address This parameter designates the address of a SGSN. Update GPRS Location, Send Routing Info for GPRS and Note MS Present for GPRS messages may also carry this field. SGSN Address (Reference 3GPP TS 29.002 sec 7.6.2.39). MAP - GGSN Address This parameter designates the address of a GGSN. Update GPRS Location Failure Report and Note MS Present for GPRS messages may also carry this field. GGSN Address (Reference 3GPP TS 29.002 sec 7.6.2.40). MAP - Home GMLC Address This parameter refers to the IP address of Home Gateway mobile location centre. (3GPP TS 29.002 sec 7.6.2.61). ItÕs filled from: ProvideSubscriberLocation and SubscriberLocationReport operations. MAP - Visited GMLC Address This parameter refers to the IP address of Visitor Gateway mobile location centre. (3GPP TS 29.002 sec 7.6.2.59). ItÕs filled from: UpdateLocation, UpdateGprsLocation and RoutingInfoforLCS MAP - TP Origination Address Alphanumeric This field is filled from 'MAP_MO/MT_FORWARD_SHORT_MESSAGE and MT Forwared SM VGCSÕ in SM-RP-UI IE whichever comes first in the sequence. GSM 29.002, 7.6.2.11 Additional number: TS 100 974 V7.5.1, 7.6.2.46 + 12.1 MAP - TP Destination Address Alphanumeric This field is filled from 'MAP_MO/MT_FORWARD_SHORT_MESSAGE and MT Forwarded SM VGCSÕ in SM-RP-UI IE whichever comes first in the sequence. GSM 29.002, 7.6.2.11 Additional number: TS 100 974 V7.5.1, 7.6.2.46 + 12.1 MAP Ð TP Message Type Indicator This field specifies the SMS TP message type. MAP Ð SMS Delivery Time Interval This field identifies the SMS Delivery Time Interval by means of a lookup of the SMS Delivery Time field on MCLS table SMS Delivery Time Interval. MCLS Table: SMS Delivery Time Interval Standard Formatting: Column SDTI_INTERVAL_NAME SDTI _LOWER_VALUE SDTI _UPPER_VALUE Default value table: SMS Delivery Time Interval Name SMS Delivery Time Lower Value (s) SMS Delivery Time Upper Value (s) 0-6 s 0 6 7-11 s 7 11 12-30 s 12 30 >=30 30 Factor conversion: 1000 (from msec to sec) CAP Fields CAP - Operation Code It represents the first operation invoked at CAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement Value Operation Name 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest 56 ContinueWith Argument 60 initialDPSMS 61 furnish Charging InformationSMS 62 connectSMS 63 requestReportSMSEvent 64 eventReportSMS 65 continueSMS 66 releaseSMS 67 resetTimerSMS 70 activityTestGPRS 71 apply Charging GPRS 72 applyChargingReportGPRS 73 cancelGPRS 74 connectGPRS 75 continueGPRS 76 entityReleasedGPRS 77 furnishChargingInformationGPRS 78 initialDPGPRS 79 releaseGPRS 80 eventReportGPRS Value Operation Name 81 requestReportGPRSEvent 82 resetTimerGPRS 83 sendChargingInformationGPRS 90 DisconnectLeg 93 Move Leg 95 Split Leg 96 Entity Released 97 Play Tone 255 undefined field CAP - Last Operation Code It represents the last operation invoked at CAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 31 continue 32 InitiateCallAttempt Value Operation Name 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest 56 ContinueWith Argument 60 initialDPSMS 61 furnish Charging InformationSMS 62 connectSMS 63 requestReportSMSEvent 64 eventReportSMS 65 continueSMS 66 releaseSMS 67 resetTimerSMS 70 activityTestGPRS 71 apply Charging GPRS Value Operation Name 72 applyChargingReportGPRS 73 cancelGPRS 74 connectGPRS 75 continueGPRS 76 entityReleasedGPRS 77 furnishChargingInformationGPRS 78 initialDPGPRS 79 releaseGPRS 80 eventReportGPRS 81 requestReportGPRSEvent 82 resetTimerGPRS 83 sendChargingInformationGPRS 255 undefined field CAP - Operation Mask S.No Interpretation (Enumeration) Bit Position 1 Initial DP/GPRS/SMS 0 2 Apply charging / GPRS 1 3 Disconnect Forward Connection 2 4 ConnectToResource 3 5 Connect / GPRS /SMS 4 6 ReleaseCall / GPRS / SMS 5 7 Continue / GPRS / SMS 6 8 ResetTimer / GPRS /SMS 7 9 FurnishChargingInfo / GPRS / SMS 8 10 CallGap 9 11 CallInformationReport 10 S.No Interpretation (Enumeration) Bit Position 12 CallInformationRequest 11 13 PlayAnnouncement 12 14 PromptAddCollectUserInfo 13 15 SpecializedResourceReport 14 16 ActivityTest / GPRS 15 17 ApplyChargingReport / GPRS 16 18 Cancel / GPRS 17 19 AssistRequestInstructions 18 20 SendChargingInfo / GPRS 19 21 EntityReleasedGPRS 20 22 EventReportBCSM / GPRS / SMS 21 23 RequestReport BCSM/GPRS/SMS 22 24 EstablishTemporaryConnection 23 25 ContinueWithArgument 24 26 InitiateCallAttempt 25 27 DisconnectLeg 26 28 MoveLeg 27 29 SplitLeg 28 30 EntityReleased 29 31 PlayTone 30 32 Spare 31 CAP - Application Error Code It represents the error code of the procedure at application layer (CAP). Value Error Name 0 Cancelled 1 Cancel Failed 3 eTC Failed 4 Improper Caller Response 6 Missing Customer Record Value Error Name 7 Missing Parameters 8 Parameter Out of Range 10 Requested Info Error 11 System Failure 12 Task Refused 13 Unavailable Resource 14 Unexpected Component Sequence 15 Unexpected Data Value 16 Unexpected Parameter 17 Unknown Leg ID 50 Unknown PDP ID 51 Unknown CS ID CAP - Additional Error Reason This field specifies the error reason for those CAP transactions having error carrying additional information. Code Text 0 unknown Operation 1 tooLate 2 operationNotCancellable 3 unknownRequestedInfo 4 requestedInfoNotAvailable 5 unavailableResources 6 componentFailure Code Text 7 basicCallProcessingException 8 resourceStatusFailure 9 endUserFailure 10 generic 11 unobtainable 12 congestion CAP - Response Cause It is additional error at CAP layer. Release cause of CAP InitialDP, ReleaseCall, EventReportBCSM or CallInformationReport accordingly to Q.850. Cause value of RPcause of ReleaseSMS SMScause from EventSpecificInformation-SMS of EventReportSMS GPRScause of EntityReleasedGPRS or ReleaseGPRS Cause of ÒCallSegmentFailureÓ component present in ÒENTITY RELEASEDÓ ÒMO-SMSCauseÓ from ÒEventSpecificInformationSMSÓ of ÒEVENT REPORT SMSÓ ÒMT-SMSCauseÓ from ÒEventSpecificInformationSMSÓ of ÒEVENT REPORT SMSÓ Cause from ÒBCSM-FailureÓ of ÒENTITY RELEASEDÓ 1, unallocated (unassigned) number 2, no route to specified transit network 3, no route to destination 4, send special information tone 5, misdialled trunk prefix 6, channel unacceptable 7, call awarded and being delivered in an established channel 8, preemption 9, preemption - circuit reserved for reuse 16, normal call clearing 17, user busy 18, no user responding 19, no answer from user (user alerted) 20, subscriber absent 21, call rejected 22, number changed 26, non-selected user clearing 27, destination out of order 28, invalid number format (address incomplete) 29, facility rejected 30, response to STATUS ENQUIRY 31, normal, unspecified 34, no circuit/channel available 38, network out of order 39, permanent frame mode connection out of service 40, permanent frame mode connection operational 41, temporary failure 42, switching equipment congestion 43, access information discarded 44, requested circuit/channel not available 46, precedence call blocked 47, resource unavailable, unspecified 49, quality of service unavailable 50, requested facility not subscribed 53, outgoing calls barred within CUG 55, incoming calls barred within CUG 57, bearer capability not authorized 58, bearer capability not presently available 62, inconsistency in designated outgoing access information and subscriber class 63, service or option not availalbe, unspecified 65, bearer capability not implemented 66, channel type not implemented 69, requested facility not implemented 70, only restricted digital information bearer capability is available 79, service or option not implemented, unspecified 81, invalid call reference value 82, identified channel does not exist 83, A suspended call exists, but this call identity does not 84, call identity in use 85, no call suspended 86, call having the requested call identity has been cleared 87, user not member of CUG 88, incompatible destination 90, non-existent CUG 91, invalid transit network selection 95, invalid message, unspecified 96, mandatory information element is missing 97, message type non-existent or not implemented 98, message not compatible with call state or message type non-existent or not implemented 99, information element/parameter non-existent or not implemented 100, invalid information element contents 101, message not compatible with call state 102, recovery on timer expiry 103, parameter non-existent or not implemented, passed on 110, message with unrecognized parameter, discarded 111, protocol error, unspecified 127, interworking, unspecified 255, NO CC Cause CAP - Destination Routing Address C-party address (DestinationRoutingAddress). Filled From: Connect or DestinationSubscriberNumber from ConnectSMS or InitialDPSMS or part of EventSpecificInformation. Or EventReportBCSM CAP - Event Report Cause It is applicable for CAP CSDR only. Event Report Cause can be present in any of the sequence routeSelectFailureSpecificInfo, oCalledPartyBusySpecificInfo, oDisconnectSpecificInfo, tBusySpecificInfo, tDisconnectSpecificInfo and oAbandonSpecificInfo present in EventReportBCSM or CallInformationReport. EventReportCause Value Description 0 system failure 1 unallocated (unassigned) number 2 no route to specified transit network 3 no route to destination 4 send special information tone 5 misdialled trunk prefix 6 channel unacceptable 7 call awarded and being delivered in an established channel 8 preemption 9 preemption - circuit reserved for reuse 10 call barred 16 normal call clearing 17 user busy 18 no user responding 19 no answer from user (user alerted) 20 subscriber absent 21 call rejected EventReportCause Value Description 22 number changed 23 redirection to new destination 25 exchange routing error 26 non-selected user clearing 27 destination out of order 28 invalid number format (address incomplete) 29 facility rejected 30 response to STATUS ENQUIRY 31 normal, unspecified 34 no circuit/channel available 38 network out of order 39 permanent frame mode connection out of service 40 permanent frame mode connection operational 41 temporary failure 42 switching equipment congestion 43 access information discarded 44 requested circuit/channel not available 46 precedence call blocked 47 resource unavailable, unspecified 49 quality of service unavailable 50 requested facility not subscribed 53 outgoing calls barred within CUG 55 incoming calls barred within CUG 57 bearer capability not authorized EventReportCause Value Description 58 bearer capability not presently available 62 inconsistency in designated outgoing access information and subscriber class 63 service or option not availalbe, unspecified 65 bearer capability not implemented 66 channel type not implemented 69 requested facility not implemented 70 only restricted digital information bearer capability is available 79 service or option not implemented, unspecified 81 invalid call reference value 82 identified channel does not exist 83 A suspended call exists, but this call identity does not 84 call identity in use 85 no call suspended 86 call having the requested call identity has been cleared 87 user not member of CUG 88 incompatible destination 90 non-existent CUG 91 invalid transit network selection 95 invalid message, unspecified 96 mandatory information element is missing 97 message type non-existent or not implemented 98 message not compatible with call state or message type non-existent or not implemented EventReportCause Value Description 99 information element/parameter non-existent or not implemented 100 invalid information element contents 101 message not compatible with call state 102 recovery on timer expiry 103 parameter non-existent or not implemented, passed on 110 message with unrecognized parameter, discarded 111 protocol error, unspecified 127 interworking, unspecified 128 Request accepted 192 Non-existent 193 Invalid message format 194 IMSI not known 195 MS is GPRS Detached 196 MS is not GPRS Responding 197 MS Refuses 198 Version not supported 199 No resources available 200 Service not supported 201 Mandatory IE incorrect 202 Mandatory IE missing 203 Optional IE incorrect 204 System failure 205 Roaming restriction EventReportCause Value Description 206 P-TMSI Signature mismatch 207 GPRS connection suspended 208 Authentication failure 209 User authentication failed 210 Context not found 211 All dynamic PDP addresses are occupied 212 No memory is available 213 Relocation failure 214 Unknown mandatory extension header 215 Semantic error in the TFT operation 216 Syntactic error in the TFT operation 217 Semantic errors in packet filter(s) 218 Syntactic errors in packet filter(s) 219 Missing or unknown APN 220 Unknown PDP address or PDP type 221 PDP context without TFT already activated 222 APN access denied - no subscription 223 APN Restriction type incompatibility with currently active PDP Contexts 224 MS MBMS Capabilities Insufficient 225 Invalid Correlation-ID 226 MBMS Bearer Context Superseded 254 route not permitted CAP - Event Type The BCSM DP event triggering the InitialDP or the SMSEvent triggering the InitialDPSMS or the GPRSEvent triggering the InitialDPGPRS. In order to interpret this field the field OperationCode has to be taken into account. In case of CAMEL Phase 1 and 2, the following table is a reference for SRS. Code Text 1 orig Attempt Authorized 2 collect Info 3 analyzed Information 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect 18 TAbandon 255 undefined field CAP - Reported Event Code Text 1 orig Attempt Authorized 2 Collected Info 3 analyzed Information or detached 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 11 pdp-ContextEstablishment 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect 18 TAbandon 19 oTermSeized 27 callAccepted 50 oChangeOfPosition 51 tChangeOfPosition 255 Undefined field CAP Ð Cell Identity INAP Fields INAP - Operation Code It represents the first operation invoked at INAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 25 request notification charging event 26 event notification charging 27 collect information 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap Value Operation Name 42 activate service filtering 43 service filtering response 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest INAP - Last Operation Code It represents the last operation invoked at INAP layer."
"Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 25 request notification charging event Value Operation Name 26 event notification charging 27 collect information 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 42 activate service filtering 43 service filtering response 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest INAP - Operation Mask1 By Default Opcode values refer to ETSI INAP (including CZECH INAP), for other INAP variants it is mentioned specifically. If it is unknown, opcode for particular variant it is not mentioned for that particular bit. Bit Position Opcode 0 (LSB) Initial DP In CHINA INAP: Initial DP In Siemens INAP: Initial DP In INAP LW: Initial DP In INAPCS1P: Initial DP In INAPCS2: Initial DP 1 In EINAPV21: Activate Resource In INAPCS2: OriginationAttemptAuthorized In INAPCS1P: ApplyCharging 2 In EINAPV21: Activity Test In INAPCS1P: ConnectToResource In INAPCS2: CollectedInformation 3 In EINAPV21: CongestionControl In INAP LW: Connect In INAPCS1P: Connect In INAPCS2: AnalysedInformation 4 In EINAPV21: Create In INAP LW: ReleaseCall In INAPCS1P: ReleaseCall In INAPCS2: RouteSelectFailure 5 In EINAPV21: Event In INAP LW: Continue In INAPCS1P: Continue In INAPCS2: OcalledPartyBusy 6 In EINAPV21: Free In INAP LW: ResetTimer In INAPCS1P: ResetTimer In INAPCS2: Onoanswer 7 In EINAPV21: Generate In INAPCS1P: FurnishChargingInformation Bit Position Opcode In INAPCS2: Oanswer 8 In EINAPV21: HandOver In INAPCS1P: CallGap In INAPCS2: Odisconnect 9 In EINAPV21: ChargingInformation In INAPCS1P: CallInformationReport In INAPCS2: TermAttemptAuthorized 10 In EINAPV21: Join In INAPCS1P: CallInformationRequest In INAPCS2: Tbusy 11 In EINAPV21: Monitor In INAPCS1P: Playannouncement In INAPCS2: Tnoanswer 12 In EINAPV21: OpenSpecificFunction In INAPCS1P: PromptAndCollectUserInformation In INAPCS2: Tanswer 13 In EINAPV21: ProvideInstructions In INAPCS1P: SpecializedResourceReport In INAPCS2: Tdisconnect 14 In EINAPV21: ReleaseResource In INAPCS1P: ApplyChargingReport In INAPCS2: Omidcall 15 In EINAPV21: Reset Timer In INAPCS1P: Cancel In INAPCS2: Tmidcall 16 AssistRequestInstructions In CHINA INAP: AssistRequestInstructions In Siemens INAP: AssistRequestInstructions In EINAPV21: Retrieve Bit Position Opcode In INAPCS2: AssistRequestInstructions In INAPCS1P: AssistRequestInstructions 17 EstablishTemporaryConnection In CHINA INAP: EstablishTemporaryConnection In Siemens INAP: EstablishTemporaryConnection In EINAPV21: SCF Reset Indication In INAPCS2: EstablishTemporaryConnection In INAPCS1P: SendChargingInformation 18 DisconnectForwardConnection In CHINA INAP: DisconnectForwardConnection In EINAPV21: Split In Siemens INAP: DisconnectForwardConnection In INAPCS2: DisconnectForwardConnection In INAPCS1P: EventReportBcsm 19 ConnectToResource In CHINA INAP: ConnectToResource In EINAPV21: SSF Reset Indication In INAPCS2: ConnectToResource In INAPCS1P: RequestReportBcsmEvent 20 Connect In CHINA INAP: Connect In EINAPV21: Transfer Control In Siemens INAP: Connect In INAPCS2: Connect In INAPCS1P: EstablishTemporaryConnection 21 In EINAPV21: Update In INAPCS2: HoldCallInNetwork In INAPCS1P: ActivateServiceFiltering 22 ReleaseCall In CHINA INAP: ReleaseCall Bit Position Opcode In EINAPV21: Backward Information In Siemens INAP: ReleaseCall In INAPCS2: ReleaseCall In INAPCS1P: CollectInformation 23 RequestReportBCSMEvent In EINAPV21: Call Control In CHINA INAP: RequestReportBCSMEvent In Siemens INAP: RequestReportBCSMEvent In INAPCS2: RequestReportBCSMEvent In INAPCS1P: EventNotificationCharging 24 EventReportBCSM In CHINA INAP: EventReportBCSM In Siemens INAP: EventReportBCSM In INAPCS2: EventReportBCSM In INAPCS1P: InitiateCallAttempt 25 RequestNotificationChargingEvent In Siemens INAP: RequestNotificationChargingEvent In INAPCS2: RequestNotificationChargingEvent In INAPCS1P: ServiceFilteringResponse 26 EventNotificationCharging In INAPCS2: EventNotificationCharging In Siemens INAP: EventNotificationCharging In INAPCS1P: RequestNotificationChargingEvent 27 CollectInformation In CHINA INAP: CollectInformation In Siemens INAP: CollectInformation In INAPCS2: CollectInformation In INAPCS1P: DisconnectForwardConnection 28 In INAPCS2: AnalyseInformation In INAPCS1P: ActivityTest Bit Position Opcode 29 In INAPCS2: SelectRoute 30 In INAPCS2: SelectFacility 31 Continue In CHINA INAP: Continue In Siemens INAP: Continue In INAPCS2: Continue INAP - Operation Mask2 Bit Position Opcode 0 InitiateCallAttempt In CHINA INAP: InitiateCallAttempt In Siemens INAP: InitiateCallAttempt In INAPCS2P: InitiateCallAttempt In INAPCS1P: Retrive 1 ResetTimer In CHINA INAP: ResetTimer In Siemens INAP: ResetTimer In INAPCS2: ResetTimer In INAPCS1P: Update 2 FurnishChargingInformation In CHINA INAP: FurnishChargingInformation In Siemens INAP: FurnishChargingInformation In INAPCS2: FurnishChargingInformation In INAPCS1P: CallLimit 3 ApplyCharging In CHINA INAP: ApplyCharging In Siemens INAP: ApplyCharging In INAPCS2P: ApplyCharging In INAPCS1P: DialogueUserInformation Bit Position Opcode 4 ApplyChargingReport In CHINA INAP: ApplyChargingReport In Siemens INAP: ApplyChargingReport In INAPCS2: ApplyChargingReport In INAPCS1P: HandOver 5 In INAPCS2: RequestCurrentStatusReport In INAPCS1P: HoldCallPartyConnection 6 In INAPCS1P: Reconnect In INAPCS2: RequestEveryStatusChangeReport 7 In INAPCS1P: ReleaseCallPartyConnection In INAPCS2: RequestFirstStatusMatchReport 8 In INAPCS1P: SignallingInformation In INAPCS2: StatusReport 9 CallGap In CHINA INAP: CallGap In INAPCS2: CallGap In Siemens INAP: CallGap In INAP LW: Continue With Argument In INAPCS1P: Continue With Argument 10 ActivateServiceFiltering In CHINA INAP: ActivateServiceFiltering In Siemens INAP: ActivateServiceFiltering In INAPCS2: ActivateServiceFiltering 11 ServiceFilteringResponse In CHINA INAP: ServiceFilteringResponse In Siemens INAP: ServiceFilteringResponse In INAPCS2: ServiceFilteringResponse 12 CallInformationReport In CHINA INAP: CallInformationReport Bit Position Opcode In INAPCS2: CallInformationReport In Siemens INAP: CallInformationReport 13 CallInformationRequest In CHINA INAP: CallInformationRequest In INAPCS2: CallInformationRequest In Siemens INAP: CallInformationRequest 14 SendChargingInformation In CHINA INAP: SendChargingInformation In Siemens INAP: SendChargingInformation In INAPCS2: SendChargingInformation 15 PlayAnnouncement In CHINA INAP: PlayAnnouncement In INAPCS2: PlayAnnouncement In Siemens INAP: PlayAnnouncement 16 PromptAndCollectUserInformation In CHINA INAP: PromptAndCollectUserInformation In Siemens INAP: PromptAndCollectUserInformation In INAPCS2: PromptAndCollectUserInformation 17 SpecializedResourceReport In CHINA INAP: SpecializedResourceReport In Siemens INAP: SpecializedResourceReport In INAPCS2: SpecializedResourceReport 18 Unknown opcode 19 Unknown opcode 20 Unknown opcode 21 Cancel In CHINA INAP: Cancel In Siemens INAP: Cancel In INAPCS2: Cancel Bit Position Opcode 22 In INAPCS2: CancelStatusReportRequest 23 ActivityTest In CHINA INAP: ActivityTest In Siemens INAP: ActivityTest In INAPCS2: ActivityTest 24 In Siemens INAP: ContinueWithArgument 25 Unknown opcode 26 Unknown opcode 27 Unknown opcode 28 In Siemens INAP: InitialDpSms 29 In Siemens INAP: FurnishChargingInformationSms 30 In Siemens INAP: ConnectSms 31 In Siemens INAP: RequestReportSmsEvent INAP - Operation Mask3 Bit Position Opcode 0 In Siemens INAP: EventReportSms 1 In Siemens INAP: ContinueSms 2 In Siemens INAP: ReleaseSms 3 In Siemens INAP: ResetTimerSms 4 Unknown opcode 5 Unknown opcode 6 In Siemens INAP: ActivityTestGprs 7 In Siemens INAP: ApplyChargingGprs 8 In Siemens INAP: ApplyChargingReportGprs Bit Position Opcode 9 In Siemens INAP: CancelGprs 10 In Siemens INAP: ConnectGprs 11 In Siemens INAP: ContinueGprs 12 In Siemens INAP: EntityReleasedGprs 13 In Siemens INAP: FurnishChargingInformationGprs 14 In Siemens INAP: InitialDpGprs 15 In Siemens INAP: ReleaseGprs 16 In Siemens INAP: EventReportGprs In INAPCS2: FacilitySelectedAndAvailable 17 In Siemens INAP: RequestReportGprsEvent In INAPCS2: OriginationAttempt 18 In Siemens INAP: ResetTimerGprs In INAPCS2: TerminationAttempt 19 In Siemens INAP: SendChargingInformationGprs In INAPCS2: Oabandon 20 In INAPCS2: Osuspended 21 In INAPCS2: Tsuspended 22 In Siemens INAP: DisconnectForwardConnectionWithArgument In INAPCS2: DisconnectForwardConnectionWithArgument 23 In INAPCS2: AuthorizeTermination 24 In Siemens INAP: ContinueWithArgument In INAPCS2: ContinueWithArgument 25 In INAPCS2: CreateCallSegmentAssociation 26 In Siemens INAP: DisconnectLeg In INAPCS2: DisconnectLeg Bit Position Opcode 27 In Siemens INAP: MergeCallSegments In INAPCS2: MergeCallSegments 28 In INAPCS2: MoveCallSegments 29 In CHINA INAP: ALC Split In INAPCS2: MoveLeg 30 In INAPCS2: Reconnect 31 In Siemens INAP: SplitLeg In INAPCS2: SplitLeg INAP - Operation Mask4 Bit Position Opcode 0 In Siemens INAP: EntityReleased In INAPCS2: EntityReleased 1 In INAPCS2: ManageTriggerData 2 In CHINA INAP: ALC Join In Siemens INAP: ManageTriggerData In INAPCS2: RequestReportUtsi 3 In CHINA INAP: ALC Free In Siemens INAP: ReleaseLeg 4 In INAPCS2: SendStui 5 In INAPCS2: ReportUtsi 6 In INAPCS2: SendFacilityInformation 7 In INAPCS2: RequestReportFacilityEvent 8 In INAPCS2: EventReportFacility 9 Unknown opcode 10 In INAPCS2: SendComponent Bit Position Opcode 11 In INAPCS2: PromptAndReceiveMessage 12 In INAPCS2: ScriptInformation 13 In Siemens INAP: ScriptEvent In INAPCS2: ScriptEvent 14 In Siemens INAP: ScriptRun In INAPCS2: ScriptRun 15 In INAPCS2: ScriptClose 16 In INAPCS2: EstablishChargingRecord 17 In INAPCS2: HandlingInformationRequest 18 In INAPCS2: HandlingInformationResult 19 In INAPCS2: NetworkCapability 20 In INAPCS2: NotificationProvided 21 In INAPCS2: ConfirmedNotificationProvided 22 In INAPCS2: ProvideUserInformation 23 In INAPCS2: ConfirmedReportChargingInformation 24 In INAPCS2: ReportchargingInformation 25 In INAPCS2: RequestNotification 26 In INAPCS2: ActivationReceivedAndAuthorized 27 In INAPCS2: InitiateAssociation 28 In INAPCS2: AssociationReleaseRequested 29 In INAPCS2: ComponentReceived 30 In INAPCS2: ReleaseAssociation 31 In INAPCS2: RequestReportBcusmEvent INAP - Application Error Code It represents the error code of the procedure at INAP application layer. INAP - Additional Error Reason This field specifies the error reason for those INAP transactions having error carrying additional information. Code Text 0 unknown Operation 1 tooLate 2 operationNotCancellable 3 unknownRequestedInfo 4 requestedInfoNotAvailable 5 unavailableResources 6 componentFailure 7 basicCallProcessingException 8 resourceStatusFailure 9 endUserFailure 10 generic 11 unobtainable 12 congestion INAP - Response Cause Indicates the reason for the release at INAP Layer. Release cause of EventReportBCSM or CallInformationReport or ReleaseCall. In case INAP LW only ReleaseCall can fill this field. In EINAPV21 this field is filled from CauseIndicator of Event / Free message, whichever comes first in the sequence. In China Inap, ALCFree can also fill this field. In INAPCS2, this field is filled from DisconnectLeg, OAbandon, ODisconnect, ReleaseCall, TDisconnect, EventReportBCSM, CallGap, ActivateServiceFiltering, NotificationProvidedMsg messages. INAP - Destination Routing Address INAP - Event Type The BCSM DP event triggering the InitialDP or the SMSEvent triggering the InitialDPSMS or the GPRSEvent triggering the InitialDPGPRS. In order to interpret this field the field OperationCode has to be taken into account. In case of CAMEL Phase 1 and 2, the following table is a reference for SRS. Code Text 1 orig Attempt Authorized 2 collect Info 3 analysed Information 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer Code Text 16 TMidCall 17 TDisconnect 18 TAbandon 255 undefined field INAP - Reported Event Code Text 1 orig Attempt Authorized 2 Collected Info 3 analyzed Information or detached 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 11 pdp-ContextEstablishment 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect Code Text 18 TAbandon 19 oTermSeized 27 callAccepted 50 oChangeOfPosition 51 tChangeOfPosition 255 Undefined field INAP - Generic Number CSDR Type CSDR field Description INAP_CSDR GENERIC_NUMBER This field contains the Number information sent in either direction to enhance network operation or for supplementary services Common Measures Common Ð Success The success field is used in conjunction with each data record type to categorize a data record transaction as successful or not. CSDR Type = CAP Value Name Success Failure 1 CAP Mobile Originating Call See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 2 CAP Mobile Terminating Call See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 3 CAP Mobile Originating SMS See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 4 CAP Mobile Terminating SMS See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 5 CAP MS Initiated PDP Context Activation See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 6 CAP NW Initiated PDP Context Activation See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table Value Name Success Failure 99 Other CAP procedure See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table CAP Success Rule A CAP transaction is considered ""successful"" when no errors occurred at CAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( CAP_ER_CODE is Empty OR (CAP_ER_CODE is NOT Network Error AND CAP_ER_CODE is NOT User Error) ) AND ( CAP_ER_REASON is Empty OR (CAP_ER_REASON is NOT Network Error AND CAP_ER_REASON is NOT User Error) ) AND ( CAP_CAUSE is Empty OR (CAP_CAUSE is NOT Network Error AND CAP_CAUSE is NOT User Error) ) AND ( TCAP_ABORT_CAUSE is Empty OR (TCAP_ABORT_CAUSE is NOT Network Error AND TCAP_ABORT_CAUSE is NOT User Error) ) AND ( SCCP_RETCAUSE is Empty OR (SCCP_RETCAUSE is NOT Network Error AND SCCP_RETCAUSE is NOT User Error) ) CAP Failure Rule A CAP transaction is considered ""Failed"" when an error occurred at CAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (CAP_ER_CODE is Network Error OR CAP_ER_CODE is User Error) ) OR ( (CAP_ER_REASON is Network Error OR CAP_ER_REASON is User Error) ) OR ( (CAP_CAUSE is Network Error OR CAP_CAUSE is User Error) ) OR ( (TCAP_ABORT_CAUSE is Network Error OR TCAP_ABORT_CAUSE is User Error) ) OR ( (SCCP_RETCAUSE is Network Error OR SCCP_RETCAUSE is User Error) ) CSDR Type = MAP Value Name Success Failure 100 MAP Update Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 101 MAP Cancel Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 102 MAP Provide Roaming Number See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 103 MAP Register SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 104 MAP Erase SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 105 MAP Activate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table Value Name Success Failure 106 MAP Deactivate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 107 MAP Interrogate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 108 MAP Send Routing Info See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 109 MAP Update GPRS Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 110 MAP Send Routing Info For GPRS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 111 MAP Mobile Terminating SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 112 MAP Send Routing Info For SM See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 113 MAP Mobile Originating SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table Value Name Success Failure 114 MAP Authentication See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 115 MAP Process Unstructured SS Request See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 116 MAP Unstructured SS Request See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 117 MAP Unstructured SS Notify See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 118 MAP Send Routing Info For LCS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 119 MAP Subscriber Location Report See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 120 MAP Ð Correlated SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 199 Other MAP procedure See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table MAP Success Rule A MAP transaction is considered ""successful"" when no errors occurred at MAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( MAP_ SCCP_RETCAUSE is Empty OR (MAP_ SCCP_RETCAUSE is NOT Network Error AND MAP_ SCCP_RETCAUSE is NOT User Error) ) AND ( MAP_ TCAP_ABORT_CAUSE is Empty OR (MAP_ TCAP_ABORT_CAUSE is NOT Network Error AND MAP_ TCAP_ABORT_CAUSE is NOT User Error) ) AND ( MAP_ER_CODE is Empty OR (MAP_ ER_CODE is NOT Network Error AND MAP_ ER_CODE is NOT User Error) ) MAP Failure Rule A MAP transaction is considered ""Failed"" when an error occurred at MAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (MAP_ SCCP_RETCAUSE is Network Error OR MAP_ SCCP_RETCAUSE is User Error) ) OR ( (MAP_ TCAP_ABORT_CAUSE is Network Error OR MAP_ TCAP_ABORT_CAUSE is User Error) ) OR ( (MAP_ ER_CODE is Network Error OR MAP_ ER_CODE is User Error) ) CSDR Type = INAP Value Name Success Failure 200 INAP Initial DP See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table 201 INAP Retrieve/Assist Request Instructions See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table 299 Other INAP procedure See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table INAP Success Rule An INAP transaction is considered ""successful"" when no errors occurred at INAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( INAP_ER_CODE is Empty OR (INAP_ER_CODE is NOT Network Error AND INAP_ER_CODE is NOT User Error) ) AND ( INAP_ER_REASON is Empty OR (INAP_ER_REASON is NOT Network Error AND INAP_ER_REASON is NOT User Error) ) AND ( INAP_CAUSE is Empty OR (INAP_CAUSE is NOT Network Error AND INAP_CAUSE is NOT User Error) ) AND ( TCAP_ABORT_CAUSE is Empty OR (TCAP_ABORT_CAUSE is NOT Network Error AND TCAP_ABORT_CAUSE is NOT User Error) ) AND ( SCCP_RETCAUSE is Empty OR (SCCP_RETCAUSE is NOT Network Error AND SCCP_RETCAUSE is NOT User Error) ) INAP Failure Rule An INAP transaction is considered ""Failed"" when an error occurred at INAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (INAP_ER_CODE is Network Error OR INAP_ER_CODE is User Error) ) OR ( (INAP_ER_REASON is Network Error OR INAP_ER_REASON is User Error) ) OR ( (INAP_CAUSE is Network Error OR INAP_CAUSE is User Error) ) OR ( (TCAP_ABORT_CAUSE is Network Error OR TCAP_ABORT_CAUSE is User Error) ) OR ( (SCCP_RETCAUSE is Network Error OR SCCP_RETCAUSE is User Error) ) CSDR Type = TCAP-AP Value Name Success Failure 300 TCAP-AP traffic TCAPAP_APPL_ERROR_CODE is NOT Network Error OR is EMPTY TCAPAP_APPL_ERROR_CODE is Network Error CSDR Type = BELL TCAP-OP Value Name Success Failure 400 TCAP OP Query (CNAM Service) (OP_ERROR_CODE is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) OP_ERROR_CODE is Network Error OR BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL TCAP-800 Value Name Success Failure 500 TCAP 800 Query (Toll Free Call) (ERROR_CODE_800 is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) ERROR_CODE_800 is Network Error OR BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL TCAP-800 Value Name Success Failure 600 AIN Query (ER_CODE is NOT Network Error OR is EMPTY) AND ER_CODE is Network Error OR Value Name Success Failure (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL LIDB Value Name Success Failure 700 LIDB Query (LIDB_ERROR_CODE is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) LIDB_ERROR_CODE is Network Error OR BTCAP_REJECT_PROBLEM is Network Error Common - Transaction Duration This field holds the time difference between the first and last message in the sequence (in units of milliseconds). This means that, in case of timeout sequences, the timer value will not be included in TransactionTime calculation. Common - Response Time Time in millisecond from the first invoke operation to the next operation in the other direction in case of full sequences. Common Ð Conversation Time It represents the total talk time for a MO/MT call (CAP/INAP layers). Common - Total Length of SCCP Messages It is the total length of SCCP messages in forward and backward direction. Common - Length of SCCP FWD Messages It is the total length of SCCP messages in forward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Length of SCCP BWD Messages It is the total length of SCCP messages in backward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Number of SCCP Messages It is the total number of SCCP messages in forward and backward direction. Common - Number of SCCP FWD Messages It is the total number of SCCP messages in forward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Number of SCCP BWD Messages It is the total number of SCCP messages in backward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP message to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common Ð Answered Call Applicable protocol: CAP, INAP This flag indicates if a call is either answe or not for CAP and INAP protocols. Common Ð Dropped Call Applicable protocol: CAP, INAP This flag indicates if a call is either dropped or not for CAP and INAP protocols. Note: a call can be considered droppped only when it is answered. MAP Measures MAP - SMS Payload Size This field contains the length of TP-UDL in octets from SM-RP-UI parameter. MAP Ð Number of MO SMS This field contains the number of SMS submitted by the subscriber. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP Ð MO SMS Success This field indicates if the MO SMS was successfully submitted to the service centre. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP - Number of MT SMS This field counts the number of MT SMS delivered by the service centre. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP Ð MT SMS Success This field indicates if the MT SMS was successfully delivered to the final user. Note: MT SMS status report are not included in this measure, for those transactions use instead the Data Record Type 111 and Common- Success. MAP - Number of Concatenated SMS The number of concatenated SMS is calculated according to the last 5 bits of [MAP].FLAGS2 CSDR field converted in decimal. 16,17,18,19,20 Concatenated SMS Count 0 - No SMS 1 - SMS not concatenated 2 - 2 Concatenated SMS 3 - 3 Concatenated SMS 4 - 4 Concatenated SMS 5 - 5 Concatenated SMS 6 - 6 Concatenated SMS 7 - 7 Concatenated SMS 8 - 8 Concatenated SMS 9 - 9 Concatenated SMS 10 - 10 Concatenated SMS 11 - 11 Concatenated SMS 12 - 12 Concatenated SMS 13 Ð 13 Concatenated SMS 14 - 14 Concatenated SMS 15 - 15 Concatenated SMS 16 - 16 Concatenated SMS 17 - 17 Concatenated SMS 18 - 18 Concatenated SMS 19 - 19 Concatenated SMS 20 - 20 Concatenated SMS 21 - 21 Concatenated SMS 22 - 22 Concatenated SMS 23 - 23 Concatenated SMS 24 - 24 Concatenated SMS 25 - 25 Concatenated SMS 26 - 26 Concatenated SMS 27 - 27 Concatenated SMS 28 - 28 Concatenated SMS 29 - 29 Concatenated SMS 30 - 30 Concatenated SMS 31 - 31 or more concatenated SMS Description: This subfield represents the number of short messages in Long SMS which is filled from IE Maximum number of Short message. This value might differ from Number of MO SMS messages, Number of MT SMS messages CSDR fields. As the ÔMaximum number of Short messageÕ IE represents the total number of expected SM in entire sequence (and is same in all subsequent messages in sequence), the number will be accurate even when messages are missing in Sequence due to loadsharing. No additional computing at QXTS/QXDRS is required for this field. MAP Ð SMS Submit Time This field specifies the time needed to submit an SMS and it is calculated as the MAP transaction duration needed to forward the MO SMS to the Service Centre. MAP Ð SMS Delivery Time This field specifies the time needed to deliver the SMS and it is calculated as the time difference between ÒEnd Time Stamp Ð TP Service Centre TimeStampÓ in milliseconds 4 MCLS Enrichments for eoLive Cell MC table: Cell (Miner=YES) Lookup Type: Match Lookup DR Key MCLS Key Enriched description prefix CAP_CELL_IDENTITY Cell-ID CAP Ð Cell Identity Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Cell Name WITHRANK NO YES Type Type ALWAYS YES YES Group Cell Group ALWAYS NO YES Paging Domain Paging Domain ALWAYS NO YES Paging Area Code Paging Domain Code WITHRANK NO YES PLMN PLMN ID ALWAYS NO YES Radio Controller Node ID Radio Node ID WITHRANK NO NO Radio Controller Node Name Radio Node Name WITHRANK NO YES Core Node ID Controlling Node ID WITHRANK NO NO Core Node Name Controlling Node Name WITHRANK NO YES Core Pool Name Core Network Node Pool ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Latitude Latitude WITHRANK NO YES Longitude Longitude WITHRANK NO YES Broadcast Power Broadcast Power WITHRANK NO YES Azimuth Azimuth WITHRANK NO YES Beam Width Beam Width WITHRANK NO YES Frequency Bands Frequency Bands ALWAYS NO YES Region Region ALWAYS NO YES Manufacturer Manufacturer ALWAYS NO YES Operational Status Operational Status ALWAYS NO YES City City ALWAYS NO YES Province Province ALWAYS NO YES ZIP Code ZIP Code ALWAYS NO YES LAC LAC WITHRANK NO NO SAC SAC WITHRANK NO NO Note: Manufacturer, Operational Status, City, Province and ZIP Code are available only from MasterClaw 8.0. The miner functions (implemented either by MCLS or by DWH) will fill the following columns: á Name: It will be filled by CAP_CELL_IDENTITY á Paging Domain: It will be filled by [CAP].LOCATION_AREA_ID CSDR field Service Key MC table: ServiceKey (Miner=NO) Lookup Type: Match Key MCLS Key Enriched description prefix SERVICE_KEY Service_Key Common - Service Standard Formatting: Display Name Internal Name Aggregation Rank Enum Visible for Application (eoLive/BO) Name Name ALWAYS NO NO Group Group ALWAYS NO NO Layer Layer ALWAYS NO NO Cause MC table: Cause (Miner=NO) Lookup Type: Match Lookup DR Key MCLS Key Enriched description prefix ÒSCCP_RET_CAUSE: Ó + SCCP_RETCAUSE ID Common - SCCP Return Cause ÒTCAP: Ó + TCAP_ABORT_CAUSE Common - TCAP Abort Cause ÒTCAP_APPL: Ò + TCAPAP_APPL_ERROR_CODE TCAP AP - Application Error Code ÒBELL_TCAP_APPL: Ò + BTCAP_APPL_ERROR_CODE BELL TCAP - Application Error Code ÒBELL_TCAP_REJ: Ò + BTCAP_REJECT_PROBLEM BELL TCAP Ð Reject Problem ÒBELL_TCAP_800: Ò + BTCAP_TCAP_800_TERMINATION_INDICATOR BELL TCAP Ð TCAP 800 Termination Indication ÒBELL_TCAP_AIN: Ò + BTCAP_AINT_ERROR_CAUSE BELL TCAP - AIN Error Cause ÒMAP: Ò + MAP_FL_ER_CODE MAP - First Leg Application Error Code ÒMAP_USER_ERR: Ò + MAP_FL_USRERR_REASON MAP Ð First Leg Additional Error Reason ÒMAP: Ò + MAP_LL_ER_CODE MAP - Last Leg Application Error Code ÒMAP_USER_ERR: Ò + MAP_LL_USRERR_REASON MAP Ð Last Leg Additional Error Reason ÒCAP: Ò + CAP_ER_CODE CAP - Application Error Code ÒINAP_CAP_ADD_ERR: Ò + CAP_ER_REASON CAP - Additional Error Reason ÒQ.931: Ò + CAP_CAUSE CAP - Response Cause ÒQ.931: Ò + CAP_EVENT_REPORT_CAUSE CAP - Event Report Cause ÒINAP: Ò + INAP_ER_CODE INAP - Application Error Code ÒINAP_CAP_ADD_ERR: Ò + INAP_ER_REASON INAP - Additional Error Reason ÒQ.931: Ò + INAP_CAUSE INAP - Response Cause Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Type Type ALWAYS YES YES Code Code ALWAYS YES NO Description Name NEVER NO NO Group Group ALWAYS NO YES is Network Error NetworkError ALWAYS YES YES is User Error UserError ALWAYS YES YES Next Best Action Next best action NO is Drop Error DropError ALWAYS YES YES OperatorE212 MC Table: OperatorE212 (Miner= NO) Lookup Type: Prefix (for IMSI), Match (for PLMN_ID) DR Lookup Key MCLS Key Enriched description prefix IMSI Prefix Common Ð Subscriber PLMN_ID Common Ð PLMN ID Remember: All enriched fields of PLMN_ID must be NOT visible on eoLive/eoFinder Applications. ONLY the enriched field ÒCommon Ð PLMN ID Operator is HomeÓ is visible in eoLive/eoFinder Applications, because it is used in eoxdr component for the eoRoaming-CP-Core-SDR generation."
"Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Prefix Prefix ALWAYS NO YES Operator Name Name ALWAYS NO YES Operator Country Name Country ALWAYS NO YES Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES Operator MCC MCC ALWAYS NO YES Operator MNC MNC ALWAYS NO YES Operator Country Code CC ALWAYS NO NO (visible only in eoSight/InSight) Device MC Table: Device (Miner=ON) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix TAC TAC Common - Device Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Manufacturer Manufacturer ALWAYS NO YES Model Model WITH RANK NO YES Terminal Type Terminal Type ALWAYS YES YES OS Vendor OS Vendor ALWAYS NO YES OS Type OS Type ALWAYS YES YES OS Version OS Version ALWAYS NO YES GSM GSM ALWAYS YES YES UMTS UMTS ALWAYS YES YES LTE LTE ALWAYS YES YES Frequency Bands Frequency Bands ALWAYS NO NO Display Size Primary Display Size ALWAYS NO YES Group Group ALWAYS NO YES Test Group Test Group ALWAYS NO YES Make and Model MakeAndModel WITH RANK NO YES CertifiedDevice MC Table: CertifiedDevice (Miner = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix IMEI IMEI Common Ð Certified Device Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) TAC TAC WITH RANK NO NO Serial Number Serial Number ALWAYS NO NO Software Version Software Version ALWAYS NO YES is Subsidized Subsidized ALWAYS YES YES is Certified Certified ALWAYS YES YES MobileSubscriber MC Table: MobileSubscriber (Miner = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix IMSI IMSI Common - Subscriber Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Name WITH FILTER NO YES Gender Gender ALWAYS YES YES Birth Date Birth Date WITH RANK NO YES Birth Place Birth Place WITH RANK NO YES Home Place Home Place WITH RANK NO YES Subscription Start Date Subscription start date WITH RANK NO YES Type Type ALWAYS YES YES Importance Importance ALWAYS YES YES Enterprise Name Enterprise name WITH RANK NO YES Department Name Enterprise part WITH RANK NO YES Plan Plan ALWAYS NO YES Options Options WITH RANK NO YES Notes Notes WITH RANK NO YES Tariff Tariff Plan ALWAYS YES YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Service Segment Service Segment ALWAYS YES YES Enterprise Importance Enterprise Importance ALWAYS YES YES Department Importance Enterprise part Importance ALWAYS YES YES Enterprice Description Enterprice Description NEVER NO NO Enterprice Part Description Enterprice part Description NEVER NO NO FixedSubscriber MC Table: FixedSubscriber (MINER = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix CALLING_PARTY ISDN Common - Calling Party CALLED_PARTY Common - Called Party MSISDN Common - User Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Name WITH FILTER NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Gender Gender ALWAYS YES YES Birth Date Birth Date WITH RANK NO YES Birth Place Birth Place WITH RANK NO YES Home Place Home Place WITH RANK NO YES Subscription Start Date Subscription start date WITH RANK NO YES Type Type ALWAYS YES YES Importance Importance ALWAYS YES YES Enterprise Name Enterprise name WITH RANK NO YES Department Name Enterprise part WITH RANK NO YES Plan Plan ALWAYS NO YES Options Options WITH RANK NO YES Notes Notes WITH RANK NO YES Tariff Tariff Plan ALWAYS YES YES Service Segment Service Segment ALWAYS YES YES Enterprise Importance Enterprise Importance ALWAYS YES YES Department Importance Enterprise part Importance ALWAYS YES YES Enterprice Description Enterprice Description NEVER NO NO Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Enterprice Part Description Enterprice part Description NEVER NO NO Operator Prefix MC Table: OperatorPrefix (MINER = NO) Lookup type: Prefix Key MCLS Key Enriched description prefix CALLING_NO Prefix Common - Calling Party CALLED_NO Common - Called Party MAP_MSRN MAP Ð MSRN MSISDN Common Ð MSISDN SCCP_CALLED_PARTY Common - SCCP Called Party Global Title SCCP_CALLING_PARTY Common - SCCP Calling Party Global Title MAP_SERVCENT_ADDR MAP - Service Centre Address LOCATION_INFO Common Ð Network Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Prefix Prefix ALWAYS NO YES Operator Name Name ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Country Name Country ALWAYS NO YES Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES Operator Country Code CC ALWAYS NO NO Operator National Destination Code NDC ALWAYS NO NO IMSIPrefix MC Table: IMSIPrefix (Miner = NO) Lookup type: Prefix Lookup DR Key MCLS Key Enriched description prefix IMSI Prefix Common - Subscriber Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Prefix ALWAYS NO YES Prefix Name Name ALWAYS NO YES Prefix Description Description NEVER NO YES Prefix Group Group ALWAYS NO YES Prefix Group 2 Group2 ALWAYS NO YES ISDNPrefix MCLS table: ISDNPrefix (Miner = NO) Lookup type=Prefix Lookup DR Key MCLS Key Enriched description prefix CALLING_NO Prefix Common - Calling Party CALLED_NO Common - Called Party INAP_GENERIC_NUMBER INAP - Generic Number Standard Formatting: Display Name Internal Name eolive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Prefix ALWAYS NO YES Display Name Internal Name eolive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Name Name ALWAYS NO YES Prefix Description Description NEVER NO YES Prefix Group Group ALWAYS NO YES Prefix Group 2 Group2 ALWAYS NO YES Operator Signalling Point MCLS table: OperatorSP (Miner = NO) Lookup type=Match DR Lookup Key MCLS Key Enriched description prefix SOURCE_SP SP Name Common - First Leg Source Signalling Point DEST_SP Common Ð First Leg Destination Signalling Point LL_SOURCE_SP Common Ð Last Leg Source Signalling Point LL_DEST_SP Common Ð Last Leg Destination Signalling Point SCCP_CALLING_SP Common Ð SCCP Calling Party Number Signalling Point SCCP_CALLED_SP Common Ð SCCP Called Party Number Signalling Point Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Name Name ALWAYS NO YES Operator Country Name Country ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES 5 Monitored procedures This table contains a list of procedures supported by the TDR format. It shall be considered as example. Procedure/Activity CSDR Failure/Success Additional Info Mobile Originating Call CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country, IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, Call Duration, CAP Operation Code, Event Type, Reported Event, Destination Address, Location Information, TAC Mobile Terminating Call CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, Call Duration, CAP Operation Code, Event Type, Reported Event, Destination Address, Location Information, TAC Mobile Originating SMS CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, CAP Operation Code, Event Type, Reported Event, Location Information, TAC Mobile Terminating SMS CAP Event Report Cause / CAP Application Error Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, CAP Operation Code, Event Type, Reported Event, Location Information, TAC MS Initiated PDP Context Activation CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, CAP Operation Code, Event Type, Reported Event,TAC NW Initiated PDP Context Activation CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, CAP Operation Code, Event Type, Reported Event, TAC Update Location MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Cancel Location MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Procedure/Activity CSDR Failure/Success Additional Info Code, Location Information Provide Roaming Number MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Register SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Erase SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Activate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Deactivate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Interrogate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, SS Code Set, MAP Operation Code Send Routing Info MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Update GPRS Location MAP MAP Application Error Code/Additional MAP Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Error Reason/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Send Routing Info For GPRS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Mobile Terminating SMS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Send Routing Info For SM MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code Mobile Originating SMS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Authentication MAP MAP Application Error Code/Additional MAP Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Error Reason/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Process Unstructured SS Request MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Unstructured SS Request MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Unstructured SS Notify MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI,MAP Timeout, Back Calling Number, MAP Operation Code Send Routing Info For LCS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Subscriber Location Report MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code,TAC 6 Appendix A. Property field definition Binary Formats The binary format may assume one of the followings values: Format Description BF_INTEGER Integer value. The size column specifies the integer type: 1 = byte 2 = word 4 = dword 8 = qword BF_BYTES Bytes The size column specifies the number of bytes. BF_STRING String of characters. The size column specifies the max length. BF_FLOATING Floating. The size is ignored. Display Format The display format may assume one of the following formats: Format Description DF_DIGIT It identifies a BCD number DF_STRING The value is displayed as a sequence of Latin-1 characters. DF_ENUM Only the description associated to the value is displayed, e.g.: Test Call Format Description DF_DEC_ENUM Both value, as decimal number, and description are displayed, e.g.: 13 Test Call DF_HEX_ENUM Both value, as hexadecimal number, and description are displayed, e.g.: C4 nTUP DF_ABSOLUTE_TIME The field is a date shown as: ""yyyy-MM-dd HH:mm:ss"". DF_RELATIVE_TIME The field is a date shown as: ""HH:mm:ss.SSS"". DF_BINARY_ENUM The field is displayed in binary form. DF_POINT_CODE The fiels is a point code, e.g: 2-112-0 Broendby DF_CIC The field is a CIC, eg: 127-31 DF_DEC The field is displayed as a decimal value. DF_HEX The field is displayed as a hexadecimal value. DF_IP The field is displayed as an IP address (either IPv4 or IPv6) according to [RFC2373]. DF_FIXEDPOINT The field is a floating number, e.g.: 3.69 DF_BOOLEAN The field is a Boolean, e.g. 0 False DF_FULLYQUALIFIED_POINT_CODE The fiels is a point code, e.g: 2-112-0 Broendby Text Format The text format (used only when DR are generated in csv format) may assume one of the following formats: Format Description DF_STRING DF_DEC DF_HEX Special Property The special property may assume one of the following formats: Special Property Description SP_SUBSCRIBER_MARKER The field represents a Subscriber identifier. SP_START_TIME The field represents the start time of a dialogue/trail. SP_END_TIME The field represents the end time of a dialogue/trail. SP_IMSI The field represents an IMSI. SP_MSISDN The field represents a MSISDN. SP_SOURCE_ADDRESS The field represents an originating address, e.g. Originating Point Code or Source IP Address. SP_DESTINATION_ADDRESS The field represents a destination address, e.g. Destination Point Code or Destination IP Address. SP_OTHER_ADDRESS The field represents an address that cannot be categorized as Source or Destination. SP_GLOBALTITLE The field represents a Global Title, e.g. SCCP Calling Numer. SP_CALLTRACEJUMP The field represent an ID used by the client application to jump to CSDR and PDU details. Aggregation Roles The aggregation role of a field could be: Role Description AR_AGGREGABLE_ALWAYS The field can always be aggregated. AR_AGGREGABLE_WITHFILTER The field can be aggregated only if the eoLive User impose filter on this field to reduce the number of different values. AR_AGGREGABLE_NEVER The field can never be used in aggregation. AR_AGGREGABLE_WITHRANK The field can be used in aggregation but only in presence of rank operation (e.g. Top). 3GPP TS 23.078 V17.0.0 (2022-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; Stage 2 (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. Keywords UMTS, GSM, CAMEL, stage 2, network 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2020, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved."
"UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 19 1 Scope 20 1.1 Support of partial implementation of CAMEL phaseÊ4 21 1.1.1 CAMEL PhaseÊ4 CSIs 21 1.1.2 CAMEL PhaseÊ4 Functionalities 21 2 References 23 3 Definitions and abbreviations 26 3.1 Definitions 26 3.2 Abbreviations 28 4 Circuit switched Call Control 30 4.1 Architecture 30 4.1.1 Functional Entities used for CAMEL 30 4.1.2 Interfaces defined for CAMEL 31 4.1.2.1 HLR - VLR interface 31 4.1.2.2 GMSC - HLR interface 31 4.1.2.3 GMSC - gsmSSF interface 31 4.1.2.4 gsmSSF - gsmSCF interface 31 4.1.2.5 MSC - gsmSSF interface 31 4.1.2.6 gsmSCF - HLR interface 31 4.1.2.7 gsmSCF - gsmSRF interface 31 4.1.2.8 GMSC - MSC interface 31 4.2 Detection Points (DPs) 32 4.2.1 Definition and description 32 4.2.1.1 Arming/disarming mechanism 32 4.2.1.2 Criteria 33 4.2.1.2.1 Criteria at DPÊCollected_Info 33 4.2.1.2.2 Criteria at DPÊAnalysed_Information 34 4.2.1.2.3 Criteria at DPÊRoute_Select_Failure 36 4.2.1.2.4 Criteria at DPÊTerminating_Attempt_Authorised 36 4.2.1.2.5 Criteria at DPÊT_Busy and T_No_Answer 37 4.2.1.3 Relationship 37 4.2.2 DP processing rules 38 4.3 Description of CAMEL Subscriber Data 38 4.3.1 Originating CAMEL Subscription Information (O CSI) 38 4.3.1.1 TDP List 38 4.3.1.2 gsmSCF address 38 4.3.1.3 Service Key 38 4.3.1.4 Default Call Handling 38 4.3.1.5 DP criteria 38 4.3.1.6 CAMEL Capability Handling 39 4.3.1.7 CSI state 39 4.3.1.8 Notification flag 39 4.3.2 Dialled Service CAMEL Subscription Information (D CSI) 39 4.3.2.1 DP criteria 39 4.3.2.2 gsmSCF address 39 4.3.2.3 Service Key 39 4.3.2.4 Default Call Handling 39 4.3.2.5 CAMEL Capability Handling 39 4.3.2.6 CSI state 39 4.3.2.7 Notification flag 40 4.3.3 Network CAMEL Service Information (N CSI) 40 4.3.4 Translation Information Flag CAMEL Subscription Information (TIF CSI) 40 4.3.4.1 Translation Information Flag 40 4.3.4.2 Notification flag 40 4.3.5 Terminating CAMEL Subscription Information (in the GMSC) (T CSI) 40 4.3.5.1 TDP List 40 4.3.5.2 gsmSCF address 40 4.3.5.3 Service Key 40 4.3.5.4 Default Call Handling 40 4.3.5.5 DP criteria 41 4.3.5.6 CAMEL Capability Handling 41 4.3.5.7 CSI state 41 4.3.5.8 Notification flag 41 4.3.6 VMSC Terminating CAMEL Subscription Information (VT CSI) 41 4.3.6.1 TDP List 41 4.3.6.2 gsmSCF address 41 4.3.6.3 Service Key 41 4.3.6.4 Default Call Handling 41 4.3.6.5 DP criteria 41 4.3.6.6 CAMEL Capability Handling 41 4.3.6.7 CSI state 42 4.3.6.8 Notification flag 42 4.3.7 Other CAMEL data 42 4.3.7.1 Location information/Subscriber state Interrogation 42 4.3.7.2 gsmSCF address list for CSI 42 4.3.8 Trunk Originated CAMEL Service Information (TO-CSI) 42 4.4 Description of CAMEL BCSMs 43 4.4.1 General Handling 43 4.4.2 Originating Basic Call State Model (O BCSM) 43 4.4.2.1 Description of O BCSM 43 4.4.2.1.1 Description of the call model (PICs) 45 4.4.3 Terminating Basic Call State Model (T BCSM) 49 4.4.3.1 Description of T BCSM 49 4.4.3.1.1 Description of the call model (PICs) 50 4.4.4 Rules for Implicit Disarming of Event Detection Points 53 4.4.5 BCSM Modelling of Call Scenarios 55 4.4.5.1 Mobile Originated Call 55 4.4.5.2 Mobile Terminated Call at the GMSC or VMSC 55 4.4.5.3 Call Forwarding at the GMSC or VMSC 56 4.4.5.4 gsmSCF Initiated Call 57 4.4.5.5 Trunk Originated Call 57 4.4.6 Leg Handling 58 4.4.6.1 Leg is created 58 4.4.6.2 Leg continues to exist 58 4.4.6.3 Leg is released 59 4.4.6.4 Leg is moved 59 4.5 Procedures for CAMEL 59 4.5.1 Overall SDL architecture 59 4.5.2 Handling of mobile originated calls 65 4.5.2.1 Handling of mobile originated calls in the originating MSC 65 4.5.2.1.1 Actions of the MSC on receipt of Int_Error 66 4.5.2.1.2 Actions of the MSC on receipt of Int_Continue 66 4.5.2.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument 66 4.5.2.1.4 Actions of the MSC on receipt of Int_Connect 66 4.5.2.1.5 Actions of the MSC on receipt of Int_Release_Call 67 4.5.2.1.6 Actions of the MSC on receipt of Int_Disconnect_Leg (Leg 2) 67 4.5.2.1.7 Actions of the MSC on receipt of Int_Apply_Warning_Tone 67 4.5.2.1.8 Action of the MSC in procedure CAMEL_OCH_MSC_ANSWER 67 4.5.2.1.9 Action of the MSC in procedure CAMEL_OCH_ETC 68 4.5.2.1.10 Procedure CAMEL_OCH_LEG1_MSC 68 4.5.2.1.11 Process CAMEL_O_CHANGE_OF_POSITION_MSC 68 4.5.2.1.12 Procedure CAMEL_Start_TNRy 68 4.5.2.2 Handling of mobile originating calls in the originating VLR 148 4.5.3 Retrieval of routeing information 151 4.5.3.1 Retrieval of routeing information in the GMSC 151 4.5.3.1.1 Action of the GMSC on receipt of Int_Release_Call 151 4.5.3.1.2 Action of the GMSC on receipt of Int_Error 151 4.5.3.1.3 Action of the GMSC on receipt of Int_Continue 152 4.5.3.1.4 Action of the GMSC on receipt of Int_Continue_With_Argument 152 4.5.3.1.5 Action of the GMSC on receipt of Int_Connect 152 4.5.3.1.6 Action of the GMSC on receipt of Send_Routeing_Info Negative Response (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.7 Action of the GMSC on receipt of Send_Routeing_Info ack with MSRN (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.8 Action of the GMSC on receipt of Send_Routeing_Info ack with FTN (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.9 Action of the GMSC on receipt of Send_Routeing_Info ack with O CSI and/or D CSI and FTN (at state Wait_For_Routeing_Info_2) 153 4.5.3.1.10 Action of the GMSC in procedure CAMEL_MT_ETC 153 4.5.3.1.11 Action of the GMSC in procedure CAMEL_MT_GMSC_Notify_CF 153 4.5.3.1.12 Action of the MSC on receipt of Int_Disconnect_Leg (Leg 2) 153 4.5.3.2 Retrieval of routeing information in the HLR 207 4.5.3.3 Handling of provide roaming number request in the VLR 215 4.5.4 Handling of mobile terminating calls 217 4.5.4.1 Handling of mobile terminating calls in the terminating VMSC 217 4.5.4.1.1 Action of the VMSC in procedure CAMEL_MT_VMSC_Notify_CF 217 4.5.4.1.2 Action of MSC on receipt of Int_Disconnect_Leg (Leg 2) 217 4.5.4.1.3 Procedure CAMEL_ICH_LEG2_MSC 218 4.5.4.1.4 Process CAMEL_T_CHANGE_OF_POSITION_MSC 218 4.5.4.2 Handling of mobile terminating calls in the VLR 255 4.5.5 Handling of forwarded calls 257 4.5.5.1 Procedure CAMEL_CF_MSC_INIT: handling of Int_Continue_With_Argument 257 4.5.5.2 Procedure CAMEL_CF_MSC_INIT: handling of Int_Connect 257 4.5.5.3 Procedure CAMEL_CF_MSC_INIT: handling of Int_Disconnect_Leg (Leg 2) 257 4.5.5.4 Action of the MSC in procedure CAMEL_CF_MSC_ANSWER 257 4.5.5.5 Action of the MSC in procedure CAMEL_CF_ETC 258 4.5.6 Handling of gsmSCF initiated calls 304 4.5.6.1 Handling of gsmSCF initiated calls in the MSC 304 4.5.6.1.1 Actions of the MSC on receipt of Int_Error 304 4.5.6.1.2 Actions of the MSC on receipt of Int_Continue 304 4.5.6.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument 304 4.5.6.1.4 Actions of the MSC on receipt of Int_Disconnect_Leg 304 4.5.6.1.5 Actions of the MSC on receipt of Int_Release_Call 304 4.5.6.2 Handling of gsmSCF initiated calls in the VLR 323 4.5.7 Handling of mobile calls in the gsmSSF 326 4.5.7.1 Call duration control 326 4.5.7.1.1 Information flow for call duration control 326 4.5.7.1.2 Audible indicators for call duration control 329 4.5.7.2 The gsmSCF control of e values 329 4.5.7.2.1 Procedure Handle_SCI 329 4.5.7.2.2 Process Tsw_For_SCI 330 4.5.7.3 Behaviour of the gsmSSF in the process CS_gsmSSF 333 4.5.7.3.1 Actions of the gsmSSF on receipt of CAP_Request_Report_BCSM_Event (in the state Waiting_For_Instructions) 333 4.5.7.3.2 Actions of the gsmSSF on receipt of CAP_Continue (in the state Waiting_For_Instructions) 333 4.5.7.3.3 Actions of the gsmSSF on receipt of CAP_Release_Call (in the state Monitoring) 333 4.5.7.3.4 Actions of the gsmSSF on receipt of Int_DP_T_Busy or Int_DP_T_No_Answer including the parameter Call Forwarded (in the state Monitoring) 333 4.5.7.4 Outstanding Request Counter and Rules for CAMEL 333 4.5.7.5 Process CS_gsmSSF and procedures 334 4.5.7.6 Process gsmSSF_SSME_FSM and procedures 412 4.5.7.7 Process CSA_gsmSSF and procedures 416 4.5.8 Assisting case 440 4.5.9 Procedure CAMEL_Provide_Subscriber_Info 450 4.5.10 CAMEL specific handling of location updating and data restoration 453 4.5.11 Cross phase compatibility 453 4.5.12 Handling of North American Carrier Information 453 4.5.13 Handling of trunk originated calls 453 4.5.13.1 Procedure CAMEL_TOC_Dialled_Services 454 4.5.13.2 Procedure CAMEL_TOC_MSC_INIT 454 4.5.13.3 Procedure CAMEL_NDS_TOC_INIT 454 4.5.13.4 Procedure CAMEL_TOC_LEG1_MSC 454 4.6 Description of information flows 474 4.6.1 gsmSSF to gsmSCF information flows 475 4.6.1.1 Activity Test ack 475 4.6.1.1.1 Description 475 4.6.1.1.2 Information Elements 475 4.6.1.2 Apply Charging Report 475 4.6.1.2.1 Description 475 4.6.1.2.2 Information Elements 475 4.6.1.3 Call Information Report 476 4.6.1.3.1 Description 476 4.6.1.3.2 Information Elements 476 4.6.1.4 Disconnect Leg ack 477 4.6.1.4.1 Description 477 4.6.1.4.2 Information Elements 477 4.6.1.5 Entity Released 477 4.6.1.5.1 Description 477 4.6.1.5.2 Information Elements 477 4.6.1.6 Event Report BCSM 477 4.6.1.6.1 Description 477 4.6.1.6.2 Information Elements 477 4.6.1.7 Initiate Call Attempt ack 481 4.6.1.7.1 Description 481 4.6.1.7.2 Information Elements 481 4.6.1.8 Initial DP 482 4.6.1.8.1 Description 482 4.6.1.8.2 Information Elements 482 4.6.1.9 Move Leg ack 488 4.6.1.9.1 Description 488 4.6.1.9.2 Information Elements 488 4.6.1.10 Split Leg ack 488 4.6.1.10.1 Description 488 4.6.1.10.2 Information Elements 488 4.6.2 gsmSCF to gsmSSF information flows 488 4.6.2.1 Activity Test 488 4.6.2.1.1 Description 488 4.6.2.1.2 Information Elements 488 4.6.2.2 Apply Charging 488 4.6.2.2.1 Description 488 4.6.2.2.2 Information Elements 489 4.6.2.3 Call Gap 490 4.6.2.3.1 Description 490 4.6.2.3.2 Information Elements 490 4.6.2.4 Call Information Request 492 4.6.2.4.1 Description 492 4.6.2.4.2 Information Elements 492 4.6.2.5 Cancel 492 4.6.2.5.1 Description 492 4.6.2.5.2 Information Elements 492 4.6.2.5A Collect Information 493 4.6.2.5A.1 Description 493 4.6.2.5A.2 Information Elements 493 4.6.2.6 Connect 493 4.6.2.6.1 Description 493 4.6.2.6.2 Information Elements 493 4.6.2.7 Connect To Resource 495 4.6.2.7.1 Description 495 4.6.2.7.2 Information Elements 495 4.6.2.8 Continue 496 4.6.2.8.1 Description 496 4.6.2.8.2 Information Elements 496 4.6.2.9 Continue With Argument 496 4.6.2.9.1 Description 496 4.6.2.9.2 Information Elements 497 4.6.2.10 Disconnect Forward Connection 498 4.6.2.10.1 Description 498 4.6.2.10.2 Information Elements 498 4.6.2.11 Disconnect Forward Connection With Argument 499 4.6.2.11.1 Description 499 4.6.2.11.2 Information Elements 499 4.6.2.12 Disconnect Leg 499 4.6.2.12.1 Description 499 4.6.2.12.2 Information Elements 499 4.6.2.13 Establish Temporary Connection 499 4.6.2.13.1 Description 499 4.6.2.13.2 Information Elements 499 4.6.2.14 Furnish Charging Information 500 4.6.2.14.1 Description 500 4.6.2.14.2 Information Elements 500 4.6.2.15 Initiate Call Attempt 501 4.6.2.15.1 Description 501 4.6.2.15.2 Information Elements 501 4.6.2.16 Move Leg 501 4.6.2.16.1 Description 501 4.6.2.16.2 Information Elements 501 4.6.2.17 Play Tone 502 4.6.2.17.1 Description 502 4.6.4.17.2 Information Elements 502 4.6.2.18 Release Call 502 4.6.2.18.1 Description 502 4.6.2.18.2 Information Elements 502 4.6.2.19 Request Report BCSM Event 503 4.6.2.19.1 Description 503 4.6.2.19.2 Information Elements 503 4.6.2.20 Reset Timer 505 4.6.2.20.1 Description 505 4.6.2.20.2 Information Elements 505 4.6.2.21 Send Charging Information 505 4.6.2.21.1 Description 505 4.6.2.21.2 Information Elements 506 4.6.2.22 Split Leg 506 4.6.2.22.1 Description 506 4.6.2.22.2 Information Elements 507 4.6.3 Optional (Service logic dependent) gsmSCF to gsmSRF information flows 507 4.6.3.1 Activity Test 507 4.6.3.1.1 Description 507 4.6.3.1.2 Information Elements 507 4.6.3.2 Cancel 507 4.6.3.2.1 Description 507 4.6.3.2.2 Information Elements 507 4.6.3.3 Play Announcement 507 4.6.3.3.1 Description 507 4.6.3.3.2 Information Elements 508 4.6.3.4 Prompt And Collect User Information 508 4.6.3.4.1 Description 508 4.6.3.4.2 Information Elements 508 4.6.4 gsmSRF to gsmSCF information flows 509 4.6.4.1 Activity Test ack 509 4.6.4.1.1 Description 509 4.6.4.1.2 Information Elements 509 4.6.4.2 Assist Request Instructions 510 4.6.4.2.1 Description 510 4.6.4.2.2 Information Elements 510 4.6.4.3 Prompt And Collect User Information ack 510 4.6.4.3.1 Description 510 4.6.4.3.2 Information Elements 510 4.6.4.4 Specialized Resource Report 510 4.6.4.4.1 Description 510 4.6.4.4.2 Information Elements 510 4.6.5 gsmSCF to Assisting SSF information flows 510 4.6.5.1 Activity Test 510 4.6.5.1.1 Description 510 4.6.5.1.2 Information Elements 510 4.6.5.2 Cancel 511 4.6.5.2.1 Description 511 4.6.5.2.2 Information Elements 511 4.6.5.3 Connect To Resource 511 4.6.5.3.1 Description 511 4.6.5.4 Disconnect Forward Connection 511 4.6.5.4.1 Description 511 4.6.5.4.2 Information Elements 511 4.6.5.5 Play Announcement 511 4.6.5.5.1 Description 511 4.6.5.6 Prompt And Collect User Information 511 4.6.5.6.1 Description 511 4.6.5.7 Reset Timer 511 4.6.5.7.1 Description 511 4.6.6 Assisting SSF to gsmSCF information flows 512 4.6.6.1 Activity Test ack 512 4.6.6.1.1 Description 512 4.6.6.1.2 Information Elements 512 4.6.6.2 Assist Request Instructions 512 4.6.6.2.1 Description 512 4.6.6.3 Prompt And Collect User Information ack (received information) 512 4.6.6.3.1 Description 512 4.6.6.4 Specialized Resource Report 512 4.6.6.4.1 Description 512 4.6.7 HLR to VLR information flows 512 4.6.7.1 Delete Subscriber Data 512 4.6.7.1.1 Description 512 4.6.7.1.2 Information Elements 512 4.6.7.2 Insert Subscriber Data 513 4.6.7.2.1 Description 513 4.6.7.2.2 Information Elements 513 4.6.7.3 Provide Subscriber Info 513 4.6.7.3.1 Description 513 4.6.7.4 Provide Roaming Number 514 4.6.7.4.1 Description 514 4.6.7.4.2 Information Elements 514 4.6.8 VLR to HLR information flows 514 4.6.8.1 Insert Subscriber Data ack 514 4.6.8.1.1 Description 514 4.6.8.1.2 Information Elements 515 4.6.8.2 Provide Subscriber Info ack 515 4.6.8.2.1 Description 515 4.6.8.3 Update Location 515 4.6.8.3.1 Description 515 4.6.8.3.2 Information Elements 515 4.6.8.4 Restore Data 515 4.6.8.4.1 Description 515 4.6.8.4.2 Information Elements 516 4.6.9 HLR to GMSC information flows 516 4.6.9.1 Send Routeing Info ack 516 4.6.9.1.1 Description 516 4.6.9.1.2 Information Elements 516 4.6.10 GMSC to HLR information flows 517 4.6.10.1 Send Routeing Info 517 4.6.10.1.1 Description 517 4.6.10.1.2 Information Elements 518 4.6.11 VMSC to GMSC information flows 518 4.6.11.1 Resume Call Handling 518 4.6.11.1.1 Description 518 4.6.11.1.2 Information Elements 518 4.6.12 MSC to VLR information flows 519 4.6.12.1 Send Info For ICA 519 4.6.12.1.1 Description 519 4.6.12.1.2 Information Elements 519 4.6.12.2 Send Info For Incoming Call 519 4.6.12.2.1 Description 519 4.6.12.2.2 Information Elements 519 4.6.12.3 Send Info For MT Reconnected Call 519 4.6.12.3.1 Description 519 4.6.12.3.2 Information Elements 519 4.6.12.4 Send Info For Outgoing Call 520 4.6.12.4.1 Description 520 4.6.12.4.2 Information Elements 520 4.6.12.5 Send Info For Reconnected Call 520 4.6.12.5.1 Description 520 4.6.12.5.2 Information Elements 520 4.6.13 VLR to MSC information flows 520 4.6.13.1 Complete Call 520 4.6.13.1.1 Description 520 4.6.13.1.2 Information Elements 521 4.6.13.2 Continue CAMEL Handling 521 4.6.13.2.1 Description 521 4.6.13.2.2 Information Elements 521 4.6.13.3 Process Call Waiting 522 4.6.13.3.1 Description 522 4.6.13.3.2 Information Elements 522 4.6.13.4 Send Info For ICA negative response 522 4.6.13.4.1 Description 522 4.6.13.4.2 Information Elements 522 4.6.13.5 Send Info For Incoming Call ack 522 4.6.13.5.1 Description 522 4.6.13.5.1 Information Elements 522 4.6.13.6 Send Info For Incoming Call negative response 523 4.6.13.6.1 Description 523 4.6.13.6.2 Information Elements 523 4.6.13.7 Send Info For MT Reconnected Call ack 523 4.6.13.7.1 Description 523 4.6.13.7.2 Information Elements 523 4.6.13.8 Send Info For MT Reconnected Call negative response 523 4.6.13.8.1 Description 523 4.6.13.8.2 Information Elements 523 4.6.13.9 Send Info For Reconnected Call ack 524 4.6.13.9.1 Description 524 4.6.13.9.2 Information Elements 524 4.6.13.10 Send Info For Reconnected Call negative response 524 4.6.13.10.1 Description 524 4.6.13.10.2 Information Elements 524 4.6.14 Internal MSC information flows 524 4.6.14.1 Perform Call Forwarding ack 524 4.6.14.1.1 Description 524 4.6.14.1.2 Information Elements 524 4.6.15 gsmSCF to HLR information flows 524 4.6.15.1 Send Routeing Info 524 4.6.15.1.1 Description 524 4.6.15.1.2 Information Elements 525 4.6.16 HLR to gsmSCF information flows 525 4.6.16.1 Send Routeing Info ack 525 4.6.16.1.1 Description 525 4.6.16.2 Send Routeing Info negative response 525 4.6.16.2.1 Description 525 4.7 Interaction with supplementary services 526 4.7.1 Line identification 526 4.7.2 Call forwarding services 526 4.7.2.1 Registration of Call Forwarding 526 4.7.2.2 Invocation of Call Forwarding 527 4.7.2.3 Invocation of Call Deflection 528 4.7.3 Call Barring services 528 4.7.4 Closed User Group 528 5 USSD to/from gsmSCF 529 5.1 Architecture 529 5.1.1 Functional Entities used for CAMEL 529 5.1.2 Interfaces defined for CAMEL 530 5.1.2.1 gsmSCF - HLR interface 530 5.2 Description of CAMEL Subscriber Data 530 5.2.1 USSD CAMEL Subscription Information (U CSI) 530 5.2.1.1 Service Code 530 5.2.1.2 gsmSCF address 530 5.3 Content of the USSD General CAMEL Service Information (UG CSI) 530 5.3.1 Service Code 530 5.3.2 gsmSCF address 530 5.4 Procedures 530 5.4.1 MS Initiated USSD 530 5.4.2 gsmSCF Initiated USSD 531 5.5 Description of information flows 531 5.5.1 gsmSCF to HLR information flows 531 5.5.1.1 Unstructured SS Request 531 5.5.1.1.1 Description 531 5.5.1.1.2 Information Elements 531 5.5.1.2 Unstructured SS Notify 532 5.5.1.2.1 Description 532 5.5.1.2.2 Information Elements 532 5.5.1.3 Process Unstructured SS Data ack 532 5.5.1.3.1 Description 532 5.5.1.3.2 Information Elements 532 5.5.1.4 Process Unstructured SS Request ack 532 5.5.1.4.1 Description 532 5.5.1.4.2 Information Elements 532 5.5.2 HLR to gsmSCF information flows 533 5.5.2.1 Unstructured SS Request ack 533 5.5.2.1.1 Description 533 5.5.2.1.2 Information Elements 533 5.5.2.2 Unstructured SS Notify ack 533 5.5.2.2.1 Description 533 5.5.2.2.2 Information Elements 533 5.5.2.3 Process Unstructured SS Data 533 5.5.2.3.1 Description 533 5.5.2.3.2 Information Elements 533 5.5.2.4 Process Unstructured SS Request 533 5.5.2.4.1 Description 533 5.5.2.4.2 Information Elements 533 5.5.2.5 Begin Subscriber Activity 534 5.5.2.5.1 Description 534 5.5.2.5.2 Information Elements 534 6 GPRS interworking 534 6.1 Architecture 534 6.1.1 Functional Entities used for CAMEL 534 6.1.2 Interfaces defined for CAMEL 535 6.1.2.1 SGSN - gprsSSF interface 535 6.1.2.2 gprsSSF - gsmSCF interface 535 6.1.2.3 HLR - SGSN interface 535 6.2 Detection Points (DPs) 535 6.2.1 Definition and description 535 6.2.2 Relationship, DP processing rules and GPRS dialogue 536 6.3 Description of CAMEL Subscriber Data 536 6.3.1 GPRS CAMEL Subscription Information (GPRS CSI) 536 6.3.1.1 gsmSCF Address 536 6.3.1.2 Service Key 536 6.3.1.3 Default GPRS Handling 536 6.3.1.4 TDP List 536 6.3.1.5 CAMEL Capability Handling 537 6.3.1.6 CSI state 537 6.3.1.7 Notification flag 537 6.3.2 gsmSCF address list for CSI 537 6.4 Description of CAMEL State Models 537 6.4.1 General Handling 537 6.4.2 GPRS Attach/Detach State Model 537 6.4.2.1 Description of the Attach/Detach model (PIAs) 538 6.4.2.1.1 Detached 538 6.4.2.1.2 Attached 539 6.4.3 GPRS PDP Context State Model 539 6.4.3.1 Description of the PDP Context model (PIAs) 540 6.4.3.1.1 Idle 541 6.4.3.1.2 PDP Context Setup 541 6.4.3.1.3 PDP Context Established 541 6.4.3.1.4 Change of Position Context 542 6.4.4 GPRS CAMEL Scenarios 542 6.4.4.1 GPRS CAMEL Scenario 1 542 6.4.4.2 GPRS CAMEL Scenario 2 543 6.4.5 SGSN Routeing Area Update 544 6.4.5.1 Intra-SGSN Routeing Area Update 544 6.4.5.2 Inter-SGSN Routeing Area Update 544 6.4.6 Rules for Implicit Disarming of Detection Points 545 6.5 Procedures for CAMEL GPRS 546 6.5.1 Overall SDL Architecture 546 6.5.2 Handling GPRS in the SGSN 546 6.5.2.1 Actions of the SGSN on receipt of Int_Error 547 6.5.2.2 Actions of the SGSN on receipt of Int_Continue 547 6.5.2.3 Handling of GPRS Attach/Detach 548 6.5.2.4 Handling of GPRS Routeing Area Update 551 6.5.2.5 Handling of PDP Context establishment and deactivation 555 6.5.3 Handling GPRS in the gprsSSF 561 6.5.3.1 Process GPRS_SSF 561 6.5.3.2 Process GPRS_Dialogue_Handler 561 6.5.3.3 Procedure Handle_AC_GPRS 561 6.5.3.4 Procedure Handle_ACR_GPRS 561 6.5.3.5 Procedure Complete_FCI_Record_GPRS 562 6.5.3.6 Procedure Handle_SCI_GPRS 562 6.5.3.6.1 Handling of SCI_GPRS for the Session 562 6.5.3.6.2 Handling of SCI_GPRS for a PDP Context 563 6.5.3.7 Procedure Handle_PDP_Acknowledgement 564 6.5.3.8 GPRS duration and volume control 564 6.5.3.8.1 Examples of information flows for GPRS session and PDP context control 564 6.5.3.8.2 TC guard timer 567 6.5.3.9 SDL diagrams for process GPRS_SSF and procedures 569 6.6 Description of information flows 606 6.6.1 gprsSSF to gsmSCF Information Flows 606 6.6.1.1 Activity Test GPRS ack 606 6.6.1.1.1 Description 606 6.6.1.1.2 Information Elements 606 6.6.1.2 Apply Charging Report GPRS 606 6.6.1.2.1 Description 606 6.6.1.2.2 Information Elements 606 6.6.1.3 Entity Released GPRS 607 6.6.1.3.1 Description 607 6.6.1.3.2 Information Elements 607 6.6.1.4 Event Report GPRS 607 6.6.1.4.1 Description 607 6.6.1.4.2 Information Elements 608 6.6.1.5 Initial DP GPRS 610 6.6.1.5.1 Description 610 6.6.1.5.2 Information Elements 610 6.6.2 gsmSCF to gprsSSF Information Flows 611 6.6.2.1 Activity Test GPRS 611 6.6.2.1.1 Description 611 6.6.2.1.2 Information Elements 611 6.6.2.2 Apply Charging GPRS 612 6.6.2.2.1 Description 612 6.6.2.2.2 Information Elements 612 6.6.2.3 Apply Charging Report GPRS ack 612 6.6.2.3.1 Description 612 6.6.2.3.2 Information Elements 612 6.6.2.4 Cancel GPRS 612 6.6.2.4.1 Description 612 6.6.2.4.2 Information Elements 612 6.6.2.5 Connect GPRS 613 6.6.2.5.1 Description 613 6.6.2.5.2 Information Elements 613 6.6.2.6 Continue GPRS 613 6.6.2.6.1 Description 613 6.6.2.6.2 Information Elements 613 6.6.2.7 Entity Released GPRS ack 613 6.6.2.7.1 Description 613 6.6.2.7.2 Information Elements 613 6.6.2.8 Event Report GPRS ack 613 6.6.2.8.1 Description 613 6.6.2.8.2 Information Elements 614 6.6.2.9 Furnish Charging Information GPRS 614 6.6.2.9.1 Description 614 6.6.2.9.2 Information Elements 614 6.6.2.10 Release GPRS 615 6.6.2.10.1 Description 615 6.6.2.10.2 Information Elements 615 6.6.2.11 Request Report GPRS Event 615 6.6.2.11.1 Description 615 6.6.2.11.2 Information Elements 615 6.6.2.12 Reset Timer GPRS 615 6.6.2.12.1 Description 615 6.6.2.12.2 Information Elements 616 6.6.2.13 Send Charging Information GPRS 616 6.6.2.13.1 Description 616 6.6.2.13.2 Information Elements 616 6.6.3 HLR to SGSN Information Flows 617 6.6.3.1 Delete Subscriber Data 617 6.6.3.1.1 Description 617 6.6.3.1.2 Information Elements 617 6.6.3.2 Insert Subscriber Data 617 6.6.3.2.1 Description 617 6.6.3.2.2 Information Elements 617 6.6.4 SGSN to HLR Information Flows 617 6.6.4.1 Insert Subscriber Data ack 617 6.6.4.1.1 Description 617 6.6.4.1.2 Information Elements 618 6.6.4.2 Update GPRS Location 618 6.6.4.2.1 Description 618 6.6.4.2.2 Information Elements 618 7 Short Message Services 618 7.1 Architecture 618 7.1.1 Functional Entities used for CAMEL 618 7.1.2 Interfaces defined for CAMEL 620 7.1.2.1 HLR - VLR interface 620 7.1.2.2 HLR - SGSN interface 620 7.1.2.3 gsmSSF - gsmSCF interface 620 7.1.2.4 gprsSSF - gsmSCF interface 620 7.1.2.5 MSC - gsmSSF interface 620 7.1.2.6 SGSN - gprsSSF interface 621 7.1.2.7 MSC - VLR interface 621 7.1.2.8 MSC - SMSC interface 621 7.1.2.9 SGSN - SMSC interface 621 7.2 Detection Points (DPs) 621 7.2.1 Criteria at DP SMS Delivery Request 621 7.3 Description of CAMEL Subscriber Data 621 7.3.1 Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI) 621 7.3.1.1 gsmSCF address 621 7.3.1.2 Service Key 621 7.3.1.3 Default SMS Handling 621 7.3.1.4 TDP List 622 7.3.1.5 CAMEL Capability Handling 622 7.3.1.6 CSI state 622 7.3.1.7 Notification flag 622 7.3.2 Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI) 622 7.3.2.1 gsmSCF address 622 7.3.2.2 Service Key 622 7.3.2.3 Default SMS Handling 622 7.3.2.4 TDP List 622 7.3.2.5 DP criteria 622 7.3.2.6 CAMEL Capability Handling 622 7.3.2.7 CSI state 622 7.3.2.8 Notification flag 623 7.3.3 gsmSCF address list for CSI 623 7.4 Description of SMS State Models 623 7.4.1 General Handling 623 7.4.2 Mobile Originating SMS State Models 623 7.4.2.1 Description of MO SMS state model 623 7.4.2.1.1 Description of the MO SMS state model (PIAs) 624 7.4.3 Mobile Terminating SMS State Model 625 7.4.3.1 Description of MT SMS state model 625 7.4.3.1.1 Description of the MT SMS state model (PIAs) 626 7.5 Procedures for CAMEL SMS 628 7.5.1 Functional architecture for CAMEL MO SMS services 628 7.5.2 Handling of mobile originating SMS 628 7.5.2.1 Handling of mobile originating SMS in the originating MSC or SGSN 628 7.5.2.1.1 Actions of the MSC or SGSN on receipt of Int_Error 629 7.5.2.1.2 Actions of the MSC or SGSN on receipt of Int_Continue_SMS 629 7.5.2.1.3 Actions of the MSC or SGSN on receipt of Int_Connect_SMS 629 7.5.2.1.4 Actions of the MSC or SGSN on receipt of Int_Release_SMS 629 7.5.2.1.5 Allocation of SMS Reference Number 629 7.5.2.2 Handling of A_MM_Release and A_LLC_Release 629 7.5.2.3 Handling of time-out from SMSC 629 7.5.2.4 Handling of mobile originating SMS in the VLR 634 7.5.3 Functional architecture for CAMEL MT SMS services 636 7.5.4 Handling of mobile terminating SMS 636 7.5.4.1 Handling of mobile terminating SMS in the terminating MSC or SGSN 636 7.5.4.1.1 Procedure CAMEL_T_SMS_INIT; 637 7.5.4.1.2 Procedure CAMEL_T_SMS_DELIVERED 637 7.5.4.1.3 Procedure CAMEL_T_SMS_FAILURE 637 7.5.4.1.4 Allocation of SMS Reference Number 638 7.5.4.2 Handling of mobile terminating SMS in the VLR 643 7.5.4.3 CAMEL subscription check for mobile terminating SMS in the SGSN 645 7.5.5 Handling of mobile originating and mobile terminating SMS in the gsmSSF or gprsSSF 647 7.5.5.1 Process SMS_SSF 647 7.5.5.2 Process Complete_SMS_FCI_Record 647 7.6 Description of information flows 657 7.6.1 gsmSSF or gprsSSF to gsmSCF information flows 657 7.6.1.1 Event Report SMS 657 7.6.1.1.1 Description 657 7.6.1.1.2 Information Elements 657 7.6.1.2 Initial DP SMS 657 7.6.1.2.1 Description 657 7.6.1.2.2 Information Elements 658 7.6.2 gsmSCF to gsmSSF or gprsSSF information flows 660 7.6.2.1 Connect SMS 660 7.6.2.1.1 Description 660 7.6.2.1.2 Information Elements 660 7.6.2.2 Continue SMS 660 7.6.2.2.1 Description 660 7.6.2.2.2 Information Elements 660 7.6.2.3 Furnish Charging Information SMS 660 7.6.2.3.1 Description 660 7.6.2.3.2 Information Elements 661 7.6.2.4 Release SMS 661 7.6.2.4.1 Description 661 7.6.2.4.2 Information Elements 661 7.6.2.5 Request Report SMS Event 661 7.6.2.5.1 Description 661 7.6.2.5.2 Information Elements 662 7.6.2.6 Reset Timer SMS 662 7.6.2.6.1 Description 662 7.6.2.6.2 Information Elements 662 7.6.3 HLR to VLR or SGSN information flows 662 7.6.3.1 Delete Subscriber Data 662 7.6.3.1.1 Description 662 7.6.3.1.2 Information Elements 662 7.6.3.2 Insert Subscriber Data 662 7.6.3.2.1 Description 662 7.6.3.2.2 Information Elements 662 7.6.4 VLR or SGSN to HLR information flows 663 7.6.4.1 Insert Subscriber Data ack 663 7.6.4.2 Update Location 663 7.6.4.3 Update GPRS Location 663 7.6.4.3.1 Description 663 7.6.4.3.2 Information Elements 663 7.6.5 VLR to MSC Information Flows 664 7.6.5.1 Continue CAMEL SMS Handling 664 7.6.5.1.1 Description 664 7.6.5.1.2 Information Elements 664 7.6.5.2 Send Info For MO SMS ack 664 7.6.5.2.1 Description 664 7.6.5.2.2 Information Elements 664 7.6.6 MSC to VLR Information Flows 664 7.6.6.1 Send Info For MT SMS 664 7.6.6.1.1 Description 664 7.6.6.1.2 Information Elements 664 8 SS Notifications 665 8.1 Architecture 665 8.1.1 Functional Entities used for CAMEL 665 8.1.2 Interfaces defined for SS Notifications 665 8.1.2.1 MSC - gsmSCF interface 665 8.1.2.2 HLR - gsmSCF interface 665 8.1.2.3 VLR - MSC interface 666 8.1.2.4 HLR-VLR interface 666 8.2 Description of CAMEL Subscriber Data 666 8.2.1 Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI) 666 8.2.1.1 Notification criteria 666 8.2.1.2 gsmSCF address 666 8.2.1.3 CSI state 666 8.2.1.4 Notification flag 666 8.2.2 gsmSCF address list for CSI 666 8.3 Procedures for CAMEL 666 8.3.1 Handling of Supplementary Service Invocation Notification 666 8.4 Description of information flows 667 8.4.1 MSC to gsmSCF information flows 667 8.4.1.1 SS Invocation Notification 667 8.4.1.1.1 Description 667 8.4.1.1.2 Information Elements 668 8.4.2 HLR to VLR information flows 668 8.4.2.1 Delete Subscriber Data 668 8.4.2.1.1 Description 668 8.4.2.1.2 Information Elements 668 8.4.2.2 Insert Subscriber Data 668 8.4.2.2.1 Description 668 8.4.2.2.2 Information Elements 668 8.4.3 HLR to gsmSCF information flows 668 8.4.3.1 SS Invocation Notification 668 8.4.3.1.2 Information Elements 669 8.4.4 VLR to MSC information flows 669 8.4.4.1 Invoke SS result 669 8.4.4.1.1 Description 669 8.4.4.1.2 Information Elements 669 8.4.4.2 Send Info For Incoming Call ack 669 8.4.4.2.1 Description 669 8.4.4.2.2 Information Elements 669 9 Mobility Management 670 9.1 Architecture 670 9.1.1 Functional Entities used for CAMEL 670 9.1.2 Interfaces defined for CAMEL 671 9.1.2.2 VLR - gsmSCF interface 671 9.1.2.3 SGSN - gsmSCF interface 671 9.2 Description of CAMEL Subscriber Data 671 9.2.1 Mobility Management CAMEL Subscription Information (M CSI) 671 9.2.1.1 Mobility Management Triggers 671 9.2.1.2 gsmSCF address 671 9.2.1.3 Service Key 671 9.2.1.4 CSI state 672 9.2.1.5 Notification flag 672 9.2.2 Mobility Management for GPRS CAMEL Subscription Information (MG CSI) 672 9.2.2.1 Mobility Management Triggers 672 9.2.2.2 gsmSCF address 672 9.2.2.3 Service Key 672 9.2.2.4 CSI state 672 9.2.2.5 Notification flag 672 9.2.3 gsmSCF address list for CSI 672 9.3 Procedures for Mobility management 673 9.3.1 Procedures for Mobility management for CS subscriber 673 9.3.1.1 Procedure descriptions 675 9.3.1.1.1 Procedure Set_Notification_Type 675 9.3.1.1.2 Procedure Notify_gsmSCF 677 9.3.2 Procedures for Mobility management for GPRS subscriber 679 9.3.2.1 Procedure CAMEL_PS_Notification 680 9.4 Description of information flows 684 9.4.1 VLR or SGSN to gsmSCF information flows 684 9.4.1.1 Mobility Management event Notification 684 9.4.1.1.1 Description 684 9.4.1.1.2 Information Elements 684 9.4.2 SGSN to HLR information flows 685 9.4.2.1 Update GPRS Location 685 9.4.3 VLR to HLR information flows 685 9.4.3.1 Update Location 685 9.4.3.2 Restore Data 685 9.4.4 HLR to VLR or SGSN information flows 685 9.4.4.1 Delete Subscriber Data 685 9.4.4.1.1 Description 685 9.4.4.1.2 Information Elements 685 9.4.4.2 Insert Subscriber Data 686 9.4.4.2.1 Description 686 9.4.4.2.2 Information Elements 686 10 Control and interrogation of subscription data 687 10.1 Architecture 687 10.1.1 Functional Entities used for CAMEL 687 10.1.2 Interfaces defined for CAMEL 687 10.1.2.1 gsmSCF - HLR 687 10.2 Procedures for CAMEL 687 10.2.1 Any Time Subscription Interrogation 687 10.2.2 Any Time Modification 690 10.2.3 Notify Subscriber Data Change 707 10.3 Description of information flows 710 10.3.1 gsmSCF to HLR information flows 710 10.3.1.1 Any Time Modification Request 710 10.3.1.1.1 Description 710 10.3.1.1.2 Information Elements 710 10.3.1.2 Any Time Subscription Interrogation Request 712 10.3.1.2.1 Description 712 10.3.1.2.2 Information Elements 713 10.3.1.3 Notify Subscriber Data Change response 713 10.3.1.3.1 Description 713 10.3.1.3.2 Information Elements 714 10.3.2 HLR to gsmSCF information flows 714 10.3.2.1 Any Time Modification ack 714 10.3.2.1.1 Description 714 10.3.2.1.2 Information Elements 714 10.3.2.2 Any Time Subscription Interrogation ack 716 10.3.2.2.1 Description 716 10.3.2.2.2 Information Elements 716 10.3.2.3 Notify Subscriber Data Change 718 10.3.2.3.1 Description 718 10.3.2.3.2 Information Elements 719 10.3.3 IP-SM-GW to HLR information flows 721 10.3.3.1 Any Time Modification Request 721 10.3.3.1.1 Description 721 10.3.3.1.2 Information Elements 721 10.3.4 HLR to IP-SM-GW information flows 721 10.3.4.1 Any Time Modification ack 721 10.3.4.1.1 Description 721 10.3.4.1.2 Information Elements 722 11 Subscriber Location and State retrieval 722 11.1 Architecture 722 11.1.1 Functional Entities used for CAMEL 722 11.1.2 Interfaces defined for CAMEL 723 11.1.2.1 gsmSCF - GMLC interface 723 11.1.2.2 GMLC - gsmSCF interface 723 11.1.2.3 gsmSCF - HLR 723 11.1.2.4 HLR - gsmSCF 724 11.1.2.5 HLR - SGSN 724 11.1.2.5 SGSN - HLR 724 11.2 Procedures for CAMEL 724 11.2.1 Location Services 724 11.2.2 Any Time Interrogation 726 11.2.3 Provide Subscriber Information in the SGSN 728 11.2.3.1 Procedure CAMEL_Provide_Subscriber_Info_SGSN 728 11.2.3.2 Procedure CAMEL_Active_Info_Retrieval_SGSN 728 11.3 Description of information flows 734 11.3.1 gsmSCF to GMLC information flows 734 11.3.1.1 Any Time Interrogation Request 734 11.3.1.1.1 Description 734 11.3.1.1.2 Information Elements 734 11.3.2 GMLC to gsmSCF information flows 734 11.3.2.1 Any Time Interrogation ack 734 11.3.2.1.1 Description 734 11.3.2.1.2 Information Elements 734 11.3.3 gsmSCF to HLR information flows 735 11.3.3.1 Any Time Interrogation Request 735 11.3.3.1.1 Description 735 11.3.3.1.2 Information Elements 735 11.3.4 HLR to gsmSCF information flows 736 11.3.4.1 Any Time Interrogation ack 736 11.3.4.1.1 Description 736 11.3.4.1.2 Information Elements 736 11.3.5 HLR to SGSN information flows 737 11.3.5.1 Provide Subscriber Info 737 11.3.5.1.1 Description 737 11.3.5.1.2 Information Elements 737 11.3.6 SGSN to HLR information flows 737 11.3.6.1 Provide Subscriber Info ack 737 11.3.6.1.1 Description 737 11.3.6.1.2 Information Elements 738 12 Subscriber Mobile Number Portability status retrieval 739 12.1 Architecture 739 12.1.1 Functional Entities used for CAMEL 739 12.1.2 Interfaces defined for CAMEL 740 12.1.2.1 gsmSCF - MNPÊSRF interface 740 12.1.2.2 MNPÊSRF - gsmSCF interface 740 12.2 Procedures for CAMEL 740 12.2.1 Provide MNP Information 740 12.2.1.1 CAMEL_Provide_MNP_Info with ATI 740 12.3 Description of information flows 742 12.3.1 gsmSCF to MNPÊSRF information flows 742 12.3.1.1 Any Time Interrogation Request 742 12.3.1.1.1 Description 742 12.3.1.1.2 Information Elements 742 12.3.2 MNPÊSRF to gsmSCF information flows 742 12.3.2.1 Any Time Interrogation ack 742 12.3.2.1.1 Description 742 12.3.2.1.2 Information Elements 742 Annex A (informative): Handling of Apply Charging GPRS and Apply Charging Report GPRS 744 Annex B (informative): Change history 747 Foreword This Technical Specification (TS) has been produced by the 3rd Generation Partnership Project (3GPP). The present document specifies the stageÊ2 description for the fourth phaseÊ(see 3GPP TSÊ22.078Ê[6]) of the Customized Applications for Mobile network Enhanced Logic (CAMEL) feature within the 3GPP system. The contents of present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will then be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. 1 Scope The present document specifies the stageÊ2 description for the fourth phaseÊ(see 3GPP TSÊ22.078Ê[6]) of the Customized Applications for Mobile network Enhanced Logic (CAMEL) feature which provides the mechanisms to support services of operators which are not covered by standardized services even when roaming outside the HPLMN. The CAMEL feature is a network feature and not a supplementary service. It is a tool to help the network operator to provide the subscribers with the operator specific services even when roaming outside the HPLMN. In the present document, the GSM Service Control Function (gsmSCF) is treated as being part of the HPLMN. The regulatory environment in some countries may require the possibility that the gsmSCF and the HPLMN are controlled by different operators, and the gsmSCF and the HPLMN are therefore distinct entities. The fourth phase of the CAMEL feature supports, in addition to the third phase of the CAMEL: - Interactions with Optimal Routing; - Call Party Handling; - DTMF Mid call procedure for Mobile Originated and Mobile Terminating calls; - Inclusion of flexible tone injection; - Provision of location information of called subscriber; - Provide location information during ongoing call; - CAMEL control over MT SMS; - Notification of GPRS mobility management to CSE; - Inclusion of ODB data in Any Time Modification; - Enhancement of Any Time Interrogation and Provide Subscriber Information for PS Domain; - Mobile Number Portability database interrogation; - Criteria for the provision of location information during ongoing call; - Enhanced Dialled Services; - Enhancement to Establish Temporary Connection; - CAMEL control of trunk originated calls. CAMEL applicability to IP-based multimedia services is introduced in the fourth phase of the CAMEL. It is specified in 3GPP TSÊ23.278Ê[29]. CAMEL is not applicable to Emergency Setup (TSÊ12), i.e. if an Emergency call is requested, then the gsmSSF shall not be invoked. The mechanism described in the present document addresses especially the need for information exchange between the VPLMN or IPLMN and the HPLMN for support of operator specific services. Any user procedures for the control of operator specific services are outside the scope of the present document. Subscribers who have subscribed to operator specific services and therefore need the functional support of the CAMEL feature shall be marked in the HPLMN and VPLMN. In case a subscriber is marked to need CAMEL support, the appropriate procedures which provide the necessary information to the VPLMN or the HPLMN are invoked. It is possible for the HPLMN to instruct the VPLMN or IPLMN to interact with a gsmSCF which is controlled by the HPLMN. The specification of operator specific services is outside the scope of the present document. 1.1 Support of partial implementation of CAMEL phaseÊ4 A functional entity (VMSC, GMSC or SGSN) may support the complete CAMEL phaseÊ4 functionality or, as a network option, it may support the complete CAMEL phaseÊ3 functionality and a partial implementation of CAMEL phaseÊ4. If a functional entity supports any part of CAMEL phaseÊ4, then the HLR is informed of the CAMEL phaseÊ4 CSIs supported. An SGSN may also indicate support of the Provide Subscriber Information IF. To indicate support of a specific CSI, a functional entity shall have the ability to trigger on any initial service event possible for that CSI. If a VMSC or GMSC supports any of the CAMEL phaseÊ4 circuit switched CSIs (O CSI, D CSI, T CSI or VT CSI), then the gsmSCF is informed of the CAMEL phaseÊ4 circuit switched functionalities offered. The gsmSCF shall not send information flows or parameters that conflict with the functionalities offered by the VMSC or GMSC. If a CAMEL subscriber attempts to register in a VMSC or SGSN which supports at least one CAMEL phaseÊ4 CSI or the enhancement of Provide Subscriber Information IF, then the VMSC or SGSN indicates in the registration request to the HLR the phase of CAMEL which the VMSC or SGSN supports (at least phaseÊ4). In addition, the VMSC or SGSN indicates which CAMEL phaseÊ4 CSIs may be downloaded. An SGSN may also indicate support of the Provide Subscriber Information IF. If a GMSC supports at least one CAMEL phaseÊ4 CSI, then the GMSC indicates in the Send Routeing Info to the HLR the phase of CAMEL which the GMSC supports (at least phaseÊ4). In addition, the GMSC indicates which CAMEL phaseÊ4 CSIs may be downloaded. If a VMSC/gsmSSF or GMSC/gsmSSF initiates contact with the gsmSCF using the Initial DP IF, or acknowledges a gsmSCF initiated contact using the Initiate Call Attempt ack IF, then the VMSC/gsmSSF or GMSC/gsmSSF indicates in the IF the CAMEL phaseÊ4 functionalities offered to the gsmSCF. If a VLR initiates contact with the gsmSCF using a Mobility Management Event Notification IF, then the VLR or SGSN indicates in the IF the functionalities offered to the gsmSCF. 1.1.1 CAMEL PhaseÊ4 CSIs A network entity may indicate to the HLR an offer of support for the following CAMEL phaseÊ4 CSIs: - CAMEL phaseÊ4 O CSI; - CAMEL phaseÊ4 D CSI; - CAMEL phaseÊ4 T CSI; - CAMEL phaseÊ4 VT CSI; - CAMEL phaseÊ4 MT SMS CSI; - CAMEL phaseÊ4 MG CSI; CAMEL control of trunk originated calls; - Reporting of additional dialled digits. An SGSN may also indicate support of the CAMEL phaseÊ4 Provide Subscriber Information IF. A functional entity (VMSC, GMSC or SGSN) may offer the CSIs in any combination applicable for this entity. A functional entity shall indicate to the HLR all the CSIs it offers. The HLR may ignore the offer of the supported CSIs if they are not applicable for the sending entity, but it shall not reject the operation in this case."
"1.1.2 CAMEL PhaseÊ4 Functionalities The CAMEL phaseÊ4 functionalities which may be offered to the gsmSCF are the following: - Creating additional parties in a call, Creating a new call (Initiate Call Attempt); - Placing an individual call party on hold or moving an individual call party to Call Segment 1, when Call Segment 1 does not exist (Split Leg); - Connecting an individual call party to the group (Move Leg); - Releasing an individual call party (Disconnect Leg); - Indication of the release of a call party or call segment (Entity Released); - Enhancements for subscriber interactions with the gsmSCF (Disconnect Forward Connection With Argument); - Inclusion of flexible tone injection (Play Tone); - DTMF Mid call procedure for MO and VT calls (DPÊO_Mid_Call, DPÊT_Mid_Call); - Provision of Charge Indicator at answer DP (Charge Indicator at DPÊO_Answer, DPÊT_Answer); - Support of Alerting DP (DPÊO_Term_Seized, DPÊCall_Accepted); - Provision of location information of subscriber at alerting DP (Location information at DPÊO_Term_Seized, DPÊCall_Accepted); - Provision of location information during an ongoing call (DPÊO_Change_Of_Position, DPÊT_Change_Of_Position); - Interactions with Basic Optimal Routeing (Basic OR Interrogation Requested in Connect and Continue With Argument, Route Not Permitted in DPÊO_Abandon); - Warning tone enhancements (Burstlist for Audible Indicator); - Enhancements of Call Forwarding indication (Forwarding Destination Number); - Criteria for the provision of location information during ongoing call (Criteria for DPÊO_Change_Of_Position and DPÊT_Change_Of_Position); - Subscribed Enhanced Dialled services (see description below); - Serving Network Enhanced Dialled Services (see description below); - SCUDIF notification during active phase of the call (DP O_Service_Change and T_Service_Change) ; and Collection of additional dialled digits (Arming CollectedInfo DP as EDP-R). For the Subscribed Enhanced Dialled Services and Serving Network Enhanced Dialled Services, the following information flows apply in addition to the information flows allowed at TDPÊAnalysed_Information since CAMEL phaseÊ3: Apply Charging, Call Information Request, Cancel (all requests) and Request Report BCSM Event together with their acknowledgements and reportings. In addition, all the other offered CAMEL phaseÊ4 functionalities apply also to the enhanced dialled services. A functional entity (VMSC or GMSC) may offer the functionalities in any combination applicable for this entity and applicable to the offered CSIs. A functional entity (VMSC or GMSC) shall indicate to the gsmSCF all the functionallities it offers. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TRÊ21.905: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Vocabulary for 3GPP Specifications"". [2] 3GPP TSÊ22.004: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General on supplementary "". [3] 3GPP TSÊ22.024: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Description of Charge Advice Information (CAI)"". [4] 3GPP TSÊ22.041: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Operator Determined Barring (ODB)"". [5] 3GPP TSÊ22.071: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Location Services (LCS); Service description, StageÊ1"". [6] 3GPP TSÊ22.078: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Customised Applications for Mobile network Enhanced Logic (CAMEL); Service description, StageÊ1"". [7] 3GPP TSÊ23.003: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Numbering, addressing and identification"". [8] 3GPP TSÊ23.008: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Organization of subscriber data"". [9] 3GPP TSÊ23.011: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Supplementary Services"". [10] 3GPP TSÊ23.012: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Location management procedures"". [11] 3GPP TSÊ23.015: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Operator Determined Barring (ODB)"". [12] 3GPP TSÊ23.018: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Basic call handling; Technical realization"". [13] 3GPP TSÊ23.032: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Universal Geographical Area Description (GAD)"". [14] 3GPP TSÊ23.040: ""3rd Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS)"". [15] 3GPP TSÊ23.060: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; StageÊ2"". [16] 3GPP TSÊ23.072: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Deflection (CD) Supplementary Service; StageÊ2"". [17] 3GPP TSÊ23.066: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Mobile Number Portability (MNP); Technical realization; StageÊ2"". [18] 3GPP TSÊ23.073: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Localised Service Area (SoLSA); StageÊ2"". [19] 3GPP TSÊ23.079: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Optimal Routeing (SOR); Technical realization"". [20] 3GPP TSÊ23.082: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Forwarding (CF) supplementary services; StageÊ2"". [21] 3GPP TSÊ23.084: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Multi Party (MPTY) supplementary service; StageÊ2"". [22] 3GPP TSÊ23.085: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Closed User Group (CUG) supplementary service; StageÊ2"". [23] 3GPP TSÊ23.088: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Barring (CB) Supplementary Services; StageÊ2"". [24] 3GPP TSÊ23.090: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Unstructured Supplementary Service Data (USSD); StageÊ2"". [25] 3GPP TSÊ23.091: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Explicit Call Transfer (ECT) supplementary service; StageÊ2"". [26] 3GPP TSÊ23.093: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Completion of Calls to Busy Subscriber (CCBS); StageÊ2"". [27] 3GPP TSÊ23.172: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification; StageÊ2"". [28] 3GPP TSÊ23.271: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional stageÊ2 description of LCS"". [29] 3GPP TSÊ23.278: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) - IP Multimedia System (IMS) interworking; Stage 2"". [30] 3GPP TSÊ24.008: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface layer 3 specification; Core Network Protocols; StageÊ3"". [31] 3GPP TSÊ24.011: ""3rd Generation Partnership Project; Technical Specification Group Core Network; PointÊ-ÊtoÊ-ÊPoint (PP) Short Message Service (SMS); support on mobile radio interface"". [32] 3GPP TSÊ25.305: ""3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Stage 2 Functional Specification of UE Positioning in UTRAN"". [33] 3GPP TSÊ25.413: ""3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling"". [34] 3GPP TSÊ29.002: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Application Part (MAP) specification"". [35] 3GPP TSÊ29.007: ""3rd Generation Partnership Project; Technical Specification Group Core Network; General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)"". [36] 3GPP TSÊ29.078: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) PhaseÊ4 CAMEL Application Part (CAP) specification"". [37] 3GPP TSÊ32.250: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging management; Circuit Switched (CS) domain charging"". [38] 3GPP TSÊ32.251: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging management; Packet Switched (PS) domain charging"". [39] 3GPP TSÊ48.008: ""3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio Access Network; Mobile-services Switching Centre - Base Station System (MSCÊ-ÊBSS) interface; LayerÊ3 specification"". [40] ETSI ENÊ300Ê356-1 (V3.2.2): ""Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 3 for the international interface; Part 1: Basic services[ITU T Recommendations Q.761 to Q.764 (1997), modified]"". [41] ETSI ENÊ301Ê070-1 (V1.2.2): ""Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) versionÊ3 interactions with the Intelligent Network Application Part (INAP); Part 1: Protocol specificationÊ[ITU T Recommendation Q.1600 (1997), modified]"". [42] GSM TRÊ03.47: ""Example protocol stacks for interconnecting; Service Centre(s) (SC) and Mobile-services Switching Centre(s) (MSC)"". [43] ITU T Recommendation Q.763, DecemberÊ1999: ""Signalling System No.Ê7Ê-ÊISDN user part formats and codes"". [44] ITU T Recommendation Q.1224, SeptemberÊ1997: ""Distributed Functional Plane for Intelligent Network Capability SetÊ2"". [45] 3GPP TSÊ23.087: ""3rd Generation Partnership Project; Technical Specification Group Core Network; User-to-User Signalling (UUS) Supplementary Service - Stage 2"". [46] 3GPP TSÊ43.059: ""3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Functional stage 2 description of Location Services (LCS) in GERAN"". [47] 3GPP TSÊ23.081: ""Line identification supplementary services; Stage 2"". [48] 3GPP TSÊ23.083: ""Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 2"". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: Basic Call State Model (BCSM): BCSM provides a high-level model of GMSC- or MSC/VLR-activities required to establish and maintain communication paths for users. As such, it identifies a set of basic call activities in a GMSC or MSC/VLR and shows how these activities are joined together to process a basic call. Call Control Function (CCF): CCF is the Call Control Function in the network that provides call/service processing and control (see ITU T Recommendation Q.1224Ê[44]). Call Party Handling (CPH) Information Flow: Any of the Disconnect Leg, Move Leg or Split Leg information flows. Call Segment: A call segment contains one or more legs that are controlled by the same CS_gsmSSF instance. The call parties in the same call segment can communicate with each other (using a conference bridge if necessary). Call segments are identified by a number, eg. CSID1 is the call segment with id numberÊ1. Call Segment Association (CSA): A CSA contains one or more call segments. Legs can be moved between call segments within the CSA. There is a single CAP dialogue between the CSA and the gsmSCF. Detection Points (DP): points in processing at which notifications (to the service logic) can occur and transfer of control (to the gsmSCF) is possible are called Detection Points (DPs). Dialled Service CAMEL Subscription Information (D CSI): D CSI identifies the subscriber as having originating CAMEL dialled services. Forwarding MSC: MSC which is either an MSC invoking a standardized Call Forwarding supplementary service or Call Deflection supplementary service; or an MSC invoking a CAMEL based call forwarding service. Gateway MLC (GMLC): functional entity that allows external LCS Clients to request real-time information about a Mobile Station. The information that can be requested from the GMLC is: - location of Mobile Station See 3GPP TSÊ23.271Ê[28] and 3GPP TSÊ25.305Ê[32] or 3GPP TSÊ43.059Ê[46] for information on the GMLC. Geodetic Information: information defining the location of a mobile station, coded according to ITU T Recommendation Q.763Ê[43]. The derivation of this information from other information defining the location of a mobile station is a network operator option. If an entity derives the geodetic information it shall also provide the equivalent geographical information. Geographical Information: information defining the location of a mobile station, coded according to 3GPP TSÊ23.032Ê[13]. GPRS CAMEL Subscription Information (GPRS CSI): GPRS CSI identifies the subscriber as having GPRS CAMEL services. GPRS Dialogue: A dialogue between the gprsSSF and the gsmSCF. A single GPRS Dialogue may consist of one or more TCAP dialogues. Only one TCAP dialogue shall exists at one point in time for one gprsDialogue. GPRS Service Switching Function (gprsSSF): functional entity that interfaces the SGSN to the gsmSCF. The concept of the gprsSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network. GPRS Session: GPRS session starts when the GPRS subscriber attaches to the GPRS data network. It ends when the GPRS subscriber detaches from the GPRS data network. GSM Service Control Function (gsmSCF): functional entity that contains the CAMEL service logic to implement OSS. It interfaces with the gsmSSF, the gsmSRF, the GMLC and the HLR. GSM Service Switching Function (gsmSSF): functional entity that interfaces the MSC or GMSC to the gsmSCF. The concept of the gsmSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network. GSM Specialised Resource Function (gsmSRF): functional entity which provides various specialized resources. It interfaces with the gsmSCF and with the MSC. This entity is defined in ITU T Recommendation Q.1224Ê[44] with variations defined in the present document. Inter-connecting MSC: MSC which provides CAMEL support for incoming trunk calls. Location Information: indicates the location of the Mobile Station. The provision of location information is independent of the MS status. As part of the location information, an indication of the age of this information may be delivered. Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI): MO SMS CSI identifies the subscriber as having MO SMS CAMEL services. MO SMS CSI (CAMEL PhaseÊ4) is identical to SMS CSI (CAMEL PhaseÊ3). Mobile Station State: similar to Subscriber State, but associated only with a Mobile Station, not with a subscriber. Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI): MT SMS CSI identifies the subscriber as having MT SMS CAMEL services. Mobility Management event CAMEL Subscription Information (M CSI): M CSI identifies the subscriber as having Mobility Management event notification CAMEL services. Mobility Management event GPRS CAMEL Subscription Information (MG CSI): MG CSI identifies the GPRS subscriber as having Mobility Management event notification CAMEL services. NA (North American): prefix attached to certain information items used by North American PLMNs in connection with routing a call to a preferred or dialled long distance carrier. Network CAMEL Service Information (N CSI): N CSI identifies services offered on a per-network basis by the serving PLMN operator for all subscribers. Originating Basic Call State Model (O BCSM): originating half of the BCSM. The O BCSM corresponds to that portion of the BCSM associated with the originating party. Originating CAMEL Subscription Information (O CSI): O CSI identifies the subscriber as having originating CAMEL services. Point In Association (PIA): PIAs identify MSC/VLR or SGSN activities associated with one or more basic association/connection states of interest to OSS service logic instances. Point In Call (PIC): PICs identify MSC/VLR (GMSC) activities associated with one or more basic call/connection states of interest to OSS service logic instances. Service Key: Service Key identifies to the gsmSCF the service logic. The Service Key is administered by the HPLMN, and is passed transparently by the VPLMN/IPLMN to the gsmSCF. The Service Key is a part of the T/O/VT/D/GPRS/SMS/M CSI. Serving MLC: functional entity that performs location information retrieval. Short Message Control Protocol (SM-CP): Protocol between the MSC or SGSN and the MS. This protocol, which is specified in 3GPP TSÊ24.011Ê[31], is used to carry RPDU elements between the MSC or SGSN and the MS. Short Message Service Centre (SMSC): also abbreviation SC is used for SMSC. Subscriber State: see 3GPP TSÊ22.078Ê[6]. Supplementary Service Notification CAMEL Subscription Information (SS CSI): SS CSI identifies the subscriber as having supplementary service invocation notification CAMEL services. Terminating Basic Call State Model (T BCSM): terminating half of the BCSM. The T BCSM corresponds to that portion of the BCSM associated with the terminating party. Terminating CAMEL Subscription Information (in the GMSC) (T CSI): T CSI identifies the subscriber as having terminating CAMEL services in the GMSC. Translation Information Flag (TIF CSI): TIF CSI is a flag in the CAMEL subscriber data which indicates that when the subscriber registers a forwarded-to number, that the HLR shall not attempt to perform any translation, number format checks, prohibited FTN checks, call barring checks. Trunk Originated CAMEL Service Information (TO-CSI): TO-CSI identifies services offered by the PLMN operator to all incoming calls on a specific MSC trunk. USSD CAMEL Subscription Information (U CSI): U CSI identifies a set of subscriber specific mappings from a USSD service code to a gsmSCF address. USSD General CAMEL Service Information (UG CSI): UG CSI globally identifies a set of mappings from a USSD service code to a gsmSCF address. The global mapping applies to all HPLMN subscribers. If, for a particular service code, both U CSI and UG CSI are applicable then the U CSI shall take precedence. VMSC Terminating CAMEL Subscription Information (VT CSI): VT CSI identifies the subscriber as having terminating CAMEL services in the VMSC. 3.2 Abbreviations Abbreviations used in the present document are listed in 3GPP TRÊ21.905Ê[1]. For the purposes of the present document, the following abbreviations apply: BCSM Basic Call State Model CAMEL Customized Applications for Mobile network Enhanced Logic CPH Call Party Handling CS Call Segment CS Circuit Switched CSA Call Segment Association CSG Closed Subscriber Group CSID Call Segment (followed by an identification Number e.g. CSID1) DP Detection Point DTN Deflected To Number D CSI Dialled Services CAMEL Subscription Information EDP Event Detection Point EDS Enhanced Dialled Services FTN Forwarded To Number GMLC Gateway MLC GMSC Gateway MSC GPRS General Packet Radio Service gprsSSF GPRS Service Switching Function GPRS CSI GPRS CAMEL Subscription Information gsmSCF GSM Service Control Function gsmSRF GSM Specialised Resource Function gsmSSF GSM Service Switching Function HLR Home Location Register HPLMN Home PLMN ICA Initiate Call Attempt IE Information Element IF Information Flow IP Intelligent Peripheral IPLMN Interrogating PLMN LCS Location Services LSA Localised Service Area M CSI Mobility Management event Notification CAMEL Subscription Information MF Mobile Forwarding MG CSI Mobility Management event Notification GPRS CAMEL Subscription Information MLC Mobile Location Centre MNP Mobile Number Portability MNPÊSRF Mobile Number Portability Signalling Relay Function MO Mobile Originating MO SMS CSI Mobile Originated Short Message Service CAMEL Subscription Information MSC Mobile service Switching Centre MT Mobile Terminating MT Mobile Terminating in GMSC MT SMS CSI Mobile Terminating Short Message Service CAMEL Subscription Information N CSI Network CAMEL Service Information NA North American NNI Network Node Interface O BCSM Originating Basic Call State Model O CSI Originating CAMEL Subscription Information ODB Operator Determined Barring OR Optimal Routeing OSS Operator Specific Service PDP Packet Data Protocol PIC Point In Call PLMN Public Land Mobile Network SGSN Serving GPRS Support Node SLPI Service Logic Program Instance SM Short Message SM-CP Short Message Control Protocol SMF Service Management Function SMLC Serving MLC SMRSE Short Message Relay Service Element SMS Short Message Service SMSC Short Message Service Centre SMS CSI Short Message Service CAMEL Subscription Information SS CSI Supplementary Service Notification CAMEL Subscription Information T BCSM Terminating Basic Call State Model T CSI Terminating CAMEL Subscription Information (in the GMSC) TDP Trigger Detection Point TO-CSI Trunk Originated CAMEL Service Information TPDU Transfer Protocol Data Unit TIF CSI Translation Information Flag U CSI USSD CAMEL Subscription Information UG CSI USSD General CAMEL Service Information UNI User Network Interface VLR Visitor Location Register VPLMN Visited PLMN VT Mobile Terminating in VMSC VT CSI VMSC Terminating CAMEL Subscription Information 4 Circuit switched Call Control 4.1 Architecture 4.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support CAMEL. Also the additions needed to the basic functionality are described. FigureÊ4.1 shows the functional entities involved in calls requiring CAMEL support. The architecture is applicable to the forth phase of CAMEL. Figure 4.1: Functional architecture for support of CAMEL HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription regarding O CSI, D CSI, T CSI, VT CSI and TIF CSI. The O CSI is sent to the VLR at Location Update, on data restoration or if the O CSI is updated by administrative action. The D CSI is sent to the VLR at Location Update, on data restoration or if the D CSI is updated by administrative action. The VT CSI is sent to the VLR at Location Update, on data restoration or if the VT CSI is updated by administrative action. The TIF CSI is sent to the VLR at Location Update, on data restoration or if the TIF CSI is updated by administrative action. The O/D/T CSI is sent to the GMSC when the HLR responds to a request for routeing information. GMSC: When processing the calls for subscribers requiring CAMEL support, the GMSC receives an O/D/T CSI from the HLR, indicating the GMSC to request instructions from the gsmSSF. The GMSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the GMSC. MSC: When processing the calls for subscribers requiring CAMEL support, the MSC receives an O CSI and / or D CSI and / or VT CSI from the VLR indicating the MSC to request instructions from the gsmSSF. The MSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the MSC. VLR: The VLR stores the O CSI, D CSI, VT CSI and TIF CSI as a part of the subscriber data for subscribers roaming in the VLR area. gsmSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. gsmSRF: see subclauseÊ3.1. 4.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 4.1.2.1 HLR - VLR interface This interface is used to send the CAMEL related subscriber data to the visited PLMN and for provision of MSRN. The interface is also used to retrieve subscriber status and location information of the mobile subscriber or to indicate suppression of announcement for a CAMEL service. 4.1.2.2 GMSC - HLR interface This interface is used at terminating calls to exchange routeing information, subscriber status, location information, subscription information and suppression of announcements. The CAMEL related subscriber data that is passed to the IPLMN is sent over this interface. 4.1.2.3 GMSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 4.1.2.4 gsmSSF - gsmSCF interface This interface is used by the gsmSCF to control a call in a certain gsmSSF and to request the gsmSSF to establish a connection with a gsmSRF. Relationships on this interface are opened as a result of the gsmSSF sending a request for instructions to the gsmSCF or opened as a result of the gsmSCF sending a request to the gsmSSF to initiate a new call. 4.1.2.5 MSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 4.1.2.6 gsmSCF - HLR interface This interface is used by the gsmSCF to request information from the HLR. As a network operator option the HLR may refuse to provide the information requested by the gsmSCF. 4.1.2.7 gsmSCF - gsmSRF interface This interface is used by the gsmSCF to instruct the gsmSRF to play tones/announcements to the users. 4.1.2.8 GMSC - MSC interface This interface is used to transfer control of a call from a VMSC back to a GMSC for optimal routeing. 4.2 Detection Points (DPs) 4.2.1 Definition and description Certain basic call events may be visible to the GSM Service Control Function (gsmSCF). The DPs are the points in call at which these events are detected. The DPs for Mobile Originated Calls and Mobile Terminated Calls are described in subclausesÊ4.4.2 and 4.4.3. A DP can be armed in order to notify the gsmSCF that the DP was encountered, and potentially to allow the gsmSCF to influence subsequent handling of the call. If the DP is not armed, the processing entity continues the processing without gsmSCF involvement. Three different types of DPs are identified: - Trigger Detection Point - Request (TDP R). This detection point is statically armed and initiates a CAMEL control relationship when encountered and there is no existing relationship due to the same CSI. Processing is suspended when the DP is encountered. - Event Detection Point - Request (EDP R). This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is suspended when encountering the DP and the gsmSSF waits for instructions from the gsmSCF. - Event Detection Point - Notification (EDP N). This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is not suspended when encountering the DP. The DPs are characterized in the following subclauses. 4.2.1.1 Arming/disarming mechanism A DP may be statically armed or dynamically armed. The following arming rules apply: - A DP for mobile terminating call handling is statically armed in the GMSC as a result of T CSI delivery from the HLR. A DP for mobile terminating call handling is statically armed in the VMSC as a result of VT CSI delivery from the VLR. A DP for forwarding leg handling is statically armed in the GMSC as result of O CSI and/or D CSI delivery from the HLR. A DP for mobile originating call or forwarded leg handling is statically armed in the VMSC as a result of O CSI and/or D CSI delivery from the VLR. - A DP is dynamically armed by the gsmSCF within the context of a CAMEL control relationship (between the gsmSSF and the gsmSCF). - A Request Report BCSM Event information flow for a detection point for a leg overwrites any previous Request Report BCSM Event information flow for that detection point for that leg. The following disarming rules apply: - A statically armed DP is disarmed when the O CSI, D CSI, T CSI or VT CSI that caused the DP to be statically armed is withdrawn in the HLR. Only TDP Rs can be disarmed using this mechanism. - If an armed EDP is met, then it is disarmed. - If an EDP is met that causes the release of the related leg, then all EDPs related to that leg are disarmed. - If a call is released, then all EDPs related to that call are disarmed. - If an EDP is met, then other EDPs are disarmed, in accordance with the implicit disarming rule table (seeÊsubclauseÊ4.4.4). - If an EDP is armed, it can be explicitly disarmed by the gsmSCF by means of the Request Report BCSM Event information flow. 4.2.1.2 Criteria Criteria are the conditions that must be met in order for the gsmSSF to request instructions from the gsmSCF. 4.2.1.2.1 Criteria at DPÊCollected_Info The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR may decide not to include the DPÊCollected_Info trigger criteria in the subscriber data sent to the GMSC if the trigger criteria for the call are not met. For optimally routed late forwarded calls, the MSC may decide not to include the DPÊCollected_Info trigger criteria in the Resume Call Handling information flow sent to the GMSC, if the trigger criteria for the call are not met. The following criteria are applicable for DPÊCollected_Info: - Destination number triggering criterion: The HLR may store a list of up to 10 destination numbers and/or up to 3 number lengths. There is no restriction on the nature of address. There is no restriction on the numbering plan indicator. This criterion may be defined to be either ""enabling"" or ""inhibiting"". - Basic service triggering criterion: The HLR may store a list of up to 5 basic service codes, each of which may represent an individual basic service or a basic service group. Compound basic service group codes, as defined in 3GPP TSÊ29.002Ê[34], are not allowed for conditional triggering. This list is a triggering list. - Forwarding triggering criterion: The HLR may store an indicator that triggering shall occur only for a call which has been subject to the Call Forwarding supplementary service, Call Deflection supplementary service or CAMEL call forwarding. This criterion may be defined to be either ""enabling"" or ""inhibiting"". For MO calls, triggering at DPÊCollected_Info shall be strictly based on the number received over the access network. No service selection information, such as ? and # digits, or carrier selection information, dialled by the subscriber, shall be removed from the number before conditional triggering check takes place. For MF calls at the VMSC, triggering at DPÊCollected_Info shall be strictly based on the number received over the access network (the Deflected-to-Number in the case of Call Deflection), the Forwarded-to-Number retained in the VLR or the Destination Routing Address received in the Connect information flow from the gsmSCF during a Terminating CAMEL Service at the VMSC. No service selection information or carrier selection information shall be removed from the number before conditional triggering check takes place. For MF calls at the GMSC, triggering at DPÊCollected_Info shall be strictly based on the Forwarded-to-Number received from HLR, on the Destination Routing Address received in the Connect information flow from the gsmSCF during a Terminating CAMEL Service or on the Forwarded-to-Number received in the Resume Call Handling information flow. No service selection information or carrier selection information shall be removed from the number before conditional triggering check takes place. One or more DP criteria may be applicable. All applicable triggering criteria must be satisfied before the dialogue is established with the gsmSCF. If the destination number triggering criterion is enabling, then the gsmSSF may establish a dialogue with the gsmSCF if: - the destination number matches one of the destination number strings defined in the list, or - the length of the destination number matches one of the destination number lengths defined in the list. In this test the destination number matches one of the destination number strings in the list if: - the nature of address of destination number is the same as the nature of address of the destination number string (The numbering plan indicator is not compared); - the destination number is at least as long as the destination number string in the list, and - all the digits in the destination number string in the list match the leading digits of the destination number. If the destination number triggering criterion is inhibiting, then the gsmSSF may establish a dialogue with the gsmSCF if: - the destination number does not match any of the destination number strings defined in the list, and - the length of the destination number does not match any of the destination number lengths defined in the list. In this test the destination number matches one of the destination number strings in the list if: - the nature of address of the destination number is the same as the nature of address of the destination number string (The numbering plan indicator is not compared); - the destination number is at least as long as the destination number string in the list, and - all the digits in the destination number string in the list match the leading digits of the destination number. The basic service triggering criterion is met if the basic service for the call matches a stored individual basic service code or is a member of the group defined by a stored basic service group code. For a SCUDIF call (see 3GPP TSÊ23.172Ê[27]), the basic service triggering criterion is met if one or both the preferred basic service and the less preferred basic service for the call match a stored individual basic service code or is a member of the group defined by a stored basic service group code. For the purpose of this paragraph a general bearer service is a member of the corresponding bearer service group. If the forwarding triggering criterion is enabling, then the gsmSSF may establish a dialogue with the gsmSCF only if the call has been subject to CAMEL call forwarding or the Call Forwarding supplementary service. If the forwarding triggering criterion is inhibiting, then the gsmSSF may establish a dialogue with the gsmSCF only if the call has not been subject to CAMEL call forwarding or the Call Forwarding supplementary service. 4.2.1.2.2 Criteria at DPÊAnalysed_Information 4.2.1.2.2.1 General The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR shall always include the trigger criteria in the subscriber data sent to the GMSC because that the HLR can not check the criteria applicable at DPÊAnalysed_Info, since the number that the criteria check shall be based on, may be modified by a Mobile Terminating or Mobile Forwarding Service Logic for this call. For optimally routed late forwarded calls, the MSC shall always include the trigger criteria in the Resume Call Handling information flow sent to the GMSC because the MSC can not check the criteria applicable at DPÊAnalysed_Info, since the number that the criteria check shall be based on, may be modified by a Mobile Terminating or Mobile Forwarding Service Logic for this call. The following criteria are applicable for DPÊAnalysed_Information: - Destination number triggering criterion: The HLR may store a list of up to 10 destination numbers. There is no restriction on the nature of address. There is no restriction on the numbering plan indicator. NOTE: The order in which the destination number criteria are checked in the MSC or GMSC is not determined. Hence, overlapping destination number criteria (e.g. use of ""0800"" and ""0800123"" for two different services) should be avoided, because they lead to unpredictable behaviour (i.e. either service might be triggered). For MO calls, triggering at DPÊAnalysed_Info shall be based on the called party number received over the access network or the Destination Routing Address in the Connect information flow from the gsmSCF during a Mobile Originating CAMEL Service. For MF calls at the VMSC, triggering at DPÊAnalysed_Info shall be based on the number received over the access network (the Deflected-to-Number in the case of Call Deflection), the Forwarded-to-Number retained in the VLR, or the Destination Routing Address in the Connect information flow from the gsmSCF during a Mobile Terminated or Mobile Forwarded CAMEL Service. For MF calls at the GMSC, triggering at DPÊAnalysed_Info shall be based on the Forwarded-to-Number received from the HLR, on the Destination Routing Address received in the Connect information flow from gsmSCF during a Mobile Terminated or Mobile Forwarded CAMEL Service, or on the Forwarded-to-Number received in the Resume Call Handling information flow. For NP calls, triggering at DPÊAnalysed_Info shall be based on the number received from gsmSCF. An NP call that is created in the VMSC or GMSC of the served subscriber may be subject to D CSI service and N CSI service. An NP call that is created in an MSC other than the VMSC or GMSC of the served subscriber, may be subject to N CSI service. For NC calls, triggering at DPÊAnalysed_Info shall be based on the number received from the gsmSCF. An NC call may be subject to N CSI service. 4.2.1.2.2.2 Removal of information significant to the serving entity In order to decide whether triggering shall take place, the trigger criteria need to be compared with the address information. Before the comparison takes place the following information shall be removed from the destination address information: - Operator specific service selection information that is recognised and treated locally in the serving entity. This shall not lead to a change of the type of number indicator of the address information. - Carrier selection information. If the removal of carrier selection information also removes international or national (trunk) prefixes (depending on regulatory requirements), then the type of number indicator of the address information shall be changed to ""international number"" or ""national (significant) number"" respectively. Otherwise the type of number indicator shall remain unchanged. The address information in a subsequent Initial DP information flow at DPÊAnalysed_Info shall not contain the removed information, however in the further call handling the serving entity shall invoke the requested services (e.g. carrier selection). 4.2.1.2.2.3 Number comparison The following procedure shall be performed for the comparison of the destination number triggering criterion and the address information in the given order. 1. The numbering plan indicators of the destination number triggering criterion and the destination number are ignored. 2. The type of number/nature of address indicators of the destination number triggering criterion and the destination number are compared. If there is a match of the type of number indicator, then the check shall be performed by comparing the digits as defined in step 6. If there is no match of the type of number the comparison procedure shall continue as follows. 3. If either or both of the address information and destination number triggering criterion includes a types of number/nature of address indicator other than ""unknown"", ""national (significant) number"" or ""international number"" then the destination number does not match the destination number triggering criterion. Otherwise the comparison procedure shall continue as follows. 4."
"If there is a number (address information or destination number triggering criterion) with type of number/nature of address ""unknown"" this number shall be translated based on the numbering plan of the serving entity in either of the following ways: - if the leading digits refer to an international prefix then those digits shall be removed and the type of number/nature of address shall be set to ""international number"". - if the leading digits refer to a national (trunk) prefix then those digits shall be removed and the type of number/nature of address shall be set to ""national (significant) number"". If the leading digits refer neither to an international prefix nor to a national (trunk) prefix, then the destination number does not match the destination number triggering criterion. If there is a match of the type of number/nature of address indicator after this number modification, then the check shall be performed by comparing the digits as defined in step 6, otherwise the comparison procedure shall continue as follows. 5. If the type of number/nature of address of the address information or of the destination number triggering criterion is ""national (significant) number"" this number shall be translated based on the numbering plan of the serving entity to international format by adding the country code of the serving entity to the number string. After this modification the destination number triggering criterion and the destination number shall be in international format and shall be checked by comparing the digits as defined in step 6. 6 If the number of digits in the address information are compared with the number of digits in the destination number triggering criterion, then there is a match if: - the destination number is at least as long as the destination number string of the destination number triggering criterion, and - all the digits in the destination number string of the destination number triggering criterion match the leading digits of the destination number. The check described in this subclause shall be repeated for every number contained in the destination number triggering criterion of the D CSI until there is a match DPÊAnalysed_Info is triggered, or until all the destination numbers have been checked without a match. In the latter case DPÊAnalysed_Info is not triggered. The procedures for the destination number triggering criterion check for N CSI are network specific. The modifications of the address information described in this subclause shall only be done for comparison purposes, i.e. they shall not affect the format of the destination address information sent in the Initial DP information flow. 4.2.1.2.3 Criteria at DPÊRoute_Select_Failure The HLR may store a list of up to 5 cause values. The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR shall always include the trigger criteria in the subscriber data sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the O CSI to the GMSC. For optimally routed late forwarded calls, the MSC shall always include the trigger criteria in the Resume Call Handling information flow sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the O CSI to the GMSC. The following criteria are applicable for DPÊRoute_Select_Failure: - Release cause code. The trigger criteria are met if the cause code received from ISUP is equal to at least one of the cause codes in the trigger criteria list. For the purpose of trigger criteria check, the MSC performing the triggering check shall use the ""cause value"" field of the ISUP ""cause indicators"" parameter, as defined in ITU T Recommendation Q.763Ê[43]. If an O BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. 4.2.1.2.4 Criteria at DPÊTerminating_Attempt_Authorised The HLR may store a list of up to 5 basic service codes, each of which may represent an individual basic service or a basic service group. Compound basic service group codes, as defined in 3GPP TSÊ29.002Ê[34], are not allowed for conditional triggering. This list is a triggering list. The criteria for DPÊTerminating_Attempt_Authorised are checked in the HLR for the GMSC or in the VLR for the MSC. The HLR shall only include T CSI in the CAMEL subscription information sent to the GMSC if the criteria are met. The VLR shall only include VT CSI in the CAMEL subscription information sent to the MSC if the criteria are met. The basic service criterion is met if the basic service for the call matches a stored individual basic service code or is a member of the group defined by a stored basic service group code. For a SCUDIF call (see 3GPP TSÊ23.172Ê[27]), the basic service triggering criterion is met if one or both the preferred basic service and the less preferred basic service for the call match a stored individual basic service code or is a member of the group defined by a stored basic service group code.For the purpose of this paragraph a general bearer service is a member of the corresponding bearer service group. 4.2.1.2.5 Criteria at DPÊT_Busy and T_No_Answer The HLR may store a list of up to 5 cause values. The criteria for a mobile terminating call are checked in the GMSC or in MSC. For mobile terminating calls in the GMSC, the HLR shall include the trigger criteria in the subscriber data sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the T CSI to the GMSC. If the Send Routeing Info ack information flow includes the Not Reachable FTN, then the HLR may decide not to include the trigger criteria, if the HLR has identified that T CSI includes DPÊT_Busy with cause code Not Reachable. If the Send Routeing Info ack information flow includes the Not Reachable FTN and also T CSI, including DPÊT_Busy with cause code, then the not reachable condition shall be mapped to an ISUP release code, which shall be used for the triggering check. For Mobile terminating calls in the VMSC, the trigger criteria are received in the VT CSI from the HLR in the Insert Subscriber Data information flow. The triggering is based on the ISUP release cause code (call set up result). The following criteria are applicable for DPÊT_Busy and DPÊT_No_Answer: - Release cause code. If the cause code is received from ISUP, then the trigger criteria are met if the cause code is equal to at least one of the cause codes in the trigger criteria list. For this check, the MSC shall use the ""cause value"" field of the ISUP ""cause indicators"" parameter, as defined in ITU T Recommendation Q.763Ê[43]. If the cause code is received from MAP, then the trigger criteria are met if the cause code is equal to at least one of the cause codes in the trigger criteria list. For this check, the MSC shall use the cause values as defined in tableÊ4.1. If the trigger criteria are satisfied, then the corresponding Service Logic shall be invoked. If a T BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. When the Resume Call Handling information flow is received in the GMSC and the subscriber has T CSI then the forwarding reason in the Resume Call Handling information flow shall be used to perform the trigger criteria check for DPÊT_Busy or DPÊT_No_Answer. If a match is found, then the corresponding Service Logic shall be invoked. If a T BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. Table 4.1: Mapping of Send Info For Incoming Call (SIFIC) ack, Send Routeing Info ack (SRI ack) or Resume Call Handling (RCH) to ISUP release causes for triggering criteria check SIFIC ack / SRI ack / RCH ""forwarding reason"" ISUP release cause number ISUP release cause name MS not reachable 20 Subscriber absent MS Busy 17 User busy Call deflection (note) 21 Call rejected No reply 19 No answer from user (user alerted) NOTE: Call Deflection is used only in the Resume Call Handling information flow, and in the VMSC. The same code point in the Send Routeing Info ack indicates CFU. However, the CFU invocation in the GMSC triggers the Terminating_Attempt_Authorised DP; thus the reason code mapping is not needed in the CFU case. 4.2.1.3 Relationship If an armed DP is encountered, the gsmSSF provides an information flow via the already established relationship with the gsmSCF. A relationship between the gsmSSF and the gsmSCF for the purpose of operator specific service processing is considered to be a CAMEL relationship. There are two types of CAMEL relationships: - A CAMEL control relationship if the gsmSCF is able to influence the call processing via the relationship. - A CAMEL monitor relationship if the gsmSCF is not able to influence the call processing via the relationship. 4.2.2 DP processing rules The gsmSSF shall apply the following set of rules during DP processing to ensure a single point of control: - EDPs are disarmed by the gsmSSF as they are encountered and reported to the gsmSCF, when the occurrence of another EDP causes the implicit disarming of the EDP or when the leg clears. - A control relationship persists as long as there is 1 or more EDP R armed for this portion of the call or if the Process CS_gsmSSF is in any state except Monitoring or Idle. - A control relationship changes to a monitor relationship if the control relationship does not persist and: - 1 or more EDP N is armed, or - 1 or more Call information Report is outstanding, or - an Apply Charging Report is outstanding. - If a control relationship does not persist and does not change to a monitor relationship then the relationship terminates. A monitor relationship terminates if there are neither EDP Ns armed nor reports outstanding or if the call clears. 4.3 Description of CAMEL Subscriber Data 4.3.1 Originating CAMEL Subscription Information (O CSI) This subclause defines the contents of the Originating CAMEL Subscription Information. 4.3.1.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊCollected_Info and DPÊRoute_Select_Failure. 4.3.1.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.1.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.1.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.1.5 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.1.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a VLR or GMSC any data for a CAMEL phase later than that which the CAMEL capability handling indicates. E.g. if the CAMEL Capability Handling indicates CAMEL phaseÊ1 then the HLR shall not send triggering criteria to the VLR. Different CSIs may contain different values of CAMEL Capability Handling. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.1.7 CSI state The CSI state indicates whether the O CSI is active or not. 4.3.1.8 Notification flag The notification flag indicates whether the change of the O CSI shall trigger Notification on Change of Subscriber Data. 4.3.2 Dialled Service CAMEL Subscription Information (D CSI) This subclause defines the contents of the Dialled Service CAMEL Subscription Information. 4.3.2.1 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.2.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. A gsmSCF address shall be associated with each DP criterion. 4.3.2.3 Service Key The Service Key identifies to the gsmSCF the service logic to be used. A Service Key shall be associated with each DP criteria. 4.3.2.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is submitted to call gapping in the gsmSSF. A default call handling shall be associated with each DP criteria. 4.3.2.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.2.6 CSI state The CSI state indicates whether the D CSI is active or not. 4.3.2.7 Notification flag The notification flag indicates whether changes of the D CSI shall trigger the Notification on Change of Subscriber Data. 4.3.3 Network CAMEL Service Information (N CSI) The N CSI identifies services offered on a per-network basis by the serving PLMN operator for all subscribers and, if applicable, for all incoming trunk originated calls. This CSI shall be stored in the MSC. 4.3.4 Translation Information Flag CAMEL Subscription Information (TIF CSI) 4.3.4.1 Translation Information Flag The TIF CSI in the CAMEL Subscriber data indicates, - when the subscriber registers a forwarded-to number, that the HLR shall not attempt to perform any translation, number format checks, prohibited FTN checks or call barring checks. (see 3GPP TSÊ23.082Ê[20]). - when the subscriber invokes the Call Deflection supplementary service, that the VLR shall not attempt to perform any translation, number format checks, prohibited DTN checks, call barring checks. (seeÊ3GPP TSÊ23.072Ê[16]). 4.3.4.2 Notification flag The notification flag indicates whether the change of the TIF CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.5 Terminating CAMEL Subscription Information (in the GMSC) (T CSI) This subclause defines the contents of the Terminating CAMEL Subscription Information. 4.3.5.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊTerminating_Attempt_Authorised, DPÊT_Busy, and DPÊT_No_Answer. 4.3.5.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.5.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.5.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.5.5 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.5.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a GMSC any data for a CAMEL phase later than that which the CAMEL capability handling indicates. Different CSIs may contain different values of CAMEL Capability Handling. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the GMSC, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (e.g. support of a lower version of CSI). 4.3.5.7 CSI state The CSI state indicates whether the T CSI is active or not. 4.3.5.8 Notification flag The notification flag indicates whether the change of the T CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.6 VMSC Terminating CAMEL Subscription Information (VT CSI) This subclause defines the contents of the Terminating CAMEL Subscription Information for the VMSC. 4.3.6.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊTerminating_Attempt_Authorised, DPÊT_Busy, and DPÊT_No_Answer. 4.3.6.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.6.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.6.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.6.5 DP criteria The DP criteria indicate whether the gsmSSF shall request the gsmSCF for instructions. 4.3.6.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a VLR any data for a CAMEL phase later than that which the CAMEL capability handling indicates. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.6.7 CSI state The CSI state indicates whether the VT CSI is active or not. 4.3.6.8 Notification flag The notification flag indicates whether the change of the VT CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.7 Other CAMEL data 4.3.7.1 Location information/Subscriber state Interrogation This data indicates whether additional subscriber information shall be sent to the GMSC as part of the terminating call handling. - an indication that the HLR shall send the location information of the called subscriber. - an indication that the HLR shall send the subscriber state of the called subscriber. 4.3.7.2 gsmSCF address list for CSI The gsmSCF address list for CSI indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 4.3.8 Trunk Originated CAMEL Service Information (TO-CSI) The TO CSI identifies services offered on a MSC basis by the serving PLMN operator for all incoming calls on a specific MSC trunk. This CSI shall be stored in the MSC. The contents of the TO-CSI is outside the scope of this specification. When processing trunk originating calls requiring CAMEL support, the TO-CSI informs the MSC to request instructions from the gsmSSF. The MSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the MSC. Certain basic call events may be visible to the GSM Service Control Function (gsmSCF). The DPs are the points in call at which these events are detected. The DPs for Trunk Originated Calls are described in subclausesÊ4.4.2. Dynamic arming/ disarming rules for TO calls are specified in subclause 4.2.1.1. Static arming/ disarming of DP Collected_Info for TO calls shall use the following rules: - A DP for trunk originating call is statically armed in the MSC as a result of TO CSI for the specific MSC trunk. - A statically armed DP is disarmed when the TO CSI that caused the DP to be statically armed is withdrawn from the MSC. TDP Criteria may be defined for the case when collection of dialled digits has been performed. Criteria may be based on the contents and/ or length of the dialled number, basic service, call type or other information at the discretion of the network operator, however this is outside the scope of this specification. DP processing rules for TO calls are defined in subclause 4.2.2. 4.4 Description of CAMEL BCSMs 4.4.1 General Handling The BCSM is used to describe the actions in an MSC or GMSC or VMSC during originating, forwarded or terminating calls. The BCSM identifies the points in basic call processing when Operator Specific Service (OSS) logic instances (accessed through the gsmSCF) are permitted to interact with basic call control capabilities. FigureÊ4.2 shows the components that have been identified to describe a BCSM. Figure 4.2: BCSM Components 4.4.2 Originating Basic Call State Model (O BCSM) 4.4.2.1 Description of O BCSM The O BCSM is used to describe the actions in an MSC during originating (MSC) , forwarded (MSC or GMSC) and trunk originating (MSC) calls. When encountering a DP the O BCSM processing is suspended at the DP and the MSC or GMSC indicates this to the gsmSSF which determines what action, if any, shall be taken if the DP is armed. For gsmSCF initiated new calls the O BCSM is initially suspended at DPÊCollected_Info. NOTE: The DPÊO_Busy also includes the 'not reachable' case. Figure 4.3: Originating BCSM for CAMEL The table below defines the different DPs which apply to mobile originating and forwarded calls and trunk originating calls. Table 4.2: Description of O BCSM DPs in the MSC CAMEL Detection Point: DP Type Description: DPÊCollected_Info TDP R, EDP-R (note 7) Indication that the O CSI is analysed, the gsmSCF has initiated a call attempt (in this case the DP is neither triggered nor reported) or additional digits have been collected. DPÊAnalysed_Information TDP RÊ(noteÊ2) Availability of routeing address and nature of address. DPÊRoute_Select_Failure TDP RÊ(noteÊ3), EDP N, EDP R Indication that the call establishment failed. DPÊO_Busy EDP N, EDP R Indication that: - a busy indication is received from the terminating party, - a not reachable event is determined from a cause IE in the ISUP Release message. DPÊO_No_Answer EDP N, EDP R Indication that: - an application timer associated with the O_No_Answer DP expires, - a no answer event is determined from a cause IE in the ISUP Release message. DPÊO_Term_Seized EDP N, EDP R Indication that the called party is being alerted. DPÊO_Answer EDP N, EDP R Indication that the call is accepted and answered by the terminating party. DPÊO_Mid_Call EDP N, EDP R Indication that a service/service feature indication is received from the originating party (DTMF - noteÊ4, noteÊ5). DPÊO_Change_Of_Position EDP N Indication that the originating party has changed position (noteÊ6). DPÊO_Disconnect EDP N, EDP R A disconnect indication is received from the originating party or from the terminating party. DPÊO_Abandon EDP N, EDP R Indication that a disconnect indication is received from the originating party during the call establishment procedure. DPÊO_Service_Change EDP N Indication that the bearer service has changed. NOTE 1: The DPs are defined in ITU T Recommendation Q.1224Ê[44]. NOTE 2: For TDP R Analysed_Information new relationship to gsmSCF is opened. NOTE 3: DPÊRoute_Select_Failure shall be reported as TDP R when there is no relationship to gsmSCF. If a relationship to gsmSCF is already open, it shall be reported as EDP R or EDP N if armed so. DP Route_Select_Failure cannot be armed as TDP-R for Trunk Originating Calls. NOTE 4: DTMF is only applicable for the Mobile Originating or Trunk Originating Call in the VMSC. DTMF is not applicable at the O_Alerting PIC. NOTE 5: Call Processing is suspended at DPÊO_Mid_Call if a Call Party Handling information flow is handled. However, the DP is not reported. NOTE 6: DPÊO_Change_Of_Position is applicable only for the Mobile Originating Call in the VMSC. NOTE 7: DP Collected_Info as a EDP-R is applicable only for Trunk Originating Calls. 4.4.2.1.1 Description of the call model (PICs) This subclause describes the call model for originating and forwarded calls. For each PIC a description can be found of the entry events, functions and exit events. It should be noted that although the names used for PICs match those used in ITU T Recommendation Q.1224Ê[44] the specific descriptions differ. 4.4.2.1.1.1 O_Null & Authorise_Origination_Attempt_Collect_Info Entry events: - Disconnection and clearing of a previous call (DPÊO_Disconnect) or default handling of exceptions by gsmSSF/(G)MSC completed. - Abandon event is reported from Analyse_Information or Routing and Alerting PIC. - Exception event is reported. - gsmSCF requests additional digits (DP CollectedInfo or DP AnalysedInfo). Actions: If entry event is 'gsmSCF requests additional digits' then MSC starts collecting additional digits. Otherwise: - Interface is idled. - Mobile Originating call: - SETUP information flow containing the dialled number is received from MS, preceeding call leg or originating exchange. - The supplementary service ""barring of all outgoing calls"" is checked and invoked if necessary. - The ODB category ""barring of all outgoing calls"" is checked and ODB is invoked if necessary. NOTE: the ODB category ""barring of all outgoing calls when roaming"" causes the HLR to send the category ""barring of all outgoing call"" if the VLR is not in the HPLMN. - CUG checks done in the originating MSC/VLR are performed. - Information being analysed e.g. O-CSI is analysed. - Trunk Originating call: - The initial information flow containing the complete dialled number or an initial information package/ dialling string is received from the trunk interface. - Any operator specific service checks done in the originating MSC are performed. - Information being analysed e.g., TO CSI is analysed. Exit events: If entry event was 'gsmSCF requests additional digits' then: - Additional digits collected. - Inter-digit timer expires - An exception condition is encountered. For example, collection of additional digits fails due to a lack of switch resources (e.g. no digit receivers are available) or calling party abandons call. Otherwise: - Originating CSI is analysed. - Trunk Originating CSI is analysed. - An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP. Example exception condition: Calling party abandons call. 4.4.2.1.1.2 Analyse_Information Entry events: - Originating CSI is analysed. (DPÊCollectedÊInfo). - Trunk Originating CSI is analysed (DP Collected Info). - Additional digits collected (DP Collected Info) in trunk originated call. - The gsmSCF has initiated a call attempt (DPÊCollected_Info). In this case the DP has neither been triggered nor has it been reported. - New routeing information is received when the Busy event (DPÊO_Busy), Route Select Failure event (DPÊRoute_Select_Failure), Not Reachable event (DPÊO_Busy) or No Answer event (DPÊO_No_Answer) is reported from the Routing and Alerting PIC. - New routeing information is received when the Disconnect event is reported from the O_Active PIC. Actions: - Compare the called party number with the dialled services information. Exit events: - Availability of routeing address and nature of address. (DPÊAnalysed_Information). - An exception condition is encountered (e.g. invalid number); this leads to the O_Exception PIC. - The calling party abandons the call; this leads to the O_Abandon DP. 4.4.2.1.1.3 Routing Entry events: - Availability of routeing address and nature of address. (DPÊAnalysed_Information). Actions: - Information is being analysed and/or translated according to dialling plan to determine routeing address. - Routeing address being interpreted. - Mobile Originating or forwarded call: Outgoing barring services and ODB categories not already applied are checked and invoked if necessary. - Trunk Originating call: Any operator specific service checks in the originating MSC are performed. Exit events: - An alerting indication (ISUP ACM) is received from the terminating party; this leads to the O_Term_Seized DP. - The attempt to select the route for the call fails; this leads to the Route_Select_Failure DP. - A busy indication is received from the terminating party; this leads to the O_Busy DP. - A not reachable indication is received from the terminating party; this leads to the O_Busy DP. - A no reply indication is received from the terminating party or a no reply condition is determined at the MSC/ gsmSSF; this leads to the O_No_Answer DP - An indication is received from the terminating half BCSM that the call is accepted and answered by the terminating party; this leads to O_Answer DP. - The calling party abandons the call' this leads to the O_Abandon DP. - An exception condition is encountered; this leads to the O_Exception PIC. 4.4.2.1.1.4 O_Alerting Entry events: - Called Party is being alerted (DPÊO_Term_Seized). - Continue is received in O_Mid_Call DP. Actions: - Call is being processed by the terminating half BCSM. Waiting for indication from terminating half BCSM that the call has been answered by terminating party. - Send a notification to the gsmSCF if the originating party changes position and DPÊO_Change_Of_Position is armed. Exit events: - An indication is received from the terminating half BCSM that the call is accepted and answered by the terminating party; this leads to the O_Answer DP. - A route select failure indication is received from the terminating party; this leads to the Route_Select_Failure DP. - A busy indication is received from the terminating party; this leads to the O_Busy DP. - A not reachable indication is received from the terminating party; this leads to the O_Busy DP. - A no reply indication is received from the terminating party or a no reply condition is determined at the MSC/ gsmSSF; this leads to the O_No_Answer DP. - The calling party abandons the call; this leads to the O_Abandon DP. - An exception condition is encountered; this leads to the O_Exception PIC. 4.4.2.1.1.5 O_Active Entry events: - Indication from the terminating half BCSM that the call is accepted and answered by the terminating party. (DPÊO_Answer) - Continue is received in O_Mid_Call DP. Actions: - Connection established between originating party and terminating party. Call supervision is provided. - Send a notification to the gsmSCF if the originating party changes position and DPÊO_Change_Of_Position is armed. - Send a notification to the gsmSCF if the bearer is changed due to the SCUDIF and DPÊO_Service_Change is armed. - Call release is awaited. Exit events: - A service/service feature request is received from the originating party (DTMF) or DPÊO_Mid_Call is used for Call Party Handling (DPÊO_Mid_Call). - A disconnection indication is received from the originating party, or received from the terminating party via the terminating half BCSM (DPÊO_Disconnect). - An exception condition is encountered. 4.4.2.1.1.6 O_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIC can not be met. Actions: - Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If any relationship exists between the gsmSSF and the gsmSCF, the gsmSSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion. - The (G)MSC/gsmSSF should make use of vendor-specific procedures to ensure release of resources within the (G)MSC/gsmSSF, so that line, trunk and other resources are made available for new calls. Exit events: - Default handling of the exception condition by gsmSSF/(G)MSC completed. 4.4.3 Terminating Basic Call State Model (T BCSM) 4.4.3.1 Description of T BCSM The T BCSM is used to describe the actions in a GMSC and in a VMSC during terminating calls. When encountering a DP the T BCSM processing is suspended at the DP and the GMSC or VMSC indicates this to the gsmSSF which determines what action, if any, shall be taken if the DP is armed. Figure 4.4: T BCSM in the GMSC or VMSC In the table below the different DPs (in the T BCSM) are described. Table 4.3: Description of T BCSM DPs in the GMSC or VMSC CAMEL Detection Point: DP Type Description: DPÊTerminating_Attempt_ Authorised TDP R Indication that the T CSI / VT CSI is analysed. DPÊT_Busy TDP RÊ(noteÊ2), EDP N, EDP R Indication that: - a busy indication is received from the destination exchange, - Busy event is determined in the visited MSC, - Not reachable or call establishment failure event is determined from the HLR response or upon a cause IE in the ISUP Release message. DPÊT_No_Answer TDP R (noteÊ2), EDP N, EDP R Indication that: - an application timer associated with the T_No_Answer DP expires - a no answer event is determined from a cause IE in the ISUP Release message. DPÊCall_Accepted EDP N, EDP R Indication that the called party is being alerted. DPÊT_Answer EDP N, EDP R Call is accepted and answered by terminating party. DPÊT_Mid_Call EDP N, EDP R Indication that a service/service feature is received from the terminating party (DTMF - noteÊ3, noteÊ4). DPÊT_Change_Of_Position EDP N Indication that the terminating party has changed position (noteÊ5). DPÊT_Disconnect EDP N, EDP R A disconnect indication is received from the terminating party or from the originating party. DPÊT_Abandon EDP N, EDP R A disconnect indication is received from the originating party during the call establishment procedure. DPÊT_Service_Change EDP N Indication that the bearer service has changed. NOTE 1: The DPs are defined in ITU T Recommendation Q.1224Ê[44]. NOTE 2: DPÊT_No_Answer and DPÊT_Busy shall be reported as TDP R when there is no relationship to gsmSCF. If a relationship to gsmSCF is already open, it shall be reported as EDP R or EDP N if armed so. NOTE 3: DTMF is only applicable for the VMSC but not for the GMSC. DTMF is not applicable at the T_Alerting PIC. NOTE 4: Call Processing is suspended at DPÊT_Mid_Call if a Call Party Handling information flow is handled. However, the DP is not reported. NOTE 5: DPÊT_Change_Of_Position is applicable only for the Mobile Terminating Call in the VMSC. 4.4.3.1.1 Description of the call model (PICs) This subclause describes the call model for terminating calls in the GMSC and in the VMSC. For each PIC a description can be found of the entry events, functions, information available and exit events. It should be noted that although the names used for PICs match those used in ITU T Recommendation Q.1224Ê[44] the specific descriptions differ. 4.4.3.1.1.1 T_Null Entry events: - Disconnection and clearing of a previous call (DPÊT_Disconnect) or default handling of exceptions by gsmSSF/GMSC or VMSC completed. - Abandon event is reported from Terminating Call Handling PIC. - Exception event is reported. Actions: - Interface is idled. - If ISUP Initial Address Message is received, the appropriate information is analysed. - If the T BCSM is in the GMSC, a Send Routeing Info information flow is sent to the HLR. - If the T BCSM is in the VMSC, a Send Info For Incoming Call information flow is sent to the VLR. - If the T BCSM is in the GMSC: - The supplementary services ""barring of all incoming calls"" and ""barring of incoming calls when roaming"" are checked in the HLR and invoked if necessary. - The ODB categories ""barring of all incoming calls"" and ""barring of incoming calls when roaming"" are checked in the HLR and ODB is invoked if necessary. - The supplementary service ""CUG"" is checked in the HLR and invoked if necessary. - T CSI/VT CSI is received and analysed. Exit events: - Response is received from HLR or VLR and terminating CSI (if available) is analysed. - An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP. Example exception condition is: - The calling party abandons call. 4.4.3.1.1.2 Terminating Call Handling Entry events: - Response is received from HLR or VLR and terminating CSI (if available) is analysed (DPÊTerminating_Attempt_Authorised). - New routeing information is received when a Busy or not reachable event (DPÊT_Busy) or a No Answer event (DPÊT_No_Answer) is reported from the Terminating Call Handling PIC. - New routeing information is received when a Disconnect event is reported from the T_Active PIC."
"NOTE: The HLR may use MAP signalling to indicate to the GMSC before the call is extended to the destination VMSC that the terminating party is not reachable, or the destination VMSC may use telephony signalling to indicate to the GMSC after the call has been extended to the destination VMSC that the terminating party is not reachable. Actions: - The response from the HLR or VLR is analysed. - Routeing address and call type are interpreted. The next route or terminating access is selected. - The Call Forwarding supplementary service is invoked if necessary. Exit events: - The call is accepted and answered by terminating party; this leads to the T_Answer DP. - An indication is received that the called party is being alerted; this leads to the Call_Accepted DP. - An exception condition is encountered; this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC or GMSC was not successful. - The calling party abandons the call; this leads to the T_Abandon DP. - The terminating access is busy in the VMSC or a busy indication is received from the destination exchange in the GMSC; this leads to the T_Busy DP. - A not reachable event detected or failure of attempt to select the route for the terminating leg in the GMSC fails or the MS cannot be reached in the VMSC; this leads to the T_Busy DP. - The no reply timer expires; this leads to the T_No_Answer DP. 4.4.3.1.1.3 T_Alerting Entry events: - Called party is being alerted (DPÊCall_Accepted) - Continue is received in T_Mid_Call DP. Actions: - Waiting for the call to be answered by terminating party. - The Call Forwarding supplementary service is invoked if necessary. - Send a notification to the gsmSCF if the terminating party changes position and DPÊT_Change_Of_Position is armed. Exit events: - The call is accepted and answered by terminating party; this leads to the T_Answer DP. - An exception condition is encountered; this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC or GMSC was not successful. - The calling party abandons the call; this leads to the T_Abandon DP. - A busy indication (UDUB) is received from the destination exchange; this leads to the T_Busy DP. - A not reachable event is detected or the attempt to select the route for the terminating leg in the GMSC fails or the MS cannot be reached in the VMSC; this leads to the T_Busy DP. - The no reply timer expires; this leads to the T_No_Answer DP. - A Call Party Handling information flow is executed; this leads to the T_Mid_Call DP. 4.4.3.1.1.4 T_Active Entry events: - Indication that the call is accepted and answered by the terminating party. (DPÊT_Answer). - Continue is received in T_Mid_Call DP. Actions: - Connection established between originating party and terminating party. Call supervision is being provided. - Send a notification to the gsmSCF if the terminating party changes position and DPÊT_Change_Of_Position is armed. - Send a notification to the gsmSCF if the bearer is changed due to the SCUDIF and DPÊT_Service_Change is armed. - Wait for call release. Exit events: - A disconnection indication is received from the terminating party, or received from the originating party via the originating half BCSM; this leads to the T_Disconnect DP. - An exception condition is encountered. In addition to the specific examples listed above, exception events include any type of failure that means that the normal exit events for a PIC cannot be met. - A service/service feature request is received from the called party (DTMF) or a Call Party Handling information flow is executed; this leads to the T_Mid_Call DP. 4.4.3.1.1.5 T_Exception Entry events: - An exception condition is encountered. In addition to the specific examples listed above, exception events include any type of failure, which means that the normal exit events for PIC cannot be met. Actions: - Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If any relationship exists between the gsmSSF and the gsmSCF, the gsmSSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion. - The GMSC or VMSC / gsmSSF should make use of vendor-specific procedures to ensure release of resources within the GMSC or VMSC / gsmSSF, so that line, trunk and other resources are made available for new calls. Exit events: - Default handling of the exception condition by gsmSSF/GMSC is completed. 4.4.4 Rules for Implicit Disarming of Event Detection Points The tables below give the rules for implicit disarming of event detection points. Implicit EDP disarming rules are specified in the tables below for Originating BCSM and Terminating BCSM respectively. Each table specifies which EDP's shall be disarmed (i.e. MonitorMode set to Transparent) if/when each EDP is encountered, irrespective of the EDP's Monitor Mode (Transparent, Notify And Continue, or Request). When EDPs armed with MonitorMode 'Request' (EDP Rs) are encountered, any implicit EDP disarming shall take place before reporting the EDP and transiting the gsmSSF to the Waiting_For_Instruction state (if not already suspended in the Waiting_For_Instruction state). If the BCSM has encountered DPÊO/T_Answer then an originator release must be detected as a DPÊO/T_Disconnect. The table entry 'X' means that if the DP is encountered (independently of arming and reporting to the gsmSCF) the marked DP is implicitly disarmed. It shall be possible to rearm explicitly an implicitly disarmed DP, e.g. for follow on call. Table 4.4: Implicit disarmed DPs in the O BCSM Encountered DP Implicit disarmed DPs Collected_Info Route_Select_Failure O_Busy O_No_Answer O_Answer O_Mid_Call Leg 1 O_Disconnect Leg 1 O_Disconnect any other Leg O_Abandon O_Term_Seized O_Change_Of_Position O_Service_Change Collected_Info X Route_Select_Failure X X X X X X O_Busy X X X X X X O_No_Answer X X X X X X O_Answer X X X X X X O_Mid_Call Leg 1 (noteÊ1) X O_Disconnect Leg 1 X X X X X O_Disconnect any other Leg X X X X X X O_Abandon X X X X X X O_Term_Seized X O_Change_Of_Position (noteÊ1) X O_Service_Change (noteÊ1) X Note 1 If the Automatic Rearm IE was present in the Request Report BCSM Event information flow for the O_Change_Of_Position DP, O_Service_Change or the O_Mid_Call DP and armed as EDP N, then the DP shall be automatically rearmed by the gsmSSF when it is encountered. Table 4.5: Implicit disarmed DPs in the T BCSM Encountered DP Implicit disarmed DPs T_Busy T_No_Answer T_Answer T_Mid_Call Leg 2 T_Disconnect Leg 1 T_Disconnect Leg 2 T_Abandon Call_Accepted T_Change_Of_Position T_Service_Change T_Busy X X X X X X X X T_No_Answer X X X X X X X X T_Answer X X X X X T_Mid_Call Leg 2 (noteÊ1) X T_Disconnect Leg 1 X X T_Disconnect Leg 2 X X X X X X X X T_Abandon X X Call_Accepted X T_Change_Of_Position (noteÊ1) X T_Service_Change (noteÊ1) X Note 1 If the Automatic Rearm IE was present in the Request Report BCSM Event information flow for the T_Change_Of_Position DP, T_Service_Change or the T_Mid_Call DP and armed as EDP N, then the DP shall be automatically rearmed by the gsmSSF when it is encountered. 4.4.5 BCSM Modelling of Call Scenarios This subclause describes how the BCSMs defined above are used to model CS call scenarios. For each scenario the used and unused BCSMs involved in the call are shown. In some cases these models may have an allocation to physical nodes different from that shown. However, the physical separation of the logical functions shown shall not impact the modelling. This subclause describes the call scenarios without optimal routeing. If optimal routeing is invoked then the physical configurations may be different from those shown, but the modelling is not changed. CAMEL may be applied simultaneously and independently for each subscriber involved in a call. This is not shown in these scenarios. Subscribers other than those being served by CAMEL may be either PSTN subscribers, other subscribers or any other addressable subscriber. 4.4.5.1 Mobile Originated Call For the call from A to B, an instance of the O BCSM will be created in the MSC (labelled ""O(A B)""). If the A party has an active O CSI or D CSI, or the MSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship with gsmSCF(1) shall be established. Figure 4.5: BCSM Scenario for Mobile Originated Call 4.4.5.2 Mobile Terminated Call at the GMSC or VMSC For the call from A to B, an instance of the T BCSM will be created in the GMSC (labelled ""T(A B)"") and an instance of the T BCSM will be created in the VMSC (labelled ""T(A B)""). If the B party has an active T CSI in the GMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC and the gsmSCF(1) shall be established. If the B party has an active VT CSI in the VMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the VMSC and the gsmSCF(2) shall be established. The relationships with gsmSCF (1) and gsmSCF(2) may exist simultaneously. The two gsmSCF endpoints of the relationships are treated independently. The nodes gsmSCF (1) and gsmSCF (2) may be the same or different entities. Figure 4.6: BCSM Scenario for Mobile Terminated Calls at the GMSC or VMSC 4.4.5.3 Call Forwarding at the GMSC or VMSC If the B party has an active T CSI in the GMSC or VT CSI in the VMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(1) shall be established. Following processing at the GMSC or VMSC the call will be extended to the VMSC serving the B party. This VMSC may be physically integrated with the GMSC. A new call leg to a ""C"" party shall be created if: - a Call Forwarding supplementary service or Call Deflection supplementary service forwards the call to C. An instance of the O BCSM O(B C) will be created for the forwarding leg. If the B party has an active O CSI or D CSI in the GMSC or VMSC, or the GMSC or VMSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(2) shall be established. If the GMSC or VMSC receives the 'Suppress O-CSI' parameter, then O CSI shall not be used for the forwarding leg or deflecting leg; or - a CAMEL service in a control relationship with T(A B) performs a CAMEL-based call forwarding by using a Connect information flow. An instance of the O BCSM O(B C) will be created for the forwarding leg. If the B party has an active O CSI or D CSI in the GMSC or VMSC, or the GMSC or VMSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(2) shall be established. The O CSI shall be used for the forwarding leg only if the last Connect information flow includes the ""O CSI applicable"" flag. The relationship with gsmSCF (1) and the relationship with gsmSCF(2) may exist simultaneously. The two relationships are treated independently at the GMSC. The instance of the BCSM T(A B) and the instance of the BCSM O(B C) are linked by an internal interface which is assumed to behave in a similar way to an ISUP interface. The nodes gsmSCF (1) and gsmSCF (2) may be the same or different physical entities. Figure 4.7: BCSM Scenario for Call Forwarding at the GMSC or VMSC 4.4.5.4 gsmSCF Initiated Call When the gsmSCF wishes to originate a new call, the gsmSCF establishes communication with the network using CAP signalling. When the gsmSCF wishes to originate a new leg within an existing call, the gsmSCF uses the already established communication with the gsmSSF. It sends an Initiate Call Attempt information flow which shall contain the address of the called party. Afterwards the gsmSCF shall instruct the gsmSSF to continue with the call processing. The MSC constructs an ISUP Initial Address Message using the parameters received from the gsmSCF and sends it to the destination exchange. The O BCSM for the gsmSCF initiated call to B (labelled ""O(M B)"") is invoked on request of the gsmSCF. A control relationship with gsmSCF (1) is created for the initiation of a new call. NOTE: The term ISUP is used to denote UNI or NNI signalling system used in a given network. Figure 4.8: BCSM Scenario for gsmSCF Initiated New Call 4.4.5.5 Trunk Originated Call For the call from A to B, an instance of the O BCSM will be created in the MSC (labelled ""O(A B)""). If the MSC has an active TO CSI for the trunk on which the call has originated, or an active N-CSI, and the trigger criteria (if present) are fulfilled, then a CAMEL control relationship with gsmSCF(1) shall be established. Figure 4.4.5.5.1: BCSM Scenario for Trunk Originated Call 4.4.6 Leg Handling A call may consist of several call parties with each party connected to the call, e.g. there may be a calling party and several called parties. From a call handling point of view it is necessary to distinguish between a leg, which is a concept internal to the call handling model, and a connection, which is the external link to the party. A connection to the call party will be set up using telephony (e.g. ISUP) or radio access signalling. The outgoing leg already exists when the connection is set up. On the other hand, if a connection is released, e.g. because the destination user is busy, the leg still exists, and the gsmSCF can send a Connect Information Flow to connect this leg to another call party. 4.4.6.1 Leg is created For the purposes of the formal description, one or more legs are created in the following cases: - When a call is to be established, i.e. when an incoming Setup or ISUP IAM is being handled or when a call is to be forwarded, the incoming leg (leg1) and the outgoing leg (leg2) are created before the first CS_gsmSSF process is invoked for that call in this MSC. In particular, this applies before the Call Control Function (CCF) sends DP_Collected_Info (for originating, forwarded or deflected calls) or DP_Terminating_Attempt_Authorised (for terminating calls) to the CS_gsmSSF process; - When the CS_gsmSSF process receives an Initiate Call Attempt Information Flow, an outgoing leg is created. 4.4.6.2 Leg continues to exist For the purposes of the formal description, a leg continues to exist in the following cases: - The CCF sends any DP to the CS_gsmSSF the leg will continue to exist at least until the CS_gsmSSF instructs the CCF to continue its processing for the leg; - A connection to a called party is not successful and the gsmSCF sends a new Connect Information Flow for that leg; - A called party releases her connection and the gsmSCF sends a new Connect Information Flow for that leg; - The CS_gsmSSF processes either of the Call Party Handling Information Flows Move Leg and Split Leg; 4.4.6.3 Leg is released Before a leg is released the corresponding connection is released. All outstanding reports for the leg are sent to the gsmSCF and the corresponding call records are closed. For the purposes of the formal description, a leg ceases to exist when any of the following events occurs: - The calling party releases the connection, the CCF sends a DP to the CS_gsmSSF and the CCF receives Int_Continue or Int_Continue_With_Argument from the CS_gsmSSF process; - A connection to a called party is not successful (DPs Route_Select_Failure, O_Busy, O_No_Answer, T_Busy and T_No_Answer), the CCF sends a DP to the CS_gsmSSF and the CCF does not receive Int_Connect for that outgoing leg from the CS_gsmSSF; - The called party releases her connection, the CCF sends a DP to the CS_gsmSSF and the CCF does not receive Int_Connect for that outgoing leg from the CS_gsmSSF; - The CCF receives Int_Disconnect_Leg from the CS_gsmSSF; - The timer Tcp expires for a leg and the condition ""Release if duration exceeded"" is true for that leg; - The CCF receives Int_Release_Call from the CS_gsmSSF. If a call is released, either on instruction from the CS_gsmSSF or on normal call handling without any CAMEL interaction, then all legs involved in the call cease to exist. 4.4.6.4 Leg is moved A leg can be moved from one call segment (source call segment) to another call segment (target call segment) as a result of a Move Leg or Split Leg information flow. When the CSA_gsmSSF receives a Split Leg Information Flow it creates a new call segment and moves the specified leg into this call segment. When the CSA_gsmSSF receives a Move Leg Information Flow it moves the specified leg into call segmentÊ1. A leg is no longer contained in the source call segment when the source CS_gsmSSF receives Int_Export_Leg_ack from the CCF. A leg is contained in the target call segment when the target CS_gsmSSF receives Int_Import_Leg_ack from the CCF. 4.5 Procedures for CAMEL The SDLs in the present document illustrate how CAMEL modifies the normal call handling. They do not attempt to show all the details of call handling in nodes that support CAMEL. Relevant parts of 3GPP TSÊ23.018Ê[12] apply in addition to these SDLs. For example, some inputs leading to unsuccessful call attempts are not shown on these diagrams - corresponding clauses in 3GPP TSÊ23.018Ê[12] apply. Note that in some SDL processes and procedures the Release information flow may be sent on both an access interface and an inter-switch interface. If the message is sent on a UNI, its effect is the same as a Release transaction information flow. The text in this clause is a supplement to the definition in the SDL diagrams; it does not duplicate the information in the SDL diagrams. 4.5.1 Overall SDL architecture The following mapping from the SDL procedures to the Intelligent Network concepts apply: SDL process Description SDL process specification CSA_gsmSSF Call Segment Association (CSA). The CSA SDL process distributes the CAP operations to the appropriate Call Segment(s). 3GPP TSÊ23.078 CS_gsmSSF Call Segment (CS). Controls one or more BCSMs. 3GPP TSÊ23.078 OCH_MSC O BCSM in VMSC for Mobile Originating call controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_OCH_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_OCH_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_OCH_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 MT_GMSC T BCSM in the GMSC controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Terminating_Attempt_Authorised), then the call is not routed to the destination and the process spawns the child process CAMEL_MT_LEG1_GMSC to control LegÊ1. The process MT_GMSC terminates. If Answer is received, the process spawns the child process CAMEL_MT_LEG1_GMSC to control LegÊ1 and calls the procedure CAMEL_MT_LEG2_GMSC to control LegÊ2. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 MT_CF_MSC O BCSM in the redirecting MSC for Call Forwarding supplementary service, or Call Deflection supplementary service, or for CAMEL-based call forwarding. This process controls both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_MT_CF_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_MT_CF_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_MT_CF_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 ICH_MSC T BCSM in the VMSC controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Terminating_Attempt_Authorised), then the call is not routed to the destination and the process spawns the child process CAMEL_ICH_LEG1_MSC to control LegÊ1. The process ICH_MSC terminates. If Answer is received, the process spawns the child process CAMEL_ICH_LEG1_MSC to control LegÊ1 and calls the procedure CAMEL_ICH_LEG2_MSC to control LegÊ2. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 TO_MSC O-BCSM in the inter-connecting MSC for trunk originated calls. This process controls both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_TOC_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_MT_CF_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_TOC_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 Assisting_MSC The process in the MSC to handle an assist request. 3GPP TSÊ23.078 CAMEL_ICA_MSC O BCSM for gsmSCF initiated new call, or for new party set-up. This process controls the new leg. 3GPP TSÊ23.078 The following general rules apply: 1 There is only one CSA per CAP dialogue. 2 The CSA controls one or more Call Segments. 3 A Call Segment controls one or more BCSMs. Due to Call Party Handling, legs may be moved from one Call Segment to another and new Call Segments may be created. When legs are moved they take their properties with them, i.e. armed EDPs and pending reports. 4 Legs are not moved between BCSMs. 5 The active legs in the same Call Segment have a voice connection. They hear each other and the same in-band tone and announcements. The following exceptions exist: - Apply Charging IF: the warning tone associated with the Apply Charging IF is played to a single call party in the Call Segment. - Play Tone IF: the flexible tone from the Play Tone IF may be played to a single call party in the Call Segment. The following diagrams shows the overall architecture for the SDL diagrams. Figure 4.9-1: Outgoing case (gsmSSF relay) Figure 4.9-2: Outgoing case (direct path gsmSCF to gsmSRF or assist with relay) Figure 4.9-3: Terminating GMSC case (gsmSSF relay) Figure 4.9-4: Terminating GMSC case (direct path gsmSCF to gsmSRF or assist with relay) NOTE: The ICH_MSC may also be connected via an A interface to the terminating Mobile Station. Figure 4.9-5: Terminating VMSC case (gsmSSF relay) NOTE: The ICH_MSC may also be connected via an A interface to the terminating Mobile Station Figure 4.9-6: Terminating VMSC case (direct path gsmSCF to gsmSRF or assist with relay) Figure 4.9-7: Assisting case Figure 4.9-8: gsmSCF initiated call case (gsmSSF relay) Figure 4.9-9: Trunk Originating case (gsmSSF relay) 4.5.2 Handling of mobile originated calls 4.5.2.1 Handling of mobile originated calls in the originating MSC The functional behaviour of the originating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_OCH_MSC_INIT; - Procedure CAMEL_MO_Dialled_Services; - Procedure CAMEL_OCH_MSC_ALERTING; - Procedure CAMEL_OCH_MSC_ANSWER; - Procedure CAMEL_OCH_MSC1; - Procedure CAMEL_OCH_MSC2; - Procedure CAMEL_OCH_MSC_DISC1; - Procedure CAMEL_OCH_MSC_DISC2; - Procedure CAMEL_OCH_MSC_DISC3; - Procedure CAMEL_OCH_MSC_DISC4; - Procedure CAMEL_Disconnect_CTR_SRF; - Procedure CAMEL_OCH_ETC; - Procedure CAMEL_OCH_CTR; - Procedure CAMEL_Start_TNRy; - Procedure CAMEL_Stop_TNRy; - Procedure CAMEL_Store_Destination_Address; - Procedure CAMEL_Modify_CUG_Info; - Procedure CAMEL_N_CSI_CHECK_MSC; - Procedure CAMEL_OCH_LEG1_MSC; - Procedure CHECK_DIGIT_STRING_MSC; - Process CAMEL_OCH_LEG2_MSC; - Process CAMEL_OCH_RECONNECT_MSC; - Procedure CAMEL_EXPORT_LEG_MSC; - Process CAMEL_O_CHANGE_OF_POSITION_MSC; - Procedure CAMEL_O_SCUDIF_MSC. NOTE: Procedure CAMEL_OCH_MSC_DISC3 applies to CAMEL PhaseÊ1 only. The procedure Send_Access_Connect_If_Required is specified in 3GPP TSÊ23.018Ê[12]. The procedure CAMEL_OCH_LEG1_MSC supervises the originating party only. The process CAMEL_OCH_LEG2_MSC supervises the terminating party only. Hence, signals from the BSS are received by the procedure CAMEL_OCH_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_OCH_LEG2_MSC. The following paragraphs give details on the behaviour of the MSC in the procedures CAMEL_OCH_MSC_INIT, CAMEL_OCH_ETC, CAMEL_OCH_ANSWER and CAMEL_Store_Destination_Address. 4.5.2.1.1 Actions of the MSC on receipt of Int_Error The MSC checks the default Call Handling parameter in the relevant CSI. If the default call handling is release call, a Release is sent to the MS and an Abort to the VLR. The MSC then releases all call resources and the procedure CAMEL_OCH_MSC_INIT ends. If the default call handling is continue call, the MSC continues processing without CAMEL support. It sends Send_Info_For_Ougoing_Call to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.2 Actions of the MSC on receipt of Int_Continue The MSC continues processing without any modification of call parameters. At DPÊAnalysed_Information it sends Send Info For Ougoing Call information flow to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument The MSC continues processing with modified call parameters. The MSC shall replace the call parameters by the information received in the Int_Continue_With_Argument signal. Call parameters which are not included in the Int_Continue_With_Argument signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.2.1.4 Actions of the MSC on receipt of Int_Connect The MSC continues processing with modified call parameters. The MSC shall transparently modify the call parameters with the received information. The MSC then sends a PROGRESS message to the MS. Call parameters which are not included in the Int_Connect signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. At DPÊCollected_Information the MSC sets the O CSI suppression parameter. If D CSI and N CSI are not present, the MSC sends a Send Info For Outgoing Call to the VLR and waits in state Wait_For_MO_Call_Result. At DPÊAnalysed_Information it sets the D CSI suppression parameter, sends a Send Info For Outgoing Call to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.5 Actions of the MSC on receipt of Int_Release_Call A Release is sent to the MS, an abort to the VLR and a Release is sent to the destination exchange. The release cause received in the Int_Release_Call signal is used. The MSC then releases all call resources and the procedure CAMEL_OCH_MSC_INIT ends. 4.5.2.1.6 Actions of the MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.2.1.7 Actions of the MSC on receipt of Int_Apply_Warning_Tone This section applies to all call cases. The MSC will play a tone to the indicated leg or call segment. The following special cases exist when there is already an existing tone to a leg or call segment: 1 If the MSC is playing a tone to a leg and the Int_Apply_Warning_Tone instructs the MSC to play a tone for another leg (in the same or a different call segment), then the tones will be played independently; 2 The tones for different call segments are independent; 3 If the MSC is playing a tone to a leg and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that leg, then the MSC will stop the existing tone and the latter tone will be played for that leg. 4 If the MSC is playing a tone to a call segment and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that call segment, then the MSC will stop the existing tone and the latter tone will be played for that call segment. 5 If the MSC is playing a tone for the call segment and the Int_Apply_Warning_Tone instructs the MSC to play another tone for a leg in that call segment, then the particular leg shall hear (as an MSC option) either: a The latter tone only, or b Two tones. As an MSC option, the two tones may be played in parallel or in a sequence. The other leg(s) shall keep hearing the (old) call segment tone. 6 If the MSC is playing a tone for a leg and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that call segment, then the particular leg shall either hear (as an MSC option): a The latter tone only, or b Two tones. As an MSC option, the two tones may be played in parallel or in a sequence. The other leg(s) shall start hearing the new call segment tone. 4.5.2.1.8 Action of the MSC in procedure CAMEL_OCH_MSC_ANSWER If the MSC received a destination address from the GMSC in the ISUP Answer or Connect Message, the MSC relays the destination address to the gsmSSF in the Int_DP_O_Answer signal. NOTEÊ1: The sending of e-parameters by the gsmSCF after receiving the DP_O_Answer indication may be to late. NOTEÊ2: If the MO call is not subject to Basic OR, then the destination address is generated by the MSC. If the MO call is subject to Basic OR, the MSC will receive a destination address from the GMSC in the ISUP Answer or Connect Message. 4.5.2.1.9 Action of the MSC in procedure CAMEL_OCH_ETC In procedure CAMEL_OCH_ETC (sheet 2) the MSC will remain in the Wait_For_Assisting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). If a Progress Message is sent towards the MS the progress indicator shall indicate ""In Band Information"". 4.5.2.1.10 Procedure CAMEL_OCH_LEG1_MSC The Int_DTMF_Digit_Received information flow is received from an internal process in the MSC that receives DTMF signalling from the MS. The handling of the internal process that receives DTMF signalling is out of scope of the present document. The playing of the received DTMF tones to the other parties in the call segment is out of scope of the present document. 4.5.2.1.11 Process CAMEL_O_CHANGE_OF_POSITION_MSC The signals HANDOVER COMPLETE and HANDOVER PERFORMED are specified in 3GPP TSÊ48.008Ê[39]. Signals RELOCATION REQUEST ACKNOWLEDGE, LOCATION REPORT and LOCATION REPORTING COMMAND are specified in 3GPP TSÊ25.413Ê[33]. 4.5.2.1.12 Procedure CAMEL_Start_TNRy The recommended value range in the gsmSSF for the default TNRy timer for CAMEL handling is 10 seconds to 3 minutes. The CSE provided TNRy value is applied only once per outgoing leg. The decision ""TNRy received?"" decision box goes to ""No"" branch if the TNRy duration has been used for once and no new timer value has been received since previous call of this procedure. The task box ""Cancel TNRy received"" ensures that the gsmSCF provided timer is applied only once per call leg. The task box prevents the use of previously received timer value from the gsmSCF in subsequent calls (e.g. as in the case of a follow-on call). For example: The gsmSCF arms O_No_Answer EDP and also sent a TNRy timer duration. The call fails and EDP O_No_Answer is reported to the gsmSCF. The gsmSCF sends a Connect (i.e. follow-on call), and also arms EDP O_No_Answer, but this time, with no TNRy timer duration included. The gsmSSF does not use the TNRy timer previously provided by the gsmSCF. Instead, the network's default TNRy timer is used if available for the follow-on call. Figure 4.10-1: Procedure CAMEL_OCH_MSC_INIT (sheet 1) Figure 4.10-2: Procedure CAMEL_OCH_MSC_INIT (sheet 2) Figure 4.10-3: Procedure CAMEL_OCH_MSC_INIT (sheet 3) Figure 4.10-4: Procedure CAMEL_OCH_MSC_INIT (sheet 4) Figure 4.11-1: Procedure CAMEL_MO_Dialled_Services (sheet 1) Figure 4.11-2: Procedure CAMEL_MO_Dialled_Services (sheet 2) Figure 4.11-3: Procedure CAMEL_MO_Dialled_Services (sheet 3) Figure 4.12-1: Procedure CAMEL_SDS_MO_Init (sheet 1) Figure 4.12-2: Procedure CAMEL_SDS_MO_INIT (sheet 2) Figure 4.12-3: Procedure CAMEL_SDS_MO_INIT (sheet 3) Figure 4.12-4: Procedure CAMEL_SDS_MO_INIT (sheet 4) Figure 4.13-1: Procedure CAMEL_NDS_MO_INIT (sheet 1) Figure 4.13-2: Procedure CAMEL_NDS_MO_INIT (sheet 2) Figure 4.13-3: Procedure CAMEL_NDS_MO_INIT (sheet 3) Figure 4.13-4: Procedure CAMEL_NDS_MO_INIT (sheet 4) Figure 4.14-1: Procedure CAMEL_OCH_MSC_ALERTING (sheet 1) Figure 4.14-2: Procedure CAMEL_OCH_MSC_ALERTING (sheet 2) Figure 4.14-3: Procedure CAMEL_OCH_MSC_ALERTING (sheet 3) Figure 4.15-1: Procedure CAMEL_OCH_MSC_ANSWER (sheet 1) Figure 4.15-2: Procedure CAMEL_OCH_ANSWER (sheet 2) Figure 4.15-3: Procedure CAMEL_OCH_ANSWER (sheet 3) Figure 4.16-1: Procedure CAMEL_OCH_MSC1 (sheet 1) Figure 4.16-2: Procedure CAMEL_OCH_MSC1 (sheet 2) Figure 4.16-3: Procedure CAMEL_OCH_MSC1 (sheet 3) Figure 4.17-1: Procedure CAMEL_OCH_MSC2 (sheet 1) Figure 4.17-2: Procedure CAMEL_OCH_MSC2 (sheet 2) Figure 4.17-3: Procedure CAMEL_OCH_MSC2 (sheet 3) Figure 4.18-1: Procedure CAMEL_OCH_MSC_DISC1 (sheet 1) Figure 4.19-1: Procedure CAMEL_OCH_MSC_DISC2 (sheet 1) Figure 4.19-2: Procedure CAMEL_OCH_MSC_DISC2 (sheet 2) Figure 4.20-1: Procedure CAMEL_OCH_MSC_DISC3 (sheet 1) Figure 4.21-1: Procedure CAMEL_OCH_MSC_DISC4 (sheet 1) Figure 4.22-1: Procedure CAMEL_Disconnect_CTR_SRF (sheet 1) Figure 4.23-1: Procedure CAMEL_OCH_ETC (sheet 1) Figure 4.23-2: Procedure CAMEL_OCH_ETC (sheet 2) Figure 4.23-3: Procedure CAMEL_OCH_ETC (sheet 3) Figure 4.23-4: Procedure CAMEL_OCH_ETC (sheet 4) Figure 4.24-1: Procedure CAMEL_OCH_CTR (sheet 1) Figure 4.24-2: Procedure CAMEL_OCH_CTR (sheet 2) Figure 4.24-3: Procedure CAMEL_OCH_CTR (sheet 3) Figure 4.24-4: Procedure CAMEL_OCH_CTR (sheet 4) Figure 4.24-5: Procedure CAMEL_OCH_CTR (sheet 5) Figure 4.25-1: Procedure CAMEL_Start_TNRy (sheet 1) Figure 4.26-1: Procedure CAMEL_Stop_TNRy (sheet 1) Figure 4.27-1: Procedure CAMEL_Store_Destination_Address (sheet 1) Figure 4.28-1: Procedure CAMEL_Modify_CUG_Info (sheet 1) Figure 4.29-1: Procedure CAMEL_N_CSI_CHECK_MSC (sheet 1) Figure 4.30-1: Procedure CAMEL_OCH_LEG1_MSC (sheet 1) Figure 4.30-2: Procedure CAMEL_OCH_LEG1_MSC (sheet 2) Figure 4.30-3: Procedure CAMEL_OCH_LEG1_MSC (sheet 3) Figure 4.30-4: Procedure CAMEL_OCH_LEG1_MSC (sheet 4) Figure 4.30-5: Procedure CAMEL_OCH_LEG1_MSC (sheet 5) Figure 4.30-6: Procedure CAMEL_OCH_LEG1_MSC (sheet 6) Figure 4.30-7: Procedure CAMEL_OCH_LEG1_MSC (sheet 7) Figure 4.30-8: Procedure CAMEL_OCH_LEG1_MSC (sheet 8) Figure 4.30-9: Procedure CAMEL_OCH_LEG1_MSC (sheet 9) Figure 4.30-10: Procedure CAMEL_OCH_LEG1_MSC (sheet 10) Figure 4.30-11: Procedure CAMEL_OCH_LEG1_MSC (sheet 11) Figure 4.30-12: Procedure CAMEL_OCH_LEG1_MSC (sheet 12) Figure 4.30-13: Procedure CAMEL_OCH_LEG1_MSC (sheet 13) Figure 4.31-1: Procedure CHECK_DIGIT_STRING_MSC (sheet 1) Figure 4.32-1: Process CAMEL_OCH_LEG2_MSC (sheet 1) Figure 4.32-2: Process CAMEL_OCH_LEG2_MSC (sheet 2) Figure 4.33-1: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 1) Figure 4.33-2: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 2) Figure 4.33-3: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 3) Figure 4.33-4: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 4) Figure 4.33-5: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 5) Figure 4.33-6: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 6) Figure 4.33-7: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 7) Figure 4.33-8: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 8) Figure 4.33-9: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 9) Figure 4.34-1: Procedure CAMEL_EXPORT_LEG_MSC (sheet 1) Figure 4.34-2: Procedure CAMEL_EXPORT_LEG_MSC (sheet 2) Figure 4.35-1: Process CAMEL_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.36-1: Process CAMEL_O_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.36-2: Process CAMEL_O_CHANGE_OF_POSITION_MSC (sheet 2) Figure 4.37-1: Procedure Check_Criteria_Change_Of_Position (sheet 1) Figure 4.38-1: Procedure CAMEL_O_SCUDIF_MSC (sheet 1) 4.5.2.2 Handling of mobile originating calls in the originating VLR The functional behaviour of the originating VLR is specified in 3GPP TSÊ23.018Ê[12]. The procedure specific to CAMEL are specified in this subclause: - Procedure CAMEL_OCH_VLR; - Process CAMEL_Reconnected_Call_VLR. Figure 4.39-1: Procedure CAMEL_OCH_VLR (sheet 1) Figure 4.40-1: Process CAMEL_Reconnected_Call_VLR (sheet 1) 4.5.3 Retrieval of routeing information 4.5.3.1 Retrieval of routeing information in the GMSC The functional behaviour of the GMSC is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_Set_ORA_Parameters; - Procedure CAMEL_MT_GMSC_INIT; - Procedure CAMEL_MT_MSC_ALERTING; - Procedure CAMEL_MT_GMSC_ANSWER; - Procedure CAMEL_MT_GMSC_DISC1; - Procedure CAMEL_MT_GMSC_DISC2; - Procedure CAMEL_MT_GMSC_DISC3; - Procedure CAMEL_MT_GMSC_DISC4; - Procedure CAMEL_MT_GMSC_DISC5; - Procedure CAMEL_MT_GMSC_DISC6; - Procedure CAMEL_MT_CTR; - Procedure CAMEL_MT_ETC; - Procedure CAMEL_Start_TNRy; - Procedure CAMEL_Stop_TNRy; - Procedure CAMEL_MT_GMSC_Notify_CF; - Procedure CAMEL_MT_LEG2_GMSC; - Process CAMEL_MT_LEG1_GMSC; - Procedure CAMEL_MT_RECONNECT_GMSC; - Procedure CAMEL_T_SCUDIF_MSC. NOTE: Procedure CAMEL_MT_GMSC_DISC3 applies to CAMEL PhaseÊ1 only. The procedure Send_ACM_If_Required is specified in 3GPP TSÊ23.018Ê[12]. The procedure CAMEL_MT_LEG2_GMSC supervises the terminating party only. The process CAMEL_MT_LEG1_GMSC supervises the originating party only. Hence, signals from the destination exchange are received by the procedure CAMEL_MT_LEG2_GMSC and signals from the originating exchange are received by the process CAMEL_MT_LEG1_GMSC. The following paragraphs give details on the behaviour of the GMSC in the procedure CAMEL_MT_GMSC_INIT. 4.5.3.1.1 Action of the GMSC on receipt of Int_Release_Call An ISUP Release message is sent to the originating exchange and resources are released. 4.5.3.1.2 Action of the GMSC on receipt of Int_Error The GMSC checks the default call handling parameter in the T CSI. If the default call handling is release call, an ISUP Release message is sent to the originating exchange. The MSC then releases all call resources and the procedure CAMEL_MT_GMSC_INIT returns result=fail. If the default call handling is continue call, the MSC continues call handling without CAMEL support. 4.5.3.1.3 Action of the GMSC on receipt of Int_Continue If an FTN has been stored then the information received from the HLR is used to overwrite the corresponding call parameters. Note that the MSISDN is replaced by the FTN as the called party number. The redirection counter is incremented. If no FTN has been stored then a Send Routeing Info information flow including a T CSI suppression parameter is sent to the HLR. The Send Routing Info information flow includes an indication of which CAMEL Phases are supported by the GMSC/gsmSSF. 4.5.3.1.4 Action of the GMSC on receipt of Int_Continue_With_Argument If an FTN has been stored then the information received from the HLR is used to overwrite the corresponding call parameters. The MSISDN is replaced by the FTN as the called party number. The redirection counter is incremented."
"If no FTN has been stored then a Send Routeing Info information flow including a T CSI suppression parameter is sent to the HLR. The Send Routing Info information flow includes an indication of which CAMEL phases are supported by the GMSC/gsmSSF. The MSC shall replace the call parameters by the information received in the Int_Continue_With_Argument signal. Call parameters which are not included in the Int_Continue_With_Argument message are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.3.1.5 Action of the GMSC on receipt of Int_Connect If the Destination Number received from the gsmSCF (via the gsmSSF) is the same as the ISUP called party number, i.e. the MSISDN, the following parameters, if received, are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]): Calling Partys Category and Generic Number. If received, the Announcement Suppression Indicator is stored. The further processing is described in subclauseÊ4.5.3.1.3 with the addition that the Announcement Suppression indicator, if stored, is sent to the HLR in the Send Routeing Info message. If: - the Destination Number received from the gsmSCF (via the gsmSSF) is not the same as the stored ISUP called party number, i.e. the MSISDN, and - a CUG active indication was received from the HLR, and - CUG information was received in the ISUP IAM for the incoming call; then an exception event is reported to the process CS_gsmSSF, an ISUP Release Message is sent to the originating exchange. The MSC then releases all call resources and the procedure CAMEL_MT_GMSC_INIT returns result=fail. Otherwise the following parameters, if received, are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]): Destination Number, Calling Partys Category, Generic Number, Original Called Party ID, Redirecting Party ID and Redirection Information. Call parameters that are not included in the Int_Connect signal are unchanged. As a network operator option loop prevention mechanisms may cause the redirection information to be ignored or modified (e.g., if the Redirection counter has been decreased). Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. 4.5.3.1.6 Action of the GMSC on receipt of Send_Routeing_Info Negative Response (in state Wait_For_Routeing_Info_2) An exception event is reported to the process CS_gsmSSF. If the Announcement Suppression indicator has been received from the gsmSCF (via the gsmSSF) any announcements or tones shall be suppressed. 4.5.3.1.7 Action of the GMSC on receipt of Send_Routeing_Info ack with MSRN (in state Wait_For_Routeing_Info_2) An ISUP IAM with the MSRN as the called party number is constructed. 4.5.3.1.8 Action of the GMSC on receipt of Send_Routeing_Info ack with FTN (in state Wait_For_Routeing_Info_2) The information received from the HLR is used to overwrite the corresponding call parameters (for details see 3GPP TSÊ23.018Ê[12]). The redirection counter is incremented. 4.5.3.1.9 Action of the GMSC on receipt of Send_Routeing_Info ack with O CSI and/or D CSI and FTN (at state Wait_For_Routeing_Info_2) The information received from the HLR is used to overwrite corresponding call parameters. The redirection counter is incremented. The Called Party Number is set to the FTN. The O CSI and/or D CSI is stored. 4.5.3.1.10 Action of the GMSC in procedure CAMEL_MT_ETC In the procedure CAMEL_MT_ETC (sheet 2) the GMSC will remain in the Wait_For_Assiting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). If a Progress Message is sent towards the MS the progress indicator shall indicate ""In Band Information"". 4.5.3.1.11 Action of the GMSC in procedure CAMEL_MT_GMSC_Notify_CF The Forwarding reason is taken from the Send Routeing Info ack information flow (for early call forwarding) or the Resume Call Handling information flow (for Optimal Routeing of Late Call Forwarding). The Int_DP_T_No_Answer signal and Int_DP_T_Busy signal include a parameter to indicate that the call has encountered conditional call forwarding. The gsmSSF will transfer this parameter to the Event Report BCSM information flow which it sends to the gsmSCF. 4.5.3.1.12 Action of the MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. Figure 4.41-1: Procedure CAMEL_Set_ORA_Parameters (sheet 1) Figure 4.42-1: Procedure CAMEL_MT_GMSC_INIT (sheet 1) Figure 4.42-2: Procedure CAMEL_MT_GMSC_INIT (sheet 2) Figure 4.42-3: Procedure CAMEL_MT_GMSC_INIT (sheet 3) Figure 4.42-4: Procedure CAMEL_MT_GMSC_INIT (sheet 4) Figure 4.42-5: Procedure CAMEL_MT_GMSC_INIT (sheet 5) Figure 4.42-6: Procedure CAMEL_MT_GMSC_INIT (sheet 6) Figure 4.42-7: Procedure CAMEL_MT_GMSC_INIT (sheet 7) Figure 4.42-8: Procedure CAMEL_MT_GMSC_INIT (sheet 8) Figure 4.43-1: Procedure CAMEL_MT_MSC_ALERTING (sheet 1) Figure 4.43-2: Procedure CAMEL_MT_MSC_ALERTING (sheet 2) Figure 4.43-3: Procedure CAMEL_MT_MSC_ALERTING (sheet 3) Figure 4.44-1: Procedure CAMEL_MT_GMSC_ANSWER (sheet 1) Figure 4.44-2: Procedure CAMEL_MT_GMSC_ANSWER (sheet 2) Figure 4.44-3: Procedure CAMEL_MT_GMSC_ANSWER (sheet 3) Figure 4.45-1: Procedure CAMEL_MT_GMSC_DISC1 (sheet 1) Figure 4.46-1: Procedure CAMEL_MT_GMSC_DISC2 (sheet 1) Figure 4.46-2: Procedure CAMEL_MT_GMSC_DISC2 (sheet 2) Figure 4.47-1: Procedure CAMEL_MT_GMSC_DISC3 (sheet 1) Figure 4.48-1: Procedure CAMEL_MT_GMSC_DISC4 (sheet 1) Figure 4.48-2: Procedure CAMEL_MT_GMSC_DISC4 (sheet 2) Figure 4.48-3: Procedure CAMEL_MT_GMSC_DISC4 (sheet 3) Figure 4.49-1: Procedure CAMEL_MT_GMSC_DISC5 (sheet 1) Figure 4.49-2: Procedure CAMEL_MT_GMSC_DISC5 (sheet 2) Figure 4.49-3: Procedure CAMEL_MT_GMSC_DISC5 (sheet 3) Figure 4.50-1: Procedure CAMEL_MT_GMSC_DISC6 (sheet 1) Figure 4.51-1: Procedure CAMEL_MT_ETC (sheet 1) Figure 4.51-2: Procedure CAMEL_MT_ETC (sheet 2) Figure 4.51-3: Procedure CAMEL_MT_ETC (sheet 3) Figure 4.51-4: Procedure CAMEL_MT_ETC (sheet 4) Figure 4.52-1: Procedure CAMEL_MT_CTR (sheet 1) Figure 4.52-2: Procedure CAMEL_MT_CTR (sheet 2) Figure 4.52-3: Procedure CAMEL_MT_CTR (sheet 3) Figure 4.52-4: Procedure CAMEL_MT_CTR (sheet 4) Figure 4.52-5: Procedure CAMEL_MT_CTR (sheet 5) Figure 4.53-1: Procedure CAMEL_MT_GMSC_Notify_CF (sheet 1) Figure 4.53-2: Procedure CAMEL_MT_GMSC_Notify_CF (sheet 2) Figure 4.54-1: Procedure CAMEL_MT_LEG2_GMSC (sheet 1) Figure 4.54-2: Procedure CAMEL_MT_LEG2_GMSC (sheet 2) Figure 4.54-3: Procedure CAMEL_MT_LEG2_GMSC (sheet 3) Figure 4.55-1: Process CAMEL_MT_LEG1_GMSC (sheet 1) Figure 4.55-2: Process CAMEL_MT_LEG1_GMSC (sheet 2) Figure 4.55-3: Process CAMEL_MT_LEG1_GMSC (sheet 3) Figure 4.55-4: Process CAMEL_MT_LEG1_GMSC (sheet 4) Figure 4.55-5: Process CAMEL_MT_LEG1_GMSC (sheet 5) Figure 4.56-1: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 1) Figure 4.56-2: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 2) Figure 4.56-3: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 3) Figure 4.56-4: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 4) Figure 4.56-5: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 5) Figure 4.56-6: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 6) Figure 4.56-7: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 7) Figure 4.57-1: Procedure CAMEL_T_SCUDIF_MSC (sheet 1) 4.5.3.2 Retrieval of routeing information in the HLR The functional behaviour of the HLR is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_HLR_INIT; - Procedure CAMEL_CSI_Check_HLR; - Procedure CAMEL_O_CSI_CHECK_HLR; - Procedure CAMEL_D_CSI_CHECK_HLR; - Procedure CAMEL_T_CSI_CHECK_HLR; - Procedure CAMEL_CHECK_SII2_CDTI. The procedure CAMEL_Provide_Subscriber_Info is specified in subclauseÊ4.5.9. Figure 4.58-1: Procedure CAMEL_HLR_INIT (sheet 1) Figure 4.58-2: Procedure CAMEL_HLR_INIT (sheet 2) Figure 4.59-1: Procedure CAMEL_CSI_Check_HLR (sheet 1) Figure 4.60-1: Procedure CAMEL_O_CSI_CHECK_HLR (sheet 1) Figure 4.61-1: Procedure CAMEL_D_CSI_CHECK_HLR (sheet 1) Figure 4.62-1: Procedure CAMEL_T_CSI_CHECK_HLR (sheet 1) Figure 4.63-1: Procedure CAMEL_CHECK_SII2_CDTI (sheet 1) 4.5.3.3 Handling of provide roaming number request in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ23.018Ê[12]. The procedure specific to CAMEL is specified in this subclause: - Procedure CAMEL_SET_SOA. Figure 4.64-1: Procedure CAMEL_SET_SOA (sheet 1) 4.5.4 Handling of mobile terminating calls 4.5.4.1 Handling of mobile terminating calls in the terminating VMSC The functional behaviour of the terminating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The behaviour specific to CAMEL is: - the inclusion of the O CSI and/or D CSI parameter in the Perform Call Forwarding information flow sent to the process MT_CF_MSC if O CSI and/or D CSI was received in the Send Info For Incoming Call ack information flow; - the requirement to suppress the connection of announcements or tones if the VLR includes the suppression of announcements parameter in the Send Info For Incoming Call negative response information flow. The processes and procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_ICH_VLR; - Procedure CAMEL_O_CSI_Check_VLR; - Procedure CAMEL_D_CSI_Check_VLR; - Procedure CAMEL_VT_CSI_Check_VLR; - Procedure CAMEL_ICH_MSC_INIT; - Procedure CAMEL_MT_VMSC_Notify_CF; - Procedure CAMEL_ICH_LEG2_MSC; - Procedure CAMEL_ICH_LEG2_CF_MSC; - Process CAMEL_ICH_LEG1_MSC; - Procedure CAMEL_ICH_RECONNECT_MSC; - Process CAMEL_T_CHANGE_OF_POSITION_MSC. The procedure CAMEL_ICH_LEG2_MSC supervises the terminating party only. The procedure CAMEL_ICH_LEG2_CF_MSC supervises the forwarded-to party only. The process CAMEL_ICH_LEG1_MSC supervises the originating party only. Hence, signals from the BSS are received by the procedure CAMEL_ICH_LEG2_MSC, signals from the destination exchange are received by the procedure CAMEL_ICH_LEG2_CF_MSC and signals from the originating exchange are received by the process CAMEL_ICH_LEG1_MSC. 4.5.4.1.1 Action of the VMSC in procedure CAMEL_MT_VMSC_Notify_CF The Forwarding reason is taken from the Complete Call information flow from the VLR. The Int_DP_T_No_Answer signal and Int_DP_T_Busy signal include a parameter to indicate that the call has encountered conditional call forwarding. The gsmSSF will transfer this parameter to the Event Report BCSM information flow which it sends to the gsmSCF. 4.5.4.1.2 Action of MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.4.1.3 Procedure CAMEL_ICH_LEG2_MSC The Int_DTMF_Digit_Received information flow is received from an internal process in the MSC that receives DTMF signalling from the MS. The handling of the internal process that receives DTMF signalling is out of scope of the present document. The playing of the received DTMF tones to the other parties in the call segment is out of scope of the present document. 4.5.4.1.4 Process CAMEL_T_CHANGE_OF_POSITION_MSC The signals HANDOVER COMPLETE and HANDOVER PERFORMED are specified in 3GPP TSÊ48.008Ê[39]. Signals RELOCATION REQUEST ACKNOWLEDGE, LOCATION REPORT and LOCATION REPORTING COMMAND are specified in 3GPP TSÊ25.413Ê[33]. Figure 4.65-1: Procedure CAMEL_ICH_VLR (sheet 1) Figure 4.66-1: Procedure CAMEL_O_CSI_Check_VLR (sheet 1) Figure 4.67-1: Procedure CAMEL_D_CSI_Check_VLR (sheet 1) Figure 4.68-1: Procedure CAMEL_VT_CSI_Check_VLR (sheet 1) Figure 4.69-1: Procedure CAMEL_ICH_MSC_INIT (sheet 1) Figure 4.69-2: Procedure CAMEL_ICH_MSC_INIT (sheet 2) Figure 4.69-3: Procedure CAMEL_ICH_MSC_INIT (sheet 3) Figure 4.69-4: Procedure CAMEL_ICH_MSC_INIT (sheet 4) Figure 4.69-5: Procedure CAMEL_ICH_MSC_INIT (sheet 5) Figure 4.70-1: Procedure CAMEL_MT_VMSC_Notify_CF (sheet 1) Figure 4.70-2: Procedure CAMEL_MT_VMSC_Notify_CF (sheet 2) Figure 4.71-1: Procedure CAMEL_ICH_LEG2_MSC (sheet 1) Figure 4.71-2: Procedure CAMEL_ICH_LEG2_MSC (sheet 2) Figure 4.71-3: Procedure CAMEL_ICH_LEG2_MSC (sheet 3) Figure 4.71-4: Procedure CAMEL_ICH_LEG2_MSC (sheet 4) Figure 4.71-5: Procedure CAMEL_ICH_LEG2_MSC (sheet 5) Figure 4.71-6: Procedure CAMEL_ICH_LEG2_MSC (sheet 6) Figure 4.71-7: Procedure CAMEL_ICH_LEG2_MSC (sheet 7) Figure 4.71-8: Procedure CAMEL_ICH_LEG2_MSC (sheet 8) Figure 4.71-9: Procedure CAMEL_ICH_LEG2_MSC (sheet 9) Figure 4.72-1: Process CAMEL_ICH_LEG2_CF_MSC (sheet 1) Figure 4.72-2: Process CAMEL_ICH_LEG2_CF_MSC (sheet 2) Figure 4.73-1: Process CAMEL_ICH_LEG1_MSC (sheet 1) Figure 4.73-2: Process CAMEL_ICH_LEG1_MSC (sheet 2) Figure 4.73-3: Process CAMEL_ICH_LEG1_MSC (sheet 3) Figure 4.73-4: Process CAMEL_ICH_LEG1_MSC (sheet 4) Figure 4.73-5: Process CAMEL_ICH_LEG1_MSC (sheet 5) Figure 4.74-1: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 1) Figure 4.74-2: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 2) Figure 4.74-3: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 3) Figure 4.74-4: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 4) Figure 4.74-5: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 5) Figure 4.74-6: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 6) Figure 4.74-7: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 7) Figure 4.75-1: Process CAMEL_T_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.75-2: Procedure CAMEL_T_CHANGE_OF_POSITION_MSC (sheet 2) 4.5.4.2 Handling of mobile terminating calls in the VLR The functional behaviour of the terminating VLR is specified in 3GPP TSÊ23.018Ê[12]. The process specific to CAMEL is specified in this subclause: - Process Reconnected_MT_Call_VLR. The behaviour specific to CAMEL is: - the inclusion of the O CSI and/or D CSI parameter in the Send Info For Incoming Call ack information flow if the call is to be forwarded and O CSI and/or D CSI is included in the subscriber data for that subscriber in the VLR; - the inclusion of the suppression of announcements parameter in the Send Info For Incoming Call negative response information flow if it was received in the Provide Roaming Number information flow from the HLR. Figure 4.76-1: Process Reconnected_MT_Call_VLR (sheet 1) 4.5.5 Handling of forwarded calls The handling of forwarded calls in the GMSC or the terminating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The processes and procedures specific to CAMEL are specified in this subclause. - Procedure CAMEL_Check_ORLCF_VMSC; - Procedure CAMEL_CF_MSC_INIT; - Procedure CAMEL_CF_MSC_ALERTING; - Procedure CAMEL_CF_MSC_ANSWER; - Procedure CAMEL_CF_ETC; - Procedure CAMEL_CF_CTR; - Procedure CAMEL_MT_CF_LEG1_MSC; - Process CAMEL_MT_CF_LEG2_MSC; - Procedure CAMEL_MF_RECONNECT_MSC. The procedure CAMEL_MT_CF_LEG1_MSC supervises the originating party only. The process CAMEL_MT_CF_LEG2_MSC supervises the forwarding-to party only. Hence, signals from the originating exchange are received by the procedure CAMEL_MT_CF_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_MT_CF_LEG2_MSC. A mobile terminated call can be forwarded either in the GMSC (indicated by provision of Forwarded-To-Number from the HLR or gsmSCF) or in the MSC (indicated by provision of Forwarded-To-Number from the VLR). 4.5.5.1 Procedure CAMEL_CF_MSC_INIT: handling of Int_Continue_With_Argument The received parameters are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]). Call parameters which are not included in the Int_Continue_With_Argument signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.5.2 Procedure CAMEL_CF_MSC_INIT: handling of Int_Connect The received parameters are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]. Call parameters which are not included in the Int_Connect signal are unchanged. As a network operator option, loop prevention mechanisms may cause the redirection information to be ignored or modified (e.g., if the Redirection counter has been decreased). Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. 4.5.5.3 Procedure CAMEL_CF_MSC_INIT: handling of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.5.4 Action of the MSC in procedure CAMEL_CF_MSC_ANSWER If the MSC received a destination address from the GMSC in the ISUP Answer or ISUP Connect Message then the MSC relays the destination address to the gsmSSF in the Int_DP_O_Answer signal. 4.5.5.5 Action of the MSC in procedure CAMEL_CF_ETC In procedure CAMEL_CF_ETC (sheet 2) the GMSC or terminating VMSC will remain in the Wait_For_Assisting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). Figure 4.77-1: Procedure CAMEL_Check_ORLCF_VMSC (sheet 1) Figure 4.77-2: Procedure CAMEL_Check_ORLCF_VMSC (sheet 2) Figure 4.78-1: Procedure CAMEL_CF_Dialled_Services (sheet 1) Figure 4.79-1: Procedure CAMEL_CF_MSC_INIT (sheet 1) Figure 4.79-2: Procedure CAMEL_CF_MSC_INIT (sheet 2) Figure 4.79-3: Procedure CAMEL_CF_MSC_INIT (sheet 3) Figure 4.79-4: Procedure CAMEL_CF_MSC_INIT (sheet 4) Figure 4.80-1: Procedure CAMEL_SDS_CF_INIT (sheet 1) Figure 4.80-2: Procedure CAMEL_SDS_CF_INIT (sheet 2) Figure 4.80-3: Procedure CAMEL_SDS_CF_INIT (sheet 3) Figure 4.80-4: Procedure CAMEL_SDS_CF_INIT (sheet 4) Figure 4.81-1: Procedure CAMEL_NDS_CF_INIT (sheet 1) Figure 4.81-2: Procedure CAMEL_NDS_CF_INIT (sheet 2) Figure 4.81-3: Procedure CAMEL_NDS_CF_INIT (sheet 3) Figure 4.81-4: Procedure CAMEL_NDS_CF_INIT (sheet 4) Figure 4.82-1: Procedure CAMEL_CF_MSC_ALERTING (sheet 1) Figure 4.82-2: Procedure CAMEL_CF_MSC_ALERTING (sheet 2) Figure 4.82-3: Procedure CAMEL_CF_MSC_ALERTING (sheet 3) Figure 4.83-1: Procedure CAMEL_CF_MSC_ANSWER (sheet 1) Figure 4.83-2: Procedure CAMEL_CF_MSC_ANSWER (sheet 2) Figure 4.83-3: Procedure CAMEL_CF_MSC_ANSWER (sheet 3) Figure 4.84-1: Procedure CAMEL_CF_ETC (sheet 1) Figure 4.84-2: Procedure CAMEL_CF_ETC (sheet 2) Figure 4.84-3: Procedure CAMEL_CF_ETC (sheet 3) Figure 4.84-4: Procedure CAMEL_CF_ETC (sheet 4) Figure 4.85-1: Procedure CAMEL_CF_CTR (sheet 1) Figure 4.85-2: Procedure CAMEL_CF_CTR (sheet 2) Figure 4.85-3: Procedure CAMEL_CF_CTR (sheet 3) Figure 4.85-4: Procedure CAMEL_CF_CTR (sheet 4) Figure 4.85-5: Procedure CAMEL_CF_CTR (sheet 5) Figure 4.86-1: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 1) Figure 4.86-2: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 2) Figure 4.86-3: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 3) Figure 4.86-4: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 4) Figure 4.86-5: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 5) Figure 4.86-6: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 6) Figure 4.86-7: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 7) Figure 4.87-1: Process CAMEL_MT_CF_LEG2_MSC (sheet 1) Figure 4.87-2: Process CAMEL_MT_CF_LEG2_MSC (sheet 2) Figure 4.88-1: Procedure CAMEL_MF_RECONNECT_MSC (sheet 1) Figure 4.88-2: Procedure CAMEL_MF_RECONNECT_MSC (sheet 2) Figure 4.88-3: Procedure CAMEL_MF_RECONNECT_MSC (sheet 3) Figure 4.88-4: Procedure CAMEL_MF_RECONNECT_MSC (sheet 4) Figure 4.88-5: Procedure CAMEL_MF_RECONNECT_MSC (sheet 5) Figure 4.88-6: Procedure CAMEL_MF_RECONNECT_MSC (sheet 6) 4.5.6 Handling of gsmSCF initiated calls 4.5.6.1 Handling of gsmSCF initiated calls in the MSC Handling of gsmSCF initiated calls in the MSC involves the following process and procedures: - Process CAMEL_ICA_MSC; - Procedure CAMEL_ICA_MSC_ALERTING; - Procedure CAMEL_ICA_MSC_ANSWER; - Procedure CAMEL_ICA_MSC1; - Procedure CAMEL_ICA_MSC2; - Procedure CAMEL_ICA_Dialled_Services. The Process CAMEL_ ICA_MSC handles both gsmSCF initiated new calls and gsmSCF initiated new parties. The following paragraphs give details on the behaviour of the MSC in the process CAMEL_ICA_MSC. 4.5.6.1.1 Actions of the MSC on receipt of Int_Error The process CAMEL_ICA_MSC returns to idle. 4.5.6.1.2 Actions of the MSC on receipt of Int_Continue The MSC continues processing without any modification of call parameters. 4.5.6.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument The MSC continues processing with modification of call parameters. 4.5.6.1.4 Actions of the MSC on receipt of Int_Disconnect_Leg A Release is sent to the destination exchange if required. The release cause received in the Int_Disconnect_Leg signal is used. The process CAMEL_ICA_MSC returns to idle. 4.5.6.1.5 Actions of the MSC on receipt of Int_Release_Call A Release is sent to the destination exchange if required. The release cause received in the Int_Release_Call signal is used. The MSC then releases all call resources and the process CAMEL_ ICA_MSC returns to idle. Figure 4.89-1: Process CAMEL_ICA_MSC (sheet 1) Figure 4.89-2: Process CAMEL_ICA_MSC (sheet 2) Figure 4.89-3: Process CAMEL_ICA_MSC (sheet 3) Figure 4.89-4: Process CAMEL_ICA_MSC (sheet 4) Figure 4.89-5: Process CAMEL_ICA_MSC (sheet 5) Figure 4.89-6: Process CAMEL_ICA_MSC (sheet 6) Figure 4.89-7: Process CAMEL_ICA_MSC (sheet 7) Figure 4.89-8: Process CAMEL_ICA_MSC (sheet 8) Figure 4.89-9: Process CAMEL_ICA_MSC (sheet 9) Figure 4.90-1: Procedure CAMEL_ICA_MSC_ALERTING (sheet 1) Figure 4.90-2: Process CAMEL_ICA_MSC_ALERTING (sheet 2) Figure 4.90-3: Process CAMEL_ICA_MSC_ALERTING (sheet 3) Figure 4.91-1: Procedure CAMEL_ICA_MSC_ANSWER (sheet 1) Figure 4.91-2: Process CAMEL_ICA_MSC_ANSWER (sheet 2) Figure 4.91-3: Process CAMEL_ICA_MSC_ANSWER (sheet 3) Figure 4.92-1: Procedure CAMEL_ICA_MSC1 (sheet 1) Figure 4.93-1: Procedure CAMEL_ICA_MSC2 (sheet 1) Figure 4.94-1: Procedure CAMEL_ICA_Dialled_Services (sheet 1) 4.5.6.2 Handling of gsmSCF initiated calls in the VLR Handling of gsmSCF initiated calls in the VLR involves the following process and procedures: - Process CAMEL_ICA_VLR. Figure 4.95-1: Process CAMEL_ICA_VLR (sheet 1) Figure 4.95-2: Process CAMEL_ICA_VLR (sheet 2) 4.5.7 Handling of mobile calls in the gsmSSF Handling of mobile calls in the gsmSSF involves the following processes and procedures: - Process CS_gsmSSF; - Procedures and process Check_Criteria; - Procedure Connect_To_Resource; - Procedure Handle_AC; - Procedure Handle_ACR; - Procedure Handle_CIR; - Procedure Handle_CIR_leg; - Procedure Complete_FCI_record; - Procedure Complete_all_FCI_records; - Procedure Handle_SCI; - Process CSA_gsmSSF; - Procedure Handle_O_Answer; - Procedure Handle_T_Answer. The detailed error handling for the process CS_gsmSSF and the associated procedures is specified in 3GPP TSÊ29.078Ê([36]). 4.5.7.1 Call duration control 4.5.7.1.1 Information flow for call duration control The following diagram shows the handling of the different timers that are used in the process CS_gsmSSF and in the procedures Handle_AC, Handle_ACR, Handle_CIR. Timers Tssf, Tcp, Tsw, Tw and DELTA are defined in the process CS_gsmSSF. Figure 4.96: Information flow for call control duration The following diagram shows an example of the handling of call duration control for CPH configurations. Figure 4.96a: Information flow for call control duration in CPH configurations 4.5.7.1.2 Audible indicators for call duration control The gsmSCF may instruct the gsmSSF to play either a fixed sequence of tones or a variable sequence of tones with the Apply Charging information flow. The gsmSCF may also instruct the gsmSSF to play a variable sequence of tones with the Play Tone information flow. For the case of the fixed sequence of tones, the gsmSSF shall play a single sequence of three tones. The duration of each of the tones shall be 200Êmilliseconds with an intertone interval of 200Êmilliseconds. This shall be played 30Êseconds before the end of a call period. For the case of a variable sequence of tones, or a burst list, the gsmSCF shall indicate the number of tones per burst, the number of bursts to be played, the tone duration, interval between the tones and the interval between the bursts. In addition, the gsmSCF shall indicate in the Apply Charging information flow, the warning time before call period expiry at which the playing of the burst list shall start. FigureÊ4.97 provides a graphical representation of the variable burst list in the case where there are three tones per burst and three bursts in the burst list. The Warning Period in figureÊ4.97 applies to the Apply Charging information flow only. Figure 4.97: Representation of burst list 4.5.7.2 The gsmSCF control of e values 4.5.7.2.1 Procedure Handle_SCI There are independent Tariff Switch Timers for the control of the call duration Tsw(pty) and for the gsmSCF control of e values Tsw(SCI). The gsmSCF control of e values is via the Send Charging Information information flow. The following terminology has been used for e parameters: - Applicable and in use. The set of e parameters is currently applicable in the MSC and the set has been sent to the MS. - Applicable but waiting. The set of e parameters is currently applicable in the MSC but the set has not yet been sent to the MS. - Applicable but not in use. The set of e parameters is currently applicable in the MSC but it cannot be sent to the MS, e.g. because the Advice of Charge supplementary service is not subscribed. - Stored. The set of e parameters is not yet applicable. The stored set of e parameters becomes applicable when a tariff switch occurs. The table below defines the actions of the Procedure Handle_SCI. Table 4.6: Handling of SCI in the gsmSSF received Tsw(SCI) and set of e parameters in the SCI information flow Primary dialogue (note 1) Secondary dialogue (noteÊ2,Ê8) no active call / SRF connection active call / SRF connection Tsw(SCI) not running and no e parameters stored Tsw(SCI) running and e parameters stored Tsw(SCI) not running and no e parameters stored Tsw(SCI) running and e parameters stored Tsw(SCI) not received 1 set send 1st set to MSC stop Tsw(SCI); discard stored set; send 1st set to MSC send 1st set to MSC stop Tsw(SCI); discard stored set; send 1st set to MSC send 1st set to MSC Tsw(SCI) not received 2 sets error error error error error Tsw(SCI) received 1 set error error store 1st set; start Tsw(SCI) stop Tsw(SCI); discard stored set; store 1st set; start new Tsw(SCI) error Tsw(SCI) received 2 sets send 1st set to MSC, store 2nd set; start Tsw(SCI) stop Tsw(SCI); discard stored set; send 1st set to MSC; store 2nd set; start new Tsw(SCI) error error send 1st set to MSC; store 2nd set; start Tsw(SCI) NOTEÊ1: Primary dialogue: The primary dialogue is initiated due to TDPÊCollected_Info, TDPÊAnalysed_Information, or TDPÊRoute_Select_Failure, TDPÊTerminating_Attempt_Authorised, TDPÊT_Busy or TDP T_No_Answer. A dialogue initiated due to TDP Analysed_Information is only the primary dialogue, if there is no ongoing dialogue due to TDP Collected_Info. NOTEÊ2: Secondary dialogue: The secondary dialogue is initiated due to TDPÊAnalysed_Information. NOTEÊ3: The condition ""active call / SRF connection"" is true if there is at least one active leg in this call (CSA) or if an SRF is connected to a Call Segment in this CSA. Incoming legs are active after an answer is sent and before the leg begins to release. Outgoing legs are active after an answer is received and before the leg is begins to release. NOTEÊ4: If the gsmSSF sends a set of e parameters to the MSC this will overwrite the current set of e parameters in the MSC, if e parameters are applicable in the MSC. NOTEÊ5: The MSC shall store the received e parameters to be sent subsequently to the MS. The MSC shall send these e parameters to the MS in a Connect message or in a Facility message. NOTEÊ6: Secondary dialogue gsmSCF can only give e parameter(s)/Tsw(SCI) when they have not previously been provided by the primary dialogue gsmSCF. After secondary dialogue gsmSCF gives e parameter(s) / Tsw(SCI), Primary dialogue gsmSCF shall not give further on-line charging instructions (i.e. Send Charging Information). For D CSI, this is ensured by service subscription restriction by a home network operator. For N CSI, this is ensured by a roaming agreement between the home network operator and the visited network operator or is only applicable within a home network. NOTEÊ7: When a gsmSCF relationship is closed then the stored e parameters given by that dialogue are discarded. Any Tariff Switch timer (Tsw(SCI)) is also stopped when the gsmSCF relationship is closed. If the gsmSCF has given any e parameters which are not stored but which are applicable (regardless of whether they are applicable and in use, applicable but waiting, or applicable but not in use) when the gsmSCF relationship is closed, those e parameters are also valid after the gsmSCF relationship is closed. If any subsequent CAP dialogues give e parameters those new e parameters shall overwrite the applicable e parameters given by the preceding CAP dialogues. NOTEÊ8: The secondary dialogue is not applicable to VT calls. NOTE 9: Service Logic designers shall take care when using SCI in both primary dialogue and secondary dialogue, if these dialogues use different versions of CAMEL. In such a case it is e.g. possible that a Tariff Switch timer (Tsw(SCI))Êinformation received in the primary dialogue is overwritten by a Tariff Switch timer (Tsw(SCI)) information received in the secondary dialogue. 4.5.7.2.2 Process Tsw_For_SCI The process Tsw_For_SCI exists per call. That is there is one process instance per CSA. The Tariff Switch Timers for the gsmSCF control of e values Tsw(SCI). Figure 4.98-1: Process Tsw_For_SCI (sheet 1) Figure 4.98-2: Process Tsw_For_SCI (sheet 2) 4.5.7.3 Behaviour of the gsmSSF in the process CS_gsmSSF The following paragraphs give details on the behaviour of the gsmSSF in the process CS_gsmSSF. 4.5.7.3.1 Actions of the gsmSSF on receipt of CAP_Request_Report_BCSM_Event (in the state Waiting_For_Instructions) The process CS_gsmSSF arms the requested EDP, if the arming rules are fulfilled and returns to the state Waiting_For_Instructions. The gsmSCF may request EDPs for any one or more of Answer, Busy, No Answer, Abandon, Route Select Failure and Disconnect event for a party in the call. 4.5.7.3.2 Actions of the gsmSSF on receipt of CAP_Continue (in the state Waiting_For_Instructions) An Int_Continue signal is sent to instruct the GMSC or MSC to continue the call set-up with the original call parameters. 4.5.7.3.3 Actions of the gsmSSF on receipt of CAP_Release_Call (in the state Monitoring) When a control relationship exists between the gsmSCF and gsmSSF (at least one EDP R is armed), the gsmSCF may spontaneously instruct the gsmSSF to release the call at any time using the Release Call information flow. The Release Call information flow shall not be sent from the gsmSCF if only monitor relationship exists between the gsmSSF and the gsmSCF. 4.5.7.3.4 Actions of the gsmSSF on receipt of Int_DP_T_Busy or Int_DP_T_No_Answer including the parameter Call Forwarded (in the state Monitoring) If the handling of Int_DP_T_Busy signal or Int_DP_T_No_Answer signal including the parameter Call Forwarded leads to the gsmSSF sending a CAP_Event_Report_BCSM to the gsmSCF, the gsmSSF shall include the parameter Call Forwarded in the Event Specific Information BCSM. 4.5.7.4 Outstanding Request Counter and Rules for CAMEL In the following the rules on handling of the 'outstanding requests' variables in the process CS_gsmSSF are given. They are storing the number of required resumptions. 1) There shall be one outstanding requests variable ORC_Leg (legID) per leg to handle TDP R and EDP R reports and ICA. 2) In addition there shall be one outstanding requests variable ORC_CS (CSID) per call segment to handle the CPH IFs. 3) A leg will only be resumed if the ORC_Leg (legID) variable for this leg and the ORC_CS (CSID) for the call segment containing the leg are 0. 4) Events that cause the suspension of the call processing are signalling events armed as TDP Rs or EDP Rs, or the processing of a CPH IF (Disconnect Leg, Split Leg or Move Leg) or Initiate Call Attempt sent by the gsmSCF. a) For TDP R or EDP R events the number of required resumptions relative to the associated leg will be incremented by 1. For TDP-R, the associated leg is always leg 2. b) For CPH IFs the number of required resumptions per call segment will be set to one if it is still 0. Otherwise the number of resumptions remains unchanged. For Split Leg the number of required resumptions for each of the source call segment and the target call segment will be set to one if it is still 0 c) For ICA the number of required resumptions relative to the associated leg will be set to 1. 5) In addition the CS_gsmSSF stores information about the events (DP with the associated leg, CPH) that require resumption and keep track of the order of events for TDP Rs and EDP Rs for each leg . The order of resumptions for a leg shall be the order in which the suspension events occured for that leg. 6) For DP event resumption Continue with Argument with legID or Continue are valid. If not otherwise stated below, for each received resumption the number of required resumption for that leg will be decremented by 1 if it was a valid resumption for the event that has to be handled first. Decrementing of the outstanding requests variables does not go below 0. 7) For CPH resumption Continue with Argument with CSID is valid. On receipt of the resumption the number of required resumptions for that call segment will be set to 0. 8) For ICA resumption Continue with Argument with LegId is valid. On receipt of the resumption the number of required resumptions for that Leg will be set to 0. 9) If Continue with Argument with neither LegID nor CSID is received, then the number of resumptions required for the leg that was reported will be decremented by 1. If reporting is performed on more than one leg, then the related leg will be selected following the sequence of the reporting. 10) If Continue is received, then the number of resumptions required for the leg that was reported will be decremented by 1. If reporting is performed on more than one leg, then the related leg will be selected following the sequence of the reporting. 11) The processing of a Connect with a LegID causes the number of required resumptions for that leg to be decremented by 1. The processing of a Connect without a LegID causes the number of resumptions for the LegID = 2 to be set to 0. 12) The processing of Tssf expiry and of TC Abort causes the number of resumptions required to be set to 0 and the call processing to be resumed. All stored resumption events are discarded. 13) On receipt of a Disconnect Leg the number of resumptions required for the corresponding leg is set to 0. 14) If Release Call is used, nothing needs to be resumed. 4.5.7.5 Process CS_gsmSSF and procedures Figure 4.99-1: Process CS_gsmSSF (sheet 1) Figure 4.99-2: Process CS_gsmSSF (sheet 2) Figure 4.99-3: Process CS_gsmSSF (sheet 3) Figure 4.99-4: Process CS_gsmSSF (sheet 4) Figure 4.99-5: Process CS_gsmSSF (sheet 5) Figure 4.99-6: Process CS_gsmSSF (sheet 6) Figure 4.99-7: Process CS_gsmSSF (sheet 7) Figure 4.99-8: Process CS_gsmSSF (sheet 8) Figure 4.99-9: Process CS_gsmSSF (sheet 9) Figure 4.99-10: Process CS_gsmSSF (sheet 10) Figure 4.99-11: Process CS_gsmSSF (sheet 11) Figure 4.99-12: Process CS_gsmSSF (sheet 12) Figure 4.99-13: Process CS_gsmSSF (sheet 13) Figure 4.99-14: Process CS_gsmSSF (sheet 14) Figure 4.99-15: Process CS_gsmSSF (sheet 15) Figure 4.99-16: Process CS_gsmSSF (sheet 16) Figure 4.99-17: Process CS_gsmSSF (sheet 17) Figure 4.99-18: Process CS_gsmSSF (sheet 18) Figure 4.99-19: Process CS_gsmSSF (sheet 19) Figure 4.99-20: Process CS_gsmSSF (sheet 20) Figure 4.99-21: Process CS_gsmSSF (sheet 21) Figure 4.99-21A: Process CS_gsmSSF (sheet 21A) Figure 4.99-22: Process CS_gsmSSF (sheet 22) Figure 4.99-23: Process CS_gsmSSF (sheet 23) Figure 4.99-24: Process CS_gsmSSF (sheet 24) Figure 4.99-25: Process CS_gsmSSF (sheet 25) Figure 4.99-26: Process CS_gsmSSF (sheet 26) Figure 4.99-27: Process CS_gsmSSF (sheet 27) Figure 4.99-28: Process CS_gsmSSF (sheet 28) Figure 4.99-29: Process CS_gsmSSF (sheet 29) Figure 4.99-29a: Process CS_gsmSSF (sheet 29a) Figure 4.99-30: Process CS_gsmSSF (sheet 30) Figure 4.99-31: Process CS_gsmSSF (sheet 31) Figure 4.99-32: Process CS_gsmSSF (sheet 32) Figure 4.99-33: Process CS_gsmSSF (sheet 33) Figure 4.99-34: Process CS_gsmSSF (sheet 34) Figure 4.99-35: Process CS_gsmSSF (sheet 35) Figure 4.99-36: Process CS_gsmSSF (sheet 36) Figure 4.99-37: Process CS_gsmSSF (sheet 37) Figure 4.99-38: Process CS_gsmSSF (sheet 38) Figure 4.99-39: Process CS_gsmSSF (sheet 39) Figure 4.99-40: Process CS_gsmSSF (sheet 40) Figure 4.99-41: Process CS_gsmSSF (sheet 41) Figure 4.99-42: Process CS_gsmSSF (sheet 42) Figure 4.99-43: Process CS_gsmSSF (sheet 43) Figure 4.99-44: Process CS_gsmSSF (sheet 44) Figure 4.99-45: Process CS_gsmSSF (sheet 45) Figure 4.99-46: Process CS_gsmSSF (sheet 46) Figure 4.99-47: Process CS_gsmSSF (sheet 47) Figure 4.99-48: Process CS_gsmSSF (sheet 48) Figure 4.99-49: Process CS_gsmSSF (sheet 49) Figure 4.99-50: Process CS_gsmSSF (sheet 50) Figure 4.99-51: Process CS_gsmSSF (sheet 51) Figure 4.99-52: Process CS_gsmSSF (sheet 52) Figure 4.99-53: Process CS_gsmSSF (sheet 53) Figure 4.99-54: Process CS_gsmSSF (sheet 54) Figure 4.99-55: Process CS_gsmSSF (sheet 55) Figure 4.99-56: Process CS_gsmSSF (sheet 56) Figure 4.99-57: Process CS_gsmSSF (sheet 57) Figure 4.99-58: Process CS_gsmSSF (sheet 58) Figure 4.99-59: Process CS_gsmSSF (sheet 59) Figure 4.99-60: Process CS_gsmSSF (sheet 60) Figure 4.99-61: Process CS_gsmSSF (sheet 61) Figure 4.99-62: Process CS_gsmSSF (sheet 62) Figure 4.100-1: Procedure Check_Criteria_Collected_Info (sheet 1) Figure 4.101-1: Procedure Check_Criteria_Analysed_Info (sheet 1) Figure 4.102-1: Procedure Check_Criteria_Unsuccessful (sheet 1) Figure 4.103-1: Procedure Connect_To_Resource (sheet 1) Figure 4.104-1: Procedure Handle_AC (sheet 1) Figure 4.105-1: Procedure Handle_ACR (sheet 1) Figure 4.106-1: Procedure Handle_CIR (sheet 1) Figure 4.107-1: Procedure Handle_CIR_leg (sheet 1) Figure 4.108-1: Procedure Complete_FCI_record (sheet 1) Figure 4.109-1: Procedure Complete_all_FCI_records (sheet 1) Figure 4.110-1: Procedure Handle_O_Answer (sheet 1) Figure 4.111-1: Procedure Handle_T_Answer (sheet 1) Figure 4.112-1: Procedure UpdateSignalling (sheet 1) 4.5.7.6 Process gsmSSF_SSME_FSM and procedures One process is instantiated for each Call Gap information flow received from a gsmSCF. Figure 4.113-1: Process gsm_SSME_SSF (sheet 1) Figure 4.113-2: Process gsm_SSME_SSF (sheet 2) NOTE: CG Int and CG Reject internal variables are initiated with False value. Figure 4.114-1: Procedure Store_Call_Gap_Criteria (sheet 1) Figure 4.115-1: Procedure Check_Gap_Criteria (sheet 1) Figure 4.115A-1: Procedure Check_Criteria_for_TOC (sheet 1) 4.5.7.7 Process CSA_gsmSSF and procedures The call gap information flow can only be received for an opened transaction between the CSA_gsmSSF and the gsmSCF. Figure 4.116-1: Process CSA_gsmSSF (sheet 1) Figure 4.116-2: Process CSA_gsmSSF (sheet 2) Figure 4.116-3: Process CSA_gsmSSF (sheet 3) Figure 4.116-4: Process CSA_gsmSSF (sheet 4) Figure 4.116-5: Process CSA_gsmSSF (sheet 5) Figure 4.116-6: Process CSA_gsmSSF (sheet 6) Figure 4.116-7: Process CSA_gsmSSF (sheet 7) Figure 4.116-8: Process CSA_gsmSSF (sheet 8) Figure 4.116-9: Process CSA_gsmSSF (sheet 9) Figure 4.116-10: Process CSA_gsmSSF (sheet 10) Figure 4.116-11: Process CSA_gsmSSF (sheet 11) Figure 4.116-12: Process CSA_gsmSSF (sheet 12) Figure 4.116-13: Process CSA_gsmSSF (sheet 13) Figure 4.116-14: Process CSA_gsmSSF (sheet 14) Figure 4.116-15: Process CSA_gsmSSF (sheet 15) Figure 4.116-16: Process CSA_gsmSSF (sheet 16) Figure 4.116-17: Process CSA_gsmSSF (sheet 17) Figure 4.116-18: Process CSA_gsmSSF (sheet 18) Figure 4.116-19: Process CSA_gsmSSF (sheet 19) Figure 4.116-20: Process CSA_gsmSSF (sheet 20) Figure 4.116-21: Process CSA_gsmSSF (sheet 21) Figure 4.116-22: Process CSA_gsmSSF (sheet 22) Figure 4.116-23: Process CSA_gsmSSF (sheet 23) 4.5.8 Assisting case Assisting case involves the following processes: - CAMEL_Assisting_MSC, - Assisting_gsmSSF. The detailed error handling for these 2 processes is specified in 3GPP TSÊ29.078Ê[36]. Figure 4.117-1: Process CAMEL_Assisting_MSC (sheet 1) Figure 4.117-2: Process CAMEL_Assisting_MSC (sheet 2) Figure 4.117-3: Process CAMEL_Assisting_MSC (sheet 3) Figure 4.118-1: Process Assisting_gsmSSF (sheet 1) Figure 4.118-2: Process Assisting_gsmSSF (sheet 2) Figure 4.118-3: Process Assisting_gsmSSF (sheet 3) Figure 4.118-4: Process Assisting_gsmSSF (sheet 4) Figure 4.118-5: Process Assisting_gsmSSF (sheet 5) Figure 4.118-6: Process Assisting_gsmSSF (sheet 6) 4.5.9 Procedure CAMEL_Provide_Subscriber_Info The procedure CAMEL_Provide_Subscriber_Info is called either during Retrieval of routeing information in the HLR or as a result of reception of the Any Time Interrogation information flow from the gsmSCF. The HLR sends a Provide Subscriber Info information flow to the VLR or SGSN dependent on the setting of the parameter ""requested domain"" received from the calling process. If the VLR or SGSN returns a Provide Subscriber Info ack information flow, then the HLR uses the received information to set the Subscriber Info to be returned to the calling process. As a network option, the HLR may use the information received from the VLR, such as Cell Id, Location Area Id or Service Area Id, to derive the Location Number and/or Geographical Information. The HLR may use the information received from the SGSN, such as Cell Id, Location Area Id, Service Area Id or Routeing Area Identity, to derive the Location Number and/or Geographical Information. This mapping is network-specific and outside the scope of the present document. NOTE: The handling in the VLR of Provide Subscriber Info is defined in 3GPP TSÊ23.018Ê[12]."
"The handling in the SGSN of Provide Subscriber Info is defined in clauseÊ11. Figure 4.119-1: Procedure CAMEL_Provide_Subscriber_Info (sheet 1) Figure 4.119-2: Procedure CAMEL_Provide_Subscriber_Info (sheet 2) 4.5.10 CAMEL specific handling of location updating and data restoration When requesting a location update or data restoration the VLR shall indicate to the HLR which CAMEL phases it supports and which CAMEL phaseÊ4 CSIs can be downloaded. The HLR may then send CAMEL subscription data to the VLR or, if some different handling is required, data for substitute handling. The CAMEL subscription data sent by the HLR shall comply with the indication of supported CAMEL phases and supported CAMEL phase 4 CSIs as received from the VLR. When the location update has been completed, the MSC/VLR in which the subscriber is registered after the location update shall check the M CSI. If a Mobility Management notification to the gsmSCF is required for this subscriber, then the MSC/VLR shall send the notification to the gsmSCF. Refer to subclauseÊ9.2.1 for a description of M CSI and the conditions under which a notification shall be sent. 4.5.11 Cross phase compatibility To avoid a case by case fallback between the gsmSSF and the gsmSCF, the gsmSSF shall use the CAP phase corresponding to the CAMEL phase negotiated on the HLR-VLR interface when it opens a dialogue with the gsmSCF. The HLR-VLR negotiation of CAMEL phase is per subscriber. 4.5.12 Handling of North American Carrier Information The following procedures apply only when the HPLMN of the CAMEL subscriber and either the VPLMN (for a mobile originated or forwarded call) or the IPLMN (for a mobile terminated call or forwarded call) are both North American. A gsmSCF may then provide the gsmSSF with any of the following North American (NA) carrier related information items. - NA Carrier Information; - NA Originating Line Information; - NA Charge Number. A gsmSSF shall use the received information items both to select any long distance carrier needed for the call and to provide certain information needed by this carrier. Any required information items not received shall be defaulted to those that would normally apply to the call in the absence of an interaction with a gsmSCF. If any NA information item received from the gsmSCF is found to be invalid, the gsmSSF may either, as an operator option, release the call or behave as if the invalid information item had not been sent. If the carrier specified in the Carrier parameter is not supported in the VPLMN or IPLMN, the gsmSSF may either, as an operator option, release the call or substitute for the unsupported carrier a preferred carrier of the VPLMN or IPLMN. Support of the NA Originating Line Information and Charge Number parameters is an operator option in a VPLMN based on roaming agreements with the operators of other PLMNs, A gsmSSF may ignore these items when received from certain or all gsmSCFs located in other PLMNs and replace them with the corresponding default items for an MO, MF, MT or VT call. 4.5.13 Handling of trunk originated calls The handling of trunk originated calls in the inter-connecting MSC is specified in 3GPP TSÊ23.018Ê[12] subclause 7.5. The processes and procedures specific to CAMEL are specified in this subclause. - Procedure CAMEL_TOC_Dialled_Services; - Procedure CAMEL_TOC_MSC_INIT; - Procedure CAMEL_NDS_TOC_INIT; - Procedure CAMEL_TOC_LEG1_MSC. The procedure CAMEL_TOC_LEG1_MSC supervises the originating party only. The process CAMEL_MT_CF_LEG2_MSC supervises the called-to party only. Hence, signals from the originating exchange are received by the procedure CAMEL_TOC_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_MT_CF_LEG2_MSC. 4.5.13.1 Procedure CAMEL_TOC_Dialled_Services Void 4.5.13.2 Procedure CAMEL_TOC_MSC_INIT Sheet 1: Decision ""First procedure call"": The procedure call formal parameter (FPAR) values ""First"" or ""NotFirst"" indicate whether the gsmSSF instance has been invoked for this call at the Collected_Information DP. - First_ The gsmSSF has not been invoked. - NotFirst: The gsmSSF has been invoked earlier and the gsmSSF is waiting for additional digits. The gsmSSF may not have triggered a CAP dialogue to gsmSCF. 4.5.13.3 Procedure CAMEL_NDS_TOC_INIT Sheet 1: Decision ""First procedure call"": The procedure call formal parameter (FPAR) values ""First"" or ""NotFirst"" indicate whether the gsmSSF instance has been invoked for this call at Analysed_Information DP. The dialled services invoke a different instance of gsmSSF than at the Collected_Information DP. - First_ The gsmSSF has not been invoked. - NotFirst: The gsmSSF has been invoked earlier and the gsmSSF is waiting for additional digits. The gsmSSF may not have triggered a CAP dialogue to gsmSCF. 4.5.13.4 Procedure CAMEL_TOC_LEG1_MSC Void Figure 4.119A-1: Procedure CAMEL_TOC_Dialled_Services (sheet 1) Figure 4.119B-1: Procedure CAMEL_TOC_MSC_INIT (sheet 1) Figure 4.119B-2: Procedure CAMEL_TOC_MSC_INIT (sheet 2) Figure 4.119B-3: Procedure CAMEL_TOC_MSC_INIT (sheet 3) Figure 4.119B-4: Procedure CAMEL_TOC_MSC_INIT (sheet 4) Figure 4.119B-5: Procedure CAMEL_TOC_MSC_INIT (sheet 5) Figure 4.119B-6: Procedure CAMEL_TOC_MSC_INIT (sheet 6) Figure 4.119B-7: Procedure CAMEL_TOC_MSC_INIT (sheet 7) Figure 4.119C-1: Procedure CAMEL_NDS_TOC_INIT (sheet 1) Figure 4.119C-2: Procedure CAMEL_NDS_TOC_INIT (sheet 2) Figure 4.119C-3: Procedure CAMEL_NDS_TOC_INIT (sheet 3) Figure 4.119C-4: Procedure CAMEL_NDS_TOC_INIT (sheet 4) Figure 4.119C-5: Procedure CAMEL_NDS_TOC_INIT (sheet 5) Figure 4.119D-1: Procedure CAMEL_TOC_LEG1_MSC (sheet 1) Figure 4.119D-2: Procedure CAMEL_TOC_LEG1_MSC (sheet 2) Figure 4.119D-3: Procedure CAMEL_TOC_LEG1_MSC (sheet 3) Figure 4.119D-4: Procedure CAMEL_TOC_LEG1_MSC (sheet 4) Figure 4.119D-5: Procedure CAMEL_TOC_LEG1_MSC (sheet 5) Figure 4.119D-6: Procedure CAMEL_TOC_LEG1_MSC (sheet 6) Figure 4.119D-7: Procedure CAMEL_TOC_LEG1_MSC (sheet 7) 4.6 Description of information flows This clause contains the detailed description of the information flows used by CAMEL for Circuit Switched call control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E), Optional (O) or not applicable (-) for each different traffic case applicable to the following CSI: - MO Mobile Originating call in the VMSC (O CSI, D CSI or N CSI dialogue); - MF Mobile Forwarded call in the VMSC or the GMSC as in figure 4.7 (O CSI, D CSI or N CSI dialogue); - MT Mobile Terminating call in the GMSC (T CSI dialogue); - VT Mobile Terminating call in the VMSC (VT CSI dialogue); - NC gsmSCF initiated new call; - NP gsmSCF initiated new party in an existing call; - TO Trunk Originating call in the MSC (TO-CSI or N-CSI dialogue). If the IEs in one table apply in all the possible cases listed above or no distinction is needed, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included for the corresponding traffic case. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted for the corresponding traffic case. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. it is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The distinction between MO, MF, MT, VT, NC, NP and TO calls is not applicable to all Information Flows. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSSF shall functionally support all IEs which can be sent to it. - The gsmSCF may silently discard any IE which it does not functionally support. - The gsmSRF shall return an error if it does not functionally support an IE which it receives. - The HLR may silently discard any IE which it does not functionally support. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.078Ê[36]. 4.6.1 gsmSSF to gsmSCF information flows 4.6.1.1 Activity Test ack 4.6.1.1.1 Description This IF is the response to the Activity Test. 4.6.1.1.2 Information Elements This IF contains no information elements. 4.6.1.2 Apply Charging Report 4.6.1.2.1 Description This IF is used by the gsmSSF to report to the gsmSCF the information requested in the Apply Charging IF. 4.6.1.2.2 Information Elements Information element name Status Description Call Result M This IE contains the charging information provided by the gsmSSF. Call Result contains the following information elements: Information element name Status Description Time Duration Charging Result M This IE is described in a table below. Time Duration Charging Result contains the following information elements: Information element name Status Description Time Information M This IE is described in a table below. Party To Charge M This IE is received in the related Apply Charging IF to correlate the result to the request. This IE shall be a copy of the corresponding IE received in the Apply Charging IF. ACh Charging Address M This IE identifies the call party to which the Apply Charging Report IF applies. This IE is described in a table below. Leg Active M This IE indicates whether the call leg is active or not. When the ACR is sent because of a change in CPH configuration legActive=FALSE shall be used. Call Leg Released At Tcp Expiry S This IE is an indication that the gsmSSF has released the call leg or the Temporary Connection or SRF Connection, due to Tcp expiry. It shall be present when Apply Charging Report is sent due to Tcp expiry and the gsmSSF has released the call leg or the Temporary Connection or SRF Connection (because 'Release If Duration Exceeded' was present in the Apply Charging IF). In all other cases, this IE shall be absent. Time Information contains the following information elements: Information element name Status Description Time If No Tariff Switch S,E This IE shall be present if no tariff switch has occurred since the reception of the first Apply Charging IF for the connection to the Called Party, the Temporary Connection, or the gsmSRF connection, otherwise it shall be absent. If Answer was detected for the connection to the Called Party, the Temporary Connection or the gsmSRF connection, then the elapsed time since detection of Answer shall be reported. For a change in a CPH configuration the particular time when the legs in a CS are connected shall be taken as Answer. If answer was not detected, it shall be set to ""0"". Time If Tariff Switch S,E This IE shall be present if a tariff switch has occurred since the reception of the first Apply Charging IF for the connection to the Called Party, the Temporary Connection, or the gsmSRF connection, otherwise it shall be absent. ACh Charging Address contains the following information elements: Information element name Status Description Leg ID E This IE indicates that the Apply Charging Report IF applies to the specified leg. SRF Connection E This IE indicates that the Apply Charging Report IF applies to the Temporary Connection or SRF Connection 4.6.1.3 Call Information Report 4.6.1.3.1 Description This IF is used to send specific call information for a single call party to the gsmSCF as requested by the gsmSCF in a previous Call Information Request IF. 4.6.1.3.2 Information Elements Information element name Status Description Requested Information List M This IE specifies the requested information. Leg ID M This IE indicates the party in the call for which information shall be collected. 4.6.1.4 Disconnect Leg ack 4.6.1.4.1 Description This IF is the successful response to the Disconnect Leg IF. 4.6.1.4.2 Information Elements This IF contains no information elements. 4.6.1.5 Entity Released 4.6.1.5.1 Description This IF is used to inform the gsmSCF about the release of a logical entity (CS or BCSM) caused by exception or errors. It is sent by the CSA FSM if this information cannot be conveyed within an TC_ABORT or TC_END because the TC dialogue has to be kept because of other existing logical entities (CS or BCSM) in this CSA which are not affected by this error/exception. This IF is not sent if the last CS was released. The IF Entity Released is not used if the release of the entity can be reported through other IFs, e.g. Event Report BCSM, Call Information Report. 4.6.1.5.2 Information Elements Information element name Status Description CS Failure E This IE indicates that an CS has been released. BCSM Failure E This IE indicates that a leg has been released. CS Failure contains the following information elements: Information element name Status Description Call Segment ID M This IE identifies the released CS. Cause C This IE indicates the cause for releasing the CS. The Cause may be used by the gsmSCF to decide how to continue the call handling. BCSM Failure contains the following information elements: Information element name Status Description Leg ID M This IE identifies the released leg. Cause C This IE indicates the cause for releasing the leg. The cause may be used by the gsmSCF to decide handling. 4.6.1.6 Event Report BCSM 4.6.1.6.1 Description This IF is used to notify the gsmSCF of a call-related event (i.e. BCSM events as answer and disconnect) previously requested by the gsmSCF in a Request Report BCSM Event IF. 4.6.1.6.2 Information Elements Information element name MO MF MT VT NC NP TO Description Event Type BCSM M M M M M M M This IE specifies the type of event that is reported. Event Specific Information BCSM C C C C C C C This IE indicates the call related information specific to the event. Leg ID M M M M M M M This IE indicates the party in the call for which the event is reported. Misc Call Info M M M M M M M This IE indicates the DP type. If the Event Type BCSM IE contains either O_Answer or T_Answer, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Destination Address M M M M M M M This IE specifies the destination address for the call leg. The NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of destination address may be zero. OR - C C - - - - This IE indicates that the call was subject to basic Optimal Routeing as specified in 3GPP TSÊ23.079Ê[19]. Forwarded Call - M C C - - - This IE indicates that the call has been subject to a Call Forwarding supplementary service. Charge Indicator S S S S S S S This IE specifies the value which will be stored in the Call Data Record. See ITU T Recommendation Q.763Ê[43]. Ext Basic Service Code S S S S - - S This IE is used for SCUDIF calls. It indicates the type of basic service, i.e. teleservice or bearer service. It indicates the service active at answer for the SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27]). Ext Basic Service Code 2 S S S S - - S This IE is used for SCUDIF calls. It indicates the type of basic service, i.e. teleservice or bearer service. It indicates the service which is not active at answer for the SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27]). It shall be present if the negotiation of the SCUDIF services resulted in both basic services for the SCUDIF call. Otherwise shall be absent. If the Event Type BCSM IE contains either O_Mid_Call or T_Mid_Call, then the Event Specific Information BCSM IE contains the following information element: Information element name MO MF MT VT NC NP TO Description Midcall Info M - - M - - M This IE is described in a table below. MidCall Info contains the following information elements: Information element name MO MF MT VT NC NP TO Description DTMF Digits Completed S,E - - S,E - - S,E This IE contains the detected mid-call digits. This IE shall be present when triggering takes place after the minimum number of digits has been detected. DTMF Digits Timeout S,E - - S,E - - S,E This IE contains the detected mid-call digits. This IE shall be present when triggering takes place before the minimum number of digits has been detected. If the Event Type BCSM IE contains one of Route_Select_Failure, O_Busy, O_Disconnect or T_Disconnect, then the Event Specific Information BCSM IE contains the following information element: Information element name MO MF MT VT NC NP TO Description Cause C C C C C C C This IE indicates the cause. If the Event Type BCSM IE contains T_Busy, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Cause - - C C - - This IE indicates the cause. Call forwarded - - C C - - This IE indicates that the call may be forwarded by the appropriate Call Forwarding supplementary service or Call Deflection supplementary service. If T_Busy is reported from the GMSC, then this IE shall be present in the following cases: - The event is triggered by the reception of an FTN in the 2nd Send Routeing Info ack from the HLR; - The event is triggered by the reception of the Resume Call Handling information flow from the VMSC. If T_Busy is reported from the VMSC, then this IE shall be present in the following cases: - The event is triggered by the invocation of conditional call forwarding (Busy or Not_Reachable); - The event notification is triggered by the invocation of Call Deflection. Route Not permitted - - S - - - This IE indicates that the further call setup will not take place in this GMSC due to the rules of basic optimal routeing. See 3GPP TSÊ23.079Ê[19]. Forwarding Destination Number - - C C - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarded IE is present. Otherwise, it shall be absent. If the Event Type BCSM IE contains T_No_Answer, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Call Forwarded - - C C - - This IE indicates that the call may be forwarded by the appropriate Call Forwarding supplementary service. If T_No_Answer is reported from the GMSC, then this IE shall be present in the following cases: - The event is triggered by the reception of the Resume Call Handling information flow from the VMSC. If the T_No_Answer is reported from the VMSC, then this IE shall be present in the following cases: - The event is triggered by the invocation of conditional call forwarding (No_Answer). Forwarding Destination Number - - C C - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarded IE is present. Otherwise, it shall be absent. If the Event Type BCSM IE contains Call_Accepted or O_Term_Seized, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Location Information C - - C - - - See subclauseÊ4.6.1.8 with VLR Number IE as ""- (not applicable)"". NOTE If gsmSCF does not arm DPÊO_Change_Of_Position, then the Location Information reported at DPÊO_Term_Seized may be the same as the Location Information reported at DPÊCollected_Information, even when the subscriber has changed location between DPÊCollected Information and DPÊO_Term_Seized. If the Event Type BCSM IE contains O_Change_Of_Position or T_Change_Of_Position, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Location Information C - - C - - See subclauseÊ4.6.1.8 with VLR Number IE as ""- (not applicable)"". Met DP Criteria List S - - S - - This IE is described in a table below. It carries the list of criteria that were triggered and met for the reporting of the change of position event. It shall be present if change of position control info was received in the request. Met DP Criteria List contains a list of up to 10 instances of the following information element: Information element name MO MF MT VT NC NP Description Met DP Criterion M - - M - - Each Met DP Criterion IE is one of the 6 possibilities indicated in the table below. If multiple instances of the Met DP Criterion IE have the same value, this is not an error. Each instance of the Met DP Criterion IE contains one of the following information elements: Information element name MO MF MT VT NC NP Description Cell Global ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the cell specified in this IE. Furthermore it indicates whether the handover was into or out of the cell. Service Area ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the service area specified in this IE. Furthermore it indicates whether the handover was into or out of the service area. Location Area ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the location area specified in this IE. Furthermore it indicates whether the handover was into or out of the location area. Inter System Handover E - - E - - This IE indicates that the mobile station performed inter system handover. Furthermore it indicates whether the handover was from GSM to UMTS or from UMTS to GSM. Inter PLMN Handover E - - E - - This IE indicates that the mobile station performed inter PLMN handover. Inter MSC Handover E - - E - - This IE indicates that the mobile station performed inter MSC handover. If the Event Type BCSM IE contains O_Abandon, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Route Not Permitted - S - - - - - This IE indicates that the further call setup will not take place in this MSC due to the rules of basic optimal routeing. See 3GPP TSÊ23.079Ê[19]. If the Event Type BCSM IE contains one of O_Service_Change or T_Service_Change, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Ext Basic Service Code M M M M - - M This IE indicates the new basic service code after a successful bearer service modification. Nature of Service Change C C C C - - C This IE indicates the nature of the service change (User initiated service change or network initiated service change). Shall be present if available. Initiator of Service Change M M M M - - M This IE indicates the initiator of the service change (A side or B side) If the Event Type BCSM IE contains O_No_Answer, then the Event Specific Information BCSM IE is not included. If the Event Type BCSM IE contains Collected_Info, then the Event Specific Information BCSM IE contains the following information elements: Information element name TO Description Called Party Number M The contents of the Called Party Number parameter are as follows: - Nature of address indicator Ð set to the same value as the Called Party Number parameter sent in InitialDP: - Numbering plan indicator Ð set to the same value as the Called Party Number parameter sent in InitialDP; - Address signals: - If 'N' relevant digits, or more, have been collected and the end of pulsing signal (ST) has not been received, then all relevant digits shall be reported plus a filler digit, if necessary (note 1) - If the end of pulsing signal (ST) has been received then all relevant digits shall be reported, plus the end of pulsing signal and a filler digit, if necessary (note 1) - If the inter-digit timer expires in the MSC then all relevant digits shall be reported plus a filler digit, if necessary (notes 1 & 2). Note 1: The relevant digits are the digits originally reported in InitialDP plus any additional relevant digits collected as a result of the CollectInformation operation(s). Note 2: If the inter-digit timer expires before any additional relevant digits have been collected then the digits reported are the same as those previously reported in InitialDP or EventReportBCSM. Note 3: Some dialled digits may not be relevant for reporting. Relevant digits are determined by operator defined rules in the MSC, e.g. operator specific service selection information may not be reported. The MSC/ gsmSSF compares 'N' against the digits to be reported. 4.6.1.7 Initiate Call Attempt ack 4.6.1.7.1 Description This IF is the successful response to the Initiate Call Attempt IF. 4.6.1.7.2 Information Elements Information element name NC NP Description Supported CAMEL Phases M M This IE indicates the CAMEL Phases supported. Offered CAMEL4 Functionalities M M This IE is described in subclause 4.6.1.8. This IE indicates the CAMEL phaseÊ4 functionalities offered. Release Call Argument Extension Allowed O - This IE indicates whether the gsmSCF is allowed to use network specific IE in the Release Call IF. 4.6.1.8 Initial DP 4.6.1.8.1 Description This IF is generated by the gsmSSF when a trigger is detected at a DP in the BCSM, to request instructions from the gsmSCF. 4.6.1.8.2 Information Elements (Note: IEs in the NC columns in this IF may need further study.) Information element name MO MF MT VT NC NP TO Description Additional Calling Party Number C C C C - C C This IE contains the calling party number provided by the access signalling system of the calling user or received from the gsmSCF due to the previous CAMEL processing. Called Party Number C M M M - M M This IE contains the number used to identify the called party in the forward direction. For MO and MF calls this IE is used in the case of TDP Route_Select_Failure (this is the destination number used to route the call) and in the case of TDP Busy and TDP No Reply (this is the MSISDN when the destination number used for the call is an MSRN, or in the case of unsuccessful call establishment received from the HLR via the MAP interface, otherwise it is the number used to route the call). For VT calls when there is no forwarding pending this is the MSISDN received in the Provide Roaming Number; if the MSISDN is not available, the basic MSISDN is used. For the MT and VT call case when there is call forwarding or call deflection pending, this is the MSISDN, i.e. not the forwarded-to or deflected-to number. If the Initial DP IF is sent at TDP Route_Select_Failure or TDP Analysed_Information then the NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of the destination address may be zero. For TO calls this IE is used to identify the called party in the forward direction. It is used in the case of TDP Collected_Information and TDP Analysed_Information. The number contained in this IE shall be the relevant digits, for reporting purposes, of the number received in the telephony signalling system call establishment message (e.g. ISUP IAM). The number may or may not include the end of pulsing signal (ST). Called Party BCD Number C - - - - - - This IE contains the number used to identify the called party in the forward direction. It is used for an MO call in all cases except in the case of TDP Route_Select_Failure. For the TDP Collected_Information, the number contained in this IE shall be identical to the number received over the access network. It may e.g. include service selection information, such as ? and # digits, or carrier selection information dialled by the subscriber. For the TDP Analysed_Information, the number contained in this IE shall be the dialled number received over the network access or received from a gsmSCF in a Connect IF, Service selection information, such as * and # digits may be present (see subclauseÊ4.2.1.2.2); carrier selection information dialled by the subscriber is not present. Calling Party Number M C C C - C C This IE carries the calling party number to identify the calling party or the origin of the call. Calling Partys Category M C C C - C C This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). CallGap Encountered C C C C - C C This IE indicates the type of gapping which has been applied to the related call. This IE shall be present only if a call gapping context is applicable to the Initial DP IF. Call Reference Number M M M M - M M This IE may be used by the gsmSCF for inclusion in a network optional gsmSCF call record. It has to be coupled with the identity of the MSC which allocated it in order to define unambiguously the identity of the call. For MO calls, the call reference number is set by the serving VMSC and included in the MO call record. For MT calls, the call reference number is set by the GMSC and included in the RCF call record in the GMSC and in the MT call record in the terminating MSC. For VT calls, the call reference number is set by the GMSC and included in the RCF call record in the GMSC and in the MT call record in the terminating MSC. For MF calls, the call reference number is set by the GMSC and included in the CF record in the forwarding MSC. For the setting of the Call Reference Number for NP calls, see the corresponding call case above (MO, MT, VT or MF). For TO calls, the call reference number is set by the inter-connecting MSC. Cause C C C C - - - This IE indicates the cause specific to the armed BCSM DP event. This IE is applicable to DPÊRoute_Select_Failure and DPÊT_Busy. The cause may be used by the gsmSCF to decide how to continue the call handling. Event Type BCSM M M M M - M M This IE indicates the armed BCSM DP event, resulting in the Initial DP IF. For the TO traffic case this will be 'CollectedInformation' or 'AnalysedInformation'. IMSI M M M M - S - This IE identifies the mobile subscriber. For the NP case, the IMSI is mandatory if the new party is initiated in an MO, MF, MT, or VT call, otherwise it shall be absent. IP SSP Capabilities C C C C - C C This IE indicates which SRF resources are supported within the gsmSSF and are available. If this IE is absent, it indicates that no gsmSRF is attached and available. Location Information M - C M - - - This IE is described in a table below. Location Number M C C C - - C For mobile originated calls this IE represents the location of the calling party. For all other call scenarios this IE contains the location number received in the incoming ISUP signalling. MSC Address M M M M - M M For MO calls, the MSC Address carries the international E.164 address of the serving VMSC. For MT calls, the MSC Address carries the international E.164 address of the GMSC. For VT calls, the MSC Address carries the international E.164 address of the serving VMSC. For MF calls, the MSC Address carries the international E.164 address of the forwarding MSC. For NP case, see the corresponding call case above (MO, MT, VT or MF). For TO calls, the MSC Address carries the international E.164 address of the inter-connecting MSC. GMSC Address - M - M - S - For MF calls, the GMSC Address carries the international E.164 address of the GMSC. For VT calls, the GMSC Address carries the international E.164 address of the GMSC. For NP calls, the GMSC Address is mandatory if the new party is initiated in an MF call or in a VT call, otherwise it shall be absent. The GMSC Address carries the international E.164 address of the GMSC. Carrier S S S S - S S This IE is described in a table below. This IE may be present when the VPLMN and the HPLMN of the subscriber are both North American. For MO calls, this IE shall identify any carrier that was explicitly selected by the calling subscriber. If no carrier was explicitly selected, this IE shall contain the calling subscriber's subscribed carrier. For MT and VT calls, the IE shall contain the carrier subscribed to by the called subscriber. For MF calls, the IE shall contain the carrier subscribed to by the forwarding subscriber. For TO calls, this IE shall identify any carrier that was explicitly selected by the calling party or redirecting party, as received from the telephony signalling system (e.g. ISUP IAM). Original Called Party ID C C C C - - C This IE carries the dialled digits if the call has met call forwarding on the route to the gsmSSF. This IE shall also be sent if it was received from the gsmSCF due to previous CAMEL processing. Redirecting Party ID C C C C - - C This IE indicates the directory number the call was redirected from. This IE shall also be sent if it was received from the gsmSCF due to previous CAMEL processing. Redirection Information C C C C - - C This IE contains forwarding related information, such as the redirection counter. Service Key M M M M - M M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application within the gsmSCF. Subscriber State - - C C - - - This IE indicates the status of the MS. The states are: - CAMEL Busy: The MS is engaged on a transaction for a mobile originating or terminated circuit-switched call. - Network Determined Not Reachable: The network can determine from its internal data that the MS is not reachable. - Assumed Idle: The state of the MS is neither ""CAMEL Busy"" nor ""Network Determined Not Reachable"". - Not provided from VLR. Time And Timezone M M M M - M M This IE contains the time that the gsmSSF was triggered, and the time zone in which gsmSSF resides. Call Forwarding SS Pending - - C C - - - If the Initial DP IF is sent from the GMSC, then this IE shall be present in the following cases: - The GMSC has received an FTN in the 1st Send Routeing Info ack IF from the HLR. - The GMSC has received an FTN in the 2nd Send Routeing Info ack IF from the HLR and no relationship with the gsmSCF exists at that moment. - The GMSC has received the Resume Call Handling IF from the VMSC and no relationship with the gsmSCF exists at that moment. If the Initial DP IF is sent from the VMSC, then this IE shall be present in the following cases: - Conditional call forwarding is invoked and no relationship with the gsmSCF exists at that moment. - Call Deflection is invoked and no relationship with the gsmSCF exists at that moment. Forwarding Destination Number - - C C - - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarding SS Pending IE is present, otherwise it shall be absent. Service Interaction Indicators Two C C C C - C C The IE is described in a table below. This IE is present if it is received in the ISUP message or due to previous CAMEL processing. CUG Index C - - - - C - See 3GPP TSÊ23.085Ê[22] for details of this IE. CUG Interlock Code C C C C - C C This IE shall be set according to 3GPP TSÊ23.085Ê[22] unless modified by the gsmSCF via the Connect or Continue With Argument IFs. Outgoing Access Indicator C C C C - C C This IE shall be set according to the 3GPP TSÊ23.085Ê[22] unless modified by the gsmSCF via the Connect or Continue With Argument IFs. MS Classmark 2 C - - - - - - This IE contains the MS classmark 2, which is sent by the MS when it requests access to setup the MO call or responds to paging in the CS domain. IMEI (with software version) C - - - - - - This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Supported CAMEL Phases M M M M M M M This IE indicates the CAMEL Phases supported by the GMSC or the VMSC. Offered CAMEL4 Functionalities M M M M M M M This IE is described in a table below. This IE indicates the CAMEL phaseÊ4 functionalities offered by the GMSC or the VMSC."
"Bearer Capability M C C C - C C This IE indicates the bearer capability connection to the user. For a SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27] this IE indicates the Bearer CapabilityÊof the preferred service. Bearer CapabilityÊ2 C C C C - - C This IE indicates the bearer capability of the less preferred service for a SCUDIF call. Ext-Basic Service Code C C C C - C C This IE indicates the basic service, i.e. teleservice or bearer service. For a SCUDIF call this IE indicates the basic service of the preferred service Ext-Basic Service CodeÊ2 C C C C - - C This IE indicates the basic service of the less preferred service for a SCUDIF call. High Layer Compatibility C C C C - C C This IE indicates the high layer compatibility, which will be used to determine the ISDN-teleservice of a connected ISDN terminal. For a SCUDIF call this IE indicates the high layer compatibility of the preferred service. High Layer Compatibility 2 C C C C - C C This IE indicates the high layer compatibility of the less preferred service for a SCUDIF call. Low Layer Compatibility C C C C - C C This IE indicates the low layer compatibility, which will be used to determine the ISDN bearer capability of a connected ISDN terminal. For a SCUDIF call this IE indicates the Low Layer Compatibility of the preferred service. Low Layer Compatibility 2 C C C C - C C This IE indicates the low layer compatibility of the less preferred service for a SCUDIF call. Enhanced Dialled Services Allowed S S - - S S S This IE indicates that the gsmSCF may use the Enhanced Dialled Services (EDS). This IE shall be included if and only if all of following four conditions are fulfilled: - this IF is sent due to triggering on DP Analysed_Information; and - the EDS functionality is offered for this call (as indicated in the Offered CAMEL4 Functionalities); and - there is no more than one outgoing leg within this call; and - there is no other CAMEL dialogue active for the leg for which this IF is sent. User-to-User Service activation request O O O O - - O This IE may be sent if it is received in a call control message. See 3GPP TSÊ23.087Ê[45], 3GPP TSÊ24.008Ê[30], and ETSI ENÊ300Ê356 1Ê[40] for details of this IE. User-to-User Information O O O O - - O This IE may be sent if it is received in a call control message. See 3GPP TSÊ23.087Ê[45], 3GPP TSÊ24.008Ê[30], and ETSI ENÊ300Ê356 1Ê[40] for details of this IE. Collect Information Allowed - - - - - - S This IE indicates whether the gsmSCF is allowed to use Collect Information for the armed BCSM DP event. This IE shall only be included when the armed BCSM DP event is 'CollectedInformation' or 'AnalysedInformation'. Note: This IE shall only be included for the 'AnalysedInformation' BCSM DP event if the 'Enhanced Dialled Services Allowed' IE is also present. Release Call Argument Extension Allowed O O O O - O O This IE indicates whether the gsmSCF is allowed to use network specific IE in the Release Call IF. Offered CAMEL4 Functionalities contains the following information elements: Information element name Status Description Initiate Call Attempt S This IE indicates that the gsmSCF may send to the gsmSSF the Initiate Call Attempt IF. Split Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Split Leg IF. Move Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Move Leg IF. Disconnect Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Disconnect Leg IF. Entity Released S This IE indicates that the gsmSSF will send to the gsmSCF the Entity Released IF, when appropriate. DFC With Argument S This IE indicates that the gsmSCF may send to the gsmSSF the Disconnect Forward Connection With Argument IF. Play Tone S This IE indicates that the gsmSCF may send to the gsmSSF the Play Tone IF. DTMF Mid Call S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_MidCall or T_MidCall DP. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. Charging Indicator S This IE indicates that the Charge Indicator IE may be present in the Event Report BCSM IF reporting the O_Answer or T_Answer DP. Alerting DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Term_Seized or Call_Accepted DP. Location At Alerting S This IE indicates that the Location Information IE shall be present (if available) in the Event Report BCSM IF reporting the O_Term_Seized or Call_Accepted DP. Change Of Position DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Change_Of_Position or T_Change_Of_Position DPs. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. OR Interactions S This IE indicates that the gsmSCF may send to the gsmSSF the Basic OR Interrogation Requested IE in the Connect or Continue With Argument IF. This IE indicates that the Route Not Permitted IE may be present in the Event Report BCSM IF reporting the O_Abandon DP. Warning Tone Enhancements S This IE indicates that the gsmSCF may send to the gsmSSF the Burstlist IE (within the Audible Indicator IE) in an Apply Charging IF. CF Enhancements S This IE indicates that the Forwarding Destination Number IE may be present in the Event Report BCSM IF reporting the T_Busy or T_No_Answer DP. Criteria for Change Of Position DP S This IE indicates that the gsmSCF may send to the gsmSSF in the Request Report BCSM Event IF criteria for reporting the report of O_Change_Of_Position or T_Change_Of_Position. Subscribed Enhanced Dialled Services S This IE indicates that Subscribed Enhanced Dialled Services is offered. Serving Network Enhanced Dialled Services S This IE indicates that Serving Network Enhanced Dialled Services is offered. Service Change DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Service_Change or T_Service_Change DPs. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. Collect Information S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the CollectedInfo EDP and order the MSC to collect a specific number of additional dialled digits. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name MO MF MT VT NC NP Description Location Number - - C C - - See 3GPP TSÊ23.018Ê[12]. Service area ID C,E - C,E C,E - - See 3GPP TSÊ23.018Ê[12]. Cell ID C,E - C,E C,E - - See 3GPP TSÊ23.018Ê[12]. Geographical information C - C C - - See 3GPP TSÊ23.018Ê[12]. Geodetic information C - C C - - See 3GPP TSÊ23.018Ê[12]. VLR number M - C M - - See 3GPP TSÊ23.018Ê[12]. Age Of location information M - C C - - See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - - - - - - Not applicable Location area ID C,E - C,E C,E - - See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S - S S - - This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority shall be present. See 3GPP TSÊ23.073Ê[18]. This IE shall be present if available and SoLSA is supported, otherwise it shall be absent. User CSG Information C - C - - - See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID - - C,E - - - See 3GPP TSÊ23.018Ê[12]. Tracking area ID - - C,E - - - See 3GPP TSÊ23.018Ê[12]. Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M - M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M - M M This IE indicates the way the carrier was selected, i.e.: - dialled - subscribed Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator C C C C - C C This IE is described in a table below. HOLD Treatment Indicator C - - C - C - This IE indicates whether the CAMEL subscriber can invoke HOLD for the call. CW Treatment Indicator C - - C - C - This IE indicates whether CW can be applied for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator C - - C - C - This IE indicates whether the call leg can become part of an ECT call initiated by the CAMEL subscriber. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator C C C C - C C This IE indicates whether the call leg can become part of a MPTY call initiated by the called subscriber. Call Diversion Treatment Indicator C C C C - C C This IE indicates whether the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. 4.6.1.9 Move Leg ack 4.6.1.9.1 Description This IF is the successful response to the Move Leg IF. 4.6.1.9.2 Information Elements This IF contains no information elements. 4.6.1.10 Split Leg ack 4.6.1.10.1 Description This IF is the successful response to the Split Leg IF. 4.6.1.10.2 Information Elements This IF contains no information elements. 4.6.2 gsmSCF to gsmSSF information flows 4.6.2.1 Activity Test 4.6.2.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gsmSSF. If the relationship is still in existence, then the gsmSSF will respond. If no reply is received, then the gsmSCF will assume that the gsmSSF has failed in some way and will take appropriate action. 4.6.2.1.2 Information Elements This IF contains no information elements. 4.6.2.2 Apply Charging 4.6.2.2.1 Description This IF is used to instruct the gsmSSF to apply charging mechanisms to control the call duration. 4.6.2.2.2 Information Elements Information element name MO MF MT VT NC NP TO Description ACh Billing Charging Characteristics M M M M M M M This IE specifies the charging related information to be provided by the gsmSSF and the conditions on which this information has to be provided back to the gsmSCF. Party To Charge M M M M M M M This IE shall be reflected in the corresponding IE of the Apply Charging Report IF. This IE has no effect on the charging procedures in the MSC. ACh Charging Address M M M M M M M This IE identifies the call party to which the Apply Charging IF applies. This IE is described in a table below. ACh Billing Charging Characteristics contains the following information element: Information element name MO MF MT VT NC NP TO Description Time Duration Charging M M M M M M M This IE is described in a table below. Time Duration Charging contains the following information elements: Information element name MO MF MT VT NC NP TO Description Max Call Period Duration M M M M M M M This IE indicates the maximum call period duration timer. Tariff Switch Interval O O O O O O O This IE indicates the tariff switch time until the next tariff switch applies for this call leg. Release If Duration Exceeded O O O O O O O This IE indicates that the call leg, SRF connection or Temporary connection shall be released when the Max call Period Duration expires. The cause used in the Release IF shall be ""normal unspecified"". The default handling is to continue the call. Audible Indicator O - O O O O O This IE is described in a table below. Audible Indicator IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Tone E - E E E E E This IE indicates that a fixed sequence of tones shall be played to the CAMEL subscriber. In the NC case, the first party created will receive the warning tone. In the TO case the calling party will receive the warning tone. If present, this IE indicates that 30 seconds before the Max Call Period Duration timer expires, a fixed sequence of tones consisting of 3 tones of 900 Hz, with a 200 milliseconds tone duration and a 200 milliseconds intertone duration shall be played. Burstlist E - E E E E E This IE is described in the table below. This IE indicates a variable sequence of bursts that shall be played during the call period to the CAMEL subscriber. In the NC case, the first party created will receive the warning tone. In the TO case the calling party will receive the warning tone. Burstlist IE contains the following information elements: Information element name Status Description Warning Period M This IE indicates the time, before the Max Call Period Duration timer expires, when the Play Burst List IE shall start. Number Of Bursts M This IE indicates the number of bursts to be played. There may be up to three bursts. Burst Interval M This IE indicates the time interval between successive bursts. Number Of Tones In Burst M This IE indicates the number of tones to be played in each burst. There may be up to three tones per burst. The tone is fixed to 900 Hz. Tone Duration M This IE indicates the duration of a tone in a burst. Tone Interval M This IE indicates the time interval between successive tones in a burst. NOTE Service logic designers should note that the total duration of the Burst List should not exceed the WarningPeriod IE, otherwise an incomplete Burst List will be played to the served party. ACh Charging Address contains the following information elements: Information element name MO MF MT VT NC NP TO Description Leg ID E E E E E E E This IE indicates that the Apply Charging IF applies to the specified leg. SRF Connection E E E E E E E This IE indicates that the Apply Charging IF applies to the Temporary Connection or SRF Connection 4.6.2.3 Call Gap 4.6.2.3.1 Description This IF is used to activate/modify/remove a call gap mechanism in the gsmSSF. The call gap mechanism is used to reduce the rate at which specific service requests are sent to a gsmSCF. A Call Gap IF can only be sent on an opened dialogue between a gsmSCF and a gsmSSF. It is possible to have several call gapping conditions applicable to the same gsmSSF (i.e. each conditions was activated for a defined Service (identified by the service Key) by a defined gsmSCF (identified by the gsmSCF address). 4.6.2.3.2 Information Elements Information element name Status Description Gap Criteria M This IE specifies the criteria for a call to be subject to call gapping. Gap Indicators M This IE indicates the gapping characteristics. Control Type O This IE indicates the reason for activating call gapping. The value ""gsmSCF Overloaded"" indicates that an automatic congestion detection and control mechanism in the gsmSCF has detected a congestion situation. The value ""Manually Initiated"" indicates that the service and/or network/service management centre has detected a congestion situation, or any other situation that requires manually initiated controls. The Control Type ""Manually Initiated"" will have priority over a ""gsmSCF Overloaded"" call gap. Note that Non-IN controlled traffic control mechanism can also apply to an exchange with the gsmSSF functionality. As the non-IN controlled traffic control is within the MSC, this traffic control has implicit priority over the IN controlled traffic control. The non-IN controlled traffic control may also have some influence on the IN call. Therefore it is recommended to take measures to coordinate several traffic control mechanisms. The non-IN controlled traffic control and co-ordination of several traffic control mechanisms are out of the scope of the present document. Gap Treatment O This IE indicates how calls that were rejected due to the call gapping condition and have Default Call Handling as ""Release Call"" shall be treated. Gap Criteria contains one of the following information elements: Information element name Status Description Basic Gap Criteria O,E This IE is a choice of various basic criteria. Compound Gap Criteria O,E This IE is a choice of various criteria including a gsmSCF ID. Compound Gap Criteria contains the following information elements: Information element name Status Description Basic Gap Criteria M This IE is a choice of various criteria. gsmSCF ID O This IE contains the address of the gsmSCF which initiated the Call Gapping. Basic Gap Criteria contains one of the following information elements: Information element name Status Description Called Address O,E This IE contains a string of digits. For each call attempt where the leading digits of the dialled number match this specific value, the call gapping treatment shall be applied to the call. Service O,E This IE contains a service key value. For each call attempt where the service key match this specific value, the call gapping treatment shall be applied to the call. Called Address And Service O,E This IE contains a specific string of digits and a service key value. For each call attempt where the leading digits of the dialled number and the service key of a call match these specific values, the call gapping treatment shall be applied to the call. Calling Address And Service O,E This IE contains a specific string of digits and a service key value. For each call attempt where the leading digits of the calling party number and the service key match these specific values, the call gapping treatment shall be applied to the call. Gap Indicators contains the following information elements: Information element name Status Description Duration M This IE specifies the total time interval during which call gapping for the specified gap criteria will be active. A duration of 0 indicates that gapping is to be removed. A duration of -2 indicates a network specific duration. Other values indicate the duration in seconds. Interval M This IE specifies the minimum time between calls being allowed through. An interval of 0 indicates that calls meeting the gap criteria are not to be rejected. An interval of -1 indicates that all calls meeting the gap criteria are to be rejected. Other values indicate the interval in milliseconds. Gap Treatment contains one of the following elements: Information element name Status Description Information To Send O,E This IE indicates an announcement or a tone to be sent to the calling party. At the tone or announcement, the call shall be released. Release Cause O,E If the call is to be released, this IE indicates the specific cause value to be sent in the Release IF. See ETSI ENÊ300Ê356 1Ê[40] for the coding. Information To Send contains one of the following elements: Information element name Status Description In-band Info O,E This IE specifies the in-band information to be sent. Tone O,E This IE specifies a tone to be sent to the end-user. In-band Info contains the following information elements: Information element name Status Description Message ID M This IE is described in a table below. This IE indicates the message(s) to be sent. Message Duration O This parameter indicates the maximum time in seconds that the message shall be played/repeated. ZERO indicates endless repetition. Message Id contains the following element: Information element name Status Description Elementary Message ID O This IE indicates a single announcement. 4.6.2.4 Call Information Request 4.6.2.4.1 Description This IF is used to request the gsmSSF to record specific information about a single call party and report it to the gsmSCF (with a Call Information Report IF). 4.6.2.4.2 Information Elements Information element name Status Description Requested Information Type List M This IE is described in a table below. This IE specifies a list of specific items of information which are requested. Leg ID M This IE indicates the party in the call for which the information shall be collected. Requested Information Type List contains the following information elements: Information element name Status Description Call Attempt Elapsed Time O This IE indicates that the Call Attempt Elapsed Time is requested in the Call Information Report. Call Attempt Elapsed Time is the duration between the end of the CAMEL processing initiating call setup (Connect, Continue or Continue With Argument IF) and the received answer indication from the called party side. For the Calling Party, the value of Call Attempt Elapsed Time in the Call Information Report shall be set to 0. Call Stop Time O This IE indicates that the Call Stop Time is requested in the Call Information Report. Call Stop Time is the time stamp when the connection is released. Call Connected Elapsed Time O This IE indicates that the Call Connected Elapsed Time is requested in the Call Information Report. Call Connected Elapsed Time is the duration between the received answer indication from the called party side and the release of the connection. For a Calling Party, it indicates the duration between the sending of the Initial DP IF and the release of that party. Release Cause O This IE indicates that the Release Cause for the call party is requested in the Call Information Report. 4.6.2.5 Cancel 4.6.2.5.1 Description This IF is used by the gsmSCF to request the gsmSSF to cancel all EDPs and reports. 4.6.2.5.2 Information Elements Information element name Status Description All Requests M This IE indicates that all active requests for the Event Report BCSM, Apply Charging Report and Call Information Report IFs shall be cancelled. 4.6.2.5A Collect Information 4.6.2.5A.1 Description This IF is used to instruct the gsmSSF to collect additional dialled digits from the calling party and report them to the gsmSCF. The use of this operation is only appropriate for a call which has not yet left the set-up phase. NOTE: It is advisable to avoid the use of gsmSCF-initiated user interaction while additional digits are being collected. Interaction with a Specialised Resource Function (SRF) may result in an ACM being sent to the originating node which will prevent any further dialled digits being sent. NOTE: If the gsmSCF sends CAP Connect before the dialling is complete then no further digits can be collected from the calling party. 4.6.2.5A.2 Information Elements This IF contains no information elements. 4.6.2.6 Connect 4.6.2.6.1 Description This IF is used to request the gsmSSF to perform the call processing actions to route a call to a specific destination. To do so, the gsmSSF may use destination information from the calling party and existing call set-up information depending on the information provided by the gsmSCF. The gsmSCF shall not send this IF when there is a CSA with a single call segment which includes only legÊ1. 4.6.2.6.2 Information Elements Information element name MO MF MT VT NC NP TO Description Alerting Pattern - - O O - - - This IE indicates the kind of Alerting Pattern to be applied. Calling Partys Category O O O O O O O This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). Destination Routing Address M M M M M M M This IE contains the called party number towards which the call is to be routed. The NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of the destination address may be zero. The gsmSCF may use national-specific NatureOfAddress indicator values of the gsmSSF country. Generic Number O O O O O O O This IE contains the generic number. Its used to convey the additional calling party number, which e.g. could be used to modify the calling line ID presented to the called user. Carrier O O O O O O O This IE is described in a table below. NA Originating Line Information O O O O O O O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O O O O O O O This IE identifies the chargeable number for the usage of a North American carrier. O CSI Applicable - - O O - - - This IE indicates that the O CSI, if present shall be applied on the outgoing leg. Suppress N-CSI - - - - - - O This IE indicates that N CSI, if present, shall be suppressed for the trunk originated call. Original Called Party ID O O O O O O O This IE carries the dialled digits if the call has met call forwarding on route to the gsmSSF or is forwarded by the gsmSCF. Leg To Be Connected S S S S S S S This IE indicates the leg to which the Connect IF applies. The gsmSCF shall include this IE if: - The CSA has more than one call segment, or - The CSA has a single call segment, which contains: - one leg, which is not legÊ2; or - two legs, which are not legÊ1 and legÊ2, or - more than two legs. Otherwise this IE may be present or absent as required by the service logic. This IE shall not indicate leg1. Redirecting Party ID O O O O O O O This IE indicates the directory number the call was redirected from. Redirection Information O O O O O O O This IE contains forwarding related information, such as redirecting counter. Suppression Of Announcements - - O O O O - This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Service Interaction Indicators Two O O O O O O O This IE is described in a table below. CUG Interlock Code O O O O O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Outgoing Access Indicator O O O O O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Basic OR interrogation requested O O - - O O O This IE indicates that a Basic Optimal Routeing interrogation is requested for the call. If Basic Optimal Routeing is successful, this will be reported to the gsmSCF in the Answer event report. This IE shall be ignored if the VMSC associated with the gsmSSF does not support Basic Optimal Routeing. This IE shall be ignored if it is received in a gsmSSF which is handling the MF call case in the GMSC function of the forwarding subscriber. Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M M M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M M M M This IE indicates the way the carrier was selected e.g.: - dialled; - subscribed. Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator O O O O O O O This IE is described in a table below. Backward Service Interaction Indicator O O O O - - O This IE is described in a table below. HOLD Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of HOLD by the CAMEL subscriber. CW Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of CW for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the call leg to become part of an ECT call initiated by the CAMEL subscriber. Connected number treatment indicator O O O O - - O This IE indicates the treatment of the connected number at the originating side. Non-CUG Call O O O O O O O This IE indicates that no parameters for CUG should be used for the call (i.e. the call should be a non-CUG call). Shall be absent if one or more of CUG Interlock Code and Outgoing Access Indicator is present in the IF. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O O - O This IE allows the gsmSCF to disallow the call leg to become part of a MPTY call initiated by the CAMEL subscriber. Call Diversion Treatment Indicator O O O O O - O This IE allows the gsmSCF to disallow the Call Forwarding or Call Deflection supplementary services for this call. Calling Party Restriction Indicator O O O O O O O This IE allows the gsmSCF to mark the CLI as Restricted for the call. Backward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O - O O This IE allows the gsmSCF to disallow the call leg to become part of a MPTY call initiated by the calling subscriber. Call Completion Treatment Indicator O O O O - O O This IE allows the gsmSCF to disallow a CCBS request to be made for the call. See also 3GPP TSÊ23.093Ê[26] for description. 4.6.2.7 Connect To Resource 4.6.2.7.1 Description This IF is used to connect a call from the gsmSSF to a gsmSRF. 4.6.2.7.2 Information Elements Information element name Status Description Resource Address M This IE indicates the address of the gsmSRF to which the connection shall be established. It is described in a table below. Service Interaction Indicators Two O This IE indicates whether or not a bothway through connection is required between the call segment and the calling party. When there is no calling party connected to the call segment, then the gsmSSF shall ignore this IE, if received. The handling when this IE is not present is defined in ETSI ENÊ301Ê070 1 ([41]). Call Segment ID M This IE indicates the call segment to be connected to the resource. The subsequent user interaction shall apply to all parties connected to the call segment. Resource Address contains the following information elements: Information element name Status Description IP Routing Address E This IE indicates the routeing address to set up a connection between the call segment and the gsmSRF. None E This IE indicates that the call segment shall be connected to a predefined gsmSRF. 4.6.2.8 Continue 4.6.2.8.1 Description This IF requests the gsmSSF to proceed with call processing at the DP at which it previously suspended call processing to await gsmSCF instructions. The gsmSSF completes DP processing, and continues basic call processing (i.e. proceeds to the next point in call in the BCSM) without substituting new data from the gsmSCF. The gsmSCF may send this operation only when there is a CSA with a single call segment which includes: - only legÊ1, or - only legÊ2, or - legÊ1 and legÊ2 but no other legs. 4.6.2.8.2 Information Elements This IF contains no information elements. 4.6.2.9 Continue With Argument 4.6.2.9.1 Description This IF requests the gsmSSF to continue the call processing with modified information at the DP at which it previously suspended call processing to await gsmSCF instructions or to continue call processing after a Call Party Handling IF was received. The gsmSSF completes DP processing if necessary, and continues basic call processing (i.e. proceeds to the next point in call in the BCSM) with the modified call setup information as received from the gsmSCF. This IF may also be used to continue call processing after an Initiate Call Attempt IF and Call Party Handling IF. The gsmSCF can send modified call information at DPÊCollected_Info and at DPÊAnalysed_Info, as listed in the MO and MF columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information at DPÊTermination_Attempt_Authorised, as listed in the MT and VT columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information immediately after sending an Initiate Call Attempt IF, as listed in the NC and NP columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information at DP Collected_Info and at DP_Analysed_Info, as listed in the TO column in subclause 4.6.2.9.2. In all other cases, Continue With Argument shall contain no other IE than Leg ID or Call Segment ID. When this IF is used to resume the processing of an Initiate Call Attempt IF, then a Leg ID shall be included and Call Segment ID shall be absent. When this IF is used to resume the processing of a Call Party Handling IF, then a Call Segment ID shall be included and Leg ID shall be absent. When this IF is used to resume processing after an EDP-R or TDP-R, then a Leg ID shall be included and Call Segment ID shall be absent. The following exception exists: if this IF is used to resume processing after an EDP R or TDP R in one of the following scenarios: - the CSA has one Call Segment only, which includes legÊ1 only; - the CSA has one Call Segment only, which includes legÊ2 only; - the CSA has one Call Segment only, which includes legÊ1 and legÊ2, but no other legs; then, the Leg ID may be present or absent, as required by the Service Logic. 4.6.2.9.2 Information Elements Information element name MO MF MT VT NC NP TO Description Alerting Pattern - - O O O - - This IE indicates the kind of Alerting Pattern to be applied. Calling Partys Category O O O O O O O This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). Generic Number O O O O O O O This IE contains the generic number. It is used to convey the additional calling party number, which e.g. could be used to modify the calling line ID presented to the called user. Carrier O O O O O O O This IE is described in a table below. NA Originating Line Information O O O O O O O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O O O O O O O This IE identifies the chargeable number for the usage of a North American carrier. Suppression Of Announcements - - O O O O - This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Service Interaction Indicators Two O O O O O O O This IE is described in a table below. CUG Interlock Code O O - - O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Outgoing Access Indicator O O - - O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Basic OR Interrogation Requested O O - - O O,S O This IE indicates that a Basic Optimal Routeing interrogation is requested for the call. If Basic Optimal Routeing is successful, this will be reported to the gsmSCF in the Answer event report. This IE shall be ignored if the VMSC associated with the gsmSSF does not support Basic Optimal Routeing. This IE shall be ignored if it is received in a gsmSSF which is handling the MF call case in the GMSC function of the forwarding subscriber. For an NP call leg, this IE can only be included if the original call was an MO or NC call. Leg ID O,E O,E O,E O,E O,E O,E O,E This IE indicates the party for which call processing is to be resumed. Call Segment ID O,E O,E O,E O,E O,E O,E O,E This IE indicates the call segment for which call processing is to be resumed. Suppress O CSI - - O O - - - This IE indicates that O CSI shall be suppressed for the forwarding leg or deflecting leg. Suppress D CSI - - - - - O - This IE indicates that D CSI shall be suppressed for the new call leg. This IE can only be included if this IE is sent to the VMSC or GMSC of the CAMEL subscriber. Suppress N CSI - - - - O O O This IE indicates that N CSI shall be suppressed for the new call leg or trunk originated call. Suppress Outgoing Call Barring - - - - - O - This IE indicates that Outgoing Call Barrings for the created leg shall be suppressed. This IE can only be included if the Initiate Call Attempt IF is sent to the VMSC of the CAMEL subscriber."
"Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M M M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M M M M This IE indicates the way the carrier was selected, i.e.: - dialled - subscribed Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator O O O O O O O This IE is described in a table below. Backward Service Interaction Indicator O O O O - - O This IE is described in a table below. HOLD Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of HOLD by the CAMEL subscriber. CW Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of CW for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the call leg to become part of an ECT call initiated by the CAMEL subscriber. Connected Number Treatment Indicator O O O O - - - This IE indicates the treatment of the connected number at the originating side. Non-CUG Call O O - - - O O This IE indicates that no parameters for CUG should be used for the call (i.e. the call should be a non-CUG call). This IE shall be absent if one or more of CUG Interlock Code and Outgoing Access Indicator are present in the IF. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O O O O This IE indicates whether the call leg can become part of a MPTY call initiated by the called subscriber. Call Diversion Treatment Indicator O O O O O O O This IE indicates whether the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. Calling Party Restriction Indicator O O O O O O O This IE allows the gsmSCF to mark the CLI as Restricted for the call. Backward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O - - O This IE indicates if the call leg can become part of a MPTY call initiated by the calling subscriber. Call Completion Treatment Indicator O O O O - - O This IE indicates whether a CCBS request can be made for the call. See also 3GPP TSÊ23.093Ê[26] for description. 4.6.2.10 Disconnect Forward Connection 4.6.2.10.1 Description This IF is used: - to disconnect a connection with a gsmSRF previously established with a Connect To Resource IF; - to disconnect an initiating gsmSSF from an assisting gsmSSF and its associated gsmSRF. The IF is sent to the initiating gsmSSF. 4.6.2.10.2 Information Elements This IF contains no information elements. 4.6.2.11 Disconnect Forward Connection With Argument 4.6.2.11.1 Description This IF is used in the following two cases: 1) To clear a connection to a gsmSRF: This IF is used to explicitly disconnect a connection to a resource (gsmSRF) established previously with a Connect To Resource or an Establish Temporary Connection IF. It is used for a forward disconnection from the gsmSSF. 2) To clear a connection to an assisting SSF: This IF is sent to the non-assisting SSF of a pair of SSFs involved in an assist procedure. It is used to disconnect the temporary connection between the initiating SSF and the assisting SSF. 4.6.2.11.2 Information Elements Information element name Status Description Call Segment ID M This IE indicates the call segment in the call to be disconnected from the resource or the temporary connection. 4.6.2.12 Disconnect Leg 4.6.2.12.1 Description This IF is used to request the gsmSSF to release a specific leg associated with the call at any phase. All other legs in this call are retained. If the last leg of the call segment is disconnected, then the call segment is deleted. 4.6.2.12.2 Information Elements Information element name Status Description Leg To Be Released M This IE indicates the party in the call to be released. Release Cause O This IE indicates to the gsmSSF the reason for releasing the identified party. This may be used by the MSC or GMSC for generating specific tones to the party to be released or to fill in the ""cause"" IE in the Release IF. 4.6.2.13 Establish Temporary Connection 4.6.2.13.1 Description This IF is used to create a connection between an initiating gsmSSF and an assisting gsmSSF as a part of the assist procedure. It can also be used to create a connection between a gsmSSF and a gsmSRF. 4.6.2.13.2 Information Elements Information element name Status Description Assisting SSP IP Routing Address M This IE indicates the destination address of the gsmSRF or assisting gsmSSF for the assist procedure. As a network operator option, the Assisting gsmSSF IP Routing Address may contain embedded within it, a ""Correlation ID"" and ""gsmSCF ID"", but only if ""Correlation ID"" and ""gsmSCF ID"" are not specified separately. Correlation ID O This IE is used for: - the correlation of dialogues from the initiating gsmSSF-> gsmSCF with dialogues from gsmSRF -> gsmSCF; - the correlation of dialogues from the initiating gsmSSF-> gsmSCF with dialogues from assisting gsmSSF -> gsmSCF. Carrier O This IE is described in a table below. NA Originating Line Information O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O This IE identifies the chargeable number for the usage of a North American carrier. gsmSCF ID O This IE indicates the gsmSCF identifier. Service Interaction Indicators Two O This IE indicates whether or not a bothway through connection is required between the call segment and the calling party. When there is no calling party connected to the call segment, then the gsmSSF shall ignore this IE, if received. The handling when this IE is not present is defined in ETSI ENÊ301Ê070 1Ê[41]. Call Segment ID M This IE indicates the call segment to be connected to the resource. The subsequent user interaction shall apply to all parties connected to the call segment. Original Called Party ID O This IE may be used to identify the original called party. If present, it shall be included in the ISUP IAM for the Temporary Connection. Support of this IE in the gsmSSF is an implementation option. Calling Party Number O This IE may be used to identify the calling party. If present, it shall be included in the ISUP IAM for the Temporary Connection. Support of this IE in the gsmSSF is an implementation option. Carrier contains the following information elements: Information element name Status Description Carrier Identification Code M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M This IE indicates the way the carrier was selected, i.e.: - dialled; - subscribed. 4.6.2.14 Furnish Charging Information 4.6.2.14.1 Description This IF is used to request the gsmSSF to include call related information in the CAMEL specific logical call record. The logical call record is created when the Furnish Charging Information IF is received and a logical call record for that leg does not exist. For modelling purposes the logical call record is buffered in the gsmSSF. The gsmSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then the free format data are moved to the corresponding CDR and the logical call record is deleted. The gsmSCF can send multiple concatenated Furnish Charging Information IFs per leg for completion. The total maximum of free format data is 160 octets per leg. The 160 octets may be sent in one or more FCI IFs. If there are incomplete free format data and new Furnish Charging Information IF(s) is/are received to overwrite the non-completed data, then the non-complete data are discarded and the gsmSCF can send another 160 octets per leg. The SDLs of the present document define when logical call records are completed. After the completion the gsmSCF can send another 160 octets of the free format data in one or more Furnish Charging Information IFs for the called leg. 4.6.2.14.2 Information Elements Information element name Status Description FCI Billing Charging Characteristics M This IE is described in a table below. FCI Billing Charging Characteristics contains the following information element: Information element name Status Description FCIBCCCAMEL Sequence 1 M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information elements: Information element name Status Description Free Format Data M This IE contains the free format data to be inserted in the CAMEL logical call record. Party To Charge M This IE indicates the party for whom a CAMEL logical call record will be created. Append Free Format Data O This IE indicates that the gsmSSF shall append the free format data to the logical call record. - If this IE is present and indicates ""Append"", the gsmSSF shall append the free format data received in this IF to the free format data already present in the logical call record for that leg of the call. - If this IE is absent or indicates ""Overwrite"", then the gsmSSF shall overwrite all free format data already present in the logical call record for that leg of the call, by the free format data received in this IF. If no logical call record exists for that leg of the call, then the gsmSSF shall ignore this IE. 4.6.2.15 Initiate Call Attempt 4.6.2.15.1 Description This IF is used to request the gsmSSF to create a new party in an existing call (NP), or to create a completely new call (NC). The created leg is an originating call. The address information provided by the gsmSCF is used. 4.6.2.15.2 Information Elements Information element name NC NP Description Destination Routeing Address M M This IE contains the called party number towards which the call is to be routed. For calls to an MS this can e.g. be (but shall not be limited to) the MSISDN (for routeing via a GMSC) or the MSRN received from the HLR (for routeing direct to the VMSC). Calling Party Number M - This IE identifies which number shall be regarded as the calling party for the created call. Leg To Be Created M M This IE indicates the legID to be assigned to the newly created party. The leg ID shall be 3 or higher. New Call Segment M M This IE indicates the CS ID to be assigned to the newly created call segment. Call Reference Number M - This IE may be used by the gsmSCF for inclusion in a network optional gsmSCF call record. The call reference number is included by the MSC in the call record. gsmSCF Address M - This IE contains the address of the gsmSCF which initiated the new call. This IE is required for a unique Call Reference. Suppress T CSI O O This IE indicates that T CSI shall be suppressed on the terminating leg. 4.6.2.16 Move Leg 4.6.2.16.1 Description This IF requests the gsmSSF to move a leg to CSID1. After the move the source call segment is deleted. In moving the specified leg, the conditions of the leg: the armed EDPs, the Stored e parameters, the Non-completed CAMEL logical call records, and the Call Information Report pending, are also applied for the same leg after the move. 4.6.2.16.2 Information Elements Information element name Status Description Leg ID To Move M This IE indicates the leg that shall be moved. 4.6.2.17 Play Tone 4.6.2.17.1 Description This IF is used to play a variable sequence of tones to a particular leg or call segment using the MSC's tone generator. Refer to subclauseÊ4.5.7.1.2 for a graphical representation of the variable sequence of tones. In order to avoid tone bursts being played in close succession to the same party or group of parties, the gsmSCF is responsible for careful use of this IF especially when warning tones have been scheduled using the Apply Charging IF. 4.6.4.17.2 Information Elements Information element name Status Description Leg or Call Segment M This IE is described in a table below. This IE indicates the leg or call segment. Burst List M This IE is described in a table below. This IE indicates a variable sequence of bursts. Leg or Call Segment contains the following information elements: Information element name Status Description Call Segment ID E This IE indicates the call segment to which tones shall be played. Leg ID E This IE indicates the leg to which tones shall be played. Burst List contains the following information elements: Information element name Status Description Number of bursts M This IE indicates the number of bursts to be played. There may be up to three bursts. Burst interval M This IE indicates the time interval between successive bursts. Number of tones in burst M This IE indicates the number of tones to be played in each burst. There may be up to three tones per burst. The tone is fixed to 900 Hz. Tone Duration M This IE indicates the duration of each tone in a burst. Tone Interval M This IE indicates the time interval between successive tones in a burst. 4.6.2.18 Release Call 4.6.2.18.1 Description This IF is used by the gsmSCF to tear down an existing call at any phase of the call for all parties involved in the call. 4.6.2.18.2 Information Elements Information element name Status Description Release Cause E This IE indicates the Release Cause for the call. This may be used by the MSC or GMSC for generating specific tones to the different parties in the call or to fill in the ""cause"" in the Release IF. Release Cause With Extensions E This IE indicates the Release Cause for the call. This may be used by the MSC or GMSC for generating specific tones to the different parties in the call or to fill in the ""cause"" in the Release IF. This IE may include additional network specific IE. It may be used by the gsmSCF only if the Initial DP IF or ICA Ack contained the 'Release Call Argument Extension Allowed' IE. 4.6.2.19 Request Report BCSM Event 4.6.2.19.1 Description This IF is used to request the gsmSSF to monitor for a call-related event, then send a notification back to the gsmSCF when the event is detected (see Event Report BCSM). 4.6.2.19.2 Information Elements Information element name MO MF MT VT NC NP TO Description BCSM Event M M M M M M M This IE specifies the event or events for which a report is requested. BCSM Event contains the following information elements: Information element name MO MF MT VT NC NP TO Description Event type M M M M M M M This IE specifies the type of event for which a report is requested. Leg ID C C C C C M C This IE indicates the party in the call for which the event shall be armed or disarmed. Monitor Mode M M M M M M M If this IE is ""interrupted"" then the event shall be reported as a request, if this IE is ""notify and continue"" then the event shall be reported as a notification, if this IE is ""transparent"" then the event shall not be reported. DP Specific Criteria O O O O O O O This IE is described in a table below. Automatic Rearm O O O O - - O This IE indicates that the detection point shall be automatically rearmed by the gsmSSF when it is encountered. This IE may be present only if the Event Type is O_Mid_Call, T_Mid_Call, O_Change_Of_Position, T_Change_Of_Position, O_Service_Change or T_Service_Change and the Monitor Mode is ""notify and continue"". The MF and MT cases apply for O_Service_Change or T_Service_Change DPs only. The TO case applies for O_Mid_Call and O_Service_Change DPs only. DP Specific Criteria contains the following information elements: Information element name MO MF MT VT NC NP TO Description Application Timer O O O O O O O This IE carries additional timer duration information (timer values for No_Answer event) required for arming the No_Answer EDPs in the gsmSSF. The TNRy timer (value defined between 10Êseconds and 40Êseconds) shall be shorter than the network no answer timer. Mid Call Control Info O - - O - - O This IE is described in a table below. This IE carries the criterion for the detection and reporting of the mid-call event. If this IE is absent, then mid-call triggering shall take place when the first digit has been entered by the user. Change of Position Control Info O - - O - - - This IE is described in a table below. It carries the list of criteria for the reporting of the change of position event. If the DP Specific Criteria IE is absent, then the criteria for any change of position shall be regarded as fulfilled. Number of Digits - - - - - - O This IE indicates the number of additional digits requested by the gsmSCF to be collected by the gsmSSF before the CollectedInfo event is reported, excluding the digits reported already. It excludes the end of pulsing signal (ST) Inter Digit Timeout - - - - - - O This IE carries additional timer duration information required for arming the CollectedInfo event in the gsmSSF. The IE indicates the maximum duration allowed between receipt of successive digits from the calling party. The Inter Digit timer value shall be shorter than the network inter-digit timer. The MSC/ gsmSSF shall use the network inter-digit timer duration as the default duration. If one or more CollectInformation operations are received in a call then the latest received value overwrites the previous value. If the latest CollectInformation does not include this IE then the previous value applies. NOTE If a Request Report BCSM Event information flow overwrites previous Request Report BCSM Event information flow which contained Application Timer IE for No_Answer DP, the behaviour of the gsmSSF is unpredictable. Mid Call Control Info contains the following information elements: Information element name MO MF MT VT NC NP TO Description Minimum Number Of Digits M - - M - - M This IE indicates the minimum number of digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. Maximum Number Of Digits M - - M - - M This IE indicates the maximum number of digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. If triggering takes place due to the detection of the maximum number of digits and the End of reply digit string, if present, is partially detected, then the partially detected End of reply digit string shall be included in the digit string to be reported to the gsmSCF. End of Reply Digit String O - - O - - O This IE, if present, indicates the digit string that denotes the end of the digits to be collected. If triggering takes place due to the detection of the End of reply digit string, then this string shall be included in the digit string to be reported to the gsmSCF. If the interdigit timeout expires when the Start Digit String, if present, is complete and the Minimum Number Of Digits has been detected and the End Digit String, if present, has been partially detected then triggering shall take place. The partially detected End Of Reply Digit String shall be included in the string to be reported to the gsmSCF. Cancel Digit String O - - O - - O This IE, if present, indicates the digit string that indicates that the input shall be erased and that digit collection, including the start digit string, if present, shall start afresh. Start Digit String O - - O - - O This IE, if present, indicates the digit string that denotes the start of the digits to be collected. If this IE is absent, then the first digit entered forms part of the digits to be collected. When triggering takes place, then the Start digit string shall be included in the digit string to be reported to the gsmSCF. Inter Digit Timeout M - - M - - M This IE indicates the maximum duration allowed between receipt of successive digits from the MS. For the TO case, this IE indicates the maximum duration allowed between receipt of successive digits from the calling party. Change of Position Control Info contains a list of up to 10 instances of the following information element: Information element name MO MF MT VT NC NP Description Change Of Location M - - M - - Each Change Of Location IE is one of the 6 possibilities indicated in the table below. If multiple instances of the Change Of Location IE have the same value, this is not an error. Each instance of the Change Of Location IE contains one of the following information elements: Information element name MO MF MT VT NC NP Description Cell Global ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the cell specified in this IE, i.e. handover into or out of the cell. Service Area ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the service area specified in this IE, i.e. handover into or out of the service area. Location Area ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the location area specified in this IE, i.e. handover into or out of the location area. Inter-System Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-system handover. Inter-PLMN Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-PLMN handover. Inter-MSC Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-MSC handover. 4.6.2.20 Reset Timer 4.6.2.20.1 Description This IF is used to reset a timer. 4.6.2.20.2 Information Elements Information element name Status Description Timer Value M This IE specifies the value to which the indicated timer shall be set. Timer ID O This IE indicates which timer shall be reset. It shall be set to 'Tssf'. Call Segment ID M This IE indicates for which Call Segment in the gsmSSF the timer shall be reset. 4.6.2.21 Send Charging Information 4.6.2.21.1 Description This IF is used to send e parameters from the gsmSCF to the gsmSSF. If Charge Advice Information (CAI) is received from the gsmSCF, it shall replace the CAI which would be generated by the MSC and inhibit any further generation of CAI by the MSC. Further processing of the CAI by the MSC shall be in accordance with the Advice of Charge supplementary service. If the subscriber is not provisioned with the Advice of Charge supplementary service or if the VPLMN does not support this service, then no e parameters shall be sent to the MS and no error due to this fact shall be sent back to the gsmSCF. The IF is only used in the MO case or in the VT case. NOTE: If CAI is received from the gsmSCF after charge information has been generated by the MSC and sent to the MS, the behaviour of the service may be unpredictable or incorrect; the service designer should therefore ensure that the first set of CAI is sent to the gsmSSF before charge information is sent to the MS. 4.6.2.21.2 Information Elements Information element name MO MF MT VT NC NP Description SCI Billing Charging Characteristics M - - M - - This IE defines the Advice Of Charge related information to be provided to the Mobile Station. Leg ID M - - M - - This IE indicates the leg to which the charging information shall be sent. SCI Billing Charging Characteristics contains the following information elements: Information element name MO MF MT VT NC NP Description AoC After Answer S,E - - S,E - - This IE is described in a table below. This IE is present after an Answer event has been detected from the called party, the current connected SRF or the temporary connection. AoC Before Answer S,E - - S,E - - This IE is described in a table below. This IE is present before an Answer event has been detected from the called party, the current connected SRF or the temporary connection. AoC Before Answer contains the following information elements: Information element name MO MF MT VT NC NP Description AoC Initial M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. AoC Subsequent O - - O - - This IE is described in a table below. AoC Subsequent contains the following information elements: Information element name MO MF MT VT NC NP Description CAI Elements M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O - - O - - This IE indicates the tariff switch time until the next tariff switch applies. AoC After Answer contains the following information elements: Information element name MO MF MT VT NC NP Description CAI Elements M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O - - O - - This IE indicates the tariff switch time until the next tariff switch applies. 4.6.2.22 Split Leg 4.6.2.22.1 Description This IF is used to request the gsmSSF to separate a leg from CSID1 and move it to a new call segment. If CSID1 does not exist, then this IF is used to request the gsmSSF to move a leg into a newly created CSID1. In splitting the specified leg, the conditions of the leg: the armed EDPs, the Stored e parameters, the Non-completed CAMEL logical call records, and the Call Information Report pending, are also applied for the same leg after split. 4.6.2.22.2 Information Elements Information element name Status Description Leg To Be Split M This IE indicates the leg in the call to be split. New Call Segment M This IE indicates the Call Segment ID to be assigned to the new call segment. 4.6.3 Optional (Service logic dependent) gsmSCF to gsmSRF information flows 4.6.3.1 Activity Test 4.6.3.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gsmSRF. If the relationship is still in existence, then the gsmSRF will respond. If no reply is received, then the gsmSCF will assume that the gsmSRF has failed in some way and will take the appropriate action. 4.6.3.1.2 Information Elements This IF contains no information elements. 4.6.3.2 Cancel 4.6.3.2.1 Description This IF is used by the gsmSCF to request the gsmSRF to cancel a correlated previous IF. 4.6.3.2.2 Information Elements Information element name Status Description Invoke ID E This IE specifies the IF to be cancelled. This IE may be used when the Cancel IF is used in a single call segment CSA or when the Cancel IF is sent by the gsmSCF to an Intelligent Peripheral. Call Segment To Cancel E This IE may be used when the Cancel IF is used in a single call segment CSA or in a multi call segment CSA. This IE is described in a table below. This IE shall not be used when the Cancel IF is sent by the gsmSCF to an Intelligent Peripheral. Call Segment To Cancel contains the following information elements: Information element name Status Description Invoke ID M This IE specifies the IF to be cancelled. Call Segment ID M This IE specifies to which call segment the cancellation of the user interaction IF shall apply. 4.6.3.3 Play Announcement 4.6.3.3.1 Description This IF is used for inband interaction. 4.6.3.3.2 Information Elements Information element name Status Description Information To Send M This IE is described in a table below. Disconnect From IP Forbidden M This IE indicates whether or not the gsmSRF may be disconnected from the user when all information has been sent. Request Announcement Complete Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when all information has been sent. Request Announcement Started Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when the first announcement or tone starts. Call Segment ID S This IE indicates the call segment to which the user interaction shall apply. This IE shall be absent if this IF is sent by the gsmSCF to an Intelligent Peripheral. Information To Send contains the following information elements: Information element name Status Description Inband Info E This IE is described in a table below. Tone E This IE is described in a table below. Inband Info contains the following information elements: Information element name Status Description Message ID M This IE is described in a table below. Number Of Repetitions M This IE indicates the maximum number of times the message shall be sent to the end-user. Duration O This IE indicates the maximum duration time in seconds that the message shall be played/repeated. Zero indicates endless repetition. Interval O This IE indicates the time interval in seconds between two repetitions. Message ID contains the following information elements: Information element name Status Description Elementary Message ID E This IE indicates a single announcement Text E This IE indicates a text to be sent. The text shall be transformed to inband information (speech) by the gsmSRF. Elementary Message IDs E This IE indicates a sequence of announcements Variable Message E This IE indicates an announcement with one or more variable parts. Tone contains the following information elements: Information element name Status Description Tone ID M This IE indicates the tone to be sent. Duration O This IE indicates the maximum duration in seconds that the message shall be played/repeated. Zero indicates endless repetition. 4.6.3.4 Prompt And Collect User Information 4.6.3.4.1 Description This IF is used to interact with a call party in order to collect information. 4.6.3.4.2 Information Elements Information element name Status Description Collected Info M This IE is described in a table below. Information To Send O This IE is described in subclauseÊ4.6.3.3.2. This IE indicates an announcement or a tone to be sent to the end user by the gsmSRF. Disconnect From IP Forbidden M This IE indicates whether the gsmSRF may be disconnected from the user when all information has been sent. Request Announcement Started Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when the first announcement or tone starts. Call Segment ID S This IE indicates the call segment to which the user interaction shall apply. This IE shall be absent if this IF is sent by the gsmSCF to an Intelligent Peripheral. Collected Info contains the following information element: Information element name Status Description Collected Digits M This IE is described in a table below. Collected Digits contains the following information elements: Information element name Status Description Minimum Number Of Digits M This IE indicates the minimum number of valid digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. Maximum Number Of Digits M This IE specifies the maximum number of valid digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. End Of Reply Digit O This IE indicates the digit(s) used to signal the end of input. Cancel Digit O If this IE is present then the cancel digit can be entered by the user to request a possible retry. Start Digit O If this IE is present then the start digit(s) indicates the start of the valid digits to be collected. First Digit Time Out O If this IE is present then the first digit shall be received before the expiration of the first digit timer expiration. Inter Digit Time Out O If this IE is present then any subsequent valid or invalid digit shall be received by the gsmSRF before the inter digit timer expires. Error Treatment O This IE indicates what specific action shall be taken by the gsmSRF in the event of error conditions occurring. Interruptable Ann Ind O If this IE is set to TRUE (default value) then the announcement is interrupted after the first valid or invalid digit received by the gsmSRF. If this IE is present and explicitly set to FALSE then the announcement will not be interrupted after the first digit is received by the gsmSRF. Voice Information O If this IE is set to FALSE (default value) then all valid or invalid digits are entered by DTMF. If this IE is set to TRUE then the calling user is required to provide all valid or invalid information by speech. Voice Back O If this IE is set to FALSE (default value) then no voice back information is given by the gsmSRF. If this IE is set to TRUE then the valid input digits received by the gsmSRF will be announced back to the calling user immediately after the end of input is received. 4.6.4 gsmSRF to gsmSCF information flows 4.6.4.1 Activity Test ack 4.6.4.1.1 Description This IF is the response to the Activity Test. 4.6.4.1.2 Information Elements This IF contains no information elements. 4.6.4.2 Assist Request Instructions 4.6.4.2.1 Description This IF is sent to the gsmSCF by a gsmSSF which is acting as the assisting gsmSSF or by a gsmSRF. 4.6.4.2.2 Information Elements Information element name Status Description Correlation ID M This IE is used to associate the Assist Request Instructions IF from an assisting gsmSSF or by a gsmSRF with the Initial DP IF from the initiating gsmSSF. IP SSP Capabilities M This IE indicates which SRF resources are attached, available and supported within the MSC where the gsmSSF resides or the IP in which the gsmSRF resides. 4.6.4.3 Prompt And Collect User Information ack 4.6.4.3.1 Description This IF is used by the gsmSRF to indicate the result of a Prompt And Collect User Information IF. 4.6.4.3.2 Information Elements Information element name Status Description Digits Response C This IE indicates the digit sequence received from the end user. 4.6.4.4 Specialized Resource Report 4.6.4.4.1 Description This IF is used when a Specialized Resource Report was requested in a Play Announcement IF or in a Prompt and Collect User Information IF. 4.6.4.4.2 Information Elements Information element name Status Description All Announcements Complete E This IE indicates that all the announcements and tones are complete. First Announcement Started E This IE indicates that the first announcement or tone has started. 4.6.5 gsmSCF to Assisting SSF information flows 4.6.5.1 Activity Test 4.6.5.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and assistSSF. If the relationship is still in existence, then the assistSSF will respond. If no reply is received, then the gsmSCF will assume that the assistSSF has failed in some way and will take the appropriate action. 4.6.5.1.2 Information Elements This IF contains no information elements. 4.6.5.2 Cancel 4.6.5.2.1 Description This IF is used by the gsmSCF to request the assisting gsmSSF to cancel a correlated previous IF. 4.6.5.2.2 Information Elements Information element name Status Description Invoke ID M This IE specifies the IF to be cancelled. 4.6.5.3 Connect To Resource 4.6.5.3.1 Description This IF is described in subclauseÊ4.6.2.7. The following difference applies: - The Call Segment ID information element is not used. 4.6.5.4 Disconnect Forward Connection 4.6.5.4.1 Description This IF is used to disconnect a connection with a gsmSRF previously established with a Connect To Resource IF. 4.6.5.4.2 Information Elements This IF contains no information elements. 4.6.5.5 Play Announcement 4.6.5.5.1 Description This IF is described in subclauseÊ4.6.3.3. The following difference applies: - The Call Segment ID information element is not used. 4.6.5.6 Prompt And Collect User Information 4.6.5.6.1 Description This IF is described in subclauseÊ4.6.3.4."
"The following difference applies: - The Call Segment ID information element is not used. 4.6.5.7 Reset Timer 4.6.5.7.1 Description This IF is described in subclauseÊ4.6.2.20. The following difference applies: - The Call Segment ID information element is not used. 4.6.6 Assisting SSF to gsmSCF information flows 4.6.6.1 Activity Test ack 4.6.6.1.1 Description This IF is the response to the Activity Test. 4.6.6.1.2 Information Elements This IF contains no information elements. 4.6.6.2 Assist Request Instructions 4.6.6.2.1 Description This IF is described in subclauseÊ4.6.4.2. 4.6.6.3 Prompt And Collect User Information ack (received information) 4.6.6.3.1 Description This IF is described in subclauseÊ4.6.4.3. 4.6.6.4 Specialized Resource Report 4.6.6.4.1 Description This IF is described in subclauseÊ4.6.4.4. 4.6.7 HLR to VLR information flows 4.6.7.1 Delete Subscriber Data 4.6.7.1.1 Description This IF is used by an HLR to delete CAMEL subscription data from a VLR. It is specified in 3GPP TSÊ29.002Ê[34]. 4.6.7.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O,E This IE identifies that all CSIs shall be deleted from the subscriber data in the VLR. Specific CSI Withdraw O,E This IE indicates that one or more specific elements of CAMEL Subscription Info shall be deleted from the VLR. The specific elements of CAMEL Subscription Info which may be deleted are: - O CSI with TDP criteria for O CSI; - TIF CSI; - D CSI; - VT CSI with TDP criteria for VT CSI. This IE should not be present when CAMEL Subscription Info Withdraw is present. 4.6.7.2 Insert Subscriber Data 4.6.7.2.1 Description This IF is used by an HLR to update a VLR with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 4.6.7.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information elements for circuit switched call control: Information element name Status Description O CSI O This IE is described in a table below. This IE identifies the subscriber as having originating CAMEL services. D CSI O This IE is described in a table below. This IE identifies the subscriber as having originating CAMEL dialled services. VT CSI O This IE is described in a table below. This IE identifies the subscriber as having terminating CAMEL services in the VMSC. TIF CSI O See 3GPP TSÊ23.072Ê[16]. O CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.1 Service Key M This IE is described in subclauseÊ4.3.1. Default Call Handling M This IE is described in subclauseÊ4.3.1. TDP List M This IE is described in subclauseÊ4.3.1. DP Criteria O This IE is described in subclauseÊ4.3.1. CAMEL Capability Handling C This IE is described in subclauseÊ4.3.1. If this IE is absent, this indicates that CAMEL phaseÊ1 support is requested. D CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.2. Service Key M This IE is described in subclauseÊ4.3.2. Default Call Handling M This IE is described in subclauseÊ4.3.2. DP Criteria M This IE is described in subclauseÊ4.3.2. CAMEL Capability Handling M This IE is described in subclauseÊ4.3.2. The CAMEL Capability Handling shall indicate CAMEL phaseÊ3 or higher. VT CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.6. Service Key M This IE is described in subclauseÊ4.3.6. Default Call Handling M This IE is described in subclauseÊ4.3.6. TDP List M This IE is described in subclauseÊ4.3.6. DP Criteria O This IE is described in subclauseÊ4.3.6. CAMEL Capability Handling M This IE is described in subclauseÊ4.3.6. The CAMEL Capability Handling shall indicate CAMEL phaseÊ3 or higher. 4.6.7.3 Provide Subscriber Info 4.6.7.3.1 Description This IF is described in TSÊ23.018Ê[12]; it is used by the HLR to request information (any one or more of subscriber state, subscriber location, IMEI & software version and MS classmark information for the CS domain) from the VLR at any time. 4.6.7.4 Provide Roaming Number 4.6.7.4.1 Description This IF is specified in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to request a roaming number from the VLR. 4.6.7.4.2 Information Elements Provide Roaming Number contains the following CAMEL specific information elements: Information element name Status Description Suppression Of Announcements S This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. It shall be present if the HLR received it in the Send Routeing Info IF. Call Reference Number M This IE carries the Call Reference Number provided by the GMSC or the gsmSCF in the Send Routeing Info IF. GMSC Or gsmSCF Address M This IE is the E.164 address of the GMSC for an MT call or the E.164 address of the gsmSCF for a gsmSCF initiated call. Alerting Pattern S This IE indicates the kind of Alerting Pattern to be applied. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info IF. Supported CAMEL Phases in Interrogating Node S This IE indicates the CAMEL Phases supported in the GMSC or the gsmSCF. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. Offered CAMEL4 CSIs in Interrogating Node S This IE indicates the CAMEL phaseÊ4 CSIs offered in the GMSC or the gsmSCF. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. This IE is described in a table below. Suppress VT CSI S This IE indicates that VT CSI shall be suppressed for the called party. This IE shall be present if the HLR received it in the Send Routeing Info IF. OR not Supported In GMSC S This IE indicates that the VMSC should not attempt to invoke Optimal Routeing of late call forwarding. It shall be present if this IF was triggered by a Send Routeing IF for a gsmSCF initiated call. Offered CAMEL4 CSIs in Interrogating Node contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. 4.6.8 VLR to HLR information flows 4.6.8.1 Insert Subscriber Data ack 4.6.8.1.1 Description This IF is used by the VLR to indicate to the HLR the result of the Insert Subscriber Data IF. It is specified in 3GPP TSÊ29.002Ê[34]. 4.6.8.1.2 Information Elements Insert Subscriber Data ack contains the following CAMEL specific information elements: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the VMSC/VLR. It shall be present when a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if a CSI has been included in the Insert Subscriber Data IF and the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. 4.6.8.2 Provide Subscriber Info ack 4.6.8.2.1 Description This IF is described in TSÊ23.018Ê[12]; it is used by the VLR to provide the requested information to the HLR. 4.6.8.3 Update Location 4.6.8.3.1 Description This IF is used by the VLR to provide information about supported CAMEL phases to the HLR. 4.6.8.3.2 Information Elements Update Location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which phases of CAMEL are supported. It shall be present if a CAMEL phase higher than phaseÊ1 is supported. Otherwise may be absent. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. 4.6.8.4 Restore Data 4.6.8.4.1 Description This IF is used by the VLR to provide the information about supported CAMEL phases to the HLR. 4.6.8.4.2 Information Elements Restore Data contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which phases of CAMEL are supported. It shall be present if a CAMEL phase higher than phaseÊ1 is supported. Otherwise may be absent. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI 4.6.9 HLR to GMSC information flows 4.6.9.1 Send Routeing Info ack 4.6.9.1.1 Description This IF is specified in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to transfer the requested routeing information to the GMSC. 4.6.9.1.2 Information Elements Send Routeing Info ack contains the following CAMEL specific information elements: Information element name Status Description Location Information C This IE indicates the location of the served subscriber. O CSI S O CSI is defined in subclauseÊ4.3.1. This IE identifies the subscriber as having originating CAMEL services. It shall be present if O CSI is active, and CFU or CFNRc has been invoked, or if both O CSI and T CSI are active. D CSI S D CSI is defined in subclauseÊ4.3.2. This IE identifies the subscriber as having originating CAMEL dialled services. It shall be present if D CSI is active, and CFU or CFNRc has been invoked, or if both D CSI and T CSI are active. Subscriber State C This IE indicates the state of the MS. The possible values of the IE are: - CAMEL Busy: The VLR has indicated that the MS is engaged in a transaction for a mobile originating or terminated circuit-switched call. - Network Determined Not Reachable: The HLR or VLR has indicated that the network can determine from its internal data that the MS is not reachable. - Assumed Idle: The VLR has indicated that the state of the MS is neither ""CAMEL Busy"" nor ""Network Determined Not Reachable"". - Not Provided From VLR: The VLR did not provide any information on subscriber state even though it was requested. T CSI S This IE is described in a table below. This IE identifies the subscriber as having terminating CAMEL services. It shall be present if T CSI is active and no Suppress T CSI indicator is present in the Send Routeing Info IF. Basic Service Code C This IE indicates the type of basic service, i.e. teleservice or bearer service. CUG Subscription Flag S This IE indicates if the called party has a CUG subscription. It shall be present only if the T CSI is active and included in the Send Routing Information ack IF. Supported CAMEL Phases In VMSC S This IE indicates the supported CAMEL phases of the VLR. It shall be present if known by the HLR, otherwise it shall be absent. Offered CAMEL4 CSIs In VMSC S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC. It shall be present if known by the HLR, otherwise it shall be absent. VMSC Address M This IE indicates the E.164 address of the VMSC in whose area the B subscriber is currently registered. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number C See 3GPP TSÊ23.018Ê[12]. The HLR shall include the internally stored VLR Number. Current Location Retrieved - Not applicable Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S This IE indicates the LSA identity associated with the current position of the MS. Shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. If there are multiple matches the LSA ID with the highest priority shall be sent. See 3GPP TSÊ23.073Ê[18]. E-UTRAN Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E See 3GPP TSÊ23.018Ê[12]. T CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.5. Service Key M This IE is described in subclauseÊ4.3.5. Default Call Handling M This IE is described in subclauseÊ4.3.5. TDP List M This IE is described in subclauseÊ4.3.5. DP Criteria S This IE is described in subclauseÊ4.3.5. The HLR shall send only the criteria associated with DPÊT_Busy or DPÊT_No_Answer, if available. CAMEL Capability Handling C This IE is described in subclauseÊ4.3.5. If this IE is absent then this indicates that CAMEL phaseÊ1 support is requested. Offered CAMEL4 CSIs In VMSC contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. It shall be present if known by the HLR, otherwise it shall be absent. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. It shall be present if known by the HLR, otherwise it shall be absent. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. It shall be present if known by the HLR, otherwise it shall be absent. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. It shall be present if known by the HLR, otherwise it shall be absent. 4.6.10 GMSC to HLR information flows 4.6.10.1 Send Routeing Info 4.6.10.1.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request information from the HLR to route an MT call. 4.6.10.1.2 Information Elements Send Routeing Info contains the following CAMEL specific information elements: Information element name Status Description Alerting Pattern S This IE indicates the kind of Alerting Pattern to be applied. It shall be present if it was received from the gsmSCF or set by the gsmSSF. Suppression Of Announcement S This IE indicates that announcements or tones generated as a result of unsuccessful call setup shall be suppressed. It shall be present in the interrogation if available, i.e. when it has been received from the gsmSCF. Suppress T CSI S This IE indicates that T CSI shall be suppressed. It shall always be present in the second interrogation or if it was received from the gsmSCF due to an Initiate Call Attempt IF. Supported CAMEL Phases M This IE lists the supported CAMEL phases in the GMSC. Offered CAMEL4 CSIs M This IE indicates the CAMEL phaseÊ4 CSIs offered in the GMSC. This IE is described in a table below. Call Reference Number M This IE carries the Call Reference Number allocated for the call by the GMSC. It shall be allocated once per call and present in both first and second interrogations. GMSC Address M This IE is the E.164 address of the GMSC. Call Diversion Treatment Indicator S This IE indicates whether or not the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. It shall be present if it was received within Forward Service Interaction Indicator in Service Interaction Indicators Two from the ISUP Initial Address Message or previous CAMEL processing. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. 4.6.11 VMSC to GMSC information flows 4.6.11.1 Resume Call Handling 4.6.11.1.1 Description This IF is described in 3GPP TSÊ23.079Ê[19], it is used to request the GMSC to take over handling the call so that it can be forwarded from the GMSC. 4.6.11.1.2 Information Elements Resume Call Handling contains the following CAMEL specific information elements: Information element name Status Description O CSI S This IE indicates that CAMEL handling applies for an optimally routed late forwarded call. This IE shall be present if CAMEL handling applies; otherwise it shall be absent. Trigger criteria for DPÊCollected_Information, if present, shall be omitted from this IF. Trigger criteria for DPÊRoute_Select_Failure, if present, shall be included in this IF. D CSI S This IE indicates that CAMEL handling applies for an optimally routed late forwarded call. This IE shall be present if CAMEL handling applies; otherwise it shall be absent. 4.6.12 MSC to VLR information flows 4.6.12.1 Send Info For ICA 4.6.12.1.1 Description This IF is used to request the VLR to provide information to handle an outgoing call leg created by the gsmSCF. 4.6.12.1.2 Information Elements Information element name NP Description Called Number M This IE indicates the E.164 number of the call leg destination. IMSI M This IE is the IMSI of the served CAMEL subscriber. CUG Index C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress Preferential CUG C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress CUG Outgoing Access C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress Outgoing Call Barring C This IE indicates that outgoing call barrings shall be suppressed for the call leg. Suppress D CSI S This IE indicates that D CSI shall be suppressed. It shall always be present in the second interrogation. N CSI Available S This IE indicates that N CSI is available in MSC. It shall be present in the first interrogation if N CSI is available in the MSC. Non CUG Call S This IE indicates that no parameters for CUG should be used for the call. It shall be present if received from gsmSCF. CUG Interlock Code S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if received from gsmSCF. Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if received from gsmSCF. 4.6.12.2 Send Info For Incoming Call 4.6.12.2.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request the VLR to provide information to handle an incoming call. 4.6.12.2.2 Information Elements Send Info For Incoming Call contains the following CAMEL specific information elements: Information element name Status Description Suppress VT CSI S This IE indicates that VT CSI shall be suppressed. It shall never be present in the first interrogation; it shall always be present in the second interrogation. Call Diversion Treatment Indicator S This IE indicates whether or not the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. It shall be present if received within the Forward Service Interaction Indicator in the Service Interaction Indicators Two from the IAM or previous CAMEL processing. 4.6.12.3 Send Info For MT Reconnected Call 4.6.12.3.1 Description This IF is used to request the VLR to provide information to handle a reconnected MT call. 4.6.12.3.2 Information Elements Information element name Required Description Called Number M E.164 number of the call destination. 4.6.12.4 Send Info For Outgoing Call 4.6.12.4.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request the VLR to provide information to handle an outgoing call. 4.6.12.4.2 Information Elements Send Info For Outgoing Call contains the following CAMEL specific information elements: Information element name Status Description Suppress O CSI S This IE indicates that O CSI shall be suppressed. It shall always be present in the second interrogation. Suppress D CSI S This IE indicates that D CSI shall be suppressed. It shall always be present in the second interrogation. N CSI Available S This IE indicates that N CSI is available in MSC. It shall be present in the first interrogation if N CSI is available in the MSC. 4.6.12.5 Send Info For Reconnected Call 4.6.12.5.1 Description This IF is used to request the VLR to provide information to handle a reconnected MO call. 4.6.12.5.2 Information Elements Information element name Status Description Called Number M This IE indicates the E.164 number of the call destination. Bearer Service S,E This IE indicates the bearer service required for the MO call, derived from the CS bearer capability information received in the setup request from the MS. One of bearer service or teleservice shall be present. Teleservice S,E This IE indicates the teleservice required for the MO call, derived from the CS bearer capability information received in the setup request from the MS or from the emergency setup request from the MS. One of bearer service or teleservice shall be present. CUG Index S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress Preferential CUG S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress CUG Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress O CSI S This IE indicates that O CSI shall be suppressed. It shall always be present in the second interrogation. 4.6.13 VLR to MSC information flows 4.6.13.1 Complete Call 4.6.13.1.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to instruct the MSC to continue the connection of a call. 4.6.13.1.2 Information Elements Complete Call contains the following CAMEL specific information elements: Information element name MO MF MT VT NC NP Description O CSI S - - - - - This IE indicates that CAMEL handling applies for an MO call. It shall be present in the response to the first interrogation for an MO call if CAMEL handling applies; otherwise it shall be absent. It shall be absent from the response to the second interrogation for an MO call. D CSI C - - - - C This IE identifies the subscriber as having originating CAMEL dialled services. Call Reference Number - - - M - - This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address - - - M - - This IE is the E.164 address of the GMSC. 4.6.13.2 Continue CAMEL Handling 4.6.13.2.1 Description This IF is used to instruct the MSC to continue the CAMEL specific handling. 4.6.13.2.2 Information Elements Information element name Status Description VT CSI M This IE identifies the subscriber as having terminating CAMEL services in the VMSC. IMSI M This IE contains the IMSI of the B subscriber. MSISDN S This IE contains the E.164 number of the B subscriber. It will be used to create the redirecting number presented to the C subscriber. It shall be present if the call is to be forwarded or if it has been provided by the HLR in the Provide Roaming Number IF, otherwise it shall be absent. CUG Interlock S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if the VLR has determined that the forwarded call is to be treated as a CUG call in accordance with the rules in 3GPP TSÊ23.085Ê[22], otherwise it shall be absent. CUG Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if the VLR has determined that the forwarded call is to be treated as a CUG call with outgoing access in accordance with the rules in 3GPP TSÊ23.085Ê[22], otherwise it shall be absent. Location Information S This IE contains the information to define the location of the MS: see definition in 3GPP TSÊ23.018Ê[12]. It shall be present if location information was requested and is available; otherwise it shall be absent. GMSC-Address M This IE is the E.164 address of the GMSC which was received in the Provide Roaming Number. Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. ExtBasic Service Code M This IE indicates the type of basic service, i.e. teleservice or bearer service. Subscriber State M This IE indicates the status of the MS. The states are: - CAMELBusy: The MS is engaged on a transaction for a mobile originating or terminated circuit-switched call. - NetworkDeterminedNotReachable: The network can determine from its internal data that the MS is not reachable. - AssumedIdle: The state of the MS is neither ""CAMELBusy"" nor ""NetworkDeterminedNotReachable"". 4.6.13.3 Process Call Waiting 4.6.13.3.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to instruct the MSC to continue the connection of a waiting call. 4.6.13.3.2 Information Elements Process Call Waiting contains the following CAMEL specific information elements: Information element name Status Description Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address M This IE is the E.164 address of the GMSC. 4.6.13.4 Send Info For ICA negative response 4.6.13.4.1 Description This IF is used to indicate that the outgoing call leg for which the MSC requested subscription information shall not be connected. 4.6.13.4.2 Information Elements The negative response information elements can take the following values: - Bearer service not provisioned; - Call barred (Operator determined barring); - Call barred (Supplementary service barring); - CUG reject (Inconsistent access information - index incompatible with basic service); - CUG reject (Inconsistent access information - no CUG selected); - CUG reject (Outgoing calls barred within the CUG); - CUG reject (Unknown CUG index); - Teleservice not provisioned. 4.6.13.5 Send Info For Incoming Call ack 4.6.13.5.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to indicate that the incoming call for which the MSC requested subscription information shall be forwarded. 4.6.13.5.1 Information Elements Send Info For Incoming Call ack contains the following CAMEL specific information elements: Information element name Status Description O CSI S This IE indicates that originating CAMEL service handling applies for a forwarded call. It shall be present if originating CAMEL service handling applies; otherwise it shall be absent. D CSI S This IE indicates that originating CAMEL dialled service handling applies for a forwarded call. It shall be present if originating CAMEL dialled service handling applies; otherwise it shall be absent. Suppression Of Announcement S This IE indicates that announcements or tones generated when the call is forwarded shall be suppressed. It shall be present if it was received in the Provide Roaming Number for this call. Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address M This IE is the E.164 address of the GMSC. Supported CAMEL Phases S This IE lists the supported CAMEL phases in the GMSC. It shall be present if the VLR received it from the HLR in the Provide Roaming Number. 4.6.13.6 Send Info For Incoming Call negative response 4.6.13.6.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to indicate that the incoming call for which the MSC requested subscription information shall not be connected. 4.6.13.6.2 Information Elements Send Info For Incoming Call negative response contains the following CAMEL specific information element which may be attached as an IE to any of the negative response values defined in 3GPP TSÊ23.018Ê[12]: Information element name Status Description Suppression Of Announcement S This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. It shall be present if it was received in the Provide Roaming Number for this call. 4.6.13.7 Send Info For MT Reconnected Call ack 4.6.13.7.1 Description This IF is used to instruct the MSC to continue the connection of a reconnected MT call. 4.6.13.7.2 Information Elements Information element name Required Description O CSI S This IE indicates that originating CAMEL service handling applies for the reconnected call. It shall be present if originating CAMEL service handling applies; otherwise it shall be absent. D CSI S This IE indicates that originating CAMEL dialled service handling applies for the reconnected call. It shall be present if originating CAMEL dialled service handling applies; otherwise it shall be absent. 4.6.13.8 Send Info For MT Reconnected Call negative response 4.6.13.8.1 Description This IF is used to indicate that the reconnected MT call for which the MSC requested subscription information shall not be connected. 4.6.13.8.2 Information Elements The negative response information element can take the following value: - CUG reject 4.6.13.9 Send Info For Reconnected Call ack 4.6.13.9.1 Description This IF is used to instruct the MSC to continue the connection of a reconnected MO call. 4.6.13.9.2 Information Elements Send Info For Reconnected Call ack does not contain any information elements. 4.6.13.10 Send Info For Reconnected Call negative response 4.6.13.10.1 Description This IF is used to indicate that the reconnected MO call for which the MSC requested subscription information shall not be connected. 4.6.13.10.2 Information Elements The negative response information element can take the following value: - Call barred (Operator determined barring); - Call barred (Supplementary service barring). 4.6.14 Internal MSC information flows 4.6.14.1 Perform Call Forwarding ack 4.6.14.1.1 Description This IF is defined in 3GPP TSÊ23.018Ê[12]; it is used to inform the MSC that Call Forwarding is taking place. 4.6.14.1.2 Information Elements Perform Call Forwarding ack is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Forwarded-to Number M If the Forwarded-to Number is not available due to CAMEL handling (a Disconnect Leg IF has been received for Leg 2), then the MSC shall populate this parameter with a dummy number. 4.6.15 gsmSCF to HLR information flows 4.6.15.1 Send Routeing Info 4.6.15.1.1 Description This IF is defined in 3GPP TSÊ23.018Ê[12] and subclauseÊ4.6.10.1; it is used to request information from the HLR to route a gsmSCF initiated call. Refer to 3GPP TSÊ29.007Ê[35] for the usage of ISDN BC, ISDN LLC, ISDN HLC and MSISDN for the selection of the PLMN Basic Service. 4.6.15.1.2 Information Elements Send Routeing Info from the gsmSCF contains the following information elements: Information element name Status Description MSISDN M This IE indicates the MSISDN of the called subscriber. Alerting Pattern O This IE indicates the kind of Alerting Pattern to be applied. CUG Interlock O For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. CUG Outgoing Access O For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppression Of Announcement O This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Suppress T CSI M This IE indicates that CAMEL subscription information should not be returned in the first Send Routeing Info ack (to avoid the need for a second interrogation). Supported CAMEL Phases M This IE indicates the CAMEL Phases supported by the gsmSCF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered by the gsmSCF. This IE shall be present when the Supported CAMEL Phases IE indicates support of CAMEL PhaseÊ4. This IE is described in a table below. Call Reference Number M This IE carries the Call Reference Number allocated for the call by the gsmSCF. GMSC Or gsmSCF Address M This IE is the E.164 address of the gsmSCF. Call Diversion Treatment Indicator O This IE indicates whether or not the call is allowed to be forwarded on behalf of the called party using the Call Forwarding supplementary service. Pre-paging Supported S This IE shall be present if the gsmSCF supports pre-paging, otherwise it shall be absent. Interrogation Type M This IE shall contain the value ""Basic Call"". Long FTN Supported O This IE indicates that the gsmSCF supports Long Forwarded to Numbers. gsmSCF Initiated Call M This IE indicates that the IF was originated by a gsmSCF. Suppress Incoming Call Barring O This IE indicates that Incoming Call Barrings shall be suppressed for the called party. Suppress VT CSI O This IE indicates that VT CSI shall be suppressed. ISDN BC O ISDN bearer capability. See 3GPP TSÊ23.018Ê[12]. ISDN LLC O ISDN lower layer compatibility. See 3GPP TSÊ23.018Ê[12]. ISDN HLC O ISDN higher layer compatibility. See 3GPP TSÊ23.018Ê[12]. Suppress MT SS O This IE indicates the MT supplementary services that shall be suppressed for the called party. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. 4.6.16 HLR to gsmSCF information flows 4.6.16.1 Send Routeing Info ack 4.6.16.1.1 Description This IF is described in subclauseÊ4.6.9.1; it is used by the HLR to transfer the requested routeing information to the gsmSCF. 4.6.16.2 Send Routeing Info negative response 4.6.16.2.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to indicate that the routeing information is not available. 4.7 Interaction with supplementary services When the gsmSCF initiates a call to a subscriber, the gsmSCF can indicate to the HLR the MT supplementary services that shall be suppressed for this call. 4.7.1 Line identification For a call subject to CAMEL control, the gsmSCF shall have the option to send the Calling Party Restriction Indicator to the gsmSSF. This information element will be sent to the MSC and shall indicate whether the CLI Presentation Indicator present in the Calling Party Number shall be set by CAMEL action to Restricted. 4.7.2 Call forwarding services 4.7.2.1 Registration of Call Forwarding The functional behaviour for the registration of the Call Forwarding supplementary service is defined in 3GPP TSÊ23.082Ê[20]. The procedure specific to CAMEL is defined in this subclause: - CAMEL_Check_CF_Interaction. Figure 4.120-1: Procedure CAMEL_Check_CF_Interaction (sheet 1) 4.7.2.2 Invocation of Call Forwarding The functional behaviour for the invocation of the Call Forwarding supplementary service is defined in 3GPP TSÊ23.018Ê[12] and 3GPP TSÊ23.082Ê[20]. The following additional requirements apply. When Call Forwarding is invoked for a CAMEL subscriber with O CSI, the gsmSSF shall send the FTN to the gsmSCF in the format in which it was received from the HLR. When Call Forwarding is invoked for a CAMEL subscriber with D CSI or if an N CSI is present in the forwarding MSC, then the FTN shall be treated as defined in subclauseÊ4.2.1.2.2. If the Service Interaction Indicators Two parameter was included in the Initial Address Message, the Continue With Argument information flow or the Connect message, the appropriate indicator shall be applied for the forwarded call. An HLR shall not send an FTN which is not in international format to a GMSC which does not support CAMEL phaseÊ2, i.e. if the HLR is handling a request from a GMSC for routeing information and the forwarded-to number is registered in a format other than international, the service logic in the HLR shall behave as if the call forwarding is provisioned but not registered. 4.7.2.3 Invocation of Call Deflection The functional behaviour for the invocation of the Call Deflection supplementary service is defined in 3GPP TSÊ23.018Ê[12] and 3GPP TSÊ23.072Ê[16]. The following additional requirements apply. When Call Deflection is invoked by a CAMEL subscriber with O CSI, the gsmSSF shall send the DTN to the gsmSCF in the format in which it was received from the MS. When Call Deflection is invoked by a CAMEL subscriber with D CSI or if a N CSI is present in the VMSC, then the DTN shall be treated as defined in subclauseÊ4.2.1.2.2. If the Service Interaction Indicators Two parameter was included in the Initial Address Message, the Continue With Argument information flow or the Connect information flow, the appropriate indicator shall be applied for the deflected call. 4.7.3 Call Barring services When a CAMEL subscriber with O CSI and TIF CSI attempts to activate a conditional call barring service (BOIC,BOIC-exHC), the HLR shall not check the interactions with call forwarding."
"When the gsmSCF initiates a call to a subscriber, the gsmSCF can indicate to the HLR that incoming call barrings shall be suppressed for this call. When the gsmSCF creates an additional call leg in an existing call, the gsmSCF can indicate to the VLR (via the gsmSSF and MSC) that outgoing call barrings shall be suppressed for this call leg. 4.7.4 Closed User Group For a CUG subscriber with CAMEL services: - The HLR shall store (and transfer to the VLR) the necessary subscriber data to ensure that the served subscriber is not unnecessarily prevented by CUG constraints from originating calls. - The HLR shall store the necessary subscriber data to ensure that the served subscriber is not unnecessarily prevented by CUG constraints from receiving calls. For an MO, MF or TO call, the CUG information for that call shall be sent to the gsmSCF in the Initial DP information flow. If the gsmSCF returns a Continue information flow, the call shall continue with the original CUG information unchanged. If the gsmSCF returns a Connect or Continue With Argument information flow, the CUG handling in table 4.7 applies. Table 4.7: CUG handling on receipt of Connect or Continue With Argument for an MO, MF or TO call CUG parameters in information flow Handling Non-CUG call (note 1) Remove CUG information for the call and continue as a non-CUG call CUG information (note 2) Call shall continue with modified CUG information No CUG information Call shall continue with original CUG information NOTE 1: Received in Service Interaction Indicators Two IE. NOTE 2: CUG information consists of at least one of CUG Interlock Code and Outgoing Access Indicator. For an MT call which is to be routed to the terminating subscriber, the CUG information shall be extracted from the Send Routeing Information ack and sent to the gsmSCF in the Initial DP, but the gsmSCF shall not have the ability to change the CUG information for the call. For an VT call which is to be routed to the terminating subscriber, the CUG information shall be extracted from the incoming ISUP IAM and sent to the gsmSCF in the Initial DP, but the gsmSCF shall not have the ability to change the CUG information for the call. For an MT or VT call which is subject to CAMEL forwarding, the gsmSCF shall return a Connect information flow and the CUG handling in table 4.7 applies. 5 USSD to/from gsmSCF 5.1 Architecture 5.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support CAMEL handling of USSD to/from gsmSCF. The functional model of USSD in an HLR that supports CAMEL is shown in figureÊ5.1. The phaseÊ2 USSD handler is defined in 3GPP TSÊ23.090Ê[24]. PhaseÊ1 USSD information flows may be relayed from the HLR to the gsmSCF. CAMEL introduces a ""CAMEL USSD application"" which is invoked by the USSD handler. The CAMEL USSD functional entities and application behaviour is specified in this subclause. Figure 5.1: Handling of USSD to and from a CAMEL subscriber HLR: The HLR stores for subscribers requiring CAMEL support the information relevant to the current subscription regarding U CSI. The UG CSI is stored as global data applicable to all subscribers. The U CSI and the UG CSI are stored in the HLR only. gsmSCF: see subclauseÊ3.1. 5.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 5.1.2.1 gsmSCF - HLR interface This interface is used for USSD information flows, both for gsmSCF-initiated dialogues and MS-initiated dialogues (relayed via HLR). It is a network operator option whether to support or not USSD information flows on this interface. 5.2 Description of CAMEL Subscriber Data 5.2.1 USSD CAMEL Subscription Information (U CSI) The subscription information specified in this subclause is for information only. This subclause defines the contents of the USSD CAMEL Subscription Information (U CSI). The U CSI consists of a list of pairs of the following two parameters. 5.2.1.1 Service Code Service code for a specific application in a gsmSCF which interacts with the user by USSD. 5.2.1.2 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber and a particular service code. The address shall be an E.164 number to be used for routeing. 5.3 Content of the USSD General CAMEL Service Information (UG CSI) The service information specified in this subclause is for information only. This subclause defines the contents of the USSD General CAMEL Service Information (UG CSI). The allocation of the UG CSI is independent from a particular subscriber. The UG CSI consists of a list of pairs of the following two parameters. 5.3.1 Service Code Service code for a specific application in a gsmSCF which interacts with the user by USSD. 5.3.2 gsmSCF address Address to be used to access the gsmSCF for a particular service code. The address shall be an E.164 number to be used for routeing. 5.4 Procedures 5.4.1 MS Initiated USSD For the behaviour of the USSD handler in HLR when receiving a MS initiated USSD see 3GPP TSÊ23.090Ê[24]. When the USSD handler has determined that the service code present in the received USSD does not indicate that an USSD application in the HLR shall be invoked it shall route the USSD to the USSD application specific for CAMEL, i.e. the CAMEL USSD application. The procedure at the CAMEL USSD application at the HLR is implementation dependent. The following text describes a recommended procedure. The CAMEL USSD application shall check the U CSI data assigned to the specific subscriber. If the service code is present in the U CSI the USSD is routed to the gsmSCF given by the gsmSCF address stored against the service code in the U CSI. If the service code is not present in the U CSI (or the subscriber does not have U CSI defined) then the CAMEL USSD application shall check the UG CSI data assigned to the HLR. If the service code is present in the UG CSI then the USSD is routed to the gsmSCF given by the gsmSCF address stored against the service code in the UG CSI. If the service code is not present in U CSI or UG CSI an error (unknown application) is returned to the USSD handler. 5.4.2 gsmSCF Initiated USSD The HLR may at any time receive a USSD information flow from the gsmSCF. If the subscriber can be contacted, the HLR shall set up a transaction to the VLR and forward the information flow unchanged. Any further information exchange between the gsmSCF and MSC shall be transparent to the VLR and the HLR. When one transaction is released, the HLR shall release the other. If an error is received from the MSC, the VLR shall release the transaction to the HLR and the HLR shall release the transaction to the gsmSCF. 5.5 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for USSD handling. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The HLR shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.002Ê[34]. 5.5.1 gsmSCF to HLR information flows 5.5.1.1 Unstructured SS Request 5.5.1.1.1 Description This IF is used for the gsmSCF to request data from the MS via the HLR. 5.5.1.1.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the MS. Data Coding Scheme M This IE indicates the characteristics of the USSD string. IMSI S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. MSISDN S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. Alerting Pattern O This IE indicates an alerting pattern to be sent to the MS. 5.5.1.2 Unstructured SS Notify 5.5.1.2.1 Description This IF is used for the gsmSCF to send data to the MS via the HLR. 5.5.1.2.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the MS. Data Coding Scheme M This IE indicates the characteristics of the USSD string. IMSI S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. MSISDN S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. Alerting Pattern O This IE indicates an alerting pattern to be sent to the MS. 5.5.1.3 Process Unstructured SS Data ack 5.5.1.3.1 Description This IF is used for the gsmSCF to send the response to the MS via the HLR for the MS initiated IF. 5.5.1.3.2 Information Elements The following information element is required: Information element name Status Description SS User Data C This IE contains the string that will be sent to the MS. 5.5.1.4 Process Unstructured SS Request ack 5.5.1.4.1 Description This IF is used for the gsmSCF to send the response to the MS via the HLR for the MS initiated IF. 5.5.1.4.2 Information Elements Information element name Status Description USSD String S This IE contains the string that will be sent to the MS. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. Data Coding Scheme S This IE indicates the characteristics of the USSD string. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. 5.5.2 HLR to gsmSCF information flows 5.5.2.1 Unstructured SS Request ack 5.5.2.1.1 Description This IF is used for the MS to send to the gsmSCF via the HLR for the gsmSCF initiated IF. 5.5.2.1.2 Information Elements Information element name Status Description USSD String C This IE contains the string that will be sent to the gsmSCF. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. Data Coding Scheme C This IE indicates the characteristics of the USSD string. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. 5.5.2.2 Unstructured SS Notify ack 5.5.2.2.1 Description This IF is used for the MS to via the HLR acknowledge to the gsmSCF that the notification was received. 5.5.2.2.2 Information Elements This IE contains no information element. 5.5.2.3 Process Unstructured SS Data 5.5.2.3.1 Description This IF is used for the MS to request data from gsmSCF via the HLR. 5.5.2.3.2 Information Elements Information element name Status Description SS User Data M This IE contains the string that was received from the MS. 5.5.2.4 Process Unstructured SS Request 5.5.2.4.1 Description This IF is used for the MS to request data from the gsmSCF via the HLR. 5.5.2.4.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the gsmSCF, including the Service Code. Data Coding Scheme M This IE indicates the characteristics of the USSD string IMSI M This IE identifies the subscriber. MSISDN S This IE contains the basic MSISDN of the subscriber who has requested the USSD IF. This IE is used as an operator option. Originating Entity Number M This IE identifies the functional entity initiating the information flow. In this case, this shall be the address of the HLR. 5.5.2.5 Begin Subscriber Activity 5.5.2.5.1 Description This IF is used by the HLR to start subscriber activity towards the gsmSCF for USSD purposes. 5.5.2.5.2 Information Elements Information element name Status Description IMSI M This IE identifies the subscriber. Originating Entity Number M This IE identifies the functional entity initiating the subscriber activity. In this case, this shall be the address of the HLR. 6 GPRS interworking 6.1 Architecture 6.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support GPRS interworking for CAMEL. FigureÊ6.1 shows the functional entities involved in a GPRS session requiring CAMEL support. The architecture is applicable to the third phase of CAMEL or higher. Figure 6.1: Functional architecture for support of CAMEL HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription GPRS CSI. SGSN: When processing GPRS Attach requests or Inter-SGSN Routeing Area Updates for subscribers requiring CAMEL support, the SGSN receives a GPRS CSI from the HLR, indicating the SGSN to request instructions from the gprsSSF. The SGSN monitors on request the GPRS events and informs the gprsSSF of these events during processing, enabling the gprsSSF to control the execution of the GPRS session or individual PDP contexts in the SGSN. gprsSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. 6.1.2 Interfaces defined for CAMEL 6.1.2.1 SGSN - gprsSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 6.1.2.2 gprsSSF - gsmSCF interface This interface is used by the gsmSCF to control a GPRS session or individual PDP Context in a certain gprsSSF. GPRS dialogues between the gprsSSF and the gsmSCF on this interface are opened as a result of the gprsSSF sending a request for instructions to the gsmSCF. A GPRS dialogue is composed of a sequence of TC dialogues linked together by the same reference. The GPRS dialogue handler allows the TC dialogue handling. 6.1.2.3 HLR - SGSN interface This interface is used to send CAMEL related subscriber data to a visited GPRS network, e.g. GPRS CSI. 6.2 Detection Points (DPs) 6.2.1 Definition and description GPRS events may be made visible to the gsmSCF. The DPs are the points in association at which these events are detected. The DPs for GPRS Session and PDP Context are described in subclauseÊ6.4.2 and subclauseÊ6.4.3. A DP can be armed in order to notify the gsmSCF that the GPRS event was encountered, and to allow the gsmSCF to influence subsequent handling of the GPRS Session, or the PDP Context. If the DP is not armed, the processing entity continues the processing without gsmSCF involvement at this DP. Three different types of DPs are identified: - Trigger Detection Point-Request (TDP R): This detection point is statically armed and may initiate a CAMEL control relationship. This CAMEL control relationship is within a new GPRS dialogue. When the GPRS event is encountered and reported, processing is suspended. - Event Detection Point- Request (EDP R): This detection point is dynamically armed within the context of a CAMEL control relationship. When the GPRS event is encountered, and reported, processing is suspended and the gprsSSF waits for instructions from the gsmSCF. - Event Detection Point-Notification (EDP N): This detection point is dynamically armed within the context of a CAMEL control relationship. When the GPRS event is encountered and reported, processing is not suspended. Arming/disarming mechanism: A DP may be statically armed or dynamically armed. The following arming rules apply: - DPs for GPRS Session and PDP Context are statically armed as a result of the GPRS CSI analysis in the SGSN. - DPs may be dynamically armed by the gsmSCF within the context of a CAMEL control relationship. In scenarioÊ1 which is described in the subclauseÊ6.4.4.1, PDP context related DPs may be armed as generic DP or as non-generic DP. The following disarming rules apply: - A statically armed DP is disarmed when the GPRS CSI is withdrawn in the HLR. Only TDP Rs can be disarmed using this mechanism. - If the GPRS Session is released, then all EDPs related to the GPRS Session are disarmed. - If a PDP context is released, then all non-generically armed EDPs related to that PDP context are disarmed. - If a non-generically armed EDP is met, then EDPs for the GPRS Session or that PDP Context are disarmed, in accordance with the implicit disarming rule (see subclauseÊ6.4.6). - Armed EDPs may be explicitly disarmed by the gsmSCF by means of the Request Report BCSM Event information flow. 6.2.2 Relationship, DP processing rules and GPRS dialogue A relationship between the State Models (in the gprsSSF) and the gsmSCF for the purpose of operator specific service processing is considered to be a CAMEL relationship. There are two types of CAMEL relationships: monitor relationship and control relationship. - A CAMEL control relationship: the gsmSCF is able to influence the GPRS Session/PDP Context via the relationship for the given state model. - A CAMEL monitor relationship: the gsmSCF is not able to influence the GPRS Session/PDP Context via the relationship for the given state model. A control relationship persists as long as there is one or more EDP R armed for this instance of the state model, or if the gprsSSF is in the state Waiting For Instruction for this instance of state model. A control relationship changes to a monitor relationship if the conditions for a control relationship are no longer fulfilled and one or more EDP N is armed or one or more Apply Charging Report GPRS is outstanding for this instance of the state model. If no EDP Ns are armed and no Apply Charging Reports GPRS are outstanding for this instance of the state model, the relationship terminates. A GPRS dialogue exists between gprsSSF and gsmSCF if at least one of the following conditions is fulfilled: - There is at least one EDP armed, - At least one report is pending, - gprsSSF is in state Waiting_For_Instructions. 6.3 Description of CAMEL Subscriber Data 6.3.1 GPRS CAMEL Subscription Information (GPRS CSI) This subclause defines the contents of the GPRS CAMEL Subscription Information. 6.3.1.1 gsmSCF Address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 6.3.1.2 Service Key The Service Key identifies to the gsmSCF the service logic that shall apply. 6.3.1.3 Default GPRS Handling The Default GPRS Handling indicates whether the GPRS session or PDP context shall be released or continued as requested in case of error in the gprsSSF to gsmSCF dialogue. 6.3.1.4 TDP List The TDP List indicates on which detection point triggering shall take place. 6.3.1.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. 6.3.1.6 CSI state The CSI state indicates whether the GPRS CSI is active or not. 6.3.1.7 Notification flag The notification flag indicates whether the change of the GPRS CSI shall trigger Notification on Change of Subscriber Data or not. 6.3.2 gsmSCF address list for CSI The gsmSCF address list contains a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 6.4 Description of CAMEL State Models GPRS can support multiple PDP contexts simultaneously for an attached subscriber, requiring the behaviour of a GPRS session to be modelled by two state models, one for the attach/detach procedures (GPRS Attach/Detach State Model) and the other for modelling individual PDP Contexts (GPRS PDP Context State Model). 6.4.1 General Handling The GPRS State Model is used to describe the actions in an SGSN during processing of a GPRS session or PDP Contexts. The GPRS State Model identifies the points in basic GPRS processing when Operator Specific Service (OSS) logic instances (accessed through the gsmSCF) are permitted to interact with basic GPRS control capabilities. FigureÊ6.2shows the components that have been identified to describe a GPRS State Model. Figure 6.2: GPRS State Model Components 6.4.2 GPRS Attach/Detach State Model The GPRS Attach/Detach State Model is used to model the behaviour of the GPRS attach/detach procedures. When encountering a DP the Attach/Detach State Model processing is suspended at the DP and the SGSN indicates this to the gprsSSF which determines what action, if any, shall be taken in case the DP is armed. Figure 6.3: GPRS Attach/Detach State Model Table 6.1: Description of GPRS Attach/Detach DPs in the SGSN CAMEL Detection Point DP Type Description DP Attach TDP R A request to attach is received. DP Change of Position GPRS Session TDP R1), EDP N Routeing Area Update is accepted. DP Detach EDP N, EDP R A detach request is received either from the MS, the SGSN or a 'Cancel Location' received from HLR or Inter SGSN Routeing update occurred in the old SGSN. Note 1: Change of Position GPRS Session is reported as TDP R in the case of Inter SGSN Routeing Area Update (provided that this DP is statically armed in GPRS CSI). Change of Position GPRS Session is reported as EDP N in the case of Intra SGSN Routeing Area Update (provided that this DP is dynamically armed by the Service Logic). 6.4.2.1 Description of the Attach/Detach model (PIAs) This subclause describes the model for the attach and detach a GPRS session in the SGSN. For each PIA a description can be found of the entry events, actions and exit events. 6.4.2.1.1 Detached Entry events: - Detach (user or network initiated) and clearing of a previous GPRS session. - Processing of exceptional conditions. Actions: - Interface is idled. - Attach request is received from MS containing the IMSI/P-TMSI and the type of attach requested and, the identity of the MS is established (IMSI) (DP Attach), or Inter-SGSN Routeing Area Update Request is accepted (DP Change of Position GPRS Session). - Information being analyzed, e.g. GPRS CSI is analyzed. Exit events: - GPRS CSI is analyzed (DP Attach or DP Change of Position GPRS Session). 6.4.2.1.2 Attached Entry events: - GPRS CSI is analyzed (DP Attach). Actions: - MM contexts are established at the MS and the SGSN. Exit events: - A GPRS Detach request is received from the MS or from the network (DP Detach). - Intra-SGSN Routeing Area Update is accepted (DP Change of Position GPRS Session). - An exception is encountered. The GPRS Attach/Detach State Model shall only have one or more GPRS PDP Context State Models associated with it when in the Attached state. A GPRS PDP Context State Model cannot exist without its associated GPRS Attach/Detach State Model being in the Attached state. Closure of the GPRS Attach/Detach State Model via a detach will result in the idling of all associated GPRS PDP Context State Models and the release of the associated GPRS PDP Contexts. It shall not be necessary to trigger a relationship from the GPRS Attach/Detach State Model to the gsmSCF in order for triggering to occur in an associated GPRS PDP Context State Model. However, in this latter case a GPRS Attach/Detach State Model shall still exist at the SGSN. This is so that CSE-initiated detach events sent within a given GPRS PDP Context relationship shall result in the GPRS Attach/Detach State Model transiting to the Detached state. As noted above, in this state no PDP Contexts can exist and so all associated GPRS PDP Context State Models will transit to state Idle. 6.4.3 GPRS PDP Context State Model The GPRS PDP Context State Model is used to model the behaviour for the GPRS PDP Context procedures. There is one PDP Context State Model per GPRS PDP context. When encountering a DP the PDP Context State Model processing is suspended at the DP and the SGSN indicates this to the gprsSSF which determines what action, if any, shall be taken in case the DP is armed. Figure 6.4: GPRS PDP Context State Model Table 6.2: Description of GPRS PDP Context DPs in the SGSN CAMEL Detection Point DP Type Description DP PDP Context Establishment TDP R1), EDP R, EDP N Activate PDP Context request is received from the MS. DP PDP Context Establishment Acknowledgement TDP R2), EDP R, EDP N Create PDP Context response is received from the GGSN. DP PDP Context Disconnection EDP N, EDP R Deactivate PDP Context Request is received from the MS, Delete PDP Context request is received from the GGSN. Inter SGSN Routeing update occurred in old SGSN. DP Change of Position Context TDP R3), EDP N, EDP R Routeing Area Update is accepted. NOTE 1: The PDP Context Establishment shall be reported as TDP R (provided that this DP is statically armed in GPRS CSI) if there is no relationship with the gsmSCF. If there is a relationship with the gsmSCF it shall be reported as EDP R or EDP N if armed so. NOTE 2: The PDP Context Establishment Acknowledgement shall be reported as TDP R (provided that this DP is statically armed in GPRS CSI) if there is no relationship with gsmSCF. If there is a relationship with the gsmSCF, it shall be reported as EDP R or EDP N if armed so. NOTE 3: Change of Position Context is reported as TDP-R in the case of Inter-SGSN Routeing Area Update (provided that this DP is statically armed in GPRS CSI) if there is no relationship with the gsmSCF. Change of Position Context is reported as EDP N or EDP R in the case of Inter-SGSN Routeing Area Update (provided that this DP is armed as generic EDP) if there is a relationship with the gsmSCF. Change of Position Context is reported as EDP N in the case of Intra-SGSN Routeing Area Update (provided that this DP is dynamically armed by the Service Logic). 6.4.3.1 Description of the PDP Context model (PIAs) This subclause describes the model for PDP Context State Model in the SGSN. For each PIA a description can be found of the entry events, actions and exit events. 6.4.3.1.1 Idle Entry events: - Deactivation (user or network initiated) and clearing of a previous PDP Context. - Processing of exceptional conditions. Actions: - Interface is idled. - Activate PDP Context request is received from MS (containing NSAPI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options), or Inter-SGSN Routeing Area Update is accepted (DP Change of Position Context). - Information being analyzed, e.g. GPRS CSI is analyzed. Exit events: - GPRS CSI is analyzed (DP PDP Context Establishment or DP Change of Position Context, new SGSN). 6.4.3.1.2 PDP Context Setup Entry events: - GPRS CSI is analyzed (DP PDP Context Establishment). Actions: - APN and GGSN selection procedure is performed for a primary PDP context as specified in Annex A of 3GPP TSÊ23.060Ê[15]. APN and GGSN selection procedure is not performed for a secondary PDP context. - Access Point Name is verified against the subscription. If the gsmSCF has provided an Access Point Name then the Access Point Name provided by the gsmSCF is checked against the subscription. For details refer to 3GPP TSÊ23.060Ê[15] Annex A. - The operator determined barring category ""Barring of all Packet Oriented Services "" is checked and invoked if necessary. - The operator determined barring category ""Barring of Packet Oriented Services from access points that are within the HPLMN whilst the subscriber is roaming in a VPLMN"" is checked and invoked if necessary. - The operator determined barring category ""Barring of Packet Oriented Services from access points that are within the roamed to VPLMN"" is checked and invoked if necessary. - The SGSN ensures that an already active PDP context is not reactivated. - GGSN address is derived from the Access Point Name by interrogation of a DNS. The Access Point Name consists of a Network Identifier and an Operator Identifier. - Create PDP Context Request is sent to the GGSN. Exit events: - Create PDP Context Response is received from the GGSN (DP PDP Context Establishment Acknowledgement). - An exception is encountered. 6.4.3.1.3 PDP Context Established Entry events: - GPRS CSI is analyzed (DP PDP Context Establishment Acknowledgement or DP Change of Position Context). Actions: - PDP context is established at the MS and the SGSN. Exit events: - Deactivation of the PDP Context is received from the MS or the GGSN, or is due to an inter SGSN routing area update (DP PDP Context Disconnection, old SGSN). - Intra-SGSN Routeing Area Update Request is received from the MS (DP Change of Position Context). - Inter-SGSN Routeing Area Update (DP Change of Position Context, new SGSN). - An exception is encountered. 6.4.3.1.4 Change of Position Context Entry events: - Inter SGSN Routing Area update accepted (new SGSN). - Intra SGSN Routeing Area update request received from the MS. Actions: - PDP Context (containing NSAPI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) is reestablished in case of Inter-SGSN Routeing Area update accepted (new SGSN). - Intra SGSN Routeing Area updated. Exit events: - reestablishement of the PDP context at the new SGSN and return to PDP context established in case of inter SGSN Routeing Area update accepted in new SGSN (PIA PDP context established). - Routeing Area update completed in case of intra SGSN Routeing Area update (PIA PDP context established). 6.4.4 GPRS CAMEL Scenarios Two different scenarios are applicable for CAMEL control of GPRS. Scenario 1: Scenario 1 allows CAMEL control of the GPRS session and of multiple PDP contexts related to this session within a single GPRS dialogue. Scenario 2: Scenario 2 allows CAMEL control of single PDP contexts. Multiple PDP contexts are controlled in this scenario via multiple GPRS dialogues. ScenarioÊ1 and scenarioÊ2 are mutually exclusive, i.e. it is not possible to use both for one GPRS session at the same time in one SGSN. A GPRS session is involved in GPRS CAMEL at one moment in time either by using scenarioÊ1 or by using possible multiple instances of scenarioÊ2. GPRS sessions in different SGSNs are independent from a CAMEL perspective. 6.4.4.1 GPRS CAMEL Scenario 1 ScenarioÊ1 allows CAMEL control of the GPRS session and of multiple PDP contexts related to this session within a single GPRS dialogue (Session dialogue). Figure 6.5: GPRS CAMEL Scenario 1 A GPRS dialogue in scenarioÊ1 always consists of one GPRS Attach/Detach State Model and optionally of additional multiple GPRS PDP Context State Models related to the Attach/Detach State Model for the GPRS session. There is at most one GPRS Attach/Detach State Model per non idle GPRS session in one SGSN and at most one PDP Context State Model per active GPRS PDP context in one SGSN. The various PDP Context State Models are treated independently of each other. The GPRS dialogue and the relationship between the GPRS Attach/Detach State Model and the gsmSCF are always initiated using the TDPs of the GPRS Attach/Detach State Model. The gsmSCf requests further control or monitoring of individual GPRS PDP contexts using the Request Report GPRS Event information flow. To be informed about new individual PDP contexts the gsmSCF arms the DP 'PDP Context Establishment' or the DP 'PDP Context Establishment Acknowledgement' generically, i.e. without a PDP ID, as an EDP. To be informed about the handed over PDP contexts the gsmSCF arms the DP 'Change of Position Context' generically as an EDP N or EDP R. Each GPRS PDP context is identified by a PDP ID. The PDP ID is assigned by the SGSN during PDP context establishment. The PDP ID is unique within one GPRS dialogue. The Request Report GPRS Event information flows to control new or handed over PDP contexts do not include a PDP ID. There is no 'PDP ID' related to the GPRS Attach/Detach State Model. The PDP Id is reported to the gsmSCF in the first event notification for that PDP context. 6.4.4.2 GPRS CAMEL Scenario 2 ScenarioÊ2 allows CAMEL control of single PDP contexts. Multiple PDP contexts are controlled in this scenario via multiple GPRS dialogues (PDP Context dialogues). Figure 6.6: GPRS CAMEL Scenario 2 A GPRS dialogue in scenarioÊ2 consists of a single GPRS PDP Context State Model. There is no GPRS Attach/Detach State Model involved in this scenario. There is at most one PDP Context State Model per active GPRS PDP context in one SGSN. There might be multiple GPRS dialogues in scenariosÊ2 for one GPRS session, each of the dialogues controlling a single GPRS PDP context. The various GPRS dialogues are independent of each other. The GPRS dialogue and the relationship between the GPRS PDP Context State Model and the gsmSCF are always initiated using the TDPs for the GPRS PDP Context State Model. Control of further individual GPRS PDP contexts in the same GPRS dialogue as in scenarioÊ1 is not possible. There are no PDP IDs in this scenario. 6.4.5 SGSN Routeing Area Update 6.4.5.1 Intra-SGSN Routeing Area Update Intra-SGSN Routeing Area Update will be detected via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and via the DPs 'Change of Position Context' for the individual PDP contexts using the GPRS PDP Context State Models. It will be reported via an EDP N if the necessary EDP N is armed. 6.4.5.2 Inter-SGSN Routeing Area Update Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. Scenario 1: Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected in the new SGSN via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and in the new SGSN via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. In this scenario the DP 'Change of Position GPRS Session' is armed as a TDP R. If the Routeing Area Update is accepted the gprsSSF reports this TDP R to the gsmSCF using the Initial DP GPRS information flow. To be informed about new PDP contexts the gsmSCF arms the DP 'PDP Context Establishment' or the DP 'PDP Context Establishment Acknowledgement' generically as EDP R or EDP N. The DPs 'Change of Position Context' for the PDP contexts which have been handed over will be reported with all necessary information to the gsmSCF when the gprsSSF is continued, i.e. it is not longer waiting for instructions. Contexts which are not continued in the new SGSN are not reported. The EDPs for new PDP contexts are reported as usual. The Detach in the old SGSN is reported to the gsmSCF, provided this event is armed. All outstanding reports in the old SGSN are sent to the gsmSCF and all open CDRs are closed. Scenario 2: Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected in the new SGSN via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. In this scenario the DP 'Change of Position Context' is armed as TDP R. If the Routeing Area Update is accepted the gprsSSF reports these TDP Rs PDP contexts which have been handed over to the gsmSCF using the Initial DP GPRS information flows in multiple GPRS dialogues. The PDP Context Disconnection in the old SGSN is reported to the gsmSCF, provided this event is armed. All outstanding reports in the old SGSN are sent to the gsmSCF and the open CDR is closed. 6.4.6 Rules for Implicit Disarming of Detection Points The two tables below give the rules for implicit disarming of event detection points. Implicit EDP disarming rules are specified for the Attach/Detach State Model and PDP Context State Model. The tables specify which EDP's shall be disarmed (i.e. MonitorMode set to Transparent) if/when each EDP is encountered, irrespective of the EDP's MonitorMode (Transparent, NotifyAndContinue, or Request). EDPs which are armed generically for GPRS PDP Context State Models shall only be implicitly disarmed at the end of the GPRS dialogue. Explicit disarming is possible."
"When EDP's are armed with MonitorMode 'Request' (EDP Rs) are encountered, any implicit EDP disarming shall take place before reporting the EDP and transiting the gprsSSF to the WFI state (if not already suspended in the WFI state). The table entry 'X' means that if one DP occurs (independently of arming and reporting to the gsmSCF) the marked one is implicitly disarmed. It shall be possible to rearm explicitly an implicitly disarmed DP. Table 6.3: Implicit disarming rules for Scenario 1 (the rules apply for non-generically armed DPs) Encountered DP Implicit disarmed DPs Change of Position GPRS Session Change of Position Context Detach PDP Context Establishment PDP Context Establishment Acknowledgement PDP Context Disconnection Change of Position GPRS Session Change of Position Context Detach X X X X X X PDP Context Establishment PDP Context Establishment Acknowledgement X PDP Context Disconnection X X X Table 6.4: Implicit disarming rules for Scenario 2 (the rules apply for non-generically armed DPs) Encountered DP Implicit disarmed DPs Change of Position Context PDP Context Establishment Acknowledgement PDP Context Disconnection PDP Context Establishment Acknowledgement X PDP Context Disconnection X X X Change of Position Context 6.5 Procedures for CAMEL GPRS 6.5.1 Overall SDL Architecture Figure 6.7: Architecture for CAMEL/GPRS interworking 6.5.2 Handling GPRS in the SGSN The functional behaviour of the SGSN is specified in 3GPP TSÊ23.060Ê[15]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_GPRS_Attach; - Procedure CAMEL_GPRS_Detach; - Procedure CAMEL_GPRS_Routeing_Area_Update_Session; - Procedure CAMEL_GPRS_Routeing_Area_Update_Context; - Procedure CAMEL_GPRS_PDP_Context_Establishment; - Procedure CAMEL_GPRS_Create_PDP_Context_Establishment_Acknowledgement; - Procedure CAMEL_GPRS_Change_Of_QoS; - Procedure CAMEL_GPRS_PDP_Context_Disconnection. 6.5.2.1 Actions of the SGSN on receipt of Int_Error The SGSN checks the default GPRS Handling parameter in GPRS CSI. If the default GPRS handling is release, a Detach indication is sent to the MS. The SGSN then releases all resources and the invoked CAMEL procedure ends. If the default GPRS handling is continue, the SGSN continues processing without CAMEL support. 6.5.2.2 Actions of the SGSN on receipt of Int_Continue The SGSN continues processing without any modification of GPRS parameters. 6.5.2.3 Handling of GPRS Attach/Detach Figure 6.8-1: Procedure CAMEL_GPRS_Attach (sheet 1) Figure 6.8-2: Procedure CAMEL_GPRS_Attach (sheet 2) Figure 6.9-1: Procedure CAMEL_GPRS_Detach (sheet 1) 6.5.2.4 Handling of GPRS Routeing Area Update Figure 6.10-1: Procedure CAMEL_GPRS_Routeing_Area_Update_Session (sheet 1) Figure 6.10-2: Procedure CAMEL_GPRS_Routeing_Area_Update_Session (sheet 2) Figure 6.11-1: Procedure CAMEL_GPRS_Routeing_Area_Update_Context (sheet 1) Figure 6.11-2: Procedure CAMEL_GPRS_Routeing_Area_Update_Context (sheet 2) 6.5.2.5 Handling of PDP Context establishment and deactivation Figure 6.12-1: Procedure CAMEL_GPRS_PDP_Context_Establishment (sheet 1) Figure 6.12-2: Procedure CAMEL_GPRS_PDP_Context_Establishment (sheet 2) Figure 6.13-1: Procedure CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement (sheet 1) Figure 6.13-2: Procedure CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement (sheet 2) Figure 6.14-1: Procedure CAMEL_GPRS_Change_Of_QoS (sheet 1) Figure 6.15-1: Procedure CAMEL_GPRS_PDP_Context_Disconnection (sheet 1) 6.5.3 Handling GPRS in the gprsSSF 6.5.3.1 Process GPRS_SSF A relationship exists between the gsmSCF and the Attach/Detach State Model and/or between the gsmSCF and every PDP Context State Model. The relationship may be in controlling or monitoring mode. When a Continue GPRS, Connect GPRS or Request Report GPRS Event information flow is received, then the relationship between the gsmSCF and the Attach/Detach State Model, and between the gsmSCF and a PDP Context State Model may be downgraded from controlling to monitoring. When Tssf expires, the CAMEL procedures that are waiting for an instruction from the gsmSCF shall receive an Int_Error signal. The Default GPRS Handling parameter determines the subsequent action of those CAMEL procedures. If the Default GPRS Handling parameter is set to 'Release', then: - if the GPRS Dialogue is controlling a GPRS Session, then the gprsSSF shall release the entire GPRS Session; - if the GPRS Dialogue is controlling a single PDP Context, then the gprsSSF shall release the PDP Context. The task box 'Open GPRS Dialogue' comprises all the tasks that are required for starting a GPRS dialogue. This includes, amongst others, the allocation of a GPRS Reference Number and the allocation of resources. The task box 'Terminate GPRS Dialogue' comprises all the tasks that are required for closing a GPRS dialogue. 6.5.3.2 Process GPRS_Dialogue_Handler When process gprsSSF sends a TC_End request primitive to process GPRS_Dialogue_Handler, then the corresponding TC_End TC Message shall be sent to the gsmSCF only when the following conditions have been fulfilled: - The gprsSSF has processed all information flows that the gprsSSF has received from the gsmSCF. - No information flows remain to be sent from the gprsSSF to the gsmSCF. - The gprsSSF is not waiting for a Result or Error component for any information flows that the gprsSSF has sent to the gsmSCF. 6.5.3.3 Procedure Handle_AC_GPRS Procedure Handle_AC_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Apply Charging GPRS procedure shall be executed for the Session - 'PDP Id'. The Apply Charging GPRS procedure shall be executed for the indicated PDP Context. SheetÊ3 in procedure Handle_AC_GPRS contains a check for the PDP Context duration (Tcp(PDP Id)) and PDP Context volume (Vc(PDP Id)). If the PDP Context delta timer (Dcp(PDP Id)) is equal to or larger than the duration threshold received in the Apply Charging GPRS operation or the PDP Context delta counter (Dc(PDP Id)) is equal to or larger than the volume threshold received in the Apply Charging GPRS operation, then the gprsSSF shall generate an internal signal to trigger the sending of an Apply Charging Report GPRS. If a QoS change has occurred prior to receiving Apply Charging GPRS but after the sending Apply Charging Report GPRS, then the gprsSSF shall generate an internal signal to trigger the sending of an Apply Charging Report GPRS, including the negotiated QoS. 6.5.3.4 Procedure Handle_ACR_GPRS Procedure Handle_ACR_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Apply Charging Report GPRS procedure shall be executed for the Session. This procedure checks if a Session Period report is pending and if so, sends this report to the gsmSCF. - 'PDP Id'. The Apply Charging Report GPRS procedure shall be executed for the indicated PDP Context. This procedure checks if a Context Volume report is pending and if so, sends this report to the gsmSCF. The procedure then checks if a Context Period is pending and if so, sends this report to the gsmSCF. - 'Session + PDPs'. The Apply Charging Report GPRS procedure shall be executed for the Session and all PDP Contexts. The sequence of checking the reports shall be as follows: 1) The procedure checks the pending Volume and Period reports for each PDP Context. 2) The procedure then checks the pending Period report for the Session. When a PDP Context Volume counter or PDP context Period timer expires or an Apply Charging GPRS is received when QoS change report is pending, then the procedure Apply Charging Report GPRS procedure is called with the PDP Id as input parameter. The procedure will then check both reports for that PDP Context. 6.5.3.5 Procedure Complete_FCI_Record_GPRS Procedure Complete_FCI_Record_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Complete_FCI_Record_GPRS procedure shall be executed for the Session. - 'PDP Id'. The Complete_FCI_Record_GPRS procedure shall be executed for the indicated PDP Context. - 'Session + PDPs'. The Complete_FCI_Record_GPRS procedure shall be executed for the Session and all PDP Contexts. 6.5.3.6 Procedure Handle_SCI_GPRS For terminology see subclauseÊ4.5.7.2.1. The gsmSCF may send e parameters to the Session and to individual PDP Contexts. When e parameters are sent for the Session, the SGSN will forward these e parameters directly to the Mobile Station. When e parameters are sent for a PDP Context and that PDP Context is not yet acknowledged (= active), then the SGSN shall retain these parameters (pending parameters). These parameters will be sent to the Mobile Station when the PDP Context is acknowledged. The gsmSCF may send two sets of e parameters and a Tariff Switch for the Session or a PDP Context. The first set of e parameters shall be sent to the SGSN and the second set of e parameters shall be stored. This second set of e parameters shall be sent to the SGSN when the tariff switch expires. When the Tariff Switch for the Session expires, then the stored e parameters for the Session shall be sent to the SGSN. When the Tariff Switch for a PDP Context expires before that PDP Context is acknowledged, then the pending e parameters for that PDP Context shall be replaced by the stored e parameters for that PDP Context. The stored e parameters for that PDP Context shall be discarded. When the Tariff Switch for a PDP Context expires after that PDP Context has been acknowledged, then the stored e parameters for that PDP Context shall be sent to the SGSN. 6.5.3.6.1 Handling of SCI_GPRS for the Session 1) Precondition: no Tsw running for the Session: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw (Session)/store 2nd set of e parameters. 2) Precondition: Tsw running for the Session and no e parameters stored for the Session: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 3) Precondition: Tsw running for the Session and e parameters stored for the Session: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6.5.3.6.2 Handling of SCI_GPRS for a PDP Context 1) Precondition: before a PDP Context Establishment Acknowledgement event is detected and no Tsw running for this PDP Context: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw(PDP Id)/store 2nd set of e parameters; 2) Precondition: before a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and no e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 3) Precondition: before a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 4) Precondition: after a PDP Context Establishment Acknowledgement event is detected and no Tsw running for this PDP Context: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> start Tsw(PDP Id)/store e parameters; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw(PDP Id)/store 2nd set of e parameters. 5) Precondition: after a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and no e parameters stored for this PDP Context; if 1 set of e parameters received --> store e parameters; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6) Precondition: after a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6.5.3.7 Procedure Handle_PDP_Acknowledgement Procedure Handle_PDP_Acknowledgement is called when an event occurs that may signal the activation (= Acknowledgement) of a PDP Context. The event signal is passed on to the Handle_PDP_Acknowledgement procedure. 6.5.3.8 GPRS duration and volume control 6.5.3.8.1 Examples of information flows for GPRS session and PDP context control Figure 6.16-1: Example of information flows for GPRS session duration at GPRS attach and change of position session Figure 6.16-2: Example of information flows for PDP context duration control at context activation and change of position context Figure 6.16-3: Example of information flows for PDP context volume control at context activation and change of position context Note1: Vc threshold reached, Tcp is stopped. Note2: Tcp time out, Vc is stopped. Figure 6.16-4: Example of information flows for PDP context volume and duration control at context activation and change of position context These figures 6.16-1 to 6.16-4show examples of handling of the timers that are used in the process gprsSSF and in the procedures Handle_AC_GPRS and Handle_ACR_GPRS. Duration timers (Tsp for the GPRS session and one Tcp for each PDP context) are used if the charging is on duration of the GPRS session or a PDP context. Tariff Switch Timers (Tsw(Session) for the GPRS session and one Tsw(PDP Id) for each PDP context) define the start point of a new Tariff. Tsw(Session) is used for charging on duration. Tsw(PDP Id) is used for both methods of charging: duration charging and volume charging. If a PDP context is charged on duration and volume, only one Tsw(PDP Id) timer will be accepted from the gsmSCF for that PDP context. Delta timers measure the response time of the gsmSCF after an Apply Charging Report GPRS information flow: - Dsp for the GPRS session; this delta timer is used for GPRS session period timing. - Dcp for each PDP context; these delta timers are used for PDP context period timing. - Dc for each PDP context; these delta counters are used for PDP context volume counting. After the sending of Apply Charging Report GPRS, the gsmSCF may reply either with: - Apply Charging GPRS, if the gsmSCF sends a new duration because of the expiration of the previous period or because of QOS change. - Release GPRS, if the gsmSCF decides to release the GPRS session or PDP context. For a more detailed example of the handling of the Apply Charging GPRS and Apply Charging Report GPRS information flows, see Annex A. 6.5.3.8.2 TC guard timer 6.5.3.8.2.1 General When the gprsSSF sends an Apply Charging Report GPRS information flow to the gsmSCF, with SessionActive or ContextActive variable set to TRUE, then the gprsSSF shall start the TC guard timer. The gprsSSF shall also mark for the Session or PDP Context for which the Apply Charging Report GPRS was sent, that a corresponding Apply Charging GPRS information flow from the gsmSCF is expected. When the gprsSSF receives an Apply Charging GPRS information flow or a Release GPRS information flow, then the 'Waiting-for-AC' marking(s) for the Session or PDP Context shall be removed. The gprsSSF shall then check if the TC guard timer shall be stopped (task box 'Check TC guard timer'). The TC guard timer shall be stopped if there are no more Apply Charging GPRS information flows expected for the Session and all PDP Contexts. When an event occurs that results in the termination of a PDP Context, then the 'Waiting-for-AC' markings for that PDP Context shall be removed. The gprsSSF shall then check if the TC guard timer shall be stopped (task box 'Check TC guard timer'). The TC guard timer shall be stopped if there are no more Apply Charging GPRS information flows expected for the Session and all PDP Contexts. When the TC guard timer expires in state Monitoring, then the gprsSSF shall close the TC dialogue, provided that all conditions for closing the TC dialogue are fulfilled, i.e. there are no information flow results expected from the gsmSCF, no information flows or errors to be sent to the gsmSCF and no information flows from the gsmSCF received and waiting to be processed. When the TC guard timer expires in state Waiting_for_Instructions, then no action shall be taken. Service Designers should note that there may be additional timer(s) in the gprsSSF to supervise the response from the gsmSCF on the Apply Charging Report GPRS procedure. As a result of this, if the gsmSCF does not send an Apply Charging GPRS, Release GPRS or Cancel GPRS in response to an Apply Charging Report GPRS when the gprsSSF is awaiting such response, then service behaviour may be unpredictable. 6.5.3.8.2.2 Check TC guard timer This clause describes the actions to be taken in the task box 'Check TC guard timer'. The tasks to be executed in the 'Check TC guard timer' box depend on the event that resulted in execution of the task box. 6.5.3.8.2.2.1 Apply Charging GPRS If 'Check guard timer' is executed as a result of an Apply Charging GPRS information flow from the gsmSCF, then the appropriate 'Waiting-for-AC' marker shall be removed, depending on the information received in the Apply Charging GPRS information flow: - if the Apply Charging GPRS information flow carries a Session Time threshold, then the Session-Period 'Waiting-for-AC' marker shall be removed. - if the Apply Charging GPRS information flow carries a PDP Context Volume threshold, then the PDP Context-Volume 'Waiting-for-AC' marker shall be removed. - if the Apply Charging GPRS information flow carries a PDP Context Time threshold, then the PDP Context -Period 'Waiting-for-AC' marker shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.8.2.2.2 Release GPRS If 'Check TC guard timer' is executed as a result of a Release GPRS information flow from the gsmSCF, then the appropriate 'Waiting-for-AC' markers shall be removed, depending on the information received in the Release GPRS information flow: - if the Release GPRS information flow is for the Session, then the Session 'Waiting-for-AC' markers shall be removed. - if the Release GPRS information flow is for the PDP Context, then the PDP Context 'Waiting-for-AC' markers shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.8.2.2.3 PDP Context Disconnect If 'Check TC guard timer' is executed as a result of a PDP Context Disconnect signal from the SGSN, then the 'Waiting-for-AC' markers for that PDP Context shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.9 SDL diagrams for process GPRS_SSF and procedures Figure 6.17-1: Process GPRS_SSF (sheet 1) Figure 6.17-2: Process GPRS_SSF (sheet 2) Figure 6.17-3: Process GPRS_SSF (sheet 3) Figure 6.17-4: Process GPRS_SSF (sheet 4) Figure 6.17-5: Process GPRS_SSF (sheet 5) Figure 6.17-6: Process GPRS_SSF (sheet 6) Figure 6.17-7: Process GPRS_SSF (sheet 7) Figure 6.17-8: Process GPRS_SSF (sheet 8) Figure 6.17-9: Process GPRS_SSF (sheet 9) Figure 6.17-10: Process GPRS_SSF (sheet 10) Figure 6.17-11: Process GPRS_SSF (sheet 11) Figure 6.17-12: Process GPRS_SSF (sheet 12) Figure 6.17-13: Process GPRS_SSF (sheet 13) Figure 6.17-14: Process GPRS_SSF (sheet 14) Figure 6.17-15: Process GPRS_SSF (sheet 15) Figure 6.17-16: Process GPRS_SSF (sheet 16) Figure 6.17-17: Process GPRS_SSF (sheet 17) Figure 6.17-18: Process GPRS_SSF (sheet 18) Figure 6.17-19: Process GPRS_SSF (sheet 19) Figure 6.17-20: Process GPRS_SSF (sheet 20) Figure 6.17-21: Process GPRS_SSF (sheet 21) Figure 6.17-22: Process GPRS_SSF (sheet 22) Figure 6.17-23: Process GPRS_SSF (sheet 23) Figure 6.18-1: Process GPRS_Dialogue_Handler (sheet 1) Figure 6.18-2: Process GPRS_Dialogue_Handler (sheet 2) Figure 6.18-3: Process GPRS_Dialogue_Handler (sheet 3) Figure 6.19-1: Procedure Handle_AC_GPRS (sheet 1) Figure 6.19-2: Procedure Handle_AC_GPRS (sheet 2) Figure 6.19-3: Procedure Handle_AC_GPRS (sheet 3) Figure 6.20-1: Procedure Handle_ACR_GPRS (sheet 1) Figure 6.20-2: Procedure Handle_ACR_GPRS (sheet 2) Figure 6.21-1: Procedure Handle_FCI_GPRS (sheet 1) Figure 6.22-1: Procedure Complete_FCI_Record_GPRS (sheet 1) Figure 6.23-1: Procedure Handle_SCI_GPRS (sheet 1) Figure 6.23-2: Procedure Handle_SCI_GPRS (sheet 2) Figure 6.23-3: Procedure Handle_SCI_GPRS (sheet 3) Figure 6.24-1: Procedure Handle_PDP_Acknowledgement (sheet 1) 6.6 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for GPRS control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34] and TSÊ29.078Ê[36]. 6.6.1 gprsSSF to gsmSCF Information Flows 6.6.1.1 Activity Test GPRS ack 6.6.1.1.1 Description This IF is the response to the Activity Test GPRS. 6.6.1.1.2 Information Elements This IF contains no information elements. 6.6.1.2 Apply Charging Report GPRS 6.6.1.2.1 Description This IF is used by the gprsSSF to report to the gsmSCF the information requested in the Apply Charging GPRS IF. In addition, this IF is used to notify the gsmSCF of changes in QoS. Note that there are several possible QoS profiles defined by the combinations of the different QoS attributes as defined in 3GPP TSÊ23.060Ê[15]. A PLMN may only support and charge on a limited subset of those QoS. It is recommended that changes in QoS are only reported in Apply Charging Report GPRS for those QoS profiles. 6.6.1.2.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Charging Result M This IE contains the charging information for the PDP provided by the gprsSSF. It is a choice between elapsed time and data volume. Quality Of Service C This IE is described in a table below. Active M This IE indicates if the GPRS session or PDP context is still established, or if it has been detached or deactivated. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Apply Charging Report GPRS applies to the GPRS Session. If this IE is present in the IF, then the Apply Charging Report GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. Charging Roll Over C This IE indicates which parameter(s) of the Charging Result have overflowed. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Quality of Service contains the following information element: Information element name Status Description Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN, as a result of a 'Modify PDP Context' request. This IE shall be included only if sending of the Apply Charging Report GPRS was triggered by a change in Quality of Service. This IE shall contain the negotiated QoS as on the time of sending the Apply Charging Report GPRS. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. 6.6.1.3 Entity Released GPRS 6.6.1.3.1 Description This IF is used by the gprsSSF to inform the gsmSCF at any phase that a GPRS Session has been detached or a PDP Context has been disconnected without reporting any EDP. 6.6.1.3.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. GPRS Cause M This IE contains the Cause value indicating the reason for the GPRS Session Detach event or the PDP Context Disconnection event. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Entity Released GPRS applies to the GPRS Session. If this IE is present in the IF, then the Entity Released GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.1.4 Event Report GPRS 6.6.1.4.1 Description This IF is used to notify the gsmSCF of a GPRS event previously requested by the gsmSCF in a Request Report GPRS Event IF. 6.6.1.4.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. GPRS Event Type M This IE specifies the type of event that is reported. Misc GPRS Info M This IE indicates the DP type (EDP N or EDP R). GPRS Event Specific Information M This IE is described in a table below. This IE contains information specific to the reported event. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Event Report GPRS applies to the GPRS Session. If this IE is present in the IF, then the Event Report GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. If the GPRS Event Type contains DP Change of Position GPRS Session, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Location Information In SGSN M See subclauseÊ7.6.1.2.2. If the GPRS Event Type contains DP Change of Position Context, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name S This IE identifies the Access Point Name to which the MS is connected. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Charging ID S This IE contains the Charging ID received from the GGSN for the PDP context. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Location Information In SGSN M See subclauseÊ7.6.1.2.2. End User Address S See subclauseÊ6.6.1.5.2. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Quality Of Service S This IE is described in a table below. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Time And Time Zone S This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. GGSN Address S This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. If the GPRS Event Type contains DP Detach or DP PDP context disconnection, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Initiating Entity M This IE identifies the entity that has initiated the disconnection or detachment. Routeing Area Update C This IE indicates that the Detach or Disconnection is due to inter-SGSN routeing area update. If the GPRS Event Type contains DP PDP context establishment, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name C This IE identifies the Access Point Name the MS has requested to connect to. End User Address C See subclauseÊ6.6.1.5.2. Quality Of Service M This IE is described in a table below. Location Information In SGSN M See subclauseÊ7.6.1.2.2. Time And Time Zone M This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. PDP Initiation Type M This IE indicates whether a PDP context was established as a result of a network-initiated request or as a result of a subscriber request. Secondary PDP Context C This IE indicates that the PDP context activation was requested for a secondary PDP context. See 3GPP TSÊ23.060Ê[15]. If the GPRS Event Type contains DP PDP context establishment acknowledgement, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name M This IE identifies the Access Point Name to which the MS is connected. Charging ID M This IE contains the Charging ID received from the GGSN for the PDP context. End User Address M See subclauseÊ6.6.1.5.2. Quality Of Service M This IE is described in a table below. Location Information In SGSN M See subclauseÊ7.6.1.2.2. Time And Time Zone M This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. GGSN Address M This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Quality of Service contains the following information elements: Information element name Status Description Requested QoS C This IE identifies the QoS requested by the subscriber for the PDP Context. It shall be included if the EventReportGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Subscribed QoS C This IE identifies the subscribed QoS. It shall be included if the EventReportGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN. It shall be included if the EventReportGPRS is sent at PDP Context Establishment Acknowledgement and at Change of Position Context. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. 6.6.1.5 Initial DP GPRS 6.6.1.5.1 Description This IF is generated by the gprsSSF when a trigger is detected at a DP in the GPRS state models, to request instructions from the gsmSCF. 6.6.1.5.2 Information Elements Information element name Status Description Gprs Reference Number M This IE consists of a number assigned by the gprsSSF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. ServiceKey M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application/SLP within the gsmSCF. GPRS Event Type M This IE indicates the armed GPRS DP event resulting in the Initial DP IF. MSISDN M This IE contains the basic MSISDN of the MS. IMSI M This IE identifies the mobile subscriber. Time and Time zone M This IE contains the time that the gprsSSF was triggered, and the time zone in which the gprsSSF resides. GPRS MS Class C This IE contains the MS network and radio access capabilities. End User Address C This IE is described in a table below. Quality of Service C This IE is described in a table below. Access Point Name C This IE identifies the Access Point Name: - At DP Change Of Position Context contains the selected APN. - AT DP PDP Context Establishment contains the APN which the MS has requested. - AT DP PDP Context Establishment Acknowledgement contains the selected APN. Charging ID C This IE contains the Charging ID received from the GGSN for the PDP context. SGSN Capabilities C This IE specifies the capabilities of the SGSN to support the CAMEL interworking, e.g. support of Advice of Charge. Location Information in SGSN M This IE is described in subclauseÊ7.6.1.2.2. PDP Initiation Type C This IE indicates whether a PDP context was established as a result of a network-initiated request or as a result of a subscriber request. GGSN Address C This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Secondary PDP context C This IE indicates that the PDP context activation was requested for a secondary PDP context. See 3GPP TSÊ23.060Ê[15]. This IE is not sent if this IF is initiated at DP Change of Position Context. IMEI (with software version) C This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Quality of Service contains the following information elements: Information element name Status Description Requested QoS C This IE identifies the QoS requested by the subscriber for a new PDP Context. It shall be included if the InitialDPGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Subscribed QoS C This IE identifies the subscribed QoS. It shall be included if the InitialDPGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN. It shall be included if the Initial DP GPRS is sent at PDP Context Establishment Acknowledgement and at Change of Position Context. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS."
"It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. End User Address shall be populated as follows: - At DP Change Of Position Context in an Inter-SGSN Routeing Area Update: Initial DP GPRS and EventReportGPRS contain the selected value; - At DP PDP Context Establishment: Initial DP GPRS and Event Report GPRS contain the value which the MS has requested; - At DP PDP Context Establishment Acknowledgement: Initial DP GPRS and Event Report GPRS contain the selected value. Note that the PDP Address is not always available at this DP. For details see 3GPP TSÊ23.060Ê[15]. End User Address contains the following information elements: Information element name Status Description PDP Type Organization C This IE identifies the PDP Type Organisation (e.g. IETF). PDP Type Number C This IE identifies the PDP type, e.g. IPv4 or IPv6. PDP Address C This IE identifies the address of the subscriber for a new PDP Context. 6.6.2 gsmSCF to gprsSSF Information Flows 6.6.2.1 Activity Test GPRS 6.6.2.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gprsSSF. If the relationship is still in existence, then the gprsSSF will respond. If no reply is received, then the gsmSCF will assume that the gprsSSF has failed in some way and will take the appropriate action. 6.6.2.1.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. 6.6.2.2 Apply Charging GPRS 6.6.2.2.1 Description This IF is used for interacting from the gsmSCF with the gprsSSF charging mechanisms to control the charging of a GPRS session or a PDP Context. 6.6.2.2.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Charging Characteristics M This IE specifies the charging related information to be provided by the gprsSSF and the conditions on which this information has to be provided back to the gsmSCF. It is a choice between granted volume and granted time for the data transfer. Time charging may be applied to GPRS Session or PDP Contexts; volume charging may be applied to PDP Context only. Tariff Switch Interval O This information element specifies the time until the next tariff switch occurrence. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Apply Charging GPRS applies to the GPRS Session. If this IE is present in the IF, then the Apply Charging GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.3 Apply Charging Report GPRS ack 6.6.2.3.1 Description This IF is the response to the Apply Charging Report GPRS. 6.6.2.3.2 Information Elements This IF contains no information elements. 6.6.2.4 Cancel GPRS 6.6.2.4.1 Description This IF is used by the gsmSCF to request the gprsSSF to cancel all EDPs and reports. 6.6.2.4.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then all pending reports of the GPRS Session and all pending reports of the PDP Contexts shall be cancelled and all armed events of the GPRS Session, all armed events of the PDP Contexts and all generically armed events shall be disarmed. If this IE is present in the IF, then all pending reports of the indicated PDP Context shall be cancelled and all armed events of the indicated PDP Context shall be disarmed. Scenario 2: This IE is not used in the IF. 6.6.2.5 Connect GPRS 6.6.2.5.1 Description This IF is used by the gsmSCF to request the gprsSSF to modify the APN used when establishing a PDP Context. This IF shall not be used for a secondary PDP context or for a network initiated PDP context. 6.6.2.5.2 Information Elements Information element name Status Description Access Point Name M This IE contains the Access Point Name (APN) to be used when establishing the PDP Context. The gsmSCF should provide an APN which is allowed by the served subscriber's subscription. The APN provided by the gsmSCF is used for selecting the primary PDP context as specified in 3GPP TSÊ23.060Ê[15]. The gsmSCF provided APN may consist of Network Identity (NI) only, or Network Identity and Operator Identity (OI). The APN provided by the gsmSCF replaces entirely the APN requested by the MS. If the gsmSCF does not provide OI in APN then the SGSN selects the OI independent of MS. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: There shall always be this IE present in this IF. This IE indicates the PDP Context to which the Connect GPRS applies. Scenario 2: This IE is not used in the IF. 6.6.2.6 Continue GPRS 6.6.2.6.1 Description This information flow requests the gprsSSF to proceed with processing at the DP at which it previously suspended processing to await gsmSCF instructions. The gprsSSF completes DP processing, and continues processing (i.e. proceeds to the next point in the Attach/Detach State Model or PDP Context State Model) without substituting new data from the gsmSCF. 6.6.2.6.2 Information Elements Information element name Status Description PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Continue GPRS applies to the GPRS Session. If this IE is present in the IF, then the Continue GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.7 Entity Released GPRS ack 6.6.2.7.1 Description This IF is the response to the Entity Released GPRS. 6.6.2.7.2 Information Elements This IF contains no information elements. 6.6.2.8 Event Report GPRS ack 6.6.2.8.1 Description This IF is the response to the Event Report GPRS. 6.6.2.8.2 Information Elements This IF contains no information elements. 6.6.2.9 Furnish Charging Information GPRS 6.6.2.9.1 Description This IF is used to request the gprsSSF to include information in the CAMEL specific logical call record. The logical call record is created when FCI-GPRS is received and a logical call record for that state model does not exist. For modelling purposes the logical call record is buffered in the gprsSSF. The gprsSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then its free format data are moved to the corresponding CDR and the logical call record is deleted. In the SGSN there is a separate Logical call record for the attach/detach state model and for each PDP context. The CSE can send multiple concatenated FCIs per Logical Call Record for completion. The total maximum of free format data is 160 octets per Logical Call Record. The 160 octets may be sent in one or more FCI IF. If there is incomplete free format data and one or more new FCI IFs is/are received to overwrite the incomplete data, then the incomplete data are discarded and the gsmSCF can send another 160 octets per CDR. 6.6.2.9.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. FCI GPRS Billing Charging Characteristics M This IE is described in a table below. FCI GPRS Billing Charging Characteristics contains the following information: Information element name Status Description FCIBCCCAMEL Sequence 1 M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information: Information element name Status Description Free Format Data M This IE contains free format data to be inserted in the CAMEL logical call record. Append Free Format Data O This IE indicates that the gprsSSF shall append the free format data to the Logical call record. In the SGSN there is a separate Logical call record for the attach/detach state model and for each PDP context. - If this IE is present indicating ""Append"", the gprsSSF shall append the free format data received in this IF to the free format data already present in the Logical call record for that GPRS session or PDP Context. - If this IE is absent or indicates ""Overwrite"", then the gprsSSF shall overwrite all free format data already present in the Logical call record for that GPRS session or PDP Context, by the free format data received in this IF. If no Logical call record exists yet for that GPRS session or PDP Context, then the gprsSSF shall ignore this IE. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Furnish Charging Information GPRS applies to the GPRS Session. If this IE is present in the IF, then the Furnish Charging Information GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.10 Release GPRS 6.6.2.10.1 Description This IF is used by the gsmSCF to tear down an existing GPRS session or PDP Context at any time. 6.6.2.10.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. GPRS Cause M This IE contains the Cause value indicating the reason for releasing the GPRS session or PDP context. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Release GPRS applies to the GPRS Session, in which case the GPRS Session and all PDP Contexts shall be released. If this IE is present in the IF, then the Release GPRS applies to the indicated PDP Context, in which case the indicated PDP Context shall be released. Scenario 2: This IE is not used in the IF. 6.6.2.11 Request Report GPRS Event 6.6.2.11.1 Description This IF is used to request the gprsSSF to monitor for an event and send a notification back to the gsmSCF when the event is detected (see Event Report GPRS IF). 6.6.2.11.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. GPRS Event M This IE specifies the event or events of which a report is requested. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IF is used to arm an event related to the GPRS Session, then this IF shall not include this IE. If this IF is used to arm an event related to a specific PDP Context, then this IF shall include this IE for that PDP Context. If this IF is used to generically arm a PDP Context related event, then this IF shall not include this IE. Scenario 2: This IE is not used in the IF. GPRS Event contains the following information elements: Information element name Status Description GPRS Event type M This IE specifies the type of event of which a report is requested. Monitor Mode M This IE indicates how the event shall be reported. 6.6.2.12 Reset Timer GPRS 6.6.2.12.1 Description This IF is used to refresh the gprsSSF timer. 6.6.2.12.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Timer ID M This IE specifies the default value for the Tssf timer. Timer Value M This IE specifies the value to which the timer Tssf shall be set. 6.6.2.13 Send Charging Information GPRS 6.6.2.13.1 Description This IF is used to send e parameters from the gsmSCF to the gprsSSF. If charge advice information is received from the gsmSCF, it shall replace the charge advice information which would be generated by the SGSN and inhibit any further generation of CAI by the SGSN. Further processing of the charge advice information by the SGSN shall be in accordance with the Advice of Charge supplementary service. If the SGSN supports Advice of Charge, then the gsmSCF may use this IF to send e parameters to the gprsSSF. However, if the subscriber is not provisioned with the Advice of Charge supplementary service, then no e parameters shall be sent to the MS and no error due to this fact shall be sent back to the gsmSCF. If the SGSN does not support Advice of Charge, then the gsmSCF shall not send e parameters to the gprsSSF. The SGSN's support of Advice of Charge is indicated in the Initial DP GPRS IF. NOTE: If charge advice information is received from the gsmSCF after charge information has been generated by the SGSN and sent to the MS, the behaviour of the service may be unpredictable or incorrect; the service designer should therefore ensure that the first set of charge advice information is sent to the gprsSSF before charge information is sent to the to the MS. 6.6.2.13.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. SCI GPRS Billing ChargingCharacteristics M This IE defines the Advice Of Charge related information to be provided to the Mobile Station, if supported by the SGSN. GPRS SCI Billing Charging Characteristics contains the following information elements: Information element name Status Description AOC GPRS M This IE is present after an Activate PDP Context Accept or Attach Accept has been received from the SGSN. This IE defines the Advice Of Charge related information to be provided to the Mobile Station, if supported by the SGSN. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Send Charging Information GPRS applies to the GPRS Session. If this IE is present in the IF, then the Send Charging Information GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. AOC GPRS contains the following information elements: Information element name Status Description AOC Initial M This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. AOC Subsequent O This IE is described in a table below. AOC Subsequent contains the following information elements: Information element name Status Description CAI Elements M This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O This IE indicates the tariff switch time until the next tariff switch applies. 6.6.3 HLR to SGSN Information Flows 6.6.3.1 Delete Subscriber Data 6.6.3.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from an SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.3.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in SGSN. Specific CSI Withdraw O This IE is used to indicate that only GPRS CSI shall be deleted from the SGSN. This IE should not be present when CAMEL Subscription Info Withdraw is present. 6.6.3.2 Insert Subscriber Data 6.6.3.2.1 Description This IF is specified in 3GPP TSÊ29.002Ê[34] and used by the HLR to insert subscriber data in the SGSN. 6.6.3.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information element: Information element name Status Description GPRS CSI O This IE identifies the subscriber as having CAMEL GPRS services. GPRS CSI contains the following information elements: Information element name Status Description GsmSCF Address M See subclauseÊ6.3.1.1. Service Key M See subclauseÊ6.3.1.2. Default Session Handling M See subclauseÊ6.3.1.3. TDP List M See subclauseÊ6.3.1.4. CAMEL Capability Handling M See subclauseÊ6.3.1.5. 6.6.4 SGSN to HLR Information Flows 6.6.4.1 Insert Subscriber Data ack 6.6.4.1.1 Description This IF is used by the SGSN to indicate to the HLR the result of the Insert Subscriber Data IF. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.4.1.2 Information Elements Insert Subscriber Data ack contains the following CAMEL specific information elements: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the SGSN. It shall be present when a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. It shall be present if a CSI has been included in the Insert Subscriber Data IF. MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI. It shall be present if a CSI has been included in the Insert Subscriber Data IF. PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancements of Provide Subscriber Information. 6.6.4.2 Update GPRS Location 6.6.4.2.1 Description This IF is used by the SGSN to indicate to the HLR the CAMEL phases supported by the SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.4.2.2 Information Elements Update GPRS location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the SGSN. The SGSN may indicate support of CAMEL phaseÊ3 or higher. It shall be present when the SGSN supports CAMEL. Offered CAMEL4 CSIs This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI. PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancements of Provide Subscriber Information. 7 Short Message Services 7.1 Architecture 7.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support Mobile Originating Short Message Service (MO SMS) and Mobile Terminating Short Message Service (MT SMS) interworking for CAMEL. FiguresÊ7.1-1 and 7.1-2 show the functional entities involved in MO SMS or MT SMS requiring CAMEL support. Further details of the architecture needed to support Mobile Originating Short Message Service (MO SMS) and Mobile Terminating Short Message Service (MT SMS) are given in 3GPP TSÊ23.040Ê[14]. Figure 7.1-1: Functional architecture for support of CAMEL control of MSC switched MO and MT SMS Figure 7.1-2: Functional architecture for support of CAMEL control of SGSN switched MO and MT SMS HLR: The HLR stores MO SMS CSI and/or MT SMS CSI. MO SMS CSI contains subscription information for subscribers that require CAMEL support of MO SMS. MT SMS CSI contains subscription information for subscribers that require CAMEL support of MT SMS. One or both of MO SMS CSI and MT SMS CSI are transferred to the VLR or to the SGSN on Location Update and Restore Data or when MO SMS CSI or MT SMS CSI has changed. VLR: The VLR receives the MO SMS CSI and MT SMS CSI for the subscriber from the HLR. MO SMS CSI and MT SMS CSI are used by the MSC to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. MSC: The MSC receives MO SMS CSI and MT SMS CSI from the VLR and uses this to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. SGSN: The SGSN receives the MO SMS CSI and MT SMS CSI for the subscriber from the HLR. The SGSN uses the MO SMS CSI and MT SMS CSI to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. gprsSSF: see subclauseÊ3.1. gsmSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. SMSC: The Short Message Service Centre accepts messages submitted by an MS or other MO short message entity, stores them and delivers them to the destination MS or other MT short message entity. SMS-GMSC: The Short Message Service Gateway MSC receives short messages from the SMSC, interrogates the HLR for routeing information to deliver each short message and forwards each short message to the serving node (MSC or SGSN) for delivery to the destination MS. The SMS-GMSC may be physically integrated with the SMSC or with the MSC for the destination subscriber. SMS-IWMSC: The Short Message Service InterWorking MSC terminates the MAP signalling from the MSC or the SGSN for MO short message submission, and transfers the short message to the SMSC, The SMS-IWMSC may be physically integrated with the SMSC or with the MSC for the originating subscriber. 7.1.2 Interfaces defined for CAMEL 7.1.2.1 HLR - VLR interface This interface is used to send CAMEL related subscriber data (MO SMS CSI and MT SMS CSI) to a visited MSC/VLR or to remove CAMEL related subscriber data from a visited MSC/VLR. 7.1.2.2 HLR - SGSN interface This interface is used to send CAMEL related subscriber data (MO SMS CSI and MT SMS CSI) to a visited SGSN or to remove CAMEL related subscriber data from a visited SGSN. 7.1.2.3 gsmSSF - gsmSCF interface This interface is used by the gsmSCF to control the handling of MO SMS and MT SMS in the MSC. A relationship on this interface is opened as a result of the gsmSSF sending a request for instructions to the gsmSCF. 7.1.2.4 gprsSSF - gsmSCF interface This interface is used by the gsmSCF to control the handling of MO SMS and MT SMS in the SGSN. A relationship on this interface is opened as a result of the gprsSSF sending a request for instructions to the gsmSCF. 7.1.2.5 MSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 7.1.2.6 SGSN - gprsSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 7.1.2.7 MSC - VLR interface This is an internal interface. The interface is described in the present document to make it easier to understand the internal information flow within the MSC/VLR. 7.1.2.8 MSC - SMSC interface This interface is used by the MSC to submit a SM to the SMSC and to deliver a SM to the MSC. 7.1.2.9 SGSN - SMSC interface This interface is used by the SGSN to submit a SM to the SMSC and to deliver a SM to the SGSN. 7.2 Detection Points (DPs) For the general handling of the DPs, see subclauseÊ4.2. 7.2.1 Criteria at DP SMS Delivery Request The HLR may store a criterion that indicates when triggering shall take place. The criterion for DPÊSMS_Delivery_Request consists of a list of TPDU types. Refer to 3GPP TSÊ23.040Ê[14] for the available TPDU types. When the TPDU type of the Short Message is present in the list of TPDU types, then triggering shall take place. Otherwise, triggering shall not take place. If no criterion is defined for a subscriber, then triggering shall take place regardless of the TPDU type of the Short Message. 7.3 Description of CAMEL Subscriber Data Note: CAMEL PhaseÊ3 specifies SMS CSI for MO SMS CAMEL Services. CAMEL PhaseÊ4 specifies MO SMS CSI for MO SMS CAMEL Services and MT SMS CSI for MT SMS CAMEL Services. SMS CSI and MO SMS CSI are, however, syntactically and functionally identical. 7.3.1 Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI) This subclause defines the contents of the Short Message Service CAMEL Subscription Information. 7.3.1.1 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 7.3.1.2 Service Key The Service Key identifies to the gsmSCF the service logic. 7.3.1.3 Default SMS Handling The Default SMS Handling indicates whether the Short Message submission shall be released or continued as requested in the case of error in the dialogue between gsmSCF and gsmSSF or gprsSSF. 7.3.1.4 TDP List The TDP List indicates on which detection point triggering shall take place. For MO SMS CSI only DPÊSMS_Collected_Info is used. 7.3.1.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. This parameter shall be set to CAMEL PhaseÊ3 7.3.1.6 CSI state The CSI state indicates whether the MO SMS CSI is active or not. 7.3.1.7 Notification flag The notification flag indicates whether the change of the MO SMS CSI shall trigger Notification on Change of Subscriber Data or not. 7.3.2 Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI) This subclause defines the contents of the Mobile Terminating Short Message Service CAMEL Subscription Information. 7.3.2.1 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 7.3.2.2 Service Key The Service Key identifies to the gsmSCF the service logic. 7.3.2.3 Default SMS Handling The Default SMS Handling indicates whether the Short Message delivery shall be released or continued as requested in the case of error in the dialogue between gsmSCF and gsmSSF or gprsSSF. 7.3.2.4 TDP List The TDP List indicates on which detection point triggering shall take place. For MT SMS CSI only DPÊSMS_Delivery_Request is used. 7.3.2.5 DP criteria The DP criteria indicate whether the SMS_SSF shall request the gsmSCF for instructions. 7.3.2.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. This parameter shall be set to CAMEL PhaseÊ4. 7.3.2.7 CSI state The CSI state indicates whether the MT SMS CSI is active or not. 7.3.2.8 Notification flag The notification flag indicates whether the change of the MT SMS CSI shall trigger Notification on Change of Subscriber Data or not. 7.3.3 gsmSCF address list for CSI The gsmSCF address list indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI's. 7.4 Description of SMS State Models 7.4.1 General Handling See subclauseÊ4.4.1. The State Model for MO SMS handling contains Points in Association (PIA's) instead of Points in Call (PIC's). 7.4.2 Mobile Originating SMS State Models 7.4.2.1 Description of MO SMS state model The MO SMS state model is used to describe the actions in an MSC and in a SGSN during Mobile Originating SMS. Figure 7.2: MO SMS State Model Table 7.1: Description of MO SMS DPs in the MSC and SGSN CAMEL Detection Point DP Type Description DPÊSMS_Collected_Info TDP R Indication that the MO SMS CSI is analysed and a mobile originated short message is received. DPÊO_SMS_Failure EDP N, EDP R Indication that the SM submission to the Short Message Service Centre failed DPÊO_SMS_Submitted EDP N, EDP R Indication that the SM has been successfully submitted to the Short Message Service Centre. 7.4.2.1.1 Description of the MO SMS state model (PIAs) This subclause describes the state model for originating SMS transfer. For each PIA a description can be found of the entry events, actions and exit events. 7.4.2.1.1.1 SMS Null & Start & Authorize Entry events: - Previous MO SMS transfer to the SMSC completed (DPÊO_SMS_Submitted). - Exception event is reported. Actions: - Interface is idled. - Authentication. - Ciphering. - MO SMS subscription check. - RP-MO-DATA message containing the User Data and the SMSC address is received from MS. - The supplementary service ""barring of all outgoing calls"" is checked and invoked if necessary. - The ODB category ""barring of all outgoing calls"" is checked and ODB is invoked if necessary. Exit events: - MO SMS CSI is analysed. - An exception condition is encountered. 7.4.2.1.1.2 SMS Analyse & Routing Entry events: - MO SMS CSI is analysed (DPÊSMS_Collected_Info). Actions: - Information being analysed and/or translated to determine routeing address of the SMSC. - Outgoing barring services and ODB categories not already applied are checked and invoked if necessary. If any of the barring services or ODB categories prevents the submission of the MO SMS, then the MSC or SGSN shall generate the ""O_SMS_Failure"" event. The cause code to be used in that case shall be ""sM DeliveryFailure"". - The short message is sent to the SMSC. Exit events: - Acknowledge from the SMSC is received. (DPÊO_SMS_submitted). A positive acknowledgement is sent to the MS. - An exception condition is encountered - this leads to the SMS_Exception PIA. A negative acknowledgement is sent to the MS. - Attempt to select the route for the SMS fails (DPÊO_SMS_Failure). A negative acknowledgement is sent to the MS. - Negative acknowledgement from the SMSC is received (DPÊO_SMS_Failure). A negative acknowledgement is sent to the MS. 7.4.2.1.1.3 SMS_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIA cannot be met. Actions: - Default handling of the exception condition is applied. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If a relationship exists between the gsmSCF and gsmSSF or gprsSSF send an error information flow closing the relationship and indicating that any outstanding Short Message handling instructions will not run to completion. - The MSC/gsmSSF or SGSN/gprsSSF shall make use of vendor-specific procedures to ensure release of internal resources. Exit events: - Default handling of the exception condition by MSC/gsmSSF or SGSN/gprsSSF completed. 7.4.3 Mobile Terminating SMS State Model 7.4.3.1 Description of MT SMS state model The MT SMS state model is used to describe the actions in an MSC and in a SGSN during Mobile Terminating SMS. Figure 7.3: MT SMS State Model Table 7.2: Description of MT SMS DPs in the MSC and SGSN CAMEL Detection Point DP Type Description DPÊSMS_Delivery_Request TDP R Indication that the MT SMS CSI is analysed and a mobile terminating short message or status report is received. DPÊT_SMS_Failure EDP N, EDP R Indication that the SM delivery to the Mobile Station has failed DPÊT_SMS_Delivered EDP N, EDP R Indication that the SM has been successfully delivered to the Mobile Station. 7.4.3.1.1 Description of the MT SMS state model (PIAs) This subclause describes the state model for terminating SMS transfer. For each PIA a description can be found of the entry events, actions and exit events. 7.4.3.1.1.1 SMS Null & Start & Authorize Entry events: - MAP-MT-FORWARD-SHORT-MESSAGE message is received from SMS-GMSC. - Previous MT SMS transfer to the MS completed (DPÊT_SMS_Delivered). - Exception event is reported. Actions: - Interface is idled. - MT SMS subscription check. - MT SMS CSI is received from the VLR (in the MSC only). Exit events: - MT SMS CSI is analysed. - An exception condition is encountered. 7.4.3.1.1.2 SMS Delivery Entry events: - MT SMS CSI is analysed. (DPÊSMS_Delivery_Request). Actions: - Subscriber paging is performed, if required. - The short message is delivered to the MS. Exit events: - Acknowledge from the MS is received. (DPÊT_SMS_Delivered). A positive acknowledgement is sent to the SMSC. - An exception condition is encountered - this leads to the SMS_Exception PIA. A negative acknowledgement is sent to the SMSC. - Negative acknowledgement from the MS is received (DPÊT_SMS_Failure). A negative acknowledgement is sent to the SMSC. 7.4.3.1.1.3 SMS_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIA cannot be met. Actions: - Default handling of the exception condition is applied. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If a relationship exists between the gsmSCF and gsmSSF or gprsSSF send an error information flow closing the relationship and indicating that any outstanding Short Message handling instructions will not run to completion. - The MSC/gsmSSF or SGSN/gprsSSF shall make use of vendor-specific procedures to ensure release of internal resources. Exit events: - Default handling of the exception condition by MSC/gsmSSF or SGSN/gprsSSF completed. 7.5 Procedures for CAMEL SMS 7.5.1 Functional architecture for CAMEL MO SMS services Note 1: The functional entities depicted by means of dark shaded boxes in the figureÊ7.4 are not affected by CAMEL interaction with MO SMS. Note 2: The Relay Protocol between the MS and the MSC or SGSN is described in 3GPP TSÊ24.011Ê[31]. The Relay Protocol between the MSC or SGSN and the SMS-GMSC is described in 3GPP TSÊ29.002Ê[34]. The Relay Protocol between the SMS-GMSC and the SMSC is not standardised. Examples of this protocol are described in GSM TRÊ03.47Ê[42]. Figure 7.4: MO SMS via MSC or SGSN 7.5.2 Handling of mobile originating SMS 7.5.2.1 Handling of mobile originating SMS in the originating MSC or SGSN The functional behaviour of the originating MSC or SGSN is specified in 3GPP TSÊ29.002Ê[34] and 3GPP TSÊ23.060Ê[15]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_O_SMS_INIT; - Procedure CAMEL_O_SMS_SUBMITTED; - Procedure CAMEL_O_SMS_FAILURE. A CAMEL Service may be invoked for the following Mobile Originated short message types: - Short Message Submission (TPDU type = SMS-SUBMIT) - Short Message Command (TPDU type = SMS-COMMAND) Refer to 3GPP TSÊ23.040Ê[14] for a description of the various TPDU types and to 3GPP TSÊ24.011Ê[31] for a description of the protocol elements of the Short Message Relay Layer (RPDUs). 7.5.2.1.1 Actions of the MSC or SGSN on receipt of Int_Error The MSC or SGSN checks the default SMS Handling parameter in MO SMS CSI. If the default SMS handling is 'releaseTransaction', a A_RP_ERROR is sent to the MS. The MSC or SGSN then releases all resources and the procedure CAMEL_O_SMS_INIT ends. If the default SMS handling is 'continueTransaction', the MSC or SGSN continues processing without CAMEL support. 7.5.2.1.2 Actions of the MSC or SGSN on receipt of Int_Continue_SMS The MSC or SGSN continues processing with modified SM parameters. The MSC or SGSN shall transparently modify the SMS parameters with the received information. Parameters which are not included in the Int_Continue_SMS signal are unchanged. 7.5.2.1.3 Actions of the MSC or SGSN on receipt of Int_Connect_SMS The MSC or SGSN continues processing with modified SM parameters. The MSC or SGSN shall transparently modify the SMS parameters with the received information. Barring is checked with the modified parameters. Parameters which are not included in the Int_Connect_SMS signal are unchanged. 7.5.2.1.4 Actions of the MSC or SGSN on receipt of Int_Release_SMS A_RP_ERROR is sent to the MS and the Short Message is deleted. The SMS cause received in the Int_Release_SMS signal is used. The MSC or SGSN then releases all resources and the procedure CAMEL_O_SMS_INIT ends. 7.5.2.1.5 Allocation of SMS Reference Number During the CAMEL handling of a Mobile Originated Short Message, the MSC or SGSN shall allocate an SMS Reference Number. This SMS Reference Number shall be placed in the SMS-MO Call Detail Record, together with the MSC Address or SGSN Number. This SMS Reference Number shall also be sent to the gsmSCF in the Initial DP SMS Information Flow, together with the MSC Address or SGSN Number. The combination of SMS Reference Number and MSC Address or SGSN Number forms a globally unique pair. This pair may be used for correlation of CDRs produced in the MSC or SGSN with CDRs produced in the gsmSCF. An SMS Reference Number shall be generated and placed in the SMS-MO Call Detail Record, for every Short Message, including the case when a Short Message forms part of a set of concatenated Short Messages."
"7.5.2.2 Handling of A_MM_Release and A_LLC_Release If the radio link with the subscriber is lost during the handling of a CAMEL procedure in the MSC or SGSN, then the MSC or SGSN sends signal A_MM_Release_ind or A_LLC_Release_ind to that procedure. This results in the termination of that CAMEL procedure. (Refer to 3GPP TSÊ29.002Ê[34] for details.) 7.5.2.3 Handling of time-out from SMSC If the MSC or SGSN does not receive a confirmation from the SMSC after submission of a Short Message, then the MSC or SGSN calls procedure CAMEL_O_SMS_FAILURE. (Refer to 3GPP TSÊ29.002Ê[34] for details.) Figure 7.5-1: Procedure CAMEL_O_SMS_INIT (sheet 1) Figure 7.5-2: Procedure CAMEL_O_SMS_INIT (sheet 2) Figure 7.5-3: Procedure CAMEL_O_SMS_INIT (sheet 3) Figure 7.6-1: Procedure CAMEL_O_SMS_SUBMITTED (sheet 1) Figure 7.7-1: Procedure CAMEL_O_SMS_FAILURE (sheet 1) 7.5.2.4 Handling of mobile originating SMS in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ29.002Ê[34] The handling specific to CAMEL is specified in the following procedure: - Procedure CAMEL_MO_SMS_VLR. Figure 7.8-1: Procedure CAMEL_MO_SMS_VLR (sheet 1) 7.5.3 Functional architecture for CAMEL MT SMS services Note 1: The functional entities depicted by means of dark shaded boxes in the figureÊ7.9 are not affected by CAMEL interaction with MT-SMS. Note 2: The Relay Protocol between the MS and the MSC or SGSN is described in 3GPP TSÊ24.011Ê[31]. The Relay Protocol between the MSC or SGSN and the SMS-GMSC is described in 3GPP TSÊ29.002Ê[34]. The Relay Protocol between the SMS-GMSC and the SMSC is not standardised. Examples of this protocol are described in GSM TRÊ03.47Ê[42]. Figure 7.9: MT SMS via MSC or SGSN 7.5.4 Handling of mobile terminating SMS 7.5.4.1 Handling of mobile terminating SMS in the terminating MSC or SGSN A CAMEL Service may be invoked for the following Mobile Terminated short message types: - Short Message Delivery (TPDU type = SMS-DELIVER) - Short Message Status Report (TPDU type = SMS-STATUS-REPORT) Refer to 3GPP TSÊ23.040Ê[14] for a description of the various TPDU types and to 3GPP TSÊ24.011Ê[31] for a description of the protocol elements of the Short Message Relay Layer (RPDUs). The functional behaviour of the terminating MSC or SGSN is specified in 3GPP TSÊ29.002Ê[34]. The procedures specific to CAMEL are specified in the following subclauses: 7.5.4.1.1 Procedure CAMEL_T_SMS_INIT; This procedure is called when a Short Message delivery attempt is received from the SMS-GMSC. If MT SMS CSI is present for the subscriber, then the SMS_SSF shall be invoked. Otherwise, the Short Message delivery attempt proceeds without CAMEL. When the SMS_SSF is invoked and the SMS_SSF has requested the gsmSCF for instructions, the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The gsmSCF has indicated that SM delivery may proceed. It may have supplied the SMS_SSF with a modified Calling Party Number. This Calling Party Number shall replace the TP-Originating-Address in the SMS-DELIVER TPDU. - Int_Release_SMS The gsmSCF has force-released SM delivery. The RP Cause received from the gsmSCF shall be conveyed to the SMS-GMSC in the RP-Cause component, in the RP-ERROR RPDU. - Int_Error A Tssf time-out or an internal SMS_SSF error has occurred; the SM has not been forwarded to the Mobile Station. If Default SMS Handling equals 'Continue', the SM delivery proceeds. Otherwise, SM delivery shall be aborted. In the latter case, the RP-Cause component, in the RP-ERROR RPDU shall be set to EquipmentProtocolError, in accordance with 3GPP TSÊ29.002Ê[34]. 7.5.4.1.2 Procedure CAMEL_T_SMS_DELIVERED This procedure is called when the MSC or SGSN has detected that delivery of the SM to the Mobile Station has succeeded. No event specific information is sent to the gsmSCF. When Short Message delivery attempt success has been reported to the gsmSCF, then the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The event was reported to the gsmSCF in interrupt mode. The gsmSCF has concluded CAMEL processing and has terminated the Service Logic. - Int_Continue The event was not reported to the gsmSCF or was reported in notification mode. - Int_Error A Tssf time-out has occurred. In all the above cases, the SM processing in the MSC or SGSN continues. 7.5.4.1.3 Procedure CAMEL_T_SMS_FAILURE This procedure is called when the MSC or SGSN has detected that delivery of the SM to the Mobile Station has failed. If the delivery failure is due to RP-ERROR RPDU received from the MS, then the MT SMS Cause in the event report to the gsmSCF shall be set to the RP-Cause component in the RP-ERROR-RPDU. Otherwise, if the delivery failure is due to internal failure in the MSC or SGSN, CP-ERROR from MS or time-out from the MS, then the MT SMS Cause in the event report to the gsmSCF shall be set to ""Protocol error, unspecified"", as defined in 3GPP TSÊ24.011Ê[31]. When Short Message delivery attempt failure has been reported to the gsmSCF, then the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The event was reported to the gsmSCF in interrupt mode. The gsmSCF has concluded CAMEL processing and has terminated the Service Logic. - Int_Continue The event was not reported to the gsmSCF or was reported in notification mode. - Int_Error A Tssf time-out has occurred. In all the above cases, the SM processing in the MSC or SGSN continues. 7.5.4.1.4 Allocation of SMS Reference Number During the CAMEL handling of a Mobile Terminating Short Message, the MSC or SGSN shall allocate an SMS Reference Number. This SMS Reference Number shall be placed in the SMS-MT Call Detail Record, together with the MSC Address or SGSN Number. This SMS Reference Number shall also be sent to the gsmSCF in the Initial DP SMS Information Flow, together with the MSC Address or SGSN Number. The combination of SMS Reference Number and MSC Address or SGSN Number forms a globally unique pair. This pair may be used for correlation of CDRs produced in the MSC or SGSN with CDRs produced in the gsmSCF. An SMS Reference Number shall be generated and placed in the SMS-MT Call Detail Record, for every Short Message, including the case when a Short Message forms part of a set of concatenated Short Messages. Figure 7.10-1: Procedure CAMEL_T_SMS_INIT (sheet 1) Figure 7.10-2: Procedure CAMEL_T_SMS_INIT (sheet 2) Figure 7.11-1: Procedure CAMEL_T_SMS_FAILURE (sheet 1) Figure 7.12-1: Procedure CAMEL_T_SMS_DELIVERED (sheet 1) 7.5.4.2 Handling of mobile terminating SMS in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ29.002Ê[34]. The handling specific to CAMEL is specified in the following procedure: - Procedure CAMEL_MT_SMS_VLR. Figure 7.13-1: Procedure CAMEL_MT_SMS_VLR (sheet 1) 7.5.4.3 CAMEL subscription check for mobile terminating SMS in the SGSN The functional behaviour of the SGSN for delivery of MT shrt message is specified in 3GPP TSÊ29.002Ê[34]. The procedure for checking CAMEL capability and subscription information is specified in the following procedure: - Procedure CAMEL_MT_SMS_SGSN. Figure 7.14-1: Procedure CAMEL_MT_SMS_SGSN (sheet 1) 7.5.5 Handling of mobile originating and mobile terminating SMS in the gsmSSF or gprsSSF 7.5.5.1 Process SMS_SSF Sheet 1 The Int_Invoke SMS_SSF signal dictates which TDP shall be armed. For a Mobile Originated SMS service, the SMS_Collected_Info TDP shall be armed. For a Mobile Terminated SMS service, the SMS_Delivery_Request TDP shall be armed. Sheet 2 The Int_SMS_Failure signal may be received only for a MO-SMS service. It is received when a MS detach event occurs before the SMS_SSF is invoked. Sheet 3 The SMSC Address and Destination Subscriber Number may be received in CAP ConnectSMS only for a MO-SMS service. Sheet 4: For a MO-SMS service, the following events may be armed or disarmed: O_SMS_Submission, O_SMS_Failure. For a MT-SMS service, the following events may be armed or disarmed: T_SMS_Delivery, T_SMS_Failure. Sheet 5: For a MO-SMS service, the gsmSCF may place free-format charging data in the 'MOSMSRecord' CDR (in the MSC) or in the S-SMO-CDR (in the SGSN). For a MT-SMS service, the gsmSCF may place free-format charging data in the 'MTSMSRecord' (in the MSC) or in the S-SMT-CDR (in the SGSN). Refer to 3GPP TSÊ32.250Ê[37] and 3GPP TSÊ32.251Ê[38] for a description of these CDR types. Sheet 6: The Int_SMS_Failure signal in state Waiting_For_Instructions may be received for a MO-SMS service only. It is received when a MS detach event occurs before the gsmSCF has given instruction to continue SM processing. Sheet 7: When the SM submission or failure event occurs, both MO-SMS events shall be disarmed. When the SM delivery or failure event occurs, both MT-SMS events shall be disarmed. 7.5.5.2 Process Complete_SMS_FCI_Record Sheet 1: For a MO-SMS service, the 'MOSMSRecord' or 'S-SMO-CDR' shall be closed. For a MT-SMS service, the 'MTSMSRecord' or 'S-SMT-CDR' shall be closed. Figure 7.15-1: Process SMS_SSF (sheet 1) Figure 7.15-2: Process SMS_SSF (sheet 2) Figure 7.15-3: Process SMS_SSF (sheet 3) Figure 7.15-4: Process SMS_SSF (sheet 4) Figure 7.15-5: Process SMS_SSF (sheet 5) Figure 7.15-6: Process SMS_SSF (sheet 6) Figure 7.15-7: Process SMS_SSF (sheet 7) Figure 7.16-1: Procedure Check_Criteria_SMS_Delivery_Request (Sheet 1) Figure 7.17-1: Procedure Complete_SMS_FCI_record (sheet 1) 7.6 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for SMS control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Optional (O), Specific conditions (S), mutually Exclusive (E), or not applicable (-) for each different traffic case: Mobile Originating SMS (MO) and Mobile Terminating SMS (MT). If the IEs in one table apply in both the MO and MT cases, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The distinction between MO and MT SMS applies only to the Information Flows between the gsmSCF and the gsmSSF or gprsSSF. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34], TSÊ29.078Ê[36]. 7.6.1 gsmSSF or gprsSSF to gsmSCF information flows 7.6.1.1 Event Report SMS 7.6.1.1.1 Description This IF is used to notify the gsmSCF of an event previously requested by the gsmSCF in a Request Report SMS Event IF. 7.6.1.1.2 Information Elements Information element name MO MT Description Event Type M M This IE specifies the type of event that is reported. Event Specific Information C C This IE indicates the SMS related information specific to the event. Misc SMS Info M M This IE indicates the DP type. If the Event Type IE indicates O_SMS_Failure, then the Event Specific Information contains the following information element: Information element name MO MT Description MO_SMS Cause M - This IE indicates the reason of submission failure. If the Event Type IE indicates T_SMS_Failure, then the Event Specific Information contains the following information elements: Information element name MO MT Description MT_SMS Cause - M This IE indicates the reason of delivery failure. If the Event Type IE indicates O_SMS_Submitted or T_SMS_Delivered, then no Event Specific Information shall be sent to the gsmSCF. 7.6.1.2 Initial DP SMS 7.6.1.2.1 Description This IF is generated by the gsmSSF or gprsSSF when a trigger is detected at a DP in the state model, to request instructions from the gsmSCF. 7.6.1.2.2 Information Elements Information element name MO MT Description Destination Subscriber Number M - This IE contains a number to identify the Destination short message entity. The Destination Subscriber Number shall be retrieved from the TP-Destination-Address in the SMS-SUBMIT TPDU or the SMS-COMMAND TPDU. Called Party Number - M This IE contains a number to identify the subscriber for whom the Short Message is destined. The Called Party Number shall be the MSISDN of the served subscriber. Calling Party Number M C For MO SMS: This IE contains a number to identify the subscriber who requests the SM submission. The Calling Party Number shall be the MSISDN of the served subscriber. For MT SMS: This IE contains the address of the submitter of the short message. For SMS-DELIVER TPDU, the Calling Party Number shall be retrieved from the TP-Originating-Address in the SMS-DELIVER TPDU. For SMS-STATUS-REPORT TPDU, this element shall not be included in this IF. Event Type M M This IE indicates the armed event resulting in the Initial DP SMS IF. IMSI M M This IE identifies the mobile subscriber. Location Information In MSC C C This IE is described in a table below. Location Information In SGSN C C This IE is described in a table below. Service Key M M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application/SLP within the gsmSCF. Time And Timezone M M This IE contains the time that the gsmSSF or gprsSSF was triggered, and the time zone the gsmSSF or gprsSSF resides in. TP Short Message Specific Information M M This IE contains the first octet of the applicable TPDU. For SMS-SUBMIT, the following elements may be included: - Message Type Indicator - Reject Duplicates - Validity Period Format - Status Report Request - User Data Header Indicator - Reply Path For SMS-COMMAND, the following elements may be included: - Message Type Indicator - User Data Header Indicator - Status Report Request For SMS-DELIVER, the following elements may be included: - Message Type Indicator - More Messages to Send - Status Report Indication - User Data Header Indicator - Reply Path For SMS-STATUS-REPORT, the following elements may be included: - Message Type Indicator - More Messages to Send - Status Report Qualifier - User Data Header Indicator Refer to 3GPP TSÊ23.040Ê[14] for an indication of which elements of this 1st octet are Mandatory and which elements are Conditional. TP Protocol Identifier M C This IE indicates the protocol used above SM-Transfer Layer. The TP Protocol Identifier shall be retrieved from the applicable TPDU. For SMS-STATUS-REPORT, the sending of this IE is Conditional, depending on its presence in the SMS-STATUS-REPORT TPDU. TP Data Coding Scheme C C This IE indicates the data coding scheme of the TP User Data field, and may indicate a message class. The message class may indicate e.g. the originator of the Short Message. The TP Data Coding Scheme shall be retrieved from the applicable TPDU. For SMS-COMMAND, this IE shall not be included in this IF. TP Validity Period S - This IE indicates the length of the validity period or the absolute time of the validity period termination. This IE is used only for the SMS-SUBMIT TPDU. The TP Validity Period, if available, shall be retrieved from the SMS-SUBMIT TPDU. For other TPDU, this IE shall not be included in this IF. SMSC Address M M For MO SMS: This IE defines the address of the SMSC to which the MO short message is intended to be submitted. It shall be retrieved from the RP-Destination-Address in the RP-MO-DATA RPDU. For MT SMS: This IE identifies the address of the SMSC from which the MT short message is originating. It shall be retrieved from the RP-Originating-Address in the RP-MT-DATA RPDU. SMS Reference Number M M This IE carries the SMS Reference Number. This Reference Number is allocated by the MSC or SGSN that processes the Short Message. It may be used by the gsmSCF for inclusion in a gsmSCF SMS record. MSC Address S S This IE carries the E.164 MSC Address. This IE shall be present if the Short Message processing takes place in an MSC. Otherwise shall be absent. SGSN Number S S This IE carries the Global Title of the SGSN. See 3GPP TSÊ23.060Ê[15]. This IE shall be present if the Short Message processing takes place in an SGSN. Otherwise shall be absent. GPRS MS Class C - This IE contains the MS network and radio access capabilities if the short message is being transferred through an SGSN. MS Classmark 2 C - This IE contains the MS classmark 2 if the short message is being transferred through an MSC. IMEI (with software version) C - This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Note: Refer to 3GPP TSÊ23.040Ê[14] for a description and encoding of the various TP-DUs and RP-DUs. Location Information in MSC is based on the Location Information IE defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name MO MT Description Service area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. VLR number M M See 3GPP TSÊ23.018Ê[12]. Age of location information - M See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - - Not applicable Selected LSA Identity S S This IE is applicable only if SoLSA is supported by the MSC. This IE indicates the LSA identity associated with the current position of the MS. It shall be shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority shall be present. See 3GPP TSÊ23.073Ê[18]. User CSG Information C C See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location Information in SGSN is based on the Location Information For GPRS IE defined in the subclauseÊ11.3.6.1.2. The following differences and clarifications apply: Information element name MO MT Description Service area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Routeing area ID C C See 3GPP TSÊ23.003Ê[7]. Geographical information C C See 3GPP TSÊ23.032Ê[13]. Geodetic information - - Not applicable Age of location information - - Not applicable Current Location Retrieved - - Not applicable User CSG Information C C See 3GPP TSÊ23.060Ê[15]. 7.6.2 gsmSCF to gsmSSF or gprsSSF information flows 7.6.2.1 Connect SMS 7.6.2.1.1 Description This IF is used to request the gsmSSF or gprsSSF to perform the actions to route the Short Message to a specific destination (for MO SMS) or to deliver the Short Message to the MS (for MT SMS). 7.6.2.1.2 Information Elements Information element name MO MT Description Calling Partys Number O O This IE indicates the subscriber who sent the SMS; possibly changed by the gsmSCF. If the Short Message type is SMS-SUBMIT or SMS-COMMAND, then this IE, if present, it shall replace the RP-Originating-Address in the RP-MO-DATA RPDU (CHOICE set to MSISDN). If the Short Message type is SMS-DELIVER, then this IE, if present, shall replace the TP-Originating-Address in the SMS-DELIVER TPDU. If the Short Message type is SMS-STATUS-REPORT, then this IE, if present, shall be ignored. Destination Subscriber Number O - This IE identifies the Destination short message entity; possibly changed by the gsmSCF. This IE, if present, shall replace the TP-Destination-Address in the SMS-SUBMIT TPDU or SMS-COMMAND-TPDU. SMSC Address O - This IE indicates the SMSC address to which the MO short message shall be submitted; possibly changed by the gsmSCF. This IE, if present, shall replace the RP-Destination-Address in the RP-MO-DATA RPDU (CHOICE set to serviceCentreAddressDA). 7.6.2.2 Continue SMS 7.6.2.2.1 Description This information flow requests the gsmSSF or gprsSSF to proceed normally. The gsmSSF or gprsSSF completes DP processing, and continues with the SMS handling. 7.6.2.2.2 Information Elements This IF contains no information elements. 7.6.2.3 Furnish Charging Information SMS 7.6.2.3.1 Description This IF is used to request the gsmSSF or gprsSSF to include information in the CAMEL specific logical MO SMS or MT SMS record. The logical call record is created when FCI-SMS is received and a logical call record for that short message does not exist. For modelling purposes the logical call record is buffered in the gsmSSF or gprsSSF. The gsmSSF or gprsSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then its free format data are moved to the corresponding CDR and the logical call record is deleted. The gsmSCF can send multiple concatenated FCIs per Short Message for completion. The total maximum of free format data is 160 octets per SM. The 160 octets may be sent in one or more FCI IFs. If there are incomplete free format data and new FCI IFs is/are received to overwrite the incomplete data, then the incomplete data are discarded and the gsmSCF can send another 160 octets per SM. 7.6.2.3.2 Information Elements Information element name MO MT Description FCI Billing Charging Characteristics M M This IE is described in a table below. FCI Billing Charging Characteristics contains the following information element: Information element name MO MT Description FCIBCCCAMEL Sequence 1 M M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information elements: Information element name MO MT Description Free Format Data M M This IE contains free format data to be inserted in the CAMEL logical call record. Append Free Format Data O O This IE indicates that the gsmSSF or gprsSSF shall append the free format data to the Logical MO SMS or MT SMS record. - If this IE is present indicating ""Append"", the gsmSSF or gprsSSF shall append the free format data received in this IF to the free format data already present in the Logical MO SMS or MT SMS record. - If this IE is absent or indicates ""Overwrite"", then the gsmSSF shall overwrite all free format data already present in the Logical MO SMS or MT SMS record, by the free format data received in this IF. If no Logical MO SMS or MT SMS record exists yet, then the gsmSSF or gprsSSF shall ignore this IE. 7.6.2.4 Release SMS 7.6.2.4.1 Description This IF is used to tear down by the gsmSCF an existing SMS transfer. 7.6.2.4.2 Information Elements Information element name MO MT Description RP Cause M M SMS Cause. Indicates the SMS specific cause of the release. The cause is reported to the MS (in the case of MO SMS) or SMSC (in the case of MT SMS). For MO SMS, the RP Cause value shall be used to set the RP-Cause in the RP-ERROR RPDU sent to the MS. 3GPP TSÊ24.011Ê[31] specifies which RP-Cause values may be sent to the MS. For MT SMS, the RP Cause value shall be used to set the RP-Cause in the RP-ERROR RPDU sent to the SMSC. 3GPP TSÊ29.002Ê[34] specifies which RP-Cause values may be sent to the SMSC. 7.6.2.5 Request Report SMS Event 7.6.2.5.1 Description This IF is used to request the gsmSSF or gprsSSF to monitor for an event and to send a notification to the gsmSCF when the event is detected (see Event Report SMS IF). 7.6.2.5.2 Information Elements Information element name MO MT Description SMS Event M M This IE specifies the event or events of which a report is requested. SMS Event contains the following information elements: Information element name MO MT Description Event Type M M This IE specifies the type of event of which a report is requested. Monitor Mode M M This IE indicates how the event shall be reported. 7.6.2.6 Reset Timer SMS 7.6.2.6.1 Description This IF is used to refresh a gsmSSF or gprsSSF timer. 7.6.2.6.2 Information Elements Information element name MO MT Description Timer Value M M This IE specifies the value to which the indicated timer shall be set. Timer ID O O This IE indicates which timer shall be reset. It shall be set to 'Tssf'. 7.6.3 HLR to VLR or SGSN information flows 7.6.3.1 Delete Subscriber Data 7.6.3.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from a VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34] 7.6.3.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in VLR or SGSN. Specific CSI Withdraw O This IE is used to indicate that only MO SMS CSI or MT SMS CSI shall be deleted from the VLR or SGSN. This IE should not be present when CAMEL Subscription Info Withdraw is present. 7.6.3.2 Insert Subscriber Data 7.6.3.2.1 Description This IF is used by the HLR to insert subscriber data in the VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.3.2.2 Information Elements The Insert Subscriber Data contains the following CAMEL specific information elements: Information element name Status Description MO SMS CSI O This IE identifies the subscriber as having MO SMS CAMEL services. MT SMS CSI O This IE identifies the subscriber as having MT SMS CAMEL services. MO SMS CSI contains the following information elements: Information element name Status Description gsmSCF Address M See subclauseÊ7.3.1.1. Service Key M See subclauseÊ7.3.1.2. Default SMS Handling M See subclauseÊ7.3.1.3. CAMEL Capability Handling M See subclauseÊ7.3.1.5. SMS Triggers M See subclauseÊ7.3.1.4. It includes the following trigger: SMS_Collected_Info MT SMS CSI contains the following information elements: Information element name Status Description gsmSCF Address M See subclauseÊ7.3.2.1. Service Key M See subclauseÊ7.3.2.2. Default SMS Handling M See subclauseÊ7.3.2.3. CAMEL Capability Handling M See subclauseÊ7.3.2.6. SMS Triggers M See subclauseÊ7.3.2.4. It includes the following trigger: SMS_Delivery_Request. SMS Trigger Criteria C See subclauseÊ7.3.2.5. 7.6.4 VLR or SGSN to HLR information flows 7.6.4.1 Insert Subscriber Data ack See subclauseÊ4.6.8.1. This information flow is sent by the VLR. 7.6.4.2 Update Location See subclauseÊ4.6.8.3. 7.6.4.3 Update GPRS Location 7.6.4.3.1 Description This IF is used by the SGSN to indicate to the HLR the CAMEL phases and CAMEL phaseÊ4 CSIs offered by the SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.4.3.2 Information Elements Update GPRS location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which CAMEL phases are supported by the SGSN. The SGSN may indicate support of CAMEL phaseÊ3 or higher. It shall be present when the SGSN supports CAMEL. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases"" IE contains support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI 7.6.5 VLR to MSC Information Flows 7.6.5.1 Continue CAMEL SMS Handling 7.6.5.1.1 Description This IF is used to instruct the MSC to continue the CAMEL specific handling. 7.6.5.1.2 Information Elements Information element name Status Description MT SMS CSI M This IE contains the CAMEL Subscription Information for MT SMS. IMSI M IMSI of the served subscriber. MSISDN M MSISDN of the served subscriber. 7.6.5.2 Send Info For MO SMS ack 7.6.5.2.1 Description This IF is used to transport MO SMS related subscription data from the VLR to the MSC. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.5.2.2 Information Elements Information element name Status Description MO SMS CSI C This IE contains the CAMEL Subscription Information for MO SMS. ODB Data C This IE contains ODB data. This information is used to apply ODB for a reconnected Short Message, if needed. CB SS Data C This IE contains CB SS data. This information is used to apply CB for a reconnected Short Message, if needed. 7.6.6 MSC to VLR Information Flows 7.6.6.1 Send Info For MT SMS 7.6.6.1.1 Description This IF is described in 3GPP TSÊ29.002Ê[34]; it is used to request the VLR to provide information to handle an MT SMS. 7.6.6.1.2 Information Elements Send Info For MT SMS contains the following CAMEL specific information element: Information element name Status Description Suppress MT SMS CSI S This IE indicates to the VLR that it shall not return MT SMS CSI to the MSC. This IE shall not be present in the first interrogation; it shall be present in the second interrogation. 8 SS Notifications 8.1 Architecture 8.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support Supplementary Service (SS) Notifications. FigureÊ8.1 shows the functional entities involved in sending SS Notifications. The architecture is applicable to the third phase of CAMEL or higher. Figure 8.1: Functional architecture for support of SS Notifications HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription regarding SS CSI. The SS CSI is sent to the VLR at Location Update, on Data Restoration or if the SS CSI is updated by administrative action. When processing an invocation of the CCBS supplementary service, the HLR shall send a notification of the invocation of the supplementary service to the gsmSCF if required by the SS CSI. MSC: When processing an invocation of any of the supplementary services ECT, CD and MPTY, the MSC may receive an SS CSI from the VLR, indicating that a notification of the invocation of the supplementary service shall be sent to the gsmSCF. VLR: The VLR stores the SS CSI as a part of the subscriber data for subscribers roaming in the VLR area. gsmSCF: The gsmSCF receives the SS Invocation Notification from the MSC or HLR. 8.1.2 Interfaces defined for SS Notifications This subclause describes the different interfaces applicable to SS Notifications. It specifies on a high level the functions specific to SS Notifications. 8.1.2.1 MSC - gsmSCF interface This interface is used by the MSC to send supplementary service invocation notifications to the gsmSCF. The SS invocations that can be notified to the gsmSCF via this interface are Call Deflection (CD), Explicit Call Transfer (ECT) and Multi Party (MPTY). 8.1.2.2 HLR - gsmSCF interface This interface is used by the HLR to send supplementary service invocation notifications to the gsmSCF. The SS invocation that can be notified to the gsmSCF via this interface is Call Completion to Busy Subscriber (CCBS). 8.1.2.3 VLR - MSC interface This interface is used by the VLR to transfer SS CSI to the MSC. 8.1.2.4 HLR-VLR interface This interface is used by the HLR to send the SS CSI to the VLR or to remove SS CSI from the VLR. 8.2 Description of CAMEL Subscriber Data 8.2.1 Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI) This subclause defines the contents of the Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI). 8.2.1.1 Notification criteria This data indicates for which supplementary services notifications shall be sent. The supplementary services which may be indicated are ECT, CD, CCBS and MPTY. 8.2.1.2 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 8.2.1.3 CSI state The CSI state indicates whether the SS CSI is active or not. 8.2.1.4 Notification flag The notification flag indicates whether the change of the SS CSI shall trigger Notification on Change of Subscriber Data or not. 8.2.2 gsmSCF address list for CSI The gsmSCF address list indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 8.3 Procedures for CAMEL 8.3.1 Handling of Supplementary Service Invocation Notification At the invocation of any of the services ECT, CD and MPTY the VLR checks whether the criteria for sending a notification are fulfilled, i.e. whether the subscriber is provisioned with the SS CSI and the particular invoked supplementary service is marked in the SS CSI. If this is the case a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS CSI. The processing of the particular SS invocation is not suspended. If the notification criteria are not fulfilled the processing of the particular supplementary service continues unchanged and no notification is sent. The sending of the notification is independent of call related CAMEL processing, i.e. processing indicated by O/D/T/VT CSI. On invocation of ECT, the VLR shall include the SS CSI in the Invoke ECT response message (see Process MAF027 in 3GPP TSÊ23.091Ê[25]) to the MSC if applicable for ECT. On invocation of MPTY, the VLR shall include the SS CSI in the Process MPTY message (see Process MPTY_MAF026 in 3GPP TSÊ23.084Ê[21]) to the MSC if applicable for MPTY. On invocation of CD, the VLR shall include the SS CSI in the Send Info For Incoming Call ack information flow to the MSC if applicable to CD (see 3GPP TSÊ23.072Ê[16]). When a subscriber activates a CCBS request, the HLR checks whether the criteria for sending a notification are fulfilled, i.e. whether - The subscriber is provisioned with an active SS CSI, and - CCBS is marked in the SS CSI. If the criteria are fulfilled, a notification is immediately sent to the gsmSCF given by the gsmSCF address contained in the SS CSI and the processing of the CCBS request continues. Whenever the state of the CCBS request changes (see 3GPP TSÊ23.093Ê[26]), an additional notification is immediately sent to the gsmSCF and the processing of the CCBS request continues. If the criteria are not fulfilled, the processing of the CCBS request continues unchanged and no notifications are sent. At the invocation of the CCBS supplementary service, the HLR checks whether the criteria for sending a notification are fulfilled, i.e. whether the subscriber is provisioned with the SS CSI and the particular invoked supplementary service is marked in the SS CSI. If this is the case, a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS CSI. The processing of the SS invocation is not suspended. If the notification criteria are not fulfilled the processing of the particular supplementary service continues unchanged and no notification are sent. 8.4 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for notification of Supplementary Service invocation. Each Information Element (IE) is marked as Mandatory (M), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.002Ê[34]. 8.4.1 MSC to gsmSCF information flows 8.4.1.1 SS Invocation Notification 8.4.1.1.1 Description This IF is generated by the MSC when it shall notify the gsmSCF of a supplementary service invocation. 8.4.1.1.2 Information Elements Information element name Status Description Notification Event M This IE indicates the supplementary service invocation, resulting in the SS Invocation Notification IF. Only the following supplementary services are allowed: Explicit Call Transfer, Call Deflection, Multi Party. Notification Event Specific Information S In the case of ECT, the sending entity shall include the called party for each call originated by the subscriber and relevant to the ECT invocation. Note: the subscriber may have originated zero, one or two calls relevant to the ECT service. In the case of CD, the deflected to number shall be included in this IE. In the case of MPTY, this IE shall be omitted. IMSI M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. MSISDN M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. 8.4.2 HLR to VLR information flows 8.4.2.1 Delete Subscriber Data 8.4.2.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from a VLR. Ii is specified in 3GPP TSÊ29.002Ê[34]. 8.4.2.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements for SS Notifications: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in the VLR. Specific CSI Withdraw O This IE is used to indicate that only SS CSI shall be deleted from the VLR. This IE should not be present when CAMEL Subscription Info Withdraw is present. 8.4.2.2 Insert Subscriber Data 8.4.2.2.1 Description This IF is used by an HLR to update a VLR with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 8.4.2.2.2 Information Elements The Insert Subscriber Data contains the following CAMEL specific information element for SS Notifications: Information element name Status Description SS CSI O This IE is described in subclauseÊ8.2.1. This IE identifies the subscriber as having supplementary service invocation notification services. It contains the Notification Criteria and gsmSCFAddress. When SS CSI is sent to the VLR, it shall not contain a marking for CCBS."
"8.4.3 HLR to gsmSCF information flows 8.4.3.1 SS Invocation Notification This IF is generated by the HLR when it shall notify the gsmSCF of a supplementary service invocation. 8.4.3.1.2 Information Elements Information element name Status Description Notification Event M This IE indicates the supplementary service invocation, resulting in the SS Invocation Notification IF. Only the following supplementary services are allowed: Completion of Calls to Busy Subscriber IMSI M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. MSISDN M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. B-Number M This IE indicates the destination address of the CCBS request. CCBS Request State M This IE identifies the current state of the CCBS request. It can be one of: - Request; - Recall; - Active; - Completed; - Suspended; - Frozen; - Deleted. 8.4.4 VLR to MSC information flows 8.4.4.1 Invoke SS result 8.4.4.1.1 Description This IF is used by the VLR to send SS CSI to the MSC. This IF is specified in 3GPP TSÊ29.002Ê[34]. 8.4.4.1.2 Information Elements The Invoke SS result contains the following CAMEL specific information element for SS Notifications: Information element name Status Description SS CSI C This IE is included when it is available in the VLR and either ECT or MPTY has been successfully invoked and that supplementary service has been marked for notification. 8.4.4.2 Send Info For Incoming Call ack 8.4.4.2.1 Description This IF is used by the VLR to send SS CSI to the MSC. This IF is specified in 3GPP TSÊ23.018Ê[12]. 8.4.4.2.2 Information Elements The Send Info For Incoming Call ack contains the following CAMEL specific information elements for SS Notifications: Information element name Status Description SS CSI S This IE is included when it is available in the VLR and CD has been successfully invoked and that supplementary service has been marked for notification. 9 Mobility Management 9.1 Architecture 9.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture required to support Mobility Management in CAMEL. FiguresÊ9.1-1 and 9.1-2 show the functional entities involved in CAMEL support of Mobility Management. The architecture in the figureÊ9.1-1 is applicable to the third phase of CAMEL or higher and the architecture in the figureÊ9.1-2 is applicable to the fourth phase of CAMEL. Figure 9.1-1: Functional architecture for CS subscriber support of CAMEL Figure 9.1-2: Functional architecture for GPRS subscriber support of CAMEL gsmSCF: see subclauseÊ3.1. HLR: The HLR contains Mobility management CAMEL Subscription Information (M CSI) for those CS subscribers that require CAMEL control of Mobility Management events and Mobility management GPRS CAMEL Subscription Information (MG CSI) for those GPRS subscribers that require CAMEL control of Mobility Management events. M CSI is sent to the VLR during the Location Update and Restore Data procedures or when M CSI is modified in the HLR. The M CSI is deleted in the VLR with the Delete Subscriber Data procedure. MG CSI is sent to the SGSN during the GPRS Location Updating procedure or when MG CSI is modified in the HLR. The MG CSI is deleted in the SGSN with the Delete Subscriber Data procedure. MS: Mobile Station. MSC: see subclauseÊ4.1. VLR: After having completed a Mobility Management event from a CS subscriber, the VLR may find it necessary to send a notification to the gsmSCF. The content of M CSI indicates which Mobility Management events shall be reported to the gsmSCF. SGSN: After having completed a Mobility Management event from a GPRS subscriber, the SGSN may find it necessary to send a notification to the gsmSCF. The content of MG CSI indicates which Mobility Management events shall be reported to the gsmSCF. 9.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL control of Mobility Management events. It specifies on a high level the functions specific to CAMEL. 9.1.2.2 VLR - gsmSCF interface This interface is used by the VLR to send Mobility Management event notifications to the gsmSCF. When processing a mobility management event, the VLR may find it necessary to send a notification to the gsmSCF, depending on the presence of M CSI for the subscriber and the contents of M CSI. 9.1.2.3 SGSN - gsmSCF interface This interface is used by the SGSN to send Mobility Management event notifications to the gsmSCF. When processing a mobility management event, the SGSN may find it necessary to send a notification to the gsmSCF, depending on the presence of MG CSI for the subscriber and the contents of MG CSI. 9.2 Description of CAMEL Subscriber Data 9.2.1 Mobility Management CAMEL Subscription Information (M CSI) This subclause specifies the contents of the Mobility Management CAMEL Subscription Information (M CSI). 9.2.1.1 Mobility Management Triggers This data indicates which Mobility Management events shall result in a notification to the gsmSCF. One or more events may be marked per subscriber. These events are: - Location update in the same VLR service area. - Location update to another VLR service area. - IMSI attach. - MS initiated IMSI detach (explicit detach). - Network initiated IMSI detach (implicit detach). 9.2.1.2 gsmSCF address This is the address of the gsmSCF where the Mobility Management event notification shall be sent to. The gsmSCF address is in E.164 format. 9.2.1.3 Service Key The Service Key is included in the notification information flow to the gsmSCF. It indicates to the gsmSCF which Service Logic shall be applied. 9.2.1.4 CSI state The CSI state indicates whether the M CSI is active or not. 9.2.1.5 Notification flag The notification flag indicates whether the change of the M CSI shall trigger Notification on Change of Subscriber Data or not. 9.2.2 Mobility Management for GPRS CAMEL Subscription Information (MG CSI) This subclause specifies the contents of the Mobility Management for GPRS CAMEL Subscription Information (MG CSI). 9.2.2.1 Mobility Management Triggers This data indicates which Mobility Management events shall result in a notification to the gsmSCF. One or more events may be marked per subscriber. These events are: - Routeing area update of MS to a different SGSN service area (update from mew SGSN); - Routeing area update of MS to a different SGSN service area (disconnect by detach); - Routeing area update of MS within the same SGSN service area; - GPRS attach (e.g. MS switched on, successful routeing area update after network initiated transfer to ""MS not reachable for paging""); - MS-initiated GPRS detach (e.g. MS switched off); - Network-initiated GPRS detach. - Network-initiated transfer to the ""not reachable for paging"" state (the network has not received a periodic routeing area update from the MS and assumes that the MS is unreachable). 9.2.2.2 gsmSCF address This is the address of the gsmSCF where the Mobility Management event notification shall be sent to. The gsmSCF address is in E.164 format. 9.2.2.3 Service Key The Service Key is included in the notification information flow to the gsmSCF. It indicates to the gsmSCF which Service Logic shall be applied. 9.2.2.4 CSI state The CSI state indicates whether the MG CSI is active or not. 9.2.2.5 Notification flag The notification flag indicates whether the change of the MG CSI shall trigger Notification on Change of Subscriber Data or not. 9.2.3 gsmSCF address list for CSI The gsmSCF address list indicates the gsmSCF addresses to which Notification on Change of Subscriber Data shall be sent. This list is common to all CSI. 9.3 Procedures for Mobility management 9.3.1 Procedures for Mobility management for CS subscriber The different procedures for Mobility Management are shown in Figures 9.2-1 to 9.2-5. Figure 9.2-1: Location Update within a single VLR Service Area. (The VLR Service area may be in the HPLMN or in the VPLMN.); Figure 9.2-2: Location Update from one VLR Service Area to another VLR Service Area. (Both VLR Service Areas are in the HPLMN or in the same VPLMN.); Figure 9.2-3: Location Update from one PLMN to another PLMN; - update from HPLMN to VPLMN; - update from VPLMN to HPLMN; - update from one VPLMN to another VPLMN. Figure 9.2-4: IMSI Detach (in HPLMN or in VPLMN); - explicit detach (the MS has been switched off by the subscriber); - implicit detach (the network has not received a periodic paging update from the MS and assumes that the MS is switched off or unreachable). Figure 9.2-5: IMSI Attach (in HPLMN or in VPLMN); - attach (the MS has been switched on by the subscriber - subscription data is still available in the VLR, no location update is needed). Figure 9.2-1: Location Update within a single VLR Service Area Figure 9.2-2: Location Update from one VLR Service Area to another VLR Service Area Figure 9.2-3: Location Update from one PLMN to another PLMN Figure 9.2-4: IMSI Detach (implicit/explicit) Figure 9.2-5: IMSI Attach When a Mobility Management Event has taken place and the processing has been completed, then the VLR may find it necessary to send a notification to the gsmSCF. The processing of the Mobility Management event in the VLR is not suspended by the sending of the notification nor is it in any way affected by the notification. The sending of a Mobility Management notification to gsmSCF is independent of other CAMEL subscription data for a subscriber. E.g. a subscriber may have M CSI without O CSI or VT CSI. The sending of a Mobility Management event notification is subscription based. Refer to subclauseÊ9.2.1 for a description of M CSI and the different Mobility Management events that may lead to a notification to the gsmSCF. 9.3.1.1 Procedure descriptions 9.3.1.1.1 Procedure Set_Notification_Type This procedure is called from process Update_Location_VLR in 3GPP TSÊ23.012Ê[10]. It checks the information element 'Location Update Type', which the VLR receives from the MSC via MAP_UPDATE_LOCATION_AREA service. This element identifies the type of Location Update requested by the mobile station. The possible values of this parameter are specified in 3GPP TSÊ24.008Ê[30]. The type of Location Update that was requested by the mobile station determines which Mobility Management notification information flow shall be sent to the gsmSCF. The values 'Periodic Updating' and 'Reserved' shall not lead to a Mobility Management notification to the gsmSCF. Figure 9.-1a: Procedure Set_Notification_Type (sheet 1) 9.3.1.1.2 Procedure Notify_gsmSCF This procedure is called from the process 'Update_Location_Area_VLR' and process 'Detach_IMSI_VLR' in 3GPP TSÊ23.012Ê[10]. It is also called from the process 'Update_Location_VLR' in 3GPP TSÊ29.002Ê[34]. The calling process passes on the variable 'Notify' to the procedure 'Notify_gsmSCF'. This variable indicates which Mobility Management notification may be necessary to be sent to the gsmSCF. If this variable has a value NULL, then no notification shall be sent to the gsmSCF. If a notification may be necessary to be sent to the gsmSCF, then the procedure checks the presence of M CSI. - If M CSI is present and the Mobility Management event indicated in the variable 'Notify' is marked in M CSI, then a notification shall be sent to the gsmSCF. - If M CSI is not present or the Mobility Management event indicated in the variable 'Notify' is not marked in M CSI, then no notification shall be sent to the gsmSCF. Figure 9.3-1: Procedure Notify_gsmSCF (sheet 1) 9.3.2 Procedures for Mobility management for GPRS subscriber The different procedures for Mobility Management are shown in figures 9.4-1 to 9.4-5. Figure 9.4-1: Routeing Area Update within SGSN Service Area Figure 9.4-2: Routeing Area Update from one SGSN Service Area to another SGSN Service Area Figure 9.4-3: Routeing Area Update from one PLMN to another PLMN Figure 9.4-4: Attach of MS Figure 9.4-5: GPRS detach When a Mobility Management Event has taken place and the processing has been completed, then the SGSN may have to send a notification to the gsmSCF. The sending of a Mobility Management notification to gsmSCF is independent of other CAMEL subscription data for a subscriber. E.g. a subscriber may have MG CSI without GPRS CSI. The sending of a Mobility Management event notification is subscription based. Refer to subclauseÊ9.2.2 for a description of MG CSI and the different Mobility Management events that may lead to a notification to the gsmSCF. 9.3.2.1 Procedure CAMEL_PS_Notification This procedure is called from processes in 3GPP TSÊ23.060Ê[15]. When this procedure is called, it checks the presence of MG CSI. If there is no MG CSI, then no notification is sent to the gsmSCF. Figure 9.5-1: Procedure CAMEL_PS_Notification (sheet 1) Figure 9.6-1: Procedure Set_PS_Notification_Type (sheet 1) Figure 9.7-1: Procedure Notify_PS_gsmSCF (sheet 1) 9.4 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for Mobility Management control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E), Optional (O) or not applicable (-) for each different entity involved: VLR (VLR) and SGSN (SGSN) where distinction is applicable. If the IEs in one table apply in both VLR and SGSN, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support; - The VLR shall functionally support all IEs which can be sent to it; - The SGSN shall functionally support all IEs which can be sent to it. 9.4.1 VLR or SGSN to gsmSCF information flows 9.4.1.1 Mobility Management event Notification 9.4.1.1.1 Description This IF is generated by the VLR or SGSN to notify the gsmSCF of a Mobility Management event. 9.4.1.1.2 Information Elements Information element name VLR SGSN Description Event Met M M This IE indicates the type of Mobility Management event that lead to the notification. Refer to subclauseÊ9.2.1.1 for the CS subscriber and subclauseÊ9.2.2.1 for the GPRS subscriber. Service Key M M This IE indicates the Service Logic that the gsmSCF shall apply. IMSI M M This IE identifies the mobile subscriber to whom the Mobility Event applies. Basic MSISDN M M This IE identifies the mobile subscriber to whom the Mobility Event applies. Location Information for CS subscriber C - This IE is described in a table below. This IE indicates the current location of the MS. Location Information for GPRS subscriber - C This IE indicates the current location of the MS which is equivalent to the location info SGSN IE in subclauseÊ7.6.1.2. Supported CAMEL Phases M M This IE indicates the CAMEL Phases that are supported by the sending entity (VMSC/VLR or SGSN) in which the MS is registered after the mobility management event. Offered CAMEL4 Functionalities M - This IE is described in subclause 4.6.1.8. It indicates the CAMEL phaseÊ4 functionalities offered by the VMSC/VLR. Location Information for CS subscriber is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number M See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - Not applicable Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18]. User CSG Information C See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E See 3GPP TSÊ23.018Ê[12]. 9.4.2 SGSN to HLR information flows 9.4.2.1 Update GPRS Location See subclauseÊ6.6.4.2. 9.4.3 VLR to HLR information flows 9.4.3.1 Update Location See subclauseÊ4.6.8.3. 9.4.3.2 Restore Data See subclauseÊ4.6.8.4. 9.4.4 HLR to VLR or SGSN information flows 9.4.4.1 Delete Subscriber Data 9.4.4.1.1 Description This IF is used by an HLR to delete CAMEL subscription data from a VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 9.4.4.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements for Mobility Management: Information element name VLR SGSN Description CAMEL Subscription Info Withdraw O O This IE identifies that all CSIs shall be deleted from the subscriber data in VLR or SGSN. Specific CSI Withdraw O O This IE is used to indicate that only M CSI or MG CSI shall be deleted from the VLR or SGSN respectively. It should not be present when CAMEL Subscription Info Withdraw is present. 9.4.4.2 Insert Subscriber Data 9.4.4.2.1 Description This IF is used by an HLR to update a VLR or SGSN with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 9.4.4.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information elements for Mobility Management: Information element name VLR SGSN Description M CSI O - This IE identifies the CS subscriber as having mobility management notification services. It contains the events that shall be reported, the gsmSCF Address and the Service Key. MG CSI - O This IE identifies the GPRS subscriber as having mobility management notification services. It contains the events that shall be reported, the gsmSCF Address and the Service Key. M CSI contains the following information elements: Information element name Status Description GsmSCF Address M This IE is described in subclauseÊ9.2.1. Service Key M This IE is described in subclauseÊ9.2.1. Mobility Management Triggers M This IE indicates which Mobility Management events shall be reported to the gsmSCF. It shall contain one or more of the following elements: - Location update in the same VLR service area - Location update to another VLR service area - IMSI attach - MS initiated IMSI detach (explicit detach) - Network initiated IMSI detach (implicit detach) MG CSI contains the following information elements: Information element name Status Description GsmSCF Address M This IE is described in subclauseÊ9.2.2. Service Key M This IE is described in subclauseÊ9.2.2. Mobility Management Triggers M This IE is described in subclauseÊ9.2.2. 10 Control and interrogation of subscription data Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 10.1 Architecture 10.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture required to support control and interrogation of subscription data. FigureÊ10.1 shows the functional entities involved in CAMEL support of control and interrogation of subscription data. Figure 10.1: Functional architecture for support of control and interrogation of subscription data gsmSCF: see subclauseÊ3.1. HLR: The HLR may provide an interface to the gsmSCF for the Any Time Subscription Interrogation and Any Time Modification procedures. The gsmSCF may provide an interface to the HLR for the Notify Subscriber Data Change procedure. 10.1.2 Interfaces defined for CAMEL This subclause describes the interface applicable to CAMEL control of subscription data. It specifies on a high level the functions specific to CAMEL. 10.1.2.1 gsmSCF - HLR This interface is used by the gsmSCF to interrogate or modify information in the HLR. As a network operator option, the HLR may refuse to provide or modify the information requested by the gsmSCF. This interface is also used by the HLR to notify the gsmSCF of a change of subscriber data. 10.2 Procedures for CAMEL 10.2.1 Any Time Subscription Interrogation Handling of Any Time Interrogation for Subscription Information Retrieval involves the following process: - CAMEL_ATSI_HLR. If an OSS needs the Subscription Information, the gsmSCF initiates a transaction to the HLR by sending an Any Time Subscription Interrogation Request. Figure 10.2-1: Process CAMEL_ATSI_HLR (sheet 1) Figure 10.2-2: Process CAMEL_ATSI_HLR (sheet 2) 10.2.2 Any Time Modification Handling of Any Time Modification involves the following process: - CAMEL_ATM_HLR. The following procedures are involved: - ATM_Modify_Data This procedure checks which data shall be modified and calls the appropriate data modification procedure. - ATM_Modify_CSI_Data If the CSI indicated in the ATM request is not available in the HLR, then an error is returned. Otherwise, the CSI state and/or Notification-to-CSE flag are set as instructed with the ATM request. - ATM_Modify_CF_Data When only the SS-code and (optionally) a Basic Service code are present in the ATM request, then all Call Forwarding data belonging to this SS code and basic service code is erased, the associated notificationToCSE flag is unchanged and the SS-Status is amended according to the state transition model defined in 3GPP TSÊ23.082Ê[20]. Otherwise, the behaviour is as follows: - If a valid SS-status (i.e., the content of the SS-status parameter takes one of the values defined in the State Transition Model for the corresponding Call Forwarding supplementary service, as specified in 3GPP TSÊ23.082Ê[20]) is present in the ATM request, then an SS state transition is performed. - If a valid FTN, FTN sub address or No Reply Condition Time is present in the ATM request, then the indicated variable is modified. - Before modification of CF data (SS state changed to 'registered', insert or change of FTN), the interaction checks between CF and ODB and between CF and CB shall be performed as described in 3GPP TSÊ23.015Ê[11] and TSÊ23.082Ê[20] respectively. The CF data shall only be modified if the changed new CF data does not conflict with the existing ODB or CB entries. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - If the modification is partially successful (e.g. succeeds for one Basic Service but fails for another Basic Service), then the operation is partially accepted by the HLR. The accepted changes are made in the HLR and the changed data is sent in the ATM acknowledgement. - ATM_Modify_CB_Data When only the SS-code and (optionally) a Basic Service code are present in the ATM request, then all Call Barring belonging to this SS code and basic service code is deactivated, the associated notificationToCSE flag is unchanged and the SS-Status is amended according to the state transition model defined in 3GPP TSÊ23.088Ê[23]. Otherwise, the behaviour is as follows: - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for the corresponding Call Barring supplementary service, as specified in 3GPP TSÊ23.088Ê[23]) is present in the ATM request, then an SS state transition is performed. - Before modification of CB data (SS state), the interaction checks between CF and CB shall be performed as described in 3GPP TSÊ23.088Ê[23]. The CB data shall only be modified if the changed new CB data does not conflict with the existing CF entries. - If a valid Password or 'Wrong password attempt counter' is present in the ATM request, then the indicated variable is modified. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_ODB_Data - If ODB data is not present in the ATM request, then it is assumed that the ODB data is not modified. When present, the modification is done by overwriting the existing ODB data. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - If the modification is partially successful (e.g. succeeds for one Basic Service but fails for another Basic Service), then the operation is partially accepted by the HLR. The accepted changes are made in the HLR and the changed data is sent in the ATM acknowledgement. - ATM_Modify_IP-SM-GW_Data - If Modification Instruction is ""activate"", the IP-SM-GW address is stored if not already pre-configured in the HLR and the process Subscriber_Present_HLR is invoked (see 3GPP TSÊ23.012Ê[10]). - If Modification Instruction is ""deactivate"" and there is no IP-SM-GW address pre-configured in the HLR, the stored IP-SM-GW address is deleted. - ATM_Modify_CW_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Call Waiting, as specified in 3GPP TSÊ23.083Ê[48]) is present in the ATM request, then the Call Waiting state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CH_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Call Hold, as specified in 3GPP TSÊ23.083Ê[48]) is present in the ATM request, then the Call Hold state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_ECT_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Explicit Call Transfer, as specified in 3GPP TSÊ23.091Ê[25]) is present in the ATM request, then the Explicit Call Transfer state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CLIP_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for CLIP, as specified in 3GPP TSÊ23.081Ê[47]) is present in the ATM request, then the Calling Line Identification Presentation state is changed accordingly, - If the Override Category is present, the Override Category is changed accordingly. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CLIR_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for CLIR, as specified in 3GPP TS 23.081Ê[47]) is present in the ATM request, then the Calling Line Identification Restriction state is changed accordingly, - If the Override Category is present, the CLI Restriction Option is changed accordingly. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. After having executed the Any Time Modification instruction from the gsmSCF, the HLR calls the procedure CAMEL_NSDC_HLR, which sends notifications to gsmSCF(s), if required. Figure 10.3-1: Process CAMEL_ATM_HLR (sheet 1) Figure 10.4-1: Procedure ATM_Modify_Data (sheet 1) Figure 10.4-2: Procedure ATM_Modify_Data (sheet 2) Figure 10.5-1: Procedure ATM_Modify_CSI_Data (sheet 1) Figure 10.6-1: Procedure ATM_Modify_CF_Data (sheet 1) Figure 10.6-2: Procedure ATM_Modify_CF_Data (sheet 2) Figure 10.7-1: Procedure ATM_Modify_CB_Data (sheet 1) Figure 10.7-2: Procedure ATM_Modify_CB_Data (sheet 2) Figure 10.8-1: Procedure ATM_Modify_ODB_Data (sheet 1) Figure 10.9-1: Procedure ATM_Modify_IP-SM-GW_Data (sheet 1) Figure 10.10-1: Procedure ATM_Modify_CH_Data (sheet 1) Figure 10.11-1: Procedure ATM_Modify_CW_Data (sheet 1) Figure 10.12-1: Procedure ATM_Modify_ECT_Data (sheet 1) Figure 10.13-1: Procedure ATM_Modify_CLIP_Data (sheet 1) Figure 10.14-1: Procedure ATM_Modify_CLIR_Data (sheet 1) 10.2.3 Notify Subscriber Data Change Changes of CSI, Call Forwarding data, Call Barring data, Call Waiting data, Call Hold data, Explicit Call transfer data, Calling line Identification Presentation data, Calling line Identification Restriction data or ODB data shall be notified only if the corresponding data is marked with the Notification-to-CSE flag. The HLR maintains a list of gsmSCF address(es) for Call Forwarding Data, Call Barring Data, ODB, Call Waiting data, Call Hold data, Explicit Call transfer data, Calling line Identification Presentation data, Calling line Identification Restriction data and CSI. When any of these items has been modified, a notification shall be sent to each gsmSCF in the corresponding list. The sending of a notification to the gsmSCF may be triggered by the following processes: - subscriber data change by administrative procedure; - subscriber data changed by subscriber; - subscriber data changed by Any Time Modification request from gsmSCF; - subscriber data changed due to a change of other subscriber data; - subscriber data change due to Location Update. When a change of subscriber data is requested by Any Time Modification, Any Time Modification acknowlegement is returned to the requesting gsmSCF confirming the status of the altered data. Separate Notifications of subscriber data change shall also be returned to the requesting gsmSCF for each other piece of altered data, but these shall not contain the requested change. Each gsmSCF shall be notified only once. Multiple occurrence of gsmSCF Address in these lists shall not lead to multiple notification. Handling of Notify Subscriber Data Change involves the following procedure: - CAMEL_NSDC_HLR. If a change of subscriber data needs to be notified to the gsmSCF, then the HLR initiates a transaction to the gsmSCF by sending Notify Subscriber Data Change information flow. Figure 10.9-1: Procedure CAMEL_NSDC_HLR (sheet 1) 10.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for control and interrogation of subscription data. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF and the IP-SM-GW may silently discard any IE which it does not functionally support. - The HLR shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 10.3.1 gsmSCF to HLR information flows 10.3.1.1 Any Time Modification Request 10.3.1.1.1 Description This IF is used to modify information in the HLR at any time. 10.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN Modification Request For Call Forwarding SS Data E This IE is described in a table below. This IE indicates the data of Call Forwarding data to be modified. Modification Request For Call Barring SS Data E This IE is described in a table below. This IE indicates the data of call barring data to be modified. Modification Request For Operator Determined Barring Data E This IE is described in a table below. This IE indicates the data of operator determined barring data to be used. Modification Request For CAMEL Subscription Information E This IE is described in a table below. This IE indicates the Modification Request for CAMEL Subscription Information. Modification Request For Call Waiting SS Data E This IE is described in a table below. This IE indicates the data of Call Waiting data to be modified. Modification Request For Call Hold SS Data E This IE is described in a table below. This IE indicates the data of Call Hold data to be modified. Modification Request For Calling Line Identification Presentation SS Data E This IE is described in a table below. This IE indicates the data of Calling Line Identification Presentation data to be modified. Modification Request For Calling Line Identification Restriction SS Data E This IE is described in a table below. This IE indicates the data of Calling Line Identification Restriction data to be modified. Modification Request For Explicit Call Transfer SS Data E This IE is described in a table below. This IE indicates the data of Explicit Call Transfer data to be modified. Modification Request For Call Forwarding SS Data contains the following information elements: Information element name Status Description SS Code M This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Modification acknowledgement IF, only the following supplementary service codes are allowed for this IE; - call forwarding unconditional; - call forwarding on mobile subscriber busy; - call forwarding on no reply; - call forwarding on mobile subscriber not reachable. Basic Service O See 3GPP TSÊ29.002Ê[34]. SS Status O See 3GPP TSÊ23.011Ê[9]. Provisioning and withdrawal are not allowed for the gsmSCF. Forwarded-to Number O See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress O See 3GPP TSÊ29.002Ê[34]. No Reply Condition Time O See 3GPP TSÊ23.082Ê[20]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Barring SS Data contains the following information elements: Information element name Status Description SS Code M This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Modification acknowledgement IF, only the following supplementary service codes are allowed for this IE; - barring of all outgoing calls; - barring of outgoing international calls; - barring of outgoing international calls except those directed to the home PLMN; - barring of all incoming calls; - barring of incoming calls when roaming outside home PLMN Country. Basic Service O See 3GPP TSÊ29.002Ê[34]. SS Status O See 3GPP TS 23.011Ê[9]. Provisioning and withdrawal are not allowed for the gsmSCF. Password O See 3GPP TSÊ23.011Ê[9]. Wrong password attempts counter O See 3GPP TSÊ23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Operator Determined Barring Data contains the following information elements: Information element name Status Description ODB data O This IE contains ODB General Data and ODB HPLMN Specific Data to be imposed by this IF. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For CAMEL Subscription Information contains the following information elements: Information element name Status Description Requested CSI M This IE indicates which CSI shall be modified. Only one CSI may be changed in one ATM Request. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modify CSI State O This IE contains an instruction to activate or de-activate the CSI. Modification Request For Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Hold Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Waiting Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Override Category O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. CLI Restriction Option O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. 10.3.1.2 Any Time Subscription Interrogation Request 10.3.1.2.1 Description This IF is used to request subscription information from the HLR at any time. 10.3.1.2.2 Information Elements Information element name Status Description GsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of subscriber information being requested: This shall consist of one or more of the following list: - supplementary service; this information is described in a table below, - Operator Determined Barring; - CAMEL Subscription Information; this information is described in a table below, - supported CAMEL phases in VLR; - supported CAMEL phases in SGSN; - MSISDNs and Basic Service Codes associated with the Subscriber Identity. - CSG Subscription Data, see 3GPP TS 29.002Ê[34]; - Call Waiting SS Data see 3GPP TS 29.002[34]; - Call Hold SS Data see 3GPP TS 29.002[34]; - Explicit Call Transfer Data see 3GPP TS 29.002[34]; - Calling Line Identification Presentattion Data see 3GPP TS 29.002[34]; - Calling Line Identification Restriction Data see 3GPP TS 29.002[34]. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN."
"Supplementary service contains the following information elements: Information element name Status Description SS Code M This IE indicates a supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Subscription Interrogation acknowledgement IF, only the following supplementary service codes are allowed for this IE; - call forwarding unconditional; - call forwarding on mobile subscriber busy; - call forwarding on no reply; - call forwarding on mobile subscriber not reachable; - barring of all outgoing calls; - barring of outgoing international calls; - barring of outgoing international calls except those directed to the home PLMN; - barring of all incoming calls; - barring of incoming calls when roaming outside home PLMN Country. Basic Service O See 3GPP TSÊ29.002Ê[34]. CAMEL subscription information shall contain one of the following information elements: Information element name Status Description CAMEL Subscription Info S,E This IE indicates which CAMEL Subscription Information is requested. It shall be one of the following elements: O CSI/T CSI/VT CSI/TIF CSI/GPRS CSI/MO SMS CSI/SS CSI/M CSI/D CSI. Additional Requested CAMEL Subscription Info S,E This IE indicates which CAMEL Subscription Information is requested. It shall be one of the following elements: MT SMS CSI/ MG CSI. 10.3.1.3 Notify Subscriber Data Change response 10.3.1.3.1 Description This IF is used by the gsmSCF to respond to the HLR of the change of subscriber data notify. 10.3.1.3.2 Information Elements This IF contains no information elements. 10.3.2 HLR to gsmSCF information flows 10.3.2.1 Any Time Modification ack 10.3.2.1.1 Description This IF is used by the HLR to provide the modified information to the gsmSCF. 10.3.2.1.2 Information Elements Information element name Status Description Call Forwarding SS Data S This IE is described in a table below. It shall be present if it was modified. Call Barring SS Data S This IE is described in a table below. It shall be present if it was modified. Operator Determined Barring Information S This IE is described in a table below. It shall be present if it was modified. CAMEL Subscription Information S This IE is described in a table below. It shall be present if it was modified. Call Waiting SS Data S This IE is described in a table below. It shall be present if it was modified. Call Hold SS Data S This IE is described in a table below. It shall be present if it was modified. Calling Line Identification Presentation SS Data S This IE is described in a table below. It shall be present if it was modified. Calling Line Identification Restriction SS Data S This IE is described in a table below. It shall be present if it was modified. Explicit Call Transfer SS Data S This IE is described in a table below. It shall be present if it was modified. Call Forwarding SS Data contains the following information elements: Information element name Status Description SS Code S This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Only the SS code for which the modification applies is sent. Forwarding Feature List S This IE is described in a table below. If a Forwarding Feature List item is modified then all applicable fields within the item shall be sent. All modified Forwarding Feature List items shall be returned. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. The IE shall be sent if it was modified. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Timer C See 3GPP TSÊ23.082Ê[20]. Call Barring SS Data contains the following information elements: Information element name Status Description SS Code S This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Only the SS code for which the modification applies is sent. Call Barring Feature List S This IE is described in a table below. If a Call Barring Feature List item is modified then all applicable fields within the item shall be sent. All modified Call Barring Feature List items shall be returned. Password S See 3GPP TSÊ23.011Ê[9]. The IE shall be sent if it was modified. Wrong Password Attempts Counter S See 3GPP TSÊ23.011Ê[9]. The IE shall be sent if it was modified. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. The IE shall be sent if it was modified. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Information contains the following information elements: Information element name Status Description ODB Data C See subclauseÊ10.3.2.3 Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI S See subclauseÊ4.3.1. It shall be present if it was modified. D CSI S See subclauseÊ4.3.2. It shall be present if it was modified. T CSI S See subclauseÊ4.3.5. It shall be present if it was modified. VT CSI S See subclauseÊ4.3.6. It shall be present if it was modified. TIF CSI S See subclauseÊ4.3.4. It shall be present if it was modified. GPRS CSI S See subclauseÊ6.3.1. It shall be present if it was modified. MO SMS CSI S See subclauseÊ7.3.1. It shall be present if it was modified. MT SMS CSI S See subclauseÊ7.3.2. It shall be present if it was modified. SS CSI S See subclauseÊ8.2.1. It shall be present if it was modified. M CSI S See subclauseÊ9.2.1. It shall be present if it was modified. MG CSI S See subclauseÊ9.2.2. It shall be present if it was modified. Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. The IE shall be sent if it was modified. Call Hold Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. The IE shall be sent if it was modified. Call Waiting Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. The IE shall be sent if it was modified. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Override Category S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. The IE shall be sent if it was modified. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified CLI Restriction Option S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Restriction SS data. The IE shall be sent if it was modified. 10.3.2.2 Any Time Subscription Interrogation ack 10.3.2.2.1 Description This IF is used by the HLR to provide the requested subscription information to the gsmSCF. 10.3.2.2.2 Information Elements Information element name Status Description Call Forwarding SS Data C This IE is described in a table below. Call Barring SS Data C This IE is described in a table below. Operator Determined Barring Data C This IE is described in a table below. CAMEL Subscription Information C This IE is described in a table below. Supported CAMEL Phases In VLR C This IE indicates the CAMEL phase supported in the VLR. Offered CAMEL4 CSIs In VLR S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases In VLR"" IE indicates CAMEL phaseÊ4. Supported CAMEL Phases In SGSN C This IE indicates the CAMEL phase supported in the SGSN. Offered CAMEL4 CSIs In SGSN S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases In SGSN"" IE indicates support of CAMEL phaseÊ4. MSISDN-BS-List C This IE indicates the subscriber's MSISDN(s) and their associated Basic Service Codes. (Note) Call Waiting SS Data C This IE is described in a table below. Call Hold SS Data C This IE is described in a table below. Calling Line Identification Presentation SS Data C This IE is described in a table below. Calling Line Identification Restriction SS Data C This IE is described in a table below. Explicit Call Transfer SS Data C This IE is described in a table below. NOTE: The BASIC MSISDN is always first in the list. Call Forwarding SS Data contains the following information elements: Information element name Status Description Forwarding Feature List C This IE is described in a table below Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Time C See 3GPP TSÊ23.082Ê[20]. Call Barring SS Data contains the following information elements: Information element name Status Description Call Barring Feature List C This IE is described in a table below. Password C See 3GPP TSÊ23.011Ê[9]. Wrong Password Attempts Counter C See 3GPP TSÊ23.011Ê[9]. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Bata contains the following information elements: Information element name Status Description ODB General Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate. ODB HPLMN Specific Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI C See subclauseÊ4.3.1. D CSI C See subclauseÊ4.3.2. T CSI C See subclauseÊ4.3.5. VT CSI C See subclauseÊ4.3.6. TIF CSI C See subclauseÊ4.3.4. GPRS CSI C See subclauseÊ6.3.1. MO SMS CSI C See subclauseÊ7.3.1. MT SMS CSI C See subclauseÊ7.3.2. SS CSI C See subclauseÊ8.2.1. M CSI C See subclauseÊ9.2.1. MG CSI C See subclauseÊ9.2.2. Offered CAMEL4 CSIs in VLR contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI Offered CAMEL4 CSIs in SGSN contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancement of Provide Subscriber Information Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. Call Hold Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. Call Waiting Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Override Category C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF CLI Restriction Option C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of C Calling Line Identification Restriction SS data. 10.3.2.3 Notify Subscriber Data Change 10.3.2.3.1 Description This IF is used by the HLR to notify to the gsmSCF of the change of subscriber data. This IF is sent at each time subscriber data is changed. 10.3.2.3.2 Information Elements Information element name Status Description IMSI M The IMSI is used to identify the subscriber. MSISDN M The MSISDN is used to identify the subscriber. Call Forwarding SS Data C This IE is described in a table below. Call Barring SS Data C This IE is described in a table below. Operator Determined Barring Data C This IE is described in a table below. CAMEL Subscription Information C This IE is described in a table below. CSG Subscription Data C See 3GPP TSÊ29.002Ê[34]. It shall be present if it was modified. Call Waiting SS Data C This IE is described in a table below. Call Hold SS Data C This IE is described in a table below. Calling Line Identification Presentation SS Data C This IE is described in a table below. Calling Line Identification Restriction SS Data C This IE is described in a table below. Explicit Call Transfer SS Data C This IE is described in a table below. Call Forwarding SS data contains the following information elements: Information element name Status Description SS Code C This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Forwarding Feature List C This IE is described in a table below. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. Compound basic service codes can also be used in this IF if the subscriber has used a compound code when modifying the SS (e.g. all bearer services compound code). SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Timer C See 3GPP TSÊ23.082Ê[20]. Call Barring SS data contains the following information elements: Information element name Status Description SS Code C This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Call Barring Feature List C This IE is described in a table below. Password C See 3GPP TSÊ23.011Ê[9]. Wrong Password Attempts Counter C See 3GPP TSÊ23.011Ê[9]. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. Compound basic service codes can also be used in this IF if the subscriber has used a compound code when modifying the SS (e.g. all bearer services compound code). SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Data contains the following information elements: Information element name Status Description ODB General Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate. When the ODB general data is removed for the subscriber, this IE indicates that the set of subscribers features is empty. ODB HPLMN Specific Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. When the ODB HPLMN specific data is removed for the subscriber, this IE indicates that the set of subscribers features is empty. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI S See subclauseÊ4.3.1. It shall be present if it was modified. D CSI S See subclauseÊ4.3.2. It shall be present if it was modified. T CSI S See subclauseÊ4.3.5. It shall be present if it was modified. VT CSI S See subclauseÊ4.3.6. It shall be present if it was modified. TIF CSI S See subclauseÊ4.3.4. It shall be present if it was modified. GPRS CSI S See subclauseÊ6.3.1. It shall be present if it was modified. MO SMS CSI S See subclauseÊ7.3.1. It shall be present if it was modified. MT SMS CSI S See subclauseÊ7.3.2. It shall be present if it was modified. SS CSI S See subclauseÊ8.2.1. It shall be present if it was modified. M CSI S See subclauseÊ9.2.1. It shall be present if it was modified. MG CSI S See subclauseÊ9.2.2. It shall be present if it was modified. Specific CSI Deleted List S This IE indicates that one or more specific elements of CAMEL Subscription Information have been deleted from the HLR. It shall indicate any of the following; - O CSI (with TDP criteria for O CSI); - T CSI (with TDP criteria for T CSI); - TIF CSI; - D CSI; - VT CSI with TDP criteria for VT CSI; - GPRS CSI; - MO SMS CSI; - MT SMS CSI with TDP criteria for MT SMS CSI; - SS CSI; - M CSI; - MG CSI. This IE shall be present if CSI is/are deleted. Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. Call Hold Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. Call Waiting Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Override Category C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified CLI Restriction Option C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of C Calling Line Identification Restriction SS data. 10.3.3 IP-SM-GW to HLR information flows 10.3.3.1 Any Time Modification Request 10.3.3.1.1 Description This IF is used to register the IP-SM-GW for a subscriber in the HLR. 10.3.3.1.2 Information Elements Information element name Status Description IP-SM-GW Address M This IE indicates the address of the interrogating IP-SM-GW. The IP-SM-GW Address shall be in international E.164 format. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN Modification Request For IP-SM-GW Data E This IE is described in a table below. This IE indicates the IP-SM-GW data to be modified. Modification Request For IP-SM-GW Data contains the following information elements: Information element name Status Description Modify Registration Flag M This IE contains an instruction to register or de-register the IP-SM-GW. 10.3.4 HLR to IP-SM-GW information flows 10.3.4.1 Any Time Modification ack 10.3.4.1.1 Description This IF is used by the HLR to acknowledge the registration or deregistration for a subscriber of the IP-SM-GW to the IP-SM-GW. 10.3.4.1.2 Information Elements This IF contains no information elements. 11 Subscriber Location and State retrieval Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 11.1 Architecture 11.1.1 Functional Entities used for CAMEL This subclause describes procedures for the retrieval of subscriber location and subscriber state information. Location Services is only supported in CAMEL PhaseÊ3 and higher. 1) The gsmSCF may request location information of a mobile station from the GMLC via Location Services. The information flow of Location Services is described in 3GPP TSÊ23.271Ê[28] and 25. 305Ê[32]. FigureÊ11.1-1 indicates the functional entities involved in the procedures for the retrieval of location information via location services. 2) The gsmSCF may request any of location information, subscriber state information, IMEI and MS Class of a mobile station from the HLR. Any of location information, subscriber state information, IMEI and MS Class may be requested either from the circuit switched or the packet switched domain. If any of location information, subscriber state information, IMEI and MS Class is requested by the gsmSCF, then the HLR may retrieve this information via the Provide Subscriber Information procedure from either the MSC/VLR or the SGSN. This procedure is defined in subclauseÊ4.5.9 of the present document. The interface for the provision of subscriber location and state information between HLR and MSC/VLR is described in 3GPP TSÊ23.018Ê[12]. The interface for the provision of subscriber location and state information between HLR and SGSN is described in this chapter. FigureÊ11.1-2 indicates the functional entities involved in the procedures for the retrieval of location information and/or subscriber state information from the circuit switched or packet switched domain. Figure 11.1-1: Functional architecture for CAMEL Support of Location Services Figure 11.1-2: Functional architecture for Any Time Interrogation gsmSCF: see subclauseÊ3.1. GMLC: A functional entity that allows external LCS Clients to request real-time information about a Mobile Station. The information that can be requested from the GMLC is the location of the mobile station. HLR: see subclauseÊ4.1. MSC/VLR: see subclauseÊ4.1. SGSN: see subclauseÊ6.1.1. The SGSN stores location and state information for each subscriber. Upon request this information is provided to the HLR. The information flows between the GMLC and functional entities other than the gsmSCF, have not been indicated in the functional architecture shown in figuresÊ11.1. These information flows are outside the scope of the present document. 11.1.2 Interfaces defined for CAMEL This subclause describes the interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 11.1.2.1 gsmSCF - GMLC interface This interface is used by the gsmSCF to request information (Mobile Station location) from the GMLC at any time. 11.1.2.2 GMLC - gsmSCF interface This interface is used by the GMLC to return the requested information (Mobile Station location) to the gsmSCF as requested by the gsmSCF via the Any Time Interrogation procedure. 11.1.2.3 gsmSCF - HLR This interface is used by the gsmSCF to interrogate the HLR. As a network operator option, the HLR may refuse to provide the information requested by the gsmSCF. 11.1.2.4 HLR - gsmSCF This interface is used by the HLR to return the requested information to the gsmSCF as requested by the gsmSCF via the Any Time Interrogation procedure. 11.1.2.5 HLR - SGSN This interface is used by the HLR to request information from the SGSN. 11.1.2.5 SGSN - HLR This interface is used by the SGSN to return the requested information to the HLR. 11.2 Procedures for CAMEL 11.2.1 Location Services Handling of Any Time Interrogation to obtain Location Information involves the following process: - CAMEL_ATI_GMLC. If an OSS needs to retrieve the active location of a Mobile Station, the gsmSCF initiates a transaction to the GMLC by sending a Any Time Interrogation Request. Figure 11.2-1: Process CAMEL_ATI_GMLC (sheet 1) 11.2.2 Any Time Interrogation Handling of Any Time Interrogation to obtain Subscriber State and Location Information involves the following process: - CAMEL_ATI_HLR. If an OSS needs the Subscriber State and/or the Location Information, the gsmSCF initiates a transaction to the HLR by sending an Any_Time_Interrogation Request. Figure 11.3-1: Process CAMEL_ATI_HLR (sheet 1) 11.2.3 Provide Subscriber Information in the SGSN The provision of Subscriber State and Location Information involves the following process and procedures: - CAMEL_Provide_Subscriber_Info_SGSN; - CAMEL_Active_Info_Retrieval_SGSN; - Retrieve_GPRS_MS_Class_If_Required; - Retrieve_IMEI_If_Required. 11.2.3.1 Procedure CAMEL_Provide_Subscriber_Info_SGSN If the SGSN receives a Provide Subscriber Info request, it performs procedures to obtain the requested information. The test ""Active retrieval required"" takes the ""Yes"" exit if any one or more of current location, GPRS MS class or IMEI is indicated in the Provide Subscriber Info request. 11.2.3.2 Procedure CAMEL_Active_Info_Retrieval_SGSN If the SGSN data show that the MS is in the ""Iu Connected"" state (i.e. it has an Iu connection established), the SGSN performs the Location Reporting Control procedure (Direct report) which is defined in 3GPP TSÊ25.413Ê[33]. The test ""Report on change of service area"" takes the ""Yes"" exit if the SGSN has performed the Location Reporting Control procedure with the Request Type IE set to ""Change of service area"". If the SGSN data show that the MS is in the ""A/Gb Ready"" state (i.e. it is transferring packet data over an A/Gb access connection) then the currently stored location information is up to date, and no further action is required. Figure 11.4-1: Process CAMEL_Provide_Subscriber_Info_SGSN (sheet 1) Figure 11.5-1: Procedure CAMEL_Active_Info_Retrieval_SGSN (sheet 1) Figure 11.5-2: Procedure CAMEL_Active_Info_Retrieval_SGSN (sheet 2) Figure 11.6-1: Procedure Retrieve_GPRS_MS_Class_If_Required (sheet 1) Figure 11.7-1: Procedure Retrieve_IMEI_If_Required (sheet 1) 11.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for the retrieval of information about the location and state of a subscriber. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or not applicable (-) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The GMLC shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 11.3.1 gsmSCF to GMLC information flows 11.3.1.1 Any Time Interrogation Request 11.3.1.1.1 Description This IF is used to request information (Mobile Station location) from the GMLC. 11.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of information that is requested. It shall have the following value: - Mobile Station location Mobile Station Identity M This IE identifies the Mobile Station of which the information is requested. The identity shall be either: - IMSI, or - MSISDN 11.3.2 GMLC to gsmSCF information flows 11.3.2.1 Any Time Interrogation ack 11.3.2.1.1 Description This IF is used by the GMLC to provide the requested information to the gsmSCF. 11.3.2.1.2 Information Elements Information element name Status Description Location Information C This IE indicates the location of the Mobile Station. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Location number - Not applicable Service area ID - Not applicable Cell ID - Not applicable Geographical information C See 3GPP TSÊ23.032Ê[13]. The GMLC receives Extended Geographical Information from the MSC. The Extended Geographical Information shall be converted to the Geographical Information by the GMLC. VLR number - Not applicable Current Location Retrieved - Not applicable MSC number C The GMLC receives the MSC number from the HLR in the SendRoutingInfoForLCS MAP message. SGSN number C The GMLC receives the SGSN number from the HLR in the SendRoutingInfoForLCS MAP message. User CSG Information C See 3GPP TS 23.060Ê[15]. 11.3.3 gsmSCF to HLR information flows 11.3.3.1 Any Time Interrogation Request 11.3.3.1.1 Description This IF is used to request information (any one or more of subscriber state, subscriber location, IMEI (with software version) and MS classmark information for the requested domain) from the HLR at any time. 11.3.3.1.2 Information Elements Information element name Status Description Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN. Requested Info M This IE indicates the type of subscriber information being requested. This IE is described in a table below. gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info contains the following information elements: Information element name Status Description Location Information O This IE indicates that the Location Information is requested. Subscriber State O This IE indicates that the Subscriber State is requested. Current Location O,S This IE indicates that the Current Location is requested. This IE shall not be present if Location Information is not present in Requested Info. Location Information in EPS Supported O,S This IE indicates by its presence that Location Information in EPS is supported. This IE should be present if Location Information is present in Requested Info and Location Information in EPS is supported. This IE shall not be present if Location Information is not present in Requested Info. Requested Domain M This IE indicates for which domain the subscriber info is requested. It shall be one of the following: - circuit switched domain; - packet switched domain. IMEI (with software version) O This IE indicates that the IMEI (with software version) is requested. MS class mark information for the requested domain O This IE indicates that the MS classmark information for the indicated domain is requested. Requested Info shall contain one or more of the following information elements: - Location Information; - Subscriber State; - IMEI (with software version); - MS classmark information for the requested domain. 11.3.4 HLR to gsmSCF information flows 11.3.4.1 Any Time Interrogation ack 11.3.4.1.1 Description This IF is used by the HLR to provide the requested subscriber location and/or subscriber state information to the gsmSCF. 11.3.4.1.2 Information Elements Information element name Status Description Location Information C, E1 This IE indicates the location of the served subscriber in the MSC/VLR. It shall be present only if requested by the gsmSCF. Location Information For GPRS C, E1 This IE indicates the location of the served subscriber in the SGSN. It shall be present only if requested by the gsmSCF. Subscriber State S, E2 This IE indicates the state of the MS in the CS domain. It shall be present only if requested by the gsmSCF. The possible values of the IE are: - CAMELBusy: The VLR has indicated that the MS is engaged in a transaction for a mobile originating or terminated circuit-switched call. - NetworkDeterminedNotReachable: The HLR or VLR has indicated that the network can determine from its internal data that the MS is not reachable. - AssumedIdle: The VLR has indicated that the state of the MS is neither ""CAMELBusy"" nor ""NetworkDeterminedNotReachable"". - NotProvidedFromVLR: The VLR did not provide any information on subscriber state even though it was requested. PS Domain Subscriber State S, E2 This IE indicates the state of the MS in the PS Domain. It shall be present only if requested by the gsmSCF. The possible values of the IE are: - Detached (see subclauseÊ11.3.5.1). - CAMEL attached, MS not reachable for paging (see subclauseÊ11.3.5.1). - CAMEL attached, MS may be reachable for paging (see subclauseÊ11.3.5.1). - CAMEL PDP active, MS not reachable for paging (see subclauseÊ11.3.5.1). - CAMEL PDP active, MS may be reachable for paging (see subclauseÊ11.3.5.1). - Not provided from SGSN: The SGSN does not support Provide Subscriber Info or it did not provide any information on subscriber state even though it was requested. - NetworkDeterminedNotReachable: The HLR has indicated that the network can determine from its internal data that the MS is not reachable. PDP Context Information List C This IE indicates the PDP context information (see the table in subclauseÊ11.3.5.1) for each PDP context which is active for the MS. It shall be present if the PS domain Subscriber State has the value ""CAMEL PDP active, MS not reachable for paging"" or ""CAMEL PDP active, MS may be reachable for paging""; otherwise it shall be absent. IMEI (with software version) C This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. It shall be present only if requested by the gsmSCF. MS Classmark 2 C This IE contains the MS classmark 2, which is returned by the MS when it responds to paging in the CS domain. It shall be present only if requested by the gsmSCF. GPRS MS Class C This IE contains the MS network and radio access capabilities. It shall be present only if requested by the gsmSCF. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number C See 3GPP TSÊ23.018Ê[12]. The HLR shall include the internally stored VLR Number. Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity C This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA Id with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18]. MSC number C E.164 number which identifies the VMSC in whose area the subscriber is currently registered. See 3GPP TSÊ23.003Ê[7]. If the HLR receives the MSC number from the VLR in the Provide Subscriber Info ack IF then the HLR shall ignore the MSC number. User CSG Information C See 3GPP TS 23.060Ê[15]. E-UTRAN Cell ID C, E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C, E See 3GPP TSÊ23.018Ê[12]. Location Information for GPRS is defined in the subclause 11.3.6.1.2. The following differences apply: Information element name Status Description SGSN Number C See subclause 11.3.6.1.2. The HLR shall include the internally stored SGSN Number. 11.3.5 HLR to SGSN information flows 11.3.5.1 Provide Subscriber Info 11.3.5.1.1 Description This IF is used by the HLR to request information (subscriber state and/or location) from the SGSN at any time. 11.3.5.1.2 Information Elements This IF is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description LMSI - Not applicable. Requested Info M This IE indicates which of the following information the HLR requires: - Subscriber location; - Subscriber state; - Current location; - IMEI & Software version; - GPRS MS classmark information. 11.3.6 SGSN to HLR information flows 11.3.6.1 Provide Subscriber Info ack 11.3.6.1.1 Description This IF is used by the SGSN to provide the requested subscriber location and/or subscriber state information to the HLR. 11.3.6.1.2 Information Elements This IF is defined in 3GPP TSÊ23.018Ê[12]."
"The following differences apply: Information element name Status Description Subscriber State - Not applicable. PS domain Subscriber State C This IE indicates the status of the MS in the PS Domain. It shall be present only if requested by the HLR. The possible values of the IE are: - Detached: The SGSN has determined from its internal data that the MS is not attached to the network. - CAMEL attached, MS not reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network, but there is no PDP Context active, and the MS is not reachable for paging. - CAMEL attached, MS may be reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network, but there is no PDP Context active; the SGSN has not determined from its internal data that the MS is not reachable for paging. - CAMEL PDP active, MS not reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network there is at least on PDP context active, and the MS not reachable for paging. - CAMEL PDP active, MS may be reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network and there is at least one PDP context active; the SGSN has not determined from its internal data that the MS is not reachable for paging. PDP Context Information List S This IE is described in a table below. This IE indicates the PDP context information for each PDP context which is active for the MS. It shall be present if the PS domain Subscriber State has the value ""CAMEL PDP active, MS not reachable for paging"" or ""CAMEL PDP active MS may be reachable for paging""; otherwise it shall be absent. Location Information For GPRS C This IE is described in a table below. It indicates the location of the MS. It shall be present only if requested by the HLR. IMEI (with software version) C This IE contains the IMEI & software version of the ME in use by the served subscriber. It shall be present only if requested by the HLR. GPRS MS Class C This IE contains the MS network and radio access capabilities. It shall be present only if requested by the HLR. PDP Context Information includes the following information elements: Information element name Status Description PDP Context Identifier M Index of the PDP context. PDP State C Packet data protocol state, INACTIVE or ACTIVE. PDP Type C PDP type, e.g., PPP or IP. PDP Address C PDP address, e.g., an IP address. APN Subscribed C The APN received from the HLR. APN in Use C The APN currently used. NSAPI C Network layer Service Access Point Identifier. TI C Transaction Identifier. TEID for Gn/Gp C Tunnel Endpoint Identifier for the Gn and Gp interfaces. TEID for Iu C Tunnel Endpoint Identifier for the Iu interface. GGSN Address in Use C The IP address of the GGSN currently used. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Subscribed QoS C The quality of service profile subscribed. Requested QoS C The quality of service profile requested. Negotiated QoS C The quality of service profile negotiated. Charging ID C Charging identifier, identifies charging records generated by SGSN and GGSN. PDP Context Charging Characteristics C The charging characteristics of this PDP context, e.g., normal, prepaid, flat-rate, and/or hot billing. RNC Address In Use C The IP address of the RNC currently used. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Location Information For GPRS includes the following information elements: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E See 3GPP TSÊ23.018Ê[12]. Routeing area ID C See 3GPP TSÊ23.003Ê[7]. Geographical information C See 3GPP TSÊ23.032Ê[13]. Geodetic information C See ITU TÊQ.763Ê[43]. Age of location information C See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved C See 3GPP TSÊ23.018Ê[12]. SGSN number M Global Title of the SGSN. See 3GPP TSÊ23.060Ê[15]. Selected LSA Identity C This IE is applicable only if SoLSA is supported by the SGSN. This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18] User CSG Information C See 3GPP TS 23.060Ê[15]. 12 Subscriber Mobile Number Portability status retrieval Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 12.1 Architecture 12.1.1 Functional Entities used for CAMEL This clause describes procedures for the retrieval of subscriber Mobile Number Portability (MNP) information. The gsmSCF may request subscriber MNP information of a mobile station from the MNP Signalling Relay Function (MNP SRF). FigureÊ12.1 indicates the functional entities involved in the procedures for the retrieval of MNP information. Figure 12.1: Functional architecture for CAMEL Support of providing MNP information gsmSCF: see subclauseÊ3.1. MNPÊSRF: A functional entity that supports the mobile number portability of a mobile station, which is described in 3GPP TSÊ23.066Ê[17]. Recipient Network: Network that receives the number in the porting process. This network becomes the subscription network when the porting process is complete. See 3GPP TSÊ23.066Ê[17]. Number Range Holder Network: Network to which the number range containing the ported number has been allocated. See 3GPP TSÊ23.066Ê[17]. 12.1.2 Interfaces defined for CAMEL This subclause describes the interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 12.1.2.1 gsmSCF - MNPÊSRF interface This interface is used by the gsmSCF to request MNP information from the MNPÊSRF at any time. 12.1.2.2 MNPÊSRF - gsmSCF interface This interface is used by the MNPÊSRF to return the requested MNP information to the gsmSCF, as requested by the gsmSCF via the Any Time Interrogation procedure. 12.2 Procedures for CAMEL 12.2.1 Provide MNP Information 12.2.1.1 CAMEL_Provide_MNP_Info with ATI The process for providing MNP information with Any Time Interrogation (ATI) is the following: - CAMEL_ATI_MNP. SheetÊ1: Details of the task box ""Query Number Portability Database"" may be obtained from 3GPP TSÊ23.066Ê[17]. The task box returns an indication whether the MSISDN is known or not. Figure 12.2-1: Process CAMEL_ATI_MNP (sheet 1) 12.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for the retrieval of MNP information about a subscriber. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or not applicable (-). An 'M' IE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E' IEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. A '-'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stageÊ2 information. It is not a stageÊ3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The MNPÊSRF shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 12.3.1 gsmSCF to MNPÊSRF information flows 12.3.1.1 Any Time Interrogation Request 12.3.1.1.1 Description This IF is used by the gsmSCF to request the MNP information for subscribers from the MNPÊSRF at any time. 12.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of subscriber information that is requested. It shall have the following value: - MNP Requested Info. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be: - MSISDN. 12.3.2 MNPÊSRF to gsmSCF information flows 12.3.2.1 Any Time Interrogation ack 12.3.2.1.1 Description This IF is used by the MNPÊSRF to provide the requested MNP information for the subscriber to the gsmSCF. 12.3.2.1.2 Information Elements Information element name Status Description MNP Information Result M This IE contains the MNP information for the subscriber. It is described in a table below. MNP Information Result contains the following information: Information element name Status Description Routeing Number C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. IMSI C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. MSISDN C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. Number Portability Status C This IE shall be present, if requested by the gsmSCF. It may have one of the following values: - Not Known To Be Ported; - Own Number PortedOut; - Foreign Number Ported To Foreign Network; - Own Number Not Ported Out; - Foreign Number Ported In. Refer to 3GPP TSÊ23.066Ê[17]. Annex A (informative): Handling of Apply Charging GPRS and Apply Charging Report GPRS This Annex provides an example to demonstrate the handling of Apply Charging GPRS and Apply Charging Report GPRS. Figure A.1: Example of Handling of Apply Charging GPRS and Apply Charging Report GPRS In Figure A.1, data volumes transferred for the active PDP context are listed on the left-hand side of diagram. The following is a description of the example: a) Apply Charging GPRS threshold set to 2000, no tariff switch timer set. b) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. c) The gsmSCF sends another Apply Charging GPRS with a 2000 unit threshold. d) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. e) Another threshold (2000) is set by the gsmSCF in Apply Charging GPRS, and a tariff switch timer is set. f) After 2000 units have been transferred, Apply Charging Report GPRS is sent to the gsmSCF, as a tariff switch timer has expired since the last Apply Charging GPRS, values for volumeTariffSwitchInterval and Volume transferred since the tariff switch are sent. The gsmSCF stores the value volumeTariffSwitchInterval. g) The gsmSCF sends another Apply Charging GPRS with a 2000 unit threshold. h) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. i) Apply Charging GPRS sets a tariff switch timer, which does not expire before the next Apply Charging Report GPRS. j) A change in QoS is reported so Apply Charging Report GPRS is returned to the gsmSCF containing VolumeIfNoTariffSwitch as no tariff switch has occurred since the last Apply Charging Report GPRS. The gsmSCF should store this value if the volume of data transferred at each QoS level is to be calculated. The Tsw sent in the previous Apply Charging GPRS is stopped. In this example the tariff switch timer (Tsw) does not expire before this QoS change. If Tsw had expired the Apply Charging Report GPRS would report the volumeTariffSwitchInterval in the normal way. k) An Apply Charging GPRS is sent giving a new threshold. This threshold is service logic dependent and does not rely on any previous value sent. In the example it is 'previous threshold - volume transferred since last threshold was set'. l) The VolumeSinceLastTariffSwitch is reported in the Apply Charging Report GPRS. Note: this includes data transferred before and after the QoS change. m) Note that a tariff switch timer is set and expires. n) A final Apply Charging Report GPRS is returned containing the data volume transferred since the last tariff switch, and also the total volume transferred at the previous tariff. The calculations made by the gsmSCF in this example are: a) Total Data Volume Transferred in this example: Total of all volumeTariffSwitchInterval received + final volumeSinceLastTariff switch is (5500 + 5000) + 1500 = 12000 units of data b) Data Volume transferred for each tariff: (periods separated by Tsw in figure A.1) - 1st Tariff: taken from Apply Charging Report GPRS (signal f)) volumeTariffSwitchInterval = 5500 units of data - 2nd Tariff: taken from Apply Charging Report GPRS (signal n)) volumeTariffSwitchInterval = 5000 units of data - 3rd Tariff: taken from VolumeSinceLastTariffSwitch (signal n)) volumeTariffSwitchInterval = 1500 units of data c) Data Volume Transferred at each QoS level (One QoS Change Occurs in figure A.1) - 1st QoS level (up to signal 10): All volumeTariffSwitchIntervals + final VolumeSinceLastTariffSwitch at QoS change is 5500 + 3200 = 8700 units of data. - 2nd QoS level (from signal 10 onwards): (Value of first VolumeTariffSwitchInterval received after QoS change - VolumeNoTariffSwitch Received directly after QoS change ) + Volume transferred since this tariff switch is (5000-3200) + 1500 = 3300 units of data. Note: The volume reported to the gsmSCF in an Apply Charging Report GPRS may exceed the threshold sent in the previous Apply Charging GPRS, e.g. if the delta timer exceeds the threshold received in the subsequent Apply Charging GPRS or a data packet is transferred causing the threshold to be exceeded. Annex B (informative): Change history Date TSGÊ# TSG Doc. CR Rev Subject/Comment New 2003-12 CN#22 NP-030526 553 3 23.078-CR553 Collective CR for Rel-6 Enhanced Dialled Services 6.0.0 2003-12 CN#22 NP-0305628 645 1 Change of position armed with criteria (check criteria in MSC) 6.0.0 2003-12 CN#22 NP-030528 647 1 Enhancements for the Partial Implementation for ""Change of position procedure armed with criteria"" 6.0.0 2004-03 CN#23 NP-040137 649 1 Missing DisconnectLeg Result 6.1.0 2004-03 CN#23 NP-040137 651 1 Correction to DP description tables 6.1.0 2004-03 CN#23 NP-040094 652 EDS and DisconnectLeg interworking 6.1.0 2004-03 CN#23 NP-040090 656 DP Triggering without having armed the TDP 6.1.0 2004-03 CN#23 NP-040145 657 1 No receipt of Int_DP_Analysed_Information in state Monitoring 6.1.0 2004-03 CN#23 NP-040138 682 2 Enhancement of Event Specific Information for DP 'Change of Position' 6.1.0 2004-03 CN#23 NP-040131 686 1 GPRS ODB reporting to CAMEL SCP 6.1.0 2004-03 CN#23 NP-040095 688 2 CAMEL4 SCUDIF notification during active call for prepay 6.1.0 2004-03 CN#23 NP-040138 689 1 NoReply timer clarification for follow-on calls 6.1.0 2004-03 CN#23 NP-040096 693 1 Adding the Layer Compatibility information elements over the gsmSSF Ð gsmSCF interface 6.1.0 2004-03 CN#23 NP-040136 694 Correction to dialed services triggering for NP and NC calls 6.1.0 2004-03 CN#23 NP-040136 695 Correction to No Answer handling (CAMEL_OCH_MSC2) 6.1.0 2004-03 CN#23 NP-040136 696 Correction to handling of DFC in CS_gsmSSF 6.1.0 2004-03 CN#23 NP-040136 697 Correction to both way through parameter for ETC and CTR 6.1.0 2004-03 CN#23 NP-040136 698 Correction to forwarded leg handling with Suppress O-CSI 6.1.0 2004-03 CN#23 NP-040136 699 Correction to ORLCF handling for CAMEL calls in VMSC 6.1.0 2004-03 CN#23 NP-040136 700 Handling of DFCWA in ETC and CTR procedures 6.1.0 2004-03 CN#23 NP-040137 701 Correction to CUG handling for NP calls 6.1.0 2004-03 CN#23 NP-040137 702 Correction to CAMEL_ICA_MSC (hanging connector) 6.1.0 2004-03 CN#23 NP-040137 703 Correction to Request Report BCSM Event handling in CSA_gsmSSF 6.1.0 2004-03 CN#23 NP-040137 704 Correction to Split Leg handling in CSA_gsmSSF 6.1.0 2004-03 CN#23 NP-040137 705 Correction to CS ID Prompt & Collect 6.1.0 2004-03 CN#23 NP-040137 706 Correction to SplitLeg preconditions 6.1.0 2004-03 CN#23 NP-040138 707 Correction to Disconnect Leg preconditions 6.1.0 2004-03 CN#23 NP-040136 708 Correction to Information Location at DP O_Term_Seized 6.1.0 2004-03 CN#23 NP-040138 710 Starting of Timer Tccd after ACR on DP 'Change of Position' 6.1.0 2004-03 CN#23 NP-040137 711 Correction to Tssf timer at Apply Charging 6.1.0 2004-03 CN#23 NP-040137 712 Allowing Export_leg at DP Alerting and DP Answer 6.1.0 2004-06 CN#24 NP-040249 685 3 IP version of GGSN address for CAMEL 6.2.0 2004-06 CN#24 NP-040249 716 3 Enhancement to User Interaction 6.2.0 2004-06 CN#24 NP-040207 721 1 Correction to Tssf timer 6.2.0 2004-06 CN#24 NP-040207 722 Correction to D-CSI suppression in Continue With Argument 6.2.0 2004-06 CN#24 NP-040249 723 Correction to CS_gsmSSF for call release 6.2.0 2004-06 CN#24 NP-040249 724 Stopping charging timers after CancelÊ[All] 6.2.0 2004-06 CN#24 NP-040207 725 Correction to Move Leg pre-condition 6.2.0 2004-06 CN#24 NP-040207 726 Correction to InitialDP IF for NP leg 6.2.0 2004-06 CN#24 NP-040207 727 Correction to User Interaction before Answer 6.2.0 2004-06 CN#24 NP-040207 728 Correction to Entity Released for individual call party 6.2.0 2004-09 CN#25 NP-040405 732 2 Support of User-to-User Information (UUI) in CAMEL InitialDP operation 6.3.0 2004-09 CN#25 NP-040406 731 Correcting status in the procedure CAMEL_MT_CTR(sheet 4) 6.3.0 2004-09 CN#25 NP-040406 732 Redundantly modifying call parameter in CAMEL_MT_GMSC_Notify_CF 6.3.0 2004-09 CN#25 NP-040406 733 Correcting SDL of Process CS_gsmSSF(sheet 7) 6.3.0 2004-09 CN#25 NP-040406 735 2 Appended a note in Process CAMEL_ICA_MSC 6.3.0 2004-09 CN#25 NP-040406 737 Correction to CAP SCI for calls with multiple CAP dialogues 6.3.0 2004-09 CN#25 NP-040406 738 Correction to CAMEL_ICA_MSC1 and CAMEL_ICA_MSC2 6.3.0 2004-09 CN#25 NP-040406 739 Removal of Int_O_Exception from CAMEL_OCH_MSC2 and CAMEL_MT_GMSC_DISC5 6.3.0 2004-09 CN#25 NP-040406 740 Correction to CAMEL_Modify_CUG_Info 6.3.0 2004-09 CN#25 NP-040406 741 Correction to CAMEL_EXPORT_LEG_MSC procedure 6.3.0 2004-09 CN#25 NP-040406 743 Correction to CS_gsmSSF for EDS 6.3.0 2004-09 CN#25 NP-040406 744 Correction to CS_gsmSSF for Tcp expiry 6.3.0 2004-09 CN#25 NP-040406 745 Correction to Handle_ACR procedure for Tccd timer 6.3.0 2004-09 CN#25 NP-040406 747 Correction to any Time Interrogation 6.3.0 2004-09 CN#25 NP-040406 730 1 Editorial correction 6.3.0 2004-12 CN#26 NP-040525 748 5 Clarification on Outstanding Request Counter (ORC) handling at EDP-R or TDP-R resumption 6.4.0 2004-12 CN#26 NP-040544 749 2 Correcting SDL of Process CS_gsmSSF (sheet 62) 6.4.0 2004-12 CN#26 NP-040544 752 Correction to Change of Position handling in gsmSSF 6.4.0 2004-12 CN#26 NP-040544 753 1 Correction in Sheet 18 of Process CSA_gsmSSF 6.4.0 2004-12 CN#26 NP-040544 757 1 Warning Tone 6.4.0 2005-01 CS_gsmSSF SDL file updated 6.4.1 2005-03 CN#27 NP-050051 762 1 CR 693 not implemented 6.5.0 2005-06 CT#28 CP-050097 763 1 Correction to DP T_No_Answer 6.6.0 2005-06 CT#28 CP-050097 765 Correction to conditional triggering for SCUDIF call 6.6.0 2005-06 CT#28 CP-050083 767 1 Correction to CAMEL_MO_Dialled_Services 6.6.0 2005-06 CT#28 CP-050097 769 Correction to Outstanding Request Counter setting at IDP handling 6.6.0 2005-06 CT#28 CP-050083 772 Correction to No_Answer handling in CAMEL_ICA_MSC2 6.6.0 2005-06 CT#28 CP-050083 774 Correction to CAMEL_ICA_MSC1 and CAMEL_ICA_MSC2 for gsmSSF process checking 6.6.0 2005-06 CT#28 CP-050083 776 Correction to EDP-N handling for ICA legs in Process CS_gsmSSF 6.6.0 2005-06 CT#28 CP-050097 780 4 NoReply Timer clarification 6.6.0 2005-06 CT#28 CP-050103 764 1 CAMEL procedures for trunk originated services 7.0.0 2005-09 CT#29 CP-050312 781 1 Trunk Originated CAMEL triggering Ð SDLs (re-introduce CR770) 7.1.0 2005-09 CT#29 CP-050312 784 2 Additions and clarifications for CAMEL trunk originated services 7.1.0 2005-09 CT#29 CP-050309 786 Adding a missing reference 7.1.0 2005-09 CT#29 CP-050309 789 Correction on Outstanding Request Counter handling 7.1.0 2005-09 CT#29 CP-050309 791 Correction on T_Disconnect handling 7.1.0 2005-12 CT#30 CP-050626 0792 2 Trunk Originated CAMEL triggering Ð DTMF and CollectInfo parameters in SDL 7.2.0 2005-12 CT#30 CP-050626 0793 1 Modification Procedure CAMEL_OCH_LEG1_MSC 11(13) 7.2.0 2006-03 CT#31 CP-060082 0794 Specification of gsmSCF Address format in AnyTime request messages 7.3.0 2006-06 CT#32 CP-060311 0796 1 Addition of information related to service change 7.4.0 2006-06 CT#32 CP-060336 0797 2 List of MSISDNs and Basic Service Code for MAP Any Time Subscription Interrogation. 7.4.0 2006-06 CT#32 CP-060300 0798 1 Corrections of Process CS_gsmSSF 7.4.0 2006-09 CT#33 CP-060414 0806 1 Response to ATI for GPRS information when PSI not supported in the SGSN 7.5.0 2006-09 CT#33 CP-060414 0807 SGSN number to be included in the ATI response 7.5.0 2006-12 CT#34 CP-060695 0810 1 Optional Suppress Terminating Services Bit String in SRI 7.6.0 2007-03 CT#35 CP-070030 0813 1 Addition of SMS over IP functionality 7.7.0 2007-06 CT#36 CP-070328 0815 Mobile Termination whilst the MS is moving to another MSC 7.8.0 2007-06 CT#36 CP-070326 0816 1 Correction of IP-SM-GW update in the HSS 7.8.0 2007-06 CT#36 CP-070325 0822 2 Adding a Information Element to Continue Camel Handling Information Flow 7.8.0 2007-06 CT#36 CP-070325 0823 Mutually exclusive elements in Location Information in MSC for Initial DP SMS 7.8.0 2007-06 CT#36 CP-070325 0824 1 Correction to DTMF detection in alerting phase 7.8.0 2007-09 CT#37 CP-070540 0814 4 AC/ACR Handling 7.9.0 2007-09 CT#37 CP-070540 0826 Correction to the Send Info For Incoming Call ack Information Flow 7.9.0 2008-12 CT#42 Upgrade to Release 8 without technical change 8.0.0 2009-09 CT#45 CP-090524 0831 2 Correction on ACR and Warning Tone Play Handling of Leg 1 when successful move of a leg 8.1.0 2009-12 - - - - Update to Rel-9 version (MCC) 9.0.0 2010-03 CT#47 CP-100029 0832 1 User CSG Information for CAMEL 9.1.0 2010-09 CT#49 CP-100449 0835 1 Correction for SMS via SGs charging 9.2.0 2010-09 CT#49 CP-100467 0836 2 Addition of SS codes to the ATSI and ATM procedures 10.0.0 2011-09 CT#53 CP-110732 0837 2 Extension parameter for Release Call 11.0.0 2011-12 CT#54 CP-110780 0841 1 Provide Subscriber Information handling for UE under LTE 11.1.0 2012-03 CT#55 CP-120038 0842 2 EPS Location in IDP SMS 11.2.0 2012-06 CT#56 CP-120244 0843 - EPS location in Initial DP 11.3.0 2012-06 CT#56 CP-120244 0844 - EPS location in MAP Note MM Event 11.3.0 2012-09 CT#61 CP-130468 0845 - Clarification of allowed values for SS-status in Any Time Modification procedure 12.0.0 2015-12 CT#70 - - - Update to Rel-13 version (MCC) 13.0.0 2017-03 CT#75 - - - Update to Rel-14 version (MCC) 14.0.0 2018-06 -CT#80 - - - Update to Rel-15 version (MCC) 15.0.0 2020-07 - - - - Update to Rel-16 version (MCC) 16.0.0 2022-03 - - - - Update to Rel-17 version (MCC) 17.0.0 3GPP TS 23.078 V17.0.0 (2022-03) 750 Release 17 3GPP Network Working Group J. Sjoberg Request for Comments: 4867 M. Westerlund Obsoletes: 3267 Ericsson Category: Standards Track A. Lakaniemi Nokia Q. Xie Motorola April 2007 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ""Internet Official Protocol Standards"" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi- Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. Sjoberg, et al. Standards Track [Page 1] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Table of Contents 1. Introduction ....................................................4 2. Conventions and Acronyms ........................................4 3. Background on AMR/AMR-WB and Design Principles ..................5 3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5 3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6 3.3. Multi-Rate Encoding and Mode Adaptation ....................6 3.4. Voice Activity Detection and Discontinuous Transmission ....7 3.5. Support for Multi-Channel Session ..........................7 3.6. Unequal Bit-Error Detection and Protection .................8 3.6.1. Applying UEP and UED in an IP Network ...............8 3.7. Robustness against Packet Loss ............................10 3.7.1. Use of Forward Error Correction (FEC) ..............10 3.7.2. Use of Frame Interleaving ..........................12 3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12 3.9. AMR or AMR-WB Speech over IP Scenarios ....................13 4. AMR and AMR-WB RTP Payload Formats .............................15 4.1. RTP Header Usage ..........................................15 4.2. Payload Structure .........................................17 4.3. Bandwidth-Efficient Mode ..................................17 4.3.1. The Payload Header .................................17 4.3.2. The Payload Table of Contents ......................18 4.3.3. Speech Data ........................................20 4.3.4. Algorithm for Forming the Payload ..................21 4.3.5. Payload Examples ...................................21 4.3.5.1. Single-Channel Payload Carrying a Single Frame ..............................21 4.3.5.2. Single-Channel Payload Carrying Multiple Frames ...........................22 4.3.5.3. Multi-Channel Payload Carrying Multiple Frames ...........................23 4.4. Octet-Aligned Mode ........................................25 4.4.1. The Payload Header .................................25 4.4.2. The Payload Table of Contents and Frame CRCs .......26 4.4.2.1. Use of Frame CRC for UED over IP ..........28 4.4.3. Speech Data ........................................30 4.4.4. Methods for Forming the Payload ....................31 4.4.5. Payload Examples ...................................32 4.4.5.1. Basic Single-Channel Payload Carrying Multiple Frames ..................32 4.4.5.2. Two-Channel Payload with CRC, Interleaving, and Robust Sorting ..........32 4.5. Implementation Considerations .............................33 4.5.1. Decoding Validation ................................34 5. AMR and AMR-WB Storage Format ..................................35 5.1. Single-Channel Header .....................................35 5.2. Multi-Channel Header ......................................36 Sjoberg, et al. Standards Track [Page 2] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5.3. Speech Frames .............................................37 6. Congestion Control .............................................38 7. Security Considerations ........................................38 7.1. Confidentiality ...........................................39 7.2. Authentication and Integrity ..............................39 8. Payload Format Parameters ......................................39 8.1. AMR Media Type Registration ...............................40 8.2. AMR-WB Media Type Registration ............................44 8.3. Mapping Media Type Parameters into SDP ....................47 8.3.1. Offer-Answer Model Considerations ..................48 8.3.2. Usage of Declarative SDP ...........................50 8.3.3. Examples ...........................................51 9. IANA Considerations ............................................53 10. Changes from RFC 3267 .........................................53 11. Acknowledgements ..............................................55 12. References ....................................................55 12.1. Normative References .....................................55 12.2. Informative References ...................................56 Sjoberg, et al. Standards Track [Page 3] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 1. Introduction This document obsoletes RFC 3267 and extends that specification with offer/answer rules. See Section 10 for the changes made to this format in relation to RFC 3267. This document specifies the payload format for packetization of AMR and AMR-WB encoded speech signals into the Real-time Transport Protocol (RTP) [8]. The payload format supports transmission of multiple channels, multiple frames per payload, the use of fast codec mode adaptation, robustness against packet loss and bit errors, and interoperation with existing AMR and AMR-WB transport formats on non-IP networks, as described in Section 3. The payload format itself is specified in Section 4. A related file format is specified in Section 5 for transport of AMR and AMR-WB speech data in storage mode applications such as email. In Section 8, two separate media type registrations are provided, one for AMR and one for AMR-WB. Even though this RTP payload format definition supports the transport of both AMR and AMR-WB speech, it is important to remember that AMR and AMR-WB are two different codecs and they are always handled as different payload types in RTP. 2. Conventions and Acronyms The key words ""MUST"", ""MUST NOT"", ""REQUIRED"", ""SHALL"", ""SHALL NOT"", ""SHOULD"", ""SHOULD NOT"", ""RECOMMENDED"", ""MAY"", and ""OPTIONAL"" in this document are to be interpreted as described in RFC 2119 [5]. The following acronyms are used in this document: 3GPP - the Third Generation Partnership Project AMR - Adaptive Multi-Rate (Codec) AMR-WB - Adaptive Multi-Rate Wideband (Codec) CMR - Codec Mode Request CN - Comfort Noise DTX - Discontinuous Transmission ETSI - European Telecommunications Standards Institute FEC - Forward Error Correction SCR - Source Controlled Rate Operation SID - Silence Indicator (the frames containing only CN parameters) VAD - Voice Activity Detection UED - Unequal Error Detection UEP - Unequal Error Protection Sjoberg, et al. Standards Track [Page 4] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The term ""frame-block"" is used in this document to describe the time-synchronized set of speech frames in a multi-channel AMR or AMR-WB session. In particular, in an N-channel session, a frame- block will contain N speech frames, one from each of the channels, and all N speech frames represents exactly the same time period. The byte order used in this document is network byte order, i.e., the most significant byte first. The bit order is also the most significant bit first. This is presented in all figures as having the most significant bit leftmost on a line and with the lowest number. Some bit fields may wrap over multiple lines in which cases the bits on the first line are more significant than the bits on the next line. 3. Background on AMR/AMR-WB and Design Principles AMR and AMR-WB were originally designed for circuit-switched mobile radio systems. Due to their flexibility and robustness, they are also suitable for other real-time speech communication services over packet-switched networks such as the Internet. Because of the flexibility of these codecs, the behavior in a particular application is controlled by several parameters that select options or specify the acceptable values for a variable. These options and variables are described in general terms at appropriate points in the text of this specification as parameters to be established through out-of-band means. In Section 8, all of the parameters are specified in the form of media subtype registrations for the AMR and AMR-WB encodings. The method used to signal these parameters at session setup or to arrange prior agreement of the participants is beyond the scope of this document; however, Section 8.3 provides a mapping of the parameters into the Session Description Protocol (SDP) [11] for those applications that use SDP. 3.1. The Adaptive Multi-Rate (AMR) Speech Codec The AMR codec was originally developed and standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems. It is now chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems [1]. The AMR codec is a multi-mode codec that supports eight narrow band speech encoding modes with bit rates between 4.75 and 12.2 kbps. The sampling frequency used in AMR is 8000 Hz and the speech encoding is performed on 20 ms speech frames. Therefore, each encoded AMR speech frame represents 160 samples of the original speech. Sjoberg, et al. Standards Track [Page 5] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Among the eight AMR encoding modes, three are already separately adopted as standards of their own. Particularly, the 6.7 kbps mode is adopted as PDC-EFR [18], the 7.4 kbps mode as IS-641 codec in TDMA [17], and the 12.2 kbps mode as GSM-EFR [16]. 3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was originally developed by 3GPP to be used in GSM and 3G cellular systems. Similar to AMR, the AMR-WB codec is also a multi-mode speech codec. AMR-WB supports nine wide band speech coding modes with respective bit rates ranging from 6.6 to 23.85 kbps. The sampling frequency used in AMR-WB is 16000 Hz and the speech processing is performed on 20 ms frames. This means that each AMR-WB encoded frame represents 320 speech samples. 3.3. Multi-Rate Encoding and Mode Adaptation The multi-rate encoding (i.e., multi-mode) capability of AMR and AMR-WB is designed for preserving high speech quality under a wide range of transmission conditions. With AMR or AMR-WB, mobile radio systems are able to use available bandwidth as effectively as possible. For example, in GSM it is possible to dynamically adjust the speech encoding rate during a session so as to continuously adapt to the varying transmission conditions by dividing the fixed overall bandwidth between speech data and error protective coding. This enables the best possible trade-off between speech compression rate and error tolerance. To perform mode adaptation, the decoder (speech receiver) needs to signal the encoder (speech sender) the new mode it prefers. This mode change signal is called Codec Mode Request or CMR. Since in most sessions speech is sent in both directions between the two ends, the mode requests from the decoder at one end to the encoder at the other end are piggy-backed over the speech frames in the reverse direction. In other words, there is no out-of-band signaling needed for sending CMRs. Every AMR or AMR-WB codec implementation is required to support all the respective speech coding modes defined by the codec and must be able to handle mode switching to any of the modes at any time. However, some transport systems may impose limitations in the number of modes supported and how often the mode can change due to bandwidth Sjoberg, et al. Standards Track [Page 6] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 limitations or other constraints. For this reason, the decoder is allowed to indicate its acceptance of a particular mode or a subset of the defined modes for the session using out-of-band means. For example, the GSM radio link can only use a subset of at most four different modes in a given session. This subset can be any combination of the eight AMR modes for an AMR session or any combination of the nine AMR-WB modes for an AMR-WB session. Moreover, for better interoperability with GSM through a gateway, the decoder is allowed to use out-of-band means to set the minimum number of frames between two mode changes and to limit the mode change among neighboring modes only. Section 8 specifies a set of media type parameters that may be used to signal these mode adaptation controls at session setup. 3.4. Voice Activity Detection and Discontinuous Transmission Both codecs support voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. Hence, the codecs have the option to reduce the number of transmitted bits and packets during silence periods to a minimum. The operation of sending CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The AMR or AMR-WB frames containing CN parameters are called Silence Indicator (SID) frames. See more details about VAD and DTX functionality in [9] and [10]. 3.5. Support for Multi-Channel Session Both the RTP payload format and the storage format defined in this document support multi-channel audio content (e.g., a stereophonic speech session). Although AMR and AMR-WB codecs themselves do not support encoding of multi-channel audio content into a single bit stream, they can be used to separately encode and decode each of the individual channels. To transport (or store) the separately encoded multi-channel content, the speech frames for all channels that are framed and encoded for the same 20 ms periods are logically collected in a frame-block. At the session setup, out-of-band signaling must be used to indicate the number of channels in the session, and the order of the speech frames from different channels in each frame-block. When using SDP for signaling, the number of channels is specified in the rtpmap attribute and the order of channels carried in each frame-block is Sjoberg, et al. Standards Track [Page 7] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 implied by the number of channels as specified in Section 4.1 in [12]. 3.6. Unequal Bit-Error Detection and Protection The speech bits encoded in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. This property has been exploited in cellular systems to achieve better voice quality by using unequal error protection and detection (UEP and UED) mechanisms. The UEP/UED mechanisms focus the protection and detection of corrupted bits to the perceptually most sensitive bits in an AMR or AMR-WB frame. In particular, speech bits in an AMR or AMR-WB frame are divided into class A, B, and C, where bits in class A are the most sensitive and bits in class C the least sensitive (see Table 1 below for AMR and [4] for AMR-WB). An AMR or AMR-WB frame is only declared damaged if there are bit errors found in the most sensitive bits, i.e., the class A bits. On the other hand, it is acceptable to have some bit errors in the other bits, i.e., class B and C bits."
"Class A Total speech Index Mode bits bits ---------------------------------------- 0 AMR 4.75 42 95 1 AMR 5.15 49 103 2 AMR 5.9 55 118 3 AMR 6.7 58 134 4 AMR 7.4 61 148 5 AMR 7.95 75 159 6 AMR 10.2 65 204 7 AMR 12.2 81 244 8 AMR SID 39 39 Table 1. The number of class A bits for the AMR codec Moreover, a damaged frame is still useful for error concealment at the decoder since some of the less sensitive bits can still be used. This approach can improve the speech quality compared to discarding the damaged frame. 3.6.1. Applying UEP and UED in an IP Network To take full advantage of the bit-error robustness of the AMR and AMR-WB codec, the RTP payload format is designed to facilitate UEP/UED in an IP network. It should be noted however that the utilization of UEP and UED discussed below is OPTIONAL. Sjoberg, et al. Standards Track [Page 8] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 UEP/UED in an IP network can be achieved by detecting bit errors in class A bits and tolerating bit errors in class B/C bits of the AMR or AMR-WB frame(s) in each RTP payload. Link-layer protocols exist that do not discard packets containing bit errors, e.g., SLIP and some wireless links. With the Internet traffic pattern shifting towards a more multimedia-centric one, more link layers of such nature may emerge in the future. With transport layer support for partial checksums (for example, those supported by UDP-Lite [19]), bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links. The relationship between UDP-Lite's partial checksum at the transport layer and the checksum coverage provided by the link-layer frame is described in UDP-Lite specification [19]. There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant IP networks: a) Utilizing a partial checksum to cover the IP, transport protocol (e.g., UDP-Lite), RTP and payload headers, and the most important speech bits of the payload. The IP, UDP and RTP headers need to be protected, and it is recommended that at least all class A bits are covered by the checksum. b) Utilizing a partial checksum to only cover the IP, transport protocol, RTP and payload headers, but an AMR or AMR-WB frame CRC to cover the class A bits of each speech frame in the RTP payload. In either approach, at least part of the class B/C bits are left without error-check and thus bit error tolerance is achieved. Note, it is still important that the network designer pays attention to the class B and C residual bit error rate. Though less sensitive to errors than class A bits, class B and C bits are not insignificant, and undetected errors in these bits cause degradation in speech quality. An example of residual error rates considered acceptable for AMR in the Universal Mobile Telecommunications System (UMTS) can be found in [24] and for AMR-WB in [25]. The application interface to the UEP/UED transport protocol (e.g., UDP-Lite) may not provide any control over the link error rate, especially in a gateway scenario. Therefore, it is incumbent upon the designer of a node with a link interface of this type to choose a residual bit error rate that is low enough to support applications such as AMR encoding when transmitting packets of a UEP/UED transport protocol. Sjoberg, et al. Standards Track [Page 9] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Approach 1 is bit efficient, flexible and simple, but comes with two disadvantages, namely, a) bit errors in protected speech bits will cause the payload to be discarded, and b) when transporting multiple AMR or AMR-WB frames in a RTP payload, there is the possibility that a single bit error in protected bits will cause all the frames to be discarded. These disadvantages can be avoided, if needed, with some overhead in the form of a frame-wise CRC (Approach 2). In problem a), the CRC makes it possible to detect bit errors in class A bits and use the frame for error concealment, which gives a small improvement in speech quality. For b), when transporting multiple frames in a payload, the CRCs remove the possibility that a single bit error in a class A bit will cause all the frames to be discarded. Avoiding that improves the speech quality when transporting multiple AMR or AMR-WB frames over links subject to bit errors. The choice between the above two approaches must be made based on the available bandwidth, and the desired tolerance to bit errors. Neither solution is appropriate for all cases. Section 8 defines parameters that may be used at session setup to choose between these approaches. 3.7. Robustness against Packet Loss The payload format supports several means, including forward error correction (FEC) and frame interleaving, to increase robustness against packet loss. 3.7.1. Use of Forward Error Correction (FEC) The simple scheme of repetition of previously sent data is one way of achieving FEC. Another possible scheme which is more bandwidth efficient is to use payload-external FEC, e.g., RFC 2733 [23], which generates extra packets containing repair data. The whole payload can also be sorted in sensitivity order to support external FEC schemes using UEP. There is also a work in progress on a generic version of such a scheme [22] that can be applied to AMR or AMR-WB payload transport. With AMR or AMR-WB, it is possible to use the multi-rate capability of the codec to send redundant copies of a frame using either the same mode or another mode, e.g., one with lower bandwidth. We describe such a scheme next. Sjoberg, et al. Standards Track [Page 10] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 This involves the simple retransmission of previously transmitted frame-blocks together with the current frame-block(s). This is done by using a sliding window to group the speech frame-blocks to send in each payload. Figure 1 below shows us an example. --+--------+--------+--------+--------+--------+--------+--------+-- | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | --+--------+--------+--------+--------+--------+--------+--------+-- <---- p(n-1) ----> <----- p(n) -----> <---- p(n+1) ----> <---- p(n+2) ----> <---- p(n+3) ----> <---- p(n+4) ----> Figure 1: An example of redundant transmission In this example each frame-block is retransmitted one time in the following RTP payload packet. Here, f(n-2)..f(n+4) denotes a sequence of speech frame-blocks, and p(n-1)..p(n+4) a sequence of payload packets. The use of this approach does not require signaling at the session setup. However, a parameter for providing a maximum delay in transmitting any redundant frame is defined in Section 8. In other words, the speech sender can choose to use this scheme without consulting the receiver. This is because a packet containing redundant frames will not look different from a packet with only new frames. The receiver may receive multiple copies or versions (encoded with different modes) of a frame for a certain timestamp if no packet is lost. If multiple versions of the same speech frame are received, it is recommended that the mode with the highest rate be used by the speech decoder. This redundancy scheme provides the same functionality as the one described in RFC 2198, ""RTP Payload for Redundant Audio Data"" [27]. In most cases the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198 in addition. There are two situations in which use of RFC 2198 is indicated: if the spread in time required between the primary and redundant encodings is larger than the duration of 5 frames, the bandwidth overhead of RFC 2198 will be lower; or, if a non-AMR codec is desired for the redundant encoding, the AMR payload format won't be able to carry it. The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel, e.g., in RTCP Sjoberg, et al. Standards Track [Page 11] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 receiver reports. A sender should not base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information, e.g., radio link performance measures. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 6 for more details). 3.7.2. Use of Frame Interleaving To decrease protocol overhead, the payload design allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that packet loss can cause loss of several consecutive speech frame-blocks, which usually causes clearly audible distortion in the reconstructed speech. Interleaving of frame-blocks can improve the speech quality in such cases by distributing the consecutive losses into a series of single frame- block losses. However, interleaving and bundling several frame- blocks per payload will also increase end-to-end delay and is therefore not appropriate for all types of applications. Streaming applications will most likely be able to exploit interleaving to improve speech quality in lossy transmission conditions. This payload design supports the use of frame interleaving as an option. For the encoder (speech sender) to use frame interleaving in its outbound RTP packets for a given session, the decoder (speech receiver) needs to indicate its support via out-of-band means (see Section 8). 3.8. Bandwidth-Efficient or Octet-Aligned Mode For a given session, the payload format can be either bandwidth efficient or octet aligned, depending on the mode of operation that is established for the session via out-of-band means. In the octet-aligned format, all the fields in a payload, including payload header, table of contents entries, and speech frames themselves, are individually aligned to octet boundaries to make implementations efficient. In the bandwidth-efficient format, only the full payload is octet aligned, so fewer padding bits are added. Note, octet alignment of a field or payload means that the last octet is padded with zeroes in the least significant bits to fill the octet. Also note that this padding is separate from padding indicated by the P bit in the RTP header. Between the two operation modes, only the octet-aligned mode has the capability to use the robust sorting, interleaving, and frame CRC to make the speech transport more robust to packet loss and bit errors. Sjoberg, et al. Standards Track [Page 12] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 3.9. AMR or AMR-WB Speech over IP Scenarios The primary scenario for this payload format is IP end-to-end between two terminals, as shown in Figure 2. This payload format is expected to be useful for both conversational and streaming services. +----------+ +----------+ | | IP/UDP/RTP/AMR or | | | TERMINAL |<----------------------->| TERMINAL | | | IP/UDP/RTP/AMR-WB | | +----------+ +----------+ Figure 2: IP terminal to IP terminal scenario A conversational service puts requirements on the payload format. Low delay is one very important factor, i.e., few speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses low bandwidth links, especially as the frequency of packets will be high. For low bandwidth links, it is also an advantage to support UED, which allows a link provider to reduce delay and packet loss, or to reduce the utilization of link resources. A streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than a conversational service. This reduces the overhead from IP, UDP, and RTP headers. However, including several frame-blocks per packet makes the transmission more vulnerable to packet loss, so interleaving may be used to reduce the effect that packet loss will have on speech quality. A streaming server handling a large number of clients also needs a payload format that requires as few resources as possible when doing packetization. The octet-aligned and interleaving modes require the least amount of resources, while CRC, robust sorting, and bandwidth-efficient modes have higher demands. Another scenario is when AMR or AMR-WB encoded speech is transmitted from a non-IP system (e.g., a GSM or 3GPP UMTS network) to an IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3. Sjoberg, et al. Standards Track [Page 13] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 AMR or AMR-WB over I.366.{2,3} or +------+ +----------+ 3G Iu or | | IP/UDP/RTP/AMR or | | <------------->| GW |<---------------------->| TERMINAL | GSM Abis | | IP/UDP/RTP/AMR-WB | | etc. +------+ +----------+ | GSM/ | IP network 3GPP UMTS network | Figure 3: GW to VoIP terminal scenario In such a case, it is likely that the AMR or AMR-WB frame is packetized in a different way in the non-IP network and will need to be re-packetized into RTP at the gateway. Also, speech frames from the non-IP network may come with some UEP/UED information (e.g., a frame quality indicator) that will need to be preserved and forwarded on to the decoder along with the speech bits. This is specified in Section 4.3.2. AMR's capability to do fast mode switching is exploited in some non- IP networks to optimize speech quality. To preserve this functionality in scenarios including a gateway to an IP network, a codec mode request (CMR) field is needed. The gateway will be responsible for forwarding the CMR between the non-IP and IP parts in both directions. The IP terminal should follow the CMR forwarded by the gateway to optimize speech quality going to the non-IP decoder. The mode control algorithm in the gateway must accommodate the delay imposed by the IP network on the IP terminal's response to CMR. The IP terminal should not set the CMR (see Section 4.3.1), but the gateway can set the CMR value on frames going toward the encoder in the non-IP part to optimize speech quality from that encoder to the gateway. The gateway can alternatively set a lower CMR value, if desired, as one means to control congestion on the IP network. A third likely scenario is that IP/UDP/RTP is used as transport between two non-IP systems, i.e., IP is originated and terminated in gateways on both sides of the IP transport, as illustrated in Figure 4 below. Sjoberg, et al. Standards Track [Page 14] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 AMR or AMR-WB AMR or AMR-WB over over I.366.{2,3} or +------+ +------+ I.366.{2,3} or 3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or <------------->| GW |<------------------->| GW |<-------------> GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis etc. +------+ +------+ etc. | | GSM/ | IP network | GSM/ 3GPP UMTS network | | 3GPP UMTS network Figure 4: GW to GW scenario This scenario requires the same mechanisms for preserving UED/UEP and CMR information as in the single gateway scenario. In addition, the CMR value may be set in packets received by the gateways on the IP network side. The gateway should forward to the non-IP side a CMR value that is the minimum of three values: - the CMR value it receives on the IP side; - the CMR value it calculates based on its reception quality on the non-IP side; and - a CMR value it may choose for congestion control of transmission on the IP side. The details of the control algorithm are left to the implementation. 4. AMR and AMR-WB RTP Payload Formats The AMR and AMR-WB payload formats have identical structure, so they are specified together. The only differences are in the types of codec frames contained in the payload. The payload format consists of the RTP header, payload header, and payload data. 4.1. RTP Header Usage The format of the RTP header is specified in [8]. This payload format uses the fields of the header in a manner consistent with that specification. The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency is the same as the sampling frequency, so the timestamp unit is in samples. Sjoberg, et al. Standards Track [Page 15] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The duration of one speech frame-block is 20 ms for both AMR and AMR-WB. For AMR, the sampling frequency is 8 kHz, corresponding to 160 encoded speech samples per frame from each channel. For AMR-WB, the sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 160 for AMR and 320 for AMR-WB for each consecutive frame-block. A packet may contain multiple frame-blocks of encoded speech or comfort noise parameters. If interleaving is employed, the frame- blocks encapsulated into a payload are picked according to the interleaving rules as defined in Section 4.4.1. Otherwise, each packet covers a period of one or more contiguous 20 ms frame-block intervals. In case the data from all the channels for a particular frame-block in the period is missing (for example, at a gateway from some other transport format), it is possible to indicate that no data is present for that frame-block rather than breaking a multi-frame- block packet into two, as explained in Section 4.3.2. To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any speech frame multiple times, in exact duplicates, in different AMR rate modes, or with data present in one packet and not present in another. If multiple versions of the same speech frame are received, it is RECOMMENDED that the mode with the highest rate be used by the speech decoder. A given frame MUST NOT be encoded as speech in one packet and comfort noise parameters in another. The payload length is always made an integral number of octets by padding with zero bits if necessary. If additional padding is required to bring the payload length to a larger multiple of octets or for some other purpose, then the P bit in the RTP in the header may be set and padding appended as specified in [8]. The RTP header marker bit (M) SHALL be set to 1 if the first frame- block carried in the packet contains a speech frame which is the first in a talkspurt. For all other packets the marker bit SHALL be set to zero (M=0). The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this encoding or specify that the payload type is to be bound dynamically. Sjoberg, et al. Standards Track [Page 16] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.2. Payload Structure The complete payload consists of a payload header, a payload table of contents, and speech data representing one or more speech frame- blocks. The following diagram shows the general payload format layout: +----------------+-------------------+---------------- | payload header | table of contents | speech data ... +----------------+-------------------+---------------- Payloads containing more than one speech frame-block are called compound payloads. The following sections describe the variations taken by the payload format depending on whether the AMR session is set up to use the bandwidth-efficient mode or octet-aligned mode and any of the OPTIONAL functions for robust sorting, interleaving, and frame CRCs. Implementations SHOULD support both bandwidth-efficient and octet- aligned operation to increase interoperability. 4.3. Bandwidth-Efficient Mode 4.3.1. The Payload Header In bandwidth-efficient mode, the payload header simply consists of a 4-bit codec mode request: 0 1 2 3 +-+-+-+-+ | CMR | +-+-+-+-+ CMR (4 bits): Indicates a codec mode request sent to the speech encoder at the site of the receiver of this payload. The value of the CMR field is set to the frame type index of the corresponding speech mode being requested. The frame type index may be 0-7 for AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined in Table 1a in [4]. CMR value 15 indicates that no mode request is present, and other values are for future use. The codec mode request received in the CMR field is valid until the next codec mode request is received, i.e., a newly received CMR value corresponding to a speech mode, or NO_DATA overrides the previously received CMR value corresponding to a speech mode or NO_DATA. Therefore, if a terminal continuously wishes to receive frames in the Sjoberg, et al. Standards Track [Page 17] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 same mode X, it needs to set CMR=X for all its outbound payloads, and if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads. If receiving a payload with a CMR value that is not a speech mode or NO_DATA, the CMR MUST be ignored by the receiver. In a multi-channel session, the codec mode request SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session. An IP end-point SHOULD NOT set the codec mode request based on packet losses or other congestion indications, for several reasons: - The other end of the IP path may be a gateway to a non-IP network (such as a radio link) that needs to set the CMR field to optimize performance on that network. - Congestion on the IP network is managed by the IP sender, in this case, at the other end of the IP path. Feedback about congestion SHOULD be provided to that IP sender through RTCP or other means, and then the sender can choose to avoid congestion using the most appropriate mechanism. That may include adjusting the codec mode, but also includes adjusting the level of redundancy or number of frames per packet. The encoder SHOULD follow a received codec mode request, but MAY change to a lower-numbered mode if it so chooses, for example, to control congestion. The CMR field MUST be set to 15 for packets sent to a multicast group. The encoder in the speech sender SHOULD ignore codec mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a codec mode change is needed. The codec mode selection MAY be restricted by a session parameter to a subset of the available modes. If so, the requested mode MUST be among the signalled subset (see Section 8). If the received CMR value is outside the signalled subset of modes, it MUST be ignored. 4.3.2. The Payload Table of Contents The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame. Sjoberg, et al. Standards Track [Page 18] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 In bandwidth-efficient mode, a ToC entry takes the following format: 0 1 2 3 4 5 +-+-+-+-+-+-+ |F| FT |Q| +-+-+-+-+-+-+ F (1 bit): If set to 1, indicates that this frame is followed by another speech frame in this payload; if set to 0, indicates that this frame is the last frame in this payload. FT (4 bits): Frame type index, indicating either the AMR or AMR-WB speech coding mode or comfort noise (SID) mode of the corresponding frame carried in this payload. The value of FT is defined in Table 1a in [2] for AMR and in Table 1a in [4] for AMR-WB. FT=14 (SPEECH_LOST, only available for AMR-WB) and FT=15 (NO_DATA) are used to indicate frames that are either lost or not being transmitted in this payload, respectively. NO_DATA (FT=15) frame could mean either that no data for that frame has been produced by the speech encoder or that no data for that frame is transmitted in the current payload (i.e., valid data for that frame could be sent in either an earlier or later packet). If receiving a ToC entry with a FT value in the range 9-14 for AMR or 10-13 for AMR-WB, the whole packet SHOULD be discarded. This is to avoid the loss of data synchronization in the depacketization process, which can result in a huge degradation in speech quality. Note that packets containing only NO_DATA frames SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX in [7]. The extra comfort noise frame types specified in table 1a in [2] (i.e., GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this payload format because the standardized AMR codec is only required to implement the general AMR SID frame type and not those that are native to the incorporated encodings. Q (1 bit): Frame quality indicator. If set to 0, indicates the corresponding frame is severely damaged, and the receiver should set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD depending on the frame type (FT). Sjoberg, et al. Standards Track [Page 19] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [20], as well as other transport formats. The frame quality indicator enables damaged frames to be forwarded to the speech decoder for error concealment. This can improve the speech quality more than dropping the damaged frames. See Section 4.4.2.1 for more details. For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order as defined in Section 4.1 in [12]. When multiple frame-blocks are present in a packet in bandwidth-efficient mode, they will be placed in the packet in order of their creation time. Therefore, with N channels and K speech frame-blocks in a packet, there MUST be N*K entries in the ToC, and the first N entries will be from the first frame-block, the second N entries will be from the second frame-block, and so on. The following figure shows an example of a ToC of three entries in a single-channel session using bandwidth-efficient mode. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| FT |Q|1| FT |Q|0| FT |Q| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Below is an example of how the ToC entries will appear in the ToC of a packet carrying three consecutive frame-blocks in a session with two channels (L and R). +----+----+----+----+----+----+ | 1L | 1R | 2L | 2R | 3L | 3R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 1 Block 2 Block 3 4.3.3. Speech Data Speech data of a payload contains zero or more speech frames or comfort noise frames, as described in the ToC of the payload. Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame present in the speech data. Sjoberg, et al. Standards Track [Page 20] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Each speech frame represents 20 ms of speech encoded with the mode indicated in the FT field of the corresponding ToC entry. The length of the speech frame is implicitly defined by the mode indicated in the FT field. The order and numbering notation of the bits are as specified for Interface Format 1 (IF1) in [2] for AMR and [4] for AMR-WB. As specified there, the bits of speech frames have been rearranged in order of decreasing sensitivity, while the bits of comfort noise frames are in the order produced by the encoder. The resulting bit sequence for a frame of length K bits is denoted d(0), d(1), ..., d(K-1). 4.3.4. Algorithm for Forming the Payload The complete RTP payload in bandwidth-efficient mode is formed by packing bits from the payload header, table of contents, and speech frames in order (as defined by their corresponding ToC entries in the ToC list), and to bring the payload to octet alignment, 0 to 7 padding bits. Padding bits MUST be set to zero and MUST be ignored on reception. They are packed contiguously into octets beginning with the most significant bits of the fields and the octets. To be precise, the four-bit payload header is packed into the first octet of the payload with bit 0 of the payload header in the most significant bit of the octet. The four most significant bits (numbered 0-3) of the first ToC entry are packed into the least significant bits of the octet, ending with bit 3 in the least significant bit. Packing continues in the second octet with bit 4 of the first ToC entry in the most significant bit of the octet. If more than one frame is contained in the payload, then packing continues with the second and successive ToC entries. Bit 0 of the first data frame follows immediately after the last ToC bit, proceeding through all the bits of the frame in numerical order. Bits from any successive frames follow contiguously in numerical order for each frame and in consecutive order of the frames. If speech data is missing for one or more speech frame within the sequence, because of, for example, DTX, a ToC entry with FT set to NO_DATA SHALL be included in the ToC for each of the missing frames, but no data bits are included in the payload for the missing frame (see Section 4.3.5.2 for an example). 4.3.5. Payload Examples 4.3.5.1. Single-Channel Payload Carrying a Single Frame The following diagram shows a bandwidth-efficient AMR payload from a single-channel session carrying a single speech frame-block. Sjoberg, et al. Standards Track [Page 21] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 In the payload, no specific mode is requested (CMR=15), the speech frame is not damaged at the IP origin (Q=1), and the coding mode is AMR 7.4 kbps (FT=4). The encoded speech bits, d(0) to d(147), are arranged in descending sensitivity order according to [2]. Finally, two padding bits (P) are added to the end as padding to make the payload octet aligned. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=15|0| FT=4 |1|d(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d(147)|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.5.2. Single-Channel Payload Carrying Multiple Frames The following diagram shows a single-channel, bandwidth-efficient compound AMR-WB payload that contains four frames, of which one has no speech data. The first frame is a speech frame at 6.6 kbps mode (FT=0) that is composed of speech bits d(0) to d(131). The second frame is an AMR-WB SID frame (FT=9), consisting of bits g(0) to g(39). The third frame is a NO_DATA frame and does not carry any speech information, it is represented in the payload by its ToC entry. The fourth frame in the payload is a speech frame at 8.85 kbps mode (FT=1), it consists of speech bits h(0) to h(176). As shown below, the payload carries a mode request for the encoder on the receiver's side to change its future coding mode to AMR-WB 8.85 kbps (CMR=1). None of the frames are damaged at IP origin (Q=1). The encoded speech and SID bits, d(0) to d(131), g(0) to g(39), and h(0) to h(176), are arranged in the payload in descending sensitivity order according to [4]. (Note, no speech bits are present for the third frame.) Finally, seven zero bits are padded to the end to make the payload octet aligned. Sjoberg, et al. Standards Track [Page 22] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=1 |1| FT=0 |1|1| FT=9 |1|1| FT=15 |1|0| FT=1 |1|d(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d(131)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |g(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g(39)|h(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h(176)|P|P|P|P|P|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.5.3. Multi-Channel Payload Carrying Multiple Frames The following diagram shows a two-channel payload carrying 3 frame- blocks, i.e., the payload will contain 6 speech frames. In the payload, all speech frames contain the same mode 7.4 kbps (FT=4) and are not damaged at IP origin. The CMR is set to 15, i.e., no specific mode is requested. The two channels are defined as left (L) and right (R) in that order. The encoded speech bits is designated dXY(0).. dXY(K-1), where X = block number, Y = channel, and K is the number of speech bits for that mode. Exemplifying this, for frame-block 1 of the left channel, the encoded bits are designated as d1L(0) to d1L(147). Sjoberg, et al. Standards Track [Page 23] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4|1|0|3R FT=4|1|d1L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d1L(147)|d1R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d1R(147)|d2L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |d2L(147|d2R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d2R(147)|d3L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d3L(147)|d3R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d3R(147)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sjoberg, et al. Standards Track [Page 24] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4. Octet-Aligned Mode 4.4.1. The Payload Header In octet-aligned mode, the payload header consists of a 4-bit CMR, 4 reserved bits, and optionally, an 8-bit interleaving header, as shown below: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+- - - - - - - - | CMR |R|R|R|R| ILL | ILP | +-+-+-+-+-+-+-+-+- - - - - - - - CMR (4 bits): same as defined in Section 4.3.1. R: is a reserved bit that MUST be set to zero. All R bits MUST be ignored by the receiver. ILL (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled out-of-band for the session. ILL=L indicates to the receiver that the interleaving length is L+1, in number of frame-blocks. ILP (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled. ILP MUST take a value between 0 and ILL, inclusive, indicating the interleaving index for frame-blocks in this payload in the interleaving group. If the value of ILP is found greater than ILL, the payload SHOULD be discarded. ILL and ILP fields MUST be present in each packet in a session if interleaving is signalled for the session. Interleaving MUST be performed on a frame-block basis (i.e., NOT on a frame basis) in a multi-channel session. The following example illustrates the arrangement of speech frame- blocks in an interleaving group during an interleaving session. Here we assume ILL=L for the interleaving group that starts at speech frame-block n. We also assume that the first payload packet of the interleaving group is s, and the number of speech frame-blocks carried in each payload is N. Then we will have: Sjoberg, et al. Standards Track [Page 25] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Payload s (the first packet of this interleaving group): ILL=L, ILP=0, Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1) Payload s+1 (the second packet of this interleaving group): ILL=L, ILP=1, frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1) ... Payload s+L (the last packet of this interleaving group): ILL=L, ILP=L, frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1) The next interleaving group will start at frame-block n+N*(L+1). There will be no interleaving effect unless the number of frame- blocks per packet (N) is at least 2. Moreover, the number of frame- blocks per payload (N) and the value of ILL MUST NOT be changed inside an interleaving group. In other words, all payloads in an interleaving group MUST have the same ILL and MUST contain the same number of speech frame-blocks. The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses media type parameter ""interleaving=I"" to set the maximum number of frame-blocks allowed in an interleaving group to I."
"When performing interleaving, the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleaving group is less or equal to I, that is, N*(L+1)<=I. 4.4.2. The Payload Table of Contents and Frame CRCs The table of contents (ToC) in octet-aligned mode consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload and, optionally, a list of speech frame CRCs. That is, the ToC is as follows: +---------------------+ | list of ToC entries | +---------------------+ | list of frame CRCs | (optional) - - - - - - - - - - - Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame or frame CRC present in the payload. Sjoberg, et al. Standards Track [Page 26] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The list of ToC entries is organized in the same way as described for bandwidth-efficient mode in 4.3.2, with the following exception: when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutively in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 4.4.1. The following example shows the ToC of three consecutive packets, each carrying three frame-blocks, in an interleaved two-channel session. Here, the two channels are left (L) and right (R) with L coming before R, and the interleaving length is 3 (i.e., ILL=2). This results in the interleaving group size of 9 frame-blocks. Packet #1 --------- ILL=2, ILP=0: +----+----+----+----+----+----+ | 1L | 1R | 4L | 4R | 7L | 7R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 1 Block 4 Block 7 Packet #2 --------- ILL=2, ILP=1: +----+----+----+----+----+----+ | 2L | 2R | 5L | 5R | 8L | 8R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 2 Block 5 Block 8 Packet #3 --------- ILL=2, ILP=2: +----+----+----+----+----+----+ | 3L | 3R | 6L | 6R | 9L | 9R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 3 Block 6 Block 9 Sjoberg, et al. Standards Track [Page 27] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 A ToC entry takes the following format in octet-aligned mode: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F| FT |Q|P|P| +-+-+-+-+-+-+-+-+ F (1 bit): see definition in Section 4.3.2. FT (4 bits, unsigned integer): see definition in Section 4.3.2. Q (1 bit): see definition in Section 4.3.2. P bits: padding bits, MUST be set to zero, and MUST be ignored on reception. The list of CRCs is OPTIONAL. It only exists if the use of CRC is signalled out-of-band for the session. When present, each CRC in the list is 8 bits long and corresponds to a speech frame (NOT a frame- block) carried in the payload. Calculation and use of the CRC is specified in the next section. 4.4.2.1. Use of Frame CRC for UED over IP The general concept of UED/UEP over IP is discussed in Section 3.6. This section provides more details on how to use the frame CRC in the octet-aligned payload header together with a partial transport layer checksum to achieve UED. To achieve UED, one SHOULD use a transport layer checksum (for example, the one defined in UDP-Lite [19]) to protect the IP, transport protocol (e.g., UDP-Lite), and RTP headers, as well as the payload header and the table of contents in the payload. The frame CRC, when used, MUST be calculated only over all class A bits in the AMR or AMR-WB frame. Class B and C bits in the AMR or AMR-WB frame MUST NOT be included in the CRC calculation and SHOULD NOT be covered by the transport checksum. Note, the number of class A bits for various coding modes in AMR codec is specified as informative in [2] and is therefore copied into Table 1 in Section 3.6 to make it normative for this payload format. The number of class A bits for various coding modes in AMR-WB codec is specified as normative in Table 2 in [4], and the SID frame (FT=9) has 40 class A bits. These definitions of class A bits MUST be used for this payload format. Sjoberg, et al. Standards Track [Page 28] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 If the transport layer checksum or link layer checksum detects any errors within the protected (sensitive) part, it is assumed that the complete packet will be discarded as defined by UDP-Lite [19]. The receiver of the payload SHOULD examine the data integrity of the received class A bits by re-calculating the CRC over the received class A bits and comparing the result to the value found in the received payload header. If the two values mismatch, the receiver SHALL consider the class A bits in the receiver frame damaged and MUST clear the Q flag of the frame (i.e., set it to 0). This will subsequently cause the frame to be marked as SPEECH_BAD, if the FT of the frame is 0..7 for AMR or 0..8 for AMR-WB, or SID_BAD if the FT of the frame is 8 for AMR or 9 for AMR-WB, before it is passed to the speech decoder. See [6] and [7] more details. The following example shows an octet-aligned ToC with a CRC list for a payload containing 3 speech frames from a single-channel session (assuming none of the FTs is equal to 14 or 15): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC#2 | CRC#3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each of the CRCs takes 8 bits 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | c0| c1| c2| c3| c4| c5| c6| c7| +---+---+---+---+---+---+---+---+ (MSB) (LSB) and is calculated by the cyclic generator polynomial, C(x) = 1 + x^2 + x^3 + x^4 + x^8 where ^ is the exponentiation operator. In binary form, the polynomial appears as follows: 101110001 (MSB..LSB). The actual calculation of the CRC is made as follows: First, an 8-bit CRC register is reset to zero: 00000000. For each bit over which the CRC shall be calculated, an XOR operation is made between the rightmost (LSB) bit of the CRC register and the bit. The CRC Sjoberg, et al. Standards Track [Page 29] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 register is then right-shifted one step (each bit's significance is reduced by one), inputting a ""0"" as the leftmost bit (MSB). If the result of the XOR operation mentioned above is a ""1"", then ""10111000"" is bit-wise XOR-ed into the CRC register. This operation is repeated for each bit that the CRC should cover. In this case, the first bit would be d(0) for the speech frame for which the CRC should cover. When the last bit (e.g., d(54) for AMR 5.9 according to Table 1 in Section 3.6) has been used in this CRC calculation, the contents in CRC register should simply be copied to the corresponding field in the list of CRCs. Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm. 4.4.3. Speech Data In octet-aligned mode, speech data is carried in a similar way to that in the bandwidth-efficient mode as discussed in Section 4.3.3, with the following exceptions: - The last octet of each speech frame MUST be padded with zero bits at the end if all bits in the octet are not used. The padding bits MUST be ignored on reception. In other words, each speech frame MUST be octet-aligned. - When multiple speech frames are present in the speech data (i.e., compound payload), the speech frames are arranged either one whole frame after another as usual, or with the octets of all frames interleaved together at the octet level, depending on the media type parameters negotiated for the payload type. Since the bits within each frame are ordered with the most error-sensitive bits first, interleaving the octets collects those sensitive bits from all frames to be nearer the beginning of the packet. This is called ""robust sorting order"" which allows the application of UED (such as UDP-Lite [19]) or UEP (such as the ULP [22]) mechanisms to the payload data. The details of assembling the payload are given in the next section. The use of robust sorting order for a payload type MUST be agreed via out-of-band means. Section 8 specifies a media type parameter for this purpose. Note, robust sorting order MUST only be performed on the frame level and thus is independent of interleaving, which is at the frame-block level, as described in Section 4.4.1. In other words, robust sorting can be applied to either non-interleaved or interleaved payload types. Sjoberg, et al. Standards Track [Page 30] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4.4. Methods for Forming the Payload Two different packetization methods, namely, normal order and robust sorting order, exist for forming a payload in octet-aligned mode. In both cases, the payload header and table of contents are packed into the payload the same way; the difference is in the packing of the speech frames. The payload begins with the payload header of one octet, or two octets if frame interleaving is selected. The payload header is followed by the table of contents consisting of a list of one-octet ToC entries. If frame CRCs are to be included, they follow the table of contents with one 8-bit CRC filling each octet. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no CRC present. The speech data follows the table of contents, or the CRCs if present. For packetization in the normal order, all of the octets comprising a speech frame are appended to the payload as a unit. The speech frames are packed in the same order as their corresponding ToC entries are arranged in the ToC list, with the exception that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame. For packetization in robust sorting order, the octets of all speech frames are interleaved together at the octet level. That is, the data portion of the payload begins with the first octet of the first frame, followed by the first octet of the second frame, then the first octet of the third frame, and so on. After the first octet of the last frame has been appended, the cycle repeats with the second octet of each frame. The process continues for as many octets as are present in the longest frame. If the frames are not all the same octet length, a shorter frame is skipped once all octets in it have been appended. The order of the frames in the cycle will be sequential if frame interleaving is not in use, or according to the interleave pattern specified in the payload header if frame interleaving is in use. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame, so it is skipped in the robust sorting cycle. The UED and/or UEP is RECOMMENDED to cover at least the RTP header, payload header, table of contents, and class A bits of a sorted payload. Exactly how many octets need to be covered depends on the network and application. If CRCs are used together with robust sorting, only the RTP header, the payload header, and the ToC SHOULD be covered by UED/UEP. The means for communicating the number of octets to be covered to other layers performing UED/UEP is beyond the scope of this specification. Sjoberg, et al. Standards Track [Page 31] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4.5. Payload Examples 4.4.5.1. Basic Single-Channel Payload Carrying Multiple Frames The following diagram shows an octet aligned payload from a single channel payload type that carries two AMR frames of 7.95 kbps coding mode (FT=5). In the payload, a codec mode request is sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. No frame CRC, interleaving, or robust sorting is in use. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=6 |R|R|R|R|1|FT#1=5 |Q|P|P|0|FT#2=5 |Q|P|P| f1(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(8..15) | f1(16..23) | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |f1(152..158) |P| f2(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(8..15) | f2(16..23) | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |f2(152..158) |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note, in the above example, the last octet in both speech frames is padded with one zero bit to make it octet-aligned. 4.4.5.2. Two-Channel Payload with CRC, Interleaving, and Robust Sorting This example shows an octet aligned payload from a two-channel payload type. Two frame-blocks, each containing two speech frames of 7.95 kbps coding mode (FT=5), are carried in this payload. The two channels are left (L) and right (R) with L coming before R. In the payload, a codec mode request is also sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. Moreover, frame CRC, robust sorting, and frame-block interleaving are all enabled for the payload type. The interleaving length is 2 (ILL=1), and this payload is the first one in an interleaving group (ILP=0). Sjoberg, et al. Standards Track [Page 32] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The first two frames in the payload are the L and R channel speech frames of frame-block #1, consisting of bits f1L(0..158) and f1R(0..158), respectively. The next two frames are the L and R channel frames of frame-block #3, consisting of bits f3L(0..158) and f3R(0..158), respectively, due to interleaving. For each of the four speech frames, a CRC is calculated as CRC1L(0..7), CRC1R(0..7), CRC3L(0..7), and CRC3R(0..7), respectively. Finally, the payload is robust sorted. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1L=5|Q|P|P|1|FT#1R=5|Q|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|FT#3L=5|Q|P|P|0|FT#3R=5|Q|P|P| CRC1L | CRC1R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC3L | CRC3R | f1L(0..7) | f1R(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(0..7) | f3R(0..7) | f1L(8..15) | f1R(8..15) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(8..15) | f3R(8..15) | f1L(16..23) | f1R(16..23) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(144..151) | f3R(144..151) |f1L(152..158)|P|f1R(152..158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |f3L(152..158)|P|f3R(152..158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note, in the above example, the last octet in all four speech frames is padded with one zero bit to make it octet-aligned. 4.5. Implementation Considerations An application implementing this payload format MUST understand all the payload parameters in the out-of-band signaling used. For example, if an application uses SDP, all the SDP and media type parameters in this document MUST be understood. This requirement ensures that an implementation always can decide if it is capable or not of communicating. No operating mode of the payload format is mandatory to implement. The requirements of the application using the payload format should be used to determine what to implement. To achieve basic interoperability, an implementation SHOULD at least implement both bandwidth-efficient and octet-aligned modes for a single audio Sjoberg, et al. Standards Track [Page 33] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 channel. The other operating modes: interleaving, robust sorting, and frame-wise CRC (in both single and multi-channel) are OPTIONAL to implement. The mode-change-period, mode-change-capability, and mode-change- neighbor parameters are intended for signaling with GSM endpoints. When interoperability with GSM is desired, encoders SHOULD only perform codec mode changes to neighboring modes and in integer multiples of 40 ms (two frame-blocks), but decoders SHOULD accept codec mode changes at any time, i.e., for every frame-block. The encoder may arbitrarily select the initial phase (odd or even frame- block) where codec mode changes are performed, but then SHOULD stick to that phase as far as possible. However, in rare cases, handovers or other events (e.g., call forwarding) may change this phase and may also cause mode changes to non-neighboring modes. The decoder SHALL therefore be prepared to accept changes also in the other phase and to other modes. Section 8 specifies the usage of the parameters mode-change-period and mode-change-capability to indicate the desired behavior in applications. See 3GPP TS 26.103 [28] for preferred AMR and AMR-WB configurations for operation in GSM and 3GPP UMTS networks. In gateway scenarios, encoders can be requested through the ""mode-set"" parameter to use a limited mode-set that is supported by the link beyond the gateway. Further, to avoid congestion on that link, the encoder SHOULD limit the initial codec mode for a session to a lower mode, until at least one frame-block is received with rate control information. 4.5.1. Decoding Validation When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information for the payload type and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet. This is because decoding a packet that has errors in its length field could severely degrade the speech quality. Sjoberg, et al. Standards Track [Page 34] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5. AMR and AMR-WB Storage Format The storage format is used for storing AMR or AMR-WB speech frames in a file or as an email attachment. Multiple channel content is supported. In general, an AMR or AMR-WB file has the following structure: +------------------+ | Header | +------------------+ | Speech frame 1 | +------------------+ : ... : +------------------+ | Speech frame n | +------------------+ Note, to preserve interoperability with already deployed implementations, single-channel content uses a file header format different from that of multi-channel content. There also exists another storage format for AMR and AMR-WB that is suitable for applications with more advanced demands on the storage format, like random access or synchronization with video. This format is the 3GPP-specified ISO-based multimedia file format 3GP [31]. Its media type is specified by RFC 3839 [32]. 5.1. Single-Channel Header A single-channel AMR or AMR-WB file header contains only a magic number. Different magic numbers are defined to distinguish AMR from AMR-WB. The magic number for single-channel AMR files MUST consist of ASCII character string: ""#!AMR\n"" (or 0x2321414d520a in hexadecimal). The magic number for single-channel AMR-WB files MUST consist of ASCII character string: ""#!AMR-WB\n"" (or 0x2321414d522d57420a in hexadecimal). Sjoberg, et al. Standards Track [Page 35] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Note, the ""\n"" is an important part of the magic numbers and MUST be included in the comparison, since, otherwise, the single-channel magic numbers above will become indistinguishable from those of the multi-channel files defined in the next section. 5.2. Multi-Channel Header The multi-channel header consists of a magic number followed by a 32-bit channel description field, giving the multi-channel header the following structure: +------------------+ | magic number | +------------------+ | chan-desc field | +------------------+ The magic number for multi-channel AMR files MUST consist of the ASCII character string: ""#!AMR_MC1.0\n"" (or 0x2321414d525F4D43312E300a in hexadecimal). The magic number for multi-channel AMR-WB files MUST consist of the ASCII character string: ""#!AMR-WB_MC1.0\n"" (or 0x2321414d522d57425F4D43312E300a in hexadecimal). The version number in the magic numbers refers to the version of the file format. The 32 bit channel description field is defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved bits | CHAN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved bits: MUST be set to 0 when written, and a reader MUST ignore them. CHAN (4 bits, unsigned integer): Indicates the number of audio channels contained in this storage file. The valid values and the order of the channels within a frame-block are specified in Section 4.1 in [12]. Sjoberg, et al. Standards Track [Page 36] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5.3. Speech Frames After the file header, speech frame-blocks consecutive in time are stored in the file. Each frame-block contains a number of octet- aligned speech frames equal to the number of channels, and stored in increasing order, starting with channel 1. Each stored speech frame starts with a one-octet frame header with the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| FT |Q|P|P| +-+-+-+-+-+-+-+-+ The FT field and the Q bit are defined in the same way as in Section 4.3.2. The P bits are padding and MUST be set to 0, and MUST be ignored. Following this one octet header come the speech bits as defined in 4.4.3. The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment. The following example shows an AMR frame in 5.9 kbps coding mode (with 118 speech bits) in the storage format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| FT=2 |Q|P|P| | +-+-+-+-+-+-+-+-+ + | | + Speech bits for frame-block n, channel k + | | + +-+-+ | |P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Non-received speech frames or frame-blocks between SID updates during non-speech periods MUST be stored as NO_DATA frames (frame type 15, as defined in [2] and [4]). Frames or frame-blocks lost in transmission MUST be stored as NO_DATA frames or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks to keep synchronization with the original media. Comfort noise frames of other types than AMR SID (FT=8) (i.e., frame type 9, 10, and 11 for AMR) SHALL NOT be used in the AMR file format. Sjoberg, et al. Standards Track [Page 37] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 6. Congestion Control The general congestion control considerations for transporting RTP data apply to AMR or AMR-WB speech over RTP as well. However, the multi-rate capability of AMR and AMR-WB speech coding may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different coding mode. Another parameter that may impact the bandwidth demand for AMR and AMR-WB is the number of frame-blocks that are encapsulated in each RTP payload. Packing more frame-blocks in each RTP payload can reduce the number of packets sent and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay. If forward error correction (FEC) is used to combat packet loss, the amount of redundancy added by FEC will need to be regulated so that the use of FEC itself does not cause a congestion problem. It is RECOMMENDED that AMR or AMR-WB applications using this payload format employ congestion control. The actual mechanism for congestion control is not specified but should be suitable for real- time flows, possibly ""TCP Friendly Rate Control"" [21]. 7. Security Considerations RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8] and in any used profile, like AVP [12] or SAVP [26]. As this format transports encoded speech, the main security issues include confidentiality, authentication, and integrity of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [26], need to be used for this functionality. Note that the appropriate mechanism to provide security to RTP and the payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable the usage of SRTP [26] is RECOMMENDED. Other known mechanisms that may be used are IPsec [33] and TLS [34] (RTP over TCP), but other alternatives may also exist. This payload format does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing, and thus is unlikely to pose a denial-of-service threat due to the receipt of pathological data. Sjoberg, et al. Standards Track [Page 38] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 7.1. Confidentiality To achieve confidentiality of the encoded AMR or AMR-WB speech, all speech data bits will need to be encrypted. There is less of a need to encrypt the payload header or the table of contents due to a) that they only carry information about the requested speech mode, frame type, and frame quality, and b) that this information could be useful to some third party, e.g., quality monitoring. The packetization and unpacketization of the AMR and AMR-WB payload is done only at the endpoints. Therefore encryption should be performed after packet encapsulation, and decryption should be performed before packet decapsulation. Encryption may affect interleaving. Specifically, a change of keys should occur at the boundary between interleaving groups. If it is not done at that boundary on both endpoints, the speech quality will be degraded during the complete interleaving group for any receiver. The encryption mechanism may impact the robustness of the error correcting mechanism. This is discussed in Section 9.5 of SRTP [26]. From this, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted. 7.2. Authentication and Integrity To authenticate the sender and to protect the integrity of the RTP packets in transit, an external mechanism has to be used. As stated before, it is RECOMMENDED that SRTP [26] be used for common interoperability. Note that the use of UED/UEP may be difficult to combine with some integrity protection mechanisms because any bit errors will cause the integrity check to fail. Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality or produce unintelligible communications. Tampering with the CMR field may result in a different speech quality than desired. 8. Payload Format Parameters This section defines the parameters that may be used to select optional features of the AMR and AMR-WB payload formats. The parameters are defined here as part of the media type registrations for the AMR and AMR-WB speech codecs. The registrations are done following RFC 4855 [15] and the media registration rules [14]. Sjoberg, et al. Standards Track [Page 39] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 A mapping of the parameters into the Session Description Protocol (SDP) [11] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use media types or SDP. Two separate media type registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by their own media type. Data formats are specified for both real-time transport in RTP and for storage type applications such as email attachments. 8.1. AMR Media Type Registration The media type for the Adaptive Multi-Rate (AMR) codec is allocated from the IETF tree since AMR is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real-time transfers via stored files. Note, any unspecified parameter MUST be ignored by the receiver. Media Type name: audio Media subtype name: AMR Required parameters: none Optional parameters: These parameters apply to RTP transfer only. octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed. mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma separated list of modes from the set: 0,...,7 (see Table 1a [2]). The SID frame type 8 and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type. Sjoberg, et al. Standards Track [Page 40] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by a period of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame- block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at any time during the session, i.e., N=1. mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change- period=2. If this parameter is not present, the mode- change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. Thus, clients RECOMMENDED to have the capability to support transmission according to mode-change-capability=2. mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed. maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet. Sjoberg, et al. Standards Track [Page 41] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session. robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session. interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used. ptime: see RFC 4566 [11]. channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1. max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present. Encoding considerations: The Audio data is binary data, and must be encoded for non- binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14]. Security considerations: See Section 7 of RFC 4867. Public specification: RFC 4867 3GPP TS 26.090, 26.092, 26.093, 26.101 Sjoberg, et al. Standards Track [Page 42] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras. Additional information: The following applies to stored-file transfer methods: Magic numbers: single-channel: ASCII character string ""#!AMR\n"" (or 0x2321414d520a in hexadecimal) multi-channel: ASCII character string ""#!AMR_MC1.0\n"" (or 0x2321414d525F4D43312E300a in hexadecimal) File extensions: amr, AMR Macintosh file type code: ""amr "" (fourth character is space) AMR speech frames may also be stored in the file format ""3GP"" defined in 3GPP TS 26.244 [31], which is identified using the media types ""audio/3GPP"" or ""video/3GPP"" as registered by RFC 3839 [32]. Person & email address to contact for further information: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices. Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used. Author: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Change controller: IETF Audio/Video Transport working group delegated from the IESG. Sjoberg, et al. Standards Track [Page 43] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 8.2. AMR-WB Media Type Registration The media type for the Adaptive Multi-Rate Wideband (AMR-WB) codec is allocated from the IETF tree since AMR-WB is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real- time transfers via stored files. Note, any unspecified parameter MUST be ignored by the receiver. Media Type name: audio Media subtype name: AMR-WB Required parameters: none Optional parameters: These parameters apply to RTP transfer only. octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed. mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma-separated list of modes from the set: 0,...,8 (see Table 1a [4]). The SID frame type 9, SPEECH_LOST (frame type 14), and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type. mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame- block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at Any time during the session, i.e., N=1. Sjoberg, et al. Standards Track [Page 44] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change- period=2. If this parameter is not present, the mode- change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required."
"Thus, clients are RECOMMENDED to have the capability to support transmission according to mode-change-capability=2. mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed. maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet. crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session. robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session. Sjoberg, et al. Standards Track [Page 45] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used. ptime: see RFC 2327 [11]. channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1. max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present. Encoding considerations: The Audio data is binary data, and must be encoded for non- binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14]. Security considerations: See Section 7 of RFC 4867. Public specification: RFC 4867 3GPP TS 26.190, 26.192, 26.193, 26.201 Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras. Sjoberg, et al. Standards Track [Page 46] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Additional information: The following applies to stored-file transfer methods: Magic numbers: single-channel: ASCII character string ""#!AMR-WB\n"" (or 0x2321414d522d57420a in hexadecimal) multi-channel: ASCII character string ""#!AMR-WB_MC1.0\n"" (or 0x2321414d522d57425F4D43312E300a in hexadecimal) File extensions: awb, AWB Macintosh file type code: amrw Object identifier or OID: none AMR-WB speech frames may also be stored in the file format ""3GP"" defined in 3GPP TS 26.244 [31] and identified using the media type ""audio/3GPP"" or ""video/3GPP"" as registered by RFC 3839 [32]. Person & email address to contact for further information: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices. Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used. Author: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Change controller: IETF Audio/Video Transport working group delegated from the IESG. 8.3. Mapping Media Type Parameters into SDP The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [11], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping is as follows: Sjoberg, et al. Standards Track [Page 47] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - The media type (""audio"") goes in SDP ""m="" as the media name. - The media subtype (payload format name) goes in SDP ""a=rtpmap"" as the encoding name. The RTP clock rate in ""a=rtpmap"" MUST be 8000 for AMR and 16000 for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed are specified in Section 4.1 in [12]. - The parameters ""ptime"" and ""maxptime"" go in the SDP ""a=ptime"" and ""a=maxptime"" attributes, respectively. - Any remaining parameters go in the SDP ""a=fmtp"" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs. 8.3.1. Offer-Answer Model Considerations The following considerations apply when using SDP Offer-Answer procedures to negotiate the use of AMR or AMR-WB payload in RTP: - Each combination of the RTP payload transport format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. When creating an offer in an application desiring to use the more advanced features (crc, robust-sorting, interleaving, or more than one channel), the offerer is RECOMMENDED to also offer a payload type containing only the octet-aligned or bandwidth-efficient configuration with a single channel. If multiple configurations are of interest to the application, they may all be offered; however, care should be taken not to offer too many payload types. An SDP answerer MUST include, in the SDP answer for a payload type, the following parameters unmodified from the SDP offer (unless it removes the payload type): ""octet- align""; ""crc""; ""robust-sorting""; ""interleaving""; and ""channels"". The SDP offerer and answerer MUST generate AMR or AMR-WB packets as described by these parameters. - The ""mode-set"" parameter can be used to restrict the set of active AMR/AMR-WB modes used in a session. This functionality is primarily intended for gateways to access networks such as GSM or 3GPP UMTS, where the access network may be capable of supporting only a subset of AMR/AMR-WB modes. The 3GPP preferred codec configurations are defined in 3GPP TS 26.103 [25], and it is RECOMMENDED that other networks also needing to restrict the mode set follow the preferred codec configurations defined in 3GPP for greatest interoperability. Sjoberg, et al. Standards Track [Page 48] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The parameter is bi-directional, i.e., the restricted set applies to media both to be received and sent by the declaring entity. If a mode set was supplied in the offer, the answerer SHALL return the mode-set unmodified or reject the payload type. However, the answerer is free to choose a mode-set in the answer only if no mode-set was supplied in the offer for a unicast two-peer session. The mode-set in the answer is binding both for offerer and answerer. Thus, an offerer supporting all modes and subsets SHOULD NOT include the mode- set parameter. For any other offerer it is RECOMMENDED to include each mode-set it can support as a separate payload type within the offer. For multicast sessions, the answerer SHALL only participate in the session if it supports the offered mode-set. Thus, it is RECOMMENDED that any offer for a multicast session include only the mode-set it will require the answerers to support, and that the mode-set be likely to be supported by all participants. - The parameters ""mode-change-period"" and ""mode-change- capability"" are intended to be used in sessions with gateways, for example, when interoperating with GSM networks. Both parameters are declarative and are combined to allow a session participant to determine if the payload type can be supported. The mode-change-period will indicate what the offerer or answerer requires of data it receives, while the mode-change- capability indicates its transmission capabilities. A mode-change-period=2 in the offer indicates a requirement on the answerer to send with a mode-change period of 2, i.e., support mode-change-capability=2. If the answerer requires mode-change-period=2, it SHALL only include it in the answer if the offerer either has indicated support with mode-change- capability=2 or has indicated mode-change-period=2; otherwise, the payload type SHALL be rejected. An offerer that supports mode-change-capability=2 SHALL include the parameter in all offers to ensure the greatest possible interoperability, unless it includes mode-change-period=2 in the offer. The mode- change-capability SHOULD be included in answers. It is then indicating the answerer's capability to transmit with that mode-change-period for the provided payload format configuration. The information is useful in future re-negotiation of the payload formats. - The parameter ""mode-change-neighbor"" is a recommendation to restrict the switching of codec modes to its neighbor and SHOULD be followed. It is intended to be used in gateway scenarios (for example, to GSM networks) where the support of Sjoberg, et al. Standards Track [Page 49] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 this parameter and the operations it implies improves interoperability. ""mode-change-neighbor"" is a declarative parameter. By including the parameter, the offerer or answerer indicates that it desires to receive streams with ""mode-change-neighbor"" restrictions. - In most cases, the parameters ""maxptime"" and ""ptime"" will not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer- answer handling of the ""ptime"" parameter is described in RFC 3264 [13]. The ""maxptime"" parameter MUST be handled in the same way. - The parameter ""max-red"" is a stream property parameter. For send-only or send-recv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the ""max-red"" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case ""max-red"" is set to 0. As this parameter was not defined originally, some senders will not declare this parameter even if it will limit or not send redundancy at all. - Any unknown parameter in an offer SHALL be removed in the answer. 8.3.2. Usage of Declarative SDP In declarative usage, like SDP in RTSP [29] or SAP [30], the parameters SHALL be interpreted as follows: - The payload format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) are all declarative, and a participant MUST use the configuration(s) that is provided for the session. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small. Sjoberg, et al. Standards Track [Page 50] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - Any restriction of the AMR or AMR-WB encoder mode-switching and mode usage through the ""mode-set"", and ""mode-change-period"" MUST be followed by all participants of the session. The restriction indicated by ""mode-change-neighbor"" SHOULD be followed. Please note that such restrictions may be necessary if gateways to other transport systems like GSM participate in the session. Failure to consider such restrictions may result in failure for a peer behind such a gateway to correctly receive all or parts of the session. Also, if different restrictions are needed by different peers in the same session (unless a common subset of the restrictions exists), some peer will not be able to participate. Note that the usage of mode-change-capability is meaningless when no negotiation exists, and can thus be excluded in any declarations. - Any ""maxptime"" and ""ptime"" values should be selected with care to ensure that the session's participants can achieve reasonable performance. - The usage of ""max-red"" puts a global upper limit on the usage of redundancy that needs to be followed by all that understand the parameter. However, due to the late addition of this parameter, it may be ignored by some implementations. 8.3.3. Examples Some example SDP session descriptions utilizing AMR and AMR-WB encodings follow. In these examples, long a=fmtp lines are folded to meet the column width constraints of this document; the backslash (""\"") at the end of a line and the carriage return that follows it should be ignored. In an example of the usage of AMR in a possible GSM gateway-to- gateway scenario, the offerer is capable of supporting three different mode-sets and needs the mode-change-period to be 2 in combination with mode-change-neighbor restrictions. The other gateway can only support two of these mode-sets and removes the payload type 97 in the answer. If the offering GSM gateway only supports a single mode-set active at the same time, it should consider doing the 1 out of N selection procedures described in Section 10.2 of [13]: Sjoberg, et al. Standards Track [Page 51] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Offer: m=audio 49120 RTP/AVP 97 98 99 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 Answer: m=audio 49120 RTP/AVP 98 99 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \< mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 The following example shows the usage of AMR between a non-GSM endpoint and a GSM gateway. The non-GSM offerer requires no restrictions of the mode-change-period or mode-change-neighbor, but must signal its mode-change-capability in the offer and abide by those restrictions in the answer. Offer: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2 a=maxptime:20 Answer: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 Sjoberg, et al. Standards Track [Page 52] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Example of usage of AMR-WB in a possible VoIP scenario where UEP may be used (99) and a fallback declaration (98): m=audio 49120 RTP/AVP 99 98 a=rtpmap:98 AMR-WB/16000 a=fmtp:98 octet-align=1; mode-change-capability=2 a=rtpmap:99 AMR-WB/16000 a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2 Example of usage of AMR-WB in a possible streaming scenario (two channel stereo): m=audio 49120 RTP/AVP 99 a=rtpmap:99 AMR-WB/16000/2 a=fmtp:99 interleaving=30 a=maxptime:100 Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute. 9. IANA Considerations Two media types (audio/AMR and audio/AMR-WB) have been updated; see Section 8. 10. Changes from RFC 3267 The differences between RFC 3267 and this document are as follows: - Added clarification of behavior in regards to mode change period and mode-change neighbor that is expected from an IP client; see Section 4.5. - Updated the maxptime for better clarification. The sentence that previously read: ""The time SHOULD be a multiple of the frame size."" now says ""The time SHOULD be an integer multiple of the frame size."" This should have no impact on interoperability. - Updated the definition of the mode-set parameter for clarification. - Restricted the values for mode-change-period to 1 or 2, which are the values used in circuit-switched AMR systems. Sjoberg, et al. Standards Track [Page 53] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - Added a new media type parameter Mode-Change-Capability that defaults to 1, which is the assumed behavior of any non-updated implementation. This enables the offer-answer procedures to work. - Changed mode-change-neighbor to indicate a recommended behavior rather than a required one. - Added an Offer-Answer Section, see Section 8.3.1. This will have implications on the interoperability to implementations that have guessed how to perform offer/answer negotiation of the payload parameters. - Clarified and aligned the unequal detection usage with the published UDP-Lite specification in Sections 3.6.1 and 4.4.2.1. This included replacing a normative statement about packet handling with an informative paragraph with a reference to UDP- Lite. - Clarified the bit order in the CRC calculation in Section 4.4.2.1. - Corrected the reference in Section 5.3 for the Q and FT fields. - Changed the padding bit definition in Sections 4.4.2 and 5.3 so that it is clear that they shall be ignored. - Added a clarification that comfort noise frames with frame type 9, 10, and 11 SHALL NOT be used in the AMR file format. - Clarified in Section 4.3.2 that the rules about not sending NO_DATA frames do apply for all payload format configurations with the exception of the interleaved mode. - The reference list has been updated to now published RFCs: RFC 3448, RFC 3550, RFC 3551, RFC 3711, RFC 3828, and RFC 4566. A reference to 3GPP TS 26.101 has also been added. - Added notes in storage format section and media type registration that AMR and AMR-WB frames can also be stored in the 3GP file format. - Added a media type parameter ""max-red"" that allows the sender to declare a bounded usage of redundancy. This parameter allows a receiver to optimize its function as it will know if redundancy will be used or not. If it is used, the maximum extra delay introduced by the sender (that is needed to be considered by the receiver to fully utilize the redundancy) will be known. The addition of this parameter should have no negative effects on older implementations as they are mandated to ignore unknown Sjoberg, et al. Standards Track [Page 54] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 parameters per RFC 3267. In addition, older implementations are required to operate as if the value of max-red is unknown and possibly infinite. - Updated the media type registration to comply with the new registration rules. - Moved section on decoding validation from Security Considerations to Implementation Considerations, where it makes more sense. - Clarified the application of encryption, integrity protection, and authentication mechanism to the payload. 11. Acknowledgements The authors would like to thank Petri Koskelainen, Bernhard Wimmer, Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for their significant contributions made throughout the writing and reviewing of RFC 3267 and this replacement. The authors would also like to thank Richard Ejzak, Thomas Belling, and Gorry Fairhurst for their input on this replacement of RFC 3267. 12. References 12.1. Normative References [1] 3GPP TS 26.090, ""Adaptive Multi-Rate (AMR) speech transcoding"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [2] 3GPP TS 26.101, ""AMR Speech Codec Frame Structure"", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP). [3] 3GPP TS 26.190 ""AMR Wideband speech codec; Transcoding functions"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [4] 3GPP TS 26.201 ""AMR Wideband speech codec; Frame Structure"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [5] Bradner, S., ""Key words for use in RFCs to Indicate Requirement Levels"", BCP 14, RFC 2119, March 1997. [6] 3GPP TS 26.093, ""AMR Speech Codec; Source Controlled Rate operation"", version 4.0.0 (2000-12), 3rd Generation Partnership Project (3GPP). Sjoberg, et al. Standards Track [Page 55] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [7] 3GPP TS 26.193 ""AMR Wideband Speech Codec; Source Controlled Rate operation"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, ""RTP: A Transport Protocol for Real-Time Applications"", STD 64, RFC 3550, July 2003. [9] 3GPP TS 26.092, ""AMR Speech Codec; Comfort noise aspects"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [10] 3GPP TS 26.192 ""AMR Wideband speech codec; Comfort Noise aspects"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [11] Handley, M., Jacobson, V., and C. Perkins, ""SDP: Session Description Protocol"", RFC 4566, July 2006. [12] Schulzrinne, H. and S. Casner, ""RTP Profile for Audio and Video Conferences with Minimal Control"", STD 65, RFC 3551, July 2003. [13] Rosenberg, J. and H. Schulzrinne, ""An Offer/Answer Model with Session Description Protocol (SDP)"", RFC 3264, June 2002. [14] Freed, N. and J. Klensin, ""Media Type Specifications and Registration Procedures"", BCP 13, RFC 4288, December 2005. [15] Casner, S., ""Media Type Registration of RTP Payload Formats"", RFC 4855, February 2007. 12.2. Informative References [16] GSM 06.60, ""Enhanced Full Rate (EFR) speech transcoding"", version 8.0.1 (2000-11), European Telecommunications Standards Institute (ETSI). [17] ANSI/TIA/EIA-136-Rev.C, part 410 - ""TDMA Cellular/PCS Radio Interface, Enhanced Full Rate Voice Codec (ACELP)"". Formerly IS-641. TIA published standard, June 1 2001. [18] ARIB, RCR STD-27H, ""Personal Digital Cellular Telecommunication System RCR Standard"", Association of Radio Industries and Businesses (ARIB). [19] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, ""The Lightweight User Datagram Protocol (UDP-Lite)"", RFC 3828, July 2004. Sjoberg, et al. Standards Track [Page 56] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [20] 3GPP TS 25.415 ""UTRAN Iu Interface User Plane Protocols"", version 4.2.0 (2001-09), 3rd Generation Partnership Project (3GPP). [21] Handley, M., Floyd, S., Padhye, J., and J. Widmer, ""TCP Friendly Rate Control (TFRC): Protocol Specification"", RFC 3448, January 2003. [22] Li, A., et al., ""An RTP Payload Format for Generic FEC with Uneven Level Protection"", Work in Progress. [23] Rosenberg, J. and H. Schulzrinne, ""An RTP Payload Format for Generic Forward Error Correction"", RFC 2733, December 1999. [24] 3GPP TS 26.102, ""AMR speech codec interface to Iu and Uu"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [25] 3GPP TS 26.202, ""AMR Wideband speech codec; Interface to Iu and Uu"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, ""The Secure Real-time Transport Protocol (SRTP)"", RFC 3711, March 2004. [27] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, ""RTP Payload for Redundant Audio Data"", RFC 2198, September 1997. [28] 3GPP TS 26.103, ""Speech codec list for GSM and UMTS"", version 5.5.0 (2004-09), 3rd Generation Partnership Project (3GPP). [29] Schulzrinne, H., Rao, A., and R. Lanphier, ""Real Time Streaming Protocol (RTSP)"", RFC 2326, April 1998. [30] Handley, M., Perkins, C., and E. Whelan, ""Session Announcement Protocol"", RFC 2974, October 2000. [31] 3GPP TS 26.244, ""3GPP file format (3GP)"", version 6.1.0 (2004- 09), 3rd Generation Partnership Project (3GPP). [32] Castagno, R. and D. Singer, ""MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files"", RFC 3839, July 2004. [33] Kent, S. and K. Seo, ""Security Architecture for the Internet Protocol"", RFC 4301, December 2005. Sjoberg, et al. Standards Track [Page 57] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [34] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.1"", RFC 4346, April 2006. ETSI documents are available from <http://www.etsi.org/>. 3GPP documents are available from <http://www.3gpp.org/>. TIA documents are available from <http://www.tiaonline.org/>. Authors' Addresses Johan Sjoberg Ericsson AB SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: Johan.Sjoberg@ericsson.com Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com Ari Lakaniemi Nokia Research Center P.O.Box 407 FIN-00045 Nokia Group, FINLAND Phone: +358-71-8008000 EMail: ari.lakaniemi@nokia.com Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-B8 Arlington Heights, IL 60004, USA Phone: +1-847-632-3028 EMail: Qiaobing.Xie@motorola.com Sjoberg, et al. Standards Track [Page 58] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an ""AS IS"" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at <%ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sjoberg, et al. Standards Track [Page 59] Network Working Group J. Rosenberg Request for Comments: 3261 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. G. Camarillo Ericsson A. Johnston WorldCom J. Peterson Neustar R. Sparks dynamicsoft M. Handley ICIR E. Schooler AT&T June 2002 SIP: Session Initiation Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ""Internet Official Protocol Standards"" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. Rosenberg, et. al. Standards Track [Page 1] RFC 3261 SIP: Session Initiation Protocol June 2002 Table of Contents 1 Introduction ........................................ 8 2 Overview of SIP Functionality ....................... 9 3 Terminology ......................................... 10 4 Overview of Operation ............................... 10 5 Structure of the Protocol ........................... 18 6 Definitions ......................................... 20 7 SIP Messages ........................................ 26 7.1 Requests ............................................ 27 7.2 Responses ........................................... 28 7.3 Header Fields ....................................... 29 7.3.1 Header Field Format ................................. 30 7.3.2 Header Field Classification ......................... 32 7.3.3 Compact Form ........................................ 32 7.4 Bodies .............................................. 33 7.4.1 Message Body Type ................................... 33 7.4.2 Message Body Length ................................. 33 7.5 Framing SIP Messages ................................ 34 8 General User Agent Behavior ......................... 34 8.1 UAC Behavior ........................................ 35 8.1.1 Generating the Request .............................. 35 8.1.1.1 Request-URI ......................................... 35 8.1.1.2 To .................................................. 36 8.1.1.3 From ................................................ 37 8.1.1.4 Call-ID ............................................. 37 8.1.1.5 CSeq ................................................ 38 8.1.1.6 Max-Forwards ........................................ 38 8.1.1.7 Via ................................................. 39 8.1.1.8 Contact ............................................. 40 8.1.1.9 Supported and Require ............................... 40 8.1.1.10 Additional Message Components ....................... 41 8.1.2 Sending the Request ................................. 41 8.1.3 Processing Responses ................................ 42 8.1.3.1 Transaction Layer Errors ............................ 42 8.1.3.2 Unrecognized Responses .............................. 42 8.1.3.3 Vias ................................................ 43 8.1.3.4 Processing 3xx Responses ............................ 43 8.1.3.5 Processing 4xx Responses ............................ 45 8.2 UAS Behavior ........................................ 46 8.2.1 Method Inspection ................................... 46 8.2.2 Header Inspection ................................... 46 8.2.2.1 To and Request-URI .................................. 46 8.2.2.2 Merged Requests ..................................... 47 8.2.2.3 Require ............................................. 47 8.2.3 Content Processing .................................. 48 8.2.4 Applying Extensions ................................. 49 8.2.5 Processing the Request .............................. 49 Rosenberg, et. al. Standards Track [Page 2] RFC 3261 SIP: Session Initiation Protocol June 2002 8.2.6 Generating the Response ............................. 49 8.2.6.1 Sending a Provisional Response ...................... 49 8.2.6.2 Headers and Tags .................................... 50 8.2.7 Stateless UAS Behavior .............................. 50 8.3 Redirect Servers .................................... 51 9 Canceling a Request ................................. 53 9.1 Client Behavior ..................................... 53 9.2 Server Behavior ..................................... 55 10 Registrations ....................................... 56 10.1 Overview ............................................ 56 10.2 Constructing the REGISTER Request ................... 57 10.2.1 Adding Bindings ..................................... 59 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 10.2.1.2 Preferences among Contact Addresses ................. 61 10.2.2 Removing Bindings ................................... 61 10.2.3 Fetching Bindings ................................... 61 10.2.4 Refreshing Bindings ................................. 61 10.2.5 Setting the Internal Clock .......................... 62 10.2.6 Discovering a Registrar ............................. 62 10.2.7 Transmitting a Request .............................. 62 10.2.8 Error Responses ..................................... 63 10.3 Processing REGISTER Requests ........................ 63 11 Querying for Capabilities ........................... 66 11.1 Construction of OPTIONS Request ..................... 67 11.2 Processing of OPTIONS Request ....................... 68 12 Dialogs ............................................. 69 12.1 Creation of a Dialog ................................ 70 12.1.1 UAS behavior ........................................ 70 12.1.2 UAC Behavior ........................................ 71 12.2 Requests within a Dialog ............................ 72 12.2.1 UAC Behavior ........................................ 73 12.2.1.1 Generating the Request .............................. 73 12.2.1.2 Processing the Responses ............................ 75 12.2.2 UAS Behavior ........................................ 76 12.3 Termination of a Dialog ............................. 77 13 Initiating a Session ................................ 77 13.1 Overview ............................................ 77 13.2 UAC Processing ...................................... 78 13.2.1 Creating the Initial INVITE ......................... 78 13.2.2 Processing INVITE Responses ......................... 81 13.2.2.1 1xx Responses ....................................... 81 13.2.2.2 3xx Responses ....................................... 81 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 13.2.2.4 2xx Responses ....................................... 82 13.3 UAS Processing ...................................... 83 13.3.1 Processing of the INVITE ............................ 83 13.3.1.1 Progress ............................................ 84 13.3.1.2 The INVITE is Redirected ............................ 84 Rosenberg, et. al. Standards Track [Page 3] RFC 3261 SIP: Session Initiation Protocol June 2002 13.3.1.3 The INVITE is Rejected .............................. 85 13.3.1.4 The INVITE is Accepted .............................. 85 14 Modifying an Existing Session ....................... 86 14.1 UAC Behavior ........................................ 86 14.2 UAS Behavior ........................................ 88 15 Terminating a Session ............................... 89 15.1 Terminating a Session with a BYE Request ............ 90 15.1.1 UAC Behavior ........................................ 90 15.1.2 UAS Behavior ........................................ 91 16 Proxy Behavior ...................................... 91 16.1 Overview ............................................ 91 16.2 Stateful Proxy ...................................... 92 16.3 Request Validation .................................. 94 16.4 Route Information Preprocessing ..................... 96 16.5 Determining Request Targets ......................... 97 16.6 Request Forwarding .................................. 99 16.7 Response Processing ................................. 107 16.8 Processing Timer C .................................. 114 16.9 Handling Transport Errors ........................... 115 16.10 CANCEL Processing ................................... 115 16.11 Stateless Proxy ..................................... 116 16.12 Summary of Proxy Route Processing ................... 118 16.12.1 Examples ............................................ 118 16.12.1.1 Basic SIP Trapezoid ................................. 118 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121 17 Transactions ........................................ 122 17.1 Client Transaction .................................. 124 17.1.1 INVITE Client Transaction ........................... 125 17.1.1.1 Overview of INVITE Transaction ...................... 125 17.1.1.2 Formal Description .................................. 125 17.1.1.3 Construction of the ACK Request ..................... 129 17.1.2 Non-INVITE Client Transaction ....................... 130 17.1.2.1 Overview of the non-INVITE Transaction .............. 130 17.1.2.2 Formal Description .................................. 131 17.1.3 Matching Responses to Client Transactions ........... 132 17.1.4 Handling Transport Errors ........................... 133 17.2 Server Transaction .................................. 134 17.2.1 INVITE Server Transaction ........................... 134 17.2.2 Non-INVITE Server Transaction ....................... 137 17.2.3 Matching Requests to Server Transactions ............ 138 17.2.4 Handling Transport Errors ........................... 141 18 Transport ........................................... 141 18.1 Clients ............................................. 142 18.1.1 Sending Requests .................................... 142 18.1.2 Receiving Responses ................................. 144 18.2 Servers ............................................. 145 18.2.1 Receiving Requests .................................. 145 Rosenberg, et. al. Standards Track [Page 4] RFC 3261 SIP: Session Initiation Protocol June 2002 18.2.2 Sending Responses ................................... 146 18.3 Framing ............................................. 147 18.4 Error Handling ...................................... 147 19 Common Message Components ........................... 147 19.1 SIP and SIPS Uniform Resource Indicators ............ 148 19.1.1 SIP and SIPS URI Components ......................... 148 19.1.2 Character Escaping Requirements ..................... 152 19.1.3 Example SIP and SIPS URIs ........................... 153 19.1.4 URI Comparison ...................................... 153 19.1.5 Forming Requests from a URI ......................... 156 19.1.6 Relating SIP URIs and tel URLs ...................... 157 19.2 Option Tags ......................................... 158 19.3 Tags ................................................ 159 20 Header Fields ....................................... 159 20.1 Accept .............................................. 161 20.2 Accept-Encoding ..................................... 163 20.3 Accept-Language ..................................... 164 20.4 Alert-Info .......................................... 164 20.5 Allow ............................................... 165 20.6 Authentication-Info ................................. 165 20.7 Authorization ....................................... 165 20.8 Call-ID ............................................. 166 20.9 Call-Info ........................................... 166 20.10 Contact ............................................. 167 20.11 Content-Disposition ................................. 168 20.12 Content-Encoding .................................... 169 20.13 Content-Language .................................... 169 20.14 Content-Length ...................................... 169 20.15 Content-Type ........................................ 170 20.16 CSeq ................................................ 170 20.17 Date ................................................ 170 20.18 Error-Info .......................................... 171 20.19 Expires ............................................. 171 20.20 From ................................................ 172 20.21 In-Reply-To ......................................... 172 20.22 Max-Forwards ........................................ 173 20.23 Min-Expires ......................................... 173 20.24 MIME-Version ........................................ 173 20.25 Organization ........................................ 174 20.26 Priority ............................................ 174 20.27 Proxy-Authenticate .................................. 174 20.28 Proxy-Authorization ................................. 175 20.29 Proxy-Require ....................................... 175 20.30 Record-Route ........................................ 175 20.31 Reply-To ............................................ 176 20.32 Require ............................................. 176 20.33 Retry-After ......................................... 176 20.34 Route ............................................... 177 Rosenberg, et. al. Standards Track [Page 5] RFC 3261 SIP: Session Initiation Protocol June 2002 20.35 Server .............................................. 177 20.36 Subject ............................................. 177 20.37 Supported ........................................... 178 20.38 Timestamp ........................................... 178 20.39 To .................................................. 178 20.40 Unsupported ......................................... 179 20.41 User-Agent .......................................... 179 20.42 Via ................................................. 179 20.43 Warning ............................................. 180 20.44 WWW-Authenticate .................................... 182 21 Response Codes ...................................... 182 21.1 Provisional 1xx ..................................... 182 21.1.1 100 Trying .......................................... 183 21.1.2 180 Ringing ......................................... 183 21.1.3 181 Call Is Being Forwarded ......................... 183 21.1.4 182 Queued .......................................... 183 21.1.5 183 Session Progress ................................ 183 21.2 Successful 2xx ...................................... 183 21.2.1 200 OK .............................................. 183 21.3 Redirection 3xx ..................................... 184 21.3.1 300 Multiple Choices ................................ 184 21.3.2 301 Moved Permanently ............................... 184 21.3.3 302 Moved Temporarily ............................... 184 21.3.4 305 Use Proxy ....................................... 185 21.3.5 380 Alternative Service ............................. 185 21.4 Request Failure 4xx ................................. 185 21.4.1 400 Bad Request ..................................... 185 21.4.2 401 Unauthorized .................................... 185 21.4.3 402 Payment Required ................................ 186 21.4.4 403 Forbidden ....................................... 186 21.4.5 404 Not Found ....................................... 186 21.4.6 405 Method Not Allowed .............................. 186 21.4.7 406 Not Acceptable .................................. 186 21.4.8 407 Proxy Authentication Required ................... 186 21.4.9 408 Request Timeout ................................. 186 21.4.10 410 Gone ............................................ 187 21.4.11 413 Request Entity Too Large ........................ 187 21.4.12 414 Request-URI Too Long ............................ 187 21.4.13 415 Unsupported Media Type .......................... 187 21.4.14 416 Unsupported URI Scheme .......................... 187 21.4.15 420 Bad Extension ................................... 187 21.4.16 421 Extension Required .............................. 188 21.4.17 423 Interval Too Brief .............................. 188 21.4.18 480 Temporarily Unavailable ......................... 188 21.4.19 481 Call/Transaction Does Not Exist ................. 188 21.4.20 482 Loop Detected ................................... 188 21.4.21 483 Too Many Hops ................................... 189 21.4.22 484 Address Incomplete .............................. 189 Rosenberg, et. al. Standards Track [Page 6] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.23 485 Ambiguous ....................................... 189 21.4.24 486 Busy Here ....................................... 189 21.4.25 487 Request Terminated .............................. 190 21.4.26 488 Not Acceptable Here ............................. 190 21.4.27 491 Request Pending ................................. 190 21.4.28 493 Undecipherable .................................. 190 21.5 Server Failure 5xx .................................. 190 21.5.1 500 Server Internal Error ........................... 190 21.5.2 501 Not Implemented ................................. 191 21.5.3 502 Bad Gateway ..................................... 191 21.5.4 503 Service Unavailable ............................. 191 21.5.5 504 Server Time-out ................................. 191 21.5.6 505 Version Not Supported ........................... 192 21.5.7 513 Message Too Large ............................... 192 21.6 Global Failures 6xx ................................. 192 21.6.1 600 Busy Everywhere ................................. 192 21.6.2 603 Decline ......................................... 192 21.6.3 604 Does Not Exist Anywhere ......................... 192 21.6.4 606 Not Acceptable .................................. 192 22 Usage of HTTP Authentication ........................ 193 22.1 Framework ........................................... 193 22.2 User-to-User Authentication ......................... 195 22.3 Proxy-to-User Authentication ........................ 197 22.4 The Digest Authentication Scheme .................... 199 23 S/MIME .............................................. 201 23.1 S/MIME Certificates ................................. 201 23.2 S/MIME Key Exchange ................................. 202 23.3 Securing MIME bodies ................................ 205 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP ....................................... 207 23.4.1 Integrity and Confidentiality Properties of SIP Headers ............................................. 207 23.4.1.1 Integrity ........................................... 207 23.4.1.2 Confidentiality ..................................... 208 23.4.2 Tunneling Integrity and Authentication .............. 209 23.4.3 Tunneling Encryption ................................ 211 24 Examples ............................................ 213 24.1 Registration ........................................ 213 24.2 Session Setup ....................................... 214 25 Augmented BNF for the SIP Protocol .................. 219 25.1 Basic Rules ......................................... 219 26 Security Considerations: Threat Model and Security Usage Recommendations ............................... 232 26.1 Attacks and Threat Models ........................... 233 26.1.1 Registration Hijacking .............................. 233 26.1.2 Impersonating a Server .............................. 234 26.1.3 Tampering with Message Bodies ....................... 235 26.1.4 Tearing Down Sessions ............................... 235 Rosenberg, et. al."
"Standards Track [Page 7] RFC 3261 SIP: Session Initiation Protocol June 2002 26.1.5 Denial of Service and Amplification ................. 236 26.2 Security Mechanisms ................................. 237 26.2.1 Transport and Network Layer Security ................ 238 26.2.2 SIPS URI Scheme ..................................... 239 26.2.3 HTTP Authentication ................................. 240 26.2.4 S/MIME .............................................. 240 26.3 Implementing Security Mechanisms .................... 241 26.3.1 Requirements for Implementers of SIP ................ 241 26.3.2 Security Solutions .................................. 242 26.3.2.1 Registration ........................................ 242 26.3.2.2 Interdomain Requests ................................ 243 26.3.2.3 Peer-to-Peer Requests ............................... 245 26.3.2.4 DoS Protection ...................................... 246 26.4 Limitations ......................................... 247 26.4.1 HTTP Digest ......................................... 247 26.4.2 S/MIME .............................................. 248 26.4.3 TLS ................................................. 249 26.4.4 SIPS URIs ........................................... 249 26.5 Privacy ............................................. 251 27 IANA Considerations ................................. 252 27.1 Option Tags ......................................... 252 27.2 Warn-Codes .......................................... 252 27.3 Header Field Names .................................. 253 27.4 Method and Response Codes ........................... 253 27.5 The ""message/sip"" MIME type. ....................... 254 27.6 New Content-Disposition Parameter Registrations ..... 255 28 Changes From RFC 2543 ............................... 255 28.1 Major Functional Changes ............................ 255 28.2 Minor Functional Changes ............................ 260 29 Normative References ................................ 261 30 Informative References .............................. 262 A Table of Timer Values ............................... 265 Acknowledgments ................................................ 266 Authors' Addresses ............................................. 267 Full Copyright Statement ....................................... 269 1 Introduction There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages. The Session Initiation Protocol (SIP) works in concert with these protocols by Rosenberg, et. al. Standards Track [Page 8] RFC 3261 SIP: Session Initiation Protocol June 2002 enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share. For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy servers) to which user agents can send registrations, invitations to sessions, and other requests. SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established. 2 Overview of SIP Functionality SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility [27] - users can maintain a single externally visible identifier regardless of their network location. SIP supports five facets of establishing and terminating multimedia communications: User location: determination of the end system to be used for communication; User availability: determination of the willingness of the called party to engage in communications; User capabilities: determination of the media and media parameters to be used; Session setup: ""ringing"", establishment of session parameters at both called and calling party; Session management: including transfer and termination of sessions, modifying session parameters, and invoking services. SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, the Media Rosenberg, et. al. Standards Track [Page 9] RFC 3261 SIP: Session Initiation Protocol June 2002 Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete services to the users. However, the basic functionality and operation of SIP does not depend on any of these protocols. SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a ""caller ID"" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services. SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of network resource reservation capabilities. The nature of the services provided make security particularly important. To that end, SIP provides a suite of security services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity protection, and encryption and privacy services. SIP works with both IPv4 and IPv6. 3 Terminology In this document, the key words ""MUST"", ""MUST NOT"", ""REQUIRED"", ""SHALL"", ""SHALL NOT"", ""SHOULD"", ""SHOULD NOT"", ""RECOMMENDED"", ""NOT RECOMMENDED"", ""MAY"", and ""OPTIONAL"" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. 4 Overview of Operation This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature and does not contain any normative statements. Rosenberg, et. al. Standards Track [Page 10] RFC 3261 SIP: Session Initiation Protocol June 2002 The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established. Figure 1 shows a typical example of a SIP message exchange between two users, Alice and Bob. (Each message is labeled with the letter ""F"" and a number for reference by the text.) In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. This typical arrangement is often referred to as the ""SIP trapezoid"" as shown by the geometric shape of the dotted lines in Figure 1. Alice ""calls"" Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. SIP URIs are defined in Section 19.1. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP service provider. Alice has a SIP URI of sip:alice@atlanta.com. Alice might have typed in Bob's URI or perhaps clicked on a hyperlink or an entry in an address book. SIP also provides a secure URI, called a SIPS URI. An example would be sips:bob@biloxi.com. A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee. SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. In this example, the transaction begins with Alice's softphone sending an INVITE request addressed to Bob's SIP URI. INVITE is an example of a SIP method that specifies the action that the requestor (Alice) wants the server (Bob) to take. The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destination address, Alice's address, and information about the type of session that Alice wishes to establish with Bob. The INVITE (message F1 in Figure 1) might look like this: Rosenberg, et. al. Standards Track [Page 11] RFC 3261 SIP: Session Initiation Protocol June 2002 atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | | Figure 1: SIP session setup example with SIP trapezoid INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below: Rosenberg, et. al. Standards Track [Page 12] RFC 3261 SIP: Session Initiation Protocol June 2002 Via contains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction. To contains a display name (Bob) and a SIP or SIPS URI (sip:bob@biloxi.com) towards which the request was originally directed. Display names are described in RFC 2822 [3]. From also contains a display name (Alice) and a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the originator of the request. This header field also has a tag parameter containing a random string (1928301774) that was added to the URI by the softphone. It is used for identification purposes. Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog. CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number. Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests. Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop. Content-Type contains a description of the message body (not shown). Content-Length contains an octet (byte) count of the message body. The complete set of SIP header fields is defined in Section 20. The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the Rosenberg, et. al. Standards Track [Page 13] RFC 3261 SIP: Session Initiation Protocol June 2002 example) is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message. Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the softphone sends the INVITE to the SIP server that serves Alice's domain, atlanta.com. The address of the atlanta.com SIP server could have been configured in Alice's softphone, or it could have been discovered by DHCP, for example. The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice's softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows Alice's softphone to correlate this response to the sent INVITE. The atlanta.com proxy server locates the proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. This is described in [4]. As a result, it obtains the IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE request there. Before forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains its own address (the INVITE already contains Alice's address in the first Via). The biloxi.com proxy server receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to indicate that it has received the INVITE and is processing the request. The proxy server consults a database, generically called a location service, that contains the current IP address of Bob. (We shall see in the next section how this database can be populated.) The biloxi.com proxy server adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP phone. Bob's SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being Rosenberg, et. al. Standards Track [Page 14] RFC 3261 SIP: Session Initiation Protocol June 2002 maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE. When Alice's softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps using an audio ringback tone or by displaying a message on Alice's screen. In this example, Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange. If Bob did not wish to answer the call or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established. The complete list of SIP response codes is in Section 21. The 200 (OK) (message F9 in Figure 1) might look like this as Bob sends it out: SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) The first line of the response contains the response code (200) and the reason phrase (OK). The remaining lines contain header fields. The Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request. (There are three Via header field values - one added by Alice's SIP phone, one added by the atlanta.com proxy, and one added by the biloxi.com proxy.) Bob's SIP phone has added a tag parameter to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included in all future Rosenberg, et. al. Standards Track [Page 15] RFC 3261 SIP: Session Initiation Protocol June 2002 requests and responses in this call. The Contact header field contains a URI at which Bob can be directly reached at his SIP phone. The Content-Type and Content-Length refer to the message body (not shown) that contains Bob's SDP media information. In addition to DNS and location service lookups shown in this example, proxy servers can make flexible ""routing decisions"" to decide where to send a request. For example, if Bob's SIP phone returned a 486 (Busy Here) response, the biloxi.com proxy server could proxy the INVITE to Bob's voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking. In this case, the 200 (OK) is routed back through the two proxies and is received by Alice's softphone, which then stops the ringback tone and indicates that the call has been answered. Finally, Alice's softphone sends an acknowledgement message, ACK, to Bob's SIP phone to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from Alice's softphone to Bob's SIP phone, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. Full details on session setup are in Section 13. Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages. During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re- INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. Full details on session modification are in Section 14. Rosenberg, et. al. Standards Track [Page 16] RFC 3261 SIP: Session Initiation Protocol June 2002 At the end of the call, Bob disconnects (hangs up) first and generates a BYE message. This BYE is routed directly to Alice's softphone, again bypassing the proxies. Alice confirms receipt of the BYE with a 200 (OK) response, which terminates the session and the BYE transaction. No ACK is sent - an ACK is only sent in response to a response to an INVITE request. The reasons for this special handling for INVITE will be discussed later, but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking. For this reason, request handling in SIP is often classified as either INVITE or non- INVITE, referring to all other methods besides INVITE. Full details on session termination are in Section 15. Section 24.2 describes the messages shown in Figure 1 in full. In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session. For example, if the biloxi.com proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record- Route that contained a URI resolving to the hostname or IP address of the proxy. This information would be received by both Bob's SIP phone and (due to the Record-Route header field being passed back in the 200 (OK)) Alice's softphone and stored for the duration of the dialog. The biloxi.com proxy server would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently decide to receive subsequent messages, and those messages will pass through all proxies that elect to receive it. This capability is frequently used for proxies that are providing mid-call features. Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). The registrar writes this association, also called a binding, to a database, called the location service, where it can be used by the proxy in the biloxi.com domain. Often, a registrar server for a domain is co-located with the proxy for that domain. It is an important concept that the distinction between types of SIP servers is logical, not physical. Bob is not limited to registering from a single device. For example, both his SIP phone at home and the one in the office could send registrations. This information is stored together in the location Rosenberg, et. al. Standards Track [Page 17] RFC 3261 SIP: Session Initiation Protocol June 2002 service and allows a proxy to perform various types of searches to locate Bob. Similarly, more than one user can be registered on a single device at the same time. The location service is just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs that tell the proxy where to send the request. Registrations are one way to create this information, but not the only way. Arbitrary mapping functions can be configured at the discretion of the administrator. Finally, it is important to note that in SIP, registration is used for routing incoming SIP requests and has no role in authorizing outgoing requests. Authorization and authentication are handled in SIP either on a request-by-request basis with a challenge/response mechanism, or by using a lower layer scheme as discussed in Section 26. The complete set of SIP message details for this registration example is in Section 24.1. Additional operations in SIP, such as querying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL, will be introduced in later sections. 5 Structure of the Protocol SIP is structured as a layered protocol, which means that its behavior is described in terms of a set of fairly independent processing stages with only a loose coupling between each stage. The protocol behavior is described as layers for the purpose of presentation, allowing the description of functions common across elements in a single section. It does not dictate an implementation in any way. When we say that an element ""contains"" a layer, we mean it is compliant to the set of rules defined by that layer. Not every element specified by the protocol contains every layer. Furthermore, the elements specified by SIP are logical elements, not physical ones. A physical realization can choose to act as different logical elements, perhaps even on a transaction-by-transaction basis. The lowest layer of SIP is its syntax and encoding. Its encoding is specified using an augmented Backus-Naur Form grammar (BNF). The complete BNF is specified in Section 25; an overview of a SIP message's structure can be found in Section 7. Rosenberg, et. al. Standards Track [Page 18] RFC 3261 SIP: Session Initiation Protocol June 2002 The second layer is the transport layer. It defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network. All SIP elements contain a transport layer. The transport layer is described in Section 18. The third layer is the transaction layer. Transactions are a fundamental component of SIP. A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions. Discussion of transactions can be found in Section 17. User agents contain a transaction layer, as do stateful proxies. Stateless proxies do not contain a transaction layer. The transaction layer has a client component (referred to as a client transaction) and a server component (referred to as a server transaction), each of which are represented by a finite state machine that is constructed to process a particular request. The layer above the transaction layer is called the transaction user (TU). Each of the SIP entities, except the stateless proxy, is a transaction user. When a TU wishes to send a request, it creates a client transaction instance and passes it the request along with the destination IP address, port, and transport to which to send the request. A TU that creates a client transaction can also cancel it. When a client cancels a transaction, it requests that the server stop further processing, revert to the state that existed before the transaction was initiated, and generate a specific error response to that transaction. This is done with a CANCEL request, which constitutes its own transaction, but references the transaction to be cancelled (Section 9). The SIP elements, that is, user agent clients and servers, stateless and stateful proxies and registrars, contain a core that distinguishes them from each other. Cores, except for the stateless proxy, are transaction users. While the behavior of the UAC and UAS cores depends on the method, there are some common rules for all methods (Section 8). For a UAC, these rules govern the construction of a request; for a UAS, they govern the processing of a request and generating a response. Since registrations play an important role in SIP, a UAS that handles a REGISTER is given the special name registrar. Section 10 describes UAC and UAS core behavior for the REGISTER method. Section 11 describes UAC and UAS core behavior for the OPTIONS method, used for determining the capabilities of a UA. Rosenberg, et. al. Standards Track [Page 19] RFC 3261 SIP: Session Initiation Protocol June 2002 Certain other requests are sent within a dialog. A dialog is a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages and proper routing of requests between the user agents. The INVITE method is the only way defined in this specification to establish a dialog. When a UAC sends a request that is within the context of a dialog, it follows the common UAC rules as discussed in Section 8 but also the rules for mid-dialog requests. Section 12 discusses dialogs and presents the procedures for their construction and maintenance, in addition to construction of requests within a dialog. The most important method in SIP is the INVITE method, which is used to establish a session between participants. A session is a collection of participants, and streams of media between them, for the purposes of communication. Section 13 discusses how sessions are initiated, resulting in one or more SIP dialogs. Section 14 discusses how characteristics of that session are modified through the use of an INVITE request within a dialog. Finally, section 15 discusses how a session is terminated. The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal entirely with the UA core (Section 9 describes cancellation, which applies to both UA core and proxy core). Section 16 discusses the proxy element, which facilitates routing of messages between user agents. 6 Definitions The following terms have special significance for SIP. Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the ""public address"" of the user. Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. Rosenberg, et. al. Standards Track [Page 20] RFC 3261 SIP: Session Initiation Protocol June 2002 Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Call Leg: Another name for a dialog [31]; no longer used in this specification. Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true. Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients. Conference: A multimedia session (see below) that contains multiple participants. Core: Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users. Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543. Downstream: A direction of message forwarding within a transaction that refers to the direction that requests flow from the user agent client to user agent server. Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final. Header: A header is a component of a SIP message that conveys information about the message. It is structured as a sequence of header fields. Header Field: A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a Rosenberg, et. al. Standards Track [Page 21] RFC 3261 SIP: Session Initiation Protocol June 2002 given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row. Header Field Value: A header field value is a single value; a header field consists of zero or more header field values. Home Domain: The domain providing service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of a registration. Informational Response: Same as a provisional response. Initiator, Calling Party, Caller: The party initiating a session (and dialog) with an INVITE request. A caller retains this role from the time it sends the initial INVITE that established a dialog until the termination of that dialog. Invitation: An INVITE request. Invitee, Invited User, Called Party, Callee: The party that receives an INVITE request for the purpose of establishing a new session. A callee retains this role from the time it receives the INVITE until the termination of the dialog established by that INVITE. Location Service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings. Loop: A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors, and the procedures for detecting them and handling them are described by the protocol. Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from Rosenberg, et. al. Standards Track [Page 22] RFC 3261 SIP: Session Initiation Protocol June 2002 the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router. Message: Data sent between SIP elements as part of the protocol. SIP messages are either requests or responses. Method: The method is the primary function that a request is meant to invoke on a server. The method is carried in the request message itself. Example methods are INVITE and BYE. Outbound Proxy: A proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols. Parallel Search: In a parallel search, a proxy issues several requests to possible user locations upon receiving an incoming request. Rather than issuing one request and then waiting for the final response before issuing the next request as in a sequential search, a parallel search issues requests without waiting for the result of previous requests. Provisional Response: A response used by the server to indicate progress, but that does not terminate a SIP transaction. 1xx responses are provisional, other responses are considered final. Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity ""closer"" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. Recursion: A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response."
"Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs. Rosenberg, et. al. Standards Track [Page 23] RFC 3261 SIP: Session Initiation Protocol June 2002 Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. Regular Transaction: A regular transaction is any transaction with a method other than INVITE, ACK, or CANCEL. Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation. Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server. Ringback: Ringback is the signaling tone produced by the calling party's application indicating that a called party is being alerted (ringing). Route Set: A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured. Server: A server is a network element that receives requests in order to service them and sends back responses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and registrars. Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, proceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final response always terminates a sequential search. Session: From the SDP specification: ""A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session."" (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP sessions.) As defined, a callee can be invited several times, by different calls, to the same session. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field. SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response Rosenberg, et. al. Standards Track [Page 24] RFC 3261 SIP: Session Initiation Protocol June 2002 sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. Spiral: A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls joe@example.com. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to bob@example.com. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition. Stateful Proxy: A logical entity that maintains the client and server transaction state machines defined by this specification during the processing of a request, also known as a transaction stateful proxy. The behavior of a stateful proxy is further defined in Section 16. A (transaction) stateful proxy is not the same as a call stateful proxy. Stateless Proxy: A logical entity that does not maintain the client or server transaction state machines defined in this specification when it processes requests. A stateless proxy forwards every request it receives downstream and every response it receives upstream. Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in this specification, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers. Target Refresh Request: A target refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog. Transaction User (TU): The layer of protocol processing that resides above the transaction layer. Transaction users include the UAC core, UAS core, and proxy core. Rosenberg, et. al. Standards Track [Page 25] RFC 3261 SIP: Session Initiation Protocol June 2002 Upstream: A direction of message forwarding within a transaction that refers to the direction that responses flow from the user agent server back to the user agent client. URL-encoded: A character string encoded according to RFC 2396, Section 2.4 [5]. User Agent Client (UAC): A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction. UAC Core: The set of processing functions required of a UAC that reside above the transaction and transport layers. User Agent Server (UAS): A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction. UAS Core: The set of processing functions required at a UAS that resides above the transaction and transport layers. User Agent (UA): A logical entity that can act as both a user agent client and user agent server. The role of UAC and UAS, as well as proxy and redirect servers, are defined on a transaction-by-transaction basis. For example, the user agent initiating a call acts as a UAC when sending the initial INVITE request and as a UAS when receiving a BYE request from the callee. Similarly, the same software can act as a proxy server for one request and as a redirect server for the next request. Proxy, location, and registrar servers defined above are logical entities; implementations MAY combine them into a single application. 7 SIP Messages SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 [7]). Rosenberg, et. al. Standards Track [Page 26] RFC 3261 SIP: Session Initiation Protocol June 2002 A SIP message is either a request from a client to a server, or a response from a server to a client. Both Request (section 7.1) and Response (section 7.2) messages use the basic format of RFC 2822 [3], even though the syntax differs in character set and syntax specifics. (SIP allows header fields that would not be valid RFC 2822 header fields, for example.) Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body. generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not. Except for the above difference in character sets, much of SIP's message and header field syntax is identical to HTTP/1.1. Rather than repeating the syntax and semantics here, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). However, SIP is not an extension of HTTP. 7.1 Requests SIP requests are distinguished by having a Request-Line for a start- line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character. The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements. Request-Line = Method SP Request-URI SP SIP-Version CRLF Method: This specification defines six methods: REGISTER for registering contact information, INVITE, ACK, and CANCEL for setting up sessions, BYE for terminating sessions, and OPTIONS for querying servers about their capabilities. SIP extensions, documented in standards track RFCs, may define additional methods. Rosenberg, et. al. Standards Track [Page 27] RFC 3261 SIP: Session Initiation Protocol June 2002 Request-URI: The Request-URI is a SIP or SIPS URI as described in Section 19.1 or a general URI (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in ""<>"". SIP elements MAY support Request-URIs with schemes other than ""sip"" and ""sips"", for example the ""tel"" URI scheme of RFC 2806 [9]. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme. SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP-Version of ""SIP/2.0"". The SIP-Version string is case-insensitive, but implementations MUST send upper-case. Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference. 7.2 Responses SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character. No CR or LF is allowed except in the final CRLF sequence. Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase. While this specification suggests specific wording for the reason phrase, implementations MAY choose other text, for example, in the language indicated in the Accept-Language header field of the request. Rosenberg, et. al. Standards Track [Page 28] RFC 3261 SIP: Session Initiation Protocol June 2002 The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a ""1xx response"", any response with a status code between 200 and 299 as a ""2xx response"", and so on. SIP/2.0 allows six values for the first digit: 1xx: Provisional -- request received, continuing to process the request; 2xx: Success -- the action was successfully received, understood, and accepted; 3xx: Redirection -- further action needs to be taken in order to complete the request; 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error -- the server failed to fulfill an apparently valid request; 6xx: Global Failure -- the request cannot be fulfilled at any server. Section 21 defines these classes and describes the individual codes. 7.3 Header Fields SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding. This specification conforms to RFC 2234 [10] and uses only explicit whitespace and folding as an integral part of the grammar. [H4.2] also specifies that multiple header fields of the same field name whose value is a comma-separated list can be combined into one header field. That applies to SIP as well, but the specific rule is different because of the different grammars. Specifically, any SIP header whose grammar is of the form header = ""header-name"" HCOLON header-value *(COMMA header-value) allows for combining header fields of the same name into a comma- separated list. The Contact header field allows a comma-separated list unless the header field value is ""*"". Rosenberg, et. al. Standards Track [Page 29] RFC 3261 SIP: Session Initiation Protocol June 2002 7.3.1 Header Field Format Header fields follow the same generic header format as that given in Section 2.2 of RFC 2822 [3]. Each header field consists of a field name followed by a colon ("":"") and the field value. field-name: field-value The formal grammar for a message-header specified in Section 25 allows for an arbitrary amount of whitespace on either side of the colon; however, implementations should avoid spaces between the field name and the colon and use a single space (SP) between the colon and the field-value. Subject: lunch Subject : lunch Subject :lunch Subject: lunch Thus, the above are all valid and equivalent, but the last is the preferred form. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a single SP character. Thus, the following are equivalent: Subject: I know you're there, pick up the phone and talk to me! Subject: I know you're there, pick up the phone and talk to me! The relative order of header fields with different field names is not significant. However, it is RECOMMENDED that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing. The relative order of header field rows with the same field name is important. Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one ""field-name: field-value"" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. Multiple header Rosenberg, et. al. Standards Track [Page 30] RFC 3261 SIP: Session Initiation Protocol June 2002 field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row. Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms. The following groups of header field rows are valid and equivalent: Route: <sip:alice@atlanta.com> Subject: Lunch Route: <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Subject: Lunch Subject: Lunch Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com> Each of the following blocks is valid but not equivalent to the others: Route: <sip:alice@atlanta.com> Route: <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Route: <sip:bob@biloxi.com> Route: <sip:alice@atlanta.com> Route: <sip:carol@chicago.com> Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, <sip:bob@biloxi.com> The format of a header field-value is defined per header-name. It will always be either an opaque sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators, and quoted strings. Many existing header fields will adhere to the general form of a value followed by a semi-colon separated sequence of parameter-name, parameter-value pairs: field-name: field-value *(;parameter-name=parameter-value) Rosenberg, et. al. Standards Track [Page 31] RFC 3261 SIP: Session Initiation Protocol June 2002 Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name MUST NOT appear more than once. When comparing header fields, field names are always case- insensitive. Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. For example, Contact: <sip:alice@atlanta.com>;expires=3600 is equivalent to CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600 and Content-Disposition: session;handling=optional is equivalent to content-disposition: Session;HANDLING=OPTIONAL The following two header fields are not equivalent: Warning: 370 devnull ""Choose a bigger pipe"" Warning: 370 devnull ""CHOOSE A BIGGER PIPE"" 7.3.2 Header Field Classification Some header fields only make sense in requests or responses. These are called request header fields and response header fields, respectively. If a header field appears in a message not matching its category (such as a request header field in a response), it MUST be ignored. Section 20 defines the classification of each header field. 7.3.3 Compact Form SIP provides a mechanism to represent common header field names in an abbreviated form. This may be useful when messages would otherwise become too large to be carried on the transport available to it (exceeding the maximum transmission unit (MTU) when using UDP, for example). These compact forms are defined in Section 20. A compact form MAY be substituted for the longer form of a header field name at any time without changing the semantics of the message. A header Rosenberg, et. al. Standards Track [Page 32] RFC 3261 SIP: Session Initiation Protocol June 2002 field name MAY appear in both long and short forms within the same message. Implementations MUST accept both the long and short forms of each header name. 7.4 Bodies Requests, including new requests defined in extensions to this specification, MAY contain message bodies unless otherwise noted. The interpretation of the body depends on the request method. For response messages, the request method and the response status code determine the type and interpretation of any message body. All responses MAY include a body. 7.4.1 Message Body Type The Internet media type of the message body MUST be given by the Content-Type header field. If the body has undergone any encoding such as compression, then this MUST be indicated by the Content- Encoding header field; otherwise, Content-Encoding MUST be omitted. If applicable, the character set of the message body is indicated as part of the Content-Type header-field value. The ""multipart"" MIME type defined in RFC 2046 [11] MAY be used within the body of the message. Implementations that send requests containing multipart message bodies MUST send a session description as a non-multipart message body if the remote implementation requests this through an Accept header field that does not contain multipart. SIP messages MAY contain binary bodies or body parts. When no explicit charset parameter is provided by the sender, media subtypes of the ""text"" type are defined to have a default charset value of ""UTF-8"". 7.4.2 Message Body Length The body length in bytes is provided by the Content-Length header field. Section 20.14 describes the necessary contents of this header field in detail. The ""chunked"" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. (Note: The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator.) Rosenberg, et. al. Standards Track [Page 33] RFC 3261 SIP: Session Initiation Protocol June 2002 7.5 Framing SIP Messages Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols. Each such datagram carries one request or response. See Section 18 on constraints on usage of unreliable transports. Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line [H4.1]. The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports. 8 General User Agent Behavior A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them. A UAC is capable of generating a request based on some external stimulus (the user clicking a button, or a signal on a PSTN line) and processing a response. A UAS is capable of receiving a request and generating a response based on user input, external stimulus, the result of a program execution, or some other mechanism. When a UAC sends a request, the request passes through some number of proxy servers, which forward the request towards the UAS. When the UAS generates a response, the response is forwarded towards the UAC. UAC and UAS procedures depend strongly on two factors. First, based on whether the request or response is inside or outside of a dialog, and second, based on the method of a request. Dialogs are discussed thoroughly in Section 12; they represent a peer-to-peer relationship between user agents and are established by specific SIP methods, such as INVITE. In this section, we discuss the method-independent rules for UAC and UAS behavior when processing requests that are outside of a dialog. This includes, of course, the requests which themselves establish a dialog. Security procedures for requests and responses outside of a dialog are described in Section 26. Specifically, mechanisms exist for the UAS and UAC to mutually authenticate. A limited set of privacy features are also supported through encryption of bodies using S/MIME. Rosenberg, et. al. Standards Track [Page 34] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1 UAC Behavior This section covers UAC behavior outside of a dialog. 8.1.1 Generating the Request A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions. These header fields are in addition to the mandatory request line, which contains the method, Request-URI, and SIP version. Examples of requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11). 8.1.1.1 Request-URI The initial Request-URI of the message SHOULD be set to the value of the URI in the To field. One notable exception is the REGISTER method; behavior for setting the Request-URI of REGISTER is given in Section 10. It may also be undesirable for privacy reasons or convenience to set these fields to the same value (especially if the originating UA expects that the Request-URI will be changed during transit). In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI. Rosenberg, et. al. Standards Track [Page 35] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.2 To The To header field first and foremost specifies the desired ""logical"" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field MAY contain a SIP or SIPS URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme. The To header field allows for a display name. A UAC may learn how to populate the To header field for a particular request in a number of ways. Usually the user will suggest the To header field through a human interface, perhaps inputting the URI manually or selecting it from some sort of address book. Frequently, the user will not enter a complete URI, but rather a string of digits or letters (for example, ""bob""). It is at the discretion of the UA to choose how to interpret this input. Using the string to form the user part of a SIP URI implies that the UA wishes the name to be resolved in the domain to the right-hand side (RHS) of the at-sign in the SIP URI (for instance, sip:bob@example.com). Using the string to form the user part of a SIPS URI implies that the UA wishes to communicate securely, and that the name is to be resolved in the domain to the RHS of the at-sign. The RHS will frequently be the home domain of the requestor, which allows for the home domain to process the outgoing request. This is useful for features like ""speed dial"" that require interpretation of the user part in the home domain. The tel URL may be used when the UA does not wish to specify the domain that should interpret a telephone number that has been input by the user. Rather, each domain through which the request passes would be given that opportunity. As an example, a user in an airport might log in and send requests through an outbound proxy in the airport. If they enter ""411"" (this is the phone number for local directory assistance in the United States), that needs to be interpreted and processed by the outbound proxy in the airport, not the user's home domain. In this case, tel:411 would be the right choice. A request outside of a dialog MUST NOT contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog is established, no tag is present. For further information on the To header field, see Section 20.39. The following is an example of a valid To header field: To: Carol <sip:carol@chicago.com> Rosenberg, et. al. Standards Track [Page 36] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.3 From The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by SIP elements to determine which processing rules to apply to a request (for example, automatic call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names. The From header field allows for a display name. A UAC SHOULD use the display name ""Anonymous"", along with a syntactically correct, but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the identity of the client is to remain hidden. Usually, the value that populates the From header field in requests generated by a particular UA is pre-provisioned by the user or by the administrators of the user's local domain. If a particular UA is used by multiple users, it might have switchable profiles that include a URI corresponding to the identity of the profiled user. Recipients of requests can authenticate the originator of a request in order to ascertain that they are who their From header field claims they are (see Section 22 for more on authentication). The From field MUST contain a new ""tag"" parameter, chosen by the UAC. See Section 19.3 for details on choosing a tag. For further information on the From header field, see Section 20.20. Examples: From: ""Bob"" <sips:bob@biloxi.com> ;tag=a48s From: sip:+12125551212@phone2net.com;tag=887s From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA. In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. Note that when requests are retried after certain Rosenberg, et. al. Standards Track [Page 37] RFC 3261 SIP: Session Initiation Protocol June 2002 failure responses that solicit an amendment to a request (for example, a challenge for authentication), these retried requests are not considered new requests, and therefore do not need new Call-ID header fields; see Section 8.1.3.5. Use of cryptographically random identifiers (RFC 1750 [12]) in the generation of Call-IDs is RECOMMENDED. Implementations MAY use the form ""localid@host"". Call-IDs are case-sensitive and are simply compared byte-by-byte. Using cryptographically random identifiers provides some protection against session hijacking and reduces the likelihood of unintentional Call-ID collisions. No provisioning or human interface is required for the selection of the Call-ID header field value for a request. For further information on the Call-ID header field, see Section 20.8. Example: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com 8.1.1.5 CSeq The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values. Section 12.2.1.1 discusses construction of the CSeq for requests within a dialog. Example: CSeq: 4711 INVITE Rosenberg, et. al. Standards Track [Page 38] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.6 Max-Forwards The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response. A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. This number was chosen to be sufficiently large to guarantee that a request would not be dropped in any SIP network when there were no loops, but not so large as to consume proxy resources when a loop does occur. Lower values should be used with caution and only in networks where topologies are known by the UA. 8.1.1.7 Via The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected (which may involve the usage of the procedures in [4]). When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server. The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges. The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC 2543. The branch ID inserted by an element compliant with this specification MUST always begin with the characters ""z9hG4bK"". These 7 characters are used as a magic cookie (7 is deemed sufficient to ensure that an older RFC 2543 implementation would not pick such a value), so that servers receiving the request can determine that the branch ID was constructed in the fashion described by this Rosenberg, et. al. Standards Track [Page 39] RFC 3261 SIP: Session Initiation Protocol June 2002 specification (that is, globally unique). Beyond this requirement, the precise format of the branch token is implementation-defined. The Via header maddr, ttl, and sent-by components will be set when the request is processed by the transport layer (Section 18). Via processing for proxies is described in Section 16.6 Item 8 and Section 16.7 Item 3. 8.1.1.8 Contact The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. For further information on the Contact header field, see Section 20.10. 8.1.1.9 Supported and Require If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a Supported header field in the request listing the option tags (Section 19.2) for those extensions. The option tags listed MUST only refer to extensions defined in standards-track RFCs. This is to prevent servers from insisting that clients implement non-standard, vendor-defined features in order to receive service. Extensions defined by experimental and informational RFCs are explicitly excluded from usage with the Supported header field in a request, since they too are often used to document vendor-defined extensions. If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request in order to process the request, it MUST insert a Require header field into the request listing the option tag for that extension. If the UAC wishes to apply an extension to the request and insist that any proxies that are Rosenberg, et. al. Standards Track [Page 40] RFC 3261 SIP: Session Initiation Protocol June 2002 traversed understand that extension, it MUST insert a Proxy-Require header field into the request listing the option tag for that extension. As with the Supported header field, the option tags in the Require and Proxy-Require header fields MUST only refer to extensions defined in standards-track RFCs. 8.1.1.10 Additional Message Components After a new request has been created, and the header fields described above have been properly constructed, any additional optional header fields are added, as are any header fields specific to the method. SIP requests MAY contain a MIME-encoded message-body. Regardless of the type of body that a request contains, certain header fields must be formulated to characterize the contents of the body. For further information on these header fields, see Sections 20.11 through 20.15. 8.1.2 Sending the Request The destination for the request is then computed. Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. If the first element in the route set indicated a strict router (resulting in forming the request as described in Section 12.2.1.1), the procedures MUST be applied to the Request-URI of the request."
"Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present. These procedures yield an ordered set of address, port, and transports to attempt. Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI. Local policy MAY specify an alternate set of destinations to attempt. If the Request-URI contains a SIPS URI, any alternate destinations MUST be contacted with TLS. Beyond that, there are no restrictions on the alternate destinations if the request contains no Route header field. This provides a simple alternative to a pre-existing route set as a way to specify an outbound proxy. However, that approach for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing route set with a single URI SHOULD be used instead. If the request contains a Route header field, the request SHOULD be sent to the locations derived from its topmost value, but MAY be sent to any server that the UA is certain will honor the Route and Request-URI policies specified in this document (as opposed to those in RFC 2543). In particular, a UAC configured with an outbound proxy SHOULD Rosenberg, et. al. Standards Track [Page 41] RFC 3261 SIP: Session Initiation Protocol June 2002 attempt to send the request to the location indicated in the first Route header field value instead of adopting the policy of sending all messages to the outbound proxy. This ensures that outbound proxies that do not add Record-Route header field values will drop out of the path of subsequent requests. It allows endpoints that cannot resolve the first Route URI to delegate that task to an outbound proxy. The UAC SHOULD follow the procedures defined in [4] for stateful elements, trying each address until a server is contacted. Each try constitutes a new transaction, and therefore each carries a different topmost Via header field value with a new branch parameter. Furthermore, the transport value in the Via header field is set to whatever transport was determined for the target server. 8.1.3 Processing Responses Responses are first processed by the transport layer and then passed up to the transaction layer. The transaction layer performs its processing and then passes the response up to the TU. The majority of response processing in the TU is method specific. However, there are some general behaviors independent of the method. 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. 8.1.3.2 Unrecognized Responses A UAC MUST treat any final response it does not recognize as being equivalent to the x00 response code of that class, and MUST be able to process the x00 response code for all classes. For example, if a UAC receives an unrecognized response code of 431, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) response code. A UAC MUST treat any provisional response different than 100 that it does not recognize as 183 (Session Progress). A UAC MUST be able to process 100 and 183 responses. Rosenberg, et. al. Standards Track [Page 42] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.3.3 Vias If more than one Via header field value is present in a response, the UAC SHOULD discard the message. The presence of additional Via header field values that precede the originator of the request suggests that the message was misrouted or possibly corrupted. 8.1.3.4 Processing 3xx Responses Upon receipt of a redirection response (for example, a 301 response status code), clients SHOULD use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request. This process is similar to that of a proxy recursing on a 3xx class response as detailed in Sections 16.5 and 16.6. A client starts with an initial target set containing exactly one URI, the Request-URI of the original request. If a client wishes to formulate new requests based on a 3xx class response to that request, it places the URIs to try into the target set. Subject to the restrictions in this specification, a client can choose which Contact URIs it places into the target set. As with proxy recursion, a client processing 3xx class responses MUST NOT add any given URI to the target set more than once. If the original request had a SIPS URI in the Request- URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI. Any new request may receive 3xx responses themselves containing the original URI as a contact. Two locations can be configured to redirect to each other. Placing any given URI in the target set only once prevents infinite redirection loops. As the target set grows, the client MAY generate new requests to the URIs in any order. A common mechanism is to order the set by the ""q"" parameter value from the Contact header field value. Requests to the URIs MAY be generated serially or in parallel. One approach is to process groups of decreasing q-values serially and process the URIs in each q-value group in parallel. Another is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value. If contacting an address in the list results in a failure, as defined in the next paragraph, the element moves to the next address in the list, until the list is exhausted. If the list is exhausted, then the request has failed. Rosenberg, et. al. Standards Track [Page 43] RFC 3261 SIP: Session Initiation Protocol June 2002 Failures SHOULD be detected through failure response codes (codes greater than 399); for network errors the client transaction will report any transport layer failures to the transaction user. Note that some response codes (detailed in 8.1.3.5) indicate that the request can be retried; requests that are reattempted should not be considered failures. When a failure for a particular contact address is received, the client SHOULD try the next contact address. This will involve creating a new client transaction to deliver a new request. In order to create a request based on a contact address in a 3xx response, a UAC MUST copy the entire URI from the target set into the Request-URI, except for the ""method-param"" and ""header"" URI parameters (see Section 19.1.1 for a definition of these parameters). It uses the ""header"" parameters to create header field values for the new request, overwriting header field values associated with the redirected request in accordance with the guidelines in Section 19.1.5. Note that in some instances, header fields that have been communicated in the contact address may instead append to existing request header fields in the original redirected request. As a general rule, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple values, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address. For example, if a contact address is returned with the following value: sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> Then any Subject header field in the original redirected request is overwritten, but the HTTP URL is merely appended to any existing Call-Info header field values. It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example. Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field as discussed in Section 8.1.1.7. Rosenberg, et. al. Standards Track [Page 44] RFC 3261 SIP: Session Initiation Protocol June 2002 In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request. In some instances, Contact header field values may be cached at UAC temporarily or permanently depending on the status code received and the presence of an expiration interval; see Sections 21.3.2 and 21.3.3. 8.1.3.5 Processing 4xx Responses Certain 4xx response codes require specific UA processing, independent of the method. If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC SHOULD follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials. If a 413 (Request Entity Too Large) response is received (Section 21.4.11), the request contained a body that was longer than the UAS was willing to accept. If possible, the UAC SHOULD retry the request, either omitting the body or using one of a smaller length. If a 415 (Unsupported Media Type) response is received (Section 21.4.13), the request contained media types not supported by the UAS. The UAC SHOULD retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response. If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14), the Request-URI used a URI scheme not supported by the server. The client SHOULD retry the request, this time, using a SIP URI. If a 420 (Bad Extension) response is received (Section 21.4.15), the request contained a Require or Proxy-Require header field listing an option-tag for a feature not supported by a proxy or UAS. The UAC SHOULD retry the request, this time omitting any extensions listed in the Unsupported header field in the response. In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. Rosenberg, et. al. Standards Track [Page 45] RFC 3261 SIP: Session Initiation Protocol June 2002 With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case. 8.2 UAS Behavior When a request outside of a dialog is processed by a UAS, there is a set of processing rules that are followed, independent of the method. Section 12 gives guidance on how a UAS can tell whether a request is inside or outside of a dialog. Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed. UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section). 8.2.1 Method Inspection Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request. If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response. Procedures for generating responses are described in Section 8.2.6. The UAS MUST also add an Allow header field to the 405 (Method Not Allowed) response. The Allow header field MUST list the set of methods supported by the UAS generating the message. The Allow header field is presented in Section 20.5. If the method is one supported by the server, processing continues. 8.2.2 Header Inspection If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. A UAS SHOULD ignore any malformed header fields that are not necessary for processing requests. 8.2.2.1 To and Request-URI The To header field identifies the original recipient of the request designated by the user identified in the From field. The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations. A UAS MAY apply any policy it wishes to determine whether to accept requests when the To Rosenberg, et. al. Standards Track [Page 46] RFC 3261 SIP: Session Initiation Protocol June 2002 header field is not the identity of the UAS. However, it is RECOMMENDED that a UAS accept requests even if they do not recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field does not address a known or current user of this UAS. If, on the other hand, the UAS decides to reject the request, it SHOULD generate a response with a 403 (Forbidden) status code and pass it to the server transaction for transmission. However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response. If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. Typically, a UA that uses the REGISTER method to bind its address-of-record to a specific contact address will see requests whose Request-URI equals that contact address. Other potential sources of received Request-URIs include the Contact header fields of requests and responses sent by the UA that establish or refresh dialogs. 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. 8.2.2.3 Require Assuming the UAS decides that it is the proper element to process the request, it examines the Require header field, if present. The Require header field is used by a UAC to tell a UAS about SIP extensions that the UAC expects the UAS to support in order to process the request properly. Its format is described in Section 20.32. If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). The UAS MUST add an Unsupported header field, and list in it those options it does not understand amongst those in the Require header field of the request. Rosenberg, et. al. Standards Track [Page 47] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response. These header fields MUST be ignored if they are present in these requests. An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request. Example: UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems. 8.2.3 Content Processing Assuming the UAS understands any extensions required by the client, the UAS examines the body of the message, and the header fields that describe it. If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content- Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. The response MUST contain an Accept header field listing the types of all bodies it understands, in the event the request contained bodies of types not supported by the UAS. If the request contained content encodings not understood by the UAS, the response MUST contain an Accept-Encoding header field listing the encodings understood by the UAS. If the request contained content with languages not understood by the UAS, the response MUST contain an Accept-Language header field indicating the languages understood by the UAS. Beyond these checks, body handling depends on the method and type. For further information on the processing of content-specific header fields, see Section 7.4 as well as Section 20.11 through 20.15. Rosenberg, et. al. Standards Track [Page 48] RFC 3261 SIP: Session Initiation Protocol June 2002 8.2.4 Applying Extensions A UAS that wishes to apply some extension when generating the response MUST NOT do so unless support for that extension is indicated in the Supported header field in the request. If the desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. In rare circumstances, where the server cannot process the request without the extension, the server MAY send a 421 (Extension Required) response. This response indicates that the proper response cannot be generated without support of a specific extension. The needed extension(s) MUST be included in a Require header field in the response. This behavior is NOT RECOMMENDED, as it will generally break interoperability. Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. As a result of this, the Require header field in a response will only ever contain option tags defined in standards- track RFCs. 8.2.5 Processing the Request Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method-specific. Section 10 covers the REGISTER request, Section 11 covers the OPTIONS request, Section 13 covers the INVITE request, and Section 15 covers the BYE request. 8.2.6 Generating the Response When a UAS wishes to construct a response to a request, it follows the general procedures detailed in the following subsections. Additional behaviors specific to the response code in question, which are not detailed in this section, may also be required. Once all procedures associated with the creation of a response have been completed, the UAS hands the response back to the server transaction from which it received the request. 8.2.6.1 Sending a Provisional Response One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible. Rosenberg, et. al. Standards Track [Page 49] RFC 3261 SIP: Session Initiation Protocol June 2002 When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response. If there is a delay in generating the response, the UAS SHOULD add a delay value into the Timestamp value in the response. This value MUST contain the difference between the time of sending of the response and receipt of the request, measured in seconds. 8.2.6.2 Headers and Tags The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering. If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). Procedures for the generation of tags are defined in Section 19.3. 8.2.7 Stateless UAS Behavior A stateless UAS is a UAS that does not maintain transaction state. It replies to requests normally, but discards any state that would ordinarily be retained by a UAS after a response has been sent. If a stateless UAS receives a retransmission of a request, it regenerates the response and resends it, just as if it were replying to the first instance of the request. A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. This rules out stateless registrars, for example. Stateless UASs do not use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer. The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge response is issued. If unauthenticated requests were handled statefully, then malicious floods of unauthenticated requests could create massive amounts of Rosenberg, et. al. Standards Track [Page 50] RFC 3261 SIP: Session Initiation Protocol June 2002 transaction state that might slow or completely halt call processing in a UAS, effectively creating a denial of service condition; for more information see Section 26.1.5. The most important behaviors of a stateless UAS are the following: o A stateless UAS MUST NOT send provisional (1xx) responses. o A stateless UAS MUST NOT retransmit responses. o A stateless UAS MUST ignore ACK requests. o A stateless UAS MUST ignore CANCEL requests. o To header tags MUST be generated for responses in a stateless manner - in a manner that will generate the same tag for the same request consistently. For information on tag construction see Section 19.3. In all other respects, a stateless UAS behaves in the same manner as a stateful UAS. A UAS can operate in either a stateful or stateless mode for each new request. 8.3 Redirect Servers In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection. Redirection allows servers to push routing information for a request back in a response to the client, thereby taking themselves out of the loop of further messaging for this transaction while still aiding in locating the target of the request. When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability. A redirect server is logically constituted of a server transaction layer and a transaction user that has access to a location service of some kind (see Section 10 for more on registrars and location services). This location service is effectively a database containing mappings between a single URI and a set of one or more alternative locations at which the target of that URI can be found. A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server either refuses the request or gathers the list of alternative locations from the Rosenberg, et. al. Standards Track [Page 51] RFC 3261 SIP: Session Initiation Protocol June 2002 location service and returns a final response of class 3xx. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for an entire SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers. When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alternative locations into the Contact header field. An ""expires"" parameter to the Contact header field values may also be supplied to indicate the lifetime of the Contact data. The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) response may also give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, or a change of SIP transport from UDP to TCP or vice versa. However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404. If a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite redirection loops. Note that a Contact header field value MAY also refer to a different resource than the one originally called. For example, a SIP call connected to PSTN gateway may need to deliver a special informational announcement such as ""The number you have dialed has been changed."" A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URIs. For example, it could contain URIs for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 discusses implications and limitations of redirecting a SIPS URI to a non-SIPS URI. The ""expires"" parameter of a Contact header field value indicates how long the URI is valid. The value of the parameter is a number indicating seconds. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Malformed values SHOULD be treated as equivalent to 3600. Rosenberg, et. al. Standards Track [Page 52] RFC 3261 SIP: Session Initiation Protocol June 2002 This provides a modest level of backwards compatibility with RFC 2543, which allowed absolute times in this header field. If an absolute time is received, it will be treated as malformed, and then default to 3600. Redirect servers MUST ignore features that are not understood (including unrecognized header fields, any unknown option tags in Require, or even method names) and proceed with the redirection of the request in question. 9 Canceling a Request The previous section has discussed general UA behavior for generating requests and processing responses for requests of all methods. In this section, we discuss a general purpose method, called CANCEL. The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would ""stop ringing"", and then respond to the INVITE with a specific error response (a 487). CANCEL requests can be constructed and sent by both proxies and user agent clients. Section 15 discusses under what conditions a UAC would CANCEL an INVITE request, and Section 16.10 discusses proxy usage of CANCEL. A stateful proxy responds to a CANCEL, rather than simply forwarding a response it would receive from a downstream element. For that reason, CANCEL is referred to as a ""hop-by-hop"" request, since it is responded to at each stateful proxy hop. 9.1 Client Behavior A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition. Rosenberg, et. al. Standards Track [Page 53] RFC 3261 SIP: Session Initiation Protocol June 2002 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17). If the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values. This is needed so that stateless proxies are able to route CANCEL requests properly. The CANCEL request MUST NOT contain any Require or Proxy-Require header fields. Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the ""original request""). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. If the original request has generated a final response, the CANCEL SHOULD NOT be sent, as it is an effective no-op, since CANCEL has no effect on requests that have already generated a final response. When the client decides to send the CANCEL, it creates a client transaction for the CANCEL and passes it the CANCEL request along with the destination address, port, and transport. The destination address, port, and transport for the CANCEL MUST be identical to those used to send the original request. If it was allowed to send the CANCEL before receiving a response for the previous request, the server could receive the CANCEL before the original request. Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is Rosenberg, et. al. Standards Track [Page 54] RFC 3261 SIP: Session Initiation Protocol June 2002 defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request. 9.2 Server Behavior The CANCEL method requests that the TU at the server side cancel a pending transaction. The TU determines the transaction to be cancelled by taking the CANCEL request, and then assuming that the request method is anything but CANCEL or ACK and applying the transaction matching procedures of Section 17.2.3. The matching transaction is the one to be cancelled. The processing of a CANCEL request at a server depends on the type of server. A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it. See Section 16.10 for proxy treatment of CANCEL. A UAS first processes the CANCEL request according to the general UAS processing described in Section 8.2. However, since CANCEL requests are hop-by-hop and cannot be resubmitted, they cannot be challenged by the server in order to get proper credentials in an Authorization header field. Note also that CANCEL requests do not contain a Require header field. If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist). If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request. If it has, the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request. If the UAS has not issued a final response for the original request, its behavior depends on the method of the original request. If the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated). A CANCEL request has no impact on the processing of transactions with any other method defined in this specification. Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same. The response to CANCEL is passed to the server transaction for transmission. Rosenberg, et. al. Standards Track [Page 55] RFC 3261 SIP: Session Initiation Protocol June 2002 10 Registrations 10.1 Overview SIP offers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there. To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain. These address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, for example, to one or more URIs that are somehow ""closer"" to the desired user, sip:bob@engineering.biloxi.com, for example. Ultimately, a proxy will consult a location service that maps a received URI to the user agent(s) at which the desired recipient is currently residing. Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. Generally, it only makes sense to register an address-of-record at a domain's location service when requests for that address-of-record would be routed to that domain. In most cases, this means that the domain of the registration will need to match the domain in the URI of the address-of-record. There are many ways by which the contents of the location service can be established. One way is administratively. In the above example, Bob is known to be a member of the engineering department through access to a corporate database. However, SIP provides a mechanism for a UA to create a binding explicitly. This mechanism is known as registration. Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests."
"This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain. An illustration of the overall registration process is given in Figure 2. Note that the registrar and proxy server are logical roles that can be played by a single device in a network; for purposes of Rosenberg, et. al. Standards Track [Page 56] RFC 3261 SIP: Session Initiation Protocol June 2002 clarity the two are separated in this illustration. Also note that UAs may send requests through a proxy server in order to reach a registrar if the two are separate elements. SIP does not mandate a particular mechanism for implementing the location service. The only requirement is that a registrar for some domain MUST be able to read and write data to the location service, and a proxy or a redirect server for that domain MUST be capable of reading that same data. A registrar MAY be co-located with a particular SIP proxy server for the same domain. 10.2 Constructing the REGISTER Request REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding between an address-of-record and one or more contact addresses. Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of- record. Except as noted, the construction of the REGISTER request and the behavior of clients sending a REGISTER request is identical to the general UAC behavior described in Section 8.1 and Section 17.1. A REGISTER request does not establish a dialog. A UAC MAY include a Route header field in a REGISTER request based on a pre-existing route set as described in Section 8.1. The Record-Route header field has no meaning in REGISTER requests or responses, and MUST be ignored if present. In particular, the UAC MUST NOT create a new route set based on the presence or absence of a Record-Route header field in any response to a REGISTER request. The following header fields, except Contact, MUST be included in a REGISTER request. A Contact header field MAY be included: Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example, ""sip:chicago.com""). The ""userinfo"" and ""@"" components of the SIP URI MUST NOT be present. To: The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name. This address-of-record MUST be a SIP URI or SIPS URI. Rosenberg, et. al. Standards Track [Page 57] RFC 3261 SIP: Session Initiation Protocol June 2002 From: The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a third- party registration. Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar. If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order. CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID. Contact: REGISTER requests MAY contain a Contact header field with zero or more values containing address bindings. UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out. Rosenberg, et. al. Standards Track [Page 58] RFC 3261 SIP: Session Initiation Protocol June 2002 bob +----+ | UA | | | +----+ | |3)INVITE | carol@chicago.com chicago.com +--------+ V +---------+ 2)Store|Location|4)Query +-----+ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com +---------+ +--------+=======>+-----+ A 5)Resp | | | | | 1)REGISTER| | | | +----+ | | UA |<-------------------------------+ cube2214a| | 6)INVITE +----+ carol@cube2214a.chicago.com carol Figure 2: REGISTER example The following Contact header parameters have a special meaning in REGISTER requests: action: The ""action"" parameter from RFC 2543 has been deprecated. UACs SHOULD NOT use the ""action"" parameter. expires: The ""expires"" parameter indicates how long the UA would like the binding to be valid. The value is a number indicating seconds. If this parameter is not provided, the value of the Expires header field is used instead. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. Malformed values SHOULD be treated as equivalent to 3600. 10.2.1 Adding Bindings The REGISTER request sent to a registrar includes the contact address(es) to which SIP requests for the address-of-record should be forwarded. The address-of-record is included in the To header field of the REGISTER request. Rosenberg, et. al. Standards Track [Page 59] RFC 3261 SIP: Session Initiation Protocol June 2002 The Contact header field values of the request typically consist of SIP or SIPS URIs that identify particular SIP endpoints (for example, ""sip:carol@cube2214a.chicago.com""), but they MAY use any URI scheme. A SIP UA can choose to register telephone numbers (with the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as Contacts for an address-of-record, for example. For example, Carol, with address-of-record ""sip:carol@chicago.com"", would register with the SIP registrar of the domain chicago.com. Her registrations would then be used by a proxy server in the chicago.com domain to route requests for Carol's address-of-record to her SIP endpoint. Once a client has established bindings at a registrar, it MAY send subsequent registrations containing new bindings or modifications to existing bindings as necessary. The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar. If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS. Registrations do not need to update all bindings. Typically, a UA only updates its own contact addresses. 10.2.1.1 Setting the Expiration Interval of Contact Addresses When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like the registration to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local policy.) There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an ""expires"" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the ""expires"" parameter. Rosenberg, et. al. Standards Track [Page 60] RFC 3261 SIP: Session Initiation Protocol June 2002 If neither mechanism for expressing a suggested expiration time is present in a REGISTER, the client is indicating its desire for the server to choose. 10.2.1.2 Preferences among Contact Addresses If more than one Contact is sent in a REGISTER request, the registering UA intends to associate all of the URIs in these Contact header field values with the address-of-record present in the To field. This list can be prioritized with the ""q"" parameter in the Contact header field. The ""q"" parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record. Section 16.6 describes how a proxy server uses this preference indication. 10.2.2 Removing Bindings Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar as described in Section 10.2.1. A UA requests the immediate removal of a binding by specifying an expiration interval of ""0"" for that contact address in a REGISTER request. UAs SHOULD support this mechanism so that bindings can be removed before their expiration interval has passed. The REGISTER-specific Contact header field value of ""*"" applies to all registrations, but it MUST NOT be used unless the Expires header field is present with a value of ""0"". Use of the ""*"" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values. 10.2.3 Fetching Bindings A success response to any REGISTER request contains the complete list of existing bindings, regardless of whether the request contained a Contact header field. If no Contact header field is present in a REGISTER request, the list of bindings is left unchanged. 10.2.4 Refreshing Bindings Each UA is responsible for refreshing the bindings that it has previously established. A UA SHOULD NOT refresh bindings set up by other UAs. Rosenberg, et. al. Standards Track [Page 61] RFC 3261 SIP: Session Initiation Protocol June 2002 The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request. A UA SHOULD use the same Call-ID for all registrations during a single boot cycle. Registration refreshes SHOULD be sent to the same network address as the original registration, unless redirected. 10.2.5 Setting the Internal Clock If the response for a REGISTER request contains a Date header field, the client MAY use this header field to learn the current time in order to set any internal clocks. 10.2.6 Discovering a Registrar UAs can use three ways to determine the address to which to send registrations: by configuration, using the address-of-record, and multicast. A UA can be configured, in ways beyond the scope of this specification, with a registrar address. If there is no configured registrar address, the UA SHOULD use the host part of the address- of-record as the Request-URI and address the request there, using the normal SIP server location mechanisms [4]. For example, the UA for the user ""sip:carol@chicago.com"" addresses the REGISTER request to ""sip:chicago.com"". Finally, a UA can be configured to use multicast. Multicast registrations are addressed to the well-known ""all SIP servers"" multicast address ""sip.mcast.net"" (224.0.1.75 for IPv4). No well- known IPv6 multicast address has been allocated; such an allocation will be documented separately when needed. SIP UAs MAY listen to that address and use it to become aware of the location of other local users (see [33]); however, they do not respond to the request. Multicast registration may be inappropriate in some environments, for example, if multiple businesses share the same local area network. 10.2.7 Transmitting a Request Once the REGISTER method has been constructed, and the destination of the message identified, UACs follow the procedures described in Section 8.1.2 to hand off the REGISTER to the transaction layer. Rosenberg, et. al. Standards Track [Page 62] RFC 3261 SIP: Session Initiation Protocol June 2002 If the transaction layer returns a timeout error because the REGISTER yielded no response, the UAC SHOULD NOT immediately re-attempt a registration to the same registrar. An immediate re-attempt is likely to also timeout. Waiting some reasonable time interval for the conditions causing the timeout to be corrected reduces unnecessary load on the network. No specific interval is mandated. 10.2.8 Error Responses If a UA receives a 423 (Interval Too Brief) response, it MAY retry the registration after making the expiration interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval within the Min-Expires header field of the 423 (Interval Too Brief) response. 10.3 Processing REGISTER Requests A registrar is a UAS that responds to REGISTER requests and maintains a list of bindings that are accessible to proxy servers and redirect servers within its administrative domain. A registrar handles requests according to Section 8.2 and Section 17.2, but it accepts only REGISTER requests. A registrar MUST not generate 6xx responses. A registrar MAY redirect REGISTER requests as appropriate. One common usage would be for a registrar listening on a multicast interface to redirect multicast REGISTER requests to its own unicast interface with a 302 (Moved Temporarily) response. Registrars MUST ignore the Record-Route header field if it is included in a REGISTER request. Registrars MUST NOT include a Record-Route header field in any response to a REGISTER request. A registrar might receive a request that traversed a proxy which treats REGISTER as an unknown request and which added a Record- Route header field value. A registrar has to know (for example, through configuration) the set of domain(s) for which it maintains bindings. REGISTER requests MUST be processed by a registrar in the order that they are received. REGISTER requests MUST also be processed atomically, meaning that a particular REGISTER request is either processed completely or not at all. Each REGISTER message MUST be processed independently of any other registration or binding changes. Rosenberg, et. al. Standards Track [Page 63] RFC 3261 SIP: Session Initiation Protocol June 2002 When receiving a REGISTER request, a registrar follows these steps: 1. The registrar inspects the Request-URI to determine whether it has access to bindings for the domain identified in the Request-URI. If not, and if the server also acts as a proxy server, the server SHOULD forward the request to the addressed domain, following the general behavior for proxying messages described in Section 16. 2. To guarantee that the registrar supports any necessary extensions, the registrar MUST process the Require header field values as described for UASs in Section 8.2.2. 3. A registrar SHOULD authenticate the UAC. Mechanisms for the authentication of SIP user agents are described in Section 22. Registration behavior in no way overrides the generic authentication framework for SIP. If no authentication mechanism is available, the registrar MAY take the From address as the asserted identity of the originator of the request. 4. The registrar SHOULD determine if the authenticated user is authorized to modify registrations for this address-of-record. For example, a registrar might consult an authorization database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings. If the authenticated user is not authorized to modify bindings, the registrar MUST return a 403 (Forbidden) and skip the remaining steps. In architectures that support third-party registration, one entity may be responsible for updating the registrations associated with multiple addresses-of-record. 5. The registrar extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form. To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings. Rosenberg, et. al. Standards Track [Page 64] RFC 3261 SIP: Session Initiation Protocol June 2002 6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the Contact header field is present, the registrar checks if there is one Contact field value that contains the special value ""*"" and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (Invalid Request) and skip the remaining steps. If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise, the update MUST be aborted and the request fails. 7. The registrar now processes each contact address in the Contact header field in turn. For each address, it determines the expiration interval as follows: - If the field value has an ""expires"" parameter, that value MUST be taken as the requested expiration. - If there is no such parameter, but the request has an Expires header field, that value MUST be taken as the requested expiration. - If there is neither, a locally-configured default value MUST be taken as the requested expiration. The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of 423 (Interval Too Brief). This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. It then skips the remaining steps. Allowing the registrar to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreasing the likelihood of registrations going stale. The expiration interval of a registration is frequently used in the creation of services. An example is a follow-me service, where the user may only be available at a terminal for a brief period. Therefore, registrars should accept brief registrations; a request should only be rejected if the interval is so short that the refreshes would degrade registrar performance. Rosenberg, et. al. Standards Track [Page 65] RFC 3261 SIP: Session Initiation Protocol June 2002 For each address, the registrar then searches the list of current bindings using the URI comparison rules. If the binding does not exist, it is tentatively added. If the binding does exist, the registrar checks the Call-ID value. If the Call-ID value in the existing binding differs from the Call-ID value in the request, the binding MUST be removed if the expiration time is zero and updated otherwise. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails. This algorithm ensures that out-of-order requests from the same UA are ignored. Each binding record records the Call-ID and CSeq values from the request. The binding updates MUST be committed (that is, made visible to the proxy or redirect server) if and only if all binding updates and additions succeed. If any one of them fails (for example, because the back-end database commit failed), the request MUST fail with a 500 (Server Error) response and all tentative binding updates MUST be removed. 8. The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an ""expires"" parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field. 11 Querying for Capabilities The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without ""ringing"" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs MUST support the OPTIONS method. The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to the way a Request-URI is set for a REGISTER request. Rosenberg, et. al. Standards Track [Page 66] RFC 3261 SIP: Session Initiation Protocol June 2002 Alternatively, a server receiving an OPTIONS request with a Max- Forwards header field value of 0 MAY respond to the request regardless of the Request-URI. This behavior is common with HTTP/1.1. This behavior can be used as a ""traceroute"" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values. As is the case for general UA behavior, the transaction layer can return a timeout error if the OPTIONS yields no response. This may indicate that the target is unreachable and hence unavailable. An OPTIONS request MAY be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog. 11.1 Construction of OPTIONS Request An OPTIONS request is constructed using the standard rules for a SIP request as discussed in Section 8.1.1. A Contact header field MAY be present in an OPTIONS. An Accept header field SHOULD be included to indicate the type of message body the UAC wishes to receive in the response. Typically, this is set to a format that is used to describe the media capabilities of a UA, such as SDP (application/sdp). The response to an OPTIONS request is assumed to be scoped to the Request-URI in the original request. However, only when an OPTIONS is sent as part of an established dialog is it guaranteed that future requests will be received by the server that generated the OPTIONS response. Example OPTIONS request: OPTIONS sip:carol@chicago.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70 To: <sip:carol@chicago.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:alice@pc33.atlanta.com> Accept: application/sdp Content-Length: 0 Rosenberg, et. al. Standards Track [Page 67] RFC 3261 SIP: Session Initiation Protocol June 2002 11.2 Processing of OPTIONS Request The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. An OPTIONS request received within a dialog generates a 200 (OK) response that is identical to one constructed outside a dialog and does not have any impact on the dialog. This use of OPTIONS has limitations due to the differences in proxy handling of OPTIONS and INVITE requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OPTIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE handling. See Section 16.7 for the normative details. If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server. The response does not contain a message body. Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is ambiguous since a proxy is method agnostic. Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present. A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). If the types include one that can describe media capabilities, the UAS SHOULD include a body in the response for that purpose. Details on the construction of such a body in the case of application/sdp are described in [13]. Rosenberg, et. al. Standards Track [Page 68] RFC 3261 SIP: Session Initiation Protocol June 2002 Example OPTIONS response generated by a UAS (corresponding to the request in Section 11.1): SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: <sip:carol@chicago.com>;tag=93810874 From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:carol@chicago.com> Contact: <mailto:carol@chicago.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Accept-Encoding: gzip Accept-Language: en Supported: foo Content-Type: application/sdp Content-Length: 274 (SDP not shown) 12 Dialogs A key concept for a user agent is that of a dialog. A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. Section 8 discussed method independent UA processing for requests and responses outside of a dialog. This section discusses how those requests and responses are used to construct a dialog, and then how subsequent requests and responses are sent within a dialog. A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag. The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of unique dialog IDs. A dialog ID is also associated with all responses and with any request that contains a tag in the To field. The rules for computing the dialog ID of a message depend on whether the SIP element is a UAC or UAS. For a UAC, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the To field of the message, and the local tag is set to the tag in the From Rosenberg, et. al. Standards Track [Page 69] RFC 3261 SIP: Session Initiation Protocol June 2002 field of the message (these rules apply to both requests and responses). As one would expect for a UAS, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the From field of the message, and the local tag is set to the tag in the To field of the message. A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called ""secure"", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer. A dialog can also be in the ""early"" state, which occurs when it is created with a provisional response, and then transition to the ""confirmed"" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates. 12.1 Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the ""early"" state and it is called an early dialog. Extensions MAY define other means for creating dialogs. Section 13 gives more details that are specific to the INVITE method. Here, we describe the process for creation of dialog state that is not dependent on the method. UAs MUST assign values to the dialog ID components as described below. 12.1.1 UAS behavior When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE). Generally, the host portion of this URI is the IP address or FQDN of the host. The URI provided in the Contact header field MUST be a SIP or SIPS URI. If the request that initiated the dialog contained a Rosenberg, et. al. Standards Track [Page 70] RFC 3261 SIP: Session Initiation Protocol June 2002 SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI. The URI SHOULD have global scope (that is, the same URI can be used in messages outside this dialog). The same way, the scope of the URI in the Contact header field of the INVITE is not limited to this dialog either. It can therefore be used in messages to the UAC even outside this dialog. The UAS then constructs the state of the dialog. This state MUST be maintained for the duration of the dialog. If the request arrived over TLS, and the Request-URI contained a SIPS URI, the ""secure"" flag is set to TRUE. The route set MUST be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters. If no Record-Route header field is present in the request, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the request. The remote sequence number MUST be set to the value of the sequence number in the CSeq header field of the request. The local sequence number MUST be empty. The call identifier component of the dialog ID MUST be set to the value of the Call-ID in the request. The local tag component of the dialog ID MUST be set to the tag in the To field in the response to the request (which always includes a tag), and the remote tag component of the dialog ID MUST be set to the tag from the From field in the request. A UAS MUST be prepared to receive a request without a tag in the From field, in which case the tag is considered to have a value of null. This is to maintain backwards compatibility with RFC 2543, which did not mandate From tags. The remote URI MUST be set to the URI in the From field, and the local URI MUST be set to the URI in the To field. 12.1.2 UAC Behavior When a UAC sends a request that can establish a dialog (such as an INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., the same SIP URI can be used in messages outside this dialog) in the Contact header field of the request. If the request has a Request- URI or a topmost Route header field value with a SIPS URI, the Contact header field MUST contain a SIPS URI. Rosenberg, et. al. Standards Track [Page 71] RFC 3261 SIP: Session Initiation Protocol June 2002 When a UAC receives a response that establishes a dialog, it constructs the state of the dialog. This state MUST be maintained for the duration of the dialog. If the request was sent over TLS, and the Request-URI contained a SIPS URI, the ""secure"" flag is set to TRUE. The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response. The local sequence number MUST be set to the value of the sequence number in the CSeq header field of the request. The remote sequence number MUST be empty (it is established when the remote UA sends a request within the dialog). The call identifier component of the dialog ID MUST be set to the value of the Call-ID in the request. The local tag component of the dialog ID MUST be set to the tag in the From field in the request, and the remote tag component of the dialog ID MUST be set to the tag in the To field of the response. A UAC MUST be prepared to receive a response without a tag in the To field, in which case the tag is considered to have a value of null. This is to maintain backwards compatibility with RFC 2543, which did not mandate To tags. The remote URI MUST be set to the URI in the To field, and the local URI MUST be set to the URI in the From field. 12.2 Requests within a Dialog Once a dialog has been established between two UAs, either of them MAY initiate new transactions as needed within the dialog. The UA sending the request will take the UAC role for the transaction. The UA receiving the request will take the UAS role. Note that these may be different roles than the UAs held during the transaction that established the dialog. Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an Rosenberg, et. al. Standards Track [Page 72] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. Note that an ACK is NOT a target refresh request. Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems. 12.2.1 UAC Behavior 12.2.1.1 Generating the Request A request within a dialog is constructed by using many of the components of the state stored as part of the dialog. The URI in the To field of the request MUST be set to the remote URI from the dialog state. The tag in the To header field of the request MUST be set to the remote tag of the dialog ID. The From URI of the request MUST be set to the local URI from the dialog state. The tag in the From header field of the request MUST be set to the local tag of the dialog ID. If the value of the remote or local tags is null, the tag parameter MUST be omitted from the To or From header fields, respectively. Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification. The Call-ID of the request MUST be set to the Call-ID of the dialog. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled)."
"Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. If the local sequence number is empty, an initial value MUST be chosen using the guidelines of Section 8.1.1.5. The method field in the CSeq header field value MUST match the method of the request. Rosenberg, et. al. Standards Track [Page 73] RFC 3261 SIP: Session Initiation Protocol June 2002 With a length of 32 bits, a client could generate, within a single call, one request a second for about 136 years before needing to wrap around. The initial value of the sequence number is chosen so that subsequent requests within the same call will not wrap around. A non-zero initial value allows clients to use a time- based initial sequence number. A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial sequence number. The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request. If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the remote target URI into the Route header field as the last value. For example, if the remote target is sip:user@remoteua and the route set contains: <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> The request will be formed with the following Request-URI and Route header field: METHOD sip:proxy1 Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> If the first URI of the route set does not contain the lr parameter, the proxy indicated does not understand the routing mechanisms described in this document and will act as specified in RFC 2543, replacing the Request-URI with the first Route header field value it receives while forwarding the message. Placing the Request-URI at the end of the Route header field preserves the Rosenberg, et. al. Standards Track [Page 74] RFC 3261 SIP: Session Initiation Protocol June 2002 information in that Request-URI across the strict router (it will be returned to the Request-URI when the request reaches a loose- router). A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. If the ""secure"" flag is true, that URI MUST be a SIPS URI. As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact address, should its address change during the duration of the dialog. However, requests that are not target refresh requests do not affect the remote target URI for the dialog. The rest of the request is formed as described in Section 8.1.1. Once the request has been constructed, the address of the server is computed and the request is sent, using the same procedures for requests outside of a dialog (Section 8.1.2). The procedures in Section 8.1.2 will normally result in the request being sent to the address indicated by the topmost Route header field value or the Request-URI if no Route header field is present. Subject to certain restrictions, they allow the request to be sent to an alternate address (such as a default outbound proxy not represented in the route set). 12.2.1.2 Processing the Responses The UAC will receive responses to the request from the transaction layer. If the client transaction returns a timeout, this is treated as a 408 (Request Timeout) response. The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a dialog. This behavior is described in Section 8.1.3.4. Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the Route header of the request. When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present. Rosenberg, et. al. Standards Track [Page 75] RFC 3261 SIP: Session Initiation Protocol June 2002 If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.) For INVITE initiated dialogs, terminating the dialog consists of sending a BYE. 12.2.2 UAS Behavior Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed. Note that some requests, such as INVITEs, affect several pieces of state. The UAS will receive the request from the transaction layer. If the request has a tag in the To header field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing dialogs. If there is a match, this is a mid-dialog request. In that case, the UAS first applies the same processing rules for requests outside of a dialog, discussed in Section 8.2. If the request has a tag in the To header field, but the dialog identifier does not match any existing dialogs, the UAS may have crashed and restarted, or it may have received a request for a different (possibly failed) UAS (the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS for which it is providing recovery). Another possibility is that the incoming request has been simply misrouted. Based on the To tag, the UAS MAY either accept or reject the request. Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers. If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction. Rosenberg, et. al. Standards Track [Page 76] RFC 3261 SIP: Session Initiation Protocol June 2002 Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog. If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request. If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition. When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that request, if present. 12.3 Termination of a Dialog Independent of the method, if a request outside of a dialog generates a non-2xx final response, any early dialogs created through provisional responses to that request are terminated. The mechanism for terminating confirmed dialogs is method specific. In this specification, the BYE method terminates a session and the dialog associated with it. See Section 15 for details. 13 Initiating a Session 13.1 Overview When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. The INVITE request asks a server to establish a session. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation. These UASs will frequently need to query the user about whether to accept the Rosenberg, et. al. Standards Track [Page 77] RFC 3261 SIP: Session Initiation Protocol June 2002 invitation. After some time, those UASs can accept the invitation (meaning the session is to be established) by sending a 2xx response. If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the reason for the rejection. Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. Because of the protracted amount of time it can take to receive final responses to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests (like OPTIONS). Once it receives a final response, the UAC needs to send an ACK for every final response it receives. The procedure for sending this ACK depends on the type of response. For final responses between 300 and 699, the ACK processing is done in the transaction layer and follows one set of rules (See Section 17). For 2xx responses, the ACK is generated by the UAC core. A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response. Therefore, when multiple 2xx responses are received from different remote UAs (because the INVITE forked), each 2xx establishes a different dialog. All these dialogs are part of the same call. This section provides details on the establishment of a session using INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and BYE. 13.2 UAC Processing 13.2.1 Creating the Initial INVITE Since the initial INVITE represents a request outside of a dialog, its construction follows the procedures of Section 8.1.1. Additional processing is required for the specific case of INVITE. An Allow header field (Section 20.5) SHOULD be present in the INVITE. It indicates what methods can be invoked within a dialog, on the UA sending the INVITE, for the duration of the dialog. For example, a UA capable of receiving INFO requests within a dialog [34] SHOULD include an Allow header field listing the INFO method. A Supported header field (Section 20.37) SHOULD be present in the INVITE. It enumerates all the extensions understood by the UAC. Rosenberg, et. al. Standards Track [Page 78] RFC 3261 SIP: Session Initiation Protocol June 2002 An Accept (Section 20.1) header field MAY be present in the INVITE. It indicates which Content-Types are acceptable to the UA, in both the response received by it, and in any subsequent requests sent to it within dialogs established by the INVITE. The Accept header field is especially useful for indicating support of various session description formats. The UAC MAY add an Expires header field (Section 20.19) to limit the validity of the invitation. If the time indicated in the Expires header field is reached and no final answer for the INVITE has been received, the UAC core SHOULD generate a CANCEL request for the INVITE, as per Section 9. A UAC MAY also find it useful to add, among others, Subject (Section 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) header fields. They all contain information related to the INVITE. The UAC MAY choose to add a message body to the INVITE. Section 8.1.1.10 deals with how to construct the header fields -- Content- Type among others -- needed to describe the message body. There are special rules for message bodies that contain a session description - their corresponding Content-Disposition is ""session"". SIP uses an offer/answer model where one UA sends a session description, called the offer, which contains a proposed description of the session. The offer indicates the desired communications means (audio, video, games), parameters of those means (such as codec types) and addresses for receiving media from the answerer. The other UA responds with another session description, called the answer, which indicates which communications means are accepted, the parameters that apply to those means, and addresses for receiving media from the offerer. An offer/answer exchange is within the context of a dialog, so that if a SIP INVITE results in multiple dialogs, each is a separate offer/answer exchange. The offer/answer model defines restrictions on when offers and answers can be made (for example, you cannot make a new offer while one is in progress). This results in restrictions on where the offers and answers can appear in SIP messages. In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The usage of offers and answers is further restricted. For the initial INVITE transaction, the rules are: o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response. Rosenberg, et. al. Standards Track [Page 79] RFC 3261 SIP: Session Initiation Protocol June 2002 o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. o If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer MUST be in the acknowledgement for that message (in this specification, ACK for a 2xx response). o After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer. o Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction. Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - the offer is in the INVITE, and the answer in the 2xx (and possibly in a 1xx as well, with the same value), or the offer is in the 2xx, and the answer is in the ACK. All user agents that support INVITE MUST support these two exchanges. The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be supported by all user agents as a means to describe sessions, and its usage for constructing offers and answers MUST follow the procedures defined in [13]. The restrictions of the offer-answer model just described only apply to bodies whose Content-Disposition header field value is ""session"". Therefore, it is possible that both the INVITE and the ACK contain a body message (for example, the INVITE carries a photo (Content- Disposition: render) and the ACK a session description (Content- Disposition: session)). If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition ""session"", while other content types imply ""render"". Rosenberg, et. al. Standards Track [Page 80] RFC 3261 SIP: Session Initiation Protocol June 2002 Once the INVITE has been created, the UAC follows the procedures defined for sending requests outside of a dialog (Section 8). This results in the construction of a client transaction that will ultimately send the request and deliver responses to the UAC. 13.2.2 Processing INVITE Responses Once the INVITE has been passed to the INVITE client transaction, the UAC waits for responses for the INVITE. If the INVITE client transaction returns a timeout rather than a response the TU acts as if a 408 (Request Timeout) response had been received, as described in Section 8.1.3. 13.2.2.1 1xx Responses Zero, one or multiple provisional responses may arrive before one or more final responses are received. Provisional responses for an INVITE request can create ""early dialogs"". If a provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing dialog, one is constructed using the procedures defined in Section 12.1.2. The early dialog will only be needed if the UAC needs to send a request to its peer within the dialog before the initial INVITE transaction completes. Header fields present in a provisional response are applicable as long as the dialog is in the early state (for example, an Allow header field in a provisional response contains the methods that can be used in the dialog while this is in the early state). 13.2.2.2 3xx Responses A 3xx response may contain one or more Contact header field values providing new addresses where the callee might be reachable. Depending on the status code of the 3xx response (see Section 21.3), the UAC MAY choose to try those new addresses. 13.2.2.3 4xx, 5xx and 6xx Responses A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final responses (which would only arrive under error conditions) MUST be ignored. All early dialogs are considered terminated upon reception of the non-2xx final response. Rosenberg, et. al. Standards Track [Page 81] RFC 3261 SIP: Session Initiation Protocol June 2002 After having received the non-2xx final response the UAC core considers the INVITE transaction completed. The INVITE client transaction handles the generation of ACKs for the response (see Section 17). 13.2.2.4 2xx Responses Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier. If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the ""confirmed"" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the ""confirmed"" state MUST be constructed using the procedures of Section 12.1.2. Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example. The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately. Once the ACK has been constructed, the procedures of [4] are used to determine the destination address, port and transport. However, the request is passed to the transport layer directly for transmission, rather than a client transaction. This is because the UAC core handles retransmissions of the ACK, not the transaction layer. The ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. Rosenberg, et. al. Standards Track [Page 82] RFC 3261 SIP: Session Initiation Protocol June 2002 The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive. If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that dialog, then the UAC MUST terminate the dialog by sending a BYE request as described in Section 15. 13.3 UAS Processing 13.3.1 Processing of the INVITE The UAS core will receive INVITE requests from the transaction layer. It first performs the request processing procedures of Section 8.2, which are applied for both requests inside and outside of a dialog. Assuming these processing states are completed without generating a response, the UAS core performs the additional processing steps: 1. If the request is an INVITE that contains an Expires header field, the UAS core sets a timer for the number of seconds indicated in the header field value. When the timer fires, the invitation is considered to be expired. If the invitation expires before the UAS has generated a final response, a 487 (Request Terminated) response SHOULD be generated. 2. If the request is a mid-dialog request, the method-independent processing described in Section 12.2.2 is first applied. It might also modify the session; Section 14 provides details. 3. If the request has a tag in the To header field but the dialog identifier does not match any of the existing dialogs, the UAS may have crashed and restarted, or may have received a request for a different (possibly failed) UAS. Section 12.2.2 provides guidelines to achieve a robust behavior under such a situation. Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes of establishing a new session. The INVITE may contain a session description, in which case the UAS is being presented with an offer for that session. It is possible that the user is already a participant in that session, even though the INVITE is outside of a dialog. This can happen when a user is invited to the same multicast conference by multiple other participants. If desired, the UAS MAY use identifiers within the session description to detect this duplication. For example, SDP Rosenberg, et. al. Standards Track [Page 83] RFC 3261 SIP: Session Initiation Protocol June 2002 contains a session id and version number in the origin (o) field. If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS MAY silently accept the INVITE (that is, send a 2xx response without prompting the user). If the INVITE does not contain a session description, the UAS is being asked to participate in a session, and the UAC has asked that the UAS provide the offer of the session. It MUST provide the offer in its first non-failure reliable message back to the UAC. In this specification, that is a 2xx response to the INVITE. The UAS can indicate progress, accept, redirect, or reject the invitation. In all of these cases, it formulates a response using the procedures described in Section 8.2.6. 13.3.1.1 Progress If the UAS is not able to answer the invitation immediately, it can choose to indicate some kind of progress to the UAC (for example, an indication that a phone is ringing). This is accomplished with a provisional response between 101 and 199. These provisional responses establish early dialogs and therefore follow the procedures of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY send as many provisional responses as it likes. Each of these MUST indicate the same dialog ID. However, these will not be delivered reliably. If the UAS desires an extended period of time to answer the INVITE, it will need to ask for an ""extension"" in order to prevent proxies from canceling the transaction. A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses. An INVITE transaction can go on for extended durations when the user is placed on hold, or when interworking with PSTN systems which allow communications to take place without answering the call. The latter is common in Interactive Voice Response (IVR) systems. 13.3.1.2 The INVITE is Redirected If the UAS decides to redirect the call, a 3xx response is sent. A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response SHOULD contain a Contact header field Rosenberg, et. al. Standards Track [Page 84] RFC 3261 SIP: Session Initiation Protocol June 2002 containing one or more URIs of new addresses to be tried. The response is passed to the INVITE server transaction, which will deal with its retransmissions. 13.3.1.3 The INVITE is Rejected A common scenario occurs when the callee is currently not willing or able to take additional calls at this end system. A 486 (Busy Here) SHOULD be returned in such a scenario. If the UAS knows that no other end system will be able to accept this call, a 600 (Busy Everywhere) response SHOULD be sent instead. However, it is unlikely that a UAS will be able to know this in general, and thus this response will not usually be used. The response is passed to the INVITE server transaction, which will deal with its retransmissions. A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected. 13.3.1.4 The INVITE is Accepted The UAS core generates a 2xx response. This response establishes a dialog, and therefore follows the procedures of Section 12.1.1 in addition to those of Section 8.2.6. A 2xx response to an INVITE SHOULD contain the Allow header field and the Supported header field, and MAY contain the Accept header field. Including these header fields allows the UAC to determine the features and extensions supported by the UAS for the duration of the call, without probing. If the INVITE request contained an offer, and the UAS had not yet sent an answer, the 2xx MUST contain an answer. If the INVITE did not contain an offer, the 2xx MUST contain an offer if the UAS had not yet sent an offer. Once the response has been constructed, it is passed to the INVITE server transaction. Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received. This is independent of whatever transport protocols are used to send the response. Rosenberg, et. al. Standards Track [Page 85] RFC 3261 SIP: Session Initiation Protocol June 2002 Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. 14 Modifying an Existing Session A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a session using the offer-answer model. Section 12 explains how to modify an existing dialog using a target refresh request (for example, changing the remote target URI of the dialog). This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE. Note that a single re-INVITE can modify the dialog and the parameters of the session at the same time. Either the caller or callee can modify an existing session. The behavior of a UA on detection of media failure is a matter of local policy. However, automated generation of re-INVITE or BYE is NOT RECOMMENDED to avoid flooding the network with traffic when there is congestion. In any case, if these messages are sent automatically, they SHOULD be sent after some randomized interval. Note that the paragraph above refers to automatically generated BYEs and re-INVITEs. If the user hangs up upon media failure, the UA would send a BYE request as usual. 14.1 UAC Behavior The same offer-answer model that applies to session descriptions in INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC that wants to add a media stream, for example, will create a new offer that contains this media stream, and send that in an INVITE request to its peer. It is important to note that the full description of the session, not just the change, is sent. This supports stateless session processing in various elements, and supports failover and recovery capabilities. Of course, a UAC MAY Rosenberg, et. al. Standards Track [Page 86] RFC 3261 SIP: Session Initiation Protocol June 2002 send a re-INVITE with no session description, in which case the first reliable non-failure response to the re-INVITE will contain the offer (in this specification, that is a 2xx response). If the session description format has the capability for version numbers, the offerer SHOULD indicate that the version of the session description has changed. The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set following the same rules as for regular requests within an existing dialog, described in Section 12. A UAC MAY choose not to add an Alert-Info header field or a body with Content-Disposition ""alert"" to re-INVITEs because UASs do not typically alert the user upon reception of a re-INVITE. Unlike an INVITE, which can fork, a re-INVITE will never fork, and therefore, only ever generate a single final response. The reason a re-INVITE will never fork is that the Request-URI identifies the target as the UA instance it established the dialog with, rather than identifying an address-of-record for the user. Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. 1. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE. 2. If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE. However, a UA MAY initiate a regular transaction while an INVITE transaction is in progress. A UA MAY also initiate an INVITE transaction while a regular transaction is in progress. If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued. Note that, as stated in Section 12.2.1.2, if the non-2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is received for the re- INVITE (that is, a timeout is returned by the INVITE client transaction), the UAC will terminate the dialog. Rosenberg, et. al. Standards Track [Page 87] RFC 3261 SIP: Session Initiation Protocol June 2002 If a UAC receives a 491 response to a re-INVITE, it SHOULD start a timer with a value T chosen as follows: 1. If the UAC is the owner of the Call-ID of the dialog ID (meaning it generated the value), T has a randomly chosen value between 2.1 and 4 seconds in units of 10 ms. 2. If the UAC is not the owner of the Call-ID of the dialog ID, T has a randomly chosen value of between 0 and 2 seconds in units of 10 ms. When the timer fires, the UAC SHOULD attempt the re-INVITE once more, if it still desires for that session modification to take place. For example, if the call was already hung up with a BYE, the re-INVITE would not take place. The rules for transmitting a re-INVITE and for generating an ACK for a 2xx response to re-INVITE are the same as for the initial INVITE (Section 13.2.1). 14.2 UAS Behavior Section 13.3.1 describes the procedure for distinguishing incoming re-INVITEs from incoming initial INVITEs and handling a re-INVITE for an existing dialog. A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received INVITE. If a UA receives a re-INVITE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly, possibly after asking the user for confirmation. Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference, add or delete media, or change from a unicast to a multicast conference. Rosenberg, et. al. Standards Track [Page 88] RFC 3261 SIP: Session Initiation Protocol June 2002 If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response for the re- INVITE. This response SHOULD include a Warning header field. If a UAS generates a 2xx response and never receives an ACK, it SHOULD generate a BYE to terminate the dialog. A UAS MAY choose not to generate 180 (Ringing) responses for a re- INVITE because UACs do not typically render this information to the user."
"For the same reason, UASs MAY choose not to use an Alert-Info header field or a body with Content-Disposition ""alert"" in responses to a re-INVITE. A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session. 15 Terminating a Session This section describes the procedures for terminating a session established by SIP. The state of the session and the state of the dialog are very closely related. When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, it also creates a session. As a result, each session is ""associated"" with a single dialog - the one which resulted in its creation. If an initial INVITE generates a non-2xx final response, that terminates all sessions (if any) and all dialogs (if any) that were created through responses to the request. By virtue of completing the transaction, a non-2xx final response also prevents further sessions from being created as a result of the INVITE. The BYE request is used to terminate a specific session or attempted session. In this case, the specific session is the one with the peer UA on the other side of the dialog. When a BYE is received on a dialog, any session associated with that dialog SHOULD terminate. A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs. Rosenberg, et. al. Standards Track [Page 89] RFC 3261 SIP: Session Initiation Protocol June 2002 However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out. If no SIP extensions have defined other application layer states associated with the dialog, the BYE also terminates the dialog. The impact of a non-2xx final response to INVITE on dialogs and sessions makes the use of CANCEL attractive. The CANCEL attempts to force a non-2xx response to the INVITE (in particular, a 487). Therefore, if a UAC wishes to give up on its call attempt entirely, it can send a CANCEL. If the INVITE results in 2xx final response(s) to the INVITE, this means that a UAS accepted the invitation while the CANCEL was in progress. The UAC MAY continue with the sessions established by any 2xx responses, or MAY terminate them with BYE. The notion of ""hanging up"" is not well defined within SIP. It is specific to a particular, albeit common, user interface. Typically, when the user hangs up, it indicates a desire to terminate the attempt to establish a session, and to terminate any sessions already created. For the caller's UA, this would imply a CANCEL request if the initial INVITE has not generated a final response, and a BYE to all confirmed dialogs after a final response. For the callee's UA, it would typically imply a BYE; presumably, when the user picked up the phone, a 2xx was generated, and so hanging up would result in a BYE after the ACK is received. This does not mean a user cannot hang up before receipt of the ACK, it just means that the software in his phone needs to maintain state for a short while in order to clean up properly. If the particular UI allows for the user to reject a call before its answered, a 403 (Forbidden) is a good way to express that. As per the rules above, a BYE can't be sent. 15.1 Terminating a Session with a BYE Request 15.1.1 UAC Behavior A BYE request is constructed as would any other request within a dialog, as described in Section 12. Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no Rosenberg, et. al. Standards Track [Page 90] RFC 3261 SIP: Session Initiation Protocol June 2002 response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated. 15.1.2 UAS Behavior A UAS first processes the BYE request according to the general UAS processing described in Section 8.2. A UAS core receiving a BYE request checks if it matches an existing dialog. If the BYE does not match an existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction Does Not Exist) response and pass that to the server transaction. This rule means that a BYE sent without tags by a UAC will be rejected. This is a change from RFC 2543, which allowed BYE without tags. A UAS core receiving a BYE request for an existing dialog MUST follow the procedures of Section 12.2.2 to process the request. Once done, the UAS SHOULD terminate the session (and therefore stop sending and listening for media). The only case where it can elect not to are multicast sessions, where participation is possible even if the other participant in the dialog has terminated its involvement in the session. Whether or not it ends its participation on the session, the UAS core MUST generate a 2xx response to the BYE, and MUST pass that to the server transaction for transmission. The UAS MUST still respond to any pending requests received for that dialog. It is RECOMMENDED that a 487 (Request Terminated) response be generated to those pending requests. 16 Proxy Behavior 16.1 Overview SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients. A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying the request before forwarding it to the next element. Responses will route through the same set of proxies traversed by the request in the reverse order. Being a proxy is a logical role for a SIP element. When a request arrives, an element that can play the role of a proxy first decides if it needs to respond to the request on its own. For instance, the request may be malformed or the element may need credentials from the client before acting as a proxy. The element MAY respond with any Rosenberg, et. al. Standards Track [Page 91] RFC 3261 SIP: Session Initiation Protocol June 2002 appropriate error code. When responding directly to a request, the element is playing the role of a UAS and MUST behave as described in Section 8.2. A proxy can operate in either a stateful or stateless mode for each new request. When stateless, a proxy acts as a simple forwarding element. It forwards each request downstream to a single element determined by making a targeting and routing decision based on the request. It simply forwards every response it receives upstream. A stateless proxy discards information about a message once the message has been forwarded. A stateful proxy remembers information (specifically, transaction state) about each incoming request and any requests it sends as a result of processing the incoming request. It uses this information to affect the processing of future messages associated with that request. A stateful proxy MAY choose to ""fork"" a request, routing it to multiple destinations. Any request that is forwarded to more than one location MUST be handled statefully. In some circumstances, a proxy MAY forward requests using stateful transports (such as TCP) without being transaction-stateful. For instance, a proxy MAY forward a request from one TCP connection to another transaction statelessly as long as it places enough information in the message to be able to forward the response down the same connection the request arrived on. Requests forwarded between different types of transports where the proxy's TU must take an active role in ensuring reliable delivery on one of the transports MUST be forwarded transaction statefully. A stateful proxy MAY transition to stateless operation at any time during the processing of a request, so long as it did not do anything that would otherwise prevent it from being stateless initially (forking, for example, or generation of a 100 response). When performing such a transition, all state is simply discarded. The proxy SHOULD NOT initiate a CANCEL request. Much of the processing involved when acting statelessly or statefully for a request is identical. The next several subsections are written from the point of view of a stateful proxy. The last section calls out those places where a stateless proxy behaves differently. 16.2 Stateful Proxy When stateful, a proxy is purely a SIP transaction processing engine. Its behavior is modeled here in terms of the server and client transactions defined in Section 17. A stateful proxy has a server transaction associated with one or more client transactions by a higher layer proxy processing component (see figure 3), known as a proxy core. An incoming request is processed by a server Rosenberg, et. al. Standards Track [Page 92] RFC 3261 SIP: Session Initiation Protocol June 2002 transaction. Requests from the server transaction are passed to a proxy core. The proxy core determines where to route the request, choosing one or more next-hop locations. An outgoing request for each next-hop location is processed by its own associated client transaction. The proxy core collects the responses from the client transactions and uses them to send responses to the server transaction. A stateful proxy creates a new server transaction for each new request received. Any retransmissions of the request will then be handled by that server transaction per Section 17. The proxy core MUST behave as a UAS with respect to sending an immediate provisional on that server transaction (such as 100 Trying) as described in Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 (Trying) responses to non-INVITE requests. This is a model of proxy behavior, not of software. An implementation is free to take any approach that replicates the external behavior this model defines. For all new requests, including any with unknown methods, an element intending to proxy the request MUST: 1. Validate the request (Section 16.3) 2. Preprocess routing information (Section 16.4) 3. Determine target(s) for the request (Section 16.5) +--------------------+ | | +---+ | | | C | | | | T | | | +---+ +---+ | Proxy | +---+ CT = Client Transaction | S | | ""Higher"" Layer | | C | | T | | | | T | ST = Server Transaction +---+ | | +---+ | | +---+ | | | C | | | | T | | | +---+ +--------------------+ Figure 3: Stateful Proxy Model Rosenberg, et. al. Standards Track [Page 93] RFC 3261 SIP: Session Initiation Protocol June 2002 4. Forward the request to each target (Section 16.6) 5. Process all responses (Section 16.7) 16.3 Request Validation Before an element can proxy a request, it MUST verify the message's validity. A valid message must pass the following checks: 1. Reasonable Syntax 2. URI scheme 3. Max-Forwards 4. (Optional) Loop Detection 5. Proxy-Require 6. Proxy-Authorization If any of these checks fail, the element MUST behave as a user agent server (see Section 8.2) and respond with an error code. Notice that a proxy is not required to detect merged requests and MUST NOT treat merged requests as an error condition. The endpoints receiving the requests will resolve the merge as described in Section 8.2.2.2. 1. Reasonable syntax check The request MUST be well-formed enough to be handled with a server transaction. Any components involved in the remainder of these Request Validation steps or the Request Forwarding section MUST be well-formed. Any other components, well-formed or not, SHOULD be ignored and remain unchanged when the message is forwarded. For instance, an element would not reject a request because of a malformed Date header field. Likewise, a proxy would not remove a malformed Date header field before forwarding a request. This protocol is designed to be extended. Future extensions may define new methods and header fields at any time. An element MUST NOT refuse to proxy a request because it contains a method or header field it does not know about. Rosenberg, et. al. Standards Track [Page 94] RFC 3261 SIP: Session Initiation Protocol June 2002 2. URI scheme check If the Request-URI has a URI whose scheme is not understood by the proxy, the proxy SHOULD reject the request with a 416 (Unsupported URI Scheme) response. 3. Max-Forwards check The Max-Forwards header field (Section 20.22) is used to limit the number of elements a SIP request can traverse. If the request does not contain a Max-Forwards header field, this check is passed. If the request contains a Max-Forwards header field with a field value greater than zero, the check is passed. If the request contains a Max-Forwards header field with a field value of zero (0), the element MUST NOT forward the request. If the request was for OPTIONS, the element MAY act as the final recipient and respond per Section 11. Otherwise, the element MUST return a 483 (Too many hops) response. 4. Optional Loop Detection check An element MAY check for forwarding loops before forwarding a request. If the request contains a Via header field with a sent- by value that equals a value placed into previous requests by the proxy, the request has been forwarded by this element before. The request has either looped or is legitimately spiraling through the element. To determine if the request has looped, the element MAY perform the branch parameter calculation described in Step 8 of Section 16.6 on this message and compare it to the parameter received in that Via header field. If the parameters match, the request has looped. If they differ, the request is spiraling, and processing continues. If a loop is detected, the element MAY return a 482 (Loop Detected) response. 5. Proxy-Require check Future extensions to this protocol may introduce features that require special handling by proxies. Endpoints will include a Proxy-Require header field in requests that use these features, telling the proxy not to process the request unless the feature is understood. Rosenberg, et. al. Standards Track [Page 95] RFC 3261 SIP: Session Initiation Protocol June 2002 If the request contains a Proxy-Require header field (Section 20.29) with one or more option-tags this element does not understand, the element MUST return a 420 (Bad Extension) response. The response MUST include an Unsupported (Section 20.40) header field listing those option-tags the element did not understand. 6. Proxy-Authorization check If an element requires credentials before forwarding a request, the request MUST be inspected as described in Section 22.3. That section also defines what the element must do if the inspection fails. 16.4 Route Information Preprocessing The proxy MUST inspect the Request-URI of the request. If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request. This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see Section 12.2.1.1). This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear. If the Request-URI contains a maddr parameter, the proxy MUST check to see if its value is in the set of addresses or domains the proxy is configured to be responsible for. If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated (explicitly or by default) in the Request-URI, the proxy MUST strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request. Rosenberg, et. al. Standards Track [Page 96] RFC 3261 SIP: Session Initiation Protocol June 2002 A request may arrive with a maddr matching the proxy, but on a port or transport different from that indicated in the URI. Such a request needs to be forwarded to the proxy using the indicated port and transport. If the first value in the Route header field indicates this proxy, the proxy MUST remove that value from the request. 16.5 Determining Request Targets Next, the proxy calculates the target(s) of the request. The set of targets will either be predetermined by the contents of the request or will be obtained from an abstract location service. Each target in the set is represented as a URI. If the Request-URI of the request contains an maddr parameter, the Request-URI MUST be placed into the target set as the only target URI, and the proxy MUST proceed to Section 16.6. If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6). There are many circumstances in which a proxy might receive a request for a domain it is not responsible for. A firewall proxy handling outgoing calls (the way HTTP proxies handle outgoing requests) is an example of where this is likely to occur. If the target set for the request has not been predetermined as described above, this implies that the element is responsible for the domain in the Request-URI, and the element MAY use whatever mechanism it desires to determine where to send the request. Any of these mechanisms can be modeled as accessing an abstract Location Service. This may consist of obtaining information from a location service created by a SIP Registrar, reading a database, consulting a presence server, utilizing other protocols, or simply performing an algorithmic substitution on the Request-URI. When accessing the location service constructed by a registrar, the Request-URI MUST first be canonicalized as described in Section 10.3 before being used as an index. The output of these mechanisms is used to construct the target set. If the Request-URI does not provide sufficient information for the proxy to determine the target set, it SHOULD return a 485 (Ambiguous) response. This response SHOULD contain a Contact header field containing URIs of new addresses to be tried. For example, an INVITE Rosenberg, et. al. Standards Track [Page 97] RFC 3261 SIP: Session Initiation Protocol June 2002 to sip:John.Smith@company.com may be ambiguous at a proxy whose location service has multiple John Smiths listed. See Section 21.4.23 for details. Any information in or about the request or the current environment of the element MAY be used in the construction of the target set. For instance, different sets may be constructed depending on contents or the presence of header fields and bodies, the time of day of the request's arrival, the interface on which the request arrived, failure of previous requests, or even the element's current level of utilization. As potential targets are located through these services, their URIs are added to the target set. Targets can only be placed in the target set once. If a target URI is already present in the set (based on the definition of equality for the URI type), it MUST NOT be added again. A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for. A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. If the proxy is not responsible for that URI, it will not recurse on 3xx or 416 responses as described below. If the Request-URI of the original request indicates a resource this proxy is responsible for, the proxy MAY continue to add targets to the set after beginning Request Forwarding. It MAY use any information obtained during that processing to determine new targets. For instance, a proxy may choose to incorporate contacts obtained in a redirect response (3xx) into the target set. If a proxy uses a dynamic source of information while building the target set (for instance, if it consults a SIP Registrar), it SHOULD monitor that source for the duration of processing the request. New locations SHOULD be added to the target set as they become available. As above, any given URI MUST NOT be added to the set more than once. Allowing a URI to be added to the set only once reduces unnecessary network traffic, and in the case of incorporating contacts from redirect requests prevents infinite recursion. For example, a trivial location service is a ""no-op"", where the target URI is equal to the incoming request URI. The request is sent to a specific next hop proxy for further processing. During request Rosenberg, et. al. Standards Track [Page 98] RFC 3261 SIP: Session Initiation Protocol June 2002 forwarding of Section 16.6, Item 6, the identity of that next hop, expressed as a SIP or SIPS URI, is inserted as the top-most Route header field value into the request. If the Request-URI indicates a resource at this proxy that does not exist, the proxy MUST return a 404 (Not Found) response. If the target set remains empty after applying all of the above, the proxy MUST return an error response, which SHOULD be the 480 (Temporarily Unavailable) response. 16.6 Request Forwarding As soon as the target set is non-empty, a proxy MAY begin forwarding the request. A stateful proxy MAY process the set in any order. It MAY process multiple targets serially, allowing each client transaction to complete before starting the next. It MAY start client transactions with every target in parallel. It also MAY arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel. A common ordering mechanism is to use the qvalue parameter of targets obtained from Contact header fields (see Section 20.10). Targets are processed from highest qvalue to lowest. Targets with equal qvalues may be processed in parallel. A stateful proxy must have a mechanism to maintain the target set as responses are received and associate the responses to each forwarded request with the original request. For the purposes of this model, this mechanism is a ""response context"" created by the proxy layer before forwarding the first request. For each target, the proxy forwards the request following these steps: 1. Make a copy of the received request 2. Update the Request-URI 3. Update the Max-Forwards header field 4. Optionally add a Record-route header field value 5. Optionally add additional header fields 6. Postprocess routing information 7. Determine the next-hop address, port, and transport Rosenberg, et. al. Standards Track [Page 99] RFC 3261 SIP: Session Initiation Protocol June 2002 8. Add a Via header field value 9. Add a Content-Length header field if necessary 10. Forward the new request 11. Set timer C Each of these steps is detailed below: 1. Copy request The proxy starts with a copy of the received request. The copy MUST initially contain all of the header fields from the received request. Fields not detailed in the processing described below MUST NOT be removed. The copy SHOULD maintain the ordering of the header fields as in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1). The proxy MUST NOT add to, modify, or remove the message body. An actual implementation need not perform a copy; the primary requirement is that the processing for each next hop begin with the same request. 2. Request-URI The Request-URI in the copy's start line MUST be replaced with the URI for this target. If the URI contains any parameters not allowed in a Request-URI, they MUST be removed. This is the essence of a proxy's role. This is the mechanism through which a proxy routes a request toward its destination. In some circumstances, the received Request-URI is placed into the target set without being modified. For that target, the replacement above is effectively a no-op. 3. Max-Forwards If the copy contains a Max-Forwards header field, the proxy MUST decrement its value by one (1). If the copy does not contain a Max-Forwards header field, the proxy MUST add one with a field value, which SHOULD be 70. Some existing UAs will not provide a Max-Forwards header field in a request. Rosenberg, et. al. Standards Track [Page 100] RFC 3261 SIP: Session Initiation Protocol June 2002 4. Record-Route If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it MUST insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present. Requests establishing a dialog may contain a preloaded Route header field. If this request is already part of a dialog, the proxy SHOULD insert a Record-Route header field value if it wishes to remain on the path of future requests in the dialog. In normal endpoint operation as described in Section 12, these Record- Route header field values will not have any effect on the route sets used by the endpoints. The proxy will remain on the path if it chooses to not insert a Record-Route header field value into requests that are already part of a dialog. However, it would be removed from the path when an endpoint that has failed reconstitutes the dialog. A proxy MAY insert a Record-Route header field value into any request. If the request does not initiate a dialog, the endpoints will ignore the value. See Section 12 for details on how endpoints use the Record-Route header field values to construct Route header fields. Each proxy in the path of a request chooses whether to add a Record-Route header field value independently - the presence of a Record-Route header field in a request does not obligate this proxy to add a value. The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI. This URI MUST contain an lr parameter (see Section 19.1.1). This URI MAY be different for each destination the request is forwarded to. The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport. The URI this proxy provides will be used by some other element to make a routing decision. This proxy, in general, has no way of knowing the capabilities of that element, so it must restrict itself to the mandatory elements of a SIP implementation: SIP URIs and either the TCP or UDP transports. Rosenberg, et. al. Standards Track [Page 101] RFC 3261 SIP: Session Initiation Protocol June 2002 The URI placed in the Record-Route header field MUST resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element. If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field. In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6), MUST insert a Record-Route header field that is not a SIPS URI. A proxy at a security perimeter must remain on the perimeter throughout the dialog. If the URI placed in the Record-Route header field needs to be rewritten when it passes back through in a response, the URI MUST be distinct enough to locate at that time. (The request may spiral through this proxy, resulting in more than one Record-Route header field value being added). Item 8 of Section 16.7 recommends a mechanism to make the URI sufficiently distinct. The proxy MAY include parameters in the Record-Route header field value. These will be echoed in some responses to the request such as the 200 (OK) responses to INVITE. Such parameters may be useful for keeping state in the message rather than the proxy. If a proxy needs to be in the path of any type of dialog (such as one straddling a firewall), it SHOULD add a Record-Route header field value to every request with a method it does not understand since that method may have dialog semantics. The URI a proxy places into a Record-Route header field is only valid for the lifetime of any dialog created by the transaction in which it occurs. A dialog-stateful proxy, for example, MAY refuse to accept future requests with that value in the Request-URI after the dialog has terminated. Non-dialog- stateful proxies, of course, have no concept of when the dialog has terminated, but they MAY encode enough information in the value to compare it against the dialog identifier of future requests and MAY reject requests not matching that information. Endpoints MUST NOT use a URI obtained from a Record-Route header field outside the dialog in which it was provided. See Rosenberg, et. al. Standards Track [Page 102] RFC 3261 SIP: Session Initiation Protocol June 2002 Section 12 for more information on an endpoint's use of Record-Route header fields. Record-routing may be required by certain services where the proxy needs to observe all messages in a dialog. However, it slows down processing and impairs scalability and thus proxies should only record-route if required for a particular service. The Record-Route process is designed to work for any SIP request that initiates a dialog. INVITE is the only such request in this specification, but extensions to the protocol MAY define others. 5. Add Additional Header Fields The proxy MAY add any other appropriate header fields to the copy at this point. 6. Postprocess routing information A proxy MAY have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination. A proxy MUST ensure that all such proxies are loose routers. Generally, this can only be known with certainty if the proxies are within the same administrative domain. This set of proxies is represented by a set of URIs (each of which contains the lr parameter). This set MUST be pushed into the Route header field of the copy ahead of any existing values, if present. If the Route header field is absent, it MUST be added, containing that list of URIs. If the proxy has a local policy that mandates that the request visit one specific proxy, an alternative to pushing a Route value into the Route header field is to bypass the forwarding logic of item 10 below, and instead just send the request to the address, port, and transport for that specific proxy. If the request has a Route header field, this alternative MUST NOT be used unless it is known that next hop proxy is a loose router. Otherwise, this approach MAY be used, but the Route insertion mechanism above is preferred for its robustness, flexibility, generality and consistency of operation. Furthermore, if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with that proxy. If the copy contains a Route header field, the proxy MUST inspect the URI in its first value. If that URI does not contain an lr parameter, the proxy MUST modify the copy as follows: Rosenberg, et. al. Standards Track [Page 103] RFC 3261 SIP: Session Initiation Protocol June 2002 - The proxy MUST place the Request-URI into the Route header field as the last value. - The proxy MUST then place the first Route header field value into the Request-URI and remove that value from the Route header field. Appending the Request-URI to the Route header field is part of a mechanism used to pass the information in that Request-URI through strict-routing elements. ""Popping"" the first Route header field value into the Request-URI formats the message the way a strict-routing element expects to receive it (with its own URI in the Request-URI and the next location to visit in the first Route header field value). 7. Determine Next-Hop Address, Port, and Transport The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI. Such a policy MUST NOT be used if the proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. However, this mechanism for sending the request through a specific next hop is NOT RECOMMENDED; instead a Route header field should be used for that purpose as described above. In the absence of such an overriding mechanism, the proxy applies the procedures listed in [4] as follows to determine where to send the request. If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy MUST apply those procedures to the Request-URI of the request. Otherwise, the proxy MUST apply the procedures to the first value in the Route header field, if present, else the Request-URI. The procedures will produce an ordered set of (address, port, transport) tuples. Independently of which URI is being used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the proxy MUST follow the procedures of [4] as if the input URI were a SIPS URI. As described in [4], the proxy MUST attempt to deliver the message to the first tuple in that set, and proceed through the set in order until the delivery attempt succeeds. For each tuple attempted, the proxy MUST format the message as appropriate for the tuple and send the request using a new client transaction as detailed in steps 8 through 10. Rosenberg, et. al. Standards Track [Page 104] RFC 3261 SIP: Session Initiation Protocol June 2002 Since each attempt uses a new client transaction, it represents a new branch. Thus, the branch parameter provided with the Via header field inserted in step 8 MUST be different for each attempt. If the client transaction reports failure to send the request or a timeout from its state machine, the proxy continues to the next address in that ordered set. If the ordered set is exhausted, the request cannot be forwarded to this element in the target set. The proxy does not need to place anything in the response context, but otherwise acts as if this element of the target set returned a 408 (Request Timeout) final response. 8. Add a Via header field value The proxy MUST insert a Via header field value into the copy before the existing Via header field values. The construction of this value follows the same guidelines of Section 8.1.1.7. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and contain the requisite magic cookie. Note that this implies that the branch parameter will be different for different instances of a spiraled or looped request through a proxy. Proxies choosing to detect loops have an additional constraint in the value they use for construction of the branch parameter."
"A proxy choosing to detect loops SHOULD create a branch parameter separable into two parts by the implementation. The first part MUST satisfy the constraints of Section 8.1.1.7 as described above. The second is used to perform loop detection and distinguish loops from spirals. Loop detection is performed by verifying that, when a request returns to a proxy, those fields having an impact on the processing of the request have not changed. The value placed in this part of the branch parameter SHOULD reflect all of those fields (including any Route, Proxy-Require and Proxy- Authorization header fields). This is to ensure that if the request is routed back to the proxy and one of those fields changes, it is treated as a spiral and not a loop (see Section 16.3). A common way to create this value is to compute a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI of the request received (before translation), the topmost Via header, and the sequence number from the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that may be present. The Rosenberg, et. al. Standards Track [Page 105] RFC 3261 SIP: Session Initiation Protocol June 2002 algorithm used to compute the hash is implementation-dependent, but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a reasonable choice. (Base64 is not permissible for a token.) If a proxy wishes to detect loops, the ""branch"" parameter it supplies MUST depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing. This is necessary to distinguish looped requests from requests whose routing parameters have changed before returning to this server. The request method MUST NOT be included in the calculation of the branch parameter. In particular, CANCEL and ACK requests (for non-2xx responses) MUST have the same branch value as the corresponding request they cancel or acknowledge. The branch parameter is used in correlating those requests at the server handling them (see Sections 17.2.3 and 9.2). 9. Add a Content-Length header field if necessary If the request will be sent to the next hop using a stream- based transport and the copy contains no Content-Length header field, the proxy MUST insert one with the correct value for the body of the request (see Section 20.14). 10. Forward Request A stateful proxy MUST create a new client transaction for this request as described in Section 17.1 and instructs the transaction to send the request using the address, port and transport determined in step 7. 11. Set timer C In order to handle the case where an INVITE request never generates a final response, the TU uses a timer which is called timer C. Timer C MUST be set for each client transaction when an INVITE request is proxied. The timer MUST be larger than 3 minutes. Section 16.7 bullet 2 discusses how this timer is updated with provisional responses, and Section 16.8 discusses processing when it fires. Rosenberg, et. al. Standards Track [Page 106] RFC 3261 SIP: Session Initiation Protocol June 2002 16.7 Response Processing When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST process the response (even if it is an informational response) as a stateless proxy (described below). If a match is found, the response is handed to the client transaction. Forwarding responses for which a client transaction (or more generally any knowledge of having sent an associated request) is not found improves robustness. In particular, it ensures that ""late"" 2xx responses to INVITE requests are forwarded properly. As client transactions pass responses to the proxy layer, the following processing MUST take place: 1. Find the appropriate response context 2. Update timer C for provisional responses 3. Remove the topmost Via 4. Add the response to the response context 5. Check to see if this response should be forwarded immediately 6. When necessary, choose the best final response from the response context If no final response has been forwarded after every client transaction associated with the response context has been terminated, the proxy must choose and forward the ""best"" response from those it has seen so far. The following processing MUST be performed on each response that is forwarded. It is likely that more than one response to each request will be forwarded: at least each provisional and one final response. 7. Aggregate authorization header field values if necessary 8. Optionally rewrite Record-Route header field values 9. Forward the response 10. Generate any necessary CANCEL requests Rosenberg, et. al. Standards Track [Page 107] RFC 3261 SIP: Session Initiation Protocol June 2002 Each of the above steps are detailed below: 1. Find Context The proxy locates the ""response context"" it created before forwarding the original request using the key described in Section 16.6. The remaining processing steps take place in this context. 2. Update timer C for provisional responses For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C for that client transaction. The timer MAY be reset to a different value, but this value MUST be greater than 3 minutes. 3. Via The proxy removes the topmost Via header field value from the response. If no Via header field values remain in the response, the response was meant for this element and MUST NOT be forwarded. The remainder of the processing described in this section is not performed on this message, the UAC processing rules described in Section 8.1.3 are followed instead (transport layer processing has already occurred). This will happen, for instance, when the element generates CANCEL requests as described in Section 10. 4. Add response to context Final responses received are stored in the response context until a final response is generated on the server transaction associated with this context. The response may be a candidate for the best final response to be returned on that server transaction. Information from this response may be needed in forming the best response, even if this response is not chosen. If the proxy chooses to recurse on any contacts in a 3xx response by adding them to the target set, it MUST remove them from the response before adding the response to the response context. However, a proxy SHOULD NOT recurse to a non-SIPS URI if the Request-URI of the original request was a SIPS URI. If Rosenberg, et. al. Standards Track [Page 108] RFC 3261 SIP: Session Initiation Protocol June 2002 the proxy recurses on all of the contacts in a 3xx response, the proxy SHOULD NOT add the resulting contactless response to the response context. Removing the contact before adding the response to the response context prevents the next element upstream from retrying a location this proxy has already attempted. 3xx responses may contain a mixture of SIP, SIPS, and non-SIP URIs. A proxy may choose to recurse on the SIP and SIPS URIs and place the remainder into the response context to be returned, potentially in the final response. If a proxy receives a 416 (Unsupported URI Scheme) response to a request whose Request-URI scheme was not SIP, but the scheme in the original received request was SIP or SIPS (that is, the proxy changed the scheme from SIP or SIPS to something else when it proxied a request), the proxy SHOULD add a new URI to the target set. This URI SHOULD be a SIP URI version of the non-SIP URI that was just tried. In the case of the tel URL, this is accomplished by placing the telephone-subscriber part of the tel URL into the user part of the SIP URI, and setting the hostpart to the domain where the prior request was sent. See Section 19.1.6 for more detail on forming SIP URIs from tel URLs. As with a 3xx response, if a proxy ""recurses"" on the 416 by trying a SIP or SIPS URI instead, the 416 response SHOULD NOT be added to the response context. 5. Check response for forwarding Until a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any provisional response other than 100 (Trying) - Any 2xx response If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context. This is a change from RFC 2543, which mandated that the proxy was to forward the 6xx response immediately. For an INVITE transaction, this approach had the problem that a 2xx response could arrive on another branch, in which case the proxy would Rosenberg, et. al. Standards Track [Page 109] RFC 3261 SIP: Session Initiation Protocol June 2002 have to forward the 2xx. The result was that the UAC could receive a 6xx response followed by a 2xx response, which should never be allowed to happen. Under the new rules, upon receiving a 6xx, a proxy will issue a CANCEL request, which will generally result in 487 responses from all outstanding client transactions, and then at that point the 6xx is forwarded upstream. After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any 2xx response to an INVITE request A stateful proxy MUST NOT immediately forward any other responses. In particular, a stateful proxy MUST NOT forward any 100 (Trying) response. Those responses that are candidates for forwarding later as the ""best"" response have been gathered as described in step ""Add Response to Context"". Any response chosen for immediate forwarding MUST be processed as described in steps ""Aggregate Authorization Header Field Values"" through ""Record-Route"". This step, combined with the next, ensures that a stateful proxy will forward exactly one final response to a non-INVITE request, and either exactly one non-2xx response or one or more 2xx responses to an INVITE request. 6. Choosing the best response A stateful proxy MUST send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules and all client transactions in this response context have been terminated. The stateful proxy MUST choose the ""best"" final response among those received and stored in the response context. If there are no final responses in the context, the proxy MUST send a 408 (Request Timeout) response to the server transaction. Otherwise, the proxy MUST forward a response from the responses stored in the response context. It MUST choose from the 6xx class responses if any exist in the context. If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context. The proxy MAY select any response within that chosen class. The proxy SHOULD Rosenberg, et. al. Standards Track [Page 110] RFC 3261 SIP: Session Initiation Protocol June 2002 give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen. A proxy which receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 503 means that the proxy knows it cannot service any requests, not just the one for the Request- URI in the request which generated the 503. If the only response that was received is a 503, the proxy SHOULD generate a 500 response and forward that upstream. The forwarded response MUST be processed as described in steps ""Aggregate Authorization Header Field Values"" through ""Record- Route"". For example, if a proxy forwarded a request to 4 locations, and received 503, 407, 501, and 404 responses, it may choose to forward the 407 (Proxy Authentication Required) response. 1xx and 2xx responses may be involved in the establishment of dialogs. When a request does not contain a To tag, the To tag in the response is used by the UAC to distinguish multiple responses to a dialog creating request. A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx response if the request did not contain one. A proxy MUST NOT modify the tag in the To header field of a 1xx or 2xx response. Since a proxy may not insert a tag into the To header field of a 1xx response to a request that did not contain one, it cannot issue non-100 provisional responses on its own. However, it can branch the request to a UAS sharing the same element as the proxy. This UAS can return its own provisional responses, entering into an early dialog with the initiator of the request. The UAS does not have to be a discreet process from the proxy. It could be a virtual UAS implemented in the same code space as the proxy. 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx response, the element is effectively acting as a UAS, issuing its own response, usually based on the responses received from downstream elements. An element SHOULD preserve the To tag when simply forwarding a 3-6xx response to a request that did not contain a To tag. A proxy MUST NOT modify the To tag in any forwarded response to a request that contains a To tag. Rosenberg, et. al. Standards Track [Page 111] RFC 3261 SIP: Session Initiation Protocol June 2002 While it makes no difference to the upstream elements if the proxy replaced the To tag in a forwarded 3-6xx response, preserving the original tag may assist with debugging. When the proxy is aggregating information from several responses, choosing a To tag from among them is arbitrary, and generating a new To tag may make debugging easier. This happens, for instance, when combining 401 (Unauthorized) and 407 (Proxy Authentication Required) challenges, or combining Contact values from unencrypted and unauthenticated 3xx responses. 7. Aggregate Authorization Header Field Values If the selected response is a 401 (Unauthorized) or 407 (Proxy Authentication Required), the proxy MUST collect any WWW- Authenticate and Proxy-Authenticate header field values from all other 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this response context and add them to this response without modification before forwarding. The resulting 401 (Unauthorized) or 407 (Proxy Authentication Required) response could have several WWW- Authenticate AND Proxy-Authenticate header field values. This is necessary because any or all of the destinations the request was forwarded to may have requested credentials. The client needs to receive all of those challenges and supply credentials for each of them when it retries the request. Motivation for this behavior is provided in Section 26. 8. Record-Route If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy MAY choose to rewrite the value before forwarding the response. This allows the proxy to provide different URIs for itself to the next upstream and downstream elements. A proxy may choose to use this mechanism for any reason. For instance, it is useful for multi-homed hosts. If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI. If the proxy received the request over a non-TLS connection, and sent it out over TLS, the proxy MUST rewrite the URI in the Record-Route header field to be a SIP URI. Rosenberg, et. al. Standards Track [Page 112] RFC 3261 SIP: Session Initiation Protocol June 2002 The new URI provided by the proxy MUST satisfy the same constraints on URIs placed in Record-Route header fields in requests (see Step 4 of Section 16.6) with the following modifications: The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge that the next upstream (as opposed to downstream) element that will be in the path of subsequent requests supports that transport. When a proxy does decide to modify the Record-Route header field in the response, one of the operations it performs is locating the Record-Route value that it had inserted. If the request spiraled, and the proxy inserted a Record-Route value in each iteration of the spiral, locating the correct value in the response (which must be the proper iteration in the reverse direction) is tricky. The rules above recommend that a proxy wishing to rewrite Record-Route header field values insert sufficiently distinct URIs into the Record-Route header field so that the right one may be selected for rewriting. A RECOMMENDED mechanism to achieve this is for the proxy to append a unique identifier for the proxy instance to the user portion of the URI. When the response arrives, the proxy modifies the first Record-Route whose identifier matches the proxy instance. The modification results in a URI without this piece of data appended to the user portion of the URI. Upon the next iteration, the same algorithm (find the topmost Record-Route header field value with the parameter) will correctly extract the next Record-Route header field value inserted by that proxy. Not every response to a request to which a proxy adds a Record-Route header field value will contain a Record-Route header field. If the response does contain a Record-Route header field, it will contain the value the proxy added. 9. Forward response After performing the processing described in steps ""Aggregate Authorization Header Field Values"" through ""Record-Route"", the proxy MAY perform any feature specific manipulations on the selected response. The proxy MUST NOT add to, modify, or remove the message body. Unless otherwise specified, the proxy MUST NOT remove any header field values other than the Via header field value discussed in Section 16.7 Item 3. In particular, the proxy MUST NOT remove any ""received"" parameter Rosenberg, et. al. Standards Track [Page 113] RFC 3261 SIP: Session Initiation Protocol June 2002 it may have added to the next Via header field value while processing the request associated with this response. The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost Via header field value. If the server transaction is no longer available to handle the transmission, the element MUST forward the response statelessly by sending it to the server transport. The server transaction might indicate failure to send the response or signal a timeout in its state machine. These errors would be logged for diagnostic purposes as appropriate, but the protocol requires no remedial action from the proxy. The proxy MUST maintain the response context until all of its associated transactions have been terminated, even after forwarding a final response. 10. Generate CANCELs If the forwarded response was a final response, the proxy MUST generate a CANCEL request for all pending client transactions associated with this response context. A proxy SHOULD also generate a CANCEL request for all pending client transactions associated with this response context when it receives a 6xx response. A pending client transaction is one that has received a provisional response, but no final response (it is in the proceeding state) and has not had an associated CANCEL generated for it. Generating CANCEL requests is described in Section 9.1. The requirement to CANCEL pending client transactions upon forwarding a final response does not guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE. 200 (OK) responses on more than one branch may be generated before the CANCEL requests can be sent and processed. Further, it is reasonable to expect that a future extension may override this requirement to issue CANCEL requests. 16.8 Processing Timer C If timer C should fire, the proxy MUST either reset the timer with any value it chooses, or terminate the client transaction. If the client transaction has received a provisional response, the proxy MUST generate a CANCEL request matching that transaction. If the client transaction has not received a provisional response, the proxy MUST behave as if the transaction received a 408 (Request Timeout) response. Rosenberg, et. al. Standards Track [Page 114] RFC 3261 SIP: Session Initiation Protocol June 2002 Allowing the proxy to reset the timer allows the proxy to dynamically extend the transaction's lifetime based on current conditions (such as utilization) when the timer fires. 16.9 Handling Transport Errors If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response. If the proxy is notified of an error when forwarding a response, it drops the response. The proxy SHOULD NOT cancel any outstanding client transactions associated with this response context due to this notification. If a proxy cancels its outstanding client transactions, a single malicious or misbehaving client can cause all transactions to fail through its Via header field. 16.10 CANCEL Processing A stateful proxy MAY generate a CANCEL to any other request it has generated at any time (subject to receiving a provisional response to that request as described in section 9.1). A proxy MUST cancel any pending client transactions associated with a response context when it receives a matching CANCEL request. A stateful proxy MAY generate CANCEL requests for pending INVITE client transactions based on the period specified in the INVITE's Expires header field elapsing. However, this is generally unnecessary since the endpoints involved will take care of signaling the end of the transaction. While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response context is not created for it. Instead, the proxy layer searches its existing response contexts for the server transaction handling the request associated with this CANCEL. If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request. In this case, the element is acting as a user agent server as defined in Section 8.2. Furthermore, the element MUST generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10. If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously). Rosenberg, et. al. Standards Track [Page 115] RFC 3261 SIP: Session Initiation Protocol June 2002 16.11 Stateless Proxy When acting statelessly, a proxy is a simple message forwarder. Much of the processing performed when acting statelessly is the same as when behaving statefully. The differences are detailed here. A stateless proxy does not have any notion of a transaction, or of the response context used to describe stateful proxy behavior. Instead, the stateless proxy takes messages, both requests and responses, directly from the transport layer (See section 18). As a result, stateless proxies do not retransmit messages on their own. They do, however, forward all retransmissions they receive (they do not have the ability to distinguish a retransmission from the original message). Furthermore, when handling a request statelessly, an element MUST NOT generate its own 100 (Trying) or any other provisional response. A stateless proxy MUST validate a request as described in Section 16.3 A stateless proxy MUST follow the request processing steps described in Sections 16.4 through 16.5 with the following exception: o A stateless proxy MUST choose one and only one target from the target set. This choice MUST only rely on fields in the message and time-invariant properties of the server. In particular, a retransmitted request MUST be forwarded to the same destination each time it is processed. Furthermore, CANCEL and non-Routed ACK requests MUST generate the same choice as their associated INVITE. A stateless proxy MUST follow the request processing steps described in Section 16.6 with the following exceptions: o The requirement for unique branch IDs across space and time applies to stateless proxies as well. However, a stateless proxy cannot simply use a random number generator to compute the first component of the branch ID, as described in Section 16.6 bullet 8. This is because retransmissions of a request need to have the same value, and a stateless proxy cannot tell a retransmission from the original request. Therefore, the component of the branch parameter that makes it unique MUST be the same each time a retransmitted request is forwarded. Thus for a stateless proxy, the branch parameter MUST be computed as a combinatoric function of message parameters which are invariant on retransmission. Rosenberg, et. al. Standards Track [Page 116] RFC 3261 SIP: Session Initiation Protocol June 2002 The stateless proxy MAY use any technique it likes to guarantee uniqueness of its branch IDs across transactions. However, the following procedure is RECOMMENDED. The proxy examines the branch ID in the topmost Via header field of the received request. If it begins with the magic cookie, the first component of the branch ID of the outgoing request is computed as a hash of the received branch ID. Otherwise, the first component of the branch ID is computed as a hash of the topmost Via, the tag in the To header field, the tag in the From header field, the Call-ID header field, the CSeq number (but not method), and the Request-URI from the received request. One of these fields will always vary across two different transactions. o All other message transformations specified in Section 16.6 MUST result in the same transformation of a retransmitted request. In particular, if the proxy inserts a Record-Route value or pushes URIs into the Route header field, it MUST place the same values in retransmissions of the request. As for the Via branch parameter, this implies that the transformations MUST be based on time-invariant configuration or retransmission-invariant properties of the request. o A stateless proxy determines where to forward the request as described for stateful proxies in Section 16.6 Item 10. The request is sent directly to the transport layer instead of through a client transaction. Since a stateless proxy must forward retransmitted requests to the same destination and add identical branch parameters to each of them, it can only use information from the message itself and time-invariant configuration data for those calculations. If the configuration state is not time-invariant (for example, if a routing table is updated) any requests that could be affected by the change may not be forwarded statelessly during an interval equal to the transaction timeout window before or after the change. The method of processing the affected requests in that interval is an implementation decision. A common solution is to forward them transaction statefully. Stateless proxies MUST NOT perform special processing for CANCEL requests. They are processed by the above rules as any other requests. In particular, a stateless proxy applies the same Route header field processing to CANCEL requests that it applies to any other request. Rosenberg, et. al. Standards Track [Page 117] RFC 3261 SIP: Session Initiation Protocol June 2002 Response processing as described in Section 16.7 does not apply to a proxy behaving statelessly. When a response arrives at a stateless proxy, the proxy MUST inspect the sent-by value in the first (topmost) Via header field value. If that address matches the proxy, (it equals a value this proxy has inserted into previous requests) the proxy MUST remove that header field value from the response and forward the result to the location indicated in the next Via header field value. The proxy MUST NOT add to, modify, or remove the message body. Unless specified otherwise, the proxy MUST NOT remove any other header field values. If the address does not match the proxy, the message MUST be silently discarded. 16.12 Summary of Proxy Route Processing In the absence of local policy to the contrary, the processing a proxy performs on a request containing a Route header field can be summarized in the following steps. 1. The proxy will inspect the Request-URI. If it indicates a resource owned by this proxy, the proxy will replace it with the results of running a location service. Otherwise, the proxy will not change the Request-URI. 2. The proxy will inspect the URI in the topmost Route header field value. If it indicates this proxy, the proxy removes it from the Route header field (this route node has been reached). 3. The proxy will forward the request to the resource indicated by the URI in the topmost Route header field value or in the Request-URI if no Route header field is present. The proxy determines the address, port and transport to use when forwarding the request by applying the procedures in [4] to that URI. If no strict-routing elements are encountered on the path of the request, the Request-URI will always indicate the target of the request. 16.12.1 Examples 16.12.1.1 Basic SIP Trapezoid This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing. Here is the flow. Rosenberg, et. al. Standards Track [Page 118] RFC 3261 SIP: Session Initiation Protocol June 2002 U1 sends: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com to P1. P1 is an outbound proxy. P1 is not responsible for domain.com, so it looks it up in DNS and sends it there. It also adds a Record-Route header field value: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p1.example.com;lr> P2 gets this. It is responsible for domain.com so it runs a location service and rewrites the Request-URI. It also adds a Record-Route header field value. There is no Route header field, so it resolves the new Request-URI to determine where to send the request: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr> The callee at u2.domain.com gets this and responds with a 200 OK: SIP/2.0 200 OK Contact: sip:callee@u2.domain.com Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr> The callee at u2 also sets its dialog state's remote target URI to sip:caller@u1.example.com and its route set to: (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>) This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its dialog state's remote target URI to sip:callee@u2.domain.com and its route set to: (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>) Since all the route set elements contain the lr parameter, U1 constructs the following BYE request: BYE sip:callee@u2.domain.com SIP/2.0 Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr> Rosenberg, et. al. Standards Track [Page 119] RFC 3261 SIP: Session Initiation Protocol June 2002 As any other element (including proxies) would do, it resolves the URI in the topmost Route header field value using DNS to determine where to send the request. This goes to P1. P1 notices that it is not responsible for the resource indicated in the Request-URI so it doesn't change it. It does see that it is the first value in the Route header field, so it removes that value, and forwards the request to P2: BYE sip:callee@u2.domain.com SIP/2.0 Route: <sip:p2.domain.com;lr> P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for domain.com, not u2.domain.com), so it doesn't change it. It does see itself in the first Route header field value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the Request-URI: BYE sip:callee@u2.domain.com SIP/2.0 16.12.1.2 Traversing a Strict-Routing Proxy In this scenario, a dialog is established across four proxies, each of which adds Record-Route header field values. The third proxy implements the strict-routing procedures specified in RFC 2543 and many works in progress. U1->P1->P2->P3->P4->U2 The INVITE arriving at U2 contains: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p4.domain.com;lr> Record-Route: <sip:p3.middle.com> Record-Route: <sip:p2.example.com;lr> Record-Route: <sip:p1.example.com;lr> Which U2 responds to with a 200 OK. Later, U2 sends the following BYE request to P4 based on the first Route header field value. BYE sip:caller@u1.example.com SIP/2.0 Route: <sip:p4.domain.com;lr> Route: <sip:p3.middle.com> Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> Rosenberg, et. al. Standards Track [Page 120] RFC 3261 SIP: Session Initiation Protocol June 2002 P4 is not responsible for the resource indicated in the Request-URI so it will leave it alone. It notices that it is the element in the first Route header field value so it removes it. It then prepares to send the request based on the now first Route header field value of sip:p3.middle.com, but it notices that this URI does not contain the lr parameter, so before sending, it reformats the request to be: BYE sip:p3.middle.com SIP/2.0 Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> Route: <sip:caller@u1.example.com> P3 is a strict router, so it forwards the following to P2: BYE sip:p2.example.com;lr SIP/2.0 Route: <sip:p1.example.com;lr> Route: <sip:caller@u1.example.com> P2 sees the request-URI is a value it placed into a Record-Route header field, so before further processing, it rewrites the request to be: BYE sip:caller@u1.example.com SIP/2.0 Route: <sip:p1.example.com;lr> P2 is not responsible for u1.example.com, so it sends the request to P1 based on the resolution of the Route header field value. P1 notices itself in the topmost Route header field value, so it removes it, resulting in: BYE sip:caller@u1.example.com SIP/2.0 Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the request to u1.example.com based on the Request-URI. 16.12.1.3 Rewriting Record-Route Header Field Values In this scenario, U1 and U2 are in different private namespaces and they enter a dialog through a proxy P1, which acts as a gateway between the namespaces. U1->P1->U2 Rosenberg, et. al. Standards Track [Page 121] RFC 3261 SIP: Session Initiation Protocol June 2002 U1 sends: INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 Contact: <sip:caller@u1.leftprivatespace.com> P1 uses its location service and sends the following to U2: INVITE sip:callee@rightprivatespace.com SIP/2.0 Contact: <sip:caller@u1.leftprivatespace.com> Record-Route: <sip:gateway.rightprivatespace.com;lr> U2 sends this 200 (OK) back to P1: SIP/2.0 200 OK Contact: <sip:callee@u2.rightprivatespace.com> Record-Route: <sip:gateway.rightprivatespace.com;lr> P1 rewrites its Record-Route header parameter to provide a value that U1 will find useful, and sends the following to U1: SIP/2.0 200 OK Contact: <sip:callee@u2.rightprivatespace.com> Record-Route: <sip:gateway.leftprivatespace.com;lr> Later, U1 sends the following BYE request to P1: BYE sip:callee@u2.rightprivatespace.com SIP/2.0 Route: <sip:gateway.leftprivatespace.com;lr> which P1 forwards to U2 as: BYE sip:callee@u2.rightprivatespace.com SIP/2.0 17 Transactions SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses. In the case of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction. The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility Rosenberg, et. al. Standards Track [Page 122] RFC 3261 SIP: Session Initiation Protocol June 2002 for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction. Transactions have a client side and a server side. The client side is known as a client transaction and the server side as a server transaction. The client transaction sends the request, and the server transaction sends the response. The client and server transactions are logical functions that are embedded in any number of elements. Specifically, they exist within user agents and stateful proxy servers. Consider the example in Section 4. In this example, the UAC executes the client transaction, and its outbound proxy executes the server transaction. The outbound proxy also executes a client transaction, which sends the request to a server transaction in the inbound proxy. That proxy also executes a client transaction, which in turn sends the request to a server transaction in the UAS. This is shown in Figure 4. +---------+ +---------+ +---------+ +---------+ | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | | |C||------->||S| |C||------->||S| |C||------->||S| | | |l|| ||e| |l|| ||e| |l|| ||e| | | |i|| ||r| |i|| ||r| |i|| ||r| | | |e|| ||v| |e|| ||v| |e|| ||v| | | |n|| ||e| |n|| ||e| |n|| ||e| | | |t|| ||r| |t|| ||r| |t|| ||r| | | | || || | | || || | | || || | | | |T|| ||T| |T|| ||T| |T|| ||T| | | |r|| ||r| |r|| ||r| |r|| ||r| | | |a|| ||a| |a|| ||a| |a|| ||a| | | |n|| ||n| |n|| ||n| |n|| ||n| | | |s||Response||s| |s||Response||s| |s||Response||s| | | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | +---------+ +---------+ +---------+ +---------+ UAC Outbound Inbound UAS Proxy Proxy Figure 4: Transaction relationships A stateless proxy does not contain a client or server transaction. The transaction exists between the UA or stateful proxy on one side, and the UA or stateful proxy on the other side. As far as SIP transactions are concerned, stateless proxies are effectively transparent."
"The purpose of the client transaction is to receive a request from the element in which the client is embedded (call this element the ""Transaction User"" or TU; it can be a UA or a stateful proxy), and reliably deliver the request to a server transaction. Rosenberg, et. al. Standards Track [Page 123] RFC 3261 SIP: Session Initiation Protocol June 2002 The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK). Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response. Similarly, the purpose of the server transaction is to receive requests from the transport layer and deliver them to the TU. The server transaction filters any request retransmissions from the network. The server transaction accepts responses from the TU and delivers them to the transport layer for transmission over the network. In the case of an INVITE transaction, it absorbs the ACK request for any final response excepting a 2xx response. The 2xx response and its ACK receive special treatment. This response is retransmitted only by a UAS, and its ACK generated only by the UAC. This end-to-end treatment is needed so that a caller knows the entire set of users that have accepted the call. Because of this special handling, retransmissions of the 2xx response are handled by the UA core, not the transaction layer. Similarly, generation of the ACK for the 2xx is handled by the UA core. Each proxy along the path merely forwards each 2xx response to INVITE and its corresponding ACK. 17.1 Client Transaction The client transaction provides its functionality through the maintenance of a state machine. The TU communicates with the client transaction through a simple interface. When the TU wishes to initiate a new transaction, it creates a client transaction and passes it the SIP request to send and an IP address, port, and transport to which to send it. The client transaction begins execution of its state machine. Valid responses are passed up to the TU from the client transaction. There are two types of client transaction state machines, depending on the method of the request passed by the TU. One handles client transactions for INVITE requests. This type of machine is referred to as an INVITE client transaction. Another type handles client transactions for all requests except INVITE and ACK. This is referred to as a non-INVITE client transaction. There is no client transaction for ACK. If the TU wishes to send an ACK, it passes one directly to the transport layer for transmission. Rosenberg, et. al. Standards Track [Page 124] RFC 3261 SIP: Session Initiation Protocol June 2002 The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is required in order to respond to an INVITE. The long delays expected for sending a response argue for a three-way handshake. On the other hand, requests of other methods are expected to complete rapidly. Because of the non-INVITE transaction's reliance on a two-way handshake, TUs SHOULD respond immediately to non-INVITE requests. 17.1.1 INVITE Client Transaction 17.1.1.1 Overview of INVITE Transaction The INVITE transaction consists of a three-way handshake. The client transaction sends an INVITE, the server transaction sends responses, and the client transaction sends an ACK. For unreliable transports (such as UDP), the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission. T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms. Nearly all of the transaction timers described here scale with T1, and changing T1 adjusts their values. The request is not retransmitted over reliable transports. After receiving a 1xx response, any retransmissions cease altogether, and the client waits for further responses. The server transaction can send additional 1xx responses, which are not transmitted reliably by the server transaction. Eventually, the server transaction decides to send a final response. For unreliable transports, that response is retransmitted periodically, and for reliable transports, it is sent once. For each final response that is received at the client transaction, the client transaction sends an ACK, the purpose of which is to quench retransmissions of the response. 17.1.1.2 Formal Description The state machine for the INVITE client transaction is shown in Figure 5. The initial state, ""calling"", MUST be entered when the TU initiates a new client transaction with an INVITE request. The client transaction MUST pass the request to the transport layer for transmission (see Section 18). If an unreliable transport is being used, the client transaction MUST start timer A with a value of T1. If a reliable transport is being used, the client transaction SHOULD NOT start timer A (Timer A controls request retransmissions). For any transport, the client transaction MUST start timer B with a value of 64*T1 seconds (Timer B controls transaction timeouts). When timer A fires, the client transaction MUST retransmit the request by passing it to the transport layer, and MUST reset the timer with a value of 2*T1. The formal definition of retransmit Rosenberg, et. al. Standards Track [Page 125] RFC 3261 SIP: Session Initiation Protocol June 2002 within the context of the transaction layer is to take the message previously sent to the transport layer and pass it to the transport layer once more. When timer A fires 2*T1 seconds later, the request MUST be retransmitted again (assuming the client transaction is still in this state). This process MUST continue so that the request is retransmitted with intervals that double after each transmission. These retransmissions SHOULD only be done while the client transaction is in the ""calling"" state. The default value for T1 is 500 ms. T1 is an estimate of the RTT between the client and server transactions. Elements MAY (though it is NOT RECOMMENDED) use smaller values of T1 within closed, private networks that do not permit general Internet connection. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. Whatever the value of T1, the exponential backoffs on retransmissions described in this section MUST be used. If the client transaction is still in the ""Calling"" state when timer B fires, the client transaction SHOULD inform the TU that a timeout has occurred. The client transaction MUST NOT generate an ACK. The value of 64*T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport. If the client transaction receives a provisional response while in the ""Calling"" state, it transitions to the ""Proceeding"" state. In the ""Proceeding"" state, the client transaction SHOULD NOT retransmit the request any longer. Furthermore, the provisional response MUST be passed to the TU. Any further provisional responses MUST be passed up to the TU while in the ""Proceeding"" state. When in either the ""Calling"" or ""Proceeding"" states, reception of a response with status code from 300-699 MUST cause the client transaction to transition to ""Completed"". The client transaction MUST pass the received response up to the TU, and the client transaction MUST generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) and then pass the ACK to the transport layer for transmission. The ACK MUST be sent to the same address, port, and transport to which the original request was sent. The client transaction SHOULD start timer D when it enters the ""Completed"" state, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction can remain in the ""Completed"" state when unreliable transports are used. This is equal to Timer H in the INVITE server transaction, whose Rosenberg, et. al. Standards Track [Page 126] RFC 3261 SIP: Session Initiation Protocol June 2002 default is 64*T1. However, the client transaction does not know the value of T1 in use by the server transaction, so an absolute minimum of 32s is used instead of basing Timer D on T1. Any retransmissions of the final response that are received while in the ""Completed"" state MUST cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response MUST NOT be passed up to the TU. A retransmission of the response is defined as any response which would match the same client transaction based on the rules of Section 17.1.3. Rosenberg, et. al. Standards Track [Page 127] RFC 3261 SIP: Session Initiation Protocol June 2002 |INVITE from TU Timer A fires |INVITE sent Reset A, V Timer B fires INVITE sent +-----------+ or Transport Err. +---------| |---------------+inform TU | | Calling | | +-------->| |-------------->| +-----------+ 2xx | | | 2xx to TU | | |1xx | 300-699 +---------------+ |1xx to TU | ACK sent | | | resp. to TU | 1xx V | | 1xx to TU -----------+ | | +---------| | | | | |Proceeding |-------------->| | +-------->| | 2xx | | +-----------+ 2xx to TU | | 300-699 | | | ACK sent, | | | resp. to TU| | | | | NOTE: | 300-699 V | | ACK sent +-----------+Transport Err. | transitions | +---------| |Inform TU | labeled with | | | Completed |-------------->| the event | +-------->| | | over the action | +-----------+ | to take | ^ | | | | | Timer D fires | +--------------+ | - | | | V | +-----------+ | | | | | Terminated|<--------------+ | | +-----------+ Figure 5: INVITE client transaction If timer D fires while the client transaction is in the ""Completed"" state, the client transaction MUST move to the terminated state. When in either the ""Calling"" or ""Proceeding"" states, reception of a 2xx response MUST cause the client transaction to enter the ""Terminated"" state, and the response MUST be passed up to the TU. The handling of this response depends on whether the TU is a proxy Rosenberg, et. al. Standards Track [Page 128] RFC 3261 SIP: Session Initiation Protocol June 2002 core or a UAC core. A UAC core will handle generation of the ACK for this response, while a proxy core will always forward the 200 (OK) upstream. The differing treatment of 200 (OK) between proxy and UAC is the reason that handling of it does not take place in the transaction layer. The client transaction MUST be destroyed the instant it enters the ""Terminated"" state. This is actually necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core. Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no match and therefore be passed to the core. 17.1.1.3 Construction of the ACK Request This section specifies the construction of ACK requests sent within the client transaction. A UAC core that generates an ACK for 2xx MUST instead follow the rules described in Section 13. The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the ""original request""). The To header field in the ACK MUST equal the To header field in the response being acknowledged, and therefore will usually differ from the To header field in the original request by the addition of the tag parameter. The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request. The CSeq header field in the ACK MUST contain the same value for the sequence number as was present in the original request, but the method parameter MUST be equal to ""ACK"". Rosenberg, et. al. Standards Track [Page 129] RFC 3261 SIP: Session Initiation Protocol June 2002 If the INVITE request whose response is being acknowledged had Route header fields, those header fields MUST appear in the ACK. This is to ensure that the ACK can be routed properly through any downstream stateless proxies. Although any request MAY contain a body, a body in an ACK is special since the request cannot be rejected if the body is not understood. Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, but if done, the body types are restricted to any that appeared in the INVITE, assuming that the response to the INVITE was not 415. If it was, the body in the ACK MAY be any type listed in the Accept header field in the 415. For example, consider the following request: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 INVITE The ACK request for a non-2xx final response to this request would look like this: ACK sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob <sip:bob@biloxi.com>;tag=99sa0xk From: Alice <sip:alice@atlanta.com>;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 ACK 17.1.2 Non-INVITE Client Transaction 17.1.2.1 Overview of the non-INVITE Transaction Non-INVITE transactions do not make use of ACK. They are simple request-response interactions. For unreliable transports, requests are retransmitted at an interval which starts at T1 and doubles until it hits T2. If a provisional response is received, retransmissions continue for unreliable transports, but at an interval of T2. The server transaction retransmits the last response it sent, which can be a provisional or final response, only when a retransmission of the request is received. This is why request retransmissions need to continue even after a provisional response; they are to ensure reliable delivery of the final response. Rosenberg, et. al. Standards Track [Page 130] RFC 3261 SIP: Session Initiation Protocol June 2002 Unlike an INVITE transaction, a non-INVITE transaction has no special handling for the 2xx response. The result is that only a single 2xx response to a non-INVITE is ever delivered to a UAC. 17.1.2.2 Formal Description The state machine for the non-INVITE client transaction is shown in Figure 6. It is very similar to the state machine for INVITE. The ""Trying"" state is entered when the TU initiates a new client transaction with a request. When entering this state, the client transaction SHOULD set timer F to fire in 64*T1 seconds. The request MUST be passed to the transport layer for transmission. If an unreliable transport is in use, the client transaction MUST set timer E to fire in T1 seconds. If timer E fires while still in this state, the timer is reset, but this time with a value of MIN(2*T1, T2). When the timer fires again, it is reset to a MIN(4*T1, T2). This process continues so that retransmissions occur with an exponentially increasing interval that caps at T2. The default value of T2 is 4s, and it represents the amount of time a non-INVITE server transaction will take to respond to a request, if it does not respond immediately. For the default values of T1 and T2, this results in intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. If Timer F fires while the client transaction is still in the ""Trying"" state, the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the ""Terminated"" state. If a provisional response is received while in the ""Trying"" state, the response MUST be passed to the TU, and then the client transaction SHOULD move to the ""Proceeding"" state. If a final response (status codes 200-699) is received while in the ""Trying"" state, the response MUST be passed to the TU, and the client transaction MUST transition to the ""Completed"" state. If Timer E fires while in the ""Proceeding"" state, the request MUST be passed to the transport layer for retransmission, and Timer E MUST be reset with a value of T2 seconds. If timer F fires while in the ""Proceeding"" state, the TU MUST be informed of a timeout, and the client transaction MUST transition to the terminated state. If a final response (status codes 200-699) is received while in the ""Proceeding"" state, the response MUST be passed to the TU, and the client transaction MUST transition to the ""Completed"" state. Once the client transaction enters the ""Completed"" state, it MUST set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. The ""Completed"" state exists to buffer any additional response retransmissions that may be received (which is why the client transaction remains there only for Rosenberg, et. al. Standards Track [Page 131] RFC 3261 SIP: Session Initiation Protocol June 2002 unreliable transports). T4 represents the amount of time the network will take to clear messages between client and server transactions. The default value of T4 is 5s. A response is a retransmission when it matches the same transaction, using the rules specified in Section 17.1.3. If Timer K fires while in this state, the client transaction MUST transition to the ""Terminated"" state. Once the transaction is in the terminated state, it MUST be destroyed immediately. 17.1.3 Matching Responses to Client Transactions When the transport layer in the client receives a response, it has to determine which client transaction will handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place. The branch parameter in the top Via header field is used for this purpose. A response matches a client transaction under two conditions: 1. If the response has the same value of the branch parameter in the top Via header field as the branch parameter in the top Via header field of the request that created the transaction. 2. If the method parameter in the CSeq header field matches the method of the request that created the transaction. The method is needed since a CANCEL request constitutes a different transaction, but shares the same value of the branch parameter. If a request is sent via multicast, it is possible that it will generate multiple responses from different servers. These responses will all have the same branch parameter in the topmost Via, but vary in the To tag. The first response received, based on the rules above, will be used, and others will be viewed as retransmissions. That is not an error; multicast SIP provides only a rudimentary ""single-hop-discovery-like"" service that is limited to processing a single response. See Section 18.1.1 for details. Rosenberg, et. al. Standards Track [Page 132] RFC 3261 SIP: Session Initiation Protocol June 2002 17.1.4 Handling Transport Errors |Request from TU |send request Timer E V send request +-----------+ +---------| |-------------------+ | | Trying | Timer F | +-------->| | or Transport Err.| +-----------+ inform TU | 200-699 | | | resp. to TU | |1xx | +---------------+ |resp. to TU | | | | | Timer E V Timer F | | send req +-----------+ or Transport Err. | | +---------| | inform TU | | | |Proceeding |------------------>| | +-------->| |-----+ | | +-----------+ |1xx | | | ^ |resp to TU | | 200-699 | +--------+ | | resp. to TU | | | | | | V | | +-----------+ | | | | | | | Completed | | | | | | | +-----------+ | | ^ | | | | | Timer K | +--------------+ | - | | | V | NOTE: +-----------+ | | | | transitions | Terminated|<------------------+ labeled with | | the event +-----------+ over the action to take Figure 6: non-INVITE client transaction When the client transaction sends a request to the transport layer to be sent, the following procedures are followed if the transport layer indicates a failure. Rosenberg, et. al. Standards Track [Page 133] RFC 3261 SIP: Session Initiation Protocol June 2002 The client transaction SHOULD inform the TU that a transport failure has occurred, and the client transaction SHOULD transition directly to the ""Terminated"" state. The TU will handle the failover mechanisms described in [4]. 17.2 Server Transaction The server transaction is responsible for the delivery of requests to the TU and the reliable transmission of responses. It accomplishes this through a state machine. Server transactions are created by the core when a request is received, and transaction handling is desired for that request (this is not always the case). As with the client transactions, the state machine depends on whether the received request is an INVITE request. 17.2.1 INVITE Server Transaction The state diagram for the INVITE server transaction is shown in Figure 7. When a server transaction is constructed for a request, it enters the ""Proceeding"" state. The server transaction MUST generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it MAY generate a 100 (Trying) response. This provisional response is needed to quench request retransmissions rapidly in order to avoid network congestion. The 100 (Trying) response is constructed according to the procedures in Section 8.2.6, except that the insertion of tags in the To header field of the response (when none was present in the request) is downgraded from MAY to SHOULD NOT. The request MUST be passed to the TU. The TU passes any number of provisional responses to the server transaction. So long as the server transaction is in the ""Proceeding"" state, each of these MUST be passed to the transport layer for transmission. They are not sent reliably by the transaction layer (they are not retransmitted by it) and do not cause a change in the state of the server transaction. If a request retransmission is received while in the ""Proceeding"" state, the most recent provisional response that was received from the TU MUST be passed to the transport layer for retransmission. A request is a retransmission if it matches the same server transaction based on the rules of Section 17.2.3. If, while in the ""Proceeding"" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not Rosenberg, et. al. Standards Track [Page 134] RFC 3261 SIP: Session Initiation Protocol June 2002 retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction MUST then transition to the ""Terminated"" state. While in the ""Proceeding"" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response MUST be passed to the transport layer for transmission, and the state machine MUST enter the ""Completed"" state. For unreliable transports, timer G is set to fire in T1 seconds, and is not set to fire for reliable transports. This is a change from RFC 2543, where responses were always retransmitted, even over reliable transports. When the ""Completed"" state is entered, timer H MUST be set to fire in 64*T1 seconds for all transports. Timer H determines when the server transaction abandons retransmitting the response. Its value is chosen to equal Timer B, the amount of time a client transaction will continue to retry sending a request. If timer G fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2. This is identical to the retransmit behavior for requests in the ""Trying"" state of the non-INVITE client transaction. Furthermore, while in the ""Completed"" state, if a request retransmission is received, the server SHOULD pass the response to the transport for retransmission. If an ACK is received while the server transaction is in the ""Completed"" state, the server transaction MUST transition to the ""Confirmed"" state. As Timer G is ignored in this state, any retransmissions of the response will cease. If timer H fires while in the ""Completed"" state, it implies that the ACK was never received. In this case, the server transaction MUST transition to the ""Terminated"" state, and MUST indicate to the TU that a transaction failure has occurred. Rosenberg, et. al. Standards Track [Page 135] RFC 3261 SIP: Session Initiation Protocol June 2002 |INVITE |pass INV to TU INVITE V send 100 if TU won't in 200ms send response+-----------+ +--------| |--------+101-199 from TU | | Proceeding| |send response +------->| |<-------+ | | Transport Err. | | Inform TU | |--------------->+ +-----------+ | 300-699 from TU | |2xx from TU | send response | |send response | | +------------------>+ | | INVITE V Timer G fires | send response+-----------+ send response | +--------| |--------+ | | | Completed | | | +------->| |<-------+ | +-----------+ | | | | ACK | | | - | +------------------>+ | Timer H fires | V or Transport Err.| +-----------+ Inform TU | | | | | Confirmed | | | | | +-----------+ | | | |Timer I fires | |- | | | V | +-----------+ | | | | | Terminated|<---------------+ | | +-----------+ Figure 7: INVITE server transaction Rosenberg, et. al. Standards Track [Page 136] RFC 3261 SIP: Session Initiation Protocol June 2002 The purpose of the ""Confirmed"" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response. When this state is entered, timer I is set to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. Once timer I fires, the server MUST transition to the ""Terminated"" state. Once the transaction is in the ""Terminated"" state, it MUST be destroyed immediately. As with client transactions, this is needed to ensure reliability of the 2xx responses to INVITE. 17.2.2 Non-INVITE Server Transaction The state machine for the non-INVITE server transaction is shown in Figure 8. The state machine is initialized in the ""Trying"" state and is passed a request other than INVITE or ACK when initialized. This request is passed up to the TU. Once in the ""Trying"" state, any further request retransmissions are discarded. A request is a retransmission if it matches the same server transaction, using the rules specified in Section 17.2.3. While in the ""Trying"" state, if the TU passes a provisional response to the server transaction, the server transaction MUST enter the ""Proceeding"" state. The response MUST be passed to the transport layer for transmission. Any further provisional responses that are received from the TU while in the ""Proceeding"" state MUST be passed to the transport layer for transmission. If a retransmission of the request is received while in the ""Proceeding"" state, the most recently sent provisional response MUST be passed to the transport layer for retransmission. If the TU passes a final response (status codes 200-699) to the server while in the ""Proceeding"" state, the transaction MUST enter the ""Completed"" state, and the response MUST be passed to the transport layer for transmission. When the server transaction enters the ""Completed"" state, it MUST set Timer J to fire in 64*T1 seconds for unreliable transports, and zero seconds for reliable transports. While in the ""Completed"" state, the server transaction MUST pass the final response to the transport layer for retransmission whenever a retransmission of the request is received. Any other final responses passed by the TU to the server transaction MUST be discarded while in the ""Completed"" state. The server transaction remains in this state until Timer J fires, at which point it MUST transition to the ""Terminated"" state. The server transaction MUST be destroyed the instant it enters the ""Terminated"" state. Rosenberg, et. al. Standards Track [Page 137] RFC 3261 SIP: Session Initiation Protocol June 2002 17.2.3 Matching Requests to Server Transactions When a request is received from the network by the server, it has to be matched to an existing transaction. This is accomplished in the following manner. The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie ""z9hG4bK"", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if: 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and 3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE. This matching rule applies to both INVITE and non-INVITE transactions alike. The sent-by value is used as part of the matching process because there could be accidental or malicious duplication of branch parameters from different clients. If the branch parameter in the top Via header field is not present, or does not contain the magic cookie, the following procedures are used. These exist to handle backwards compatibility with RFC 2543 compliant implementations. The INVITE request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq, and top Via header field match those of the INVITE request which created the transaction. In this case, the INVITE is a retransmission of the original one that created the transaction. The ACK request matches a transaction if the Request- URI, From tag, Call-ID, CSeq number (not the method), and top Via header field match those of the INVITE request which created the transaction, and the To tag of the ACK matches the To tag of the response sent by the server transaction. Matching is done based on the matching rules defined for each of those header fields. Inclusion of the tag in the To header field in the ACK matching process helps disambiguate ACK for 2xx from ACK for other responses Rosenberg, et. al. Standards Track [Page 138] RFC 3261 SIP: Session Initiation Protocol June 2002 at a proxy, which may have forwarded both responses (This can occur in unusual conditions. Specifically, when a proxy forked a request, and then crashes, the responses may be delivered to another proxy, which might end up forwarding multiple responses upstream). An ACK request that matches an INVITE transaction matched by a previous ACK is considered a retransmission of that previous ACK. Rosenberg, et. al. Standards Track [Page 139] RFC 3261 SIP: Session Initiation Protocol June 2002 |Request received |pass to TU V +-----------+ | | | Trying |-------------+ | | | +-----------+ |200-699 from TU | |send response |1xx from TU | |send response | | | Request V 1xx from TU | send response+-----------+send response| +--------| |--------+ | | | Proceeding| | | +------->| |<-------+ | +<--------------| | | |Trnsprt Err +-----------+ | |Inform TU | | | | | | |200-699 from TU | | |send response | | Request V | | send response+-----------+ | | +--------| | | | | | Completed |<------------+ | +------->| | +<--------------| | |Trnsprt Err +-----------+ |Inform TU | | |Timer J fires | |- | | | V | +-----------+ | | | +-------------->| Terminated| | | +-----------+ Figure 8: non-INVITE server transaction For all other request methods, a request is matched to a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq (including the method), and top Via header field match those of the request that created the transaction. Matching is done based on the matching Rosenberg, et. al. Standards Track [Page 140] RFC 3261 SIP: Session Initiation Protocol June 2002 rules defined for each of those header fields. When a non-INVITE request matches an existing transaction, it is a retransmission of the request that created that transaction. Because the matching rules include the Request-URI, the server cannot match a response to a transaction. When the TU passes a response to the server transaction, it must pass it to the specific server transaction for which the response is targeted. 17.2.4 Handling Transport Errors When the server transaction sends a response to the transport layer to be sent, the following procedures are followed if the transport layer indicates a failure. First, the procedures in [4] are followed, which attempt to deliver the response to a backup. If those should all fail, based on the definition of failure in [4], the server transaction SHOULD inform the TU that a failure has occurred, and SHOULD transition to the terminated state. 18 Transport The transport layer is responsible for the actual transmission of requests and responses over network transports. This includes determination of the connection to use for a request or response in the case of connection-oriented transports. The transport layer is responsible for managing persistent connections for transport protocols like TCP and SCTP, or TLS over those, including ones opened to the transport layer. This includes connections opened by the client or server transports, so that connections are shared between client and server transport functions. These connections are indexed by the tuple formed from the address, port, and transport protocol at the far end of the connection. When a connection is opened by the transport layer, this index is set to the destination IP, port and transport. When the connection is accepted by the transport layer, this index is set to the source IP address, port number, and transport. Note that, because the source port is often ephemeral, but it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by the transport layer will frequently not be reused. The result is that two proxies in a ""peering"" relationship using a connection- oriented transport frequently will have two connections in use, one for transactions initiated in each direction. Rosenberg, et. al. Standards Track [Page 141] RFC 3261 SIP: Session Initiation Protocol June 2002 It is RECOMMENDED that connections be kept open for some implementation-defined duration after the last message was sent or received over that connection. This duration SHOULD at least equal the longest amount of time the element would need in order to bring a transaction from instantiation to the terminated state. This is to make it likely that transactions are completed over the same connection on which they are initiated (for example, request, response, and in the case of INVITE, ACK for non-2xx responses). This usually means at least 64*T1 (see Section 17.1.1.1 for a definition of T1). However, it could be larger in an element that has a TU using a large value for timer C (bullet 11 of Section 16.6), for example. All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them. 18.1 Clients 18.1.1 Sending Requests The client side of the transport layer is responsible for sending the request and receiving responses. The user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly TTL for multicast destinations. If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers. The 200 byte ""buffer"" between the message size and the MTU accommodates the fact that the response in SIP can be larger than the request. This happens due to the addition of Record-Route header field values to the responses to INVITE, for example."
"With the extra buffer, the response can be about 170 bytes larger than the request, and still not be fragmented on IPv4 (about 30 bytes Rosenberg, et. al. Standards Track [Page 142] RFC 3261 SIP: Session Initiation Protocol June 2002 is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU. If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not support TCP. It is anticipated that this behavior will be deprecated in a future revision of this specification. A client that sends a request to a multicast address MUST add the ""maddr"" parameter to its Via header field value containing the destination multicast address, and for IPv4, SHOULD add the ""ttl"" parameter with a value of 1. Usage of IPv6 multicast is not defined in this specification, and will be a subject of future standardization when the need arises. These rules result in a purposeful limitation of multicast in SIP. Its primary function is to provide a ""single-hop-discovery-like"" service, delivering a request to a group of homogeneous servers, where it is only required to process the response from any one of them. This functionality is most useful for registrations. In fact, based on the transaction processing rules in Section 17.1.3, the client transaction will accept the first response, and view any others as retransmissions because they all contain the same Via branch identifier. Before a request is sent, the client transport MUST insert a value of the ""sent-by"" field into the Via header field. This field contains an IP address or host name, and port. The usage of an FQDN is RECOMMENDED. This field is used for sending responses under certain conditions, described below. If the port is absent, the default value depends on the transport. It is 5060 for UDP, TCP and SCTP, 5061 for TLS. For reliable transports, the response is normally sent on the connection on which the request was received. Therefore, the client transport MUST be prepared to receive the response on the same connection used to send the request. Under error conditions, the server may attempt to open a new connection to send the response. To handle this case, the transport layer MUST also be prepared to receive an incoming connection on the source IP address from which the request was sent and port number in the ""sent-by"" field. It also Rosenberg, et. al. Standards Track [Page 143] RFC 3261 SIP: Session Initiation Protocol June 2002 MUST be prepared to receive incoming connections on any address and port that would be selected by a server based on the procedures described in Section 5 of [4]. For unreliable unicast transports, the client transport MUST be prepared to receive responses on the source IP address from which the request is sent (as responses are sent back to the source address) and the port number in the ""sent-by"" field. Furthermore, as with reliable transports, in certain cases the response will be sent elsewhere. The client MUST be prepared to receive responses on any address and port that would be selected by a server based on the procedures described in Section 5 of [4]. For multicast, the client transport MUST be prepared to receive responses on the same multicast group and port to which the request is sent (that is, it needs to be a member of the multicast group it sent the request to.) If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection MAY be opened and used. If a request is sent using multicast, it is sent to the group address, port, and TTL provided by the transport user. If a request is sent using unicast unreliable transports, it is sent to the IP address and port provided by the transport user. 18.1.2 Receiving Responses When a response is received, the client transport examines the top Via header field value. If the value of the ""sent-by"" parameter in that header field value does not correspond to a value that the client transport is configured to insert into requests, the response MUST be silently discarded. If there are any client transactions in existence, the client transport uses the matching procedures of Section 17.1.3 to attempt to match the response to an existing transaction. If there is a match, the response MUST be passed to that transaction. Otherwise, the response MUST be passed to the core (whether it be stateless proxy, stateful proxy, or UA) for further processing. Handling of these ""stray"" responses is dependent on the core (a proxy will forward them, while a UA will discard, for example). Rosenberg, et. al. Standards Track [Page 144] RFC 3261 SIP: Session Initiation Protocol June 2002 18.2 Servers 18.2.1 Receiving Requests A server SHOULD be prepared to receive requests on any IP address, port and transport combination that can be the result of a DNS lookup on a SIP or SIPS URI [4] that is handed out for the purposes of communicating with that server. In this context, ""handing out"" includes placing a URI in a Contact header field in a REGISTER request or a redirect response, or in a Record-Route header field in a request or response. A URI can also be ""handed out"" by placing it on a web page or business card. It is also RECOMMENDED that a server listen for requests on the default SIP ports (5060 for TCP and UDP, 5061 for TLS over TCP) on all public interfaces. The typical exception would be private networks, or when multiple server instances are running on the same host. For any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP. This is because a message may need to be sent using TCP, rather than UDP, if it is too large. As a result, the converse is not true. A server need not listen for UDP on a particular address and port just because it is listening on that same address and port for TCP. There may, of course, be other reasons why a server needs to listen for UDP on a particular address and port. When the server transport receives a request over any transport, it MUST examine the value of the ""sent-by"" parameter in the top Via header field value. If the host portion of the ""sent-by"" parameter contains a domain name, or if it contains an IP address that differs from the packet source address, the server MUST add a ""received"" parameter to that Via header field value. This parameter MUST contain the source address from which the packet was received. This is to assist the server transport layer in sending the response, since it must be sent to the source IP address from which the request came. Consider a request received by the server transport which looks like, in part: INVITE sip:bob@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060 The request is received with a source IP address of 192.0.2.4. Before passing the request up, the transport adds a ""received"" parameter, so that the request would look like, in part: INVITE sip:bob@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 Rosenberg, et. al. Standards Track [Page 145] RFC 3261 SIP: Session Initiation Protocol June 2002 Next, the server transport attempts to match the request to a server transaction. It does so using the matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed to that transaction for processing. If no match is found, the request is passed to the core, which may decide to construct a new server transaction for that request. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed. 18.2.2 Sending Responses The server transport uses the value of the top Via header field in order to determine where to send a response. It MUST follow the following process: o If the ""sent-protocol"" is a reliable transport protocol such as TCP or SCTP, or TLS over those, the response MUST be sent using the existing connection to the source of the original request that created the transaction, if that connection is still open. This requires the server transport to maintain an association between server transactions and transport connections. If that connection is no longer open, the server SHOULD open a connection to the IP address in the ""received"" parameter, if present, using the port in the ""sent-by"" value, or the default port for that transport, if no port is specified. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. o Otherwise, if the Via header field value contains a ""maddr"" parameter, the response MUST be forwarded to the address listed there, using the port indicated in ""sent-by"", or port 5060 if none is present. If the address is a multicast address, the response SHOULD be sent using the TTL indicated in the ""ttl"" parameter, or with a TTL of 1 if that parameter is not present. o Otherwise (for unreliable unicast transports), if the top Via has a ""received"" parameter, the response MUST be sent to the address in the ""received"" parameter, using the port indicated in the ""sent-by"" value, or using port 5060 if none is specified explicitly. If this fails, for example, elicits an ICMP ""port unreachable"" response, the procedures of Section 5 of [4] SHOULD be used to determine where to send the response. Rosenberg, et. al. Standards Track [Page 146] RFC 3261 SIP: Session Initiation Protocol June 2002 o Otherwise, if it is not receiver-tagged, the response MUST be sent to the address indicated by the ""sent-by"" value, using the procedures in Section 5 of [4]. 18.3 Framing In the case of message-oriented transports (such as UDP), if the message has a Content-Length header field, the message body is assumed to contain that many bytes. If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. If the transport packet ends before the end of the message body, this is considered an error. If the message is a response, it MUST be discarded. If the message is a request, the element SHOULD generate a 400 (Bad Request) response. If the message has no Content-Length header field, the message body is assumed to end at the end of the transport packet. In the case of stream-oriented transports such as TCP, the Content- Length header field indicates the size of the body. The Content- Length header field MUST be used with stream oriented transports. 18.4 Error Handling Error handling is independent of whether the message was a request or response. If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP error, the behavior depends on the type of ICMP error. Host, network, port or protocol unreachable errors, or parameter problem errors SHOULD cause the transport layer to inform the transport user of a failure in sending. Source quench and TTL exceeded ICMP errors SHOULD be ignored. If the transport user asks for a request to be sent over a reliable transport, and the result is a connection failure, the transport layer SHOULD inform the transport user of a failure in sending. 19 Common Message Components There are certain components of SIP messages that appear in various places within SIP messages (and sometimes, outside of them) that merit separate discussion. Rosenberg, et. al. Standards Track [Page 147] RFC 3261 SIP: Session Initiation Protocol June 2002 19.1 SIP and SIPS Uniform Resource Indicators A SIP or SIPS URI identifies a communications resource. Like all URIs, SIP and SIPS URIs may be placed in web pages, email messages, or printed literature. They contain sufficient information to initiate and maintain a communication session with the resource. Examples of communications resources include the following: o a user of an online service o an appearance on a multi-line phone o a mailbox on a messaging system o a PSTN number at a gateway service o a group (such as ""sales"" or ""helpdesk"") in an organization A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain. Any resource described by a SIP URI can be ""upgraded"" to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely. 19.1.1 SIP and SIPS URI Components The ""sip:"" and ""sips:"" schemes follow the guidelines in RFC 2396 [5]. They use a form similar to the mailto URL, allowing the specification of SIP request-header fields and the SIP message-body. This makes it possible to specify the subject, media type, or urgency of sessions initiated by using a URI on a web page or in an email message. The formal syntax for a SIP or SIPS URI is presented in Section 25. Its general form, in the case of a SIP URI, is: sip:user:password@host:port;uri-parameters?headers The format for a SIPS URI is the same, except that the scheme is ""sips"" instead of sip. These tokens, and some of the tokens in their expansions, have the following meanings: user: The identifier of a particular resource at the host being addressed. The term ""host"" in this context frequently refers to a domain. The ""userinfo"" of a URI consists of this user field, the password field, and the @ sign following them. The userinfo part of a URI is optional and MAY be absent when the Rosenberg, et. al. Standards Track [Page 148] RFC 3261 SIP: Session Initiation Protocol June 2002 destination host does not have a notion of users or when the host itself is the resource being identified. If the @ sign is present in a SIP or SIPS URI, the user field MUST NOT be empty. If the host being addressed can process telephone numbers, for instance, an Internet telephony gateway, a telephone- subscriber field defined in RFC 2806 [9] MAY be used to populate the user field. There are special escaping rules for encoding telephone-subscriber fields in SIP and SIPS URIs described in Section 19.1.2. password: A password associated with the user. While the SIP and SIPS URI syntax allows this field to be present, its use is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URIs) has proven to be a security risk in almost every case where it has been used. For instance, transporting a PIN number in this field exposes the PIN. Note that the password field is just an extension of the user portion. Implementations not wishing to give special significance to the password portion of the field MAY simply treat ""user:password"" as a single string. host: The host providing the SIP resource. The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is RECOMMENDED whenever possible. port: The port number where the request is to be sent. URI parameters: Parameters affecting a request constructed from the URI. URI parameters are added after the hostport component and are separated by semi-colons. URI parameters take the form: parameter-name ""="" parameter-value Even though an arbitrary number of URI parameters may be included in a URI, any given parameter-name MUST NOT appear more than once. This extensible mechanism includes the transport, maddr, ttl, user, method and lr parameters. Rosenberg, et. al. Standards Track [Page 149] RFC 3261 SIP: Session Initiation Protocol June 2002 The transport parameter determines the transport mechanism to be used for sending SIP messages, as specified in [4]. SIP can use any network transport protocol. Parameter names are defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST indicate a reliable transport. The maddr parameter indicates the server address to be contacted for this user, overriding any address derived from the host field. When an maddr parameter is present, the port and transport components of the URI apply to the address indicated in the maddr parameter value. [4] describes the proper interpretation of the transport, maddr, and hostport in order to obtain the destination address, port, and transport for sending a request. The maddr field has been used as a simple form of loose source routing. It allows a URI to specify a proxy that must be traversed en-route to the destination. Continuing to use the maddr parameter this way is strongly discouraged (the mechanisms that enable it are deprecated). Implementations should instead use the Route mechanism described in this document, establishing a pre-existing route set if necessary (see Section 8.1.1.1). This provides a full URI to describe the node to be traversed. The ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP. For example, to specify a call to alice@atlanta.com using multicast to 239.255.255.1 with a ttl of 15, the following URI would be used: sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value ""phone"" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it. The method of the SIP request constructed from the URI can be specified with the method parameter. Rosenberg, et. al. Standards Track [Page 150] RFC 3261 SIP: Session Initiation Protocol June 2002 The lr parameter, when present, indicates that the element responsible for this resource implements the routing mechanisms specified in this document. This parameter will be used in the URIs proxies place into Record-Route header field values, and may appear in the URIs in a pre-existing route set. This parameter is used to achieve backwards compatibility with systems implementing the strict-routing mechanisms of RFC 2543 and the rfc2543bis drafts up to bis-05. An element preparing to send a request based on a URI not containing this parameter can assume the receiving element implements strict-routing and reformat the message to preserve the information in the Request-URI. Since the uri-parameter mechanism is extensible, SIP elements MUST silently ignore any uri-parameters that they do not understand. Headers: Header fields to be included in a request constructed from the URI. Headers fields in the SIP request can be specified with the ""?"" mechanism within a URI. The header names and values are encoded in ampersand separated hname = hvalue pairs. The special hname ""body"" indicates that the associated hvalue is the message-body of the SIP request. Table 1 summarizes the use of SIP and SIPS URI components based on the context in which the URI appears. The external column describes URIs appearing anywhere outside of a SIP message, for instance on a web page or business card. Entries marked ""m"" are mandatory, those marked ""o"" are optional, and those marked ""-"" are not allowed. Elements processing URIs SHOULD ignore any disallowed components if they are present. The second column indicates the default value of an optional element if it is not present. ""--"" indicates that the element is either not optional, or has no default value. URIs in Contact header fields have different restrictions depending on the context in which the header field appears. One set applies to messages that establish and maintain dialogs (INVITE and its 200 (OK) response). The other applies to registration and redirection messages (REGISTER, its 200 (OK) response, and 3xx class responses to any method). Rosenberg, et. al. Standards Track [Page 151] RFC 3261 SIP: Session Initiation Protocol June 2002 19.1.2 Character Escaping Requirements dialog reg./redir. Contact/ default Req.-URI To From Contact R-R/Route external user -- o o o o o o password -- o o o o o o host -- m m m m m m port (1) o - - o o o user-param ip o o o o o o method INVITE - - - - - o maddr-param -- o - - o o o ttl-param 1 o - - o - o transp.-param (2) o - - o o o lr-param -- o - - - o o other-param -- o o o o o o headers -- - - - o - o (1): The default port value is transport and scheme dependent. The default is 5060 for sip: using UDP, TCP, or SCTP. The default is 5061 for sip: using TLS over TCP and sips: over TCP. (2): The default transport is scheme dependent. For sip:, it is UDP. For sips:, it is TCP. Table 1: Use and default values of URI components for SIP header field values, Request-URI and references SIP follows the requirements and guidelines of RFC 2396 [5] when defining the set of characters that must be escaped in a SIP URI, and uses its """"%"" HEX HEX"" mechanism for escaping. From RFC 2396 [5]: The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding [5]. Excluded US- ASCII characters (RFC 2396 [5]), such as space and control characters and characters used as URI delimiters, also MUST be escaped. URIs MUST NOT contain unescaped space and control characters. For each component, the set of valid BNF expansions defines exactly which characters may appear unescaped. All other characters MUST be escaped. For example, ""@"" is not in the set of characters in the user component, so the user ""j@s0n"" must have at least the @ sign encoded, as in ""j%40s0n"". Rosenberg, et. al. Standards Track [Page 152] RFC 3261 SIP: Session Initiation Protocol June 2002 Expanding the hname and hvalue tokens in Section 25 show that all URI reserved characters in header field names and values MUST be escaped. The telephone-subscriber subset of the user component has special escaping considerations. The set of characters not reserved in the RFC 2806 [9] description of telephone-subscriber contains a number of characters in various syntax elements that need to be escaped when used in SIP URIs. Any characters occurring in a telephone-subscriber that do not appear in an expansion of the BNF for the user rule MUST be escaped. Note that character escaping is not allowed in the host component of a SIP or SIPS URI (the % character is not valid in its expansion). This is likely to change in the future as requirements for Internationalized Domain Names are finalized. Current implementations MUST NOT attempt to improve robustness by treating received escaped characters in the host component as literally equivalent to their unescaped counterpart. The behavior required to meet the requirements of IDN may be significantly different. 19.1.3 Example SIP and SIPS URIs sip:alice@atlanta.com sip:alice:secretword@atlanta.com;transport=tcp sips:alice@atlanta.com?subject=project%20x&priority=urgent sip:+1-212-555-1212:1234@gateway.com;user=phone sips:1212@gateway.com sip:alice@192.0.2.4 sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com sip:alice;day=tuesday@atlanta.com The last sample URI above has a user field value of ""alice;day=tuesday"". The escaping rules defined above allow a semicolon to appear unescaped in this field. For the purposes of this protocol, the field is opaque. The structure of that value is only useful to the SIP element responsible for the resource. 19.1.4 URI Comparison Some operations in this specification require determining whether two SIP or SIPS URIs are equivalent. In this specification, registrars need to compare bindings in Contact URIs in REGISTER requests (see Section 10.3.). SIP and SIPS URIs are compared for equality according to the following rules: o A SIP and SIPS URI are never equivalent. Rosenberg, et. al. Standards Track [Page 153] RFC 3261 SIP: Session Initiation Protocol June 2002 o Comparison of the userinfo of SIP and SIPS URIs is case- sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise. o The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs. o Characters other than those in the ""reserved"" set (see RFC 2396 [5]) are equivalent to their """"%"" HEX HEX"" encoding. o An IP address that is the result of a DNS lookup of a host name does not match that host name. o For two URIs to be equal, the user, password, host, and port components must match. A URI omitting the user component will not match a URI that includes one. A URI omitting the password component will not match a URI that includes one. A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value. For instance, a URI omitting the optional port component will not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-parameter, user-parameter, and method components. Defining sip:user@host to not be equivalent to sip:user@host:5060 is a change from RFC 2543. When deriving addresses from URIs, equivalent addresses are expected from equivalent URIs. The URI sip:user@host:5060 will always resolve to port 5060. The URI sip:user@host may resolve to other ports through the DNS SRV mechanisms detailed in [4]. o URI uri-parameter components are compared as follows: - Any uri-parameter appearing in both URIs must match. - A user, ttl, or method uri-parameter appearing in only one URI never matches, even if it contains the default value. - A URI that includes an maddr parameter will not match a URI that contains no maddr parameter. - All other uri-parameters appearing in only one URI are ignored when comparing the URIs. Rosenberg, et. al. Standards Track [Page 154] RFC 3261 SIP: Session Initiation Protocol June 2002 o URI header components are never ignored. Any present header component MUST be present in both URIs and match for the URIs to match. The matching rules are defined for each header field in Section 20. The URIs within each of the following sets are equivalent: sip:%61lice@atlanta.com;transport=TCP sip:alice@AtLanTa.CoM;Transport=tcp sip:carol@chicago.com sip:carol@chicago.com;newparam=5 sip:carol@chicago.com;security=on sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com sip:alice@atlanta.com?subject=project%20x&priority=urgent sip:alice@atlanta.com?priority=urgent&subject=project%20x The URIs within each of the following sets are not equivalent: SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) sip:alice@AtLanTa.CoM;Transport=UDP sip:bob@biloxi.com (can resolve to different ports) sip:bob@biloxi.com:5060 sip:bob@biloxi.com (can resolve to different transports) sip:bob@biloxi.com;transport=udp sip:bob@biloxi.com (can resolve to different port and transports) sip:bob@biloxi.com:6000;transport=tcp sip:carol@chicago.com (different header component) sip:carol@chicago.com?Subject=next%20meeting sip:bob@phone21.boxesbybob.com (even though that's what sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) Note that equality is not transitive: o sip:carol@chicago.com and sip:carol@chicago.com;security=on are equivalent o sip:carol@chicago.com and sip:carol@chicago.com;security=off are equivalent Rosenberg, et. al. Standards Track [Page 155] RFC 3261 SIP: Session Initiation Protocol June 2002 o sip:carol@chicago.com;security=on and sip:carol@chicago.com;security=off are not equivalent 19.1.5 Forming Requests from a URI An implementation needs to take care when forming requests directly from a URI. URIs from business cards, web pages, and even from sources inside the protocol such as registered contacts may contain inappropriate header fields or body parts. An implementation MUST include any provided transport, maddr, ttl, or user parameter in the Request-URI of the formed request. If the URI contains a method parameter, its value MUST be used as the method of the request. The method parameter MUST NOT be placed in the Request-URI. Unknown URI parameters MUST be placed in the message's Request-URI. An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis. An implementation SHOULD NOT honor these obviously dangerous header fields: From, Call-ID, CSeq, Via, and Record-Route. An implementation SHOULD NOT honor any requested Route header field values in order to not be used as an unwitting agent in malicious attacks. An implementation SHOULD NOT honor requests to include header fields that may cause it to falsely advertise its location or capabilities. These include: Accept, Accept-Encoding, Accept-Language, Allow, Contact (in its dialog usage), Organization, Supported, and User- Agent. An implementation SHOULD verify the accuracy of any requested descriptive header fields, including: Content-Disposition, Content- Encoding, Content-Language, Content-Length, Content-Type, Date, Mime-Version, and Timestamp. If the request formed from constructing a message from a given URI is not a valid SIP request, the URI is invalid. An implementation MUST NOT proceed with transmitting the request. It should instead pursue the course of action due an invalid URI in the context it occurs. The constructed request can be invalid in many ways. These include, but are not limited to, syntax error in header fields, invalid combinations of URI parameters, or an incorrect description of the message body. Rosenberg, et. al. Standards Track [Page 156] RFC 3261 SIP: Session Initiation Protocol June 2002 Sending a request formed from a given URI may require capabilities unavailable to the implementation. The URI might indicate use of an unimplemented transport or extension, for example. An implementation SHOULD refuse to send these requests rather than modifying them to match their capabilities. An implementation MUST NOT send a request requiring an extension that it does not support. For example, such a request can be formed through the presence of a Require header parameter or a method URI parameter with an unknown or explicitly unsupported value. 19.1.6 Relating SIP URIs and tel URLs When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI. Thus, tel:+358-555-1234567;postd=pp22 becomes sip:+358-555-1234567;postd=pp22@foo.com;user=phone or sips:+358-555-1234567;postd=pp22@foo.com;user=phone not sip:+358-555-1234567@foo.com;postd=pp22;user=phone or sips:+358-555-1234567@foo.com;postd=pp22;user=phone In general, equivalent ""tel"" URLs converted to SIP or SIPS URIs in this fashion may not produce equivalent SIP or SIPS URIs. The userinfo of SIP and SIPS URIs are compared as a case-sensitive string. Variance in case-insensitive portions of tel URLs and reordering of tel URL parameters does not affect tel URL equivalence, but does affect the equivalence of SIP URIs formed from them. For example, tel:+358-555-1234567;postd=pp22 tel:+358-555-1234567;POSTD=PP22 are equivalent, while sip:+358-555-1234567;postd=pp22@foo.com;user=phone sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone Rosenberg, et. al. Standards Track [Page 157] RFC 3261 SIP: Session Initiation Protocol June 2002 are not. Likewise, tel:+358-555-1234567;postd=pp22;isub=1411 tel:+358-555-1234567;isub=1411;postd=pp22 are equivalent, while sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone are not. To mitigate this problem, elements constructing telephone-subscriber fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold any case-insensitive portion of telephone-subscriber to lower case, and order the telephone-subscriber parameters lexically by parameter name, excepting isdn-subaddress and post-dial, which occur first and in that order. (All components of a tel URL except for future- extension parameters are defined to be compared case-insensitive.) Following this suggestion, both tel:+358-555-1234567;postd=pp22 tel:+358-555-1234567;POSTD=PP22 become sip:+358-555-1234567;postd=pp22@foo.com;user=phone and both tel:+358-555-1234567;tsp=a.b;phone-context=5 tel:+358-555-1234567;phone-context=5;tsp=a.b become sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone 19.2 Option Tags Option tags are unique identifiers used to designate new options (extensions) in SIP. These tags are used in Require (Section 20.32), Proxy-Require (Section 20.29), Supported (Section 20.37) and Unsupported (Section 20.40) header fields. Note that these options appear as parameters in those header fields in an option-tag = token form (see Section 25 for the definition of token). Rosenberg, et. al. Standards Track [Page 158] RFC 3261 SIP: Session Initiation Protocol June 2002 Option tags are defined in standards track RFCs. This is a change from past practice, and is instituted to ensure continuing multi- vendor interoperability (see discussion in Section 20.32 and Section 20.37). An IANA registry of option tags is used to ensure easy reference. 19.3 Tags The ""tag"" parameter is used in the To and From header fields of SIP messages. It serves as a general mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from each participant in the dialog. When a UA sends a request outside of a dialog, it contains a From tag only, providing ""half"" of the dialog ID. The dialog is completed from the response(s), each of which contributes the second half in the To header field. The forking of SIP requests means that multiple dialogs can be established from a single request. This also explains the need for the two-sided dialog identifier; without a contribution from the recipients, the originator could not disambiguate the multiple dialogs established from a single request. When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. A property of this selection requirement is that a UA will place a different tag into the From header of an INVITE than it would place into the To header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a common case for ""hairpinning"" of calls in PSTN gateways. Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags. Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation-specific. Tags are helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server after a failure. A UAS can select the tag in such a way that a backup can recognize a request as part of a dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other state associated with it. 20 Header Fields The general syntax for header fields is covered in Section 7.3. This section lists the full set of header fields along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 [8]. Examples of each header field are given. Rosenberg, et. al. Standards Track [Page 159] RFC 3261 SIP: Session Initiation Protocol June 2002 Information about header fields in relation to methods and proxy processing is summarized in Tables 2 and 3. The ""where"" column describes the request and response types in which the header field can be used. Values in this column are: R: header field may only appear in requests; r: header field may only appear in responses; 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; c: header field is copied from the request to the response. An empty entry in the ""where"" column indicates that the header field may be present in all requests and responses. The ""proxy"" column describes the operations a proxy may perform on a header field: a: A proxy can add or concatenate the header field if not present. m: A proxy can modify an existing header field value. d: A proxy can delete a header field value. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. The next six columns relate to the presence of a header field in a method: c: Conditional; requirements on the header field depend on the context of the message. m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: The header field is optional. t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent. Rosenberg, et. al. Standards Track [Page 160] RFC 3261 SIP: Session Initiation Protocol June 2002 *: The header field is required if the message body is not empty. See Sections 20.14, 20.15 and 7.4 for details. -: The header field is not applicable. ""Optional"" means that an element MAY include the header field in a request or response, and a UA MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 20.32). A ""mandatory"" header field MUST be present in a request, and MUST be understood by the UAS receiving the request."
"A mandatory response header field MUST be present in the response, and the header field MUST be understood by the UAC processing the response. ""Not applicable"" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request. Similarly, a header field labeled ""not applicable"" for a response means that the UAS MUST NOT place the header field in the response, and the UAC MUST ignore the header field in the response. A UA SHOULD ignore extension header parameters that are not understood. A compact form of some common header field names is also defined for use when overall message size is an issue. The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. 20.1 Accept The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server SHOULD assume a default value of application/sdp. An empty Accept header field means that no formats are acceptable. Rosenberg, et. al. Standards Track [Page 161] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alert-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * CSeq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Table 2: Summary of header fields, A--O Rosenberg, et. al. Standards Track [Page 162] RFC 3261 SIP: Session Initiation Protocol June 2002 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o Table 3: Summary of header fields, P--Z; (1): copied with possible addition of tag Accept: application/sdp;level=1, application/x-private, text/html 20.2 Accept-Encoding The Accept-Encoding header field is similar to Accept, but restricts the content-codings [H3.5] that are acceptable in the response. See [H14.3]. The semantics in SIP are identical to those defined in [H14.3]. An empty Accept-Encoding header field is permissible. It is equivalent to Accept-Encoding: identity, that is, only the identity encoding, meaning no encoding, is permissible. If no Accept-Encoding header field is present, the server SHOULD assume a default value of identity. Rosenberg, et. al. Standards Track [Page 163] RFC 3261 SIP: Session Initiation Protocol June 2002 This differs slightly from the HTTP definition, which indicates that when not present, any encoding can be used, but the identity encoding is preferred. Example: Accept-Encoding: gzip 20.3 Accept-Language The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-Language header field is present, the server SHOULD assume all languages are acceptable to the client. The Accept-Language header field follows the syntax defined in [H14.4]. The rules for ordering the languages based on the ""q"" parameter apply to SIP as well. Example: Accept-Language: da, en-gb;q=0.8, en;q=0.7 20.4 Alert-Info When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS. When present in a 180 (Ringing) response, the Alert-Info header field specifies an alternative ringback tone to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature. The Alert-Info header field can introduce security risks. These risks and the ways to handle them are discussed in Section 20.9, which discusses the Call-Info header field since the risks are identical. In addition, a user SHOULD be able to disable this feature selectively. This helps prevent disruptions that could result from the use of this header field by untrusted elements. Example: Alert-Info: <http://www.example.com/sounds/moo.wav> Rosenberg, et. al. Standards Track [Page 164] RFC 3261 SIP: Session Initiation Protocol June 2002 20.5 Allow The Allow header field lists the set of methods supported by the UA generating the message. All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. The absence of an Allow header field MUST NOT be interpreted to mean that the UA sending the message supports no methods. Rather, it implies that the UA is not providing any information on what methods it supports. Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of messages needed. Example: Allow: INVITE, ACK, OPTIONS, CANCEL, BYE 20.6 Authentication-Info The Authentication-Info header field provides for mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field. Syntax and semantics follow those specified in RFC 2617 [17]. Example: Authentication-Info: nextnonce=""47364c23432d2e131a5fb210812c"" 20.7 Authorization The Authorization header field contains authentication credentials of a UA. Section 22.2 overviews the use of the Authorization header field, and Section 22.4 describes the syntax and semantics when used with HTTP authentication. This header field, along with Proxy-Authorization, breaks the general rules about multiple header field values. Although not a comma- separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line using the usual rules described in Section 7.3. Rosenberg, et. al. Standards Track [Page 165] RFC 3261 SIP: Session Initiation Protocol June 2002 In the example below, there are no quotes around the Digest parameter: Authorization: Digest username=""Alice"", realm=""atlanta.com"", nonce=""84a4cc6f3082121f32b42a2187831a9e"", response=""7587245234b3434cc3412213e5f113a5432"" 20.8 Call-ID The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte. The compact form of the Call-ID header field is i. Examples: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the ""purpose"" parameter. The ""icon"" parameter designates an image suitable as an iconic representation of the caller or callee. The ""info"" parameter describes the caller or callee in general, for example, through a web page. The ""card"" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, <http://www.example.com/alice/> ;purpose=info Rosenberg, et. al. Standards Track [Page 166] RFC 3261 SIP: Session Initiation Protocol June 2002 20.10 Contact A Contact header field value provides a URI whose meaning depends on the type of request or response it is in. A Contact header field value can contain a display name, a URI with URI parameters, and header parameters. This document defines the Contact parameters ""q"" and ""expires"". These parameters are only used when the Contact is present in a REGISTER request or response, or in a 3xx response. Additional parameters may be defined in other specifications. When the header field value contains a display name, the URI including all URI parameters is enclosed in ""<"" and "">"". If no ""<"" and "">"" are present, all parameters after the URI are header parameters, not URI parameters. The display name can be tokens, or a quoted string, if a larger character set is desired. Even if the ""display-name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, semicolon, or question mark. There may or may not be LWS between the display-name and the ""<"". These rules for parsing a display name, URI and URI parameters, and header parameters also apply for the header fields To and From. The Contact header field has a role similar to the Location header field in HTTP. However, the HTTP header field only allows one address, unquoted. Since URIs can contain commas and semicolons as reserved characters, they can be mistaken for header or parameter delimiters, respectively. The compact form of the Contact header field is m (for ""moved""). Examples: Contact: ""Mr. Watson"" <sip:watson@worcester.bell-telephone.com> ;q=0.7; expires=3600, ""Mr. Watson"" <mailto:watson@bell-telephone.com> ;q=0.1 m: <sips:bob@192.0.2.4>;expires=60 Rosenberg, et. al. Standards Track [Page 167] RFC 3261 SIP: Session Initiation Protocol June 2002 20.11 Content-Disposition The Content-Disposition header field describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS. This SIP header field extends the MIME Content- Type (RFC 2183 [18]). Several new ""disposition-types"" of the Content-Disposition header are defined by SIP. The value ""session"" indicates that the body part describes a session, for either calls or early (pre-call) media. The value ""render"" indicates that the body part should be displayed or otherwise rendered to the user. Note that the value ""render"" is used rather than ""inline"" to avoid the connotation that the MIME body is displayed as a part of the rendering of the entire message (since the MIME bodies of SIP messages oftentimes are not displayed to users). For backward-compatibility, if the Content-Disposition header field is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition ""session"", while other content types are ""render"". The disposition type ""icon"" indicates that the body part contains an image suitable as an iconic representation of the caller or callee that could be rendered informationally by a user agent when a message has been received, or persistently while a dialog takes place. The value ""alert"" indicates that the body part contains information, such as an audio clip, that should be rendered by the user agent in an attempt to alert the user to the receipt of a request, generally a request that initiates a dialog; this alerting body could for example be rendered as a ring tone for a phone call after a 180 Ringing provisional response has been sent. Any MIME body with a ""disposition-type"" that renders content to the user should only be processed when a message has been properly authenticated. The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of ""optional"" and ""required"". If the handling parameter is missing, the value ""required"" SHOULD be assumed. The handling parameter is described in RFC 3204 [19]. If this header field is missing, the MIME type determines the default content disposition. If there is none, ""render"" is assumed. Example: Content-Disposition: session Rosenberg, et. al. Standards Track [Page 168] RFC 3261 SIP: Session Initiation Protocol June 2002 20.12 Content-Encoding The Content-Encoding header field is used as a modifier to the ""media-type"". When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms MUST be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a body to be compressed without losing the identity of its underlying media type. If multiple encodings have been applied to an entity-body, the content codings MUST be listed in the order in which they were applied. All content-coding values are case-insensitive. IANA acts as a registry for content-coding value tokens. See [H3.5] for a definition of the syntax for content-coding. Clients MAY apply content encodings to the body in requests. A server MAY apply content encodings to the bodies in responses. The server MUST only use encodings listed in the Accept-Encoding header field in the request. The compact form of the Content-Encoding header field is e. Examples: Content-Encoding: gzip e: tar 20.13 Content-Language See [H14.12]. Example: Content-Language: fr 20.14 Content-Length The Content-Length header field indicates the size of the message- body, in decimal number of octets, sent to the recipient. Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as transport, the header field MUST be used. The size of the message-body does not include the CRLF separating header fields and body. Any Content-Length greater than or equal to zero is a valid value. If no body is present in a message, then the Content-Length header field value MUST be set to zero. Rosenberg, et. al. Standards Track [Page 169] RFC 3261 SIP: Session Initiation Protocol June 2002 The ability to omit Content-Length simplifies the creation of cgi-like scripts that dynamically generate responses. The compact form of the header field is l. Examples: Content-Length: 349 l: 173 20.15 Content-Type The Content-Type header field indicates the media type of the message-body sent to the recipient. The ""media-type"" element is defined in [H3.7]. The Content-Type header field MUST be present if the body is not empty. If the body is empty, and a Content-Type header field is present, it indicates that the body of the specific type has zero length (for example, an empty audio file). The compact form of the header field is c. Examples: Content-Type: application/sdp c: text/html; charset=ISO-8859-4 20.16 CSeq A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical. Example: CSeq: 4711 INVITE 20.17 Date The Date header field contains the date and time. Unlike HTTP/1.1, SIP only supports the most recent RFC 1123 [20] format for dates. As in [H3.3], SIP restricts the time zone in SIP-date to ""GMT"", while RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. The Date header field reflects the time when the request or response is first sent. Rosenberg, et. al. Standards Track [Page 170] RFC 3261 SIP: Session Initiation Protocol June 2002 The Date header field can be used by simple end systems without a battery-backed clock to acquire a notion of current time. However, in its GMT form, it requires clients to know their offset from GMT. Example: Date: Sat, 13 Nov 2010 23:29:00 GMT 20.18 Error-Info The Error-Info header field provides a pointer to additional information about the error status response. SIP UACs have user interface capabilities ranging from pop-up windows and audio on PC softclients to audio-only on ""black"" phones or endpoints connected via gateways. Rather than forcing a server generating an error to choose between sending an error status code with a detailed reason phrase and playing an audio recording, the Error-Info header field allows both to be sent. The UAC then has the choice of which error indicator to render to the caller. A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if it were a Contact in a redirect and generate a new INVITE, resulting in a recorded announcement session being established. A non-SIP URI MAY be rendered to the user. Examples: SIP/2.0 404 The number you have dialed is not in service Error-Info: <sip:not-in-service-recording@atlanta.com> 20.19 Expires The Expires header field gives the relative time after which the message (or content) expires. The precise meaning of this is method dependent. The expiration time in an INVITE does not affect the duration of the actual session that may result from the invitation. Session description protocols may offer the ability to express time limits on the session duration, however. The value of this field is an integral number of seconds (in decimal) between 0 and (2**32)-1, measured from the receipt of the request. Rosenberg, et. al. Standards Track [Page 171] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Expires: 5 20.20 From The From header field indicates the initiator of the request. This may be different from the initiator of the dialog. Requests sent by the callee to the caller use the callee's address in the From header field. The optional ""display-name"" is meant to be rendered by a human user interface. A system SHOULD use the display name ""Anonymous"" if the identity of the client is to remain hidden. Even if the ""display- name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. Two From header fields are equivalent if their URIs match, and their parameters match. Extension parameters in one header field, not present in the other are ignored for the purposes of comparison. This means that the display name and presence or absence of angle brackets do not affect matching. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters. The compact form of the From header field is f. Examples: From: ""A. G. Bell"" <sip:agb@bell-telephone.com> ;tag=a48s From: sip:+12125551212@server.phone2net.com;tag=887s f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 20.21 In-Reply-To The In-Reply-To header field enumerates the Call-IDs that this call references or returns. These Call-IDs may have been cached by the client then included in this header field in a return call. This allows automatic call distribution systems to route return calls to the originator of the first call. This also allows callees to filter calls, so that only return calls for calls they originated will be accepted. This field is not a substitute for request authentication. Rosenberg, et. al. Standards Track [Page 172] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com 20.22 Max-Forwards The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain. The Max-Forwards value is an integer in the range 0-255 indicating the remaining number of times this request message is allowed to be forwarded. This count is decremented by each server that forwards the request. The recommended initial value is 70. This header field should be inserted by elements that can not otherwise guarantee loop detection. For example, a B2BUA should insert a Max-Forwards header field. Example: Max-Forwards: 6 20.23 Min-Expires The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server. This includes Contact header fields that are stored by a registrar. The header field contains a decimal integer number of seconds from 0 to (2**32)-1. The use of the header field in a 423 (Interval Too Brief) response is described in Sections 10.2.8, 10.3, and 21.4.17. Example: Min-Expires: 60 20.24 MIME-Version See [H19.4.1]. Example: MIME-Version: 1.0 Rosenberg, et. al. Standards Track [Page 173] RFC 3261 SIP: Session Initiation Protocol June 2002 20.25 Organization The Organization header field conveys the name of the organization to which the SIP element issuing the request or response belongs. The field MAY be used by client software to filter calls. Example: Organization: Boxes by Bob 20.26 Priority The Priority header field indicates the urgency of the request as perceived by the client. The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. For these decisions, a message containing no Priority header field SHOULD be treated as if it specified a Priority of ""normal"". The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways. The header field can have the values ""non-urgent"", ""normal"", ""urgent"", and ""emergency"", but additional values can be defined elsewhere. It is RECOMMENDED that the value of ""emergency"" only be used when life, limb, or property are in imminent danger. Otherwise, there are no semantics defined for this header field. These are the values of RFC 2076 [38], with the addition of ""emergency"". Examples: Subject: A tornado is heading our way! Priority: emergency or Subject: Weekend plans Priority: non-urgent 20.27 Proxy-Authenticate A Proxy-Authenticate header field value contains an authentication challenge. The use of this header field is defined in [H14.33]. See Section 22.3 for further details on its usage. Rosenberg, et. al. Standards Track [Page 174] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Proxy-Authenticate: Digest realm=""atlanta.com"", domain=""sip:ss1.carrier.com"", qop=""auth"", nonce=""f84f1cec41e6cbe5aea9c8e88d359"", opaque="""", stale=FALSE, algorithm=MD5 20.28 Proxy-Authorization The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication. A Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. See Section 22.3 for a definition of the usage of this header field. This header field, along with Authorization, breaks the general rules about multiple header field names. Although not a comma-separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line using the usual rules described in Section 7.3.1. Example: Proxy-Authorization: Digest username=""Alice"", realm=""atlanta.com"", nonce=""c60f3082ee1212b402a21831ae"", response=""245f23415f11432b3434341c022"" 20.29 Proxy-Require The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the proxy. See Section 20.32 for more details on the mechanics of this message and a usage example. Example: Proxy-Require: foo 20.30 Record-Route The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy. Examples of its use with the Route header field are described in Sections 16.12.1. Rosenberg, et. al. Standards Track [Page 175] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Record-Route: <sip:server10.biloxi.com;lr>, <sip:bigbox3.site3.atlanta.com;lr> 20.31 Reply-To The Reply-To header field contains a logical return URI that may be different from the From header field. For example, the URI MAY be used to return missed calls or unestablished sessions. If the user wished to remain anonymous, the header field SHOULD either be omitted from the request or populated in such a way that does not reveal any private information. Even if the ""display-name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. Example: Reply-To: Bob <sip:bob@biloxi.com> 20.32 Require The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. Although an optional header field, the Require MUST NOT be ignored if it is present. The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs. Example: Require: 100rel 20.33 Retry-After The Retry-After header field can be used with a 500 (Server Internal Error) or 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client and with a 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 Rosenberg, et. al. Standards Track [Page 176] RFC 3261 SIP: Session Initiation Protocol June 2002 (Decline) response to indicate when the called party anticipates being available again. The value of this field is a positive integer number of seconds (in decimal) after the time of the response. An optional comment can be used to indicate additional information about the time of callback. An optional ""duration"" parameter indicates how long the called party will be reachable starting at the initial time of availability. If no duration parameter is given, the service is assumed to be available indefinitely. Examples: Retry-After: 18000;duration=3600 Retry-After: 120 (I'm in a meeting) 20.34 Route The Route header field is used to force routing for a request through the listed set of proxies. Examples of the use of the Route header field are in Section 16.12.1. Example: Route: <sip:bigbox3.site3.atlanta.com;lr>, <sip:server10.biloxi.com;lr> 20.35 Server The Server header field contains information about the software used by the UAS to handle the request. Revealing the specific software version of the server might allow the server to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the Server header field a configurable option. Example: Server: HomeServer v2 20.36 Subject The Subject header field provides a summary or indicates the nature of the call, allowing call filtering without having to parse the session description. The session description does not have to use the same subject indication as the invitation. The compact form of the Subject header field is s. Rosenberg, et. al. Standards Track [Page 177] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Subject: Need more boxes s: Tech Support 20.37 Supported The Supported header field enumerates all the extensions supported by the UAC or UAS. The Supported header field contains a list of option tags, described in Section 19.2, that are understood by the UAC or UAS. A UA compliant to this specification MUST only include option tags corresponding to standards-track RFCs. If empty, it means that no extensions are supported. The compact form of the Supported header field is k. Example: Supported: 100rel 20.38 Timestamp The Timestamp header field describes when the UAC sent the request to the UAS. See Section 8.2.6 for details on how to generate a response to a request that contains the header field. Although there is no normative behavior defined here that makes use of the header, it allows for extensions or SIP applications to obtain RTT estimates. Example: Timestamp: 54 20.39 To The To header field specifies the logical recipient of the request. The optional ""display-name"" is meant to be rendered by a human-user interface. The ""tag"" parameter serves as a general mechanism for dialog identification. See Section 19.3 for details of the ""tag"" parameter. Rosenberg, et. al. Standards Track [Page 178] RFC 3261 SIP: Session Initiation Protocol June 2002 Comparison of To header fields for equality is identical to comparison of From header fields. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters. The compact form of the To header field is t. The following are examples of valid To header fields: To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 t: sip:+12125551212@server.phone2net.com 20.40 Unsupported The Unsupported header field lists the features not supported by the UAS. See Section 20.32 for motivation. Example: Unsupported: foo 20.41 User-Agent The User-Agent header field contains information about the UAC originating the request. The semantics of this header field are defined in [H14.43]. Revealing the specific software version of the user agent might allow the user agent to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the User-Agent header field a configurable option. Example: User-Agent: Softphone Beta1.5 20.42 Via The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses. The branch ID parameter in the Via header field values serves as a transaction identifier, and is used by proxies to detect loops. A Via header field value contains the transport protocol used to send the message, the client's host name or network address, and possibly the port number at which it wishes to receive responses. A Via header field value can also contain parameters such as ""maddr"", ""ttl"", ""received"", and ""branch"", whose meaning and use are described Rosenberg, et. al. Standards Track [Page 179] RFC 3261 SIP: Session Initiation Protocol June 2002 in other sections. For implementations compliant to this specification, the value of the branch parameter MUST start with the magic cookie ""z9hG4bK"", as discussed in Section 8.1.1.7. Transport protocols defined here are ""UDP"", ""TCP"", ""TLS"", and ""SCTP"". ""TLS"" means TLS over TCP. When a request is sent to a SIPS URI, the protocol still indicates ""SIP"", and the transport protocol is TLS. Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 ;branch=z9hG4bK77asjd The compact form of the Via header field is v. In this example, the message originated from a multi-homed host with two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong as to which network interface would be used. Erlang.bell- telephone.com noticed the mismatch and added a parameter to the previous hop's Via header field value, containing the address that the packet actually came from. The host or network address and port number are not required to follow the SIP URI syntax. Specifically, LWS on either side of the "":"" or ""/"" is allowed, as shown here: Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 Even though this specification mandates that the branch parameter be present in all requests, the BNF for the header field indicates that it is optional. This allows interoperation with RFC 2543 elements, which did not have to insert the branch parameter. Two Via header fields are equal if their sent-protocol and sent-by fields are equal, both have the same set of parameters, and the values of all parameters are equal. 20.43 Warning The Warning header field is used to carry additional information about the status of a response. Warning header field values are sent with responses and contain a three-digit warning code, host name, and warning text. The ""warn-text"" should be in a natural language that is most likely to be intelligible to the human user receiving the response. This decision can be based on any available knowledge, such as the location of the user, the Accept-Language field in a request, or the Rosenberg, et. al. Standards Track [Page 180] RFC 3261 SIP: Session Initiation Protocol June 2002 Content-Language field in a response. The default language is i- default [21]. The currently-defined ""warn-code""s are listed below, with a recommended warn-text in English and a description of their meaning. These warnings describe failures induced by the session description. The first digit of warning codes beginning with ""3"" indicates warnings specific to SIP. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories. 300 Incompatible network protocol: One or more network protocols contained in the session description are not available. 301 Incompatible network address formats: One or more network address formats contained in the session description are not available. 302 Incompatible transport protocol: One or more transport protocols described in the session description are not available. 303 Incompatible bandwidth units: One or more bandwidth measurement units contained in the session description were not understood. 304 Media type not available: One or more media types contained in the session description are not available. 305 Incompatible media format: One or more media formats contained in the session description are not available. 306 Attribute not understood: One or more of the media attributes in the session description are not supported. 307 Session description parameter not understood: A parameter other than those listed above was not understood. 330 Multicast not available: The site where the user is located does not support multicast. 331 Unicast not available: The site where the user is located does not support unicast communication (usually due to the presence of a firewall). Rosenberg, et. al. Standards Track [Page 181] RFC 3261 SIP: Session Initiation Protocol June 2002 370 Insufficient bandwidth: The bandwidth specified in the session description or defined by the media exceeds that known to be available. 399 Miscellaneous warning: The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action. 1xx and 2xx have been taken by HTTP/1.1. Additional ""warn-code""s can be defined through IANA, as defined in Section 27.2. Examples: Warning: 307 isi.edu ""Session parameter 'foo' not understood"" Warning: 301 isi.edu ""Incompatible network address type 'E.164'"" 20.44 WWW-Authenticate A WWW-Authenticate header field value contains an authentication challenge. See Section 22.2 for further details on its usage. Example: WWW-Authenticate: Digest realm=""atlanta.com"", domain=""sip:boxesbybob.com"", qop=""auth"", nonce=""f84f1cec41e6cbe5aea9c8e88d359"", opaque="""", stale=FALSE, algorithm=MD5 21 Response Codes The response codes are consistent with, and extend, HTTP/1.1 response codes. Not all HTTP/1.1 response codes are appropriate, and only those that are appropriate are given here. Other HTTP/1.1 response codes SHOULD NOT be used. Also, SIP defines a new class, 6xx. 21.1 Provisional 1xx Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response. Note that 1xx responses are not transmitted reliably. They never cause the client to send an ACK. Provisional (1xx) responses MAY contain message bodies, including session descriptions. Rosenberg, et. al."
"Standards Track [Page 182] RFC 3261 SIP: Session Initiation Protocol June 2002 21.1.1 100 Trying This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC. The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy. 21.1.2 180 Ringing The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback. 21.1.3 181 Call Is Being Forwarded A server MAY use this status code to indicate that the call is being forwarded to a different set of destinations. 21.1.4 182 Queued The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, ""5 calls queued; expected waiting time is 15 minutes"". The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call. 21.1.5 183 Session Progress The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress. 21.2 Successful 2xx The request was successful. 21.2.1 200 OK The request has succeeded. The information returned with the response depends on the method used in the request. Rosenberg, et. al. Standards Track [Page 183] RFC 3261 SIP: Session Initiation Protocol June 2002 21.3 Redirection 3xx 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. 21.3.1 300 Multiple Choices The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location. The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body. The choices SHOULD also be listed as Contact fields (Section 20.10). Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. UAs MAY use the Contact header field value for automatic redirection or MAY ask the user to confirm a choice. However, this specification does not define any standard for such automatic selection. This status response is appropriate if the callee can be reached at several different locations and the server cannot or prefers not to proxy the request. 21.3.2 301 Moved Permanently The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field (Section 20.10). The requestor SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed. 21.3.3 302 Moved Temporarily The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 20.10). The Request-URI of the new request uses the value of the Contact header field in the response. Rosenberg, et. al. Standards Track [Page 184] RFC 3261 SIP: Session Initiation Protocol June 2002 The duration of the validity of the Contact URI can be indicated through an Expires (Section 20.19) header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions. If the URI cached from the Contact header field fails, the Request- URI from the redirected request MAY be tried again a single time. The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI may be available. 21.3.4 305 Use Proxy The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs. 21.3.5 380 Alternative Service The call was not successful, but alternative services are possible. The alternative services are described in the message body of the response. Formats for such bodies are not defined here, and may be the subject of future standardization. 21.4 Request Failure 4xx 4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful. 21.4.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, ""Missing Call-ID header field"". 21.4.2 401 Unauthorized The request requires user authentication. This response is issued by UASs and registrars, while 407 (Proxy Authentication Required) is used by proxy servers. Rosenberg, et. al. Standards Track [Page 185] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.3 402 Payment Required Reserved for future use. 21.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated. 21.4.5 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. 21.4.6 405 Method Not Allowed The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. The response MUST include an Allow header field containing a list of valid methods for the indicated address. 21.4.7 406 Not Acceptable The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request. 21.4.8 407 Proxy Authentication Required This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. SIP access authentication is explained in Sections 26 and 22.3. This status code can be used for applications where access to the communication channel (for example, a telephony gateway) rather than the callee requires authentication. 21.4.9 408 Request Timeout The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time. Rosenberg, et. al. Standards Track [Page 186] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.10 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. 21.4.11 413 Request Entity Too Large The server is refusing to process a request because the request entity-body is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. 21.4.12 414 Request-URI Too Long The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. 21.4.13 415 Unsupported Media Type The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. UAC processing of this response is described in Section 8.1.3.5. 21.4.14 416 Unsupported URI Scheme The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. Client processing of this response is described in Section 8.1.3.5. 21.4.15 420 Bad Extension The server did not understand the protocol extension specified in a Proxy-Require (Section 20.29) or Require (Section 20.32) header field. The server MUST include a list of the unsupported extensions in an Unsupported header field in the response. UAC processing of this response is described in Section 8.1.3.5. Rosenberg, et. al. Standards Track [Page 187] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.16 421 Extension Required The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. Responses with this status code MUST contain a Require header field listing the required extensions. A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client. 21.4.17 423 Interval Too Brief The server is rejecting the request because the expiration time of the resource refreshed by the request is too short. This response can be used by a registrar to reject a registration whose Contact header field expiration time was too small. The use of this response and the related Min-Expires header field are described in Sections 10.2.8, 10.3, and 20.23. 21.4.18 480 Temporarily Unavailable The callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the ""do not disturb"" feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure. This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user. 21.4.19 481 Call/Transaction Does Not Exist This status indicates that the UAS received a request that does not match any existing dialog or transaction. 21.4.20 482 Loop Detected The server has detected a loop (Section 16.3 Item 4). Rosenberg, et. al. Standards Track [Page 188] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.21 483 Too Many Hops The server received a request that contains a Max-Forwards (Section 20.22) header field with the value zero. 21.4.22 484 Address Incomplete The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase. This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response. 21.4.23 485 Ambiguous The Request-URI was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs. Example response to a request with the Request-URI sip:lee@example.com: SIP/2.0 485 Ambiguous Contact: Carol Lee <sip:carol.lee@example.com> Contact: Ping Lee <sip:p.lee@example.com> Contact: Lee M. Foote <sips:lee.foote@example.com> Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response. 21.4.24 486 Busy Here The callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response MAY indicate a better time to call in the Retry-After header field. The user could also be available Rosenberg, et. al. Standards Track [Page 189] RFC 3261 SIP: Session Initiation Protocol June 2002 elsewhere, such as through a voice mail service. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call. 21.4.25 487 Request Terminated The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself. 21.4.26 488 Not Acceptable Here The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. 21.4.27 491 Request Pending The request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes how such ""glare"" situations are resolved. 21.4.28 493 Undecipherable The request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. This response MAY have a single body containing an appropriate public key that should be used to encrypt MIME bodies sent to this UA. Details of the usage of this response code can be found in Section 23.2. 21.5 Server Failure 5xx 5xx responses are failure responses given when a server itself has erred. 21.5.1 500 Server Internal Error The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds. If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field. Rosenberg, et. al. Standards Track [Page 190] RFC 3261 SIP: Session Initiation Protocol June 2002 21.5.2 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies forward all requests regardless of method.) Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported. 21.5.3 502 Bad Gateway The server, while acting as a gateway or proxy, received an invalid response from the downstream server it accessed in attempting to fulfill the request. 21.5.4 503 Service Unavailable The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response. A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable). 21.5.5 504 Server Time-out The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server. 21.5.6 505 Version Not Supported The server does not support, or refuses to support, the SIP protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. Rosenberg, et. al. Standards Track [Page 191] RFC 3261 SIP: Session Initiation Protocol June 2002 21.5.7 513 Message Too Large The server was unable to process the request since the message length exceeded its capabilities. 21.6 Global Failures 6xx 6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI. 21.6.1 600 Busy Everywhere The callee's end system was contacted successfully but the callee is busy and does not wish to take the call at this time. The response MAY indicate a better time to call in the Retry-After header field. If the callee does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This status response is returned only if the client knows that no other end point (such as a voice mail system) will answer the request. Otherwise, 486 (Busy Here) should be returned. 21.6.2 603 Decline The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request. 21.6.3 604 Does Not Exist Anywhere The server has authoritative information that the user indicated in the Request-URI does not exist anywhere. 21.6.4 606 Not Acceptable The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable. A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response MAY contain a list of reasons in a Warning header field describing why the session described cannot be supported. Warning reason codes are listed in Section 20.43. Rosenberg, et. al. Standards Track [Page 192] RFC 3261 SIP: Session Initiation Protocol June 2002 A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response. This status response is returned only if the client knows that no other end point will answer the request. 22 Usage of HTTP Authentication SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it MAY challenge the initiator of the request to provide assurance of its identity. Once the originator has been identified, the recipient of the request SHOULD ascertain whether or not this user is authorized to make the request in question. No authorization systems are recommended or discussed in this document. The ""Digest"" authentication mechanism described in this section provides message authentication and replay protection only, without message integrity or confidentiality. Protective measures above and beyond those provided by Digest need to be taken to prevent active attackers from modifying SIP requests and responses. Note that due to its weak security, the usage of ""Basic"" authentication has been deprecated. Servers MUST NOT accept credentials using the ""Basic"" authorization scheme, and servers also MUST NOT challenge with ""Basic"". This is a change from RFC 2543. 22.1 Framework The framework for SIP authentication closely parallels that of HTTP (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical (although the usage of ""Basic"" as a scheme is not permitted). In SIP, a UAS uses the 401 (Unauthorized) response to challenge the identity of a UAC. Additionally, registrars and redirect servers MAY make use of 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead MAY use the 407 (Proxy Authentication Required) Rosenberg, et. al. Standards Track [Page 193] RFC 3261 SIP: Session Initiation Protocol June 2002 response. The requirements for inclusion of the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages are identical to those described in RFC 2617 [17]. Since SIP does not have the concept of a canonical root URL, the notion of protection spaces is interpreted differently in SIP. The realm string alone defines the protection domain. This is a change from RFC 2543, in which the Request-URI and the realm together defined the protection domain. This previous definition of protection domain caused some amount of confusion since the Request-URI sent by the UAC and the Request-URI received by the challenging server might be different, and indeed the final form of the Request-URI might not be known to the UAC. Also, the previous definition depended on the presence of a SIP URI in the Request-URI and seemed to rule out alternative URI schemes (for example, the tel URL). Operators of user agents or proxy servers that will authenticate received requests MUST adhere to the following guidelines for creation of a realm string for their server: o Realm strings MUST be globally unique. It is RECOMMENDED that a realm string contain a hostname or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17]. o Realm strings SHOULD present a human-readable identifier that can be rendered to a user. For example: INVITE sip:bob@biloxi.com SIP/2.0 Authorization: Digest realm=""biloxi.com"", <...> Generally, SIP authentication is meaningful for a specific realm, a protection domain. Thus, for Digest authentication, each such protection domain has its own set of usernames and passwords. If a server does not require authentication for a particular request, it MAY accept a default username, ""anonymous"", which has no password (password of """"). Similarly, UACs representing many users, such as PSTN gateways, MAY have their own device-specific username and password, rather than accounts for particular users, for their realm. While a server can legitimately challenge most SIP requests, there are two requests defined by this document that require special handling for authentication: ACK and CANCEL. Rosenberg, et. al. Standards Track [Page 194] RFC 3261 SIP: Session Initiation Protocol June 2002 Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK. Although the CANCEL method does take a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place). When a UAC receives a challenge, it SHOULD render to the user the contents of the ""realm"" parameter in the challenge (which appears in either a WWW-Authenticate header field or Proxy-Authenticate header field) if the UAC device does not already know of a credential for the realm in question. A service provider that pre-configures UAs with credentials for its realm should be aware that users will not have the opportunity to present their own credentials for this realm when challenged at a pre-configured device. Finally, note that even if a UAC can locate credentials that are associated with the proper realm, the potential exists that these credentials may no longer be valid or that the challenging server will not accept these credentials for whatever reason (especially when ""anonymous"" with no password is submitted). In this instance a server may repeat its challenge, or it may respond with a 403 Forbidden. A UAC MUST NOT re-attempt requests with the credentials that have just been rejected (though the request may be retried if the nonce was stale). 22.2 User-to-User Authentication When a UAS receives a request from a UAC, the UAS MAY authenticate the originator before the request is processed. If no credentials (in the Authorization header field) are provided in the request, the UAS can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status code. The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the realm. Rosenberg, et. al. Standards Track [Page 195] RFC 3261 SIP: Session Initiation Protocol June 2002 An example of the WWW-Authenticate header field in a 401 challenge is: WWW-Authenticate: Digest realm=""biloxi.com"", qop=""auth,auth-int"", nonce=""dcd98b7102dd2f0e8b11d0f600bfb0c093"", opaque=""5ccc069c403ebaf9f0171e9517f40e41"" When the originating UAC receives the 401 (Unauthorized), it SHOULD, if it is able, re-originate the request with the proper credentials. The UAC may require input from the originating user before proceeding. Once authentication credentials have been supplied (either directly by the user, or discovered in an internal keyring), UAs SHOULD cache the credentials for a given value of the To header field and ""realm"" and attempt to re-use these values on the next request for that destination. UAs MAY cache credentials in any way they would like. If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of ""anonymous"" and no password (a password of """"). Once credentials have been located, any UA that wishes to authenticate itself with a UAS or registrar -- usually, but not necessarily, after receiving a 401 (Unauthorized) response -- MAY do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the UA for the realm of the resource being requested as well as parameters required in support of authentication and replay protection. An example of the Authorization header field is: Authorization: Digest username=""bob"", realm=""biloxi.com"", nonce=""dcd98b7102dd2f0e8b11d0f600bfb0c093"", uri=""sip:bob@biloxi.com"", qop=auth, nc=00000001, cnonce=""0a4f113b"", response=""6629fae49393a05397450978507c4ef1"", opaque=""5ccc069c403ebaf9f0171e9517f40e41"" When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request. Rosenberg, et. al. Standards Track [Page 196] RFC 3261 SIP: Session Initiation Protocol June 2002 22.3 Proxy-to-User Authentication Similarly, when a UAC sends a request to a proxy server, the proxy server MAY authenticate the originator before the request is processed. If no credentials (in the Proxy-Authorization header field) are provided in the request, the proxy can challenge the originator to provide credentials by rejecting the request with a 407 (Proxy Authentication Required) status code. The proxy MUST populate the 407 (Proxy Authentication Required) message with a Proxy- Authenticate header field value applicable to the proxy for the requested resource. The use of Proxy-Authenticate and Proxy-Authorization parallel that described in [17], with one difference. Proxies MUST NOT add values to the Proxy-Authorization header field. All 407 (Proxy Authentication Required) responses MUST be forwarded upstream toward the UAC following the procedures for any other response. It is the UAC's responsibility to add the Proxy-Authorization header field value containing credentials for the realm of the proxy that has asked for authentication. If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different. When the originating UAC receives the 407 (Proxy Authentication Required) it SHOULD, if it is able, re-originate the request with the proper credentials. It should follow the same procedures for the display of the ""realm"" parameter that are given above for responding to 401. If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of ""anonymous"" and no password (a password of """"). The UAC SHOULD also cache the credentials used in the re-originated request. The following rule is RECOMMENDED for proxy credential caching: If a UA receives a Proxy-Authenticate header field value in a 401/407 response to a request with a particular Call-ID, it should incorporate credentials for that realm in all subsequent requests that contain the same Call-ID. These credentials MUST NOT be cached across dialogs; however, if a UA is configured with the realm of its local outbound proxy, when one exists, then the UA MAY cache Rosenberg, et. al. Standards Track [Page 197] RFC 3261 SIP: Session Initiation Protocol June 2002 credentials for that realm across dialogs. Note that this does mean a future request in a dialog could contain credentials that are not needed by any proxy along the Route header path. Any UA that wishes to authenticate itself to a proxy server -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) response -- MAY do so by including a Proxy- Authorization header field value with the request. The Proxy- Authorization request-header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization header field value consists of credentials containing the authentication information of the UA for the proxy and/or realm of the resource being requested. A Proxy-Authorization header field value applies only to the proxy whose realm is identified in the ""realm"" parameter (this proxy may previously have demanded authentication using the Proxy-Authenticate field). When multiple proxies are used in a chain, a Proxy- Authorization header field value MUST NOT be consumed by any proxy whose realm does not match the ""realm"" parameter specified in that value. Note that if an authentication scheme that does not support realms is used in the Proxy-Authorization header field, a proxy server MUST attempt to parse all Proxy-Authorization header field values to determine whether one of them has what the proxy server considers to be valid credentials. Because this is potentially very time- consuming in large networks, proxy servers SHOULD use an authentication scheme that supports realms in the Proxy-Authorization header field. If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may wish to challenge the UAC. In this case, the forking proxy server is responsible for aggregating these challenges into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be placed into the single response that is sent by the forking proxy to the UA; the ordering of these header field values is not significant. When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has retried the request with valid credentials. A forking proxy may forward a request simultaneously to multiple proxy servers that require authentication, each of which in turn will not forward the request until the originating UAC has authenticated itself in their respective realm. If the UAC does not provide credentials for Rosenberg, et. al. Standards Track [Page 198] RFC 3261 SIP: Session Initiation Protocol June 2002 each challenge, the proxy servers that issued the challenges will not forward requests to the UA where the destination user might be located, and therefore, the virtues of forking are largely lost. When resubmitting its request in response to a 401 (Unauthorized) or 407 (Proxy Authentication Required) that contains multiple challenges, a UAC MAY include an Authorization value for each WWW- Authenticate value and a Proxy-Authorization value for each Proxy- Authenticate value for which the UAC wishes to supply a credential. As noted above, multiple credentials in a request SHOULD be differentiated by the ""realm"" parameter. It is possible for multiple challenges associated with the same realm to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication Required). This can occur, for example, when multiple proxies within the same administrative domain, which use a common realm, are reached by a forking request. When it retries a request, a UAC MAY therefore supply multiple credentials in Authorization or Proxy-Authorization header fields with the same ""realm"" parameter value. The same credentials SHOULD be used for the same realm. 22.4 The Digest Authentication Scheme This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to SIP. The SIP scheme usage is almost completely identical to that for HTTP [17]. Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], SIP servers supporting RFC 2617 MUST ensure they are backwards compatible with RFC 2069. Procedures for this backwards compatibility are specified in RFC 2617. Note, however, that SIP servers MUST NOT accept or request Basic authentication. The rules for Digest authentication follow those defined in [17], with ""HTTP/1.1"" replaced by ""SIP/2.0"" in addition to the following differences: 1. The URI included in the challenge has the following BNF: URI = SIP-URI / SIPS-URI 2. The BNF in RFC 2617 has an error in that the 'uri' parameter of the Authorization header field for HTTP Digest Rosenberg, et. al. Standards Track [Page 199] RFC 3261 SIP: Session Initiation Protocol June 2002 authentication is not enclosed in quotation marks. (The example in Section 3.5 of RFC 2617 is correct.) For SIP, the 'uri' MUST be enclosed in quotation marks. 3. The BNF for digest-uri-value is: digest-uri-value = Request-URI ; as defined in Section 25 4. The example procedure for choosing a nonce based on Etag does not work for SIP. 5. The text in RFC 2617 [17] regarding cache operation does not apply to SIP. 6. RFC 2617 [17] requires that a server check that the URI in the request line and the URI included in the Authorization header field point to the same resource. In a SIP context, these two URIs may refer to different users, due to forwarding at some proxy. Therefore, in SIP, a server MAY check that the Request-URI in the Authorization header field value corresponds to a user for whom the server is willing to accept forwarded or direct requests, but it is not necessarily a failure if the two fields are not equivalent. 7. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when SIP messages have no body) that the hash of the entity-body resolves to the MD5 hash of an empty string, or: H(entity-body) = MD5("""") = ""d41d8cd98f00b204e9800998ecf8427e"" 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent. Therefore, any algorithms that have a dependency on the cnonce (including ""MD5-Sess"") require that the qop directive be sent. Use of the ""qop"" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since RFC 2543 was based on RFC 2069, the ""qop"" parameter must unfortunately remain optional for clients and servers to receive. However, servers MUST always send a ""qop"" parameter in WWW-Authenticate and Proxy-Authenticate header field values. If a client receives a ""qop"" parameter in a challenge header field, it MUST send the ""qop"" parameter in any resulting authorization header field. Rosenberg, et. al. Standards Track [Page 200] RFC 3261 SIP: Session Initiation Protocol June 2002 RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. RFC 2617 [17] defines mechanisms for backwards compatibility using the qop attribute in the request. These mechanisms MUST be used by a server to determine if the client supports the new mechanisms in RFC 2617 that were not specified in RFC 2069."
"23 S/MIME SIP messages carry MIME bodies and the MIME standard includes mechanisms for securing MIME contents to ensure both integrity and confidentiality (including the 'multipart/signed' and 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] and RFC 2633 [24]). Implementers should note, however, that there may be rare network intermediaries (not typical proxy servers) that rely on viewing or modifying the bodies of SIP messages (especially SDP), and that secure MIME may prevent these sorts of intermediaries from functioning. This applies particularly to certain types of firewalls. The PGP mechanism for encrypting the header fields and bodies of SIP messages described in RFC 2543 has been deprecated. 23.1 S/MIME Certificates The certificates that are used to identify an end-user for the purposes of S/MIME differ from those used by servers in one important respect - rather than asserting that the identity of the holder corresponds to a particular hostname, these certificates assert that the holder is identified by an end-user address. This address is composed of the concatenation of the ""userinfo"" ""@"" and ""domainname"" portions of a SIP or SIPS URI (in other words, an email address of the form ""bob@biloxi.com""), most commonly corresponding to a user's address-of-record. These certificates are also associated with keys that are used to sign or encrypt bodies of SIP messages. Bodies are signed with the private key of the sender (who may include their public key with the message as appropriate), but bodies are encrypted with the public key of the intended recipient. Obviously, senders must have foreknowledge of the public key of recipients in order to encrypt message bodies. Public keys can be stored within a UA on a virtual keyring. Rosenberg, et. al. Standards Track [Page 201] RFC 3261 SIP: Session Initiation Protocol June 2002 Each user agent that supports S/MIME MUST contain a keyring specifically for end-users' certificates. This keyring should map between addresses of record and corresponding certificates. Over time, users SHOULD use the same certificate when they populate the originating URI of signaling (the From header field) with the same address-of-record. Any mechanisms depending on the existence of end-user certificates are seriously limited in that there is virtually no consolidated authority today that provides certificates for end-user applications. However, users SHOULD acquire certificates from known public certificate authorities. As an alternative, users MAY create self- signed certificates. The implications of self-signed certificates are explored further in Section 26.4.2. Implementations may also use pre-configured certificates in deployments in which a previous trust relationship exists between all SIP entities. Above and beyond the problem of acquiring an end-user certificate, there are few well-known centralized directories that distribute end-user certificates. However, the holder of a certificate SHOULD publish their certificate in any public directories as appropriate. Similarly, UACs SHOULD support a mechanism for importing (manually or automatically) certificates discovered in public directories corresponding to the target URIs of SIP requests. 23.2 S/MIME Key Exchange SIP itself can also be used as a means to distribute public keys in the following manner. Whenever the CMS SignedData message is used in S/MIME for SIP, it MUST contain the certificate bearing the public key necessary to verify the signature. When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-INVITE request outside the context of a dialog, the UAC SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS service is EnvelopedData (and the public key of the target user is known), the UAC SHOULD send the EnvelopedData message encapsulated within a SignedData message. When a UAS receives a request containing an S/MIME CMS body that includes a certificate, the UAS SHOULD first validate the certificate, if possible, with any available root certificates for certificate authorities. The UAS SHOULD also determine the subject of the certificate (for S/MIME, the SubjectAltName will contain the appropriate identity) and compare this value to the From header field Rosenberg, et. al. Standards Track [Page 202] RFC 3261 SIP: Session Initiation Protocol June 2002 of the request. If the certificate cannot be verified, because it is self-signed, or signed by no known authority, or if it is verifiable but its subject does not correspond to the From header field of request, the UAS MUST notify its user of the status of the certificate (including the subject of the certificate, its signer, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified and the subject of the certificate corresponds to the From header field of the SIP request, or if the user (after notification) explicitly authorizes the use of the certificate, the UAS SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or a response to a non-INVITE request outside the context of a dialog, the UAS SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS service is EnvelopedData, the UAS SHOULD send the EnvelopedData message encapsulated within a SignedData message. When a UAC receives a response containing an S/MIME CMS body that includes a certificate, the UAC SHOULD first validate the certificate, if possible, with any appropriate root certificate. The UAC SHOULD also determine the subject of the certificate and compare this value to the To field of the response; although the two may very well be different, and this is not necessarily indicative of a security breach. If the certificate cannot be verified because it is self-signed, or signed by no known authority, the UAC MUST notify its user of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified, and the subject of the certificate corresponds to the To header field in the response, or if the user (after notification) explicitly authorizes the use of the certificate, the UAC SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. If the UAC had not transmitted its own certificate to the UAS in any previous transaction, it SHOULD use a CMS SignedData body for its next request or response. On future occasions, when the UA receives requests or responses that contain a From header field corresponding to a value in its keyring, the UA SHOULD compare the certificate offered in these messages with the existing certificate in its keyring. If there is a discrepancy, the UA MUST notify its user of a change of the certificate (preferably in terms that indicate that this is a potential security breach) and acquire the user's permission before continuing to Rosenberg, et. al. Standards Track [Page 203] RFC 3261 SIP: Session Initiation Protocol June 2002 process the signaling. If the user authorizes this certificate, it SHOULD be added to the keyring alongside any previous value(s) for this address-of-record. Note well however, that this key exchange mechanism does not guarantee the secure exchange of keys when self-signed certificates, or certificates signed by an obscure authority, are used - it is vulnerable to well-known attacks. In the opinion of the authors, however, the security it provides is proverbially better than nothing; it is in fact comparable to the widely used SSH application. These limitations are explored in greater detail in Section 26.4.2. If a UA receives an S/MIME body that has been encrypted with a public key unknown to the recipient, it MUST reject the request with a 493 (Undecipherable) response. This response SHOULD contain a valid certificate for the respondent (corresponding, if possible, to any address of record given in the To header field of the rejected request) within a MIME body with a 'certs-only' ""smime-type"" parameter. A 493 (Undecipherable) sent without any certificate indicates that the respondent cannot or will not utilize S/MIME encrypted messages, though they may still support S/MIME signatures. Note that a user agent that receives a request containing an S/MIME body that is not optional (with a Content-Disposition header ""handling"" parameter of ""required"") MUST reject the request with a 415 Unsupported Media Type response if the MIME type is not understood. A user agent that receives such a response when S/MIME is sent SHOULD notify its user that the remote device does not support S/MIME, and it MAY subsequently resend the request without S/MIME, if appropriate; however, this 415 response may constitute a downgrade attack. If a user agent sends an S/MIME body in a request, but receives a response that contains a MIME body that is not secured, the UAC SHOULD notify its user that the session could not be secured. However, if a user agent that supports S/MIME receives a request with an unsecured body, it SHOULD NOT respond with a secured body, but if it expects S/MIME from the sender (for example, because the sender's From header field value corresponds to an identity on its keychain), the UAS SHOULD notify its user that the session could not be secured. A number of conditions that arise in the previous text call for the notification of the user when an anomalous certificate-management event occurs. Users might well ask what they should do under these circumstances. First and foremost, an unexpected change in a certificate, or an absence of security when security is expected, are Rosenberg, et. al. Standards Track [Page 204] RFC 3261 SIP: Session Initiation Protocol June 2002 causes for caution but not necessarily indications that an attack is in progress. Users might abort any connection attempt or refuse a connection request they have received; in telephony parlance, they could hang up and call back. Users may wish to find an alternate means to contact the other party and confirm that their key has legitimately changed. Note that users are sometimes compelled to change their certificates, for example when they suspect that the secrecy of their private key has been compromised. When their private key is no longer private, users must legitimately generate a new key and re-establish trust with any users that held their old key. Finally, if during the course of a dialog a UA receives a certificate in a CMS SignedData message that does not correspond with the certificates previously exchanged during a dialog, the UA MUST notify its user of the change, preferably in terms that indicate that this is a potential security breach. 23.3 Securing MIME bodies There are two types of secure MIME bodies that are of interest to SIP: use of these bodies should follow the S/MIME specification [24] with a few variations. o ""multipart/signed"" MUST be used only with CMS detached signatures. This allows backwards compatibility with non-S/MIME- compliant recipients. o S/MIME bodies SHOULD have a Content-Disposition header field, and the value of the ""handling"" parameter SHOULD be ""required."" o If a UAC has no certificate on its keyring associated with the address-of-record to which it wants to send a request, it cannot send an encrypted ""application/pkcs7-mime"" MIME message. UACs MAY send an initial request such as an OPTIONS message with a CMS detached signature in order to solicit the certificate of the remote side (the signature SHOULD be over a ""message/sip"" body of the type described in Section 23.4). Note that future standardization work on S/MIME may define non-certificate based keys. o Senders of S/MIME bodies SHOULD use the ""SMIMECapabilities"" (see Section 2.5.2 of [24]) attribute to express their capabilities and preferences for further communications. Note especially that senders MAY use the ""preferSignedData"" Rosenberg, et. al. Standards Track [Page 205] RFC 3261 SIP: Session Initiation Protocol June 2002 capability to encourage receivers to respond with CMS SignedData messages (for example, when sending an OPTIONS request as described above). o S/MIME implementations MUST at a minimum support SHA1 as a digital signature algorithm, and 3DES as an encryption algorithm. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for these algorithms with the ""SMIMECapabilities"" attribute. o Each S/MIME body in a SIP message SHOULD be signed with only one certificate. If a UA receives a message with multiple signatures, the outermost signature should be treated as the single certificate for this body. Parallel signatures SHOULD NOT be used. The following is an example of an encrypted S/MIME SDP body within a SIP message: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Disposition: attachment; filename=smime.p7m handling=required ******************************************************* * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=- * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * ******************************************************* Rosenberg, et. al. Standards Track [Page 206] RFC 3261 SIP: Session Initiation Protocol June 2002 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP As a means of providing some degree of end-to-end authentication, integrity or confidentiality for SIP header fields, S/MIME can encapsulate entire SIP messages within MIME bodies of type ""message/sip"" and then apply MIME security to these bodies in the same manner as typical SIP bodies. These encapsulated SIP requests and responses do not constitute a separate dialog or transaction, they are a copy of the ""outer"" message that is used to verify integrity or to supply additional information. If a UAS receives a request that contains a tunneled ""message/sip"" S/MIME body, it SHOULD include a tunneled ""message/sip"" body in the response with the same smime-type. Any traditional MIME bodies (such as SDP) SHOULD be attached to the ""inner"" message so that they can also benefit from S/MIME security. Note that ""message/sip"" bodies can be sent as a part of a MIME ""multipart/mixed"" body if any unsecured MIME types should also be transmitted in a request. 23.4.1 Integrity and Confidentiality Properties of SIP Headers When the S/MIME integrity or confidentiality mechanisms are used, there may be discrepancies between the values in the ""inner"" message and values in the ""outer"" message. The rules for handling any such differences for all of the header fields described in this document are given in this section. Note that for the purposes of loose timestamping, all SIP messages that tunnel ""message/sip"" SHOULD contain a Date header in both the ""inner"" and ""outer"" headers. 23.4.1.1 Integrity Whenever integrity checks are performed, the integrity of a header field should be determined by matching the value of the header field in the signed body with that in the ""outer"" messages using the comparison rules of SIP as described in 20. Header fields that can be legitimately modified by proxy servers are: Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- Authorization. If these header fields are not intact end-to-end, implementations SHOULD NOT consider this a breach of security. Changes to any other header fields defined in this document constitute an integrity violation; users MUST be notified of a discrepancy. Rosenberg, et. al. Standards Track [Page 207] RFC 3261 SIP: Session Initiation Protocol June 2002 23.4.1.2 Confidentiality When messages are encrypted, header fields may be included in the encrypted body that are not present in the ""outer"" message. Some header fields must always have a plaintext version because they are required header fields in requests and responses - these include: To, From, Call-ID, CSeq, Contact. While it is probably not useful to provide an encrypted alternative for the Call-ID, CSeq, or Contact, providing an alternative to the information in the ""outer"" To or From is permitted. Note that the values in an encrypted body are not used for the purposes of identifying transactions or dialogs - they are merely informational. If the From header field in an encrypted body differs from the value in the ""outer"" message, the value within the encrypted body SHOULD be displayed to the user, but MUST NOT be used in the ""outer"" header fields of any future messages. Primarily, a user agent will want to encrypt header fields that have an end-to-end semantic, including: Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server, and Warning. If any of these header fields are present in an encrypted body, they should be used instead of any ""outer"" header fields, whether this entails displaying the header field values to users or setting internal states in the UA. They SHOULD NOT however be used in the ""outer"" headers of any future messages. If present, the Date header field MUST always be the same in the ""inner"" and ""outer"" headers. Since MIME bodies are attached to the ""inner"" message, implementations will usually encrypt MIME-specific header fields, including: MIME-Version, Content-Type, Content-Length, Content- Language, Content-Encoding and Content-Disposition. The ""outer"" message will have the proper MIME header fields for S/MIME bodies. These header fields (and any MIME bodies they preface) should be treated as normal MIME header fields and bodies received in a SIP message. It is not particularly useful to encrypt the following header fields: Min-Expires, Timestamp, Authorization, Priority, and WWW- Authenticate. This category also includes those header fields that can be changed by proxy servers (described in the preceding section). UAs SHOULD never include these in an ""inner"" message if they are not Rosenberg, et. al. Standards Track [Page 208] RFC 3261 SIP: Session Initiation Protocol June 2002 included in the ""outer"" message. UAs that receive any of these header fields in an encrypted body SHOULD ignore the encrypted values. Note that extensions to SIP may define additional header fields; the authors of these extensions should describe the integrity and confidentiality properties of such header fields. If a SIP UA encounters an unknown header field with an integrity violation, it MUST ignore the header field. 23.4.2 Tunneling Integrity and Authentication Tunneling SIP messages within S/MIME bodies can provide integrity for SIP header fields if the header fields that the sender wishes to secure are replicated in a ""message/sip"" MIME body signed with a CMS detached signature. Provided that the ""message/sip"" body contains at least the fundamental dialog identifiers (To, From, Call-ID, CSeq), then a signed MIME body can provide limited authentication. At the very least, if the certificate used to sign the body is unknown to the recipient and cannot be verified, the signature can be used to ascertain that a later request in a dialog was transmitted by the same certificate-holder that initiated the dialog. If the recipient of the signed MIME body has some stronger incentive to trust the certificate (they were able to validate it, they acquired it from a trusted repository, or they have used it frequently) then the signature can be taken as a stronger assertion of the identity of the subject of the certificate. In order to eliminate possible confusions about the addition or subtraction of entire header fields, senders SHOULD replicate all header fields from the request within the signed body. Any message bodies that require integrity protection MUST be attached to the ""inner"" message. If a Date header is present in a message with a signed body, the recipient SHOULD compare the header field value with its own internal clock, if applicable. If a significant time discrepancy is detected (on the order of an hour or more), the user agent SHOULD alert the user to the anomaly, and note that it is a potential security breach. If an integrity violation in a message is detected by its recipient, the message MAY be rejected with a 403 (Forbidden) response if it is a request, or any existing dialog MAY be terminated. UAs SHOULD notify users of this circumstance and request explicit guidance on how to proceed. Rosenberg, et. al. Standards Track [Page 209] RFC 3261 SIP: Session Initiation Protocol June 2002 The following is an example of the use of a tunneled ""message/sip"" body: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: multipart/signed; protocol=""application/pkcs7-signature""; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: message/sip INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <bob@biloxi.com> From: Alice <alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 pc33.atlanta.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required Rosenberg, et. al. Standards Track [Page 210] RFC 3261 SIP: Session Initiation Protocol June 2002 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 23.4.3 Tunneling Encryption It may also be desirable to use this mechanism to encrypt a ""message/sip"" MIME body within a CMS EnvelopedData message S/MIME body, but in practice, most header fields are of at least some use to the network; the general use of encryption with S/MIME is to secure message bodies like SDP rather than message headers. Some informational header fields, such as the Subject or Organization could perhaps warrant end-to-end security. Headers defined by future SIP applications might also require obfuscation. Another possible application of encrypting header fields is selective anonymity. A request could be constructed with a From header field that contains no personal information (for example, sip:anonymous@anonymizer.invalid). However, a second From header field containing the genuine address-of-record of the originator could be encrypted within a ""message/sip"" MIME body where it will only be visible to the endpoints of a dialog. Note that if this mechanism is used for anonymity, the From header field will no longer be usable by the recipient of a message as an index to their certificate keychain for retrieving the proper S/MIME key to associated with the sender. The message must first be decrypted, and the ""inner"" From header field MUST be used as an index. In order to provide end-to-end integrity, encrypted ""message/sip"" MIME bodies SHOULD be signed by the sender. This creates a ""multipart/signed"" MIME body that contains an encrypted body and a signature, both of type ""application/pkcs7-mime"". Rosenberg, et. al. Standards Track [Page 211] RFC 3261 SIP: Session Initiation Protocol June 2002 In the following example, of an encrypted and signed message, the text boxed in asterisks (""*"") is encrypted: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:pc33.atlanta.com> Content-Type: multipart/signed; protocol=""application/pkcs7-signature""; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m handling=required Content-Length: 231 *********************************************************** * Content-Type: message/sip * * * * INVITE sip:bob@biloxi.com SIP/2.0 * * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * * To: Bob <bob@biloxi.com> * * From: Alice <alice@atlanta.com>;tag=1928301774 * * Call-ID: a84b4c76e66710 * * CSeq: 314159 INVITE * * Max-Forwards: 70 * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Contact: <sip:alice@pc33.atlanta.com> * * * * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=Session SDP * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * *********************************************************** Rosenberg, et. al. Standards Track [Page 212] RFC 3261 SIP: Session Initiation Protocol June 2002 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 24 Examples In the following examples, we often omit the message body and the corresponding Content-Length and Content-Type header fields for brevity. 24.1 Registration Bob registers on start-up. The message flow is shown in Figure 9. Note that the authentication usually required for registration is not shown for simplicity. biloxi.com Bob's registrar softphone | | | REGISTER F1 | |<---------------| | 200 OK F2 | |--------------->| Figure 9: SIP Registration Example F1 REGISTER Bob -> Registrar REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0 Rosenberg, et. al. Standards Track [Page 213] RFC 3261 SIP: Session Initiation Protocol June 2002 The registration expires after two hours. The registrar responds with a 200 OK: F2 200 OK Registrar -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Bob <sip:bob@biloxi.com>;tag=2493k59kd From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0 24.2 Session Setup This example contains the full details of the example session setup in Section 4. The message flow is shown in Figure 1. Note that these flows show the minimum required set of header fields - some other header fields such as Allow and Supported would normally be present. F1 INVITE Alice -> atlanta.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Rosenberg, et. al. Standards Track [Page 214] RFC 3261 SIP: Session Initiation Protocol June 2002 F2 100 Trying atlanta.com proxy -> Alice SIP/2.0 100 Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 F3 INVITE atlanta.com proxy -> biloxi.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 69 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) F4 100 Trying biloxi.com proxy -> atlanta.com proxy SIP/2.0 100 Trying Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 215] RFC 3261 SIP: Session Initiation Protocol June 2002 F5 INVITE biloxi.com proxy -> Bob INVITE sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) F6 180 Ringing Bob -> biloxi.com proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 216] RFC 3261 SIP: Session Initiation Protocol June 2002 F8 180 Ringing atlanta.com proxy -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 F9 200 OK Bob -> biloxi.com proxy SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) F10 200 OK biloxi.com proxy -> atlanta.com proxy SIP/2.0 200 OK Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Rosenberg, et. al. Standards Track [Page 217] RFC 3261 SIP: Session Initiation Protocol June 2002 F11 200 OK atlanta.com proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) F12 ACK Alice -> Bob ACK sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0 The media session between Alice and Bob is now established. Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq numbering space, which, in this example, begins with 231. Since Bob is making the request, the To and From URIs and tags have been swapped. F13 BYE Bob -> Alice BYE sip:alice@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 218] RFC 3261 SIP: Session Initiation Protocol June 2002 F14 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 The SIP Call Flows document [40] contains further examples of SIP messages. 25 Augmented BNF for the SIP Protocol All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that are used by this specification, and not repeated here. Implementers need to be familiar with the notation and content of RFC 2234 in order to understand this specification. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions to clarify the use of rule names. The use of square brackets is redundant syntactically. It is used as a semantic hint that the specific parameter is optional to use. 25.1 Basic Rules The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986. alphanum = ALPHA / DIGIT Rosenberg, et. al. Standards Track [Page 219] RFC 3261 SIP: Session Initiation Protocol June 2002 Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include: reserved = "";"" / ""/"" / ""?"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" unreserved = alphanum / mark mark = ""-"" / ""_"" / ""."" / ""!"" / ""~"" / ""*"" / ""'"" / ""("" / "")"" escaped = ""%"" HEXDIG HEXDIG SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS construct is used when linear white space is optional, generally between tokens and separators. LWS = [*WSP CRLF] 1*WSP ; linear whitespace SWS = [LWS] ; sep whitespace To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines this construct. HCOLON = *( SP / HTAB ) "":"" SWS The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful. In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set. TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) TEXT-UTF8char = %x21-7E / UTF8-NONASCII UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF Rosenberg, et. al. Standards Track [Page 220] RFC 3261 SIP: Session Initiation Protocol June 2002 A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT- UTF8-TRIM value. Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case. LHEX = DIGIT / %x61-66 ;lowercase a-f Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise stated, tokens are case- insensitive. These special characters MUST be in a quoted string to be used within a parameter value. The word construct is used in Call-ID to allow most separators to be used. token = 1*(alphanum / ""-"" / ""."" / ""!"" / ""%"" / ""*"" / ""_"" / ""+"" / ""`"" / ""'"" / ""~"" ) separators = ""("" / "")"" / ""<"" / "">"" / ""@"" / "","" / "";"" / "":"" / ""\"" / DQUOTE / ""/"" / ""["" / ""]"" / ""?"" / ""="" / ""{"" / ""}"" / SP / HTAB word = 1*(alphanum / ""-"" / ""."" / ""!"" / ""%"" / ""*"" / ""_"" / ""+"" / ""`"" / ""'"" / ""~"" / ""("" / "")"" / ""<"" / "">"" / "":"" / ""\"" / DQUOTE / ""/"" / ""["" / ""]"" / ""?"" / ""{"" / ""}"" ) When tokens are used or separators are used between elements, whitespace is often allowed before or after these characters: STAR = SWS ""*"" SWS ; asterisk SLASH = SWS ""/"" SWS ; slash EQUAL = SWS ""="" SWS ; equal LPAREN = SWS ""("" SWS ; left parenthesis RPAREN = SWS "")"" SWS ; right parenthesis RAQUOT = "">"" SWS ; right angle quote LAQUOT = SWS ""<""; left angle quote COMMA = SWS "","" SWS ; comma SEMI = SWS "";"" SWS ; semicolon COLON = SWS "":"" SWS ; colon LDQUOT = SWS DQUOTE; open double quotation mark RDQUOT = DQUOTE SWS ; close double quotation mark Rosenberg, et. al. Standards Track [Page 221] RFC 3261 SIP: Session Initiation Protocol June 2002 Comments can be included in some SIP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing ""comment"" as part of their field value definition. In all other fields, parentheses are considered part of the field value. comment = LPAREN *(ctext / quoted-pair / comment) RPAREN ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII / LWS ctext includes all chars except left and right parens and backslash. A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings, quotation marks ("") and backslashes (\) need to be escaped. quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII The backslash character (""\"") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation. quoted-pair = ""\"" (%x00-09 / %x0B-0C / %x0E-7F) SIP-URI = ""sip:"" [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = ""sips:"" [ userinfo ] hostport uri-parameters [ headers ] userinfo = ( user / telephone-subscriber ) [ "":"" password ] ""@"" user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = ""&"" / ""="" / ""+"" / ""$"" / "","" / "";"" / ""?"" / ""/"" password = *( unreserved / escaped / ""&"" / ""="" / ""+"" / ""$"" / "","" ) hostport = host [ "":"" port ] host = hostname / IPv4address / IPv6reference hostname = *( domainlabel ""."" ) toplabel [ ""."" ] domainlabel = alphanum / alphanum *( alphanum / ""-"" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / ""-"" ) alphanum Rosenberg, et. al. Standards Track [Page 222] RFC 3261 SIP: Session Initiation Protocol June 2002 IPv4address = 1*3DIGIT ""."" 1*3DIGIT ""."" 1*3DIGIT ""."" 1*3DIGIT IPv6reference = ""["" IPv6address ""]"" IPv6address = hexpart [ "":"" IPv4address ] hexpart = hexseq / hexseq ""::"" [ hexseq ] / ""::"" [ hexseq ] hexseq = hex4 *( "":"" hex4) hex4 = 1*4HEXDIG port = 1*DIGIT The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, however, that any characters allowed there that are not allowed in the user part of the SIP URI MUST be escaped. uri-parameters = *( "";"" uri-parameter) uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param transport-param = ""transport="" ( ""udp"" / ""tcp"" / ""sctp"" / ""tls"" / other-transport) other-transport = token user-param = ""user="" ( ""phone"" / ""ip"" / other-user) other-user = token method-param = ""method="" Method ttl-param = ""ttl="" ttl maddr-param = ""maddr="" host lr-param = ""lr"" other-param = pname [ ""="" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = ""["" / ""]"" / ""/"" / "":"" / ""&"" / ""+"" / ""$"" headers = ""?"" header *( ""&"" header ) header = hname ""="" hvalue hname = 1*( hnv-unreserved / unreserved / escaped ) hvalue = *( hnv-unreserved / unreserved / escaped ) hnv-unreserved = ""["" / ""]"" / ""/"" / ""?"" / "":"" / ""+"" / ""$"" SIP-message = Request / Response Request = Request-Line *( message-header ) CRLF [ message-body ] Request-Line = Method SP Request-URI SP SIP-Version CRLF Request-URI = SIP-URI / SIPS-URI / absoluteURI absoluteURI = scheme "":"" ( hier-part / opaque-part ) hier-part = ( net-path / abs-path ) [ ""?"" query ] net-path = ""//"" authority [ abs-path ] abs-path = ""/"" path-segments Rosenberg, et. al."
"Standards Track [Page 223] RFC 3261 SIP: Session Initiation Protocol June 2002 opaque-part = uric-no-slash *uric uric = reserved / unreserved / escaped uric-no-slash = unreserved / escaped / "";"" / ""?"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" path-segments = segment *( ""/"" segment ) segment = *pchar *( "";"" param ) param = *pchar pchar = unreserved / escaped / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" scheme = ALPHA *( ALPHA / DIGIT / ""+"" / ""-"" / ""."" ) authority = srvr / reg-name srvr = [ [ userinfo ""@"" ] hostport ] reg-name = 1*( unreserved / escaped / ""$"" / "","" / "";"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" ) query = *uric SIP-Version = ""SIP"" ""/"" 1*DIGIT ""."" 1*DIGIT message-header = (Accept / Accept-Encoding / Accept-Language / Alert-Info / Allow / Authentication-Info / Authorization / Call-ID / Call-Info / Contact / Content-Disposition / Content-Encoding / Content-Language / Content-Length / Content-Type / CSeq / Date / Error-Info / Expires / From / In-Reply-To / Max-Forwards / MIME-Version / Min-Expires / Organization / Priority / Proxy-Authenticate / Proxy-Authorization / Proxy-Require / Record-Route / Reply-To Rosenberg, et. al. Standards Track [Page 224] RFC 3261 SIP: Session Initiation Protocol June 2002 / Require / Retry-After / Route / Server / Subject / Supported / Timestamp / To / Unsupported / User-Agent / Via / Warning / WWW-Authenticate / extension-header) CRLF INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps ACKm = %x41.43.4B ; ACK in caps OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps BYEm = %x42.59.45 ; BYE in caps CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / extension-method extension-method = token Response = Status-Line *( message-header ) CRLF [ message-body ] Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF Status-Code = Informational / Redirection / Success / Client-Error / Server-Error / Global-Failure / extension-code extension-code = 3DIGIT Reason-Phrase = *(reserved / unreserved / escaped / UTF8-NONASCII / UTF8-CONT / SP / HTAB) Informational = ""100"" ; Trying / ""180"" ; Ringing / ""181"" ; Call Is Being Forwarded / ""182"" ; Queued / ""183"" ; Session Progress Rosenberg, et. al. Standards Track [Page 225] RFC 3261 SIP: Session Initiation Protocol June 2002 Success = ""200"" ; OK Redirection = ""300"" ; Multiple Choices / ""301"" ; Moved Permanently / ""302"" ; Moved Temporarily / ""305"" ; Use Proxy / ""380"" ; Alternative Service Client-Error = ""400"" ; Bad Request / ""401"" ; Unauthorized / ""402"" ; Payment Required / ""403"" ; Forbidden / ""404"" ; Not Found / ""405"" ; Method Not Allowed / ""406"" ; Not Acceptable / ""407"" ; Proxy Authentication Required / ""408"" ; Request Timeout / ""410"" ; Gone / ""413"" ; Request Entity Too Large / ""414"" ; Request-URI Too Large / ""415"" ; Unsupported Media Type / ""416"" ; Unsupported URI Scheme / ""420"" ; Bad Extension / ""421"" ; Extension Required / ""423"" ; Interval Too Brief / ""480"" ; Temporarily not available / ""481"" ; Call Leg/Transaction Does Not Exist / ""482"" ; Loop Detected / ""483"" ; Too Many Hops / ""484"" ; Address Incomplete / ""485"" ; Ambiguous / ""486"" ; Busy Here / ""487"" ; Request Terminated / ""488"" ; Not Acceptable Here / ""491"" ; Request Pending / ""493"" ; Undecipherable Server-Error = ""500"" ; Internal Server Error / ""501"" ; Not Implemented / ""502"" ; Bad Gateway / ""503"" ; Service Unavailable / ""504"" ; Server Time-out / ""505"" ; SIP Version not supported / ""513"" ; Message Too Large Rosenberg, et. al. Standards Track [Page 226] RFC 3261 SIP: Session Initiation Protocol June 2002 Global-Failure = ""600"" ; Busy Everywhere / ""603"" ; Decline / ""604"" ; Does not exist anywhere / ""606"" ; Not Acceptable Accept = ""Accept"" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range = ( ""*/*"" / ( m-type SLASH ""*"" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-param = (""q"" EQUAL qvalue) / generic-param qvalue = ( ""0"" [ ""."" 0*3DIGIT ] ) / ( ""1"" [ ""."" 0*3(""0"") ] ) generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string Accept-Encoding = ""Accept-Encoding"" HCOLON [ encoding *(COMMA encoding) ] encoding = codings *(SEMI accept-param) codings = content-coding / ""*"" content-coding = token Accept-Language = ""Accept-Language"" HCOLON [ language *(COMMA language) ] language = language-range *(SEMI accept-param) language-range = ( ( 1*8ALPHA *( ""-"" 1*8ALPHA ) ) / ""*"" ) Alert-Info = ""Alert-Info"" HCOLON alert-param *(COMMA alert-param) alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Allow = ""Allow"" HCOLON [Method *(COMMA Method)] Authorization = ""Authorization"" HCOLON credentials credentials = (""Digest"" LWS digest-response) / other-response digest-response = dig-resp *(COMMA dig-resp) dig-resp = username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username = ""username"" EQUAL username-value username-value = quoted-string digest-uri = ""uri"" EQUAL LDQUOT digest-uri-value RDQUOT digest-uri-value = rquest-uri ; Equal to request-uri as specified by HTTP/1.1 message-qop = ""qop"" EQUAL qop-value Rosenberg, et. al. Standards Track [Page 227] RFC 3261 SIP: Session Initiation Protocol June 2002 cnonce = ""cnonce"" EQUAL cnonce-value cnonce-value = nonce-value nonce-count = ""nc"" EQUAL nc-value nc-value = 8LHEX dresponse = ""response"" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT auth-param = auth-param-name EQUAL ( token / quoted-string ) auth-param-name = token other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token Authentication-Info = ""Authentication-Info"" HCOLON ainfo *(COMMA ainfo) ainfo = nextnonce / message-qop / response-auth / cnonce / nonce-count nextnonce = ""nextnonce"" EQUAL nonce-value response-auth = ""rspauth"" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT Call-ID = ( ""Call-ID"" / ""i"" ) HCOLON callid callid = word [ ""@"" word ] Call-Info = ""Call-Info"" HCOLON info *(COMMA info) info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) info-param = ( ""purpose"" EQUAL ( ""icon"" / ""info"" / ""card"" / token ) ) / generic-param Contact = (""Contact"" / ""m"" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *(SEMI contact-params) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI display-name = *(token LWS)/ quoted-string contact-params = c-p-q / c-p-expires / contact-extension c-p-q = ""q"" EQUAL qvalue c-p-expires = ""expires"" EQUAL delta-seconds contact-extension = generic-param delta-seconds = 1*DIGIT Content-Disposition = ""Content-Disposition"" HCOLON disp-type *( SEMI disp-param ) disp-type = ""render"" / ""session"" / ""icon"" / ""alert"" / disp-extension-token Rosenberg, et. al. Standards Track [Page 228] RFC 3261 SIP: Session Initiation Protocol June 2002 disp-param = handling-param / generic-param handling-param = ""handling"" EQUAL ( ""optional"" / ""required"" / other-handling ) other-handling = token disp-extension-token = token Content-Encoding = ( ""Content-Encoding"" / ""e"" ) HCOLON content-coding *(COMMA content-coding) Content-Language = ""Content-Language"" HCOLON language-tag *(COMMA language-tag) language-tag = primary-tag *( ""-"" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA Content-Length = ( ""Content-Length"" / ""l"" ) HCOLON 1*DIGIT Content-Type = ( ""Content-Type"" / ""c"" ) HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter) m-type = discrete-type / composite-type discrete-type = ""text"" / ""image"" / ""audio"" / ""video"" / ""application"" / extension-token composite-type = ""message"" / ""multipart"" / extension-token extension-token = ietf-token / x-token ietf-token = token x-token = ""x-"" token m-subtype = extension-token / iana-token iana-token = token m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string CSeq = ""CSeq"" HCOLON 1*DIGIT LWS Method Date = ""Date"" HCOLON SIP-date SIP-date = rfc1123-date rfc1123-date = wkday "","" SP date1 SP time SP ""GMT"" date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) time = 2DIGIT "":"" 2DIGIT "":"" 2DIGIT ; 00:00:00 - 23:59:59 wkday = ""Mon"" / ""Tue"" / ""Wed"" / ""Thu"" / ""Fri"" / ""Sat"" / ""Sun"" month = ""Jan"" / ""Feb"" / ""Mar"" / ""Apr"" / ""May"" / ""Jun"" / ""Jul"" / ""Aug"" / ""Sep"" / ""Oct"" / ""Nov"" / ""Dec"" Error-Info = ""Error-Info"" HCOLON error-uri *(COMMA error-uri) Rosenberg, et. al. Standards Track [Page 229] RFC 3261 SIP: Session Initiation Protocol June 2002 error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Expires = ""Expires"" HCOLON delta-seconds From = ( ""From"" / ""f"" ) HCOLON from-spec from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-param = tag-param / generic-param tag-param = ""tag"" EQUAL token In-Reply-To = ""In-Reply-To"" HCOLON callid *(COMMA callid) Max-Forwards = ""Max-Forwards"" HCOLON 1*DIGIT MIME-Version = ""MIME-Version"" HCOLON 1*DIGIT ""."" 1*DIGIT Min-Expires = ""Min-Expires"" HCOLON delta-seconds Organization = ""Organization"" HCOLON [TEXT-UTF8-TRIM] Priority = ""Priority"" HCOLON priority-value priority-value = ""emergency"" / ""urgent"" / ""normal"" / ""non-urgent"" / other-priority other-priority = token Proxy-Authenticate = ""Proxy-Authenticate"" HCOLON challenge challenge = (""Digest"" LWS digest-cln *(COMMA digest-cln)) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = ""realm"" EQUAL realm-value realm-value = quoted-string domain = ""domain"" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT URI = absoluteURI / abs-path nonce = ""nonce"" EQUAL nonce-value nonce-value = quoted-string opaque = ""opaque"" EQUAL quoted-string stale = ""stale"" EQUAL ( ""true"" / ""false"" ) algorithm = ""algorithm"" EQUAL ( ""MD5"" / ""MD5-sess"" / token ) qop-options = ""qop"" EQUAL LDQUOT qop-value *("","" qop-value) RDQUOT qop-value = ""auth"" / ""auth-int"" / token Proxy-Authorization = ""Proxy-Authorization"" HCOLON credentials Rosenberg, et. al. Standards Track [Page 230] RFC 3261 SIP: Session Initiation Protocol June 2002 Proxy-Require = ""Proxy-Require"" HCOLON option-tag *(COMMA option-tag) option-tag = token Record-Route = ""Record-Route"" HCOLON rec-route *(COMMA rec-route) rec-route = name-addr *( SEMI rr-param ) rr-param = generic-param Reply-To = ""Reply-To"" HCOLON rplyto-spec rplyto-spec = ( name-addr / addr-spec ) *( SEMI rplyto-param ) rplyto-param = generic-param Require = ""Require"" HCOLON option-tag *(COMMA option-tag) Retry-After = ""Retry-After"" HCOLON delta-seconds [ comment ] *( SEMI retry-param ) retry-param = (""duration"" EQUAL delta-seconds) / generic-param Route = ""Route"" HCOLON route-param *(COMMA route-param) route-param = name-addr *( SEMI rr-param ) Server = ""Server"" HCOLON server-val *(LWS server-val) server-val = product / comment product = token [SLASH product-version] product-version = token Subject = ( ""Subject"" / ""s"" ) HCOLON [TEXT-UTF8-TRIM] Supported = ( ""Supported"" / ""k"" ) HCOLON [option-tag *(COMMA option-tag)] Timestamp = ""Timestamp"" HCOLON 1*(DIGIT) [ ""."" *(DIGIT) ] [ LWS delay ] delay = *(DIGIT) [ ""."" *(DIGIT) ] To = ( ""To"" / ""t"" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param ) to-param = tag-param / generic-param Unsupported = ""Unsupported"" HCOLON option-tag *(COMMA option-tag) User-Agent = ""User-Agent"" HCOLON server-val *(LWS server-val) Rosenberg, et. al. Standards Track [Page 231] RFC 3261 SIP: Session Initiation Protocol June 2002 Via = ( ""Via"" / ""v"" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-ttl = ""ttl"" EQUAL ttl via-maddr = ""maddr"" EQUAL host via-received = ""received"" EQUAL (IPv4address / IPv6address) via-branch = ""branch"" EQUAL token via-extension = generic-param sent-protocol = protocol-name SLASH protocol-version SLASH transport protocol-name = ""SIP"" / token protocol-version = token transport = ""UDP"" / ""TCP"" / ""TLS"" / ""SCTP"" / other-transport sent-by = host [ COLON port ] ttl = 1*3DIGIT ; 0 to 255 Warning = ""Warning"" HCOLON warning-value *(COMMA warning-value) warning-value = warn-code SP warn-agent SP warn-text warn-code = 3DIGIT warn-agent = hostport / pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string pseudonym = token WWW-Authenticate = ""WWW-Authenticate"" HCOLON challenge extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) message-body = *OCTET 26 Security Considerations: Threat Model and Security Usage Recommendations SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial. Security solutions are needed that are deployable today, without extensive coordination, in a wide variety of environments and usages. In order to meet these diverse needs, several distinct mechanisms applicable to different aspects and usages of SIP will be required. Rosenberg, et. al. Standards Track [Page 232] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that the security of SIP signaling itself has no bearing on the security of protocols used in concert with SIP such as RTP, or with the security implications of any specific bodies SIP might carry (although MIME security plays a substantial role in securing SIP). Any media associated with a session can be encrypted end-to-end independently of any associated SIP signaling. Media encryption is outside the scope of this document. The considerations that follow first examine a set of classic threat models that broadly identify the security needs of SIP. The set of security services required to address these threats is then detailed, followed by an explanation of several security mechanisms that can be used to provide these services. Next, the requirements for implementers of SIP are enumerated, along with exemplary deployments in which these security mechanisms could be used to improve the security of SIP. Some notes on privacy conclude this section. 26.1 Attacks and Threat Models This section details some threats that should be common to most deployments of SIP. These threats have been chosen specifically to illustrate each of the security services that SIP requires. The following examples by no means provide an exhaustive list of the threats against SIP; rather, these are ""classic"" threats that demonstrate the need for particular security services that can potentially prevent whole categories of threats. These attacks assume an environment in which attackers can potentially read any packet on the network - it is anticipated that SIP will frequently be used on the public Internet. Attackers on the network may be able to modify packets (perhaps at some compromised intermediary). Attackers may wish to steal services, eavesdrop on communications, or disrupt sessions. 26.1.1 Registration Hijacking The SIP registration mechanism allows a user agent to identify itself to a registrar as a device at which a user (designated by an address of record) is located. A registrar assesses the identity asserted in the From header field of a REGISTER message to determine whether this request can modify the contact addresses associated with the address-of-record in the To header field. While these two fields are frequently the same, there are many valid deployments in which a third-party may register contacts on a user's behalf. Rosenberg, et. al. Standards Track [Page 233] RFC 3261 SIP: Session Initiation Protocol June 2002 The From header field of a SIP request, however, can be modified arbitrarily by the owner of a UA, and this opens the door to malicious registrations. An attacker that successfully impersonates a party authorized to change contacts associated with an address-of- record could, for example, de-register all existing contacts for a URI and then register their own device as the appropriate contact address, thereby directing all requests for the affected user to the attacker's device. This threat belongs to a family of threats that rely on the absence of cryptographic assurance of a request's originator. Any SIP UAS that represents a valuable service (a gateway that interworks SIP requests with traditional telephone calls, for example) might want to control access to its resources by authenticating requests that it receives. Even end-user UAs, for example SIP phones, have an interest in ascertaining the identities of originators of requests. This threat demonstrates the need for security services that enable SIP entities to authenticate the originators of requests. 26.1.2 Impersonating a Server The domain to which a request is destined is generally specified in the Request-URI. UAs commonly contact a server in this domain directly in order to deliver a request. However, there is always a possibility that an attacker could impersonate the remote server, and that the UA's request could be intercepted by some other party. For example, consider a case in which a redirect server at one domain, chicago.com, impersonates a redirect server at another domain, biloxi.com. A user agent sends a request to biloxi.com, but the redirect server at chicago.com answers with a forged response that has appropriate SIP header fields for a response from biloxi.com. The forged contact addresses in the redirection response could direct the originating UA to inappropriate or insecure resources, or simply prevent requests for biloxi.com from succeeding. This family of threats has a vast membership, many of which are critical. As a converse to the registration hijacking threat, consider the case in which a registration sent to biloxi.com is intercepted by chicago.com, which replies to the intercepted registration with a forged 301 (Moved Permanently) response. This response might seem to come from biloxi.com yet designate chicago.com as the appropriate registrar. All future REGISTER requests from the originating UA would then go to chicago.com. Prevention of this threat requires a means by which UAs can authenticate the servers to whom they send requests. Rosenberg, et. al. Standards Track [Page 234] RFC 3261 SIP: Session Initiation Protocol June 2002 26.1.3 Tampering with Message Bodies As a matter of course, SIP UAs route requests through trusted proxy servers. Regardless of how that trust is established (authentication of proxies is discussed elsewhere in this section), a UA may trust a proxy server to route a request, but not to inspect or possibly modify the bodies contained in that request. Consider a UA that is using SIP message bodies to communicate session encryption keys for a media session. Although it trusts the proxy server of the domain it is contacting to deliver signaling properly, it may not want the administrators of that domain to be capable of decrypting any subsequent media session. Worse yet, if the proxy server were actively malicious, it could modify the session key, either acting as a man-in-the-middle, or perhaps changing the security characteristics requested by the originating UA. This family of threats applies not only to session keys, but to most conceivable forms of content carried end-to-end in SIP. These might include MIME bodies that should be rendered to the user, SDP, or encapsulated telephony signals, among others. Attackers might attempt to modify SDP bodies, for example, in order to point RTP media streams to a wiretapping device in order to eavesdrop on subsequent voice communications. Also note that some header fields in SIP are meaningful end-to-end, for example, Subject. UAs might be protective of these header fields as well as bodies (a malicious intermediary changing the Subject header field might make an important request appear to be spam, for example). However, since many header fields are legitimately inspected or altered by proxy servers as a request is routed, not all header fields should be secured end-to-end. For these reasons, the UA might want to secure SIP message bodies, and in some limited cases header fields, end-to-end. The security services required for bodies include confidentiality, integrity, and authentication. These end-to-end services should be independent of the means used to secure interactions with intermediaries such as proxy servers. 26.1.4 Tearing Down Sessions Once a dialog has been established by initial messaging, subsequent requests can be sent that modify the state of the dialog and/or session. It is critical that principals in a session can be certain that such requests are not forged by attackers. Rosenberg, et. al. Standards Track [Page 235] RFC 3261 SIP: Session Initiation Protocol June 2002 Consider a case in which a third-party attacker captures some initial messages in a dialog shared by two parties in order to learn the parameters of the session (To tag, From tag, and so forth) and then inserts a BYE request into the session. The attacker could opt to forge the request such that it seemed to come from either participant. Once the BYE is received by its target, the session will be torn down prematurely. Similar mid-session threats include the transmission of forged re- INVITEs that alter the session (possibly to reduce session security or redirect media streams as part of a wiretapping attack). The most effective countermeasure to this threat is the authentication of the sender of the BYE. In this instance, the recipient needs only know that the BYE came from the same party with whom the corresponding dialog was established (as opposed to ascertaining the absolute identity of the sender). Also, if the attacker is unable to learn the parameters of the session due to confidentiality, it would not be possible to forge the BYE. However, some intermediaries (like proxy servers) will need to inspect those parameters as the session is established. 26.1.5 Denial of Service and Amplification Denial-of-service attacks focus on rendering a particular network element unavailable, usually by directing an excessive amount of network traffic at its interfaces. A distributed denial-of-service attack allows one network user to cause multiple network hosts to flood a target host with a large amount of network traffic. In many architectures, SIP proxy servers face the public Internet in order to accept requests from worldwide IP endpoints. SIP creates a number of potential opportunities for distributed denial-of-service attacks that must be recognized and addressed by the implementers and operators of SIP systems. Attackers can create bogus requests that contain a falsified source IP address and a corresponding Via header field that identify a targeted host as the originator of the request and then send this request to a large number of SIP network elements, thereby using hapless SIP UAs or proxies to generate denial-of-service traffic aimed at the target. Similarly, attackers might use falsified Route header field values in a request that identify the target host and then send such messages to forking proxies that will amplify messaging sent to the target. Rosenberg, et. al. Standards Track [Page 236] RFC 3261 SIP: Session Initiation Protocol June 2002 Record-Route could be used to similar effect when the attacker is certain that the SIP dialog initiated by the request will result in numerous transactions originating in the backwards direction. A number of denial-of-service attacks open up if REGISTER requests are not properly authenticated and authorized by registrars. Attackers could de-register some or all users in an administrative domain, thereby preventing these users from being invited to new sessions. An attacker could also register a large number of contacts designating the same host for a given address-of-record in order to use the registrar and any associated proxy servers as amplifiers in a denial-of-service attack. Attackers might also attempt to deplete available memory and disk resources of a registrar by registering huge numbers of bindings. The use of multicast to transmit SIP requests can greatly increase the potential for denial-of-service attacks. These problems demonstrate a general need to define architectures that minimize the risks of denial-of-service, and the need to be mindful in recommendations for security mechanisms of this class of attacks. 26.2 Security Mechanisms From the threats described above, we gather that the fundamental security services required for the SIP protocol are: preserving the confidentiality and integrity of messaging, preventing replay attacks or message spoofing, providing for the authentication and privacy of the participants in a session, and preventing denial-of-service attacks. Bodies within SIP messages separately require the security services of confidentiality, integrity, and authentication. Rather than defining new security mechanisms specific to SIP, SIP reuses wherever possible existing security models derived from the HTTP and SMTP space. Full encryption of messages provides the best means to preserve the confidentiality of signaling - it can also guarantee that messages are not modified by any malicious intermediaries. However, SIP requests and responses cannot be naively encrypted end-to-end in their entirety because message fields such as the Request-URI, Route, and Via need to be visible to proxies in most network architectures so that SIP requests are routed correctly. Note that proxy servers need to modify some features of messages as well (such as adding Via header field values) in order for SIP to function. Proxy servers must therefore be trusted, to some degree, by SIP UAs. To this purpose, low-layer security mechanisms for SIP are recommended, which Rosenberg, et. al. Standards Track [Page 237] RFC 3261 SIP: Session Initiation Protocol June 2002 encrypt the entire SIP requests or responses on the wire on a hop- by-hop basis, and that allow endpoints to verify the identity of proxy servers to whom they send requests. SIP entities also have a need to identify one another in a secure fashion. When a SIP endpoint asserts the identity of its user to a peer UA or to a proxy server, that identity should in some way be verifiable. A cryptographic authentication mechanism is provided in SIP to address this requirement. An independent security mechanism for SIP message bodies supplies an alternative means of end-to-end mutual authentication, as well as providing a limit on the degree to which user agents must trust intermediaries. 26.2.1 Transport and Network Layer Security Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and integrity. Oftentimes, certificates are used in the establishment of lower-layer security, and these certificates can also be used to provide a means of authentication in many architectures. Two popular alternatives for providing security at the transport and network layer are, respectively, TLS [25] and IPSec [26]. IPSec is a set of network-layer protocol tools that collectively can be used as a secure replacement for traditional IP (Internet Protocol). IPSec is most commonly used in architectures in which a set of hosts or administrative domains have an existing trust relationship with one another. IPSec is usually implemented at the operating system level in a host, or on a security gateway that provides confidentiality and integrity for all traffic it receives from a particular interface (as in a VPN architecture). IPSec can also be used on a hop-by-hop basis. In many architectures IPSec does not require integration with SIP applications; IPSec is perhaps best suited to deployments in which adding security directly to SIP hosts would be arduous. UAs that have a pre-shared keying relationship with their first-hop proxy server are also good candidates to use IPSec. Any deployment of IPSec for SIP would require an IPSec profile describing the protocol tools that would be required to secure SIP. No such profile is given in this document. Rosenberg, et. al. Standards Track [Page 238] RFC 3261 SIP: Session Initiation Protocol June 2002 TLS provides transport-layer security over connection-oriented protocols (for the purposes of this document, TCP); ""tls"" (signifying TLS over TCP) can be specified as the desired transport protocol within a Via header field value or a SIP-URI. TLS is most suited to architectures in which hop-by-hop security is required between hosts with no pre-existing trust association. For example, Alice trusts her local proxy server, which after a certificate exchange decides to trust Bob's local proxy server, which Bob trusts, hence Bob and Alice can communicate securely. TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on a hop-by-hop basis in SIP, thus a UA that sends requests over TLS to a proxy server has no assurance that TLS will be used end-to-end. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at a minimum by implementers when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, redirect servers, and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other ciphersuite. 26.2.2 SIPS URI Scheme The SIPS URI scheme adheres to the syntax of the SIP URI (described in 19), although the scheme string is ""sips"" rather than ""sip"". The semantics of SIPS are very different from the SIP URI, however. SIPS allows resources to specify that they should be reached securely. A SIPS URI can be used as an address-of-record for a particular user - the URI by which the user is canonically known (on their business cards, in the From header field of their requests, in the To header field of REGISTER requests). When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured. The SIPS scheme is applicable to many of the other ways in which SIP URIs are used in SIP today in addition to the Request-URI, including in addresses-of-record, contact addresses (the contents of Contact headers, including those of REGISTER methods), and Route headers. In each instance, the SIPS URI scheme allows these existing fields to Rosenberg, et. al. Standards Track [Page 239] RFC 3261 SIP: Session Initiation Protocol June 2002 designate secure resources. The manner in which a SIPS URI is dereferenced in any of these contexts has its own security properties which are detailed in [4]. The use of SIPS in particular entails that mutual TLS authentication SHOULD be employed, as SHOULD the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the authentication process SHOULD be validated with root certificates held by the client; failure to validate a certificate SHOULD result in the failure of the request. Note that in the SIPS URI scheme, transport is independent of TLS, and thus ""sips:alice@atlanta.com;transport=tcp"" and ""sips:alice@atlanta.com;transport=sctp"" are both valid (although note that UDP is not a valid transport for SIPS). The use of ""transport=tls"" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports. 26.2.3 HTTP Authentication SIP provides a challenge capability, based on HTTP authentication, that relies on the 401 and 407 response codes as well as header fields for carrying challenges and credentials. Without significant modification, the reuse of the HTTP Digest authentication scheme in SIP allows for replay protection and one-way authentication. The usage of Digest authentication in SIP is detailed in Section 22. 26.2.4 S/MIME As is discussed above, encrypting entire SIP messages end-to-end for the purpose of confidentiality is not appropriate because network intermediaries (like proxy servers) need to view certain header fields in order to route messages correctly, and if these intermediaries are excluded from security associations, then SIP messages will essentially be non-routable. However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, securing these bodies end-to-end without affecting message headers. S/MIME can provide end-to-end confidentiality and integrity for message bodies, as well as mutual authentication. It is also possible to use S/MIME to provide a form of integrity and confidentiality for SIP header fields through SIP message tunneling. Rosenberg, et. al. Standards Track [Page 240] RFC 3261 SIP: Session Initiation Protocol June 2002 The usage of S/MIME in SIP is detailed in Section 23. 26.3 Implementing Security Mechanisms 26.3.1 Requirements for Implementers of SIP Proxy servers, redirect servers, and registrars MUST implement TLS, and MUST support both mutual and one-way authentication. It is strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also be capable of acting as a TLS server. Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname. UAs MAY have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. All SIP elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers). All SIP elements that support TLS MUST also support the SIPS URI scheme. Proxy servers, redirect servers, registrars, and UAs MAY also implement IPSec or other lower-layer security protocols. When a UA attempts to contact a proxy server, redirect server, or registrar, the UAC SHOULD initiate a TLS connection over which it will send SIP messages. In some architectures, UASs MAY receive requests over such TLS connections as well. Proxy servers, redirect servers, registrars, and UAs MUST implement Digest Authorization, encompassing all of the aspects required in 22. Proxy servers, redirect servers, and registrars SHOULD be configured with at least one Digest realm, and at least one ""realm"" string supported by a given server SHOULD correspond to the server's hostname or domainname. UAs MAY support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23. If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it SHOULD be capable of reusing these to verify S/MIME certificates, as appropriate. A UA MAY hold root certificates specifically for validating S/MIME certificates. Rosenberg, et. al. Standards Track [Page 241] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that is it anticipated that future security extensions may upgrade the normative strength associated with S/MIME as S/MIME implementations appear and the problem space becomes better understood. 26.3.2 Security Solutions The operation of these security mechanisms in concert can follow the existing web and email security models to some degree. At a high level, UAs authenticate themselves to servers (proxy servers, redirect servers, and registrars) with a Digest username and password; servers authenticate themselves to UAs one hop away, or to another server one hop away (and vice versa), with a site certificate delivered by TLS. On a peer-to-peer level, UAs trust the network to authenticate one another ordinarily; however, S/MIME can also be used to provide direct authentication when the network does not, or if the network itself is not trusted. The following is an illustrative example in which these security mechanisms are used by various UAs and servers to prevent the sorts of threats described in Section 26.1. While implementers and network administrators MAY follow the normative guidelines given in the remainder of this section, these are provided only as example implementations. 26.3.2.1 Registration When a UA comes online and registers with its local administrative domain, it SHOULD establish a TLS connection with its registrar (Section 10 describes how the UA reaches its registrar). The registrar SHOULD offer a certificate to the UA, and the site identified by the certificate MUST correspond with the domain in which the UA intends to register; for example, if the UA intends to register the address-of-record 'alice@atlanta.com', the site certificate must identify a host within the atlanta.com domain (such as sip.atlanta.com). When it receives the TLS Certificate message, the UA SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid, revoked, or if it does not identify the appropriate party, the UA MUST NOT send the REGISTER message and otherwise proceed with the registration. When a valid certificate has been provided by the registrar, the UA knows that the registrar is not an attacker who might redirect the UA, steal passwords, or attempt any similar attacks. Rosenberg, et. al. Standards Track [Page 242] RFC 3261 SIP: Session Initiation Protocol June 2002 The UA then creates a REGISTER request that SHOULD be addressed to a Request-URI corresponding to the site certificate received from the registrar. When the UA sends the REGISTER request over the existing TLS connection, the registrar SHOULD challenge the request with a 401 (Proxy Authentication Required) response. The ""realm"" parameter within the Proxy-Authenticate header field of the response SHOULD correspond to the domain previously given by the site certificate. When the UAC receives the challenge, it SHOULD either prompt the user for credentials or take an appropriate credential from a keyring corresponding to the ""realm"" parameter in the challenge. The username of this credential SHOULD correspond with the ""userinfo"" portion of the URI in the To header field of the REGISTER request. Once the Digest credentials have been inserted into an appropriate Proxy-Authorization header field, the REGISTER should be resubmitted to the registrar. Since the registrar requires the user agent to authenticate itself, it would be difficult for an attacker to forge REGISTER requests for the user's address-of-record. Also note that since the REGISTER is sent over a confidential TLS connection, attackers will not be able to intercept the REGISTER to record credentials for any possible replay attack. Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that has just completed registration."
"Because the UA has already authenticated the server on the other side of the TLS connection, all requests that come over this connection are known to have passed through the proxy server - attackers cannot create spoofed requests that appear to have been sent through that proxy server. 26.3.2.2 Interdomain Requests Now let's say that Alice's UA would like to initiate a session with a user in a remote administrative domain, namely ""bob@biloxi.com"". We will also say that the local administrative domain (atlanta.com) has a local outbound proxy. The proxy server that handles inbound requests for an administrative domain MAY also act as a local outbound proxy; for simplicity's sake we'll assume this to be the case for atlanta.com (otherwise the user agent would initiate a new TLS connection to a separate server at this point). Assuming that the client has completed the registration Rosenberg, et. al. Standards Track [Page 243] RFC 3261 SIP: Session Initiation Protocol June 2002 process described in the preceding section, it SHOULD reuse the TLS connection to the local proxy server when it sends an INVITE request to another user. The UA SHOULD reuse cached credentials in the INVITE to avoid prompting the user unnecessarily. When the local outbound proxy server has validated the credentials presented by the UA in the INVITE, it SHOULD inspect the Request-URI to determine how the message should be routed (see [4]). If the ""domainname"" portion of the Request-URI had corresponded to the local domain (atlanta.com) rather than biloxi.com, then the proxy server would have consulted its location service to determine how best to reach the requested user. Had ""alice@atlanta.com"" been attempting to contact, say, ""alex@atlanta.com"", the local proxy would have proxied to the request to the TLS connection Alex had established with the registrar when he registered. Since Alex would receive this request over his authenticated channel, he would be assured that Alice's request had been authorized by the proxy server of the local administrative domain. However, in this instance the Request-URI designates a remote domain. The local outbound proxy server at atlanta.com SHOULD therefore establish a TLS connection with the remote proxy server at biloxi.com. Since both of the participants in this TLS connection are servers that possess site certificates, mutual TLS authentication SHOULD occur. Each side of the connection SHOULD verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages. The atlanta.com proxy server, for example, SHOULD verify at this stage that the certificate received from the remote side corresponds with the biloxi.com domain. Once it has done so, and TLS negotiation has completed, resulting in a secure channel between the two proxies, the atlanta.com proxy can forward the INVITE request to biloxi.com. The proxy server at biloxi.com SHOULD inspect the certificate of the proxy server at atlanta.com in turn and compare the domain asserted by the certificate with the ""domainname"" portion of the From header field in the INVITE request. The biloxi proxy MAY have a strict security policy that requires it to reject requests that do not match the administrative domain from which they have been proxied. Such security policies could be instituted to prevent the SIP equivalent of SMTP 'open relays' that are frequently exploited to generate spam. Rosenberg, et. al. Standards Track [Page 244] RFC 3261 SIP: Session Initiation Protocol June 2002 This policy, however, only guarantees that the request came from the domain it ascribes to itself; it does not allow biloxi.com to ascertain how atlanta.com authenticated Alice. Only if biloxi.com has some other way of knowing atlanta.com's authentication policies could it possibly ascertain how Alice proved her identity. biloxi.com might then institute an even stricter policy that forbids requests that come from domains that are not known administratively to share a common authentication policy with biloxi.com. Once the INVITE has been approved by the biloxi proxy, the proxy server SHOULD identify the existing TLS channel, if any, associated with the user targeted by this request (in this case ""bob@biloxi.com""). The INVITE should be proxied through this channel to Bob. Since the request is received over a TLS connection that had previously been authenticated as the biloxi proxy, Bob knows that the From header field was not tampered with and that atlanta.com has validated Alice, although not necessarily whether or not to trust Alice's identity. Before they forward the request, both proxy servers SHOULD add a Record-Route header field to the request so that all future requests in this dialog will pass through the proxy servers. The proxy servers can thereby continue to provide security services for the lifetime of this dialog. If the proxy servers do not add themselves to the Record-Route, future messages will pass directly end-to-end between Alice and Bob without any security services (unless the two parties agree on some independent end-to-end security such as S/MIME). In this respect the SIP trapezoid model can provide a nice structure where conventions of agreement between the site proxies can provide a reasonably secure channel between Alice and Bob. An attacker preying on this architecture would, for example, be unable to forge a BYE request and insert it into the signaling stream between Bob and Alice because the attacker has no way of ascertaining the parameters of the session and also because the integrity mechanism transitively protects the traffic between Alice and Bob. 26.3.2.3 Peer-to-Peer Requests Alternatively, consider a UA asserting the identity ""carol@chicago.com"" that has no local outbound proxy. When Carol wishes to send an INVITE to ""bob@biloxi.com"", her UA SHOULD initiate a TLS connection with the biloxi proxy directly (using the mechanism described in [4] to determine how to best to reach the given Request-URI). When her UA receives a certificate from the biloxi proxy, it SHOULD be verified normally before she passes her INVITE across the TLS connection. However, Carol has no means of proving Rosenberg, et. al. Standards Track [Page 245] RFC 3261 SIP: Session Initiation Protocol June 2002 her identity to the biloxi proxy, but she does have a CMS-detached signature over a ""message/sip"" body in the INVITE. It is unlikely in this instance that Carol would have any credentials in the biloxi.com realm, since she has no formal association with biloxi.com. The biloxi proxy MAY also have a strict policy that precludes it from even bothering to challenge requests that do not have biloxi.com in the ""domainname"" portion of the From header field - it treats these users as unauthenticated. The biloxi proxy has a policy for Bob that all non-authenticated requests should be redirected to the appropriate contact address registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>. Carol receives the redirection response over the TLS connection she established with the biloxi proxy, so she trusts the veracity of the contact address. Carol SHOULD then establish a TCP connection with the designated address and send a new INVITE with a Request-URI containing the received contact address (recomputing the signature in the body as the request is readied). Bob receives this INVITE on an insecure interface, but his UA inspects and, in this instance, recognizes the From header field of the request and subsequently matches a locally cached certificate with the one presented in the signature of the body of the INVITE. He replies in similar fashion, authenticating himself to Carol, and a secure dialog begins. Sometimes firewalls or NATs in an administrative domain could preclude the establishment of a direct TCP connection to a UA. In these cases, proxy servers could also potentially relay requests to UAs in a way that has no trust implications (for example, forgoing an existing TLS connection and forwarding the request over cleartext TCP) as local policy dictates. 26.3.2.4 DoS Protection In order to minimize the risk of a denial-of-service attack against architectures using these security solutions, implementers should take note of the following guidelines. When the host on which a SIP proxy server is operating is routable from the public Internet, it SHOULD be deployed in an administrative domain with defensive operational policies (blocking source-routed traffic, preferably filtering ping traffic). Both TLS and IPSec can also make use of bastion hosts at the edges of administrative domains that participate in the security associations to aggregate secure tunnels and sockets. These bastion hosts can also take the brunt of denial-of-service attacks, ensuring that SIP hosts within the administrative domain are not encumbered with superfluous messaging. Rosenberg, et. al. Standards Track [Page 246] RFC 3261 SIP: Session Initiation Protocol June 2002 No matter what security solutions are deployed, floods of messages directed at proxy servers can lock up proxy server resources and prevent desirable traffic from reaching its destination. There is a computational expense associated with processing a SIP transaction at a proxy server, and that expense is greater for stateful proxy servers than it is for stateless proxy servers. Therefore, stateful proxies are more susceptible to flooding than stateless proxy servers. UAs and proxy servers SHOULD challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests. Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication Required) status response amplifies the problem of an attacker using a falsified header field value (such as Via) to direct traffic to a third party. In summary, the mutual authentication of proxy servers through mechanisms such as TLS significantly reduces the potential for rogue intermediaries to introduce falsified requests or responses that can deny service. This commensurately makes it harder for attackers to make innocent SIP nodes into agents of amplification. 26.4 Limitations Although these security mechanisms, when applied in a judicious manner, can thwart many threats, there are limitations in the scope of the mechanisms that must be understood by implementers and network operators. 26.4.1 HTTP Digest One of the primary limitations of using HTTP Digest in SIP is that the integrity mechanisms in Digest do not work very well for SIP. Specifically, they offer protection of the Request-URI and the method of a message, but not for any of the header fields that UAs would most likely wish to secure. The existing replay protection mechanisms described in RFC 2617 also have some limitations for SIP. The next-nonce mechanism, for example, does not support pipelined requests. The nonce-count mechanism should be used for replay protection. Another limitation of HTTP Digest is the scope of realms. Digest is valuable when a user wants to authenticate themselves to a resource with which they have a pre-existing association, like a service Rosenberg, et. al. Standards Track [Page 247] RFC 3261 SIP: Session Initiation Protocol June 2002 provider of which the user is a customer (which is quite a common scenario and thus Digest provides an extremely useful function). By way of contrast, the scope of TLS is interdomain or multirealm, since certificates are often globally verifiable, so that the UA can authenticate the server with no pre-existing association. 26.4.2 S/MIME The largest outstanding defect with the S/MIME mechanism is the lack of a prevalent public key infrastructure for end users. If self- signed certificates (or certificates that cannot be verified by one of the participants in a dialog) are used, the SIP-based key exchange mechanism described in Section 23.2 is susceptible to a man-in-the- middle attack with which an attacker can potentially inspect and modify S/MIME bodies. The attacker needs to intercept the first exchange of keys between the two parties in a dialog, remove the existing CMS-detached signatures from the request and response, and insert a different CMS-detached signature containing a certificate supplied by the attacker (but which seems to be a certificate for the proper address-of-record). Each party will think they have exchanged keys with the other, when in fact each has the public key of the attacker. It is important to note that the attacker can only leverage this vulnerability on the first exchange of keys between two parties - on subsequent occasions, the alteration of the key would be noticeable to the UAs. It would also be difficult for the attacker to remain in the path of all future dialogs between the two parties over time (as potentially days, weeks, or years pass). SSH is susceptible to the same man-in-the-middle attack on the first exchange of keys; however, it is widely acknowledged that while SSH is not perfect, it does improve the security of connections. The use of key fingerprints could provide some assistance to SIP, just as it does for SSH. For example, if two parties use SIP to establish a voice communications session, each could read off the fingerprint of the key they received from the other, which could be compared against the original. It would certainly be more difficult for the man-in- the-middle to emulate the voices of the participants than their signaling (a practice that was used with the Clipper chip-based secure telephone). The S/MIME mechanism allows UAs to send encrypted requests without preamble if they possess a certificate for the destination address- of-record on their keyring. However, it is possible that any particular device registered for an address-of-record will not hold the certificate that has been previously employed by the device's current user, and that it will therefore be unable to process an Rosenberg, et. al. Standards Track [Page 248] RFC 3261 SIP: Session Initiation Protocol June 2002 encrypted request properly, which could lead to some avoidable error signaling. This is especially likely when an encrypted request is forked. The keys associated with S/MIME are most useful when associated with a particular user (an address-of-record) rather than a device (a UA). When users move between devices, it may be difficult to transport private keys securely between UAs; how such keys might be acquired by a device is outside the scope of this document. Another, more prosaic difficulty with the S/MIME mechanism is that it can result in very large messages, especially when the SIP tunneling mechanism described in Section 23.4 is used. For that reason, it is RECOMMENDED that TCP should be used as a transport protocol when S/MIME tunneling is employed. 26.4.3 TLS The most commonly voiced concern about TLS is that it cannot run over UDP; TLS requires a connection-oriented underlying transport protocol, which for the purposes of this document means TCP. It may also be arduous for a local outbound proxy server and/or registrar to maintain many simultaneous long-lived TLS connections with numerous UAs. This introduces some valid scalability concerns, especially for intensive ciphersuites. Maintaining redundancy of long-lived TLS connections, especially when a UA is solely responsible for their establishment, could also be cumbersome. TLS only allows SIP entities to authenticate servers to which they are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, nor any other mechanism specified in this document, allows clients to authenticate proxy servers to whom they cannot form a direct TCP connection. 26.4.4 SIPS URIs Actually using TLS on every segment of a request path entails that the terminating UAS must be reachable over TLS (perhaps registering with a SIPS URI as a contact address). This is the preferred use of SIPS. Many valid architectures, however, use TLS to secure part of the request path, but rely on some other mechanism for the final hop to a UAS, for example. Thus SIPS cannot guarantee that TLS usage will be truly end-to-end. Note that since many UAs will not accept incoming TLS connections, even those UAs that do support TLS may be required to maintain persistent TLS connections as described in the TLS limitations section above in order to receive requests over TLS as a UAS. Rosenberg, et. al. Standards Track [Page 249] RFC 3261 SIP: Session Initiation Protocol June 2002 Location services are not required to provide a SIPS binding for a SIPS Request-URI. Although location services are commonly populated by user registrations (as described in Section 10.2.1), various other protocols and interfaces could conceivably supply contact addresses for an AOR, and these tools are free to map SIPS URIs to SIP URIs as appropriate. When queried for bindings, a location service returns its contact addresses without regard for whether it received a request with a SIPS Request-URI. If a redirect server is accessing the location service, it is up to the entity that processes the Contact header field of a redirection to determine the propriety of the contact addresses. Ensuring that TLS will be used for all of the request segments up to the target domain is somewhat complex. It is possible that cryptographically authenticated proxy servers along the way that are non-compliant or compromised may choose to disregard the forwarding rules associated with SIPS (and the general forwarding rules in Section 16.6). Such malicious intermediaries could, for example, retarget a request from a SIPS URI to a SIP URI in an attempt to downgrade security. Alternatively, an intermediary might legitimately retarget a request from a SIP to a SIPS URI. Recipients of a request whose Request-URI uses the SIPS URI scheme thus cannot assume on the basis of the Request-URI alone that SIPS was used for the entire request path (from the client onwards). To address these concerns, it is RECOMMENDED that recipients of a request whose Request-URI contains a SIP or SIPS URI inspect the To header field value to see if it contains a SIPS URI (though note that it does not constitute a breach of security if this URI has the same scheme but is not equivalent to the URI in the To header field). Although clients may choose to populate the Request-URI and To header field of a request differently, when SIPS is used this disparity could be interpreted as a possible security violation, and the request could consequently be rejected by its recipient. Recipients MAY also inspect the Via header chain in order to double-check whether or not TLS was used for the entire request path until the local administrative domain was reached. S/MIME may also be used by the originating UAC to help ensure that the original form of the To header field is carried end-to-end. If the UAS has reason to believe that the scheme of the Request-URI has been improperly modified in transit, the UA SHOULD notify its user of a potential security breach. Rosenberg, et. al. Standards Track [Page 250] RFC 3261 SIP: Session Initiation Protocol June 2002 As a further measure to prevent downgrade attacks, entities that accept only SIPS requests MAY also refuse connections on insecure ports. End users will undoubtedly discern the difference between SIPS and SIP URIs, and they may manually edit them in response to stimuli. This can either benefit or degrade security. For example, if an attacker corrupts a DNS cache, inserting a fake record set that effectively removes all SIPS records for a proxy server, then any SIPS requests that traverse this proxy server may fail. When a user, however, sees that repeated calls to a SIPS AOR are failing, they could on some devices manually convert the scheme from SIPS to SIP and retry. Of course, there are some safeguards against this (if the destination UA is truly paranoid it could refuse all non-SIPS requests), but it is a limitation worth noting. On the bright side, users might also divine that 'SIPS' would be valid even when they are presented only with a SIP URI. 26.5 Privacy SIP messages frequently contain sensitive information about their senders - not just what they have to say, but with whom they communicate, when they communicate and for how long, and from where they participate in sessions. Many applications and their users require that this sort of private information be hidden from any parties that do not need to know it. Note that there are also less direct ways in which private information can be divulged. If a user or service chooses to be reachable at an address that is guessable from the person's name and organizational affiliation (which describes most addresses-of- record), the traditional method of ensuring privacy by having an unlisted ""phone number"" is compromised. A user location service can infringe on the privacy of the recipient of a session invitation by divulging their specific whereabouts to the caller; an implementation consequently SHOULD be able to restrict, on a per-user basis, what kind of location and availability information is given out to certain classes of callers. This is a whole class of problem that is expected to be studied further in ongoing SIP work. In some cases, users may want to conceal personal information in header fields that convey identity. This can apply not only to the From and related headers representing the originator of the request, but also the To - it may not be appropriate to convey to the final destination a speed-dialing nickname, or an unexpanded identifier for a group of targets, either of which would be removed from the Request-URI as the request is routed, but not changed in the To Rosenberg, et. al. Standards Track [Page 251] RFC 3261 SIP: Session Initiation Protocol June 2002 header field if the two were initially identical. Thus it MAY be desirable for privacy reasons to create a To header field that differs from the Request-URI. 27 IANA Considerations All method names, header field names, status codes, and option tags used in SIP applications are registered with IANA through instructions in an IANA Considerations section in an RFC. The specification instructs the IANA to create four new sub- registries under http://www.iana.org/assignments/sip-parameters: Option Tags, Warning Codes (warn-codes), Methods and Response Codes, added to the sub-registry of Header Fields that is already present there. 27.1 Option Tags This specification establishes the Option Tags sub-registry under http://www.iana.org/assignments/sip-parameters. Option tags are used in header fields such as Require, Supported, Proxy-Require, and Unsupported in support of SIP compatibility mechanisms for extensions (Section 19.2). The option tag itself is a string that is associated with a particular SIP option (that is, an extension). It identifies the option to SIP endpoints. Option tags are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC must include the following information, which appears in the IANA registry along with the RFC number of the publication. o Name of the option tag. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (Section 25) characters only. o Descriptive text that describes the extension. 27.2 Warn-Codes This specification establishes the Warn-codes sub-registry under http://www.iana.org/assignments/sip-parameters and initiates its population with the warn-codes listed in Section 20.43. Additional warn-codes are registered by RFC publication. Rosenberg, et. al. Standards Track [Page 252] RFC 3261 SIP: Session Initiation Protocol June 2002 The descriptive text for the table of warn-codes is: Warning codes provide information supplemental to the status code in SIP response messages when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. The ""warn-code"" consists of three digits. A first digit of ""3"" indicates warnings specific to SIP. Until a future specification describes uses of warn-codes other than 3xx, only 3xx warn-codes may be registered. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories. 27.3 Header Field Names This obsoletes the IANA instructions about the header sub-registry under http://www.iana.org/assignments/sip-parameters. The following information needs to be provided in an RFC publication in order to register a new header field name: o The RFC number in which the header is registered; o the name of the header field being registered; o a compact form version for that header field, if one is defined; Some common and widely used header fields MAY be assigned one-letter compact forms (Section 7.3.3). Compact forms can only be assigned after SIP working group review, followed by RFC publication. 27.4 Method and Response Codes This specification establishes the Method and Response-Code sub- registries under http://www.iana.org/assignments/sip-parameters and initiates their population as follows. The initial Methods table is: Rosenberg, et. al. Standards Track [Page 253] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITE [RFC3261] ACK [RFC3261] BYE [RFC3261] CANCEL [RFC3261] REGISTER [RFC3261] OPTIONS [RFC3261] INFO [RFC2976] The response code table is initially populated from Section 21, the portions labeled Informational, Success, Redirection, Client-Error, Server-Error, and Global-Failure. The table has the following format: Type (e.g., Informational) Number Default Reason Phrase [RFC3261] The following information needs to be provided in an RFC publication in order to register a new response code or method: o The RFC number in which the method or response code is registered; o the number of the response code or name of the method being registered; o the default reason phrase for that response code, if applicable; 27.5 The ""message/sip"" MIME type. This document registers the ""message/sip"" MIME media type in order to allow SIP messages to be tunneled as bodies within SIP, primarily for end-to-end security purposes. This media type is defined by the following information: Media type name: message Media subtype name: sip Required parameters: none Optional parameters: version version: The SIP-Version number of the enclosed message (e.g., ""2.0""). If not present, the version defaults to ""2.0"". Encoding scheme: SIP messages consist of an 8-bit header optionally followed by a binary MIME data object. As such, SIP messages must be treated as binary. Under normal circumstances SIP messages are transported over binary-capable transports, no special encodings are needed. Rosenberg, et. al. Standards Track [Page 254] RFC 3261 SIP: Session Initiation Protocol June 2002 Security considerations: see below Motivation and examples of this usage as a security mechanism in concert with S/MIME are given in 23.4. 27.6 New Content-Disposition Parameter Registrations This document also registers four new Content-Disposition header ""disposition-types"": alert, icon, session and render. The authors request that these values be recorded in the IANA registry for Content-Dispositions. Descriptions of these ""disposition-types"", including motivation and examples, are given in Section 20.11. Short descriptions suitable for the IANA registry are: alert the body is a custom ring tone to alert the user icon the body is displayed as an icon to the user render the body should be displayed to the user session the body describes a communications session, for example, as RFC 2327 SDP body 28 Changes From RFC 2543 This RFC revises RFC 2543. It is mostly backwards compatible with RFC 2543. The changes described here fix many errors discovered in RFC 2543 and provide information on scenarios not detailed in RFC 2543. The protocol has been presented in a more cleanly layered model here. We break the differences into functional behavior that is a substantial change from RFC 2543, which has impact on interoperability or correct operation in some cases, and functional behavior that is different from RFC 2543 but not a potential source of interoperability problems. There have been countless clarifications as well, which are not documented here. 28.1 Major Functional Changes o When a UAC wishes to terminate a call before it has been answered, it sends CANCEL. If the original INVITE still returns a 2xx, the UAC then sends BYE. BYE can only be sent on an existing call leg (now called a dialog in this RFC), whereas it could be sent at any time in RFC 2543. o The SIP BNF was converted to be RFC 2234 compliant. Rosenberg, et. al. Standards Track [Page 255] RFC 3261 SIP: Session Initiation Protocol June 2002 o SIP URL BNF was made more general, allowing a greater set of characters in the user part. Furthermore, comparison rules were simplified to be primarily case-insensitive, and detailed handling of comparison in the presence of parameters was described. The most substantial change is that a URI with a parameter with the default value does not match a URI without that parameter. o Removed Via hiding. It had serious trust issues, since it relied on the next hop to perform the obfuscation process. Instead, Via hiding can be done as a local implementation choice in stateful proxies, and thus is no longer documented. o In RFC 2543, CANCEL and INVITE transactions were intermingled. They are separated now. When a user sends an INVITE and then a CANCEL, the INVITE transaction still terminates normally. A UAS needs to respond to the original INVITE request with a 487 response. o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 allowed the UAS not to send a response to INVITE when a BYE was received. That is disallowed here. The original INVITE needs a response. o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs need to support both UDP and TCP. o In RFC 2543, a forking proxy only passed up one challenge from downstream elements in the event of multiple challenges. In this RFC, proxies are supposed to collect all challenges and place them into the forwarded response. o In Digest credentials, the URI needs to be quoted; this is unclear from RFC 2617 and RFC 2069 which are both inconsistent on it. o SDP processing has been split off into a separate specification [13], and more fully specified as a formal offer/answer exchange process that is effectively tunneled through SIP. SDP is allowed in INVITE/200 or 200/ACK for baseline SIP implementations; RFC 2543 alluded to the ability to use it in INVITE, 200, and ACK in a single transaction, but this was not well specified. More complex SDP usages are allowed in extensions. Rosenberg, et. al. Standards Track [Page 256] RFC 3261 SIP: Session Initiation Protocol June 2002 o Added full support for IPv6 in URIs and in the Via header field. Support for IPv6 in Via has required that its header field parameters allow the square bracket and colon characters. These characters were previously not permitted. In theory, this could cause interop problems with older implementations. However, we have observed that most implementations accept any non-control ASCII character in these parameters. o DNS SRV procedure is now documented in a separate specification [4]. This procedure uses both SRV and NAPTR resource records and no longer combines data from across SRV records as described in RFC 2543. o Loop detection has been made optional, supplanted by a mandatory usage of Max-Forwards. The loop detection procedure in RFC 2543 had a serious bug which would report ""spirals"" as an error condition when it was not. The optional loop detection procedure is more fully and correctly specified here. o Usage of tags is now mandatory (they were optional in RFC 2543), as they are now the fundamental building blocks of dialog identification. o Added the Supported header field, allowing for clients to indicate what extensions are supported to a server, which can apply those extensions to the response, and indicate their usage with a Require in the response. o Extension parameters were missing from the BNF for several header fields, and they have been added. o Handling of Route and Record-Route construction was very underspecified in RFC 2543, and also not the right approach. It has been substantially reworked in this specification (and made vastly simpler), and this is arguably the largest change. Backwards compatibility is still provided for deployments that do not use ""pre-loaded routes"", where the initial request has a set of Route header field values obtained in some way outside of Record-Route. In those situations, the new mechanism is not interoperable. o In RFC 2543, lines in a message could be terminated with CR, LF, or CRLF. This specification only allows CRLF. Rosenberg, et. al. Standards Track [Page 257] RFC 3261 SIP: Session Initiation Protocol June 2002 o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. It is now well specified; if a request had a Route header field, its CANCEL or ACK for a non-2xx response to the request need to carry the same Route header field values. ACKs for 2xx responses use the Route values learned from the Record-Route of the 2xx responses. o RFC 2543 allowed multiple requests in a single UDP packet. This usage has been removed. o Usage of absolute time in the Expires header field and parameter has been removed. It caused interoperability problems in elements that were not time synchronized, a common occurrence. Relative times are used instead. o The branch parameter of the Via header field value is now mandatory for all elements to use. It now plays the role of a unique transaction identifier. This avoids the complex and bug- laden transaction identification rules from RFC 2543. A magic cookie is used in the parameter value to determine if the previous hop has made the parameter globally unique, and comparison falls back to the old rules when it is not present. Thus, interoperability is assured. o In RFC 2543, closure of a TCP connection was made equivalent to a CANCEL. This was nearly impossible to implement (and wrong) for TCP connections between proxies. This has been eliminated, so that there is no coupling between TCP connection state and SIP processing. o RFC 2543 was silent on whether a UA could initiate a new transaction to a peer while another was in progress. That is now specified here. It is allowed for non-INVITE requests, disallowed for INVITE. o PGP was removed. It was not sufficiently specified, and not compatible with the more complete PGP MIME. It was replaced with S/MIME. o Added the ""sips"" URI scheme for end-to-end TLS. This scheme is not backwards compatible with RFC 2543. Existing elements that receive a request with a SIPS URI scheme in the Request-URI will likely reject the request. This is actually a feature; it ensures that a call to a SIPS URI is only delivered if all path hops can be secured. Rosenberg, et. al. Standards Track [Page 258] RFC 3261 SIP: Session Initiation Protocol June 2002 o Additional security features were added with TLS, and these are described in a much larger and complete security considerations section. o In RFC 2543, a proxy was not required to forward provisional responses from 101 to 199 upstream. This was changed to MUST. This is important, since many subsequent features depend on delivery of all provisional responses from 101 to 199. o Little was said about the 503 response code in RFC 2543. It has since found substantial use in indicating failure or overload conditions in proxies. This requires somewhat special treatment. Specifically, receipt of a 503 should trigger an attempt to contact the next element in the result of a DNS SRV lookup. Also, 503 response is only forwarded upstream by a proxy under certain conditions. o RFC 2543 defined, but did no sufficiently specify, a mechanism for UA authentication of a server. That has been removed. Instead, the mutual authentication procedures of RFC 2617 are allowed. o A UA cannot send a BYE for a call until it has received an ACK for the initial INVITE. This was allowed in RFC 2543 but leads to a potential race condition. o A UA or proxy cannot send CANCEL for a transaction until it gets a provisional response for the request. This was allowed in RFC 2543 but leads to potential race conditions. o The action parameter in registrations has been deprecated. It was insufficient for any useful services, and caused conflicts when application processing was applied in proxies. o RFC 2543 had a number of special cases for multicast. For example, certain responses were suppressed, timers were adjusted, and so on. Multicast now plays a more limited role, and the protocol operation is unaffected by usage of multicast as opposed to unicast. The limitations as a result of that are documented. o Basic authentication has been removed entirely and its usage forbidden. Rosenberg, et. al. Standards Track [Page 259] RFC 3261 SIP: Session Initiation Protocol June 2002 o Proxies no longer forward a 6xx immediately on receiving it. Instead, they CANCEL pending branches immediately. This avoids a potential race condition that would result in a UAC getting a 6xx followed by a 2xx. In all cases except this race condition, the result will be the same - the 6xx is forwarded upstream. o RFC 2543 did not address the problem of request merging. This occurs when a request forks at a proxy and later rejoins at an element. Handling of merging is done only at a UA, and procedures are defined for rejecting all but the first request. 28.2 Minor Functional Changes o Added the Alert-Info, Error-Info, and Call-Info header fields for optional content presentation to users. o Added the Content-Language, Content-Disposition and MIME-Version header fields. o Added a ""glare handling"" mechanism to deal with the case where both parties send each other a re-INVITE simultaneously. It uses the new 491 (Request Pending) error code."
"o Added the In-Reply-To and Reply-To header fields for supporting the return of missed calls or messages at a later time. o Added TLS and SCTP as valid SIP transports. o There were a variety of mechanisms described for handling failures at any time during a call; those are now generally unified. BYE is sent to terminate. o RFC 2543 mandated retransmission of INVITE responses over TCP, but noted it was really only needed for 2xx. That was an artifact of insufficient protocol layering. With a more coherent transaction layer defined here, that is no longer needed. Only 2xx responses to INVITEs are retransmitted over TCP. o Client and server transaction machines are now driven based on timeouts rather than retransmit counts. This allows the state machines to be properly specified for TCP and UDP. o The Date header field is used in REGISTER responses to provide a simple means for auto-configuration of dates in user agents. o Allowed a registrar to reject registrations with expirations that are too short in duration. Defined the 423 response code and the Min-Expires for this purpose. Rosenberg, et. al. Standards Track [Page 260] RFC 3261 SIP: Session Initiation Protocol June 2002 29 Normative References [1] Handley, M. and V. Jacobson, ""SDP: Session Description Protocol"", RFC 2327, April 1998. [2] Bradner, S., ""Key words for use in RFCs to Indicate Requirement Levels"", BCP 14, RFC 2119, March 1997. [3] Resnick, P., ""Internet Message Format"", RFC 2822, April 2001. [4] Rosenberg, J. and H. Schulzrinne, ""SIP: Locating SIP Servers"", RFC 3263, June 2002. [5] Berners-Lee, T., Fielding, R. and L. Masinter, ""Uniform Resource Identifiers (URI): Generic Syntax"", RFC 2396, August 1998. [6] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)"", RFC 3268, June 2002. [7] Yergeau, F., ""UTF-8, a transformation format of ISO 10646"", RFC 2279, January 1998. [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, ""Hypertext Transfer Protocol -- HTTP/1.1"", RFC 2616, June 1999. [9] Vaha-Sipila, A., ""URLs for Telephone Calls"", RFC 2806, April 2000. [10] Crocker, D. and P. Overell, ""Augmented BNF for Syntax Specifications: ABNF"", RFC 2234, November 1997. [11] Freed, F. and N. Borenstein, ""Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"", RFC 2046, November 1996. [12] Eastlake, D., Crocker, S. and J. Schiller, ""Randomness Recommendations for Security"", RFC 1750, December 1994. [13] Rosenberg, J. and H. Schulzrinne, ""An Offer/Answer Model with SDP"", RFC 3264, June 2002. [14] Postel, J., ""User Datagram Protocol"", STD 6, RFC 768, August 1980. [15] Postel, J., ""DoD Standard Transmission Control Protocol"", RFC 761, January 1980. Rosenberg, et. al. Standards Track [Page 261] RFC 3261 SIP: Session Initiation Protocol June 2002 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, ""Stream Control Transmission Protocol"", RFC 2960, October 2000. [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, ""HTTP authentication: Basic and Digest Access Authentication"", RFC 2617, June 1999. [18] Troost, R., Dorner, S. and K. Moore, ""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"", RFC 2183, August 1997. [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, ""MIME media types for ISUP and QSIG Objects"", RFC 3204, December 2001. [20] Braden, R., ""Requirements for Internet Hosts - Application and Support"", STD 3, RFC 1123, October 1989. [21] Alvestrand, H., ""IETF Policy on Character Sets and Languages"", BCP 18, RFC 2277, January 1998. [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, ""Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"", RFC 1847, October 1995. [23] Housley, R., ""Cryptographic Message Syntax"", RFC 2630, June 1999. [24] Ramsdell B., ""S/MIME Version 3 Message Specification"", RFC 2633, June 1999. [25] Dierks, T. and C. Allen, ""The TLS Protocol Version 1.0"", RFC 2246, January 1999. [26] Kent, S. and R. Atkinson, ""Security Architecture for the Internet Protocol"", RFC 2401, November 1998. 30 Informative References [27] R. Pandya, ""Emerging mobile and personal communication systems,"" IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, ""RTP: A Transport Protocol for Real-Time Applications"", RFC 1889, January 1996. Rosenberg, et. al. Standards Track [Page 262] RFC 3261 SIP: Session Initiation Protocol June 2002 [29] Schulzrinne, H., Rao, R. and R. Lanphier, ""Real Time Streaming Protocol (RTSP)"", RFC 2326, April 1998. [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, ""Megaco Protocol Version 1.0"", RFC 3015, November 2000. [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, ""SIP: Session Initiation Protocol"", RFC 2543, March 1999. [32] Hoffman, P., Masinter, L. and J. Zawinski, ""The mailto URL scheme"", RFC 2368, July 1998. [33] E. M. Schooler, ""A multicast user directory service for synchronous rendezvous,"" Master's Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996. [34] Donovan, S., ""The SIP INFO Method"", RFC 2976, October 2000. [35] Rivest, R., ""The MD5 Message-Digest Algorithm"", RFC 1321, April 1992. [36] Dawson, F. and T. Howes, ""vCard MIME Directory Profile"", RFC 2426, September 1998. [37] Good, G., ""The LDAP Data Interchange Format (LDIF) - Technical Specification"", RFC 2849, June 2000. [38] Palme, J., ""Common Internet Message Headers"", RFC 2076, February 1997. [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, ""An Extension to HTTP: Digest Access Authentication"", RFC 2069, January 1997. [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, ""SIP Call Flow Examples"", Work in Progress. [41] E. M. Schooler, ""Case study: multimedia conference control in a packet-switched teleconferencing system,"" Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359. Rosenberg, et. al. Standards Track [Page 263] RFC 3261 SIP: Session Initiation Protocol June 2002 [42] H. Schulzrinne, ""Personal mobility for multimedia services in the Internet,"" in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996. [43] Floyd, S., ""Congestion Control Principles"", RFC 2914, September 2000. Rosenberg, et. al. Standards Track [Page 264] RFC 3261 SIP: Session Initiation Protocol June 2002 A Table of Timer Values Table 4 summarizes the meaning and defaults of the various timers used by this specification. Timer Value Section Meaning ---------------------------------------------------------------------- T1 500ms default Section 17.1.1.1 RTT Estimate T2 4s Section 17.1.2.2 The maximum retransmit interval for non-INVITE requests and INVITE responses T4 5s Section 17.1.2.2 Maximum duration a message will remain in the network Timer A initially T1 Section 17.1.1.2 INVITE request retransmit interval, for UDP only Timer B 64*T1 Section 17.1.1.2 INVITE transaction timeout timer Timer C > 3min Section 16.6 proxy INVITE transaction bullet 11 timeout Timer D > 32s for UDP Section 17.1.1.2 Wait time for response 0s for TCP/SCTP retransmits Timer E initially T1 Section 17.1.2.2 non-INVITE request retransmit interval, UDP only Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction timeout timer Timer G initially T1 Section 17.2.1 INVITE response retransmit interval Timer H 64*T1 Section 17.2.1 Wait time for ACK receipt Timer I T4 for UDP Section 17.2.1 Wait time for 0s for TCP/SCTP ACK retransmits Timer J 64*T1 for UDP Section 17.2.2 Wait time for 0s for TCP/SCTP non-INVITE request retransmits Timer K T4 for UDP Section 17.1.2.2 Wait time for 0s for TCP/SCTP response retransmits Table 4: Summary of timers Rosenberg, et. al. Standards Track [Page 265] RFC 3261 SIP: Session Initiation Protocol June 2002 Acknowledgments We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments and suggestions. Detailed comments were provided by Ofir Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick Workman. Brian Rosen provided the compiled BNF. Jean Mahoney provided technical writing assistance. This work is based, inter alia, on [41,42]. Rosenberg, et. al. Standards Track [Page 266] RFC 3261 SIP: Session Initiation Protocol June 2002 Authors' Addresses Authors addresses are listed alphabetically for the editors, the writers, and then the original authors of RFC 2543. All listed authors actively contributed large amounts of text to this document. Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63102 USA EMail: alan.johnston@wcom.com Rosenberg, et. al. Standards Track [Page 267] RFC 3261 SIP: Session Initiation Protocol June 2002 Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520 USA EMail: jon.peterson@neustar.com Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA EMail: rsparks@dynamicsoft.com Mark Handley International Computer Science Institute 1947 Center St, Suite 600 Berkeley, CA 94704 USA EMail: mjh@icir.org Eve Schooler AT&T Labs-Research 75 Willow Road Menlo Park, CA 94025 USA EMail: schooler@research.att.com Rosenberg, et. al. Standards Track [Page 268] RFC 3261 SIP: Session Initiation Protocol June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an ""AS IS"" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg, et. al. Standards Track [Page 269] 3GPP TS 29.329 V17.0.0 (2022-04) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Sh Interface based on the Diameter protocol; Protocol details (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 5 1 Scope 6 2 References 6 3 Definitions, symbols and abbreviations 7 3.1 Definitions 7 3.2 Abbreviations 7 4 General 7 5 Use of the Diameter base protocol 8 6 Diameter application for Sh interface 8 6.1 Command-Code values 8 6.1.1 User-Data-Request (UDR) Command 8 6.1.2 User-Data-Answer (UDA) Command 9 6.1.3 Profile-Update-Request (PUR) Command 10 6.1.4 Profile-Update-Answer (PUA) Command 10 6.1.5 Subscribe-Notifications-Request (SNR) Command 11 6.1.6 Subscribe-Notifications-Answer (SNA) Command 11 6.1.7 Push-Notification-Request (PNR) Command 12 6.1.8 Push-Notifications-Answer (PNA) Command 12 6.2 Result-Code AVP values 13 6.2.1 Success 13 6.2.2 Permanent Failures 13 6.2.2.1 DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED (5100) 13 6.2.2.2 DIAMETER_ERROR_OPERATION_NOT_ALLOWED (5101) 13 6.2.2.3 DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ (5102) 13 6.2.2.4 DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED (5103) 13 6.2.2.5 DIAMETER_ERROR_USER_DATA_CANNOT_BE_NOTIFIED (5104) 13 6.2.2.6 DIAMETER_ERROR_TOO_MUCH_DATA (5008) 13 6.2.2.7 DIAMETER_ERROR_TRANSPARENT_DATA OUT_OF_SYNC (5105) 13 6.2.2.8 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) 13 6.2.2.9 DIAMETER_ERROR_SUBS_DATA_ABSENT (5106) 13 6.2.2.10 DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA (5107) 14 6.2.2.11 DIAMETER_ERROR_DSAI_NOT_AVAILABLE (5108) 14 6.2.2.12 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) 14 6.2.3 Transient Failures 14 6.2.3.1 DIAMETER_USER_DATA_NOT_AVAILABLE (4100) 14 6.2.3.2 DIAMETER_PRIOR_UPDATE_IN_PROGRESS (4101) 14 6.3 AVPs 15 6.3.1 User-Identity AVP 16 6.3.2 MSISDN AVP 16 6.3.3 User-Data AVP 16 6.3.4 Data-Reference AVP 16 6.3.5 Service-Indication AVP 17 6.3.6 Subs-Req-Type AVP 17 6.3.7 Requested-Domain AVP 18 6.3.7A Requested-Nodes AVP 18 6.3.8 Current-Location AVP 18 6.3.9 Server-Name AVP 18 6.3.10 Identity-Set AVP 18 6.3.11 Supported-Features AVP 18 6.3.12 Feature-List-ID AVP 19 6.3.13 Feature-List AVP 19 6.3.14 Supported-Applications AVP 19 6.3.15 Public-Identity AVP 19 6.3.16 Expiry-Time AVP 19 6.3.17 Send-Data-Indication AVP 19 6.3.18 DSAI-Tag AVP 19 6.3.19 Wildcarded-Public-Identity AVP 19 6.3.20 Wildcarded-IMPU AVP 19 6.3.21 Session-Priority AVP 19 6.3.22 One-Time-Notification AVP 19 6.3.23 Serving-Node-Indication AVP 20 6.3.24 Repository-Data-ID AVP 20 6.3.25 Sequence-Number AVP 20 6.3.26 Pre-paging-Supported AVP 20 6.3.27 Local-Time-Zone-Indication AVP 20 6.3.28 UDR-Flags 20 6.3.29 Call-Reference-Info AVP 21 6.3.30 Call-Reference-Number AVP 21 6.3.31 AS-Number AVP 21 6.3.32 OC-Supported-Features 21 6.3.33 OC-OLR 21 6.3.34 DRMP AVP 21 6.3.35 Load 21 6.4 Use of namespaces 21 6.4.1 AVP codes 21 6.4.2 Experimental-Result-Code AVP values 22 6.4.3 Command Code values 22 6.4.4 Application-ID value 22 7 Special Requirements 23 7.1 Version Control 23 Annex A (informative): Change history 24 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope The present document defines a transport protocol for use in the IP multimedia (IM) Core Network (CN) subsystem based on the Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15]. The present document is applicable to: - The Sh interface between an AS and the HSS. - The Sh interface between an SCS and the HSS. Whenever it is possible this document specifies the requirements for this protocol by reference to specifications produced by the IETF within the scope of Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15]. Where this is not possible, extensions to the Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15] are defined within this document. 2 References The following documents contain provisions, which through reference in this text constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TSÊ29.328 ""IP Multimedia (IM) Subsystem Sh interface; signalling flows and message contents"". [2] 3GPP TSÊ33.210 ""3G Security; Network Domain Security; IP Network Layer Security"". [3] IETF RFC 2960 ""Stream Control Transmission Protocol"". [4] Void. [5] IETF RFC 2234 ""Augmented BNF for syntax specifications"". [6] 3GPP TSÊ29.229 ""Cx and Dx Interfaces based on the Diameter protocol; protocol details"". [7] IETF RFC 3589 ""Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5"". [8] ITU-TÊRecommendationÊE.164: ""The international public telecommunication numbering plan"". [9] 3GPP TRÊ33.978 ""Security aspects of early IP Multimedia Subsystem (IMS) (Release 6)"". [10] 3GPP TSÊ29.364 ""IMS Application Server Service Data Descriptions for AS interoperability"". [11] 3GPP TSÊ29.002 ""Mobile Application Part (MAP) specification"". [12] IETF RFC 7683: ""Diameter Overload Indication Conveyance"". [13] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [14] IETFÊRFCÊ8583: ""Diameter Load Information Conveyance"". Ê[15] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [16]] 3GPP TSÊ29.336: ""Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications"". 3 Definitions, symbols and abbreviations 3.1 Definitions Refer to IETFÊRFCÊ6733Ê[15] for the definitions of some terms used in this document. For the purposes of the present document, the following terms and definitions apply. Attribute-Value Pair: see IETFÊRFCÊ6733Ê[15], it corresponds to an Information Element in a Diameter message. Server: SIP-server. User data: user profile data. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AAA Authentication, Authorization and Accounting AS Application Server ABNF Augmented Backus-Naur Form AVP Attribute-Value Pair CN Core Network DRMP Diameter Routing Message Priority DSCP Differentiated Services Code Point HSS Home Subscriber Server IANA Internet Assigned Numbers Authority IETF Internet Engineering Task Force IMS IP Multimedia Subsystem NDS Network Domain Security RFC Request For Comment SCTP Stream Control Transport Protocol UCS Universal Character Set URL Uniform Resource Locator UTF UCS Transformation Formats 4 General he Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and event codes specified in clauseÊ6 of this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) are unmodified. 5 Use of the Diameter base protocol The same clarifications of clauseÊ5 of 3GPP TSÊ29.229Ê[6] shall apply to the Sh interface. An exception is that the application identifier for this application is defined in chapter 6. 6 Diameter application for Sh interface This clause specifies a Diameter application that allows a Diameter server and a Diameter client: - to download and update transparent and non-transparent user data - to request and send notifications on changes on user data The Sh interface protocol is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP ( http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the Sh interface application is 16777217 (allocated by IANA). 6.1 Command-Code values This clause defines Command-Code values for this Diameter application. Every command is defined by means of the ABNF syntax (as defined in RFC 2234Ê[5]), according to the Command Code Format (CCF) specification defined in IETFÊRFCÊ6733Ê[15]. Whenever the definition and use of an AVP is not specified in this document, what is stated in 3GPP TSÊ29.229Ê[6] shall apply. NOTE: As the Diameter commands described in this specification have been defined based on the former specification of the Diameter base protocol, the Vendor-Specific-Application-Id AVP is still listed as a required AVP (an AVP indicated as {AVP}) in the command code format specifications defined in this specification to avoid backward compatibility issues, even if the use of this AVP has been deprecated in the new specification of the Diameter base protocol (IETFÊRFCÊ6733Ê[15]). The command codes for the Sh interface application are taken from the range allocated by IANA in IETF RFC 3589Ê[7] as assigned in this specification. For these commands, the Application-ID field shall be set to 16777217 (application identifier of the Sh interface application, allocated by IANA). The following Command Codes are defined in this specification: Table 6.1.1: Command-Code values Command-Name Abbreviation Code Clause User-Data-Request UDR 306 6.1.1 User-Data-Answer UDA 306 6.1.2 Profile-Update-Request PUR 307 6.1.3 Profile-Update-Answer PUA 307 6.1.4 Subscribe-Notifications-Request SNR 308 6.1.5 Subscribe-Notifications-Answer SNA 308 6.1.6 Push-Notification-Request PNR 309 6.1.7 Push-Notification-Answer PNA 309 6.1.8 6.1.1 User-Data-Request (UDR) Command The User-Data-Request (UDR) command, indicated by the Command-Code field set to 306 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to request user data. Message Format < User-Data -Request> ::= < Diameter Header: 306, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ Server-Name ] *[ Service-Indication ] *{ Data-Reference } *[ Identity-Set ] [ Requested-Domain ] [ Current-Location ] *[ DSAI-Tag ] [ Session-Priority ] [ User-Name ] [ Requested-Nodes ] [ Serving-Node-Indication ] [ Pre-paging-Supported ] [ Local-Time-Zone-Indication ] [ UDR-Flags ] [ Call-Reference-Info ] [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.2 User-Data-Answer (UDA) Command The User-Data-Answer (UDA) command, indicated by the Command-Code field set to 306 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the User-Data-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < User-Data-Answer > ::= < Diameter Header: 306, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Data ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.3 Profile-Update-Request (PUR) Command The Profile-Update-Request (PUR) command, indicated by the Command-Code field set to 307 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to update user data in the server. Message Format < Profile-Update-Request > ::= < Diameter Header: 307, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Name ] *{ Data-Reference } { User-Data } [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] NOTE: More than one Data-Reference AVP may be present in the message only if both the AS and the HSS support the Update-Eff-Enhance feature. How the AS knows whether the HSS supports the Update-Eff-Enhance feature is implementation issue, e.g. the AS can get the information from a previous PUA message. 6.1.4 Profile-Update-Answer (PUA) Command The Profile-Update-Answer (PUA) command, indicated by the Command-Code field set to 307 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Profile-Update-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Profile-Update-Answer > ::=< Diameter Header: 307, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ Repository-Data-ID ] [ Data-Reference ] *[ Supported-Features ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] NOTE: The Data-Reference AVP may be present in the message only if both the AS and the HSS support the Update-Eff-Enhance feature. 6.1.5 Subscribe-Notifications-Request (SNR) Command The Subscribe-Notifications-Request (SNR) command, indicated by the Command-Code field set to 308 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to request notifications of changes in user data. Message Format < Subscribe-Notifications-Request > ::= < Diameter Header: 308, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] *[ Service-Indication ] [ Send-Data-Indication ] [ Server-Name ] { Subs-Req-Type } *{ Data-Reference } *[ Identity-Set ] [ Expiry-Time ] *[ DSAI-Tag ] [One-Time-Notification] [ User-Name ] [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.6 Subscribe-Notifications-Answer (SNA) Command The Subscribe-Notifications-Answer command, indicated by the Command-Code field set to 308 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Subscribe-Notifications-Request command. The Result-Code or Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Subscribe-Notifications-Answer > ::= < Diameter Header: 308, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } [ Result-Code ] [ Experimental-Result ] { Origin-Host } { Origin-Realm } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] *[ Supported-Features ] [ User-Data ] [ Expiry-Time ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.7 Push-Notification-Request (PNR) Command The Push-Notification-Request (PNR) command, indicated by the Command-Code field set to 309 and the 'R' bit set in the Command Flags field, is sent by a Diameter server to a Diameter client in order to notify changes in the user data in the server. Message Format < Push-Notification-Request > ::= < Diameter Header: 309, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Name ] { User-Data } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.8 Push-Notifications-Answer (PNA) Command The Push-Notifications-Answer (PNA) command, indicated by the Command-Code field set to 309 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Push-Notification-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Push-Notification-Answer > ::=< Diameter Header: 309, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.2 Result-Code AVP values This clause defines new result code values that must be supported by all Diameter implementations that conform to this specification. The result codes defined in 3GPP TSÊ29.229Ê[6] are also applicable. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and Result-Code AVP shall be absent. 6.2.1 Success Result codes that fall within the Success category are used to inform a peer that a request has been successfully completed. No result codes within this category have been defined so far. 6.2.2 Permanent Failures Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not be attempted again. 6.2.2.1 DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED (5100) The data received by the AS is not supported or recognized. 6.2.2.2 DIAMETER_ERROR_OPERATION_NOT_ALLOWED (5101) The requested operation is not allowed for the user 6.2.2.3 DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ (5102) The requested user data is not allowed to be read. 6.2.2.4 DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED (5103) The requested user data is not allowed to be modified. 6.2.2.5 DIAMETER_ERROR_USER_DATA_CANNOT_BE_NOTIFIED (5104) The requested user data is not allowed to be notified on changes. 6.2.2.6 DIAMETER_ERROR_TOO_MUCH_DATA (5008) The size of the data pushed to the receiving entity exceeds its capacity. This error code is defined in 3GPP TSÊ29.229Ê[6]. 6.2.2.7 DIAMETER_ERROR_TRANSPARENT_DATA OUT_OF_SYNC (5105) The request to update the repository data at the HSS could not be completed because the requested update is based on an out-of-date version of the repository data. That is, the sequence number in the Sh-Update Request message, does not match with the immediate successor of the associated sequence number stored for that repository data at the HSS. It is also used where an AS tries to create a new set of repository data when the identified repository data already exists in the HSS. 6.2.2.8 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) See 3GPP TSÊ29.229Ê[6] clauseÊ6.2.2.11. 6.2.2.9 DIAMETER_ERROR_SUBS_DATA_ABSENT (5106) The Application Server requested to subscribe to changes to Repository Data that is not present in the HSS. 6.2.2.10 DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA (5107) The AS received a notification of changes of some information to which it is not subscribed. 6.2.2.11 DIAMETER_ERROR_DSAI_NOT_AVAILABLE (5108) The Application Server addressed a DSAI not configured in the HSS. 6.2.2.12 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) See 3GPP TSÊ29.229Ê[6] 6.2.3 Transient Failures Errors that fall within the transient failures category are those used to inform a peer that the request could not be satisfied at the time that it was received. The request may be able to be satisfied in the future. 6.2.3.1 DIAMETER_USER_DATA_NOT_AVAILABLE (4100) The requested user data is not available at this time to satisfy the requested operation. 6.2.3.2 DIAMETER_PRIOR_UPDATE_IN_PROGRESS (4101) The request to update data at the HSS could not be completed for one of the following reasons: - If the Data Reference is Repository Data, then the related Repository Data is currently being updated by another entity; - If the Data Reference is other than Repository Data, then the related data is currently being updated. 6.3 AVPs The following table describes the Diameter AVPs defined for the Sh interface protocol, their AVP Code values, types, possible flag values and whether the AVP may or not be encrypted. Table 6.3.1: Diameter Multimedia Application AVPs AVP Flag rules Attribute Name AVP Code Clause defined Value Type Must May Should not Must not May Encrypt User-Identity 700 6.3.1 Grouped M, V No MSISDN 701 6.3.2 OctetString M, V No User-Data 702 6.3.3 OctetString M, V No Data-Reference 703 6.3.4 Enumerated M, V No Service-Indication 704 6.3.5 OctetString M, V No Subs-Req-Type 705 6.3.6 Enumerated M, V No Requested-Domain 706 6.3.7 Enumerated M, V No Current-Location 707 6.3.8 Enumerated M, V No Identity-Set 708 6.3.10 Enumerated V M No Expiry-Time 709 6.3.16 Time V M No Send-Data-Indication 710 6.3.17 Enumerated V M No Server-Name 602 6.3.9 UTF8String M, V No Supported-Features 628 6.3.11 Grouped V M No Feature-List-ID 629 6.3.12 Unsigned32 V M No Feature-List 630 6.3.13 Unsigned32 V M No Supported-Applications 631 6.3.14 Grouped V M No Public-Identity 601 6.3.15 UTF8String M, V No DSAI-Tag 711 6.3.18 OctetString M, V No Wildcarded-Public-Identity 634 6.3.19 UTF8String V M No Wildcarded-IMPU 636 6.3.20 UTF8String V M No Session-Priority 650 6.3.21 Enumerated V M No One-Time-Notification 712 6.3.22 Enumerated V M No Requested-Nodes 713 6.3.7A Unsigned32 V M No Serving-Node-Indication 714 6.3.23 Enumerated V M No Repository-Data-ID 715 6.3.24 Grouped V M No Sequence-Number 716 6.3.25 Unsigned32 V M No Pre-paging-Supported 717 6.3.26 Enumerated V M No Local-Time-Zone-Indication 718 6.3.27 Enumerated V M No UDR-Flags 719 6.3.28 Unsigned32 V M No Call-Reference-Info 720 6.3.29 Grouped V M No Call-Reference-Number 721 6.3.30 OctetString V M No AS-Number 722 6.3.31 OctetString V M No OC-Supported-Features 621 NOTE 3 6.3.32 Grouped M, V No OC-OLR 623 NOTE 3 6.3.33 Grouped M, V No DRMP 301 NOTE 4 6.3.34 Enumerated M, V No Load NOTE 5 6.3.35 Grouped M, V No NOTE 1: The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see 3GPP TSÊ29.229Ê[6]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. NOTE 3: The value of these attributes is defined in IETFÊRFCÊ7683Ê[12]. NOTE 4: The value of this attribute is defined in IETFÊRFCÊ7944Ê[13]. NOTE 5: The value of this attribute is defined in IETFÊRFCÊ8583Ê[14]. The following table specifies the Diameter AVPs re-used by the Sh interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within Sh. Table 6.3/2: Sh re-used Diameter AVPs Attribute Name Reference Comments M-bit External-Identifier 3GPP TSÊ29.336Ê[16] Must set NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: ""Must set"", ""Must not set"". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. 6.3.1 User-Identity AVP The User-Identity AVP is of type Grouped. This AVP contains either a Public- Identity AVP or an MSISDN AVP or an External-Identifier AVP. AVP format User-Identity ::= <AVP header: 700 10415> [Public-Identity] [MSISDN] [External-Identifier] *[AVP] 6.3.2 MSISDN AVP The MSISDN AVP is of type OctetString. This AVP contains an MSISDN, in international number format as described in ITU-T Rec E.164Ê[8], encoded as a TBCD-string, i.e. digits from 0 through 9 are encoded 0000 to 1001; 1111 is used as a filler when there is an odd number of digits; bits 8 to 5 of octet n encode digit 2n; bits 4 to 1 of octet n encode digit 2(n-1)+1. 6.3.3 User-Data AVP The User-Data AVP is of type OctetString. This AVP contains the user data requested in the UDR/UDA, SNR/SNA and PNR/PNA operations and the data to be modified in the PUR/PUA operation. The exact content and format of this AVP is described in 3GPP TSÊ29.328Ê[1] Annex C as Sh-Data. 6.3.4 Data-Reference AVP The Data-Reference AVP is of type Enumerated, and indicates the type of the requested user data in the operation UDR and SNR. Its exact values and meaning is defined in 3GPP TSÊ29.328Ê[1]."
"The following values are defined (more details are given in 3GPP TSÊ29.328Ê[1]): RepositoryData (0) IMSPublicIdentity (10) IMSUserState (11) S-CSCFName (12) InitialFilterCriteria (13) This value is used to request initial filter criteria relevant to the requesting AS LocationInformation (14) UserState (15) ChargingInformation (16) MSISDN (17) PSIActivation (18) DSAI (19) ServiceLevelTraceInfo (21) IPAddressSecureBindingInformation (22) ServicePriorityLevel (23) SMSRegistrationInfo (24) UEReachabilityForIP (25) TADSinformation (26) STN-SR (27) UE-SRVCC-Capability (28) ExtendedPriority (29) CSRN (30) ReferenceLocationInformation (31) IMSI (32) IMSPrivateUserIdentity (33) IMEISV (34) UE-5G-SRVCC-Capability (35) NOTE: Value 20 is reserved. 6.3.5 Service-Indication AVP The Service-Indication AVP is of type OctetString. This AVP contains the Service Indication that identifies a service or a set of services in an AS and the related repository data in the HSS. Standardized values of Service-Indication identifying a standardized service or set of services in the AS and standardized format of the related repository data are defined in 3GPP TSÊ29.364Ê[10]. 6.3.6 Subs-Req-Type AVP The Subs-Req-Type AVP is of type Enumerated, and indicates the type of the subscription-to-notifications request. The following values are defined: Subscribe (0) This value is used by an AS to subscribe to notifications of changes in data. Unsubscribe (1) This value is used by an AS to unsubscribe to notifications of changes in data. 6.3.7 Requested-Domain AVP The Requested-Domain AVP is of type Enumerated, and indicates the access domain for which certain data (e.g. user state) are requested. The following values are defined: CS-Domain (0) The requested data apply to the CS domain. PS-Domain (1) The requested data apply to the PS domain. 6.3.7A Requested-Nodes AVP The Requested-Nodes AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.7A/1: Table 6.3.7A/1: Requested-Nodes Bit Name Description 0 MME The requested data apply to the MME 1 SGSN The requested data apply to the SGSN 2 3GPP-AAA-SERVER-TWAN The requested data apply to the 3GPP AAA Server for TWAN 3 AMF The requested data apply to the AMF (for 3GPP access) 6.3.8 Current-Location AVP The Current-Location AVP is of type Enumerated, and indicates whether an active location retrieval has to be initiated or not: DoNotNeedInitiateActiveLocationRetrieval (0) The request indicates that the initiation of an active location retrieval is not required. InitiateActiveLocationRetrieval (1) It is requested that an active location retrieval is initiated. 6.3.9 Server-Name AVP The Server-Name contains a SIP-URL used to identify an AS. See 3GPP TSÊ29.229Ê[6] for further description of this AVP. 6.3.10 Identity-Set AVP The Identity-Set AVP is of type Enumerated and indicates the requested set of IMS Public Identities. The following values are defined: ALL_IDENTITIES (0) REGISTERED_IDENTITIES (1) IMPLICIT_IDENTITIES (2) ALIAS_IDENTITIES (3) 6.3.11 Supported-Features AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.29. 6.3.12 Feature-List-ID AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.30. 6.3.13 Feature-List AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.31. 6.3.14 Supported-Applications AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.32. 6.3.15 Public-Identity AVP The Public-Identity AVP contains a Public User Identity. See 3GPP TSÊ29.229Ê[6] for the definition of this AVP. 6.3.16 Expiry-Time AVP The Expiry-Time AVP is of type Time. This AVP contains the expiry time of subscriptions to notifications in the HSS. 6.3.17 Send-Data-Indication AVP The Send-Data-Indication AVP is of type Enumerated. If present it indicates that the sender requests the User-Data. The following values are defined: USER_DATA_NOT_REQUESTED (0) USER_DATA_REQUESTED (1) 6.3.18 DSAI-Tag AVP The DSAI-Tag AVP is of type OctetString. This AVP contains the DSAI-Tag identifying the instance of the Dynamic Service Activation Information being accessed for the Public Identity. 6.3.19 Wildcarded-Public-Identity AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.35 for the definition of theWildcarded-Public-Identity AVP. This AVP only contains a Wildcarded PSI over Sh interface. 6.3.20 Wildcarded-IMPU AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.43. 6.3.21 Session-Priority AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.56. 6.3.22 One-Time-Notification AVP The One-Time-Notification AVP is of type Enumerated. If present it indicates that the sender requests to be notified only one time. The following values are defined: ONE_TIME_NOTIFICATION_REQUESTED (0) This AVP is only applicable to UE reachability for IP (25) 6.3.23 Serving-Node-Indication AVP The Serving-Node-Indication AVP is of type Enumerated. If present it indicates that the sender does not require any location information other than the Serving Node Addresses/Identities requested (e.g. MME name, VLR number). Other location information (e.g. Global Cell ID, Tracking Area ID) may be absent. The following values are defined: ONLY_SERVING_NODES_REQUIRED (0) 6.3.24 Repository-Data-ID AVP The Repository-Data-ID AVP is of type Grouped. This AVP shall contain a Service-Indication AVP and a Sequence-Number AVP. AVP format Repository-Data-ID ::= <AVP header: 715 10415> {Service-Indication} {Sequence-Number} *[AVP] 6.3.25 Sequence-Number AVP The Sequence-Number AVP is of type Unsigned32. This AVP contains a number associated to a repository data. 6.3.26 Pre-paging-Supported AVP The Pre-paging-Supported AVP is of type Enumerated. It indicates whether the sender supports pre-paging or not. The following values are defined: PREPAGING_NOT_SUPPORTED (0) PREPAGING_SUPPORTED (1) If this AVP is not present in the command, the default value is PREPAGING_NOT_SUPPORTED (0). 6.3.27 Local-Time-Zone-Indication AVP The Local-Time-Zone-Indication AVP is of type Enumerated. If present it indicates that the Local Time Zone information (time zone and daylight saving time) of the visited network where the UE is attached is requested with or without other location information. The following values are defined: ONLY_LOCAL_TIME_ZONE_REQUESTED (0) LOCAL_TIME_ZONE_WITH_LOCATION_INFO_REQUESTED (1) 6.3.28 UDR-Flags The UDR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in 3GPPÊTSÊ29.328Ê[1]. Table 6.3.28/1: UDR-Flags Bit Name 0 Location-Information-EPS-Supported 1 RAT-Type-Requested NOTE: Bits not defined in this table shall be cleared by the sender of the request and discarded by the receiver of the request. 6.3.29 Call-Reference-Info AVP The Call-Reference-Info AVP is of type Grouped. This AVP shall contain a Call-Reference-Number AVP and an AS-Number AVP. AVP format Call-Reference-Info ::= <AVP header: 720 10415> {Call-Reference-Number} {AS-Number} *[AVP] 6.3.30 Call-Reference-Number AVP The Call-Reference-Number AVP is of type OctetString. The exact content and format of this AVP is described in 3GPP TSÊ29.002Ê[11]. 6.3.31 AS-Number AVP The AS-Number AVP is of type OctetString. The exact content and format of this AVP corresponds to the gmsc-address parameter described in 3GPP TSÊ29.002Ê[11]. 6.3.32 OC-Supported-Features The OC-Supported-Features AVP is of type Grouped and it is defined in IETF RFC 7683Ê[12]. This AVP is used to support Diameter overload control mechanism. 6.3.33 OC-OLR The OC-OLR AVP is of type Grouped and it is defined in IETF RFC 7683Ê[12]. This AVP is used to support Diameter overload control mechanism. 6.3.34 DRMP AVP The DRMP AVP is of type Enumerated and it is defined in IETFÊRFCÊ7944Ê[13]. This AVP allows the HSS/SLF and the AS/OSA SCS to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message. 6.3.35 Load The Load AVP is of type Grouped and it is defined in IETFÊRFCÊ8583Ê[14]. This AVP is used to support the Diameter load control mechanism. 6.4 Use of namespaces This clause contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA. 6.4.1 AVP codes This specification assigns the AVP values from the AVP Code namespace managed by 3GPP for its Diameter vendor-specific applications. See clauseÊ6.3 for the assignment of the namespace in this specification. 6.4.2 Experimental-Result-Code AVP values This specification has assigned Experimental-Result-Code AVP values 4100-4101 and 5100-5105. See clauseÊ6.2. 6.4.3 Command Code values This specification assigns the values 306-309 from the range allocated by IANA to 3GPP in IETF RFC 3589Ê[7]. 6.4.4 Application-ID value IANA has allocated the value 16777217 for the 3GPP Sh interface application. 7 Special Requirements 7.1 Version Control The version control mechanisms specified in 3GPP TSÊ29.229Ê[6] clauses 7.1, 7.2 and 7.3 apply to this specification. The following table of features shall apply to the Sh interface. Table 7.1.1: Features of feature list 1 used in Sh Feature bit Feature M/O Description 0 Notif-Eff M This feature is applicable to the UDR/UDA, SNR/SNA and PNR/PNA command pairs. It requires support in both the HSS and the AS. If multiple subscriptions to notifications are associated with a Public User Identity, the HSS may combine the notifications for multiple Data References and/or Service Indications and/or Identity Sets into a single Push-Notification-Request message. The User-Data-Request / Answer and the Subscribe-Notifications-Request / Answer allow multiple Data References, Service Indications and Identity Sets. The User-Data-Answer and Push-Notification-Request allow combining multiple DataReference items resulting in the User Data AVP including a single XML document with the separable XML clauses populated. 1 Update-Eff O This feature is applicable to the PUR/PUA commands. If both the HSS and the AS support this feature, a PUR command where the Data reference type is Repository Data, may contain an XML document with several Repository Data instances. 2 Update-Eff-Enhance O This feature is an enhancement of the Update-Eff feature and requires Update-Eff is supported. It is applicable to the PUR/PUA commands. If both the HSS and the AS support this feature, a PUR command may contain an XML document with several Data instances. 3 Additional-MSISDN O This feature is applicable to UDR/UDA commands. It requires support in both HSS and AS. If enabled, it extends the information returned with DataReference=17. Instead of returning only MSISDN, it includes ExtendedMSISDN. See 3GPP TSÊ29.328Ê[1] for more information. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""MOM"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. The following table shall apply to the Sh interface; the column Application identifier lists the used application identifiers on Sh and 3GPP. Table 7.1.2: Application identifiers used in Sh Application identifier First applied 16777217 3GPP Rel-5 Annex A (informative): Change history Change history Date Meeting TDoc CR Rev Cat Subject/Comment New version June 2002 CN#16 NP-020266 Version 2.0.1 present in CN#16 for approval 5.0.0 Sep 2002 CN#17 NP-020450 2 1 Cancellation of subscriptions to notifications 5.1.0 Sep 2002 CN#17 NP-020450 3 1 Addition of AVPs to User-Data-Request 5.1.0 Dec 2002 CN#18 NP-020592 6 - Error handling in HSS when being updated with too much data 5.2.0 Mar 2003 CN#19 NP-030102 005 1 Initial Filter Criteria 5.3.0 Mar 2003 CN#19 NP-030102 007 2 Update after Diameter has become RFC 5.3.0 Mar 2003 CN#19 NP-030102 011 - Missing code-point in Data-Reference AVP 5.3.0 Mar 2003 CN#19 NP-030102 013 - Registration State Alignment 5.3.0 Mar 2003 CN#19 NP-030102 008 - Correction of the Application Server Identification type for Initial Filter Criteria usage 5.3.0 Mar 2003 CN#19 NP-030102 009 - Clarification on Sh interface for charging purposes 5.3.0 Jun 2003 CN#20 NP-030216 014 1 Co-ordination of Update of Repository Data 5.4.0 Jun 2003 CN#20 NP-030216 015 1 Command code correction for UDA plus editorial corrections 5.4.0 Jun 2003 CN#20 NP-030216 016 - Correction on Current-Location AVP values 5.4.0 Jun 2003 CN#20 NP-030216 018 - Correction to the use of User-Identity 5.4.0 Jun 2003 CN#20 NP-030216 019 1 Correction to the use of Data-Reference 5.4.0 Dec 2003 CN#22 Editorial changes in application IDs and references [4] and [7]. 5.4.1 Mar 2004 CN#23 NP-040135 031 1 Add MSISDN to set of Data that may be downloaded 5.5.0 Mar 2004 CN#23 NP-040055 032 2 Introduction of 'Identity-Set' AVP 6.0.0 Jun 2004 CN#24 NP-040216 037 - Correction to description of Data Reference AVP value 10 6.1.0 Jun 2004 CN#24 NP-040216 035 1 Correction of reference for definition of MSISDN 6.1.0 Sep 2004 CN#25 NP-040394 043 - Incorrect Data-Reference AVP in Subscriber Notification Answer Command 6.2.0 Sep 2004 CN#25 NP-040395 046 1 Application version control 6.2.0 Sep 2004 CN#25 NP-040394 041 1 Public-Identity is unspecified for the Sh interface 6.2.0 Sep 2004 CN#25 NP-040395 045 1 Single Public_Identity required in Grouped User-Identity AVP 6.2.0 Sep 2004 CN#25 NP-040394 049 - Correction of the Application-Id code 6.2.0 Sep 2004 CN#25 NP-040412 051 1 Re-numbering of 3GPP specific AVP codes 6.2.0 Dec 2004 CN#26 NP-040578 053 - Sh ABNF corrections 6.3.0 Mar 2005 CN#27 NP-050031 057 1 Introduction of Failed AVP 6.4.0 Mar 2005 CN#27 NP-050031 064 - Sh-Update needs to include Data-Reference to be future proof 6.4.0 Jun 2005 CT#28 CP-050216 069 - Sh UDR correction 6.5.0 Jun 2005 CT#28 CP-050087 070 - Correction of references 6.5.0 Jun 2005 CT#28 CP-050087 071 1 Corrections to message parameters 6.5.0 Jun 2005 CT#28 CP-050087 072 1 Miscellaneous Corrections 6.5.0 Jun 2005 CT#28 CP-050216 074 - Correction to allow realm based routing 6.5.0 Sep 2005 CT#29 CP-050424 075 - Identity-Set correction 6.6.0 Sep 2005 CT#29 CP-050422 095 1 State the condition for encryption of the Data Reference 6.6.0 Sep 2005 CT#29 CP-050423 097 1 Early IMS Security based protection for the Ut interface 6.6.0 Dec 2005 CT#30 CP-050625 098 3 Notification & Query Efficiency 7.0.0 Dec 2005 CT#30 CP-050625 099 1 Management of subscriptions 7.0.0 Mar 2006 CT#31 CP-060084 0100 1 User-Data in the response to Sh-Subs-Notif 7.1.0 Mar 2006 CT#31 CP-060084 0101 3 New error indications for the Sh-Subs-Notif procedure 7.1.0 Jun 2006 CT#32 CP-060319 0105 2 Sh interface efficiency improvement 7.2.0 Sep 2006 CT#33 CP-060417 0107 2 Introduction of Activation State Information for IMS (DSAI) 7.3.0 Sep 2006 CT#33 CP-060417 0108 - Addition of AVPs in SNR and SNA 7.3.0 Sep 2006 CT#33 CP-060417 0110 1 Public User Identity Grouping Information 7.3.0 Sep 2006 CT#33 CP-060405 0112 - Missing Data Reference value 7.3.0 Sep 2006 CT#33 CP-060417 0113 1 Errors to be sent in response to Sh-Notif 7.3.0 Sep 2007 CT#37 CP-070527 0118 - Define User-Data AVP 7.4.0 Sep 2007 CT#37 CP-070527 0119 1 Wildcarded PSI as key in the Sh Interface 7.4.0 Nov 2007 CT#38 CP-070743 0120 - ABNF correction for UDR and SNR 7.5.0 Nov 2007 CT#38 CP-070743 0121 1 PNR for Subscriptions to Notifications for all Identity Sets 7.5.0 Mar 2008 CT#39 CP-080019 0122 - Wildcarded Public User Identities 8.0.0 Jun 2008 CT#40 CP-080267 0123 1 DSAI Corrections 8.1.0 Jun 2008 CT#40 CP-080702 0130 1 Service Indication for standardized services 8.2.0 Jun 2008 CT#40 CP-080883 0132 1 Correction of Identity-Set AVP 8.2.0 Mar 2009 CT#43 CP-090042 0134 1 AliasesRepositoryData removal 8.3.0 Jun 2009 CT#44 CP-090305 0136 Missing data-reference for GIBA 8.4.0 Dec 2009 CT#46 CP-090778 0138 Session-Priority AVP 8.5.0 Dec 2009 CT#46 Upgraded unchanged from Rel-8 9.0.0 Mar 2010 CT#47 CP-100033 0143 1 IP-SM-GW UE reachability handling over Sh 9.1.0 Mar 2010 CT#47 CP-100048 0144 1 Sh handling of T-ADS 9.1.0 Mar 2010 CT#47 CP-100206 0148 3 EPS Subcsriber State and Location Information Request 9.1.0 Jun 2010 CT#48 CP-100275 0149 EPS state and location retrieval 9.2.0 Jun 2010 CT#48 CP-100279 0154 1 9.2.0 Sep 2010 CT#49 CP-100447 0157 1 Correction to the Value of Data-Reference AVP 9.3.0 Sep 2010 CT#49 CP-100454 0160 1 Correction on Requested-Domain 9.3.0 Sep 2010 CT#49 CP-100466 0158 2 Usage of IMSI and IMPI for user identification over Sh 10.0.0 Sep 2010 CT#49 CP-100466 0159 3 Location data including only serving node address 10.0.0 Sep 2010 CT#49 CP-100466 0163 3 Update-Eff feature 10.0.0 Dec 2010 CT#50 CP-100699 0164 2 Enhanced SRVCC 10.1.0 Mar 2011 CT#51 CP-110257 0168 2 MPS over Sh 10.2.0 Mar 2011 CT#51 CP-110075 0170 2 Retrieval of CSRN from HSS 10.2.0 Jun 2011 CT#52 CP-110370 0175 1 Pre-paging Support Indicator for CSRN 10.3.0 Jun 2011 CT#52 CP-110370 0176 1 Clarification on Notif-Eff description for SNR/SNA 10.3.0 Jun 2011 CT#52 CP-110370 0177 - Missing Repository-Data-ID AVP in PUA 10.3.0 Jun 2011 CT#52 CP-110383 0173 2 Reference Location over Sh interface 11.0.0 Dec 2011 CT#54 CP-110781 0189 - Correction on Wildcarded Public Identity 11.1.0 Mar 2012 CT#55 CP-120035 0194 2 Update of Multiple Data Instances in Sh-Update 11.2.0 Jun 2012 CT#56 CP-120240 0195 3 Local Time for NPLI 11.3.0 Sep 2012 CT#57 CP-120481 0197 A-MSISDN handling over Sh 11.4.0 Sep 2012 CT#57 CP-120481 0198 1 Local Time Zone 11.4.0 Dec 2012 CT#58 CP-120743 0202 1 EPS LocationInformation Support 11.5.0 Mar 2013 CT#59 CP-130020 0208 1 PS Location Info request with RAT-type 11.6.0 Mar 2013 CT#59 CP-130020 0210 1 Pre-paging-Supported and Local-Time-Zone-Indication AVPs 11.6.0 Mar 2013 CT#59 CP-130031 0200 1 Sh IMSI retrieval 12.0.0 Jun 2013 CT#60 CP-130374 0211 1 MTRR on Sh 12.1.0 Mar 2014 CT#63 CP-140027 0214 1 Multiple notification due to the Update-Eff feature 12.2.0 Jun 2014 CT#64 CP-140262 0217 - Private User Identity retrieval 12.3.0 Jun 2014 CT#64 CP-140262 0218 - UE Reachability for IP 12.3.0 Sep 2014 CT#65 CP-140515 0219 - Session-Priority reference 12.4.0 Sep 2014 CT#65 CP-140509 0220 1 Diameter Overload Control Over Sh 12.4.0 Dec 2014 CT#66 CP-140773 0222 - M-bit clarification 12.5.0 Dec 2014 CT#66 CP-140779 0223 - Retrieval of TWAN-Id over Sh 12.5.0 Dec 2014 CT#66 CP-140790 0224 - DOIC reference update 12.5.0 Dec 2015 CT#70 CP-150759 0226 1 Update reference to DOIC new IETF RFC 12.6.0 Dec 2015 CT#70 CP-150849 0227 4 Support of the DRMP AVP over Sh/Dh 13.0.0 2016-09 CT#73 CP-160431 0228 1 Request to update data while a previous update request is in progress 14.0.0 2016-12 CT#74 CP-160649 0236 1 RAT type included in EPS location information 14.1.0 2016-12 CT#74 CP-160681 0237 1 Load Control 14.1.0 2016-12 CT#74 CP-160664 0239 1 Correction to change IETF drmp draft version to official RFC 7944 14.1.0 2017-03 CT#75 CP-170035 0241 - Notif-Eff feature description correction 14.2.0 2017-03 CT#75 CP-170035 0245 1 UDR flag description 14.2.0 2017-03 CT#75 CP-170048 0243 1 Update of reference for the Diameter base protocol 14.2.0 2017-03 CT#75 CP-170048 0244 - Cardinality of the Failed-AVP AVP in answer 14.2.0 2017-06 CT#76 CP-171018 0248 1 Support for signaling transport level packet marking 14.3.0 2017-06 CT#76 CP-171040 0246 1 External Identifier on Sh 15.0.0 2018-06 CT#80 CP-181131 0249 - Requested Node AMF 15.1.0 2019-09 CT#85 CP-192094 0251 2 draft-ietf-dime-load published as RFC 8583 15.2.0 2020-07 CT#88e - - - Update to Rel-16 version (MCC) 16.0.0 2020-12 CT#91e CP-203022 0253 1 Incomplete implemented CR 16.1.0 2021-03 CT#91e CP-210044 0354 - IMEISV and 5G SRVCC Capability missing in Data Reference AVP 16.2.0 2022-04 - - - - - Update to Rel-17 version (MCC) 17.0.0 3GPP TS 29.329 V17.0.0 (2022-04) 14 Release 17 3GPP 3GPP TS 29.229 V17.2.0 (2022-06) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Cx and Dx interfaces based on the Diameter protocol; Protocol details (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 6 1 Scope 7 2 References 7 3 Definitions, symbols and abbreviations 8 3.1 Definitions 8 3.2 Abbreviations 9 4 General 9 5 Use of the Diameter base protocol 9 5.1 Securing Diameter Messages 9 5.2 Accounting functionality 9 5.3 Use of sessions 9 5.4 Transport protocol 10 5.5 Routing considerations 10 5.6 Advertising Application Support 10 6 Diameter application for Cx interface 11 6.1 Command-Code values 11 6.1.1 User-Authorization-Request (UAR) Command 11 6.1.2 User-Authorization-Answer (UAA) Command 12 6.1.3 Server-Assignment-Request (SAR) Command 12 6.1.4 Server-Assignment-Answer (SAA) Command 13 6.1.5 Location-Info-Request (LIR) Command 14 6.1.6 Location-Info-Answer (LIA) Command 14 6.1.7 Multimedia-Auth-Request (MAR) Command 14 6.1.8 Multimedia-Auth-Answer (MAA) Command 15 6.1.9 Registration-Termination-Request (RTR) Command 15 6.1.10 Registration-Termination-Answer (RTA) Command 16 6.1.11 Push-Profile-Request (PPR) Command 16 6.1.12 Push-Profile-Answer (PPA) Command 17 6.2 Result-Code AVP values 17 6.2.1 Success 17 6.2.1.1 DIAMETER_FIRST_REGISTRATION (2001) 17 6.2.1.2 DIAMETER_SUBSEQUENT_REGISTRATION (2002) 17 6.2.1.3 DIAMETER_UNREGISTERED_SERVICE (2003) 17 6.2.1.4 DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED (2004) 18 6.2.1.5 Void 18 6.2.2 Permanent Failures 18 6.2.2.1 DIAMETER_ERROR_USER_UNKNOWN (5001) 18 6.2.2.2 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) 18 6.2.2.3 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003) 18 6.2.2.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) 18 6.2.2.5 DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED (5005) 18 6.2.2.6 DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED (5006) 18 6.2.2.7 DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (5007) 18 6.2.2.8 DIAMETER_ERROR_TOO_MUCH_DATA (5008) 18 6.2.2.9 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA (5009) 19 6.2.2.10 Void 19 6.2.2.11 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) 19 6.2.2.12 DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED (5012) 19 6.3 AVPs 19 6.3.0 General 19 6.3.1 Visited-Network-Identifier AVP 22 6.3.2 Public-Identity AVP 22 6.3.3 Server-Name AVP 22 6.3.4 Server-Capabilities AVP 23 6.3.5 Mandatory-Capability AVP 23 6.3.6 Optional-Capability AVP 23 6.3.7 User-Data AVP 23 6.3.8 SIP-Number-Auth-Items AVP 23 6.3.9 SIP-Authentication-Scheme AVP 23 6.3.10 SIP-Authenticate AVP 24 6.3.11 SIP-Authorization AVP 24 6.3.12 SIP-Authentication-Context AVP 24 6.3.13 SIP-Auth-Data-Item AVP 24 6.3.14 SIP-Item-Number AVP 25 6.3.15 Server-Assignment-Type AVP 25 6.3.16 Deregistration-Reason AVP 26 6.3.17 Reason-Code AVP 26 6.3.18 Reason-Info AVP 26 6.3.19 Charging-Information AVP 27 6.3.20 Primary-Event-Charging-Function-Name AVP 27 6.3.21 Secondary-Event-Charging-Function-Name AVP 27 6.3.22 Primary-Charging-Collection-Function-Name AVP 27 6.3.23 Secondary-Charging-Collection-Function-Name AVP 27 6.3.24 User-Authorization-Type AVP 27 6.3.25 Void 28 6.3.26 User-Data-Already-Available AVP 28 6.3.27 Confidentiality-Key AVP 28 6.3.28 Integrity-Key AVP 28 6.3.29 Supported-Features AVP 28 6.3.30 Feature-List-ID AVP 29 6.3.31 Feature-List AVP 29 6.3.32 Supported-Applications AVP 29 6.3.33 Associated-Identities AVP 29 6.3.34 Originating-Request AVP 29 6.3.35 Wildcarded-Public-Identity AVP 29 6.3.36 SIP-Digest-Authenticate AVP 29 6.3.37 Digest-Realm AVP 30 6.3.38 Void 30 6.3.39 Digest-Algorithm AVP 30 6.3.40 Digest-QoP AVP 30 6.3.41 Digest-HA1 AVP 30 6.3.42 Line-Identifier AVP 30 6.3.43 Wildcarded-IMPU AVP 30 6.3.44 UAR-Flags AVP 30 6.3.45 Loose-Route-Indication AVP 31 6.3.46 SCSCF-Restoration-Info AVP 31 6.3.47 Path AVP 31 6.3.48 Contact AVP 31 6.3.49 Subscription-Info AVP 31 6.3.49.1 Call-ID-SIP-Header AVP 32 6.3.49.2 From-SIP-Header AVP 32 6.3.49.3 To-SIP-Header AVP 32 6.3.49.4 Record-Route AVP 32 6.3.50 Associated-Registered-Identities AVP 32 6.3.51 Multiple-Registration-Indication 32 6.3.52 Restoration-Info AVP 32 6.3.53 Framed-IP-Address AVP 33 6.3.54 Framed-IPv6-Prefix AVP 33 6.3.55 Framed-Interface-Id AVP 33 6.3.56 Session-Priority AVP 33 6.3.57 Identity-with-Emergency-Registration AVP 33 6.3.58 Priviledged-Sender-Indication AVP 33 6.3.59 LIA-Flags 34 6.3.60 OC-Supported-Features 34 6.3.61 OC-OLR 34 6.3.62 Initial-CSeq-Sequence-Number AVP 34 6.3.63 SAR-Flags 34 6.3.64 Allowed-WAF-WWSF-Identities AVP 34 6.3.65 WebRTC-Authentication-Function-Name AVP 35 6.3.66 WebRTC-Web-Server-Function-Name AVP 35 6.3.67 DRMP AVP 35 6.3.68 Load 35 6.3.69 RTR-Flags 35 6.3.70 P-CSCF-Subscription-Info AVP 35 6.3.71 Registration-Time-Out 35 6.3.72 Alternate-Digest-Algorithm AVP 36 6.3.73 Alternate-Digest-HA1 AVP 36 6.3.74 Failed-PCSCF 36 6.3.75 PCSCF-FQDN 36 6.3.76 PCSCF-IP-Address 36 6.4 Use of namespaces 36 6.4.1 AVP codes 36 6.4.2 Experimental-Result-Code AVP values 36 6.4.3 Command Code values 36 6.4.4 Application-ID value 36 7 Special Requirements 37 7.1 Version Control 37 7.1.1 Defining a new feature 37 7.1.2 Changing the version of the interface 40 7.2 Supported features 40 7.2.1 Dynamic discovery of supported features 40 7.3 Interface versions 41 7.3.1 Discovery of supported interface versions 41 Annex A (informative): Change history 43 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope The present document defines a transport protocol for use in the IP multimedia (IM) Core Network (CN) subsystem based on Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28]. The present document is applicable to: - The Cx interface between the I-CSCF/S-CSCF and the HSS. - The Dx interface between the I-CSCF/S-CSCF and the SLF. Whenever it is possible, this document specifies the requirements for this protocol by reference to specifications produced by the IETF within the scope of Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28]. Where this is not possible, extensions to Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28] are defined within this document. 2 References The following documents contain provisions, which through reference in this text constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPPÊTSÊ29.228: ""IP Multimedia (IM) Subsystem Cx and Dx interface; signalling flows and message contents"". [2] 3GPPÊTSÊ33.210: ""3G Security; Network Domain Security; IP Network Layer Security"". [3] IETFÊRFCÊ3261: ""SIP: Session Initiation Protocol"". [4] IETFÊRFCÊ2396: ""Uniform Resource Identifiers (URI): generic syntax"". [5] Void. [6] Void. [7] IETFÊRFCÊ2234: ""Augmented BNF for syntax specifications"". [8] IETFÊRFCÊ3966: ""The tel URI for Telephone Numbers"". [9] Void. [10] Void. [11] 3GPPÊTSÊ29.329: ""Sh Interface based on the Diameter protocol; protocol details"". [12] IETFÊRFCÊ3589: ""Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5"". [13] 3GPPÊTSÊ23.003: ""Numbering, addressing and identification"". [14] Void. [15] IETFÊRFCÊ4740: ""Diameter Session Initiation Protocol (SIP) Application"". [16] 3GPPÊTSÊ29.328: ""IP Multimedia (IM) Subsystem Sh interface; Signalling flows and message contents"". [17] IETFÊRFCÊ3327: ""Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts"". [18] 3GPPÊTSÊ29.273: ""3GPP EPS AAA interfaces"". [19] IETFÊRFCÊ4005: ""Diameter Network Access Server Application"". [20] IETFÊRFCÊ4590: "" RADIUS Extension for Digest Authentication"". [21] IETFÊRFCÊ4960: ""Stream Control Transmission Protocol"". [22] IETFÊRFCÊ3162: ""RADIUS and IPv6"". [23] IETFÊRFCÊ7683: ""Diameter Overload Indication Conveyance"". [24] 3GPPÊTSÊ23.380: ""IMS Restoration Procedures"". [25] IETF draft-holmberg-sipcore-auth-id-01: ""Authorization server identity"". Editor's note: The above document cannot be formally referenced until it is published as an RFC. [26] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [27] IEFTÊRFCÊ8583: ""Diameter Load Information Conveyance"". [28] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [29] IETFÊRFCÊ7616: ""HTTP Digest Access Authentication"". 3 Definitions, symbols and abbreviations 3.1 Definitions Refer to IETFÊRFCÊ6733Ê[28] for the definitions of some terms used in this document. For the purposes of the present document, the following terms and definitions apply. Attribute-Value Pair: see IETFÊRFCÊ6733Ê[28], it corresponds to an Information Element in a Diameter message. Diameter Multimedia client: a client that implements the Diameter Multimedia application. The client is one of the communicating Diameter peers that usually initiate transactions. Examples in 3GPP are the I-CSCF and S-CSCF. Diameter Multimedia server: a server that implements the Diameter Multimedia application. A Diameter Multimedia server that also supported the NASREQ and MobileIP applications would be referred to as a Diameter server. An example of a Diameter Multimedia server in 3GPP is the HSS. Registration: SIP-registration. Server: SIP-server. User data: user profile data. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AAA Authentication, Authorization and Accounting ABNF Augmented Backus-Naur Form AVP Attribute-Value Pair CN Core Network CSCF Call Session Control Function DSCP Differentiated Services Code Point DRMP Diameter Routing Message Priority HSS Home Subscriber Server IANA Internet Assigned Numbers Authority I-CSCF Interrogating CSCF IETF Internet Engineering Task Force IMS IP Multimedia Subsystem NDS Network Domain Security RFC Request For Comments S-CSCF Serving CSCF SCTP Stream Control Transport Protocol SIP Session Initiation Protocol SLF Server Locator Function UCS Universal Character Set URL Uniform Resource Locator UTF UCS Transformation Formats WAF WebRTC Authentication Function WWSF WebRTC Web Server Function 4 General The Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and event codes specified in clauseÊ5 of this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) are unmodified. 5 Use of the Diameter base protocol With the clarifications listed in the following clauses the Diameter base protocol defined by IETFÊRFCÊ6733Ê[28] shall apply. 5.1 Securing Diameter Messages For secure transport of Diameter messages, see 3GPPÊTSÊ33.210Ê[2]. 5.2 Accounting functionality Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used on the Cx interface. 5.3 Use of sessions Both between the I-CSCF and the HSS and between the S-CSCF and the HSS, Diameter sessions are implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client does not need to send any re-authorization or session termination requests to the server. The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions. The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETFÊRFCÊ6733Ê[28]. As a consequence, the server does not maintain any state information about this session and the client does not need to send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 5.4 Transport protocol Diameter messages over the Cx and the Dx interfaces shall make use of SCTP IETFÊRFCÊ4960Ê[21]. 5.5 Routing considerations This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host. If an I-CSCF or S-CSCF knows the address/name of the HSS for a certain user, both the Destination-Realm and Destination-Host AVPs shall be present in the request. Otherwise, only the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. the SLF or a Diameter Proxy Agent (see 3GPPÊTSÊ29.228Ê[1]), based on the Diameter routing table in the client. If the next Diameter node is an SLF, then once the SLF has returned the address or the destination HSS (using Redirect-Host AVP), the redirected request to the HSS shall include both Destination-Realm and Destination-Host AVPs. If the next Diameter node is a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the destination HSS. The Diameter Proxy Agent, based on the result of this determination of the destination HSS, shall modify the Destination-Realm AVP and Destination-Host AVP of the request appropriately. The Diameter Proxy Agent shall then append a Route-Record AVP to the request and shall send the request to the destination HSS. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an I-CSCF or an S-CSCF. If the response is routed back to a Diameter Proxy Agent, the Diameter Proxy Agent shall send the response back to the I-CSCF or S-CSCF without modifying the Origin-Realm AVP and Origin-Host AVP. The response shall contain the Origin-Realm AVP set to the realm of the HSS together with the Origin-Host AVP set to the HSS that sent the response. The S-CSCF shall store the HSS realm and HSS address for each Public Identity, after the first request sent to the User Identity to HSS resolution function. Requests initiated by the HSS towards an S-CSCF shall include both Destination-Host and Destination-Realm AVPs. The HSS obtains the Destination-Host AVP to use in requests towards an S-CSCF, from the Origin-Host AVP received in previous requests from the S-CSCF. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the HSS. Destination-Realm AVP is declared as mandatory in the ABNF for all requests. 5.6 Advertising Application Support The HSS, S-CSCF and I-CSCF shall advertise support of the Diameter Multimedia Application by including the value of the application identifier (see clauseÊ6) in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The vendor identifier value of 3GPP (10415) and ETSI (13019) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. Note: The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETFÊRFCÊ6733Ê[28]. 6 Diameter application for Cx interface This clause specifies a Diameter application that allows a Diameter Multimedia server and a Diameter Multimedia client: - to exchange location information - to authorize a user to access the IMS - to exchange authentication information - to download and handle changes in the user data stored in the server The Cx interface protocol is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the Cx/Dx interface application is 16777216 (allocated by IANA). 6.1 Command-Code values This clause defines Command-Code values for this Diameter application. Every command is defined by means of the ABNF syntax IETFÊRFCÊ2234Ê[7], according to the Command Code Format (CCF) specification defined in IETFÊRFCÊ6733Ê[28]. Whenever the definition and use of an AVP is not specified in this document, what is stated in IETFÊRFCÊ6733Ê[28] shall apply. NOTE: As the Diameter commands described in this specification have been defined based on the former specification of the Diameter base protocol, the Vendor-Specific-Application-Id AVP is still listed as a required AVP (an AVP indicated as {AVP}) in the command code format specifications defined in this specification to avoid backward compatibility issues, even if the use of this AVP has been deprecated in the new specification of the Diameter base protocol (IETFÊRFCÊ6733Ê[28]). The command codes for the Cx/Dx interface application are taken from the range allocated by IANA in IETFÊRFCÊ3589Ê[12] as assigned in this specification. For these commands, the Application-ID field shall be set to 16777216 (application identifier of the Cx/Dx interface application, allocated by IANA). The following Command Codes are defined in this specification: Table 6.1.1: Command-Code values Command-Name Abbreviation Code Clause User-Authorization-Request UAR 300 6.1.1 User-Authorization-Answer UAA 300 6.1.2 Server-Assignment-Request SAR 301 6.1.3 Server-Assignment-Answer SAA 301 6.1.4 Location-Info-Request LIR 302 6.1.5 Location-Info-Answer LIA 302 6.1.6 Multimedia-Auth-Request MAR 303 6.1.7 Multimedia-Auth-Answer MAA 303 6.1.8 Registration-Termination-Request RTR 304 6.1.9 Registration-Termination-Answer RTA 304 6.1.10 Push-Profile-Request PPR 305 6.1.11 Push-Profile-Answer PPA 305 6.1.12 6.1.1 User-Authorization-Request (UAR) Command The User-Authorization-Request (UAR) command, indicated by the Command-Code field set to 300 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request the authorization of the registration of a multimedia user."
"Message Format < User-Authorization-Request> ::= < Diameter Header: 300, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } { Visited-Network-Identifier } [ User-Authorization-Type ] [ UAR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.2 User-Authorization-Answer (UAA) Command The User-Authorization-Answer (UAA) command, indicated by the Command-Code field set to 300 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the User-Authorization-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < User-Authorization-Answer> ::= < Diameter Header: 300, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Server-Name ] [ Server-Capabilities ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.3 Server-Assignment-Request (SAR) Command The Server-Assignment-Request (SAR) command, indicated by the Command-Code field set to 301 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request it to store the name of the server that is currently serving the user. Message Format <Server-Assignment-Request> ::= < Diameter Header: 301, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ User-Name ] [ OC-Supported-Features ] *[ Supported-Features ] *[ Public-Identity ] [ Wildcarded-Public-Identity ] { Server-Name } { Server-Assignment-Type } { User-Data-Already-Available } [ SCSCF-Restoration-Info ] [ Multiple-Registration-Indication ] [ Session-Priority ] [ SAR-Flags ] [ Failed-PCSCF ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.4 Server-Assignment-Answer (SAA) Command The Server-Assignment-Answer (SAA) command, indicated by the Command-Code field set to 301 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Server-Assignment-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. If Result-Code or Experimental-Result does not inform about an error, the User-Data AVP shall contain the information that the S-CSCF needs to give service to the user. Message Format <Server-Assignment-Answer> ::= < Diameter Header: 301, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ User-Name ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ User-Data ] [ Charging-Information ] [ Associated-Identities ] [ Loose-Route-Indication ] *[ SCSCF-Restoration-Info ] [ Associated-Registered-Identities ] [ Server-Name ] [ Wildcarded-Public-Identity ] [ Priviledged-Sender-Indication ] [ Allowed-WAF-WWSF-Identities ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.5 Location-Info-Request (LIR) Command The Location-Info-Request (LIR) command, indicated by the Command-Code field set to 302 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request name of the server that is currently serving the user. Message Format <Location-Info-Request> ::= < Diameter Header: 302, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ Originating-Request ] [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } [ User-Authorization-Type ] [ Session-Priority ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.6 Location-Info-Answer (LIA) Command The Location-Info-Answer (LIA) command, indicated by the Command-Code field set to 302 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Location-Info-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format <Location-Info-Answer> ::= < Diameter Header: 302, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Server-Name ] [ Server-Capabilities ] [ Wildcarded-Public-Identity ] [ LIA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.7 Multimedia-Auth-Request (MAR) Command The Multimedia-Auth-Request (MAR) command, indicated by the Command-Code field set to 303 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request security information. Message Format < Multimedia-Auth-Request > ::= < Diameter Header: 303, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Realm } [ Destination-Host ] { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } { SIP-Auth-Data-Item } { SIP-Number-Auth-Items } { Server-Name } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.8 Multimedia-Auth-Answer (MAA) Command The Multimedia-Auth-Answer (MAA) command, indicated by the Command-Code field set to 303 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Multimedia-Auth-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < Multimedia-Auth-Answer > ::= < Diameter Header: 303, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ User-Name ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Public-Identity ] [ SIP-Number-Auth-Items ] *[SIP-Auth-Data-Item ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.9 Registration-Termination-Request (RTR) Command The Registration-Termination-Request (RTR) command, indicated by the Command-Code field set to 304 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter Multimedia client in order to request the de-registration of a user. Message Format <Registration-Termination-Request> ::= < Diameter Header: 304, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Realm } { User-Name } [ Associated-Identities ] *[ Supported-Features ] *[ Public-Identity ] { Deregistration-Reason } RTR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.10 Registration-Termination-Answer (RTA) Command The Registration-Termination-Answer (RTA) command, indicated by the Command-Code field set to 304 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Registration-Termination-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format <Registration-Termination-Answer> ::= < Diameter Header: 304, PXY, 16777216 > < Session-Id > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Associated-Identities ] *[ Supported-Features ] *[ Identity-with-Emergency-Registration ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.11 Push-Profile-Request (PPR) Command The Push-Profile-Request (PPR) command, indicated by the Command-Code field set to 305 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter Multimedia client in order to update the subscription data and for SIP Digest authentication the authentication data of a multimedia user in the Diameter Multimedia client whenever a modification has occurred in the subscription data or digest password that constitutes the data used by the client. Message Format < Push-Profile-Request > ::= < Diameter Header: 305, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] [ User-Data ] [ Charging-Information ] [ SIP-Auth-Data-Item ] [ Allowed-WAF-WWSF-Identities ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.12 Push-Profile-Answer (PPA) Command The Push-Profile-Answer (PPA) command, indicated by the Command-Code field set to 305 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Push-Profile-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < Push-Profile-Answer > ::= < Diameter Header: 305, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.2 Result-Code AVP values This clause defines new result code values that must be supported by all Diameter implementations that conform to this specification. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and Result-Code AVP shall be absent. 6.2.1 Success Result codes that fall within the Success category are used to inform a peer that a request has been successfully completed. 6.2.1.1 DIAMETER_FIRST_REGISTRATION (2001) The HSS informs the I-CSCF that: - The user is authorized to register this public identity; - A S-CSCF shall be assigned to the user. 6.2.1.2 DIAMETER_SUBSEQUENT_REGISTRATION (2002) The HSS informs the I-CSCF that: - The user is authorized to register this public identity; - A S-CSCF is already assigned and there is no need to select a new one. 6.2.1.3 DIAMETER_UNREGISTERED_SERVICE (2003) The HSS informs the I-CSCF that: - The public identity is not registered but has services related to unregistered state; - A S-CSCF shall be assigned to the user. 6.2.1.4 DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED (2004) The HSS informs to the S-CSCF that: - The de-registration is completed; - The S-CSCF name is not stored in the HSS. 6.2.1.5 Void 6.2.2 Permanent Failures Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not be attempted again. 6.2.2.1 DIAMETER_ERROR_USER_UNKNOWN (5001) A message was received for a user or a wildcarded identity that is unknown. 6.2.2.2 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) A message was received with a public identity and a private identity for a user, and the server determines that the public identity does not correspond to the private identity. 6.2.2.3 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003) A query for location information is received for a public identity that has not been registered before. The user to which this identity belongs cannot be given service in this situation. 6.2.2.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) The user is not allowed to roam in the visited network. 6.2.2.5 DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED (5005) The identity has already a server assigned and the registration status does not allow that it is overwritten. 6.2.2.6 DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED (5006) The authentication scheme indicated in an authentication request is not supported. 6.2.2.7 DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (5007) The identity being registered has already the same server assigned and the registration status does not allow the server assignment type or the Public Identity type received in the request is not allowed for the indicated server-assignment-type. 6.2.2.8 DIAMETER_ERROR_TOO_MUCH_DATA (5008) The volume of the data pushed to the receiving entity exceeds its capacity. NOTE: This error code is also used in 3GPPÊTSÊ29.329Ê[11]. 6.2.2.9 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA (5009) The S-CSCF informs HSS that the received subscription data contained information, which was not recognised or supported. 6.2.2.10 Void 6.2.2.11 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) A request application message was received indicating that the origin host requests that the command pair would be handled using a feature which is not supported by the destination host. 6.2.2.12 DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED (5012) This error is used when the HSS supports the P-CSCF-Restoration-mechanism feature, but none of the user serving node(s) supports it, as described by 3GPPÊTSÊ23.380Ê[24] clauseÊ5.4. 6.3 AVPs 6.3.0 General The following table describes the Diameter AVPs defined by 3GPP for the Cx interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415) if not otherwise indicated. Table 6.3.0.1: Diameter Multimedia Application AVPs AVP Flag rules Attribute Name AVP Code Clause defined Value Type Must May Should not Must not May Encr. Visited-Network-Identifier 600 6.3.1 OctetString M, V No Public-Identity 601 6.3.2 UTF8String M, V No Server-Name 602 6.3.3 UTF8String M, V No Server-Capabilities 603 6.3.4 Grouped M, V No Mandatory-Capability 604 6.3.5 Unsigned32 M, V No Optional-Capability 605 6.3.6 Unsigned32 M, V No User-Data 606 6.3.7 OctetString M, V No SIP-Number-Auth-Items 607 6.3.8 Unsigned32 M, V No SIP-Authentication-Scheme 608 6.3.9 UTF8String M, V No SIP-Authenticate 609 6.3.10 OctetString M, V No SIP-Authorization 610 6.3.11 OctetString M, V No SIP-Authentication-Context 611 6.3.12 OctetString M, V No SIP-Auth-Data-Item 612 6.3.13 Grouped M, V No SIP-Item-Number 613 6.3.14 Unsigned32 M, V No Server-Assignment-Type 614 6.3.15 Enumerated M, V No Deregistration-Reason 615 6.3.16 Grouped M, V No Reason-Code 616 6.3.17 Enumerated M, V No Reason-Info 617 6.3.18 UTF8String M, V No Charging-Information 618 6.3.19 Grouped M, V No Primary-Event-Charging-Function-Name 619 6.3.20 DiameterURI M, V No Secondary-Event-Charging-Function-Name 620 6.3.21 DiameterURI M, V No Primary-Charging-Collection-Function-Name 621 6.3.22 DiameterURI M, V No Secondary-Charging-Collection-Function-Name 622 6.3.23 DiameterURI M, V No User-Authorization-Type 623 6.3.24 Enumerated M, V No User-Data-Already-Available 624 6.3.26 Enumerated M, V No Confidentiality-Key 625 6.3.27 OctetString M, V No Integrity-Key 626 6.3.28 OctetString M, V No Supported-Features 628 6.3.29 Grouped V M No Feature-List-ID 629 6.3.30 Unsigned32 V M No Feature-List 630 6.3.31 Unsigned32 V M No Supported-Applications 631 6.3.32 Grouped V M No Associated-Identities 632 6.3.33 Grouped V M No Originating-Request 633 6.3.34 Enumerated M,V No Wildcarded-Public-Identity 634 6.3.35 UTF8String V M No SIP-Digest-Authenticate 635 6.3.36 Grouped V M No Digest-Realm 104 NOTE 3 6.3.37 UTF8String M V No Digest-Algorithm 111 NOTE 3 6.3.39 UTF8String M V No Digest-QoP 110 NOTE 3 6.3.40 UTF8String M V No Digest-HA1 121 NOTE 3 6.3.41 UTF8String M V No UAR-Flags 637 6.3.44 Unsigned32 V M No Loose-Route-Indication 638 6.3.45 Enumerated V M No SCSCF-Restoration-Info 639 6.3.46 Grouped V M No Path 640 6.3.47 OctetString V M No Contact 641 6.3.48 OctetString V M No Subscription-Info 642 6.3.49 Grouped V M No Call-ID-SIP-Header 643 6.3.49.1 OctetString V M No From-SIP-Header 644 6.3.49.2 OctetString V M No To-SIP-Header 645 6.3.49.3 OctetString V M No Record-Route 646 6.3.49.4 OctetString V M No Associated-Registered-Identities 647 6.3.50 Grouped V M No Multiple-Registration-Indication 648 6.3.51 Enumerated V M No Restoration-Info 649 6.3.52 Grouped V M No Session-Priority 650 6.3.56 Enumerated V M No Identity-with-Emergency-Registration 651 6.3.57 Grouped V M No Priviledged-Sender-Indication 652 6.3.58 Enumerated V M No LIA-Flags 653 6.3.59 Unsigned32 V M No OC-Supported-Features 621 NOTE 4 6.3.60 Grouped M, V No OC-OLR 623 NOTE 4 6.3.61 Grouped M, V No Initial-CSeq-Sequence-Number 654 6.3.62 Unsigned32 V M No SAR-Flags 655 6.3.63 Unsigned32 V M No Allowed-WAF-WWSF-Identities 656 6.3.64 Grouped V M No WebRTC-Authentication-Function-Name 657 6.3.65 UTF8String V M No WebRTC-Web-Server-Function-Name 658 6.3.66 UTF8String V M No DRMP 301 NOTE 5 6.3.67 Enumerated M, V No Load NOTE 6 6.3.68 Grouped M, V No RTR-Flags 659 6.3.69 Unsigned32 V M No P-CSCF-Subscription-Info 660 6.3.70 Grouped V M No Registration-Time-Out 661 6.3.71 Time V M No Alternate-Digest-Algorithm 662 NOTEÊ7 6.3.72 UTF8String V M No Alternate-Digest-HA1 663 NOTEÊ7 6.3.73 UTF8String V M No Failed-PCSCF 664 6.3.74 Grouped V M No PCSCF-FQDN 665 6.3.75 DiameterIdentity V M No PCSCF-IP-Address 666 6.3.76 Address V M No NOTE 1: The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETFÊRFCÊ6733Ê[28]. NOTE 1a: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. NOTE 2: Depending on the concrete command. NOTE 3: The value of these attributes is defined in IETFÊRFCÊ4590Ê[20]. NOTE 4: The value of these attributes is defined in IETFÊRFCÊ7683Ê[23]. NOTE 5: The value of this attribute is defined in IETFÊRFCÊ7944Ê[26]. NOTE 6: The value of this attribute is defined in IEFTÊRFCÊ8583Ê[27]. NOTEÊ7: The Alternate-Digest-HA1 AVP is defined in the same way as Digest-HA1 AVP in accordance with IETFÊRFCÊ7616Ê[29]. If the Alternate-Digest-HA1 AVP is present, the Digest-HA1 AVP shall also be present and the Digest-HA1 AVP shall contain the MD5 hash. The algorithm of the Alternate-Digest-HA1 AVP shall be determined by the Alternate-Digest-Algorithm AVP. 6.3.1 Visited-Network-Identifier AVP The Visited-Network-Identifier AVP is of type OctetString. This AVP contains an identifier that helps the HSS to identify the visited network (e.g. the visited network domain name). Coding of octets is H-PLMN operator specific. The I-CSCF maps a received P-Visited-Network-ID onto an Octet String value that is consistently configured in I-CSCF and HSS to uniquely identify the visited network. 6.3.2 Public-Identity AVP The Public-Identity AVP is of type UTF8String. This AVP contains the public identity of a user in the IMS. The syntax of this AVP corresponds either to a SIP URL (with the format defined in IETFÊRFCÊ3261Ê[3] and IETFÊRFCÊ2396Ê[4]) or a TEL URL (with the format defined in IETFÊRFCÊ3966Ê[8]). Both SIP URL and TEL URL shall be in canonical form, as described in 3GPPÊTSÊ23.003Ê[13]. 6.3.3 Server-Name AVP The Server-Name AVP is of type UTF8String. This AVP contains a SIP-URL (as defined in IETFÊRFCÊ3261Ê[3] and IETFÊRFCÊ2396Ê[4]), used to identify a SIP server (e.g. S-CSCF name). 6.3.4 Server-Capabilities AVP The Server-Capabilities AVP is of type Grouped. This AVP contains information to assist the I-CSCF in the selection of an S-CSCF. AVP format Server-Capabilities ::= <AVP header: 603 10415> *[Mandatory-Capability] *[Optional-Capability] *[Server-Name] *[AVP] 6.3.5 Mandatory-Capability AVP The Mandatory-Capability AVP is of type Unsigned32. Each value included in this AVP can be used to represent a single determined mandatory capability or a set of capabilities of an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1] (clauseÊ6.7). 6.3.6 Optional-Capability AVP The Optional-Capability AVP is of type Unsigned32. Each value included in this AVP can be used to represent a single determined optional capability or a set of capabilities of an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1] (clauseÊ6.7). 6.3.7 User-Data AVP The User-Data AVP is of type OctetString. This AVP contains the user data required to give service to a user. The exact content and format of this AVP is described in 3GPPÊTSÊ29.228Ê[1]. 6.3.8 SIP-Number-Auth-Items AVP The SIP-Number-Auth-Items AVP is of type Unsigned32. When used in a request, the SIP-Number-Auth-Items indicates the number of authentication vectors the S-CSCF is requesting. This can be used, for instance, when the client is requesting several pre-calculated authentication vectors. In the answer message, the SIP-Number-Auth-Items AVP indicates the actual number of SIP-Auth-Data-Item AVPs provided by the Diameter server. 6.3.9 SIP-Authentication-Scheme AVP The Authentication-Scheme AVP is of type UTF8String and indicates the authentication scheme used in the authentication of SIP messages. The following values are defined: - ""Digest-AKAv1-MD5"": it indicates IMS-AKA authentication scheme. NOTEÊ1: The S-CSCF uses the ""Digest-AKAv1-MD5"" authentication scheme towards the HSS for Digest-AKAv1 and Digest-AKAv2 versions. E.g. digest algorithms ""AKAv1-MD5"" and ""AKAv2-SHA-256"" require from the HSS the same procedures i.e. the same authentication information: random number RAND, authentication token AUTN, expected response XRES, cipher key CK and integrity key IK. NOTEÊ2: The ""AKAv1-MD5"" digest AKA algorithm is only supported for backward compatibility. - ""SIP Digest"": it indicates SIP Digest authentication scheme. - ""NASS-Bundled"": it indicates NASS Bundled authentication scheme. - ""Early IMS Security"": it indicates GPRS-IMS-Bundled authentication scheme. - ""Unknown"": it indicates that the authentication scheme to be used is unknown at this point. 6.3.10 SIP-Authenticate AVP The SIP-Authenticate AVP is of type OctetString and contains specific parts of the data portion of the WWW-Authenticate or Proxy-Authenticate SIP headers that are to be present in a SIP response. It shall contain, binary encoded, the concatenation of the authentication challenge RAND and the token AUTN. See 3GPPÊTSÊ33.203Ê[3] for further details about RAND and AUTN. The Authentication Information has a fixed length of 32 octets; the 16 most significant octets shall contain the RAND, the 16 least significant octets shall contain the AUTN. 6.3.11 SIP-Authorization AVP The SIP-Authorization AVP is of type OctetString and contains specific parts of the data portion of the Authorization or Proxy-Authorization SIP headers suitable for inclusion in a SIP request. When included in an Authentication Request, it shall contain the concatenation of RAND, as sent to the terminal, and AUTS, as received from the terminal. RAND and AUTS shall both be binary encoded. See 3GPPÊTSÊ33.203Ê[3] for further details about RAND and AUTS. The Authorization Information has a fixed length of 30 octets; the 16 most significant octets shall contain the RAND, the 14 least significant octets shall contain the AUTS. When included in an Authentication Request Response, it shall contain, binary encoded, the expected response XRES. See 3GPPÊTSÊ33.203Ê[3] for further details about XRES. 6.3.12 SIP-Authentication-Context AVP The SIP-Authentication-Context AVP is of type OctectString. 6.3.13 SIP-Auth-Data-Item AVP The SIP-Auth-Data-Item is of type Grouped, and contains the authentication and/or authorization information for the Diameter client. AVP format SIP-Auth-Data-Item :: = < AVP Header : 612 10415 > [ SIP-Item-Number ] [ SIP-Authentication-Scheme ] [ SIP-Authenticate ] [ SIP-Authorization ] [ SIP-Authentication-Context ] [ Confidentiality-Key ] [ Integrity-Key ] [ SIP-Digest-Authenticate ] [ Framed-IP-Address ] [ Framed-IPv6-Prefix ] [ Framed-Interface-Id ] *Ê[ Line-Identifier ] *Ê[AVP] 6.3.14 SIP-Item-Number AVP The SIP-Item-Number AVP is of type Unsigned32. 6.3.15 Server-Assignment-Type AVP The Server-Assignment-Type AVP is of type Enumerated, and indicates the type of server update, request or notification being performed in a Server-Assignment-Request operation. The following values are defined: NO_ASSIGNMENT (0) This value is used to request from HSS the user profile assigned to one or more public identities and to retrieve the S-CSCF restoration information for a registered Public User Identity, without affecting the registration state of those identities. REGISTRATION (1) The request is generated as a consequence of a first registration of an identity. RE_REGISTRATION (2) The request corresponds to the re-registration of an identity or update of the S-CSCF Restoration Information. UNREGISTERED_USER (3) The request is generated in the following cases: - The S-CSCF received a request for a Public Identity that is not registered, or - An AS sent an originating request on behalf of a Public Identity that is not registered, or - The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with only one Private User Identity and started the P-CSCF Restoration procedure including the P-CSCF Restoration Indication in the request to the HSS. TIMEOUT_DEREGISTRATION (4) The SIP registration timer of an identity has expired. USER_DEREGISTRATION (5) The S-CSCF has received a user initiated de-registration request. TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) The request is generated in the following cases: The SIP registration timer of an identity has expired. The S-CSCF keeps the user data stored in the S-CSCF and requests HSS to store the S-CSCF name. The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with only one Private User Identity and started the PCRF-based P-CSCF Restoration procedure. USER_DEREGISTRATION_STORE_SERVER_NAME (7) The S-CSCF has received a user initiated de-registration request. The S-CSCF keeps the user data stored in the S-CSCF and requests HSS to store the S-CSCF name. ADMINISTRATIVE_DEREGISTRATION (8) The request is generated in the following cases: - The S-CSCF, due to administrative reasons or network issues, has performed the de-registration of an identity. - The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with more than one Private User Identity and started the P-CSCF Restoration procedure including the P-CSCF Restoration Indication in the request to the HSS. The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with more than one Private User Identity and started the PCRF-based P-CSCF Restoration procedure. AUTHENTICATION_FAILURE (9) The authentication of a user has failed. AUTHENTICATION_TIMEOUT (10) The authentication timeout has occurred. DEREGISTRATION_TOO_MUCH_DATA (11) The S-CSCF has requested user profile information from the HSS and has received a volume of data higher than it can accept. AAA_USER_DATA_REQUEST (12) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. PGW_UPDATE (13) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. RESTORATION (14) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. 6.3.16 Deregistration-Reason AVP The Deregistration-Reason AVP is of type Grouped, and indicates the reason for a de-registration operation. AVP format Deregistration-Reason :: = < AVP Header : 615 10415 > { Reason-Code } [ Reason-Info ] *Ê[AVP] 6.3.17 Reason-Code AVP The Reason-Code AVP is of type Enumerated, and defines the reason for the network initiated de-registration. The following values are defined: PERMANENT_TERMINATION (0) NEW_SERVER_ASSIGNED (1) SERVER_CHANGE (2) REMOVE_S-CSCF (3) The detailed behaviour of the S-CSCF is defined in 3GPPÊTSÊ29.228Ê[1]. 6.3.18 Reason-Info AVP The Reason-Info AVP is of type UTF8String, and contains textual information to inform the user about the reason for a de-registration. 6.3.19 Charging-Information AVP The Charging-Information is of type Grouped, and contains the addresses of the charging functions. AVP format Charging-Information :: = < AVP Header : 618 10415 > [ Primary-Event-Charging-Function-Name ] [ Secondary-Event-Charging-Function-Name ] [ Primary-Charging-Collection-Function-Name ] [ Secondary-Charging-Collection-Function-Name ] *[ AVP] 6.3.20 Primary-Event-Charging-Function-Name AVP The Primary-Event-Charging-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Primary Online Charging Function. The receiving network element shall extract the FQDN of the DiameterURI in this AVP and may use it as content of the Destination-Host AVP for the Diameter accounting requests. The parent domain of the FQDN in the DiameterURI shall be used as Destination-Realm. The number of labels used for the Destination-Realm shall be determined before the Charging Information is provisioned and may be a configuration option. NOTE: A FQDN is an absolute domain name including a subdomain and its parent domain. The subdomain and the parent domain contain one or more labels separated by dots. 6.3.21 Secondary-Event-Charging-Function-Name AVP The Secondary-Event-Charging-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Secondary Online Charging Function. The Destination-Host and Destination-Realm values for the Diameter accounting requests should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.22 Primary-Charging-Collection-Function-Name AVP The Primary-Charging-Collection-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Primary Charging Data Function. The Destination-Host and Destination-Realm values for the Diameter accounting requests should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.23 Secondary-Charging-Collection-Function-Name AVP The Secondary-Charging-Collection-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Secondary Charging Data Function. The Destination-Host and Destination-Realm for the Diameter accounting requests values should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.24 User-Authorization-Type AVP The User-Authorization-Type AVP is of type Enumerated, and indicates the type of user authorization being performed in a User Authorization operation, i.e. UAR command. The following values are defined: REGISTRATION (0) This value is used in case of the initial registration or re-registration. I-CSCF determines this from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is not equal to zero. This is the default value. DE_REGISTRATION (1) This value is used in case of the de-registration. I-CSCF determines this from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is equal to zero. REGISTRATION_AND_CAPABILITIES (2) This value is used when the I-CSCF explicitly requests S-CSCF capability information from the HSS. The I-CSCF shall use this value when the user's current S-CSCF, which is stored in the HSS, cannot be contacted and a new S-CSCF needs to be selected 6.3.25 Void 6.3.26 User-Data-Already-Available AVP The User-Data-Already-Available AVP is of type Enumerated, and indicates to the HSS whether or not the S-CSCF already has the part of the user profile that it needs to serve the user. The following values are defined: USER_DATA_NOT_AVAILABLE (0) The S-CSCF does not have the data that it needs to serve the user. USER_DATA_ALREADY_AVAILABLE (1) The S-CSCF already has the data that it needs to serve the user. 6.3.27 Confidentiality-Key AVP The Confidentiality-Key is of type OctetString, and contains the Confidentiality Key (CK). 6.3.28 Integrity-Key AVP The Integrity-Key is of type OctetString, and contains the Integrity Key (IK). 6.3.29 Supported-Features AVP The Supported-Features AVP is of type Grouped. If this AVP is present it may inform the destination host about the features that the origin host supports for the application. The Feature-List AVP contains a list of supported features of the origin host. The Vendor-Id AVP and the Feature-List-ID AVP shall together identify which feature list is carried in the Supported-Features AVP for the Application-ID present in the command header. Where a Supported-Features AVP is used to identify features that have been defined by 3GPP, the Vendor-Id AVP shall contain the vendor ID of 3GPP. Vendors may define proprietary features, but it is strongly recommended that the possibility is used only as the last resort. Where the Supported-Features AVP is used to identify features that have been defined by a vendor other than 3GPP, it shall contain the vendor ID of the specific vendor in question. If there are multiple feature lists defined by the same vendor and the same application, the Feature-List-ID AVP shall differentiate those lists from one another. The destination host shall use the value of the Feature-List-ID AVP to identify the feature list. AVP format Supported-Features ::= < AVP header: 628 10415 > { Vendor-Id } { Feature-List-ID } { Feature-List } *[AVP] 6.3.30 Feature-List-ID AVP The Feature-List-ID AVP is of type Unsigned32 and it contains the identity of a feature list. 6.3.31 Feature-List AVP The Feature-List AVP is of type Unsigned32 and it contains a bit mask indicating the supported features of an application. When the bit set, indicates the corresponding feature is supported by the application. For the Cx application, the meaning of the bits has been defined in 7.1.1. 6.3.32 Supported-Applications AVP The Supported-Applications AVP is of type Grouped and it contains the supported application identifiers of a Diameter node. AVP format Supported-Applications ::= < AVP header: 631 10415 > *[ Auth-Application-Id ] *[ Acct-Application-Id ] *[ Vendor-Specific-Application-Id ] *[ AVP ] 6.3.33 Associated-Identities AVP The Associated-Identities AVP is of type Grouped and it contains the private user identities associated to an IMS subscription. AVP format Associated-Identities ::= < AVP header: 632, 10415 > *[ User-Name ] *[ AVP ] 6.3.34 Originating-Request AVP The Originating-Request AVP is of type Enumerated. The following value is defined: ORIGINATING (0) This value indicates to the HSS that the request is related to an AS originating SIP request in the Location-Information-Request operation. 6.3.35 Wildcarded-Public-Identity AVP The Wildcarded-Public-Identity AVP is of type UTF8String. This AVP contains a Wildcarded PSI or Wildcarded Public User Identity stored in the HSS. The syntax of the contents of this AVP is described in 3GPPÊTSÊ23.003Ê[13]. 6.3.36 SIP-Digest-Authenticate AVP The SIP-Digest-Authenticate is of type Grouped and it contains a reconstruction of either the SIP WWW-Authenticate or Proxy-Authentication header fields specified in IETFÊRFCÊ7616Ê[29]. AVP format SIP-Digest-Authenticate ::= < AVP Header: 635 10415> { Digest-Realm } Ê[ Digest-Algorithm ] { Digest-QoP } { Digest-HA1} [ Alternate-Digest-Algorithm ] [ Alternate-Digest-HA1 ] *[ AVP ] 6.3.37 Digest-Realm AVP The Digest-Realm AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.38 Void 6.3.39 Digest-Algorithm AVP The Digest-Algorithm AVP is defined in IETFÊRFCÊ4740Ê[15] and contains values as defined in IETFÊRFCÊ7616Ê[29]. NOTE: The MD5 algorithm is only supported for backward compatibility. 6.3.40 Digest-QoP AVP The Digest-QoP AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.41 Digest-HA1 AVP The Digest-HA1 AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.42 Line-Identifier AVP The Line-Identifier AVP is of type OctetString. This AVP has Vendor Id ETSI (13019) and AVP code 500. This AVP contains a fixed broadband access line identifier associated with the user. 6.3.43 Wildcarded-IMPU AVP The Wildcarded-IMPU AVP is of type UTF8String. This AVP contains a Wildcarded Public User Identity stored in the HSS. The syntax of the contents of this AVP is described in 3GPPÊTSÊ23.003Ê[13]. Note: This AVP is used by Sh interface as specified in the 3GPPÊTSÊ29.328Ê[16] and 3GPPÊTSÊ29.329Ê[11]. 6.3.44 UAR-Flags AVP The UAR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in the following table: Table 6.3.44.1: UAR-Flags Bit Name Description 0 IMS Emergency Registration This bit, when set, indicates that the request corresponds to an IMS Emergency Registration. Bits not defined in this table shall be cleared by the sending I-CSCF and discarded by the receiving HSS. 6.3.45 Loose-Route-Indication AVP The Loose-Route-Indication AVP is of type Enumerated and indicates to the S-CSCF whether or not the loose route mechanism is required to serve the registered Public User Identities. The following values are defined: LOOSE_ROUTE_NOT_REQUIRED (0) LOOSE_ROUTE_REQUIRED (1) 6.3.46 SCSCF-Restoration-Info AVP The SCSCF-Restoration-Info AVP is of type Grouped and it contains the information required for an S-CSCF to handle the requests for a user. AVP format SCSCF-Restoration-Info ::= < AVP Header: 639, 10415> { User-Name } 1*{ Restoration-Info } [ Registration-Time-Out ] [ SIP-Authentication-Scheme ] *[ AVP ] 6.3.47 Path AVP The Path AVP is of type OctetString and it contains a comma separated list of SIP proxies in the Path header as defined in IETFÊRFCÊ3327Ê[17]. 6.3.48 Contact AVP The Contact AVP is of type OctetString and it contains the Contact Addresses and Parameters in the Contact header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49 Subscription-Info AVP The Subscription-Info AVP is of type Grouped and it contains the UE's subscription information. The Contact AVP contains the Contact Address and Parameters in the Contact header of the subscription request. AVP format Subscription-Info ::= < AVP Header: 642, 10415> { Call-ID-SIP-Header } { From-SIP-Header } { To-SIP-Header } { Record-Route } {Contact} *[ AVP ] 6.3.49.1 Call-ID-SIP-Header AVP The Call-ID-SIP-Header AVP is of type OctetString and it contains the information in the Call-ID header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.2 From-SIP-Header AVP The From-SIP-Header AVP is of type OctetString and it contains the information in the From header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.3 To-SIP-Header AVP The To-SIP-Header AVP is of type OctetString and it contains the information in the To header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.4 Record-Route AVP The Record-Route AVP is of type OctetString and it contains a comma separated list of Record Route header(s) as defined in IETFÊRFCÊ3261Ê[11]. 6.3.50 Associated-Registered-Identities AVP The Associated-Registered-Identities AVP is of type Grouped and it contains the Private User Identities registered with the Public User Identity received in the request command. AVP format Associated-Registered-Identities ::= < AVP header: 647, 10415 > *[ User-Name ] *[ AVP ] 6.3.51 Multiple-Registration-Indication The Multiple-Registration-Indication AVP is of type Enumerated and indicates to the HSS whether or not the request is related to a multiple registration. The following values are defined: NOT_MULTIPLE_REGISTRATION (0) MULTIPLE_REGISTRATION (1) 6.3.52 Restoration-Info AVP The Restoration-Info AVP is of type Grouped and it contains the information related to a specific registration required for an S-CSCF to handle the requests for a user. The Contact AVP contains the Contact Address and Parameters in the Contact header of the registration request. AVP format Restoration-Info ::= < AVP Header: 649, 10415> { Path } { Contact } [ Initial-CSeq-Sequence-Number ] [ Call-ID-SIP-Header ] [ Subscription-Info ] [ P-CSCF-Subscription-Info ] *[ AVP ] 6.3.53 Framed-IP-Address AVP The Framed-IP-Address AVP is defined in IETFÊRFCÊ4005Ê[19]. 6.3.54 Framed-IPv6-Prefix AVP The Framed-IPv6-Prefix AVP is defined in IETFÊRFCÊ4005Ê[19], and it shall be encoded as defined in IETFÊRFCÊ3162Ê[22]. 6.3.55 Framed-Interface-Id AVP The Framed-Interface-Id AVP is defined in IETFÊRFCÊ4005Ê[19]. 6.3.56 Session-Priority AVP The Session-Priority AVP is of type Enumerated and indicates to the HSS the session's priority. The following values are defined: PRIORITY-0 (0) PRIORITY-1 (1) PRIORITY-2 (2) PRIORITY-3 (3) PRIORITY-4 (4) PRIORITY-0 is the highest priority. The value of the AVP when sent to the HSS is mapped from the value received by the CSCF as described in 3GPPÊTSÊ24.229 table A.162. The mapping is operator specific. This AVP may be placed as close to the Diameter header as possible in order to potentially allow optimized processing at the receiver. 6.3.57 Identity-with-Emergency-Registration AVP The Identity-with-Emergency-Registration AVP is of type Grouped and it contains a pair of private/public user identities which are emergency registered. AVP format Identity-with-Emergency-Registration ::= < AVP header: 651, 10415 > { User-Name } { Public-Identity } *[ AVP ] 6.3.58 Priviledged-Sender-Indication AVP The Priviledged-Sender-Indication AVP is of type Enumerated and indicates to the S-CSCF whether or not the Private User Identity shall be considered as a priviledged sender. The following values are defined: NOT_PRIVILEDGED_SENDER (0)PRIVILEDGED_SENDER (1) 6.3.59 LIA-Flags The LIA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.59.1. Table 6.3.59.1: LIA-Flags Bit Name Description 0 PSI Direct Routing Indication This bit, when set, indicates the request corresponds to PSI Direct Routing, what implies that HSS returns an AS name in Server-Name AVP. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving I-CSCF. 6.3.60 OC-Supported-Features The OC-Supported-Features AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[23]."
"This AVP is used to support Diameter overload control mechanism. 6.3.61 OC-OLR The OC-OLR AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[23]. This AVP is used to support Diameter overload control mechanism. 6.3.62 Initial-CSeq-Sequence-Number AVP The Initial-CSeq-Sequence-Number AVP is of type Unsigned32, and it contains the sequence number of the CSeq header field contained in the initial successful REGISTER request, as defined in IETFÊRFCÊ3261Ê[11]. 6.3.63 SAR-Flags The SAR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in the following table: Table 6.3.63.1: SAR-Flags Bit Name Description 0 P-CSCF Restoration Indication This bit, when set, indicates that the P-CSCF-Restoration-mechanism feature shall be executed, as described in 3GPPÊTSÊ23.380Ê[24], clauseÊ5.4. This AVP is optionally present only when Server-Assignment-Type takes the value ADMINISTRATIVE_DEREGISTRATION or UNREGISTERED_USER. Note: Bits not defined in this table shall be cleared by the sending S-CSCF and discarded by the receiving HSS. 6.3.64 Allowed-WAF-WWSF-Identities AVP The Allowed-WAF-WWSF-Identities AVP is of type Grouped and contains the addresses of the WAFs and WWSFs allowed for the subscription. AVP format Allowed-WAF-WWSF-Identities :: = < AVP Header : 656 10415 > *[ WebRTC-Authentication-Function-Name ] *[ WebRTC-Web-Server-Function-Name ] *[ AVP] 6.3.65 WebRTC-Authentication-Function-Name AVP The WebRTC-Authentication-Function-Name AVP is of type UTF8String and contains the address of a WAF allowed for the subscription. For the format of the string see IETF draft-holmberg-sipcore-auth-id-01Ê[25]. 6.3.66 WebRTC-Web-Server-Function-Name AVP The WebRTC-Web-Server-Function-Name AVP is of type UTF8String and contains the address of a WWSF allowed for the subscription. For the format of the string see IETF draft-holmberg-sipcore-auth-id-01Ê[25]. 6.3.67 DRMP AVP The DRMP AVP is of type Enumerated and it is defined in IETFÊRFCÊ7944Ê[26]. This AVP allows the HSS/SLF and the S-CSCF/I-CSCF to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message. 6.3.68 Load The Load AVP is of type Grouped and it is defined in IEFTÊRFCÊ8583Ê[27]. This AVP is used to support the Diameter load control mechanism. 6.3.69 RTR-Flags The RTR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.69.1. Table 6.3.69.1: RTR-Flags Bit Name Description 0 Reference Location Information change This bit, when set, indicates the request is sent due to change of Reference Location Information. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving I-CSCF. 6.3.70 P-CSCF-Subscription-Info AVP The P-CSCF-Subscription-Info AVP is of type Grouped and it contains the P-CSCF''s subscription information. The Contact AVP contains the Contact Address and Parameters in the Contact header of the subscription request. AVP format P-CSCF-Subscription-Info ::= < AVP Header: 660, 10415> { Call-ID-SIP-Header } { From-SIP-Header } { To-SIP-Header } { Contact } *[ AVP ] 6.3.71 Registration-Time-Out The Registration-Time-Out AVP is of type Time (see IETFÊRFCÊ6733Ê[28]), and contains the point of time at which the UE's registration expires. 6.3.72 Alternate-Digest-Algorithm AVP The Alternate-Digest-Algorithm AVP contains algorithm values specified in IETFÊRFCÊ7616Ê[29]. NOTE: The MD5 algorithm is only supported for backward compatibility and can only be provided within the Digest-Algorithm AVP. 6.3.73 Alternate-Digest-HA1 AVP The Alternate-Digest-HA1 AVP contains H(A1) value specified in IETFÊRFCÊ7616Ê[29]. 6.3.74 Failed-PCSCF The Failed-PCSCF AVP is of type Grouped and contains the FQDN and/or IP addresses of the failed P-CSCF. AVP format Failed-PCSCF ::= < AVP Header: 664, 10415> [ PCSCF-FQDN ] *[ PCSCF-IP-Address ] *[ AVP ] 6.3.75 PCSCF-FQDN The PCSCF-FQDN AVP is of type DiameterIdentity and contains the FQDN of the P-CSCF. 6.3.76 PCSCF-IP-Address The PCSCF-IP-Address AVP is of type Address and contains the IPv4 or IPv6 address of the P-CSCF. 6.4 Use of namespaces This clause contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA. 6.4.1 AVP codes This specification assigns the AVP values from the AVP Code namespace managed by 3GPP for its Diameter vendor-specific applications. See clauseÊ6.3 for the assignment of the namespace in this specification. 6.4.2 Experimental-Result-Code AVP values This specification has assigned Experimental-Result-Code AVP values 2001-2005 and 5001-5011. See clauseÊ6.2. 6.4.3 Command Code values This specification assigns the values 300-305 from the range allocated by IANA to 3GPP in IETFÊRFCÊ3589Ê[12]. 6.4.4 Application-ID value IANA has allocated the value 16777216 for the 3GPP Cx interface application. 7 Special Requirements 7.1 Version Control New functionality - i.e. functionality beyond the Rel-5 standard - shall be introduced by post-Rel-5 versions of this specification to the Diameter applications as follows: 1. If possible, the new functionality shall be defined optional. 2. If backwards incompatible changes can not be avoided, the new functionality should be introduced as a feature, see 7.1.1. 3. If the change would be backwards incompatible even as if it was defined as a feature, a new version of the interface shall be created by changing the application identifier of the Diameter application, see 7.1.2. 7.1.1 Defining a new feature The base functionality for the Cx is the 3GPP Rel-5 standard and a feature is an extension to that functionality. A feature is a functional entity that has a significant meaning to the operation of a Diameter application i.e. a single new parameter without a substantial meaning to the functionality of the Diameter endpoints should not be defined to be a new feature. If the support for a feature is defined mandatory in a post-Rel-5 versions of this specification, the feature concept enables interworking between Diameter endpoints regardless of whether they support all, some or none of the features of the application. Features should be defined so that they are independent from one another. The content of a feature shall be defined as a part of the specification of the affected application messages. If new AVPs are added to the commands because of the new feature, the new AVPs shall have the 'M' bit cleared and the AVP shall not be defined mandatory in the command ABNF. The support for a feature may be defined to be mandatory behaviour of a node. As an option to defining a feature, an extension to S-CSCF functionality for post-Rel-5 version may be defined as part of the list of mandatory capabilities that is used by the I-CSCF during the process of selecting an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1]. Any new feature should be taken into account in the definition of the list of mandatory and optional S-CSCF capabilities. Guidelines for the definition of S-CSCF Capabilities are described in 3GPPÊTSÊ29.228Ê[1]. The following table of features shall apply to the Cx interface. Table 7.1.1: Features of Feature-List-ID 1 used in Cx Feature bit Feature M/O Description 0 SiFC O Shared iFC sets This feature is applicable for the SAR/SAA and PPR/PPA command pairs. If both the HSS and the S-CSCF support this feature, subsets of Initial Filter Criteria may be shared by several service profiles and the HSS shall download the shared iFC sets implicitly by downloading the unique identifiers of the shared iFC sets to the S-CSCF. By means of a locally administered database, the S-CSCF then maps the downloaded identifiers onto the shared iFC sets. If the DSAI feature, as defined in 3GPPÊTSÊ29.328Ê[16], is also active with the shared iFC sets feature then the HSS shall behave as described below: If the DSAI feature is active with the shared iFC sets feature and if all the iFCs bounding to a Shared iFC set are not masked by the DSAI, the HSS shall download the unique identifier of the shared iFC set to the S-CSCF. If some iFCs or all the iFCs bounding to a shared iFC set are masked by the DSAI, the HSS shall not download the identifier of the shared iFC set. Instead the HSS shall - download the remaining non masked iFCs of the shared iFC set explicitly or - download suitable identifiers of other shared iFC sets, i.e. those covering exactly the remaining non masked iFCs and which do not contain masked iFCs or - download a combination of identifiers of shared iFC sets and explicit iFCs which cover exactly the remaining non masked iFCs. If the S-CSCF does not support this feature, the HSS shall not download identifiers of shared iFC sets. Instead as a default behavior the HSS shall (by means of a locally administered database) download the iFCs of a shared iFC set explicitly. If the HSS does not support this feature, no special default behaviour is required for the S-CSCF. Note: In using this feature option, the network operator is responsible for keeping the local databases in the S-CSCFs and HSSs consistent. 1 AliasInd M Alias Indication This feature is applicable for the SAR/SAA and PPR/PPA command pairs. If both the HSS and the S-CSCF support this feature, different aliases groups may be sent within the same service profile. Identities within the same service profile that are aliases shall be sent with identical alias group ID. If the S-CSCF does not support this feature, the HSS shall send within the service profile only those identities that are aliases. Public User Identities that are not aliases of each other shall be sent in different service profiles even if these service profiles have exactly the same Core Network Service Authorization, Initial Filter Criteria, and Shared iFC Set information and these service profiles only differ in the contained Public User Identities. This is done in order to allow backwards compatibility since part of the handling of aliases in the S-CSCF was there before this indication was required and it applied to identities that share the same service profile and implicit registration set. In this case, the S-CSCF does not provide any additional treatment of aliases than that which existed before this indication was required. If the HSS does not support this feature, no special default behaviour is required for the S-CSCF. Note: All identities included in a single SAA or PPR command are always within one implicit registration set. 2 IMSRestorationInd O IMS Restoration Indication This feature is applicable for the UAR/UAA, LIR/LIA, SAR/SAA command pairs. If both the HSS and the I-CSCF support this feature, in case the S-CSCF currently assigned in the HSS to the Public User Identity cannot be contacted the I-CSCF shall trigger the assignment of a new S-CSCF. If both the HSS and the S-CSCF support this feature, the S-CSCF shall send S-CSCF Restoration Information to the HSS. The HSS shall send this information element in SAA to the S-CSCF when required. If the S-CSCF does not support this feature, the HSS shall not send the IMS Restoration Information to the S-CSCF. 3 P-CSCF-Restoration-mechanism O HSS-based P-CSCF Restoration mechanism. This feature is applicable for the SAR/SAA command pair. If both the HSS and the S-CSCF support this feature, the S-CSCF shall send the P-CSCF-Restoration-Indication in SAR-Flags AVP to the HSS when required as described by 3GPPÊTSÊ23.380Ê[24] clauseÊ5.4. If the HSS does not support this feature, the S-CSCF shall not send the P-CSCF-Restoration-Indication to HSS. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""MOM"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. The origin host may discover the supported features of the destination host with the dynamic discovery mechanism defined in 7.2 or via local O&M interfaces. 7.1.2 Changing the version of the interface The version of an interface shall be changed by a future version of this specification only if there is no technically feasible means to avoid backwards incompatible changes to the Diameter application, i.e. to the current version of the interface. However, if the incompatible changes can be capsulated within a feature, there is no need to change the version of the interface. The versioning of an interface shall be implemented by assigning a new application identifier for the interface. This procedure is in line with the Diameter base protocol (see IETFÊRFCÊ3588) which defines that if an incompatible change is made to a Diameter application, a new application identifier shall be assigned for the Diameter application. The following table shall apply to the Cx interface, column Application identifier lists the used application identifiers on Cx and 3GPP. Table 7.1.2: Application identifiers used in Cx Application identifier First applied 16777216 3GPP Rel-5 The origin host may discover which versions of an interface the destination host supports within the capabilities exchange (i.e. CER/CEA command), via the error messages defined in the clauseÊ7.3 or via local O&M interfaces. 7.2 Supported features Features that are not indicated in the Supported-Features AVPs within a given application message shall not be used to construct that message. A request application message shall always be compliant with the list of supported features indicated in the Supported-Features AVPs within the application message. If a feature does not have an effect on constructing an application message, the message is by definition compliant with the feature. If no features are indicated in the application message, no features - i.e. no extensions to Rel-5 - shall be used to construct the application message. An answer application message shall always indicate in the Supported-Features AVPs the complete set of features supported by the sender of the answer application message. An answer application message shall be compliant with the features commonly supported by the sender of the request and answer application messages. The sender of a request application message shall discover for a given application message pair which features a destination host supports as described in 7.2.1. The discovered features of one command pair may be applicable to other command pairs within the application. Different commands within an application may support a different set of features. After discovering the features a destination host supports for a given application message pair, the sender of the request application message may store the information on the supported features of the destination host and it may use the features the destination host supports to construct the subsequent request application messages sent to the destination host. 7.2.1 Dynamic discovery of supported features When sending a request application message to a destination host whose supported features the sender does not know, the request application message shall include the Supported-Features AVP containing the set of features required to process the request and generate the answer. An exception to this is where the origin host does not use any features to construct the request application message and it is not prepared to accept an answer application message which is constructed by making use of any features. For this exception the origin host need not include the Supported-Features AVP within the message. The Supported-Features AVP within a request application message shall always have the 'M' bit set and within an answer application message the AVP shall never have the 'M' bit set. An exception to this is where the origin host does not use any supported feature to construct the request application message but is prepared to accept an answer application message which is constructed by making use of supported features. For this exception it is optional for the origin host to set the 'M' bit of the Supported-Features AVP within the request application message. On receiving a request application message, the destination host shall do one of the following: - If it supports all features indicated in the Supported-Features AVPs within the request message, the answer application message shall include Supported-Features AVPs identifying the complete set of features that it supports. The Experimental-Result-Code AVP shall not be set to DIAMETER_ERROR_FEATURE_UNSUPPORTED. - If the request application message does not contain any Supported-Features AVPs, the answer application message shall include either Supported-Features AVPs identifying the complete set of features that it supports or, if it does not support any features, no Supported-Features AVPs shall be present. The Experimental-Result-Code AVP shall not be set to DIAMETER_ERROR_FEATURE_UNSUPPORTED. - If it does not support all the features indicated in the Supported-Features AVPs with the 'M' bit set, it shall return the answer application message with the Experimental-Result-Code AVP set to DIAMETER_ERROR_FEATURE_UNSUPPORTED and it shall include also Supported-Features AVPs containing lists of all features that it supports. - If it does not support Supported-Features AVP and it receives a request application message containing Supported-Features AVPs with the 'M' bit set, it will return the answer application message with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED and a Failed-AVP AVP containing at least one Supported-Features AVP as received in the request application message. If an answer application message is received with the Experimental-Result-Code AVP set to DIAMETER_ERROR_FEATURE_UNSUPPORTED or with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED, the sender of the request application message may, based on the information in the received Supported-Features AVP or the lack of the AVP in the message, re-send the Diameter message containing only the common supported features. 7.3 Interface versions The sender of the request application message may discover which versions of an interface a destination host supports together with the capabilities exchange (i.e. CER/CEA command pair) and with error mechanisms defined to the application messages in 7.3.1. The sender of the request application message should store information on all versions of the interface the destination host supports. The sender of the request application message should use the latest common version of the application supported by the destination host to send the request. If the receiver of the request application message itself or the versions of the interface it supports are not yet known, the sender of the request application message should use the latest supported version of the interface of the Diameter peer (i.e. Diameter proxy, redirect or relay agent) discovered during the capabilities exchange. If the Diameter peer is a redirect or relay agent, which advertises the 0xffffffff as an application identifier, the sender of the request application message shall use its own latest supported version of the interface when initiating the request. 7.3.1 Discovery of supported interface versions When a Diameter agent receives a request application message and the Diameter agent doesn't find any upstream peer that would support the application identifier indicated in the request, the Diameter agent shall return the result code DIAMETER_UNABLE_TO_DELIVER and it may also return the list of the application identifiers, which are supported by the destination host of the request application message. The supported application identifiers are carried in the answer application message in the Supported-Applications grouped AVP. Message format for the answer application message (based on the RFC 3588, clauseÊ7.2) is as follows: <answer-message> ::= < Diameter Header: code, ERRÊ[PXY] > 0*1< Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Reporting-Host ] [ Proxy-Info ] [ Supported-Applications ] *Ê[ AVP ] If the receiver of a request application message does not support the application identifier indicated in the message, it shall return the result code DIAMETER_APPLICATION_UNSUPPORTED and it may also return the list of all application identifiers it supports. The supported application identifiers are carried in the Supported-Applications grouped AVP. The error message format is as specified above. If an answer application message is received with Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER or Experimental-Result-Code AVP set to DIAMETER_APPLICATION_UNSUPPORTED and the message contains the Supported-Applications AVP, the receiver of the answer application message may select, based on the information in the Supported-Applications AVP, the latest common version of the interface with the destination host and re-send the Diameter message with a structure conforming to the ABNF of that release. Annex A (informative): Change history Date TSGÊ# TSG Doc. CR# Rev Cat Subject/Comment Out Jun 2002 CN#16 NP-020265 Version 2.0.0 approved at CN#16 5.0.0 Sep 2002 CN#17 NP-020449 001 - Add a reference to the new IETFÊRFCÊon SCTP checksum 5.1.0 Sep 2002 CN#17 NP-020449 003 - Wrong format of Charging Function Addresses 5.1.0 Sep 2002 CN#17 NP-020449 005 - Editorial mistake in the definition of command MAA 5.1.0 Dec 2002 CN#18 NP-020587 006 - Addition of User-Name AVP to SAA 5.2.0 Dec 2002 CN#18 NP-020587 007 - Editorial correction of SIP-Auth-Data-Item AVP definition 5.2.0 Dec 2002 CN#18 NP-020589 008 1 Clarification of REGISTRATION_AND_CAPABILITIES value 5.2.0 Dec 2002 CN#18 NP-020588 009 - Correction in charging information 5.2.0 Dec 2002 CN#18 NP-020590 010 1 Error handling in S-CSCF when receiving too much data 5.2.0 Mar 2003 CN#19 NP-030101 012 1 Update TS 29.229 after Diameter has become RFC 5.3.0 Mar 2003 CN#19 NP-030101 015 1 Clarification on Re-allocation of S-CSCF 5.3.0 Mar 2003 CN#19 NP-030101 018 1 Handling of non supported data in the S-CSCF when the profile is being updated. 5.3.0 Mar 2003 CN#19 NP-030101 014 - Correction to the values of User-Authorizatin-Type AVP 5.3.0 Mar 2003 CN#19 NP-030101 013 - Replacement of the NAS-Session-Key AVP 5.3.0 Jun 2003 CN#20 NP-030215 019 - Conditionality of User-Name AVP in Server-Assignment-Answer 5.4.0 Sep 2003 CN#21 NP-030383 022 1 Critical Correction on the PPR command code 5.5.0 Dec 2003 CN#22 NP-030500 021 1 The S-CSCF name needs to be checked always in MAR and SAR 5.6.0 Dec 2003 CN#22 NP-030500 027 - User-Authorization-Type 5.6.0 Dec 2003 CN#22 NP-030518 029 - Clarification of inclusion of elements in Charging Information 5.6.0 Dec 2003 CN#22 Application IDs and references updated 5.6.0 Mar 2004 CN#23 NP-040055 035 - Error for no identification in SAR command 6.0.0 Jun 2004 CN#24 NP-040215 037 1 Update of the charging addresses from HSS 6.1.0 Jun 2004 CN#24 NP-040215 043 - Multimedia-Auth-Request (MAR) Command Message Format Corrections 6.1.0 Jun 2004 CN#24 NP-040215 050 2 Use of Vendor-Id by 3GPP 6.1.0 Sep 2004 CN#25 NP-040395 065 2 Application version control 6.2.0 Sep 2004 CN#25 NP-040401 056 - Optimization of User Profile Download 6.2.0 Sep 2004 CN#25 NP-040396 058 - Simplification of the User Profile Split concept 6.2.0 Sep 2004 CN#25 NP-040401 061 - Correction of the Application-Id code 6.2.0 Sep 2004 CN#25 NP-040412 063 1 Re-numbering of 3GPP specific AVP codes 6.2.0 Dec 2004 CN#26 NP-040523 070 - Cx ABNF corrections 6.3.0 Mar 2005 CN#27 NP-050030 078 2 Correction of authentication-related AVPs 6.4.0 Mar 2005 CN#27 NP-050037 079 - TEL-URI reference update 6.4.0 Mar 2005 CN#27 NP-050030 082 1 Introduction of Failed-AVP 6.4.0 Jun 2005 CT#28 CP-050086 087 - Correction of reference 6.5.0 Jun 2005 CT#28 CP-050086 089 1 Editorial corrections 6.5.0 Jun 2005 CT#28 CP-050086 088 2 Corrections to message parameters 6.5.0 Sep 2005 CT#29 CP-050440 091 2 Private identities on the Cx 6.6.0 Sep 2005 CT#29 CP-050282 093 1 Charging-Information correction 6.6.0 Sep 2005 CT#29 CP-050296 094 - Error code cleanup 6.6.0 Dec 2005 CT#30 CP-050611 095 1 Removal of overhead in Private Identities handling in RTR 6.7.0 Dec 2005 CT#30 CP-050611 098 1 Incorrect Definition of Supported-Applications AVP 6.7.0 Jan 2006 Rel-7 version was created because of ETSI TISPAN references. 7.0.0 Mar 2006 CT#31 CP-060084 0099 - Supported Features Text missing 7.1.0 Jun 2006 CT#32 CP-060302 0108 - S-CSCF reselection removal 7.2.0 Jun 2006 CT#32 CP-060308 0110 3 Definition of new Feature for Cx 7.2.0 Sep 2006 CT#33 CP-060417 0114 3 AS originating requests on behalf of a user 7.3.0 Sep 2006 CT#33 CP-060405 0118 2 Correction of discovery of supported features in Sh and Cx 7.3.0 Sep 2006 CT#33 CP-060417 0119 1 Sharing feature support information between command pairs 7.3.0 Dec 2006 CT#34 CP-060566 0124 1 Optimization of handling of Wildcarded PSIs 7.4.0 Mar 2007 CT#35 CP-070020 0125 1 M-bit in SupportedFeatures AVP 7.5.0 Sep 2007 CT#37 CP-070520 0129 - Misalignment of Mandatory Items in the MAR 7.6.0 Nov 2007 CT#38 CP-070744 0132 6 Add alias as a new feature 7.7.0 Nov 2007 CT#38 CP-070755 0130 4 Updates to 29.229 for Digest on the Cx interface 8.0.0 Mar 2008 CT#39 CP-080022 0138 2 Update 29.229 for Supporting NASS-Bundled-Authentication 8.1.0 Mar 2008 CT#39 CP-080019 0139 - SIP Digest password push 8.1.0 Mar 2008 CT#39 CP-080019 0141 2 Wildcarded Public User Identities 8.1.0 Jun 2008 CT#40 CP-080261 0145 1 Correction to the behavior of the HSS defined in the SiFC feature 8.2.0 Jun 2008 CT#40 CP-080261 0146 2 Realm and Host to be used for Charging 8.2.0 Sep 2008 CT#41 CP-080456 0149 1 Emergency Public User Identity Removal 8.3.0 Sep 2008 CT#41 CP-080460 0155 1 Support of ""Loose-Route"" indication from HSS 8.3.0 Sep 2008 CT#41 CP-080463 0156 1 Cx Impacts of IMS Restoration Procedures 8.3.0 Sep 2008 CT#41 CP-080463 0158 Add IMS Restoration as a new feature 8.3.0 Sep 2008 CT#41 CP-080463 0159 1 Addition of Registered Private Identities in SAA 8.3.0 Sep 2008 CT#41 CP-080460 0160 1 Add Assigned S-CSCF name to SAA 8.3.0 Dec 2008 CT#42 CP-080708 0163 Removal of Digest Domain 8.4.0 Dec 2008 CT#42 CP-080708 0166 2 Diameter Proxy Agent - an alternative User Identity to HSS resolution mechanism 8.4.0 Mar 2009 CT#43 CP-090026 0167 Multiple Registrations in Registration 8.5.0 Mar 2009 CT#43 CP-090026 0168 1 Restoration Information for Multiple Registrations 8.5.0 Mar 2009 CT#43 CP-090026 0169 Update for Restoration 8.5.0 Mar 2009 CT#43 CP-090051 0170 1 Definition of Server-Assignment-Type values in Cx 8.5.0 Mar 2009 CT#43 CP-090028 0171 Support for GPRS IMS Bundled Authentication (GIBA) in Cx 8.5.0 Mar 2009 CT#43 CP-090025 0172 Use of canonical form for SIP URI/tel URI in Cx interface 8.5.0 Mar 2009 CT#43 CP-090026 0175 1 Comma separated list for Path, Contact and Record-Route AVPs 8.5.0 Jun 2009 CT#44 CP-090484 0176 2 Contact storage in reg event subscription 8.6.0 Jun 2009 CT#44 CP-090303 0177 1 Comma separated list for path AVP 8.6.0 Sep CT#45 CP-090526 0181 Dx over SCTP 8.7.0 Dec 2009 CT#46 CP-090784 0182 2 SIP Digest AVP Flag Settings 8.8.0 Dec 2009 CT#46 CP-090781 0185 1 Unregistered user clarification 8.8.0 Dec 2009 CT#46 CP-090778 0188 2 Session-Priority AVP 8.8.0 Dec 2009 CT#46 CP-091030 0189 Validity of Feature Bit Value in Feature-List AVP 8.8.0 Dec 2009 CT#46 Upgraded unchanged from Rel-8 9.0.0 Mar 2010 CT#47 CP-100239 0195 1 Wildcarded Public Identity 9.1.0 Mar 2010 CT#47 CP-100031 0199 Wildcarded Public Identities handling 9.1.0 Jun 2010 CT#48 CP-100412 0205 1 Digest AVPs wrongly defined 9.2.0 Sep 2010 CT#49 CP-100447 0207 2 Wildcarded Identities handling 9.3.0 Sep 2010 CT#49 CP-100442 0209 2 Mandatory and optional capabilities handling 9.3.0 Sep 2010 CT#49 CP-100442 0212 Reference to SCTP IETFÊRFCÊobsolete 9.3.0 Sep 2010 CT#49 CP-100463 0213 2 Restoration Data Backup 9.3.0 Sep 2010 CT#49 CP-100447 0216 Encoding of Framed-IPv6-Prefix AVP 9.3.0 2011-03 - - - - Update to Rel-10 version (MCC) 10.0.0 Jun 2011 CT#52 CP-110349 0224 2 Handling of RTR for Emergency Registration 10.1.0 Jun 2011 CT#52 CP-110349 0227 Error in assignment type for backward compatibility scenarios 10.1.0 Jun 2011 CT#52 CP-110349 0230 User-Authorization-Type AVP error in description 10.1.0 Sep 2011 CT#53 CP-110566 0233 1 Priviledged sender 10.2.0 Dec 2011 CT#54 CP-110781 0240 1 Restoration of Wildcarded-IMPU AVP 10.3.0 Dec 2011 CT#54 CP-110812 0235 2 Server Assignment Type AVP definition 11.0.0 Sep 2012 CT#57 CP-120440 0247 1 Emergency registrations do not affect registration status 11.1.0 Dec 2012 CT#58 CP-120743 0251 2 PSI direct routing with restoration procedures 11.2.0 Mar 2013 CT#59 CP-130011 0258 1 Originating-request AVP in LIR 11.3.0 Jun 2013 CT#60 CP-130374 0260 1 Supported-Feature AVP carries list of features specific to the Application-ID 11.4.0 Jun 2013 CT#60 CP-130380 0259 - Visited Network ID coding 12.0.0 Dec 2013 CT#62 CP-130627 0263 1 Session-Priority AVP 12.1.0 Jun 2014 CT#64 CP-140243 0264 2 Diameter Overload Control Over Cx 12.2.0 Sep 2014 CT#65 CP-140515 0265 1 T-GRUU restoration 12.3.0 Sep 2014 CT#65 CP-140506 0266 2 P-CSCF Restoration indication 12.3.0 Dec 2014 CT#66 CP-140794 0268 2 P-CSCF Restoration mechanism new feature 12.4.0 Dec 2014 CT#66 CP-140794 0270 1 P-CSCF Restoration mechanism new error 12.4.0 Dec 2014 CT#66 CP-140773 0269 - M-bit clarification 12.4.0 Mar 2015 CT#67 CP-150023 0273 1 SIP-Authentication-Scheme AVP encoding 12.5.0 Jun 2015 CT#68 CP-150261 0274 - SAR-Flags inclusion in SAR command 12.6.0 Sep 2015 CT#69 CP-150428 0276 1 SIP-Auth-Data-Item sub AVPs clarifications 12.7.0 Sep 2015 CT#69 CP-150436 0275 1 Server-Assignment-Type AVP update to consider P-CSCF Restoration 12.7.0 Dec 2015 CT#70 CP-150754 0279 2 Allowed WAF and/or WWSF Identities 12.8.0 Dec 2015 CT#70 CP-150759 0281 1 Update reference to DOIC new IETF RFC 12.8.0 Dec 2015 CT#70 CP-150768 0282 2 Support of the DRMP AVP over Cx/Dx 13.0.0 2016-12 CT#74 CP-160664 0284 1 Correction to change IETF drmp draft version to official RFC 7944 13.1.0 2016-12 CT#74 CP-160681 0283 1 Load Control 14.0.0 2017-03 CT#75 CP-170048 0285 1 Update of reference for the Diameter base protocol 14.1.0 2017-03 CT#75 CP-170048 0286 - Cardinality of the Failed-AVP AVP in answer 14.1.0 2017-06 CT#76 CP-171018 0288 1 Support for signaling transport level packet marking 14.2.0 2018-06 CT#80 - - - Update to Rel-15 version (MCC) 15.0.0 2019-03 CT#83 CP-190035 0289 1 Reference Location Information change 15.1.0 2019-09 CT#85 CP-192094 0293 2 draft-ietf-dime-load published as RFC 8583 15.2.0 2019-09 CT#85 CP-192125 0291 - Add P-CSCF subscription info to Restoration information 16.0.0 2019-12 CT#86 CP-193040 0294 - S-CSCF restoration after registration timer expiry 16.1.0 2020-06 CT#88e CP-201053 0295 - Support of PCRF-based P-CSCF restoration 16.2.0 2021-12 CT#94e CP-213104 0297 - B Update of SIP Digest Access Authentication 17.0.0 2022-03 CT#95e CP-220052 0300 - F Reference identity for RFC 7616 17.1.0 2022-03 CT#95e CP-220052 0301 2 B Support of the hash value for alternate SIP Digest algorithm 17.1.0 2022-03 CT#95e CP-220054 0298 - B Failed P-CSCF 17.1.0 2022-06 CT#96 CP-221041 0303 - F IMS authentication using AKAv2-SHA-256 digest AKA algorithm 17.2.0 3GPP TS 29.229 V17.2.0 (2022-06) 14 Release 17 3GPP ................. 7...................... 7.......................... 8.......... 9 eoTCAP Format 7 Reference Manual MC versions: 8.0.1 Last update: 2021-06-25 Document revision: 8.0 Revision History Revision Last update Description 1.0 2019-02-06 This Format Reference Manual released for eoTCAP format 7.0. 2.0 2019-04-03 Updated filling Rule of the following fields: - Data Record Type (#111, #113), section 5.2.1.4 Common - Data Record Type - MAP Ð Number of MO SMS, section 5.2.8.2 - MAP Ð MO SMS Success, section 5.2.8.3 - MAP Ð Number of MT SMS, section 5.2.8.4 - MAP Ð MT SMS Success, section 5.2.8.5 Updated filling rule of the fields #111 and #113 in Data Record Type, section 5.2.1.4 Common - Data Record Type 3.0 2019-08-07 Removed filling rules for field description. Updated sections: á5 DR File Structure á5.2.5 CAP Fields áAdded Operator Country Code in section 6.3OperatorE212 6.1 CellAdded section 4 DR File Exchange protocol 4.0 2019-10-25 Description improved for the Common - Success field. 5.0 2020-01-08 Updated sections 3.1.1.8 Common - First Leg Destination Point Code, 3.1.1.17 Common Ð Last Leg Originating Point Code and 3.1.1.18 Common - Last Leg Destination Point Code. ÒMCLS TableÓ column added at Chapter 3 DR Format. 6.0 2020-10-22 Added the following generations to sect. 2.2 List of Generations: - eoTCAP-CAP-DeDup - eoTCAP-INAP-DeDup Updated table in sect. 4.1 Cell Updated sect. 3.2.7.1 Common Ð Success 7.0 2020-11-18 Updated MCLS Cell table in section 4.1 Cell. 8.0 2021-06-25 Updated sections: á 3.2.7.6 Common - Length of SCCP FWD Messages á 3.2.7.7 Common - Length of SCCP BWD Messages á 3.2.7.10 Common - Number of SCCP BWD Messages á 3.2.8.2 MAP Ð Number of MO SMS á 3.2.8.3 MAP Ð MO SMS Success á 3.2.8.4 MAP - Number of MT SMS á 3.2.8.5 MAP Ð MT SMS Success ©2021 Anritsu. All Rights Reserved. Specifications subject to change without notice. Table of Contents ..................................................................................................... 6 1 Introduction ................................................................................................................ 6 List of compatible FIDs Differences with respect to previous eoTCAP 6.0 version References 2 eoTCAP DR Content ..................................................................................................... 8 Scenario List of Generations 2.2.1 eoTCAP-CAP ...................................................................................................................................... 9 2.2.2 eoTCAP-CAP-DeDup ........................................................................................................................ 10 2.2.3 eoTCAP-MAP................................................................................................................................... 10 2.2.4 eoTCAP-INAP .................................................................................................................................. 10 2.2.5 eoTCAP-INAP-DeDup ...................................................................................................................... 11 2.2.6 eoTCAP-AP ...................................................................................................................................... 11 2.2.7 eoTCAP-OP ...................................................................................................................................... 11 2.2.8 eoTCAP-BELL-800 ............................................................................................................................ 11 2.2.9 eoTCAP-BELL-AIN ............................................................................................................................ 11 2.2.10 eoTCAP-BELL-LIDB .......................................................................................................................... 11 2.2.11 eoTCAP-MAP-E2E-SMS ................................................................................................................... 11 DR File Structure ........................................................................................................ 13 DR Format ..................................................................................................................... 13 eoTCAP DR Fields Description ........................................................................................ 41 Common Fields ............................................................................................................................... 41 WHITE TCAP Fields .......................................................................................................................... 81 BELL TCAP Fields ........................................................................................................................... 102 MAP Fields .................................................................................................................................... 110 CAP Fields ..................................................................................................................................... 122 INAP Fields .................................................................................................................................... 139 Common Measures ...................................................................................................................... 157 MAP Measures ............................................................................................................................. 170 4 MCLS Enrichments for eoLive .................................................................................. 173 Cell .............................................................................................................................. 173 Service Key .................................................................................................................. 175 Cause .......................................................................................................................... 175 OperatorE212 .............................................................................................................. 177 Device ......................................................................................................................... 180 CertifiedDevice ............................................................................................................ 181 MobileSubscriber ........................................................................................................ 182 FixedSubscriber ........................................................................................................... 183 Operator Prefix............................................................................................................ 185 IMSIPrefix .................................................................................................................... 186 ISDNPrefix ................................................................................................................... 187 Operator Signalling Point ............................................................................................. 188 5 Monitored procedures ............................................................................................ 190 6 Appendix A. Property field definition ...................................................................... 196 Binary Formats ............................................................................................................ 196 Display Format ............................................................................................................ 196 Text Format ................................................................................................................. 197 Special Property .......................................................................................................... 198 Aggregation Roles ....................................................................................................... 199 1 Introduction This document specifies the eoTCAP TDR File Structure v.7.0 generated by eoXDR server for MasterClaw eoLive, eoSearch, and eoFinder Application. This specification is based on: - MAP_CSDR on any compatible FID. MAP protocol stack is widely used in the world except in USA. - CAP_CSDR on any compatible FID. CAMEL protocol stack is widely used in the world except in USA. - INAP_CSDR on any compatible FID. - TCAP-AP_CSDR on any compatible FID. - BELL_TCAP_OP on any compatible FID. - BELL_TCAP_800 on any compatible FID. - BELL_AIN on any compatible FID. - BELL_LIDB on any compatible FID. List of compatible FIDs CSDR Format Name FID (Value) Protocol Layer CAP_CSDR_FID_693 693 CAP/CAMEL CAP_CSDR_FID_645 645 CAP/CAMEL MAP_CSDR_FID_629 629 MAP INAP_CSDR_FID_694 694 INAP INAP_CSDR_FID_646 646 INAP TCAP-AP_CSDR_FID_630 630 TCAP-AP BELLCORE_TCAP_OP_CSDR_FID_548 548 TCAP-OP BELL_TCAP_800_CSDR_FID_563 563 BELL_TCAP_800 BELLAIN_CSDR_FID_564 564 BELL_AIN BELLCORE_LIDB_CSDR_FID_567 567 BELL_LIDB Differences with respect to previous eoTCAP 6.0 version New fields Common Ð VLR Number Normalization Added field to normalize: Common Ð VLR Number Modified Fields INAP Ð Additional Error Reason (Modified Display Format) New eoTCAP DWH Dimensions VLR NUMBER References CAP_CSDR_693 CAP_CSDR_645 MAP_CSDR_FID_629 INAP_CSDR_FID_694 INAP_CSDR_FID_646 WHITE_TCAP_AP_CSDR_630 BELLCORE_TCAP_OP_CSDR_FID_548 BELL_TCAP_800_CSDR_FID_563 BELLAIN_CSDR_FID_564 BELLCORE_LIDB_CSDR_FID_567 2 eoTCAP DR Content Scenario This section provides a high level description of the DR content in terms of: á Monitored network á Monitored procedure/call/transaction Monitored Network Data is collected from links surrounding the various service elements (SCP etc.) or interconnect links. The services supported in this application are LNP, MNP LIDB, CLASS, TCAP operations, LIDB, IS41, CAP and MAP. Each stored transaction record (TDR) contains data from the lower SCCP protocol layer, the TCAP layer, and some information from the upper service application layer. Two protocol stacks are supported: - CAP/MAP/INAP (over TCAP/SCCP). - TCAP-OP (LNP, MNP LIDB, CLASS, TCAP operations, LIDB, IS41 (over TCAP/SCCP)). - TCAP-AP Monitored procedure/call/transaction The DR provides signalling data from the TCAP protocol focusing on the following procedures: á Voice Call Send Authentication Info Send Routing Info ÔandÕ Provide Roaming Number Mobile Originating Call Mobile Terminating Call á Location Update Location Cancel Location Send Routing Info For LCS Subscriber Location Report á Data Session Update GPRS Location Send Routing Info For GPRS MS Initiated PDP Context Activation NW Initiated PDP Context Activation á Short Message services Send Routing Info For SM Mobile Originating SMS Mobile Terminating SMS E2E SMS á Supplementary Services Register SS Erase SS Activate SS Deactivate SS Interrogate SS Process Unstructured SS Request Unstructured SS Request Unstructured SS Notify á INAP Services List of Generations 2.2.1 eoTCAP-CAP This generation produces data record related to CAP transactions with a one to one relation to the incoming CAP CSDRs (no correlation rules are defined). In case of MEGACSDR option enabled, the information about first and last leg will be filled in the data record. 2.2.2 eoTCAP-CAP-DeDup This generation performs a deduplication process on incoming CAP MEGACSDRs and produces a data record for each leg of the CAP transaction. The MEGACSDR option in CAP must be active in order to produce consistent results. Note: The deduplication process is intended to split only the MEGACSDR into single legs, no need to remove duplicated legs because of the following assumption: If SIGTRAN/TDM linksets around STPs are monitored on different probes, that traffic must be redirected to single probe. 2.2.3 eoTCAP-MAP This generation perform a correlation of MAP CSDRs in order to obtain a single data record with information about the first and last leg of the MAP transaction. This generation could be run: 1. On customer operator internal links only. á If routing is SPC (Signalling Point Code) based, the correlation rule is based on OTID/ LABEL_OPC and DTID /LABEL_DPC (as second look-up). á If routing is Global Title based, then the correlation rule is based on it (see option 2 below). 2. On inter-operator/international links only. OTID, GTCALLING_NO and DTID, BACKCLG_NO (as second look-up). Second look-up is applied as additional rule at same time together with 1st rule. Example, for case 1 two CSDR A and B will be correlated if: OTID/ LABEL_OPC: A.OTID=B.OTID e A.LABEL_OPC= B.LABEL_OPC Or with second lookup DTID /LABEL_DPC: A.OTID=B.DTID e A.LABEL_OPC= B.LABEL_DPC 2.2.4 eoTCAP-INAP This generation produces data record related to INAP transactions with a one to one relation to the incoming INAP CSDRs (no correlation rules are defined). In case of MEGACSDR option enabled, the information about first and last leg will be filled in the data record. 2.2.5 eoTCAP-INAP-DeDup This generation performs a deduplication process on incoming INAP MEGACSDRs and produces a data record for each leg of the INAP transaction. The MEGACSDR option in INAP must be active in order to produce consistent results."
"Note: The deduplication process is intended to split only the MEGACSDR into single legs, no need to remove duplicated legs because of the following assumption: If SIGTRAN/TDM linksets around STPs are monitored on different probes, that traffic must be redirected to single probe. 2.2.6 eoTCAP-AP This generation produces data record related to TCAP_AP transactions with a one to one relation to the incoming TCAP_AP CSDRs (no correlation rules are defined). 2.2.7 eoTCAP-OP This generation produces data record related to TCAP_OP transactions with a one to one relation to the incoming TCAP_OP CSDRs (no correlation rules are defined). 2.2.8 eoTCAP-BELL-800 This generation produces data record related to BELL_TCAP_800 transactions with a one to one relation to the incoming BELL_TCAP_800 CSDRs (no correlation rules are defined). 2.2.9 eoTCAP-BELL-AIN This generation produces data record related to BELL_AIN transactions with a one to one relation to the incoming BELL_AIN CSDRs (no correlation rules are defined). 2.2.10 eoTCAP-BELL-LIDB This generation produces data record related to BELL_LIDB transactions with a one to one relation to the incoming BELL_ LIDB CSDRs (no correlation rules are defined). 2.2.11 eoTCAP-MAP-E2E-SMS This generation performs a correlation of MAP CSDRs in order to obtain a single data record for an end to end SMS scenario (SMS submit + SMS Delivery) CSDR Filters: The First Dialogue can be any MAP Dialogue with TP_MTI=1 (SMS-SUBMIT) Correlation Keys: [First Dialogue].MSISDN=[Second Dialogue].TP_OA [First Dialogue].PAYLOAD_SZ=[Second Dialogue].PAYLOAD_SZ Time Constraints: Start Time (First Dialogue) < Start time (Second Dialogue) <= 5 minutes (First Dialogue) DR File Structure A eoTCAP DR File contains a list of eoTCAP Transaction Data Records within a time interval [start time, end time). The date and time fields of eoTCAP TDRs within the file refers to the completion time of the transaction and it is always in the interval [start time, end time). eoTCAP TDRs in the file are not ordered w.r.t any of the fields. The file format stores Data Records in a proprietary binary format. DR Format # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path COMMON FIELDS 1 Start_Date_and_time Common - Start Time BF_INTEGER 8 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Measures/Common 2 End_Date_and_time Common - End Time BF_INTEGER 8 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Measures/Common 3 LAYER_TYPE Common Ð DR Generation Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 4 DATA_RECORD_TYPE Common - Data Record Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 5 VIOLATION Common Ð Violation BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 6 TIMEOUT Common Ð Timeout BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 7 LABEL_OPC Common Ð First Leg Originating Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 8 LABEL_DPC Common - First Leg Destination Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 9 SOURCE_IP Common - First Leg Source IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 10 DESTINATION_IP Common - First Leg Destination IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 11 SOURCE_SWITCH Common - First Leg Source Network Node BF_STRING 80 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 12 SOURCE_SWITCH_ROLE Common - First Leg Source Network Node Type BF_STRING 30 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 13 DEST_SWITCH Common - First Leg Destination Network Node BF_STRING 80 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 14 DEST_SWITCH_ROLE Common - First Leg Destination Network Node Type BF_STRING 30 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 15 SOURCE_SP Common - First Leg Source Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 16 DEST_SP Common - First Leg Destination Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 17 LL_LABEL_OPC Common Ð Last Leg Originating Point Code BF_INTEGER 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 18 LL_LABEL_DPC Common - Last Leg Destination Point Code BF_INTEGER 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 19 LL_SOURCE_IP Common Ð Last Leg Source IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 20 LL_DESTINATION_IP Common Ð Last Leg Destination IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 21 LL_SOURCE_SWITCH Common - Last Leg Source Network Node BF_STRING 80 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 22 LL_SOURCE_SWITCH_ROLE Common Ð Last Leg Source Network Node Type BF_STRING 30 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 23 LL_DEST_SWITCH Common Ð Last Leg Destination Network Node BF_STRING 80 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 24 LL_DEST_SWITCH_ROLE Common Ð Last Leg Destination Network Node Type BF_STRING 30 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 25 LL_SOURCE_SP Common Ð Last Leg Source Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 26 LL_DEST_SP Common - Last Leg Destination Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 27 CALLING_NO Common - Calling Party Number BF_STRING 22 DF_DIGITS FixedSubscriber, OperatorPrefix, ISDNPrefix FixedSubscriber, OperatorPrefix, ISDNPrefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 28 CALLED_NO Common - Called Party Number BF_STRING 22 DF_DIGITS FixedSubscriber, OperatorPrefix, ISDNPrefix FixedSubscriber, OperatorPrefix, ISDNPrefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 29 PAYMENT_PLAN Common - Payment Plan BF_INTEGER 1 DF_DEC_ENUM MobileSubscriber Payment Plan AR_AGGREGABLE_ALWAYS Objects/Common 30 LINKSET_NAME Common Ð First Leg Forward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 31 LINKSET_NAME_BACKWARD Common - First Leg Backward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 32 LL_LINKSET_NAME Common - Last Leg Forward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 33 LL_LINKSET_NAME_BACKWARD Common - Last Leg Backward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 34 OTID Common Ð OTID BF_INTEGER 4 DF_HEX AR_AGGREGABLE_NEVER Objects/Common 35 DTID Common Ð DTID BF_INTEGER 4 DF_HEX AR_AGGREGABLE_NEVER Objects/Common 36 BACKCLG_NO Common - SCCP Back Calling Number BF_STRING 22 DF_DIGITS AR_AGGREGABLE_WITHFILTER Objects/Common 37 SCCP_CALLED_PARTY Common - SCCP Called Party Global Title BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/Common 38 SCCP_CALLING_PARTY Common - SCCP Calling Party Global Title BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 39 CALLED_SSN Common - Called SSN BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 40 CALLING_SSN Common - Calling SSN BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 41 SCCP_RETCAUSE Common - SCCP Return Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/Common 42 TCAP_ABORT_CAUSE Common - TCAP Abort Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/Common 43 SIO Common - Service Information Octet BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 44 SERVICE_KEY Common - Service Key BF_STRING 4 BF_STRING ServiceKey ServiceKey AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 45 CONV_TIME_INT Common Ð Conversation Time Interval BF_STRING 64 DF_STRING Conversation Time Interval Conversation Time Interval AR_AGGREGABLE_ALWAYS Objects/Common 46 IMSI Common Ð IMSI BF_STRING 16 DF_DIGITS MobileSubscriber, OperatorE212, IMSIPrefix Mobile Subscriber, Operator E212, IMSI Prefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 47 MSISDN Common Ð MSISDN BF_STRING 22 DF_DIGITS OperatorPrefix,FixedSubscriber OperatorPrefix,FixedSubscriber SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 48 IMEI Common Ð IMEI BF_STRING 16 DF_DIGITS CertifiedDevice Certified Device SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 49 TAC Common - Device TAC BF_STRING 8 DF_DIGITS Device Device SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 50 LOCATION_INFO Common - Location Information BF_STRING 20 DF_DIGITS OperatorPrefix Location Info, OperatorPrefix AR_AGGREGABLE_ALWAYS Objects/Common 51 PLMN_ID Common Ð PLMN ID BF_STRING 6 DF_STRING Operator E212 AR_AGGREGABLE_WITHRANK Objects/Common 52 SCCP_CALLING_OPC Common Ð SCCP Calling Party Number Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 53 SCCP_CALLING_SP Common Ð SCCP Calling Party Number Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 54 SCCP_CALLED_OPC Common Ð SCCP Terminating Party Number Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 55 SCCP_CALLED_SP Common Ð SCCP Called Party Number Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 56 VLR_NUMBER Common Ð VLR Number BF_STRING 22 DF_DIGITS VLR Number AR_AGGREGABLE_ALWAYS Object/Common WHITE TCAP FIELDS 101 TCAPAP_APPL_OP_CODE WHITE TCAP - Application Operation Code BF_INTEGER 2 DF_HEX_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/WHITE TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 102 TCAPAP_APPL_ERROR_CODE WHITE TCAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/WHITE TCAP BELL TCAP FIELDS 150 BTCAP_OPERATION_CODE BELL TCAP - Application Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 151 BTCAP_LAST_OPERATION_CODE BELL TCAP - Last Application Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 152 BTCAP_APPL_ERROR_CODE BELL TCAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 153 BTCAP_REJECT_PROBLEM BELL TCAP Ð Reject Problem BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 154 BTCAP_TRANSLATION_TYPE BELL TCAP Ð Translation Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 155 BTCAP_GTT_REQUESTED BELL TCAP - GTT Requested BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 156 BTCAP_TCAP_800_TERMINATION_INDICATOR BELL TCAP Ð TCAP 800 Termination Indicator BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 157 BTCAP_AINT_ERROR_CAUSE BELL TCAP Ð AIN Error Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 158 BTCAP_TCAP_OP_LINE_SERVICE_TYPE BELL TCAP Ð TCAP OP Line Service Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 159 BTCAP_LIDB_SERVICE_OR_EQUIP_INDICATOR BELL TCAP Ð LIDB Service or Equipment Indicator BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP MAP FIELDS 201 MAP_FL_OP_CODE MAP Ð First Leg Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 202 MAP_FL_ER_CODE MAP - First Leg Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 203 MAP_FL_USRERR_REASON MAP Ð First Leg Additional Error Reason BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 204 MAP_FL_TP_SCTS MAP Ð First Leg SMS Service Centre Time Stamp BF_INTEGER 4 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Objects/MAP 205 MAP_LL_OP_CODE MAP Ð Last Leg Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 206 MAP_LL_ER_CODE MAP - Last Leg Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 207 MAP_LL_USRERR_REASON MAP Ð Last Leg Additional Error Reason BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 208 MAP_LL_TP_SCTS MAP Ð Last Leg SMS Service Centre Time Stamp BF_INTEGER 4 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 209 MAP_TP_MR MAP Ð SMS Message Reference Number BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Objects/MAP 210 MAP_ABSENT_SUBSCRIBER_DIAG_SM MAP - GSM Absent Reason BF_INTEGER 4 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 211 MAP_MSRN MAP ÐMSRN BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/MAP 212 MAP_USSD_STR MAP - USSD String BF_STRING 128 DF_STRING SP_USSD AR_AGGREGABLE_WITHFILTER Objects/MAP 213 MAP_SERVCENT_ADDR MAP - Service Centre Address BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/MAP 214 MAP_SGSN_ADDRESS MAP - SGSN Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 215 MAP_GGSN_ADDRESS MAP - GGSN Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 216 MAP_H_GMLC_ADDRESS MAP - Home GMLC Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 217 MAP_V_GMLC_ADDRESS MAP - Visited GMLC Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 218 MAP_TP_OA_ALPHANUM MAP - TP Origination Address Alphanumeric BF_STRING 12 DF_STRING SMS Service SP_ ENDPOINTDETAILS AR_AGGREGABLE_WITHRANK Objects/MAP 219 MAP_TP_DA_ALPHANUM MAP - TP Destination Address Alphanumeric BF_STRING 12 DF_STRING SP_ ENDPOINTDETAILS AR_AGGREGABLE_WITHRANK Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 220 MAP_TP_MTI MAP Ð TP Message Type Indicator BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 221 MAP_SMS_DELIV_TIME_INT MAP Ð SMS Delivery Time Interval BF_STRING 64 DF_STRING SMSDeliveryTime Interval SMSDeliveryTime Interval AR_AGGREGABLE_ALWAYS Objects/MAP CAP FIELDS 301 CAP_OP_CODE CAP Ð Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 302 CAP_LAST_OPERATION CAP - Last Operation BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 303 CAP_OPERATION_MASK CAP - Operation Mask BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/CAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 304 CAP_ER_CODE CAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 305 CAP_ER_REASON CAP - Additional Error Reason BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 306 CAP_CAUSE CAP - Response Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 307 CAP_DEST_ADDRESS CAP - Destination Routing Address BF_STRING 22 DF_DIGITS Destination Address AR_AGGREGABLE_WITHFILTER Objects/CAP 308 CAP_EVENT_REPORT_CAUSE CAP - Event Report Cause BF_INTEGER 1 DF_ENUM Cause cause AR_AGGREGABLE_ALWAYS Objects/CAP 309 CAP_EVENT_TYPE_MET CAP - Event Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 310 CAP_REPORTED_EVENT CAP - Reported Event BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 311 CAP_CELL_IDENTITY CAP Ð Cell Identity BF_STRING 30 DF_STRING Cell Cell AR_AGGREGABLE_WITHRANK Objects/CAP INAP FIELDS 401 INAP_OP_CODE INAP Ð Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 402 INAP_LAST_OPERATION INAP - Last Operation BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 403 INAP_OPERATION_MASK1 INAP - Operation Mask1 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 404 INAP_OPERATION_MASK2 INAP - Operation Mask2 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 405 INAP_OPERATION_MASK3 INAP - Operation Mask3 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 406 INAP_OPERATION_MASK4 INAP - Operation Mask4 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 407 INAP_ER_CODE INAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP 408 INAP_ER_REASON INAP - Additional Error Reason BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP 409 INAP_CAUSE INAP - Response Cause BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 410 INAP_DEST_ROUT_ADDRESS INAP - Destination Routing Address BF_STRING 22 DF_DIGITS Destination Address AR_AGGREGABLE_WITHFILTER Objects/INAP 411 INAP_EVENT_TYPE_MET INAP - Event Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 412 INAP_REPORTED_EVENT INAP - Reported Event BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 413 INAP_GENERIC_NUMBER INAP - Generic Number BF_STRING 22 DF_DIGITS ISDNPrefix ISDNPrefix AR_AGGREGABLE_WITHFILTER Objects/INAP COMMON MEASURES 501 SUCCESS Common - Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 502 TRANS_TIME Common - Transaction Duration BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 503 RESPONSE_TIME Common - Response Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 504 CONV_TIME Common Ð Conversation Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 505 SCCP_MSGLEN Common - Total Length of SCCP Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 506 TX_SCCP_MSGLEN Common - Total Length of SCCP FWD Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 507 RX_SCCP_MSGLEN Common - Total Length of SCCP BWD Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 508 NUMOF_SCCPMSG Common - Number of SCCP Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 509 NUMOF_TXSCCP_MSGS Common - Number of SCCP FWD Messages BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 510 NUMOF_RXSCCP_MSGS Common - Number of SCCP BWD Messages BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 511 ANSWERED_CALL Common Ð Answered Call BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 512 DROPPED_CALL Common Ð Dropped Call BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common MAP MEASURES 601 MAP_PAYLOAD_SZ MAP - SMS Payload Size BF_INTEGER 2 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 602 MAP_NUMBER_OF_MO_SMS_MESSAGES MAP Ð Number of MO SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 603 MAP_MO_SMS_SUCC MAP Ð MO SMS Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / MAP 604 MAP_NUMBER_OF_MT_SMS_MESSAGES MAP - Number of MT SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 605 MAP_MT_SMS_SUCC MAP Ð MT SMS Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / MAP 606 MAP_NO_CONCA_SMS MAP - Number of Concatenated SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 607 MAP_SMS_SUBMIT_TIME MAP Ð SMS Submit Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / MAP 608 MAP_SMS_DELIV_TIME MAP Ð SMS Delivery Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / MAP SPECIAL FIELDS 705 Call Trace Jump N/A BF_STRING 184 N/A N/A N/A N/A TABLE 1 ATTRIBUTES OF EOTCAP TDR eoTCAP DR Fields Description Common Fields Common - Start Time Applicable Protocols: All This is the time stamp for start of the transaction. The time stamp is UTC time milli seconds since 1 Jan 1970 0:00. This field is computed using the StartTimeStmpSec and StartmsPart CSDR fields. Common - End Time Applicable Protocols: All This is the time stamp for completion of the transaction. The time stamp is UTC time milli seconds since 1 Jan 1970 0:00. Common Ð DR Generation Type Applicable Protocols: All This field is an enumerated one used to distinguish the signalling interface of the data record. It can assume the following values depending on the CSDR source: Value Exported Description 1. TCAP-AP 2. MAP 3. CAP 4. INAP 5. TCAP-OP 6. TCAP-800 Value Exported Description 7. AIN 8. LIDB 9. CAP Single Leg 10. INAP Single Leg Common - Data Record Type Applicable Protocols: All It indicates the type of procedure/activity done (or being done) by the user. CSDR Type = CAP Value Name Description 1 CAP Mobile Originating Call Mobile Originating Call 2 CAP Mobile Terminating Call Mobile Terminating Call 3 CAP Mobile Originating SMS Mobile Originating SMS 4 CAP Mobile Terminating SMS Mobile Terminating SMS 5 CAP MS Initiated PDP Context Activation MS Initiated PDP Context Activation 6 CAP NW Initiated PDP Context Activation NW Initiated PDP Context Activation 99 Other CAP procedure CSDR Type = MAP Value Name Description 100 MAP Update Location Location Update procedure is initiated by the VLR towards the HLR in order to update the subscriber location information related to the CS domain. 101 MAP Cancel Location Cancel Location procedure is initiated when the subscriber moves into another VLR area or into another PLMN. 102 MAP Provide Roaming Number MSC initiates this procedure when a mobile terminating call has to be routed towards a roamer subscriber visiting the network. 103 MAP Register SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to register data related to a supplementary service. The VLR will relay the message to the HLR. 104 MAP Erase SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a supplementary procedure. The VLR will relay the message to the HLR. 105 MAP Activate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to activate a supplementary procedure. The VLR will relay the message to the HLR. 106 MAP Deactivate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to deactivate a supplementary procedure. The VLR will relay the message to the HLR. 107 MAP Interrogate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to retrieve information related to a supplementary procedure. The VLR Value Name Description will relay the message to the HLR if necessary. 108 MAP Send Routing Info Send Routing Info procedure is initiated by the MSC/VLR towards the HLR to retrieve subscriber information related to the CS domain. 109 MAP Update GPRS Location Update GPRS Location procedure is initiated by the SGSN/VLR towards the HLR in order to update the subscriber location information related to the PS domain. 110 MAP Send Routing Info For GPRS Send Routing Info For GPRS procedure is initiated by the GGSN towards the HLR to retrieve subscriber information related to the PS domain. 111 MAP Mobile Terminating SMS Mobile Terminating SMS 112 MAP Send Routing Info For SM Send Routing Info For SM procedure is initiated by the Gateway MSC towards the HLR to retrieve information needed for routing the short message to the servicing MSC. 113 MAP Mobile Originating SMS Mobile Originating SMS 114 MAP Authentication VLR may initiate the Authentication procedure (Send Authentication Info). It is used to ensure security and deny services to unauthorized services. This procedure can be done periodically. 115 MAP Process Unstructured SS Request This procedure is used between the MSC and the VLR, between the VLR and the HLR, between the HLR and gsmSCF and between the HLR and HLR to relay information in order to allow unstructured supplementary service operation. Value Name Description 116 MAP Unstructured SS Request This procedure is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires information from the mobile user, in connection with unstructured supplementary service handling. 117 MAP Unstructured SS Notify This procedure is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires a notification to be sent to the mobile user, in connection with unstructured supplementary services handling. 118 MAP Send Routing Info For LCS Send Routing Info For LCS procedure is initiated by the GMLC towards the HLR to retrieve subscriber information related to the Location based Services. 119 MAP Subscriber Location Report Subscriber Location Report procedure is initiated by the SGSN/VLR towards the HLR to provide the GMLC the location of a subscriber. 120 MAP Ð Correlated SMS 199 Other MAP procedure CSDR Type = INAP Value Name Description 200 INAP Initial DP 201 INAP Retrieve/Assist Request Instructions 299 Other INAP procedure CSDR Type = TCAP-AP Value Name Description 300 TCAP-AP traffic CSDR Type =BELL TCAP-OP Value Name Description 400 TCAP OP Query (CNAM Service) CSDR Type = BELL TCAP-800 Value Name Description 500 TCAP 800 Query (Toll Free Call) CSDR Type = BELL TCAP-800 Value Name Description 600 AIN Query CSDR Type = BELL LIDB Value Name Description 700 LIDB Query Common Ð Violation Applicable Protocols: All It indicates if the sequence contains all messages or some error condition happened. Value Name 0 No Violation 1 Missing End or Response Message 2 Only Begin or Query Message 3 Only Continue or Conversation Message Common Ð Timeout Applicable Protocols: All Timeout identifies the type of timeout that occurred during processing of the signalling data. Note that timeout field does not refer to network timeouts but refer only to the timeouts used by the network monitoring system. Value Timeout Description CAP CSDR MAP CSDR INAP CSDR WHITE_TCAP_AP CSDR TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 0 No Timeout 0 0 0 0 0 0 0 0 1 Sequence Timeout 1 1 1 1 1 1 1 1 2 Short Call (Not used in CSR mode) 2 2 2 3 Long Call (Not used in CSR mode) 3 3 3 Value Timeout Description CAP CSDR MAP CSDR INAP CSDR WHITE_TCAP_AP CSDR TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 4 Out of Error State 4 4 4 5 User Timeout 5 5 5 6 More-To-Come Timeout 6 - 6 7 Short Timeout 7 6 - 8 SMS Short Timeout 8 - - 9 Medium Timeout 9 7 - 10 Long Timeout 10 9 11 Wait for End Abort Timeout 11 - - 16 Medium-Long Timeout - 8 - 17 Pre-arranged END Timeout - - 7 Common Ð First Leg Originating Point Code Applicable Protocols: All Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR LABEL_OPC Originating Point Code of transaction MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_AIN_CSDR BELL_LIDB_CSDR Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: LABEL_OPC LABEL_OPC_LEG_2 LABEL_OPC_LEG_3 LABEL_OPC_LEG_4 LABEL_OPC_LEG_5 LABEL_OPC_LEG_6 LABEL_OPC_LEG_7 LABEL_OPC_LEG_8 LABEL_OPC_LEG_9 LABEL_OPC_LEG_10 Common - First Leg Destination Point Code Applicable Protocols: All Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR LABEL_DPC Destination Point Code of transaction MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_AIN_CSDR BELL_LIDB_CSDR Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: LABEL_DPC LABEL_DPC_LEG_2 LABEL_DPC_LEG_3 LABEL_DPC_LEG_4 LABEL_DPC_LEG_5 LABEL_DPC_LEG_6 LABEL_DPC_LEG_7 LABEL_DPC_LEG_8 LABEL_DPC_LEG_9 LABEL_DPC_LEG_10 Common - First Leg Source IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Source IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format. MAP_CSDR SOURCE_IP CAP_CSDR SOURCE_IP INAP_CSDR SOURCE_IP TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_AIN_CSDR - BELL_LIDB_CSDR - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: SOURCE_IP SOURCE_IP_LEG_2 SOURCE_IP_LEG_3 SOURCE_IP_LEG_4 SOURCE_IP_LEG_5 SOURCE_IP_LEG_6 SOURCE_IP_LEG_7 SOURCE_IP_LEG_8 SOURCE_IP_LEG_9 SOURCE_IP_LEG_10 Common - First Leg Destination IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Destination IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format. MAP_CSDR DESTINATION_IP CAP_CSDR DESTINATION_IP INAP_CSDR DESTINATION_IP TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from younger BEGIN (or QUERY) Else itÕs filled from younger CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: DESTINATION_IP DESTINATION_IP_LEG_2 DESTINATION_IP_LEG_3 DESTINATION_IP_LEG_4 DESTINATION_IP_LEG_5 DESTINATION_IP_LEG_6 DESTINATION_IP_LEG_7 DESTINATION_IP_LEG_8 DESTINATION_IP_LEG_9 DESTINATION_IP_LEG_10 Common - First Leg Source Network Node Applicable Protocols: All This field identifies the name of the First Leg Source Network Node by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Network node name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Source Network Node Type Applicable Protocols: All This field identifies the Role of the First Leg Source Network Node by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Network node type is calculated using the same filling rule of the other generations exploiting the following CAP/INAP CSDR fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Network Node Applicable Protocols: All This field identifies the Role of the First Leg Destination Network Node by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. CAP/INAP De-duplicated Generations: First Leg Destination Network node name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Network Node Type Applicable Protocols: All This field identifies the Role of the First Leg Destination Network Node by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Destination IP Address. CAP/INAP De-duplicated Generations: First Leg Destination Network node type is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Source Signalling Point Applicable Protocols: All This field identifies the name of the First Leg Source Signalling Point by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Signalling Point name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Signalling Point Applicable Protocols: All This field identifies the name of the First Leg Destination Signalling Point by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only destination IP Address. CAP/INAP De-duplicated Generations: First Leg Destination Signalling Point name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common Ð Last Leg Originating Point Code Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP Generations CAP, MAP, INAP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Originating Point Code of the last leg of the transaction MAP_CSDR LABEL_OPC CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR LAST_OPC BELL_TCAP_800_CSDR LAST_OPC BELL_LIDB_CSDR LAST_OPC BELL_AIN LAST_OPC Filling criteria: in case of full load sharing it is filled from If BEGIN (or QUERY) present, then it is filled from younger BEGIN (or QUERY) Else it is filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found LABEL_OPC_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Destination Point Code Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Destination Point Code of the last leg of the transaction MAP_CSDR LABEL_DPC CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR LAST_DPC BELL_TCAP_800_CSDR LAST_DPC BELL_LIDB_CSDR LAST_DPC BELL_AIN LAST_DPC Filling criteria: in case of full load sharing it is filled from If BEGIN (or QUERY) present, then it is filled from younger BEGIN (or QUERY) Else it is filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found LABEL_DPC_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Source IP Address Applicable Protocols: MAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Source IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format in the last leg of transaction MAP_CSDR SOURCE_IP CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from: If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found SOURCE_IP_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Destination IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Destination IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format in the last leg of transaction MAP_CSDR DESTINATION_IP CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from younger BEGIN (or QUERY) Else itÕs filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found DESTINATION_IP_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Source Network Node Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Source Network Node by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin."
"The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN The last leg IP Address + VLAN lookup is available only for MAP, CAP and INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP and INAP CSDRs. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Source IP Address. Common - Last Leg Source Network Node Type Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the role of the Last Leg Source Network Node by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDRs. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Source IP Address. Common - Last Leg Destination Network Node Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Destination Network Node by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Destination IP Address. Common - Last Leg Destination Network Node Type Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the role of the Last Leg Destination Network Node by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Common - Last Leg Source Signalling Point Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Source Signalling Point by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last leg Source IP Address. Common Ð Last Leg Destination Signalling Point Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Destination Signalling Point by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last leg Source IP Address. Common - Calling Party Number Applicable Protocols: MAP, CAP, INAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN CSDR Type CSDR field Description TCAP-AP_CSDR - Indicates Calling party number (TCAP-OP, TCAP-800, LIDB, AIN, CAP, INAP CSDRs) or the address of the originating Short Message Entity (MAP CSDR) MAP_CSDR TP_OA CAP_CSDR CALLING_NO INAP_CSDR INAP_CALLING_PARTY_NO TCAP-OP_CSDR CALLING_PARTY or CALLING_DN BELL_TCAP_800_CSDR CALLING_PARTY BELL_LIDB_CSDR LIDB_ANI_CALLING_NUMBER or LIDB_CALLING_DIRECTORY_NUMBER BELL_AIN CALLING_NO Common - Called Party Number Applicable Protocols: MAP, CAP, INAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Generations CAP, MAP, INAP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Indicates Called party number (TCAP-OP, TCAP-800, LIDB, AIN, CAP, INAP CSDRs) or the address of the destinating Short Message Entity (MAP CSDR) MAP_CSDR TP_DA CAP_CSDR CALLED_NO INAP_CSDR INAP_CALLED_PARTY_NO TCAP-OP_CSDR CALLED_PARTY BELL_TCAP_800_CSDR CALLED_PARTY BELL_LIDB_CSDR LIDB_DIALLED_NUMBER BELL_AIN CALLED_NO CAP De-duplicated Generation: It exploits the following CAP fields: CALLED_NO CALLED_NO_LEG_2 CALLED_NO_LEG_3 CALLED_NO_LEG_4 CALLED_NO_LEG_5 CALLED_NO_LEG_6 CALLED_NO_LEG_7 CALLED_NO_LEG_8 CALLED_NO_LEG_9 CALLED_NO_LEG_10 INAP De-duplicated Generation: It exploits the following INAP fields: INAP_CALLED_PARTY_NO INAP_CALLED_PARTY_NO_LEG_2 INAP_CALLED_PARTY_NO_LEG_3 INAP_CALLED_PARTY_NO_LEG_4 INAP_CALLED_PARTY_NO_LEG_5 INAP_CALLED_PARTY_NO_LEG_6 INAP_CALLED_PARTY_NO_LEG_7 INAP_CALLED_PARTY_NO_LEG_8 INAP_CALLED_PARTY_NO_LEG_9 INAP_CALLED_PARTY_NO_LEG_10 Common - Payment Plan Applicable protocol: TCAP, MAP, CAP, INAP It is based on lookup of IMSI on MCLS Mobile Subscriber table (ÒPlanÓ column). This feature is optional. MCLS Table: Mobile Subscriber The lookup will be made on the IMSI CSDR field. Enumeration Value: 0 Pre-paid subscriber 1 Post-paid subscriber Common Ð First Leg Forward Linkset Name Applicable protocol: All The Linkset Name is retrieved from the MasterClaw Configuration database CDB. This is the Linkset Name concerning the BEGIN or QUERY PDU or any message initiating the transaction. Common Ð First Leg Backward Linkset Name Applicable protocol: All The Linkset Name is retrieved from the MasterClaw Configuration database CDB. This is the Linkset Name concerning the first message sent in response to the first message initiating the transaction. Common Ð Last Leg Forward Linkset Name Applicable protocol: All CSDR Type CSDR field Description TCAP-AP_CSDR - This is the Linkset Name of the first forward message in last leg of the sequence. MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR LAST_LINKSET_TXID BELL_TCAP_800_CSDR LAST_LINKSET_TXID CSDR Type CSDR field Description BELL_LIDB_CSDR LAST_LINKSET_TXID BELL_AIN LAST_LINKSET_TXID Common Ð Last Leg Backward Linkset Name Applicable protocol: All CSDR Type CSDR field Description TCAP-AP_CSDR - This is the Linkset Name of the first backward message in last leg of the sequence. MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR LAST_LINKSET_RXID BELL_TCAP_800_CSDR LAST_LINKSET_RXID BELL_LIDB_CSDR LAST_LINKSET_RXID BELL_AIN LAST_LINKSET_RXID Common - OTID Applicable protocol: All 32-Bit long Originating Transaction ID of TCAP. Filled from: Filled with the OTID of BEGIN message or from DTID of END/CONTINUE message whichever comes first in the sequence. CSDR Type CSDR field Description TCAP-AP_CSDR OTID Originating Transaction ID of TCAP MAP_CSDR CAP_CSDR CSDR Type CSDR field Description INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common Ð DTID Applicable protocol: All 32-bit long Destination Transaction ID of TCAP Filled from: Filled with the OTID of CONTINUE message if present in the sequence CSDR Type CSDR field Description TCAP-AP_CSDR DTID Destination Transaction ID of TCAP MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common Ð SCCP Back Calling Number Applicable protocol: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN The 'address information part' of the 'calling party global titleÕ, which is carried in the TCAP CONTINUE/END operation. Also from BEGIN operation if only UDT/XUDT (BEGIN) and UDTS/XUDTS (BEGIN) forms a sequence. Q713 (section 3.4), E164, E214 Generations CAP, MAP, INAP, TCAP-AP, MAP-E2E-SMS CSDR Type CSDR field TCAP-AP_CSDR BACKCLG_NO MAP_CSDR CAP_CSDR See below INAP_CSDR TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - CAP/INAP CSDR Check in this order the following CAP/INAP fields: 1- BACKCLG_NO 2- BACKCLG_NO_LEG_N (for N=2 to N=10, N++) Common Ð SCCP Back Calling Number = the first found CAP/INAP field not NULL If no field is found Common Ð SCCP Back Calling Number = NULL CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: BACKCLG_NO BACKCLG_NO_LEG_2 BACKCLG_NO_LEG_3 BACKCLG_NO_LEG_4 BACKCLG_NO_LEG_5 BACKCLG_NO_LEG_6 BACKCLG_NO_LEG_7 BACKCLG_NO_LEG_8 BACKCLG_NO_LEG_9 BACKCLG_NO_LEG_10 Common - Called Party Global Title Applicable protocol: All The 'address information part' of the 'called party global titleÕ, which is carried in the TCAP BEGIN/CONTINUE/END operation. Q713 (section 3.4), E164, E214 Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field TCAP-AP_CSDR GTCALLED_NO MAP_CSDR GTCALLED_NO CAP_CSDR SCCP_CALLED_PARTY INAP_CSDR SCCP_CALLED_PARTY TCAP-OP_CSDR SCCP_CALLED_PARTY BELL_TCAP_800_CSDR SCCP_CALLED_PARTY BELL_LIDB_CSDR SCCP_CALLED_PARTY BELL_AIN SCCP_CALLED_PARTY CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: SCCP_CALLED_PARTY SCCP_CALLED_PARTY_LEG_2 SCCP_CALLED_PARTY_LEG_3 SCCP_CALLED_PARTY_LEG_4 SCCP_CALLED_PARTY_LEG_5 SCCP_CALLED_PARTY_LEG_6 SCCP_CALLED_PARTY_LEG_7 SCCP_CALLED_PARTY_LEG_8 SCCP_CALLED_PARTY_LEG_9 SCCP_CALLED_PARTY_LEG_10 Common - Calling Party Global Title Applicable protocol: All The 'address information part' of the 'called party global titleÕ, which is carried in the TCAP BEGIN/CONTINUE/END operation. Q713 (section 3.4), E164, E214 Common - Called SSN Applicable protocol: All It represents the Called Sub System Number, Part of SCCP called party sub system. Q.713 (section 3.4.2.2) CSDR Type CSDR field TCAP-AP_CSDR CALLED_SSN MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Value Definition 0 SSN not known not used Value Definition 1 SCCP Management 3 ISDN User Part 4 OMAP 5 MAP 6 HLR 7 VLR 8 MSC 9 EIR 10 AUC 11 ISDN Supplementary Services 12 INAP 13 broadband ISDN Edge To Edge 14 TC Test Responder 15 SINAP 142 RANAP 143 RNSAP 145 GMLC 146 CAP 147 GSMSCF 148 SIWF 149 SGSN 150 GGSN 192 BSSAP 241 INAPCS2 Value Definition 248 MTXMUP 249 HLRMUP 252 BSAP 254 BSSAP Table for MAP/CAP Common - Calling SSN Applicable protocol: All It represents the Calling Sub System Number, part of SCCP called party sub system. Q.713 (section 3.4.2.2) CSDR Type CSDR field TCAP-AP_CSDR CALLING_SSN MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN See Called SSN for value list. Common - SCCP Return Cause Applicable protocol: All This field contains the result of procedure at SCCP layer. Common - TCAP Abort Cause Applicable protocol: All This field contains the result of procedure at TCAP layer. Common - Service Information Octet Applicable protocol: All The service information octet of message contains the service indicator and sub service field (which contains network indicator and spare bits). It is used to distinguish the network service carried in SCCP layer. Value SIO (Enumeration) 0 SNM 1 SNT 3 international SCCP 4 TUP 5 international ISUP 6 DUP 7 DUP1 8 MTUP 9 BISUP 10 SISUP 128 national SNM 129 national SNT 131 national SCCP 132 national TUP 133 national ISUP 192 nSNM* 193 nSNT* 195 nSCCP* 196 nTUP* Value SIO (Enumeration) 197 nISUP 255 undefined field CSDR Type CSDR field Description TCAP-AP_CSDR SIO The service information octet of message signal units contains the service indicator and sub service field (which contains network indicator and spare bits) MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common - Service Key Applicable Protocols: CAP, INAP, MAP CAP: it represents a CAP/CAMEL service descriptor. The interpretation is operator dependent. INAP: it represents an INAP service descriptor. The interpretation is operator dependent. MAP: it defines the ServiceKey field of VLR CAMEL subscription info Common Ð Conversation Time Interval Applicable Protocols: CAP, INAP This field identifies the Conversation Time Interval by means of a lookup of the Conversation Time field on MCLS table Conversation Interval Standard Formatting: Column CTI_INTERVAL_NAME CTI_LOWER_VALUE CTI_UPPER_VALUE Default table value: Conversation Time Interval Name Conversation Time Lower Value (s) Conversation Time Upper Value (s) 0-30 s 0 30 30-60 s 30 60 60-900 s 60 900 900-1800 s 900 1800 1800-3600 s 1800 3600 >=3600 s 3600 Factor conversion: 1000 (from msec to sec) Common - IMSI Applicable protocol: TCAP-AP, MAP, CAP, INAP Common - MSISDN Applicable protocol: TCAP-AP, MAP, CAP, INAP MAP: This field is mandatory only in successful cases because it is contained in the Insert Subscriber Data from HLR that follow the GSM/GPRS Update Location only in case of success. This parameter refers to the Directory number used to call GSM subscriber. The structure of a GSM directory number consists of country code, the national destination code and the subscriber number. MSISDN number (Reference GSM 09.02 V4.6.0, 5.6.2.17) TCAP-AP: IMSI lookup via MICS. CAP: IMSI lookup via MICS. INAP IMSI lookup via MICS. TCAP-OP: N.A. BELL_TCAP_800: N.A. BELL_LIDB: N.A. BELL_AIN: N.A. Common - IMEI Applicable protocol:, MAP, CAP International Mobile Equipment identity number. CAP CSDR: itÕs filled by ÒINITIAL DPÓ, ÒINITIAL DP SMSÓ & ÒINITIAL DP GPRSÓ. MAP CSDR: itÕs filled by ÒPrepare HandoverÓ, ÒUpdate LocationÓ, ÒUpdate GPRS LocationÓ, ÒUE Identity IE from CN INVOKE TRACE message of RANAP layer over MAP Common - Device TAC Applicable protocol: MAP, CAP TAC (Type of Allocation) is composed by the first eight digits of IMEI. TAC code identifies the device manufacturer and the model. Common - Location Information Applicable protocol: TCAP-OP, MAP, INAP Common Ð PLMN ID Applicable protocol: MAP, CAP It conveys the identity of the network to which the UE is attached according to the ITU-T E.212 standard. Common Ð SCCP Calling Party Number Point Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Common Ð SCCP Calling Party Number Signalling Point Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN This field identifies the Calling Party Number signalling point name by means of a lookup of: - SCCP Calling Party Number Point Code Common Ð SCCP Called Party Number Point Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Common Ð SCCP Called Party Number Signalling Point This field identifies the Called Party Number signalling point name by means of a lookup of: - SCCP Called Party Number Point Code - Common Ð VLR Number This field identifies the ISDN Number of the VLR Applicable protocol: MAP, CAP, INAP WHITE TCAP Fields WHITE TCAP - Application Operation Code It represents the first operation invoked at TCAP layer. Application Operation Code Opcode Description EINAPV21 0x0101 EINAPV21 Activate Resource 0x0102 EINAPV21 Activity Test 0x0103 EINAPV21 Congestion Control 0x0104 EINAPV21 Create 0x0105 EINAPV21 Event 0x0106 EINAPV21 Free 0x0107 EINAPV21 Generate 0x0108 EINAPV21 Handover 0x0109 EINAPV21 Charging Information 0x010A EINAPV21 Join 0x010B EINAPV21 Monitor 0x010C EINAPV21 Open Special Function 0x010D EINAPV21 Provide Instructions 0x010E EINAPV21 Release Resource 0x010F EINAPV21 Reset Timer Opcode Description 0x0110 EINAPV21 Retrieve 0x0111 EINAPV21 sCF Reset Indication 0x0112 EINAPV21 Split 0x0113 EINAPV21 sSF Reset Indication 0x0114 EINAPV21 Transfer Control 0x0115 EINAPV21 Update 0x0116 EINAPV21 Backward Information 0x0117 EINAPV21 Call Control INAPCS1P 0x0200 INAPCS1P InitialDP 0x0210 INAPCS1P Retrieve / Assist Request Instructions 0x0211 INAPCS1P Establish Temporary Connection 0x0212 INAPCS1P Disconnect Forward Connection 0x0213 INAPCS1P Connect To Resource 0x0214 INAPCS1P Connect 0x0215 INAPCS1P Update 0x0216 INAPCS1P Release Call 0x0217 INAPCS1P Request Report BCSM Event 0x0218 INAPCS1P Event Report BCSM 0x0219 INAPCS1P Request Notification Charging Event 0x021A INAPCS1P Event Notification Charging 0x021B INAPCS1P Collect Information 0x021F INAPCS1P Continue 0x0220 INAPCS1P Initiate Call Attempt Opcode Description 0x0221 INAPCS1P Reset Timer 0x0222 INAPCS1P Furnish Charging Information 0x0223 INAPCS1P Apply Charging 0x0224 INAPCS1P Apply Charging Report 0x0229 INAPCS1P Call Gap 0x022A INAPCS1P Activate Service Filtering 0x022B INAPCS1P Service Filtering Response 0x022C INAPCS1P Call Information Report 0x022D INAPCS1P Call Information Request 0x022E INAPCS1P Send Charging Information 0x022F INAPCS1P Play Announcement 0x0230 INAPCS1P Prompt And Collect User Information 0x0231 INAPCS1P Specialised Resource Report 0x0235 INAPCS1P Cancel 0x0236 INAPCS1P Activity Test 0x02F8 INAPCS1P Signalling Information 0x02FA INAPCS1P Release Call Party Connection 0x02FB INAPCS1P Reconnect 0x02FC INAPCS1P Hold Call Party Connection 0x02FD INAPCS1P HandOver 0x02FE INAPCS1P Dialogue User Information 0x02FF INAPCS1P Call Limit ETSI_INAP 0x0300 ETSI_INAP InitialDP Opcode Description 0x0310 ETSI_INAP Retrieve / Assist Request Instructions 0x0311 ETSI_INAP Establish Temporary Connection 0x0312 ETSI_INAP Disconnect Forward Connection 0x0313 ETSI_INAP Connect To Resource 0x0314 ETSI_INAP Connect 0x0315 ETSI_INAP Update 0x0316 ETSI_INAP Release Call 0x0317 ETSI_INAP Request Report BCSM Event 0x0318 ETSI_INAP Event Report BCSM 0x0319 ETSI_INAP Request Notification Charging Event 0x031A ETSI_INAP Event Notification Charging 0x031B ETSI_INAP Collect Information 0x031F ETSI_INAP Continue 0x0320 ETSI_INAP Initiate Call Attempt 0x0321 ETSI_INAP Reset Timer 0x0322 ETSI_INAP Furnish Charging Information 0x0323 ETSI_INAP Apply Charging 0x0324 ETSI_INAP Apply Charging Report 0x0329 ETSI_INAP Call Gap 0x032A ETSI_INAP Activate Service Filtering 0x032B ETSI_INAP Service Filtering Response 0x032C ETSI_INAP Call Information Report 0x032D ETSI_INAP Call Information Request 0x032E ETSI_INAP Send Charging Information Opcode Description 0x032F ETSI_INAP Play Announcement 0x0330 ETSI_INAP Prompt And Collect User Information 0x0331 ETSI_INAP Specialised Resource Report 0x0335 ETSI_INAP Cancel 0x0336 ETSI_INAP Activity Test ETSI_CAP 0x0400 ETSI_CAP InitialDP 0x0410 ETSI_CAP Assist Request Instructions 0x0411 ETSI_CAP Establish Temporary Connection 0x0412 ETSI_CAP Disconnect Forward Connection 0x0413 ETSI_CAP Connect To Resource 0x0414 ETSI_CAP Connect 0x0416 ETSI_CAP Release Call 0x0417 ETSI_CAP Request Report BCSM Event 0x0418 ETSI_CAP Event Report BCSM 0x041F ETSI_CAP Continue 0x0420 ETSI_CAP Initiate Call Attempt 0x0421 ETSI_CAP Reset Timer 0x0422 ETSI_CAP Furnish Charging Information 0x0423 ETSI_CAP Apply Charging 0x0424 ETSI_CAP Apply Charging Report 0x0429 ETSI_CAP Call Gap 0x042C ETSI_CAP Call Information Report 0x042D ETSI_CAP Call Information Request Opcode Description 0x042E ETSI_CAP Send Charging Information 0x042F ETSI_CAP Play Announcement 0x0430 ETSI_CAP Prompt And Collect User Information 0x0431 ETSI_CAP Specialized Resource Report 0x0435 ETSI_CAP Cancel 0x0437 ETSI_CAP Activity Test 0x0438 ETSI_CAP Continue With Argument 0x043C ETSI_CAP InitialDP SMS 0x043D ETSI_CAP Furnish Charging Information SMS 0x043E ETSI_CAP Connect SMS 0x043F ETSI_CAP Request Report SMS Event 0x0440 ETSI_CAP Event Report SMS 0x0441 ETSI_CAP Continue SMS 0x0442 ETSI_CAP Release SMS 0x0443 ETSI_CAP Reset Timer SMS 0x0446 ETSI_CAP Activity Test GPRS 0x0447 ETSI_CAP Apply Charging GPRS 0x0448 ETSI_CAP Apply Charging Report GPRS 0x0449 ETSI_CAP Cancel GPRS 0x044A ETSI_CAP Connect GPRS 0x044B ETSI_CAP Continue GPRS 0x044C ETSI_CAP Entity Released GPRS 0x044D ETSI_CAP Furnish Charging Information GPRS 0x044E ETSI_CAP InitialDP GPRS Opcode Description 0x044F ETSI_CAP Release GPRS 0x0450 ETSI_CAP Event Report GPRS 0x0451 ETSI_CAP Request Report GPRS Event 0x0452 ETSI_CAP Reset Timer GPRS 0x0453 ETSI_CAP Send Charging Information GPRS 0x045A ETSI_CAP Disconnect Leg 0x045D ETSI_CAP Move Leg 0x045F ETSI_CAP Split Leg 0x0460 ETSI_CAP Entity Released 0x0461 ETSI_CAP Play Tone 0x04FF ETSI_CAP undefined field ETSI_MAP 0x0502 ETSI_MAP Update Location 0x0503 ETSI_MAP Cancel Location 0x0504 ETSI_MAP Provide Roaming Number 0x0505 ETSI_MAP Note Subscriber Data Modified 0x0506 ETSI_MAP Resume Call Handling 0x0507 ETSI_MAP Insert Subscriber Data 0x0508 ETSI_MAP Delete Subscriber Data 0x0509 ETSI_MAP Send Parameters 0x050A ETSI_MAP Register SS 0x050B ETSI_MAP Erase SS 0x050C ETSI_MAP Activate SS 0x050D ETSI_MAP Deactivate SS Opcode Description 0x050E ETSI_MAP Interrogate SS 0x050F ETSI_MAP Authentication Failure Report 0x0511 ETSI_MAP Register Password 0x0512 ETSI_MAP Get Password 0x0513 ETSI_MAP Process Unstructured SS-Data 0x0514 ETSI_MAP Release Resources 0x0515 ETSI_MAP MT Forward SM VGCS 0x0516 ETSI_MAP Send Routing Info 0x0517 ETSI_MAP Update Gprs Location 0x0518 ETSI_MAP Send Routing Info For GPRS 0x0519 ETSI_MAP Failure Report 0x051A ETSI_MAP Note MS Present For GPRS 0x051C ETSI_MAP Perform Handover 0x051D ETSI_MAP Send End Signal 0x051E ETSI_MAP Perform Subsequent Handover 0x051F ETSI_MAP Provide SIWFS Number 0x0520 ETSI_MAP SIW FS Signalling Modify 0x0521 ETSI_MAP Process Access Signalling 0x0522 ETSI_MAP Forward Access Signalling 0x0523 ETSI_MAP Note Internal Handover 0x0525 ETSI_MAP Reset 0x0526 ETSI_MAP Forward Check SS-Indication 0x0527 ETSI_MAP Prepare Group Call 0x0528 ETSI_MAP Send Group Call End Signal Opcode Description 0x0529 ETSI_MAP Process Group Call Signalling 0x052A ETSI_MAP Forward Group Call Signalling 0x052B ETSI_MAP Check IMEI 0x052C ETSI_MAP MT-ForwardSM 0x052D ETSI_MAP Send Routing Info For SM 0x052E ETSI_MAP MO-ForwardSM 0x052F ETSI_MAP Report SM-Delivery Status 0x0530 ETSI_MAP Note Subscriber Present 0x0531 ETSI_MAP Alert Service Centre Without Result 0x0532 ETSI_MAP Activate Trace Mode 0x0533 ETSI_MAP Deactivate Trace Mode 0x0534 ETSI_MAP Trace Subscriber Activity 0x0536 ETSI_MAP Begin Subscriber Activity 0x0537 ETSI_MAP Send Identification 0x0538 ETSI_MAP Send Authentication Info 0x0539 ETSI_MAP Restore Data 0x053A ETSI_MAP Send IMSI 0x053B ETSI_MAP Process Unstructured SS Request 0x053C ETSI_MAP Unstructured SS Request 0x053D ETSI_MAP Unstructured SS Notify 0x053E ETSI_MAP Any Time Subscription Interrogation 0x053F ETSI_MAP Inform Service Centre 0x0540 ETSI_MAP Alert Service Centre 0x0541 ETSI_MAP Any Time Modification Opcode Description 0x0542 ETSI_MAP Ready For SM 0x0543 ETSI_MAP Purge MS 0x0544 ETSI_MAP Prepare Handover 0x0545 ETSI_MAP Prepare Subsequent Handover 0x0546 ETSI_MAP Provide Subscriber Info 0x0547 ETSI_MAP Any Time Interrogation 0x0548 ETSI_MAP SS-Invocation Notification 0x0549 ETSI_MAP Set Reporting State 0x054A ETSI_MAP Status Report 0x054B ETSI_MAP Remote User Free 0x054C ETSI_MAP Register CC-Entry 0x054D ETSI_MAP Erase CC-Entry 0x054E ETSI_MAP Secure Transport Class1 0x054F ETSI_MAP Secure Transport Class2 0x0550 ETSI_MAP Secure Transport Class3 0x0551 ETSI_MAP Secure Transport Class4 0x0552 ETSI_MAP Provide Subscriber Location 0x0553 ETSI_MAP Send Group Call Information 0x0554 ETSI_MAP Send Routing Info For LCS 0x0555 ETSI_MAP Subscriber Location Report 0x0556 ETSI_MAP IST-Alert 0x0557 ETSI_MAP IST-Command 0x0558 ETSI_MAP Note MM-Event 0x05FF ETSI_MAP Undefined Field Opcode Description BEL IS41D 0x0601 BEL IS41D HandOff Measurement Request 0x0602 BEL IS41D Facilities Directive 0x0603 BEL IS41D Mobile on channel 0x0604 BEL IS41D HandOff Back 0x0605 BEL IS41D Facilities Release 0x0606 BEL IS41D Qualification Request 0x0607 BEL IS41D Qualification Directive 0x0608 BEL IS41D Blocking 0x0609 BEL IS41D Unblocking 0x060A BEL IS41D Reset Circuit 0x060B BEL IS41D TrunkTest 0x060C BEL IS41D Trunk Test Disconnect 0x060D BEL IS41D Registration Notification 0x060E BEL IS41D Registration Cancellation 0x060F BEL IS41D Location Request 0x0610 BEL IS41D Routing Request 0x0611 BEL IS41D Feature Request 0x0612 BEL IS41D Service Profile Request 0x0613 BEL IS41D Service Profile Directive 0x0614 BEL IS41D Unreliable Roamer Data Dir 0x0615 BEL IS41D Call Data Request 0x0616 BEL IS41D MS Inactive 0x0617 BEL IS41D Transfer To Number Request Opcode Description 0x0618 BEL IS41D Redirection Request 0x0619 BEL IS41D HandOff To Third 0x061A BEL IS41D Flash Request 0x061B BEL IS41D Authentication Directive 0x061C BEL IS41D Authentication Request 0x061D BEL IS41D Base Station Challenge 0x061E BEL IS41D Authentication Failure Report 0x061F BEL IS41D Count Request 0x0620 BEL IS41D InterSystemPage 0x0621 BEL IS41D Unsolicited Response 0x0622 BEL IS41D Bulk Deregistration 0x0623 BEL IS41D HandOff Measurement Request 2 0x0624 BEL IS41D Facilities Directive 2 0x0625 BEL IS41D HandOff Back 2 0x0626 BEL IS41D HandOff To Third 2 0x0627 BEL IS41D Authentication Directive Forward 0x0628 BEL IS41D Authentication Status Report 0x0629 BEL IS41D Reserved 0x062A BEL IS41D Information Directive 0x062B BEL IS41D Information Forward 0x062C BEL IS41D Inter System Answer 0x062D BEL IS41D Inter System Page 2 0x062E BEL IS41D Inter System Setup 0x062F BEL IS41D Origination Request Opcode Description 0x0630 BEL IS41D Random Variable Request 0x0631 BEL IS41D Redirection Directive 0x0632 BEL IS41D Remote User Interaction Dir 0x0633 BEL IS41D SMS Delivery Backward 0x0634 BEL IS41D SMS Delivery Forward 0x0635 BEL IS41D SMS Delivery Point To Point 0x0636 BEL IS41D SMS Notification 0x0637 BEL IS41D SMS Request 0x0639 BEL IS41D Number Portability Request 0x063A BEL IS41D Analyzed Information 0x063B BEL IS41D Connection Failure Report 0x063C BEL IS41D Connect Resource 0x063D BEL IS41D Disconnect Resource 0x063E BEL IS41D Facility Selected & Available 0x063F BEL IS41D Instruction Request 0x0640 BEL IS41D Modify 0x0641 BEL IS41D Reset Timer 0x0642 BEL IS41D Search 0x0643 BEL IS41D Seize Resource 0x0644 BEL IS41D SRF Directive 0x0645 BEL IS41D T Busy 0x0646 BEL IS41D T No Answer 0x0647 BEL IS41D ServiceRequest 0x0648 BEL IS41D Bulk Disconnection Opcode Description 0x0649 BEL IS41D Call Control Directive 0x064A BEL IS41D O Answer 0x064B BEL IS41D O Disconnect 0x064C BEL IS41D Call Recovery Report 0x064D BEL IS41D T Answer 0x064E BEL IS41D T Disconnect 0x064F BEL IS41D Unreliable Call Data TCAPOP 0x0701 TCAPOP Dequeue Call 0x0702 TCAPOP Queue Call 0x0703 TCAPOP Voice Message Retrieved 0x0704 TCAPOP Voice Message Available 0x0705 TCAPOP Cancel 0x0706 TCAPOP Security 0x0707 TCAPOP Report assist Termination 0x0708 TCAPOP Temporary Handover 0x0709 TCAPOP Automatic Code Gap 0x070A TCAPOP When Party Free 0x070B TCAPOP Indicate Information Provided 0x070C TCAPOP Indicate Information Waiting 0x070D TCAPOP Play announcement abd collect Digits 0x070E TCAPOP Play Announcement 0x070F TCAPOP Forward Disconnect 0x0710 TCAPOP Disconnect Opcode Description 0x0711 TCAPOP Temporary Connect 0x0712 TCAPOP Connect 0x0713 TCAPOP Assist 0x0714 TCAPOP Start 0x0715 TCAPOP Bill Call 0x0716 TCAPOP Set Value 0x0717 TCAPOP Provide Value INAPCS2 0x800 initialDP 0x801 originationAttemptAuthorized 0x802 collectedInformation 0x803 analysedInformation 0x804 routeSelectFailure 0x805 oCalledPartyBusy 0x806 oNoAnswer 0x807 oAnswer 0x808 oDisconnect 0x809 termAttemptAuthorized 0x80A tBusy 0x80B tNoAnswer 0x80C tAnswer 0x80D tDisconnect 0x80E oMidCall 0x80F tMidCall Opcode Description 0x810 assistRequestInstructions 0x811 establishTemporaryConnection 0x812 disconnectForwardConnection 0x813 connectToResource 0x814 connect 0x815 holdCallInNetwork 0x816 releaseCall 0x817 requestReportBCSMEvent 0x818 eventReportBCSM 0x819 requestNotificationChargingEvent 0x81A eventNotificationCharging 0x81B collectInformation 0x81C analyseInformation 0x81D selectRoute 0x81E selectFacility 0x81F continue 0x820 initiateCallAttempt 0x821 resetTimer 0x822 furnishChargingInformation 0x823 applyCharging 0x824 applyChargingReport 0x825 requestCurrentStatusReport 0x826 requestEveryStatusChangeReport 0x827 requestFirstStatusMatchReport Opcode Description 0x828 statusReport 0x829 callGap 0x82A activateServiceFiltering 0x82B serviceFilteringResponse 0x82C callInformationReport 0x82D callInformationRequest 0x82E sendChargingInformation 0x82F playAnnouncement 0x830 promptAndCollectUserInformation 0x831 specializedResourceReport 0x835 cancel 0x836 cancelStatusReportRequest 0x837 activityTest 0x850 facilitySelectedAndAvailable 0x851 originationAttempt 0x852 terminationAttempt 0x853 oAbandon 0x854 oSuspended 0x855 tSuspended 0x856 dFCWithArgument 0x857 authorizeTermination 0x858 continueWithArgument 0x859 createCallSegmentAssociation 0x85A disconnectLeg Opcode Description 0x85B mergeCallSegments 0x85C moveCallSegments 0x85D moveLeg 0x85E reconnect 0x85F splitLeg 0x860 entityReleased 0x861 manageTriggerData 0x862 requestReportUTSI 0x864 sendSTUI 0x865 reportUTSI 0x866 sendFacilityInformation 0x867 requestReportFacilityEvent 0x868 eventReportFacility 0x86B promptAndReceiveMessage 0x86C scriptInformation 0x86D scriptEvent 0x86E scriptRun 0x86F scriptClose 0x870 establishChargingRecord 0x871 handlingInformationRequest 0x872 handlingInformationResult 0x873 networkCapability 0x874 notificationProvided 0x875 confirmedNotificationProvided Opcode Description 0x876 provideUserInformation 0x877 confirmedReportChargingInformation 0x878 reportChargingInformation 0x879 requestNotification 0x87A activationReceivedAndAuthorized 0x87B initiateAssociation 0x87C associationReleaseRequested 0x87D componentReceived 0x87E releaseAssociation 0x87F requestReportBCUSMEvent 0x882 sendComponent NOKIA_INAP 0x900 initialDP 0x910 assistRequestInstructions 0x911 establishTemporaryConnection 0x912 disconnectForwardConnection 0x913 connectToResource 0x914 connect 0x916 releaseCall 0x917 requestReportBCSMEvent 0x918 eventReportBCSM 0x919 requestNotificationChargingEvent 0x91A eventNotificationCharging 0x91B collectInformation Opcode Description 0x91F continue 0x920 initiateCallAttempt 0x921 resetTimer 0x922 furnishChargingInformation 0x923 applyCharging 0x924 applyChargingReport 0x929 callGap 0x92A activateServiceFiltering 0x92B serviceFilteringResponse 0x92C callInformationReport 0x92D callInformationRequest 0x92E sendChargingInformation 0x92F playAnnouncement 0x930 promptAndCollectUserInformation 0x931 specializedResourceReport 0x935 cancel 0x937 activityTest SINAP 0xA00 sinapInitialDP 0xA10 sinapAssistRequestInstructions 0xA11 sinapEstablishTemporaryConnection 0xA12 disconnectForwardConnection 0xA13 sinapConnectToResource 0xA14 sinapConnect Opcode Description 0xA16 sinapReleaseCall 0xA17 sinapRequestReportBCSMEvent 0xA18 sinapEventReportBCSM 0xA19 requestNotificationChargingEvent 0xA1A eventNotificationCharging 0xA1B collectInformation 0xA1F continue 0xA20 sinapInitiateCallAttempt 0xA21 sinapResetTimer 0xA22 furnishChargingInformation 0xA23 sinapApplyCharging 0xA24 sinapApplyChargingReport 0xA29 sinapCallGap 0xA2A activateServiceFiltering 0xA2B serviceFilteringResponse 0xA2C sinapCallInformationReport 0xA2D sinapCallInformationRequest 0xA2E sinapSendChargingInformation 0xA2F sinapPlayAnnouncement 0xA30 sinapPromptAndCollectUserInformation 0xA31 specializedResourceReport 0xA35 sinapCancel 0xA56 sinapDisconnectForwardConnectionWithArgument 0xA58 sinapContinueWithArgument Opcode Description 0xA5A sinapDisconnectLeg 0xA5B sinapMergeCallSegments 0xA5F sinapSplitLeg 0xA60 sinapEntityReleased 0xA62 manageTriggerData 0xA63 releaseLeg 0xA6D sinapScriptEvent 0xA6E sinapScriptRun WHITE TCAP - Application Error Code This field has to be filled with error codes of EINAPV21, INAPCS1P, ETSI_CAP,ETSI_MAP, ETSI_INAP,INAPCS2,NOKIA_INAP,SINAP,BELIS41D,TCAPOP layers when Return Error Component comes with their Error Code Value. BELL TCAP Fields BELL TCAP Ð Application Operation Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 257 Parameter Provide Value X X 258 Parameter Set Value X x 513 Charging Bill Call X X 769 Provide Instructions Start X x X 770 Provide Instructions Assist X X 1025 Connection Control Connect X x X 1026 Connection Control Temporary Connect X X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 1027 Connection Control Disconnect X X 1028 Connection Control Forward Disconnect X X 1281 Caller Interaction Play Announcement X x X 1282 Caller Interaction PA and Collect Digits X X 1283 Caller Interaction Indicate Information Waiting X 1284 Caller Interaction Indicate Information Provided X 1537 Send Notification When Party Free X x X 1793 Network Management Automatic Code Gap X x X 2049 Procedural Temporary Handover X X 2050 Procedural Report Assist Termination X 2051 Procedural Security X x x 2305 Operation Control Cancel X 2561 Report Event Voice Message Available X 2562 Report Event Voice Message Retrieved X 32257 Miscellaneous Queue Call X 32258 Miscellaneous Dequeue Call x 26116 callInfoFromResource X 28161 close X 26118 cTRClear X 25604 failureOutcome X 25603 infoAnalyzed X 25602 infoCollected X 25623 networkBusy X 25611 oAnswer X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 25614 oAbandon X 25607 oCalledPartyBusy X 25626 oDisconnect X 25615 oMidCall X 25609 oNoAnswer X 25625 oSuspended X 25612 oTermSeized X 25624 originationAttempt X 26114 resourceClear X 25617 successOutcome X 25610 tAnswer X 25606 tBusy X 25618 tDisconnect X 25619 tMidCall X 25608 tNoAnswer X 25605 terminationAttempt X 25613 termResourceAvailable X 25620 timeout X 25862 acknowledge X 25857 analyzeRoute X 25858 authorizeTermination X 26115 cancelResourceEvent X 25861 collectInformation X 26117 connectToResource X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 25869 continue X 25863 createCall X 25859 disconnect X 25864 disconnectLeg X 27137 forwardCall X 25865 mergeCall X 25866 moveLeg X 25860 offerCall X 25867 originateCall X 25870 reconnect X 26113 sendToResource X 25868 splitLeg X 26881 acg X 26883 acgGlobalCtrlRestore X 26884 acgOverflow X 26885 controlRequest X 26882 echoRequest X 27649 furnishAMAInformation X 26369 monitorForChange X 26371 monitorSuccess X 27394 nCAData X 27393 nCARequest X 26626 queryRequest X 27905 requestReportBCMEvent X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 26373 sendNotification X 26370 statusReported X 26372 terminationNotification X 26627 update X 26625 updateRequest X 28417 reportError X 25627 oDTMFEnteredArg X 26889 setTimerArg X 25628 tDTMFEnteredArg X 26886c activityTestArg X 26887 callTypeRequestArg X BELL TCAP Ð Last Application Operation Code Applicable protocol: TCAP-OP, BELL LIDB, BELL AIN BELL TCAP Ð Application Error Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP Ð Reject Problem Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP Ð Translation Type Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP - GTT REQUESTED Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB BELL TCAP Ð TCAP 800 Termination Indicator Applicable protocol: BELL TCAP 800 CSDR Type CSDR field Description BELL_TCAP_800_CSDR TERMIN_INDIC This field indicates the termination indicator. BELL TCAP Ð AIN Error Cause Applicable protocol: BELL AIN CSDR Type CSDR field Description BELL_AIN ER_REASON Contains a reason for those transactions having an error carrying additional information. This parameter is sent to identify the application error detected at the SSP or SCP. This field and the ÔErrorCodeÕ field specify the exact error and reason. BELL TCAP Ð TCAP OP Line Service Type Applicable protocol: BELL TCAP OP CSDR Type CSDR field Description BELL_TCAP_OP_CSDR SERVICE_TYPE This field indicates which line service type is associated with a DN and also whether a DN is applicable to both originating and terminating service Value Interpretation 0 Individual 1 Coin 2 Multiline Hunt 3 PBX 4 Choke Value Interpretation 5 Series Completion 6 Unassigned DN 7 Multi-Party 8 Non-specific 9 Temporarily out of Service BELL TCAP Ð LIDB Service or Equipment Indicator Applicable protocol: BELL TCAP OP, BELL LIDB CSDR Type CSDR field Description BELL_LIDB_CSDR LIDB_SERVICE_EQUIPMENT_INDICATOR This parameter indicates the type of service or equipment associated with the line originating the call. Value Interpretation 1 POTS Line (Business/Residential) 2 LEC Public - Standard Interface - Postpay Overtime 3 POTS Line - Residential - Message rate 1 4 POTS Line - Residential - Message rate 2 5 LEC Semi-Public 6 POTS Line - Business - flat rate 7 POTS Line - Business - message rate 1 8 Coinless (non-IPP) 9 Coinless (IPP) 10 LEC Prepaid Telecommunications Card Station 11 POTS Line - Business - message rate 2 Value Interpretation 12 LEC Public - Standard Interface - Prepay Overtime 13 LEC Public - Alternate Interface 14 IC Public - Standard Interface 15 IC Public -Alternate Interface 16 POTS line - Residential - flat rate 17 Voice Quote - without tax 18 Voice Quote - with tax 19 IPP - Standard Interface 20 IPP - Alternate Interface 21 Hospital 22 Prison (non-IPP) 23 Auto Quote - without tax 24 Auto Quote - with tax 25 Dormitory Line 26 Centrex Line 27 PBX Line 28 Prison (IPP) 29 WATS Line 30 Cellular 31 Pager 32 Personal Communication Service (PCS) 33 Feature Group A (FGA) 34 Mobile 35 LEC Public - Special Billing - Postpay Overtime Value Interpretation 36 LEC Public - Special Billing - Prepay Overtime 37 Public - Incompatible Network Interface 38 Cellular-Rate 1 39 Cellular-Rate 2 40 POTS Line - Business - Single-Line 41 POTS Line - Business - Multi-Line 42 Public-Postpay 255 Reserved MAP Fields MAP Ð First Leg Operation Code It represents the first operation invoked at MAP layer related to the first leg of the MAP transaction in case of correlated generation. Value Operation Name 2 updateLocation 3 cancelLocation 4 provideRoamingNumber 5 noteSubscriberDataModified 6 resumeCallHandling 7 insertSubscriberData 8 deleteSubscriberData 9 sendParameters 10 registerSS 11 eraseSS 12 activateSS Value Operation Name 13 deactivateSS 14 interrogateSS 15 authenticationFailureReport 17 registerPassword 18 getPassword 19 processUnstructuredSS-Data 20 ReleaseResources 21 mt-ForwardSM-VGCS 22 sendRoutingInfo 23 updateGprsLocation 24 sendRoutingInfoForGprs 25 failureReport 26 noteMsPresentForGprs 28 performHandover 29 sendEndSignal 30 performSubsequentHandover 31 provideSIWFSNumber 32 SIWFSSignallingModify 33 processAccessSignalling 34 forwardAccessSignalling 35 noteInternalHandover 37 reset 38 forwardCheckSS-Indication 39 prepareGroupCall 40 sendGroupCallEndSignal 41 processGroupCallSignalling 42 forwardGroupCallSignalling 43 checkIMEI Value Operation Name 44 MT-ForwardSM 45 sendRoutingInfoForSM 46 MO-ForwardSM 47 reportSM-DeliveryStatus 48 noteSubscriberPresent 49 alertServiceCentreWithoutResult 50 activateTraceMode 51 deactivateTraceMode 52 traceSubscriberActivity 54 beginSubscriberActivity 55 sendIdentification 56 sendAuthenticationInfo 57 restoreData 58 sendIMSI 59 processUnstructuredSSRequest 60 unstructuredSSRequest 61 unstructuredSSNotify 62 anyTimeSubscriptionInterrogation 63 informServiceCentre 64 alertServiceCentre 65 anyTimeModification 66 readyForSM 67 purgeMS 68 prepareHandover 69 prepareSubsequentHandover 70 provideSubscriberInfo 71 anyTimeInterrogation 72 SS-InvocationNotification 73 setReportingState Value Operation Name 74 statusReport 75 remoteUserFree 76 registerCC-Entry 77 eraseCC-Entry 78 secureTransportClass1 79 secureTransportClass2 80 secureTransportClass3 81 secureTransportClass4 83 provideSubscriberLocation 84 sendGroupCallInfo 85 sendRoutingInfoForLCS 86 subscriberLocationReport 87 IST-Alert 88 IST-Command 89 noteMM-Event 255 undefined field MAP Ð First Leg Application Error Code It represents the error code of the procedure at application layer (MAP) related to the first leg of the transaction in case of correlated generation. Value Error Name 1 unknownSubscriber 8 roamingNotAllowed 13 callBarred 15 cug-Reject 27 absentSubscriber 32 sm-DeliveryFailure Value Error Name 34 systemFailure 37 pw-RegistrationFailure 53 unauthorizedLCSClient 54 positionMethodFailure 21 facilityNotSupported 45 busySubscriber 31 subscriberBusyForMT-SMS 254 Invalid combination of Error Code and User ErrorReason MAP Ð First Leg Additional Error Reason This field specifies the error reason for those MAP transactions having error carrying additional information related to the first leg of the transaction in case of correlated generation. MAP Ð First Leg SMS Service Centre Time Stamp This filed is filled with the absolute time stamp that is offered to the recipient of a short message on when the message arrived at the SM-TL entity of the SC related to the first leg of the transaction in case of correlated generation. MAP Ð Last Leg Operation Code It represents the first operation invoked at MAP layer related to the last leg of the transaction in case of correlated generation. Value Operation Name 2 updateLocation 3 cancelLocation 4 provideRoamingNumber 5 noteSubscriberDataModified 6 resumeCallHandling 7 insertSubscriberData Value Operation Name 8 deleteSubscriberData 9 sendParameters 10 registerSS 11 eraseSS 12 activateSS 13 deactivateSS 14 interrogateSS 15 authenticationFailureReport 17 registerPassword 18 getPassword 19 processUnstructuredSS-Data 20 ReleaseResources 21 mt-ForwardSM-VGCS 22 sendRoutingInfo 23 updateGprsLocation 24 sendRoutingInfoForGprs 25 failureReport 26 noteMsPresentForGprs 28 performHandover 29 sendEndSignal 30 performSubsequentHandover 31 provideSIWFSNumber 32 SIWFSSignallingModify 33 processAccessSignalling 34 forwardAccessSignalling 35 noteInternalHandover 37 reset 38 forwardCheckSS-Indication 39 prepareGroupCall Value Operation Name 40 sendGroupCallEndSignal 41 processGroupCallSignalling 42 forwardGroupCallSignalling 43 checkIMEI 44 MT-ForwardSM 45 sendRoutingInfoForSM 46 MO-ForwardSM 47 reportSM-DeliveryStatus 48 noteSubscriberPresent 49 alertServiceCentreWithoutResult 50 activateTraceMode 51 deactivateTraceMode 52 traceSubscriberActivity 54 beginSubscriberActivity 55 sendIdentification 56 sendAuthenticationInfo 57 restoreData 58 sendIMSI 59 processUnstructuredSSRequest 60 unstructuredSSRequest 61 unstructuredSSNotify 62 anyTimeSubscriptionInterrogation 63 informServiceCentre 64 alertServiceCentre 65 anyTimeModification 66 readyForSM 67 purgeMS 68 prepareHandover Value Operation Name 69 prepareSubsequentHandover 70 provideSubscriberInfo 71 anyTimeInterrogation 72 SS-InvocationNotification 73 setReportingState 74 statusReport 75 remoteUserFree 76 registerCC-Entry 77 eraseCC-Entry 78 secureTransportClass1 79 secureTransportClass2 80 secureTransportClass3 81 secureTransportClass4 83 provideSubscriberLocation 84 sendGroupCallInfo 85 sendRoutingInfoForLCS 86 subscriberLocationReport 87 IST-Alert 88 IST-Command 89 noteMM-Event 255 undefined field MAP Ð Last Leg Application Error Code It represents the error code of the procedure at application layer (MAP) related to the first leg of the transaction in case of correlated generation. Value Error Name 1 unknownSubscriber 8 roamingNotAllowed Value Error Name 13 callBarred 15 cug-Reject 27 absentSubscriber 32 sm-DeliveryFailure 34 systemFailure 37 pw-RegistrationFailure 53 unauthorizedLCSClient 54 positionMethodFailure 21 facilityNotSupported 45 busySubscriber 31 subscriberBusyForMT-SMS 254 Invalid combination of Error Code and User ErrorReason MAP Ð Last Leg Additional Error Reason This field specifies the error reason for those MAP transactions having error carrying additional information related to the last leg of the transaction in case of correlated generation. MAP Ð Last Leg SMS Service Centre Time Stamp This filed is filled with the absolute time stamp that is offered to the recipient of a short message on when the message arrived at the SM-TL entity of the SC related to the last leg of the transaction in case of correlated generation. MAP - SMS Message Reference Number The TP Message Reference field gives an integer representation of a reference number of the SMS SUBMIT or SMS COMMAND submitted to the Service Centre by the Mobile station. MAP - GSM Absent Reason This parameter represents the reason why the subscriber is absent MAP - MSRN A Mobile Station Roaming Number (MSRN) is an E.164 defined telephone number used to route telephone calls in a mobile network from a GMSC (Gateway Mobile Switching Centre) to the target MSC. It can also be defined as a directory number temporarily assigned to a mobile for a mobile terminated call. (Reference GSM 09.02 V5.3.0, 8.3.3) MAP - USSD String This fields contains a string of unstructured information in an Unstructured Supplementary Service Data operation ItÕs filled by: Process Unstructured SS, Unstructured SS Request and Unstructured SS Notify whichever comes first in the sequence."
"Note: This field would be filled only in case of dcs value indicating 7-bit and will not be filled if in case dcs value is 8-bit/UCS2 as the support in application is temporarily not available. MAP - Service Centre Address This parameter designates the address of a short message service centre. This field may also be carried by SM-RP-DA and SM-RP-OA parameters. SMS Service Centre Address (Reference GSM 09.02, 5.6.2.27). MAP - SGSN Address This parameter designates the address of a SGSN. Update GPRS Location, Send Routing Info for GPRS and Note MS Present for GPRS messages may also carry this field. SGSN Address (Reference 3GPP TS 29.002 sec 7.6.2.39). MAP - GGSN Address This parameter designates the address of a GGSN. Update GPRS Location Failure Report and Note MS Present for GPRS messages may also carry this field. GGSN Address (Reference 3GPP TS 29.002 sec 7.6.2.40). MAP - Home GMLC Address This parameter refers to the IP address of Home Gateway mobile location centre. (3GPP TS 29.002 sec 7.6.2.61). ItÕs filled from: ProvideSubscriberLocation and SubscriberLocationReport operations. MAP - Visited GMLC Address This parameter refers to the IP address of Visitor Gateway mobile location centre. (3GPP TS 29.002 sec 7.6.2.59). ItÕs filled from: UpdateLocation, UpdateGprsLocation and RoutingInfoforLCS MAP - TP Origination Address Alphanumeric This field is filled from 'MAP_MO/MT_FORWARD_SHORT_MESSAGE and MT Forwared SM VGCSÕ in SM-RP-UI IE whichever comes first in the sequence. GSM 29.002, 7.6.2.11 Additional number: TS 100 974 V7.5.1, 7.6.2.46 + 12.1 MAP - TP Destination Address Alphanumeric This field is filled from 'MAP_MO/MT_FORWARD_SHORT_MESSAGE and MT Forwarded SM VGCSÕ in SM-RP-UI IE whichever comes first in the sequence. GSM 29.002, 7.6.2.11 Additional number: TS 100 974 V7.5.1, 7.6.2.46 + 12.1 MAP Ð TP Message Type Indicator This field specifies the SMS TP message type. MAP Ð SMS Delivery Time Interval This field identifies the SMS Delivery Time Interval by means of a lookup of the SMS Delivery Time field on MCLS table SMS Delivery Time Interval. MCLS Table: SMS Delivery Time Interval Standard Formatting: Column SDTI_INTERVAL_NAME SDTI _LOWER_VALUE SDTI _UPPER_VALUE Default value table: SMS Delivery Time Interval Name SMS Delivery Time Lower Value (s) SMS Delivery Time Upper Value (s) 0-6 s 0 6 7-11 s 7 11 12-30 s 12 30 >=30 30 Factor conversion: 1000 (from msec to sec) CAP Fields CAP - Operation Code It represents the first operation invoked at CAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement Value Operation Name 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest 56 ContinueWith Argument 60 initialDPSMS 61 furnish Charging InformationSMS 62 connectSMS 63 requestReportSMSEvent 64 eventReportSMS 65 continueSMS 66 releaseSMS 67 resetTimerSMS 70 activityTestGPRS 71 apply Charging GPRS 72 applyChargingReportGPRS 73 cancelGPRS 74 connectGPRS 75 continueGPRS 76 entityReleasedGPRS 77 furnishChargingInformationGPRS 78 initialDPGPRS 79 releaseGPRS 80 eventReportGPRS Value Operation Name 81 requestReportGPRSEvent 82 resetTimerGPRS 83 sendChargingInformationGPRS 90 DisconnectLeg 93 Move Leg 95 Split Leg 96 Entity Released 97 Play Tone 255 undefined field CAP - Last Operation Code It represents the last operation invoked at CAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 31 continue 32 InitiateCallAttempt Value Operation Name 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest 56 ContinueWith Argument 60 initialDPSMS 61 furnish Charging InformationSMS 62 connectSMS 63 requestReportSMSEvent 64 eventReportSMS 65 continueSMS 66 releaseSMS 67 resetTimerSMS 70 activityTestGPRS 71 apply Charging GPRS Value Operation Name 72 applyChargingReportGPRS 73 cancelGPRS 74 connectGPRS 75 continueGPRS 76 entityReleasedGPRS 77 furnishChargingInformationGPRS 78 initialDPGPRS 79 releaseGPRS 80 eventReportGPRS 81 requestReportGPRSEvent 82 resetTimerGPRS 83 sendChargingInformationGPRS 255 undefined field CAP - Operation Mask S.No Interpretation (Enumeration) Bit Position 1 Initial DP/GPRS/SMS 0 2 Apply charging / GPRS 1 3 Disconnect Forward Connection 2 4 ConnectToResource 3 5 Connect / GPRS /SMS 4 6 ReleaseCall / GPRS / SMS 5 7 Continue / GPRS / SMS 6 8 ResetTimer / GPRS /SMS 7 9 FurnishChargingInfo / GPRS / SMS 8 10 CallGap 9 11 CallInformationReport 10 S.No Interpretation (Enumeration) Bit Position 12 CallInformationRequest 11 13 PlayAnnouncement 12 14 PromptAddCollectUserInfo 13 15 SpecializedResourceReport 14 16 ActivityTest / GPRS 15 17 ApplyChargingReport / GPRS 16 18 Cancel / GPRS 17 19 AssistRequestInstructions 18 20 SendChargingInfo / GPRS 19 21 EntityReleasedGPRS 20 22 EventReportBCSM / GPRS / SMS 21 23 RequestReport BCSM/GPRS/SMS 22 24 EstablishTemporaryConnection 23 25 ContinueWithArgument 24 26 InitiateCallAttempt 25 27 DisconnectLeg 26 28 MoveLeg 27 29 SplitLeg 28 30 EntityReleased 29 31 PlayTone 30 32 Spare 31 CAP - Application Error Code It represents the error code of the procedure at application layer (CAP). Value Error Name 0 Cancelled 1 Cancel Failed 3 eTC Failed 4 Improper Caller Response 6 Missing Customer Record Value Error Name 7 Missing Parameters 8 Parameter Out of Range 10 Requested Info Error 11 System Failure 12 Task Refused 13 Unavailable Resource 14 Unexpected Component Sequence 15 Unexpected Data Value 16 Unexpected Parameter 17 Unknown Leg ID 50 Unknown PDP ID 51 Unknown CS ID CAP - Additional Error Reason This field specifies the error reason for those CAP transactions having error carrying additional information. Code Text 0 unknown Operation 1 tooLate 2 operationNotCancellable 3 unknownRequestedInfo 4 requestedInfoNotAvailable 5 unavailableResources 6 componentFailure Code Text 7 basicCallProcessingException 8 resourceStatusFailure 9 endUserFailure 10 generic 11 unobtainable 12 congestion CAP - Response Cause It is additional error at CAP layer. Release cause of CAP InitialDP, ReleaseCall, EventReportBCSM or CallInformationReport accordingly to Q.850. Cause value of RPcause of ReleaseSMS SMScause from EventSpecificInformation-SMS of EventReportSMS GPRScause of EntityReleasedGPRS or ReleaseGPRS Cause of ÒCallSegmentFailureÓ component present in ÒENTITY RELEASEDÓ ÒMO-SMSCauseÓ from ÒEventSpecificInformationSMSÓ of ÒEVENT REPORT SMSÓ ÒMT-SMSCauseÓ from ÒEventSpecificInformationSMSÓ of ÒEVENT REPORT SMSÓ Cause from ÒBCSM-FailureÓ of ÒENTITY RELEASEDÓ 1, unallocated (unassigned) number 2, no route to specified transit network 3, no route to destination 4, send special information tone 5, misdialled trunk prefix 6, channel unacceptable 7, call awarded and being delivered in an established channel 8, preemption 9, preemption - circuit reserved for reuse 16, normal call clearing 17, user busy 18, no user responding 19, no answer from user (user alerted) 20, subscriber absent 21, call rejected 22, number changed 26, non-selected user clearing 27, destination out of order 28, invalid number format (address incomplete) 29, facility rejected 30, response to STATUS ENQUIRY 31, normal, unspecified 34, no circuit/channel available 38, network out of order 39, permanent frame mode connection out of service 40, permanent frame mode connection operational 41, temporary failure 42, switching equipment congestion 43, access information discarded 44, requested circuit/channel not available 46, precedence call blocked 47, resource unavailable, unspecified 49, quality of service unavailable 50, requested facility not subscribed 53, outgoing calls barred within CUG 55, incoming calls barred within CUG 57, bearer capability not authorized 58, bearer capability not presently available 62, inconsistency in designated outgoing access information and subscriber class 63, service or option not availalbe, unspecified 65, bearer capability not implemented 66, channel type not implemented 69, requested facility not implemented 70, only restricted digital information bearer capability is available 79, service or option not implemented, unspecified 81, invalid call reference value 82, identified channel does not exist 83, A suspended call exists, but this call identity does not 84, call identity in use 85, no call suspended 86, call having the requested call identity has been cleared 87, user not member of CUG 88, incompatible destination 90, non-existent CUG 91, invalid transit network selection 95, invalid message, unspecified 96, mandatory information element is missing 97, message type non-existent or not implemented 98, message not compatible with call state or message type non-existent or not implemented 99, information element/parameter non-existent or not implemented 100, invalid information element contents 101, message not compatible with call state 102, recovery on timer expiry 103, parameter non-existent or not implemented, passed on 110, message with unrecognized parameter, discarded 111, protocol error, unspecified 127, interworking, unspecified 255, NO CC Cause CAP - Destination Routing Address C-party address (DestinationRoutingAddress). Filled From: Connect or DestinationSubscriberNumber from ConnectSMS or InitialDPSMS or part of EventSpecificInformation. Or EventReportBCSM CAP - Event Report Cause It is applicable for CAP CSDR only. Event Report Cause can be present in any of the sequence routeSelectFailureSpecificInfo, oCalledPartyBusySpecificInfo, oDisconnectSpecificInfo, tBusySpecificInfo, tDisconnectSpecificInfo and oAbandonSpecificInfo present in EventReportBCSM or CallInformationReport. EventReportCause Value Description 0 system failure 1 unallocated (unassigned) number 2 no route to specified transit network 3 no route to destination 4 send special information tone 5 misdialled trunk prefix 6 channel unacceptable 7 call awarded and being delivered in an established channel 8 preemption 9 preemption - circuit reserved for reuse 10 call barred 16 normal call clearing 17 user busy 18 no user responding 19 no answer from user (user alerted) 20 subscriber absent 21 call rejected EventReportCause Value Description 22 number changed 23 redirection to new destination 25 exchange routing error 26 non-selected user clearing 27 destination out of order 28 invalid number format (address incomplete) 29 facility rejected 30 response to STATUS ENQUIRY 31 normal, unspecified 34 no circuit/channel available 38 network out of order 39 permanent frame mode connection out of service 40 permanent frame mode connection operational 41 temporary failure 42 switching equipment congestion 43 access information discarded 44 requested circuit/channel not available 46 precedence call blocked 47 resource unavailable, unspecified 49 quality of service unavailable 50 requested facility not subscribed 53 outgoing calls barred within CUG 55 incoming calls barred within CUG 57 bearer capability not authorized EventReportCause Value Description 58 bearer capability not presently available 62 inconsistency in designated outgoing access information and subscriber class 63 service or option not availalbe, unspecified 65 bearer capability not implemented 66 channel type not implemented 69 requested facility not implemented 70 only restricted digital information bearer capability is available 79 service or option not implemented, unspecified 81 invalid call reference value 82 identified channel does not exist 83 A suspended call exists, but this call identity does not 84 call identity in use 85 no call suspended 86 call having the requested call identity has been cleared 87 user not member of CUG 88 incompatible destination 90 non-existent CUG 91 invalid transit network selection 95 invalid message, unspecified 96 mandatory information element is missing 97 message type non-existent or not implemented 98 message not compatible with call state or message type non-existent or not implemented EventReportCause Value Description 99 information element/parameter non-existent or not implemented 100 invalid information element contents 101 message not compatible with call state 102 recovery on timer expiry 103 parameter non-existent or not implemented, passed on 110 message with unrecognized parameter, discarded 111 protocol error, unspecified 127 interworking, unspecified 128 Request accepted 192 Non-existent 193 Invalid message format 194 IMSI not known 195 MS is GPRS Detached 196 MS is not GPRS Responding 197 MS Refuses 198 Version not supported 199 No resources available 200 Service not supported 201 Mandatory IE incorrect 202 Mandatory IE missing 203 Optional IE incorrect 204 System failure 205 Roaming restriction EventReportCause Value Description 206 P-TMSI Signature mismatch 207 GPRS connection suspended 208 Authentication failure 209 User authentication failed 210 Context not found 211 All dynamic PDP addresses are occupied 212 No memory is available 213 Relocation failure 214 Unknown mandatory extension header 215 Semantic error in the TFT operation 216 Syntactic error in the TFT operation 217 Semantic errors in packet filter(s) 218 Syntactic errors in packet filter(s) 219 Missing or unknown APN 220 Unknown PDP address or PDP type 221 PDP context without TFT already activated 222 APN access denied - no subscription 223 APN Restriction type incompatibility with currently active PDP Contexts 224 MS MBMS Capabilities Insufficient 225 Invalid Correlation-ID 226 MBMS Bearer Context Superseded 254 route not permitted CAP - Event Type The BCSM DP event triggering the InitialDP or the SMSEvent triggering the InitialDPSMS or the GPRSEvent triggering the InitialDPGPRS. In order to interpret this field the field OperationCode has to be taken into account. In case of CAMEL Phase 1 and 2, the following table is a reference for SRS. Code Text 1 orig Attempt Authorized 2 collect Info 3 analyzed Information 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect 18 TAbandon 255 undefined field CAP - Reported Event Code Text 1 orig Attempt Authorized 2 Collected Info 3 analyzed Information or detached 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 11 pdp-ContextEstablishment 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect 18 TAbandon 19 oTermSeized 27 callAccepted 50 oChangeOfPosition 51 tChangeOfPosition 255 Undefined field CAP Ð Cell Identity INAP Fields INAP - Operation Code It represents the first operation invoked at INAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 25 request notification charging event 26 event notification charging 27 collect information 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap Value Operation Name 42 activate service filtering 43 service filtering response 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest INAP - Last Operation Code It represents the last operation invoked at INAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 25 request notification charging event Value Operation Name 26 event notification charging 27 collect information 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 42 activate service filtering 43 service filtering response 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest INAP - Operation Mask1 By Default Opcode values refer to ETSI INAP (including CZECH INAP), for other INAP variants it is mentioned specifically. If it is unknown, opcode for particular variant it is not mentioned for that particular bit. Bit Position Opcode 0 (LSB) Initial DP In CHINA INAP: Initial DP In Siemens INAP: Initial DP In INAP LW: Initial DP In INAPCS1P: Initial DP In INAPCS2: Initial DP 1 In EINAPV21: Activate Resource In INAPCS2: OriginationAttemptAuthorized In INAPCS1P: ApplyCharging 2 In EINAPV21: Activity Test In INAPCS1P: ConnectToResource In INAPCS2: CollectedInformation 3 In EINAPV21: CongestionControl In INAP LW: Connect In INAPCS1P: Connect In INAPCS2: AnalysedInformation 4 In EINAPV21: Create In INAP LW: ReleaseCall In INAPCS1P: ReleaseCall In INAPCS2: RouteSelectFailure 5 In EINAPV21: Event In INAP LW: Continue In INAPCS1P: Continue In INAPCS2: OcalledPartyBusy 6 In EINAPV21: Free In INAP LW: ResetTimer In INAPCS1P: ResetTimer In INAPCS2: Onoanswer 7 In EINAPV21: Generate In INAPCS1P: FurnishChargingInformation Bit Position Opcode In INAPCS2: Oanswer 8 In EINAPV21: HandOver In INAPCS1P: CallGap In INAPCS2: Odisconnect 9 In EINAPV21: ChargingInformation In INAPCS1P: CallInformationReport In INAPCS2: TermAttemptAuthorized 10 In EINAPV21: Join In INAPCS1P: CallInformationRequest In INAPCS2: Tbusy 11 In EINAPV21: Monitor In INAPCS1P: Playannouncement In INAPCS2: Tnoanswer 12 In EINAPV21: OpenSpecificFunction In INAPCS1P: PromptAndCollectUserInformation In INAPCS2: Tanswer 13 In EINAPV21: ProvideInstructions In INAPCS1P: SpecializedResourceReport In INAPCS2: Tdisconnect 14 In EINAPV21: ReleaseResource In INAPCS1P: ApplyChargingReport In INAPCS2: Omidcall 15 In EINAPV21: Reset Timer In INAPCS1P: Cancel In INAPCS2: Tmidcall 16 AssistRequestInstructions In CHINA INAP: AssistRequestInstructions In Siemens INAP: AssistRequestInstructions In EINAPV21: Retrieve Bit Position Opcode In INAPCS2: AssistRequestInstructions In INAPCS1P: AssistRequestInstructions 17 EstablishTemporaryConnection In CHINA INAP: EstablishTemporaryConnection In Siemens INAP: EstablishTemporaryConnection In EINAPV21: SCF Reset Indication In INAPCS2: EstablishTemporaryConnection In INAPCS1P: SendChargingInformation 18 DisconnectForwardConnection In CHINA INAP: DisconnectForwardConnection In EINAPV21: Split In Siemens INAP: DisconnectForwardConnection In INAPCS2: DisconnectForwardConnection In INAPCS1P: EventReportBcsm 19 ConnectToResource In CHINA INAP: ConnectToResource In EINAPV21: SSF Reset Indication In INAPCS2: ConnectToResource In INAPCS1P: RequestReportBcsmEvent 20 Connect In CHINA INAP: Connect In EINAPV21: Transfer Control In Siemens INAP: Connect In INAPCS2: Connect In INAPCS1P: EstablishTemporaryConnection 21 In EINAPV21: Update In INAPCS2: HoldCallInNetwork In INAPCS1P: ActivateServiceFiltering 22 ReleaseCall In CHINA INAP: ReleaseCall Bit Position Opcode In EINAPV21: Backward Information In Siemens INAP: ReleaseCall In INAPCS2: ReleaseCall In INAPCS1P: CollectInformation 23 RequestReportBCSMEvent In EINAPV21: Call Control In CHINA INAP: RequestReportBCSMEvent In Siemens INAP: RequestReportBCSMEvent In INAPCS2: RequestReportBCSMEvent In INAPCS1P: EventNotificationCharging 24 EventReportBCSM In CHINA INAP: EventReportBCSM In Siemens INAP: EventReportBCSM In INAPCS2: EventReportBCSM In INAPCS1P: InitiateCallAttempt 25 RequestNotificationChargingEvent In Siemens INAP: RequestNotificationChargingEvent In INAPCS2: RequestNotificationChargingEvent In INAPCS1P: ServiceFilteringResponse 26 EventNotificationCharging In INAPCS2: EventNotificationCharging In Siemens INAP: EventNotificationCharging In INAPCS1P: RequestNotificationChargingEvent 27 CollectInformation In CHINA INAP: CollectInformation In Siemens INAP: CollectInformation In INAPCS2: CollectInformation In INAPCS1P: DisconnectForwardConnection 28 In INAPCS2: AnalyseInformation In INAPCS1P: ActivityTest Bit Position Opcode 29 In INAPCS2: SelectRoute 30 In INAPCS2: SelectFacility 31 Continue In CHINA INAP: Continue In Siemens INAP: Continue In INAPCS2: Continue INAP - Operation Mask2 Bit Position Opcode 0 InitiateCallAttempt In CHINA INAP: InitiateCallAttempt In Siemens INAP: InitiateCallAttempt In INAPCS2P: InitiateCallAttempt In INAPCS1P: Retrive 1 ResetTimer In CHINA INAP: ResetTimer In Siemens INAP: ResetTimer In INAPCS2: ResetTimer In INAPCS1P: Update 2 FurnishChargingInformation In CHINA INAP: FurnishChargingInformation In Siemens INAP: FurnishChargingInformation In INAPCS2: FurnishChargingInformation In INAPCS1P: CallLimit 3 ApplyCharging In CHINA INAP: ApplyCharging In Siemens INAP: ApplyCharging In INAPCS2P: ApplyCharging In INAPCS1P: DialogueUserInformation Bit Position Opcode 4 ApplyChargingReport In CHINA INAP: ApplyChargingReport In Siemens INAP: ApplyChargingReport In INAPCS2: ApplyChargingReport In INAPCS1P: HandOver 5 In INAPCS2: RequestCurrentStatusReport In INAPCS1P: HoldCallPartyConnection 6 In INAPCS1P: Reconnect In INAPCS2: RequestEveryStatusChangeReport 7 In INAPCS1P: ReleaseCallPartyConnection In INAPCS2: RequestFirstStatusMatchReport 8 In INAPCS1P: SignallingInformation In INAPCS2: StatusReport 9 CallGap In CHINA INAP: CallGap In INAPCS2: CallGap In Siemens INAP: CallGap In INAP LW: Continue With Argument In INAPCS1P: Continue With Argument 10 ActivateServiceFiltering In CHINA INAP: ActivateServiceFiltering In Siemens INAP: ActivateServiceFiltering In INAPCS2: ActivateServiceFiltering 11 ServiceFilteringResponse In CHINA INAP: ServiceFilteringResponse In Siemens INAP: ServiceFilteringResponse In INAPCS2: ServiceFilteringResponse 12 CallInformationReport In CHINA INAP: CallInformationReport Bit Position Opcode In INAPCS2: CallInformationReport In Siemens INAP: CallInformationReport 13 CallInformationRequest In CHINA INAP: CallInformationRequest In INAPCS2: CallInformationRequest In Siemens INAP: CallInformationRequest 14 SendChargingInformation In CHINA INAP: SendChargingInformation In Siemens INAP: SendChargingInformation In INAPCS2: SendChargingInformation 15 PlayAnnouncement In CHINA INAP: PlayAnnouncement In INAPCS2: PlayAnnouncement In Siemens INAP: PlayAnnouncement 16 PromptAndCollectUserInformation In CHINA INAP: PromptAndCollectUserInformation In Siemens INAP: PromptAndCollectUserInformation In INAPCS2: PromptAndCollectUserInformation 17 SpecializedResourceReport In CHINA INAP: SpecializedResourceReport In Siemens INAP: SpecializedResourceReport In INAPCS2: SpecializedResourceReport 18 Unknown opcode 19 Unknown opcode 20 Unknown opcode 21 Cancel In CHINA INAP: Cancel In Siemens INAP: Cancel In INAPCS2: Cancel Bit Position Opcode 22 In INAPCS2: CancelStatusReportRequest 23 ActivityTest In CHINA INAP: ActivityTest In Siemens INAP: ActivityTest In INAPCS2: ActivityTest 24 In Siemens INAP: ContinueWithArgument 25 Unknown opcode 26 Unknown opcode 27 Unknown opcode 28 In Siemens INAP: InitialDpSms 29 In Siemens INAP: FurnishChargingInformationSms 30 In Siemens INAP: ConnectSms 31 In Siemens INAP: RequestReportSmsEvent INAP - Operation Mask3 Bit Position Opcode 0 In Siemens INAP: EventReportSms 1 In Siemens INAP: ContinueSms 2 In Siemens INAP: ReleaseSms 3 In Siemens INAP: ResetTimerSms 4 Unknown opcode 5 Unknown opcode 6 In Siemens INAP: ActivityTestGprs 7 In Siemens INAP: ApplyChargingGprs 8 In Siemens INAP: ApplyChargingReportGprs Bit Position Opcode 9 In Siemens INAP: CancelGprs 10 In Siemens INAP: ConnectGprs 11 In Siemens INAP: ContinueGprs 12 In Siemens INAP: EntityReleasedGprs 13 In Siemens INAP: FurnishChargingInformationGprs 14 In Siemens INAP: InitialDpGprs 15 In Siemens INAP: ReleaseGprs 16 In Siemens INAP: EventReportGprs In INAPCS2: FacilitySelectedAndAvailable 17 In Siemens INAP: RequestReportGprsEvent In INAPCS2: OriginationAttempt 18 In Siemens INAP: ResetTimerGprs In INAPCS2: TerminationAttempt 19 In Siemens INAP: SendChargingInformationGprs In INAPCS2: Oabandon 20 In INAPCS2: Osuspended 21 In INAPCS2: Tsuspended 22 In Siemens INAP: DisconnectForwardConnectionWithArgument In INAPCS2: DisconnectForwardConnectionWithArgument 23 In INAPCS2: AuthorizeTermination 24 In Siemens INAP: ContinueWithArgument In INAPCS2: ContinueWithArgument 25 In INAPCS2: CreateCallSegmentAssociation 26 In Siemens INAP: DisconnectLeg In INAPCS2: DisconnectLeg Bit Position Opcode 27 In Siemens INAP: MergeCallSegments In INAPCS2: MergeCallSegments 28 In INAPCS2: MoveCallSegments 29 In CHINA INAP: ALC Split In INAPCS2: MoveLeg 30 In INAPCS2: Reconnect 31 In Siemens INAP: SplitLeg In INAPCS2: SplitLeg INAP - Operation Mask4 Bit Position Opcode 0 In Siemens INAP: EntityReleased In INAPCS2: EntityReleased 1 In INAPCS2: ManageTriggerData 2 In CHINA INAP: ALC Join In Siemens INAP: ManageTriggerData In INAPCS2: RequestReportUtsi 3 In CHINA INAP: ALC Free In Siemens INAP: ReleaseLeg 4 In INAPCS2: SendStui 5 In INAPCS2: ReportUtsi 6 In INAPCS2: SendFacilityInformation 7 In INAPCS2: RequestReportFacilityEvent 8 In INAPCS2: EventReportFacility 9 Unknown opcode 10 In INAPCS2: SendComponent Bit Position Opcode 11 In INAPCS2: PromptAndReceiveMessage 12 In INAPCS2: ScriptInformation 13 In Siemens INAP: ScriptEvent In INAPCS2: ScriptEvent 14 In Siemens INAP: ScriptRun In INAPCS2: ScriptRun 15 In INAPCS2: ScriptClose 16 In INAPCS2: EstablishChargingRecord 17 In INAPCS2: HandlingInformationRequest 18 In INAPCS2: HandlingInformationResult 19 In INAPCS2: NetworkCapability 20 In INAPCS2: NotificationProvided 21 In INAPCS2: ConfirmedNotificationProvided 22 In INAPCS2: ProvideUserInformation 23 In INAPCS2: ConfirmedReportChargingInformation 24 In INAPCS2: ReportchargingInformation 25 In INAPCS2: RequestNotification 26 In INAPCS2: ActivationReceivedAndAuthorized 27 In INAPCS2: InitiateAssociation 28 In INAPCS2: AssociationReleaseRequested 29 In INAPCS2: ComponentReceived 30 In INAPCS2: ReleaseAssociation 31 In INAPCS2: RequestReportBcusmEvent INAP - Application Error Code It represents the error code of the procedure at INAP application layer. INAP - Additional Error Reason This field specifies the error reason for those INAP transactions having error carrying additional information. Code Text 0 unknown Operation 1 tooLate 2 operationNotCancellable 3 unknownRequestedInfo 4 requestedInfoNotAvailable 5 unavailableResources 6 componentFailure 7 basicCallProcessingException 8 resourceStatusFailure 9 endUserFailure 10 generic 11 unobtainable 12 congestion INAP - Response Cause Indicates the reason for the release at INAP Layer. Release cause of EventReportBCSM or CallInformationReport or ReleaseCall. In case INAP LW only ReleaseCall can fill this field. In EINAPV21 this field is filled from CauseIndicator of Event / Free message, whichever comes first in the sequence. In China Inap, ALCFree can also fill this field. In INAPCS2, this field is filled from DisconnectLeg, OAbandon, ODisconnect, ReleaseCall, TDisconnect, EventReportBCSM, CallGap, ActivateServiceFiltering, NotificationProvidedMsg messages. INAP - Destination Routing Address INAP - Event Type The BCSM DP event triggering the InitialDP or the SMSEvent triggering the InitialDPSMS or the GPRSEvent triggering the InitialDPGPRS. In order to interpret this field the field OperationCode has to be taken into account. In case of CAMEL Phase 1 and 2, the following table is a reference for SRS. Code Text 1 orig Attempt Authorized 2 collect Info 3 analysed Information 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer Code Text 16 TMidCall 17 TDisconnect 18 TAbandon 255 undefined field INAP - Reported Event Code Text 1 orig Attempt Authorized 2 Collected Info 3 analyzed Information or detached 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 11 pdp-ContextEstablishment 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect Code Text 18 TAbandon 19 oTermSeized 27 callAccepted 50 oChangeOfPosition 51 tChangeOfPosition 255 Undefined field INAP - Generic Number CSDR Type CSDR field Description INAP_CSDR GENERIC_NUMBER This field contains the Number information sent in either direction to enhance network operation or for supplementary services Common Measures Common Ð Success The success field is used in conjunction with each data record type to categorize a data record transaction as successful or not. CSDR Type = CAP Value Name Success Failure 1 CAP Mobile Originating Call See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 2 CAP Mobile Terminating Call See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 3 CAP Mobile Originating SMS See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 4 CAP Mobile Terminating SMS See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 5 CAP MS Initiated PDP Context Activation See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 6 CAP NW Initiated PDP Context Activation See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table Value Name Success Failure 99 Other CAP procedure See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table CAP Success Rule A CAP transaction is considered ""successful"" when no errors occurred at CAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( CAP_ER_CODE is Empty OR (CAP_ER_CODE is NOT Network Error AND CAP_ER_CODE is NOT User Error) ) AND ( CAP_ER_REASON is Empty OR (CAP_ER_REASON is NOT Network Error AND CAP_ER_REASON is NOT User Error) ) AND ( CAP_CAUSE is Empty OR (CAP_CAUSE is NOT Network Error AND CAP_CAUSE is NOT User Error) ) AND ( TCAP_ABORT_CAUSE is Empty OR (TCAP_ABORT_CAUSE is NOT Network Error AND TCAP_ABORT_CAUSE is NOT User Error) ) AND ( SCCP_RETCAUSE is Empty OR (SCCP_RETCAUSE is NOT Network Error AND SCCP_RETCAUSE is NOT User Error) ) CAP Failure Rule A CAP transaction is considered ""Failed"" when an error occurred at CAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (CAP_ER_CODE is Network Error OR CAP_ER_CODE is User Error) ) OR ( (CAP_ER_REASON is Network Error OR CAP_ER_REASON is User Error) ) OR ( (CAP_CAUSE is Network Error OR CAP_CAUSE is User Error) ) OR ( (TCAP_ABORT_CAUSE is Network Error OR TCAP_ABORT_CAUSE is User Error) ) OR ( (SCCP_RETCAUSE is Network Error OR SCCP_RETCAUSE is User Error) ) CSDR Type = MAP Value Name Success Failure 100 MAP Update Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 101 MAP Cancel Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 102 MAP Provide Roaming Number See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 103 MAP Register SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 104 MAP Erase SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 105 MAP Activate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table Value Name Success Failure 106 MAP Deactivate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 107 MAP Interrogate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 108 MAP Send Routing Info See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 109 MAP Update GPRS Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 110 MAP Send Routing Info For GPRS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 111 MAP Mobile Terminating SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 112 MAP Send Routing Info For SM See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 113 MAP Mobile Originating SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table Value Name Success Failure 114 MAP Authentication See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 115 MAP Process Unstructured SS Request See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 116 MAP Unstructured SS Request See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 117 MAP Unstructured SS Notify See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 118 MAP Send Routing Info For LCS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 119 MAP Subscriber Location Report See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 120 MAP Ð Correlated SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 199 Other MAP procedure See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table MAP Success Rule A MAP transaction is considered ""successful"" when no errors occurred at MAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( MAP_ SCCP_RETCAUSE is Empty OR (MAP_ SCCP_RETCAUSE is NOT Network Error AND MAP_ SCCP_RETCAUSE is NOT User Error) ) AND ( MAP_ TCAP_ABORT_CAUSE is Empty OR (MAP_ TCAP_ABORT_CAUSE is NOT Network Error AND MAP_ TCAP_ABORT_CAUSE is NOT User Error) ) AND ( MAP_ER_CODE is Empty OR (MAP_ ER_CODE is NOT Network Error AND MAP_ ER_CODE is NOT User Error) ) MAP Failure Rule A MAP transaction is considered ""Failed"" when an error occurred at MAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (MAP_ SCCP_RETCAUSE is Network Error OR MAP_ SCCP_RETCAUSE is User Error) ) OR ( (MAP_ TCAP_ABORT_CAUSE is Network Error OR MAP_ TCAP_ABORT_CAUSE is User Error) ) OR ( (MAP_ ER_CODE is Network Error OR MAP_ ER_CODE is User Error) ) CSDR Type = INAP Value Name Success Failure 200 INAP Initial DP See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table 201 INAP Retrieve/Assist Request Instructions See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table 299 Other INAP procedure See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table INAP Success Rule An INAP transaction is considered ""successful"" when no errors occurred at INAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( INAP_ER_CODE is Empty OR (INAP_ER_CODE is NOT Network Error AND INAP_ER_CODE is NOT User Error) ) AND ( INAP_ER_REASON is Empty OR (INAP_ER_REASON is NOT Network Error AND INAP_ER_REASON is NOT User Error) ) AND ( INAP_CAUSE is Empty OR (INAP_CAUSE is NOT Network Error AND INAP_CAUSE is NOT User Error) ) AND ( TCAP_ABORT_CAUSE is Empty OR (TCAP_ABORT_CAUSE is NOT Network Error AND TCAP_ABORT_CAUSE is NOT User Error) ) AND ( SCCP_RETCAUSE is Empty OR (SCCP_RETCAUSE is NOT Network Error AND SCCP_RETCAUSE is NOT User Error) ) INAP Failure Rule An INAP transaction is considered ""Failed"" when an error occurred at INAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (INAP_ER_CODE is Network Error OR INAP_ER_CODE is User Error) ) OR ( (INAP_ER_REASON is Network Error OR INAP_ER_REASON is User Error) ) OR ( (INAP_CAUSE is Network Error OR INAP_CAUSE is User Error) ) OR ( (TCAP_ABORT_CAUSE is Network Error OR TCAP_ABORT_CAUSE is User Error) ) OR ( (SCCP_RETCAUSE is Network Error OR SCCP_RETCAUSE is User Error) ) CSDR Type = TCAP-AP Value Name Success Failure 300 TCAP-AP traffic TCAPAP_APPL_ERROR_CODE is NOT Network Error OR is EMPTY TCAPAP_APPL_ERROR_CODE is Network Error CSDR Type = BELL TCAP-OP Value Name Success Failure 400 TCAP OP Query (CNAM Service) (OP_ERROR_CODE is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) OP_ERROR_CODE is Network Error OR BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL TCAP-800 Value Name Success Failure 500 TCAP 800 Query (Toll Free Call) (ERROR_CODE_800 is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) ERROR_CODE_800 is Network Error OR BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL TCAP-800 Value Name Success Failure 600 AIN Query (ER_CODE is NOT Network Error OR is EMPTY) AND ER_CODE is Network Error OR Value Name Success Failure (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL LIDB Value Name Success Failure 700 LIDB Query (LIDB_ERROR_CODE is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) LIDB_ERROR_CODE is Network Error OR BTCAP_REJECT_PROBLEM is Network Error Common - Transaction Duration This field holds the time difference between the first and last message in the sequence (in units of milliseconds). This means that, in case of timeout sequences, the timer value will not be included in TransactionTime calculation. Common - Response Time Time in millisecond from the first invoke operation to the next operation in the other direction in case of full sequences. Common Ð Conversation Time It represents the total talk time for a MO/MT call (CAP/INAP layers). Common - Total Length of SCCP Messages It is the total length of SCCP messages in forward and backward direction. Common - Length of SCCP FWD Messages It is the total length of SCCP messages in forward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Length of SCCP BWD Messages It is the total length of SCCP messages in backward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Number of SCCP Messages It is the total number of SCCP messages in forward and backward direction. Common - Number of SCCP FWD Messages It is the total number of SCCP messages in forward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Number of SCCP BWD Messages It is the total number of SCCP messages in backward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP message to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common Ð Answered Call Applicable protocol: CAP, INAP This flag indicates if a call is either answe or not for CAP and INAP protocols. Common Ð Dropped Call Applicable protocol: CAP, INAP This flag indicates if a call is either dropped or not for CAP and INAP protocols. Note: a call can be considered droppped only when it is answered. MAP Measures MAP - SMS Payload Size This field contains the length of TP-UDL in octets from SM-RP-UI parameter. MAP Ð Number of MO SMS This field contains the number of SMS submitted by the subscriber."
"Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP Ð MO SMS Success This field indicates if the MO SMS was successfully submitted to the service centre. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP - Number of MT SMS This field counts the number of MT SMS delivered by the service centre. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP Ð MT SMS Success This field indicates if the MT SMS was successfully delivered to the final user. Note: MT SMS status report are not included in this measure, for those transactions use instead the Data Record Type 111 and Common- Success. MAP - Number of Concatenated SMS The number of concatenated SMS is calculated according to the last 5 bits of [MAP].FLAGS2 CSDR field converted in decimal. 16,17,18,19,20 Concatenated SMS Count 0 - No SMS 1 - SMS not concatenated 2 - 2 Concatenated SMS 3 - 3 Concatenated SMS 4 - 4 Concatenated SMS 5 - 5 Concatenated SMS 6 - 6 Concatenated SMS 7 - 7 Concatenated SMS 8 - 8 Concatenated SMS 9 - 9 Concatenated SMS 10 - 10 Concatenated SMS 11 - 11 Concatenated SMS 12 - 12 Concatenated SMS 13 Ð 13 Concatenated SMS 14 - 14 Concatenated SMS 15 - 15 Concatenated SMS 16 - 16 Concatenated SMS 17 - 17 Concatenated SMS 18 - 18 Concatenated SMS 19 - 19 Concatenated SMS 20 - 20 Concatenated SMS 21 - 21 Concatenated SMS 22 - 22 Concatenated SMS 23 - 23 Concatenated SMS 24 - 24 Concatenated SMS 25 - 25 Concatenated SMS 26 - 26 Concatenated SMS 27 - 27 Concatenated SMS 28 - 28 Concatenated SMS 29 - 29 Concatenated SMS 30 - 30 Concatenated SMS 31 - 31 or more concatenated SMS Description: This subfield represents the number of short messages in Long SMS which is filled from IE Maximum number of Short message. This value might differ from Number of MO SMS messages, Number of MT SMS messages CSDR fields. As the ÔMaximum number of Short messageÕ IE represents the total number of expected SM in entire sequence (and is same in all subsequent messages in sequence), the number will be accurate even when messages are missing in Sequence due to loadsharing. No additional computing at QXTS/QXDRS is required for this field. MAP Ð SMS Submit Time This field specifies the time needed to submit an SMS and it is calculated as the MAP transaction duration needed to forward the MO SMS to the Service Centre. MAP Ð SMS Delivery Time This field specifies the time needed to deliver the SMS and it is calculated as the time difference between ÒEnd Time Stamp Ð TP Service Centre TimeStampÓ in milliseconds 4 MCLS Enrichments for eoLive Cell MC table: Cell (Miner=YES) Lookup Type: Match Lookup DR Key MCLS Key Enriched description prefix CAP_CELL_IDENTITY Cell-ID CAP Ð Cell Identity Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Cell Name WITHRANK NO YES Type Type ALWAYS YES YES Group Cell Group ALWAYS NO YES Paging Domain Paging Domain ALWAYS NO YES Paging Area Code Paging Domain Code WITHRANK NO YES PLMN PLMN ID ALWAYS NO YES Radio Controller Node ID Radio Node ID WITHRANK NO NO Radio Controller Node Name Radio Node Name WITHRANK NO YES Core Node ID Controlling Node ID WITHRANK NO NO Core Node Name Controlling Node Name WITHRANK NO YES Core Pool Name Core Network Node Pool ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Latitude Latitude WITHRANK NO YES Longitude Longitude WITHRANK NO YES Broadcast Power Broadcast Power WITHRANK NO YES Azimuth Azimuth WITHRANK NO YES Beam Width Beam Width WITHRANK NO YES Frequency Bands Frequency Bands ALWAYS NO YES Region Region ALWAYS NO YES Manufacturer Manufacturer ALWAYS NO YES Operational Status Operational Status ALWAYS NO YES City City ALWAYS NO YES Province Province ALWAYS NO YES ZIP Code ZIP Code ALWAYS NO YES LAC LAC WITHRANK NO NO SAC SAC WITHRANK NO NO Note: Manufacturer, Operational Status, City, Province and ZIP Code are available only from MasterClaw 8.0. The miner functions (implemented either by MCLS or by DWH) will fill the following columns: á Name: It will be filled by CAP_CELL_IDENTITY á Paging Domain: It will be filled by [CAP].LOCATION_AREA_ID CSDR field Service Key MC table: ServiceKey (Miner=NO) Lookup Type: Match Key MCLS Key Enriched description prefix SERVICE_KEY Service_Key Common - Service Standard Formatting: Display Name Internal Name Aggregation Rank Enum Visible for Application (eoLive/BO) Name Name ALWAYS NO NO Group Group ALWAYS NO NO Layer Layer ALWAYS NO NO Cause MC table: Cause (Miner=NO) Lookup Type: Match Lookup DR Key MCLS Key Enriched description prefix ÒSCCP_RET_CAUSE: Ó + SCCP_RETCAUSE ID Common - SCCP Return Cause ÒTCAP: Ó + TCAP_ABORT_CAUSE Common - TCAP Abort Cause ÒTCAP_APPL: Ò + TCAPAP_APPL_ERROR_CODE TCAP AP - Application Error Code ÒBELL_TCAP_APPL: Ò + BTCAP_APPL_ERROR_CODE BELL TCAP - Application Error Code ÒBELL_TCAP_REJ: Ò + BTCAP_REJECT_PROBLEM BELL TCAP Ð Reject Problem ÒBELL_TCAP_800: Ò + BTCAP_TCAP_800_TERMINATION_INDICATOR BELL TCAP Ð TCAP 800 Termination Indication ÒBELL_TCAP_AIN: Ò + BTCAP_AINT_ERROR_CAUSE BELL TCAP - AIN Error Cause ÒMAP: Ò + MAP_FL_ER_CODE MAP - First Leg Application Error Code ÒMAP_USER_ERR: Ò + MAP_FL_USRERR_REASON MAP Ð First Leg Additional Error Reason ÒMAP: Ò + MAP_LL_ER_CODE MAP - Last Leg Application Error Code ÒMAP_USER_ERR: Ò + MAP_LL_USRERR_REASON MAP Ð Last Leg Additional Error Reason ÒCAP: Ò + CAP_ER_CODE CAP - Application Error Code ÒINAP_CAP_ADD_ERR: Ò + CAP_ER_REASON CAP - Additional Error Reason ÒQ.931: Ò + CAP_CAUSE CAP - Response Cause ÒQ.931: Ò + CAP_EVENT_REPORT_CAUSE CAP - Event Report Cause ÒINAP: Ò + INAP_ER_CODE INAP - Application Error Code ÒINAP_CAP_ADD_ERR: Ò + INAP_ER_REASON INAP - Additional Error Reason ÒQ.931: Ò + INAP_CAUSE INAP - Response Cause Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Type Type ALWAYS YES YES Code Code ALWAYS YES NO Description Name NEVER NO NO Group Group ALWAYS NO YES is Network Error NetworkError ALWAYS YES YES is User Error UserError ALWAYS YES YES Next Best Action Next best action NO is Drop Error DropError ALWAYS YES YES OperatorE212 MC Table: OperatorE212 (Miner= NO) Lookup Type: Prefix (for IMSI), Match (for PLMN_ID) DR Lookup Key MCLS Key Enriched description prefix IMSI Prefix Common Ð Subscriber PLMN_ID Common Ð PLMN ID Remember: All enriched fields of PLMN_ID must be NOT visible on eoLive/eoFinder Applications. ONLY the enriched field ÒCommon Ð PLMN ID Operator is HomeÓ is visible in eoLive/eoFinder Applications, because it is used in eoxdr component for the eoRoaming-CP-Core-SDR generation. Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Prefix Prefix ALWAYS NO YES Operator Name Name ALWAYS NO YES Operator Country Name Country ALWAYS NO YES Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES Operator MCC MCC ALWAYS NO YES Operator MNC MNC ALWAYS NO YES Operator Country Code CC ALWAYS NO NO (visible only in eoSight/InSight) Device MC Table: Device (Miner=ON) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix TAC TAC Common - Device Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Manufacturer Manufacturer ALWAYS NO YES Model Model WITH RANK NO YES Terminal Type Terminal Type ALWAYS YES YES OS Vendor OS Vendor ALWAYS NO YES OS Type OS Type ALWAYS YES YES OS Version OS Version ALWAYS NO YES GSM GSM ALWAYS YES YES UMTS UMTS ALWAYS YES YES LTE LTE ALWAYS YES YES Frequency Bands Frequency Bands ALWAYS NO NO Display Size Primary Display Size ALWAYS NO YES Group Group ALWAYS NO YES Test Group Test Group ALWAYS NO YES Make and Model MakeAndModel WITH RANK NO YES CertifiedDevice MC Table: CertifiedDevice (Miner = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix IMEI IMEI Common Ð Certified Device Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) TAC TAC WITH RANK NO NO Serial Number Serial Number ALWAYS NO NO Software Version Software Version ALWAYS NO YES is Subsidized Subsidized ALWAYS YES YES is Certified Certified ALWAYS YES YES MobileSubscriber MC Table: MobileSubscriber (Miner = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix IMSI IMSI Common - Subscriber Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Name WITH FILTER NO YES Gender Gender ALWAYS YES YES Birth Date Birth Date WITH RANK NO YES Birth Place Birth Place WITH RANK NO YES Home Place Home Place WITH RANK NO YES Subscription Start Date Subscription start date WITH RANK NO YES Type Type ALWAYS YES YES Importance Importance ALWAYS YES YES Enterprise Name Enterprise name WITH RANK NO YES Department Name Enterprise part WITH RANK NO YES Plan Plan ALWAYS NO YES Options Options WITH RANK NO YES Notes Notes WITH RANK NO YES Tariff Tariff Plan ALWAYS YES YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Service Segment Service Segment ALWAYS YES YES Enterprise Importance Enterprise Importance ALWAYS YES YES Department Importance Enterprise part Importance ALWAYS YES YES Enterprice Description Enterprice Description NEVER NO NO Enterprice Part Description Enterprice part Description NEVER NO NO FixedSubscriber MC Table: FixedSubscriber (MINER = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix CALLING_PARTY ISDN Common - Calling Party CALLED_PARTY Common - Called Party MSISDN Common - User Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Name WITH FILTER NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Gender Gender ALWAYS YES YES Birth Date Birth Date WITH RANK NO YES Birth Place Birth Place WITH RANK NO YES Home Place Home Place WITH RANK NO YES Subscription Start Date Subscription start date WITH RANK NO YES Type Type ALWAYS YES YES Importance Importance ALWAYS YES YES Enterprise Name Enterprise name WITH RANK NO YES Department Name Enterprise part WITH RANK NO YES Plan Plan ALWAYS NO YES Options Options WITH RANK NO YES Notes Notes WITH RANK NO YES Tariff Tariff Plan ALWAYS YES YES Service Segment Service Segment ALWAYS YES YES Enterprise Importance Enterprise Importance ALWAYS YES YES Department Importance Enterprise part Importance ALWAYS YES YES Enterprice Description Enterprice Description NEVER NO NO Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Enterprice Part Description Enterprice part Description NEVER NO NO Operator Prefix MC Table: OperatorPrefix (MINER = NO) Lookup type: Prefix Key MCLS Key Enriched description prefix CALLING_NO Prefix Common - Calling Party CALLED_NO Common - Called Party MAP_MSRN MAP Ð MSRN MSISDN Common Ð MSISDN SCCP_CALLED_PARTY Common - SCCP Called Party Global Title SCCP_CALLING_PARTY Common - SCCP Calling Party Global Title MAP_SERVCENT_ADDR MAP - Service Centre Address LOCATION_INFO Common Ð Network Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Prefix Prefix ALWAYS NO YES Operator Name Name ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Country Name Country ALWAYS NO YES Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES Operator Country Code CC ALWAYS NO NO Operator National Destination Code NDC ALWAYS NO NO IMSIPrefix MC Table: IMSIPrefix (Miner = NO) Lookup type: Prefix Lookup DR Key MCLS Key Enriched description prefix IMSI Prefix Common - Subscriber Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Prefix ALWAYS NO YES Prefix Name Name ALWAYS NO YES Prefix Description Description NEVER NO YES Prefix Group Group ALWAYS NO YES Prefix Group 2 Group2 ALWAYS NO YES ISDNPrefix MCLS table: ISDNPrefix (Miner = NO) Lookup type=Prefix Lookup DR Key MCLS Key Enriched description prefix CALLING_NO Prefix Common - Calling Party CALLED_NO Common - Called Party INAP_GENERIC_NUMBER INAP - Generic Number Standard Formatting: Display Name Internal Name eolive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Prefix ALWAYS NO YES Display Name Internal Name eolive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Name Name ALWAYS NO YES Prefix Description Description NEVER NO YES Prefix Group Group ALWAYS NO YES Prefix Group 2 Group2 ALWAYS NO YES Operator Signalling Point MCLS table: OperatorSP (Miner = NO) Lookup type=Match DR Lookup Key MCLS Key Enriched description prefix SOURCE_SP SP Name Common - First Leg Source Signalling Point DEST_SP Common Ð First Leg Destination Signalling Point LL_SOURCE_SP Common Ð Last Leg Source Signalling Point LL_DEST_SP Common Ð Last Leg Destination Signalling Point SCCP_CALLING_SP Common Ð SCCP Calling Party Number Signalling Point SCCP_CALLED_SP Common Ð SCCP Called Party Number Signalling Point Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Name Name ALWAYS NO YES Operator Country Name Country ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES 5 Monitored procedures This table contains a list of procedures supported by the TDR format. It shall be considered as example. Procedure/Activity CSDR Failure/Success Additional Info Mobile Originating Call CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country, IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, Call Duration, CAP Operation Code, Event Type, Reported Event, Destination Address, Location Information, TAC Mobile Terminating Call CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, Call Duration, CAP Operation Code, Event Type, Reported Event, Destination Address, Location Information, TAC Mobile Originating SMS CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, CAP Operation Code, Event Type, Reported Event, Location Information, TAC Mobile Terminating SMS CAP Event Report Cause / CAP Application Error Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, CAP Operation Code, Event Type, Reported Event, Location Information, TAC MS Initiated PDP Context Activation CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, CAP Operation Code, Event Type, Reported Event,TAC NW Initiated PDP Context Activation CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, CAP Operation Code, Event Type, Reported Event, TAC Update Location MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Cancel Location MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Procedure/Activity CSDR Failure/Success Additional Info Code, Location Information Provide Roaming Number MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Register SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Erase SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Activate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Deactivate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Interrogate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, SS Code Set, MAP Operation Code Send Routing Info MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Update GPRS Location MAP MAP Application Error Code/Additional MAP Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Error Reason/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Send Routing Info For GPRS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Mobile Terminating SMS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Send Routing Info For SM MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code Mobile Originating SMS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Authentication MAP MAP Application Error Code/Additional MAP Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Error Reason/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Process Unstructured SS Request MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Unstructured SS Request MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Unstructured SS Notify MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI,MAP Timeout, Back Calling Number, MAP Operation Code Send Routing Info For LCS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Subscriber Location Report MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code,TAC 6 Appendix A. Property field definition Binary Formats The binary format may assume one of the followings values: Format Description BF_INTEGER Integer value. The size column specifies the integer type: 1 = byte 2 = word 4 = dword 8 = qword BF_BYTES Bytes The size column specifies the number of bytes. BF_STRING String of characters. The size column specifies the max length. BF_FLOATING Floating. The size is ignored. Display Format The display format may assume one of the following formats: Format Description DF_DIGIT It identifies a BCD number DF_STRING The value is displayed as a sequence of Latin-1 characters. DF_ENUM Only the description associated to the value is displayed, e.g.: Test Call Format Description DF_DEC_ENUM Both value, as decimal number, and description are displayed, e.g.: 13 Test Call DF_HEX_ENUM Both value, as hexadecimal number, and description are displayed, e.g.: C4 nTUP DF_ABSOLUTE_TIME The field is a date shown as: ""yyyy-MM-dd HH:mm:ss"". DF_RELATIVE_TIME The field is a date shown as: ""HH:mm:ss.SSS"". DF_BINARY_ENUM The field is displayed in binary form. DF_POINT_CODE The fiels is a point code, e.g: 2-112-0 Broendby DF_CIC The field is a CIC, eg: 127-31 DF_DEC The field is displayed as a decimal value. DF_HEX The field is displayed as a hexadecimal value. DF_IP The field is displayed as an IP address (either IPv4 or IPv6) according to [RFC2373]. DF_FIXEDPOINT The field is a floating number, e.g.: 3.69 DF_BOOLEAN The field is a Boolean, e.g. 0 False DF_FULLYQUALIFIED_POINT_CODE The fiels is a point code, e.g: 2-112-0 Broendby Text Format The text format (used only when DR are generated in csv format) may assume one of the following formats: Format Description DF_STRING DF_DEC DF_HEX Special Property The special property may assume one of the following formats: Special Property Description SP_SUBSCRIBER_MARKER The field represents a Subscriber identifier. SP_START_TIME The field represents the start time of a dialogue/trail. SP_END_TIME The field represents the end time of a dialogue/trail. SP_IMSI The field represents an IMSI. SP_MSISDN The field represents a MSISDN. SP_SOURCE_ADDRESS The field represents an originating address, e.g. Originating Point Code or Source IP Address. SP_DESTINATION_ADDRESS The field represents a destination address, e.g. Destination Point Code or Destination IP Address. SP_OTHER_ADDRESS The field represents an address that cannot be categorized as Source or Destination. SP_GLOBALTITLE The field represents a Global Title, e.g. SCCP Calling Numer. SP_CALLTRACEJUMP The field represent an ID used by the client application to jump to CSDR and PDU details. Aggregation Roles The aggregation role of a field could be: Role Description AR_AGGREGABLE_ALWAYS The field can always be aggregated. AR_AGGREGABLE_WITHFILTER The field can be aggregated only if the eoLive User impose filter on this field to reduce the number of different values. AR_AGGREGABLE_NEVER The field can never be used in aggregation. AR_AGGREGABLE_WITHRANK The field can be used in aggregation but only in presence of rank operation (e.g. Top). 3GPP TS 23.078 V17.0.0 (2022-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; Stage 2 (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. Keywords UMTS, GSM, CAMEL, stage 2, network 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2020, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved."
"UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 19 1 Scope 20 1.1 Support of partial implementation of CAMEL phaseÊ4 21 1.1.1 CAMEL PhaseÊ4 CSIs 21 1.1.2 CAMEL PhaseÊ4 Functionalities 21 2 References 23 3 Definitions and abbreviations 26 3.1 Definitions 26 3.2 Abbreviations 28 4 Circuit switched Call Control 30 4.1 Architecture 30 4.1.1 Functional Entities used for CAMEL 30 4.1.2 Interfaces defined for CAMEL 31 4.1.2.1 HLR - VLR interface 31 4.1.2.2 GMSC - HLR interface 31 4.1.2.3 GMSC - gsmSSF interface 31 4.1.2.4 gsmSSF - gsmSCF interface 31 4.1.2.5 MSC - gsmSSF interface 31 4.1.2.6 gsmSCF - HLR interface 31 4.1.2.7 gsmSCF - gsmSRF interface 31 4.1.2.8 GMSC - MSC interface 31 4.2 Detection Points (DPs) 32 4.2.1 Definition and description 32 4.2.1.1 Arming/disarming mechanism 32 4.2.1.2 Criteria 33 4.2.1.2.1 Criteria at DPÊCollected_Info 33 4.2.1.2.2 Criteria at DPÊAnalysed_Information 34 4.2.1.2.3 Criteria at DPÊRoute_Select_Failure 36 4.2.1.2.4 Criteria at DPÊTerminating_Attempt_Authorised 36 4.2.1.2.5 Criteria at DPÊT_Busy and T_No_Answer 37 4.2.1.3 Relationship 37 4.2.2 DP processing rules 38 4.3 Description of CAMEL Subscriber Data 38 4.3.1 Originating CAMEL Subscription Information (O CSI) 38 4.3.1.1 TDP List 38 4.3.1.2 gsmSCF address 38 4.3.1.3 Service Key 38 4.3.1.4 Default Call Handling 38 4.3.1.5 DP criteria 38 4.3.1.6 CAMEL Capability Handling 39 4.3.1.7 CSI state 39 4.3.1.8 Notification flag 39 4.3.2 Dialled Service CAMEL Subscription Information (D CSI) 39 4.3.2.1 DP criteria 39 4.3.2.2 gsmSCF address 39 4.3.2.3 Service Key 39 4.3.2.4 Default Call Handling 39 4.3.2.5 CAMEL Capability Handling 39 4.3.2.6 CSI state 39 4.3.2.7 Notification flag 40 4.3.3 Network CAMEL Service Information (N CSI) 40 4.3.4 Translation Information Flag CAMEL Subscription Information (TIF CSI) 40 4.3.4.1 Translation Information Flag 40 4.3.4.2 Notification flag 40 4.3.5 Terminating CAMEL Subscription Information (in the GMSC) (T CSI) 40 4.3.5.1 TDP List 40 4.3.5.2 gsmSCF address 40 4.3.5.3 Service Key 40 4.3.5.4 Default Call Handling 40 4.3.5.5 DP criteria 41 4.3.5.6 CAMEL Capability Handling 41 4.3.5.7 CSI state 41 4.3.5.8 Notification flag 41 4.3.6 VMSC Terminating CAMEL Subscription Information (VT CSI) 41 4.3.6.1 TDP List 41 4.3.6.2 gsmSCF address 41 4.3.6.3 Service Key 41 4.3.6.4 Default Call Handling 41 4.3.6.5 DP criteria 41 4.3.6.6 CAMEL Capability Handling 41 4.3.6.7 CSI state 42 4.3.6.8 Notification flag 42 4.3.7 Other CAMEL data 42 4.3.7.1 Location information/Subscriber state Interrogation 42 4.3.7.2 gsmSCF address list for CSI 42 4.3.8 Trunk Originated CAMEL Service Information (TO-CSI) 42 4.4 Description of CAMEL BCSMs 43 4.4.1 General Handling 43 4.4.2 Originating Basic Call State Model (O BCSM) 43 4.4.2.1 Description of O BCSM 43 4.4.2.1.1 Description of the call model (PICs) 45 4.4.3 Terminating Basic Call State Model (T BCSM) 49 4.4.3.1 Description of T BCSM 49 4.4.3.1.1 Description of the call model (PICs) 50 4.4.4 Rules for Implicit Disarming of Event Detection Points 53 4.4.5 BCSM Modelling of Call Scenarios 55 4.4.5.1 Mobile Originated Call 55 4.4.5.2 Mobile Terminated Call at the GMSC or VMSC 55 4.4.5.3 Call Forwarding at the GMSC or VMSC 56 4.4.5.4 gsmSCF Initiated Call 57 4.4.5.5 Trunk Originated Call 57 4.4.6 Leg Handling 58 4.4.6.1 Leg is created 58 4.4.6.2 Leg continues to exist 58 4.4.6.3 Leg is released 59 4.4.6.4 Leg is moved 59 4.5 Procedures for CAMEL 59 4.5.1 Overall SDL architecture 59 4.5.2 Handling of mobile originated calls 65 4.5.2.1 Handling of mobile originated calls in the originating MSC 65 4.5.2.1.1 Actions of the MSC on receipt of Int_Error 66 4.5.2.1.2 Actions of the MSC on receipt of Int_Continue 66 4.5.2.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument 66 4.5.2.1.4 Actions of the MSC on receipt of Int_Connect 66 4.5.2.1.5 Actions of the MSC on receipt of Int_Release_Call 67 4.5.2.1.6 Actions of the MSC on receipt of Int_Disconnect_Leg (Leg 2) 67 4.5.2.1.7 Actions of the MSC on receipt of Int_Apply_Warning_Tone 67 4.5.2.1.8 Action of the MSC in procedure CAMEL_OCH_MSC_ANSWER 67 4.5.2.1.9 Action of the MSC in procedure CAMEL_OCH_ETC 68 4.5.2.1.10 Procedure CAMEL_OCH_LEG1_MSC 68 4.5.2.1.11 Process CAMEL_O_CHANGE_OF_POSITION_MSC 68 4.5.2.1.12 Procedure CAMEL_Start_TNRy 68 4.5.2.2 Handling of mobile originating calls in the originating VLR 148 4.5.3 Retrieval of routeing information 151 4.5.3.1 Retrieval of routeing information in the GMSC 151 4.5.3.1.1 Action of the GMSC on receipt of Int_Release_Call 151 4.5.3.1.2 Action of the GMSC on receipt of Int_Error 151 4.5.3.1.3 Action of the GMSC on receipt of Int_Continue 152 4.5.3.1.4 Action of the GMSC on receipt of Int_Continue_With_Argument 152 4.5.3.1.5 Action of the GMSC on receipt of Int_Connect 152 4.5.3.1.6 Action of the GMSC on receipt of Send_Routeing_Info Negative Response (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.7 Action of the GMSC on receipt of Send_Routeing_Info ack with MSRN (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.8 Action of the GMSC on receipt of Send_Routeing_Info ack with FTN (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.9 Action of the GMSC on receipt of Send_Routeing_Info ack with O CSI and/or D CSI and FTN (at state Wait_For_Routeing_Info_2) 153 4.5.3.1.10 Action of the GMSC in procedure CAMEL_MT_ETC 153 4.5.3.1.11 Action of the GMSC in procedure CAMEL_MT_GMSC_Notify_CF 153 4.5.3.1.12 Action of the MSC on receipt of Int_Disconnect_Leg (Leg 2) 153 4.5.3.2 Retrieval of routeing information in the HLR 207 4.5.3.3 Handling of provide roaming number request in the VLR 215 4.5.4 Handling of mobile terminating calls 217 4.5.4.1 Handling of mobile terminating calls in the terminating VMSC 217 4.5.4.1.1 Action of the VMSC in procedure CAMEL_MT_VMSC_Notify_CF 217 4.5.4.1.2 Action of MSC on receipt of Int_Disconnect_Leg (Leg 2) 217 4.5.4.1.3 Procedure CAMEL_ICH_LEG2_MSC 218 4.5.4.1.4 Process CAMEL_T_CHANGE_OF_POSITION_MSC 218 4.5.4.2 Handling of mobile terminating calls in the VLR 255 4.5.5 Handling of forwarded calls 257 4.5.5.1 Procedure CAMEL_CF_MSC_INIT: handling of Int_Continue_With_Argument 257 4.5.5.2 Procedure CAMEL_CF_MSC_INIT: handling of Int_Connect 257 4.5.5.3 Procedure CAMEL_CF_MSC_INIT: handling of Int_Disconnect_Leg (Leg 2) 257 4.5.5.4 Action of the MSC in procedure CAMEL_CF_MSC_ANSWER 257 4.5.5.5 Action of the MSC in procedure CAMEL_CF_ETC 258 4.5.6 Handling of gsmSCF initiated calls 304 4.5.6.1 Handling of gsmSCF initiated calls in the MSC 304 4.5.6.1.1 Actions of the MSC on receipt of Int_Error 304 4.5.6.1.2 Actions of the MSC on receipt of Int_Continue 304 4.5.6.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument 304 4.5.6.1.4 Actions of the MSC on receipt of Int_Disconnect_Leg 304 4.5.6.1.5 Actions of the MSC on receipt of Int_Release_Call 304 4.5.6.2 Handling of gsmSCF initiated calls in the VLR 323 4.5.7 Handling of mobile calls in the gsmSSF 326 4.5.7.1 Call duration control 326 4.5.7.1.1 Information flow for call duration control 326 4.5.7.1.2 Audible indicators for call duration control 329 4.5.7.2 The gsmSCF control of e values 329 4.5.7.2.1 Procedure Handle_SCI 329 4.5.7.2.2 Process Tsw_For_SCI 330 4.5.7.3 Behaviour of the gsmSSF in the process CS_gsmSSF 333 4.5.7.3.1 Actions of the gsmSSF on receipt of CAP_Request_Report_BCSM_Event (in the state Waiting_For_Instructions) 333 4.5.7.3.2 Actions of the gsmSSF on receipt of CAP_Continue (in the state Waiting_For_Instructions) 333 4.5.7.3.3 Actions of the gsmSSF on receipt of CAP_Release_Call (in the state Monitoring) 333 4.5.7.3.4 Actions of the gsmSSF on receipt of Int_DP_T_Busy or Int_DP_T_No_Answer including the parameter Call Forwarded (in the state Monitoring) 333 4.5.7.4 Outstanding Request Counter and Rules for CAMEL 333 4.5.7.5 Process CS_gsmSSF and procedures 334 4.5.7.6 Process gsmSSF_SSME_FSM and procedures 412 4.5.7.7 Process CSA_gsmSSF and procedures 416 4.5.8 Assisting case 440 4.5.9 Procedure CAMEL_Provide_Subscriber_Info 450 4.5.10 CAMEL specific handling of location updating and data restoration 453 4.5.11 Cross phase compatibility 453 4.5.12 Handling of North American Carrier Information 453 4.5.13 Handling of trunk originated calls 453 4.5.13.1 Procedure CAMEL_TOC_Dialled_Services 454 4.5.13.2 Procedure CAMEL_TOC_MSC_INIT 454 4.5.13.3 Procedure CAMEL_NDS_TOC_INIT 454 4.5.13.4 Procedure CAMEL_TOC_LEG1_MSC 454 4.6 Description of information flows 474 4.6.1 gsmSSF to gsmSCF information flows 475 4.6.1.1 Activity Test ack 475 4.6.1.1.1 Description 475 4.6.1.1.2 Information Elements 475 4.6.1.2 Apply Charging Report 475 4.6.1.2.1 Description 475 4.6.1.2.2 Information Elements 475 4.6.1.3 Call Information Report 476 4.6.1.3.1 Description 476 4.6.1.3.2 Information Elements 476 4.6.1.4 Disconnect Leg ack 477 4.6.1.4.1 Description 477 4.6.1.4.2 Information Elements 477 4.6.1.5 Entity Released 477 4.6.1.5.1 Description 477 4.6.1.5.2 Information Elements 477 4.6.1.6 Event Report BCSM 477 4.6.1.6.1 Description 477 4.6.1.6.2 Information Elements 477 4.6.1.7 Initiate Call Attempt ack 481 4.6.1.7.1 Description 481 4.6.1.7.2 Information Elements 481 4.6.1.8 Initial DP 482 4.6.1.8.1 Description 482 4.6.1.8.2 Information Elements 482 4.6.1.9 Move Leg ack 488 4.6.1.9.1 Description 488 4.6.1.9.2 Information Elements 488 4.6.1.10 Split Leg ack 488 4.6.1.10.1 Description 488 4.6.1.10.2 Information Elements 488 4.6.2 gsmSCF to gsmSSF information flows 488 4.6.2.1 Activity Test 488 4.6.2.1.1 Description 488 4.6.2.1.2 Information Elements 488 4.6.2.2 Apply Charging 488 4.6.2.2.1 Description 488 4.6.2.2.2 Information Elements 489 4.6.2.3 Call Gap 490 4.6.2.3.1 Description 490 4.6.2.3.2 Information Elements 490 4.6.2.4 Call Information Request 492 4.6.2.4.1 Description 492 4.6.2.4.2 Information Elements 492 4.6.2.5 Cancel 492 4.6.2.5.1 Description 492 4.6.2.5.2 Information Elements 492 4.6.2.5A Collect Information 493 4.6.2.5A.1 Description 493 4.6.2.5A.2 Information Elements 493 4.6.2.6 Connect 493 4.6.2.6.1 Description 493 4.6.2.6.2 Information Elements 493 4.6.2.7 Connect To Resource 495 4.6.2.7.1 Description 495 4.6.2.7.2 Information Elements 495 4.6.2.8 Continue 496 4.6.2.8.1 Description 496 4.6.2.8.2 Information Elements 496 4.6.2.9 Continue With Argument 496 4.6.2.9.1 Description 496 4.6.2.9.2 Information Elements 497 4.6.2.10 Disconnect Forward Connection 498 4.6.2.10.1 Description 498 4.6.2.10.2 Information Elements 498 4.6.2.11 Disconnect Forward Connection With Argument 499 4.6.2.11.1 Description 499 4.6.2.11.2 Information Elements 499 4.6.2.12 Disconnect Leg 499 4.6.2.12.1 Description 499 4.6.2.12.2 Information Elements 499 4.6.2.13 Establish Temporary Connection 499 4.6.2.13.1 Description 499 4.6.2.13.2 Information Elements 499 4.6.2.14 Furnish Charging Information 500 4.6.2.14.1 Description 500 4.6.2.14.2 Information Elements 500 4.6.2.15 Initiate Call Attempt 501 4.6.2.15.1 Description 501 4.6.2.15.2 Information Elements 501 4.6.2.16 Move Leg 501 4.6.2.16.1 Description 501 4.6.2.16.2 Information Elements 501 4.6.2.17 Play Tone 502 4.6.2.17.1 Description 502 4.6.4.17.2 Information Elements 502 4.6.2.18 Release Call 502 4.6.2.18.1 Description 502 4.6.2.18.2 Information Elements 502 4.6.2.19 Request Report BCSM Event 503 4.6.2.19.1 Description 503 4.6.2.19.2 Information Elements 503 4.6.2.20 Reset Timer 505 4.6.2.20.1 Description 505 4.6.2.20.2 Information Elements 505 4.6.2.21 Send Charging Information 505 4.6.2.21.1 Description 505 4.6.2.21.2 Information Elements 506 4.6.2.22 Split Leg 506 4.6.2.22.1 Description 506 4.6.2.22.2 Information Elements 507 4.6.3 Optional (Service logic dependent) gsmSCF to gsmSRF information flows 507 4.6.3.1 Activity Test 507 4.6.3.1.1 Description 507 4.6.3.1.2 Information Elements 507 4.6.3.2 Cancel 507 4.6.3.2.1 Description 507 4.6.3.2.2 Information Elements 507 4.6.3.3 Play Announcement 507 4.6.3.3.1 Description 507 4.6.3.3.2 Information Elements 508 4.6.3.4 Prompt And Collect User Information 508 4.6.3.4.1 Description 508 4.6.3.4.2 Information Elements 508 4.6.4 gsmSRF to gsmSCF information flows 509 4.6.4.1 Activity Test ack 509 4.6.4.1.1 Description 509 4.6.4.1.2 Information Elements 509 4.6.4.2 Assist Request Instructions 510 4.6.4.2.1 Description 510 4.6.4.2.2 Information Elements 510 4.6.4.3 Prompt And Collect User Information ack 510 4.6.4.3.1 Description 510 4.6.4.3.2 Information Elements 510 4.6.4.4 Specialized Resource Report 510 4.6.4.4.1 Description 510 4.6.4.4.2 Information Elements 510 4.6.5 gsmSCF to Assisting SSF information flows 510 4.6.5.1 Activity Test 510 4.6.5.1.1 Description 510 4.6.5.1.2 Information Elements 510 4.6.5.2 Cancel 511 4.6.5.2.1 Description 511 4.6.5.2.2 Information Elements 511 4.6.5.3 Connect To Resource 511 4.6.5.3.1 Description 511 4.6.5.4 Disconnect Forward Connection 511 4.6.5.4.1 Description 511 4.6.5.4.2 Information Elements 511 4.6.5.5 Play Announcement 511 4.6.5.5.1 Description 511 4.6.5.6 Prompt And Collect User Information 511 4.6.5.6.1 Description 511 4.6.5.7 Reset Timer 511 4.6.5.7.1 Description 511 4.6.6 Assisting SSF to gsmSCF information flows 512 4.6.6.1 Activity Test ack 512 4.6.6.1.1 Description 512 4.6.6.1.2 Information Elements 512 4.6.6.2 Assist Request Instructions 512 4.6.6.2.1 Description 512 4.6.6.3 Prompt And Collect User Information ack (received information) 512 4.6.6.3.1 Description 512 4.6.6.4 Specialized Resource Report 512 4.6.6.4.1 Description 512 4.6.7 HLR to VLR information flows 512 4.6.7.1 Delete Subscriber Data 512 4.6.7.1.1 Description 512 4.6.7.1.2 Information Elements 512 4.6.7.2 Insert Subscriber Data 513 4.6.7.2.1 Description 513 4.6.7.2.2 Information Elements 513 4.6.7.3 Provide Subscriber Info 513 4.6.7.3.1 Description 513 4.6.7.4 Provide Roaming Number 514 4.6.7.4.1 Description 514 4.6.7.4.2 Information Elements 514 4.6.8 VLR to HLR information flows 514 4.6.8.1 Insert Subscriber Data ack 514 4.6.8.1.1 Description 514 4.6.8.1.2 Information Elements 515 4.6.8.2 Provide Subscriber Info ack 515 4.6.8.2.1 Description 515 4.6.8.3 Update Location 515 4.6.8.3.1 Description 515 4.6.8.3.2 Information Elements 515 4.6.8.4 Restore Data 515 4.6.8.4.1 Description 515 4.6.8.4.2 Information Elements 516 4.6.9 HLR to GMSC information flows 516 4.6.9.1 Send Routeing Info ack 516 4.6.9.1.1 Description 516 4.6.9.1.2 Information Elements 516 4.6.10 GMSC to HLR information flows 517 4.6.10.1 Send Routeing Info 517 4.6.10.1.1 Description 517 4.6.10.1.2 Information Elements 518 4.6.11 VMSC to GMSC information flows 518 4.6.11.1 Resume Call Handling 518 4.6.11.1.1 Description 518 4.6.11.1.2 Information Elements 518 4.6.12 MSC to VLR information flows 519 4.6.12.1 Send Info For ICA 519 4.6.12.1.1 Description 519 4.6.12.1.2 Information Elements 519 4.6.12.2 Send Info For Incoming Call 519 4.6.12.2.1 Description 519 4.6.12.2.2 Information Elements 519 4.6.12.3 Send Info For MT Reconnected Call 519 4.6.12.3.1 Description 519 4.6.12.3.2 Information Elements 519 4.6.12.4 Send Info For Outgoing Call 520 4.6.12.4.1 Description 520 4.6.12.4.2 Information Elements 520 4.6.12.5 Send Info For Reconnected Call 520 4.6.12.5.1 Description 520 4.6.12.5.2 Information Elements 520 4.6.13 VLR to MSC information flows 520 4.6.13.1 Complete Call 520 4.6.13.1.1 Description 520 4.6.13.1.2 Information Elements 521 4.6.13.2 Continue CAMEL Handling 521 4.6.13.2.1 Description 521 4.6.13.2.2 Information Elements 521 4.6.13.3 Process Call Waiting 522 4.6.13.3.1 Description 522 4.6.13.3.2 Information Elements 522 4.6.13.4 Send Info For ICA negative response 522 4.6.13.4.1 Description 522 4.6.13.4.2 Information Elements 522 4.6.13.5 Send Info For Incoming Call ack 522 4.6.13.5.1 Description 522 4.6.13.5.1 Information Elements 522 4.6.13.6 Send Info For Incoming Call negative response 523 4.6.13.6.1 Description 523 4.6.13.6.2 Information Elements 523 4.6.13.7 Send Info For MT Reconnected Call ack 523 4.6.13.7.1 Description 523 4.6.13.7.2 Information Elements 523 4.6.13.8 Send Info For MT Reconnected Call negative response 523 4.6.13.8.1 Description 523 4.6.13.8.2 Information Elements 523 4.6.13.9 Send Info For Reconnected Call ack 524 4.6.13.9.1 Description 524 4.6.13.9.2 Information Elements 524 4.6.13.10 Send Info For Reconnected Call negative response 524 4.6.13.10.1 Description 524 4.6.13.10.2 Information Elements 524 4.6.14 Internal MSC information flows 524 4.6.14.1 Perform Call Forwarding ack 524 4.6.14.1.1 Description 524 4.6.14.1.2 Information Elements 524 4.6.15 gsmSCF to HLR information flows 524 4.6.15.1 Send Routeing Info 524 4.6.15.1.1 Description 524 4.6.15.1.2 Information Elements 525 4.6.16 HLR to gsmSCF information flows 525 4.6.16.1 Send Routeing Info ack 525 4.6.16.1.1 Description 525 4.6.16.2 Send Routeing Info negative response 525 4.6.16.2.1 Description 525 4.7 Interaction with supplementary services 526 4.7.1 Line identification 526 4.7.2 Call forwarding services 526 4.7.2.1 Registration of Call Forwarding 526 4.7.2.2 Invocation of Call Forwarding 527 4.7.2.3 Invocation of Call Deflection 528 4.7.3 Call Barring services 528 4.7.4 Closed User Group 528 5 USSD to/from gsmSCF 529 5.1 Architecture 529 5.1.1 Functional Entities used for CAMEL 529 5.1.2 Interfaces defined for CAMEL 530 5.1.2.1 gsmSCF - HLR interface 530 5.2 Description of CAMEL Subscriber Data 530 5.2.1 USSD CAMEL Subscription Information (U CSI) 530 5.2.1.1 Service Code 530 5.2.1.2 gsmSCF address 530 5.3 Content of the USSD General CAMEL Service Information (UG CSI) 530 5.3.1 Service Code 530 5.3.2 gsmSCF address 530 5.4 Procedures 530 5.4.1 MS Initiated USSD 530 5.4.2 gsmSCF Initiated USSD 531 5.5 Description of information flows 531 5.5.1 gsmSCF to HLR information flows 531 5.5.1.1 Unstructured SS Request 531 5.5.1.1.1 Description 531 5.5.1.1.2 Information Elements 531 5.5.1.2 Unstructured SS Notify 532 5.5.1.2.1 Description 532 5.5.1.2.2 Information Elements 532 5.5.1.3 Process Unstructured SS Data ack 532 5.5.1.3.1 Description 532 5.5.1.3.2 Information Elements 532 5.5.1.4 Process Unstructured SS Request ack 532 5.5.1.4.1 Description 532 5.5.1.4.2 Information Elements 532 5.5.2 HLR to gsmSCF information flows 533 5.5.2.1 Unstructured SS Request ack 533 5.5.2.1.1 Description 533 5.5.2.1.2 Information Elements 533 5.5.2.2 Unstructured SS Notify ack 533 5.5.2.2.1 Description 533 5.5.2.2.2 Information Elements 533 5.5.2.3 Process Unstructured SS Data 533 5.5.2.3.1 Description 533 5.5.2.3.2 Information Elements 533 5.5.2.4 Process Unstructured SS Request 533 5.5.2.4.1 Description 533 5.5.2.4.2 Information Elements 533 5.5.2.5 Begin Subscriber Activity 534 5.5.2.5.1 Description 534 5.5.2.5.2 Information Elements 534 6 GPRS interworking 534 6.1 Architecture 534 6.1.1 Functional Entities used for CAMEL 534 6.1.2 Interfaces defined for CAMEL 535 6.1.2.1 SGSN - gprsSSF interface 535 6.1.2.2 gprsSSF - gsmSCF interface 535 6.1.2.3 HLR - SGSN interface 535 6.2 Detection Points (DPs) 535 6.2.1 Definition and description 535 6.2.2 Relationship, DP processing rules and GPRS dialogue 536 6.3 Description of CAMEL Subscriber Data 536 6.3.1 GPRS CAMEL Subscription Information (GPRS CSI) 536 6.3.1.1 gsmSCF Address 536 6.3.1.2 Service Key 536 6.3.1.3 Default GPRS Handling 536 6.3.1.4 TDP List 536 6.3.1.5 CAMEL Capability Handling 537 6.3.1.6 CSI state 537 6.3.1.7 Notification flag 537 6.3.2 gsmSCF address list for CSI 537 6.4 Description of CAMEL State Models 537 6.4.1 General Handling 537 6.4.2 GPRS Attach/Detach State Model 537 6.4.2.1 Description of the Attach/Detach model (PIAs) 538 6.4.2.1.1 Detached 538 6.4.2.1.2 Attached 539 6.4.3 GPRS PDP Context State Model 539 6.4.3.1 Description of the PDP Context model (PIAs) 540 6.4.3.1.1 Idle 541 6.4.3.1.2 PDP Context Setup 541 6.4.3.1.3 PDP Context Established 541 6.4.3.1.4 Change of Position Context 542 6.4.4 GPRS CAMEL Scenarios 542 6.4.4.1 GPRS CAMEL Scenario 1 542 6.4.4.2 GPRS CAMEL Scenario 2 543 6.4.5 SGSN Routeing Area Update 544 6.4.5.1 Intra-SGSN Routeing Area Update 544 6.4.5.2 Inter-SGSN Routeing Area Update 544 6.4.6 Rules for Implicit Disarming of Detection Points 545 6.5 Procedures for CAMEL GPRS 546 6.5.1 Overall SDL Architecture 546 6.5.2 Handling GPRS in the SGSN 546 6.5.2.1 Actions of the SGSN on receipt of Int_Error 547 6.5.2.2 Actions of the SGSN on receipt of Int_Continue 547 6.5.2.3 Handling of GPRS Attach/Detach 548 6.5.2.4 Handling of GPRS Routeing Area Update 551 6.5.2.5 Handling of PDP Context establishment and deactivation 555 6.5.3 Handling GPRS in the gprsSSF 561 6.5.3.1 Process GPRS_SSF 561 6.5.3.2 Process GPRS_Dialogue_Handler 561 6.5.3.3 Procedure Handle_AC_GPRS 561 6.5.3.4 Procedure Handle_ACR_GPRS 561 6.5.3.5 Procedure Complete_FCI_Record_GPRS 562 6.5.3.6 Procedure Handle_SCI_GPRS 562 6.5.3.6.1 Handling of SCI_GPRS for the Session 562 6.5.3.6.2 Handling of SCI_GPRS for a PDP Context 563 6.5.3.7 Procedure Handle_PDP_Acknowledgement 564 6.5.3.8 GPRS duration and volume control 564 6.5.3.8.1 Examples of information flows for GPRS session and PDP context control 564 6.5.3.8.2 TC guard timer 567 6.5.3.9 SDL diagrams for process GPRS_SSF and procedures 569 6.6 Description of information flows 606 6.6.1 gprsSSF to gsmSCF Information Flows 606 6.6.1.1 Activity Test GPRS ack 606 6.6.1.1.1 Description 606 6.6.1.1.2 Information Elements 606 6.6.1.2 Apply Charging Report GPRS 606 6.6.1.2.1 Description 606 6.6.1.2.2 Information Elements 606 6.6.1.3 Entity Released GPRS 607 6.6.1.3.1 Description 607 6.6.1.3.2 Information Elements 607 6.6.1.4 Event Report GPRS 607 6.6.1.4.1 Description 607 6.6.1.4.2 Information Elements 608 6.6.1.5 Initial DP GPRS 610 6.6.1.5.1 Description 610 6.6.1.5.2 Information Elements 610 6.6.2 gsmSCF to gprsSSF Information Flows 611 6.6.2.1 Activity Test GPRS 611 6.6.2.1.1 Description 611 6.6.2.1.2 Information Elements 611 6.6.2.2 Apply Charging GPRS 612 6.6.2.2.1 Description 612 6.6.2.2.2 Information Elements 612 6.6.2.3 Apply Charging Report GPRS ack 612 6.6.2.3.1 Description 612 6.6.2.3.2 Information Elements 612 6.6.2.4 Cancel GPRS 612 6.6.2.4.1 Description 612 6.6.2.4.2 Information Elements 612 6.6.2.5 Connect GPRS 613 6.6.2.5.1 Description 613 6.6.2.5.2 Information Elements 613 6.6.2.6 Continue GPRS 613 6.6.2.6.1 Description 613 6.6.2.6.2 Information Elements 613 6.6.2.7 Entity Released GPRS ack 613 6.6.2.7.1 Description 613 6.6.2.7.2 Information Elements 613 6.6.2.8 Event Report GPRS ack 613 6.6.2.8.1 Description 613 6.6.2.8.2 Information Elements 614 6.6.2.9 Furnish Charging Information GPRS 614 6.6.2.9.1 Description 614 6.6.2.9.2 Information Elements 614 6.6.2.10 Release GPRS 615 6.6.2.10.1 Description 615 6.6.2.10.2 Information Elements 615 6.6.2.11 Request Report GPRS Event 615 6.6.2.11.1 Description 615 6.6.2.11.2 Information Elements 615 6.6.2.12 Reset Timer GPRS 615 6.6.2.12.1 Description 615 6.6.2.12.2 Information Elements 616 6.6.2.13 Send Charging Information GPRS 616 6.6.2.13.1 Description 616 6.6.2.13.2 Information Elements 616 6.6.3 HLR to SGSN Information Flows 617 6.6.3.1 Delete Subscriber Data 617 6.6.3.1.1 Description 617 6.6.3.1.2 Information Elements 617 6.6.3.2 Insert Subscriber Data 617 6.6.3.2.1 Description 617 6.6.3.2.2 Information Elements 617 6.6.4 SGSN to HLR Information Flows 617 6.6.4.1 Insert Subscriber Data ack 617 6.6.4.1.1 Description 617 6.6.4.1.2 Information Elements 618 6.6.4.2 Update GPRS Location 618 6.6.4.2.1 Description 618 6.6.4.2.2 Information Elements 618 7 Short Message Services 618 7.1 Architecture 618 7.1.1 Functional Entities used for CAMEL 618 7.1.2 Interfaces defined for CAMEL 620 7.1.2.1 HLR - VLR interface 620 7.1.2.2 HLR - SGSN interface 620 7.1.2.3 gsmSSF - gsmSCF interface 620 7.1.2.4 gprsSSF - gsmSCF interface 620 7.1.2.5 MSC - gsmSSF interface 620 7.1.2.6 SGSN - gprsSSF interface 621 7.1.2.7 MSC - VLR interface 621 7.1.2.8 MSC - SMSC interface 621 7.1.2.9 SGSN - SMSC interface 621 7.2 Detection Points (DPs) 621 7.2.1 Criteria at DP SMS Delivery Request 621 7.3 Description of CAMEL Subscriber Data 621 7.3.1 Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI) 621 7.3.1.1 gsmSCF address 621 7.3.1.2 Service Key 621 7.3.1.3 Default SMS Handling 621 7.3.1.4 TDP List 622 7.3.1.5 CAMEL Capability Handling 622 7.3.1.6 CSI state 622 7.3.1.7 Notification flag 622 7.3.2 Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI) 622 7.3.2.1 gsmSCF address 622 7.3.2.2 Service Key 622 7.3.2.3 Default SMS Handling 622 7.3.2.4 TDP List 622 7.3.2.5 DP criteria 622 7.3.2.6 CAMEL Capability Handling 622 7.3.2.7 CSI state 622 7.3.2.8 Notification flag 623 7.3.3 gsmSCF address list for CSI 623 7.4 Description of SMS State Models 623 7.4.1 General Handling 623 7.4.2 Mobile Originating SMS State Models 623 7.4.2.1 Description of MO SMS state model 623 7.4.2.1.1 Description of the MO SMS state model (PIAs) 624 7.4.3 Mobile Terminating SMS State Model 625 7.4.3.1 Description of MT SMS state model 625 7.4.3.1.1 Description of the MT SMS state model (PIAs) 626 7.5 Procedures for CAMEL SMS 628 7.5.1 Functional architecture for CAMEL MO SMS services 628 7.5.2 Handling of mobile originating SMS 628 7.5.2.1 Handling of mobile originating SMS in the originating MSC or SGSN 628 7.5.2.1.1 Actions of the MSC or SGSN on receipt of Int_Error 629 7.5.2.1.2 Actions of the MSC or SGSN on receipt of Int_Continue_SMS 629 7.5.2.1.3 Actions of the MSC or SGSN on receipt of Int_Connect_SMS 629 7.5.2.1.4 Actions of the MSC or SGSN on receipt of Int_Release_SMS 629 7.5.2.1.5 Allocation of SMS Reference Number 629 7.5.2.2 Handling of A_MM_Release and A_LLC_Release 629 7.5.2.3 Handling of time-out from SMSC 629 7.5.2.4 Handling of mobile originating SMS in the VLR 634 7.5.3 Functional architecture for CAMEL MT SMS services 636 7.5.4 Handling of mobile terminating SMS 636 7.5.4.1 Handling of mobile terminating SMS in the terminating MSC or SGSN 636 7.5.4.1.1 Procedure CAMEL_T_SMS_INIT; 637 7.5.4.1.2 Procedure CAMEL_T_SMS_DELIVERED 637 7.5.4.1.3 Procedure CAMEL_T_SMS_FAILURE 637 7.5.4.1.4 Allocation of SMS Reference Number 638 7.5.4.2 Handling of mobile terminating SMS in the VLR 643 7.5.4.3 CAMEL subscription check for mobile terminating SMS in the SGSN 645 7.5.5 Handling of mobile originating and mobile terminating SMS in the gsmSSF or gprsSSF 647 7.5.5.1 Process SMS_SSF 647 7.5.5.2 Process Complete_SMS_FCI_Record 647 7.6 Description of information flows 657 7.6.1 gsmSSF or gprsSSF to gsmSCF information flows 657 7.6.1.1 Event Report SMS 657 7.6.1.1.1 Description 657 7.6.1.1.2 Information Elements 657 7.6.1.2 Initial DP SMS 657 7.6.1.2.1 Description 657 7.6.1.2.2 Information Elements 658 7.6.2 gsmSCF to gsmSSF or gprsSSF information flows 660 7.6.2.1 Connect SMS 660 7.6.2.1.1 Description 660 7.6.2.1.2 Information Elements 660 7.6.2.2 Continue SMS 660 7.6.2.2.1 Description 660 7.6.2.2.2 Information Elements 660 7.6.2.3 Furnish Charging Information SMS 660 7.6.2.3.1 Description 660 7.6.2.3.2 Information Elements 661 7.6.2.4 Release SMS 661 7.6.2.4.1 Description 661 7.6.2.4.2 Information Elements 661 7.6.2.5 Request Report SMS Event 661 7.6.2.5.1 Description 661 7.6.2.5.2 Information Elements 662 7.6.2.6 Reset Timer SMS 662 7.6.2.6.1 Description 662 7.6.2.6.2 Information Elements 662 7.6.3 HLR to VLR or SGSN information flows 662 7.6.3.1 Delete Subscriber Data 662 7.6.3.1.1 Description 662 7.6.3.1.2 Information Elements 662 7.6.3.2 Insert Subscriber Data 662 7.6.3.2.1 Description 662 7.6.3.2.2 Information Elements 662 7.6.4 VLR or SGSN to HLR information flows 663 7.6.4.1 Insert Subscriber Data ack 663 7.6.4.2 Update Location 663 7.6.4.3 Update GPRS Location 663 7.6.4.3.1 Description 663 7.6.4.3.2 Information Elements 663 7.6.5 VLR to MSC Information Flows 664 7.6.5.1 Continue CAMEL SMS Handling 664 7.6.5.1.1 Description 664 7.6.5.1.2 Information Elements 664 7.6.5.2 Send Info For MO SMS ack 664 7.6.5.2.1 Description 664 7.6.5.2.2 Information Elements 664 7.6.6 MSC to VLR Information Flows 664 7.6.6.1 Send Info For MT SMS 664 7.6.6.1.1 Description 664 7.6.6.1.2 Information Elements 664 8 SS Notifications 665 8.1 Architecture 665 8.1.1 Functional Entities used for CAMEL 665 8.1.2 Interfaces defined for SS Notifications 665 8.1.2.1 MSC - gsmSCF interface 665 8.1.2.2 HLR - gsmSCF interface 665 8.1.2.3 VLR - MSC interface 666 8.1.2.4 HLR-VLR interface 666 8.2 Description of CAMEL Subscriber Data 666 8.2.1 Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI) 666 8.2.1.1 Notification criteria 666 8.2.1.2 gsmSCF address 666 8.2.1.3 CSI state 666 8.2.1.4 Notification flag 666 8.2.2 gsmSCF address list for CSI 666 8.3 Procedures for CAMEL 666 8.3.1 Handling of Supplementary Service Invocation Notification 666 8.4 Description of information flows 667 8.4.1 MSC to gsmSCF information flows 667 8.4.1.1 SS Invocation Notification 667 8.4.1.1.1 Description 667 8.4.1.1.2 Information Elements 668 8.4.2 HLR to VLR information flows 668 8.4.2.1 Delete Subscriber Data 668 8.4.2.1.1 Description 668 8.4.2.1.2 Information Elements 668 8.4.2.2 Insert Subscriber Data 668 8.4.2.2.1 Description 668 8.4.2.2.2 Information Elements 668 8.4.3 HLR to gsmSCF information flows 668 8.4.3.1 SS Invocation Notification 668 8.4.3.1.2 Information Elements 669 8.4.4 VLR to MSC information flows 669 8.4.4.1 Invoke SS result 669 8.4.4.1.1 Description 669 8.4.4.1.2 Information Elements 669 8.4.4.2 Send Info For Incoming Call ack 669 8.4.4.2.1 Description 669 8.4.4.2.2 Information Elements 669 9 Mobility Management 670 9.1 Architecture 670 9.1.1 Functional Entities used for CAMEL 670 9.1.2 Interfaces defined for CAMEL 671 9.1.2.2 VLR - gsmSCF interface 671 9.1.2.3 SGSN - gsmSCF interface 671 9.2 Description of CAMEL Subscriber Data 671 9.2.1 Mobility Management CAMEL Subscription Information (M CSI) 671 9.2.1.1 Mobility Management Triggers 671 9.2.1.2 gsmSCF address 671 9.2.1.3 Service Key 671 9.2.1.4 CSI state 672 9.2.1.5 Notification flag 672 9.2.2 Mobility Management for GPRS CAMEL Subscription Information (MG CSI) 672 9.2.2.1 Mobility Management Triggers 672 9.2.2.2 gsmSCF address 672 9.2.2.3 Service Key 672 9.2.2.4 CSI state 672 9.2.2.5 Notification flag 672 9.2.3 gsmSCF address list for CSI 672 9.3 Procedures for Mobility management 673 9.3.1 Procedures for Mobility management for CS subscriber 673 9.3.1.1 Procedure descriptions 675 9.3.1.1.1 Procedure Set_Notification_Type 675 9.3.1.1.2 Procedure Notify_gsmSCF 677 9.3.2 Procedures for Mobility management for GPRS subscriber 679 9.3.2.1 Procedure CAMEL_PS_Notification 680 9.4 Description of information flows 684 9.4.1 VLR or SGSN to gsmSCF information flows 684 9.4.1.1 Mobility Management event Notification 684 9.4.1.1.1 Description 684 9.4.1.1.2 Information Elements 684 9.4.2 SGSN to HLR information flows 685 9.4.2.1 Update GPRS Location 685 9.4.3 VLR to HLR information flows 685 9.4.3.1 Update Location 685 9.4.3.2 Restore Data 685 9.4.4 HLR to VLR or SGSN information flows 685 9.4.4.1 Delete Subscriber Data 685 9.4.4.1.1 Description 685 9.4.4.1.2 Information Elements 685 9.4.4.2 Insert Subscriber Data 686 9.4.4.2.1 Description 686 9.4.4.2.2 Information Elements 686 10 Control and interrogation of subscription data 687 10.1 Architecture 687 10.1.1 Functional Entities used for CAMEL 687 10.1.2 Interfaces defined for CAMEL 687 10.1.2.1 gsmSCF - HLR 687 10.2 Procedures for CAMEL 687 10.2.1 Any Time Subscription Interrogation 687 10.2.2 Any Time Modification 690 10.2.3 Notify Subscriber Data Change 707 10.3 Description of information flows 710 10.3.1 gsmSCF to HLR information flows 710 10.3.1.1 Any Time Modification Request 710 10.3.1.1.1 Description 710 10.3.1.1.2 Information Elements 710 10.3.1.2 Any Time Subscription Interrogation Request 712 10.3.1.2.1 Description 712 10.3.1.2.2 Information Elements 713 10.3.1.3 Notify Subscriber Data Change response 713 10.3.1.3.1 Description 713 10.3.1.3.2 Information Elements 714 10.3.2 HLR to gsmSCF information flows 714 10.3.2.1 Any Time Modification ack 714 10.3.2.1.1 Description 714 10.3.2.1.2 Information Elements 714 10.3.2.2 Any Time Subscription Interrogation ack 716 10.3.2.2.1 Description 716 10.3.2.2.2 Information Elements 716 10.3.2.3 Notify Subscriber Data Change 718 10.3.2.3.1 Description 718 10.3.2.3.2 Information Elements 719 10.3.3 IP-SM-GW to HLR information flows 721 10.3.3.1 Any Time Modification Request 721 10.3.3.1.1 Description 721 10.3.3.1.2 Information Elements 721 10.3.4 HLR to IP-SM-GW information flows 721 10.3.4.1 Any Time Modification ack 721 10.3.4.1.1 Description 721 10.3.4.1.2 Information Elements 722 11 Subscriber Location and State retrieval 722 11.1 Architecture 722 11.1.1 Functional Entities used for CAMEL 722 11.1.2 Interfaces defined for CAMEL 723 11.1.2.1 gsmSCF - GMLC interface 723 11.1.2.2 GMLC - gsmSCF interface 723 11.1.2.3 gsmSCF - HLR 723 11.1.2.4 HLR - gsmSCF 724 11.1.2.5 HLR - SGSN 724 11.1.2.5 SGSN - HLR 724 11.2 Procedures for CAMEL 724 11.2.1 Location Services 724 11.2.2 Any Time Interrogation 726 11.2.3 Provide Subscriber Information in the SGSN 728 11.2.3.1 Procedure CAMEL_Provide_Subscriber_Info_SGSN 728 11.2.3.2 Procedure CAMEL_Active_Info_Retrieval_SGSN 728 11.3 Description of information flows 734 11.3.1 gsmSCF to GMLC information flows 734 11.3.1.1 Any Time Interrogation Request 734 11.3.1.1.1 Description 734 11.3.1.1.2 Information Elements 734 11.3.2 GMLC to gsmSCF information flows 734 11.3.2.1 Any Time Interrogation ack 734 11.3.2.1.1 Description 734 11.3.2.1.2 Information Elements 734 11.3.3 gsmSCF to HLR information flows 735 11.3.3.1 Any Time Interrogation Request 735 11.3.3.1.1 Description 735 11.3.3.1.2 Information Elements 735 11.3.4 HLR to gsmSCF information flows 736 11.3.4.1 Any Time Interrogation ack 736 11.3.4.1.1 Description 736 11.3.4.1.2 Information Elements 736 11.3.5 HLR to SGSN information flows 737 11.3.5.1 Provide Subscriber Info 737 11.3.5.1.1 Description 737 11.3.5.1.2 Information Elements 737 11.3.6 SGSN to HLR information flows 737 11.3.6.1 Provide Subscriber Info ack 737 11.3.6.1.1 Description 737 11.3.6.1.2 Information Elements 738 12 Subscriber Mobile Number Portability status retrieval 739 12.1 Architecture 739 12.1.1 Functional Entities used for CAMEL 739 12.1.2 Interfaces defined for CAMEL 740 12.1.2.1 gsmSCF - MNPÊSRF interface 740 12.1.2.2 MNPÊSRF - gsmSCF interface 740 12.2 Procedures for CAMEL 740 12.2.1 Provide MNP Information 740 12.2.1.1 CAMEL_Provide_MNP_Info with ATI 740 12.3 Description of information flows 742 12.3.1 gsmSCF to MNPÊSRF information flows 742 12.3.1.1 Any Time Interrogation Request 742 12.3.1.1.1 Description 742 12.3.1.1.2 Information Elements 742 12.3.2 MNPÊSRF to gsmSCF information flows 742 12.3.2.1 Any Time Interrogation ack 742 12.3.2.1.1 Description 742 12.3.2.1.2 Information Elements 742 Annex A (informative): Handling of Apply Charging GPRS and Apply Charging Report GPRS 744 Annex B (informative): Change history 747 Foreword This Technical Specification (TS) has been produced by the 3rd Generation Partnership Project (3GPP). The present document specifies the stageÊ2 description for the fourth phaseÊ(see 3GPP TSÊ22.078Ê[6]) of the Customized Applications for Mobile network Enhanced Logic (CAMEL) feature within the 3GPP system. The contents of present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will then be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. 1 Scope The present document specifies the stageÊ2 description for the fourth phaseÊ(see 3GPP TSÊ22.078Ê[6]) of the Customized Applications for Mobile network Enhanced Logic (CAMEL) feature which provides the mechanisms to support services of operators which are not covered by standardized services even when roaming outside the HPLMN. The CAMEL feature is a network feature and not a supplementary service. It is a tool to help the network operator to provide the subscribers with the operator specific services even when roaming outside the HPLMN. In the present document, the GSM Service Control Function (gsmSCF) is treated as being part of the HPLMN. The regulatory environment in some countries may require the possibility that the gsmSCF and the HPLMN are controlled by different operators, and the gsmSCF and the HPLMN are therefore distinct entities. The fourth phase of the CAMEL feature supports, in addition to the third phase of the CAMEL: - Interactions with Optimal Routing; - Call Party Handling; - DTMF Mid call procedure for Mobile Originated and Mobile Terminating calls; - Inclusion of flexible tone injection; - Provision of location information of called subscriber; - Provide location information during ongoing call; - CAMEL control over MT SMS; - Notification of GPRS mobility management to CSE; - Inclusion of ODB data in Any Time Modification; - Enhancement of Any Time Interrogation and Provide Subscriber Information for PS Domain; - Mobile Number Portability database interrogation; - Criteria for the provision of location information during ongoing call; - Enhanced Dialled Services; - Enhancement to Establish Temporary Connection; - CAMEL control of trunk originated calls. CAMEL applicability to IP-based multimedia services is introduced in the fourth phase of the CAMEL. It is specified in 3GPP TSÊ23.278Ê[29]. CAMEL is not applicable to Emergency Setup (TSÊ12), i.e. if an Emergency call is requested, then the gsmSSF shall not be invoked. The mechanism described in the present document addresses especially the need for information exchange between the VPLMN or IPLMN and the HPLMN for support of operator specific services. Any user procedures for the control of operator specific services are outside the scope of the present document. Subscribers who have subscribed to operator specific services and therefore need the functional support of the CAMEL feature shall be marked in the HPLMN and VPLMN. In case a subscriber is marked to need CAMEL support, the appropriate procedures which provide the necessary information to the VPLMN or the HPLMN are invoked. It is possible for the HPLMN to instruct the VPLMN or IPLMN to interact with a gsmSCF which is controlled by the HPLMN. The specification of operator specific services is outside the scope of the present document. 1.1 Support of partial implementation of CAMEL phaseÊ4 A functional entity (VMSC, GMSC or SGSN) may support the complete CAMEL phaseÊ4 functionality or, as a network option, it may support the complete CAMEL phaseÊ3 functionality and a partial implementation of CAMEL phaseÊ4. If a functional entity supports any part of CAMEL phaseÊ4, then the HLR is informed of the CAMEL phaseÊ4 CSIs supported. An SGSN may also indicate support of the Provide Subscriber Information IF. To indicate support of a specific CSI, a functional entity shall have the ability to trigger on any initial service event possible for that CSI. If a VMSC or GMSC supports any of the CAMEL phaseÊ4 circuit switched CSIs (O CSI, D CSI, T CSI or VT CSI), then the gsmSCF is informed of the CAMEL phaseÊ4 circuit switched functionalities offered. The gsmSCF shall not send information flows or parameters that conflict with the functionalities offered by the VMSC or GMSC. If a CAMEL subscriber attempts to register in a VMSC or SGSN which supports at least one CAMEL phaseÊ4 CSI or the enhancement of Provide Subscriber Information IF, then the VMSC or SGSN indicates in the registration request to the HLR the phase of CAMEL which the VMSC or SGSN supports (at least phaseÊ4). In addition, the VMSC or SGSN indicates which CAMEL phaseÊ4 CSIs may be downloaded. An SGSN may also indicate support of the Provide Subscriber Information IF. If a GMSC supports at least one CAMEL phaseÊ4 CSI, then the GMSC indicates in the Send Routeing Info to the HLR the phase of CAMEL which the GMSC supports (at least phaseÊ4). In addition, the GMSC indicates which CAMEL phaseÊ4 CSIs may be downloaded. If a VMSC/gsmSSF or GMSC/gsmSSF initiates contact with the gsmSCF using the Initial DP IF, or acknowledges a gsmSCF initiated contact using the Initiate Call Attempt ack IF, then the VMSC/gsmSSF or GMSC/gsmSSF indicates in the IF the CAMEL phaseÊ4 functionalities offered to the gsmSCF. If a VLR initiates contact with the gsmSCF using a Mobility Management Event Notification IF, then the VLR or SGSN indicates in the IF the functionalities offered to the gsmSCF. 1.1.1 CAMEL PhaseÊ4 CSIs A network entity may indicate to the HLR an offer of support for the following CAMEL phaseÊ4 CSIs: - CAMEL phaseÊ4 O CSI; - CAMEL phaseÊ4 D CSI; - CAMEL phaseÊ4 T CSI; - CAMEL phaseÊ4 VT CSI; - CAMEL phaseÊ4 MT SMS CSI; - CAMEL phaseÊ4 MG CSI; CAMEL control of trunk originated calls; - Reporting of additional dialled digits. An SGSN may also indicate support of the CAMEL phaseÊ4 Provide Subscriber Information IF. A functional entity (VMSC, GMSC or SGSN) may offer the CSIs in any combination applicable for this entity. A functional entity shall indicate to the HLR all the CSIs it offers. The HLR may ignore the offer of the supported CSIs if they are not applicable for the sending entity, but it shall not reject the operation in this case."
"1.1.2 CAMEL PhaseÊ4 Functionalities The CAMEL phaseÊ4 functionalities which may be offered to the gsmSCF are the following: - Creating additional parties in a call, Creating a new call (Initiate Call Attempt); - Placing an individual call party on hold or moving an individual call party to Call Segment 1, when Call Segment 1 does not exist (Split Leg); - Connecting an individual call party to the group (Move Leg); - Releasing an individual call party (Disconnect Leg); - Indication of the release of a call party or call segment (Entity Released); - Enhancements for subscriber interactions with the gsmSCF (Disconnect Forward Connection With Argument); - Inclusion of flexible tone injection (Play Tone); - DTMF Mid call procedure for MO and VT calls (DPÊO_Mid_Call, DPÊT_Mid_Call); - Provision of Charge Indicator at answer DP (Charge Indicator at DPÊO_Answer, DPÊT_Answer); - Support of Alerting DP (DPÊO_Term_Seized, DPÊCall_Accepted); - Provision of location information of subscriber at alerting DP (Location information at DPÊO_Term_Seized, DPÊCall_Accepted); - Provision of location information during an ongoing call (DPÊO_Change_Of_Position, DPÊT_Change_Of_Position); - Interactions with Basic Optimal Routeing (Basic OR Interrogation Requested in Connect and Continue With Argument, Route Not Permitted in DPÊO_Abandon); - Warning tone enhancements (Burstlist for Audible Indicator); - Enhancements of Call Forwarding indication (Forwarding Destination Number); - Criteria for the provision of location information during ongoing call (Criteria for DPÊO_Change_Of_Position and DPÊT_Change_Of_Position); - Subscribed Enhanced Dialled services (see description below); - Serving Network Enhanced Dialled Services (see description below); - SCUDIF notification during active phase of the call (DP O_Service_Change and T_Service_Change) ; and Collection of additional dialled digits (Arming CollectedInfo DP as EDP-R). For the Subscribed Enhanced Dialled Services and Serving Network Enhanced Dialled Services, the following information flows apply in addition to the information flows allowed at TDPÊAnalysed_Information since CAMEL phaseÊ3: Apply Charging, Call Information Request, Cancel (all requests) and Request Report BCSM Event together with their acknowledgements and reportings. In addition, all the other offered CAMEL phaseÊ4 functionalities apply also to the enhanced dialled services. A functional entity (VMSC or GMSC) may offer the functionalities in any combination applicable for this entity and applicable to the offered CSIs. A functional entity (VMSC or GMSC) shall indicate to the gsmSCF all the functionallities it offers. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TRÊ21.905: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Vocabulary for 3GPP Specifications"". [2] 3GPP TSÊ22.004: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General on supplementary "". [3] 3GPP TSÊ22.024: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Description of Charge Advice Information (CAI)"". [4] 3GPP TSÊ22.041: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Operator Determined Barring (ODB)"". [5] 3GPP TSÊ22.071: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Location Services (LCS); Service description, StageÊ1"". [6] 3GPP TSÊ22.078: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Customised Applications for Mobile network Enhanced Logic (CAMEL); Service description, StageÊ1"". [7] 3GPP TSÊ23.003: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Numbering, addressing and identification"". [8] 3GPP TSÊ23.008: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Organization of subscriber data"". [9] 3GPP TSÊ23.011: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Supplementary Services"". [10] 3GPP TSÊ23.012: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Location management procedures"". [11] 3GPP TSÊ23.015: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Operator Determined Barring (ODB)"". [12] 3GPP TSÊ23.018: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Basic call handling; Technical realization"". [13] 3GPP TSÊ23.032: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Universal Geographical Area Description (GAD)"". [14] 3GPP TSÊ23.040: ""3rd Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS)"". [15] 3GPP TSÊ23.060: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; StageÊ2"". [16] 3GPP TSÊ23.072: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Deflection (CD) Supplementary Service; StageÊ2"". [17] 3GPP TSÊ23.066: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Mobile Number Portability (MNP); Technical realization; StageÊ2"". [18] 3GPP TSÊ23.073: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Localised Service Area (SoLSA); StageÊ2"". [19] 3GPP TSÊ23.079: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Optimal Routeing (SOR); Technical realization"". [20] 3GPP TSÊ23.082: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Forwarding (CF) supplementary services; StageÊ2"". [21] 3GPP TSÊ23.084: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Multi Party (MPTY) supplementary service; StageÊ2"". [22] 3GPP TSÊ23.085: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Closed User Group (CUG) supplementary service; StageÊ2"". [23] 3GPP TSÊ23.088: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Barring (CB) Supplementary Services; StageÊ2"". [24] 3GPP TSÊ23.090: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Unstructured Supplementary Service Data (USSD); StageÊ2"". [25] 3GPP TSÊ23.091: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Explicit Call Transfer (ECT) supplementary service; StageÊ2"". [26] 3GPP TSÊ23.093: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Completion of Calls to Busy Subscriber (CCBS); StageÊ2"". [27] 3GPP TSÊ23.172: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification; StageÊ2"". [28] 3GPP TSÊ23.271: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional stageÊ2 description of LCS"". [29] 3GPP TSÊ23.278: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) - IP Multimedia System (IMS) interworking; Stage 2"". [30] 3GPP TSÊ24.008: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface layer 3 specification; Core Network Protocols; StageÊ3"". [31] 3GPP TSÊ24.011: ""3rd Generation Partnership Project; Technical Specification Group Core Network; PointÊ-ÊtoÊ-ÊPoint (PP) Short Message Service (SMS); support on mobile radio interface"". [32] 3GPP TSÊ25.305: ""3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Stage 2 Functional Specification of UE Positioning in UTRAN"". [33] 3GPP TSÊ25.413: ""3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling"". [34] 3GPP TSÊ29.002: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Application Part (MAP) specification"". [35] 3GPP TSÊ29.007: ""3rd Generation Partnership Project; Technical Specification Group Core Network; General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)"". [36] 3GPP TSÊ29.078: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) PhaseÊ4 CAMEL Application Part (CAP) specification"". [37] 3GPP TSÊ32.250: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging management; Circuit Switched (CS) domain charging"". [38] 3GPP TSÊ32.251: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging management; Packet Switched (PS) domain charging"". [39] 3GPP TSÊ48.008: ""3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio Access Network; Mobile-services Switching Centre - Base Station System (MSCÊ-ÊBSS) interface; LayerÊ3 specification"". [40] ETSI ENÊ300Ê356-1 (V3.2.2): ""Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 3 for the international interface; Part 1: Basic services[ITU T Recommendations Q.761 to Q.764 (1997), modified]"". [41] ETSI ENÊ301Ê070-1 (V1.2.2): ""Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) versionÊ3 interactions with the Intelligent Network Application Part (INAP); Part 1: Protocol specificationÊ[ITU T Recommendation Q.1600 (1997), modified]"". [42] GSM TRÊ03.47: ""Example protocol stacks for interconnecting; Service Centre(s) (SC) and Mobile-services Switching Centre(s) (MSC)"". [43] ITU T Recommendation Q.763, DecemberÊ1999: ""Signalling System No.Ê7Ê-ÊISDN user part formats and codes"". [44] ITU T Recommendation Q.1224, SeptemberÊ1997: ""Distributed Functional Plane for Intelligent Network Capability SetÊ2"". [45] 3GPP TSÊ23.087: ""3rd Generation Partnership Project; Technical Specification Group Core Network; User-to-User Signalling (UUS) Supplementary Service - Stage 2"". [46] 3GPP TSÊ43.059: ""3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Functional stage 2 description of Location Services (LCS) in GERAN"". [47] 3GPP TSÊ23.081: ""Line identification supplementary services; Stage 2"". [48] 3GPP TSÊ23.083: ""Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 2"". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: Basic Call State Model (BCSM): BCSM provides a high-level model of GMSC- or MSC/VLR-activities required to establish and maintain communication paths for users. As such, it identifies a set of basic call activities in a GMSC or MSC/VLR and shows how these activities are joined together to process a basic call. Call Control Function (CCF): CCF is the Call Control Function in the network that provides call/service processing and control (see ITU T Recommendation Q.1224Ê[44]). Call Party Handling (CPH) Information Flow: Any of the Disconnect Leg, Move Leg or Split Leg information flows. Call Segment: A call segment contains one or more legs that are controlled by the same CS_gsmSSF instance. The call parties in the same call segment can communicate with each other (using a conference bridge if necessary). Call segments are identified by a number, eg. CSID1 is the call segment with id numberÊ1. Call Segment Association (CSA): A CSA contains one or more call segments. Legs can be moved between call segments within the CSA. There is a single CAP dialogue between the CSA and the gsmSCF. Detection Points (DP): points in processing at which notifications (to the service logic) can occur and transfer of control (to the gsmSCF) is possible are called Detection Points (DPs). Dialled Service CAMEL Subscription Information (D CSI): D CSI identifies the subscriber as having originating CAMEL dialled services. Forwarding MSC: MSC which is either an MSC invoking a standardized Call Forwarding supplementary service or Call Deflection supplementary service; or an MSC invoking a CAMEL based call forwarding service. Gateway MLC (GMLC): functional entity that allows external LCS Clients to request real-time information about a Mobile Station. The information that can be requested from the GMLC is: - location of Mobile Station See 3GPP TSÊ23.271Ê[28] and 3GPP TSÊ25.305Ê[32] or 3GPP TSÊ43.059Ê[46] for information on the GMLC. Geodetic Information: information defining the location of a mobile station, coded according to ITU T Recommendation Q.763Ê[43]. The derivation of this information from other information defining the location of a mobile station is a network operator option. If an entity derives the geodetic information it shall also provide the equivalent geographical information. Geographical Information: information defining the location of a mobile station, coded according to 3GPP TSÊ23.032Ê[13]. GPRS CAMEL Subscription Information (GPRS CSI): GPRS CSI identifies the subscriber as having GPRS CAMEL services. GPRS Dialogue: A dialogue between the gprsSSF and the gsmSCF. A single GPRS Dialogue may consist of one or more TCAP dialogues. Only one TCAP dialogue shall exists at one point in time for one gprsDialogue. GPRS Service Switching Function (gprsSSF): functional entity that interfaces the SGSN to the gsmSCF. The concept of the gprsSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network. GPRS Session: GPRS session starts when the GPRS subscriber attaches to the GPRS data network. It ends when the GPRS subscriber detaches from the GPRS data network. GSM Service Control Function (gsmSCF): functional entity that contains the CAMEL service logic to implement OSS. It interfaces with the gsmSSF, the gsmSRF, the GMLC and the HLR. GSM Service Switching Function (gsmSSF): functional entity that interfaces the MSC or GMSC to the gsmSCF. The concept of the gsmSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network. GSM Specialised Resource Function (gsmSRF): functional entity which provides various specialized resources. It interfaces with the gsmSCF and with the MSC. This entity is defined in ITU T Recommendation Q.1224Ê[44] with variations defined in the present document. Inter-connecting MSC: MSC which provides CAMEL support for incoming trunk calls. Location Information: indicates the location of the Mobile Station. The provision of location information is independent of the MS status. As part of the location information, an indication of the age of this information may be delivered. Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI): MO SMS CSI identifies the subscriber as having MO SMS CAMEL services. MO SMS CSI (CAMEL PhaseÊ4) is identical to SMS CSI (CAMEL PhaseÊ3). Mobile Station State: similar to Subscriber State, but associated only with a Mobile Station, not with a subscriber. Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI): MT SMS CSI identifies the subscriber as having MT SMS CAMEL services. Mobility Management event CAMEL Subscription Information (M CSI): M CSI identifies the subscriber as having Mobility Management event notification CAMEL services. Mobility Management event GPRS CAMEL Subscription Information (MG CSI): MG CSI identifies the GPRS subscriber as having Mobility Management event notification CAMEL services. NA (North American): prefix attached to certain information items used by North American PLMNs in connection with routing a call to a preferred or dialled long distance carrier. Network CAMEL Service Information (N CSI): N CSI identifies services offered on a per-network basis by the serving PLMN operator for all subscribers. Originating Basic Call State Model (O BCSM): originating half of the BCSM. The O BCSM corresponds to that portion of the BCSM associated with the originating party. Originating CAMEL Subscription Information (O CSI): O CSI identifies the subscriber as having originating CAMEL services. Point In Association (PIA): PIAs identify MSC/VLR or SGSN activities associated with one or more basic association/connection states of interest to OSS service logic instances. Point In Call (PIC): PICs identify MSC/VLR (GMSC) activities associated with one or more basic call/connection states of interest to OSS service logic instances. Service Key: Service Key identifies to the gsmSCF the service logic. The Service Key is administered by the HPLMN, and is passed transparently by the VPLMN/IPLMN to the gsmSCF. The Service Key is a part of the T/O/VT/D/GPRS/SMS/M CSI. Serving MLC: functional entity that performs location information retrieval. Short Message Control Protocol (SM-CP): Protocol between the MSC or SGSN and the MS. This protocol, which is specified in 3GPP TSÊ24.011Ê[31], is used to carry RPDU elements between the MSC or SGSN and the MS. Short Message Service Centre (SMSC): also abbreviation SC is used for SMSC. Subscriber State: see 3GPP TSÊ22.078Ê[6]. Supplementary Service Notification CAMEL Subscription Information (SS CSI): SS CSI identifies the subscriber as having supplementary service invocation notification CAMEL services. Terminating Basic Call State Model (T BCSM): terminating half of the BCSM. The T BCSM corresponds to that portion of the BCSM associated with the terminating party. Terminating CAMEL Subscription Information (in the GMSC) (T CSI): T CSI identifies the subscriber as having terminating CAMEL services in the GMSC. Translation Information Flag (TIF CSI): TIF CSI is a flag in the CAMEL subscriber data which indicates that when the subscriber registers a forwarded-to number, that the HLR shall not attempt to perform any translation, number format checks, prohibited FTN checks, call barring checks. Trunk Originated CAMEL Service Information (TO-CSI): TO-CSI identifies services offered by the PLMN operator to all incoming calls on a specific MSC trunk. USSD CAMEL Subscription Information (U CSI): U CSI identifies a set of subscriber specific mappings from a USSD service code to a gsmSCF address. USSD General CAMEL Service Information (UG CSI): UG CSI globally identifies a set of mappings from a USSD service code to a gsmSCF address. The global mapping applies to all HPLMN subscribers. If, for a particular service code, both U CSI and UG CSI are applicable then the U CSI shall take precedence. VMSC Terminating CAMEL Subscription Information (VT CSI): VT CSI identifies the subscriber as having terminating CAMEL services in the VMSC. 3.2 Abbreviations Abbreviations used in the present document are listed in 3GPP TRÊ21.905Ê[1]. For the purposes of the present document, the following abbreviations apply: BCSM Basic Call State Model CAMEL Customized Applications for Mobile network Enhanced Logic CPH Call Party Handling CS Call Segment CS Circuit Switched CSA Call Segment Association CSG Closed Subscriber Group CSID Call Segment (followed by an identification Number e.g. CSID1) DP Detection Point DTN Deflected To Number D CSI Dialled Services CAMEL Subscription Information EDP Event Detection Point EDS Enhanced Dialled Services FTN Forwarded To Number GMLC Gateway MLC GMSC Gateway MSC GPRS General Packet Radio Service gprsSSF GPRS Service Switching Function GPRS CSI GPRS CAMEL Subscription Information gsmSCF GSM Service Control Function gsmSRF GSM Specialised Resource Function gsmSSF GSM Service Switching Function HLR Home Location Register HPLMN Home PLMN ICA Initiate Call Attempt IE Information Element IF Information Flow IP Intelligent Peripheral IPLMN Interrogating PLMN LCS Location Services LSA Localised Service Area M CSI Mobility Management event Notification CAMEL Subscription Information MF Mobile Forwarding MG CSI Mobility Management event Notification GPRS CAMEL Subscription Information MLC Mobile Location Centre MNP Mobile Number Portability MNPÊSRF Mobile Number Portability Signalling Relay Function MO Mobile Originating MO SMS CSI Mobile Originated Short Message Service CAMEL Subscription Information MSC Mobile service Switching Centre MT Mobile Terminating MT Mobile Terminating in GMSC MT SMS CSI Mobile Terminating Short Message Service CAMEL Subscription Information N CSI Network CAMEL Service Information NA North American NNI Network Node Interface O BCSM Originating Basic Call State Model O CSI Originating CAMEL Subscription Information ODB Operator Determined Barring OR Optimal Routeing OSS Operator Specific Service PDP Packet Data Protocol PIC Point In Call PLMN Public Land Mobile Network SGSN Serving GPRS Support Node SLPI Service Logic Program Instance SM Short Message SM-CP Short Message Control Protocol SMF Service Management Function SMLC Serving MLC SMRSE Short Message Relay Service Element SMS Short Message Service SMSC Short Message Service Centre SMS CSI Short Message Service CAMEL Subscription Information SS CSI Supplementary Service Notification CAMEL Subscription Information T BCSM Terminating Basic Call State Model T CSI Terminating CAMEL Subscription Information (in the GMSC) TDP Trigger Detection Point TO-CSI Trunk Originated CAMEL Service Information TPDU Transfer Protocol Data Unit TIF CSI Translation Information Flag U CSI USSD CAMEL Subscription Information UG CSI USSD General CAMEL Service Information UNI User Network Interface VLR Visitor Location Register VPLMN Visited PLMN VT Mobile Terminating in VMSC VT CSI VMSC Terminating CAMEL Subscription Information 4 Circuit switched Call Control 4.1 Architecture 4.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support CAMEL. Also the additions needed to the basic functionality are described. FigureÊ4.1 shows the functional entities involved in calls requiring CAMEL support. The architecture is applicable to the forth phase of CAMEL. Figure 4.1: Functional architecture for support of CAMEL HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription regarding O CSI, D CSI, T CSI, VT CSI and TIF CSI. The O CSI is sent to the VLR at Location Update, on data restoration or if the O CSI is updated by administrative action. The D CSI is sent to the VLR at Location Update, on data restoration or if the D CSI is updated by administrative action. The VT CSI is sent to the VLR at Location Update, on data restoration or if the VT CSI is updated by administrative action. The TIF CSI is sent to the VLR at Location Update, on data restoration or if the TIF CSI is updated by administrative action. The O/D/T CSI is sent to the GMSC when the HLR responds to a request for routeing information. GMSC: When processing the calls for subscribers requiring CAMEL support, the GMSC receives an O/D/T CSI from the HLR, indicating the GMSC to request instructions from the gsmSSF. The GMSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the GMSC. MSC: When processing the calls for subscribers requiring CAMEL support, the MSC receives an O CSI and / or D CSI and / or VT CSI from the VLR indicating the MSC to request instructions from the gsmSSF. The MSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the MSC. VLR: The VLR stores the O CSI, D CSI, VT CSI and TIF CSI as a part of the subscriber data for subscribers roaming in the VLR area. gsmSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. gsmSRF: see subclauseÊ3.1. 4.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 4.1.2.1 HLR - VLR interface This interface is used to send the CAMEL related subscriber data to the visited PLMN and for provision of MSRN. The interface is also used to retrieve subscriber status and location information of the mobile subscriber or to indicate suppression of announcement for a CAMEL service. 4.1.2.2 GMSC - HLR interface This interface is used at terminating calls to exchange routeing information, subscriber status, location information, subscription information and suppression of announcements. The CAMEL related subscriber data that is passed to the IPLMN is sent over this interface. 4.1.2.3 GMSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 4.1.2.4 gsmSSF - gsmSCF interface This interface is used by the gsmSCF to control a call in a certain gsmSSF and to request the gsmSSF to establish a connection with a gsmSRF. Relationships on this interface are opened as a result of the gsmSSF sending a request for instructions to the gsmSCF or opened as a result of the gsmSCF sending a request to the gsmSSF to initiate a new call. 4.1.2.5 MSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 4.1.2.6 gsmSCF - HLR interface This interface is used by the gsmSCF to request information from the HLR. As a network operator option the HLR may refuse to provide the information requested by the gsmSCF. 4.1.2.7 gsmSCF - gsmSRF interface This interface is used by the gsmSCF to instruct the gsmSRF to play tones/announcements to the users. 4.1.2.8 GMSC - MSC interface This interface is used to transfer control of a call from a VMSC back to a GMSC for optimal routeing. 4.2 Detection Points (DPs) 4.2.1 Definition and description Certain basic call events may be visible to the GSM Service Control Function (gsmSCF). The DPs are the points in call at which these events are detected. The DPs for Mobile Originated Calls and Mobile Terminated Calls are described in subclausesÊ4.4.2 and 4.4.3. A DP can be armed in order to notify the gsmSCF that the DP was encountered, and potentially to allow the gsmSCF to influence subsequent handling of the call. If the DP is not armed, the processing entity continues the processing without gsmSCF involvement. Three different types of DPs are identified: - Trigger Detection Point - Request (TDP R). This detection point is statically armed and initiates a CAMEL control relationship when encountered and there is no existing relationship due to the same CSI. Processing is suspended when the DP is encountered. - Event Detection Point - Request (EDP R). This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is suspended when encountering the DP and the gsmSSF waits for instructions from the gsmSCF. - Event Detection Point - Notification (EDP N). This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is not suspended when encountering the DP. The DPs are characterized in the following subclauses. 4.2.1.1 Arming/disarming mechanism A DP may be statically armed or dynamically armed. The following arming rules apply: - A DP for mobile terminating call handling is statically armed in the GMSC as a result of T CSI delivery from the HLR. A DP for mobile terminating call handling is statically armed in the VMSC as a result of VT CSI delivery from the VLR. A DP for forwarding leg handling is statically armed in the GMSC as result of O CSI and/or D CSI delivery from the HLR. A DP for mobile originating call or forwarded leg handling is statically armed in the VMSC as a result of O CSI and/or D CSI delivery from the VLR. - A DP is dynamically armed by the gsmSCF within the context of a CAMEL control relationship (between the gsmSSF and the gsmSCF). - A Request Report BCSM Event information flow for a detection point for a leg overwrites any previous Request Report BCSM Event information flow for that detection point for that leg. The following disarming rules apply: - A statically armed DP is disarmed when the O CSI, D CSI, T CSI or VT CSI that caused the DP to be statically armed is withdrawn in the HLR. Only TDP Rs can be disarmed using this mechanism. - If an armed EDP is met, then it is disarmed. - If an EDP is met that causes the release of the related leg, then all EDPs related to that leg are disarmed. - If a call is released, then all EDPs related to that call are disarmed. - If an EDP is met, then other EDPs are disarmed, in accordance with the implicit disarming rule table (seeÊsubclauseÊ4.4.4). - If an EDP is armed, it can be explicitly disarmed by the gsmSCF by means of the Request Report BCSM Event information flow. 4.2.1.2 Criteria Criteria are the conditions that must be met in order for the gsmSSF to request instructions from the gsmSCF. 4.2.1.2.1 Criteria at DPÊCollected_Info The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR may decide not to include the DPÊCollected_Info trigger criteria in the subscriber data sent to the GMSC if the trigger criteria for the call are not met. For optimally routed late forwarded calls, the MSC may decide not to include the DPÊCollected_Info trigger criteria in the Resume Call Handling information flow sent to the GMSC, if the trigger criteria for the call are not met. The following criteria are applicable for DPÊCollected_Info: - Destination number triggering criterion: The HLR may store a list of up to 10 destination numbers and/or up to 3 number lengths. There is no restriction on the nature of address. There is no restriction on the numbering plan indicator. This criterion may be defined to be either ""enabling"" or ""inhibiting"". - Basic service triggering criterion: The HLR may store a list of up to 5 basic service codes, each of which may represent an individual basic service or a basic service group. Compound basic service group codes, as defined in 3GPP TSÊ29.002Ê[34], are not allowed for conditional triggering. This list is a triggering list. - Forwarding triggering criterion: The HLR may store an indicator that triggering shall occur only for a call which has been subject to the Call Forwarding supplementary service, Call Deflection supplementary service or CAMEL call forwarding. This criterion may be defined to be either ""enabling"" or ""inhibiting"". For MO calls, triggering at DPÊCollected_Info shall be strictly based on the number received over the access network. No service selection information, such as ? and # digits, or carrier selection information, dialled by the subscriber, shall be removed from the number before conditional triggering check takes place. For MF calls at the VMSC, triggering at DPÊCollected_Info shall be strictly based on the number received over the access network (the Deflected-to-Number in the case of Call Deflection), the Forwarded-to-Number retained in the VLR or the Destination Routing Address received in the Connect information flow from the gsmSCF during a Terminating CAMEL Service at the VMSC. No service selection information or carrier selection information shall be removed from the number before conditional triggering check takes place. For MF calls at the GMSC, triggering at DPÊCollected_Info shall be strictly based on the Forwarded-to-Number received from HLR, on the Destination Routing Address received in the Connect information flow from the gsmSCF during a Terminating CAMEL Service or on the Forwarded-to-Number received in the Resume Call Handling information flow. No service selection information or carrier selection information shall be removed from the number before conditional triggering check takes place. One or more DP criteria may be applicable. All applicable triggering criteria must be satisfied before the dialogue is established with the gsmSCF. If the destination number triggering criterion is enabling, then the gsmSSF may establish a dialogue with the gsmSCF if: - the destination number matches one of the destination number strings defined in the list, or - the length of the destination number matches one of the destination number lengths defined in the list. In this test the destination number matches one of the destination number strings in the list if: - the nature of address of destination number is the same as the nature of address of the destination number string (The numbering plan indicator is not compared); - the destination number is at least as long as the destination number string in the list, and - all the digits in the destination number string in the list match the leading digits of the destination number. If the destination number triggering criterion is inhibiting, then the gsmSSF may establish a dialogue with the gsmSCF if: - the destination number does not match any of the destination number strings defined in the list, and - the length of the destination number does not match any of the destination number lengths defined in the list. In this test the destination number matches one of the destination number strings in the list if: - the nature of address of the destination number is the same as the nature of address of the destination number string (The numbering plan indicator is not compared); - the destination number is at least as long as the destination number string in the list, and - all the digits in the destination number string in the list match the leading digits of the destination number. The basic service triggering criterion is met if the basic service for the call matches a stored individual basic service code or is a member of the group defined by a stored basic service group code. For a SCUDIF call (see 3GPP TSÊ23.172Ê[27]), the basic service triggering criterion is met if one or both the preferred basic service and the less preferred basic service for the call match a stored individual basic service code or is a member of the group defined by a stored basic service group code. For the purpose of this paragraph a general bearer service is a member of the corresponding bearer service group. If the forwarding triggering criterion is enabling, then the gsmSSF may establish a dialogue with the gsmSCF only if the call has been subject to CAMEL call forwarding or the Call Forwarding supplementary service. If the forwarding triggering criterion is inhibiting, then the gsmSSF may establish a dialogue with the gsmSCF only if the call has not been subject to CAMEL call forwarding or the Call Forwarding supplementary service. 4.2.1.2.2 Criteria at DPÊAnalysed_Information 4.2.1.2.2.1 General The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR shall always include the trigger criteria in the subscriber data sent to the GMSC because that the HLR can not check the criteria applicable at DPÊAnalysed_Info, since the number that the criteria check shall be based on, may be modified by a Mobile Terminating or Mobile Forwarding Service Logic for this call. For optimally routed late forwarded calls, the MSC shall always include the trigger criteria in the Resume Call Handling information flow sent to the GMSC because the MSC can not check the criteria applicable at DPÊAnalysed_Info, since the number that the criteria check shall be based on, may be modified by a Mobile Terminating or Mobile Forwarding Service Logic for this call. The following criteria are applicable for DPÊAnalysed_Information: - Destination number triggering criterion: The HLR may store a list of up to 10 destination numbers. There is no restriction on the nature of address. There is no restriction on the numbering plan indicator. NOTE: The order in which the destination number criteria are checked in the MSC or GMSC is not determined. Hence, overlapping destination number criteria (e.g. use of ""0800"" and ""0800123"" for two different services) should be avoided, because they lead to unpredictable behaviour (i.e. either service might be triggered). For MO calls, triggering at DPÊAnalysed_Info shall be based on the called party number received over the access network or the Destination Routing Address in the Connect information flow from the gsmSCF during a Mobile Originating CAMEL Service. For MF calls at the VMSC, triggering at DPÊAnalysed_Info shall be based on the number received over the access network (the Deflected-to-Number in the case of Call Deflection), the Forwarded-to-Number retained in the VLR, or the Destination Routing Address in the Connect information flow from the gsmSCF during a Mobile Terminated or Mobile Forwarded CAMEL Service. For MF calls at the GMSC, triggering at DPÊAnalysed_Info shall be based on the Forwarded-to-Number received from the HLR, on the Destination Routing Address received in the Connect information flow from gsmSCF during a Mobile Terminated or Mobile Forwarded CAMEL Service, or on the Forwarded-to-Number received in the Resume Call Handling information flow. For NP calls, triggering at DPÊAnalysed_Info shall be based on the number received from gsmSCF. An NP call that is created in the VMSC or GMSC of the served subscriber may be subject to D CSI service and N CSI service. An NP call that is created in an MSC other than the VMSC or GMSC of the served subscriber, may be subject to N CSI service. For NC calls, triggering at DPÊAnalysed_Info shall be based on the number received from the gsmSCF. An NC call may be subject to N CSI service. 4.2.1.2.2.2 Removal of information significant to the serving entity In order to decide whether triggering shall take place, the trigger criteria need to be compared with the address information. Before the comparison takes place the following information shall be removed from the destination address information: - Operator specific service selection information that is recognised and treated locally in the serving entity. This shall not lead to a change of the type of number indicator of the address information. - Carrier selection information. If the removal of carrier selection information also removes international or national (trunk) prefixes (depending on regulatory requirements), then the type of number indicator of the address information shall be changed to ""international number"" or ""national (significant) number"" respectively. Otherwise the type of number indicator shall remain unchanged. The address information in a subsequent Initial DP information flow at DPÊAnalysed_Info shall not contain the removed information, however in the further call handling the serving entity shall invoke the requested services (e.g. carrier selection). 4.2.1.2.2.3 Number comparison The following procedure shall be performed for the comparison of the destination number triggering criterion and the address information in the given order. 1. The numbering plan indicators of the destination number triggering criterion and the destination number are ignored. 2. The type of number/nature of address indicators of the destination number triggering criterion and the destination number are compared. If there is a match of the type of number indicator, then the check shall be performed by comparing the digits as defined in step 6. If there is no match of the type of number the comparison procedure shall continue as follows. 3. If either or both of the address information and destination number triggering criterion includes a types of number/nature of address indicator other than ""unknown"", ""national (significant) number"" or ""international number"" then the destination number does not match the destination number triggering criterion. Otherwise the comparison procedure shall continue as follows. 4."
"If there is a number (address information or destination number triggering criterion) with type of number/nature of address ""unknown"" this number shall be translated based on the numbering plan of the serving entity in either of the following ways: - if the leading digits refer to an international prefix then those digits shall be removed and the type of number/nature of address shall be set to ""international number"". - if the leading digits refer to a national (trunk) prefix then those digits shall be removed and the type of number/nature of address shall be set to ""national (significant) number"". If the leading digits refer neither to an international prefix nor to a national (trunk) prefix, then the destination number does not match the destination number triggering criterion. If there is a match of the type of number/nature of address indicator after this number modification, then the check shall be performed by comparing the digits as defined in step 6, otherwise the comparison procedure shall continue as follows. 5. If the type of number/nature of address of the address information or of the destination number triggering criterion is ""national (significant) number"" this number shall be translated based on the numbering plan of the serving entity to international format by adding the country code of the serving entity to the number string. After this modification the destination number triggering criterion and the destination number shall be in international format and shall be checked by comparing the digits as defined in step 6. 6 If the number of digits in the address information are compared with the number of digits in the destination number triggering criterion, then there is a match if: - the destination number is at least as long as the destination number string of the destination number triggering criterion, and - all the digits in the destination number string of the destination number triggering criterion match the leading digits of the destination number. The check described in this subclause shall be repeated for every number contained in the destination number triggering criterion of the D CSI until there is a match DPÊAnalysed_Info is triggered, or until all the destination numbers have been checked without a match. In the latter case DPÊAnalysed_Info is not triggered. The procedures for the destination number triggering criterion check for N CSI are network specific. The modifications of the address information described in this subclause shall only be done for comparison purposes, i.e. they shall not affect the format of the destination address information sent in the Initial DP information flow. 4.2.1.2.3 Criteria at DPÊRoute_Select_Failure The HLR may store a list of up to 5 cause values. The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR shall always include the trigger criteria in the subscriber data sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the O CSI to the GMSC. For optimally routed late forwarded calls, the MSC shall always include the trigger criteria in the Resume Call Handling information flow sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the O CSI to the GMSC. The following criteria are applicable for DPÊRoute_Select_Failure: - Release cause code. The trigger criteria are met if the cause code received from ISUP is equal to at least one of the cause codes in the trigger criteria list. For the purpose of trigger criteria check, the MSC performing the triggering check shall use the ""cause value"" field of the ISUP ""cause indicators"" parameter, as defined in ITU T Recommendation Q.763Ê[43]. If an O BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. 4.2.1.2.4 Criteria at DPÊTerminating_Attempt_Authorised The HLR may store a list of up to 5 basic service codes, each of which may represent an individual basic service or a basic service group. Compound basic service group codes, as defined in 3GPP TSÊ29.002Ê[34], are not allowed for conditional triggering. This list is a triggering list. The criteria for DPÊTerminating_Attempt_Authorised are checked in the HLR for the GMSC or in the VLR for the MSC. The HLR shall only include T CSI in the CAMEL subscription information sent to the GMSC if the criteria are met. The VLR shall only include VT CSI in the CAMEL subscription information sent to the MSC if the criteria are met. The basic service criterion is met if the basic service for the call matches a stored individual basic service code or is a member of the group defined by a stored basic service group code. For a SCUDIF call (see 3GPP TSÊ23.172Ê[27]), the basic service triggering criterion is met if one or both the preferred basic service and the less preferred basic service for the call match a stored individual basic service code or is a member of the group defined by a stored basic service group code.For the purpose of this paragraph a general bearer service is a member of the corresponding bearer service group. 4.2.1.2.5 Criteria at DPÊT_Busy and T_No_Answer The HLR may store a list of up to 5 cause values. The criteria for a mobile terminating call are checked in the GMSC or in MSC. For mobile terminating calls in the GMSC, the HLR shall include the trigger criteria in the subscriber data sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the T CSI to the GMSC. If the Send Routeing Info ack information flow includes the Not Reachable FTN, then the HLR may decide not to include the trigger criteria, if the HLR has identified that T CSI includes DPÊT_Busy with cause code Not Reachable. If the Send Routeing Info ack information flow includes the Not Reachable FTN and also T CSI, including DPÊT_Busy with cause code, then the not reachable condition shall be mapped to an ISUP release code, which shall be used for the triggering check. For Mobile terminating calls in the VMSC, the trigger criteria are received in the VT CSI from the HLR in the Insert Subscriber Data information flow. The triggering is based on the ISUP release cause code (call set up result). The following criteria are applicable for DPÊT_Busy and DPÊT_No_Answer: - Release cause code. If the cause code is received from ISUP, then the trigger criteria are met if the cause code is equal to at least one of the cause codes in the trigger criteria list. For this check, the MSC shall use the ""cause value"" field of the ISUP ""cause indicators"" parameter, as defined in ITU T Recommendation Q.763Ê[43]. If the cause code is received from MAP, then the trigger criteria are met if the cause code is equal to at least one of the cause codes in the trigger criteria list. For this check, the MSC shall use the cause values as defined in tableÊ4.1. If the trigger criteria are satisfied, then the corresponding Service Logic shall be invoked. If a T BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. When the Resume Call Handling information flow is received in the GMSC and the subscriber has T CSI then the forwarding reason in the Resume Call Handling information flow shall be used to perform the trigger criteria check for DPÊT_Busy or DPÊT_No_Answer. If a match is found, then the corresponding Service Logic shall be invoked. If a T BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. Table 4.1: Mapping of Send Info For Incoming Call (SIFIC) ack, Send Routeing Info ack (SRI ack) or Resume Call Handling (RCH) to ISUP release causes for triggering criteria check SIFIC ack / SRI ack / RCH ""forwarding reason"" ISUP release cause number ISUP release cause name MS not reachable 20 Subscriber absent MS Busy 17 User busy Call deflection (note) 21 Call rejected No reply 19 No answer from user (user alerted) NOTE: Call Deflection is used only in the Resume Call Handling information flow, and in the VMSC. The same code point in the Send Routeing Info ack indicates CFU. However, the CFU invocation in the GMSC triggers the Terminating_Attempt_Authorised DP; thus the reason code mapping is not needed in the CFU case. 4.2.1.3 Relationship If an armed DP is encountered, the gsmSSF provides an information flow via the already established relationship with the gsmSCF. A relationship between the gsmSSF and the gsmSCF for the purpose of operator specific service processing is considered to be a CAMEL relationship. There are two types of CAMEL relationships: - A CAMEL control relationship if the gsmSCF is able to influence the call processing via the relationship. - A CAMEL monitor relationship if the gsmSCF is not able to influence the call processing via the relationship. 4.2.2 DP processing rules The gsmSSF shall apply the following set of rules during DP processing to ensure a single point of control: - EDPs are disarmed by the gsmSSF as they are encountered and reported to the gsmSCF, when the occurrence of another EDP causes the implicit disarming of the EDP or when the leg clears. - A control relationship persists as long as there is 1 or more EDP R armed for this portion of the call or if the Process CS_gsmSSF is in any state except Monitoring or Idle. - A control relationship changes to a monitor relationship if the control relationship does not persist and: - 1 or more EDP N is armed, or - 1 or more Call information Report is outstanding, or - an Apply Charging Report is outstanding. - If a control relationship does not persist and does not change to a monitor relationship then the relationship terminates. A monitor relationship terminates if there are neither EDP Ns armed nor reports outstanding or if the call clears. 4.3 Description of CAMEL Subscriber Data 4.3.1 Originating CAMEL Subscription Information (O CSI) This subclause defines the contents of the Originating CAMEL Subscription Information. 4.3.1.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊCollected_Info and DPÊRoute_Select_Failure. 4.3.1.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.1.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.1.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.1.5 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.1.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a VLR or GMSC any data for a CAMEL phase later than that which the CAMEL capability handling indicates. E.g. if the CAMEL Capability Handling indicates CAMEL phaseÊ1 then the HLR shall not send triggering criteria to the VLR. Different CSIs may contain different values of CAMEL Capability Handling. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.1.7 CSI state The CSI state indicates whether the O CSI is active or not. 4.3.1.8 Notification flag The notification flag indicates whether the change of the O CSI shall trigger Notification on Change of Subscriber Data. 4.3.2 Dialled Service CAMEL Subscription Information (D CSI) This subclause defines the contents of the Dialled Service CAMEL Subscription Information. 4.3.2.1 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.2.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. A gsmSCF address shall be associated with each DP criterion. 4.3.2.3 Service Key The Service Key identifies to the gsmSCF the service logic to be used. A Service Key shall be associated with each DP criteria. 4.3.2.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is submitted to call gapping in the gsmSSF. A default call handling shall be associated with each DP criteria. 4.3.2.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.2.6 CSI state The CSI state indicates whether the D CSI is active or not. 4.3.2.7 Notification flag The notification flag indicates whether changes of the D CSI shall trigger the Notification on Change of Subscriber Data. 4.3.3 Network CAMEL Service Information (N CSI) The N CSI identifies services offered on a per-network basis by the serving PLMN operator for all subscribers and, if applicable, for all incoming trunk originated calls. This CSI shall be stored in the MSC. 4.3.4 Translation Information Flag CAMEL Subscription Information (TIF CSI) 4.3.4.1 Translation Information Flag The TIF CSI in the CAMEL Subscriber data indicates, - when the subscriber registers a forwarded-to number, that the HLR shall not attempt to perform any translation, number format checks, prohibited FTN checks or call barring checks. (see 3GPP TSÊ23.082Ê[20]). - when the subscriber invokes the Call Deflection supplementary service, that the VLR shall not attempt to perform any translation, number format checks, prohibited DTN checks, call barring checks. (seeÊ3GPP TSÊ23.072Ê[16]). 4.3.4.2 Notification flag The notification flag indicates whether the change of the TIF CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.5 Terminating CAMEL Subscription Information (in the GMSC) (T CSI) This subclause defines the contents of the Terminating CAMEL Subscription Information. 4.3.5.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊTerminating_Attempt_Authorised, DPÊT_Busy, and DPÊT_No_Answer. 4.3.5.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.5.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.5.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.5.5 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.5.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a GMSC any data for a CAMEL phase later than that which the CAMEL capability handling indicates. Different CSIs may contain different values of CAMEL Capability Handling. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the GMSC, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (e.g. support of a lower version of CSI). 4.3.5.7 CSI state The CSI state indicates whether the T CSI is active or not. 4.3.5.8 Notification flag The notification flag indicates whether the change of the T CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.6 VMSC Terminating CAMEL Subscription Information (VT CSI) This subclause defines the contents of the Terminating CAMEL Subscription Information for the VMSC. 4.3.6.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊTerminating_Attempt_Authorised, DPÊT_Busy, and DPÊT_No_Answer. 4.3.6.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.6.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.6.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.6.5 DP criteria The DP criteria indicate whether the gsmSSF shall request the gsmSCF for instructions. 4.3.6.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a VLR any data for a CAMEL phase later than that which the CAMEL capability handling indicates. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.6.7 CSI state The CSI state indicates whether the VT CSI is active or not. 4.3.6.8 Notification flag The notification flag indicates whether the change of the VT CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.7 Other CAMEL data 4.3.7.1 Location information/Subscriber state Interrogation This data indicates whether additional subscriber information shall be sent to the GMSC as part of the terminating call handling. - an indication that the HLR shall send the location information of the called subscriber. - an indication that the HLR shall send the subscriber state of the called subscriber. 4.3.7.2 gsmSCF address list for CSI The gsmSCF address list for CSI indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 4.3.8 Trunk Originated CAMEL Service Information (TO-CSI) The TO CSI identifies services offered on a MSC basis by the serving PLMN operator for all incoming calls on a specific MSC trunk. This CSI shall be stored in the MSC. The contents of the TO-CSI is outside the scope of this specification. When processing trunk originating calls requiring CAMEL support, the TO-CSI informs the MSC to request instructions from the gsmSSF. The MSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the MSC. Certain basic call events may be visible to the GSM Service Control Function (gsmSCF). The DPs are the points in call at which these events are detected. The DPs for Trunk Originated Calls are described in subclausesÊ4.4.2. Dynamic arming/ disarming rules for TO calls are specified in subclause 4.2.1.1. Static arming/ disarming of DP Collected_Info for TO calls shall use the following rules: - A DP for trunk originating call is statically armed in the MSC as a result of TO CSI for the specific MSC trunk. - A statically armed DP is disarmed when the TO CSI that caused the DP to be statically armed is withdrawn from the MSC. TDP Criteria may be defined for the case when collection of dialled digits has been performed. Criteria may be based on the contents and/ or length of the dialled number, basic service, call type or other information at the discretion of the network operator, however this is outside the scope of this specification. DP processing rules for TO calls are defined in subclause 4.2.2. 4.4 Description of CAMEL BCSMs 4.4.1 General Handling The BCSM is used to describe the actions in an MSC or GMSC or VMSC during originating, forwarded or terminating calls. The BCSM identifies the points in basic call processing when Operator Specific Service (OSS) logic instances (accessed through the gsmSCF) are permitted to interact with basic call control capabilities. FigureÊ4.2 shows the components that have been identified to describe a BCSM. Figure 4.2: BCSM Components 4.4.2 Originating Basic Call State Model (O BCSM) 4.4.2.1 Description of O BCSM The O BCSM is used to describe the actions in an MSC during originating (MSC) , forwarded (MSC or GMSC) and trunk originating (MSC) calls. When encountering a DP the O BCSM processing is suspended at the DP and the MSC or GMSC indicates this to the gsmSSF which determines what action, if any, shall be taken if the DP is armed. For gsmSCF initiated new calls the O BCSM is initially suspended at DPÊCollected_Info. NOTE: The DPÊO_Busy also includes the 'not reachable' case. Figure 4.3: Originating BCSM for CAMEL The table below defines the different DPs which apply to mobile originating and forwarded calls and trunk originating calls. Table 4.2: Description of O BCSM DPs in the MSC CAMEL Detection Point: DP Type Description: DPÊCollected_Info TDP R, EDP-R (note 7) Indication that the O CSI is analysed, the gsmSCF has initiated a call attempt (in this case the DP is neither triggered nor reported) or additional digits have been collected. DPÊAnalysed_Information TDP RÊ(noteÊ2) Availability of routeing address and nature of address. DPÊRoute_Select_Failure TDP RÊ(noteÊ3), EDP N, EDP R Indication that the call establishment failed. DPÊO_Busy EDP N, EDP R Indication that: - a busy indication is received from the terminating party, - a not reachable event is determined from a cause IE in the ISUP Release message. DPÊO_No_Answer EDP N, EDP R Indication that: - an application timer associated with the O_No_Answer DP expires, - a no answer event is determined from a cause IE in the ISUP Release message. DPÊO_Term_Seized EDP N, EDP R Indication that the called party is being alerted. DPÊO_Answer EDP N, EDP R Indication that the call is accepted and answered by the terminating party. DPÊO_Mid_Call EDP N, EDP R Indication that a service/service feature indication is received from the originating party (DTMF - noteÊ4, noteÊ5). DPÊO_Change_Of_Position EDP N Indication that the originating party has changed position (noteÊ6). DPÊO_Disconnect EDP N, EDP R A disconnect indication is received from the originating party or from the terminating party. DPÊO_Abandon EDP N, EDP R Indication that a disconnect indication is received from the originating party during the call establishment procedure. DPÊO_Service_Change EDP N Indication that the bearer service has changed. NOTE 1: The DPs are defined in ITU T Recommendation Q.1224Ê[44]. NOTE 2: For TDP R Analysed_Information new relationship to gsmSCF is opened. NOTE 3: DPÊRoute_Select_Failure shall be reported as TDP R when there is no relationship to gsmSCF. If a relationship to gsmSCF is already open, it shall be reported as EDP R or EDP N if armed so. DP Route_Select_Failure cannot be armed as TDP-R for Trunk Originating Calls. NOTE 4: DTMF is only applicable for the Mobile Originating or Trunk Originating Call in the VMSC. DTMF is not applicable at the O_Alerting PIC. NOTE 5: Call Processing is suspended at DPÊO_Mid_Call if a Call Party Handling information flow is handled. However, the DP is not reported. NOTE 6: DPÊO_Change_Of_Position is applicable only for the Mobile Originating Call in the VMSC. NOTE 7: DP Collected_Info as a EDP-R is applicable only for Trunk Originating Calls. 4.4.2.1.1 Description of the call model (PICs) This subclause describes the call model for originating and forwarded calls. For each PIC a description can be found of the entry events, functions and exit events. It should be noted that although the names used for PICs match those used in ITU T Recommendation Q.1224Ê[44] the specific descriptions differ. 4.4.2.1.1.1 O_Null & Authorise_Origination_Attempt_Collect_Info Entry events: - Disconnection and clearing of a previous call (DPÊO_Disconnect) or default handling of exceptions by gsmSSF/(G)MSC completed. - Abandon event is reported from Analyse_Information or Routing and Alerting PIC. - Exception event is reported. - gsmSCF requests additional digits (DP CollectedInfo or DP AnalysedInfo). Actions: If entry event is 'gsmSCF requests additional digits' then MSC starts collecting additional digits. Otherwise: - Interface is idled. - Mobile Originating call: - SETUP information flow containing the dialled number is received from MS, preceeding call leg or originating exchange. - The supplementary service ""barring of all outgoing calls"" is checked and invoked if necessary. - The ODB category ""barring of all outgoing calls"" is checked and ODB is invoked if necessary. NOTE: the ODB category ""barring of all outgoing calls when roaming"" causes the HLR to send the category ""barring of all outgoing call"" if the VLR is not in the HPLMN. - CUG checks done in the originating MSC/VLR are performed. - Information being analysed e.g. O-CSI is analysed. - Trunk Originating call: - The initial information flow containing the complete dialled number or an initial information package/ dialling string is received from the trunk interface. - Any operator specific service checks done in the originating MSC are performed. - Information being analysed e.g., TO CSI is analysed. Exit events: If entry event was 'gsmSCF requests additional digits' then: - Additional digits collected. - Inter-digit timer expires - An exception condition is encountered. For example, collection of additional digits fails due to a lack of switch resources (e.g. no digit receivers are available) or calling party abandons call. Otherwise: - Originating CSI is analysed. - Trunk Originating CSI is analysed. - An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP. Example exception condition: Calling party abandons call. 4.4.2.1.1.2 Analyse_Information Entry events: - Originating CSI is analysed. (DPÊCollectedÊInfo). - Trunk Originating CSI is analysed (DP Collected Info). - Additional digits collected (DP Collected Info) in trunk originated call. - The gsmSCF has initiated a call attempt (DPÊCollected_Info). In this case the DP has neither been triggered nor has it been reported. - New routeing information is received when the Busy event (DPÊO_Busy), Route Select Failure event (DPÊRoute_Select_Failure), Not Reachable event (DPÊO_Busy) or No Answer event (DPÊO_No_Answer) is reported from the Routing and Alerting PIC. - New routeing information is received when the Disconnect event is reported from the O_Active PIC. Actions: - Compare the called party number with the dialled services information. Exit events: - Availability of routeing address and nature of address. (DPÊAnalysed_Information). - An exception condition is encountered (e.g. invalid number); this leads to the O_Exception PIC. - The calling party abandons the call; this leads to the O_Abandon DP. 4.4.2.1.1.3 Routing Entry events: - Availability of routeing address and nature of address. (DPÊAnalysed_Information). Actions: - Information is being analysed and/or translated according to dialling plan to determine routeing address. - Routeing address being interpreted. - Mobile Originating or forwarded call: Outgoing barring services and ODB categories not already applied are checked and invoked if necessary. - Trunk Originating call: Any operator specific service checks in the originating MSC are performed. Exit events: - An alerting indication (ISUP ACM) is received from the terminating party; this leads to the O_Term_Seized DP. - The attempt to select the route for the call fails; this leads to the Route_Select_Failure DP. - A busy indication is received from the terminating party; this leads to the O_Busy DP. - A not reachable indication is received from the terminating party; this leads to the O_Busy DP. - A no reply indication is received from the terminating party or a no reply condition is determined at the MSC/ gsmSSF; this leads to the O_No_Answer DP - An indication is received from the terminating half BCSM that the call is accepted and answered by the terminating party; this leads to O_Answer DP. - The calling party abandons the call' this leads to the O_Abandon DP. - An exception condition is encountered; this leads to the O_Exception PIC. 4.4.2.1.1.4 O_Alerting Entry events: - Called Party is being alerted (DPÊO_Term_Seized). - Continue is received in O_Mid_Call DP. Actions: - Call is being processed by the terminating half BCSM. Waiting for indication from terminating half BCSM that the call has been answered by terminating party. - Send a notification to the gsmSCF if the originating party changes position and DPÊO_Change_Of_Position is armed. Exit events: - An indication is received from the terminating half BCSM that the call is accepted and answered by the terminating party; this leads to the O_Answer DP. - A route select failure indication is received from the terminating party; this leads to the Route_Select_Failure DP. - A busy indication is received from the terminating party; this leads to the O_Busy DP. - A not reachable indication is received from the terminating party; this leads to the O_Busy DP. - A no reply indication is received from the terminating party or a no reply condition is determined at the MSC/ gsmSSF; this leads to the O_No_Answer DP. - The calling party abandons the call; this leads to the O_Abandon DP. - An exception condition is encountered; this leads to the O_Exception PIC. 4.4.2.1.1.5 O_Active Entry events: - Indication from the terminating half BCSM that the call is accepted and answered by the terminating party. (DPÊO_Answer) - Continue is received in O_Mid_Call DP. Actions: - Connection established between originating party and terminating party. Call supervision is provided. - Send a notification to the gsmSCF if the originating party changes position and DPÊO_Change_Of_Position is armed. - Send a notification to the gsmSCF if the bearer is changed due to the SCUDIF and DPÊO_Service_Change is armed. - Call release is awaited. Exit events: - A service/service feature request is received from the originating party (DTMF) or DPÊO_Mid_Call is used for Call Party Handling (DPÊO_Mid_Call). - A disconnection indication is received from the originating party, or received from the terminating party via the terminating half BCSM (DPÊO_Disconnect). - An exception condition is encountered. 4.4.2.1.1.6 O_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIC can not be met. Actions: - Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If any relationship exists between the gsmSSF and the gsmSCF, the gsmSSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion. - The (G)MSC/gsmSSF should make use of vendor-specific procedures to ensure release of resources within the (G)MSC/gsmSSF, so that line, trunk and other resources are made available for new calls. Exit events: - Default handling of the exception condition by gsmSSF/(G)MSC completed. 4.4.3 Terminating Basic Call State Model (T BCSM) 4.4.3.1 Description of T BCSM The T BCSM is used to describe the actions in a GMSC and in a VMSC during terminating calls. When encountering a DP the T BCSM processing is suspended at the DP and the GMSC or VMSC indicates this to the gsmSSF which determines what action, if any, shall be taken if the DP is armed. Figure 4.4: T BCSM in the GMSC or VMSC In the table below the different DPs (in the T BCSM) are described. Table 4.3: Description of T BCSM DPs in the GMSC or VMSC CAMEL Detection Point: DP Type Description: DPÊTerminating_Attempt_ Authorised TDP R Indication that the T CSI / VT CSI is analysed. DPÊT_Busy TDP RÊ(noteÊ2), EDP N, EDP R Indication that: - a busy indication is received from the destination exchange, - Busy event is determined in the visited MSC, - Not reachable or call establishment failure event is determined from the HLR response or upon a cause IE in the ISUP Release message. DPÊT_No_Answer TDP R (noteÊ2), EDP N, EDP R Indication that: - an application timer associated with the T_No_Answer DP expires - a no answer event is determined from a cause IE in the ISUP Release message. DPÊCall_Accepted EDP N, EDP R Indication that the called party is being alerted. DPÊT_Answer EDP N, EDP R Call is accepted and answered by terminating party. DPÊT_Mid_Call EDP N, EDP R Indication that a service/service feature is received from the terminating party (DTMF - noteÊ3, noteÊ4). DPÊT_Change_Of_Position EDP N Indication that the terminating party has changed position (noteÊ5). DPÊT_Disconnect EDP N, EDP R A disconnect indication is received from the terminating party or from the originating party. DPÊT_Abandon EDP N, EDP R A disconnect indication is received from the originating party during the call establishment procedure. DPÊT_Service_Change EDP N Indication that the bearer service has changed. NOTE 1: The DPs are defined in ITU T Recommendation Q.1224Ê[44]. NOTE 2: DPÊT_No_Answer and DPÊT_Busy shall be reported as TDP R when there is no relationship to gsmSCF. If a relationship to gsmSCF is already open, it shall be reported as EDP R or EDP N if armed so. NOTE 3: DTMF is only applicable for the VMSC but not for the GMSC. DTMF is not applicable at the T_Alerting PIC. NOTE 4: Call Processing is suspended at DPÊT_Mid_Call if a Call Party Handling information flow is handled. However, the DP is not reported. NOTE 5: DPÊT_Change_Of_Position is applicable only for the Mobile Terminating Call in the VMSC. 4.4.3.1.1 Description of the call model (PICs) This subclause describes the call model for terminating calls in the GMSC and in the VMSC. For each PIC a description can be found of the entry events, functions, information available and exit events. It should be noted that although the names used for PICs match those used in ITU T Recommendation Q.1224Ê[44] the specific descriptions differ. 4.4.3.1.1.1 T_Null Entry events: - Disconnection and clearing of a previous call (DPÊT_Disconnect) or default handling of exceptions by gsmSSF/GMSC or VMSC completed. - Abandon event is reported from Terminating Call Handling PIC. - Exception event is reported. Actions: - Interface is idled. - If ISUP Initial Address Message is received, the appropriate information is analysed. - If the T BCSM is in the GMSC, a Send Routeing Info information flow is sent to the HLR. - If the T BCSM is in the VMSC, a Send Info For Incoming Call information flow is sent to the VLR. - If the T BCSM is in the GMSC: - The supplementary services ""barring of all incoming calls"" and ""barring of incoming calls when roaming"" are checked in the HLR and invoked if necessary. - The ODB categories ""barring of all incoming calls"" and ""barring of incoming calls when roaming"" are checked in the HLR and ODB is invoked if necessary. - The supplementary service ""CUG"" is checked in the HLR and invoked if necessary. - T CSI/VT CSI is received and analysed. Exit events: - Response is received from HLR or VLR and terminating CSI (if available) is analysed. - An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP. Example exception condition is: - The calling party abandons call. 4.4.3.1.1.2 Terminating Call Handling Entry events: - Response is received from HLR or VLR and terminating CSI (if available) is analysed (DPÊTerminating_Attempt_Authorised). - New routeing information is received when a Busy or not reachable event (DPÊT_Busy) or a No Answer event (DPÊT_No_Answer) is reported from the Terminating Call Handling PIC. - New routeing information is received when a Disconnect event is reported from the T_Active PIC."
"NOTE: The HLR may use MAP signalling to indicate to the GMSC before the call is extended to the destination VMSC that the terminating party is not reachable, or the destination VMSC may use telephony signalling to indicate to the GMSC after the call has been extended to the destination VMSC that the terminating party is not reachable. Actions: - The response from the HLR or VLR is analysed. - Routeing address and call type are interpreted. The next route or terminating access is selected. - The Call Forwarding supplementary service is invoked if necessary. Exit events: - The call is accepted and answered by terminating party; this leads to the T_Answer DP. - An indication is received that the called party is being alerted; this leads to the Call_Accepted DP. - An exception condition is encountered; this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC or GMSC was not successful. - The calling party abandons the call; this leads to the T_Abandon DP. - The terminating access is busy in the VMSC or a busy indication is received from the destination exchange in the GMSC; this leads to the T_Busy DP. - A not reachable event detected or failure of attempt to select the route for the terminating leg in the GMSC fails or the MS cannot be reached in the VMSC; this leads to the T_Busy DP. - The no reply timer expires; this leads to the T_No_Answer DP. 4.4.3.1.1.3 T_Alerting Entry events: - Called party is being alerted (DPÊCall_Accepted) - Continue is received in T_Mid_Call DP. Actions: - Waiting for the call to be answered by terminating party. - The Call Forwarding supplementary service is invoked if necessary. - Send a notification to the gsmSCF if the terminating party changes position and DPÊT_Change_Of_Position is armed. Exit events: - The call is accepted and answered by terminating party; this leads to the T_Answer DP. - An exception condition is encountered; this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC or GMSC was not successful. - The calling party abandons the call; this leads to the T_Abandon DP. - A busy indication (UDUB) is received from the destination exchange; this leads to the T_Busy DP. - A not reachable event is detected or the attempt to select the route for the terminating leg in the GMSC fails or the MS cannot be reached in the VMSC; this leads to the T_Busy DP. - The no reply timer expires; this leads to the T_No_Answer DP. - A Call Party Handling information flow is executed; this leads to the T_Mid_Call DP. 4.4.3.1.1.4 T_Active Entry events: - Indication that the call is accepted and answered by the terminating party. (DPÊT_Answer). - Continue is received in T_Mid_Call DP. Actions: - Connection established between originating party and terminating party. Call supervision is being provided. - Send a notification to the gsmSCF if the terminating party changes position and DPÊT_Change_Of_Position is armed. - Send a notification to the gsmSCF if the bearer is changed due to the SCUDIF and DPÊT_Service_Change is armed. - Wait for call release. Exit events: - A disconnection indication is received from the terminating party, or received from the originating party via the originating half BCSM; this leads to the T_Disconnect DP. - An exception condition is encountered. In addition to the specific examples listed above, exception events include any type of failure that means that the normal exit events for a PIC cannot be met. - A service/service feature request is received from the called party (DTMF) or a Call Party Handling information flow is executed; this leads to the T_Mid_Call DP. 4.4.3.1.1.5 T_Exception Entry events: - An exception condition is encountered. In addition to the specific examples listed above, exception events include any type of failure, which means that the normal exit events for PIC cannot be met. Actions: - Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If any relationship exists between the gsmSSF and the gsmSCF, the gsmSSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion. - The GMSC or VMSC / gsmSSF should make use of vendor-specific procedures to ensure release of resources within the GMSC or VMSC / gsmSSF, so that line, trunk and other resources are made available for new calls. Exit events: - Default handling of the exception condition by gsmSSF/GMSC is completed. 4.4.4 Rules for Implicit Disarming of Event Detection Points The tables below give the rules for implicit disarming of event detection points. Implicit EDP disarming rules are specified in the tables below for Originating BCSM and Terminating BCSM respectively. Each table specifies which EDP's shall be disarmed (i.e. MonitorMode set to Transparent) if/when each EDP is encountered, irrespective of the EDP's Monitor Mode (Transparent, Notify And Continue, or Request). When EDPs armed with MonitorMode 'Request' (EDP Rs) are encountered, any implicit EDP disarming shall take place before reporting the EDP and transiting the gsmSSF to the Waiting_For_Instruction state (if not already suspended in the Waiting_For_Instruction state). If the BCSM has encountered DPÊO/T_Answer then an originator release must be detected as a DPÊO/T_Disconnect. The table entry 'X' means that if the DP is encountered (independently of arming and reporting to the gsmSCF) the marked DP is implicitly disarmed. It shall be possible to rearm explicitly an implicitly disarmed DP, e.g. for follow on call. Table 4.4: Implicit disarmed DPs in the O BCSM Encountered DP Implicit disarmed DPs Collected_Info Route_Select_Failure O_Busy O_No_Answer O_Answer O_Mid_Call Leg 1 O_Disconnect Leg 1 O_Disconnect any other Leg O_Abandon O_Term_Seized O_Change_Of_Position O_Service_Change Collected_Info X Route_Select_Failure X X X X X X O_Busy X X X X X X O_No_Answer X X X X X X O_Answer X X X X X X O_Mid_Call Leg 1 (noteÊ1) X O_Disconnect Leg 1 X X X X X O_Disconnect any other Leg X X X X X X O_Abandon X X X X X X O_Term_Seized X O_Change_Of_Position (noteÊ1) X O_Service_Change (noteÊ1) X Note 1 If the Automatic Rearm IE was present in the Request Report BCSM Event information flow for the O_Change_Of_Position DP, O_Service_Change or the O_Mid_Call DP and armed as EDP N, then the DP shall be automatically rearmed by the gsmSSF when it is encountered. Table 4.5: Implicit disarmed DPs in the T BCSM Encountered DP Implicit disarmed DPs T_Busy T_No_Answer T_Answer T_Mid_Call Leg 2 T_Disconnect Leg 1 T_Disconnect Leg 2 T_Abandon Call_Accepted T_Change_Of_Position T_Service_Change T_Busy X X X X X X X X T_No_Answer X X X X X X X X T_Answer X X X X X T_Mid_Call Leg 2 (noteÊ1) X T_Disconnect Leg 1 X X T_Disconnect Leg 2 X X X X X X X X T_Abandon X X Call_Accepted X T_Change_Of_Position (noteÊ1) X T_Service_Change (noteÊ1) X Note 1 If the Automatic Rearm IE was present in the Request Report BCSM Event information flow for the T_Change_Of_Position DP, T_Service_Change or the T_Mid_Call DP and armed as EDP N, then the DP shall be automatically rearmed by the gsmSSF when it is encountered. 4.4.5 BCSM Modelling of Call Scenarios This subclause describes how the BCSMs defined above are used to model CS call scenarios. For each scenario the used and unused BCSMs involved in the call are shown. In some cases these models may have an allocation to physical nodes different from that shown. However, the physical separation of the logical functions shown shall not impact the modelling. This subclause describes the call scenarios without optimal routeing. If optimal routeing is invoked then the physical configurations may be different from those shown, but the modelling is not changed. CAMEL may be applied simultaneously and independently for each subscriber involved in a call. This is not shown in these scenarios. Subscribers other than those being served by CAMEL may be either PSTN subscribers, other subscribers or any other addressable subscriber. 4.4.5.1 Mobile Originated Call For the call from A to B, an instance of the O BCSM will be created in the MSC (labelled ""O(A B)""). If the A party has an active O CSI or D CSI, or the MSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship with gsmSCF(1) shall be established. Figure 4.5: BCSM Scenario for Mobile Originated Call 4.4.5.2 Mobile Terminated Call at the GMSC or VMSC For the call from A to B, an instance of the T BCSM will be created in the GMSC (labelled ""T(A B)"") and an instance of the T BCSM will be created in the VMSC (labelled ""T(A B)""). If the B party has an active T CSI in the GMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC and the gsmSCF(1) shall be established. If the B party has an active VT CSI in the VMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the VMSC and the gsmSCF(2) shall be established. The relationships with gsmSCF (1) and gsmSCF(2) may exist simultaneously. The two gsmSCF endpoints of the relationships are treated independently. The nodes gsmSCF (1) and gsmSCF (2) may be the same or different entities. Figure 4.6: BCSM Scenario for Mobile Terminated Calls at the GMSC or VMSC 4.4.5.3 Call Forwarding at the GMSC or VMSC If the B party has an active T CSI in the GMSC or VT CSI in the VMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(1) shall be established. Following processing at the GMSC or VMSC the call will be extended to the VMSC serving the B party. This VMSC may be physically integrated with the GMSC. A new call leg to a ""C"" party shall be created if: - a Call Forwarding supplementary service or Call Deflection supplementary service forwards the call to C. An instance of the O BCSM O(B C) will be created for the forwarding leg. If the B party has an active O CSI or D CSI in the GMSC or VMSC, or the GMSC or VMSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(2) shall be established. If the GMSC or VMSC receives the 'Suppress O-CSI' parameter, then O CSI shall not be used for the forwarding leg or deflecting leg; or - a CAMEL service in a control relationship with T(A B) performs a CAMEL-based call forwarding by using a Connect information flow. An instance of the O BCSM O(B C) will be created for the forwarding leg. If the B party has an active O CSI or D CSI in the GMSC or VMSC, or the GMSC or VMSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(2) shall be established. The O CSI shall be used for the forwarding leg only if the last Connect information flow includes the ""O CSI applicable"" flag. The relationship with gsmSCF (1) and the relationship with gsmSCF(2) may exist simultaneously. The two relationships are treated independently at the GMSC. The instance of the BCSM T(A B) and the instance of the BCSM O(B C) are linked by an internal interface which is assumed to behave in a similar way to an ISUP interface. The nodes gsmSCF (1) and gsmSCF (2) may be the same or different physical entities. Figure 4.7: BCSM Scenario for Call Forwarding at the GMSC or VMSC 4.4.5.4 gsmSCF Initiated Call When the gsmSCF wishes to originate a new call, the gsmSCF establishes communication with the network using CAP signalling. When the gsmSCF wishes to originate a new leg within an existing call, the gsmSCF uses the already established communication with the gsmSSF. It sends an Initiate Call Attempt information flow which shall contain the address of the called party. Afterwards the gsmSCF shall instruct the gsmSSF to continue with the call processing. The MSC constructs an ISUP Initial Address Message using the parameters received from the gsmSCF and sends it to the destination exchange. The O BCSM for the gsmSCF initiated call to B (labelled ""O(M B)"") is invoked on request of the gsmSCF. A control relationship with gsmSCF (1) is created for the initiation of a new call. NOTE: The term ISUP is used to denote UNI or NNI signalling system used in a given network. Figure 4.8: BCSM Scenario for gsmSCF Initiated New Call 4.4.5.5 Trunk Originated Call For the call from A to B, an instance of the O BCSM will be created in the MSC (labelled ""O(A B)""). If the MSC has an active TO CSI for the trunk on which the call has originated, or an active N-CSI, and the trigger criteria (if present) are fulfilled, then a CAMEL control relationship with gsmSCF(1) shall be established. Figure 4.4.5.5.1: BCSM Scenario for Trunk Originated Call 4.4.6 Leg Handling A call may consist of several call parties with each party connected to the call, e.g. there may be a calling party and several called parties. From a call handling point of view it is necessary to distinguish between a leg, which is a concept internal to the call handling model, and a connection, which is the external link to the party. A connection to the call party will be set up using telephony (e.g. ISUP) or radio access signalling. The outgoing leg already exists when the connection is set up. On the other hand, if a connection is released, e.g. because the destination user is busy, the leg still exists, and the gsmSCF can send a Connect Information Flow to connect this leg to another call party. 4.4.6.1 Leg is created For the purposes of the formal description, one or more legs are created in the following cases: - When a call is to be established, i.e. when an incoming Setup or ISUP IAM is being handled or when a call is to be forwarded, the incoming leg (leg1) and the outgoing leg (leg2) are created before the first CS_gsmSSF process is invoked for that call in this MSC. In particular, this applies before the Call Control Function (CCF) sends DP_Collected_Info (for originating, forwarded or deflected calls) or DP_Terminating_Attempt_Authorised (for terminating calls) to the CS_gsmSSF process; - When the CS_gsmSSF process receives an Initiate Call Attempt Information Flow, an outgoing leg is created. 4.4.6.2 Leg continues to exist For the purposes of the formal description, a leg continues to exist in the following cases: - The CCF sends any DP to the CS_gsmSSF the leg will continue to exist at least until the CS_gsmSSF instructs the CCF to continue its processing for the leg; - A connection to a called party is not successful and the gsmSCF sends a new Connect Information Flow for that leg; - A called party releases her connection and the gsmSCF sends a new Connect Information Flow for that leg; - The CS_gsmSSF processes either of the Call Party Handling Information Flows Move Leg and Split Leg; 4.4.6.3 Leg is released Before a leg is released the corresponding connection is released. All outstanding reports for the leg are sent to the gsmSCF and the corresponding call records are closed. For the purposes of the formal description, a leg ceases to exist when any of the following events occurs: - The calling party releases the connection, the CCF sends a DP to the CS_gsmSSF and the CCF receives Int_Continue or Int_Continue_With_Argument from the CS_gsmSSF process; - A connection to a called party is not successful (DPs Route_Select_Failure, O_Busy, O_No_Answer, T_Busy and T_No_Answer), the CCF sends a DP to the CS_gsmSSF and the CCF does not receive Int_Connect for that outgoing leg from the CS_gsmSSF; - The called party releases her connection, the CCF sends a DP to the CS_gsmSSF and the CCF does not receive Int_Connect for that outgoing leg from the CS_gsmSSF; - The CCF receives Int_Disconnect_Leg from the CS_gsmSSF; - The timer Tcp expires for a leg and the condition ""Release if duration exceeded"" is true for that leg; - The CCF receives Int_Release_Call from the CS_gsmSSF. If a call is released, either on instruction from the CS_gsmSSF or on normal call handling without any CAMEL interaction, then all legs involved in the call cease to exist. 4.4.6.4 Leg is moved A leg can be moved from one call segment (source call segment) to another call segment (target call segment) as a result of a Move Leg or Split Leg information flow. When the CSA_gsmSSF receives a Split Leg Information Flow it creates a new call segment and moves the specified leg into this call segment. When the CSA_gsmSSF receives a Move Leg Information Flow it moves the specified leg into call segmentÊ1. A leg is no longer contained in the source call segment when the source CS_gsmSSF receives Int_Export_Leg_ack from the CCF. A leg is contained in the target call segment when the target CS_gsmSSF receives Int_Import_Leg_ack from the CCF. 4.5 Procedures for CAMEL The SDLs in the present document illustrate how CAMEL modifies the normal call handling. They do not attempt to show all the details of call handling in nodes that support CAMEL. Relevant parts of 3GPP TSÊ23.018Ê[12] apply in addition to these SDLs. For example, some inputs leading to unsuccessful call attempts are not shown on these diagrams - corresponding clauses in 3GPP TSÊ23.018Ê[12] apply. Note that in some SDL processes and procedures the Release information flow may be sent on both an access interface and an inter-switch interface. If the message is sent on a UNI, its effect is the same as a Release transaction information flow. The text in this clause is a supplement to the definition in the SDL diagrams; it does not duplicate the information in the SDL diagrams. 4.5.1 Overall SDL architecture The following mapping from the SDL procedures to the Intelligent Network concepts apply: SDL process Description SDL process specification CSA_gsmSSF Call Segment Association (CSA). The CSA SDL process distributes the CAP operations to the appropriate Call Segment(s). 3GPP TSÊ23.078 CS_gsmSSF Call Segment (CS). Controls one or more BCSMs. 3GPP TSÊ23.078 OCH_MSC O BCSM in VMSC for Mobile Originating call controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_OCH_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_OCH_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_OCH_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 MT_GMSC T BCSM in the GMSC controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Terminating_Attempt_Authorised), then the call is not routed to the destination and the process spawns the child process CAMEL_MT_LEG1_GMSC to control LegÊ1. The process MT_GMSC terminates. If Answer is received, the process spawns the child process CAMEL_MT_LEG1_GMSC to control LegÊ1 and calls the procedure CAMEL_MT_LEG2_GMSC to control LegÊ2. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 MT_CF_MSC O BCSM in the redirecting MSC for Call Forwarding supplementary service, or Call Deflection supplementary service, or for CAMEL-based call forwarding. This process controls both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_MT_CF_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_MT_CF_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_MT_CF_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 ICH_MSC T BCSM in the VMSC controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Terminating_Attempt_Authorised), then the call is not routed to the destination and the process spawns the child process CAMEL_ICH_LEG1_MSC to control LegÊ1. The process ICH_MSC terminates. If Answer is received, the process spawns the child process CAMEL_ICH_LEG1_MSC to control LegÊ1 and calls the procedure CAMEL_ICH_LEG2_MSC to control LegÊ2. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 TO_MSC O-BCSM in the inter-connecting MSC for trunk originated calls. This process controls both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_TOC_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_MT_CF_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_TOC_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 Assisting_MSC The process in the MSC to handle an assist request. 3GPP TSÊ23.078 CAMEL_ICA_MSC O BCSM for gsmSCF initiated new call, or for new party set-up. This process controls the new leg. 3GPP TSÊ23.078 The following general rules apply: 1 There is only one CSA per CAP dialogue. 2 The CSA controls one or more Call Segments. 3 A Call Segment controls one or more BCSMs. Due to Call Party Handling, legs may be moved from one Call Segment to another and new Call Segments may be created. When legs are moved they take their properties with them, i.e. armed EDPs and pending reports. 4 Legs are not moved between BCSMs. 5 The active legs in the same Call Segment have a voice connection. They hear each other and the same in-band tone and announcements. The following exceptions exist: - Apply Charging IF: the warning tone associated with the Apply Charging IF is played to a single call party in the Call Segment. - Play Tone IF: the flexible tone from the Play Tone IF may be played to a single call party in the Call Segment. The following diagrams shows the overall architecture for the SDL diagrams. Figure 4.9-1: Outgoing case (gsmSSF relay) Figure 4.9-2: Outgoing case (direct path gsmSCF to gsmSRF or assist with relay) Figure 4.9-3: Terminating GMSC case (gsmSSF relay) Figure 4.9-4: Terminating GMSC case (direct path gsmSCF to gsmSRF or assist with relay) NOTE: The ICH_MSC may also be connected via an A interface to the terminating Mobile Station. Figure 4.9-5: Terminating VMSC case (gsmSSF relay) NOTE: The ICH_MSC may also be connected via an A interface to the terminating Mobile Station Figure 4.9-6: Terminating VMSC case (direct path gsmSCF to gsmSRF or assist with relay) Figure 4.9-7: Assisting case Figure 4.9-8: gsmSCF initiated call case (gsmSSF relay) Figure 4.9-9: Trunk Originating case (gsmSSF relay) 4.5.2 Handling of mobile originated calls 4.5.2.1 Handling of mobile originated calls in the originating MSC The functional behaviour of the originating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_OCH_MSC_INIT; - Procedure CAMEL_MO_Dialled_Services; - Procedure CAMEL_OCH_MSC_ALERTING; - Procedure CAMEL_OCH_MSC_ANSWER; - Procedure CAMEL_OCH_MSC1; - Procedure CAMEL_OCH_MSC2; - Procedure CAMEL_OCH_MSC_DISC1; - Procedure CAMEL_OCH_MSC_DISC2; - Procedure CAMEL_OCH_MSC_DISC3; - Procedure CAMEL_OCH_MSC_DISC4; - Procedure CAMEL_Disconnect_CTR_SRF; - Procedure CAMEL_OCH_ETC; - Procedure CAMEL_OCH_CTR; - Procedure CAMEL_Start_TNRy; - Procedure CAMEL_Stop_TNRy; - Procedure CAMEL_Store_Destination_Address; - Procedure CAMEL_Modify_CUG_Info; - Procedure CAMEL_N_CSI_CHECK_MSC; - Procedure CAMEL_OCH_LEG1_MSC; - Procedure CHECK_DIGIT_STRING_MSC; - Process CAMEL_OCH_LEG2_MSC; - Process CAMEL_OCH_RECONNECT_MSC; - Procedure CAMEL_EXPORT_LEG_MSC; - Process CAMEL_O_CHANGE_OF_POSITION_MSC; - Procedure CAMEL_O_SCUDIF_MSC. NOTE: Procedure CAMEL_OCH_MSC_DISC3 applies to CAMEL PhaseÊ1 only. The procedure Send_Access_Connect_If_Required is specified in 3GPP TSÊ23.018Ê[12]. The procedure CAMEL_OCH_LEG1_MSC supervises the originating party only. The process CAMEL_OCH_LEG2_MSC supervises the terminating party only. Hence, signals from the BSS are received by the procedure CAMEL_OCH_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_OCH_LEG2_MSC. The following paragraphs give details on the behaviour of the MSC in the procedures CAMEL_OCH_MSC_INIT, CAMEL_OCH_ETC, CAMEL_OCH_ANSWER and CAMEL_Store_Destination_Address. 4.5.2.1.1 Actions of the MSC on receipt of Int_Error The MSC checks the default Call Handling parameter in the relevant CSI. If the default call handling is release call, a Release is sent to the MS and an Abort to the VLR. The MSC then releases all call resources and the procedure CAMEL_OCH_MSC_INIT ends. If the default call handling is continue call, the MSC continues processing without CAMEL support. It sends Send_Info_For_Ougoing_Call to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.2 Actions of the MSC on receipt of Int_Continue The MSC continues processing without any modification of call parameters. At DPÊAnalysed_Information it sends Send Info For Ougoing Call information flow to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument The MSC continues processing with modified call parameters. The MSC shall replace the call parameters by the information received in the Int_Continue_With_Argument signal. Call parameters which are not included in the Int_Continue_With_Argument signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.2.1.4 Actions of the MSC on receipt of Int_Connect The MSC continues processing with modified call parameters. The MSC shall transparently modify the call parameters with the received information. The MSC then sends a PROGRESS message to the MS. Call parameters which are not included in the Int_Connect signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. At DPÊCollected_Information the MSC sets the O CSI suppression parameter. If D CSI and N CSI are not present, the MSC sends a Send Info For Outgoing Call to the VLR and waits in state Wait_For_MO_Call_Result. At DPÊAnalysed_Information it sets the D CSI suppression parameter, sends a Send Info For Outgoing Call to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.5 Actions of the MSC on receipt of Int_Release_Call A Release is sent to the MS, an abort to the VLR and a Release is sent to the destination exchange. The release cause received in the Int_Release_Call signal is used. The MSC then releases all call resources and the procedure CAMEL_OCH_MSC_INIT ends. 4.5.2.1.6 Actions of the MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.2.1.7 Actions of the MSC on receipt of Int_Apply_Warning_Tone This section applies to all call cases. The MSC will play a tone to the indicated leg or call segment. The following special cases exist when there is already an existing tone to a leg or call segment: 1 If the MSC is playing a tone to a leg and the Int_Apply_Warning_Tone instructs the MSC to play a tone for another leg (in the same or a different call segment), then the tones will be played independently; 2 The tones for different call segments are independent; 3 If the MSC is playing a tone to a leg and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that leg, then the MSC will stop the existing tone and the latter tone will be played for that leg. 4 If the MSC is playing a tone to a call segment and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that call segment, then the MSC will stop the existing tone and the latter tone will be played for that call segment. 5 If the MSC is playing a tone for the call segment and the Int_Apply_Warning_Tone instructs the MSC to play another tone for a leg in that call segment, then the particular leg shall hear (as an MSC option) either: a The latter tone only, or b Two tones. As an MSC option, the two tones may be played in parallel or in a sequence. The other leg(s) shall keep hearing the (old) call segment tone. 6 If the MSC is playing a tone for a leg and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that call segment, then the particular leg shall either hear (as an MSC option): a The latter tone only, or b Two tones. As an MSC option, the two tones may be played in parallel or in a sequence. The other leg(s) shall start hearing the new call segment tone. 4.5.2.1.8 Action of the MSC in procedure CAMEL_OCH_MSC_ANSWER If the MSC received a destination address from the GMSC in the ISUP Answer or Connect Message, the MSC relays the destination address to the gsmSSF in the Int_DP_O_Answer signal. NOTEÊ1: The sending of e-parameters by the gsmSCF after receiving the DP_O_Answer indication may be to late. NOTEÊ2: If the MO call is not subject to Basic OR, then the destination address is generated by the MSC. If the MO call is subject to Basic OR, the MSC will receive a destination address from the GMSC in the ISUP Answer or Connect Message. 4.5.2.1.9 Action of the MSC in procedure CAMEL_OCH_ETC In procedure CAMEL_OCH_ETC (sheet 2) the MSC will remain in the Wait_For_Assisting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). If a Progress Message is sent towards the MS the progress indicator shall indicate ""In Band Information"". 4.5.2.1.10 Procedure CAMEL_OCH_LEG1_MSC The Int_DTMF_Digit_Received information flow is received from an internal process in the MSC that receives DTMF signalling from the MS. The handling of the internal process that receives DTMF signalling is out of scope of the present document. The playing of the received DTMF tones to the other parties in the call segment is out of scope of the present document. 4.5.2.1.11 Process CAMEL_O_CHANGE_OF_POSITION_MSC The signals HANDOVER COMPLETE and HANDOVER PERFORMED are specified in 3GPP TSÊ48.008Ê[39]. Signals RELOCATION REQUEST ACKNOWLEDGE, LOCATION REPORT and LOCATION REPORTING COMMAND are specified in 3GPP TSÊ25.413Ê[33]. 4.5.2.1.12 Procedure CAMEL_Start_TNRy The recommended value range in the gsmSSF for the default TNRy timer for CAMEL handling is 10 seconds to 3 minutes. The CSE provided TNRy value is applied only once per outgoing leg. The decision ""TNRy received?"" decision box goes to ""No"" branch if the TNRy duration has been used for once and no new timer value has been received since previous call of this procedure. The task box ""Cancel TNRy received"" ensures that the gsmSCF provided timer is applied only once per call leg. The task box prevents the use of previously received timer value from the gsmSCF in subsequent calls (e.g. as in the case of a follow-on call). For example: The gsmSCF arms O_No_Answer EDP and also sent a TNRy timer duration. The call fails and EDP O_No_Answer is reported to the gsmSCF. The gsmSCF sends a Connect (i.e. follow-on call), and also arms EDP O_No_Answer, but this time, with no TNRy timer duration included. The gsmSSF does not use the TNRy timer previously provided by the gsmSCF. Instead, the network's default TNRy timer is used if available for the follow-on call. Figure 4.10-1: Procedure CAMEL_OCH_MSC_INIT (sheet 1) Figure 4.10-2: Procedure CAMEL_OCH_MSC_INIT (sheet 2) Figure 4.10-3: Procedure CAMEL_OCH_MSC_INIT (sheet 3) Figure 4.10-4: Procedure CAMEL_OCH_MSC_INIT (sheet 4) Figure 4.11-1: Procedure CAMEL_MO_Dialled_Services (sheet 1) Figure 4.11-2: Procedure CAMEL_MO_Dialled_Services (sheet 2) Figure 4.11-3: Procedure CAMEL_MO_Dialled_Services (sheet 3) Figure 4.12-1: Procedure CAMEL_SDS_MO_Init (sheet 1) Figure 4.12-2: Procedure CAMEL_SDS_MO_INIT (sheet 2) Figure 4.12-3: Procedure CAMEL_SDS_MO_INIT (sheet 3) Figure 4.12-4: Procedure CAMEL_SDS_MO_INIT (sheet 4) Figure 4.13-1: Procedure CAMEL_NDS_MO_INIT (sheet 1) Figure 4.13-2: Procedure CAMEL_NDS_MO_INIT (sheet 2) Figure 4.13-3: Procedure CAMEL_NDS_MO_INIT (sheet 3) Figure 4.13-4: Procedure CAMEL_NDS_MO_INIT (sheet 4) Figure 4.14-1: Procedure CAMEL_OCH_MSC_ALERTING (sheet 1) Figure 4.14-2: Procedure CAMEL_OCH_MSC_ALERTING (sheet 2) Figure 4.14-3: Procedure CAMEL_OCH_MSC_ALERTING (sheet 3) Figure 4.15-1: Procedure CAMEL_OCH_MSC_ANSWER (sheet 1) Figure 4.15-2: Procedure CAMEL_OCH_ANSWER (sheet 2) Figure 4.15-3: Procedure CAMEL_OCH_ANSWER (sheet 3) Figure 4.16-1: Procedure CAMEL_OCH_MSC1 (sheet 1) Figure 4.16-2: Procedure CAMEL_OCH_MSC1 (sheet 2) Figure 4.16-3: Procedure CAMEL_OCH_MSC1 (sheet 3) Figure 4.17-1: Procedure CAMEL_OCH_MSC2 (sheet 1) Figure 4.17-2: Procedure CAMEL_OCH_MSC2 (sheet 2) Figure 4.17-3: Procedure CAMEL_OCH_MSC2 (sheet 3) Figure 4.18-1: Procedure CAMEL_OCH_MSC_DISC1 (sheet 1) Figure 4.19-1: Procedure CAMEL_OCH_MSC_DISC2 (sheet 1) Figure 4.19-2: Procedure CAMEL_OCH_MSC_DISC2 (sheet 2) Figure 4.20-1: Procedure CAMEL_OCH_MSC_DISC3 (sheet 1) Figure 4.21-1: Procedure CAMEL_OCH_MSC_DISC4 (sheet 1) Figure 4.22-1: Procedure CAMEL_Disconnect_CTR_SRF (sheet 1) Figure 4.23-1: Procedure CAMEL_OCH_ETC (sheet 1) Figure 4.23-2: Procedure CAMEL_OCH_ETC (sheet 2) Figure 4.23-3: Procedure CAMEL_OCH_ETC (sheet 3) Figure 4.23-4: Procedure CAMEL_OCH_ETC (sheet 4) Figure 4.24-1: Procedure CAMEL_OCH_CTR (sheet 1) Figure 4.24-2: Procedure CAMEL_OCH_CTR (sheet 2) Figure 4.24-3: Procedure CAMEL_OCH_CTR (sheet 3) Figure 4.24-4: Procedure CAMEL_OCH_CTR (sheet 4) Figure 4.24-5: Procedure CAMEL_OCH_CTR (sheet 5) Figure 4.25-1: Procedure CAMEL_Start_TNRy (sheet 1) Figure 4.26-1: Procedure CAMEL_Stop_TNRy (sheet 1) Figure 4.27-1: Procedure CAMEL_Store_Destination_Address (sheet 1) Figure 4.28-1: Procedure CAMEL_Modify_CUG_Info (sheet 1) Figure 4.29-1: Procedure CAMEL_N_CSI_CHECK_MSC (sheet 1) Figure 4.30-1: Procedure CAMEL_OCH_LEG1_MSC (sheet 1) Figure 4.30-2: Procedure CAMEL_OCH_LEG1_MSC (sheet 2) Figure 4.30-3: Procedure CAMEL_OCH_LEG1_MSC (sheet 3) Figure 4.30-4: Procedure CAMEL_OCH_LEG1_MSC (sheet 4) Figure 4.30-5: Procedure CAMEL_OCH_LEG1_MSC (sheet 5) Figure 4.30-6: Procedure CAMEL_OCH_LEG1_MSC (sheet 6) Figure 4.30-7: Procedure CAMEL_OCH_LEG1_MSC (sheet 7) Figure 4.30-8: Procedure CAMEL_OCH_LEG1_MSC (sheet 8) Figure 4.30-9: Procedure CAMEL_OCH_LEG1_MSC (sheet 9) Figure 4.30-10: Procedure CAMEL_OCH_LEG1_MSC (sheet 10) Figure 4.30-11: Procedure CAMEL_OCH_LEG1_MSC (sheet 11) Figure 4.30-12: Procedure CAMEL_OCH_LEG1_MSC (sheet 12) Figure 4.30-13: Procedure CAMEL_OCH_LEG1_MSC (sheet 13) Figure 4.31-1: Procedure CHECK_DIGIT_STRING_MSC (sheet 1) Figure 4.32-1: Process CAMEL_OCH_LEG2_MSC (sheet 1) Figure 4.32-2: Process CAMEL_OCH_LEG2_MSC (sheet 2) Figure 4.33-1: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 1) Figure 4.33-2: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 2) Figure 4.33-3: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 3) Figure 4.33-4: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 4) Figure 4.33-5: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 5) Figure 4.33-6: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 6) Figure 4.33-7: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 7) Figure 4.33-8: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 8) Figure 4.33-9: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 9) Figure 4.34-1: Procedure CAMEL_EXPORT_LEG_MSC (sheet 1) Figure 4.34-2: Procedure CAMEL_EXPORT_LEG_MSC (sheet 2) Figure 4.35-1: Process CAMEL_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.36-1: Process CAMEL_O_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.36-2: Process CAMEL_O_CHANGE_OF_POSITION_MSC (sheet 2) Figure 4.37-1: Procedure Check_Criteria_Change_Of_Position (sheet 1) Figure 4.38-1: Procedure CAMEL_O_SCUDIF_MSC (sheet 1) 4.5.2.2 Handling of mobile originating calls in the originating VLR The functional behaviour of the originating VLR is specified in 3GPP TSÊ23.018Ê[12]. The procedure specific to CAMEL are specified in this subclause: - Procedure CAMEL_OCH_VLR; - Process CAMEL_Reconnected_Call_VLR. Figure 4.39-1: Procedure CAMEL_OCH_VLR (sheet 1) Figure 4.40-1: Process CAMEL_Reconnected_Call_VLR (sheet 1) 4.5.3 Retrieval of routeing information 4.5.3.1 Retrieval of routeing information in the GMSC The functional behaviour of the GMSC is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_Set_ORA_Parameters; - Procedure CAMEL_MT_GMSC_INIT; - Procedure CAMEL_MT_MSC_ALERTING; - Procedure CAMEL_MT_GMSC_ANSWER; - Procedure CAMEL_MT_GMSC_DISC1; - Procedure CAMEL_MT_GMSC_DISC2; - Procedure CAMEL_MT_GMSC_DISC3; - Procedure CAMEL_MT_GMSC_DISC4; - Procedure CAMEL_MT_GMSC_DISC5; - Procedure CAMEL_MT_GMSC_DISC6; - Procedure CAMEL_MT_CTR; - Procedure CAMEL_MT_ETC; - Procedure CAMEL_Start_TNRy; - Procedure CAMEL_Stop_TNRy; - Procedure CAMEL_MT_GMSC_Notify_CF; - Procedure CAMEL_MT_LEG2_GMSC; - Process CAMEL_MT_LEG1_GMSC; - Procedure CAMEL_MT_RECONNECT_GMSC; - Procedure CAMEL_T_SCUDIF_MSC. NOTE: Procedure CAMEL_MT_GMSC_DISC3 applies to CAMEL PhaseÊ1 only. The procedure Send_ACM_If_Required is specified in 3GPP TSÊ23.018Ê[12]. The procedure CAMEL_MT_LEG2_GMSC supervises the terminating party only. The process CAMEL_MT_LEG1_GMSC supervises the originating party only. Hence, signals from the destination exchange are received by the procedure CAMEL_MT_LEG2_GMSC and signals from the originating exchange are received by the process CAMEL_MT_LEG1_GMSC. The following paragraphs give details on the behaviour of the GMSC in the procedure CAMEL_MT_GMSC_INIT. 4.5.3.1.1 Action of the GMSC on receipt of Int_Release_Call An ISUP Release message is sent to the originating exchange and resources are released. 4.5.3.1.2 Action of the GMSC on receipt of Int_Error The GMSC checks the default call handling parameter in the T CSI. If the default call handling is release call, an ISUP Release message is sent to the originating exchange. The MSC then releases all call resources and the procedure CAMEL_MT_GMSC_INIT returns result=fail. If the default call handling is continue call, the MSC continues call handling without CAMEL support. 4.5.3.1.3 Action of the GMSC on receipt of Int_Continue If an FTN has been stored then the information received from the HLR is used to overwrite the corresponding call parameters. Note that the MSISDN is replaced by the FTN as the called party number. The redirection counter is incremented. If no FTN has been stored then a Send Routeing Info information flow including a T CSI suppression parameter is sent to the HLR. The Send Routing Info information flow includes an indication of which CAMEL Phases are supported by the GMSC/gsmSSF. 4.5.3.1.4 Action of the GMSC on receipt of Int_Continue_With_Argument If an FTN has been stored then the information received from the HLR is used to overwrite the corresponding call parameters. The MSISDN is replaced by the FTN as the called party number. The redirection counter is incremented."
"If no FTN has been stored then a Send Routeing Info information flow including a T CSI suppression parameter is sent to the HLR. The Send Routing Info information flow includes an indication of which CAMEL phases are supported by the GMSC/gsmSSF. The MSC shall replace the call parameters by the information received in the Int_Continue_With_Argument signal. Call parameters which are not included in the Int_Continue_With_Argument message are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.3.1.5 Action of the GMSC on receipt of Int_Connect If the Destination Number received from the gsmSCF (via the gsmSSF) is the same as the ISUP called party number, i.e. the MSISDN, the following parameters, if received, are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]): Calling Partys Category and Generic Number. If received, the Announcement Suppression Indicator is stored. The further processing is described in subclauseÊ4.5.3.1.3 with the addition that the Announcement Suppression indicator, if stored, is sent to the HLR in the Send Routeing Info message. If: - the Destination Number received from the gsmSCF (via the gsmSSF) is not the same as the stored ISUP called party number, i.e. the MSISDN, and - a CUG active indication was received from the HLR, and - CUG information was received in the ISUP IAM for the incoming call; then an exception event is reported to the process CS_gsmSSF, an ISUP Release Message is sent to the originating exchange. The MSC then releases all call resources and the procedure CAMEL_MT_GMSC_INIT returns result=fail. Otherwise the following parameters, if received, are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]): Destination Number, Calling Partys Category, Generic Number, Original Called Party ID, Redirecting Party ID and Redirection Information. Call parameters that are not included in the Int_Connect signal are unchanged. As a network operator option loop prevention mechanisms may cause the redirection information to be ignored or modified (e.g., if the Redirection counter has been decreased). Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. 4.5.3.1.6 Action of the GMSC on receipt of Send_Routeing_Info Negative Response (in state Wait_For_Routeing_Info_2) An exception event is reported to the process CS_gsmSSF. If the Announcement Suppression indicator has been received from the gsmSCF (via the gsmSSF) any announcements or tones shall be suppressed. 4.5.3.1.7 Action of the GMSC on receipt of Send_Routeing_Info ack with MSRN (in state Wait_For_Routeing_Info_2) An ISUP IAM with the MSRN as the called party number is constructed. 4.5.3.1.8 Action of the GMSC on receipt of Send_Routeing_Info ack with FTN (in state Wait_For_Routeing_Info_2) The information received from the HLR is used to overwrite the corresponding call parameters (for details see 3GPP TSÊ23.018Ê[12]). The redirection counter is incremented. 4.5.3.1.9 Action of the GMSC on receipt of Send_Routeing_Info ack with O CSI and/or D CSI and FTN (at state Wait_For_Routeing_Info_2) The information received from the HLR is used to overwrite corresponding call parameters. The redirection counter is incremented. The Called Party Number is set to the FTN. The O CSI and/or D CSI is stored. 4.5.3.1.10 Action of the GMSC in procedure CAMEL_MT_ETC In the procedure CAMEL_MT_ETC (sheet 2) the GMSC will remain in the Wait_For_Assiting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). If a Progress Message is sent towards the MS the progress indicator shall indicate ""In Band Information"". 4.5.3.1.11 Action of the GMSC in procedure CAMEL_MT_GMSC_Notify_CF The Forwarding reason is taken from the Send Routeing Info ack information flow (for early call forwarding) or the Resume Call Handling information flow (for Optimal Routeing of Late Call Forwarding). The Int_DP_T_No_Answer signal and Int_DP_T_Busy signal include a parameter to indicate that the call has encountered conditional call forwarding. The gsmSSF will transfer this parameter to the Event Report BCSM information flow which it sends to the gsmSCF. 4.5.3.1.12 Action of the MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. Figure 4.41-1: Procedure CAMEL_Set_ORA_Parameters (sheet 1) Figure 4.42-1: Procedure CAMEL_MT_GMSC_INIT (sheet 1) Figure 4.42-2: Procedure CAMEL_MT_GMSC_INIT (sheet 2) Figure 4.42-3: Procedure CAMEL_MT_GMSC_INIT (sheet 3) Figure 4.42-4: Procedure CAMEL_MT_GMSC_INIT (sheet 4) Figure 4.42-5: Procedure CAMEL_MT_GMSC_INIT (sheet 5) Figure 4.42-6: Procedure CAMEL_MT_GMSC_INIT (sheet 6) Figure 4.42-7: Procedure CAMEL_MT_GMSC_INIT (sheet 7) Figure 4.42-8: Procedure CAMEL_MT_GMSC_INIT (sheet 8) Figure 4.43-1: Procedure CAMEL_MT_MSC_ALERTING (sheet 1) Figure 4.43-2: Procedure CAMEL_MT_MSC_ALERTING (sheet 2) Figure 4.43-3: Procedure CAMEL_MT_MSC_ALERTING (sheet 3) Figure 4.44-1: Procedure CAMEL_MT_GMSC_ANSWER (sheet 1) Figure 4.44-2: Procedure CAMEL_MT_GMSC_ANSWER (sheet 2) Figure 4.44-3: Procedure CAMEL_MT_GMSC_ANSWER (sheet 3) Figure 4.45-1: Procedure CAMEL_MT_GMSC_DISC1 (sheet 1) Figure 4.46-1: Procedure CAMEL_MT_GMSC_DISC2 (sheet 1) Figure 4.46-2: Procedure CAMEL_MT_GMSC_DISC2 (sheet 2) Figure 4.47-1: Procedure CAMEL_MT_GMSC_DISC3 (sheet 1) Figure 4.48-1: Procedure CAMEL_MT_GMSC_DISC4 (sheet 1) Figure 4.48-2: Procedure CAMEL_MT_GMSC_DISC4 (sheet 2) Figure 4.48-3: Procedure CAMEL_MT_GMSC_DISC4 (sheet 3) Figure 4.49-1: Procedure CAMEL_MT_GMSC_DISC5 (sheet 1) Figure 4.49-2: Procedure CAMEL_MT_GMSC_DISC5 (sheet 2) Figure 4.49-3: Procedure CAMEL_MT_GMSC_DISC5 (sheet 3) Figure 4.50-1: Procedure CAMEL_MT_GMSC_DISC6 (sheet 1) Figure 4.51-1: Procedure CAMEL_MT_ETC (sheet 1) Figure 4.51-2: Procedure CAMEL_MT_ETC (sheet 2) Figure 4.51-3: Procedure CAMEL_MT_ETC (sheet 3) Figure 4.51-4: Procedure CAMEL_MT_ETC (sheet 4) Figure 4.52-1: Procedure CAMEL_MT_CTR (sheet 1) Figure 4.52-2: Procedure CAMEL_MT_CTR (sheet 2) Figure 4.52-3: Procedure CAMEL_MT_CTR (sheet 3) Figure 4.52-4: Procedure CAMEL_MT_CTR (sheet 4) Figure 4.52-5: Procedure CAMEL_MT_CTR (sheet 5) Figure 4.53-1: Procedure CAMEL_MT_GMSC_Notify_CF (sheet 1) Figure 4.53-2: Procedure CAMEL_MT_GMSC_Notify_CF (sheet 2) Figure 4.54-1: Procedure CAMEL_MT_LEG2_GMSC (sheet 1) Figure 4.54-2: Procedure CAMEL_MT_LEG2_GMSC (sheet 2) Figure 4.54-3: Procedure CAMEL_MT_LEG2_GMSC (sheet 3) Figure 4.55-1: Process CAMEL_MT_LEG1_GMSC (sheet 1) Figure 4.55-2: Process CAMEL_MT_LEG1_GMSC (sheet 2) Figure 4.55-3: Process CAMEL_MT_LEG1_GMSC (sheet 3) Figure 4.55-4: Process CAMEL_MT_LEG1_GMSC (sheet 4) Figure 4.55-5: Process CAMEL_MT_LEG1_GMSC (sheet 5) Figure 4.56-1: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 1) Figure 4.56-2: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 2) Figure 4.56-3: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 3) Figure 4.56-4: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 4) Figure 4.56-5: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 5) Figure 4.56-6: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 6) Figure 4.56-7: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 7) Figure 4.57-1: Procedure CAMEL_T_SCUDIF_MSC (sheet 1) 4.5.3.2 Retrieval of routeing information in the HLR The functional behaviour of the HLR is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_HLR_INIT; - Procedure CAMEL_CSI_Check_HLR; - Procedure CAMEL_O_CSI_CHECK_HLR; - Procedure CAMEL_D_CSI_CHECK_HLR; - Procedure CAMEL_T_CSI_CHECK_HLR; - Procedure CAMEL_CHECK_SII2_CDTI. The procedure CAMEL_Provide_Subscriber_Info is specified in subclauseÊ4.5.9. Figure 4.58-1: Procedure CAMEL_HLR_INIT (sheet 1) Figure 4.58-2: Procedure CAMEL_HLR_INIT (sheet 2) Figure 4.59-1: Procedure CAMEL_CSI_Check_HLR (sheet 1) Figure 4.60-1: Procedure CAMEL_O_CSI_CHECK_HLR (sheet 1) Figure 4.61-1: Procedure CAMEL_D_CSI_CHECK_HLR (sheet 1) Figure 4.62-1: Procedure CAMEL_T_CSI_CHECK_HLR (sheet 1) Figure 4.63-1: Procedure CAMEL_CHECK_SII2_CDTI (sheet 1) 4.5.3.3 Handling of provide roaming number request in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ23.018Ê[12]. The procedure specific to CAMEL is specified in this subclause: - Procedure CAMEL_SET_SOA. Figure 4.64-1: Procedure CAMEL_SET_SOA (sheet 1) 4.5.4 Handling of mobile terminating calls 4.5.4.1 Handling of mobile terminating calls in the terminating VMSC The functional behaviour of the terminating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The behaviour specific to CAMEL is: - the inclusion of the O CSI and/or D CSI parameter in the Perform Call Forwarding information flow sent to the process MT_CF_MSC if O CSI and/or D CSI was received in the Send Info For Incoming Call ack information flow; - the requirement to suppress the connection of announcements or tones if the VLR includes the suppression of announcements parameter in the Send Info For Incoming Call negative response information flow. The processes and procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_ICH_VLR; - Procedure CAMEL_O_CSI_Check_VLR; - Procedure CAMEL_D_CSI_Check_VLR; - Procedure CAMEL_VT_CSI_Check_VLR; - Procedure CAMEL_ICH_MSC_INIT; - Procedure CAMEL_MT_VMSC_Notify_CF; - Procedure CAMEL_ICH_LEG2_MSC; - Procedure CAMEL_ICH_LEG2_CF_MSC; - Process CAMEL_ICH_LEG1_MSC; - Procedure CAMEL_ICH_RECONNECT_MSC; - Process CAMEL_T_CHANGE_OF_POSITION_MSC. The procedure CAMEL_ICH_LEG2_MSC supervises the terminating party only. The procedure CAMEL_ICH_LEG2_CF_MSC supervises the forwarded-to party only. The process CAMEL_ICH_LEG1_MSC supervises the originating party only. Hence, signals from the BSS are received by the procedure CAMEL_ICH_LEG2_MSC, signals from the destination exchange are received by the procedure CAMEL_ICH_LEG2_CF_MSC and signals from the originating exchange are received by the process CAMEL_ICH_LEG1_MSC. 4.5.4.1.1 Action of the VMSC in procedure CAMEL_MT_VMSC_Notify_CF The Forwarding reason is taken from the Complete Call information flow from the VLR. The Int_DP_T_No_Answer signal and Int_DP_T_Busy signal include a parameter to indicate that the call has encountered conditional call forwarding. The gsmSSF will transfer this parameter to the Event Report BCSM information flow which it sends to the gsmSCF. 4.5.4.1.2 Action of MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.4.1.3 Procedure CAMEL_ICH_LEG2_MSC The Int_DTMF_Digit_Received information flow is received from an internal process in the MSC that receives DTMF signalling from the MS. The handling of the internal process that receives DTMF signalling is out of scope of the present document. The playing of the received DTMF tones to the other parties in the call segment is out of scope of the present document. 4.5.4.1.4 Process CAMEL_T_CHANGE_OF_POSITION_MSC The signals HANDOVER COMPLETE and HANDOVER PERFORMED are specified in 3GPP TSÊ48.008Ê[39]. Signals RELOCATION REQUEST ACKNOWLEDGE, LOCATION REPORT and LOCATION REPORTING COMMAND are specified in 3GPP TSÊ25.413Ê[33]. Figure 4.65-1: Procedure CAMEL_ICH_VLR (sheet 1) Figure 4.66-1: Procedure CAMEL_O_CSI_Check_VLR (sheet 1) Figure 4.67-1: Procedure CAMEL_D_CSI_Check_VLR (sheet 1) Figure 4.68-1: Procedure CAMEL_VT_CSI_Check_VLR (sheet 1) Figure 4.69-1: Procedure CAMEL_ICH_MSC_INIT (sheet 1) Figure 4.69-2: Procedure CAMEL_ICH_MSC_INIT (sheet 2) Figure 4.69-3: Procedure CAMEL_ICH_MSC_INIT (sheet 3) Figure 4.69-4: Procedure CAMEL_ICH_MSC_INIT (sheet 4) Figure 4.69-5: Procedure CAMEL_ICH_MSC_INIT (sheet 5) Figure 4.70-1: Procedure CAMEL_MT_VMSC_Notify_CF (sheet 1) Figure 4.70-2: Procedure CAMEL_MT_VMSC_Notify_CF (sheet 2) Figure 4.71-1: Procedure CAMEL_ICH_LEG2_MSC (sheet 1) Figure 4.71-2: Procedure CAMEL_ICH_LEG2_MSC (sheet 2) Figure 4.71-3: Procedure CAMEL_ICH_LEG2_MSC (sheet 3) Figure 4.71-4: Procedure CAMEL_ICH_LEG2_MSC (sheet 4) Figure 4.71-5: Procedure CAMEL_ICH_LEG2_MSC (sheet 5) Figure 4.71-6: Procedure CAMEL_ICH_LEG2_MSC (sheet 6) Figure 4.71-7: Procedure CAMEL_ICH_LEG2_MSC (sheet 7) Figure 4.71-8: Procedure CAMEL_ICH_LEG2_MSC (sheet 8) Figure 4.71-9: Procedure CAMEL_ICH_LEG2_MSC (sheet 9) Figure 4.72-1: Process CAMEL_ICH_LEG2_CF_MSC (sheet 1) Figure 4.72-2: Process CAMEL_ICH_LEG2_CF_MSC (sheet 2) Figure 4.73-1: Process CAMEL_ICH_LEG1_MSC (sheet 1) Figure 4.73-2: Process CAMEL_ICH_LEG1_MSC (sheet 2) Figure 4.73-3: Process CAMEL_ICH_LEG1_MSC (sheet 3) Figure 4.73-4: Process CAMEL_ICH_LEG1_MSC (sheet 4) Figure 4.73-5: Process CAMEL_ICH_LEG1_MSC (sheet 5) Figure 4.74-1: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 1) Figure 4.74-2: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 2) Figure 4.74-3: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 3) Figure 4.74-4: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 4) Figure 4.74-5: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 5) Figure 4.74-6: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 6) Figure 4.74-7: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 7) Figure 4.75-1: Process CAMEL_T_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.75-2: Procedure CAMEL_T_CHANGE_OF_POSITION_MSC (sheet 2) 4.5.4.2 Handling of mobile terminating calls in the VLR The functional behaviour of the terminating VLR is specified in 3GPP TSÊ23.018Ê[12]. The process specific to CAMEL is specified in this subclause: - Process Reconnected_MT_Call_VLR. The behaviour specific to CAMEL is: - the inclusion of the O CSI and/or D CSI parameter in the Send Info For Incoming Call ack information flow if the call is to be forwarded and O CSI and/or D CSI is included in the subscriber data for that subscriber in the VLR; - the inclusion of the suppression of announcements parameter in the Send Info For Incoming Call negative response information flow if it was received in the Provide Roaming Number information flow from the HLR. Figure 4.76-1: Process Reconnected_MT_Call_VLR (sheet 1) 4.5.5 Handling of forwarded calls The handling of forwarded calls in the GMSC or the terminating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The processes and procedures specific to CAMEL are specified in this subclause. - Procedure CAMEL_Check_ORLCF_VMSC; - Procedure CAMEL_CF_MSC_INIT; - Procedure CAMEL_CF_MSC_ALERTING; - Procedure CAMEL_CF_MSC_ANSWER; - Procedure CAMEL_CF_ETC; - Procedure CAMEL_CF_CTR; - Procedure CAMEL_MT_CF_LEG1_MSC; - Process CAMEL_MT_CF_LEG2_MSC; - Procedure CAMEL_MF_RECONNECT_MSC. The procedure CAMEL_MT_CF_LEG1_MSC supervises the originating party only. The process CAMEL_MT_CF_LEG2_MSC supervises the forwarding-to party only. Hence, signals from the originating exchange are received by the procedure CAMEL_MT_CF_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_MT_CF_LEG2_MSC. A mobile terminated call can be forwarded either in the GMSC (indicated by provision of Forwarded-To-Number from the HLR or gsmSCF) or in the MSC (indicated by provision of Forwarded-To-Number from the VLR). 4.5.5.1 Procedure CAMEL_CF_MSC_INIT: handling of Int_Continue_With_Argument The received parameters are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]). Call parameters which are not included in the Int_Continue_With_Argument signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.5.2 Procedure CAMEL_CF_MSC_INIT: handling of Int_Connect The received parameters are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]. Call parameters which are not included in the Int_Connect signal are unchanged. As a network operator option, loop prevention mechanisms may cause the redirection information to be ignored or modified (e.g., if the Redirection counter has been decreased). Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. 4.5.5.3 Procedure CAMEL_CF_MSC_INIT: handling of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.5.4 Action of the MSC in procedure CAMEL_CF_MSC_ANSWER If the MSC received a destination address from the GMSC in the ISUP Answer or ISUP Connect Message then the MSC relays the destination address to the gsmSSF in the Int_DP_O_Answer signal. 4.5.5.5 Action of the MSC in procedure CAMEL_CF_ETC In procedure CAMEL_CF_ETC (sheet 2) the GMSC or terminating VMSC will remain in the Wait_For_Assisting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). Figure 4.77-1: Procedure CAMEL_Check_ORLCF_VMSC (sheet 1) Figure 4.77-2: Procedure CAMEL_Check_ORLCF_VMSC (sheet 2) Figure 4.78-1: Procedure CAMEL_CF_Dialled_Services (sheet 1) Figure 4.79-1: Procedure CAMEL_CF_MSC_INIT (sheet 1) Figure 4.79-2: Procedure CAMEL_CF_MSC_INIT (sheet 2) Figure 4.79-3: Procedure CAMEL_CF_MSC_INIT (sheet 3) Figure 4.79-4: Procedure CAMEL_CF_MSC_INIT (sheet 4) Figure 4.80-1: Procedure CAMEL_SDS_CF_INIT (sheet 1) Figure 4.80-2: Procedure CAMEL_SDS_CF_INIT (sheet 2) Figure 4.80-3: Procedure CAMEL_SDS_CF_INIT (sheet 3) Figure 4.80-4: Procedure CAMEL_SDS_CF_INIT (sheet 4) Figure 4.81-1: Procedure CAMEL_NDS_CF_INIT (sheet 1) Figure 4.81-2: Procedure CAMEL_NDS_CF_INIT (sheet 2) Figure 4.81-3: Procedure CAMEL_NDS_CF_INIT (sheet 3) Figure 4.81-4: Procedure CAMEL_NDS_CF_INIT (sheet 4) Figure 4.82-1: Procedure CAMEL_CF_MSC_ALERTING (sheet 1) Figure 4.82-2: Procedure CAMEL_CF_MSC_ALERTING (sheet 2) Figure 4.82-3: Procedure CAMEL_CF_MSC_ALERTING (sheet 3) Figure 4.83-1: Procedure CAMEL_CF_MSC_ANSWER (sheet 1) Figure 4.83-2: Procedure CAMEL_CF_MSC_ANSWER (sheet 2) Figure 4.83-3: Procedure CAMEL_CF_MSC_ANSWER (sheet 3) Figure 4.84-1: Procedure CAMEL_CF_ETC (sheet 1) Figure 4.84-2: Procedure CAMEL_CF_ETC (sheet 2) Figure 4.84-3: Procedure CAMEL_CF_ETC (sheet 3) Figure 4.84-4: Procedure CAMEL_CF_ETC (sheet 4) Figure 4.85-1: Procedure CAMEL_CF_CTR (sheet 1) Figure 4.85-2: Procedure CAMEL_CF_CTR (sheet 2) Figure 4.85-3: Procedure CAMEL_CF_CTR (sheet 3) Figure 4.85-4: Procedure CAMEL_CF_CTR (sheet 4) Figure 4.85-5: Procedure CAMEL_CF_CTR (sheet 5) Figure 4.86-1: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 1) Figure 4.86-2: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 2) Figure 4.86-3: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 3) Figure 4.86-4: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 4) Figure 4.86-5: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 5) Figure 4.86-6: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 6) Figure 4.86-7: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 7) Figure 4.87-1: Process CAMEL_MT_CF_LEG2_MSC (sheet 1) Figure 4.87-2: Process CAMEL_MT_CF_LEG2_MSC (sheet 2) Figure 4.88-1: Procedure CAMEL_MF_RECONNECT_MSC (sheet 1) Figure 4.88-2: Procedure CAMEL_MF_RECONNECT_MSC (sheet 2) Figure 4.88-3: Procedure CAMEL_MF_RECONNECT_MSC (sheet 3) Figure 4.88-4: Procedure CAMEL_MF_RECONNECT_MSC (sheet 4) Figure 4.88-5: Procedure CAMEL_MF_RECONNECT_MSC (sheet 5) Figure 4.88-6: Procedure CAMEL_MF_RECONNECT_MSC (sheet 6) 4.5.6 Handling of gsmSCF initiated calls 4.5.6.1 Handling of gsmSCF initiated calls in the MSC Handling of gsmSCF initiated calls in the MSC involves the following process and procedures: - Process CAMEL_ICA_MSC; - Procedure CAMEL_ICA_MSC_ALERTING; - Procedure CAMEL_ICA_MSC_ANSWER; - Procedure CAMEL_ICA_MSC1; - Procedure CAMEL_ICA_MSC2; - Procedure CAMEL_ICA_Dialled_Services. The Process CAMEL_ ICA_MSC handles both gsmSCF initiated new calls and gsmSCF initiated new parties. The following paragraphs give details on the behaviour of the MSC in the process CAMEL_ICA_MSC. 4.5.6.1.1 Actions of the MSC on receipt of Int_Error The process CAMEL_ICA_MSC returns to idle. 4.5.6.1.2 Actions of the MSC on receipt of Int_Continue The MSC continues processing without any modification of call parameters. 4.5.6.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument The MSC continues processing with modification of call parameters. 4.5.6.1.4 Actions of the MSC on receipt of Int_Disconnect_Leg A Release is sent to the destination exchange if required. The release cause received in the Int_Disconnect_Leg signal is used. The process CAMEL_ICA_MSC returns to idle. 4.5.6.1.5 Actions of the MSC on receipt of Int_Release_Call A Release is sent to the destination exchange if required. The release cause received in the Int_Release_Call signal is used. The MSC then releases all call resources and the process CAMEL_ ICA_MSC returns to idle. Figure 4.89-1: Process CAMEL_ICA_MSC (sheet 1) Figure 4.89-2: Process CAMEL_ICA_MSC (sheet 2) Figure 4.89-3: Process CAMEL_ICA_MSC (sheet 3) Figure 4.89-4: Process CAMEL_ICA_MSC (sheet 4) Figure 4.89-5: Process CAMEL_ICA_MSC (sheet 5) Figure 4.89-6: Process CAMEL_ICA_MSC (sheet 6) Figure 4.89-7: Process CAMEL_ICA_MSC (sheet 7) Figure 4.89-8: Process CAMEL_ICA_MSC (sheet 8) Figure 4.89-9: Process CAMEL_ICA_MSC (sheet 9) Figure 4.90-1: Procedure CAMEL_ICA_MSC_ALERTING (sheet 1) Figure 4.90-2: Process CAMEL_ICA_MSC_ALERTING (sheet 2) Figure 4.90-3: Process CAMEL_ICA_MSC_ALERTING (sheet 3) Figure 4.91-1: Procedure CAMEL_ICA_MSC_ANSWER (sheet 1) Figure 4.91-2: Process CAMEL_ICA_MSC_ANSWER (sheet 2) Figure 4.91-3: Process CAMEL_ICA_MSC_ANSWER (sheet 3) Figure 4.92-1: Procedure CAMEL_ICA_MSC1 (sheet 1) Figure 4.93-1: Procedure CAMEL_ICA_MSC2 (sheet 1) Figure 4.94-1: Procedure CAMEL_ICA_Dialled_Services (sheet 1) 4.5.6.2 Handling of gsmSCF initiated calls in the VLR Handling of gsmSCF initiated calls in the VLR involves the following process and procedures: - Process CAMEL_ICA_VLR. Figure 4.95-1: Process CAMEL_ICA_VLR (sheet 1) Figure 4.95-2: Process CAMEL_ICA_VLR (sheet 2) 4.5.7 Handling of mobile calls in the gsmSSF Handling of mobile calls in the gsmSSF involves the following processes and procedures: - Process CS_gsmSSF; - Procedures and process Check_Criteria; - Procedure Connect_To_Resource; - Procedure Handle_AC; - Procedure Handle_ACR; - Procedure Handle_CIR; - Procedure Handle_CIR_leg; - Procedure Complete_FCI_record; - Procedure Complete_all_FCI_records; - Procedure Handle_SCI; - Process CSA_gsmSSF; - Procedure Handle_O_Answer; - Procedure Handle_T_Answer. The detailed error handling for the process CS_gsmSSF and the associated procedures is specified in 3GPP TSÊ29.078Ê([36]). 4.5.7.1 Call duration control 4.5.7.1.1 Information flow for call duration control The following diagram shows the handling of the different timers that are used in the process CS_gsmSSF and in the procedures Handle_AC, Handle_ACR, Handle_CIR. Timers Tssf, Tcp, Tsw, Tw and DELTA are defined in the process CS_gsmSSF. Figure 4.96: Information flow for call control duration The following diagram shows an example of the handling of call duration control for CPH configurations. Figure 4.96a: Information flow for call control duration in CPH configurations 4.5.7.1.2 Audible indicators for call duration control The gsmSCF may instruct the gsmSSF to play either a fixed sequence of tones or a variable sequence of tones with the Apply Charging information flow. The gsmSCF may also instruct the gsmSSF to play a variable sequence of tones with the Play Tone information flow. For the case of the fixed sequence of tones, the gsmSSF shall play a single sequence of three tones. The duration of each of the tones shall be 200Êmilliseconds with an intertone interval of 200Êmilliseconds. This shall be played 30Êseconds before the end of a call period. For the case of a variable sequence of tones, or a burst list, the gsmSCF shall indicate the number of tones per burst, the number of bursts to be played, the tone duration, interval between the tones and the interval between the bursts. In addition, the gsmSCF shall indicate in the Apply Charging information flow, the warning time before call period expiry at which the playing of the burst list shall start. FigureÊ4.97 provides a graphical representation of the variable burst list in the case where there are three tones per burst and three bursts in the burst list. The Warning Period in figureÊ4.97 applies to the Apply Charging information flow only. Figure 4.97: Representation of burst list 4.5.7.2 The gsmSCF control of e values 4.5.7.2.1 Procedure Handle_SCI There are independent Tariff Switch Timers for the control of the call duration Tsw(pty) and for the gsmSCF control of e values Tsw(SCI). The gsmSCF control of e values is via the Send Charging Information information flow. The following terminology has been used for e parameters: - Applicable and in use. The set of e parameters is currently applicable in the MSC and the set has been sent to the MS. - Applicable but waiting. The set of e parameters is currently applicable in the MSC but the set has not yet been sent to the MS. - Applicable but not in use. The set of e parameters is currently applicable in the MSC but it cannot be sent to the MS, e.g. because the Advice of Charge supplementary service is not subscribed. - Stored. The set of e parameters is not yet applicable. The stored set of e parameters becomes applicable when a tariff switch occurs. The table below defines the actions of the Procedure Handle_SCI. Table 4.6: Handling of SCI in the gsmSSF received Tsw(SCI) and set of e parameters in the SCI information flow Primary dialogue (note 1) Secondary dialogue (noteÊ2,Ê8) no active call / SRF connection active call / SRF connection Tsw(SCI) not running and no e parameters stored Tsw(SCI) running and e parameters stored Tsw(SCI) not running and no e parameters stored Tsw(SCI) running and e parameters stored Tsw(SCI) not received 1 set send 1st set to MSC stop Tsw(SCI); discard stored set; send 1st set to MSC send 1st set to MSC stop Tsw(SCI); discard stored set; send 1st set to MSC send 1st set to MSC Tsw(SCI) not received 2 sets error error error error error Tsw(SCI) received 1 set error error store 1st set; start Tsw(SCI) stop Tsw(SCI); discard stored set; store 1st set; start new Tsw(SCI) error Tsw(SCI) received 2 sets send 1st set to MSC, store 2nd set; start Tsw(SCI) stop Tsw(SCI); discard stored set; send 1st set to MSC; store 2nd set; start new Tsw(SCI) error error send 1st set to MSC; store 2nd set; start Tsw(SCI) NOTEÊ1: Primary dialogue: The primary dialogue is initiated due to TDPÊCollected_Info, TDPÊAnalysed_Information, or TDPÊRoute_Select_Failure, TDPÊTerminating_Attempt_Authorised, TDPÊT_Busy or TDP T_No_Answer. A dialogue initiated due to TDP Analysed_Information is only the primary dialogue, if there is no ongoing dialogue due to TDP Collected_Info. NOTEÊ2: Secondary dialogue: The secondary dialogue is initiated due to TDPÊAnalysed_Information. NOTEÊ3: The condition ""active call / SRF connection"" is true if there is at least one active leg in this call (CSA) or if an SRF is connected to a Call Segment in this CSA. Incoming legs are active after an answer is sent and before the leg begins to release. Outgoing legs are active after an answer is received and before the leg is begins to release. NOTEÊ4: If the gsmSSF sends a set of e parameters to the MSC this will overwrite the current set of e parameters in the MSC, if e parameters are applicable in the MSC. NOTEÊ5: The MSC shall store the received e parameters to be sent subsequently to the MS. The MSC shall send these e parameters to the MS in a Connect message or in a Facility message. NOTEÊ6: Secondary dialogue gsmSCF can only give e parameter(s)/Tsw(SCI) when they have not previously been provided by the primary dialogue gsmSCF. After secondary dialogue gsmSCF gives e parameter(s) / Tsw(SCI), Primary dialogue gsmSCF shall not give further on-line charging instructions (i.e. Send Charging Information). For D CSI, this is ensured by service subscription restriction by a home network operator. For N CSI, this is ensured by a roaming agreement between the home network operator and the visited network operator or is only applicable within a home network. NOTEÊ7: When a gsmSCF relationship is closed then the stored e parameters given by that dialogue are discarded. Any Tariff Switch timer (Tsw(SCI)) is also stopped when the gsmSCF relationship is closed. If the gsmSCF has given any e parameters which are not stored but which are applicable (regardless of whether they are applicable and in use, applicable but waiting, or applicable but not in use) when the gsmSCF relationship is closed, those e parameters are also valid after the gsmSCF relationship is closed. If any subsequent CAP dialogues give e parameters those new e parameters shall overwrite the applicable e parameters given by the preceding CAP dialogues. NOTEÊ8: The secondary dialogue is not applicable to VT calls. NOTE 9: Service Logic designers shall take care when using SCI in both primary dialogue and secondary dialogue, if these dialogues use different versions of CAMEL. In such a case it is e.g. possible that a Tariff Switch timer (Tsw(SCI))Êinformation received in the primary dialogue is overwritten by a Tariff Switch timer (Tsw(SCI)) information received in the secondary dialogue. 4.5.7.2.2 Process Tsw_For_SCI The process Tsw_For_SCI exists per call. That is there is one process instance per CSA. The Tariff Switch Timers for the gsmSCF control of e values Tsw(SCI). Figure 4.98-1: Process Tsw_For_SCI (sheet 1) Figure 4.98-2: Process Tsw_For_SCI (sheet 2) 4.5.7.3 Behaviour of the gsmSSF in the process CS_gsmSSF The following paragraphs give details on the behaviour of the gsmSSF in the process CS_gsmSSF. 4.5.7.3.1 Actions of the gsmSSF on receipt of CAP_Request_Report_BCSM_Event (in the state Waiting_For_Instructions) The process CS_gsmSSF arms the requested EDP, if the arming rules are fulfilled and returns to the state Waiting_For_Instructions. The gsmSCF may request EDPs for any one or more of Answer, Busy, No Answer, Abandon, Route Select Failure and Disconnect event for a party in the call. 4.5.7.3.2 Actions of the gsmSSF on receipt of CAP_Continue (in the state Waiting_For_Instructions) An Int_Continue signal is sent to instruct the GMSC or MSC to continue the call set-up with the original call parameters. 4.5.7.3.3 Actions of the gsmSSF on receipt of CAP_Release_Call (in the state Monitoring) When a control relationship exists between the gsmSCF and gsmSSF (at least one EDP R is armed), the gsmSCF may spontaneously instruct the gsmSSF to release the call at any time using the Release Call information flow. The Release Call information flow shall not be sent from the gsmSCF if only monitor relationship exists between the gsmSSF and the gsmSCF. 4.5.7.3.4 Actions of the gsmSSF on receipt of Int_DP_T_Busy or Int_DP_T_No_Answer including the parameter Call Forwarded (in the state Monitoring) If the handling of Int_DP_T_Busy signal or Int_DP_T_No_Answer signal including the parameter Call Forwarded leads to the gsmSSF sending a CAP_Event_Report_BCSM to the gsmSCF, the gsmSSF shall include the parameter Call Forwarded in the Event Specific Information BCSM. 4.5.7.4 Outstanding Request Counter and Rules for CAMEL In the following the rules on handling of the 'outstanding requests' variables in the process CS_gsmSSF are given. They are storing the number of required resumptions. 1) There shall be one outstanding requests variable ORC_Leg (legID) per leg to handle TDP R and EDP R reports and ICA. 2) In addition there shall be one outstanding requests variable ORC_CS (CSID) per call segment to handle the CPH IFs. 3) A leg will only be resumed if the ORC_Leg (legID) variable for this leg and the ORC_CS (CSID) for the call segment containing the leg are 0. 4) Events that cause the suspension of the call processing are signalling events armed as TDP Rs or EDP Rs, or the processing of a CPH IF (Disconnect Leg, Split Leg or Move Leg) or Initiate Call Attempt sent by the gsmSCF. a) For TDP R or EDP R events the number of required resumptions relative to the associated leg will be incremented by 1. For TDP-R, the associated leg is always leg 2. b) For CPH IFs the number of required resumptions per call segment will be set to one if it is still 0. Otherwise the number of resumptions remains unchanged. For Split Leg the number of required resumptions for each of the source call segment and the target call segment will be set to one if it is still 0 c) For ICA the number of required resumptions relative to the associated leg will be set to 1. 5) In addition the CS_gsmSSF stores information about the events (DP with the associated leg, CPH) that require resumption and keep track of the order of events for TDP Rs and EDP Rs for each leg . The order of resumptions for a leg shall be the order in which the suspension events occured for that leg. 6) For DP event resumption Continue with Argument with legID or Continue are valid. If not otherwise stated below, for each received resumption the number of required resumption for that leg will be decremented by 1 if it was a valid resumption for the event that has to be handled first. Decrementing of the outstanding requests variables does not go below 0. 7) For CPH resumption Continue with Argument with CSID is valid. On receipt of the resumption the number of required resumptions for that call segment will be set to 0. 8) For ICA resumption Continue with Argument with LegId is valid. On receipt of the resumption the number of required resumptions for that Leg will be set to 0. 9) If Continue with Argument with neither LegID nor CSID is received, then the number of resumptions required for the leg that was reported will be decremented by 1. If reporting is performed on more than one leg, then the related leg will be selected following the sequence of the reporting. 10) If Continue is received, then the number of resumptions required for the leg that was reported will be decremented by 1. If reporting is performed on more than one leg, then the related leg will be selected following the sequence of the reporting. 11) The processing of a Connect with a LegID causes the number of required resumptions for that leg to be decremented by 1. The processing of a Connect without a LegID causes the number of resumptions for the LegID = 2 to be set to 0. 12) The processing of Tssf expiry and of TC Abort causes the number of resumptions required to be set to 0 and the call processing to be resumed. All stored resumption events are discarded. 13) On receipt of a Disconnect Leg the number of resumptions required for the corresponding leg is set to 0. 14) If Release Call is used, nothing needs to be resumed. 4.5.7.5 Process CS_gsmSSF and procedures Figure 4.99-1: Process CS_gsmSSF (sheet 1) Figure 4.99-2: Process CS_gsmSSF (sheet 2) Figure 4.99-3: Process CS_gsmSSF (sheet 3) Figure 4.99-4: Process CS_gsmSSF (sheet 4) Figure 4.99-5: Process CS_gsmSSF (sheet 5) Figure 4.99-6: Process CS_gsmSSF (sheet 6) Figure 4.99-7: Process CS_gsmSSF (sheet 7) Figure 4.99-8: Process CS_gsmSSF (sheet 8) Figure 4.99-9: Process CS_gsmSSF (sheet 9) Figure 4.99-10: Process CS_gsmSSF (sheet 10) Figure 4.99-11: Process CS_gsmSSF (sheet 11) Figure 4.99-12: Process CS_gsmSSF (sheet 12) Figure 4.99-13: Process CS_gsmSSF (sheet 13) Figure 4.99-14: Process CS_gsmSSF (sheet 14) Figure 4.99-15: Process CS_gsmSSF (sheet 15) Figure 4.99-16: Process CS_gsmSSF (sheet 16) Figure 4.99-17: Process CS_gsmSSF (sheet 17) Figure 4.99-18: Process CS_gsmSSF (sheet 18) Figure 4.99-19: Process CS_gsmSSF (sheet 19) Figure 4.99-20: Process CS_gsmSSF (sheet 20) Figure 4.99-21: Process CS_gsmSSF (sheet 21) Figure 4.99-21A: Process CS_gsmSSF (sheet 21A) Figure 4.99-22: Process CS_gsmSSF (sheet 22) Figure 4.99-23: Process CS_gsmSSF (sheet 23) Figure 4.99-24: Process CS_gsmSSF (sheet 24) Figure 4.99-25: Process CS_gsmSSF (sheet 25) Figure 4.99-26: Process CS_gsmSSF (sheet 26) Figure 4.99-27: Process CS_gsmSSF (sheet 27) Figure 4.99-28: Process CS_gsmSSF (sheet 28) Figure 4.99-29: Process CS_gsmSSF (sheet 29) Figure 4.99-29a: Process CS_gsmSSF (sheet 29a) Figure 4.99-30: Process CS_gsmSSF (sheet 30) Figure 4.99-31: Process CS_gsmSSF (sheet 31) Figure 4.99-32: Process CS_gsmSSF (sheet 32) Figure 4.99-33: Process CS_gsmSSF (sheet 33) Figure 4.99-34: Process CS_gsmSSF (sheet 34) Figure 4.99-35: Process CS_gsmSSF (sheet 35) Figure 4.99-36: Process CS_gsmSSF (sheet 36) Figure 4.99-37: Process CS_gsmSSF (sheet 37) Figure 4.99-38: Process CS_gsmSSF (sheet 38) Figure 4.99-39: Process CS_gsmSSF (sheet 39) Figure 4.99-40: Process CS_gsmSSF (sheet 40) Figure 4.99-41: Process CS_gsmSSF (sheet 41) Figure 4.99-42: Process CS_gsmSSF (sheet 42) Figure 4.99-43: Process CS_gsmSSF (sheet 43) Figure 4.99-44: Process CS_gsmSSF (sheet 44) Figure 4.99-45: Process CS_gsmSSF (sheet 45) Figure 4.99-46: Process CS_gsmSSF (sheet 46) Figure 4.99-47: Process CS_gsmSSF (sheet 47) Figure 4.99-48: Process CS_gsmSSF (sheet 48) Figure 4.99-49: Process CS_gsmSSF (sheet 49) Figure 4.99-50: Process CS_gsmSSF (sheet 50) Figure 4.99-51: Process CS_gsmSSF (sheet 51) Figure 4.99-52: Process CS_gsmSSF (sheet 52) Figure 4.99-53: Process CS_gsmSSF (sheet 53) Figure 4.99-54: Process CS_gsmSSF (sheet 54) Figure 4.99-55: Process CS_gsmSSF (sheet 55) Figure 4.99-56: Process CS_gsmSSF (sheet 56) Figure 4.99-57: Process CS_gsmSSF (sheet 57) Figure 4.99-58: Process CS_gsmSSF (sheet 58) Figure 4.99-59: Process CS_gsmSSF (sheet 59) Figure 4.99-60: Process CS_gsmSSF (sheet 60) Figure 4.99-61: Process CS_gsmSSF (sheet 61) Figure 4.99-62: Process CS_gsmSSF (sheet 62) Figure 4.100-1: Procedure Check_Criteria_Collected_Info (sheet 1) Figure 4.101-1: Procedure Check_Criteria_Analysed_Info (sheet 1) Figure 4.102-1: Procedure Check_Criteria_Unsuccessful (sheet 1) Figure 4.103-1: Procedure Connect_To_Resource (sheet 1) Figure 4.104-1: Procedure Handle_AC (sheet 1) Figure 4.105-1: Procedure Handle_ACR (sheet 1) Figure 4.106-1: Procedure Handle_CIR (sheet 1) Figure 4.107-1: Procedure Handle_CIR_leg (sheet 1) Figure 4.108-1: Procedure Complete_FCI_record (sheet 1) Figure 4.109-1: Procedure Complete_all_FCI_records (sheet 1) Figure 4.110-1: Procedure Handle_O_Answer (sheet 1) Figure 4.111-1: Procedure Handle_T_Answer (sheet 1) Figure 4.112-1: Procedure UpdateSignalling (sheet 1) 4.5.7.6 Process gsmSSF_SSME_FSM and procedures One process is instantiated for each Call Gap information flow received from a gsmSCF. Figure 4.113-1: Process gsm_SSME_SSF (sheet 1) Figure 4.113-2: Process gsm_SSME_SSF (sheet 2) NOTE: CG Int and CG Reject internal variables are initiated with False value. Figure 4.114-1: Procedure Store_Call_Gap_Criteria (sheet 1) Figure 4.115-1: Procedure Check_Gap_Criteria (sheet 1) Figure 4.115A-1: Procedure Check_Criteria_for_TOC (sheet 1) 4.5.7.7 Process CSA_gsmSSF and procedures The call gap information flow can only be received for an opened transaction between the CSA_gsmSSF and the gsmSCF. Figure 4.116-1: Process CSA_gsmSSF (sheet 1) Figure 4.116-2: Process CSA_gsmSSF (sheet 2) Figure 4.116-3: Process CSA_gsmSSF (sheet 3) Figure 4.116-4: Process CSA_gsmSSF (sheet 4) Figure 4.116-5: Process CSA_gsmSSF (sheet 5) Figure 4.116-6: Process CSA_gsmSSF (sheet 6) Figure 4.116-7: Process CSA_gsmSSF (sheet 7) Figure 4.116-8: Process CSA_gsmSSF (sheet 8) Figure 4.116-9: Process CSA_gsmSSF (sheet 9) Figure 4.116-10: Process CSA_gsmSSF (sheet 10) Figure 4.116-11: Process CSA_gsmSSF (sheet 11) Figure 4.116-12: Process CSA_gsmSSF (sheet 12) Figure 4.116-13: Process CSA_gsmSSF (sheet 13) Figure 4.116-14: Process CSA_gsmSSF (sheet 14) Figure 4.116-15: Process CSA_gsmSSF (sheet 15) Figure 4.116-16: Process CSA_gsmSSF (sheet 16) Figure 4.116-17: Process CSA_gsmSSF (sheet 17) Figure 4.116-18: Process CSA_gsmSSF (sheet 18) Figure 4.116-19: Process CSA_gsmSSF (sheet 19) Figure 4.116-20: Process CSA_gsmSSF (sheet 20) Figure 4.116-21: Process CSA_gsmSSF (sheet 21) Figure 4.116-22: Process CSA_gsmSSF (sheet 22) Figure 4.116-23: Process CSA_gsmSSF (sheet 23) 4.5.8 Assisting case Assisting case involves the following processes: - CAMEL_Assisting_MSC, - Assisting_gsmSSF. The detailed error handling for these 2 processes is specified in 3GPP TSÊ29.078Ê[36]. Figure 4.117-1: Process CAMEL_Assisting_MSC (sheet 1) Figure 4.117-2: Process CAMEL_Assisting_MSC (sheet 2) Figure 4.117-3: Process CAMEL_Assisting_MSC (sheet 3) Figure 4.118-1: Process Assisting_gsmSSF (sheet 1) Figure 4.118-2: Process Assisting_gsmSSF (sheet 2) Figure 4.118-3: Process Assisting_gsmSSF (sheet 3) Figure 4.118-4: Process Assisting_gsmSSF (sheet 4) Figure 4.118-5: Process Assisting_gsmSSF (sheet 5) Figure 4.118-6: Process Assisting_gsmSSF (sheet 6) 4.5.9 Procedure CAMEL_Provide_Subscriber_Info The procedure CAMEL_Provide_Subscriber_Info is called either during Retrieval of routeing information in the HLR or as a result of reception of the Any Time Interrogation information flow from the gsmSCF. The HLR sends a Provide Subscriber Info information flow to the VLR or SGSN dependent on the setting of the parameter ""requested domain"" received from the calling process. If the VLR or SGSN returns a Provide Subscriber Info ack information flow, then the HLR uses the received information to set the Subscriber Info to be returned to the calling process. As a network option, the HLR may use the information received from the VLR, such as Cell Id, Location Area Id or Service Area Id, to derive the Location Number and/or Geographical Information. The HLR may use the information received from the SGSN, such as Cell Id, Location Area Id, Service Area Id or Routeing Area Identity, to derive the Location Number and/or Geographical Information. This mapping is network-specific and outside the scope of the present document. NOTE: The handling in the VLR of Provide Subscriber Info is defined in 3GPP TSÊ23.018Ê[12]."
"The handling in the SGSN of Provide Subscriber Info is defined in clauseÊ11. Figure 4.119-1: Procedure CAMEL_Provide_Subscriber_Info (sheet 1) Figure 4.119-2: Procedure CAMEL_Provide_Subscriber_Info (sheet 2) 4.5.10 CAMEL specific handling of location updating and data restoration When requesting a location update or data restoration the VLR shall indicate to the HLR which CAMEL phases it supports and which CAMEL phaseÊ4 CSIs can be downloaded. The HLR may then send CAMEL subscription data to the VLR or, if some different handling is required, data for substitute handling. The CAMEL subscription data sent by the HLR shall comply with the indication of supported CAMEL phases and supported CAMEL phase 4 CSIs as received from the VLR. When the location update has been completed, the MSC/VLR in which the subscriber is registered after the location update shall check the M CSI. If a Mobility Management notification to the gsmSCF is required for this subscriber, then the MSC/VLR shall send the notification to the gsmSCF. Refer to subclauseÊ9.2.1 for a description of M CSI and the conditions under which a notification shall be sent. 4.5.11 Cross phase compatibility To avoid a case by case fallback between the gsmSSF and the gsmSCF, the gsmSSF shall use the CAP phase corresponding to the CAMEL phase negotiated on the HLR-VLR interface when it opens a dialogue with the gsmSCF. The HLR-VLR negotiation of CAMEL phase is per subscriber. 4.5.12 Handling of North American Carrier Information The following procedures apply only when the HPLMN of the CAMEL subscriber and either the VPLMN (for a mobile originated or forwarded call) or the IPLMN (for a mobile terminated call or forwarded call) are both North American. A gsmSCF may then provide the gsmSSF with any of the following North American (NA) carrier related information items. - NA Carrier Information; - NA Originating Line Information; - NA Charge Number. A gsmSSF shall use the received information items both to select any long distance carrier needed for the call and to provide certain information needed by this carrier. Any required information items not received shall be defaulted to those that would normally apply to the call in the absence of an interaction with a gsmSCF. If any NA information item received from the gsmSCF is found to be invalid, the gsmSSF may either, as an operator option, release the call or behave as if the invalid information item had not been sent. If the carrier specified in the Carrier parameter is not supported in the VPLMN or IPLMN, the gsmSSF may either, as an operator option, release the call or substitute for the unsupported carrier a preferred carrier of the VPLMN or IPLMN. Support of the NA Originating Line Information and Charge Number parameters is an operator option in a VPLMN based on roaming agreements with the operators of other PLMNs, A gsmSSF may ignore these items when received from certain or all gsmSCFs located in other PLMNs and replace them with the corresponding default items for an MO, MF, MT or VT call. 4.5.13 Handling of trunk originated calls The handling of trunk originated calls in the inter-connecting MSC is specified in 3GPP TSÊ23.018Ê[12] subclause 7.5. The processes and procedures specific to CAMEL are specified in this subclause. - Procedure CAMEL_TOC_Dialled_Services; - Procedure CAMEL_TOC_MSC_INIT; - Procedure CAMEL_NDS_TOC_INIT; - Procedure CAMEL_TOC_LEG1_MSC. The procedure CAMEL_TOC_LEG1_MSC supervises the originating party only. The process CAMEL_MT_CF_LEG2_MSC supervises the called-to party only. Hence, signals from the originating exchange are received by the procedure CAMEL_TOC_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_MT_CF_LEG2_MSC. 4.5.13.1 Procedure CAMEL_TOC_Dialled_Services Void 4.5.13.2 Procedure CAMEL_TOC_MSC_INIT Sheet 1: Decision ""First procedure call"": The procedure call formal parameter (FPAR) values ""First"" or ""NotFirst"" indicate whether the gsmSSF instance has been invoked for this call at the Collected_Information DP. - First_ The gsmSSF has not been invoked. - NotFirst: The gsmSSF has been invoked earlier and the gsmSSF is waiting for additional digits. The gsmSSF may not have triggered a CAP dialogue to gsmSCF. 4.5.13.3 Procedure CAMEL_NDS_TOC_INIT Sheet 1: Decision ""First procedure call"": The procedure call formal parameter (FPAR) values ""First"" or ""NotFirst"" indicate whether the gsmSSF instance has been invoked for this call at Analysed_Information DP. The dialled services invoke a different instance of gsmSSF than at the Collected_Information DP. - First_ The gsmSSF has not been invoked. - NotFirst: The gsmSSF has been invoked earlier and the gsmSSF is waiting for additional digits. The gsmSSF may not have triggered a CAP dialogue to gsmSCF. 4.5.13.4 Procedure CAMEL_TOC_LEG1_MSC Void Figure 4.119A-1: Procedure CAMEL_TOC_Dialled_Services (sheet 1) Figure 4.119B-1: Procedure CAMEL_TOC_MSC_INIT (sheet 1) Figure 4.119B-2: Procedure CAMEL_TOC_MSC_INIT (sheet 2) Figure 4.119B-3: Procedure CAMEL_TOC_MSC_INIT (sheet 3) Figure 4.119B-4: Procedure CAMEL_TOC_MSC_INIT (sheet 4) Figure 4.119B-5: Procedure CAMEL_TOC_MSC_INIT (sheet 5) Figure 4.119B-6: Procedure CAMEL_TOC_MSC_INIT (sheet 6) Figure 4.119B-7: Procedure CAMEL_TOC_MSC_INIT (sheet 7) Figure 4.119C-1: Procedure CAMEL_NDS_TOC_INIT (sheet 1) Figure 4.119C-2: Procedure CAMEL_NDS_TOC_INIT (sheet 2) Figure 4.119C-3: Procedure CAMEL_NDS_TOC_INIT (sheet 3) Figure 4.119C-4: Procedure CAMEL_NDS_TOC_INIT (sheet 4) Figure 4.119C-5: Procedure CAMEL_NDS_TOC_INIT (sheet 5) Figure 4.119D-1: Procedure CAMEL_TOC_LEG1_MSC (sheet 1) Figure 4.119D-2: Procedure CAMEL_TOC_LEG1_MSC (sheet 2) Figure 4.119D-3: Procedure CAMEL_TOC_LEG1_MSC (sheet 3) Figure 4.119D-4: Procedure CAMEL_TOC_LEG1_MSC (sheet 4) Figure 4.119D-5: Procedure CAMEL_TOC_LEG1_MSC (sheet 5) Figure 4.119D-6: Procedure CAMEL_TOC_LEG1_MSC (sheet 6) Figure 4.119D-7: Procedure CAMEL_TOC_LEG1_MSC (sheet 7) 4.6 Description of information flows This clause contains the detailed description of the information flows used by CAMEL for Circuit Switched call control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E), Optional (O) or not applicable (-) for each different traffic case applicable to the following CSI: - MO Mobile Originating call in the VMSC (O CSI, D CSI or N CSI dialogue); - MF Mobile Forwarded call in the VMSC or the GMSC as in figure 4.7 (O CSI, D CSI or N CSI dialogue); - MT Mobile Terminating call in the GMSC (T CSI dialogue); - VT Mobile Terminating call in the VMSC (VT CSI dialogue); - NC gsmSCF initiated new call; - NP gsmSCF initiated new party in an existing call; - TO Trunk Originating call in the MSC (TO-CSI or N-CSI dialogue). If the IEs in one table apply in all the possible cases listed above or no distinction is needed, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included for the corresponding traffic case. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted for the corresponding traffic case. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. it is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The distinction between MO, MF, MT, VT, NC, NP and TO calls is not applicable to all Information Flows. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSSF shall functionally support all IEs which can be sent to it. - The gsmSCF may silently discard any IE which it does not functionally support. - The gsmSRF shall return an error if it does not functionally support an IE which it receives. - The HLR may silently discard any IE which it does not functionally support. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.078Ê[36]. 4.6.1 gsmSSF to gsmSCF information flows 4.6.1.1 Activity Test ack 4.6.1.1.1 Description This IF is the response to the Activity Test. 4.6.1.1.2 Information Elements This IF contains no information elements. 4.6.1.2 Apply Charging Report 4.6.1.2.1 Description This IF is used by the gsmSSF to report to the gsmSCF the information requested in the Apply Charging IF. 4.6.1.2.2 Information Elements Information element name Status Description Call Result M This IE contains the charging information provided by the gsmSSF. Call Result contains the following information elements: Information element name Status Description Time Duration Charging Result M This IE is described in a table below. Time Duration Charging Result contains the following information elements: Information element name Status Description Time Information M This IE is described in a table below. Party To Charge M This IE is received in the related Apply Charging IF to correlate the result to the request. This IE shall be a copy of the corresponding IE received in the Apply Charging IF. ACh Charging Address M This IE identifies the call party to which the Apply Charging Report IF applies. This IE is described in a table below. Leg Active M This IE indicates whether the call leg is active or not. When the ACR is sent because of a change in CPH configuration legActive=FALSE shall be used. Call Leg Released At Tcp Expiry S This IE is an indication that the gsmSSF has released the call leg or the Temporary Connection or SRF Connection, due to Tcp expiry. It shall be present when Apply Charging Report is sent due to Tcp expiry and the gsmSSF has released the call leg or the Temporary Connection or SRF Connection (because 'Release If Duration Exceeded' was present in the Apply Charging IF). In all other cases, this IE shall be absent. Time Information contains the following information elements: Information element name Status Description Time If No Tariff Switch S,E This IE shall be present if no tariff switch has occurred since the reception of the first Apply Charging IF for the connection to the Called Party, the Temporary Connection, or the gsmSRF connection, otherwise it shall be absent. If Answer was detected for the connection to the Called Party, the Temporary Connection or the gsmSRF connection, then the elapsed time since detection of Answer shall be reported. For a change in a CPH configuration the particular time when the legs in a CS are connected shall be taken as Answer. If answer was not detected, it shall be set to ""0"". Time If Tariff Switch S,E This IE shall be present if a tariff switch has occurred since the reception of the first Apply Charging IF for the connection to the Called Party, the Temporary Connection, or the gsmSRF connection, otherwise it shall be absent. ACh Charging Address contains the following information elements: Information element name Status Description Leg ID E This IE indicates that the Apply Charging Report IF applies to the specified leg. SRF Connection E This IE indicates that the Apply Charging Report IF applies to the Temporary Connection or SRF Connection 4.6.1.3 Call Information Report 4.6.1.3.1 Description This IF is used to send specific call information for a single call party to the gsmSCF as requested by the gsmSCF in a previous Call Information Request IF. 4.6.1.3.2 Information Elements Information element name Status Description Requested Information List M This IE specifies the requested information. Leg ID M This IE indicates the party in the call for which information shall be collected. 4.6.1.4 Disconnect Leg ack 4.6.1.4.1 Description This IF is the successful response to the Disconnect Leg IF. 4.6.1.4.2 Information Elements This IF contains no information elements. 4.6.1.5 Entity Released 4.6.1.5.1 Description This IF is used to inform the gsmSCF about the release of a logical entity (CS or BCSM) caused by exception or errors. It is sent by the CSA FSM if this information cannot be conveyed within an TC_ABORT or TC_END because the TC dialogue has to be kept because of other existing logical entities (CS or BCSM) in this CSA which are not affected by this error/exception. This IF is not sent if the last CS was released. The IF Entity Released is not used if the release of the entity can be reported through other IFs, e.g. Event Report BCSM, Call Information Report. 4.6.1.5.2 Information Elements Information element name Status Description CS Failure E This IE indicates that an CS has been released. BCSM Failure E This IE indicates that a leg has been released. CS Failure contains the following information elements: Information element name Status Description Call Segment ID M This IE identifies the released CS. Cause C This IE indicates the cause for releasing the CS. The Cause may be used by the gsmSCF to decide how to continue the call handling. BCSM Failure contains the following information elements: Information element name Status Description Leg ID M This IE identifies the released leg. Cause C This IE indicates the cause for releasing the leg. The cause may be used by the gsmSCF to decide handling. 4.6.1.6 Event Report BCSM 4.6.1.6.1 Description This IF is used to notify the gsmSCF of a call-related event (i.e. BCSM events as answer and disconnect) previously requested by the gsmSCF in a Request Report BCSM Event IF. 4.6.1.6.2 Information Elements Information element name MO MF MT VT NC NP TO Description Event Type BCSM M M M M M M M This IE specifies the type of event that is reported. Event Specific Information BCSM C C C C C C C This IE indicates the call related information specific to the event. Leg ID M M M M M M M This IE indicates the party in the call for which the event is reported. Misc Call Info M M M M M M M This IE indicates the DP type. If the Event Type BCSM IE contains either O_Answer or T_Answer, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Destination Address M M M M M M M This IE specifies the destination address for the call leg. The NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of destination address may be zero. OR - C C - - - - This IE indicates that the call was subject to basic Optimal Routeing as specified in 3GPP TSÊ23.079Ê[19]. Forwarded Call - M C C - - - This IE indicates that the call has been subject to a Call Forwarding supplementary service. Charge Indicator S S S S S S S This IE specifies the value which will be stored in the Call Data Record. See ITU T Recommendation Q.763Ê[43]. Ext Basic Service Code S S S S - - S This IE is used for SCUDIF calls. It indicates the type of basic service, i.e. teleservice or bearer service. It indicates the service active at answer for the SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27]). Ext Basic Service Code 2 S S S S - - S This IE is used for SCUDIF calls. It indicates the type of basic service, i.e. teleservice or bearer service. It indicates the service which is not active at answer for the SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27]). It shall be present if the negotiation of the SCUDIF services resulted in both basic services for the SCUDIF call. Otherwise shall be absent. If the Event Type BCSM IE contains either O_Mid_Call or T_Mid_Call, then the Event Specific Information BCSM IE contains the following information element: Information element name MO MF MT VT NC NP TO Description Midcall Info M - - M - - M This IE is described in a table below. MidCall Info contains the following information elements: Information element name MO MF MT VT NC NP TO Description DTMF Digits Completed S,E - - S,E - - S,E This IE contains the detected mid-call digits. This IE shall be present when triggering takes place after the minimum number of digits has been detected. DTMF Digits Timeout S,E - - S,E - - S,E This IE contains the detected mid-call digits. This IE shall be present when triggering takes place before the minimum number of digits has been detected. If the Event Type BCSM IE contains one of Route_Select_Failure, O_Busy, O_Disconnect or T_Disconnect, then the Event Specific Information BCSM IE contains the following information element: Information element name MO MF MT VT NC NP TO Description Cause C C C C C C C This IE indicates the cause. If the Event Type BCSM IE contains T_Busy, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Cause - - C C - - This IE indicates the cause. Call forwarded - - C C - - This IE indicates that the call may be forwarded by the appropriate Call Forwarding supplementary service or Call Deflection supplementary service. If T_Busy is reported from the GMSC, then this IE shall be present in the following cases: - The event is triggered by the reception of an FTN in the 2nd Send Routeing Info ack from the HLR; - The event is triggered by the reception of the Resume Call Handling information flow from the VMSC. If T_Busy is reported from the VMSC, then this IE shall be present in the following cases: - The event is triggered by the invocation of conditional call forwarding (Busy or Not_Reachable); - The event notification is triggered by the invocation of Call Deflection. Route Not permitted - - S - - - This IE indicates that the further call setup will not take place in this GMSC due to the rules of basic optimal routeing. See 3GPP TSÊ23.079Ê[19]. Forwarding Destination Number - - C C - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarded IE is present. Otherwise, it shall be absent. If the Event Type BCSM IE contains T_No_Answer, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Call Forwarded - - C C - - This IE indicates that the call may be forwarded by the appropriate Call Forwarding supplementary service. If T_No_Answer is reported from the GMSC, then this IE shall be present in the following cases: - The event is triggered by the reception of the Resume Call Handling information flow from the VMSC. If the T_No_Answer is reported from the VMSC, then this IE shall be present in the following cases: - The event is triggered by the invocation of conditional call forwarding (No_Answer). Forwarding Destination Number - - C C - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarded IE is present. Otherwise, it shall be absent. If the Event Type BCSM IE contains Call_Accepted or O_Term_Seized, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Location Information C - - C - - - See subclauseÊ4.6.1.8 with VLR Number IE as ""- (not applicable)"". NOTE If gsmSCF does not arm DPÊO_Change_Of_Position, then the Location Information reported at DPÊO_Term_Seized may be the same as the Location Information reported at DPÊCollected_Information, even when the subscriber has changed location between DPÊCollected Information and DPÊO_Term_Seized. If the Event Type BCSM IE contains O_Change_Of_Position or T_Change_Of_Position, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Location Information C - - C - - See subclauseÊ4.6.1.8 with VLR Number IE as ""- (not applicable)"". Met DP Criteria List S - - S - - This IE is described in a table below. It carries the list of criteria that were triggered and met for the reporting of the change of position event. It shall be present if change of position control info was received in the request. Met DP Criteria List contains a list of up to 10 instances of the following information element: Information element name MO MF MT VT NC NP Description Met DP Criterion M - - M - - Each Met DP Criterion IE is one of the 6 possibilities indicated in the table below. If multiple instances of the Met DP Criterion IE have the same value, this is not an error. Each instance of the Met DP Criterion IE contains one of the following information elements: Information element name MO MF MT VT NC NP Description Cell Global ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the cell specified in this IE. Furthermore it indicates whether the handover was into or out of the cell. Service Area ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the service area specified in this IE. Furthermore it indicates whether the handover was into or out of the service area. Location Area ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the location area specified in this IE. Furthermore it indicates whether the handover was into or out of the location area. Inter System Handover E - - E - - This IE indicates that the mobile station performed inter system handover. Furthermore it indicates whether the handover was from GSM to UMTS or from UMTS to GSM. Inter PLMN Handover E - - E - - This IE indicates that the mobile station performed inter PLMN handover. Inter MSC Handover E - - E - - This IE indicates that the mobile station performed inter MSC handover. If the Event Type BCSM IE contains O_Abandon, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Route Not Permitted - S - - - - - This IE indicates that the further call setup will not take place in this MSC due to the rules of basic optimal routeing. See 3GPP TSÊ23.079Ê[19]. If the Event Type BCSM IE contains one of O_Service_Change or T_Service_Change, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Ext Basic Service Code M M M M - - M This IE indicates the new basic service code after a successful bearer service modification. Nature of Service Change C C C C - - C This IE indicates the nature of the service change (User initiated service change or network initiated service change). Shall be present if available. Initiator of Service Change M M M M - - M This IE indicates the initiator of the service change (A side or B side) If the Event Type BCSM IE contains O_No_Answer, then the Event Specific Information BCSM IE is not included. If the Event Type BCSM IE contains Collected_Info, then the Event Specific Information BCSM IE contains the following information elements: Information element name TO Description Called Party Number M The contents of the Called Party Number parameter are as follows: - Nature of address indicator Ð set to the same value as the Called Party Number parameter sent in InitialDP: - Numbering plan indicator Ð set to the same value as the Called Party Number parameter sent in InitialDP; - Address signals: - If 'N' relevant digits, or more, have been collected and the end of pulsing signal (ST) has not been received, then all relevant digits shall be reported plus a filler digit, if necessary (note 1) - If the end of pulsing signal (ST) has been received then all relevant digits shall be reported, plus the end of pulsing signal and a filler digit, if necessary (note 1) - If the inter-digit timer expires in the MSC then all relevant digits shall be reported plus a filler digit, if necessary (notes 1 & 2). Note 1: The relevant digits are the digits originally reported in InitialDP plus any additional relevant digits collected as a result of the CollectInformation operation(s). Note 2: If the inter-digit timer expires before any additional relevant digits have been collected then the digits reported are the same as those previously reported in InitialDP or EventReportBCSM. Note 3: Some dialled digits may not be relevant for reporting. Relevant digits are determined by operator defined rules in the MSC, e.g. operator specific service selection information may not be reported. The MSC/ gsmSSF compares 'N' against the digits to be reported. 4.6.1.7 Initiate Call Attempt ack 4.6.1.7.1 Description This IF is the successful response to the Initiate Call Attempt IF. 4.6.1.7.2 Information Elements Information element name NC NP Description Supported CAMEL Phases M M This IE indicates the CAMEL Phases supported. Offered CAMEL4 Functionalities M M This IE is described in subclause 4.6.1.8. This IE indicates the CAMEL phaseÊ4 functionalities offered. Release Call Argument Extension Allowed O - This IE indicates whether the gsmSCF is allowed to use network specific IE in the Release Call IF. 4.6.1.8 Initial DP 4.6.1.8.1 Description This IF is generated by the gsmSSF when a trigger is detected at a DP in the BCSM, to request instructions from the gsmSCF. 4.6.1.8.2 Information Elements (Note: IEs in the NC columns in this IF may need further study.) Information element name MO MF MT VT NC NP TO Description Additional Calling Party Number C C C C - C C This IE contains the calling party number provided by the access signalling system of the calling user or received from the gsmSCF due to the previous CAMEL processing. Called Party Number C M M M - M M This IE contains the number used to identify the called party in the forward direction. For MO and MF calls this IE is used in the case of TDP Route_Select_Failure (this is the destination number used to route the call) and in the case of TDP Busy and TDP No Reply (this is the MSISDN when the destination number used for the call is an MSRN, or in the case of unsuccessful call establishment received from the HLR via the MAP interface, otherwise it is the number used to route the call). For VT calls when there is no forwarding pending this is the MSISDN received in the Provide Roaming Number; if the MSISDN is not available, the basic MSISDN is used. For the MT and VT call case when there is call forwarding or call deflection pending, this is the MSISDN, i.e. not the forwarded-to or deflected-to number. If the Initial DP IF is sent at TDP Route_Select_Failure or TDP Analysed_Information then the NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of the destination address may be zero. For TO calls this IE is used to identify the called party in the forward direction. It is used in the case of TDP Collected_Information and TDP Analysed_Information. The number contained in this IE shall be the relevant digits, for reporting purposes, of the number received in the telephony signalling system call establishment message (e.g. ISUP IAM). The number may or may not include the end of pulsing signal (ST). Called Party BCD Number C - - - - - - This IE contains the number used to identify the called party in the forward direction. It is used for an MO call in all cases except in the case of TDP Route_Select_Failure. For the TDP Collected_Information, the number contained in this IE shall be identical to the number received over the access network. It may e.g. include service selection information, such as ? and # digits, or carrier selection information dialled by the subscriber. For the TDP Analysed_Information, the number contained in this IE shall be the dialled number received over the network access or received from a gsmSCF in a Connect IF, Service selection information, such as * and # digits may be present (see subclauseÊ4.2.1.2.2); carrier selection information dialled by the subscriber is not present. Calling Party Number M C C C - C C This IE carries the calling party number to identify the calling party or the origin of the call. Calling Partys Category M C C C - C C This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). CallGap Encountered C C C C - C C This IE indicates the type of gapping which has been applied to the related call. This IE shall be present only if a call gapping context is applicable to the Initial DP IF. Call Reference Number M M M M - M M This IE may be used by the gsmSCF for inclusion in a network optional gsmSCF call record. It has to be coupled with the identity of the MSC which allocated it in order to define unambiguously the identity of the call. For MO calls, the call reference number is set by the serving VMSC and included in the MO call record. For MT calls, the call reference number is set by the GMSC and included in the RCF call record in the GMSC and in the MT call record in the terminating MSC. For VT calls, the call reference number is set by the GMSC and included in the RCF call record in the GMSC and in the MT call record in the terminating MSC. For MF calls, the call reference number is set by the GMSC and included in the CF record in the forwarding MSC. For the setting of the Call Reference Number for NP calls, see the corresponding call case above (MO, MT, VT or MF). For TO calls, the call reference number is set by the inter-connecting MSC. Cause C C C C - - - This IE indicates the cause specific to the armed BCSM DP event. This IE is applicable to DPÊRoute_Select_Failure and DPÊT_Busy. The cause may be used by the gsmSCF to decide how to continue the call handling. Event Type BCSM M M M M - M M This IE indicates the armed BCSM DP event, resulting in the Initial DP IF. For the TO traffic case this will be 'CollectedInformation' or 'AnalysedInformation'. IMSI M M M M - S - This IE identifies the mobile subscriber. For the NP case, the IMSI is mandatory if the new party is initiated in an MO, MF, MT, or VT call, otherwise it shall be absent. IP SSP Capabilities C C C C - C C This IE indicates which SRF resources are supported within the gsmSSF and are available. If this IE is absent, it indicates that no gsmSRF is attached and available. Location Information M - C M - - - This IE is described in a table below. Location Number M C C C - - C For mobile originated calls this IE represents the location of the calling party. For all other call scenarios this IE contains the location number received in the incoming ISUP signalling. MSC Address M M M M - M M For MO calls, the MSC Address carries the international E.164 address of the serving VMSC. For MT calls, the MSC Address carries the international E.164 address of the GMSC. For VT calls, the MSC Address carries the international E.164 address of the serving VMSC. For MF calls, the MSC Address carries the international E.164 address of the forwarding MSC. For NP case, see the corresponding call case above (MO, MT, VT or MF). For TO calls, the MSC Address carries the international E.164 address of the inter-connecting MSC. GMSC Address - M - M - S - For MF calls, the GMSC Address carries the international E.164 address of the GMSC. For VT calls, the GMSC Address carries the international E.164 address of the GMSC. For NP calls, the GMSC Address is mandatory if the new party is initiated in an MF call or in a VT call, otherwise it shall be absent. The GMSC Address carries the international E.164 address of the GMSC. Carrier S S S S - S S This IE is described in a table below. This IE may be present when the VPLMN and the HPLMN of the subscriber are both North American. For MO calls, this IE shall identify any carrier that was explicitly selected by the calling subscriber. If no carrier was explicitly selected, this IE shall contain the calling subscriber's subscribed carrier. For MT and VT calls, the IE shall contain the carrier subscribed to by the called subscriber. For MF calls, the IE shall contain the carrier subscribed to by the forwarding subscriber. For TO calls, this IE shall identify any carrier that was explicitly selected by the calling party or redirecting party, as received from the telephony signalling system (e.g. ISUP IAM). Original Called Party ID C C C C - - C This IE carries the dialled digits if the call has met call forwarding on the route to the gsmSSF. This IE shall also be sent if it was received from the gsmSCF due to previous CAMEL processing. Redirecting Party ID C C C C - - C This IE indicates the directory number the call was redirected from. This IE shall also be sent if it was received from the gsmSCF due to previous CAMEL processing. Redirection Information C C C C - - C This IE contains forwarding related information, such as the redirection counter. Service Key M M M M - M M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application within the gsmSCF. Subscriber State - - C C - - - This IE indicates the status of the MS. The states are: - CAMEL Busy: The MS is engaged on a transaction for a mobile originating or terminated circuit-switched call. - Network Determined Not Reachable: The network can determine from its internal data that the MS is not reachable. - Assumed Idle: The state of the MS is neither ""CAMEL Busy"" nor ""Network Determined Not Reachable"". - Not provided from VLR. Time And Timezone M M M M - M M This IE contains the time that the gsmSSF was triggered, and the time zone in which gsmSSF resides. Call Forwarding SS Pending - - C C - - - If the Initial DP IF is sent from the GMSC, then this IE shall be present in the following cases: - The GMSC has received an FTN in the 1st Send Routeing Info ack IF from the HLR. - The GMSC has received an FTN in the 2nd Send Routeing Info ack IF from the HLR and no relationship with the gsmSCF exists at that moment. - The GMSC has received the Resume Call Handling IF from the VMSC and no relationship with the gsmSCF exists at that moment. If the Initial DP IF is sent from the VMSC, then this IE shall be present in the following cases: - Conditional call forwarding is invoked and no relationship with the gsmSCF exists at that moment. - Call Deflection is invoked and no relationship with the gsmSCF exists at that moment. Forwarding Destination Number - - C C - - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarding SS Pending IE is present, otherwise it shall be absent. Service Interaction Indicators Two C C C C - C C The IE is described in a table below. This IE is present if it is received in the ISUP message or due to previous CAMEL processing. CUG Index C - - - - C - See 3GPP TSÊ23.085Ê[22] for details of this IE. CUG Interlock Code C C C C - C C This IE shall be set according to 3GPP TSÊ23.085Ê[22] unless modified by the gsmSCF via the Connect or Continue With Argument IFs. Outgoing Access Indicator C C C C - C C This IE shall be set according to the 3GPP TSÊ23.085Ê[22] unless modified by the gsmSCF via the Connect or Continue With Argument IFs. MS Classmark 2 C - - - - - - This IE contains the MS classmark 2, which is sent by the MS when it requests access to setup the MO call or responds to paging in the CS domain. IMEI (with software version) C - - - - - - This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Supported CAMEL Phases M M M M M M M This IE indicates the CAMEL Phases supported by the GMSC or the VMSC. Offered CAMEL4 Functionalities M M M M M M M This IE is described in a table below. This IE indicates the CAMEL phaseÊ4 functionalities offered by the GMSC or the VMSC."
"Bearer Capability M C C C - C C This IE indicates the bearer capability connection to the user. For a SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27] this IE indicates the Bearer CapabilityÊof the preferred service. Bearer CapabilityÊ2 C C C C - - C This IE indicates the bearer capability of the less preferred service for a SCUDIF call. Ext-Basic Service Code C C C C - C C This IE indicates the basic service, i.e. teleservice or bearer service. For a SCUDIF call this IE indicates the basic service of the preferred service Ext-Basic Service CodeÊ2 C C C C - - C This IE indicates the basic service of the less preferred service for a SCUDIF call. High Layer Compatibility C C C C - C C This IE indicates the high layer compatibility, which will be used to determine the ISDN-teleservice of a connected ISDN terminal. For a SCUDIF call this IE indicates the high layer compatibility of the preferred service. High Layer Compatibility 2 C C C C - C C This IE indicates the high layer compatibility of the less preferred service for a SCUDIF call. Low Layer Compatibility C C C C - C C This IE indicates the low layer compatibility, which will be used to determine the ISDN bearer capability of a connected ISDN terminal. For a SCUDIF call this IE indicates the Low Layer Compatibility of the preferred service. Low Layer Compatibility 2 C C C C - C C This IE indicates the low layer compatibility of the less preferred service for a SCUDIF call. Enhanced Dialled Services Allowed S S - - S S S This IE indicates that the gsmSCF may use the Enhanced Dialled Services (EDS). This IE shall be included if and only if all of following four conditions are fulfilled: - this IF is sent due to triggering on DP Analysed_Information; and - the EDS functionality is offered for this call (as indicated in the Offered CAMEL4 Functionalities); and - there is no more than one outgoing leg within this call; and - there is no other CAMEL dialogue active for the leg for which this IF is sent. User-to-User Service activation request O O O O - - O This IE may be sent if it is received in a call control message. See 3GPP TSÊ23.087Ê[45], 3GPP TSÊ24.008Ê[30], and ETSI ENÊ300Ê356 1Ê[40] for details of this IE. User-to-User Information O O O O - - O This IE may be sent if it is received in a call control message. See 3GPP TSÊ23.087Ê[45], 3GPP TSÊ24.008Ê[30], and ETSI ENÊ300Ê356 1Ê[40] for details of this IE. Collect Information Allowed - - - - - - S This IE indicates whether the gsmSCF is allowed to use Collect Information for the armed BCSM DP event. This IE shall only be included when the armed BCSM DP event is 'CollectedInformation' or 'AnalysedInformation'. Note: This IE shall only be included for the 'AnalysedInformation' BCSM DP event if the 'Enhanced Dialled Services Allowed' IE is also present. Release Call Argument Extension Allowed O O O O - O O This IE indicates whether the gsmSCF is allowed to use network specific IE in the Release Call IF. Offered CAMEL4 Functionalities contains the following information elements: Information element name Status Description Initiate Call Attempt S This IE indicates that the gsmSCF may send to the gsmSSF the Initiate Call Attempt IF. Split Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Split Leg IF. Move Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Move Leg IF. Disconnect Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Disconnect Leg IF. Entity Released S This IE indicates that the gsmSSF will send to the gsmSCF the Entity Released IF, when appropriate. DFC With Argument S This IE indicates that the gsmSCF may send to the gsmSSF the Disconnect Forward Connection With Argument IF. Play Tone S This IE indicates that the gsmSCF may send to the gsmSSF the Play Tone IF. DTMF Mid Call S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_MidCall or T_MidCall DP. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. Charging Indicator S This IE indicates that the Charge Indicator IE may be present in the Event Report BCSM IF reporting the O_Answer or T_Answer DP. Alerting DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Term_Seized or Call_Accepted DP. Location At Alerting S This IE indicates that the Location Information IE shall be present (if available) in the Event Report BCSM IF reporting the O_Term_Seized or Call_Accepted DP. Change Of Position DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Change_Of_Position or T_Change_Of_Position DPs. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. OR Interactions S This IE indicates that the gsmSCF may send to the gsmSSF the Basic OR Interrogation Requested IE in the Connect or Continue With Argument IF. This IE indicates that the Route Not Permitted IE may be present in the Event Report BCSM IF reporting the O_Abandon DP. Warning Tone Enhancements S This IE indicates that the gsmSCF may send to the gsmSSF the Burstlist IE (within the Audible Indicator IE) in an Apply Charging IF. CF Enhancements S This IE indicates that the Forwarding Destination Number IE may be present in the Event Report BCSM IF reporting the T_Busy or T_No_Answer DP. Criteria for Change Of Position DP S This IE indicates that the gsmSCF may send to the gsmSSF in the Request Report BCSM Event IF criteria for reporting the report of O_Change_Of_Position or T_Change_Of_Position. Subscribed Enhanced Dialled Services S This IE indicates that Subscribed Enhanced Dialled Services is offered. Serving Network Enhanced Dialled Services S This IE indicates that Serving Network Enhanced Dialled Services is offered. Service Change DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Service_Change or T_Service_Change DPs. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. Collect Information S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the CollectedInfo EDP and order the MSC to collect a specific number of additional dialled digits. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name MO MF MT VT NC NP Description Location Number - - C C - - See 3GPP TSÊ23.018Ê[12]. Service area ID C,E - C,E C,E - - See 3GPP TSÊ23.018Ê[12]. Cell ID C,E - C,E C,E - - See 3GPP TSÊ23.018Ê[12]. Geographical information C - C C - - See 3GPP TSÊ23.018Ê[12]. Geodetic information C - C C - - See 3GPP TSÊ23.018Ê[12]. VLR number M - C M - - See 3GPP TSÊ23.018Ê[12]. Age Of location information M - C C - - See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - - - - - - Not applicable Location area ID C,E - C,E C,E - - See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S - S S - - This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority shall be present. See 3GPP TSÊ23.073Ê[18]. This IE shall be present if available and SoLSA is supported, otherwise it shall be absent. User CSG Information C - C - - - See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID - - C,E - - - See 3GPP TSÊ23.018Ê[12]. Tracking area ID - - C,E - - - See 3GPP TSÊ23.018Ê[12]. Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M - M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M - M M This IE indicates the way the carrier was selected, i.e.: - dialled - subscribed Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator C C C C - C C This IE is described in a table below. HOLD Treatment Indicator C - - C - C - This IE indicates whether the CAMEL subscriber can invoke HOLD for the call. CW Treatment Indicator C - - C - C - This IE indicates whether CW can be applied for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator C - - C - C - This IE indicates whether the call leg can become part of an ECT call initiated by the CAMEL subscriber. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator C C C C - C C This IE indicates whether the call leg can become part of a MPTY call initiated by the called subscriber. Call Diversion Treatment Indicator C C C C - C C This IE indicates whether the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. 4.6.1.9 Move Leg ack 4.6.1.9.1 Description This IF is the successful response to the Move Leg IF. 4.6.1.9.2 Information Elements This IF contains no information elements. 4.6.1.10 Split Leg ack 4.6.1.10.1 Description This IF is the successful response to the Split Leg IF. 4.6.1.10.2 Information Elements This IF contains no information elements. 4.6.2 gsmSCF to gsmSSF information flows 4.6.2.1 Activity Test 4.6.2.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gsmSSF. If the relationship is still in existence, then the gsmSSF will respond. If no reply is received, then the gsmSCF will assume that the gsmSSF has failed in some way and will take appropriate action. 4.6.2.1.2 Information Elements This IF contains no information elements. 4.6.2.2 Apply Charging 4.6.2.2.1 Description This IF is used to instruct the gsmSSF to apply charging mechanisms to control the call duration. 4.6.2.2.2 Information Elements Information element name MO MF MT VT NC NP TO Description ACh Billing Charging Characteristics M M M M M M M This IE specifies the charging related information to be provided by the gsmSSF and the conditions on which this information has to be provided back to the gsmSCF. Party To Charge M M M M M M M This IE shall be reflected in the corresponding IE of the Apply Charging Report IF. This IE has no effect on the charging procedures in the MSC. ACh Charging Address M M M M M M M This IE identifies the call party to which the Apply Charging IF applies. This IE is described in a table below. ACh Billing Charging Characteristics contains the following information element: Information element name MO MF MT VT NC NP TO Description Time Duration Charging M M M M M M M This IE is described in a table below. Time Duration Charging contains the following information elements: Information element name MO MF MT VT NC NP TO Description Max Call Period Duration M M M M M M M This IE indicates the maximum call period duration timer. Tariff Switch Interval O O O O O O O This IE indicates the tariff switch time until the next tariff switch applies for this call leg. Release If Duration Exceeded O O O O O O O This IE indicates that the call leg, SRF connection or Temporary connection shall be released when the Max call Period Duration expires. The cause used in the Release IF shall be ""normal unspecified"". The default handling is to continue the call. Audible Indicator O - O O O O O This IE is described in a table below. Audible Indicator IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Tone E - E E E E E This IE indicates that a fixed sequence of tones shall be played to the CAMEL subscriber. In the NC case, the first party created will receive the warning tone. In the TO case the calling party will receive the warning tone. If present, this IE indicates that 30 seconds before the Max Call Period Duration timer expires, a fixed sequence of tones consisting of 3 tones of 900 Hz, with a 200 milliseconds tone duration and a 200 milliseconds intertone duration shall be played. Burstlist E - E E E E E This IE is described in the table below. This IE indicates a variable sequence of bursts that shall be played during the call period to the CAMEL subscriber. In the NC case, the first party created will receive the warning tone. In the TO case the calling party will receive the warning tone. Burstlist IE contains the following information elements: Information element name Status Description Warning Period M This IE indicates the time, before the Max Call Period Duration timer expires, when the Play Burst List IE shall start. Number Of Bursts M This IE indicates the number of bursts to be played. There may be up to three bursts. Burst Interval M This IE indicates the time interval between successive bursts. Number Of Tones In Burst M This IE indicates the number of tones to be played in each burst. There may be up to three tones per burst. The tone is fixed to 900 Hz. Tone Duration M This IE indicates the duration of a tone in a burst. Tone Interval M This IE indicates the time interval between successive tones in a burst. NOTE Service logic designers should note that the total duration of the Burst List should not exceed the WarningPeriod IE, otherwise an incomplete Burst List will be played to the served party. ACh Charging Address contains the following information elements: Information element name MO MF MT VT NC NP TO Description Leg ID E E E E E E E This IE indicates that the Apply Charging IF applies to the specified leg. SRF Connection E E E E E E E This IE indicates that the Apply Charging IF applies to the Temporary Connection or SRF Connection 4.6.2.3 Call Gap 4.6.2.3.1 Description This IF is used to activate/modify/remove a call gap mechanism in the gsmSSF. The call gap mechanism is used to reduce the rate at which specific service requests are sent to a gsmSCF. A Call Gap IF can only be sent on an opened dialogue between a gsmSCF and a gsmSSF. It is possible to have several call gapping conditions applicable to the same gsmSSF (i.e. each conditions was activated for a defined Service (identified by the service Key) by a defined gsmSCF (identified by the gsmSCF address). 4.6.2.3.2 Information Elements Information element name Status Description Gap Criteria M This IE specifies the criteria for a call to be subject to call gapping. Gap Indicators M This IE indicates the gapping characteristics. Control Type O This IE indicates the reason for activating call gapping. The value ""gsmSCF Overloaded"" indicates that an automatic congestion detection and control mechanism in the gsmSCF has detected a congestion situation. The value ""Manually Initiated"" indicates that the service and/or network/service management centre has detected a congestion situation, or any other situation that requires manually initiated controls. The Control Type ""Manually Initiated"" will have priority over a ""gsmSCF Overloaded"" call gap. Note that Non-IN controlled traffic control mechanism can also apply to an exchange with the gsmSSF functionality. As the non-IN controlled traffic control is within the MSC, this traffic control has implicit priority over the IN controlled traffic control. The non-IN controlled traffic control may also have some influence on the IN call. Therefore it is recommended to take measures to coordinate several traffic control mechanisms. The non-IN controlled traffic control and co-ordination of several traffic control mechanisms are out of the scope of the present document. Gap Treatment O This IE indicates how calls that were rejected due to the call gapping condition and have Default Call Handling as ""Release Call"" shall be treated. Gap Criteria contains one of the following information elements: Information element name Status Description Basic Gap Criteria O,E This IE is a choice of various basic criteria. Compound Gap Criteria O,E This IE is a choice of various criteria including a gsmSCF ID. Compound Gap Criteria contains the following information elements: Information element name Status Description Basic Gap Criteria M This IE is a choice of various criteria. gsmSCF ID O This IE contains the address of the gsmSCF which initiated the Call Gapping. Basic Gap Criteria contains one of the following information elements: Information element name Status Description Called Address O,E This IE contains a string of digits. For each call attempt where the leading digits of the dialled number match this specific value, the call gapping treatment shall be applied to the call. Service O,E This IE contains a service key value. For each call attempt where the service key match this specific value, the call gapping treatment shall be applied to the call. Called Address And Service O,E This IE contains a specific string of digits and a service key value. For each call attempt where the leading digits of the dialled number and the service key of a call match these specific values, the call gapping treatment shall be applied to the call. Calling Address And Service O,E This IE contains a specific string of digits and a service key value. For each call attempt where the leading digits of the calling party number and the service key match these specific values, the call gapping treatment shall be applied to the call. Gap Indicators contains the following information elements: Information element name Status Description Duration M This IE specifies the total time interval during which call gapping for the specified gap criteria will be active. A duration of 0 indicates that gapping is to be removed. A duration of -2 indicates a network specific duration. Other values indicate the duration in seconds. Interval M This IE specifies the minimum time between calls being allowed through. An interval of 0 indicates that calls meeting the gap criteria are not to be rejected. An interval of -1 indicates that all calls meeting the gap criteria are to be rejected. Other values indicate the interval in milliseconds. Gap Treatment contains one of the following elements: Information element name Status Description Information To Send O,E This IE indicates an announcement or a tone to be sent to the calling party. At the tone or announcement, the call shall be released. Release Cause O,E If the call is to be released, this IE indicates the specific cause value to be sent in the Release IF. See ETSI ENÊ300Ê356 1Ê[40] for the coding. Information To Send contains one of the following elements: Information element name Status Description In-band Info O,E This IE specifies the in-band information to be sent. Tone O,E This IE specifies a tone to be sent to the end-user. In-band Info contains the following information elements: Information element name Status Description Message ID M This IE is described in a table below. This IE indicates the message(s) to be sent. Message Duration O This parameter indicates the maximum time in seconds that the message shall be played/repeated. ZERO indicates endless repetition. Message Id contains the following element: Information element name Status Description Elementary Message ID O This IE indicates a single announcement. 4.6.2.4 Call Information Request 4.6.2.4.1 Description This IF is used to request the gsmSSF to record specific information about a single call party and report it to the gsmSCF (with a Call Information Report IF). 4.6.2.4.2 Information Elements Information element name Status Description Requested Information Type List M This IE is described in a table below. This IE specifies a list of specific items of information which are requested. Leg ID M This IE indicates the party in the call for which the information shall be collected. Requested Information Type List contains the following information elements: Information element name Status Description Call Attempt Elapsed Time O This IE indicates that the Call Attempt Elapsed Time is requested in the Call Information Report. Call Attempt Elapsed Time is the duration between the end of the CAMEL processing initiating call setup (Connect, Continue or Continue With Argument IF) and the received answer indication from the called party side. For the Calling Party, the value of Call Attempt Elapsed Time in the Call Information Report shall be set to 0. Call Stop Time O This IE indicates that the Call Stop Time is requested in the Call Information Report. Call Stop Time is the time stamp when the connection is released. Call Connected Elapsed Time O This IE indicates that the Call Connected Elapsed Time is requested in the Call Information Report. Call Connected Elapsed Time is the duration between the received answer indication from the called party side and the release of the connection. For a Calling Party, it indicates the duration between the sending of the Initial DP IF and the release of that party. Release Cause O This IE indicates that the Release Cause for the call party is requested in the Call Information Report. 4.6.2.5 Cancel 4.6.2.5.1 Description This IF is used by the gsmSCF to request the gsmSSF to cancel all EDPs and reports. 4.6.2.5.2 Information Elements Information element name Status Description All Requests M This IE indicates that all active requests for the Event Report BCSM, Apply Charging Report and Call Information Report IFs shall be cancelled. 4.6.2.5A Collect Information 4.6.2.5A.1 Description This IF is used to instruct the gsmSSF to collect additional dialled digits from the calling party and report them to the gsmSCF. The use of this operation is only appropriate for a call which has not yet left the set-up phase. NOTE: It is advisable to avoid the use of gsmSCF-initiated user interaction while additional digits are being collected. Interaction with a Specialised Resource Function (SRF) may result in an ACM being sent to the originating node which will prevent any further dialled digits being sent. NOTE: If the gsmSCF sends CAP Connect before the dialling is complete then no further digits can be collected from the calling party. 4.6.2.5A.2 Information Elements This IF contains no information elements. 4.6.2.6 Connect 4.6.2.6.1 Description This IF is used to request the gsmSSF to perform the call processing actions to route a call to a specific destination. To do so, the gsmSSF may use destination information from the calling party and existing call set-up information depending on the information provided by the gsmSCF. The gsmSCF shall not send this IF when there is a CSA with a single call segment which includes only legÊ1. 4.6.2.6.2 Information Elements Information element name MO MF MT VT NC NP TO Description Alerting Pattern - - O O - - - This IE indicates the kind of Alerting Pattern to be applied. Calling Partys Category O O O O O O O This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). Destination Routing Address M M M M M M M This IE contains the called party number towards which the call is to be routed. The NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of the destination address may be zero. The gsmSCF may use national-specific NatureOfAddress indicator values of the gsmSSF country. Generic Number O O O O O O O This IE contains the generic number. Its used to convey the additional calling party number, which e.g. could be used to modify the calling line ID presented to the called user. Carrier O O O O O O O This IE is described in a table below. NA Originating Line Information O O O O O O O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O O O O O O O This IE identifies the chargeable number for the usage of a North American carrier. O CSI Applicable - - O O - - - This IE indicates that the O CSI, if present shall be applied on the outgoing leg. Suppress N-CSI - - - - - - O This IE indicates that N CSI, if present, shall be suppressed for the trunk originated call. Original Called Party ID O O O O O O O This IE carries the dialled digits if the call has met call forwarding on route to the gsmSSF or is forwarded by the gsmSCF. Leg To Be Connected S S S S S S S This IE indicates the leg to which the Connect IF applies. The gsmSCF shall include this IE if: - The CSA has more than one call segment, or - The CSA has a single call segment, which contains: - one leg, which is not legÊ2; or - two legs, which are not legÊ1 and legÊ2, or - more than two legs. Otherwise this IE may be present or absent as required by the service logic. This IE shall not indicate leg1. Redirecting Party ID O O O O O O O This IE indicates the directory number the call was redirected from. Redirection Information O O O O O O O This IE contains forwarding related information, such as redirecting counter. Suppression Of Announcements - - O O O O - This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Service Interaction Indicators Two O O O O O O O This IE is described in a table below. CUG Interlock Code O O O O O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Outgoing Access Indicator O O O O O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Basic OR interrogation requested O O - - O O O This IE indicates that a Basic Optimal Routeing interrogation is requested for the call. If Basic Optimal Routeing is successful, this will be reported to the gsmSCF in the Answer event report. This IE shall be ignored if the VMSC associated with the gsmSSF does not support Basic Optimal Routeing. This IE shall be ignored if it is received in a gsmSSF which is handling the MF call case in the GMSC function of the forwarding subscriber. Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M M M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M M M M This IE indicates the way the carrier was selected e.g.: - dialled; - subscribed. Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator O O O O O O O This IE is described in a table below. Backward Service Interaction Indicator O O O O - - O This IE is described in a table below. HOLD Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of HOLD by the CAMEL subscriber. CW Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of CW for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the call leg to become part of an ECT call initiated by the CAMEL subscriber. Connected number treatment indicator O O O O - - O This IE indicates the treatment of the connected number at the originating side. Non-CUG Call O O O O O O O This IE indicates that no parameters for CUG should be used for the call (i.e. the call should be a non-CUG call). Shall be absent if one or more of CUG Interlock Code and Outgoing Access Indicator is present in the IF. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O O - O This IE allows the gsmSCF to disallow the call leg to become part of a MPTY call initiated by the CAMEL subscriber. Call Diversion Treatment Indicator O O O O O - O This IE allows the gsmSCF to disallow the Call Forwarding or Call Deflection supplementary services for this call. Calling Party Restriction Indicator O O O O O O O This IE allows the gsmSCF to mark the CLI as Restricted for the call. Backward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O - O O This IE allows the gsmSCF to disallow the call leg to become part of a MPTY call initiated by the calling subscriber. Call Completion Treatment Indicator O O O O - O O This IE allows the gsmSCF to disallow a CCBS request to be made for the call. See also 3GPP TSÊ23.093Ê[26] for description. 4.6.2.7 Connect To Resource 4.6.2.7.1 Description This IF is used to connect a call from the gsmSSF to a gsmSRF. 4.6.2.7.2 Information Elements Information element name Status Description Resource Address M This IE indicates the address of the gsmSRF to which the connection shall be established. It is described in a table below. Service Interaction Indicators Two O This IE indicates whether or not a bothway through connection is required between the call segment and the calling party. When there is no calling party connected to the call segment, then the gsmSSF shall ignore this IE, if received. The handling when this IE is not present is defined in ETSI ENÊ301Ê070 1 ([41]). Call Segment ID M This IE indicates the call segment to be connected to the resource. The subsequent user interaction shall apply to all parties connected to the call segment. Resource Address contains the following information elements: Information element name Status Description IP Routing Address E This IE indicates the routeing address to set up a connection between the call segment and the gsmSRF. None E This IE indicates that the call segment shall be connected to a predefined gsmSRF. 4.6.2.8 Continue 4.6.2.8.1 Description This IF requests the gsmSSF to proceed with call processing at the DP at which it previously suspended call processing to await gsmSCF instructions. The gsmSSF completes DP processing, and continues basic call processing (i.e. proceeds to the next point in call in the BCSM) without substituting new data from the gsmSCF. The gsmSCF may send this operation only when there is a CSA with a single call segment which includes: - only legÊ1, or - only legÊ2, or - legÊ1 and legÊ2 but no other legs. 4.6.2.8.2 Information Elements This IF contains no information elements. 4.6.2.9 Continue With Argument 4.6.2.9.1 Description This IF requests the gsmSSF to continue the call processing with modified information at the DP at which it previously suspended call processing to await gsmSCF instructions or to continue call processing after a Call Party Handling IF was received. The gsmSSF completes DP processing if necessary, and continues basic call processing (i.e. proceeds to the next point in call in the BCSM) with the modified call setup information as received from the gsmSCF. This IF may also be used to continue call processing after an Initiate Call Attempt IF and Call Party Handling IF. The gsmSCF can send modified call information at DPÊCollected_Info and at DPÊAnalysed_Info, as listed in the MO and MF columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information at DPÊTermination_Attempt_Authorised, as listed in the MT and VT columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information immediately after sending an Initiate Call Attempt IF, as listed in the NC and NP columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information at DP Collected_Info and at DP_Analysed_Info, as listed in the TO column in subclause 4.6.2.9.2. In all other cases, Continue With Argument shall contain no other IE than Leg ID or Call Segment ID. When this IF is used to resume the processing of an Initiate Call Attempt IF, then a Leg ID shall be included and Call Segment ID shall be absent. When this IF is used to resume the processing of a Call Party Handling IF, then a Call Segment ID shall be included and Leg ID shall be absent. When this IF is used to resume processing after an EDP-R or TDP-R, then a Leg ID shall be included and Call Segment ID shall be absent. The following exception exists: if this IF is used to resume processing after an EDP R or TDP R in one of the following scenarios: - the CSA has one Call Segment only, which includes legÊ1 only; - the CSA has one Call Segment only, which includes legÊ2 only; - the CSA has one Call Segment only, which includes legÊ1 and legÊ2, but no other legs; then, the Leg ID may be present or absent, as required by the Service Logic. 4.6.2.9.2 Information Elements Information element name MO MF MT VT NC NP TO Description Alerting Pattern - - O O O - - This IE indicates the kind of Alerting Pattern to be applied. Calling Partys Category O O O O O O O This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). Generic Number O O O O O O O This IE contains the generic number. It is used to convey the additional calling party number, which e.g. could be used to modify the calling line ID presented to the called user. Carrier O O O O O O O This IE is described in a table below. NA Originating Line Information O O O O O O O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O O O O O O O This IE identifies the chargeable number for the usage of a North American carrier. Suppression Of Announcements - - O O O O - This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Service Interaction Indicators Two O O O O O O O This IE is described in a table below. CUG Interlock Code O O - - O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Outgoing Access Indicator O O - - O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Basic OR Interrogation Requested O O - - O O,S O This IE indicates that a Basic Optimal Routeing interrogation is requested for the call. If Basic Optimal Routeing is successful, this will be reported to the gsmSCF in the Answer event report. This IE shall be ignored if the VMSC associated with the gsmSSF does not support Basic Optimal Routeing. This IE shall be ignored if it is received in a gsmSSF which is handling the MF call case in the GMSC function of the forwarding subscriber. For an NP call leg, this IE can only be included if the original call was an MO or NC call. Leg ID O,E O,E O,E O,E O,E O,E O,E This IE indicates the party for which call processing is to be resumed. Call Segment ID O,E O,E O,E O,E O,E O,E O,E This IE indicates the call segment for which call processing is to be resumed. Suppress O CSI - - O O - - - This IE indicates that O CSI shall be suppressed for the forwarding leg or deflecting leg. Suppress D CSI - - - - - O - This IE indicates that D CSI shall be suppressed for the new call leg. This IE can only be included if this IE is sent to the VMSC or GMSC of the CAMEL subscriber. Suppress N CSI - - - - O O O This IE indicates that N CSI shall be suppressed for the new call leg or trunk originated call. Suppress Outgoing Call Barring - - - - - O - This IE indicates that Outgoing Call Barrings for the created leg shall be suppressed. This IE can only be included if the Initiate Call Attempt IF is sent to the VMSC of the CAMEL subscriber."
"Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M M M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M M M M This IE indicates the way the carrier was selected, i.e.: - dialled - subscribed Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator O O O O O O O This IE is described in a table below. Backward Service Interaction Indicator O O O O - - O This IE is described in a table below. HOLD Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of HOLD by the CAMEL subscriber. CW Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of CW for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the call leg to become part of an ECT call initiated by the CAMEL subscriber. Connected Number Treatment Indicator O O O O - - - This IE indicates the treatment of the connected number at the originating side. Non-CUG Call O O - - - O O This IE indicates that no parameters for CUG should be used for the call (i.e. the call should be a non-CUG call). This IE shall be absent if one or more of CUG Interlock Code and Outgoing Access Indicator are present in the IF. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O O O O This IE indicates whether the call leg can become part of a MPTY call initiated by the called subscriber. Call Diversion Treatment Indicator O O O O O O O This IE indicates whether the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. Calling Party Restriction Indicator O O O O O O O This IE allows the gsmSCF to mark the CLI as Restricted for the call. Backward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O - - O This IE indicates if the call leg can become part of a MPTY call initiated by the calling subscriber. Call Completion Treatment Indicator O O O O - - O This IE indicates whether a CCBS request can be made for the call. See also 3GPP TSÊ23.093Ê[26] for description. 4.6.2.10 Disconnect Forward Connection 4.6.2.10.1 Description This IF is used: - to disconnect a connection with a gsmSRF previously established with a Connect To Resource IF; - to disconnect an initiating gsmSSF from an assisting gsmSSF and its associated gsmSRF. The IF is sent to the initiating gsmSSF. 4.6.2.10.2 Information Elements This IF contains no information elements. 4.6.2.11 Disconnect Forward Connection With Argument 4.6.2.11.1 Description This IF is used in the following two cases: 1) To clear a connection to a gsmSRF: This IF is used to explicitly disconnect a connection to a resource (gsmSRF) established previously with a Connect To Resource or an Establish Temporary Connection IF. It is used for a forward disconnection from the gsmSSF. 2) To clear a connection to an assisting SSF: This IF is sent to the non-assisting SSF of a pair of SSFs involved in an assist procedure. It is used to disconnect the temporary connection between the initiating SSF and the assisting SSF. 4.6.2.11.2 Information Elements Information element name Status Description Call Segment ID M This IE indicates the call segment in the call to be disconnected from the resource or the temporary connection. 4.6.2.12 Disconnect Leg 4.6.2.12.1 Description This IF is used to request the gsmSSF to release a specific leg associated with the call at any phase. All other legs in this call are retained. If the last leg of the call segment is disconnected, then the call segment is deleted. 4.6.2.12.2 Information Elements Information element name Status Description Leg To Be Released M This IE indicates the party in the call to be released. Release Cause O This IE indicates to the gsmSSF the reason for releasing the identified party. This may be used by the MSC or GMSC for generating specific tones to the party to be released or to fill in the ""cause"" IE in the Release IF. 4.6.2.13 Establish Temporary Connection 4.6.2.13.1 Description This IF is used to create a connection between an initiating gsmSSF and an assisting gsmSSF as a part of the assist procedure. It can also be used to create a connection between a gsmSSF and a gsmSRF. 4.6.2.13.2 Information Elements Information element name Status Description Assisting SSP IP Routing Address M This IE indicates the destination address of the gsmSRF or assisting gsmSSF for the assist procedure. As a network operator option, the Assisting gsmSSF IP Routing Address may contain embedded within it, a ""Correlation ID"" and ""gsmSCF ID"", but only if ""Correlation ID"" and ""gsmSCF ID"" are not specified separately. Correlation ID O This IE is used for: - the correlation of dialogues from the initiating gsmSSF-> gsmSCF with dialogues from gsmSRF -> gsmSCF; - the correlation of dialogues from the initiating gsmSSF-> gsmSCF with dialogues from assisting gsmSSF -> gsmSCF. Carrier O This IE is described in a table below. NA Originating Line Information O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O This IE identifies the chargeable number for the usage of a North American carrier. gsmSCF ID O This IE indicates the gsmSCF identifier. Service Interaction Indicators Two O This IE indicates whether or not a bothway through connection is required between the call segment and the calling party. When there is no calling party connected to the call segment, then the gsmSSF shall ignore this IE, if received. The handling when this IE is not present is defined in ETSI ENÊ301Ê070 1Ê[41]. Call Segment ID M This IE indicates the call segment to be connected to the resource. The subsequent user interaction shall apply to all parties connected to the call segment. Original Called Party ID O This IE may be used to identify the original called party. If present, it shall be included in the ISUP IAM for the Temporary Connection. Support of this IE in the gsmSSF is an implementation option. Calling Party Number O This IE may be used to identify the calling party. If present, it shall be included in the ISUP IAM for the Temporary Connection. Support of this IE in the gsmSSF is an implementation option. Carrier contains the following information elements: Information element name Status Description Carrier Identification Code M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M This IE indicates the way the carrier was selected, i.e.: - dialled; - subscribed. 4.6.2.14 Furnish Charging Information 4.6.2.14.1 Description This IF is used to request the gsmSSF to include call related information in the CAMEL specific logical call record. The logical call record is created when the Furnish Charging Information IF is received and a logical call record for that leg does not exist. For modelling purposes the logical call record is buffered in the gsmSSF. The gsmSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then the free format data are moved to the corresponding CDR and the logical call record is deleted. The gsmSCF can send multiple concatenated Furnish Charging Information IFs per leg for completion. The total maximum of free format data is 160 octets per leg. The 160 octets may be sent in one or more FCI IFs. If there are incomplete free format data and new Furnish Charging Information IF(s) is/are received to overwrite the non-completed data, then the non-complete data are discarded and the gsmSCF can send another 160 octets per leg. The SDLs of the present document define when logical call records are completed. After the completion the gsmSCF can send another 160 octets of the free format data in one or more Furnish Charging Information IFs for the called leg. 4.6.2.14.2 Information Elements Information element name Status Description FCI Billing Charging Characteristics M This IE is described in a table below. FCI Billing Charging Characteristics contains the following information element: Information element name Status Description FCIBCCCAMEL Sequence 1 M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information elements: Information element name Status Description Free Format Data M This IE contains the free format data to be inserted in the CAMEL logical call record. Party To Charge M This IE indicates the party for whom a CAMEL logical call record will be created. Append Free Format Data O This IE indicates that the gsmSSF shall append the free format data to the logical call record. - If this IE is present and indicates ""Append"", the gsmSSF shall append the free format data received in this IF to the free format data already present in the logical call record for that leg of the call. - If this IE is absent or indicates ""Overwrite"", then the gsmSSF shall overwrite all free format data already present in the logical call record for that leg of the call, by the free format data received in this IF. If no logical call record exists for that leg of the call, then the gsmSSF shall ignore this IE. 4.6.2.15 Initiate Call Attempt 4.6.2.15.1 Description This IF is used to request the gsmSSF to create a new party in an existing call (NP), or to create a completely new call (NC). The created leg is an originating call. The address information provided by the gsmSCF is used. 4.6.2.15.2 Information Elements Information element name NC NP Description Destination Routeing Address M M This IE contains the called party number towards which the call is to be routed. For calls to an MS this can e.g. be (but shall not be limited to) the MSISDN (for routeing via a GMSC) or the MSRN received from the HLR (for routeing direct to the VMSC). Calling Party Number M - This IE identifies which number shall be regarded as the calling party for the created call. Leg To Be Created M M This IE indicates the legID to be assigned to the newly created party. The leg ID shall be 3 or higher. New Call Segment M M This IE indicates the CS ID to be assigned to the newly created call segment. Call Reference Number M - This IE may be used by the gsmSCF for inclusion in a network optional gsmSCF call record. The call reference number is included by the MSC in the call record. gsmSCF Address M - This IE contains the address of the gsmSCF which initiated the new call. This IE is required for a unique Call Reference. Suppress T CSI O O This IE indicates that T CSI shall be suppressed on the terminating leg. 4.6.2.16 Move Leg 4.6.2.16.1 Description This IF requests the gsmSSF to move a leg to CSID1. After the move the source call segment is deleted. In moving the specified leg, the conditions of the leg: the armed EDPs, the Stored e parameters, the Non-completed CAMEL logical call records, and the Call Information Report pending, are also applied for the same leg after the move. 4.6.2.16.2 Information Elements Information element name Status Description Leg ID To Move M This IE indicates the leg that shall be moved. 4.6.2.17 Play Tone 4.6.2.17.1 Description This IF is used to play a variable sequence of tones to a particular leg or call segment using the MSC's tone generator. Refer to subclauseÊ4.5.7.1.2 for a graphical representation of the variable sequence of tones. In order to avoid tone bursts being played in close succession to the same party or group of parties, the gsmSCF is responsible for careful use of this IF especially when warning tones have been scheduled using the Apply Charging IF. 4.6.4.17.2 Information Elements Information element name Status Description Leg or Call Segment M This IE is described in a table below. This IE indicates the leg or call segment. Burst List M This IE is described in a table below. This IE indicates a variable sequence of bursts. Leg or Call Segment contains the following information elements: Information element name Status Description Call Segment ID E This IE indicates the call segment to which tones shall be played. Leg ID E This IE indicates the leg to which tones shall be played. Burst List contains the following information elements: Information element name Status Description Number of bursts M This IE indicates the number of bursts to be played. There may be up to three bursts. Burst interval M This IE indicates the time interval between successive bursts. Number of tones in burst M This IE indicates the number of tones to be played in each burst. There may be up to three tones per burst. The tone is fixed to 900 Hz. Tone Duration M This IE indicates the duration of each tone in a burst. Tone Interval M This IE indicates the time interval between successive tones in a burst. 4.6.2.18 Release Call 4.6.2.18.1 Description This IF is used by the gsmSCF to tear down an existing call at any phase of the call for all parties involved in the call. 4.6.2.18.2 Information Elements Information element name Status Description Release Cause E This IE indicates the Release Cause for the call. This may be used by the MSC or GMSC for generating specific tones to the different parties in the call or to fill in the ""cause"" in the Release IF. Release Cause With Extensions E This IE indicates the Release Cause for the call. This may be used by the MSC or GMSC for generating specific tones to the different parties in the call or to fill in the ""cause"" in the Release IF. This IE may include additional network specific IE. It may be used by the gsmSCF only if the Initial DP IF or ICA Ack contained the 'Release Call Argument Extension Allowed' IE. 4.6.2.19 Request Report BCSM Event 4.6.2.19.1 Description This IF is used to request the gsmSSF to monitor for a call-related event, then send a notification back to the gsmSCF when the event is detected (see Event Report BCSM). 4.6.2.19.2 Information Elements Information element name MO MF MT VT NC NP TO Description BCSM Event M M M M M M M This IE specifies the event or events for which a report is requested. BCSM Event contains the following information elements: Information element name MO MF MT VT NC NP TO Description Event type M M M M M M M This IE specifies the type of event for which a report is requested. Leg ID C C C C C M C This IE indicates the party in the call for which the event shall be armed or disarmed. Monitor Mode M M M M M M M If this IE is ""interrupted"" then the event shall be reported as a request, if this IE is ""notify and continue"" then the event shall be reported as a notification, if this IE is ""transparent"" then the event shall not be reported. DP Specific Criteria O O O O O O O This IE is described in a table below. Automatic Rearm O O O O - - O This IE indicates that the detection point shall be automatically rearmed by the gsmSSF when it is encountered. This IE may be present only if the Event Type is O_Mid_Call, T_Mid_Call, O_Change_Of_Position, T_Change_Of_Position, O_Service_Change or T_Service_Change and the Monitor Mode is ""notify and continue"". The MF and MT cases apply for O_Service_Change or T_Service_Change DPs only. The TO case applies for O_Mid_Call and O_Service_Change DPs only. DP Specific Criteria contains the following information elements: Information element name MO MF MT VT NC NP TO Description Application Timer O O O O O O O This IE carries additional timer duration information (timer values for No_Answer event) required for arming the No_Answer EDPs in the gsmSSF. The TNRy timer (value defined between 10Êseconds and 40Êseconds) shall be shorter than the network no answer timer. Mid Call Control Info O - - O - - O This IE is described in a table below. This IE carries the criterion for the detection and reporting of the mid-call event. If this IE is absent, then mid-call triggering shall take place when the first digit has been entered by the user. Change of Position Control Info O - - O - - - This IE is described in a table below. It carries the list of criteria for the reporting of the change of position event. If the DP Specific Criteria IE is absent, then the criteria for any change of position shall be regarded as fulfilled. Number of Digits - - - - - - O This IE indicates the number of additional digits requested by the gsmSCF to be collected by the gsmSSF before the CollectedInfo event is reported, excluding the digits reported already. It excludes the end of pulsing signal (ST) Inter Digit Timeout - - - - - - O This IE carries additional timer duration information required for arming the CollectedInfo event in the gsmSSF. The IE indicates the maximum duration allowed between receipt of successive digits from the calling party. The Inter Digit timer value shall be shorter than the network inter-digit timer. The MSC/ gsmSSF shall use the network inter-digit timer duration as the default duration. If one or more CollectInformation operations are received in a call then the latest received value overwrites the previous value. If the latest CollectInformation does not include this IE then the previous value applies. NOTE If a Request Report BCSM Event information flow overwrites previous Request Report BCSM Event information flow which contained Application Timer IE for No_Answer DP, the behaviour of the gsmSSF is unpredictable. Mid Call Control Info contains the following information elements: Information element name MO MF MT VT NC NP TO Description Minimum Number Of Digits M - - M - - M This IE indicates the minimum number of digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. Maximum Number Of Digits M - - M - - M This IE indicates the maximum number of digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. If triggering takes place due to the detection of the maximum number of digits and the End of reply digit string, if present, is partially detected, then the partially detected End of reply digit string shall be included in the digit string to be reported to the gsmSCF. End of Reply Digit String O - - O - - O This IE, if present, indicates the digit string that denotes the end of the digits to be collected. If triggering takes place due to the detection of the End of reply digit string, then this string shall be included in the digit string to be reported to the gsmSCF. If the interdigit timeout expires when the Start Digit String, if present, is complete and the Minimum Number Of Digits has been detected and the End Digit String, if present, has been partially detected then triggering shall take place. The partially detected End Of Reply Digit String shall be included in the string to be reported to the gsmSCF. Cancel Digit String O - - O - - O This IE, if present, indicates the digit string that indicates that the input shall be erased and that digit collection, including the start digit string, if present, shall start afresh. Start Digit String O - - O - - O This IE, if present, indicates the digit string that denotes the start of the digits to be collected. If this IE is absent, then the first digit entered forms part of the digits to be collected. When triggering takes place, then the Start digit string shall be included in the digit string to be reported to the gsmSCF. Inter Digit Timeout M - - M - - M This IE indicates the maximum duration allowed between receipt of successive digits from the MS. For the TO case, this IE indicates the maximum duration allowed between receipt of successive digits from the calling party. Change of Position Control Info contains a list of up to 10 instances of the following information element: Information element name MO MF MT VT NC NP Description Change Of Location M - - M - - Each Change Of Location IE is one of the 6 possibilities indicated in the table below. If multiple instances of the Change Of Location IE have the same value, this is not an error. Each instance of the Change Of Location IE contains one of the following information elements: Information element name MO MF MT VT NC NP Description Cell Global ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the cell specified in this IE, i.e. handover into or out of the cell. Service Area ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the service area specified in this IE, i.e. handover into or out of the service area. Location Area ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the location area specified in this IE, i.e. handover into or out of the location area. Inter-System Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-system handover. Inter-PLMN Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-PLMN handover. Inter-MSC Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-MSC handover. 4.6.2.20 Reset Timer 4.6.2.20.1 Description This IF is used to reset a timer. 4.6.2.20.2 Information Elements Information element name Status Description Timer Value M This IE specifies the value to which the indicated timer shall be set. Timer ID O This IE indicates which timer shall be reset. It shall be set to 'Tssf'. Call Segment ID M This IE indicates for which Call Segment in the gsmSSF the timer shall be reset. 4.6.2.21 Send Charging Information 4.6.2.21.1 Description This IF is used to send e parameters from the gsmSCF to the gsmSSF. If Charge Advice Information (CAI) is received from the gsmSCF, it shall replace the CAI which would be generated by the MSC and inhibit any further generation of CAI by the MSC. Further processing of the CAI by the MSC shall be in accordance with the Advice of Charge supplementary service. If the subscriber is not provisioned with the Advice of Charge supplementary service or if the VPLMN does not support this service, then no e parameters shall be sent to the MS and no error due to this fact shall be sent back to the gsmSCF. The IF is only used in the MO case or in the VT case. NOTE: If CAI is received from the gsmSCF after charge information has been generated by the MSC and sent to the MS, the behaviour of the service may be unpredictable or incorrect; the service designer should therefore ensure that the first set of CAI is sent to the gsmSSF before charge information is sent to the MS. 4.6.2.21.2 Information Elements Information element name MO MF MT VT NC NP Description SCI Billing Charging Characteristics M - - M - - This IE defines the Advice Of Charge related information to be provided to the Mobile Station. Leg ID M - - M - - This IE indicates the leg to which the charging information shall be sent. SCI Billing Charging Characteristics contains the following information elements: Information element name MO MF MT VT NC NP Description AoC After Answer S,E - - S,E - - This IE is described in a table below. This IE is present after an Answer event has been detected from the called party, the current connected SRF or the temporary connection. AoC Before Answer S,E - - S,E - - This IE is described in a table below. This IE is present before an Answer event has been detected from the called party, the current connected SRF or the temporary connection. AoC Before Answer contains the following information elements: Information element name MO MF MT VT NC NP Description AoC Initial M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. AoC Subsequent O - - O - - This IE is described in a table below. AoC Subsequent contains the following information elements: Information element name MO MF MT VT NC NP Description CAI Elements M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O - - O - - This IE indicates the tariff switch time until the next tariff switch applies. AoC After Answer contains the following information elements: Information element name MO MF MT VT NC NP Description CAI Elements M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O - - O - - This IE indicates the tariff switch time until the next tariff switch applies. 4.6.2.22 Split Leg 4.6.2.22.1 Description This IF is used to request the gsmSSF to separate a leg from CSID1 and move it to a new call segment. If CSID1 does not exist, then this IF is used to request the gsmSSF to move a leg into a newly created CSID1. In splitting the specified leg, the conditions of the leg: the armed EDPs, the Stored e parameters, the Non-completed CAMEL logical call records, and the Call Information Report pending, are also applied for the same leg after split. 4.6.2.22.2 Information Elements Information element name Status Description Leg To Be Split M This IE indicates the leg in the call to be split. New Call Segment M This IE indicates the Call Segment ID to be assigned to the new call segment. 4.6.3 Optional (Service logic dependent) gsmSCF to gsmSRF information flows 4.6.3.1 Activity Test 4.6.3.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gsmSRF. If the relationship is still in existence, then the gsmSRF will respond. If no reply is received, then the gsmSCF will assume that the gsmSRF has failed in some way and will take the appropriate action. 4.6.3.1.2 Information Elements This IF contains no information elements. 4.6.3.2 Cancel 4.6.3.2.1 Description This IF is used by the gsmSCF to request the gsmSRF to cancel a correlated previous IF. 4.6.3.2.2 Information Elements Information element name Status Description Invoke ID E This IE specifies the IF to be cancelled. This IE may be used when the Cancel IF is used in a single call segment CSA or when the Cancel IF is sent by the gsmSCF to an Intelligent Peripheral. Call Segment To Cancel E This IE may be used when the Cancel IF is used in a single call segment CSA or in a multi call segment CSA. This IE is described in a table below. This IE shall not be used when the Cancel IF is sent by the gsmSCF to an Intelligent Peripheral. Call Segment To Cancel contains the following information elements: Information element name Status Description Invoke ID M This IE specifies the IF to be cancelled. Call Segment ID M This IE specifies to which call segment the cancellation of the user interaction IF shall apply. 4.6.3.3 Play Announcement 4.6.3.3.1 Description This IF is used for inband interaction. 4.6.3.3.2 Information Elements Information element name Status Description Information To Send M This IE is described in a table below. Disconnect From IP Forbidden M This IE indicates whether or not the gsmSRF may be disconnected from the user when all information has been sent. Request Announcement Complete Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when all information has been sent. Request Announcement Started Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when the first announcement or tone starts. Call Segment ID S This IE indicates the call segment to which the user interaction shall apply. This IE shall be absent if this IF is sent by the gsmSCF to an Intelligent Peripheral. Information To Send contains the following information elements: Information element name Status Description Inband Info E This IE is described in a table below. Tone E This IE is described in a table below. Inband Info contains the following information elements: Information element name Status Description Message ID M This IE is described in a table below. Number Of Repetitions M This IE indicates the maximum number of times the message shall be sent to the end-user. Duration O This IE indicates the maximum duration time in seconds that the message shall be played/repeated. Zero indicates endless repetition. Interval O This IE indicates the time interval in seconds between two repetitions. Message ID contains the following information elements: Information element name Status Description Elementary Message ID E This IE indicates a single announcement Text E This IE indicates a text to be sent. The text shall be transformed to inband information (speech) by the gsmSRF. Elementary Message IDs E This IE indicates a sequence of announcements Variable Message E This IE indicates an announcement with one or more variable parts. Tone contains the following information elements: Information element name Status Description Tone ID M This IE indicates the tone to be sent. Duration O This IE indicates the maximum duration in seconds that the message shall be played/repeated. Zero indicates endless repetition. 4.6.3.4 Prompt And Collect User Information 4.6.3.4.1 Description This IF is used to interact with a call party in order to collect information. 4.6.3.4.2 Information Elements Information element name Status Description Collected Info M This IE is described in a table below. Information To Send O This IE is described in subclauseÊ4.6.3.3.2. This IE indicates an announcement or a tone to be sent to the end user by the gsmSRF. Disconnect From IP Forbidden M This IE indicates whether the gsmSRF may be disconnected from the user when all information has been sent. Request Announcement Started Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when the first announcement or tone starts. Call Segment ID S This IE indicates the call segment to which the user interaction shall apply. This IE shall be absent if this IF is sent by the gsmSCF to an Intelligent Peripheral. Collected Info contains the following information element: Information element name Status Description Collected Digits M This IE is described in a table below. Collected Digits contains the following information elements: Information element name Status Description Minimum Number Of Digits M This IE indicates the minimum number of valid digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. Maximum Number Of Digits M This IE specifies the maximum number of valid digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. End Of Reply Digit O This IE indicates the digit(s) used to signal the end of input. Cancel Digit O If this IE is present then the cancel digit can be entered by the user to request a possible retry. Start Digit O If this IE is present then the start digit(s) indicates the start of the valid digits to be collected. First Digit Time Out O If this IE is present then the first digit shall be received before the expiration of the first digit timer expiration. Inter Digit Time Out O If this IE is present then any subsequent valid or invalid digit shall be received by the gsmSRF before the inter digit timer expires. Error Treatment O This IE indicates what specific action shall be taken by the gsmSRF in the event of error conditions occurring. Interruptable Ann Ind O If this IE is set to TRUE (default value) then the announcement is interrupted after the first valid or invalid digit received by the gsmSRF. If this IE is present and explicitly set to FALSE then the announcement will not be interrupted after the first digit is received by the gsmSRF. Voice Information O If this IE is set to FALSE (default value) then all valid or invalid digits are entered by DTMF. If this IE is set to TRUE then the calling user is required to provide all valid or invalid information by speech. Voice Back O If this IE is set to FALSE (default value) then no voice back information is given by the gsmSRF. If this IE is set to TRUE then the valid input digits received by the gsmSRF will be announced back to the calling user immediately after the end of input is received. 4.6.4 gsmSRF to gsmSCF information flows 4.6.4.1 Activity Test ack 4.6.4.1.1 Description This IF is the response to the Activity Test. 4.6.4.1.2 Information Elements This IF contains no information elements. 4.6.4.2 Assist Request Instructions 4.6.4.2.1 Description This IF is sent to the gsmSCF by a gsmSSF which is acting as the assisting gsmSSF or by a gsmSRF. 4.6.4.2.2 Information Elements Information element name Status Description Correlation ID M This IE is used to associate the Assist Request Instructions IF from an assisting gsmSSF or by a gsmSRF with the Initial DP IF from the initiating gsmSSF. IP SSP Capabilities M This IE indicates which SRF resources are attached, available and supported within the MSC where the gsmSSF resides or the IP in which the gsmSRF resides. 4.6.4.3 Prompt And Collect User Information ack 4.6.4.3.1 Description This IF is used by the gsmSRF to indicate the result of a Prompt And Collect User Information IF. 4.6.4.3.2 Information Elements Information element name Status Description Digits Response C This IE indicates the digit sequence received from the end user. 4.6.4.4 Specialized Resource Report 4.6.4.4.1 Description This IF is used when a Specialized Resource Report was requested in a Play Announcement IF or in a Prompt and Collect User Information IF. 4.6.4.4.2 Information Elements Information element name Status Description All Announcements Complete E This IE indicates that all the announcements and tones are complete. First Announcement Started E This IE indicates that the first announcement or tone has started. 4.6.5 gsmSCF to Assisting SSF information flows 4.6.5.1 Activity Test 4.6.5.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and assistSSF. If the relationship is still in existence, then the assistSSF will respond. If no reply is received, then the gsmSCF will assume that the assistSSF has failed in some way and will take the appropriate action. 4.6.5.1.2 Information Elements This IF contains no information elements. 4.6.5.2 Cancel 4.6.5.2.1 Description This IF is used by the gsmSCF to request the assisting gsmSSF to cancel a correlated previous IF. 4.6.5.2.2 Information Elements Information element name Status Description Invoke ID M This IE specifies the IF to be cancelled. 4.6.5.3 Connect To Resource 4.6.5.3.1 Description This IF is described in subclauseÊ4.6.2.7. The following difference applies: - The Call Segment ID information element is not used. 4.6.5.4 Disconnect Forward Connection 4.6.5.4.1 Description This IF is used to disconnect a connection with a gsmSRF previously established with a Connect To Resource IF. 4.6.5.4.2 Information Elements This IF contains no information elements. 4.6.5.5 Play Announcement 4.6.5.5.1 Description This IF is described in subclauseÊ4.6.3.3. The following difference applies: - The Call Segment ID information element is not used. 4.6.5.6 Prompt And Collect User Information 4.6.5.6.1 Description This IF is described in subclauseÊ4.6.3.4."
"The following difference applies: - The Call Segment ID information element is not used. 4.6.5.7 Reset Timer 4.6.5.7.1 Description This IF is described in subclauseÊ4.6.2.20. The following difference applies: - The Call Segment ID information element is not used. 4.6.6 Assisting SSF to gsmSCF information flows 4.6.6.1 Activity Test ack 4.6.6.1.1 Description This IF is the response to the Activity Test. 4.6.6.1.2 Information Elements This IF contains no information elements. 4.6.6.2 Assist Request Instructions 4.6.6.2.1 Description This IF is described in subclauseÊ4.6.4.2. 4.6.6.3 Prompt And Collect User Information ack (received information) 4.6.6.3.1 Description This IF is described in subclauseÊ4.6.4.3. 4.6.6.4 Specialized Resource Report 4.6.6.4.1 Description This IF is described in subclauseÊ4.6.4.4. 4.6.7 HLR to VLR information flows 4.6.7.1 Delete Subscriber Data 4.6.7.1.1 Description This IF is used by an HLR to delete CAMEL subscription data from a VLR. It is specified in 3GPP TSÊ29.002Ê[34]. 4.6.7.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O,E This IE identifies that all CSIs shall be deleted from the subscriber data in the VLR. Specific CSI Withdraw O,E This IE indicates that one or more specific elements of CAMEL Subscription Info shall be deleted from the VLR. The specific elements of CAMEL Subscription Info which may be deleted are: - O CSI with TDP criteria for O CSI; - TIF CSI; - D CSI; - VT CSI with TDP criteria for VT CSI. This IE should not be present when CAMEL Subscription Info Withdraw is present. 4.6.7.2 Insert Subscriber Data 4.6.7.2.1 Description This IF is used by an HLR to update a VLR with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 4.6.7.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information elements for circuit switched call control: Information element name Status Description O CSI O This IE is described in a table below. This IE identifies the subscriber as having originating CAMEL services. D CSI O This IE is described in a table below. This IE identifies the subscriber as having originating CAMEL dialled services. VT CSI O This IE is described in a table below. This IE identifies the subscriber as having terminating CAMEL services in the VMSC. TIF CSI O See 3GPP TSÊ23.072Ê[16]. O CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.1 Service Key M This IE is described in subclauseÊ4.3.1. Default Call Handling M This IE is described in subclauseÊ4.3.1. TDP List M This IE is described in subclauseÊ4.3.1. DP Criteria O This IE is described in subclauseÊ4.3.1. CAMEL Capability Handling C This IE is described in subclauseÊ4.3.1. If this IE is absent, this indicates that CAMEL phaseÊ1 support is requested. D CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.2. Service Key M This IE is described in subclauseÊ4.3.2. Default Call Handling M This IE is described in subclauseÊ4.3.2. DP Criteria M This IE is described in subclauseÊ4.3.2. CAMEL Capability Handling M This IE is described in subclauseÊ4.3.2. The CAMEL Capability Handling shall indicate CAMEL phaseÊ3 or higher. VT CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.6. Service Key M This IE is described in subclauseÊ4.3.6. Default Call Handling M This IE is described in subclauseÊ4.3.6. TDP List M This IE is described in subclauseÊ4.3.6. DP Criteria O This IE is described in subclauseÊ4.3.6. CAMEL Capability Handling M This IE is described in subclauseÊ4.3.6. The CAMEL Capability Handling shall indicate CAMEL phaseÊ3 or higher. 4.6.7.3 Provide Subscriber Info 4.6.7.3.1 Description This IF is described in TSÊ23.018Ê[12]; it is used by the HLR to request information (any one or more of subscriber state, subscriber location, IMEI & software version and MS classmark information for the CS domain) from the VLR at any time. 4.6.7.4 Provide Roaming Number 4.6.7.4.1 Description This IF is specified in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to request a roaming number from the VLR. 4.6.7.4.2 Information Elements Provide Roaming Number contains the following CAMEL specific information elements: Information element name Status Description Suppression Of Announcements S This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. It shall be present if the HLR received it in the Send Routeing Info IF. Call Reference Number M This IE carries the Call Reference Number provided by the GMSC or the gsmSCF in the Send Routeing Info IF. GMSC Or gsmSCF Address M This IE is the E.164 address of the GMSC for an MT call or the E.164 address of the gsmSCF for a gsmSCF initiated call. Alerting Pattern S This IE indicates the kind of Alerting Pattern to be applied. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info IF. Supported CAMEL Phases in Interrogating Node S This IE indicates the CAMEL Phases supported in the GMSC or the gsmSCF. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. Offered CAMEL4 CSIs in Interrogating Node S This IE indicates the CAMEL phaseÊ4 CSIs offered in the GMSC or the gsmSCF. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. This IE is described in a table below. Suppress VT CSI S This IE indicates that VT CSI shall be suppressed for the called party. This IE shall be present if the HLR received it in the Send Routeing Info IF. OR not Supported In GMSC S This IE indicates that the VMSC should not attempt to invoke Optimal Routeing of late call forwarding. It shall be present if this IF was triggered by a Send Routeing IF for a gsmSCF initiated call. Offered CAMEL4 CSIs in Interrogating Node contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. 4.6.8 VLR to HLR information flows 4.6.8.1 Insert Subscriber Data ack 4.6.8.1.1 Description This IF is used by the VLR to indicate to the HLR the result of the Insert Subscriber Data IF. It is specified in 3GPP TSÊ29.002Ê[34]. 4.6.8.1.2 Information Elements Insert Subscriber Data ack contains the following CAMEL specific information elements: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the VMSC/VLR. It shall be present when a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if a CSI has been included in the Insert Subscriber Data IF and the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. 4.6.8.2 Provide Subscriber Info ack 4.6.8.2.1 Description This IF is described in TSÊ23.018Ê[12]; it is used by the VLR to provide the requested information to the HLR. 4.6.8.3 Update Location 4.6.8.3.1 Description This IF is used by the VLR to provide information about supported CAMEL phases to the HLR. 4.6.8.3.2 Information Elements Update Location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which phases of CAMEL are supported. It shall be present if a CAMEL phase higher than phaseÊ1 is supported. Otherwise may be absent. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. 4.6.8.4 Restore Data 4.6.8.4.1 Description This IF is used by the VLR to provide the information about supported CAMEL phases to the HLR. 4.6.8.4.2 Information Elements Restore Data contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which phases of CAMEL are supported. It shall be present if a CAMEL phase higher than phaseÊ1 is supported. Otherwise may be absent. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI 4.6.9 HLR to GMSC information flows 4.6.9.1 Send Routeing Info ack 4.6.9.1.1 Description This IF is specified in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to transfer the requested routeing information to the GMSC. 4.6.9.1.2 Information Elements Send Routeing Info ack contains the following CAMEL specific information elements: Information element name Status Description Location Information C This IE indicates the location of the served subscriber. O CSI S O CSI is defined in subclauseÊ4.3.1. This IE identifies the subscriber as having originating CAMEL services. It shall be present if O CSI is active, and CFU or CFNRc has been invoked, or if both O CSI and T CSI are active. D CSI S D CSI is defined in subclauseÊ4.3.2. This IE identifies the subscriber as having originating CAMEL dialled services. It shall be present if D CSI is active, and CFU or CFNRc has been invoked, or if both D CSI and T CSI are active. Subscriber State C This IE indicates the state of the MS. The possible values of the IE are: - CAMEL Busy: The VLR has indicated that the MS is engaged in a transaction for a mobile originating or terminated circuit-switched call. - Network Determined Not Reachable: The HLR or VLR has indicated that the network can determine from its internal data that the MS is not reachable. - Assumed Idle: The VLR has indicated that the state of the MS is neither ""CAMEL Busy"" nor ""Network Determined Not Reachable"". - Not Provided From VLR: The VLR did not provide any information on subscriber state even though it was requested. T CSI S This IE is described in a table below. This IE identifies the subscriber as having terminating CAMEL services. It shall be present if T CSI is active and no Suppress T CSI indicator is present in the Send Routeing Info IF. Basic Service Code C This IE indicates the type of basic service, i.e. teleservice or bearer service. CUG Subscription Flag S This IE indicates if the called party has a CUG subscription. It shall be present only if the T CSI is active and included in the Send Routing Information ack IF. Supported CAMEL Phases In VMSC S This IE indicates the supported CAMEL phases of the VLR. It shall be present if known by the HLR, otherwise it shall be absent. Offered CAMEL4 CSIs In VMSC S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC. It shall be present if known by the HLR, otherwise it shall be absent. VMSC Address M This IE indicates the E.164 address of the VMSC in whose area the B subscriber is currently registered. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number C See 3GPP TSÊ23.018Ê[12]. The HLR shall include the internally stored VLR Number. Current Location Retrieved - Not applicable Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S This IE indicates the LSA identity associated with the current position of the MS. Shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. If there are multiple matches the LSA ID with the highest priority shall be sent. See 3GPP TSÊ23.073Ê[18]. E-UTRAN Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E See 3GPP TSÊ23.018Ê[12]. T CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.5. Service Key M This IE is described in subclauseÊ4.3.5. Default Call Handling M This IE is described in subclauseÊ4.3.5. TDP List M This IE is described in subclauseÊ4.3.5. DP Criteria S This IE is described in subclauseÊ4.3.5. The HLR shall send only the criteria associated with DPÊT_Busy or DPÊT_No_Answer, if available. CAMEL Capability Handling C This IE is described in subclauseÊ4.3.5. If this IE is absent then this indicates that CAMEL phaseÊ1 support is requested. Offered CAMEL4 CSIs In VMSC contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. It shall be present if known by the HLR, otherwise it shall be absent. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. It shall be present if known by the HLR, otherwise it shall be absent. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. It shall be present if known by the HLR, otherwise it shall be absent. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. It shall be present if known by the HLR, otherwise it shall be absent. 4.6.10 GMSC to HLR information flows 4.6.10.1 Send Routeing Info 4.6.10.1.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request information from the HLR to route an MT call. 4.6.10.1.2 Information Elements Send Routeing Info contains the following CAMEL specific information elements: Information element name Status Description Alerting Pattern S This IE indicates the kind of Alerting Pattern to be applied. It shall be present if it was received from the gsmSCF or set by the gsmSSF. Suppression Of Announcement S This IE indicates that announcements or tones generated as a result of unsuccessful call setup shall be suppressed. It shall be present in the interrogation if available, i.e. when it has been received from the gsmSCF. Suppress T CSI S This IE indicates that T CSI shall be suppressed. It shall always be present in the second interrogation or if it was received from the gsmSCF due to an Initiate Call Attempt IF. Supported CAMEL Phases M This IE lists the supported CAMEL phases in the GMSC. Offered CAMEL4 CSIs M This IE indicates the CAMEL phaseÊ4 CSIs offered in the GMSC. This IE is described in a table below. Call Reference Number M This IE carries the Call Reference Number allocated for the call by the GMSC. It shall be allocated once per call and present in both first and second interrogations. GMSC Address M This IE is the E.164 address of the GMSC. Call Diversion Treatment Indicator S This IE indicates whether or not the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. It shall be present if it was received within Forward Service Interaction Indicator in Service Interaction Indicators Two from the ISUP Initial Address Message or previous CAMEL processing. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. 4.6.11 VMSC to GMSC information flows 4.6.11.1 Resume Call Handling 4.6.11.1.1 Description This IF is described in 3GPP TSÊ23.079Ê[19], it is used to request the GMSC to take over handling the call so that it can be forwarded from the GMSC. 4.6.11.1.2 Information Elements Resume Call Handling contains the following CAMEL specific information elements: Information element name Status Description O CSI S This IE indicates that CAMEL handling applies for an optimally routed late forwarded call. This IE shall be present if CAMEL handling applies; otherwise it shall be absent. Trigger criteria for DPÊCollected_Information, if present, shall be omitted from this IF. Trigger criteria for DPÊRoute_Select_Failure, if present, shall be included in this IF. D CSI S This IE indicates that CAMEL handling applies for an optimally routed late forwarded call. This IE shall be present if CAMEL handling applies; otherwise it shall be absent. 4.6.12 MSC to VLR information flows 4.6.12.1 Send Info For ICA 4.6.12.1.1 Description This IF is used to request the VLR to provide information to handle an outgoing call leg created by the gsmSCF. 4.6.12.1.2 Information Elements Information element name NP Description Called Number M This IE indicates the E.164 number of the call leg destination. IMSI M This IE is the IMSI of the served CAMEL subscriber. CUG Index C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress Preferential CUG C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress CUG Outgoing Access C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress Outgoing Call Barring C This IE indicates that outgoing call barrings shall be suppressed for the call leg. Suppress D CSI S This IE indicates that D CSI shall be suppressed. It shall always be present in the second interrogation. N CSI Available S This IE indicates that N CSI is available in MSC. It shall be present in the first interrogation if N CSI is available in the MSC. Non CUG Call S This IE indicates that no parameters for CUG should be used for the call. It shall be present if received from gsmSCF. CUG Interlock Code S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if received from gsmSCF. Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if received from gsmSCF. 4.6.12.2 Send Info For Incoming Call 4.6.12.2.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request the VLR to provide information to handle an incoming call. 4.6.12.2.2 Information Elements Send Info For Incoming Call contains the following CAMEL specific information elements: Information element name Status Description Suppress VT CSI S This IE indicates that VT CSI shall be suppressed. It shall never be present in the first interrogation; it shall always be present in the second interrogation. Call Diversion Treatment Indicator S This IE indicates whether or not the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. It shall be present if received within the Forward Service Interaction Indicator in the Service Interaction Indicators Two from the IAM or previous CAMEL processing. 4.6.12.3 Send Info For MT Reconnected Call 4.6.12.3.1 Description This IF is used to request the VLR to provide information to handle a reconnected MT call. 4.6.12.3.2 Information Elements Information element name Required Description Called Number M E.164 number of the call destination. 4.6.12.4 Send Info For Outgoing Call 4.6.12.4.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request the VLR to provide information to handle an outgoing call. 4.6.12.4.2 Information Elements Send Info For Outgoing Call contains the following CAMEL specific information elements: Information element name Status Description Suppress O CSI S This IE indicates that O CSI shall be suppressed. It shall always be present in the second interrogation. Suppress D CSI S This IE indicates that D CSI shall be suppressed. It shall always be present in the second interrogation. N CSI Available S This IE indicates that N CSI is available in MSC. It shall be present in the first interrogation if N CSI is available in the MSC. 4.6.12.5 Send Info For Reconnected Call 4.6.12.5.1 Description This IF is used to request the VLR to provide information to handle a reconnected MO call. 4.6.12.5.2 Information Elements Information element name Status Description Called Number M This IE indicates the E.164 number of the call destination. Bearer Service S,E This IE indicates the bearer service required for the MO call, derived from the CS bearer capability information received in the setup request from the MS. One of bearer service or teleservice shall be present. Teleservice S,E This IE indicates the teleservice required for the MO call, derived from the CS bearer capability information received in the setup request from the MS or from the emergency setup request from the MS. One of bearer service or teleservice shall be present. CUG Index S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress Preferential CUG S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress CUG Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress O CSI S This IE indicates that O CSI shall be suppressed. It shall always be present in the second interrogation. 4.6.13 VLR to MSC information flows 4.6.13.1 Complete Call 4.6.13.1.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to instruct the MSC to continue the connection of a call. 4.6.13.1.2 Information Elements Complete Call contains the following CAMEL specific information elements: Information element name MO MF MT VT NC NP Description O CSI S - - - - - This IE indicates that CAMEL handling applies for an MO call. It shall be present in the response to the first interrogation for an MO call if CAMEL handling applies; otherwise it shall be absent. It shall be absent from the response to the second interrogation for an MO call. D CSI C - - - - C This IE identifies the subscriber as having originating CAMEL dialled services. Call Reference Number - - - M - - This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address - - - M - - This IE is the E.164 address of the GMSC. 4.6.13.2 Continue CAMEL Handling 4.6.13.2.1 Description This IF is used to instruct the MSC to continue the CAMEL specific handling. 4.6.13.2.2 Information Elements Information element name Status Description VT CSI M This IE identifies the subscriber as having terminating CAMEL services in the VMSC. IMSI M This IE contains the IMSI of the B subscriber. MSISDN S This IE contains the E.164 number of the B subscriber. It will be used to create the redirecting number presented to the C subscriber. It shall be present if the call is to be forwarded or if it has been provided by the HLR in the Provide Roaming Number IF, otherwise it shall be absent. CUG Interlock S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if the VLR has determined that the forwarded call is to be treated as a CUG call in accordance with the rules in 3GPP TSÊ23.085Ê[22], otherwise it shall be absent. CUG Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if the VLR has determined that the forwarded call is to be treated as a CUG call with outgoing access in accordance with the rules in 3GPP TSÊ23.085Ê[22], otherwise it shall be absent. Location Information S This IE contains the information to define the location of the MS: see definition in 3GPP TSÊ23.018Ê[12]. It shall be present if location information was requested and is available; otherwise it shall be absent. GMSC-Address M This IE is the E.164 address of the GMSC which was received in the Provide Roaming Number. Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. ExtBasic Service Code M This IE indicates the type of basic service, i.e. teleservice or bearer service. Subscriber State M This IE indicates the status of the MS. The states are: - CAMELBusy: The MS is engaged on a transaction for a mobile originating or terminated circuit-switched call. - NetworkDeterminedNotReachable: The network can determine from its internal data that the MS is not reachable. - AssumedIdle: The state of the MS is neither ""CAMELBusy"" nor ""NetworkDeterminedNotReachable"". 4.6.13.3 Process Call Waiting 4.6.13.3.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to instruct the MSC to continue the connection of a waiting call. 4.6.13.3.2 Information Elements Process Call Waiting contains the following CAMEL specific information elements: Information element name Status Description Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address M This IE is the E.164 address of the GMSC. 4.6.13.4 Send Info For ICA negative response 4.6.13.4.1 Description This IF is used to indicate that the outgoing call leg for which the MSC requested subscription information shall not be connected. 4.6.13.4.2 Information Elements The negative response information elements can take the following values: - Bearer service not provisioned; - Call barred (Operator determined barring); - Call barred (Supplementary service barring); - CUG reject (Inconsistent access information - index incompatible with basic service); - CUG reject (Inconsistent access information - no CUG selected); - CUG reject (Outgoing calls barred within the CUG); - CUG reject (Unknown CUG index); - Teleservice not provisioned. 4.6.13.5 Send Info For Incoming Call ack 4.6.13.5.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to indicate that the incoming call for which the MSC requested subscription information shall be forwarded. 4.6.13.5.1 Information Elements Send Info For Incoming Call ack contains the following CAMEL specific information elements: Information element name Status Description O CSI S This IE indicates that originating CAMEL service handling applies for a forwarded call. It shall be present if originating CAMEL service handling applies; otherwise it shall be absent. D CSI S This IE indicates that originating CAMEL dialled service handling applies for a forwarded call. It shall be present if originating CAMEL dialled service handling applies; otherwise it shall be absent. Suppression Of Announcement S This IE indicates that announcements or tones generated when the call is forwarded shall be suppressed. It shall be present if it was received in the Provide Roaming Number for this call. Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address M This IE is the E.164 address of the GMSC. Supported CAMEL Phases S This IE lists the supported CAMEL phases in the GMSC. It shall be present if the VLR received it from the HLR in the Provide Roaming Number. 4.6.13.6 Send Info For Incoming Call negative response 4.6.13.6.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to indicate that the incoming call for which the MSC requested subscription information shall not be connected. 4.6.13.6.2 Information Elements Send Info For Incoming Call negative response contains the following CAMEL specific information element which may be attached as an IE to any of the negative response values defined in 3GPP TSÊ23.018Ê[12]: Information element name Status Description Suppression Of Announcement S This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. It shall be present if it was received in the Provide Roaming Number for this call. 4.6.13.7 Send Info For MT Reconnected Call ack 4.6.13.7.1 Description This IF is used to instruct the MSC to continue the connection of a reconnected MT call. 4.6.13.7.2 Information Elements Information element name Required Description O CSI S This IE indicates that originating CAMEL service handling applies for the reconnected call. It shall be present if originating CAMEL service handling applies; otherwise it shall be absent. D CSI S This IE indicates that originating CAMEL dialled service handling applies for the reconnected call. It shall be present if originating CAMEL dialled service handling applies; otherwise it shall be absent. 4.6.13.8 Send Info For MT Reconnected Call negative response 4.6.13.8.1 Description This IF is used to indicate that the reconnected MT call for which the MSC requested subscription information shall not be connected. 4.6.13.8.2 Information Elements The negative response information element can take the following value: - CUG reject 4.6.13.9 Send Info For Reconnected Call ack 4.6.13.9.1 Description This IF is used to instruct the MSC to continue the connection of a reconnected MO call. 4.6.13.9.2 Information Elements Send Info For Reconnected Call ack does not contain any information elements. 4.6.13.10 Send Info For Reconnected Call negative response 4.6.13.10.1 Description This IF is used to indicate that the reconnected MO call for which the MSC requested subscription information shall not be connected. 4.6.13.10.2 Information Elements The negative response information element can take the following value: - Call barred (Operator determined barring); - Call barred (Supplementary service barring). 4.6.14 Internal MSC information flows 4.6.14.1 Perform Call Forwarding ack 4.6.14.1.1 Description This IF is defined in 3GPP TSÊ23.018Ê[12]; it is used to inform the MSC that Call Forwarding is taking place. 4.6.14.1.2 Information Elements Perform Call Forwarding ack is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Forwarded-to Number M If the Forwarded-to Number is not available due to CAMEL handling (a Disconnect Leg IF has been received for Leg 2), then the MSC shall populate this parameter with a dummy number. 4.6.15 gsmSCF to HLR information flows 4.6.15.1 Send Routeing Info 4.6.15.1.1 Description This IF is defined in 3GPP TSÊ23.018Ê[12] and subclauseÊ4.6.10.1; it is used to request information from the HLR to route a gsmSCF initiated call. Refer to 3GPP TSÊ29.007Ê[35] for the usage of ISDN BC, ISDN LLC, ISDN HLC and MSISDN for the selection of the PLMN Basic Service. 4.6.15.1.2 Information Elements Send Routeing Info from the gsmSCF contains the following information elements: Information element name Status Description MSISDN M This IE indicates the MSISDN of the called subscriber. Alerting Pattern O This IE indicates the kind of Alerting Pattern to be applied. CUG Interlock O For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. CUG Outgoing Access O For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppression Of Announcement O This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Suppress T CSI M This IE indicates that CAMEL subscription information should not be returned in the first Send Routeing Info ack (to avoid the need for a second interrogation). Supported CAMEL Phases M This IE indicates the CAMEL Phases supported by the gsmSCF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered by the gsmSCF. This IE shall be present when the Supported CAMEL Phases IE indicates support of CAMEL PhaseÊ4. This IE is described in a table below. Call Reference Number M This IE carries the Call Reference Number allocated for the call by the gsmSCF. GMSC Or gsmSCF Address M This IE is the E.164 address of the gsmSCF. Call Diversion Treatment Indicator O This IE indicates whether or not the call is allowed to be forwarded on behalf of the called party using the Call Forwarding supplementary service. Pre-paging Supported S This IE shall be present if the gsmSCF supports pre-paging, otherwise it shall be absent. Interrogation Type M This IE shall contain the value ""Basic Call"". Long FTN Supported O This IE indicates that the gsmSCF supports Long Forwarded to Numbers. gsmSCF Initiated Call M This IE indicates that the IF was originated by a gsmSCF. Suppress Incoming Call Barring O This IE indicates that Incoming Call Barrings shall be suppressed for the called party. Suppress VT CSI O This IE indicates that VT CSI shall be suppressed. ISDN BC O ISDN bearer capability. See 3GPP TSÊ23.018Ê[12]. ISDN LLC O ISDN lower layer compatibility. See 3GPP TSÊ23.018Ê[12]. ISDN HLC O ISDN higher layer compatibility. See 3GPP TSÊ23.018Ê[12]. Suppress MT SS O This IE indicates the MT supplementary services that shall be suppressed for the called party. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. 4.6.16 HLR to gsmSCF information flows 4.6.16.1 Send Routeing Info ack 4.6.16.1.1 Description This IF is described in subclauseÊ4.6.9.1; it is used by the HLR to transfer the requested routeing information to the gsmSCF. 4.6.16.2 Send Routeing Info negative response 4.6.16.2.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to indicate that the routeing information is not available. 4.7 Interaction with supplementary services When the gsmSCF initiates a call to a subscriber, the gsmSCF can indicate to the HLR the MT supplementary services that shall be suppressed for this call. 4.7.1 Line identification For a call subject to CAMEL control, the gsmSCF shall have the option to send the Calling Party Restriction Indicator to the gsmSSF. This information element will be sent to the MSC and shall indicate whether the CLI Presentation Indicator present in the Calling Party Number shall be set by CAMEL action to Restricted. 4.7.2 Call forwarding services 4.7.2.1 Registration of Call Forwarding The functional behaviour for the registration of the Call Forwarding supplementary service is defined in 3GPP TSÊ23.082Ê[20]. The procedure specific to CAMEL is defined in this subclause: - CAMEL_Check_CF_Interaction. Figure 4.120-1: Procedure CAMEL_Check_CF_Interaction (sheet 1) 4.7.2.2 Invocation of Call Forwarding The functional behaviour for the invocation of the Call Forwarding supplementary service is defined in 3GPP TSÊ23.018Ê[12] and 3GPP TSÊ23.082Ê[20]. The following additional requirements apply. When Call Forwarding is invoked for a CAMEL subscriber with O CSI, the gsmSSF shall send the FTN to the gsmSCF in the format in which it was received from the HLR. When Call Forwarding is invoked for a CAMEL subscriber with D CSI or if an N CSI is present in the forwarding MSC, then the FTN shall be treated as defined in subclauseÊ4.2.1.2.2. If the Service Interaction Indicators Two parameter was included in the Initial Address Message, the Continue With Argument information flow or the Connect message, the appropriate indicator shall be applied for the forwarded call. An HLR shall not send an FTN which is not in international format to a GMSC which does not support CAMEL phaseÊ2, i.e. if the HLR is handling a request from a GMSC for routeing information and the forwarded-to number is registered in a format other than international, the service logic in the HLR shall behave as if the call forwarding is provisioned but not registered. 4.7.2.3 Invocation of Call Deflection The functional behaviour for the invocation of the Call Deflection supplementary service is defined in 3GPP TSÊ23.018Ê[12] and 3GPP TSÊ23.072Ê[16]. The following additional requirements apply. When Call Deflection is invoked by a CAMEL subscriber with O CSI, the gsmSSF shall send the DTN to the gsmSCF in the format in which it was received from the MS. When Call Deflection is invoked by a CAMEL subscriber with D CSI or if a N CSI is present in the VMSC, then the DTN shall be treated as defined in subclauseÊ4.2.1.2.2. If the Service Interaction Indicators Two parameter was included in the Initial Address Message, the Continue With Argument information flow or the Connect information flow, the appropriate indicator shall be applied for the deflected call. 4.7.3 Call Barring services When a CAMEL subscriber with O CSI and TIF CSI attempts to activate a conditional call barring service (BOIC,BOIC-exHC), the HLR shall not check the interactions with call forwarding."
"When the gsmSCF initiates a call to a subscriber, the gsmSCF can indicate to the HLR that incoming call barrings shall be suppressed for this call. When the gsmSCF creates an additional call leg in an existing call, the gsmSCF can indicate to the VLR (via the gsmSSF and MSC) that outgoing call barrings shall be suppressed for this call leg. 4.7.4 Closed User Group For a CUG subscriber with CAMEL services: - The HLR shall store (and transfer to the VLR) the necessary subscriber data to ensure that the served subscriber is not unnecessarily prevented by CUG constraints from originating calls. - The HLR shall store the necessary subscriber data to ensure that the served subscriber is not unnecessarily prevented by CUG constraints from receiving calls. For an MO, MF or TO call, the CUG information for that call shall be sent to the gsmSCF in the Initial DP information flow. If the gsmSCF returns a Continue information flow, the call shall continue with the original CUG information unchanged. If the gsmSCF returns a Connect or Continue With Argument information flow, the CUG handling in table 4.7 applies. Table 4.7: CUG handling on receipt of Connect or Continue With Argument for an MO, MF or TO call CUG parameters in information flow Handling Non-CUG call (note 1) Remove CUG information for the call and continue as a non-CUG call CUG information (note 2) Call shall continue with modified CUG information No CUG information Call shall continue with original CUG information NOTE 1: Received in Service Interaction Indicators Two IE. NOTE 2: CUG information consists of at least one of CUG Interlock Code and Outgoing Access Indicator. For an MT call which is to be routed to the terminating subscriber, the CUG information shall be extracted from the Send Routeing Information ack and sent to the gsmSCF in the Initial DP, but the gsmSCF shall not have the ability to change the CUG information for the call. For an VT call which is to be routed to the terminating subscriber, the CUG information shall be extracted from the incoming ISUP IAM and sent to the gsmSCF in the Initial DP, but the gsmSCF shall not have the ability to change the CUG information for the call. For an MT or VT call which is subject to CAMEL forwarding, the gsmSCF shall return a Connect information flow and the CUG handling in table 4.7 applies. 5 USSD to/from gsmSCF 5.1 Architecture 5.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support CAMEL handling of USSD to/from gsmSCF. The functional model of USSD in an HLR that supports CAMEL is shown in figureÊ5.1. The phaseÊ2 USSD handler is defined in 3GPP TSÊ23.090Ê[24]. PhaseÊ1 USSD information flows may be relayed from the HLR to the gsmSCF. CAMEL introduces a ""CAMEL USSD application"" which is invoked by the USSD handler. The CAMEL USSD functional entities and application behaviour is specified in this subclause. Figure 5.1: Handling of USSD to and from a CAMEL subscriber HLR: The HLR stores for subscribers requiring CAMEL support the information relevant to the current subscription regarding U CSI. The UG CSI is stored as global data applicable to all subscribers. The U CSI and the UG CSI are stored in the HLR only. gsmSCF: see subclauseÊ3.1. 5.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 5.1.2.1 gsmSCF - HLR interface This interface is used for USSD information flows, both for gsmSCF-initiated dialogues and MS-initiated dialogues (relayed via HLR). It is a network operator option whether to support or not USSD information flows on this interface. 5.2 Description of CAMEL Subscriber Data 5.2.1 USSD CAMEL Subscription Information (U CSI) The subscription information specified in this subclause is for information only. This subclause defines the contents of the USSD CAMEL Subscription Information (U CSI). The U CSI consists of a list of pairs of the following two parameters. 5.2.1.1 Service Code Service code for a specific application in a gsmSCF which interacts with the user by USSD. 5.2.1.2 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber and a particular service code. The address shall be an E.164 number to be used for routeing. 5.3 Content of the USSD General CAMEL Service Information (UG CSI) The service information specified in this subclause is for information only. This subclause defines the contents of the USSD General CAMEL Service Information (UG CSI). The allocation of the UG CSI is independent from a particular subscriber. The UG CSI consists of a list of pairs of the following two parameters. 5.3.1 Service Code Service code for a specific application in a gsmSCF which interacts with the user by USSD. 5.3.2 gsmSCF address Address to be used to access the gsmSCF for a particular service code. The address shall be an E.164 number to be used for routeing. 5.4 Procedures 5.4.1 MS Initiated USSD For the behaviour of the USSD handler in HLR when receiving a MS initiated USSD see 3GPP TSÊ23.090Ê[24]. When the USSD handler has determined that the service code present in the received USSD does not indicate that an USSD application in the HLR shall be invoked it shall route the USSD to the USSD application specific for CAMEL, i.e. the CAMEL USSD application. The procedure at the CAMEL USSD application at the HLR is implementation dependent. The following text describes a recommended procedure. The CAMEL USSD application shall check the U CSI data assigned to the specific subscriber. If the service code is present in the U CSI the USSD is routed to the gsmSCF given by the gsmSCF address stored against the service code in the U CSI. If the service code is not present in the U CSI (or the subscriber does not have U CSI defined) then the CAMEL USSD application shall check the UG CSI data assigned to the HLR. If the service code is present in the UG CSI then the USSD is routed to the gsmSCF given by the gsmSCF address stored against the service code in the UG CSI. If the service code is not present in U CSI or UG CSI an error (unknown application) is returned to the USSD handler. 5.4.2 gsmSCF Initiated USSD The HLR may at any time receive a USSD information flow from the gsmSCF. If the subscriber can be contacted, the HLR shall set up a transaction to the VLR and forward the information flow unchanged. Any further information exchange between the gsmSCF and MSC shall be transparent to the VLR and the HLR. When one transaction is released, the HLR shall release the other. If an error is received from the MSC, the VLR shall release the transaction to the HLR and the HLR shall release the transaction to the gsmSCF. 5.5 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for USSD handling. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The HLR shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.002Ê[34]. 5.5.1 gsmSCF to HLR information flows 5.5.1.1 Unstructured SS Request 5.5.1.1.1 Description This IF is used for the gsmSCF to request data from the MS via the HLR. 5.5.1.1.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the MS. Data Coding Scheme M This IE indicates the characteristics of the USSD string. IMSI S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. MSISDN S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. Alerting Pattern O This IE indicates an alerting pattern to be sent to the MS. 5.5.1.2 Unstructured SS Notify 5.5.1.2.1 Description This IF is used for the gsmSCF to send data to the MS via the HLR. 5.5.1.2.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the MS. Data Coding Scheme M This IE indicates the characteristics of the USSD string. IMSI S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. MSISDN S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. Alerting Pattern O This IE indicates an alerting pattern to be sent to the MS. 5.5.1.3 Process Unstructured SS Data ack 5.5.1.3.1 Description This IF is used for the gsmSCF to send the response to the MS via the HLR for the MS initiated IF. 5.5.1.3.2 Information Elements The following information element is required: Information element name Status Description SS User Data C This IE contains the string that will be sent to the MS. 5.5.1.4 Process Unstructured SS Request ack 5.5.1.4.1 Description This IF is used for the gsmSCF to send the response to the MS via the HLR for the MS initiated IF. 5.5.1.4.2 Information Elements Information element name Status Description USSD String S This IE contains the string that will be sent to the MS. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. Data Coding Scheme S This IE indicates the characteristics of the USSD string. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. 5.5.2 HLR to gsmSCF information flows 5.5.2.1 Unstructured SS Request ack 5.5.2.1.1 Description This IF is used for the MS to send to the gsmSCF via the HLR for the gsmSCF initiated IF. 5.5.2.1.2 Information Elements Information element name Status Description USSD String C This IE contains the string that will be sent to the gsmSCF. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. Data Coding Scheme C This IE indicates the characteristics of the USSD string. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. 5.5.2.2 Unstructured SS Notify ack 5.5.2.2.1 Description This IF is used for the MS to via the HLR acknowledge to the gsmSCF that the notification was received. 5.5.2.2.2 Information Elements This IE contains no information element. 5.5.2.3 Process Unstructured SS Data 5.5.2.3.1 Description This IF is used for the MS to request data from gsmSCF via the HLR. 5.5.2.3.2 Information Elements Information element name Status Description SS User Data M This IE contains the string that was received from the MS. 5.5.2.4 Process Unstructured SS Request 5.5.2.4.1 Description This IF is used for the MS to request data from the gsmSCF via the HLR. 5.5.2.4.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the gsmSCF, including the Service Code. Data Coding Scheme M This IE indicates the characteristics of the USSD string IMSI M This IE identifies the subscriber. MSISDN S This IE contains the basic MSISDN of the subscriber who has requested the USSD IF. This IE is used as an operator option. Originating Entity Number M This IE identifies the functional entity initiating the information flow. In this case, this shall be the address of the HLR. 5.5.2.5 Begin Subscriber Activity 5.5.2.5.1 Description This IF is used by the HLR to start subscriber activity towards the gsmSCF for USSD purposes. 5.5.2.5.2 Information Elements Information element name Status Description IMSI M This IE identifies the subscriber. Originating Entity Number M This IE identifies the functional entity initiating the subscriber activity. In this case, this shall be the address of the HLR. 6 GPRS interworking 6.1 Architecture 6.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support GPRS interworking for CAMEL. FigureÊ6.1 shows the functional entities involved in a GPRS session requiring CAMEL support. The architecture is applicable to the third phase of CAMEL or higher. Figure 6.1: Functional architecture for support of CAMEL HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription GPRS CSI. SGSN: When processing GPRS Attach requests or Inter-SGSN Routeing Area Updates for subscribers requiring CAMEL support, the SGSN receives a GPRS CSI from the HLR, indicating the SGSN to request instructions from the gprsSSF. The SGSN monitors on request the GPRS events and informs the gprsSSF of these events during processing, enabling the gprsSSF to control the execution of the GPRS session or individual PDP contexts in the SGSN. gprsSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. 6.1.2 Interfaces defined for CAMEL 6.1.2.1 SGSN - gprsSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 6.1.2.2 gprsSSF - gsmSCF interface This interface is used by the gsmSCF to control a GPRS session or individual PDP Context in a certain gprsSSF. GPRS dialogues between the gprsSSF and the gsmSCF on this interface are opened as a result of the gprsSSF sending a request for instructions to the gsmSCF. A GPRS dialogue is composed of a sequence of TC dialogues linked together by the same reference. The GPRS dialogue handler allows the TC dialogue handling. 6.1.2.3 HLR - SGSN interface This interface is used to send CAMEL related subscriber data to a visited GPRS network, e.g. GPRS CSI. 6.2 Detection Points (DPs) 6.2.1 Definition and description GPRS events may be made visible to the gsmSCF. The DPs are the points in association at which these events are detected. The DPs for GPRS Session and PDP Context are described in subclauseÊ6.4.2 and subclauseÊ6.4.3. A DP can be armed in order to notify the gsmSCF that the GPRS event was encountered, and to allow the gsmSCF to influence subsequent handling of the GPRS Session, or the PDP Context. If the DP is not armed, the processing entity continues the processing without gsmSCF involvement at this DP. Three different types of DPs are identified: - Trigger Detection Point-Request (TDP R): This detection point is statically armed and may initiate a CAMEL control relationship. This CAMEL control relationship is within a new GPRS dialogue. When the GPRS event is encountered and reported, processing is suspended. - Event Detection Point- Request (EDP R): This detection point is dynamically armed within the context of a CAMEL control relationship. When the GPRS event is encountered, and reported, processing is suspended and the gprsSSF waits for instructions from the gsmSCF. - Event Detection Point-Notification (EDP N): This detection point is dynamically armed within the context of a CAMEL control relationship. When the GPRS event is encountered and reported, processing is not suspended. Arming/disarming mechanism: A DP may be statically armed or dynamically armed. The following arming rules apply: - DPs for GPRS Session and PDP Context are statically armed as a result of the GPRS CSI analysis in the SGSN. - DPs may be dynamically armed by the gsmSCF within the context of a CAMEL control relationship. In scenarioÊ1 which is described in the subclauseÊ6.4.4.1, PDP context related DPs may be armed as generic DP or as non-generic DP. The following disarming rules apply: - A statically armed DP is disarmed when the GPRS CSI is withdrawn in the HLR. Only TDP Rs can be disarmed using this mechanism. - If the GPRS Session is released, then all EDPs related to the GPRS Session are disarmed. - If a PDP context is released, then all non-generically armed EDPs related to that PDP context are disarmed. - If a non-generically armed EDP is met, then EDPs for the GPRS Session or that PDP Context are disarmed, in accordance with the implicit disarming rule (see subclauseÊ6.4.6). - Armed EDPs may be explicitly disarmed by the gsmSCF by means of the Request Report BCSM Event information flow. 6.2.2 Relationship, DP processing rules and GPRS dialogue A relationship between the State Models (in the gprsSSF) and the gsmSCF for the purpose of operator specific service processing is considered to be a CAMEL relationship. There are two types of CAMEL relationships: monitor relationship and control relationship. - A CAMEL control relationship: the gsmSCF is able to influence the GPRS Session/PDP Context via the relationship for the given state model. - A CAMEL monitor relationship: the gsmSCF is not able to influence the GPRS Session/PDP Context via the relationship for the given state model. A control relationship persists as long as there is one or more EDP R armed for this instance of the state model, or if the gprsSSF is in the state Waiting For Instruction for this instance of state model. A control relationship changes to a monitor relationship if the conditions for a control relationship are no longer fulfilled and one or more EDP N is armed or one or more Apply Charging Report GPRS is outstanding for this instance of the state model. If no EDP Ns are armed and no Apply Charging Reports GPRS are outstanding for this instance of the state model, the relationship terminates. A GPRS dialogue exists between gprsSSF and gsmSCF if at least one of the following conditions is fulfilled: - There is at least one EDP armed, - At least one report is pending, - gprsSSF is in state Waiting_For_Instructions. 6.3 Description of CAMEL Subscriber Data 6.3.1 GPRS CAMEL Subscription Information (GPRS CSI) This subclause defines the contents of the GPRS CAMEL Subscription Information. 6.3.1.1 gsmSCF Address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 6.3.1.2 Service Key The Service Key identifies to the gsmSCF the service logic that shall apply. 6.3.1.3 Default GPRS Handling The Default GPRS Handling indicates whether the GPRS session or PDP context shall be released or continued as requested in case of error in the gprsSSF to gsmSCF dialogue. 6.3.1.4 TDP List The TDP List indicates on which detection point triggering shall take place. 6.3.1.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. 6.3.1.6 CSI state The CSI state indicates whether the GPRS CSI is active or not. 6.3.1.7 Notification flag The notification flag indicates whether the change of the GPRS CSI shall trigger Notification on Change of Subscriber Data or not. 6.3.2 gsmSCF address list for CSI The gsmSCF address list contains a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 6.4 Description of CAMEL State Models GPRS can support multiple PDP contexts simultaneously for an attached subscriber, requiring the behaviour of a GPRS session to be modelled by two state models, one for the attach/detach procedures (GPRS Attach/Detach State Model) and the other for modelling individual PDP Contexts (GPRS PDP Context State Model). 6.4.1 General Handling The GPRS State Model is used to describe the actions in an SGSN during processing of a GPRS session or PDP Contexts. The GPRS State Model identifies the points in basic GPRS processing when Operator Specific Service (OSS) logic instances (accessed through the gsmSCF) are permitted to interact with basic GPRS control capabilities. FigureÊ6.2shows the components that have been identified to describe a GPRS State Model. Figure 6.2: GPRS State Model Components 6.4.2 GPRS Attach/Detach State Model The GPRS Attach/Detach State Model is used to model the behaviour of the GPRS attach/detach procedures. When encountering a DP the Attach/Detach State Model processing is suspended at the DP and the SGSN indicates this to the gprsSSF which determines what action, if any, shall be taken in case the DP is armed. Figure 6.3: GPRS Attach/Detach State Model Table 6.1: Description of GPRS Attach/Detach DPs in the SGSN CAMEL Detection Point DP Type Description DP Attach TDP R A request to attach is received. DP Change of Position GPRS Session TDP R1), EDP N Routeing Area Update is accepted. DP Detach EDP N, EDP R A detach request is received either from the MS, the SGSN or a 'Cancel Location' received from HLR or Inter SGSN Routeing update occurred in the old SGSN. Note 1: Change of Position GPRS Session is reported as TDP R in the case of Inter SGSN Routeing Area Update (provided that this DP is statically armed in GPRS CSI). Change of Position GPRS Session is reported as EDP N in the case of Intra SGSN Routeing Area Update (provided that this DP is dynamically armed by the Service Logic). 6.4.2.1 Description of the Attach/Detach model (PIAs) This subclause describes the model for the attach and detach a GPRS session in the SGSN. For each PIA a description can be found of the entry events, actions and exit events. 6.4.2.1.1 Detached Entry events: - Detach (user or network initiated) and clearing of a previous GPRS session. - Processing of exceptional conditions. Actions: - Interface is idled. - Attach request is received from MS containing the IMSI/P-TMSI and the type of attach requested and, the identity of the MS is established (IMSI) (DP Attach), or Inter-SGSN Routeing Area Update Request is accepted (DP Change of Position GPRS Session). - Information being analyzed, e.g. GPRS CSI is analyzed. Exit events: - GPRS CSI is analyzed (DP Attach or DP Change of Position GPRS Session). 6.4.2.1.2 Attached Entry events: - GPRS CSI is analyzed (DP Attach). Actions: - MM contexts are established at the MS and the SGSN. Exit events: - A GPRS Detach request is received from the MS or from the network (DP Detach). - Intra-SGSN Routeing Area Update is accepted (DP Change of Position GPRS Session). - An exception is encountered. The GPRS Attach/Detach State Model shall only have one or more GPRS PDP Context State Models associated with it when in the Attached state. A GPRS PDP Context State Model cannot exist without its associated GPRS Attach/Detach State Model being in the Attached state. Closure of the GPRS Attach/Detach State Model via a detach will result in the idling of all associated GPRS PDP Context State Models and the release of the associated GPRS PDP Contexts. It shall not be necessary to trigger a relationship from the GPRS Attach/Detach State Model to the gsmSCF in order for triggering to occur in an associated GPRS PDP Context State Model. However, in this latter case a GPRS Attach/Detach State Model shall still exist at the SGSN. This is so that CSE-initiated detach events sent within a given GPRS PDP Context relationship shall result in the GPRS Attach/Detach State Model transiting to the Detached state. As noted above, in this state no PDP Contexts can exist and so all associated GPRS PDP Context State Models will transit to state Idle. 6.4.3 GPRS PDP Context State Model The GPRS PDP Context State Model is used to model the behaviour for the GPRS PDP Context procedures. There is one PDP Context State Model per GPRS PDP context. When encountering a DP the PDP Context State Model processing is suspended at the DP and the SGSN indicates this to the gprsSSF which determines what action, if any, shall be taken in case the DP is armed. Figure 6.4: GPRS PDP Context State Model Table 6.2: Description of GPRS PDP Context DPs in the SGSN CAMEL Detection Point DP Type Description DP PDP Context Establishment TDP R1), EDP R, EDP N Activate PDP Context request is received from the MS. DP PDP Context Establishment Acknowledgement TDP R2), EDP R, EDP N Create PDP Context response is received from the GGSN. DP PDP Context Disconnection EDP N, EDP R Deactivate PDP Context Request is received from the MS, Delete PDP Context request is received from the GGSN. Inter SGSN Routeing update occurred in old SGSN. DP Change of Position Context TDP R3), EDP N, EDP R Routeing Area Update is accepted. NOTE 1: The PDP Context Establishment shall be reported as TDP R (provided that this DP is statically armed in GPRS CSI) if there is no relationship with the gsmSCF. If there is a relationship with the gsmSCF it shall be reported as EDP R or EDP N if armed so. NOTE 2: The PDP Context Establishment Acknowledgement shall be reported as TDP R (provided that this DP is statically armed in GPRS CSI) if there is no relationship with gsmSCF. If there is a relationship with the gsmSCF, it shall be reported as EDP R or EDP N if armed so. NOTE 3: Change of Position Context is reported as TDP-R in the case of Inter-SGSN Routeing Area Update (provided that this DP is statically armed in GPRS CSI) if there is no relationship with the gsmSCF. Change of Position Context is reported as EDP N or EDP R in the case of Inter-SGSN Routeing Area Update (provided that this DP is armed as generic EDP) if there is a relationship with the gsmSCF. Change of Position Context is reported as EDP N in the case of Intra-SGSN Routeing Area Update (provided that this DP is dynamically armed by the Service Logic). 6.4.3.1 Description of the PDP Context model (PIAs) This subclause describes the model for PDP Context State Model in the SGSN. For each PIA a description can be found of the entry events, actions and exit events. 6.4.3.1.1 Idle Entry events: - Deactivation (user or network initiated) and clearing of a previous PDP Context. - Processing of exceptional conditions. Actions: - Interface is idled. - Activate PDP Context request is received from MS (containing NSAPI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options), or Inter-SGSN Routeing Area Update is accepted (DP Change of Position Context). - Information being analyzed, e.g. GPRS CSI is analyzed. Exit events: - GPRS CSI is analyzed (DP PDP Context Establishment or DP Change of Position Context, new SGSN). 6.4.3.1.2 PDP Context Setup Entry events: - GPRS CSI is analyzed (DP PDP Context Establishment). Actions: - APN and GGSN selection procedure is performed for a primary PDP context as specified in Annex A of 3GPP TSÊ23.060Ê[15]. APN and GGSN selection procedure is not performed for a secondary PDP context. - Access Point Name is verified against the subscription. If the gsmSCF has provided an Access Point Name then the Access Point Name provided by the gsmSCF is checked against the subscription. For details refer to 3GPP TSÊ23.060Ê[15] Annex A. - The operator determined barring category ""Barring of all Packet Oriented Services "" is checked and invoked if necessary. - The operator determined barring category ""Barring of Packet Oriented Services from access points that are within the HPLMN whilst the subscriber is roaming in a VPLMN"" is checked and invoked if necessary. - The operator determined barring category ""Barring of Packet Oriented Services from access points that are within the roamed to VPLMN"" is checked and invoked if necessary. - The SGSN ensures that an already active PDP context is not reactivated. - GGSN address is derived from the Access Point Name by interrogation of a DNS. The Access Point Name consists of a Network Identifier and an Operator Identifier. - Create PDP Context Request is sent to the GGSN. Exit events: - Create PDP Context Response is received from the GGSN (DP PDP Context Establishment Acknowledgement). - An exception is encountered. 6.4.3.1.3 PDP Context Established Entry events: - GPRS CSI is analyzed (DP PDP Context Establishment Acknowledgement or DP Change of Position Context). Actions: - PDP context is established at the MS and the SGSN. Exit events: - Deactivation of the PDP Context is received from the MS or the GGSN, or is due to an inter SGSN routing area update (DP PDP Context Disconnection, old SGSN). - Intra-SGSN Routeing Area Update Request is received from the MS (DP Change of Position Context). - Inter-SGSN Routeing Area Update (DP Change of Position Context, new SGSN). - An exception is encountered. 6.4.3.1.4 Change of Position Context Entry events: - Inter SGSN Routing Area update accepted (new SGSN). - Intra SGSN Routeing Area update request received from the MS. Actions: - PDP Context (containing NSAPI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) is reestablished in case of Inter-SGSN Routeing Area update accepted (new SGSN). - Intra SGSN Routeing Area updated. Exit events: - reestablishement of the PDP context at the new SGSN and return to PDP context established in case of inter SGSN Routeing Area update accepted in new SGSN (PIA PDP context established). - Routeing Area update completed in case of intra SGSN Routeing Area update (PIA PDP context established). 6.4.4 GPRS CAMEL Scenarios Two different scenarios are applicable for CAMEL control of GPRS. Scenario 1: Scenario 1 allows CAMEL control of the GPRS session and of multiple PDP contexts related to this session within a single GPRS dialogue. Scenario 2: Scenario 2 allows CAMEL control of single PDP contexts. Multiple PDP contexts are controlled in this scenario via multiple GPRS dialogues. ScenarioÊ1 and scenarioÊ2 are mutually exclusive, i.e. it is not possible to use both for one GPRS session at the same time in one SGSN. A GPRS session is involved in GPRS CAMEL at one moment in time either by using scenarioÊ1 or by using possible multiple instances of scenarioÊ2. GPRS sessions in different SGSNs are independent from a CAMEL perspective. 6.4.4.1 GPRS CAMEL Scenario 1 ScenarioÊ1 allows CAMEL control of the GPRS session and of multiple PDP contexts related to this session within a single GPRS dialogue (Session dialogue). Figure 6.5: GPRS CAMEL Scenario 1 A GPRS dialogue in scenarioÊ1 always consists of one GPRS Attach/Detach State Model and optionally of additional multiple GPRS PDP Context State Models related to the Attach/Detach State Model for the GPRS session. There is at most one GPRS Attach/Detach State Model per non idle GPRS session in one SGSN and at most one PDP Context State Model per active GPRS PDP context in one SGSN. The various PDP Context State Models are treated independently of each other. The GPRS dialogue and the relationship between the GPRS Attach/Detach State Model and the gsmSCF are always initiated using the TDPs of the GPRS Attach/Detach State Model. The gsmSCf requests further control or monitoring of individual GPRS PDP contexts using the Request Report GPRS Event information flow. To be informed about new individual PDP contexts the gsmSCF arms the DP 'PDP Context Establishment' or the DP 'PDP Context Establishment Acknowledgement' generically, i.e. without a PDP ID, as an EDP. To be informed about the handed over PDP contexts the gsmSCF arms the DP 'Change of Position Context' generically as an EDP N or EDP R. Each GPRS PDP context is identified by a PDP ID. The PDP ID is assigned by the SGSN during PDP context establishment. The PDP ID is unique within one GPRS dialogue. The Request Report GPRS Event information flows to control new or handed over PDP contexts do not include a PDP ID. There is no 'PDP ID' related to the GPRS Attach/Detach State Model. The PDP Id is reported to the gsmSCF in the first event notification for that PDP context. 6.4.4.2 GPRS CAMEL Scenario 2 ScenarioÊ2 allows CAMEL control of single PDP contexts. Multiple PDP contexts are controlled in this scenario via multiple GPRS dialogues (PDP Context dialogues). Figure 6.6: GPRS CAMEL Scenario 2 A GPRS dialogue in scenarioÊ2 consists of a single GPRS PDP Context State Model. There is no GPRS Attach/Detach State Model involved in this scenario. There is at most one PDP Context State Model per active GPRS PDP context in one SGSN. There might be multiple GPRS dialogues in scenariosÊ2 for one GPRS session, each of the dialogues controlling a single GPRS PDP context. The various GPRS dialogues are independent of each other. The GPRS dialogue and the relationship between the GPRS PDP Context State Model and the gsmSCF are always initiated using the TDPs for the GPRS PDP Context State Model. Control of further individual GPRS PDP contexts in the same GPRS dialogue as in scenarioÊ1 is not possible. There are no PDP IDs in this scenario. 6.4.5 SGSN Routeing Area Update 6.4.5.1 Intra-SGSN Routeing Area Update Intra-SGSN Routeing Area Update will be detected via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and via the DPs 'Change of Position Context' for the individual PDP contexts using the GPRS PDP Context State Models. It will be reported via an EDP N if the necessary EDP N is armed. 6.4.5.2 Inter-SGSN Routeing Area Update Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. Scenario 1: Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected in the new SGSN via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and in the new SGSN via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. In this scenario the DP 'Change of Position GPRS Session' is armed as a TDP R. If the Routeing Area Update is accepted the gprsSSF reports this TDP R to the gsmSCF using the Initial DP GPRS information flow. To be informed about new PDP contexts the gsmSCF arms the DP 'PDP Context Establishment' or the DP 'PDP Context Establishment Acknowledgement' generically as EDP R or EDP N. The DPs 'Change of Position Context' for the PDP contexts which have been handed over will be reported with all necessary information to the gsmSCF when the gprsSSF is continued, i.e. it is not longer waiting for instructions. Contexts which are not continued in the new SGSN are not reported. The EDPs for new PDP contexts are reported as usual. The Detach in the old SGSN is reported to the gsmSCF, provided this event is armed. All outstanding reports in the old SGSN are sent to the gsmSCF and all open CDRs are closed. Scenario 2: Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected in the new SGSN via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. In this scenario the DP 'Change of Position Context' is armed as TDP R. If the Routeing Area Update is accepted the gprsSSF reports these TDP Rs PDP contexts which have been handed over to the gsmSCF using the Initial DP GPRS information flows in multiple GPRS dialogues. The PDP Context Disconnection in the old SGSN is reported to the gsmSCF, provided this event is armed. All outstanding reports in the old SGSN are sent to the gsmSCF and the open CDR is closed. 6.4.6 Rules for Implicit Disarming of Detection Points The two tables below give the rules for implicit disarming of event detection points. Implicit EDP disarming rules are specified for the Attach/Detach State Model and PDP Context State Model. The tables specify which EDP's shall be disarmed (i.e. MonitorMode set to Transparent) if/when each EDP is encountered, irrespective of the EDP's MonitorMode (Transparent, NotifyAndContinue, or Request). EDPs which are armed generically for GPRS PDP Context State Models shall only be implicitly disarmed at the end of the GPRS dialogue. Explicit disarming is possible."
"When EDP's are armed with MonitorMode 'Request' (EDP Rs) are encountered, any implicit EDP disarming shall take place before reporting the EDP and transiting the gprsSSF to the WFI state (if not already suspended in the WFI state). The table entry 'X' means that if one DP occurs (independently of arming and reporting to the gsmSCF) the marked one is implicitly disarmed. It shall be possible to rearm explicitly an implicitly disarmed DP. Table 6.3: Implicit disarming rules for Scenario 1 (the rules apply for non-generically armed DPs) Encountered DP Implicit disarmed DPs Change of Position GPRS Session Change of Position Context Detach PDP Context Establishment PDP Context Establishment Acknowledgement PDP Context Disconnection Change of Position GPRS Session Change of Position Context Detach X X X X X X PDP Context Establishment PDP Context Establishment Acknowledgement X PDP Context Disconnection X X X Table 6.4: Implicit disarming rules for Scenario 2 (the rules apply for non-generically armed DPs) Encountered DP Implicit disarmed DPs Change of Position Context PDP Context Establishment Acknowledgement PDP Context Disconnection PDP Context Establishment Acknowledgement X PDP Context Disconnection X X X Change of Position Context 6.5 Procedures for CAMEL GPRS 6.5.1 Overall SDL Architecture Figure 6.7: Architecture for CAMEL/GPRS interworking 6.5.2 Handling GPRS in the SGSN The functional behaviour of the SGSN is specified in 3GPP TSÊ23.060Ê[15]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_GPRS_Attach; - Procedure CAMEL_GPRS_Detach; - Procedure CAMEL_GPRS_Routeing_Area_Update_Session; - Procedure CAMEL_GPRS_Routeing_Area_Update_Context; - Procedure CAMEL_GPRS_PDP_Context_Establishment; - Procedure CAMEL_GPRS_Create_PDP_Context_Establishment_Acknowledgement; - Procedure CAMEL_GPRS_Change_Of_QoS; - Procedure CAMEL_GPRS_PDP_Context_Disconnection. 6.5.2.1 Actions of the SGSN on receipt of Int_Error The SGSN checks the default GPRS Handling parameter in GPRS CSI. If the default GPRS handling is release, a Detach indication is sent to the MS. The SGSN then releases all resources and the invoked CAMEL procedure ends. If the default GPRS handling is continue, the SGSN continues processing without CAMEL support. 6.5.2.2 Actions of the SGSN on receipt of Int_Continue The SGSN continues processing without any modification of GPRS parameters. 6.5.2.3 Handling of GPRS Attach/Detach Figure 6.8-1: Procedure CAMEL_GPRS_Attach (sheet 1) Figure 6.8-2: Procedure CAMEL_GPRS_Attach (sheet 2) Figure 6.9-1: Procedure CAMEL_GPRS_Detach (sheet 1) 6.5.2.4 Handling of GPRS Routeing Area Update Figure 6.10-1: Procedure CAMEL_GPRS_Routeing_Area_Update_Session (sheet 1) Figure 6.10-2: Procedure CAMEL_GPRS_Routeing_Area_Update_Session (sheet 2) Figure 6.11-1: Procedure CAMEL_GPRS_Routeing_Area_Update_Context (sheet 1) Figure 6.11-2: Procedure CAMEL_GPRS_Routeing_Area_Update_Context (sheet 2) 6.5.2.5 Handling of PDP Context establishment and deactivation Figure 6.12-1: Procedure CAMEL_GPRS_PDP_Context_Establishment (sheet 1) Figure 6.12-2: Procedure CAMEL_GPRS_PDP_Context_Establishment (sheet 2) Figure 6.13-1: Procedure CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement (sheet 1) Figure 6.13-2: Procedure CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement (sheet 2) Figure 6.14-1: Procedure CAMEL_GPRS_Change_Of_QoS (sheet 1) Figure 6.15-1: Procedure CAMEL_GPRS_PDP_Context_Disconnection (sheet 1) 6.5.3 Handling GPRS in the gprsSSF 6.5.3.1 Process GPRS_SSF A relationship exists between the gsmSCF and the Attach/Detach State Model and/or between the gsmSCF and every PDP Context State Model. The relationship may be in controlling or monitoring mode. When a Continue GPRS, Connect GPRS or Request Report GPRS Event information flow is received, then the relationship between the gsmSCF and the Attach/Detach State Model, and between the gsmSCF and a PDP Context State Model may be downgraded from controlling to monitoring. When Tssf expires, the CAMEL procedures that are waiting for an instruction from the gsmSCF shall receive an Int_Error signal. The Default GPRS Handling parameter determines the subsequent action of those CAMEL procedures. If the Default GPRS Handling parameter is set to 'Release', then: - if the GPRS Dialogue is controlling a GPRS Session, then the gprsSSF shall release the entire GPRS Session; - if the GPRS Dialogue is controlling a single PDP Context, then the gprsSSF shall release the PDP Context. The task box 'Open GPRS Dialogue' comprises all the tasks that are required for starting a GPRS dialogue. This includes, amongst others, the allocation of a GPRS Reference Number and the allocation of resources. The task box 'Terminate GPRS Dialogue' comprises all the tasks that are required for closing a GPRS dialogue. 6.5.3.2 Process GPRS_Dialogue_Handler When process gprsSSF sends a TC_End request primitive to process GPRS_Dialogue_Handler, then the corresponding TC_End TC Message shall be sent to the gsmSCF only when the following conditions have been fulfilled: - The gprsSSF has processed all information flows that the gprsSSF has received from the gsmSCF. - No information flows remain to be sent from the gprsSSF to the gsmSCF. - The gprsSSF is not waiting for a Result or Error component for any information flows that the gprsSSF has sent to the gsmSCF. 6.5.3.3 Procedure Handle_AC_GPRS Procedure Handle_AC_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Apply Charging GPRS procedure shall be executed for the Session - 'PDP Id'. The Apply Charging GPRS procedure shall be executed for the indicated PDP Context. SheetÊ3 in procedure Handle_AC_GPRS contains a check for the PDP Context duration (Tcp(PDP Id)) and PDP Context volume (Vc(PDP Id)). If the PDP Context delta timer (Dcp(PDP Id)) is equal to or larger than the duration threshold received in the Apply Charging GPRS operation or the PDP Context delta counter (Dc(PDP Id)) is equal to or larger than the volume threshold received in the Apply Charging GPRS operation, then the gprsSSF shall generate an internal signal to trigger the sending of an Apply Charging Report GPRS. If a QoS change has occurred prior to receiving Apply Charging GPRS but after the sending Apply Charging Report GPRS, then the gprsSSF shall generate an internal signal to trigger the sending of an Apply Charging Report GPRS, including the negotiated QoS. 6.5.3.4 Procedure Handle_ACR_GPRS Procedure Handle_ACR_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Apply Charging Report GPRS procedure shall be executed for the Session. This procedure checks if a Session Period report is pending and if so, sends this report to the gsmSCF. - 'PDP Id'. The Apply Charging Report GPRS procedure shall be executed for the indicated PDP Context. This procedure checks if a Context Volume report is pending and if so, sends this report to the gsmSCF. The procedure then checks if a Context Period is pending and if so, sends this report to the gsmSCF. - 'Session + PDPs'. The Apply Charging Report GPRS procedure shall be executed for the Session and all PDP Contexts. The sequence of checking the reports shall be as follows: 1) The procedure checks the pending Volume and Period reports for each PDP Context. 2) The procedure then checks the pending Period report for the Session. When a PDP Context Volume counter or PDP context Period timer expires or an Apply Charging GPRS is received when QoS change report is pending, then the procedure Apply Charging Report GPRS procedure is called with the PDP Id as input parameter. The procedure will then check both reports for that PDP Context. 6.5.3.5 Procedure Complete_FCI_Record_GPRS Procedure Complete_FCI_Record_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Complete_FCI_Record_GPRS procedure shall be executed for the Session. - 'PDP Id'. The Complete_FCI_Record_GPRS procedure shall be executed for the indicated PDP Context. - 'Session + PDPs'. The Complete_FCI_Record_GPRS procedure shall be executed for the Session and all PDP Contexts. 6.5.3.6 Procedure Handle_SCI_GPRS For terminology see subclauseÊ4.5.7.2.1. The gsmSCF may send e parameters to the Session and to individual PDP Contexts. When e parameters are sent for the Session, the SGSN will forward these e parameters directly to the Mobile Station. When e parameters are sent for a PDP Context and that PDP Context is not yet acknowledged (= active), then the SGSN shall retain these parameters (pending parameters). These parameters will be sent to the Mobile Station when the PDP Context is acknowledged. The gsmSCF may send two sets of e parameters and a Tariff Switch for the Session or a PDP Context. The first set of e parameters shall be sent to the SGSN and the second set of e parameters shall be stored. This second set of e parameters shall be sent to the SGSN when the tariff switch expires. When the Tariff Switch for the Session expires, then the stored e parameters for the Session shall be sent to the SGSN. When the Tariff Switch for a PDP Context expires before that PDP Context is acknowledged, then the pending e parameters for that PDP Context shall be replaced by the stored e parameters for that PDP Context. The stored e parameters for that PDP Context shall be discarded. When the Tariff Switch for a PDP Context expires after that PDP Context has been acknowledged, then the stored e parameters for that PDP Context shall be sent to the SGSN. 6.5.3.6.1 Handling of SCI_GPRS for the Session 1) Precondition: no Tsw running for the Session: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw (Session)/store 2nd set of e parameters. 2) Precondition: Tsw running for the Session and no e parameters stored for the Session: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 3) Precondition: Tsw running for the Session and e parameters stored for the Session: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6.5.3.6.2 Handling of SCI_GPRS for a PDP Context 1) Precondition: before a PDP Context Establishment Acknowledgement event is detected and no Tsw running for this PDP Context: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw(PDP Id)/store 2nd set of e parameters; 2) Precondition: before a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and no e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 3) Precondition: before a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 4) Precondition: after a PDP Context Establishment Acknowledgement event is detected and no Tsw running for this PDP Context: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> start Tsw(PDP Id)/store e parameters; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw(PDP Id)/store 2nd set of e parameters. 5) Precondition: after a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and no e parameters stored for this PDP Context; if 1 set of e parameters received --> store e parameters; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6) Precondition: after a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6.5.3.7 Procedure Handle_PDP_Acknowledgement Procedure Handle_PDP_Acknowledgement is called when an event occurs that may signal the activation (= Acknowledgement) of a PDP Context. The event signal is passed on to the Handle_PDP_Acknowledgement procedure. 6.5.3.8 GPRS duration and volume control 6.5.3.8.1 Examples of information flows for GPRS session and PDP context control Figure 6.16-1: Example of information flows for GPRS session duration at GPRS attach and change of position session Figure 6.16-2: Example of information flows for PDP context duration control at context activation and change of position context Figure 6.16-3: Example of information flows for PDP context volume control at context activation and change of position context Note1: Vc threshold reached, Tcp is stopped. Note2: Tcp time out, Vc is stopped. Figure 6.16-4: Example of information flows for PDP context volume and duration control at context activation and change of position context These figures 6.16-1 to 6.16-4show examples of handling of the timers that are used in the process gprsSSF and in the procedures Handle_AC_GPRS and Handle_ACR_GPRS. Duration timers (Tsp for the GPRS session and one Tcp for each PDP context) are used if the charging is on duration of the GPRS session or a PDP context. Tariff Switch Timers (Tsw(Session) for the GPRS session and one Tsw(PDP Id) for each PDP context) define the start point of a new Tariff. Tsw(Session) is used for charging on duration. Tsw(PDP Id) is used for both methods of charging: duration charging and volume charging. If a PDP context is charged on duration and volume, only one Tsw(PDP Id) timer will be accepted from the gsmSCF for that PDP context. Delta timers measure the response time of the gsmSCF after an Apply Charging Report GPRS information flow: - Dsp for the GPRS session; this delta timer is used for GPRS session period timing. - Dcp for each PDP context; these delta timers are used for PDP context period timing. - Dc for each PDP context; these delta counters are used for PDP context volume counting. After the sending of Apply Charging Report GPRS, the gsmSCF may reply either with: - Apply Charging GPRS, if the gsmSCF sends a new duration because of the expiration of the previous period or because of QOS change. - Release GPRS, if the gsmSCF decides to release the GPRS session or PDP context. For a more detailed example of the handling of the Apply Charging GPRS and Apply Charging Report GPRS information flows, see Annex A. 6.5.3.8.2 TC guard timer 6.5.3.8.2.1 General When the gprsSSF sends an Apply Charging Report GPRS information flow to the gsmSCF, with SessionActive or ContextActive variable set to TRUE, then the gprsSSF shall start the TC guard timer. The gprsSSF shall also mark for the Session or PDP Context for which the Apply Charging Report GPRS was sent, that a corresponding Apply Charging GPRS information flow from the gsmSCF is expected. When the gprsSSF receives an Apply Charging GPRS information flow or a Release GPRS information flow, then the 'Waiting-for-AC' marking(s) for the Session or PDP Context shall be removed. The gprsSSF shall then check if the TC guard timer shall be stopped (task box 'Check TC guard timer'). The TC guard timer shall be stopped if there are no more Apply Charging GPRS information flows expected for the Session and all PDP Contexts. When an event occurs that results in the termination of a PDP Context, then the 'Waiting-for-AC' markings for that PDP Context shall be removed. The gprsSSF shall then check if the TC guard timer shall be stopped (task box 'Check TC guard timer'). The TC guard timer shall be stopped if there are no more Apply Charging GPRS information flows expected for the Session and all PDP Contexts. When the TC guard timer expires in state Monitoring, then the gprsSSF shall close the TC dialogue, provided that all conditions for closing the TC dialogue are fulfilled, i.e. there are no information flow results expected from the gsmSCF, no information flows or errors to be sent to the gsmSCF and no information flows from the gsmSCF received and waiting to be processed. When the TC guard timer expires in state Waiting_for_Instructions, then no action shall be taken. Service Designers should note that there may be additional timer(s) in the gprsSSF to supervise the response from the gsmSCF on the Apply Charging Report GPRS procedure. As a result of this, if the gsmSCF does not send an Apply Charging GPRS, Release GPRS or Cancel GPRS in response to an Apply Charging Report GPRS when the gprsSSF is awaiting such response, then service behaviour may be unpredictable. 6.5.3.8.2.2 Check TC guard timer This clause describes the actions to be taken in the task box 'Check TC guard timer'. The tasks to be executed in the 'Check TC guard timer' box depend on the event that resulted in execution of the task box. 6.5.3.8.2.2.1 Apply Charging GPRS If 'Check guard timer' is executed as a result of an Apply Charging GPRS information flow from the gsmSCF, then the appropriate 'Waiting-for-AC' marker shall be removed, depending on the information received in the Apply Charging GPRS information flow: - if the Apply Charging GPRS information flow carries a Session Time threshold, then the Session-Period 'Waiting-for-AC' marker shall be removed. - if the Apply Charging GPRS information flow carries a PDP Context Volume threshold, then the PDP Context-Volume 'Waiting-for-AC' marker shall be removed. - if the Apply Charging GPRS information flow carries a PDP Context Time threshold, then the PDP Context -Period 'Waiting-for-AC' marker shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.8.2.2.2 Release GPRS If 'Check TC guard timer' is executed as a result of a Release GPRS information flow from the gsmSCF, then the appropriate 'Waiting-for-AC' markers shall be removed, depending on the information received in the Release GPRS information flow: - if the Release GPRS information flow is for the Session, then the Session 'Waiting-for-AC' markers shall be removed. - if the Release GPRS information flow is for the PDP Context, then the PDP Context 'Waiting-for-AC' markers shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.8.2.2.3 PDP Context Disconnect If 'Check TC guard timer' is executed as a result of a PDP Context Disconnect signal from the SGSN, then the 'Waiting-for-AC' markers for that PDP Context shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.9 SDL diagrams for process GPRS_SSF and procedures Figure 6.17-1: Process GPRS_SSF (sheet 1) Figure 6.17-2: Process GPRS_SSF (sheet 2) Figure 6.17-3: Process GPRS_SSF (sheet 3) Figure 6.17-4: Process GPRS_SSF (sheet 4) Figure 6.17-5: Process GPRS_SSF (sheet 5) Figure 6.17-6: Process GPRS_SSF (sheet 6) Figure 6.17-7: Process GPRS_SSF (sheet 7) Figure 6.17-8: Process GPRS_SSF (sheet 8) Figure 6.17-9: Process GPRS_SSF (sheet 9) Figure 6.17-10: Process GPRS_SSF (sheet 10) Figure 6.17-11: Process GPRS_SSF (sheet 11) Figure 6.17-12: Process GPRS_SSF (sheet 12) Figure 6.17-13: Process GPRS_SSF (sheet 13) Figure 6.17-14: Process GPRS_SSF (sheet 14) Figure 6.17-15: Process GPRS_SSF (sheet 15) Figure 6.17-16: Process GPRS_SSF (sheet 16) Figure 6.17-17: Process GPRS_SSF (sheet 17) Figure 6.17-18: Process GPRS_SSF (sheet 18) Figure 6.17-19: Process GPRS_SSF (sheet 19) Figure 6.17-20: Process GPRS_SSF (sheet 20) Figure 6.17-21: Process GPRS_SSF (sheet 21) Figure 6.17-22: Process GPRS_SSF (sheet 22) Figure 6.17-23: Process GPRS_SSF (sheet 23) Figure 6.18-1: Process GPRS_Dialogue_Handler (sheet 1) Figure 6.18-2: Process GPRS_Dialogue_Handler (sheet 2) Figure 6.18-3: Process GPRS_Dialogue_Handler (sheet 3) Figure 6.19-1: Procedure Handle_AC_GPRS (sheet 1) Figure 6.19-2: Procedure Handle_AC_GPRS (sheet 2) Figure 6.19-3: Procedure Handle_AC_GPRS (sheet 3) Figure 6.20-1: Procedure Handle_ACR_GPRS (sheet 1) Figure 6.20-2: Procedure Handle_ACR_GPRS (sheet 2) Figure 6.21-1: Procedure Handle_FCI_GPRS (sheet 1) Figure 6.22-1: Procedure Complete_FCI_Record_GPRS (sheet 1) Figure 6.23-1: Procedure Handle_SCI_GPRS (sheet 1) Figure 6.23-2: Procedure Handle_SCI_GPRS (sheet 2) Figure 6.23-3: Procedure Handle_SCI_GPRS (sheet 3) Figure 6.24-1: Procedure Handle_PDP_Acknowledgement (sheet 1) 6.6 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for GPRS control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34] and TSÊ29.078Ê[36]. 6.6.1 gprsSSF to gsmSCF Information Flows 6.6.1.1 Activity Test GPRS ack 6.6.1.1.1 Description This IF is the response to the Activity Test GPRS. 6.6.1.1.2 Information Elements This IF contains no information elements. 6.6.1.2 Apply Charging Report GPRS 6.6.1.2.1 Description This IF is used by the gprsSSF to report to the gsmSCF the information requested in the Apply Charging GPRS IF. In addition, this IF is used to notify the gsmSCF of changes in QoS. Note that there are several possible QoS profiles defined by the combinations of the different QoS attributes as defined in 3GPP TSÊ23.060Ê[15]. A PLMN may only support and charge on a limited subset of those QoS. It is recommended that changes in QoS are only reported in Apply Charging Report GPRS for those QoS profiles. 6.6.1.2.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Charging Result M This IE contains the charging information for the PDP provided by the gprsSSF. It is a choice between elapsed time and data volume. Quality Of Service C This IE is described in a table below. Active M This IE indicates if the GPRS session or PDP context is still established, or if it has been detached or deactivated. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Apply Charging Report GPRS applies to the GPRS Session. If this IE is present in the IF, then the Apply Charging Report GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. Charging Roll Over C This IE indicates which parameter(s) of the Charging Result have overflowed. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Quality of Service contains the following information element: Information element name Status Description Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN, as a result of a 'Modify PDP Context' request. This IE shall be included only if sending of the Apply Charging Report GPRS was triggered by a change in Quality of Service. This IE shall contain the negotiated QoS as on the time of sending the Apply Charging Report GPRS. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. 6.6.1.3 Entity Released GPRS 6.6.1.3.1 Description This IF is used by the gprsSSF to inform the gsmSCF at any phase that a GPRS Session has been detached or a PDP Context has been disconnected without reporting any EDP. 6.6.1.3.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. GPRS Cause M This IE contains the Cause value indicating the reason for the GPRS Session Detach event or the PDP Context Disconnection event. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Entity Released GPRS applies to the GPRS Session. If this IE is present in the IF, then the Entity Released GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.1.4 Event Report GPRS 6.6.1.4.1 Description This IF is used to notify the gsmSCF of a GPRS event previously requested by the gsmSCF in a Request Report GPRS Event IF. 6.6.1.4.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. GPRS Event Type M This IE specifies the type of event that is reported. Misc GPRS Info M This IE indicates the DP type (EDP N or EDP R). GPRS Event Specific Information M This IE is described in a table below. This IE contains information specific to the reported event. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Event Report GPRS applies to the GPRS Session. If this IE is present in the IF, then the Event Report GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. If the GPRS Event Type contains DP Change of Position GPRS Session, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Location Information In SGSN M See subclauseÊ7.6.1.2.2. If the GPRS Event Type contains DP Change of Position Context, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name S This IE identifies the Access Point Name to which the MS is connected. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Charging ID S This IE contains the Charging ID received from the GGSN for the PDP context. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Location Information In SGSN M See subclauseÊ7.6.1.2.2. End User Address S See subclauseÊ6.6.1.5.2. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Quality Of Service S This IE is described in a table below. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Time And Time Zone S This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. GGSN Address S This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. If the GPRS Event Type contains DP Detach or DP PDP context disconnection, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Initiating Entity M This IE identifies the entity that has initiated the disconnection or detachment. Routeing Area Update C This IE indicates that the Detach or Disconnection is due to inter-SGSN routeing area update. If the GPRS Event Type contains DP PDP context establishment, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name C This IE identifies the Access Point Name the MS has requested to connect to. End User Address C See subclauseÊ6.6.1.5.2. Quality Of Service M This IE is described in a table below. Location Information In SGSN M See subclauseÊ7.6.1.2.2. Time And Time Zone M This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. PDP Initiation Type M This IE indicates whether a PDP context was established as a result of a network-initiated request or as a result of a subscriber request. Secondary PDP Context C This IE indicates that the PDP context activation was requested for a secondary PDP context. See 3GPP TSÊ23.060Ê[15]. If the GPRS Event Type contains DP PDP context establishment acknowledgement, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name M This IE identifies the Access Point Name to which the MS is connected. Charging ID M This IE contains the Charging ID received from the GGSN for the PDP context. End User Address M See subclauseÊ6.6.1.5.2. Quality Of Service M This IE is described in a table below. Location Information In SGSN M See subclauseÊ7.6.1.2.2. Time And Time Zone M This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. GGSN Address M This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Quality of Service contains the following information elements: Information element name Status Description Requested QoS C This IE identifies the QoS requested by the subscriber for the PDP Context. It shall be included if the EventReportGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Subscribed QoS C This IE identifies the subscribed QoS. It shall be included if the EventReportGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN. It shall be included if the EventReportGPRS is sent at PDP Context Establishment Acknowledgement and at Change of Position Context. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. 6.6.1.5 Initial DP GPRS 6.6.1.5.1 Description This IF is generated by the gprsSSF when a trigger is detected at a DP in the GPRS state models, to request instructions from the gsmSCF. 6.6.1.5.2 Information Elements Information element name Status Description Gprs Reference Number M This IE consists of a number assigned by the gprsSSF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. ServiceKey M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application/SLP within the gsmSCF. GPRS Event Type M This IE indicates the armed GPRS DP event resulting in the Initial DP IF. MSISDN M This IE contains the basic MSISDN of the MS. IMSI M This IE identifies the mobile subscriber. Time and Time zone M This IE contains the time that the gprsSSF was triggered, and the time zone in which the gprsSSF resides. GPRS MS Class C This IE contains the MS network and radio access capabilities. End User Address C This IE is described in a table below. Quality of Service C This IE is described in a table below. Access Point Name C This IE identifies the Access Point Name: - At DP Change Of Position Context contains the selected APN. - AT DP PDP Context Establishment contains the APN which the MS has requested. - AT DP PDP Context Establishment Acknowledgement contains the selected APN. Charging ID C This IE contains the Charging ID received from the GGSN for the PDP context. SGSN Capabilities C This IE specifies the capabilities of the SGSN to support the CAMEL interworking, e.g. support of Advice of Charge. Location Information in SGSN M This IE is described in subclauseÊ7.6.1.2.2. PDP Initiation Type C This IE indicates whether a PDP context was established as a result of a network-initiated request or as a result of a subscriber request. GGSN Address C This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Secondary PDP context C This IE indicates that the PDP context activation was requested for a secondary PDP context. See 3GPP TSÊ23.060Ê[15]. This IE is not sent if this IF is initiated at DP Change of Position Context. IMEI (with software version) C This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Quality of Service contains the following information elements: Information element name Status Description Requested QoS C This IE identifies the QoS requested by the subscriber for a new PDP Context. It shall be included if the InitialDPGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Subscribed QoS C This IE identifies the subscribed QoS. It shall be included if the InitialDPGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN. It shall be included if the Initial DP GPRS is sent at PDP Context Establishment Acknowledgement and at Change of Position Context. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS."
"It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. End User Address shall be populated as follows: - At DP Change Of Position Context in an Inter-SGSN Routeing Area Update: Initial DP GPRS and EventReportGPRS contain the selected value; - At DP PDP Context Establishment: Initial DP GPRS and Event Report GPRS contain the value which the MS has requested; - At DP PDP Context Establishment Acknowledgement: Initial DP GPRS and Event Report GPRS contain the selected value. Note that the PDP Address is not always available at this DP. For details see 3GPP TSÊ23.060Ê[15]. End User Address contains the following information elements: Information element name Status Description PDP Type Organization C This IE identifies the PDP Type Organisation (e.g. IETF). PDP Type Number C This IE identifies the PDP type, e.g. IPv4 or IPv6. PDP Address C This IE identifies the address of the subscriber for a new PDP Context. 6.6.2 gsmSCF to gprsSSF Information Flows 6.6.2.1 Activity Test GPRS 6.6.2.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gprsSSF. If the relationship is still in existence, then the gprsSSF will respond. If no reply is received, then the gsmSCF will assume that the gprsSSF has failed in some way and will take the appropriate action. 6.6.2.1.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. 6.6.2.2 Apply Charging GPRS 6.6.2.2.1 Description This IF is used for interacting from the gsmSCF with the gprsSSF charging mechanisms to control the charging of a GPRS session or a PDP Context. 6.6.2.2.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Charging Characteristics M This IE specifies the charging related information to be provided by the gprsSSF and the conditions on which this information has to be provided back to the gsmSCF. It is a choice between granted volume and granted time for the data transfer. Time charging may be applied to GPRS Session or PDP Contexts; volume charging may be applied to PDP Context only. Tariff Switch Interval O This information element specifies the time until the next tariff switch occurrence. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Apply Charging GPRS applies to the GPRS Session. If this IE is present in the IF, then the Apply Charging GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.3 Apply Charging Report GPRS ack 6.6.2.3.1 Description This IF is the response to the Apply Charging Report GPRS. 6.6.2.3.2 Information Elements This IF contains no information elements. 6.6.2.4 Cancel GPRS 6.6.2.4.1 Description This IF is used by the gsmSCF to request the gprsSSF to cancel all EDPs and reports. 6.6.2.4.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then all pending reports of the GPRS Session and all pending reports of the PDP Contexts shall be cancelled and all armed events of the GPRS Session, all armed events of the PDP Contexts and all generically armed events shall be disarmed. If this IE is present in the IF, then all pending reports of the indicated PDP Context shall be cancelled and all armed events of the indicated PDP Context shall be disarmed. Scenario 2: This IE is not used in the IF. 6.6.2.5 Connect GPRS 6.6.2.5.1 Description This IF is used by the gsmSCF to request the gprsSSF to modify the APN used when establishing a PDP Context. This IF shall not be used for a secondary PDP context or for a network initiated PDP context. 6.6.2.5.2 Information Elements Information element name Status Description Access Point Name M This IE contains the Access Point Name (APN) to be used when establishing the PDP Context. The gsmSCF should provide an APN which is allowed by the served subscriber's subscription. The APN provided by the gsmSCF is used for selecting the primary PDP context as specified in 3GPP TSÊ23.060Ê[15]. The gsmSCF provided APN may consist of Network Identity (NI) only, or Network Identity and Operator Identity (OI). The APN provided by the gsmSCF replaces entirely the APN requested by the MS. If the gsmSCF does not provide OI in APN then the SGSN selects the OI independent of MS. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: There shall always be this IE present in this IF. This IE indicates the PDP Context to which the Connect GPRS applies. Scenario 2: This IE is not used in the IF. 6.6.2.6 Continue GPRS 6.6.2.6.1 Description This information flow requests the gprsSSF to proceed with processing at the DP at which it previously suspended processing to await gsmSCF instructions. The gprsSSF completes DP processing, and continues processing (i.e. proceeds to the next point in the Attach/Detach State Model or PDP Context State Model) without substituting new data from the gsmSCF. 6.6.2.6.2 Information Elements Information element name Status Description PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Continue GPRS applies to the GPRS Session. If this IE is present in the IF, then the Continue GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.7 Entity Released GPRS ack 6.6.2.7.1 Description This IF is the response to the Entity Released GPRS. 6.6.2.7.2 Information Elements This IF contains no information elements. 6.6.2.8 Event Report GPRS ack 6.6.2.8.1 Description This IF is the response to the Event Report GPRS. 6.6.2.8.2 Information Elements This IF contains no information elements. 6.6.2.9 Furnish Charging Information GPRS 6.6.2.9.1 Description This IF is used to request the gprsSSF to include information in the CAMEL specific logical call record. The logical call record is created when FCI-GPRS is received and a logical call record for that state model does not exist. For modelling purposes the logical call record is buffered in the gprsSSF. The gprsSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then its free format data are moved to the corresponding CDR and the logical call record is deleted. In the SGSN there is a separate Logical call record for the attach/detach state model and for each PDP context. The CSE can send multiple concatenated FCIs per Logical Call Record for completion. The total maximum of free format data is 160 octets per Logical Call Record. The 160 octets may be sent in one or more FCI IF. If there is incomplete free format data and one or more new FCI IFs is/are received to overwrite the incomplete data, then the incomplete data are discarded and the gsmSCF can send another 160 octets per CDR. 6.6.2.9.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. FCI GPRS Billing Charging Characteristics M This IE is described in a table below. FCI GPRS Billing Charging Characteristics contains the following information: Information element name Status Description FCIBCCCAMEL Sequence 1 M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information: Information element name Status Description Free Format Data M This IE contains free format data to be inserted in the CAMEL logical call record. Append Free Format Data O This IE indicates that the gprsSSF shall append the free format data to the Logical call record. In the SGSN there is a separate Logical call record for the attach/detach state model and for each PDP context. - If this IE is present indicating ""Append"", the gprsSSF shall append the free format data received in this IF to the free format data already present in the Logical call record for that GPRS session or PDP Context. - If this IE is absent or indicates ""Overwrite"", then the gprsSSF shall overwrite all free format data already present in the Logical call record for that GPRS session or PDP Context, by the free format data received in this IF. If no Logical call record exists yet for that GPRS session or PDP Context, then the gprsSSF shall ignore this IE. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Furnish Charging Information GPRS applies to the GPRS Session. If this IE is present in the IF, then the Furnish Charging Information GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.10 Release GPRS 6.6.2.10.1 Description This IF is used by the gsmSCF to tear down an existing GPRS session or PDP Context at any time. 6.6.2.10.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. GPRS Cause M This IE contains the Cause value indicating the reason for releasing the GPRS session or PDP context. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Release GPRS applies to the GPRS Session, in which case the GPRS Session and all PDP Contexts shall be released. If this IE is present in the IF, then the Release GPRS applies to the indicated PDP Context, in which case the indicated PDP Context shall be released. Scenario 2: This IE is not used in the IF. 6.6.2.11 Request Report GPRS Event 6.6.2.11.1 Description This IF is used to request the gprsSSF to monitor for an event and send a notification back to the gsmSCF when the event is detected (see Event Report GPRS IF). 6.6.2.11.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. GPRS Event M This IE specifies the event or events of which a report is requested. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IF is used to arm an event related to the GPRS Session, then this IF shall not include this IE. If this IF is used to arm an event related to a specific PDP Context, then this IF shall include this IE for that PDP Context. If this IF is used to generically arm a PDP Context related event, then this IF shall not include this IE. Scenario 2: This IE is not used in the IF. GPRS Event contains the following information elements: Information element name Status Description GPRS Event type M This IE specifies the type of event of which a report is requested. Monitor Mode M This IE indicates how the event shall be reported. 6.6.2.12 Reset Timer GPRS 6.6.2.12.1 Description This IF is used to refresh the gprsSSF timer. 6.6.2.12.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Timer ID M This IE specifies the default value for the Tssf timer. Timer Value M This IE specifies the value to which the timer Tssf shall be set. 6.6.2.13 Send Charging Information GPRS 6.6.2.13.1 Description This IF is used to send e parameters from the gsmSCF to the gprsSSF. If charge advice information is received from the gsmSCF, it shall replace the charge advice information which would be generated by the SGSN and inhibit any further generation of CAI by the SGSN. Further processing of the charge advice information by the SGSN shall be in accordance with the Advice of Charge supplementary service. If the SGSN supports Advice of Charge, then the gsmSCF may use this IF to send e parameters to the gprsSSF. However, if the subscriber is not provisioned with the Advice of Charge supplementary service, then no e parameters shall be sent to the MS and no error due to this fact shall be sent back to the gsmSCF. If the SGSN does not support Advice of Charge, then the gsmSCF shall not send e parameters to the gprsSSF. The SGSN's support of Advice of Charge is indicated in the Initial DP GPRS IF. NOTE: If charge advice information is received from the gsmSCF after charge information has been generated by the SGSN and sent to the MS, the behaviour of the service may be unpredictable or incorrect; the service designer should therefore ensure that the first set of charge advice information is sent to the gprsSSF before charge information is sent to the to the MS. 6.6.2.13.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. SCI GPRS Billing ChargingCharacteristics M This IE defines the Advice Of Charge related information to be provided to the Mobile Station, if supported by the SGSN. GPRS SCI Billing Charging Characteristics contains the following information elements: Information element name Status Description AOC GPRS M This IE is present after an Activate PDP Context Accept or Attach Accept has been received from the SGSN. This IE defines the Advice Of Charge related information to be provided to the Mobile Station, if supported by the SGSN. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Send Charging Information GPRS applies to the GPRS Session. If this IE is present in the IF, then the Send Charging Information GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. AOC GPRS contains the following information elements: Information element name Status Description AOC Initial M This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. AOC Subsequent O This IE is described in a table below. AOC Subsequent contains the following information elements: Information element name Status Description CAI Elements M This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O This IE indicates the tariff switch time until the next tariff switch applies. 6.6.3 HLR to SGSN Information Flows 6.6.3.1 Delete Subscriber Data 6.6.3.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from an SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.3.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in SGSN. Specific CSI Withdraw O This IE is used to indicate that only GPRS CSI shall be deleted from the SGSN. This IE should not be present when CAMEL Subscription Info Withdraw is present. 6.6.3.2 Insert Subscriber Data 6.6.3.2.1 Description This IF is specified in 3GPP TSÊ29.002Ê[34] and used by the HLR to insert subscriber data in the SGSN. 6.6.3.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information element: Information element name Status Description GPRS CSI O This IE identifies the subscriber as having CAMEL GPRS services. GPRS CSI contains the following information elements: Information element name Status Description GsmSCF Address M See subclauseÊ6.3.1.1. Service Key M See subclauseÊ6.3.1.2. Default Session Handling M See subclauseÊ6.3.1.3. TDP List M See subclauseÊ6.3.1.4. CAMEL Capability Handling M See subclauseÊ6.3.1.5. 6.6.4 SGSN to HLR Information Flows 6.6.4.1 Insert Subscriber Data ack 6.6.4.1.1 Description This IF is used by the SGSN to indicate to the HLR the result of the Insert Subscriber Data IF. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.4.1.2 Information Elements Insert Subscriber Data ack contains the following CAMEL specific information elements: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the SGSN. It shall be present when a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. It shall be present if a CSI has been included in the Insert Subscriber Data IF. MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI. It shall be present if a CSI has been included in the Insert Subscriber Data IF. PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancements of Provide Subscriber Information. 6.6.4.2 Update GPRS Location 6.6.4.2.1 Description This IF is used by the SGSN to indicate to the HLR the CAMEL phases supported by the SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.4.2.2 Information Elements Update GPRS location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the SGSN. The SGSN may indicate support of CAMEL phaseÊ3 or higher. It shall be present when the SGSN supports CAMEL. Offered CAMEL4 CSIs This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI. PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancements of Provide Subscriber Information. 7 Short Message Services 7.1 Architecture 7.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support Mobile Originating Short Message Service (MO SMS) and Mobile Terminating Short Message Service (MT SMS) interworking for CAMEL. FiguresÊ7.1-1 and 7.1-2 show the functional entities involved in MO SMS or MT SMS requiring CAMEL support. Further details of the architecture needed to support Mobile Originating Short Message Service (MO SMS) and Mobile Terminating Short Message Service (MT SMS) are given in 3GPP TSÊ23.040Ê[14]. Figure 7.1-1: Functional architecture for support of CAMEL control of MSC switched MO and MT SMS Figure 7.1-2: Functional architecture for support of CAMEL control of SGSN switched MO and MT SMS HLR: The HLR stores MO SMS CSI and/or MT SMS CSI. MO SMS CSI contains subscription information for subscribers that require CAMEL support of MO SMS. MT SMS CSI contains subscription information for subscribers that require CAMEL support of MT SMS. One or both of MO SMS CSI and MT SMS CSI are transferred to the VLR or to the SGSN on Location Update and Restore Data or when MO SMS CSI or MT SMS CSI has changed. VLR: The VLR receives the MO SMS CSI and MT SMS CSI for the subscriber from the HLR. MO SMS CSI and MT SMS CSI are used by the MSC to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. MSC: The MSC receives MO SMS CSI and MT SMS CSI from the VLR and uses this to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. SGSN: The SGSN receives the MO SMS CSI and MT SMS CSI for the subscriber from the HLR. The SGSN uses the MO SMS CSI and MT SMS CSI to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. gprsSSF: see subclauseÊ3.1. gsmSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. SMSC: The Short Message Service Centre accepts messages submitted by an MS or other MO short message entity, stores them and delivers them to the destination MS or other MT short message entity. SMS-GMSC: The Short Message Service Gateway MSC receives short messages from the SMSC, interrogates the HLR for routeing information to deliver each short message and forwards each short message to the serving node (MSC or SGSN) for delivery to the destination MS. The SMS-GMSC may be physically integrated with the SMSC or with the MSC for the destination subscriber. SMS-IWMSC: The Short Message Service InterWorking MSC terminates the MAP signalling from the MSC or the SGSN for MO short message submission, and transfers the short message to the SMSC, The SMS-IWMSC may be physically integrated with the SMSC or with the MSC for the originating subscriber. 7.1.2 Interfaces defined for CAMEL 7.1.2.1 HLR - VLR interface This interface is used to send CAMEL related subscriber data (MO SMS CSI and MT SMS CSI) to a visited MSC/VLR or to remove CAMEL related subscriber data from a visited MSC/VLR. 7.1.2.2 HLR - SGSN interface This interface is used to send CAMEL related subscriber data (MO SMS CSI and MT SMS CSI) to a visited SGSN or to remove CAMEL related subscriber data from a visited SGSN. 7.1.2.3 gsmSSF - gsmSCF interface This interface is used by the gsmSCF to control the handling of MO SMS and MT SMS in the MSC. A relationship on this interface is opened as a result of the gsmSSF sending a request for instructions to the gsmSCF. 7.1.2.4 gprsSSF - gsmSCF interface This interface is used by the gsmSCF to control the handling of MO SMS and MT SMS in the SGSN. A relationship on this interface is opened as a result of the gprsSSF sending a request for instructions to the gsmSCF. 7.1.2.5 MSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 7.1.2.6 SGSN - gprsSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 7.1.2.7 MSC - VLR interface This is an internal interface. The interface is described in the present document to make it easier to understand the internal information flow within the MSC/VLR. 7.1.2.8 MSC - SMSC interface This interface is used by the MSC to submit a SM to the SMSC and to deliver a SM to the MSC. 7.1.2.9 SGSN - SMSC interface This interface is used by the SGSN to submit a SM to the SMSC and to deliver a SM to the SGSN. 7.2 Detection Points (DPs) For the general handling of the DPs, see subclauseÊ4.2. 7.2.1 Criteria at DP SMS Delivery Request The HLR may store a criterion that indicates when triggering shall take place. The criterion for DPÊSMS_Delivery_Request consists of a list of TPDU types. Refer to 3GPP TSÊ23.040Ê[14] for the available TPDU types. When the TPDU type of the Short Message is present in the list of TPDU types, then triggering shall take place. Otherwise, triggering shall not take place. If no criterion is defined for a subscriber, then triggering shall take place regardless of the TPDU type of the Short Message. 7.3 Description of CAMEL Subscriber Data Note: CAMEL PhaseÊ3 specifies SMS CSI for MO SMS CAMEL Services. CAMEL PhaseÊ4 specifies MO SMS CSI for MO SMS CAMEL Services and MT SMS CSI for MT SMS CAMEL Services. SMS CSI and MO SMS CSI are, however, syntactically and functionally identical. 7.3.1 Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI) This subclause defines the contents of the Short Message Service CAMEL Subscription Information. 7.3.1.1 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 7.3.1.2 Service Key The Service Key identifies to the gsmSCF the service logic. 7.3.1.3 Default SMS Handling The Default SMS Handling indicates whether the Short Message submission shall be released or continued as requested in the case of error in the dialogue between gsmSCF and gsmSSF or gprsSSF. 7.3.1.4 TDP List The TDP List indicates on which detection point triggering shall take place. For MO SMS CSI only DPÊSMS_Collected_Info is used. 7.3.1.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. This parameter shall be set to CAMEL PhaseÊ3 7.3.1.6 CSI state The CSI state indicates whether the MO SMS CSI is active or not. 7.3.1.7 Notification flag The notification flag indicates whether the change of the MO SMS CSI shall trigger Notification on Change of Subscriber Data or not. 7.3.2 Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI) This subclause defines the contents of the Mobile Terminating Short Message Service CAMEL Subscription Information. 7.3.2.1 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 7.3.2.2 Service Key The Service Key identifies to the gsmSCF the service logic. 7.3.2.3 Default SMS Handling The Default SMS Handling indicates whether the Short Message delivery shall be released or continued as requested in the case of error in the dialogue between gsmSCF and gsmSSF or gprsSSF. 7.3.2.4 TDP List The TDP List indicates on which detection point triggering shall take place. For MT SMS CSI only DPÊSMS_Delivery_Request is used. 7.3.2.5 DP criteria The DP criteria indicate whether the SMS_SSF shall request the gsmSCF for instructions. 7.3.2.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. This parameter shall be set to CAMEL PhaseÊ4. 7.3.2.7 CSI state The CSI state indicates whether the MT SMS CSI is active or not. 7.3.2.8 Notification flag The notification flag indicates whether the change of the MT SMS CSI shall trigger Notification on Change of Subscriber Data or not. 7.3.3 gsmSCF address list for CSI The gsmSCF address list indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI's. 7.4 Description of SMS State Models 7.4.1 General Handling See subclauseÊ4.4.1. The State Model for MO SMS handling contains Points in Association (PIA's) instead of Points in Call (PIC's). 7.4.2 Mobile Originating SMS State Models 7.4.2.1 Description of MO SMS state model The MO SMS state model is used to describe the actions in an MSC and in a SGSN during Mobile Originating SMS. Figure 7.2: MO SMS State Model Table 7.1: Description of MO SMS DPs in the MSC and SGSN CAMEL Detection Point DP Type Description DPÊSMS_Collected_Info TDP R Indication that the MO SMS CSI is analysed and a mobile originated short message is received. DPÊO_SMS_Failure EDP N, EDP R Indication that the SM submission to the Short Message Service Centre failed DPÊO_SMS_Submitted EDP N, EDP R Indication that the SM has been successfully submitted to the Short Message Service Centre. 7.4.2.1.1 Description of the MO SMS state model (PIAs) This subclause describes the state model for originating SMS transfer. For each PIA a description can be found of the entry events, actions and exit events. 7.4.2.1.1.1 SMS Null & Start & Authorize Entry events: - Previous MO SMS transfer to the SMSC completed (DPÊO_SMS_Submitted). - Exception event is reported. Actions: - Interface is idled. - Authentication. - Ciphering. - MO SMS subscription check. - RP-MO-DATA message containing the User Data and the SMSC address is received from MS. - The supplementary service ""barring of all outgoing calls"" is checked and invoked if necessary. - The ODB category ""barring of all outgoing calls"" is checked and ODB is invoked if necessary. Exit events: - MO SMS CSI is analysed. - An exception condition is encountered. 7.4.2.1.1.2 SMS Analyse & Routing Entry events: - MO SMS CSI is analysed (DPÊSMS_Collected_Info). Actions: - Information being analysed and/or translated to determine routeing address of the SMSC. - Outgoing barring services and ODB categories not already applied are checked and invoked if necessary. If any of the barring services or ODB categories prevents the submission of the MO SMS, then the MSC or SGSN shall generate the ""O_SMS_Failure"" event. The cause code to be used in that case shall be ""sM DeliveryFailure"". - The short message is sent to the SMSC. Exit events: - Acknowledge from the SMSC is received. (DPÊO_SMS_submitted). A positive acknowledgement is sent to the MS. - An exception condition is encountered - this leads to the SMS_Exception PIA. A negative acknowledgement is sent to the MS. - Attempt to select the route for the SMS fails (DPÊO_SMS_Failure). A negative acknowledgement is sent to the MS. - Negative acknowledgement from the SMSC is received (DPÊO_SMS_Failure). A negative acknowledgement is sent to the MS. 7.4.2.1.1.3 SMS_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIA cannot be met. Actions: - Default handling of the exception condition is applied. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If a relationship exists between the gsmSCF and gsmSSF or gprsSSF send an error information flow closing the relationship and indicating that any outstanding Short Message handling instructions will not run to completion. - The MSC/gsmSSF or SGSN/gprsSSF shall make use of vendor-specific procedures to ensure release of internal resources. Exit events: - Default handling of the exception condition by MSC/gsmSSF or SGSN/gprsSSF completed. 7.4.3 Mobile Terminating SMS State Model 7.4.3.1 Description of MT SMS state model The MT SMS state model is used to describe the actions in an MSC and in a SGSN during Mobile Terminating SMS. Figure 7.3: MT SMS State Model Table 7.2: Description of MT SMS DPs in the MSC and SGSN CAMEL Detection Point DP Type Description DPÊSMS_Delivery_Request TDP R Indication that the MT SMS CSI is analysed and a mobile terminating short message or status report is received. DPÊT_SMS_Failure EDP N, EDP R Indication that the SM delivery to the Mobile Station has failed DPÊT_SMS_Delivered EDP N, EDP R Indication that the SM has been successfully delivered to the Mobile Station. 7.4.3.1.1 Description of the MT SMS state model (PIAs) This subclause describes the state model for terminating SMS transfer. For each PIA a description can be found of the entry events, actions and exit events. 7.4.3.1.1.1 SMS Null & Start & Authorize Entry events: - MAP-MT-FORWARD-SHORT-MESSAGE message is received from SMS-GMSC. - Previous MT SMS transfer to the MS completed (DPÊT_SMS_Delivered). - Exception event is reported. Actions: - Interface is idled. - MT SMS subscription check. - MT SMS CSI is received from the VLR (in the MSC only). Exit events: - MT SMS CSI is analysed. - An exception condition is encountered. 7.4.3.1.1.2 SMS Delivery Entry events: - MT SMS CSI is analysed. (DPÊSMS_Delivery_Request). Actions: - Subscriber paging is performed, if required. - The short message is delivered to the MS. Exit events: - Acknowledge from the MS is received. (DPÊT_SMS_Delivered). A positive acknowledgement is sent to the SMSC. - An exception condition is encountered - this leads to the SMS_Exception PIA. A negative acknowledgement is sent to the SMSC. - Negative acknowledgement from the MS is received (DPÊT_SMS_Failure). A negative acknowledgement is sent to the SMSC. 7.4.3.1.1.3 SMS_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIA cannot be met. Actions: - Default handling of the exception condition is applied. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If a relationship exists between the gsmSCF and gsmSSF or gprsSSF send an error information flow closing the relationship and indicating that any outstanding Short Message handling instructions will not run to completion. - The MSC/gsmSSF or SGSN/gprsSSF shall make use of vendor-specific procedures to ensure release of internal resources. Exit events: - Default handling of the exception condition by MSC/gsmSSF or SGSN/gprsSSF completed. 7.5 Procedures for CAMEL SMS 7.5.1 Functional architecture for CAMEL MO SMS services Note 1: The functional entities depicted by means of dark shaded boxes in the figureÊ7.4 are not affected by CAMEL interaction with MO SMS. Note 2: The Relay Protocol between the MS and the MSC or SGSN is described in 3GPP TSÊ24.011Ê[31]. The Relay Protocol between the MSC or SGSN and the SMS-GMSC is described in 3GPP TSÊ29.002Ê[34]. The Relay Protocol between the SMS-GMSC and the SMSC is not standardised. Examples of this protocol are described in GSM TRÊ03.47Ê[42]. Figure 7.4: MO SMS via MSC or SGSN 7.5.2 Handling of mobile originating SMS 7.5.2.1 Handling of mobile originating SMS in the originating MSC or SGSN The functional behaviour of the originating MSC or SGSN is specified in 3GPP TSÊ29.002Ê[34] and 3GPP TSÊ23.060Ê[15]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_O_SMS_INIT; - Procedure CAMEL_O_SMS_SUBMITTED; - Procedure CAMEL_O_SMS_FAILURE. A CAMEL Service may be invoked for the following Mobile Originated short message types: - Short Message Submission (TPDU type = SMS-SUBMIT) - Short Message Command (TPDU type = SMS-COMMAND) Refer to 3GPP TSÊ23.040Ê[14] for a description of the various TPDU types and to 3GPP TSÊ24.011Ê[31] for a description of the protocol elements of the Short Message Relay Layer (RPDUs). 7.5.2.1.1 Actions of the MSC or SGSN on receipt of Int_Error The MSC or SGSN checks the default SMS Handling parameter in MO SMS CSI. If the default SMS handling is 'releaseTransaction', a A_RP_ERROR is sent to the MS. The MSC or SGSN then releases all resources and the procedure CAMEL_O_SMS_INIT ends. If the default SMS handling is 'continueTransaction', the MSC or SGSN continues processing without CAMEL support. 7.5.2.1.2 Actions of the MSC or SGSN on receipt of Int_Continue_SMS The MSC or SGSN continues processing with modified SM parameters. The MSC or SGSN shall transparently modify the SMS parameters with the received information. Parameters which are not included in the Int_Continue_SMS signal are unchanged. 7.5.2.1.3 Actions of the MSC or SGSN on receipt of Int_Connect_SMS The MSC or SGSN continues processing with modified SM parameters. The MSC or SGSN shall transparently modify the SMS parameters with the received information. Barring is checked with the modified parameters. Parameters which are not included in the Int_Connect_SMS signal are unchanged. 7.5.2.1.4 Actions of the MSC or SGSN on receipt of Int_Release_SMS A_RP_ERROR is sent to the MS and the Short Message is deleted. The SMS cause received in the Int_Release_SMS signal is used. The MSC or SGSN then releases all resources and the procedure CAMEL_O_SMS_INIT ends. 7.5.2.1.5 Allocation of SMS Reference Number During the CAMEL handling of a Mobile Originated Short Message, the MSC or SGSN shall allocate an SMS Reference Number. This SMS Reference Number shall be placed in the SMS-MO Call Detail Record, together with the MSC Address or SGSN Number. This SMS Reference Number shall also be sent to the gsmSCF in the Initial DP SMS Information Flow, together with the MSC Address or SGSN Number. The combination of SMS Reference Number and MSC Address or SGSN Number forms a globally unique pair. This pair may be used for correlation of CDRs produced in the MSC or SGSN with CDRs produced in the gsmSCF. An SMS Reference Number shall be generated and placed in the SMS-MO Call Detail Record, for every Short Message, including the case when a Short Message forms part of a set of concatenated Short Messages."
"7.5.2.2 Handling of A_MM_Release and A_LLC_Release If the radio link with the subscriber is lost during the handling of a CAMEL procedure in the MSC or SGSN, then the MSC or SGSN sends signal A_MM_Release_ind or A_LLC_Release_ind to that procedure. This results in the termination of that CAMEL procedure. (Refer to 3GPP TSÊ29.002Ê[34] for details.) 7.5.2.3 Handling of time-out from SMSC If the MSC or SGSN does not receive a confirmation from the SMSC after submission of a Short Message, then the MSC or SGSN calls procedure CAMEL_O_SMS_FAILURE. (Refer to 3GPP TSÊ29.002Ê[34] for details.) Figure 7.5-1: Procedure CAMEL_O_SMS_INIT (sheet 1) Figure 7.5-2: Procedure CAMEL_O_SMS_INIT (sheet 2) Figure 7.5-3: Procedure CAMEL_O_SMS_INIT (sheet 3) Figure 7.6-1: Procedure CAMEL_O_SMS_SUBMITTED (sheet 1) Figure 7.7-1: Procedure CAMEL_O_SMS_FAILURE (sheet 1) 7.5.2.4 Handling of mobile originating SMS in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ29.002Ê[34] The handling specific to CAMEL is specified in the following procedure: - Procedure CAMEL_MO_SMS_VLR. Figure 7.8-1: Procedure CAMEL_MO_SMS_VLR (sheet 1) 7.5.3 Functional architecture for CAMEL MT SMS services Note 1: The functional entities depicted by means of dark shaded boxes in the figureÊ7.9 are not affected by CAMEL interaction with MT-SMS. Note 2: The Relay Protocol between the MS and the MSC or SGSN is described in 3GPP TSÊ24.011Ê[31]. The Relay Protocol between the MSC or SGSN and the SMS-GMSC is described in 3GPP TSÊ29.002Ê[34]. The Relay Protocol between the SMS-GMSC and the SMSC is not standardised. Examples of this protocol are described in GSM TRÊ03.47Ê[42]. Figure 7.9: MT SMS via MSC or SGSN 7.5.4 Handling of mobile terminating SMS 7.5.4.1 Handling of mobile terminating SMS in the terminating MSC or SGSN A CAMEL Service may be invoked for the following Mobile Terminated short message types: - Short Message Delivery (TPDU type = SMS-DELIVER) - Short Message Status Report (TPDU type = SMS-STATUS-REPORT) Refer to 3GPP TSÊ23.040Ê[14] for a description of the various TPDU types and to 3GPP TSÊ24.011Ê[31] for a description of the protocol elements of the Short Message Relay Layer (RPDUs). The functional behaviour of the terminating MSC or SGSN is specified in 3GPP TSÊ29.002Ê[34]. The procedures specific to CAMEL are specified in the following subclauses: 7.5.4.1.1 Procedure CAMEL_T_SMS_INIT; This procedure is called when a Short Message delivery attempt is received from the SMS-GMSC. If MT SMS CSI is present for the subscriber, then the SMS_SSF shall be invoked. Otherwise, the Short Message delivery attempt proceeds without CAMEL. When the SMS_SSF is invoked and the SMS_SSF has requested the gsmSCF for instructions, the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The gsmSCF has indicated that SM delivery may proceed. It may have supplied the SMS_SSF with a modified Calling Party Number. This Calling Party Number shall replace the TP-Originating-Address in the SMS-DELIVER TPDU. - Int_Release_SMS The gsmSCF has force-released SM delivery. The RP Cause received from the gsmSCF shall be conveyed to the SMS-GMSC in the RP-Cause component, in the RP-ERROR RPDU. - Int_Error A Tssf time-out or an internal SMS_SSF error has occurred; the SM has not been forwarded to the Mobile Station. If Default SMS Handling equals 'Continue', the SM delivery proceeds. Otherwise, SM delivery shall be aborted. In the latter case, the RP-Cause component, in the RP-ERROR RPDU shall be set to EquipmentProtocolError, in accordance with 3GPP TSÊ29.002Ê[34]. 7.5.4.1.2 Procedure CAMEL_T_SMS_DELIVERED This procedure is called when the MSC or SGSN has detected that delivery of the SM to the Mobile Station has succeeded. No event specific information is sent to the gsmSCF. When Short Message delivery attempt success has been reported to the gsmSCF, then the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The event was reported to the gsmSCF in interrupt mode. The gsmSCF has concluded CAMEL processing and has terminated the Service Logic. - Int_Continue The event was not reported to the gsmSCF or was reported in notification mode. - Int_Error A Tssf time-out has occurred. In all the above cases, the SM processing in the MSC or SGSN continues. 7.5.4.1.3 Procedure CAMEL_T_SMS_FAILURE This procedure is called when the MSC or SGSN has detected that delivery of the SM to the Mobile Station has failed. If the delivery failure is due to RP-ERROR RPDU received from the MS, then the MT SMS Cause in the event report to the gsmSCF shall be set to the RP-Cause component in the RP-ERROR-RPDU. Otherwise, if the delivery failure is due to internal failure in the MSC or SGSN, CP-ERROR from MS or time-out from the MS, then the MT SMS Cause in the event report to the gsmSCF shall be set to ""Protocol error, unspecified"", as defined in 3GPP TSÊ24.011Ê[31]. When Short Message delivery attempt failure has been reported to the gsmSCF, then the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The event was reported to the gsmSCF in interrupt mode. The gsmSCF has concluded CAMEL processing and has terminated the Service Logic. - Int_Continue The event was not reported to the gsmSCF or was reported in notification mode. - Int_Error A Tssf time-out has occurred. In all the above cases, the SM processing in the MSC or SGSN continues. 7.5.4.1.4 Allocation of SMS Reference Number During the CAMEL handling of a Mobile Terminating Short Message, the MSC or SGSN shall allocate an SMS Reference Number. This SMS Reference Number shall be placed in the SMS-MT Call Detail Record, together with the MSC Address or SGSN Number. This SMS Reference Number shall also be sent to the gsmSCF in the Initial DP SMS Information Flow, together with the MSC Address or SGSN Number. The combination of SMS Reference Number and MSC Address or SGSN Number forms a globally unique pair. This pair may be used for correlation of CDRs produced in the MSC or SGSN with CDRs produced in the gsmSCF. An SMS Reference Number shall be generated and placed in the SMS-MT Call Detail Record, for every Short Message, including the case when a Short Message forms part of a set of concatenated Short Messages. Figure 7.10-1: Procedure CAMEL_T_SMS_INIT (sheet 1) Figure 7.10-2: Procedure CAMEL_T_SMS_INIT (sheet 2) Figure 7.11-1: Procedure CAMEL_T_SMS_FAILURE (sheet 1) Figure 7.12-1: Procedure CAMEL_T_SMS_DELIVERED (sheet 1) 7.5.4.2 Handling of mobile terminating SMS in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ29.002Ê[34]. The handling specific to CAMEL is specified in the following procedure: - Procedure CAMEL_MT_SMS_VLR. Figure 7.13-1: Procedure CAMEL_MT_SMS_VLR (sheet 1) 7.5.4.3 CAMEL subscription check for mobile terminating SMS in the SGSN The functional behaviour of the SGSN for delivery of MT shrt message is specified in 3GPP TSÊ29.002Ê[34]. The procedure for checking CAMEL capability and subscription information is specified in the following procedure: - Procedure CAMEL_MT_SMS_SGSN. Figure 7.14-1: Procedure CAMEL_MT_SMS_SGSN (sheet 1) 7.5.5 Handling of mobile originating and mobile terminating SMS in the gsmSSF or gprsSSF 7.5.5.1 Process SMS_SSF Sheet 1 The Int_Invoke SMS_SSF signal dictates which TDP shall be armed. For a Mobile Originated SMS service, the SMS_Collected_Info TDP shall be armed. For a Mobile Terminated SMS service, the SMS_Delivery_Request TDP shall be armed. Sheet 2 The Int_SMS_Failure signal may be received only for a MO-SMS service. It is received when a MS detach event occurs before the SMS_SSF is invoked. Sheet 3 The SMSC Address and Destination Subscriber Number may be received in CAP ConnectSMS only for a MO-SMS service. Sheet 4: For a MO-SMS service, the following events may be armed or disarmed: O_SMS_Submission, O_SMS_Failure. For a MT-SMS service, the following events may be armed or disarmed: T_SMS_Delivery, T_SMS_Failure. Sheet 5: For a MO-SMS service, the gsmSCF may place free-format charging data in the 'MOSMSRecord' CDR (in the MSC) or in the S-SMO-CDR (in the SGSN). For a MT-SMS service, the gsmSCF may place free-format charging data in the 'MTSMSRecord' (in the MSC) or in the S-SMT-CDR (in the SGSN). Refer to 3GPP TSÊ32.250Ê[37] and 3GPP TSÊ32.251Ê[38] for a description of these CDR types. Sheet 6: The Int_SMS_Failure signal in state Waiting_For_Instructions may be received for a MO-SMS service only. It is received when a MS detach event occurs before the gsmSCF has given instruction to continue SM processing. Sheet 7: When the SM submission or failure event occurs, both MO-SMS events shall be disarmed. When the SM delivery or failure event occurs, both MT-SMS events shall be disarmed. 7.5.5.2 Process Complete_SMS_FCI_Record Sheet 1: For a MO-SMS service, the 'MOSMSRecord' or 'S-SMO-CDR' shall be closed. For a MT-SMS service, the 'MTSMSRecord' or 'S-SMT-CDR' shall be closed. Figure 7.15-1: Process SMS_SSF (sheet 1) Figure 7.15-2: Process SMS_SSF (sheet 2) Figure 7.15-3: Process SMS_SSF (sheet 3) Figure 7.15-4: Process SMS_SSF (sheet 4) Figure 7.15-5: Process SMS_SSF (sheet 5) Figure 7.15-6: Process SMS_SSF (sheet 6) Figure 7.15-7: Process SMS_SSF (sheet 7) Figure 7.16-1: Procedure Check_Criteria_SMS_Delivery_Request (Sheet 1) Figure 7.17-1: Procedure Complete_SMS_FCI_record (sheet 1) 7.6 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for SMS control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Optional (O), Specific conditions (S), mutually Exclusive (E), or not applicable (-) for each different traffic case: Mobile Originating SMS (MO) and Mobile Terminating SMS (MT). If the IEs in one table apply in both the MO and MT cases, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The distinction between MO and MT SMS applies only to the Information Flows between the gsmSCF and the gsmSSF or gprsSSF. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34], TSÊ29.078Ê[36]. 7.6.1 gsmSSF or gprsSSF to gsmSCF information flows 7.6.1.1 Event Report SMS 7.6.1.1.1 Description This IF is used to notify the gsmSCF of an event previously requested by the gsmSCF in a Request Report SMS Event IF. 7.6.1.1.2 Information Elements Information element name MO MT Description Event Type M M This IE specifies the type of event that is reported. Event Specific Information C C This IE indicates the SMS related information specific to the event. Misc SMS Info M M This IE indicates the DP type. If the Event Type IE indicates O_SMS_Failure, then the Event Specific Information contains the following information element: Information element name MO MT Description MO_SMS Cause M - This IE indicates the reason of submission failure. If the Event Type IE indicates T_SMS_Failure, then the Event Specific Information contains the following information elements: Information element name MO MT Description MT_SMS Cause - M This IE indicates the reason of delivery failure. If the Event Type IE indicates O_SMS_Submitted or T_SMS_Delivered, then no Event Specific Information shall be sent to the gsmSCF. 7.6.1.2 Initial DP SMS 7.6.1.2.1 Description This IF is generated by the gsmSSF or gprsSSF when a trigger is detected at a DP in the state model, to request instructions from the gsmSCF. 7.6.1.2.2 Information Elements Information element name MO MT Description Destination Subscriber Number M - This IE contains a number to identify the Destination short message entity. The Destination Subscriber Number shall be retrieved from the TP-Destination-Address in the SMS-SUBMIT TPDU or the SMS-COMMAND TPDU. Called Party Number - M This IE contains a number to identify the subscriber for whom the Short Message is destined. The Called Party Number shall be the MSISDN of the served subscriber. Calling Party Number M C For MO SMS: This IE contains a number to identify the subscriber who requests the SM submission. The Calling Party Number shall be the MSISDN of the served subscriber. For MT SMS: This IE contains the address of the submitter of the short message. For SMS-DELIVER TPDU, the Calling Party Number shall be retrieved from the TP-Originating-Address in the SMS-DELIVER TPDU. For SMS-STATUS-REPORT TPDU, this element shall not be included in this IF. Event Type M M This IE indicates the armed event resulting in the Initial DP SMS IF. IMSI M M This IE identifies the mobile subscriber. Location Information In MSC C C This IE is described in a table below. Location Information In SGSN C C This IE is described in a table below. Service Key M M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application/SLP within the gsmSCF. Time And Timezone M M This IE contains the time that the gsmSSF or gprsSSF was triggered, and the time zone the gsmSSF or gprsSSF resides in. TP Short Message Specific Information M M This IE contains the first octet of the applicable TPDU. For SMS-SUBMIT, the following elements may be included: - Message Type Indicator - Reject Duplicates - Validity Period Format - Status Report Request - User Data Header Indicator - Reply Path For SMS-COMMAND, the following elements may be included: - Message Type Indicator - User Data Header Indicator - Status Report Request For SMS-DELIVER, the following elements may be included: - Message Type Indicator - More Messages to Send - Status Report Indication - User Data Header Indicator - Reply Path For SMS-STATUS-REPORT, the following elements may be included: - Message Type Indicator - More Messages to Send - Status Report Qualifier - User Data Header Indicator Refer to 3GPP TSÊ23.040Ê[14] for an indication of which elements of this 1st octet are Mandatory and which elements are Conditional. TP Protocol Identifier M C This IE indicates the protocol used above SM-Transfer Layer. The TP Protocol Identifier shall be retrieved from the applicable TPDU. For SMS-STATUS-REPORT, the sending of this IE is Conditional, depending on its presence in the SMS-STATUS-REPORT TPDU. TP Data Coding Scheme C C This IE indicates the data coding scheme of the TP User Data field, and may indicate a message class. The message class may indicate e.g. the originator of the Short Message. The TP Data Coding Scheme shall be retrieved from the applicable TPDU. For SMS-COMMAND, this IE shall not be included in this IF. TP Validity Period S - This IE indicates the length of the validity period or the absolute time of the validity period termination. This IE is used only for the SMS-SUBMIT TPDU. The TP Validity Period, if available, shall be retrieved from the SMS-SUBMIT TPDU. For other TPDU, this IE shall not be included in this IF. SMSC Address M M For MO SMS: This IE defines the address of the SMSC to which the MO short message is intended to be submitted. It shall be retrieved from the RP-Destination-Address in the RP-MO-DATA RPDU. For MT SMS: This IE identifies the address of the SMSC from which the MT short message is originating. It shall be retrieved from the RP-Originating-Address in the RP-MT-DATA RPDU. SMS Reference Number M M This IE carries the SMS Reference Number. This Reference Number is allocated by the MSC or SGSN that processes the Short Message. It may be used by the gsmSCF for inclusion in a gsmSCF SMS record. MSC Address S S This IE carries the E.164 MSC Address. This IE shall be present if the Short Message processing takes place in an MSC. Otherwise shall be absent. SGSN Number S S This IE carries the Global Title of the SGSN. See 3GPP TSÊ23.060Ê[15]. This IE shall be present if the Short Message processing takes place in an SGSN. Otherwise shall be absent. GPRS MS Class C - This IE contains the MS network and radio access capabilities if the short message is being transferred through an SGSN. MS Classmark 2 C - This IE contains the MS classmark 2 if the short message is being transferred through an MSC. IMEI (with software version) C - This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Note: Refer to 3GPP TSÊ23.040Ê[14] for a description and encoding of the various TP-DUs and RP-DUs. Location Information in MSC is based on the Location Information IE defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name MO MT Description Service area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. VLR number M M See 3GPP TSÊ23.018Ê[12]. Age of location information - M See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - - Not applicable Selected LSA Identity S S This IE is applicable only if SoLSA is supported by the MSC. This IE indicates the LSA identity associated with the current position of the MS. It shall be shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority shall be present. See 3GPP TSÊ23.073Ê[18]. User CSG Information C C See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location Information in SGSN is based on the Location Information For GPRS IE defined in the subclauseÊ11.3.6.1.2. The following differences and clarifications apply: Information element name MO MT Description Service area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Routeing area ID C C See 3GPP TSÊ23.003Ê[7]. Geographical information C C See 3GPP TSÊ23.032Ê[13]. Geodetic information - - Not applicable Age of location information - - Not applicable Current Location Retrieved - - Not applicable User CSG Information C C See 3GPP TSÊ23.060Ê[15]. 7.6.2 gsmSCF to gsmSSF or gprsSSF information flows 7.6.2.1 Connect SMS 7.6.2.1.1 Description This IF is used to request the gsmSSF or gprsSSF to perform the actions to route the Short Message to a specific destination (for MO SMS) or to deliver the Short Message to the MS (for MT SMS). 7.6.2.1.2 Information Elements Information element name MO MT Description Calling Partys Number O O This IE indicates the subscriber who sent the SMS; possibly changed by the gsmSCF. If the Short Message type is SMS-SUBMIT or SMS-COMMAND, then this IE, if present, it shall replace the RP-Originating-Address in the RP-MO-DATA RPDU (CHOICE set to MSISDN). If the Short Message type is SMS-DELIVER, then this IE, if present, shall replace the TP-Originating-Address in the SMS-DELIVER TPDU. If the Short Message type is SMS-STATUS-REPORT, then this IE, if present, shall be ignored. Destination Subscriber Number O - This IE identifies the Destination short message entity; possibly changed by the gsmSCF. This IE, if present, shall replace the TP-Destination-Address in the SMS-SUBMIT TPDU or SMS-COMMAND-TPDU. SMSC Address O - This IE indicates the SMSC address to which the MO short message shall be submitted; possibly changed by the gsmSCF. This IE, if present, shall replace the RP-Destination-Address in the RP-MO-DATA RPDU (CHOICE set to serviceCentreAddressDA). 7.6.2.2 Continue SMS 7.6.2.2.1 Description This information flow requests the gsmSSF or gprsSSF to proceed normally. The gsmSSF or gprsSSF completes DP processing, and continues with the SMS handling. 7.6.2.2.2 Information Elements This IF contains no information elements. 7.6.2.3 Furnish Charging Information SMS 7.6.2.3.1 Description This IF is used to request the gsmSSF or gprsSSF to include information in the CAMEL specific logical MO SMS or MT SMS record. The logical call record is created when FCI-SMS is received and a logical call record for that short message does not exist. For modelling purposes the logical call record is buffered in the gsmSSF or gprsSSF. The gsmSSF or gprsSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then its free format data are moved to the corresponding CDR and the logical call record is deleted. The gsmSCF can send multiple concatenated FCIs per Short Message for completion. The total maximum of free format data is 160 octets per SM. The 160 octets may be sent in one or more FCI IFs. If there are incomplete free format data and new FCI IFs is/are received to overwrite the incomplete data, then the incomplete data are discarded and the gsmSCF can send another 160 octets per SM. 7.6.2.3.2 Information Elements Information element name MO MT Description FCI Billing Charging Characteristics M M This IE is described in a table below. FCI Billing Charging Characteristics contains the following information element: Information element name MO MT Description FCIBCCCAMEL Sequence 1 M M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information elements: Information element name MO MT Description Free Format Data M M This IE contains free format data to be inserted in the CAMEL logical call record. Append Free Format Data O O This IE indicates that the gsmSSF or gprsSSF shall append the free format data to the Logical MO SMS or MT SMS record. - If this IE is present indicating ""Append"", the gsmSSF or gprsSSF shall append the free format data received in this IF to the free format data already present in the Logical MO SMS or MT SMS record. - If this IE is absent or indicates ""Overwrite"", then the gsmSSF shall overwrite all free format data already present in the Logical MO SMS or MT SMS record, by the free format data received in this IF. If no Logical MO SMS or MT SMS record exists yet, then the gsmSSF or gprsSSF shall ignore this IE. 7.6.2.4 Release SMS 7.6.2.4.1 Description This IF is used to tear down by the gsmSCF an existing SMS transfer. 7.6.2.4.2 Information Elements Information element name MO MT Description RP Cause M M SMS Cause. Indicates the SMS specific cause of the release. The cause is reported to the MS (in the case of MO SMS) or SMSC (in the case of MT SMS). For MO SMS, the RP Cause value shall be used to set the RP-Cause in the RP-ERROR RPDU sent to the MS. 3GPP TSÊ24.011Ê[31] specifies which RP-Cause values may be sent to the MS. For MT SMS, the RP Cause value shall be used to set the RP-Cause in the RP-ERROR RPDU sent to the SMSC. 3GPP TSÊ29.002Ê[34] specifies which RP-Cause values may be sent to the SMSC. 7.6.2.5 Request Report SMS Event 7.6.2.5.1 Description This IF is used to request the gsmSSF or gprsSSF to monitor for an event and to send a notification to the gsmSCF when the event is detected (see Event Report SMS IF). 7.6.2.5.2 Information Elements Information element name MO MT Description SMS Event M M This IE specifies the event or events of which a report is requested. SMS Event contains the following information elements: Information element name MO MT Description Event Type M M This IE specifies the type of event of which a report is requested. Monitor Mode M M This IE indicates how the event shall be reported. 7.6.2.6 Reset Timer SMS 7.6.2.6.1 Description This IF is used to refresh a gsmSSF or gprsSSF timer. 7.6.2.6.2 Information Elements Information element name MO MT Description Timer Value M M This IE specifies the value to which the indicated timer shall be set. Timer ID O O This IE indicates which timer shall be reset. It shall be set to 'Tssf'. 7.6.3 HLR to VLR or SGSN information flows 7.6.3.1 Delete Subscriber Data 7.6.3.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from a VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34] 7.6.3.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in VLR or SGSN. Specific CSI Withdraw O This IE is used to indicate that only MO SMS CSI or MT SMS CSI shall be deleted from the VLR or SGSN. This IE should not be present when CAMEL Subscription Info Withdraw is present. 7.6.3.2 Insert Subscriber Data 7.6.3.2.1 Description This IF is used by the HLR to insert subscriber data in the VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.3.2.2 Information Elements The Insert Subscriber Data contains the following CAMEL specific information elements: Information element name Status Description MO SMS CSI O This IE identifies the subscriber as having MO SMS CAMEL services. MT SMS CSI O This IE identifies the subscriber as having MT SMS CAMEL services. MO SMS CSI contains the following information elements: Information element name Status Description gsmSCF Address M See subclauseÊ7.3.1.1. Service Key M See subclauseÊ7.3.1.2. Default SMS Handling M See subclauseÊ7.3.1.3. CAMEL Capability Handling M See subclauseÊ7.3.1.5. SMS Triggers M See subclauseÊ7.3.1.4. It includes the following trigger: SMS_Collected_Info MT SMS CSI contains the following information elements: Information element name Status Description gsmSCF Address M See subclauseÊ7.3.2.1. Service Key M See subclauseÊ7.3.2.2. Default SMS Handling M See subclauseÊ7.3.2.3. CAMEL Capability Handling M See subclauseÊ7.3.2.6. SMS Triggers M See subclauseÊ7.3.2.4. It includes the following trigger: SMS_Delivery_Request. SMS Trigger Criteria C See subclauseÊ7.3.2.5. 7.6.4 VLR or SGSN to HLR information flows 7.6.4.1 Insert Subscriber Data ack See subclauseÊ4.6.8.1. This information flow is sent by the VLR. 7.6.4.2 Update Location See subclauseÊ4.6.8.3. 7.6.4.3 Update GPRS Location 7.6.4.3.1 Description This IF is used by the SGSN to indicate to the HLR the CAMEL phases and CAMEL phaseÊ4 CSIs offered by the SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.4.3.2 Information Elements Update GPRS location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which CAMEL phases are supported by the SGSN. The SGSN may indicate support of CAMEL phaseÊ3 or higher. It shall be present when the SGSN supports CAMEL. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases"" IE contains support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI 7.6.5 VLR to MSC Information Flows 7.6.5.1 Continue CAMEL SMS Handling 7.6.5.1.1 Description This IF is used to instruct the MSC to continue the CAMEL specific handling. 7.6.5.1.2 Information Elements Information element name Status Description MT SMS CSI M This IE contains the CAMEL Subscription Information for MT SMS. IMSI M IMSI of the served subscriber. MSISDN M MSISDN of the served subscriber. 7.6.5.2 Send Info For MO SMS ack 7.6.5.2.1 Description This IF is used to transport MO SMS related subscription data from the VLR to the MSC. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.5.2.2 Information Elements Information element name Status Description MO SMS CSI C This IE contains the CAMEL Subscription Information for MO SMS. ODB Data C This IE contains ODB data. This information is used to apply ODB for a reconnected Short Message, if needed. CB SS Data C This IE contains CB SS data. This information is used to apply CB for a reconnected Short Message, if needed. 7.6.6 MSC to VLR Information Flows 7.6.6.1 Send Info For MT SMS 7.6.6.1.1 Description This IF is described in 3GPP TSÊ29.002Ê[34]; it is used to request the VLR to provide information to handle an MT SMS. 7.6.6.1.2 Information Elements Send Info For MT SMS contains the following CAMEL specific information element: Information element name Status Description Suppress MT SMS CSI S This IE indicates to the VLR that it shall not return MT SMS CSI to the MSC. This IE shall not be present in the first interrogation; it shall be present in the second interrogation. 8 SS Notifications 8.1 Architecture 8.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support Supplementary Service (SS) Notifications. FigureÊ8.1 shows the functional entities involved in sending SS Notifications. The architecture is applicable to the third phase of CAMEL or higher. Figure 8.1: Functional architecture for support of SS Notifications HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription regarding SS CSI. The SS CSI is sent to the VLR at Location Update, on Data Restoration or if the SS CSI is updated by administrative action. When processing an invocation of the CCBS supplementary service, the HLR shall send a notification of the invocation of the supplementary service to the gsmSCF if required by the SS CSI. MSC: When processing an invocation of any of the supplementary services ECT, CD and MPTY, the MSC may receive an SS CSI from the VLR, indicating that a notification of the invocation of the supplementary service shall be sent to the gsmSCF. VLR: The VLR stores the SS CSI as a part of the subscriber data for subscribers roaming in the VLR area. gsmSCF: The gsmSCF receives the SS Invocation Notification from the MSC or HLR. 8.1.2 Interfaces defined for SS Notifications This subclause describes the different interfaces applicable to SS Notifications. It specifies on a high level the functions specific to SS Notifications. 8.1.2.1 MSC - gsmSCF interface This interface is used by the MSC to send supplementary service invocation notifications to the gsmSCF. The SS invocations that can be notified to the gsmSCF via this interface are Call Deflection (CD), Explicit Call Transfer (ECT) and Multi Party (MPTY). 8.1.2.2 HLR - gsmSCF interface This interface is used by the HLR to send supplementary service invocation notifications to the gsmSCF. The SS invocation that can be notified to the gsmSCF via this interface is Call Completion to Busy Subscriber (CCBS). 8.1.2.3 VLR - MSC interface This interface is used by the VLR to transfer SS CSI to the MSC. 8.1.2.4 HLR-VLR interface This interface is used by the HLR to send the SS CSI to the VLR or to remove SS CSI from the VLR. 8.2 Description of CAMEL Subscriber Data 8.2.1 Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI) This subclause defines the contents of the Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI). 8.2.1.1 Notification criteria This data indicates for which supplementary services notifications shall be sent. The supplementary services which may be indicated are ECT, CD, CCBS and MPTY. 8.2.1.2 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 8.2.1.3 CSI state The CSI state indicates whether the SS CSI is active or not. 8.2.1.4 Notification flag The notification flag indicates whether the change of the SS CSI shall trigger Notification on Change of Subscriber Data or not. 8.2.2 gsmSCF address list for CSI The gsmSCF address list indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 8.3 Procedures for CAMEL 8.3.1 Handling of Supplementary Service Invocation Notification At the invocation of any of the services ECT, CD and MPTY the VLR checks whether the criteria for sending a notification are fulfilled, i.e. whether the subscriber is provisioned with the SS CSI and the particular invoked supplementary service is marked in the SS CSI. If this is the case a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS CSI. The processing of the particular SS invocation is not suspended. If the notification criteria are not fulfilled the processing of the particular supplementary service continues unchanged and no notification is sent. The sending of the notification is independent of call related CAMEL processing, i.e. processing indicated by O/D/T/VT CSI. On invocation of ECT, the VLR shall include the SS CSI in the Invoke ECT response message (see Process MAF027 in 3GPP TSÊ23.091Ê[25]) to the MSC if applicable for ECT. On invocation of MPTY, the VLR shall include the SS CSI in the Process MPTY message (see Process MPTY_MAF026 in 3GPP TSÊ23.084Ê[21]) to the MSC if applicable for MPTY. On invocation of CD, the VLR shall include the SS CSI in the Send Info For Incoming Call ack information flow to the MSC if applicable to CD (see 3GPP TSÊ23.072Ê[16]). When a subscriber activates a CCBS request, the HLR checks whether the criteria for sending a notification are fulfilled, i.e. whether - The subscriber is provisioned with an active SS CSI, and - CCBS is marked in the SS CSI. If the criteria are fulfilled, a notification is immediately sent to the gsmSCF given by the gsmSCF address contained in the SS CSI and the processing of the CCBS request continues. Whenever the state of the CCBS request changes (see 3GPP TSÊ23.093Ê[26]), an additional notification is immediately sent to the gsmSCF and the processing of the CCBS request continues. If the criteria are not fulfilled, the processing of the CCBS request continues unchanged and no notifications are sent. At the invocation of the CCBS supplementary service, the HLR checks whether the criteria for sending a notification are fulfilled, i.e. whether the subscriber is provisioned with the SS CSI and the particular invoked supplementary service is marked in the SS CSI. If this is the case, a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS CSI. The processing of the SS invocation is not suspended. If the notification criteria are not fulfilled the processing of the particular supplementary service continues unchanged and no notification are sent. 8.4 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for notification of Supplementary Service invocation. Each Information Element (IE) is marked as Mandatory (M), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.002Ê[34]. 8.4.1 MSC to gsmSCF information flows 8.4.1.1 SS Invocation Notification 8.4.1.1.1 Description This IF is generated by the MSC when it shall notify the gsmSCF of a supplementary service invocation. 8.4.1.1.2 Information Elements Information element name Status Description Notification Event M This IE indicates the supplementary service invocation, resulting in the SS Invocation Notification IF. Only the following supplementary services are allowed: Explicit Call Transfer, Call Deflection, Multi Party. Notification Event Specific Information S In the case of ECT, the sending entity shall include the called party for each call originated by the subscriber and relevant to the ECT invocation. Note: the subscriber may have originated zero, one or two calls relevant to the ECT service. In the case of CD, the deflected to number shall be included in this IE. In the case of MPTY, this IE shall be omitted. IMSI M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. MSISDN M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. 8.4.2 HLR to VLR information flows 8.4.2.1 Delete Subscriber Data 8.4.2.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from a VLR. Ii is specified in 3GPP TSÊ29.002Ê[34]. 8.4.2.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements for SS Notifications: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in the VLR. Specific CSI Withdraw O This IE is used to indicate that only SS CSI shall be deleted from the VLR. This IE should not be present when CAMEL Subscription Info Withdraw is present. 8.4.2.2 Insert Subscriber Data 8.4.2.2.1 Description This IF is used by an HLR to update a VLR with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 8.4.2.2.2 Information Elements The Insert Subscriber Data contains the following CAMEL specific information element for SS Notifications: Information element name Status Description SS CSI O This IE is described in subclauseÊ8.2.1. This IE identifies the subscriber as having supplementary service invocation notification services. It contains the Notification Criteria and gsmSCFAddress. When SS CSI is sent to the VLR, it shall not contain a marking for CCBS."
"8.4.3 HLR to gsmSCF information flows 8.4.3.1 SS Invocation Notification This IF is generated by the HLR when it shall notify the gsmSCF of a supplementary service invocation. 8.4.3.1.2 Information Elements Information element name Status Description Notification Event M This IE indicates the supplementary service invocation, resulting in the SS Invocation Notification IF. Only the following supplementary services are allowed: Completion of Calls to Busy Subscriber IMSI M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. MSISDN M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. B-Number M This IE indicates the destination address of the CCBS request. CCBS Request State M This IE identifies the current state of the CCBS request. It can be one of: - Request; - Recall; - Active; - Completed; - Suspended; - Frozen; - Deleted. 8.4.4 VLR to MSC information flows 8.4.4.1 Invoke SS result 8.4.4.1.1 Description This IF is used by the VLR to send SS CSI to the MSC. This IF is specified in 3GPP TSÊ29.002Ê[34]. 8.4.4.1.2 Information Elements The Invoke SS result contains the following CAMEL specific information element for SS Notifications: Information element name Status Description SS CSI C This IE is included when it is available in the VLR and either ECT or MPTY has been successfully invoked and that supplementary service has been marked for notification. 8.4.4.2 Send Info For Incoming Call ack 8.4.4.2.1 Description This IF is used by the VLR to send SS CSI to the MSC. This IF is specified in 3GPP TSÊ23.018Ê[12]. 8.4.4.2.2 Information Elements The Send Info For Incoming Call ack contains the following CAMEL specific information elements for SS Notifications: Information element name Status Description SS CSI S This IE is included when it is available in the VLR and CD has been successfully invoked and that supplementary service has been marked for notification. 9 Mobility Management 9.1 Architecture 9.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture required to support Mobility Management in CAMEL. FiguresÊ9.1-1 and 9.1-2 show the functional entities involved in CAMEL support of Mobility Management. The architecture in the figureÊ9.1-1 is applicable to the third phase of CAMEL or higher and the architecture in the figureÊ9.1-2 is applicable to the fourth phase of CAMEL. Figure 9.1-1: Functional architecture for CS subscriber support of CAMEL Figure 9.1-2: Functional architecture for GPRS subscriber support of CAMEL gsmSCF: see subclauseÊ3.1. HLR: The HLR contains Mobility management CAMEL Subscription Information (M CSI) for those CS subscribers that require CAMEL control of Mobility Management events and Mobility management GPRS CAMEL Subscription Information (MG CSI) for those GPRS subscribers that require CAMEL control of Mobility Management events. M CSI is sent to the VLR during the Location Update and Restore Data procedures or when M CSI is modified in the HLR. The M CSI is deleted in the VLR with the Delete Subscriber Data procedure. MG CSI is sent to the SGSN during the GPRS Location Updating procedure or when MG CSI is modified in the HLR. The MG CSI is deleted in the SGSN with the Delete Subscriber Data procedure. MS: Mobile Station. MSC: see subclauseÊ4.1. VLR: After having completed a Mobility Management event from a CS subscriber, the VLR may find it necessary to send a notification to the gsmSCF. The content of M CSI indicates which Mobility Management events shall be reported to the gsmSCF. SGSN: After having completed a Mobility Management event from a GPRS subscriber, the SGSN may find it necessary to send a notification to the gsmSCF. The content of MG CSI indicates which Mobility Management events shall be reported to the gsmSCF. 9.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL control of Mobility Management events. It specifies on a high level the functions specific to CAMEL. 9.1.2.2 VLR - gsmSCF interface This interface is used by the VLR to send Mobility Management event notifications to the gsmSCF. When processing a mobility management event, the VLR may find it necessary to send a notification to the gsmSCF, depending on the presence of M CSI for the subscriber and the contents of M CSI. 9.1.2.3 SGSN - gsmSCF interface This interface is used by the SGSN to send Mobility Management event notifications to the gsmSCF. When processing a mobility management event, the SGSN may find it necessary to send a notification to the gsmSCF, depending on the presence of MG CSI for the subscriber and the contents of MG CSI. 9.2 Description of CAMEL Subscriber Data 9.2.1 Mobility Management CAMEL Subscription Information (M CSI) This subclause specifies the contents of the Mobility Management CAMEL Subscription Information (M CSI). 9.2.1.1 Mobility Management Triggers This data indicates which Mobility Management events shall result in a notification to the gsmSCF. One or more events may be marked per subscriber. These events are: - Location update in the same VLR service area. - Location update to another VLR service area. - IMSI attach. - MS initiated IMSI detach (explicit detach). - Network initiated IMSI detach (implicit detach). 9.2.1.2 gsmSCF address This is the address of the gsmSCF where the Mobility Management event notification shall be sent to. The gsmSCF address is in E.164 format. 9.2.1.3 Service Key The Service Key is included in the notification information flow to the gsmSCF. It indicates to the gsmSCF which Service Logic shall be applied. 9.2.1.4 CSI state The CSI state indicates whether the M CSI is active or not. 9.2.1.5 Notification flag The notification flag indicates whether the change of the M CSI shall trigger Notification on Change of Subscriber Data or not. 9.2.2 Mobility Management for GPRS CAMEL Subscription Information (MG CSI) This subclause specifies the contents of the Mobility Management for GPRS CAMEL Subscription Information (MG CSI). 9.2.2.1 Mobility Management Triggers This data indicates which Mobility Management events shall result in a notification to the gsmSCF. One or more events may be marked per subscriber. These events are: - Routeing area update of MS to a different SGSN service area (update from mew SGSN); - Routeing area update of MS to a different SGSN service area (disconnect by detach); - Routeing area update of MS within the same SGSN service area; - GPRS attach (e.g. MS switched on, successful routeing area update after network initiated transfer to ""MS not reachable for paging""); - MS-initiated GPRS detach (e.g. MS switched off); - Network-initiated GPRS detach. - Network-initiated transfer to the ""not reachable for paging"" state (the network has not received a periodic routeing area update from the MS and assumes that the MS is unreachable). 9.2.2.2 gsmSCF address This is the address of the gsmSCF where the Mobility Management event notification shall be sent to. The gsmSCF address is in E.164 format. 9.2.2.3 Service Key The Service Key is included in the notification information flow to the gsmSCF. It indicates to the gsmSCF which Service Logic shall be applied. 9.2.2.4 CSI state The CSI state indicates whether the MG CSI is active or not. 9.2.2.5 Notification flag The notification flag indicates whether the change of the MG CSI shall trigger Notification on Change of Subscriber Data or not. 9.2.3 gsmSCF address list for CSI The gsmSCF address list indicates the gsmSCF addresses to which Notification on Change of Subscriber Data shall be sent. This list is common to all CSI. 9.3 Procedures for Mobility management 9.3.1 Procedures for Mobility management for CS subscriber The different procedures for Mobility Management are shown in Figures 9.2-1 to 9.2-5. Figure 9.2-1: Location Update within a single VLR Service Area. (The VLR Service area may be in the HPLMN or in the VPLMN.); Figure 9.2-2: Location Update from one VLR Service Area to another VLR Service Area. (Both VLR Service Areas are in the HPLMN or in the same VPLMN.); Figure 9.2-3: Location Update from one PLMN to another PLMN; - update from HPLMN to VPLMN; - update from VPLMN to HPLMN; - update from one VPLMN to another VPLMN. Figure 9.2-4: IMSI Detach (in HPLMN or in VPLMN); - explicit detach (the MS has been switched off by the subscriber); - implicit detach (the network has not received a periodic paging update from the MS and assumes that the MS is switched off or unreachable). Figure 9.2-5: IMSI Attach (in HPLMN or in VPLMN); - attach (the MS has been switched on by the subscriber - subscription data is still available in the VLR, no location update is needed). Figure 9.2-1: Location Update within a single VLR Service Area Figure 9.2-2: Location Update from one VLR Service Area to another VLR Service Area Figure 9.2-3: Location Update from one PLMN to another PLMN Figure 9.2-4: IMSI Detach (implicit/explicit) Figure 9.2-5: IMSI Attach When a Mobility Management Event has taken place and the processing has been completed, then the VLR may find it necessary to send a notification to the gsmSCF. The processing of the Mobility Management event in the VLR is not suspended by the sending of the notification nor is it in any way affected by the notification. The sending of a Mobility Management notification to gsmSCF is independent of other CAMEL subscription data for a subscriber. E.g. a subscriber may have M CSI without O CSI or VT CSI. The sending of a Mobility Management event notification is subscription based. Refer to subclauseÊ9.2.1 for a description of M CSI and the different Mobility Management events that may lead to a notification to the gsmSCF. 9.3.1.1 Procedure descriptions 9.3.1.1.1 Procedure Set_Notification_Type This procedure is called from process Update_Location_VLR in 3GPP TSÊ23.012Ê[10]. It checks the information element 'Location Update Type', which the VLR receives from the MSC via MAP_UPDATE_LOCATION_AREA service. This element identifies the type of Location Update requested by the mobile station. The possible values of this parameter are specified in 3GPP TSÊ24.008Ê[30]. The type of Location Update that was requested by the mobile station determines which Mobility Management notification information flow shall be sent to the gsmSCF. The values 'Periodic Updating' and 'Reserved' shall not lead to a Mobility Management notification to the gsmSCF. Figure 9.-1a: Procedure Set_Notification_Type (sheet 1) 9.3.1.1.2 Procedure Notify_gsmSCF This procedure is called from the process 'Update_Location_Area_VLR' and process 'Detach_IMSI_VLR' in 3GPP TSÊ23.012Ê[10]. It is also called from the process 'Update_Location_VLR' in 3GPP TSÊ29.002Ê[34]. The calling process passes on the variable 'Notify' to the procedure 'Notify_gsmSCF'. This variable indicates which Mobility Management notification may be necessary to be sent to the gsmSCF. If this variable has a value NULL, then no notification shall be sent to the gsmSCF. If a notification may be necessary to be sent to the gsmSCF, then the procedure checks the presence of M CSI. - If M CSI is present and the Mobility Management event indicated in the variable 'Notify' is marked in M CSI, then a notification shall be sent to the gsmSCF. - If M CSI is not present or the Mobility Management event indicated in the variable 'Notify' is not marked in M CSI, then no notification shall be sent to the gsmSCF. Figure 9.3-1: Procedure Notify_gsmSCF (sheet 1) 9.3.2 Procedures for Mobility management for GPRS subscriber The different procedures for Mobility Management are shown in figures 9.4-1 to 9.4-5. Figure 9.4-1: Routeing Area Update within SGSN Service Area Figure 9.4-2: Routeing Area Update from one SGSN Service Area to another SGSN Service Area Figure 9.4-3: Routeing Area Update from one PLMN to another PLMN Figure 9.4-4: Attach of MS Figure 9.4-5: GPRS detach When a Mobility Management Event has taken place and the processing has been completed, then the SGSN may have to send a notification to the gsmSCF. The sending of a Mobility Management notification to gsmSCF is independent of other CAMEL subscription data for a subscriber. E.g. a subscriber may have MG CSI without GPRS CSI. The sending of a Mobility Management event notification is subscription based. Refer to subclauseÊ9.2.2 for a description of MG CSI and the different Mobility Management events that may lead to a notification to the gsmSCF. 9.3.2.1 Procedure CAMEL_PS_Notification This procedure is called from processes in 3GPP TSÊ23.060Ê[15]. When this procedure is called, it checks the presence of MG CSI. If there is no MG CSI, then no notification is sent to the gsmSCF. Figure 9.5-1: Procedure CAMEL_PS_Notification (sheet 1) Figure 9.6-1: Procedure Set_PS_Notification_Type (sheet 1) Figure 9.7-1: Procedure Notify_PS_gsmSCF (sheet 1) 9.4 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for Mobility Management control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E), Optional (O) or not applicable (-) for each different entity involved: VLR (VLR) and SGSN (SGSN) where distinction is applicable. If the IEs in one table apply in both VLR and SGSN, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support; - The VLR shall functionally support all IEs which can be sent to it; - The SGSN shall functionally support all IEs which can be sent to it. 9.4.1 VLR or SGSN to gsmSCF information flows 9.4.1.1 Mobility Management event Notification 9.4.1.1.1 Description This IF is generated by the VLR or SGSN to notify the gsmSCF of a Mobility Management event. 9.4.1.1.2 Information Elements Information element name VLR SGSN Description Event Met M M This IE indicates the type of Mobility Management event that lead to the notification. Refer to subclauseÊ9.2.1.1 for the CS subscriber and subclauseÊ9.2.2.1 for the GPRS subscriber. Service Key M M This IE indicates the Service Logic that the gsmSCF shall apply. IMSI M M This IE identifies the mobile subscriber to whom the Mobility Event applies. Basic MSISDN M M This IE identifies the mobile subscriber to whom the Mobility Event applies. Location Information for CS subscriber C - This IE is described in a table below. This IE indicates the current location of the MS. Location Information for GPRS subscriber - C This IE indicates the current location of the MS which is equivalent to the location info SGSN IE in subclauseÊ7.6.1.2. Supported CAMEL Phases M M This IE indicates the CAMEL Phases that are supported by the sending entity (VMSC/VLR or SGSN) in which the MS is registered after the mobility management event. Offered CAMEL4 Functionalities M - This IE is described in subclause 4.6.1.8. It indicates the CAMEL phaseÊ4 functionalities offered by the VMSC/VLR. Location Information for CS subscriber is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number M See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - Not applicable Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18]. User CSG Information C See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E See 3GPP TSÊ23.018Ê[12]. 9.4.2 SGSN to HLR information flows 9.4.2.1 Update GPRS Location See subclauseÊ6.6.4.2. 9.4.3 VLR to HLR information flows 9.4.3.1 Update Location See subclauseÊ4.6.8.3. 9.4.3.2 Restore Data See subclauseÊ4.6.8.4. 9.4.4 HLR to VLR or SGSN information flows 9.4.4.1 Delete Subscriber Data 9.4.4.1.1 Description This IF is used by an HLR to delete CAMEL subscription data from a VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 9.4.4.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements for Mobility Management: Information element name VLR SGSN Description CAMEL Subscription Info Withdraw O O This IE identifies that all CSIs shall be deleted from the subscriber data in VLR or SGSN. Specific CSI Withdraw O O This IE is used to indicate that only M CSI or MG CSI shall be deleted from the VLR or SGSN respectively. It should not be present when CAMEL Subscription Info Withdraw is present. 9.4.4.2 Insert Subscriber Data 9.4.4.2.1 Description This IF is used by an HLR to update a VLR or SGSN with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 9.4.4.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information elements for Mobility Management: Information element name VLR SGSN Description M CSI O - This IE identifies the CS subscriber as having mobility management notification services. It contains the events that shall be reported, the gsmSCF Address and the Service Key. MG CSI - O This IE identifies the GPRS subscriber as having mobility management notification services. It contains the events that shall be reported, the gsmSCF Address and the Service Key. M CSI contains the following information elements: Information element name Status Description GsmSCF Address M This IE is described in subclauseÊ9.2.1. Service Key M This IE is described in subclauseÊ9.2.1. Mobility Management Triggers M This IE indicates which Mobility Management events shall be reported to the gsmSCF. It shall contain one or more of the following elements: - Location update in the same VLR service area - Location update to another VLR service area - IMSI attach - MS initiated IMSI detach (explicit detach) - Network initiated IMSI detach (implicit detach) MG CSI contains the following information elements: Information element name Status Description GsmSCF Address M This IE is described in subclauseÊ9.2.2. Service Key M This IE is described in subclauseÊ9.2.2. Mobility Management Triggers M This IE is described in subclauseÊ9.2.2. 10 Control and interrogation of subscription data Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 10.1 Architecture 10.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture required to support control and interrogation of subscription data. FigureÊ10.1 shows the functional entities involved in CAMEL support of control and interrogation of subscription data. Figure 10.1: Functional architecture for support of control and interrogation of subscription data gsmSCF: see subclauseÊ3.1. HLR: The HLR may provide an interface to the gsmSCF for the Any Time Subscription Interrogation and Any Time Modification procedures. The gsmSCF may provide an interface to the HLR for the Notify Subscriber Data Change procedure. 10.1.2 Interfaces defined for CAMEL This subclause describes the interface applicable to CAMEL control of subscription data. It specifies on a high level the functions specific to CAMEL. 10.1.2.1 gsmSCF - HLR This interface is used by the gsmSCF to interrogate or modify information in the HLR. As a network operator option, the HLR may refuse to provide or modify the information requested by the gsmSCF. This interface is also used by the HLR to notify the gsmSCF of a change of subscriber data. 10.2 Procedures for CAMEL 10.2.1 Any Time Subscription Interrogation Handling of Any Time Interrogation for Subscription Information Retrieval involves the following process: - CAMEL_ATSI_HLR. If an OSS needs the Subscription Information, the gsmSCF initiates a transaction to the HLR by sending an Any Time Subscription Interrogation Request. Figure 10.2-1: Process CAMEL_ATSI_HLR (sheet 1) Figure 10.2-2: Process CAMEL_ATSI_HLR (sheet 2) 10.2.2 Any Time Modification Handling of Any Time Modification involves the following process: - CAMEL_ATM_HLR. The following procedures are involved: - ATM_Modify_Data This procedure checks which data shall be modified and calls the appropriate data modification procedure. - ATM_Modify_CSI_Data If the CSI indicated in the ATM request is not available in the HLR, then an error is returned. Otherwise, the CSI state and/or Notification-to-CSE flag are set as instructed with the ATM request. - ATM_Modify_CF_Data When only the SS-code and (optionally) a Basic Service code are present in the ATM request, then all Call Forwarding data belonging to this SS code and basic service code is erased, the associated notificationToCSE flag is unchanged and the SS-Status is amended according to the state transition model defined in 3GPP TSÊ23.082Ê[20]. Otherwise, the behaviour is as follows: - If a valid SS-status (i.e., the content of the SS-status parameter takes one of the values defined in the State Transition Model for the corresponding Call Forwarding supplementary service, as specified in 3GPP TSÊ23.082Ê[20]) is present in the ATM request, then an SS state transition is performed. - If a valid FTN, FTN sub address or No Reply Condition Time is present in the ATM request, then the indicated variable is modified. - Before modification of CF data (SS state changed to 'registered', insert or change of FTN), the interaction checks between CF and ODB and between CF and CB shall be performed as described in 3GPP TSÊ23.015Ê[11] and TSÊ23.082Ê[20] respectively. The CF data shall only be modified if the changed new CF data does not conflict with the existing ODB or CB entries. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - If the modification is partially successful (e.g. succeeds for one Basic Service but fails for another Basic Service), then the operation is partially accepted by the HLR. The accepted changes are made in the HLR and the changed data is sent in the ATM acknowledgement. - ATM_Modify_CB_Data When only the SS-code and (optionally) a Basic Service code are present in the ATM request, then all Call Barring belonging to this SS code and basic service code is deactivated, the associated notificationToCSE flag is unchanged and the SS-Status is amended according to the state transition model defined in 3GPP TSÊ23.088Ê[23]. Otherwise, the behaviour is as follows: - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for the corresponding Call Barring supplementary service, as specified in 3GPP TSÊ23.088Ê[23]) is present in the ATM request, then an SS state transition is performed. - Before modification of CB data (SS state), the interaction checks between CF and CB shall be performed as described in 3GPP TSÊ23.088Ê[23]. The CB data shall only be modified if the changed new CB data does not conflict with the existing CF entries. - If a valid Password or 'Wrong password attempt counter' is present in the ATM request, then the indicated variable is modified. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_ODB_Data - If ODB data is not present in the ATM request, then it is assumed that the ODB data is not modified. When present, the modification is done by overwriting the existing ODB data. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - If the modification is partially successful (e.g. succeeds for one Basic Service but fails for another Basic Service), then the operation is partially accepted by the HLR. The accepted changes are made in the HLR and the changed data is sent in the ATM acknowledgement. - ATM_Modify_IP-SM-GW_Data - If Modification Instruction is ""activate"", the IP-SM-GW address is stored if not already pre-configured in the HLR and the process Subscriber_Present_HLR is invoked (see 3GPP TSÊ23.012Ê[10]). - If Modification Instruction is ""deactivate"" and there is no IP-SM-GW address pre-configured in the HLR, the stored IP-SM-GW address is deleted. - ATM_Modify_CW_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Call Waiting, as specified in 3GPP TSÊ23.083Ê[48]) is present in the ATM request, then the Call Waiting state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CH_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Call Hold, as specified in 3GPP TSÊ23.083Ê[48]) is present in the ATM request, then the Call Hold state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_ECT_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Explicit Call Transfer, as specified in 3GPP TSÊ23.091Ê[25]) is present in the ATM request, then the Explicit Call Transfer state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CLIP_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for CLIP, as specified in 3GPP TSÊ23.081Ê[47]) is present in the ATM request, then the Calling Line Identification Presentation state is changed accordingly, - If the Override Category is present, the Override Category is changed accordingly. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CLIR_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for CLIR, as specified in 3GPP TS 23.081Ê[47]) is present in the ATM request, then the Calling Line Identification Restriction state is changed accordingly, - If the Override Category is present, the CLI Restriction Option is changed accordingly. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. After having executed the Any Time Modification instruction from the gsmSCF, the HLR calls the procedure CAMEL_NSDC_HLR, which sends notifications to gsmSCF(s), if required. Figure 10.3-1: Process CAMEL_ATM_HLR (sheet 1) Figure 10.4-1: Procedure ATM_Modify_Data (sheet 1) Figure 10.4-2: Procedure ATM_Modify_Data (sheet 2) Figure 10.5-1: Procedure ATM_Modify_CSI_Data (sheet 1) Figure 10.6-1: Procedure ATM_Modify_CF_Data (sheet 1) Figure 10.6-2: Procedure ATM_Modify_CF_Data (sheet 2) Figure 10.7-1: Procedure ATM_Modify_CB_Data (sheet 1) Figure 10.7-2: Procedure ATM_Modify_CB_Data (sheet 2) Figure 10.8-1: Procedure ATM_Modify_ODB_Data (sheet 1) Figure 10.9-1: Procedure ATM_Modify_IP-SM-GW_Data (sheet 1) Figure 10.10-1: Procedure ATM_Modify_CH_Data (sheet 1) Figure 10.11-1: Procedure ATM_Modify_CW_Data (sheet 1) Figure 10.12-1: Procedure ATM_Modify_ECT_Data (sheet 1) Figure 10.13-1: Procedure ATM_Modify_CLIP_Data (sheet 1) Figure 10.14-1: Procedure ATM_Modify_CLIR_Data (sheet 1) 10.2.3 Notify Subscriber Data Change Changes of CSI, Call Forwarding data, Call Barring data, Call Waiting data, Call Hold data, Explicit Call transfer data, Calling line Identification Presentation data, Calling line Identification Restriction data or ODB data shall be notified only if the corresponding data is marked with the Notification-to-CSE flag. The HLR maintains a list of gsmSCF address(es) for Call Forwarding Data, Call Barring Data, ODB, Call Waiting data, Call Hold data, Explicit Call transfer data, Calling line Identification Presentation data, Calling line Identification Restriction data and CSI. When any of these items has been modified, a notification shall be sent to each gsmSCF in the corresponding list. The sending of a notification to the gsmSCF may be triggered by the following processes: - subscriber data change by administrative procedure; - subscriber data changed by subscriber; - subscriber data changed by Any Time Modification request from gsmSCF; - subscriber data changed due to a change of other subscriber data; - subscriber data change due to Location Update. When a change of subscriber data is requested by Any Time Modification, Any Time Modification acknowlegement is returned to the requesting gsmSCF confirming the status of the altered data. Separate Notifications of subscriber data change shall also be returned to the requesting gsmSCF for each other piece of altered data, but these shall not contain the requested change. Each gsmSCF shall be notified only once. Multiple occurrence of gsmSCF Address in these lists shall not lead to multiple notification. Handling of Notify Subscriber Data Change involves the following procedure: - CAMEL_NSDC_HLR. If a change of subscriber data needs to be notified to the gsmSCF, then the HLR initiates a transaction to the gsmSCF by sending Notify Subscriber Data Change information flow. Figure 10.9-1: Procedure CAMEL_NSDC_HLR (sheet 1) 10.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for control and interrogation of subscription data. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF and the IP-SM-GW may silently discard any IE which it does not functionally support. - The HLR shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 10.3.1 gsmSCF to HLR information flows 10.3.1.1 Any Time Modification Request 10.3.1.1.1 Description This IF is used to modify information in the HLR at any time. 10.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN Modification Request For Call Forwarding SS Data E This IE is described in a table below. This IE indicates the data of Call Forwarding data to be modified. Modification Request For Call Barring SS Data E This IE is described in a table below. This IE indicates the data of call barring data to be modified. Modification Request For Operator Determined Barring Data E This IE is described in a table below. This IE indicates the data of operator determined barring data to be used. Modification Request For CAMEL Subscription Information E This IE is described in a table below. This IE indicates the Modification Request for CAMEL Subscription Information. Modification Request For Call Waiting SS Data E This IE is described in a table below. This IE indicates the data of Call Waiting data to be modified. Modification Request For Call Hold SS Data E This IE is described in a table below. This IE indicates the data of Call Hold data to be modified. Modification Request For Calling Line Identification Presentation SS Data E This IE is described in a table below. This IE indicates the data of Calling Line Identification Presentation data to be modified. Modification Request For Calling Line Identification Restriction SS Data E This IE is described in a table below. This IE indicates the data of Calling Line Identification Restriction data to be modified. Modification Request For Explicit Call Transfer SS Data E This IE is described in a table below. This IE indicates the data of Explicit Call Transfer data to be modified. Modification Request For Call Forwarding SS Data contains the following information elements: Information element name Status Description SS Code M This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Modification acknowledgement IF, only the following supplementary service codes are allowed for this IE; - call forwarding unconditional; - call forwarding on mobile subscriber busy; - call forwarding on no reply; - call forwarding on mobile subscriber not reachable. Basic Service O See 3GPP TSÊ29.002Ê[34]. SS Status O See 3GPP TSÊ23.011Ê[9]. Provisioning and withdrawal are not allowed for the gsmSCF. Forwarded-to Number O See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress O See 3GPP TSÊ29.002Ê[34]. No Reply Condition Time O See 3GPP TSÊ23.082Ê[20]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Barring SS Data contains the following information elements: Information element name Status Description SS Code M This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Modification acknowledgement IF, only the following supplementary service codes are allowed for this IE; - barring of all outgoing calls; - barring of outgoing international calls; - barring of outgoing international calls except those directed to the home PLMN; - barring of all incoming calls; - barring of incoming calls when roaming outside home PLMN Country. Basic Service O See 3GPP TSÊ29.002Ê[34]. SS Status O See 3GPP TS 23.011Ê[9]. Provisioning and withdrawal are not allowed for the gsmSCF. Password O See 3GPP TSÊ23.011Ê[9]. Wrong password attempts counter O See 3GPP TSÊ23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Operator Determined Barring Data contains the following information elements: Information element name Status Description ODB data O This IE contains ODB General Data and ODB HPLMN Specific Data to be imposed by this IF. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For CAMEL Subscription Information contains the following information elements: Information element name Status Description Requested CSI M This IE indicates which CSI shall be modified. Only one CSI may be changed in one ATM Request. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modify CSI State O This IE contains an instruction to activate or de-activate the CSI. Modification Request For Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Hold Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Waiting Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Override Category O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. CLI Restriction Option O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. 10.3.1.2 Any Time Subscription Interrogation Request 10.3.1.2.1 Description This IF is used to request subscription information from the HLR at any time. 10.3.1.2.2 Information Elements Information element name Status Description GsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of subscriber information being requested: This shall consist of one or more of the following list: - supplementary service; this information is described in a table below, - Operator Determined Barring; - CAMEL Subscription Information; this information is described in a table below, - supported CAMEL phases in VLR; - supported CAMEL phases in SGSN; - MSISDNs and Basic Service Codes associated with the Subscriber Identity. - CSG Subscription Data, see 3GPP TS 29.002Ê[34]; - Call Waiting SS Data see 3GPP TS 29.002[34]; - Call Hold SS Data see 3GPP TS 29.002[34]; - Explicit Call Transfer Data see 3GPP TS 29.002[34]; - Calling Line Identification Presentattion Data see 3GPP TS 29.002[34]; - Calling Line Identification Restriction Data see 3GPP TS 29.002[34]. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN."
"Supplementary service contains the following information elements: Information element name Status Description SS Code M This IE indicates a supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Subscription Interrogation acknowledgement IF, only the following supplementary service codes are allowed for this IE; - call forwarding unconditional; - call forwarding on mobile subscriber busy; - call forwarding on no reply; - call forwarding on mobile subscriber not reachable; - barring of all outgoing calls; - barring of outgoing international calls; - barring of outgoing international calls except those directed to the home PLMN; - barring of all incoming calls; - barring of incoming calls when roaming outside home PLMN Country. Basic Service O See 3GPP TSÊ29.002Ê[34]. CAMEL subscription information shall contain one of the following information elements: Information element name Status Description CAMEL Subscription Info S,E This IE indicates which CAMEL Subscription Information is requested. It shall be one of the following elements: O CSI/T CSI/VT CSI/TIF CSI/GPRS CSI/MO SMS CSI/SS CSI/M CSI/D CSI. Additional Requested CAMEL Subscription Info S,E This IE indicates which CAMEL Subscription Information is requested. It shall be one of the following elements: MT SMS CSI/ MG CSI. 10.3.1.3 Notify Subscriber Data Change response 10.3.1.3.1 Description This IF is used by the gsmSCF to respond to the HLR of the change of subscriber data notify. 10.3.1.3.2 Information Elements This IF contains no information elements. 10.3.2 HLR to gsmSCF information flows 10.3.2.1 Any Time Modification ack 10.3.2.1.1 Description This IF is used by the HLR to provide the modified information to the gsmSCF. 10.3.2.1.2 Information Elements Information element name Status Description Call Forwarding SS Data S This IE is described in a table below. It shall be present if it was modified. Call Barring SS Data S This IE is described in a table below. It shall be present if it was modified. Operator Determined Barring Information S This IE is described in a table below. It shall be present if it was modified. CAMEL Subscription Information S This IE is described in a table below. It shall be present if it was modified. Call Waiting SS Data S This IE is described in a table below. It shall be present if it was modified. Call Hold SS Data S This IE is described in a table below. It shall be present if it was modified. Calling Line Identification Presentation SS Data S This IE is described in a table below. It shall be present if it was modified. Calling Line Identification Restriction SS Data S This IE is described in a table below. It shall be present if it was modified. Explicit Call Transfer SS Data S This IE is described in a table below. It shall be present if it was modified. Call Forwarding SS Data contains the following information elements: Information element name Status Description SS Code S This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Only the SS code for which the modification applies is sent. Forwarding Feature List S This IE is described in a table below. If a Forwarding Feature List item is modified then all applicable fields within the item shall be sent. All modified Forwarding Feature List items shall be returned. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. The IE shall be sent if it was modified. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Timer C See 3GPP TSÊ23.082Ê[20]. Call Barring SS Data contains the following information elements: Information element name Status Description SS Code S This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Only the SS code for which the modification applies is sent. Call Barring Feature List S This IE is described in a table below. If a Call Barring Feature List item is modified then all applicable fields within the item shall be sent. All modified Call Barring Feature List items shall be returned. Password S See 3GPP TSÊ23.011Ê[9]. The IE shall be sent if it was modified. Wrong Password Attempts Counter S See 3GPP TSÊ23.011Ê[9]. The IE shall be sent if it was modified. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. The IE shall be sent if it was modified. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Information contains the following information elements: Information element name Status Description ODB Data C See subclauseÊ10.3.2.3 Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI S See subclauseÊ4.3.1. It shall be present if it was modified. D CSI S See subclauseÊ4.3.2. It shall be present if it was modified. T CSI S See subclauseÊ4.3.5. It shall be present if it was modified. VT CSI S See subclauseÊ4.3.6. It shall be present if it was modified. TIF CSI S See subclauseÊ4.3.4. It shall be present if it was modified. GPRS CSI S See subclauseÊ6.3.1. It shall be present if it was modified. MO SMS CSI S See subclauseÊ7.3.1. It shall be present if it was modified. MT SMS CSI S See subclauseÊ7.3.2. It shall be present if it was modified. SS CSI S See subclauseÊ8.2.1. It shall be present if it was modified. M CSI S See subclauseÊ9.2.1. It shall be present if it was modified. MG CSI S See subclauseÊ9.2.2. It shall be present if it was modified. Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. The IE shall be sent if it was modified. Call Hold Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. The IE shall be sent if it was modified. Call Waiting Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. The IE shall be sent if it was modified. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Override Category S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. The IE shall be sent if it was modified. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified CLI Restriction Option S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Restriction SS data. The IE shall be sent if it was modified. 10.3.2.2 Any Time Subscription Interrogation ack 10.3.2.2.1 Description This IF is used by the HLR to provide the requested subscription information to the gsmSCF. 10.3.2.2.2 Information Elements Information element name Status Description Call Forwarding SS Data C This IE is described in a table below. Call Barring SS Data C This IE is described in a table below. Operator Determined Barring Data C This IE is described in a table below. CAMEL Subscription Information C This IE is described in a table below. Supported CAMEL Phases In VLR C This IE indicates the CAMEL phase supported in the VLR. Offered CAMEL4 CSIs In VLR S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases In VLR"" IE indicates CAMEL phaseÊ4. Supported CAMEL Phases In SGSN C This IE indicates the CAMEL phase supported in the SGSN. Offered CAMEL4 CSIs In SGSN S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases In SGSN"" IE indicates support of CAMEL phaseÊ4. MSISDN-BS-List C This IE indicates the subscriber's MSISDN(s) and their associated Basic Service Codes. (Note) Call Waiting SS Data C This IE is described in a table below. Call Hold SS Data C This IE is described in a table below. Calling Line Identification Presentation SS Data C This IE is described in a table below. Calling Line Identification Restriction SS Data C This IE is described in a table below. Explicit Call Transfer SS Data C This IE is described in a table below. NOTE: The BASIC MSISDN is always first in the list. Call Forwarding SS Data contains the following information elements: Information element name Status Description Forwarding Feature List C This IE is described in a table below Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Time C See 3GPP TSÊ23.082Ê[20]. Call Barring SS Data contains the following information elements: Information element name Status Description Call Barring Feature List C This IE is described in a table below. Password C See 3GPP TSÊ23.011Ê[9]. Wrong Password Attempts Counter C See 3GPP TSÊ23.011Ê[9]. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Bata contains the following information elements: Information element name Status Description ODB General Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate. ODB HPLMN Specific Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI C See subclauseÊ4.3.1. D CSI C See subclauseÊ4.3.2. T CSI C See subclauseÊ4.3.5. VT CSI C See subclauseÊ4.3.6. TIF CSI C See subclauseÊ4.3.4. GPRS CSI C See subclauseÊ6.3.1. MO SMS CSI C See subclauseÊ7.3.1. MT SMS CSI C See subclauseÊ7.3.2. SS CSI C See subclauseÊ8.2.1. M CSI C See subclauseÊ9.2.1. MG CSI C See subclauseÊ9.2.2. Offered CAMEL4 CSIs in VLR contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI Offered CAMEL4 CSIs in SGSN contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancement of Provide Subscriber Information Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. Call Hold Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. Call Waiting Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Override Category C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF CLI Restriction Option C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of C Calling Line Identification Restriction SS data. 10.3.2.3 Notify Subscriber Data Change 10.3.2.3.1 Description This IF is used by the HLR to notify to the gsmSCF of the change of subscriber data. This IF is sent at each time subscriber data is changed. 10.3.2.3.2 Information Elements Information element name Status Description IMSI M The IMSI is used to identify the subscriber. MSISDN M The MSISDN is used to identify the subscriber. Call Forwarding SS Data C This IE is described in a table below. Call Barring SS Data C This IE is described in a table below. Operator Determined Barring Data C This IE is described in a table below. CAMEL Subscription Information C This IE is described in a table below. CSG Subscription Data C See 3GPP TSÊ29.002Ê[34]. It shall be present if it was modified. Call Waiting SS Data C This IE is described in a table below. Call Hold SS Data C This IE is described in a table below. Calling Line Identification Presentation SS Data C This IE is described in a table below. Calling Line Identification Restriction SS Data C This IE is described in a table below. Explicit Call Transfer SS Data C This IE is described in a table below. Call Forwarding SS data contains the following information elements: Information element name Status Description SS Code C This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Forwarding Feature List C This IE is described in a table below. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. Compound basic service codes can also be used in this IF if the subscriber has used a compound code when modifying the SS (e.g. all bearer services compound code). SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Timer C See 3GPP TSÊ23.082Ê[20]. Call Barring SS data contains the following information elements: Information element name Status Description SS Code C This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Call Barring Feature List C This IE is described in a table below. Password C See 3GPP TSÊ23.011Ê[9]. Wrong Password Attempts Counter C See 3GPP TSÊ23.011Ê[9]. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. Compound basic service codes can also be used in this IF if the subscriber has used a compound code when modifying the SS (e.g. all bearer services compound code). SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Data contains the following information elements: Information element name Status Description ODB General Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate. When the ODB general data is removed for the subscriber, this IE indicates that the set of subscribers features is empty. ODB HPLMN Specific Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. When the ODB HPLMN specific data is removed for the subscriber, this IE indicates that the set of subscribers features is empty. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI S See subclauseÊ4.3.1. It shall be present if it was modified. D CSI S See subclauseÊ4.3.2. It shall be present if it was modified. T CSI S See subclauseÊ4.3.5. It shall be present if it was modified. VT CSI S See subclauseÊ4.3.6. It shall be present if it was modified. TIF CSI S See subclauseÊ4.3.4. It shall be present if it was modified. GPRS CSI S See subclauseÊ6.3.1. It shall be present if it was modified. MO SMS CSI S See subclauseÊ7.3.1. It shall be present if it was modified. MT SMS CSI S See subclauseÊ7.3.2. It shall be present if it was modified. SS CSI S See subclauseÊ8.2.1. It shall be present if it was modified. M CSI S See subclauseÊ9.2.1. It shall be present if it was modified. MG CSI S See subclauseÊ9.2.2. It shall be present if it was modified. Specific CSI Deleted List S This IE indicates that one or more specific elements of CAMEL Subscription Information have been deleted from the HLR. It shall indicate any of the following; - O CSI (with TDP criteria for O CSI); - T CSI (with TDP criteria for T CSI); - TIF CSI; - D CSI; - VT CSI with TDP criteria for VT CSI; - GPRS CSI; - MO SMS CSI; - MT SMS CSI with TDP criteria for MT SMS CSI; - SS CSI; - M CSI; - MG CSI. This IE shall be present if CSI is/are deleted. Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. Call Hold Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. Call Waiting Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Override Category C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified CLI Restriction Option C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of C Calling Line Identification Restriction SS data. 10.3.3 IP-SM-GW to HLR information flows 10.3.3.1 Any Time Modification Request 10.3.3.1.1 Description This IF is used to register the IP-SM-GW for a subscriber in the HLR. 10.3.3.1.2 Information Elements Information element name Status Description IP-SM-GW Address M This IE indicates the address of the interrogating IP-SM-GW. The IP-SM-GW Address shall be in international E.164 format. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN Modification Request For IP-SM-GW Data E This IE is described in a table below. This IE indicates the IP-SM-GW data to be modified. Modification Request For IP-SM-GW Data contains the following information elements: Information element name Status Description Modify Registration Flag M This IE contains an instruction to register or de-register the IP-SM-GW. 10.3.4 HLR to IP-SM-GW information flows 10.3.4.1 Any Time Modification ack 10.3.4.1.1 Description This IF is used by the HLR to acknowledge the registration or deregistration for a subscriber of the IP-SM-GW to the IP-SM-GW. 10.3.4.1.2 Information Elements This IF contains no information elements. 11 Subscriber Location and State retrieval Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 11.1 Architecture 11.1.1 Functional Entities used for CAMEL This subclause describes procedures for the retrieval of subscriber location and subscriber state information. Location Services is only supported in CAMEL PhaseÊ3 and higher. 1) The gsmSCF may request location information of a mobile station from the GMLC via Location Services. The information flow of Location Services is described in 3GPP TSÊ23.271Ê[28] and 25. 305Ê[32]. FigureÊ11.1-1 indicates the functional entities involved in the procedures for the retrieval of location information via location services. 2) The gsmSCF may request any of location information, subscriber state information, IMEI and MS Class of a mobile station from the HLR. Any of location information, subscriber state information, IMEI and MS Class may be requested either from the circuit switched or the packet switched domain. If any of location information, subscriber state information, IMEI and MS Class is requested by the gsmSCF, then the HLR may retrieve this information via the Provide Subscriber Information procedure from either the MSC/VLR or the SGSN. This procedure is defined in subclauseÊ4.5.9 of the present document. The interface for the provision of subscriber location and state information between HLR and MSC/VLR is described in 3GPP TSÊ23.018Ê[12]. The interface for the provision of subscriber location and state information between HLR and SGSN is described in this chapter. FigureÊ11.1-2 indicates the functional entities involved in the procedures for the retrieval of location information and/or subscriber state information from the circuit switched or packet switched domain. Figure 11.1-1: Functional architecture for CAMEL Support of Location Services Figure 11.1-2: Functional architecture for Any Time Interrogation gsmSCF: see subclauseÊ3.1. GMLC: A functional entity that allows external LCS Clients to request real-time information about a Mobile Station. The information that can be requested from the GMLC is the location of the mobile station. HLR: see subclauseÊ4.1. MSC/VLR: see subclauseÊ4.1. SGSN: see subclauseÊ6.1.1. The SGSN stores location and state information for each subscriber. Upon request this information is provided to the HLR. The information flows between the GMLC and functional entities other than the gsmSCF, have not been indicated in the functional architecture shown in figuresÊ11.1. These information flows are outside the scope of the present document. 11.1.2 Interfaces defined for CAMEL This subclause describes the interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 11.1.2.1 gsmSCF - GMLC interface This interface is used by the gsmSCF to request information (Mobile Station location) from the GMLC at any time. 11.1.2.2 GMLC - gsmSCF interface This interface is used by the GMLC to return the requested information (Mobile Station location) to the gsmSCF as requested by the gsmSCF via the Any Time Interrogation procedure. 11.1.2.3 gsmSCF - HLR This interface is used by the gsmSCF to interrogate the HLR. As a network operator option, the HLR may refuse to provide the information requested by the gsmSCF. 11.1.2.4 HLR - gsmSCF This interface is used by the HLR to return the requested information to the gsmSCF as requested by the gsmSCF via the Any Time Interrogation procedure. 11.1.2.5 HLR - SGSN This interface is used by the HLR to request information from the SGSN. 11.1.2.5 SGSN - HLR This interface is used by the SGSN to return the requested information to the HLR. 11.2 Procedures for CAMEL 11.2.1 Location Services Handling of Any Time Interrogation to obtain Location Information involves the following process: - CAMEL_ATI_GMLC. If an OSS needs to retrieve the active location of a Mobile Station, the gsmSCF initiates a transaction to the GMLC by sending a Any Time Interrogation Request. Figure 11.2-1: Process CAMEL_ATI_GMLC (sheet 1) 11.2.2 Any Time Interrogation Handling of Any Time Interrogation to obtain Subscriber State and Location Information involves the following process: - CAMEL_ATI_HLR. If an OSS needs the Subscriber State and/or the Location Information, the gsmSCF initiates a transaction to the HLR by sending an Any_Time_Interrogation Request. Figure 11.3-1: Process CAMEL_ATI_HLR (sheet 1) 11.2.3 Provide Subscriber Information in the SGSN The provision of Subscriber State and Location Information involves the following process and procedures: - CAMEL_Provide_Subscriber_Info_SGSN; - CAMEL_Active_Info_Retrieval_SGSN; - Retrieve_GPRS_MS_Class_If_Required; - Retrieve_IMEI_If_Required. 11.2.3.1 Procedure CAMEL_Provide_Subscriber_Info_SGSN If the SGSN receives a Provide Subscriber Info request, it performs procedures to obtain the requested information. The test ""Active retrieval required"" takes the ""Yes"" exit if any one or more of current location, GPRS MS class or IMEI is indicated in the Provide Subscriber Info request. 11.2.3.2 Procedure CAMEL_Active_Info_Retrieval_SGSN If the SGSN data show that the MS is in the ""Iu Connected"" state (i.e. it has an Iu connection established), the SGSN performs the Location Reporting Control procedure (Direct report) which is defined in 3GPP TSÊ25.413Ê[33]. The test ""Report on change of service area"" takes the ""Yes"" exit if the SGSN has performed the Location Reporting Control procedure with the Request Type IE set to ""Change of service area"". If the SGSN data show that the MS is in the ""A/Gb Ready"" state (i.e. it is transferring packet data over an A/Gb access connection) then the currently stored location information is up to date, and no further action is required. Figure 11.4-1: Process CAMEL_Provide_Subscriber_Info_SGSN (sheet 1) Figure 11.5-1: Procedure CAMEL_Active_Info_Retrieval_SGSN (sheet 1) Figure 11.5-2: Procedure CAMEL_Active_Info_Retrieval_SGSN (sheet 2) Figure 11.6-1: Procedure Retrieve_GPRS_MS_Class_If_Required (sheet 1) Figure 11.7-1: Procedure Retrieve_IMEI_If_Required (sheet 1) 11.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for the retrieval of information about the location and state of a subscriber. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or not applicable (-) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The GMLC shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 11.3.1 gsmSCF to GMLC information flows 11.3.1.1 Any Time Interrogation Request 11.3.1.1.1 Description This IF is used to request information (Mobile Station location) from the GMLC. 11.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of information that is requested. It shall have the following value: - Mobile Station location Mobile Station Identity M This IE identifies the Mobile Station of which the information is requested. The identity shall be either: - IMSI, or - MSISDN 11.3.2 GMLC to gsmSCF information flows 11.3.2.1 Any Time Interrogation ack 11.3.2.1.1 Description This IF is used by the GMLC to provide the requested information to the gsmSCF. 11.3.2.1.2 Information Elements Information element name Status Description Location Information C This IE indicates the location of the Mobile Station. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Location number - Not applicable Service area ID - Not applicable Cell ID - Not applicable Geographical information C See 3GPP TSÊ23.032Ê[13]. The GMLC receives Extended Geographical Information from the MSC. The Extended Geographical Information shall be converted to the Geographical Information by the GMLC. VLR number - Not applicable Current Location Retrieved - Not applicable MSC number C The GMLC receives the MSC number from the HLR in the SendRoutingInfoForLCS MAP message. SGSN number C The GMLC receives the SGSN number from the HLR in the SendRoutingInfoForLCS MAP message. User CSG Information C See 3GPP TS 23.060Ê[15]. 11.3.3 gsmSCF to HLR information flows 11.3.3.1 Any Time Interrogation Request 11.3.3.1.1 Description This IF is used to request information (any one or more of subscriber state, subscriber location, IMEI (with software version) and MS classmark information for the requested domain) from the HLR at any time. 11.3.3.1.2 Information Elements Information element name Status Description Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN. Requested Info M This IE indicates the type of subscriber information being requested. This IE is described in a table below. gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info contains the following information elements: Information element name Status Description Location Information O This IE indicates that the Location Information is requested. Subscriber State O This IE indicates that the Subscriber State is requested. Current Location O,S This IE indicates that the Current Location is requested. This IE shall not be present if Location Information is not present in Requested Info. Location Information in EPS Supported O,S This IE indicates by its presence that Location Information in EPS is supported. This IE should be present if Location Information is present in Requested Info and Location Information in EPS is supported. This IE shall not be present if Location Information is not present in Requested Info. Requested Domain M This IE indicates for which domain the subscriber info is requested. It shall be one of the following: - circuit switched domain; - packet switched domain. IMEI (with software version) O This IE indicates that the IMEI (with software version) is requested. MS class mark information for the requested domain O This IE indicates that the MS classmark information for the indicated domain is requested. Requested Info shall contain one or more of the following information elements: - Location Information; - Subscriber State; - IMEI (with software version); - MS classmark information for the requested domain. 11.3.4 HLR to gsmSCF information flows 11.3.4.1 Any Time Interrogation ack 11.3.4.1.1 Description This IF is used by the HLR to provide the requested subscriber location and/or subscriber state information to the gsmSCF. 11.3.4.1.2 Information Elements Information element name Status Description Location Information C, E1 This IE indicates the location of the served subscriber in the MSC/VLR. It shall be present only if requested by the gsmSCF. Location Information For GPRS C, E1 This IE indicates the location of the served subscriber in the SGSN. It shall be present only if requested by the gsmSCF. Subscriber State S, E2 This IE indicates the state of the MS in the CS domain. It shall be present only if requested by the gsmSCF. The possible values of the IE are: - CAMELBusy: The VLR has indicated that the MS is engaged in a transaction for a mobile originating or terminated circuit-switched call. - NetworkDeterminedNotReachable: The HLR or VLR has indicated that the network can determine from its internal data that the MS is not reachable. - AssumedIdle: The VLR has indicated that the state of the MS is neither ""CAMELBusy"" nor ""NetworkDeterminedNotReachable"". - NotProvidedFromVLR: The VLR did not provide any information on subscriber state even though it was requested. PS Domain Subscriber State S, E2 This IE indicates the state of the MS in the PS Domain. It shall be present only if requested by the gsmSCF. The possible values of the IE are: - Detached (see subclauseÊ11.3.5.1). - CAMEL attached, MS not reachable for paging (see subclauseÊ11.3.5.1). - CAMEL attached, MS may be reachable for paging (see subclauseÊ11.3.5.1). - CAMEL PDP active, MS not reachable for paging (see subclauseÊ11.3.5.1). - CAMEL PDP active, MS may be reachable for paging (see subclauseÊ11.3.5.1). - Not provided from SGSN: The SGSN does not support Provide Subscriber Info or it did not provide any information on subscriber state even though it was requested. - NetworkDeterminedNotReachable: The HLR has indicated that the network can determine from its internal data that the MS is not reachable. PDP Context Information List C This IE indicates the PDP context information (see the table in subclauseÊ11.3.5.1) for each PDP context which is active for the MS. It shall be present if the PS domain Subscriber State has the value ""CAMEL PDP active, MS not reachable for paging"" or ""CAMEL PDP active, MS may be reachable for paging""; otherwise it shall be absent. IMEI (with software version) C This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. It shall be present only if requested by the gsmSCF. MS Classmark 2 C This IE contains the MS classmark 2, which is returned by the MS when it responds to paging in the CS domain. It shall be present only if requested by the gsmSCF. GPRS MS Class C This IE contains the MS network and radio access capabilities. It shall be present only if requested by the gsmSCF. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number C See 3GPP TSÊ23.018Ê[12]. The HLR shall include the internally stored VLR Number. Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity C This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA Id with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18]. MSC number C E.164 number which identifies the VMSC in whose area the subscriber is currently registered. See 3GPP TSÊ23.003Ê[7]. If the HLR receives the MSC number from the VLR in the Provide Subscriber Info ack IF then the HLR shall ignore the MSC number. User CSG Information C See 3GPP TS 23.060Ê[15]. E-UTRAN Cell ID C, E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C, E See 3GPP TSÊ23.018Ê[12]. Location Information for GPRS is defined in the subclause 11.3.6.1.2. The following differences apply: Information element name Status Description SGSN Number C See subclause 11.3.6.1.2. The HLR shall include the internally stored SGSN Number. 11.3.5 HLR to SGSN information flows 11.3.5.1 Provide Subscriber Info 11.3.5.1.1 Description This IF is used by the HLR to request information (subscriber state and/or location) from the SGSN at any time. 11.3.5.1.2 Information Elements This IF is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description LMSI - Not applicable. Requested Info M This IE indicates which of the following information the HLR requires: - Subscriber location; - Subscriber state; - Current location; - IMEI & Software version; - GPRS MS classmark information. 11.3.6 SGSN to HLR information flows 11.3.6.1 Provide Subscriber Info ack 11.3.6.1.1 Description This IF is used by the SGSN to provide the requested subscriber location and/or subscriber state information to the HLR. 11.3.6.1.2 Information Elements This IF is defined in 3GPP TSÊ23.018Ê[12]."
"The following differences apply: Information element name Status Description Subscriber State - Not applicable. PS domain Subscriber State C This IE indicates the status of the MS in the PS Domain. It shall be present only if requested by the HLR. The possible values of the IE are: - Detached: The SGSN has determined from its internal data that the MS is not attached to the network. - CAMEL attached, MS not reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network, but there is no PDP Context active, and the MS is not reachable for paging. - CAMEL attached, MS may be reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network, but there is no PDP Context active; the SGSN has not determined from its internal data that the MS is not reachable for paging. - CAMEL PDP active, MS not reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network there is at least on PDP context active, and the MS not reachable for paging. - CAMEL PDP active, MS may be reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network and there is at least one PDP context active; the SGSN has not determined from its internal data that the MS is not reachable for paging. PDP Context Information List S This IE is described in a table below. This IE indicates the PDP context information for each PDP context which is active for the MS. It shall be present if the PS domain Subscriber State has the value ""CAMEL PDP active, MS not reachable for paging"" or ""CAMEL PDP active MS may be reachable for paging""; otherwise it shall be absent. Location Information For GPRS C This IE is described in a table below. It indicates the location of the MS. It shall be present only if requested by the HLR. IMEI (with software version) C This IE contains the IMEI & software version of the ME in use by the served subscriber. It shall be present only if requested by the HLR. GPRS MS Class C This IE contains the MS network and radio access capabilities. It shall be present only if requested by the HLR. PDP Context Information includes the following information elements: Information element name Status Description PDP Context Identifier M Index of the PDP context. PDP State C Packet data protocol state, INACTIVE or ACTIVE. PDP Type C PDP type, e.g., PPP or IP. PDP Address C PDP address, e.g., an IP address. APN Subscribed C The APN received from the HLR. APN in Use C The APN currently used. NSAPI C Network layer Service Access Point Identifier. TI C Transaction Identifier. TEID for Gn/Gp C Tunnel Endpoint Identifier for the Gn and Gp interfaces. TEID for Iu C Tunnel Endpoint Identifier for the Iu interface. GGSN Address in Use C The IP address of the GGSN currently used. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Subscribed QoS C The quality of service profile subscribed. Requested QoS C The quality of service profile requested. Negotiated QoS C The quality of service profile negotiated. Charging ID C Charging identifier, identifies charging records generated by SGSN and GGSN. PDP Context Charging Characteristics C The charging characteristics of this PDP context, e.g., normal, prepaid, flat-rate, and/or hot billing. RNC Address In Use C The IP address of the RNC currently used. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Location Information For GPRS includes the following information elements: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E See 3GPP TSÊ23.018Ê[12]. Routeing area ID C See 3GPP TSÊ23.003Ê[7]. Geographical information C See 3GPP TSÊ23.032Ê[13]. Geodetic information C See ITU TÊQ.763Ê[43]. Age of location information C See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved C See 3GPP TSÊ23.018Ê[12]. SGSN number M Global Title of the SGSN. See 3GPP TSÊ23.060Ê[15]. Selected LSA Identity C This IE is applicable only if SoLSA is supported by the SGSN. This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18] User CSG Information C See 3GPP TS 23.060Ê[15]. 12 Subscriber Mobile Number Portability status retrieval Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 12.1 Architecture 12.1.1 Functional Entities used for CAMEL This clause describes procedures for the retrieval of subscriber Mobile Number Portability (MNP) information. The gsmSCF may request subscriber MNP information of a mobile station from the MNP Signalling Relay Function (MNP SRF). FigureÊ12.1 indicates the functional entities involved in the procedures for the retrieval of MNP information. Figure 12.1: Functional architecture for CAMEL Support of providing MNP information gsmSCF: see subclauseÊ3.1. MNPÊSRF: A functional entity that supports the mobile number portability of a mobile station, which is described in 3GPP TSÊ23.066Ê[17]. Recipient Network: Network that receives the number in the porting process. This network becomes the subscription network when the porting process is complete. See 3GPP TSÊ23.066Ê[17]. Number Range Holder Network: Network to which the number range containing the ported number has been allocated. See 3GPP TSÊ23.066Ê[17]. 12.1.2 Interfaces defined for CAMEL This subclause describes the interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 12.1.2.1 gsmSCF - MNPÊSRF interface This interface is used by the gsmSCF to request MNP information from the MNPÊSRF at any time. 12.1.2.2 MNPÊSRF - gsmSCF interface This interface is used by the MNPÊSRF to return the requested MNP information to the gsmSCF, as requested by the gsmSCF via the Any Time Interrogation procedure. 12.2 Procedures for CAMEL 12.2.1 Provide MNP Information 12.2.1.1 CAMEL_Provide_MNP_Info with ATI The process for providing MNP information with Any Time Interrogation (ATI) is the following: - CAMEL_ATI_MNP. SheetÊ1: Details of the task box ""Query Number Portability Database"" may be obtained from 3GPP TSÊ23.066Ê[17]. The task box returns an indication whether the MSISDN is known or not. Figure 12.2-1: Process CAMEL_ATI_MNP (sheet 1) 12.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for the retrieval of MNP information about a subscriber. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or not applicable (-). An 'M' IE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E' IEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. A '-'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stageÊ2 information. It is not a stageÊ3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The MNPÊSRF shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 12.3.1 gsmSCF to MNPÊSRF information flows 12.3.1.1 Any Time Interrogation Request 12.3.1.1.1 Description This IF is used by the gsmSCF to request the MNP information for subscribers from the MNPÊSRF at any time. 12.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of subscriber information that is requested. It shall have the following value: - MNP Requested Info. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be: - MSISDN. 12.3.2 MNPÊSRF to gsmSCF information flows 12.3.2.1 Any Time Interrogation ack 12.3.2.1.1 Description This IF is used by the MNPÊSRF to provide the requested MNP information for the subscriber to the gsmSCF. 12.3.2.1.2 Information Elements Information element name Status Description MNP Information Result M This IE contains the MNP information for the subscriber. It is described in a table below. MNP Information Result contains the following information: Information element name Status Description Routeing Number C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. IMSI C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. MSISDN C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. Number Portability Status C This IE shall be present, if requested by the gsmSCF. It may have one of the following values: - Not Known To Be Ported; - Own Number PortedOut; - Foreign Number Ported To Foreign Network; - Own Number Not Ported Out; - Foreign Number Ported In. Refer to 3GPP TSÊ23.066Ê[17]. Annex A (informative): Handling of Apply Charging GPRS and Apply Charging Report GPRS This Annex provides an example to demonstrate the handling of Apply Charging GPRS and Apply Charging Report GPRS. Figure A.1: Example of Handling of Apply Charging GPRS and Apply Charging Report GPRS In Figure A.1, data volumes transferred for the active PDP context are listed on the left-hand side of diagram. The following is a description of the example: a) Apply Charging GPRS threshold set to 2000, no tariff switch timer set. b) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. c) The gsmSCF sends another Apply Charging GPRS with a 2000 unit threshold. d) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. e) Another threshold (2000) is set by the gsmSCF in Apply Charging GPRS, and a tariff switch timer is set. f) After 2000 units have been transferred, Apply Charging Report GPRS is sent to the gsmSCF, as a tariff switch timer has expired since the last Apply Charging GPRS, values for volumeTariffSwitchInterval and Volume transferred since the tariff switch are sent. The gsmSCF stores the value volumeTariffSwitchInterval. g) The gsmSCF sends another Apply Charging GPRS with a 2000 unit threshold. h) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. i) Apply Charging GPRS sets a tariff switch timer, which does not expire before the next Apply Charging Report GPRS. j) A change in QoS is reported so Apply Charging Report GPRS is returned to the gsmSCF containing VolumeIfNoTariffSwitch as no tariff switch has occurred since the last Apply Charging Report GPRS. The gsmSCF should store this value if the volume of data transferred at each QoS level is to be calculated. The Tsw sent in the previous Apply Charging GPRS is stopped. In this example the tariff switch timer (Tsw) does not expire before this QoS change. If Tsw had expired the Apply Charging Report GPRS would report the volumeTariffSwitchInterval in the normal way. k) An Apply Charging GPRS is sent giving a new threshold. This threshold is service logic dependent and does not rely on any previous value sent. In the example it is 'previous threshold - volume transferred since last threshold was set'. l) The VolumeSinceLastTariffSwitch is reported in the Apply Charging Report GPRS. Note: this includes data transferred before and after the QoS change. m) Note that a tariff switch timer is set and expires. n) A final Apply Charging Report GPRS is returned containing the data volume transferred since the last tariff switch, and also the total volume transferred at the previous tariff. The calculations made by the gsmSCF in this example are: a) Total Data Volume Transferred in this example: Total of all volumeTariffSwitchInterval received + final volumeSinceLastTariff switch is (5500 + 5000) + 1500 = 12000 units of data b) Data Volume transferred for each tariff: (periods separated by Tsw in figure A.1) - 1st Tariff: taken from Apply Charging Report GPRS (signal f)) volumeTariffSwitchInterval = 5500 units of data - 2nd Tariff: taken from Apply Charging Report GPRS (signal n)) volumeTariffSwitchInterval = 5000 units of data - 3rd Tariff: taken from VolumeSinceLastTariffSwitch (signal n)) volumeTariffSwitchInterval = 1500 units of data c) Data Volume Transferred at each QoS level (One QoS Change Occurs in figure A.1) - 1st QoS level (up to signal 10): All volumeTariffSwitchIntervals + final VolumeSinceLastTariffSwitch at QoS change is 5500 + 3200 = 8700 units of data. - 2nd QoS level (from signal 10 onwards): (Value of first VolumeTariffSwitchInterval received after QoS change - VolumeNoTariffSwitch Received directly after QoS change ) + Volume transferred since this tariff switch is (5000-3200) + 1500 = 3300 units of data. Note: The volume reported to the gsmSCF in an Apply Charging Report GPRS may exceed the threshold sent in the previous Apply Charging GPRS, e.g. if the delta timer exceeds the threshold received in the subsequent Apply Charging GPRS or a data packet is transferred causing the threshold to be exceeded. Annex B (informative): Change history Date TSGÊ# TSG Doc. CR Rev Subject/Comment New 2003-12 CN#22 NP-030526 553 3 23.078-CR553 Collective CR for Rel-6 Enhanced Dialled Services 6.0.0 2003-12 CN#22 NP-0305628 645 1 Change of position armed with criteria (check criteria in MSC) 6.0.0 2003-12 CN#22 NP-030528 647 1 Enhancements for the Partial Implementation for ""Change of position procedure armed with criteria"" 6.0.0 2004-03 CN#23 NP-040137 649 1 Missing DisconnectLeg Result 6.1.0 2004-03 CN#23 NP-040137 651 1 Correction to DP description tables 6.1.0 2004-03 CN#23 NP-040094 652 EDS and DisconnectLeg interworking 6.1.0 2004-03 CN#23 NP-040090 656 DP Triggering without having armed the TDP 6.1.0 2004-03 CN#23 NP-040145 657 1 No receipt of Int_DP_Analysed_Information in state Monitoring 6.1.0 2004-03 CN#23 NP-040138 682 2 Enhancement of Event Specific Information for DP 'Change of Position' 6.1.0 2004-03 CN#23 NP-040131 686 1 GPRS ODB reporting to CAMEL SCP 6.1.0 2004-03 CN#23 NP-040095 688 2 CAMEL4 SCUDIF notification during active call for prepay 6.1.0 2004-03 CN#23 NP-040138 689 1 NoReply timer clarification for follow-on calls 6.1.0 2004-03 CN#23 NP-040096 693 1 Adding the Layer Compatibility information elements over the gsmSSF Ð gsmSCF interface 6.1.0 2004-03 CN#23 NP-040136 694 Correction to dialed services triggering for NP and NC calls 6.1.0 2004-03 CN#23 NP-040136 695 Correction to No Answer handling (CAMEL_OCH_MSC2) 6.1.0 2004-03 CN#23 NP-040136 696 Correction to handling of DFC in CS_gsmSSF 6.1.0 2004-03 CN#23 NP-040136 697 Correction to both way through parameter for ETC and CTR 6.1.0 2004-03 CN#23 NP-040136 698 Correction to forwarded leg handling with Suppress O-CSI 6.1.0 2004-03 CN#23 NP-040136 699 Correction to ORLCF handling for CAMEL calls in VMSC 6.1.0 2004-03 CN#23 NP-040136 700 Handling of DFCWA in ETC and CTR procedures 6.1.0 2004-03 CN#23 NP-040137 701 Correction to CUG handling for NP calls 6.1.0 2004-03 CN#23 NP-040137 702 Correction to CAMEL_ICA_MSC (hanging connector) 6.1.0 2004-03 CN#23 NP-040137 703 Correction to Request Report BCSM Event handling in CSA_gsmSSF 6.1.0 2004-03 CN#23 NP-040137 704 Correction to Split Leg handling in CSA_gsmSSF 6.1.0 2004-03 CN#23 NP-040137 705 Correction to CS ID Prompt & Collect 6.1.0 2004-03 CN#23 NP-040137 706 Correction to SplitLeg preconditions 6.1.0 2004-03 CN#23 NP-040138 707 Correction to Disconnect Leg preconditions 6.1.0 2004-03 CN#23 NP-040136 708 Correction to Information Location at DP O_Term_Seized 6.1.0 2004-03 CN#23 NP-040138 710 Starting of Timer Tccd after ACR on DP 'Change of Position' 6.1.0 2004-03 CN#23 NP-040137 711 Correction to Tssf timer at Apply Charging 6.1.0 2004-03 CN#23 NP-040137 712 Allowing Export_leg at DP Alerting and DP Answer 6.1.0 2004-06 CN#24 NP-040249 685 3 IP version of GGSN address for CAMEL 6.2.0 2004-06 CN#24 NP-040249 716 3 Enhancement to User Interaction 6.2.0 2004-06 CN#24 NP-040207 721 1 Correction to Tssf timer 6.2.0 2004-06 CN#24 NP-040207 722 Correction to D-CSI suppression in Continue With Argument 6.2.0 2004-06 CN#24 NP-040249 723 Correction to CS_gsmSSF for call release 6.2.0 2004-06 CN#24 NP-040249 724 Stopping charging timers after CancelÊ[All] 6.2.0 2004-06 CN#24 NP-040207 725 Correction to Move Leg pre-condition 6.2.0 2004-06 CN#24 NP-040207 726 Correction to InitialDP IF for NP leg 6.2.0 2004-06 CN#24 NP-040207 727 Correction to User Interaction before Answer 6.2.0 2004-06 CN#24 NP-040207 728 Correction to Entity Released for individual call party 6.2.0 2004-09 CN#25 NP-040405 732 2 Support of User-to-User Information (UUI) in CAMEL InitialDP operation 6.3.0 2004-09 CN#25 NP-040406 731 Correcting status in the procedure CAMEL_MT_CTR(sheet 4) 6.3.0 2004-09 CN#25 NP-040406 732 Redundantly modifying call parameter in CAMEL_MT_GMSC_Notify_CF 6.3.0 2004-09 CN#25 NP-040406 733 Correcting SDL of Process CS_gsmSSF(sheet 7) 6.3.0 2004-09 CN#25 NP-040406 735 2 Appended a note in Process CAMEL_ICA_MSC 6.3.0 2004-09 CN#25 NP-040406 737 Correction to CAP SCI for calls with multiple CAP dialogues 6.3.0 2004-09 CN#25 NP-040406 738 Correction to CAMEL_ICA_MSC1 and CAMEL_ICA_MSC2 6.3.0 2004-09 CN#25 NP-040406 739 Removal of Int_O_Exception from CAMEL_OCH_MSC2 and CAMEL_MT_GMSC_DISC5 6.3.0 2004-09 CN#25 NP-040406 740 Correction to CAMEL_Modify_CUG_Info 6.3.0 2004-09 CN#25 NP-040406 741 Correction to CAMEL_EXPORT_LEG_MSC procedure 6.3.0 2004-09 CN#25 NP-040406 743 Correction to CS_gsmSSF for EDS 6.3.0 2004-09 CN#25 NP-040406 744 Correction to CS_gsmSSF for Tcp expiry 6.3.0 2004-09 CN#25 NP-040406 745 Correction to Handle_ACR procedure for Tccd timer 6.3.0 2004-09 CN#25 NP-040406 747 Correction to any Time Interrogation 6.3.0 2004-09 CN#25 NP-040406 730 1 Editorial correction 6.3.0 2004-12 CN#26 NP-040525 748 5 Clarification on Outstanding Request Counter (ORC) handling at EDP-R or TDP-R resumption 6.4.0 2004-12 CN#26 NP-040544 749 2 Correcting SDL of Process CS_gsmSSF (sheet 62) 6.4.0 2004-12 CN#26 NP-040544 752 Correction to Change of Position handling in gsmSSF 6.4.0 2004-12 CN#26 NP-040544 753 1 Correction in Sheet 18 of Process CSA_gsmSSF 6.4.0 2004-12 CN#26 NP-040544 757 1 Warning Tone 6.4.0 2005-01 CS_gsmSSF SDL file updated 6.4.1 2005-03 CN#27 NP-050051 762 1 CR 693 not implemented 6.5.0 2005-06 CT#28 CP-050097 763 1 Correction to DP T_No_Answer 6.6.0 2005-06 CT#28 CP-050097 765 Correction to conditional triggering for SCUDIF call 6.6.0 2005-06 CT#28 CP-050083 767 1 Correction to CAMEL_MO_Dialled_Services 6.6.0 2005-06 CT#28 CP-050097 769 Correction to Outstanding Request Counter setting at IDP handling 6.6.0 2005-06 CT#28 CP-050083 772 Correction to No_Answer handling in CAMEL_ICA_MSC2 6.6.0 2005-06 CT#28 CP-050083 774 Correction to CAMEL_ICA_MSC1 and CAMEL_ICA_MSC2 for gsmSSF process checking 6.6.0 2005-06 CT#28 CP-050083 776 Correction to EDP-N handling for ICA legs in Process CS_gsmSSF 6.6.0 2005-06 CT#28 CP-050097 780 4 NoReply Timer clarification 6.6.0 2005-06 CT#28 CP-050103 764 1 CAMEL procedures for trunk originated services 7.0.0 2005-09 CT#29 CP-050312 781 1 Trunk Originated CAMEL triggering Ð SDLs (re-introduce CR770) 7.1.0 2005-09 CT#29 CP-050312 784 2 Additions and clarifications for CAMEL trunk originated services 7.1.0 2005-09 CT#29 CP-050309 786 Adding a missing reference 7.1.0 2005-09 CT#29 CP-050309 789 Correction on Outstanding Request Counter handling 7.1.0 2005-09 CT#29 CP-050309 791 Correction on T_Disconnect handling 7.1.0 2005-12 CT#30 CP-050626 0792 2 Trunk Originated CAMEL triggering Ð DTMF and CollectInfo parameters in SDL 7.2.0 2005-12 CT#30 CP-050626 0793 1 Modification Procedure CAMEL_OCH_LEG1_MSC 11(13) 7.2.0 2006-03 CT#31 CP-060082 0794 Specification of gsmSCF Address format in AnyTime request messages 7.3.0 2006-06 CT#32 CP-060311 0796 1 Addition of information related to service change 7.4.0 2006-06 CT#32 CP-060336 0797 2 List of MSISDNs and Basic Service Code for MAP Any Time Subscription Interrogation. 7.4.0 2006-06 CT#32 CP-060300 0798 1 Corrections of Process CS_gsmSSF 7.4.0 2006-09 CT#33 CP-060414 0806 1 Response to ATI for GPRS information when PSI not supported in the SGSN 7.5.0 2006-09 CT#33 CP-060414 0807 SGSN number to be included in the ATI response 7.5.0 2006-12 CT#34 CP-060695 0810 1 Optional Suppress Terminating Services Bit String in SRI 7.6.0 2007-03 CT#35 CP-070030 0813 1 Addition of SMS over IP functionality 7.7.0 2007-06 CT#36 CP-070328 0815 Mobile Termination whilst the MS is moving to another MSC 7.8.0 2007-06 CT#36 CP-070326 0816 1 Correction of IP-SM-GW update in the HSS 7.8.0 2007-06 CT#36 CP-070325 0822 2 Adding a Information Element to Continue Camel Handling Information Flow 7.8.0 2007-06 CT#36 CP-070325 0823 Mutually exclusive elements in Location Information in MSC for Initial DP SMS 7.8.0 2007-06 CT#36 CP-070325 0824 1 Correction to DTMF detection in alerting phase 7.8.0 2007-09 CT#37 CP-070540 0814 4 AC/ACR Handling 7.9.0 2007-09 CT#37 CP-070540 0826 Correction to the Send Info For Incoming Call ack Information Flow 7.9.0 2008-12 CT#42 Upgrade to Release 8 without technical change 8.0.0 2009-09 CT#45 CP-090524 0831 2 Correction on ACR and Warning Tone Play Handling of Leg 1 when successful move of a leg 8.1.0 2009-12 - - - - Update to Rel-9 version (MCC) 9.0.0 2010-03 CT#47 CP-100029 0832 1 User CSG Information for CAMEL 9.1.0 2010-09 CT#49 CP-100449 0835 1 Correction for SMS via SGs charging 9.2.0 2010-09 CT#49 CP-100467 0836 2 Addition of SS codes to the ATSI and ATM procedures 10.0.0 2011-09 CT#53 CP-110732 0837 2 Extension parameter for Release Call 11.0.0 2011-12 CT#54 CP-110780 0841 1 Provide Subscriber Information handling for UE under LTE 11.1.0 2012-03 CT#55 CP-120038 0842 2 EPS Location in IDP SMS 11.2.0 2012-06 CT#56 CP-120244 0843 - EPS location in Initial DP 11.3.0 2012-06 CT#56 CP-120244 0844 - EPS location in MAP Note MM Event 11.3.0 2012-09 CT#61 CP-130468 0845 - Clarification of allowed values for SS-status in Any Time Modification procedure 12.0.0 2015-12 CT#70 - - - Update to Rel-13 version (MCC) 13.0.0 2017-03 CT#75 - - - Update to Rel-14 version (MCC) 14.0.0 2018-06 -CT#80 - - - Update to Rel-15 version (MCC) 15.0.0 2020-07 - - - - Update to Rel-16 version (MCC) 16.0.0 2022-03 - - - - Update to Rel-17 version (MCC) 17.0.0 3GPP TS 23.078 V17.0.0 (2022-03) 750 Release 17 3GPP Network Working Group J. Sjoberg Request for Comments: 4867 M. Westerlund Obsoletes: 3267 Ericsson Category: Standards Track A. Lakaniemi Nokia Q. Xie Motorola April 2007 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ""Internet Official Protocol Standards"" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi- Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. Sjoberg, et al. Standards Track [Page 1] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Table of Contents 1. Introduction ....................................................4 2. Conventions and Acronyms ........................................4 3. Background on AMR/AMR-WB and Design Principles ..................5 3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5 3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6 3.3. Multi-Rate Encoding and Mode Adaptation ....................6 3.4. Voice Activity Detection and Discontinuous Transmission ....7 3.5. Support for Multi-Channel Session ..........................7 3.6. Unequal Bit-Error Detection and Protection .................8 3.6.1. Applying UEP and UED in an IP Network ...............8 3.7. Robustness against Packet Loss ............................10 3.7.1. Use of Forward Error Correction (FEC) ..............10 3.7.2. Use of Frame Interleaving ..........................12 3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12 3.9. AMR or AMR-WB Speech over IP Scenarios ....................13 4. AMR and AMR-WB RTP Payload Formats .............................15 4.1. RTP Header Usage ..........................................15 4.2. Payload Structure .........................................17 4.3. Bandwidth-Efficient Mode ..................................17 4.3.1. The Payload Header .................................17 4.3.2. The Payload Table of Contents ......................18 4.3.3. Speech Data ........................................20 4.3.4. Algorithm for Forming the Payload ..................21 4.3.5. Payload Examples ...................................21 4.3.5.1. Single-Channel Payload Carrying a Single Frame ..............................21 4.3.5.2. Single-Channel Payload Carrying Multiple Frames ...........................22 4.3.5.3. Multi-Channel Payload Carrying Multiple Frames ...........................23 4.4. Octet-Aligned Mode ........................................25 4.4.1. The Payload Header .................................25 4.4.2. The Payload Table of Contents and Frame CRCs .......26 4.4.2.1. Use of Frame CRC for UED over IP ..........28 4.4.3. Speech Data ........................................30 4.4.4. Methods for Forming the Payload ....................31 4.4.5. Payload Examples ...................................32 4.4.5.1. Basic Single-Channel Payload Carrying Multiple Frames ..................32 4.4.5.2. Two-Channel Payload with CRC, Interleaving, and Robust Sorting ..........32 4.5. Implementation Considerations .............................33 4.5.1. Decoding Validation ................................34 5. AMR and AMR-WB Storage Format ..................................35 5.1. Single-Channel Header .....................................35 5.2. Multi-Channel Header ......................................36 Sjoberg, et al. Standards Track [Page 2] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5.3. Speech Frames .............................................37 6. Congestion Control .............................................38 7. Security Considerations ........................................38 7.1. Confidentiality ...........................................39 7.2. Authentication and Integrity ..............................39 8. Payload Format Parameters ......................................39 8.1. AMR Media Type Registration ...............................40 8.2. AMR-WB Media Type Registration ............................44 8.3. Mapping Media Type Parameters into SDP ....................47 8.3.1. Offer-Answer Model Considerations ..................48 8.3.2. Usage of Declarative SDP ...........................50 8.3.3. Examples ...........................................51 9. IANA Considerations ............................................53 10. Changes from RFC 3267 .........................................53 11. Acknowledgements ..............................................55 12. References ....................................................55 12.1. Normative References .....................................55 12.2. Informative References ...................................56 Sjoberg, et al. Standards Track [Page 3] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 1. Introduction This document obsoletes RFC 3267 and extends that specification with offer/answer rules. See Section 10 for the changes made to this format in relation to RFC 3267. This document specifies the payload format for packetization of AMR and AMR-WB encoded speech signals into the Real-time Transport Protocol (RTP) [8]. The payload format supports transmission of multiple channels, multiple frames per payload, the use of fast codec mode adaptation, robustness against packet loss and bit errors, and interoperation with existing AMR and AMR-WB transport formats on non-IP networks, as described in Section 3. The payload format itself is specified in Section 4. A related file format is specified in Section 5 for transport of AMR and AMR-WB speech data in storage mode applications such as email. In Section 8, two separate media type registrations are provided, one for AMR and one for AMR-WB. Even though this RTP payload format definition supports the transport of both AMR and AMR-WB speech, it is important to remember that AMR and AMR-WB are two different codecs and they are always handled as different payload types in RTP. 2. Conventions and Acronyms The key words ""MUST"", ""MUST NOT"", ""REQUIRED"", ""SHALL"", ""SHALL NOT"", ""SHOULD"", ""SHOULD NOT"", ""RECOMMENDED"", ""MAY"", and ""OPTIONAL"" in this document are to be interpreted as described in RFC 2119 [5]. The following acronyms are used in this document: 3GPP - the Third Generation Partnership Project AMR - Adaptive Multi-Rate (Codec) AMR-WB - Adaptive Multi-Rate Wideband (Codec) CMR - Codec Mode Request CN - Comfort Noise DTX - Discontinuous Transmission ETSI - European Telecommunications Standards Institute FEC - Forward Error Correction SCR - Source Controlled Rate Operation SID - Silence Indicator (the frames containing only CN parameters) VAD - Voice Activity Detection UED - Unequal Error Detection UEP - Unequal Error Protection Sjoberg, et al. Standards Track [Page 4] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The term ""frame-block"" is used in this document to describe the time-synchronized set of speech frames in a multi-channel AMR or AMR-WB session. In particular, in an N-channel session, a frame- block will contain N speech frames, one from each of the channels, and all N speech frames represents exactly the same time period. The byte order used in this document is network byte order, i.e., the most significant byte first. The bit order is also the most significant bit first. This is presented in all figures as having the most significant bit leftmost on a line and with the lowest number. Some bit fields may wrap over multiple lines in which cases the bits on the first line are more significant than the bits on the next line. 3. Background on AMR/AMR-WB and Design Principles AMR and AMR-WB were originally designed for circuit-switched mobile radio systems. Due to their flexibility and robustness, they are also suitable for other real-time speech communication services over packet-switched networks such as the Internet. Because of the flexibility of these codecs, the behavior in a particular application is controlled by several parameters that select options or specify the acceptable values for a variable. These options and variables are described in general terms at appropriate points in the text of this specification as parameters to be established through out-of-band means. In Section 8, all of the parameters are specified in the form of media subtype registrations for the AMR and AMR-WB encodings. The method used to signal these parameters at session setup or to arrange prior agreement of the participants is beyond the scope of this document; however, Section 8.3 provides a mapping of the parameters into the Session Description Protocol (SDP) [11] for those applications that use SDP. 3.1. The Adaptive Multi-Rate (AMR) Speech Codec The AMR codec was originally developed and standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems. It is now chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems [1]. The AMR codec is a multi-mode codec that supports eight narrow band speech encoding modes with bit rates between 4.75 and 12.2 kbps. The sampling frequency used in AMR is 8000 Hz and the speech encoding is performed on 20 ms speech frames. Therefore, each encoded AMR speech frame represents 160 samples of the original speech. Sjoberg, et al. Standards Track [Page 5] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Among the eight AMR encoding modes, three are already separately adopted as standards of their own. Particularly, the 6.7 kbps mode is adopted as PDC-EFR [18], the 7.4 kbps mode as IS-641 codec in TDMA [17], and the 12.2 kbps mode as GSM-EFR [16]. 3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was originally developed by 3GPP to be used in GSM and 3G cellular systems. Similar to AMR, the AMR-WB codec is also a multi-mode speech codec. AMR-WB supports nine wide band speech coding modes with respective bit rates ranging from 6.6 to 23.85 kbps. The sampling frequency used in AMR-WB is 16000 Hz and the speech processing is performed on 20 ms frames. This means that each AMR-WB encoded frame represents 320 speech samples. 3.3. Multi-Rate Encoding and Mode Adaptation The multi-rate encoding (i.e., multi-mode) capability of AMR and AMR-WB is designed for preserving high speech quality under a wide range of transmission conditions. With AMR or AMR-WB, mobile radio systems are able to use available bandwidth as effectively as possible. For example, in GSM it is possible to dynamically adjust the speech encoding rate during a session so as to continuously adapt to the varying transmission conditions by dividing the fixed overall bandwidth between speech data and error protective coding. This enables the best possible trade-off between speech compression rate and error tolerance. To perform mode adaptation, the decoder (speech receiver) needs to signal the encoder (speech sender) the new mode it prefers. This mode change signal is called Codec Mode Request or CMR. Since in most sessions speech is sent in both directions between the two ends, the mode requests from the decoder at one end to the encoder at the other end are piggy-backed over the speech frames in the reverse direction. In other words, there is no out-of-band signaling needed for sending CMRs. Every AMR or AMR-WB codec implementation is required to support all the respective speech coding modes defined by the codec and must be able to handle mode switching to any of the modes at any time. However, some transport systems may impose limitations in the number of modes supported and how often the mode can change due to bandwidth Sjoberg, et al. Standards Track [Page 6] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 limitations or other constraints. For this reason, the decoder is allowed to indicate its acceptance of a particular mode or a subset of the defined modes for the session using out-of-band means. For example, the GSM radio link can only use a subset of at most four different modes in a given session. This subset can be any combination of the eight AMR modes for an AMR session or any combination of the nine AMR-WB modes for an AMR-WB session. Moreover, for better interoperability with GSM through a gateway, the decoder is allowed to use out-of-band means to set the minimum number of frames between two mode changes and to limit the mode change among neighboring modes only. Section 8 specifies a set of media type parameters that may be used to signal these mode adaptation controls at session setup. 3.4. Voice Activity Detection and Discontinuous Transmission Both codecs support voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. Hence, the codecs have the option to reduce the number of transmitted bits and packets during silence periods to a minimum. The operation of sending CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The AMR or AMR-WB frames containing CN parameters are called Silence Indicator (SID) frames. See more details about VAD and DTX functionality in [9] and [10]. 3.5. Support for Multi-Channel Session Both the RTP payload format and the storage format defined in this document support multi-channel audio content (e.g., a stereophonic speech session). Although AMR and AMR-WB codecs themselves do not support encoding of multi-channel audio content into a single bit stream, they can be used to separately encode and decode each of the individual channels. To transport (or store) the separately encoded multi-channel content, the speech frames for all channels that are framed and encoded for the same 20 ms periods are logically collected in a frame-block. At the session setup, out-of-band signaling must be used to indicate the number of channels in the session, and the order of the speech frames from different channels in each frame-block. When using SDP for signaling, the number of channels is specified in the rtpmap attribute and the order of channels carried in each frame-block is Sjoberg, et al. Standards Track [Page 7] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 implied by the number of channels as specified in Section 4.1 in [12]. 3.6. Unequal Bit-Error Detection and Protection The speech bits encoded in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. This property has been exploited in cellular systems to achieve better voice quality by using unequal error protection and detection (UEP and UED) mechanisms. The UEP/UED mechanisms focus the protection and detection of corrupted bits to the perceptually most sensitive bits in an AMR or AMR-WB frame. In particular, speech bits in an AMR or AMR-WB frame are divided into class A, B, and C, where bits in class A are the most sensitive and bits in class C the least sensitive (see Table 1 below for AMR and [4] for AMR-WB). An AMR or AMR-WB frame is only declared damaged if there are bit errors found in the most sensitive bits, i.e., the class A bits. On the other hand, it is acceptable to have some bit errors in the other bits, i.e., class B and C bits."
"Class A Total speech Index Mode bits bits ---------------------------------------- 0 AMR 4.75 42 95 1 AMR 5.15 49 103 2 AMR 5.9 55 118 3 AMR 6.7 58 134 4 AMR 7.4 61 148 5 AMR 7.95 75 159 6 AMR 10.2 65 204 7 AMR 12.2 81 244 8 AMR SID 39 39 Table 1. The number of class A bits for the AMR codec Moreover, a damaged frame is still useful for error concealment at the decoder since some of the less sensitive bits can still be used. This approach can improve the speech quality compared to discarding the damaged frame. 3.6.1. Applying UEP and UED in an IP Network To take full advantage of the bit-error robustness of the AMR and AMR-WB codec, the RTP payload format is designed to facilitate UEP/UED in an IP network. It should be noted however that the utilization of UEP and UED discussed below is OPTIONAL. Sjoberg, et al. Standards Track [Page 8] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 UEP/UED in an IP network can be achieved by detecting bit errors in class A bits and tolerating bit errors in class B/C bits of the AMR or AMR-WB frame(s) in each RTP payload. Link-layer protocols exist that do not discard packets containing bit errors, e.g., SLIP and some wireless links. With the Internet traffic pattern shifting towards a more multimedia-centric one, more link layers of such nature may emerge in the future. With transport layer support for partial checksums (for example, those supported by UDP-Lite [19]), bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links. The relationship between UDP-Lite's partial checksum at the transport layer and the checksum coverage provided by the link-layer frame is described in UDP-Lite specification [19]. There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant IP networks: a) Utilizing a partial checksum to cover the IP, transport protocol (e.g., UDP-Lite), RTP and payload headers, and the most important speech bits of the payload. The IP, UDP and RTP headers need to be protected, and it is recommended that at least all class A bits are covered by the checksum. b) Utilizing a partial checksum to only cover the IP, transport protocol, RTP and payload headers, but an AMR or AMR-WB frame CRC to cover the class A bits of each speech frame in the RTP payload. In either approach, at least part of the class B/C bits are left without error-check and thus bit error tolerance is achieved. Note, it is still important that the network designer pays attention to the class B and C residual bit error rate. Though less sensitive to errors than class A bits, class B and C bits are not insignificant, and undetected errors in these bits cause degradation in speech quality. An example of residual error rates considered acceptable for AMR in the Universal Mobile Telecommunications System (UMTS) can be found in [24] and for AMR-WB in [25]. The application interface to the UEP/UED transport protocol (e.g., UDP-Lite) may not provide any control over the link error rate, especially in a gateway scenario. Therefore, it is incumbent upon the designer of a node with a link interface of this type to choose a residual bit error rate that is low enough to support applications such as AMR encoding when transmitting packets of a UEP/UED transport protocol. Sjoberg, et al. Standards Track [Page 9] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Approach 1 is bit efficient, flexible and simple, but comes with two disadvantages, namely, a) bit errors in protected speech bits will cause the payload to be discarded, and b) when transporting multiple AMR or AMR-WB frames in a RTP payload, there is the possibility that a single bit error in protected bits will cause all the frames to be discarded. These disadvantages can be avoided, if needed, with some overhead in the form of a frame-wise CRC (Approach 2). In problem a), the CRC makes it possible to detect bit errors in class A bits and use the frame for error concealment, which gives a small improvement in speech quality. For b), when transporting multiple frames in a payload, the CRCs remove the possibility that a single bit error in a class A bit will cause all the frames to be discarded. Avoiding that improves the speech quality when transporting multiple AMR or AMR-WB frames over links subject to bit errors. The choice between the above two approaches must be made based on the available bandwidth, and the desired tolerance to bit errors. Neither solution is appropriate for all cases. Section 8 defines parameters that may be used at session setup to choose between these approaches. 3.7. Robustness against Packet Loss The payload format supports several means, including forward error correction (FEC) and frame interleaving, to increase robustness against packet loss. 3.7.1. Use of Forward Error Correction (FEC) The simple scheme of repetition of previously sent data is one way of achieving FEC. Another possible scheme which is more bandwidth efficient is to use payload-external FEC, e.g., RFC 2733 [23], which generates extra packets containing repair data. The whole payload can also be sorted in sensitivity order to support external FEC schemes using UEP. There is also a work in progress on a generic version of such a scheme [22] that can be applied to AMR or AMR-WB payload transport. With AMR or AMR-WB, it is possible to use the multi-rate capability of the codec to send redundant copies of a frame using either the same mode or another mode, e.g., one with lower bandwidth. We describe such a scheme next. Sjoberg, et al. Standards Track [Page 10] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 This involves the simple retransmission of previously transmitted frame-blocks together with the current frame-block(s). This is done by using a sliding window to group the speech frame-blocks to send in each payload. Figure 1 below shows us an example. --+--------+--------+--------+--------+--------+--------+--------+-- | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | --+--------+--------+--------+--------+--------+--------+--------+-- <---- p(n-1) ----> <----- p(n) -----> <---- p(n+1) ----> <---- p(n+2) ----> <---- p(n+3) ----> <---- p(n+4) ----> Figure 1: An example of redundant transmission In this example each frame-block is retransmitted one time in the following RTP payload packet. Here, f(n-2)..f(n+4) denotes a sequence of speech frame-blocks, and p(n-1)..p(n+4) a sequence of payload packets. The use of this approach does not require signaling at the session setup. However, a parameter for providing a maximum delay in transmitting any redundant frame is defined in Section 8. In other words, the speech sender can choose to use this scheme without consulting the receiver. This is because a packet containing redundant frames will not look different from a packet with only new frames. The receiver may receive multiple copies or versions (encoded with different modes) of a frame for a certain timestamp if no packet is lost. If multiple versions of the same speech frame are received, it is recommended that the mode with the highest rate be used by the speech decoder. This redundancy scheme provides the same functionality as the one described in RFC 2198, ""RTP Payload for Redundant Audio Data"" [27]. In most cases the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198 in addition. There are two situations in which use of RFC 2198 is indicated: if the spread in time required between the primary and redundant encodings is larger than the duration of 5 frames, the bandwidth overhead of RFC 2198 will be lower; or, if a non-AMR codec is desired for the redundant encoding, the AMR payload format won't be able to carry it. The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel, e.g., in RTCP Sjoberg, et al. Standards Track [Page 11] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 receiver reports. A sender should not base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information, e.g., radio link performance measures. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 6 for more details). 3.7.2. Use of Frame Interleaving To decrease protocol overhead, the payload design allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that packet loss can cause loss of several consecutive speech frame-blocks, which usually causes clearly audible distortion in the reconstructed speech. Interleaving of frame-blocks can improve the speech quality in such cases by distributing the consecutive losses into a series of single frame- block losses. However, interleaving and bundling several frame- blocks per payload will also increase end-to-end delay and is therefore not appropriate for all types of applications. Streaming applications will most likely be able to exploit interleaving to improve speech quality in lossy transmission conditions. This payload design supports the use of frame interleaving as an option. For the encoder (speech sender) to use frame interleaving in its outbound RTP packets for a given session, the decoder (speech receiver) needs to indicate its support via out-of-band means (see Section 8). 3.8. Bandwidth-Efficient or Octet-Aligned Mode For a given session, the payload format can be either bandwidth efficient or octet aligned, depending on the mode of operation that is established for the session via out-of-band means. In the octet-aligned format, all the fields in a payload, including payload header, table of contents entries, and speech frames themselves, are individually aligned to octet boundaries to make implementations efficient. In the bandwidth-efficient format, only the full payload is octet aligned, so fewer padding bits are added. Note, octet alignment of a field or payload means that the last octet is padded with zeroes in the least significant bits to fill the octet. Also note that this padding is separate from padding indicated by the P bit in the RTP header. Between the two operation modes, only the octet-aligned mode has the capability to use the robust sorting, interleaving, and frame CRC to make the speech transport more robust to packet loss and bit errors. Sjoberg, et al. Standards Track [Page 12] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 3.9. AMR or AMR-WB Speech over IP Scenarios The primary scenario for this payload format is IP end-to-end between two terminals, as shown in Figure 2. This payload format is expected to be useful for both conversational and streaming services. +----------+ +----------+ | | IP/UDP/RTP/AMR or | | | TERMINAL |<----------------------->| TERMINAL | | | IP/UDP/RTP/AMR-WB | | +----------+ +----------+ Figure 2: IP terminal to IP terminal scenario A conversational service puts requirements on the payload format. Low delay is one very important factor, i.e., few speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses low bandwidth links, especially as the frequency of packets will be high. For low bandwidth links, it is also an advantage to support UED, which allows a link provider to reduce delay and packet loss, or to reduce the utilization of link resources. A streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than a conversational service. This reduces the overhead from IP, UDP, and RTP headers. However, including several frame-blocks per packet makes the transmission more vulnerable to packet loss, so interleaving may be used to reduce the effect that packet loss will have on speech quality. A streaming server handling a large number of clients also needs a payload format that requires as few resources as possible when doing packetization. The octet-aligned and interleaving modes require the least amount of resources, while CRC, robust sorting, and bandwidth-efficient modes have higher demands. Another scenario is when AMR or AMR-WB encoded speech is transmitted from a non-IP system (e.g., a GSM or 3GPP UMTS network) to an IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3. Sjoberg, et al. Standards Track [Page 13] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 AMR or AMR-WB over I.366.{2,3} or +------+ +----------+ 3G Iu or | | IP/UDP/RTP/AMR or | | <------------->| GW |<---------------------->| TERMINAL | GSM Abis | | IP/UDP/RTP/AMR-WB | | etc. +------+ +----------+ | GSM/ | IP network 3GPP UMTS network | Figure 3: GW to VoIP terminal scenario In such a case, it is likely that the AMR or AMR-WB frame is packetized in a different way in the non-IP network and will need to be re-packetized into RTP at the gateway. Also, speech frames from the non-IP network may come with some UEP/UED information (e.g., a frame quality indicator) that will need to be preserved and forwarded on to the decoder along with the speech bits. This is specified in Section 4.3.2. AMR's capability to do fast mode switching is exploited in some non- IP networks to optimize speech quality. To preserve this functionality in scenarios including a gateway to an IP network, a codec mode request (CMR) field is needed. The gateway will be responsible for forwarding the CMR between the non-IP and IP parts in both directions. The IP terminal should follow the CMR forwarded by the gateway to optimize speech quality going to the non-IP decoder. The mode control algorithm in the gateway must accommodate the delay imposed by the IP network on the IP terminal's response to CMR. The IP terminal should not set the CMR (see Section 4.3.1), but the gateway can set the CMR value on frames going toward the encoder in the non-IP part to optimize speech quality from that encoder to the gateway. The gateway can alternatively set a lower CMR value, if desired, as one means to control congestion on the IP network. A third likely scenario is that IP/UDP/RTP is used as transport between two non-IP systems, i.e., IP is originated and terminated in gateways on both sides of the IP transport, as illustrated in Figure 4 below. Sjoberg, et al. Standards Track [Page 14] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 AMR or AMR-WB AMR or AMR-WB over over I.366.{2,3} or +------+ +------+ I.366.{2,3} or 3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or <------------->| GW |<------------------->| GW |<-------------> GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis etc. +------+ +------+ etc. | | GSM/ | IP network | GSM/ 3GPP UMTS network | | 3GPP UMTS network Figure 4: GW to GW scenario This scenario requires the same mechanisms for preserving UED/UEP and CMR information as in the single gateway scenario. In addition, the CMR value may be set in packets received by the gateways on the IP network side. The gateway should forward to the non-IP side a CMR value that is the minimum of three values: - the CMR value it receives on the IP side; - the CMR value it calculates based on its reception quality on the non-IP side; and - a CMR value it may choose for congestion control of transmission on the IP side. The details of the control algorithm are left to the implementation. 4. AMR and AMR-WB RTP Payload Formats The AMR and AMR-WB payload formats have identical structure, so they are specified together. The only differences are in the types of codec frames contained in the payload. The payload format consists of the RTP header, payload header, and payload data. 4.1. RTP Header Usage The format of the RTP header is specified in [8]. This payload format uses the fields of the header in a manner consistent with that specification. The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency is the same as the sampling frequency, so the timestamp unit is in samples. Sjoberg, et al. Standards Track [Page 15] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The duration of one speech frame-block is 20 ms for both AMR and AMR-WB. For AMR, the sampling frequency is 8 kHz, corresponding to 160 encoded speech samples per frame from each channel. For AMR-WB, the sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 160 for AMR and 320 for AMR-WB for each consecutive frame-block. A packet may contain multiple frame-blocks of encoded speech or comfort noise parameters. If interleaving is employed, the frame- blocks encapsulated into a payload are picked according to the interleaving rules as defined in Section 4.4.1. Otherwise, each packet covers a period of one or more contiguous 20 ms frame-block intervals. In case the data from all the channels for a particular frame-block in the period is missing (for example, at a gateway from some other transport format), it is possible to indicate that no data is present for that frame-block rather than breaking a multi-frame- block packet into two, as explained in Section 4.3.2. To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any speech frame multiple times, in exact duplicates, in different AMR rate modes, or with data present in one packet and not present in another. If multiple versions of the same speech frame are received, it is RECOMMENDED that the mode with the highest rate be used by the speech decoder. A given frame MUST NOT be encoded as speech in one packet and comfort noise parameters in another. The payload length is always made an integral number of octets by padding with zero bits if necessary. If additional padding is required to bring the payload length to a larger multiple of octets or for some other purpose, then the P bit in the RTP in the header may be set and padding appended as specified in [8]. The RTP header marker bit (M) SHALL be set to 1 if the first frame- block carried in the packet contains a speech frame which is the first in a talkspurt. For all other packets the marker bit SHALL be set to zero (M=0). The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this encoding or specify that the payload type is to be bound dynamically. Sjoberg, et al. Standards Track [Page 16] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.2. Payload Structure The complete payload consists of a payload header, a payload table of contents, and speech data representing one or more speech frame- blocks. The following diagram shows the general payload format layout: +----------------+-------------------+---------------- | payload header | table of contents | speech data ... +----------------+-------------------+---------------- Payloads containing more than one speech frame-block are called compound payloads. The following sections describe the variations taken by the payload format depending on whether the AMR session is set up to use the bandwidth-efficient mode or octet-aligned mode and any of the OPTIONAL functions for robust sorting, interleaving, and frame CRCs. Implementations SHOULD support both bandwidth-efficient and octet- aligned operation to increase interoperability. 4.3. Bandwidth-Efficient Mode 4.3.1. The Payload Header In bandwidth-efficient mode, the payload header simply consists of a 4-bit codec mode request: 0 1 2 3 +-+-+-+-+ | CMR | +-+-+-+-+ CMR (4 bits): Indicates a codec mode request sent to the speech encoder at the site of the receiver of this payload. The value of the CMR field is set to the frame type index of the corresponding speech mode being requested. The frame type index may be 0-7 for AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined in Table 1a in [4]. CMR value 15 indicates that no mode request is present, and other values are for future use. The codec mode request received in the CMR field is valid until the next codec mode request is received, i.e., a newly received CMR value corresponding to a speech mode, or NO_DATA overrides the previously received CMR value corresponding to a speech mode or NO_DATA. Therefore, if a terminal continuously wishes to receive frames in the Sjoberg, et al. Standards Track [Page 17] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 same mode X, it needs to set CMR=X for all its outbound payloads, and if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads. If receiving a payload with a CMR value that is not a speech mode or NO_DATA, the CMR MUST be ignored by the receiver. In a multi-channel session, the codec mode request SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session. An IP end-point SHOULD NOT set the codec mode request based on packet losses or other congestion indications, for several reasons: - The other end of the IP path may be a gateway to a non-IP network (such as a radio link) that needs to set the CMR field to optimize performance on that network. - Congestion on the IP network is managed by the IP sender, in this case, at the other end of the IP path. Feedback about congestion SHOULD be provided to that IP sender through RTCP or other means, and then the sender can choose to avoid congestion using the most appropriate mechanism. That may include adjusting the codec mode, but also includes adjusting the level of redundancy or number of frames per packet. The encoder SHOULD follow a received codec mode request, but MAY change to a lower-numbered mode if it so chooses, for example, to control congestion. The CMR field MUST be set to 15 for packets sent to a multicast group. The encoder in the speech sender SHOULD ignore codec mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a codec mode change is needed. The codec mode selection MAY be restricted by a session parameter to a subset of the available modes. If so, the requested mode MUST be among the signalled subset (see Section 8). If the received CMR value is outside the signalled subset of modes, it MUST be ignored. 4.3.2. The Payload Table of Contents The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame. Sjoberg, et al. Standards Track [Page 18] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 In bandwidth-efficient mode, a ToC entry takes the following format: 0 1 2 3 4 5 +-+-+-+-+-+-+ |F| FT |Q| +-+-+-+-+-+-+ F (1 bit): If set to 1, indicates that this frame is followed by another speech frame in this payload; if set to 0, indicates that this frame is the last frame in this payload. FT (4 bits): Frame type index, indicating either the AMR or AMR-WB speech coding mode or comfort noise (SID) mode of the corresponding frame carried in this payload. The value of FT is defined in Table 1a in [2] for AMR and in Table 1a in [4] for AMR-WB. FT=14 (SPEECH_LOST, only available for AMR-WB) and FT=15 (NO_DATA) are used to indicate frames that are either lost or not being transmitted in this payload, respectively. NO_DATA (FT=15) frame could mean either that no data for that frame has been produced by the speech encoder or that no data for that frame is transmitted in the current payload (i.e., valid data for that frame could be sent in either an earlier or later packet). If receiving a ToC entry with a FT value in the range 9-14 for AMR or 10-13 for AMR-WB, the whole packet SHOULD be discarded. This is to avoid the loss of data synchronization in the depacketization process, which can result in a huge degradation in speech quality. Note that packets containing only NO_DATA frames SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX in [7]. The extra comfort noise frame types specified in table 1a in [2] (i.e., GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this payload format because the standardized AMR codec is only required to implement the general AMR SID frame type and not those that are native to the incorporated encodings. Q (1 bit): Frame quality indicator. If set to 0, indicates the corresponding frame is severely damaged, and the receiver should set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD depending on the frame type (FT). Sjoberg, et al. Standards Track [Page 19] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [20], as well as other transport formats. The frame quality indicator enables damaged frames to be forwarded to the speech decoder for error concealment. This can improve the speech quality more than dropping the damaged frames. See Section 4.4.2.1 for more details. For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order as defined in Section 4.1 in [12]. When multiple frame-blocks are present in a packet in bandwidth-efficient mode, they will be placed in the packet in order of their creation time. Therefore, with N channels and K speech frame-blocks in a packet, there MUST be N*K entries in the ToC, and the first N entries will be from the first frame-block, the second N entries will be from the second frame-block, and so on. The following figure shows an example of a ToC of three entries in a single-channel session using bandwidth-efficient mode. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| FT |Q|1| FT |Q|0| FT |Q| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Below is an example of how the ToC entries will appear in the ToC of a packet carrying three consecutive frame-blocks in a session with two channels (L and R). +----+----+----+----+----+----+ | 1L | 1R | 2L | 2R | 3L | 3R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 1 Block 2 Block 3 4.3.3. Speech Data Speech data of a payload contains zero or more speech frames or comfort noise frames, as described in the ToC of the payload. Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame present in the speech data. Sjoberg, et al. Standards Track [Page 20] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Each speech frame represents 20 ms of speech encoded with the mode indicated in the FT field of the corresponding ToC entry. The length of the speech frame is implicitly defined by the mode indicated in the FT field. The order and numbering notation of the bits are as specified for Interface Format 1 (IF1) in [2] for AMR and [4] for AMR-WB. As specified there, the bits of speech frames have been rearranged in order of decreasing sensitivity, while the bits of comfort noise frames are in the order produced by the encoder. The resulting bit sequence for a frame of length K bits is denoted d(0), d(1), ..., d(K-1). 4.3.4. Algorithm for Forming the Payload The complete RTP payload in bandwidth-efficient mode is formed by packing bits from the payload header, table of contents, and speech frames in order (as defined by their corresponding ToC entries in the ToC list), and to bring the payload to octet alignment, 0 to 7 padding bits. Padding bits MUST be set to zero and MUST be ignored on reception. They are packed contiguously into octets beginning with the most significant bits of the fields and the octets. To be precise, the four-bit payload header is packed into the first octet of the payload with bit 0 of the payload header in the most significant bit of the octet. The four most significant bits (numbered 0-3) of the first ToC entry are packed into the least significant bits of the octet, ending with bit 3 in the least significant bit. Packing continues in the second octet with bit 4 of the first ToC entry in the most significant bit of the octet. If more than one frame is contained in the payload, then packing continues with the second and successive ToC entries. Bit 0 of the first data frame follows immediately after the last ToC bit, proceeding through all the bits of the frame in numerical order. Bits from any successive frames follow contiguously in numerical order for each frame and in consecutive order of the frames. If speech data is missing for one or more speech frame within the sequence, because of, for example, DTX, a ToC entry with FT set to NO_DATA SHALL be included in the ToC for each of the missing frames, but no data bits are included in the payload for the missing frame (see Section 4.3.5.2 for an example). 4.3.5. Payload Examples 4.3.5.1. Single-Channel Payload Carrying a Single Frame The following diagram shows a bandwidth-efficient AMR payload from a single-channel session carrying a single speech frame-block. Sjoberg, et al. Standards Track [Page 21] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 In the payload, no specific mode is requested (CMR=15), the speech frame is not damaged at the IP origin (Q=1), and the coding mode is AMR 7.4 kbps (FT=4). The encoded speech bits, d(0) to d(147), are arranged in descending sensitivity order according to [2]. Finally, two padding bits (P) are added to the end as padding to make the payload octet aligned. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=15|0| FT=4 |1|d(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d(147)|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.5.2. Single-Channel Payload Carrying Multiple Frames The following diagram shows a single-channel, bandwidth-efficient compound AMR-WB payload that contains four frames, of which one has no speech data. The first frame is a speech frame at 6.6 kbps mode (FT=0) that is composed of speech bits d(0) to d(131). The second frame is an AMR-WB SID frame (FT=9), consisting of bits g(0) to g(39). The third frame is a NO_DATA frame and does not carry any speech information, it is represented in the payload by its ToC entry. The fourth frame in the payload is a speech frame at 8.85 kbps mode (FT=1), it consists of speech bits h(0) to h(176). As shown below, the payload carries a mode request for the encoder on the receiver's side to change its future coding mode to AMR-WB 8.85 kbps (CMR=1). None of the frames are damaged at IP origin (Q=1). The encoded speech and SID bits, d(0) to d(131), g(0) to g(39), and h(0) to h(176), are arranged in the payload in descending sensitivity order according to [4]. (Note, no speech bits are present for the third frame.) Finally, seven zero bits are padded to the end to make the payload octet aligned. Sjoberg, et al. Standards Track [Page 22] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=1 |1| FT=0 |1|1| FT=9 |1|1| FT=15 |1|0| FT=1 |1|d(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d(131)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |g(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g(39)|h(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h(176)|P|P|P|P|P|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.5.3. Multi-Channel Payload Carrying Multiple Frames The following diagram shows a two-channel payload carrying 3 frame- blocks, i.e., the payload will contain 6 speech frames. In the payload, all speech frames contain the same mode 7.4 kbps (FT=4) and are not damaged at IP origin. The CMR is set to 15, i.e., no specific mode is requested. The two channels are defined as left (L) and right (R) in that order. The encoded speech bits is designated dXY(0).. dXY(K-1), where X = block number, Y = channel, and K is the number of speech bits for that mode. Exemplifying this, for frame-block 1 of the left channel, the encoded bits are designated as d1L(0) to d1L(147). Sjoberg, et al. Standards Track [Page 23] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4|1|0|3R FT=4|1|d1L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d1L(147)|d1R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d1R(147)|d2L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |d2L(147|d2R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d2R(147)|d3L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d3L(147)|d3R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d3R(147)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sjoberg, et al. Standards Track [Page 24] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4. Octet-Aligned Mode 4.4.1. The Payload Header In octet-aligned mode, the payload header consists of a 4-bit CMR, 4 reserved bits, and optionally, an 8-bit interleaving header, as shown below: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+- - - - - - - - | CMR |R|R|R|R| ILL | ILP | +-+-+-+-+-+-+-+-+- - - - - - - - CMR (4 bits): same as defined in Section 4.3.1. R: is a reserved bit that MUST be set to zero. All R bits MUST be ignored by the receiver. ILL (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled out-of-band for the session. ILL=L indicates to the receiver that the interleaving length is L+1, in number of frame-blocks. ILP (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled. ILP MUST take a value between 0 and ILL, inclusive, indicating the interleaving index for frame-blocks in this payload in the interleaving group. If the value of ILP is found greater than ILL, the payload SHOULD be discarded. ILL and ILP fields MUST be present in each packet in a session if interleaving is signalled for the session. Interleaving MUST be performed on a frame-block basis (i.e., NOT on a frame basis) in a multi-channel session. The following example illustrates the arrangement of speech frame- blocks in an interleaving group during an interleaving session. Here we assume ILL=L for the interleaving group that starts at speech frame-block n. We also assume that the first payload packet of the interleaving group is s, and the number of speech frame-blocks carried in each payload is N. Then we will have: Sjoberg, et al. Standards Track [Page 25] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Payload s (the first packet of this interleaving group): ILL=L, ILP=0, Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1) Payload s+1 (the second packet of this interleaving group): ILL=L, ILP=1, frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1) ... Payload s+L (the last packet of this interleaving group): ILL=L, ILP=L, frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1) The next interleaving group will start at frame-block n+N*(L+1). There will be no interleaving effect unless the number of frame- blocks per packet (N) is at least 2. Moreover, the number of frame- blocks per payload (N) and the value of ILL MUST NOT be changed inside an interleaving group. In other words, all payloads in an interleaving group MUST have the same ILL and MUST contain the same number of speech frame-blocks. The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses media type parameter ""interleaving=I"" to set the maximum number of frame-blocks allowed in an interleaving group to I."
"When performing interleaving, the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleaving group is less or equal to I, that is, N*(L+1)<=I. 4.4.2. The Payload Table of Contents and Frame CRCs The table of contents (ToC) in octet-aligned mode consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload and, optionally, a list of speech frame CRCs. That is, the ToC is as follows: +---------------------+ | list of ToC entries | +---------------------+ | list of frame CRCs | (optional) - - - - - - - - - - - Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame or frame CRC present in the payload. Sjoberg, et al. Standards Track [Page 26] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The list of ToC entries is organized in the same way as described for bandwidth-efficient mode in 4.3.2, with the following exception: when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutively in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 4.4.1. The following example shows the ToC of three consecutive packets, each carrying three frame-blocks, in an interleaved two-channel session. Here, the two channels are left (L) and right (R) with L coming before R, and the interleaving length is 3 (i.e., ILL=2). This results in the interleaving group size of 9 frame-blocks. Packet #1 --------- ILL=2, ILP=0: +----+----+----+----+----+----+ | 1L | 1R | 4L | 4R | 7L | 7R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 1 Block 4 Block 7 Packet #2 --------- ILL=2, ILP=1: +----+----+----+----+----+----+ | 2L | 2R | 5L | 5R | 8L | 8R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 2 Block 5 Block 8 Packet #3 --------- ILL=2, ILP=2: +----+----+----+----+----+----+ | 3L | 3R | 6L | 6R | 9L | 9R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 3 Block 6 Block 9 Sjoberg, et al. Standards Track [Page 27] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 A ToC entry takes the following format in octet-aligned mode: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F| FT |Q|P|P| +-+-+-+-+-+-+-+-+ F (1 bit): see definition in Section 4.3.2. FT (4 bits, unsigned integer): see definition in Section 4.3.2. Q (1 bit): see definition in Section 4.3.2. P bits: padding bits, MUST be set to zero, and MUST be ignored on reception. The list of CRCs is OPTIONAL. It only exists if the use of CRC is signalled out-of-band for the session. When present, each CRC in the list is 8 bits long and corresponds to a speech frame (NOT a frame- block) carried in the payload. Calculation and use of the CRC is specified in the next section. 4.4.2.1. Use of Frame CRC for UED over IP The general concept of UED/UEP over IP is discussed in Section 3.6. This section provides more details on how to use the frame CRC in the octet-aligned payload header together with a partial transport layer checksum to achieve UED. To achieve UED, one SHOULD use a transport layer checksum (for example, the one defined in UDP-Lite [19]) to protect the IP, transport protocol (e.g., UDP-Lite), and RTP headers, as well as the payload header and the table of contents in the payload. The frame CRC, when used, MUST be calculated only over all class A bits in the AMR or AMR-WB frame. Class B and C bits in the AMR or AMR-WB frame MUST NOT be included in the CRC calculation and SHOULD NOT be covered by the transport checksum. Note, the number of class A bits for various coding modes in AMR codec is specified as informative in [2] and is therefore copied into Table 1 in Section 3.6 to make it normative for this payload format. The number of class A bits for various coding modes in AMR-WB codec is specified as normative in Table 2 in [4], and the SID frame (FT=9) has 40 class A bits. These definitions of class A bits MUST be used for this payload format. Sjoberg, et al. Standards Track [Page 28] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 If the transport layer checksum or link layer checksum detects any errors within the protected (sensitive) part, it is assumed that the complete packet will be discarded as defined by UDP-Lite [19]. The receiver of the payload SHOULD examine the data integrity of the received class A bits by re-calculating the CRC over the received class A bits and comparing the result to the value found in the received payload header. If the two values mismatch, the receiver SHALL consider the class A bits in the receiver frame damaged and MUST clear the Q flag of the frame (i.e., set it to 0). This will subsequently cause the frame to be marked as SPEECH_BAD, if the FT of the frame is 0..7 for AMR or 0..8 for AMR-WB, or SID_BAD if the FT of the frame is 8 for AMR or 9 for AMR-WB, before it is passed to the speech decoder. See [6] and [7] more details. The following example shows an octet-aligned ToC with a CRC list for a payload containing 3 speech frames from a single-channel session (assuming none of the FTs is equal to 14 or 15): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC#2 | CRC#3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each of the CRCs takes 8 bits 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | c0| c1| c2| c3| c4| c5| c6| c7| +---+---+---+---+---+---+---+---+ (MSB) (LSB) and is calculated by the cyclic generator polynomial, C(x) = 1 + x^2 + x^3 + x^4 + x^8 where ^ is the exponentiation operator. In binary form, the polynomial appears as follows: 101110001 (MSB..LSB). The actual calculation of the CRC is made as follows: First, an 8-bit CRC register is reset to zero: 00000000. For each bit over which the CRC shall be calculated, an XOR operation is made between the rightmost (LSB) bit of the CRC register and the bit. The CRC Sjoberg, et al. Standards Track [Page 29] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 register is then right-shifted one step (each bit's significance is reduced by one), inputting a ""0"" as the leftmost bit (MSB). If the result of the XOR operation mentioned above is a ""1"", then ""10111000"" is bit-wise XOR-ed into the CRC register. This operation is repeated for each bit that the CRC should cover. In this case, the first bit would be d(0) for the speech frame for which the CRC should cover. When the last bit (e.g., d(54) for AMR 5.9 according to Table 1 in Section 3.6) has been used in this CRC calculation, the contents in CRC register should simply be copied to the corresponding field in the list of CRCs. Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm. 4.4.3. Speech Data In octet-aligned mode, speech data is carried in a similar way to that in the bandwidth-efficient mode as discussed in Section 4.3.3, with the following exceptions: - The last octet of each speech frame MUST be padded with zero bits at the end if all bits in the octet are not used. The padding bits MUST be ignored on reception. In other words, each speech frame MUST be octet-aligned. - When multiple speech frames are present in the speech data (i.e., compound payload), the speech frames are arranged either one whole frame after another as usual, or with the octets of all frames interleaved together at the octet level, depending on the media type parameters negotiated for the payload type. Since the bits within each frame are ordered with the most error-sensitive bits first, interleaving the octets collects those sensitive bits from all frames to be nearer the beginning of the packet. This is called ""robust sorting order"" which allows the application of UED (such as UDP-Lite [19]) or UEP (such as the ULP [22]) mechanisms to the payload data. The details of assembling the payload are given in the next section. The use of robust sorting order for a payload type MUST be agreed via out-of-band means. Section 8 specifies a media type parameter for this purpose. Note, robust sorting order MUST only be performed on the frame level and thus is independent of interleaving, which is at the frame-block level, as described in Section 4.4.1. In other words, robust sorting can be applied to either non-interleaved or interleaved payload types. Sjoberg, et al. Standards Track [Page 30] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4.4. Methods for Forming the Payload Two different packetization methods, namely, normal order and robust sorting order, exist for forming a payload in octet-aligned mode. In both cases, the payload header and table of contents are packed into the payload the same way; the difference is in the packing of the speech frames. The payload begins with the payload header of one octet, or two octets if frame interleaving is selected. The payload header is followed by the table of contents consisting of a list of one-octet ToC entries. If frame CRCs are to be included, they follow the table of contents with one 8-bit CRC filling each octet. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no CRC present. The speech data follows the table of contents, or the CRCs if present. For packetization in the normal order, all of the octets comprising a speech frame are appended to the payload as a unit. The speech frames are packed in the same order as their corresponding ToC entries are arranged in the ToC list, with the exception that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame. For packetization in robust sorting order, the octets of all speech frames are interleaved together at the octet level. That is, the data portion of the payload begins with the first octet of the first frame, followed by the first octet of the second frame, then the first octet of the third frame, and so on. After the first octet of the last frame has been appended, the cycle repeats with the second octet of each frame. The process continues for as many octets as are present in the longest frame. If the frames are not all the same octet length, a shorter frame is skipped once all octets in it have been appended. The order of the frames in the cycle will be sequential if frame interleaving is not in use, or according to the interleave pattern specified in the payload header if frame interleaving is in use. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame, so it is skipped in the robust sorting cycle. The UED and/or UEP is RECOMMENDED to cover at least the RTP header, payload header, table of contents, and class A bits of a sorted payload. Exactly how many octets need to be covered depends on the network and application. If CRCs are used together with robust sorting, only the RTP header, the payload header, and the ToC SHOULD be covered by UED/UEP. The means for communicating the number of octets to be covered to other layers performing UED/UEP is beyond the scope of this specification. Sjoberg, et al. Standards Track [Page 31] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4.5. Payload Examples 4.4.5.1. Basic Single-Channel Payload Carrying Multiple Frames The following diagram shows an octet aligned payload from a single channel payload type that carries two AMR frames of 7.95 kbps coding mode (FT=5). In the payload, a codec mode request is sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. No frame CRC, interleaving, or robust sorting is in use. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=6 |R|R|R|R|1|FT#1=5 |Q|P|P|0|FT#2=5 |Q|P|P| f1(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(8..15) | f1(16..23) | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |f1(152..158) |P| f2(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(8..15) | f2(16..23) | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |f2(152..158) |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note, in the above example, the last octet in both speech frames is padded with one zero bit to make it octet-aligned. 4.4.5.2. Two-Channel Payload with CRC, Interleaving, and Robust Sorting This example shows an octet aligned payload from a two-channel payload type. Two frame-blocks, each containing two speech frames of 7.95 kbps coding mode (FT=5), are carried in this payload. The two channels are left (L) and right (R) with L coming before R. In the payload, a codec mode request is also sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. Moreover, frame CRC, robust sorting, and frame-block interleaving are all enabled for the payload type. The interleaving length is 2 (ILL=1), and this payload is the first one in an interleaving group (ILP=0). Sjoberg, et al. Standards Track [Page 32] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The first two frames in the payload are the L and R channel speech frames of frame-block #1, consisting of bits f1L(0..158) and f1R(0..158), respectively. The next two frames are the L and R channel frames of frame-block #3, consisting of bits f3L(0..158) and f3R(0..158), respectively, due to interleaving. For each of the four speech frames, a CRC is calculated as CRC1L(0..7), CRC1R(0..7), CRC3L(0..7), and CRC3R(0..7), respectively. Finally, the payload is robust sorted. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1L=5|Q|P|P|1|FT#1R=5|Q|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|FT#3L=5|Q|P|P|0|FT#3R=5|Q|P|P| CRC1L | CRC1R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC3L | CRC3R | f1L(0..7) | f1R(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(0..7) | f3R(0..7) | f1L(8..15) | f1R(8..15) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(8..15) | f3R(8..15) | f1L(16..23) | f1R(16..23) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(144..151) | f3R(144..151) |f1L(152..158)|P|f1R(152..158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |f3L(152..158)|P|f3R(152..158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note, in the above example, the last octet in all four speech frames is padded with one zero bit to make it octet-aligned. 4.5. Implementation Considerations An application implementing this payload format MUST understand all the payload parameters in the out-of-band signaling used. For example, if an application uses SDP, all the SDP and media type parameters in this document MUST be understood. This requirement ensures that an implementation always can decide if it is capable or not of communicating. No operating mode of the payload format is mandatory to implement. The requirements of the application using the payload format should be used to determine what to implement. To achieve basic interoperability, an implementation SHOULD at least implement both bandwidth-efficient and octet-aligned modes for a single audio Sjoberg, et al. Standards Track [Page 33] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 channel. The other operating modes: interleaving, robust sorting, and frame-wise CRC (in both single and multi-channel) are OPTIONAL to implement. The mode-change-period, mode-change-capability, and mode-change- neighbor parameters are intended for signaling with GSM endpoints. When interoperability with GSM is desired, encoders SHOULD only perform codec mode changes to neighboring modes and in integer multiples of 40 ms (two frame-blocks), but decoders SHOULD accept codec mode changes at any time, i.e., for every frame-block. The encoder may arbitrarily select the initial phase (odd or even frame- block) where codec mode changes are performed, but then SHOULD stick to that phase as far as possible. However, in rare cases, handovers or other events (e.g., call forwarding) may change this phase and may also cause mode changes to non-neighboring modes. The decoder SHALL therefore be prepared to accept changes also in the other phase and to other modes. Section 8 specifies the usage of the parameters mode-change-period and mode-change-capability to indicate the desired behavior in applications. See 3GPP TS 26.103 [28] for preferred AMR and AMR-WB configurations for operation in GSM and 3GPP UMTS networks. In gateway scenarios, encoders can be requested through the ""mode-set"" parameter to use a limited mode-set that is supported by the link beyond the gateway. Further, to avoid congestion on that link, the encoder SHOULD limit the initial codec mode for a session to a lower mode, until at least one frame-block is received with rate control information. 4.5.1. Decoding Validation When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information for the payload type and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet. This is because decoding a packet that has errors in its length field could severely degrade the speech quality. Sjoberg, et al. Standards Track [Page 34] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5. AMR and AMR-WB Storage Format The storage format is used for storing AMR or AMR-WB speech frames in a file or as an email attachment. Multiple channel content is supported. In general, an AMR or AMR-WB file has the following structure: +------------------+ | Header | +------------------+ | Speech frame 1 | +------------------+ : ... : +------------------+ | Speech frame n | +------------------+ Note, to preserve interoperability with already deployed implementations, single-channel content uses a file header format different from that of multi-channel content. There also exists another storage format for AMR and AMR-WB that is suitable for applications with more advanced demands on the storage format, like random access or synchronization with video. This format is the 3GPP-specified ISO-based multimedia file format 3GP [31]. Its media type is specified by RFC 3839 [32]. 5.1. Single-Channel Header A single-channel AMR or AMR-WB file header contains only a magic number. Different magic numbers are defined to distinguish AMR from AMR-WB. The magic number for single-channel AMR files MUST consist of ASCII character string: ""#!AMR\n"" (or 0x2321414d520a in hexadecimal). The magic number for single-channel AMR-WB files MUST consist of ASCII character string: ""#!AMR-WB\n"" (or 0x2321414d522d57420a in hexadecimal). Sjoberg, et al. Standards Track [Page 35] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Note, the ""\n"" is an important part of the magic numbers and MUST be included in the comparison, since, otherwise, the single-channel magic numbers above will become indistinguishable from those of the multi-channel files defined in the next section. 5.2. Multi-Channel Header The multi-channel header consists of a magic number followed by a 32-bit channel description field, giving the multi-channel header the following structure: +------------------+ | magic number | +------------------+ | chan-desc field | +------------------+ The magic number for multi-channel AMR files MUST consist of the ASCII character string: ""#!AMR_MC1.0\n"" (or 0x2321414d525F4D43312E300a in hexadecimal). The magic number for multi-channel AMR-WB files MUST consist of the ASCII character string: ""#!AMR-WB_MC1.0\n"" (or 0x2321414d522d57425F4D43312E300a in hexadecimal). The version number in the magic numbers refers to the version of the file format. The 32 bit channel description field is defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved bits | CHAN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved bits: MUST be set to 0 when written, and a reader MUST ignore them. CHAN (4 bits, unsigned integer): Indicates the number of audio channels contained in this storage file. The valid values and the order of the channels within a frame-block are specified in Section 4.1 in [12]. Sjoberg, et al. Standards Track [Page 36] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5.3. Speech Frames After the file header, speech frame-blocks consecutive in time are stored in the file. Each frame-block contains a number of octet- aligned speech frames equal to the number of channels, and stored in increasing order, starting with channel 1. Each stored speech frame starts with a one-octet frame header with the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| FT |Q|P|P| +-+-+-+-+-+-+-+-+ The FT field and the Q bit are defined in the same way as in Section 4.3.2. The P bits are padding and MUST be set to 0, and MUST be ignored. Following this one octet header come the speech bits as defined in 4.4.3. The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment. The following example shows an AMR frame in 5.9 kbps coding mode (with 118 speech bits) in the storage format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| FT=2 |Q|P|P| | +-+-+-+-+-+-+-+-+ + | | + Speech bits for frame-block n, channel k + | | + +-+-+ | |P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Non-received speech frames or frame-blocks between SID updates during non-speech periods MUST be stored as NO_DATA frames (frame type 15, as defined in [2] and [4]). Frames or frame-blocks lost in transmission MUST be stored as NO_DATA frames or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks to keep synchronization with the original media. Comfort noise frames of other types than AMR SID (FT=8) (i.e., frame type 9, 10, and 11 for AMR) SHALL NOT be used in the AMR file format. Sjoberg, et al. Standards Track [Page 37] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 6. Congestion Control The general congestion control considerations for transporting RTP data apply to AMR or AMR-WB speech over RTP as well. However, the multi-rate capability of AMR and AMR-WB speech coding may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different coding mode. Another parameter that may impact the bandwidth demand for AMR and AMR-WB is the number of frame-blocks that are encapsulated in each RTP payload. Packing more frame-blocks in each RTP payload can reduce the number of packets sent and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay. If forward error correction (FEC) is used to combat packet loss, the amount of redundancy added by FEC will need to be regulated so that the use of FEC itself does not cause a congestion problem. It is RECOMMENDED that AMR or AMR-WB applications using this payload format employ congestion control. The actual mechanism for congestion control is not specified but should be suitable for real- time flows, possibly ""TCP Friendly Rate Control"" [21]. 7. Security Considerations RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8] and in any used profile, like AVP [12] or SAVP [26]. As this format transports encoded speech, the main security issues include confidentiality, authentication, and integrity of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [26], need to be used for this functionality. Note that the appropriate mechanism to provide security to RTP and the payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable the usage of SRTP [26] is RECOMMENDED. Other known mechanisms that may be used are IPsec [33] and TLS [34] (RTP over TCP), but other alternatives may also exist. This payload format does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing, and thus is unlikely to pose a denial-of-service threat due to the receipt of pathological data. Sjoberg, et al. Standards Track [Page 38] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 7.1. Confidentiality To achieve confidentiality of the encoded AMR or AMR-WB speech, all speech data bits will need to be encrypted. There is less of a need to encrypt the payload header or the table of contents due to a) that they only carry information about the requested speech mode, frame type, and frame quality, and b) that this information could be useful to some third party, e.g., quality monitoring. The packetization and unpacketization of the AMR and AMR-WB payload is done only at the endpoints. Therefore encryption should be performed after packet encapsulation, and decryption should be performed before packet decapsulation. Encryption may affect interleaving. Specifically, a change of keys should occur at the boundary between interleaving groups. If it is not done at that boundary on both endpoints, the speech quality will be degraded during the complete interleaving group for any receiver. The encryption mechanism may impact the robustness of the error correcting mechanism. This is discussed in Section 9.5 of SRTP [26]. From this, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted. 7.2. Authentication and Integrity To authenticate the sender and to protect the integrity of the RTP packets in transit, an external mechanism has to be used. As stated before, it is RECOMMENDED that SRTP [26] be used for common interoperability. Note that the use of UED/UEP may be difficult to combine with some integrity protection mechanisms because any bit errors will cause the integrity check to fail. Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality or produce unintelligible communications. Tampering with the CMR field may result in a different speech quality than desired. 8. Payload Format Parameters This section defines the parameters that may be used to select optional features of the AMR and AMR-WB payload formats. The parameters are defined here as part of the media type registrations for the AMR and AMR-WB speech codecs. The registrations are done following RFC 4855 [15] and the media registration rules [14]. Sjoberg, et al. Standards Track [Page 39] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 A mapping of the parameters into the Session Description Protocol (SDP) [11] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use media types or SDP. Two separate media type registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by their own media type. Data formats are specified for both real-time transport in RTP and for storage type applications such as email attachments. 8.1. AMR Media Type Registration The media type for the Adaptive Multi-Rate (AMR) codec is allocated from the IETF tree since AMR is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real-time transfers via stored files. Note, any unspecified parameter MUST be ignored by the receiver. Media Type name: audio Media subtype name: AMR Required parameters: none Optional parameters: These parameters apply to RTP transfer only. octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed. mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma separated list of modes from the set: 0,...,7 (see Table 1a [2]). The SID frame type 8 and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type. Sjoberg, et al. Standards Track [Page 40] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by a period of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame- block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at any time during the session, i.e., N=1. mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change- period=2. If this parameter is not present, the mode- change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. Thus, clients RECOMMENDED to have the capability to support transmission according to mode-change-capability=2. mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed. maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet. Sjoberg, et al. Standards Track [Page 41] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session. robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session. interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used. ptime: see RFC 4566 [11]. channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1. max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present. Encoding considerations: The Audio data is binary data, and must be encoded for non- binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14]. Security considerations: See Section 7 of RFC 4867. Public specification: RFC 4867 3GPP TS 26.090, 26.092, 26.093, 26.101 Sjoberg, et al. Standards Track [Page 42] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras. Additional information: The following applies to stored-file transfer methods: Magic numbers: single-channel: ASCII character string ""#!AMR\n"" (or 0x2321414d520a in hexadecimal) multi-channel: ASCII character string ""#!AMR_MC1.0\n"" (or 0x2321414d525F4D43312E300a in hexadecimal) File extensions: amr, AMR Macintosh file type code: ""amr "" (fourth character is space) AMR speech frames may also be stored in the file format ""3GP"" defined in 3GPP TS 26.244 [31], which is identified using the media types ""audio/3GPP"" or ""video/3GPP"" as registered by RFC 3839 [32]. Person & email address to contact for further information: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices. Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used. Author: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Change controller: IETF Audio/Video Transport working group delegated from the IESG. Sjoberg, et al. Standards Track [Page 43] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 8.2. AMR-WB Media Type Registration The media type for the Adaptive Multi-Rate Wideband (AMR-WB) codec is allocated from the IETF tree since AMR-WB is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real- time transfers via stored files. Note, any unspecified parameter MUST be ignored by the receiver. Media Type name: audio Media subtype name: AMR-WB Required parameters: none Optional parameters: These parameters apply to RTP transfer only. octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed. mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma-separated list of modes from the set: 0,...,8 (see Table 1a [4]). The SID frame type 9, SPEECH_LOST (frame type 14), and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type. mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame- block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at Any time during the session, i.e., N=1. Sjoberg, et al. Standards Track [Page 44] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change- period=2. If this parameter is not present, the mode- change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required."
"Thus, clients are RECOMMENDED to have the capability to support transmission according to mode-change-capability=2. mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed. maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet. crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session. robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session. Sjoberg, et al. Standards Track [Page 45] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used. ptime: see RFC 2327 [11]. channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1. max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present. Encoding considerations: The Audio data is binary data, and must be encoded for non- binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14]. Security considerations: See Section 7 of RFC 4867. Public specification: RFC 4867 3GPP TS 26.190, 26.192, 26.193, 26.201 Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras. Sjoberg, et al. Standards Track [Page 46] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Additional information: The following applies to stored-file transfer methods: Magic numbers: single-channel: ASCII character string ""#!AMR-WB\n"" (or 0x2321414d522d57420a in hexadecimal) multi-channel: ASCII character string ""#!AMR-WB_MC1.0\n"" (or 0x2321414d522d57425F4D43312E300a in hexadecimal) File extensions: awb, AWB Macintosh file type code: amrw Object identifier or OID: none AMR-WB speech frames may also be stored in the file format ""3GP"" defined in 3GPP TS 26.244 [31] and identified using the media type ""audio/3GPP"" or ""video/3GPP"" as registered by RFC 3839 [32]. Person & email address to contact for further information: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices. Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used. Author: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Change controller: IETF Audio/Video Transport working group delegated from the IESG. 8.3. Mapping Media Type Parameters into SDP The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [11], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping is as follows: Sjoberg, et al. Standards Track [Page 47] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - The media type (""audio"") goes in SDP ""m="" as the media name. - The media subtype (payload format name) goes in SDP ""a=rtpmap"" as the encoding name. The RTP clock rate in ""a=rtpmap"" MUST be 8000 for AMR and 16000 for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed are specified in Section 4.1 in [12]. - The parameters ""ptime"" and ""maxptime"" go in the SDP ""a=ptime"" and ""a=maxptime"" attributes, respectively. - Any remaining parameters go in the SDP ""a=fmtp"" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs. 8.3.1. Offer-Answer Model Considerations The following considerations apply when using SDP Offer-Answer procedures to negotiate the use of AMR or AMR-WB payload in RTP: - Each combination of the RTP payload transport format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. When creating an offer in an application desiring to use the more advanced features (crc, robust-sorting, interleaving, or more than one channel), the offerer is RECOMMENDED to also offer a payload type containing only the octet-aligned or bandwidth-efficient configuration with a single channel. If multiple configurations are of interest to the application, they may all be offered; however, care should be taken not to offer too many payload types. An SDP answerer MUST include, in the SDP answer for a payload type, the following parameters unmodified from the SDP offer (unless it removes the payload type): ""octet- align""; ""crc""; ""robust-sorting""; ""interleaving""; and ""channels"". The SDP offerer and answerer MUST generate AMR or AMR-WB packets as described by these parameters. - The ""mode-set"" parameter can be used to restrict the set of active AMR/AMR-WB modes used in a session. This functionality is primarily intended for gateways to access networks such as GSM or 3GPP UMTS, where the access network may be capable of supporting only a subset of AMR/AMR-WB modes. The 3GPP preferred codec configurations are defined in 3GPP TS 26.103 [25], and it is RECOMMENDED that other networks also needing to restrict the mode set follow the preferred codec configurations defined in 3GPP for greatest interoperability. Sjoberg, et al. Standards Track [Page 48] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The parameter is bi-directional, i.e., the restricted set applies to media both to be received and sent by the declaring entity. If a mode set was supplied in the offer, the answerer SHALL return the mode-set unmodified or reject the payload type. However, the answerer is free to choose a mode-set in the answer only if no mode-set was supplied in the offer for a unicast two-peer session. The mode-set in the answer is binding both for offerer and answerer. Thus, an offerer supporting all modes and subsets SHOULD NOT include the mode- set parameter. For any other offerer it is RECOMMENDED to include each mode-set it can support as a separate payload type within the offer. For multicast sessions, the answerer SHALL only participate in the session if it supports the offered mode-set. Thus, it is RECOMMENDED that any offer for a multicast session include only the mode-set it will require the answerers to support, and that the mode-set be likely to be supported by all participants. - The parameters ""mode-change-period"" and ""mode-change- capability"" are intended to be used in sessions with gateways, for example, when interoperating with GSM networks. Both parameters are declarative and are combined to allow a session participant to determine if the payload type can be supported. The mode-change-period will indicate what the offerer or answerer requires of data it receives, while the mode-change- capability indicates its transmission capabilities. A mode-change-period=2 in the offer indicates a requirement on the answerer to send with a mode-change period of 2, i.e., support mode-change-capability=2. If the answerer requires mode-change-period=2, it SHALL only include it in the answer if the offerer either has indicated support with mode-change- capability=2 or has indicated mode-change-period=2; otherwise, the payload type SHALL be rejected. An offerer that supports mode-change-capability=2 SHALL include the parameter in all offers to ensure the greatest possible interoperability, unless it includes mode-change-period=2 in the offer. The mode- change-capability SHOULD be included in answers. It is then indicating the answerer's capability to transmit with that mode-change-period for the provided payload format configuration. The information is useful in future re-negotiation of the payload formats. - The parameter ""mode-change-neighbor"" is a recommendation to restrict the switching of codec modes to its neighbor and SHOULD be followed. It is intended to be used in gateway scenarios (for example, to GSM networks) where the support of Sjoberg, et al. Standards Track [Page 49] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 this parameter and the operations it implies improves interoperability. ""mode-change-neighbor"" is a declarative parameter. By including the parameter, the offerer or answerer indicates that it desires to receive streams with ""mode-change-neighbor"" restrictions. - In most cases, the parameters ""maxptime"" and ""ptime"" will not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer- answer handling of the ""ptime"" parameter is described in RFC 3264 [13]. The ""maxptime"" parameter MUST be handled in the same way. - The parameter ""max-red"" is a stream property parameter. For send-only or send-recv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the ""max-red"" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case ""max-red"" is set to 0. As this parameter was not defined originally, some senders will not declare this parameter even if it will limit or not send redundancy at all. - Any unknown parameter in an offer SHALL be removed in the answer. 8.3.2. Usage of Declarative SDP In declarative usage, like SDP in RTSP [29] or SAP [30], the parameters SHALL be interpreted as follows: - The payload format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) are all declarative, and a participant MUST use the configuration(s) that is provided for the session. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small. Sjoberg, et al. Standards Track [Page 50] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - Any restriction of the AMR or AMR-WB encoder mode-switching and mode usage through the ""mode-set"", and ""mode-change-period"" MUST be followed by all participants of the session. The restriction indicated by ""mode-change-neighbor"" SHOULD be followed. Please note that such restrictions may be necessary if gateways to other transport systems like GSM participate in the session. Failure to consider such restrictions may result in failure for a peer behind such a gateway to correctly receive all or parts of the session. Also, if different restrictions are needed by different peers in the same session (unless a common subset of the restrictions exists), some peer will not be able to participate. Note that the usage of mode-change-capability is meaningless when no negotiation exists, and can thus be excluded in any declarations. - Any ""maxptime"" and ""ptime"" values should be selected with care to ensure that the session's participants can achieve reasonable performance. - The usage of ""max-red"" puts a global upper limit on the usage of redundancy that needs to be followed by all that understand the parameter. However, due to the late addition of this parameter, it may be ignored by some implementations. 8.3.3. Examples Some example SDP session descriptions utilizing AMR and AMR-WB encodings follow. In these examples, long a=fmtp lines are folded to meet the column width constraints of this document; the backslash (""\"") at the end of a line and the carriage return that follows it should be ignored. In an example of the usage of AMR in a possible GSM gateway-to- gateway scenario, the offerer is capable of supporting three different mode-sets and needs the mode-change-period to be 2 in combination with mode-change-neighbor restrictions. The other gateway can only support two of these mode-sets and removes the payload type 97 in the answer. If the offering GSM gateway only supports a single mode-set active at the same time, it should consider doing the 1 out of N selection procedures described in Section 10.2 of [13]: Sjoberg, et al. Standards Track [Page 51] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Offer: m=audio 49120 RTP/AVP 97 98 99 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 Answer: m=audio 49120 RTP/AVP 98 99 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \< mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 The following example shows the usage of AMR between a non-GSM endpoint and a GSM gateway. The non-GSM offerer requires no restrictions of the mode-change-period or mode-change-neighbor, but must signal its mode-change-capability in the offer and abide by those restrictions in the answer. Offer: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2 a=maxptime:20 Answer: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 Sjoberg, et al. Standards Track [Page 52] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Example of usage of AMR-WB in a possible VoIP scenario where UEP may be used (99) and a fallback declaration (98): m=audio 49120 RTP/AVP 99 98 a=rtpmap:98 AMR-WB/16000 a=fmtp:98 octet-align=1; mode-change-capability=2 a=rtpmap:99 AMR-WB/16000 a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2 Example of usage of AMR-WB in a possible streaming scenario (two channel stereo): m=audio 49120 RTP/AVP 99 a=rtpmap:99 AMR-WB/16000/2 a=fmtp:99 interleaving=30 a=maxptime:100 Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute. 9. IANA Considerations Two media types (audio/AMR and audio/AMR-WB) have been updated; see Section 8. 10. Changes from RFC 3267 The differences between RFC 3267 and this document are as follows: - Added clarification of behavior in regards to mode change period and mode-change neighbor that is expected from an IP client; see Section 4.5. - Updated the maxptime for better clarification. The sentence that previously read: ""The time SHOULD be a multiple of the frame size."" now says ""The time SHOULD be an integer multiple of the frame size."" This should have no impact on interoperability. - Updated the definition of the mode-set parameter for clarification. - Restricted the values for mode-change-period to 1 or 2, which are the values used in circuit-switched AMR systems. Sjoberg, et al. Standards Track [Page 53] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - Added a new media type parameter Mode-Change-Capability that defaults to 1, which is the assumed behavior of any non-updated implementation. This enables the offer-answer procedures to work. - Changed mode-change-neighbor to indicate a recommended behavior rather than a required one. - Added an Offer-Answer Section, see Section 8.3.1. This will have implications on the interoperability to implementations that have guessed how to perform offer/answer negotiation of the payload parameters. - Clarified and aligned the unequal detection usage with the published UDP-Lite specification in Sections 3.6.1 and 4.4.2.1. This included replacing a normative statement about packet handling with an informative paragraph with a reference to UDP- Lite. - Clarified the bit order in the CRC calculation in Section 4.4.2.1. - Corrected the reference in Section 5.3 for the Q and FT fields. - Changed the padding bit definition in Sections 4.4.2 and 5.3 so that it is clear that they shall be ignored. - Added a clarification that comfort noise frames with frame type 9, 10, and 11 SHALL NOT be used in the AMR file format. - Clarified in Section 4.3.2 that the rules about not sending NO_DATA frames do apply for all payload format configurations with the exception of the interleaved mode. - The reference list has been updated to now published RFCs: RFC 3448, RFC 3550, RFC 3551, RFC 3711, RFC 3828, and RFC 4566. A reference to 3GPP TS 26.101 has also been added. - Added notes in storage format section and media type registration that AMR and AMR-WB frames can also be stored in the 3GP file format. - Added a media type parameter ""max-red"" that allows the sender to declare a bounded usage of redundancy. This parameter allows a receiver to optimize its function as it will know if redundancy will be used or not. If it is used, the maximum extra delay introduced by the sender (that is needed to be considered by the receiver to fully utilize the redundancy) will be known. The addition of this parameter should have no negative effects on older implementations as they are mandated to ignore unknown Sjoberg, et al. Standards Track [Page 54] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 parameters per RFC 3267. In addition, older implementations are required to operate as if the value of max-red is unknown and possibly infinite. - Updated the media type registration to comply with the new registration rules. - Moved section on decoding validation from Security Considerations to Implementation Considerations, where it makes more sense. - Clarified the application of encryption, integrity protection, and authentication mechanism to the payload. 11. Acknowledgements The authors would like to thank Petri Koskelainen, Bernhard Wimmer, Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for their significant contributions made throughout the writing and reviewing of RFC 3267 and this replacement. The authors would also like to thank Richard Ejzak, Thomas Belling, and Gorry Fairhurst for their input on this replacement of RFC 3267. 12. References 12.1. Normative References [1] 3GPP TS 26.090, ""Adaptive Multi-Rate (AMR) speech transcoding"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [2] 3GPP TS 26.101, ""AMR Speech Codec Frame Structure"", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP). [3] 3GPP TS 26.190 ""AMR Wideband speech codec; Transcoding functions"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [4] 3GPP TS 26.201 ""AMR Wideband speech codec; Frame Structure"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [5] Bradner, S., ""Key words for use in RFCs to Indicate Requirement Levels"", BCP 14, RFC 2119, March 1997. [6] 3GPP TS 26.093, ""AMR Speech Codec; Source Controlled Rate operation"", version 4.0.0 (2000-12), 3rd Generation Partnership Project (3GPP). Sjoberg, et al. Standards Track [Page 55] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [7] 3GPP TS 26.193 ""AMR Wideband Speech Codec; Source Controlled Rate operation"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, ""RTP: A Transport Protocol for Real-Time Applications"", STD 64, RFC 3550, July 2003. [9] 3GPP TS 26.092, ""AMR Speech Codec; Comfort noise aspects"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [10] 3GPP TS 26.192 ""AMR Wideband speech codec; Comfort Noise aspects"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [11] Handley, M., Jacobson, V., and C. Perkins, ""SDP: Session Description Protocol"", RFC 4566, July 2006. [12] Schulzrinne, H. and S. Casner, ""RTP Profile for Audio and Video Conferences with Minimal Control"", STD 65, RFC 3551, July 2003. [13] Rosenberg, J. and H. Schulzrinne, ""An Offer/Answer Model with Session Description Protocol (SDP)"", RFC 3264, June 2002. [14] Freed, N. and J. Klensin, ""Media Type Specifications and Registration Procedures"", BCP 13, RFC 4288, December 2005. [15] Casner, S., ""Media Type Registration of RTP Payload Formats"", RFC 4855, February 2007. 12.2. Informative References [16] GSM 06.60, ""Enhanced Full Rate (EFR) speech transcoding"", version 8.0.1 (2000-11), European Telecommunications Standards Institute (ETSI). [17] ANSI/TIA/EIA-136-Rev.C, part 410 - ""TDMA Cellular/PCS Radio Interface, Enhanced Full Rate Voice Codec (ACELP)"". Formerly IS-641. TIA published standard, June 1 2001. [18] ARIB, RCR STD-27H, ""Personal Digital Cellular Telecommunication System RCR Standard"", Association of Radio Industries and Businesses (ARIB). [19] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, ""The Lightweight User Datagram Protocol (UDP-Lite)"", RFC 3828, July 2004. Sjoberg, et al. Standards Track [Page 56] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [20] 3GPP TS 25.415 ""UTRAN Iu Interface User Plane Protocols"", version 4.2.0 (2001-09), 3rd Generation Partnership Project (3GPP). [21] Handley, M., Floyd, S., Padhye, J., and J. Widmer, ""TCP Friendly Rate Control (TFRC): Protocol Specification"", RFC 3448, January 2003. [22] Li, A., et al., ""An RTP Payload Format for Generic FEC with Uneven Level Protection"", Work in Progress. [23] Rosenberg, J. and H. Schulzrinne, ""An RTP Payload Format for Generic Forward Error Correction"", RFC 2733, December 1999. [24] 3GPP TS 26.102, ""AMR speech codec interface to Iu and Uu"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [25] 3GPP TS 26.202, ""AMR Wideband speech codec; Interface to Iu and Uu"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, ""The Secure Real-time Transport Protocol (SRTP)"", RFC 3711, March 2004. [27] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, ""RTP Payload for Redundant Audio Data"", RFC 2198, September 1997. [28] 3GPP TS 26.103, ""Speech codec list for GSM and UMTS"", version 5.5.0 (2004-09), 3rd Generation Partnership Project (3GPP). [29] Schulzrinne, H., Rao, A., and R. Lanphier, ""Real Time Streaming Protocol (RTSP)"", RFC 2326, April 1998. [30] Handley, M., Perkins, C., and E. Whelan, ""Session Announcement Protocol"", RFC 2974, October 2000. [31] 3GPP TS 26.244, ""3GPP file format (3GP)"", version 6.1.0 (2004- 09), 3rd Generation Partnership Project (3GPP). [32] Castagno, R. and D. Singer, ""MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files"", RFC 3839, July 2004. [33] Kent, S. and K. Seo, ""Security Architecture for the Internet Protocol"", RFC 4301, December 2005. Sjoberg, et al. Standards Track [Page 57] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [34] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.1"", RFC 4346, April 2006. ETSI documents are available from <http://www.etsi.org/>. 3GPP documents are available from <http://www.3gpp.org/>. TIA documents are available from <http://www.tiaonline.org/>. Authors' Addresses Johan Sjoberg Ericsson AB SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: Johan.Sjoberg@ericsson.com Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com Ari Lakaniemi Nokia Research Center P.O.Box 407 FIN-00045 Nokia Group, FINLAND Phone: +358-71-8008000 EMail: ari.lakaniemi@nokia.com Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-B8 Arlington Heights, IL 60004, USA Phone: +1-847-632-3028 EMail: Qiaobing.Xie@motorola.com Sjoberg, et al. Standards Track [Page 58] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an ""AS IS"" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at <%ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sjoberg, et al. Standards Track [Page 59] Network Working Group J. Rosenberg Request for Comments: 3261 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. G. Camarillo Ericsson A. Johnston WorldCom J. Peterson Neustar R. Sparks dynamicsoft M. Handley ICIR E. Schooler AT&T June 2002 SIP: Session Initiation Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ""Internet Official Protocol Standards"" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. Rosenberg, et. al. Standards Track [Page 1] RFC 3261 SIP: Session Initiation Protocol June 2002 Table of Contents 1 Introduction ........................................ 8 2 Overview of SIP Functionality ....................... 9 3 Terminology ......................................... 10 4 Overview of Operation ............................... 10 5 Structure of the Protocol ........................... 18 6 Definitions ......................................... 20 7 SIP Messages ........................................ 26 7.1 Requests ............................................ 27 7.2 Responses ........................................... 28 7.3 Header Fields ....................................... 29 7.3.1 Header Field Format ................................. 30 7.3.2 Header Field Classification ......................... 32 7.3.3 Compact Form ........................................ 32 7.4 Bodies .............................................. 33 7.4.1 Message Body Type ................................... 33 7.4.2 Message Body Length ................................. 33 7.5 Framing SIP Messages ................................ 34 8 General User Agent Behavior ......................... 34 8.1 UAC Behavior ........................................ 35 8.1.1 Generating the Request .............................. 35 8.1.1.1 Request-URI ......................................... 35 8.1.1.2 To .................................................. 36 8.1.1.3 From ................................................ 37 8.1.1.4 Call-ID ............................................. 37 8.1.1.5 CSeq ................................................ 38 8.1.1.6 Max-Forwards ........................................ 38 8.1.1.7 Via ................................................. 39 8.1.1.8 Contact ............................................. 40 8.1.1.9 Supported and Require ............................... 40 8.1.1.10 Additional Message Components ....................... 41 8.1.2 Sending the Request ................................. 41 8.1.3 Processing Responses ................................ 42 8.1.3.1 Transaction Layer Errors ............................ 42 8.1.3.2 Unrecognized Responses .............................. 42 8.1.3.3 Vias ................................................ 43 8.1.3.4 Processing 3xx Responses ............................ 43 8.1.3.5 Processing 4xx Responses ............................ 45 8.2 UAS Behavior ........................................ 46 8.2.1 Method Inspection ................................... 46 8.2.2 Header Inspection ................................... 46 8.2.2.1 To and Request-URI .................................. 46 8.2.2.2 Merged Requests ..................................... 47 8.2.2.3 Require ............................................. 47 8.2.3 Content Processing .................................. 48 8.2.4 Applying Extensions ................................. 49 8.2.5 Processing the Request .............................. 49 Rosenberg, et. al. Standards Track [Page 2] RFC 3261 SIP: Session Initiation Protocol June 2002 8.2.6 Generating the Response ............................. 49 8.2.6.1 Sending a Provisional Response ...................... 49 8.2.6.2 Headers and Tags .................................... 50 8.2.7 Stateless UAS Behavior .............................. 50 8.3 Redirect Servers .................................... 51 9 Canceling a Request ................................. 53 9.1 Client Behavior ..................................... 53 9.2 Server Behavior ..................................... 55 10 Registrations ....................................... 56 10.1 Overview ............................................ 56 10.2 Constructing the REGISTER Request ................... 57 10.2.1 Adding Bindings ..................................... 59 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 10.2.1.2 Preferences among Contact Addresses ................. 61 10.2.2 Removing Bindings ................................... 61 10.2.3 Fetching Bindings ................................... 61 10.2.4 Refreshing Bindings ................................. 61 10.2.5 Setting the Internal Clock .......................... 62 10.2.6 Discovering a Registrar ............................. 62 10.2.7 Transmitting a Request .............................. 62 10.2.8 Error Responses ..................................... 63 10.3 Processing REGISTER Requests ........................ 63 11 Querying for Capabilities ........................... 66 11.1 Construction of OPTIONS Request ..................... 67 11.2 Processing of OPTIONS Request ....................... 68 12 Dialogs ............................................. 69 12.1 Creation of a Dialog ................................ 70 12.1.1 UAS behavior ........................................ 70 12.1.2 UAC Behavior ........................................ 71 12.2 Requests within a Dialog ............................ 72 12.2.1 UAC Behavior ........................................ 73 12.2.1.1 Generating the Request .............................. 73 12.2.1.2 Processing the Responses ............................ 75 12.2.2 UAS Behavior ........................................ 76 12.3 Termination of a Dialog ............................. 77 13 Initiating a Session ................................ 77 13.1 Overview ............................................ 77 13.2 UAC Processing ...................................... 78 13.2.1 Creating the Initial INVITE ......................... 78 13.2.2 Processing INVITE Responses ......................... 81 13.2.2.1 1xx Responses ....................................... 81 13.2.2.2 3xx Responses ....................................... 81 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 13.2.2.4 2xx Responses ....................................... 82 13.3 UAS Processing ...................................... 83 13.3.1 Processing of the INVITE ............................ 83 13.3.1.1 Progress ............................................ 84 13.3.1.2 The INVITE is Redirected ............................ 84 Rosenberg, et. al. Standards Track [Page 3] RFC 3261 SIP: Session Initiation Protocol June 2002 13.3.1.3 The INVITE is Rejected .............................. 85 13.3.1.4 The INVITE is Accepted .............................. 85 14 Modifying an Existing Session ....................... 86 14.1 UAC Behavior ........................................ 86 14.2 UAS Behavior ........................................ 88 15 Terminating a Session ............................... 89 15.1 Terminating a Session with a BYE Request ............ 90 15.1.1 UAC Behavior ........................................ 90 15.1.2 UAS Behavior ........................................ 91 16 Proxy Behavior ...................................... 91 16.1 Overview ............................................ 91 16.2 Stateful Proxy ...................................... 92 16.3 Request Validation .................................. 94 16.4 Route Information Preprocessing ..................... 96 16.5 Determining Request Targets ......................... 97 16.6 Request Forwarding .................................. 99 16.7 Response Processing ................................. 107 16.8 Processing Timer C .................................. 114 16.9 Handling Transport Errors ........................... 115 16.10 CANCEL Processing ................................... 115 16.11 Stateless Proxy ..................................... 116 16.12 Summary of Proxy Route Processing ................... 118 16.12.1 Examples ............................................ 118 16.12.1.1 Basic SIP Trapezoid ................................. 118 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121 17 Transactions ........................................ 122 17.1 Client Transaction .................................. 124 17.1.1 INVITE Client Transaction ........................... 125 17.1.1.1 Overview of INVITE Transaction ...................... 125 17.1.1.2 Formal Description .................................. 125 17.1.1.3 Construction of the ACK Request ..................... 129 17.1.2 Non-INVITE Client Transaction ....................... 130 17.1.2.1 Overview of the non-INVITE Transaction .............. 130 17.1.2.2 Formal Description .................................. 131 17.1.3 Matching Responses to Client Transactions ........... 132 17.1.4 Handling Transport Errors ........................... 133 17.2 Server Transaction .................................. 134 17.2.1 INVITE Server Transaction ........................... 134 17.2.2 Non-INVITE Server Transaction ....................... 137 17.2.3 Matching Requests to Server Transactions ............ 138 17.2.4 Handling Transport Errors ........................... 141 18 Transport ........................................... 141 18.1 Clients ............................................. 142 18.1.1 Sending Requests .................................... 142 18.1.2 Receiving Responses ................................. 144 18.2 Servers ............................................. 145 18.2.1 Receiving Requests .................................. 145 Rosenberg, et. al. Standards Track [Page 4] RFC 3261 SIP: Session Initiation Protocol June 2002 18.2.2 Sending Responses ................................... 146 18.3 Framing ............................................. 147 18.4 Error Handling ...................................... 147 19 Common Message Components ........................... 147 19.1 SIP and SIPS Uniform Resource Indicators ............ 148 19.1.1 SIP and SIPS URI Components ......................... 148 19.1.2 Character Escaping Requirements ..................... 152 19.1.3 Example SIP and SIPS URIs ........................... 153 19.1.4 URI Comparison ...................................... 153 19.1.5 Forming Requests from a URI ......................... 156 19.1.6 Relating SIP URIs and tel URLs ...................... 157 19.2 Option Tags ......................................... 158 19.3 Tags ................................................ 159 20 Header Fields ....................................... 159 20.1 Accept .............................................. 161 20.2 Accept-Encoding ..................................... 163 20.3 Accept-Language ..................................... 164 20.4 Alert-Info .......................................... 164 20.5 Allow ............................................... 165 20.6 Authentication-Info ................................. 165 20.7 Authorization ....................................... 165 20.8 Call-ID ............................................. 166 20.9 Call-Info ........................................... 166 20.10 Contact ............................................. 167 20.11 Content-Disposition ................................. 168 20.12 Content-Encoding .................................... 169 20.13 Content-Language .................................... 169 20.14 Content-Length ...................................... 169 20.15 Content-Type ........................................ 170 20.16 CSeq ................................................ 170 20.17 Date ................................................ 170 20.18 Error-Info .......................................... 171 20.19 Expires ............................................. 171 20.20 From ................................................ 172 20.21 In-Reply-To ......................................... 172 20.22 Max-Forwards ........................................ 173 20.23 Min-Expires ......................................... 173 20.24 MIME-Version ........................................ 173 20.25 Organization ........................................ 174 20.26 Priority ............................................ 174 20.27 Proxy-Authenticate .................................. 174 20.28 Proxy-Authorization ................................. 175 20.29 Proxy-Require ....................................... 175 20.30 Record-Route ........................................ 175 20.31 Reply-To ............................................ 176 20.32 Require ............................................. 176 20.33 Retry-After ......................................... 176 20.34 Route ............................................... 177 Rosenberg, et. al. Standards Track [Page 5] RFC 3261 SIP: Session Initiation Protocol June 2002 20.35 Server .............................................. 177 20.36 Subject ............................................. 177 20.37 Supported ........................................... 178 20.38 Timestamp ........................................... 178 20.39 To .................................................. 178 20.40 Unsupported ......................................... 179 20.41 User-Agent .......................................... 179 20.42 Via ................................................. 179 20.43 Warning ............................................. 180 20.44 WWW-Authenticate .................................... 182 21 Response Codes ...................................... 182 21.1 Provisional 1xx ..................................... 182 21.1.1 100 Trying .......................................... 183 21.1.2 180 Ringing ......................................... 183 21.1.3 181 Call Is Being Forwarded ......................... 183 21.1.4 182 Queued .......................................... 183 21.1.5 183 Session Progress ................................ 183 21.2 Successful 2xx ...................................... 183 21.2.1 200 OK .............................................. 183 21.3 Redirection 3xx ..................................... 184 21.3.1 300 Multiple Choices ................................ 184 21.3.2 301 Moved Permanently ............................... 184 21.3.3 302 Moved Temporarily ............................... 184 21.3.4 305 Use Proxy ....................................... 185 21.3.5 380 Alternative Service ............................. 185 21.4 Request Failure 4xx ................................. 185 21.4.1 400 Bad Request ..................................... 185 21.4.2 401 Unauthorized .................................... 185 21.4.3 402 Payment Required ................................ 186 21.4.4 403 Forbidden ....................................... 186 21.4.5 404 Not Found ....................................... 186 21.4.6 405 Method Not Allowed .............................. 186 21.4.7 406 Not Acceptable .................................. 186 21.4.8 407 Proxy Authentication Required ................... 186 21.4.9 408 Request Timeout ................................. 186 21.4.10 410 Gone ............................................ 187 21.4.11 413 Request Entity Too Large ........................ 187 21.4.12 414 Request-URI Too Long ............................ 187 21.4.13 415 Unsupported Media Type .......................... 187 21.4.14 416 Unsupported URI Scheme .......................... 187 21.4.15 420 Bad Extension ................................... 187 21.4.16 421 Extension Required .............................. 188 21.4.17 423 Interval Too Brief .............................. 188 21.4.18 480 Temporarily Unavailable ......................... 188 21.4.19 481 Call/Transaction Does Not Exist ................. 188 21.4.20 482 Loop Detected ................................... 188 21.4.21 483 Too Many Hops ................................... 189 21.4.22 484 Address Incomplete .............................. 189 Rosenberg, et. al. Standards Track [Page 6] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.23 485 Ambiguous ....................................... 189 21.4.24 486 Busy Here ....................................... 189 21.4.25 487 Request Terminated .............................. 190 21.4.26 488 Not Acceptable Here ............................. 190 21.4.27 491 Request Pending ................................. 190 21.4.28 493 Undecipherable .................................. 190 21.5 Server Failure 5xx .................................. 190 21.5.1 500 Server Internal Error ........................... 190 21.5.2 501 Not Implemented ................................. 191 21.5.3 502 Bad Gateway ..................................... 191 21.5.4 503 Service Unavailable ............................. 191 21.5.5 504 Server Time-out ................................. 191 21.5.6 505 Version Not Supported ........................... 192 21.5.7 513 Message Too Large ............................... 192 21.6 Global Failures 6xx ................................. 192 21.6.1 600 Busy Everywhere ................................. 192 21.6.2 603 Decline ......................................... 192 21.6.3 604 Does Not Exist Anywhere ......................... 192 21.6.4 606 Not Acceptable .................................. 192 22 Usage of HTTP Authentication ........................ 193 22.1 Framework ........................................... 193 22.2 User-to-User Authentication ......................... 195 22.3 Proxy-to-User Authentication ........................ 197 22.4 The Digest Authentication Scheme .................... 199 23 S/MIME .............................................. 201 23.1 S/MIME Certificates ................................. 201 23.2 S/MIME Key Exchange ................................. 202 23.3 Securing MIME bodies ................................ 205 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP ....................................... 207 23.4.1 Integrity and Confidentiality Properties of SIP Headers ............................................. 207 23.4.1.1 Integrity ........................................... 207 23.4.1.2 Confidentiality ..................................... 208 23.4.2 Tunneling Integrity and Authentication .............. 209 23.4.3 Tunneling Encryption ................................ 211 24 Examples ............................................ 213 24.1 Registration ........................................ 213 24.2 Session Setup ....................................... 214 25 Augmented BNF for the SIP Protocol .................. 219 25.1 Basic Rules ......................................... 219 26 Security Considerations: Threat Model and Security Usage Recommendations ............................... 232 26.1 Attacks and Threat Models ........................... 233 26.1.1 Registration Hijacking .............................. 233 26.1.2 Impersonating a Server .............................. 234 26.1.3 Tampering with Message Bodies ....................... 235 26.1.4 Tearing Down Sessions ............................... 235 Rosenberg, et. al."
"Standards Track [Page 7] RFC 3261 SIP: Session Initiation Protocol June 2002 26.1.5 Denial of Service and Amplification ................. 236 26.2 Security Mechanisms ................................. 237 26.2.1 Transport and Network Layer Security ................ 238 26.2.2 SIPS URI Scheme ..................................... 239 26.2.3 HTTP Authentication ................................. 240 26.2.4 S/MIME .............................................. 240 26.3 Implementing Security Mechanisms .................... 241 26.3.1 Requirements for Implementers of SIP ................ 241 26.3.2 Security Solutions .................................. 242 26.3.2.1 Registration ........................................ 242 26.3.2.2 Interdomain Requests ................................ 243 26.3.2.3 Peer-to-Peer Requests ............................... 245 26.3.2.4 DoS Protection ...................................... 246 26.4 Limitations ......................................... 247 26.4.1 HTTP Digest ......................................... 247 26.4.2 S/MIME .............................................. 248 26.4.3 TLS ................................................. 249 26.4.4 SIPS URIs ........................................... 249 26.5 Privacy ............................................. 251 27 IANA Considerations ................................. 252 27.1 Option Tags ......................................... 252 27.2 Warn-Codes .......................................... 252 27.3 Header Field Names .................................. 253 27.4 Method and Response Codes ........................... 253 27.5 The ""message/sip"" MIME type. ....................... 254 27.6 New Content-Disposition Parameter Registrations ..... 255 28 Changes From RFC 2543 ............................... 255 28.1 Major Functional Changes ............................ 255 28.2 Minor Functional Changes ............................ 260 29 Normative References ................................ 261 30 Informative References .............................. 262 A Table of Timer Values ............................... 265 Acknowledgments ................................................ 266 Authors' Addresses ............................................. 267 Full Copyright Statement ....................................... 269 1 Introduction There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages. The Session Initiation Protocol (SIP) works in concert with these protocols by Rosenberg, et. al. Standards Track [Page 8] RFC 3261 SIP: Session Initiation Protocol June 2002 enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share. For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy servers) to which user agents can send registrations, invitations to sessions, and other requests. SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established. 2 Overview of SIP Functionality SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility [27] - users can maintain a single externally visible identifier regardless of their network location. SIP supports five facets of establishing and terminating multimedia communications: User location: determination of the end system to be used for communication; User availability: determination of the willingness of the called party to engage in communications; User capabilities: determination of the media and media parameters to be used; Session setup: ""ringing"", establishment of session parameters at both called and calling party; Session management: including transfer and termination of sessions, modifying session parameters, and invoking services. SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, the Media Rosenberg, et. al. Standards Track [Page 9] RFC 3261 SIP: Session Initiation Protocol June 2002 Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete services to the users. However, the basic functionality and operation of SIP does not depend on any of these protocols. SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a ""caller ID"" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services. SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of network resource reservation capabilities. The nature of the services provided make security particularly important. To that end, SIP provides a suite of security services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity protection, and encryption and privacy services. SIP works with both IPv4 and IPv6. 3 Terminology In this document, the key words ""MUST"", ""MUST NOT"", ""REQUIRED"", ""SHALL"", ""SHALL NOT"", ""SHOULD"", ""SHOULD NOT"", ""RECOMMENDED"", ""NOT RECOMMENDED"", ""MAY"", and ""OPTIONAL"" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. 4 Overview of Operation This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature and does not contain any normative statements. Rosenberg, et. al. Standards Track [Page 10] RFC 3261 SIP: Session Initiation Protocol June 2002 The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established. Figure 1 shows a typical example of a SIP message exchange between two users, Alice and Bob. (Each message is labeled with the letter ""F"" and a number for reference by the text.) In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. This typical arrangement is often referred to as the ""SIP trapezoid"" as shown by the geometric shape of the dotted lines in Figure 1. Alice ""calls"" Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. SIP URIs are defined in Section 19.1. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP service provider. Alice has a SIP URI of sip:alice@atlanta.com. Alice might have typed in Bob's URI or perhaps clicked on a hyperlink or an entry in an address book. SIP also provides a secure URI, called a SIPS URI. An example would be sips:bob@biloxi.com. A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee. SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. In this example, the transaction begins with Alice's softphone sending an INVITE request addressed to Bob's SIP URI. INVITE is an example of a SIP method that specifies the action that the requestor (Alice) wants the server (Bob) to take. The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destination address, Alice's address, and information about the type of session that Alice wishes to establish with Bob. The INVITE (message F1 in Figure 1) might look like this: Rosenberg, et. al. Standards Track [Page 11] RFC 3261 SIP: Session Initiation Protocol June 2002 atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | | Figure 1: SIP session setup example with SIP trapezoid INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below: Rosenberg, et. al. Standards Track [Page 12] RFC 3261 SIP: Session Initiation Protocol June 2002 Via contains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction. To contains a display name (Bob) and a SIP or SIPS URI (sip:bob@biloxi.com) towards which the request was originally directed. Display names are described in RFC 2822 [3]. From also contains a display name (Alice) and a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the originator of the request. This header field also has a tag parameter containing a random string (1928301774) that was added to the URI by the softphone. It is used for identification purposes. Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog. CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number. Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests. Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop. Content-Type contains a description of the message body (not shown). Content-Length contains an octet (byte) count of the message body. The complete set of SIP header fields is defined in Section 20. The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the Rosenberg, et. al. Standards Track [Page 13] RFC 3261 SIP: Session Initiation Protocol June 2002 example) is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message. Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the softphone sends the INVITE to the SIP server that serves Alice's domain, atlanta.com. The address of the atlanta.com SIP server could have been configured in Alice's softphone, or it could have been discovered by DHCP, for example. The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice's softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows Alice's softphone to correlate this response to the sent INVITE. The atlanta.com proxy server locates the proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. This is described in [4]. As a result, it obtains the IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE request there. Before forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains its own address (the INVITE already contains Alice's address in the first Via). The biloxi.com proxy server receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to indicate that it has received the INVITE and is processing the request. The proxy server consults a database, generically called a location service, that contains the current IP address of Bob. (We shall see in the next section how this database can be populated.) The biloxi.com proxy server adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP phone. Bob's SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being Rosenberg, et. al. Standards Track [Page 14] RFC 3261 SIP: Session Initiation Protocol June 2002 maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE. When Alice's softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps using an audio ringback tone or by displaying a message on Alice's screen. In this example, Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange. If Bob did not wish to answer the call or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established. The complete list of SIP response codes is in Section 21. The 200 (OK) (message F9 in Figure 1) might look like this as Bob sends it out: SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) The first line of the response contains the response code (200) and the reason phrase (OK). The remaining lines contain header fields. The Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request. (There are three Via header field values - one added by Alice's SIP phone, one added by the atlanta.com proxy, and one added by the biloxi.com proxy.) Bob's SIP phone has added a tag parameter to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included in all future Rosenberg, et. al. Standards Track [Page 15] RFC 3261 SIP: Session Initiation Protocol June 2002 requests and responses in this call. The Contact header field contains a URI at which Bob can be directly reached at his SIP phone. The Content-Type and Content-Length refer to the message body (not shown) that contains Bob's SDP media information. In addition to DNS and location service lookups shown in this example, proxy servers can make flexible ""routing decisions"" to decide where to send a request. For example, if Bob's SIP phone returned a 486 (Busy Here) response, the biloxi.com proxy server could proxy the INVITE to Bob's voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking. In this case, the 200 (OK) is routed back through the two proxies and is received by Alice's softphone, which then stops the ringback tone and indicates that the call has been answered. Finally, Alice's softphone sends an acknowledgement message, ACK, to Bob's SIP phone to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from Alice's softphone to Bob's SIP phone, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. Full details on session setup are in Section 13. Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages. During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re- INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. Full details on session modification are in Section 14. Rosenberg, et. al. Standards Track [Page 16] RFC 3261 SIP: Session Initiation Protocol June 2002 At the end of the call, Bob disconnects (hangs up) first and generates a BYE message. This BYE is routed directly to Alice's softphone, again bypassing the proxies. Alice confirms receipt of the BYE with a 200 (OK) response, which terminates the session and the BYE transaction. No ACK is sent - an ACK is only sent in response to a response to an INVITE request. The reasons for this special handling for INVITE will be discussed later, but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking. For this reason, request handling in SIP is often classified as either INVITE or non- INVITE, referring to all other methods besides INVITE. Full details on session termination are in Section 15. Section 24.2 describes the messages shown in Figure 1 in full. In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session. For example, if the biloxi.com proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record- Route that contained a URI resolving to the hostname or IP address of the proxy. This information would be received by both Bob's SIP phone and (due to the Record-Route header field being passed back in the 200 (OK)) Alice's softphone and stored for the duration of the dialog. The biloxi.com proxy server would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently decide to receive subsequent messages, and those messages will pass through all proxies that elect to receive it. This capability is frequently used for proxies that are providing mid-call features. Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). The registrar writes this association, also called a binding, to a database, called the location service, where it can be used by the proxy in the biloxi.com domain. Often, a registrar server for a domain is co-located with the proxy for that domain. It is an important concept that the distinction between types of SIP servers is logical, not physical. Bob is not limited to registering from a single device. For example, both his SIP phone at home and the one in the office could send registrations. This information is stored together in the location Rosenberg, et. al. Standards Track [Page 17] RFC 3261 SIP: Session Initiation Protocol June 2002 service and allows a proxy to perform various types of searches to locate Bob. Similarly, more than one user can be registered on a single device at the same time. The location service is just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs that tell the proxy where to send the request. Registrations are one way to create this information, but not the only way. Arbitrary mapping functions can be configured at the discretion of the administrator. Finally, it is important to note that in SIP, registration is used for routing incoming SIP requests and has no role in authorizing outgoing requests. Authorization and authentication are handled in SIP either on a request-by-request basis with a challenge/response mechanism, or by using a lower layer scheme as discussed in Section 26. The complete set of SIP message details for this registration example is in Section 24.1. Additional operations in SIP, such as querying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL, will be introduced in later sections. 5 Structure of the Protocol SIP is structured as a layered protocol, which means that its behavior is described in terms of a set of fairly independent processing stages with only a loose coupling between each stage. The protocol behavior is described as layers for the purpose of presentation, allowing the description of functions common across elements in a single section. It does not dictate an implementation in any way. When we say that an element ""contains"" a layer, we mean it is compliant to the set of rules defined by that layer. Not every element specified by the protocol contains every layer. Furthermore, the elements specified by SIP are logical elements, not physical ones. A physical realization can choose to act as different logical elements, perhaps even on a transaction-by-transaction basis. The lowest layer of SIP is its syntax and encoding. Its encoding is specified using an augmented Backus-Naur Form grammar (BNF). The complete BNF is specified in Section 25; an overview of a SIP message's structure can be found in Section 7. Rosenberg, et. al. Standards Track [Page 18] RFC 3261 SIP: Session Initiation Protocol June 2002 The second layer is the transport layer. It defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network. All SIP elements contain a transport layer. The transport layer is described in Section 18. The third layer is the transaction layer. Transactions are a fundamental component of SIP. A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions. Discussion of transactions can be found in Section 17. User agents contain a transaction layer, as do stateful proxies. Stateless proxies do not contain a transaction layer. The transaction layer has a client component (referred to as a client transaction) and a server component (referred to as a server transaction), each of which are represented by a finite state machine that is constructed to process a particular request. The layer above the transaction layer is called the transaction user (TU). Each of the SIP entities, except the stateless proxy, is a transaction user. When a TU wishes to send a request, it creates a client transaction instance and passes it the request along with the destination IP address, port, and transport to which to send the request. A TU that creates a client transaction can also cancel it. When a client cancels a transaction, it requests that the server stop further processing, revert to the state that existed before the transaction was initiated, and generate a specific error response to that transaction. This is done with a CANCEL request, which constitutes its own transaction, but references the transaction to be cancelled (Section 9). The SIP elements, that is, user agent clients and servers, stateless and stateful proxies and registrars, contain a core that distinguishes them from each other. Cores, except for the stateless proxy, are transaction users. While the behavior of the UAC and UAS cores depends on the method, there are some common rules for all methods (Section 8). For a UAC, these rules govern the construction of a request; for a UAS, they govern the processing of a request and generating a response. Since registrations play an important role in SIP, a UAS that handles a REGISTER is given the special name registrar. Section 10 describes UAC and UAS core behavior for the REGISTER method. Section 11 describes UAC and UAS core behavior for the OPTIONS method, used for determining the capabilities of a UA. Rosenberg, et. al. Standards Track [Page 19] RFC 3261 SIP: Session Initiation Protocol June 2002 Certain other requests are sent within a dialog. A dialog is a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages and proper routing of requests between the user agents. The INVITE method is the only way defined in this specification to establish a dialog. When a UAC sends a request that is within the context of a dialog, it follows the common UAC rules as discussed in Section 8 but also the rules for mid-dialog requests. Section 12 discusses dialogs and presents the procedures for their construction and maintenance, in addition to construction of requests within a dialog. The most important method in SIP is the INVITE method, which is used to establish a session between participants. A session is a collection of participants, and streams of media between them, for the purposes of communication. Section 13 discusses how sessions are initiated, resulting in one or more SIP dialogs. Section 14 discusses how characteristics of that session are modified through the use of an INVITE request within a dialog. Finally, section 15 discusses how a session is terminated. The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal entirely with the UA core (Section 9 describes cancellation, which applies to both UA core and proxy core). Section 16 discusses the proxy element, which facilitates routing of messages between user agents. 6 Definitions The following terms have special significance for SIP. Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the ""public address"" of the user. Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. Rosenberg, et. al. Standards Track [Page 20] RFC 3261 SIP: Session Initiation Protocol June 2002 Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Call Leg: Another name for a dialog [31]; no longer used in this specification. Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true. Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients. Conference: A multimedia session (see below) that contains multiple participants. Core: Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users. Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543. Downstream: A direction of message forwarding within a transaction that refers to the direction that requests flow from the user agent client to user agent server. Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final. Header: A header is a component of a SIP message that conveys information about the message. It is structured as a sequence of header fields. Header Field: A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a Rosenberg, et. al. Standards Track [Page 21] RFC 3261 SIP: Session Initiation Protocol June 2002 given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row. Header Field Value: A header field value is a single value; a header field consists of zero or more header field values. Home Domain: The domain providing service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of a registration. Informational Response: Same as a provisional response. Initiator, Calling Party, Caller: The party initiating a session (and dialog) with an INVITE request. A caller retains this role from the time it sends the initial INVITE that established a dialog until the termination of that dialog. Invitation: An INVITE request. Invitee, Invited User, Called Party, Callee: The party that receives an INVITE request for the purpose of establishing a new session. A callee retains this role from the time it receives the INVITE until the termination of the dialog established by that INVITE. Location Service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings. Loop: A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors, and the procedures for detecting them and handling them are described by the protocol. Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from Rosenberg, et. al. Standards Track [Page 22] RFC 3261 SIP: Session Initiation Protocol June 2002 the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router. Message: Data sent between SIP elements as part of the protocol. SIP messages are either requests or responses. Method: The method is the primary function that a request is meant to invoke on a server. The method is carried in the request message itself. Example methods are INVITE and BYE. Outbound Proxy: A proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols. Parallel Search: In a parallel search, a proxy issues several requests to possible user locations upon receiving an incoming request. Rather than issuing one request and then waiting for the final response before issuing the next request as in a sequential search, a parallel search issues requests without waiting for the result of previous requests. Provisional Response: A response used by the server to indicate progress, but that does not terminate a SIP transaction. 1xx responses are provisional, other responses are considered final. Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity ""closer"" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. Recursion: A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response."
"Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs. Rosenberg, et. al. Standards Track [Page 23] RFC 3261 SIP: Session Initiation Protocol June 2002 Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. Regular Transaction: A regular transaction is any transaction with a method other than INVITE, ACK, or CANCEL. Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation. Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server. Ringback: Ringback is the signaling tone produced by the calling party's application indicating that a called party is being alerted (ringing). Route Set: A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured. Server: A server is a network element that receives requests in order to service them and sends back responses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and registrars. Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, proceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final response always terminates a sequential search. Session: From the SDP specification: ""A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session."" (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP sessions.) As defined, a callee can be invited several times, by different calls, to the same session. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field. SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response Rosenberg, et. al. Standards Track [Page 24] RFC 3261 SIP: Session Initiation Protocol June 2002 sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. Spiral: A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls joe@example.com. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to bob@example.com. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition. Stateful Proxy: A logical entity that maintains the client and server transaction state machines defined by this specification during the processing of a request, also known as a transaction stateful proxy. The behavior of a stateful proxy is further defined in Section 16. A (transaction) stateful proxy is not the same as a call stateful proxy. Stateless Proxy: A logical entity that does not maintain the client or server transaction state machines defined in this specification when it processes requests. A stateless proxy forwards every request it receives downstream and every response it receives upstream. Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in this specification, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers. Target Refresh Request: A target refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog. Transaction User (TU): The layer of protocol processing that resides above the transaction layer. Transaction users include the UAC core, UAS core, and proxy core. Rosenberg, et. al. Standards Track [Page 25] RFC 3261 SIP: Session Initiation Protocol June 2002 Upstream: A direction of message forwarding within a transaction that refers to the direction that responses flow from the user agent server back to the user agent client. URL-encoded: A character string encoded according to RFC 2396, Section 2.4 [5]. User Agent Client (UAC): A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction. UAC Core: The set of processing functions required of a UAC that reside above the transaction and transport layers. User Agent Server (UAS): A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction. UAS Core: The set of processing functions required at a UAS that resides above the transaction and transport layers. User Agent (UA): A logical entity that can act as both a user agent client and user agent server. The role of UAC and UAS, as well as proxy and redirect servers, are defined on a transaction-by-transaction basis. For example, the user agent initiating a call acts as a UAC when sending the initial INVITE request and as a UAS when receiving a BYE request from the callee. Similarly, the same software can act as a proxy server for one request and as a redirect server for the next request. Proxy, location, and registrar servers defined above are logical entities; implementations MAY combine them into a single application. 7 SIP Messages SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 [7]). Rosenberg, et. al. Standards Track [Page 26] RFC 3261 SIP: Session Initiation Protocol June 2002 A SIP message is either a request from a client to a server, or a response from a server to a client. Both Request (section 7.1) and Response (section 7.2) messages use the basic format of RFC 2822 [3], even though the syntax differs in character set and syntax specifics. (SIP allows header fields that would not be valid RFC 2822 header fields, for example.) Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body. generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not. Except for the above difference in character sets, much of SIP's message and header field syntax is identical to HTTP/1.1. Rather than repeating the syntax and semantics here, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). However, SIP is not an extension of HTTP. 7.1 Requests SIP requests are distinguished by having a Request-Line for a start- line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character. The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements. Request-Line = Method SP Request-URI SP SIP-Version CRLF Method: This specification defines six methods: REGISTER for registering contact information, INVITE, ACK, and CANCEL for setting up sessions, BYE for terminating sessions, and OPTIONS for querying servers about their capabilities. SIP extensions, documented in standards track RFCs, may define additional methods. Rosenberg, et. al. Standards Track [Page 27] RFC 3261 SIP: Session Initiation Protocol June 2002 Request-URI: The Request-URI is a SIP or SIPS URI as described in Section 19.1 or a general URI (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in ""<>"". SIP elements MAY support Request-URIs with schemes other than ""sip"" and ""sips"", for example the ""tel"" URI scheme of RFC 2806 [9]. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme. SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP-Version of ""SIP/2.0"". The SIP-Version string is case-insensitive, but implementations MUST send upper-case. Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference. 7.2 Responses SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character. No CR or LF is allowed except in the final CRLF sequence. Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase. While this specification suggests specific wording for the reason phrase, implementations MAY choose other text, for example, in the language indicated in the Accept-Language header field of the request. Rosenberg, et. al. Standards Track [Page 28] RFC 3261 SIP: Session Initiation Protocol June 2002 The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a ""1xx response"", any response with a status code between 200 and 299 as a ""2xx response"", and so on. SIP/2.0 allows six values for the first digit: 1xx: Provisional -- request received, continuing to process the request; 2xx: Success -- the action was successfully received, understood, and accepted; 3xx: Redirection -- further action needs to be taken in order to complete the request; 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error -- the server failed to fulfill an apparently valid request; 6xx: Global Failure -- the request cannot be fulfilled at any server. Section 21 defines these classes and describes the individual codes. 7.3 Header Fields SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding. This specification conforms to RFC 2234 [10] and uses only explicit whitespace and folding as an integral part of the grammar. [H4.2] also specifies that multiple header fields of the same field name whose value is a comma-separated list can be combined into one header field. That applies to SIP as well, but the specific rule is different because of the different grammars. Specifically, any SIP header whose grammar is of the form header = ""header-name"" HCOLON header-value *(COMMA header-value) allows for combining header fields of the same name into a comma- separated list. The Contact header field allows a comma-separated list unless the header field value is ""*"". Rosenberg, et. al. Standards Track [Page 29] RFC 3261 SIP: Session Initiation Protocol June 2002 7.3.1 Header Field Format Header fields follow the same generic header format as that given in Section 2.2 of RFC 2822 [3]. Each header field consists of a field name followed by a colon ("":"") and the field value. field-name: field-value The formal grammar for a message-header specified in Section 25 allows for an arbitrary amount of whitespace on either side of the colon; however, implementations should avoid spaces between the field name and the colon and use a single space (SP) between the colon and the field-value. Subject: lunch Subject : lunch Subject :lunch Subject: lunch Thus, the above are all valid and equivalent, but the last is the preferred form. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a single SP character. Thus, the following are equivalent: Subject: I know you're there, pick up the phone and talk to me! Subject: I know you're there, pick up the phone and talk to me! The relative order of header fields with different field names is not significant. However, it is RECOMMENDED that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing. The relative order of header field rows with the same field name is important. Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one ""field-name: field-value"" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. Multiple header Rosenberg, et. al. Standards Track [Page 30] RFC 3261 SIP: Session Initiation Protocol June 2002 field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row. Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms. The following groups of header field rows are valid and equivalent: Route: <sip:alice@atlanta.com> Subject: Lunch Route: <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Subject: Lunch Subject: Lunch Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com> Each of the following blocks is valid but not equivalent to the others: Route: <sip:alice@atlanta.com> Route: <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Route: <sip:bob@biloxi.com> Route: <sip:alice@atlanta.com> Route: <sip:carol@chicago.com> Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, <sip:bob@biloxi.com> The format of a header field-value is defined per header-name. It will always be either an opaque sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators, and quoted strings. Many existing header fields will adhere to the general form of a value followed by a semi-colon separated sequence of parameter-name, parameter-value pairs: field-name: field-value *(;parameter-name=parameter-value) Rosenberg, et. al. Standards Track [Page 31] RFC 3261 SIP: Session Initiation Protocol June 2002 Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name MUST NOT appear more than once. When comparing header fields, field names are always case- insensitive. Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. For example, Contact: <sip:alice@atlanta.com>;expires=3600 is equivalent to CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600 and Content-Disposition: session;handling=optional is equivalent to content-disposition: Session;HANDLING=OPTIONAL The following two header fields are not equivalent: Warning: 370 devnull ""Choose a bigger pipe"" Warning: 370 devnull ""CHOOSE A BIGGER PIPE"" 7.3.2 Header Field Classification Some header fields only make sense in requests or responses. These are called request header fields and response header fields, respectively. If a header field appears in a message not matching its category (such as a request header field in a response), it MUST be ignored. Section 20 defines the classification of each header field. 7.3.3 Compact Form SIP provides a mechanism to represent common header field names in an abbreviated form. This may be useful when messages would otherwise become too large to be carried on the transport available to it (exceeding the maximum transmission unit (MTU) when using UDP, for example). These compact forms are defined in Section 20. A compact form MAY be substituted for the longer form of a header field name at any time without changing the semantics of the message. A header Rosenberg, et. al. Standards Track [Page 32] RFC 3261 SIP: Session Initiation Protocol June 2002 field name MAY appear in both long and short forms within the same message. Implementations MUST accept both the long and short forms of each header name. 7.4 Bodies Requests, including new requests defined in extensions to this specification, MAY contain message bodies unless otherwise noted. The interpretation of the body depends on the request method. For response messages, the request method and the response status code determine the type and interpretation of any message body. All responses MAY include a body. 7.4.1 Message Body Type The Internet media type of the message body MUST be given by the Content-Type header field. If the body has undergone any encoding such as compression, then this MUST be indicated by the Content- Encoding header field; otherwise, Content-Encoding MUST be omitted. If applicable, the character set of the message body is indicated as part of the Content-Type header-field value. The ""multipart"" MIME type defined in RFC 2046 [11] MAY be used within the body of the message. Implementations that send requests containing multipart message bodies MUST send a session description as a non-multipart message body if the remote implementation requests this through an Accept header field that does not contain multipart. SIP messages MAY contain binary bodies or body parts. When no explicit charset parameter is provided by the sender, media subtypes of the ""text"" type are defined to have a default charset value of ""UTF-8"". 7.4.2 Message Body Length The body length in bytes is provided by the Content-Length header field. Section 20.14 describes the necessary contents of this header field in detail. The ""chunked"" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. (Note: The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator.) Rosenberg, et. al. Standards Track [Page 33] RFC 3261 SIP: Session Initiation Protocol June 2002 7.5 Framing SIP Messages Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols. Each such datagram carries one request or response. See Section 18 on constraints on usage of unreliable transports. Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line [H4.1]. The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports. 8 General User Agent Behavior A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them. A UAC is capable of generating a request based on some external stimulus (the user clicking a button, or a signal on a PSTN line) and processing a response. A UAS is capable of receiving a request and generating a response based on user input, external stimulus, the result of a program execution, or some other mechanism. When a UAC sends a request, the request passes through some number of proxy servers, which forward the request towards the UAS. When the UAS generates a response, the response is forwarded towards the UAC. UAC and UAS procedures depend strongly on two factors. First, based on whether the request or response is inside or outside of a dialog, and second, based on the method of a request. Dialogs are discussed thoroughly in Section 12; they represent a peer-to-peer relationship between user agents and are established by specific SIP methods, such as INVITE. In this section, we discuss the method-independent rules for UAC and UAS behavior when processing requests that are outside of a dialog. This includes, of course, the requests which themselves establish a dialog. Security procedures for requests and responses outside of a dialog are described in Section 26. Specifically, mechanisms exist for the UAS and UAC to mutually authenticate. A limited set of privacy features are also supported through encryption of bodies using S/MIME. Rosenberg, et. al. Standards Track [Page 34] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1 UAC Behavior This section covers UAC behavior outside of a dialog. 8.1.1 Generating the Request A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions. These header fields are in addition to the mandatory request line, which contains the method, Request-URI, and SIP version. Examples of requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11). 8.1.1.1 Request-URI The initial Request-URI of the message SHOULD be set to the value of the URI in the To field. One notable exception is the REGISTER method; behavior for setting the Request-URI of REGISTER is given in Section 10. It may also be undesirable for privacy reasons or convenience to set these fields to the same value (especially if the originating UA expects that the Request-URI will be changed during transit). In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI. Rosenberg, et. al. Standards Track [Page 35] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.2 To The To header field first and foremost specifies the desired ""logical"" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field MAY contain a SIP or SIPS URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme. The To header field allows for a display name. A UAC may learn how to populate the To header field for a particular request in a number of ways. Usually the user will suggest the To header field through a human interface, perhaps inputting the URI manually or selecting it from some sort of address book. Frequently, the user will not enter a complete URI, but rather a string of digits or letters (for example, ""bob""). It is at the discretion of the UA to choose how to interpret this input. Using the string to form the user part of a SIP URI implies that the UA wishes the name to be resolved in the domain to the right-hand side (RHS) of the at-sign in the SIP URI (for instance, sip:bob@example.com). Using the string to form the user part of a SIPS URI implies that the UA wishes to communicate securely, and that the name is to be resolved in the domain to the RHS of the at-sign. The RHS will frequently be the home domain of the requestor, which allows for the home domain to process the outgoing request. This is useful for features like ""speed dial"" that require interpretation of the user part in the home domain. The tel URL may be used when the UA does not wish to specify the domain that should interpret a telephone number that has been input by the user. Rather, each domain through which the request passes would be given that opportunity. As an example, a user in an airport might log in and send requests through an outbound proxy in the airport. If they enter ""411"" (this is the phone number for local directory assistance in the United States), that needs to be interpreted and processed by the outbound proxy in the airport, not the user's home domain. In this case, tel:411 would be the right choice. A request outside of a dialog MUST NOT contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog is established, no tag is present. For further information on the To header field, see Section 20.39. The following is an example of a valid To header field: To: Carol <sip:carol@chicago.com> Rosenberg, et. al. Standards Track [Page 36] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.3 From The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by SIP elements to determine which processing rules to apply to a request (for example, automatic call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names. The From header field allows for a display name. A UAC SHOULD use the display name ""Anonymous"", along with a syntactically correct, but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the identity of the client is to remain hidden. Usually, the value that populates the From header field in requests generated by a particular UA is pre-provisioned by the user or by the administrators of the user's local domain. If a particular UA is used by multiple users, it might have switchable profiles that include a URI corresponding to the identity of the profiled user. Recipients of requests can authenticate the originator of a request in order to ascertain that they are who their From header field claims they are (see Section 22 for more on authentication). The From field MUST contain a new ""tag"" parameter, chosen by the UAC. See Section 19.3 for details on choosing a tag. For further information on the From header field, see Section 20.20. Examples: From: ""Bob"" <sips:bob@biloxi.com> ;tag=a48s From: sip:+12125551212@phone2net.com;tag=887s From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA. In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. Note that when requests are retried after certain Rosenberg, et. al. Standards Track [Page 37] RFC 3261 SIP: Session Initiation Protocol June 2002 failure responses that solicit an amendment to a request (for example, a challenge for authentication), these retried requests are not considered new requests, and therefore do not need new Call-ID header fields; see Section 8.1.3.5. Use of cryptographically random identifiers (RFC 1750 [12]) in the generation of Call-IDs is RECOMMENDED. Implementations MAY use the form ""localid@host"". Call-IDs are case-sensitive and are simply compared byte-by-byte. Using cryptographically random identifiers provides some protection against session hijacking and reduces the likelihood of unintentional Call-ID collisions. No provisioning or human interface is required for the selection of the Call-ID header field value for a request. For further information on the Call-ID header field, see Section 20.8. Example: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com 8.1.1.5 CSeq The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values. Section 12.2.1.1 discusses construction of the CSeq for requests within a dialog. Example: CSeq: 4711 INVITE Rosenberg, et. al. Standards Track [Page 38] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.6 Max-Forwards The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response. A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. This number was chosen to be sufficiently large to guarantee that a request would not be dropped in any SIP network when there were no loops, but not so large as to consume proxy resources when a loop does occur. Lower values should be used with caution and only in networks where topologies are known by the UA. 8.1.1.7 Via The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected (which may involve the usage of the procedures in [4]). When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server. The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges. The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC 2543. The branch ID inserted by an element compliant with this specification MUST always begin with the characters ""z9hG4bK"". These 7 characters are used as a magic cookie (7 is deemed sufficient to ensure that an older RFC 2543 implementation would not pick such a value), so that servers receiving the request can determine that the branch ID was constructed in the fashion described by this Rosenberg, et. al. Standards Track [Page 39] RFC 3261 SIP: Session Initiation Protocol June 2002 specification (that is, globally unique). Beyond this requirement, the precise format of the branch token is implementation-defined. The Via header maddr, ttl, and sent-by components will be set when the request is processed by the transport layer (Section 18). Via processing for proxies is described in Section 16.6 Item 8 and Section 16.7 Item 3. 8.1.1.8 Contact The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. For further information on the Contact header field, see Section 20.10. 8.1.1.9 Supported and Require If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a Supported header field in the request listing the option tags (Section 19.2) for those extensions. The option tags listed MUST only refer to extensions defined in standards-track RFCs. This is to prevent servers from insisting that clients implement non-standard, vendor-defined features in order to receive service. Extensions defined by experimental and informational RFCs are explicitly excluded from usage with the Supported header field in a request, since they too are often used to document vendor-defined extensions. If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request in order to process the request, it MUST insert a Require header field into the request listing the option tag for that extension. If the UAC wishes to apply an extension to the request and insist that any proxies that are Rosenberg, et. al. Standards Track [Page 40] RFC 3261 SIP: Session Initiation Protocol June 2002 traversed understand that extension, it MUST insert a Proxy-Require header field into the request listing the option tag for that extension. As with the Supported header field, the option tags in the Require and Proxy-Require header fields MUST only refer to extensions defined in standards-track RFCs. 8.1.1.10 Additional Message Components After a new request has been created, and the header fields described above have been properly constructed, any additional optional header fields are added, as are any header fields specific to the method. SIP requests MAY contain a MIME-encoded message-body. Regardless of the type of body that a request contains, certain header fields must be formulated to characterize the contents of the body. For further information on these header fields, see Sections 20.11 through 20.15. 8.1.2 Sending the Request The destination for the request is then computed. Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. If the first element in the route set indicated a strict router (resulting in forming the request as described in Section 12.2.1.1), the procedures MUST be applied to the Request-URI of the request."
"Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present. These procedures yield an ordered set of address, port, and transports to attempt. Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI. Local policy MAY specify an alternate set of destinations to attempt. If the Request-URI contains a SIPS URI, any alternate destinations MUST be contacted with TLS. Beyond that, there are no restrictions on the alternate destinations if the request contains no Route header field. This provides a simple alternative to a pre-existing route set as a way to specify an outbound proxy. However, that approach for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing route set with a single URI SHOULD be used instead. If the request contains a Route header field, the request SHOULD be sent to the locations derived from its topmost value, but MAY be sent to any server that the UA is certain will honor the Route and Request-URI policies specified in this document (as opposed to those in RFC 2543). In particular, a UAC configured with an outbound proxy SHOULD Rosenberg, et. al. Standards Track [Page 41] RFC 3261 SIP: Session Initiation Protocol June 2002 attempt to send the request to the location indicated in the first Route header field value instead of adopting the policy of sending all messages to the outbound proxy. This ensures that outbound proxies that do not add Record-Route header field values will drop out of the path of subsequent requests. It allows endpoints that cannot resolve the first Route URI to delegate that task to an outbound proxy. The UAC SHOULD follow the procedures defined in [4] for stateful elements, trying each address until a server is contacted. Each try constitutes a new transaction, and therefore each carries a different topmost Via header field value with a new branch parameter. Furthermore, the transport value in the Via header field is set to whatever transport was determined for the target server. 8.1.3 Processing Responses Responses are first processed by the transport layer and then passed up to the transaction layer. The transaction layer performs its processing and then passes the response up to the TU. The majority of response processing in the TU is method specific. However, there are some general behaviors independent of the method. 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. 8.1.3.2 Unrecognized Responses A UAC MUST treat any final response it does not recognize as being equivalent to the x00 response code of that class, and MUST be able to process the x00 response code for all classes. For example, if a UAC receives an unrecognized response code of 431, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) response code. A UAC MUST treat any provisional response different than 100 that it does not recognize as 183 (Session Progress). A UAC MUST be able to process 100 and 183 responses. Rosenberg, et. al. Standards Track [Page 42] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.3.3 Vias If more than one Via header field value is present in a response, the UAC SHOULD discard the message. The presence of additional Via header field values that precede the originator of the request suggests that the message was misrouted or possibly corrupted. 8.1.3.4 Processing 3xx Responses Upon receipt of a redirection response (for example, a 301 response status code), clients SHOULD use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request. This process is similar to that of a proxy recursing on a 3xx class response as detailed in Sections 16.5 and 16.6. A client starts with an initial target set containing exactly one URI, the Request-URI of the original request. If a client wishes to formulate new requests based on a 3xx class response to that request, it places the URIs to try into the target set. Subject to the restrictions in this specification, a client can choose which Contact URIs it places into the target set. As with proxy recursion, a client processing 3xx class responses MUST NOT add any given URI to the target set more than once. If the original request had a SIPS URI in the Request- URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI. Any new request may receive 3xx responses themselves containing the original URI as a contact. Two locations can be configured to redirect to each other. Placing any given URI in the target set only once prevents infinite redirection loops. As the target set grows, the client MAY generate new requests to the URIs in any order. A common mechanism is to order the set by the ""q"" parameter value from the Contact header field value. Requests to the URIs MAY be generated serially or in parallel. One approach is to process groups of decreasing q-values serially and process the URIs in each q-value group in parallel. Another is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value. If contacting an address in the list results in a failure, as defined in the next paragraph, the element moves to the next address in the list, until the list is exhausted. If the list is exhausted, then the request has failed. Rosenberg, et. al. Standards Track [Page 43] RFC 3261 SIP: Session Initiation Protocol June 2002 Failures SHOULD be detected through failure response codes (codes greater than 399); for network errors the client transaction will report any transport layer failures to the transaction user. Note that some response codes (detailed in 8.1.3.5) indicate that the request can be retried; requests that are reattempted should not be considered failures. When a failure for a particular contact address is received, the client SHOULD try the next contact address. This will involve creating a new client transaction to deliver a new request. In order to create a request based on a contact address in a 3xx response, a UAC MUST copy the entire URI from the target set into the Request-URI, except for the ""method-param"" and ""header"" URI parameters (see Section 19.1.1 for a definition of these parameters). It uses the ""header"" parameters to create header field values for the new request, overwriting header field values associated with the redirected request in accordance with the guidelines in Section 19.1.5. Note that in some instances, header fields that have been communicated in the contact address may instead append to existing request header fields in the original redirected request. As a general rule, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple values, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address. For example, if a contact address is returned with the following value: sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> Then any Subject header field in the original redirected request is overwritten, but the HTTP URL is merely appended to any existing Call-Info header field values. It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example. Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field as discussed in Section 8.1.1.7. Rosenberg, et. al. Standards Track [Page 44] RFC 3261 SIP: Session Initiation Protocol June 2002 In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request. In some instances, Contact header field values may be cached at UAC temporarily or permanently depending on the status code received and the presence of an expiration interval; see Sections 21.3.2 and 21.3.3. 8.1.3.5 Processing 4xx Responses Certain 4xx response codes require specific UA processing, independent of the method. If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC SHOULD follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials. If a 413 (Request Entity Too Large) response is received (Section 21.4.11), the request contained a body that was longer than the UAS was willing to accept. If possible, the UAC SHOULD retry the request, either omitting the body or using one of a smaller length. If a 415 (Unsupported Media Type) response is received (Section 21.4.13), the request contained media types not supported by the UAS. The UAC SHOULD retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response. If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14), the Request-URI used a URI scheme not supported by the server. The client SHOULD retry the request, this time, using a SIP URI. If a 420 (Bad Extension) response is received (Section 21.4.15), the request contained a Require or Proxy-Require header field listing an option-tag for a feature not supported by a proxy or UAS. The UAC SHOULD retry the request, this time omitting any extensions listed in the Unsupported header field in the response. In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. Rosenberg, et. al. Standards Track [Page 45] RFC 3261 SIP: Session Initiation Protocol June 2002 With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case. 8.2 UAS Behavior When a request outside of a dialog is processed by a UAS, there is a set of processing rules that are followed, independent of the method. Section 12 gives guidance on how a UAS can tell whether a request is inside or outside of a dialog. Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed. UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section). 8.2.1 Method Inspection Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request. If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response. Procedures for generating responses are described in Section 8.2.6. The UAS MUST also add an Allow header field to the 405 (Method Not Allowed) response. The Allow header field MUST list the set of methods supported by the UAS generating the message. The Allow header field is presented in Section 20.5. If the method is one supported by the server, processing continues. 8.2.2 Header Inspection If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. A UAS SHOULD ignore any malformed header fields that are not necessary for processing requests. 8.2.2.1 To and Request-URI The To header field identifies the original recipient of the request designated by the user identified in the From field. The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations. A UAS MAY apply any policy it wishes to determine whether to accept requests when the To Rosenberg, et. al. Standards Track [Page 46] RFC 3261 SIP: Session Initiation Protocol June 2002 header field is not the identity of the UAS. However, it is RECOMMENDED that a UAS accept requests even if they do not recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field does not address a known or current user of this UAS. If, on the other hand, the UAS decides to reject the request, it SHOULD generate a response with a 403 (Forbidden) status code and pass it to the server transaction for transmission. However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response. If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. Typically, a UA that uses the REGISTER method to bind its address-of-record to a specific contact address will see requests whose Request-URI equals that contact address. Other potential sources of received Request-URIs include the Contact header fields of requests and responses sent by the UA that establish or refresh dialogs. 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. 8.2.2.3 Require Assuming the UAS decides that it is the proper element to process the request, it examines the Require header field, if present. The Require header field is used by a UAC to tell a UAS about SIP extensions that the UAC expects the UAS to support in order to process the request properly. Its format is described in Section 20.32. If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). The UAS MUST add an Unsupported header field, and list in it those options it does not understand amongst those in the Require header field of the request. Rosenberg, et. al. Standards Track [Page 47] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response. These header fields MUST be ignored if they are present in these requests. An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request. Example: UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems. 8.2.3 Content Processing Assuming the UAS understands any extensions required by the client, the UAS examines the body of the message, and the header fields that describe it. If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content- Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. The response MUST contain an Accept header field listing the types of all bodies it understands, in the event the request contained bodies of types not supported by the UAS. If the request contained content encodings not understood by the UAS, the response MUST contain an Accept-Encoding header field listing the encodings understood by the UAS. If the request contained content with languages not understood by the UAS, the response MUST contain an Accept-Language header field indicating the languages understood by the UAS. Beyond these checks, body handling depends on the method and type. For further information on the processing of content-specific header fields, see Section 7.4 as well as Section 20.11 through 20.15. Rosenberg, et. al. Standards Track [Page 48] RFC 3261 SIP: Session Initiation Protocol June 2002 8.2.4 Applying Extensions A UAS that wishes to apply some extension when generating the response MUST NOT do so unless support for that extension is indicated in the Supported header field in the request. If the desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. In rare circumstances, where the server cannot process the request without the extension, the server MAY send a 421 (Extension Required) response. This response indicates that the proper response cannot be generated without support of a specific extension. The needed extension(s) MUST be included in a Require header field in the response. This behavior is NOT RECOMMENDED, as it will generally break interoperability. Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. As a result of this, the Require header field in a response will only ever contain option tags defined in standards- track RFCs. 8.2.5 Processing the Request Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method-specific. Section 10 covers the REGISTER request, Section 11 covers the OPTIONS request, Section 13 covers the INVITE request, and Section 15 covers the BYE request. 8.2.6 Generating the Response When a UAS wishes to construct a response to a request, it follows the general procedures detailed in the following subsections. Additional behaviors specific to the response code in question, which are not detailed in this section, may also be required. Once all procedures associated with the creation of a response have been completed, the UAS hands the response back to the server transaction from which it received the request. 8.2.6.1 Sending a Provisional Response One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible. Rosenberg, et. al. Standards Track [Page 49] RFC 3261 SIP: Session Initiation Protocol June 2002 When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response. If there is a delay in generating the response, the UAS SHOULD add a delay value into the Timestamp value in the response. This value MUST contain the difference between the time of sending of the response and receipt of the request, measured in seconds. 8.2.6.2 Headers and Tags The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering. If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). Procedures for the generation of tags are defined in Section 19.3. 8.2.7 Stateless UAS Behavior A stateless UAS is a UAS that does not maintain transaction state. It replies to requests normally, but discards any state that would ordinarily be retained by a UAS after a response has been sent. If a stateless UAS receives a retransmission of a request, it regenerates the response and resends it, just as if it were replying to the first instance of the request. A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. This rules out stateless registrars, for example. Stateless UASs do not use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer. The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge response is issued. If unauthenticated requests were handled statefully, then malicious floods of unauthenticated requests could create massive amounts of Rosenberg, et. al. Standards Track [Page 50] RFC 3261 SIP: Session Initiation Protocol June 2002 transaction state that might slow or completely halt call processing in a UAS, effectively creating a denial of service condition; for more information see Section 26.1.5. The most important behaviors of a stateless UAS are the following: o A stateless UAS MUST NOT send provisional (1xx) responses. o A stateless UAS MUST NOT retransmit responses. o A stateless UAS MUST ignore ACK requests. o A stateless UAS MUST ignore CANCEL requests. o To header tags MUST be generated for responses in a stateless manner - in a manner that will generate the same tag for the same request consistently. For information on tag construction see Section 19.3. In all other respects, a stateless UAS behaves in the same manner as a stateful UAS. A UAS can operate in either a stateful or stateless mode for each new request. 8.3 Redirect Servers In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection. Redirection allows servers to push routing information for a request back in a response to the client, thereby taking themselves out of the loop of further messaging for this transaction while still aiding in locating the target of the request. When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability. A redirect server is logically constituted of a server transaction layer and a transaction user that has access to a location service of some kind (see Section 10 for more on registrars and location services). This location service is effectively a database containing mappings between a single URI and a set of one or more alternative locations at which the target of that URI can be found. A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server either refuses the request or gathers the list of alternative locations from the Rosenberg, et. al. Standards Track [Page 51] RFC 3261 SIP: Session Initiation Protocol June 2002 location service and returns a final response of class 3xx. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for an entire SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers. When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alternative locations into the Contact header field. An ""expires"" parameter to the Contact header field values may also be supplied to indicate the lifetime of the Contact data. The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) response may also give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, or a change of SIP transport from UDP to TCP or vice versa. However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404. If a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite redirection loops. Note that a Contact header field value MAY also refer to a different resource than the one originally called. For example, a SIP call connected to PSTN gateway may need to deliver a special informational announcement such as ""The number you have dialed has been changed."" A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URIs. For example, it could contain URIs for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 discusses implications and limitations of redirecting a SIPS URI to a non-SIPS URI. The ""expires"" parameter of a Contact header field value indicates how long the URI is valid. The value of the parameter is a number indicating seconds. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Malformed values SHOULD be treated as equivalent to 3600. Rosenberg, et. al. Standards Track [Page 52] RFC 3261 SIP: Session Initiation Protocol June 2002 This provides a modest level of backwards compatibility with RFC 2543, which allowed absolute times in this header field. If an absolute time is received, it will be treated as malformed, and then default to 3600. Redirect servers MUST ignore features that are not understood (including unrecognized header fields, any unknown option tags in Require, or even method names) and proceed with the redirection of the request in question. 9 Canceling a Request The previous section has discussed general UA behavior for generating requests and processing responses for requests of all methods. In this section, we discuss a general purpose method, called CANCEL. The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would ""stop ringing"", and then respond to the INVITE with a specific error response (a 487). CANCEL requests can be constructed and sent by both proxies and user agent clients. Section 15 discusses under what conditions a UAC would CANCEL an INVITE request, and Section 16.10 discusses proxy usage of CANCEL. A stateful proxy responds to a CANCEL, rather than simply forwarding a response it would receive from a downstream element. For that reason, CANCEL is referred to as a ""hop-by-hop"" request, since it is responded to at each stateful proxy hop. 9.1 Client Behavior A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition. Rosenberg, et. al. Standards Track [Page 53] RFC 3261 SIP: Session Initiation Protocol June 2002 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17). If the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values. This is needed so that stateless proxies are able to route CANCEL requests properly. The CANCEL request MUST NOT contain any Require or Proxy-Require header fields. Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the ""original request""). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. If the original request has generated a final response, the CANCEL SHOULD NOT be sent, as it is an effective no-op, since CANCEL has no effect on requests that have already generated a final response. When the client decides to send the CANCEL, it creates a client transaction for the CANCEL and passes it the CANCEL request along with the destination address, port, and transport. The destination address, port, and transport for the CANCEL MUST be identical to those used to send the original request. If it was allowed to send the CANCEL before receiving a response for the previous request, the server could receive the CANCEL before the original request. Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is Rosenberg, et. al. Standards Track [Page 54] RFC 3261 SIP: Session Initiation Protocol June 2002 defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request. 9.2 Server Behavior The CANCEL method requests that the TU at the server side cancel a pending transaction. The TU determines the transaction to be cancelled by taking the CANCEL request, and then assuming that the request method is anything but CANCEL or ACK and applying the transaction matching procedures of Section 17.2.3. The matching transaction is the one to be cancelled. The processing of a CANCEL request at a server depends on the type of server. A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it. See Section 16.10 for proxy treatment of CANCEL. A UAS first processes the CANCEL request according to the general UAS processing described in Section 8.2. However, since CANCEL requests are hop-by-hop and cannot be resubmitted, they cannot be challenged by the server in order to get proper credentials in an Authorization header field. Note also that CANCEL requests do not contain a Require header field. If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist). If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request. If it has, the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request. If the UAS has not issued a final response for the original request, its behavior depends on the method of the original request. If the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated). A CANCEL request has no impact on the processing of transactions with any other method defined in this specification. Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same. The response to CANCEL is passed to the server transaction for transmission. Rosenberg, et. al. Standards Track [Page 55] RFC 3261 SIP: Session Initiation Protocol June 2002 10 Registrations 10.1 Overview SIP offers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there. To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain. These address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, for example, to one or more URIs that are somehow ""closer"" to the desired user, sip:bob@engineering.biloxi.com, for example. Ultimately, a proxy will consult a location service that maps a received URI to the user agent(s) at which the desired recipient is currently residing. Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. Generally, it only makes sense to register an address-of-record at a domain's location service when requests for that address-of-record would be routed to that domain. In most cases, this means that the domain of the registration will need to match the domain in the URI of the address-of-record. There are many ways by which the contents of the location service can be established. One way is administratively. In the above example, Bob is known to be a member of the engineering department through access to a corporate database. However, SIP provides a mechanism for a UA to create a binding explicitly. This mechanism is known as registration. Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests."
"This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain. An illustration of the overall registration process is given in Figure 2. Note that the registrar and proxy server are logical roles that can be played by a single device in a network; for purposes of Rosenberg, et. al. Standards Track [Page 56] RFC 3261 SIP: Session Initiation Protocol June 2002 clarity the two are separated in this illustration. Also note that UAs may send requests through a proxy server in order to reach a registrar if the two are separate elements. SIP does not mandate a particular mechanism for implementing the location service. The only requirement is that a registrar for some domain MUST be able to read and write data to the location service, and a proxy or a redirect server for that domain MUST be capable of reading that same data. A registrar MAY be co-located with a particular SIP proxy server for the same domain. 10.2 Constructing the REGISTER Request REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding between an address-of-record and one or more contact addresses. Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of- record. Except as noted, the construction of the REGISTER request and the behavior of clients sending a REGISTER request is identical to the general UAC behavior described in Section 8.1 and Section 17.1. A REGISTER request does not establish a dialog. A UAC MAY include a Route header field in a REGISTER request based on a pre-existing route set as described in Section 8.1. The Record-Route header field has no meaning in REGISTER requests or responses, and MUST be ignored if present. In particular, the UAC MUST NOT create a new route set based on the presence or absence of a Record-Route header field in any response to a REGISTER request. The following header fields, except Contact, MUST be included in a REGISTER request. A Contact header field MAY be included: Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example, ""sip:chicago.com""). The ""userinfo"" and ""@"" components of the SIP URI MUST NOT be present. To: The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name. This address-of-record MUST be a SIP URI or SIPS URI. Rosenberg, et. al. Standards Track [Page 57] RFC 3261 SIP: Session Initiation Protocol June 2002 From: The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a third- party registration. Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar. If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order. CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID. Contact: REGISTER requests MAY contain a Contact header field with zero or more values containing address bindings. UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out. Rosenberg, et. al. Standards Track [Page 58] RFC 3261 SIP: Session Initiation Protocol June 2002 bob +----+ | UA | | | +----+ | |3)INVITE | carol@chicago.com chicago.com +--------+ V +---------+ 2)Store|Location|4)Query +-----+ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com +---------+ +--------+=======>+-----+ A 5)Resp | | | | | 1)REGISTER| | | | +----+ | | UA |<-------------------------------+ cube2214a| | 6)INVITE +----+ carol@cube2214a.chicago.com carol Figure 2: REGISTER example The following Contact header parameters have a special meaning in REGISTER requests: action: The ""action"" parameter from RFC 2543 has been deprecated. UACs SHOULD NOT use the ""action"" parameter. expires: The ""expires"" parameter indicates how long the UA would like the binding to be valid. The value is a number indicating seconds. If this parameter is not provided, the value of the Expires header field is used instead. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. Malformed values SHOULD be treated as equivalent to 3600. 10.2.1 Adding Bindings The REGISTER request sent to a registrar includes the contact address(es) to which SIP requests for the address-of-record should be forwarded. The address-of-record is included in the To header field of the REGISTER request. Rosenberg, et. al. Standards Track [Page 59] RFC 3261 SIP: Session Initiation Protocol June 2002 The Contact header field values of the request typically consist of SIP or SIPS URIs that identify particular SIP endpoints (for example, ""sip:carol@cube2214a.chicago.com""), but they MAY use any URI scheme. A SIP UA can choose to register telephone numbers (with the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as Contacts for an address-of-record, for example. For example, Carol, with address-of-record ""sip:carol@chicago.com"", would register with the SIP registrar of the domain chicago.com. Her registrations would then be used by a proxy server in the chicago.com domain to route requests for Carol's address-of-record to her SIP endpoint. Once a client has established bindings at a registrar, it MAY send subsequent registrations containing new bindings or modifications to existing bindings as necessary. The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar. If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS. Registrations do not need to update all bindings. Typically, a UA only updates its own contact addresses. 10.2.1.1 Setting the Expiration Interval of Contact Addresses When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like the registration to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local policy.) There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an ""expires"" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the ""expires"" parameter. Rosenberg, et. al. Standards Track [Page 60] RFC 3261 SIP: Session Initiation Protocol June 2002 If neither mechanism for expressing a suggested expiration time is present in a REGISTER, the client is indicating its desire for the server to choose. 10.2.1.2 Preferences among Contact Addresses If more than one Contact is sent in a REGISTER request, the registering UA intends to associate all of the URIs in these Contact header field values with the address-of-record present in the To field. This list can be prioritized with the ""q"" parameter in the Contact header field. The ""q"" parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record. Section 16.6 describes how a proxy server uses this preference indication. 10.2.2 Removing Bindings Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar as described in Section 10.2.1. A UA requests the immediate removal of a binding by specifying an expiration interval of ""0"" for that contact address in a REGISTER request. UAs SHOULD support this mechanism so that bindings can be removed before their expiration interval has passed. The REGISTER-specific Contact header field value of ""*"" applies to all registrations, but it MUST NOT be used unless the Expires header field is present with a value of ""0"". Use of the ""*"" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values. 10.2.3 Fetching Bindings A success response to any REGISTER request contains the complete list of existing bindings, regardless of whether the request contained a Contact header field. If no Contact header field is present in a REGISTER request, the list of bindings is left unchanged. 10.2.4 Refreshing Bindings Each UA is responsible for refreshing the bindings that it has previously established. A UA SHOULD NOT refresh bindings set up by other UAs. Rosenberg, et. al. Standards Track [Page 61] RFC 3261 SIP: Session Initiation Protocol June 2002 The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request. A UA SHOULD use the same Call-ID for all registrations during a single boot cycle. Registration refreshes SHOULD be sent to the same network address as the original registration, unless redirected. 10.2.5 Setting the Internal Clock If the response for a REGISTER request contains a Date header field, the client MAY use this header field to learn the current time in order to set any internal clocks. 10.2.6 Discovering a Registrar UAs can use three ways to determine the address to which to send registrations: by configuration, using the address-of-record, and multicast. A UA can be configured, in ways beyond the scope of this specification, with a registrar address. If there is no configured registrar address, the UA SHOULD use the host part of the address- of-record as the Request-URI and address the request there, using the normal SIP server location mechanisms [4]. For example, the UA for the user ""sip:carol@chicago.com"" addresses the REGISTER request to ""sip:chicago.com"". Finally, a UA can be configured to use multicast. Multicast registrations are addressed to the well-known ""all SIP servers"" multicast address ""sip.mcast.net"" (224.0.1.75 for IPv4). No well- known IPv6 multicast address has been allocated; such an allocation will be documented separately when needed. SIP UAs MAY listen to that address and use it to become aware of the location of other local users (see [33]); however, they do not respond to the request. Multicast registration may be inappropriate in some environments, for example, if multiple businesses share the same local area network. 10.2.7 Transmitting a Request Once the REGISTER method has been constructed, and the destination of the message identified, UACs follow the procedures described in Section 8.1.2 to hand off the REGISTER to the transaction layer. Rosenberg, et. al. Standards Track [Page 62] RFC 3261 SIP: Session Initiation Protocol June 2002 If the transaction layer returns a timeout error because the REGISTER yielded no response, the UAC SHOULD NOT immediately re-attempt a registration to the same registrar. An immediate re-attempt is likely to also timeout. Waiting some reasonable time interval for the conditions causing the timeout to be corrected reduces unnecessary load on the network. No specific interval is mandated. 10.2.8 Error Responses If a UA receives a 423 (Interval Too Brief) response, it MAY retry the registration after making the expiration interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval within the Min-Expires header field of the 423 (Interval Too Brief) response. 10.3 Processing REGISTER Requests A registrar is a UAS that responds to REGISTER requests and maintains a list of bindings that are accessible to proxy servers and redirect servers within its administrative domain. A registrar handles requests according to Section 8.2 and Section 17.2, but it accepts only REGISTER requests. A registrar MUST not generate 6xx responses. A registrar MAY redirect REGISTER requests as appropriate. One common usage would be for a registrar listening on a multicast interface to redirect multicast REGISTER requests to its own unicast interface with a 302 (Moved Temporarily) response. Registrars MUST ignore the Record-Route header field if it is included in a REGISTER request. Registrars MUST NOT include a Record-Route header field in any response to a REGISTER request. A registrar might receive a request that traversed a proxy which treats REGISTER as an unknown request and which added a Record- Route header field value. A registrar has to know (for example, through configuration) the set of domain(s) for which it maintains bindings. REGISTER requests MUST be processed by a registrar in the order that they are received. REGISTER requests MUST also be processed atomically, meaning that a particular REGISTER request is either processed completely or not at all. Each REGISTER message MUST be processed independently of any other registration or binding changes. Rosenberg, et. al. Standards Track [Page 63] RFC 3261 SIP: Session Initiation Protocol June 2002 When receiving a REGISTER request, a registrar follows these steps: 1. The registrar inspects the Request-URI to determine whether it has access to bindings for the domain identified in the Request-URI. If not, and if the server also acts as a proxy server, the server SHOULD forward the request to the addressed domain, following the general behavior for proxying messages described in Section 16. 2. To guarantee that the registrar supports any necessary extensions, the registrar MUST process the Require header field values as described for UASs in Section 8.2.2. 3. A registrar SHOULD authenticate the UAC. Mechanisms for the authentication of SIP user agents are described in Section 22. Registration behavior in no way overrides the generic authentication framework for SIP. If no authentication mechanism is available, the registrar MAY take the From address as the asserted identity of the originator of the request. 4. The registrar SHOULD determine if the authenticated user is authorized to modify registrations for this address-of-record. For example, a registrar might consult an authorization database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings. If the authenticated user is not authorized to modify bindings, the registrar MUST return a 403 (Forbidden) and skip the remaining steps. In architectures that support third-party registration, one entity may be responsible for updating the registrations associated with multiple addresses-of-record. 5. The registrar extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form. To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings. Rosenberg, et. al. Standards Track [Page 64] RFC 3261 SIP: Session Initiation Protocol June 2002 6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the Contact header field is present, the registrar checks if there is one Contact field value that contains the special value ""*"" and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (Invalid Request) and skip the remaining steps. If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise, the update MUST be aborted and the request fails. 7. The registrar now processes each contact address in the Contact header field in turn. For each address, it determines the expiration interval as follows: - If the field value has an ""expires"" parameter, that value MUST be taken as the requested expiration. - If there is no such parameter, but the request has an Expires header field, that value MUST be taken as the requested expiration. - If there is neither, a locally-configured default value MUST be taken as the requested expiration. The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of 423 (Interval Too Brief). This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. It then skips the remaining steps. Allowing the registrar to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreasing the likelihood of registrations going stale. The expiration interval of a registration is frequently used in the creation of services. An example is a follow-me service, where the user may only be available at a terminal for a brief period. Therefore, registrars should accept brief registrations; a request should only be rejected if the interval is so short that the refreshes would degrade registrar performance. Rosenberg, et. al. Standards Track [Page 65] RFC 3261 SIP: Session Initiation Protocol June 2002 For each address, the registrar then searches the list of current bindings using the URI comparison rules. If the binding does not exist, it is tentatively added. If the binding does exist, the registrar checks the Call-ID value. If the Call-ID value in the existing binding differs from the Call-ID value in the request, the binding MUST be removed if the expiration time is zero and updated otherwise. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails. This algorithm ensures that out-of-order requests from the same UA are ignored. Each binding record records the Call-ID and CSeq values from the request. The binding updates MUST be committed (that is, made visible to the proxy or redirect server) if and only if all binding updates and additions succeed. If any one of them fails (for example, because the back-end database commit failed), the request MUST fail with a 500 (Server Error) response and all tentative binding updates MUST be removed. 8. The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an ""expires"" parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field. 11 Querying for Capabilities The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without ""ringing"" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs MUST support the OPTIONS method. The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to the way a Request-URI is set for a REGISTER request. Rosenberg, et. al. Standards Track [Page 66] RFC 3261 SIP: Session Initiation Protocol June 2002 Alternatively, a server receiving an OPTIONS request with a Max- Forwards header field value of 0 MAY respond to the request regardless of the Request-URI. This behavior is common with HTTP/1.1. This behavior can be used as a ""traceroute"" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values. As is the case for general UA behavior, the transaction layer can return a timeout error if the OPTIONS yields no response. This may indicate that the target is unreachable and hence unavailable. An OPTIONS request MAY be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog. 11.1 Construction of OPTIONS Request An OPTIONS request is constructed using the standard rules for a SIP request as discussed in Section 8.1.1. A Contact header field MAY be present in an OPTIONS. An Accept header field SHOULD be included to indicate the type of message body the UAC wishes to receive in the response. Typically, this is set to a format that is used to describe the media capabilities of a UA, such as SDP (application/sdp). The response to an OPTIONS request is assumed to be scoped to the Request-URI in the original request. However, only when an OPTIONS is sent as part of an established dialog is it guaranteed that future requests will be received by the server that generated the OPTIONS response. Example OPTIONS request: OPTIONS sip:carol@chicago.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70 To: <sip:carol@chicago.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:alice@pc33.atlanta.com> Accept: application/sdp Content-Length: 0 Rosenberg, et. al. Standards Track [Page 67] RFC 3261 SIP: Session Initiation Protocol June 2002 11.2 Processing of OPTIONS Request The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. An OPTIONS request received within a dialog generates a 200 (OK) response that is identical to one constructed outside a dialog and does not have any impact on the dialog. This use of OPTIONS has limitations due to the differences in proxy handling of OPTIONS and INVITE requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OPTIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE handling. See Section 16.7 for the normative details. If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server. The response does not contain a message body. Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is ambiguous since a proxy is method agnostic. Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present. A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). If the types include one that can describe media capabilities, the UAS SHOULD include a body in the response for that purpose. Details on the construction of such a body in the case of application/sdp are described in [13]. Rosenberg, et. al. Standards Track [Page 68] RFC 3261 SIP: Session Initiation Protocol June 2002 Example OPTIONS response generated by a UAS (corresponding to the request in Section 11.1): SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: <sip:carol@chicago.com>;tag=93810874 From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:carol@chicago.com> Contact: <mailto:carol@chicago.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Accept-Encoding: gzip Accept-Language: en Supported: foo Content-Type: application/sdp Content-Length: 274 (SDP not shown) 12 Dialogs A key concept for a user agent is that of a dialog. A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. Section 8 discussed method independent UA processing for requests and responses outside of a dialog. This section discusses how those requests and responses are used to construct a dialog, and then how subsequent requests and responses are sent within a dialog. A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag. The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of unique dialog IDs. A dialog ID is also associated with all responses and with any request that contains a tag in the To field. The rules for computing the dialog ID of a message depend on whether the SIP element is a UAC or UAS. For a UAC, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the To field of the message, and the local tag is set to the tag in the From Rosenberg, et. al. Standards Track [Page 69] RFC 3261 SIP: Session Initiation Protocol June 2002 field of the message (these rules apply to both requests and responses). As one would expect for a UAS, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the From field of the message, and the local tag is set to the tag in the To field of the message. A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called ""secure"", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer. A dialog can also be in the ""early"" state, which occurs when it is created with a provisional response, and then transition to the ""confirmed"" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates. 12.1 Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the ""early"" state and it is called an early dialog. Extensions MAY define other means for creating dialogs. Section 13 gives more details that are specific to the INVITE method. Here, we describe the process for creation of dialog state that is not dependent on the method. UAs MUST assign values to the dialog ID components as described below. 12.1.1 UAS behavior When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE). Generally, the host portion of this URI is the IP address or FQDN of the host. The URI provided in the Contact header field MUST be a SIP or SIPS URI. If the request that initiated the dialog contained a Rosenberg, et. al. Standards Track [Page 70] RFC 3261 SIP: Session Initiation Protocol June 2002 SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI. The URI SHOULD have global scope (that is, the same URI can be used in messages outside this dialog). The same way, the scope of the URI in the Contact header field of the INVITE is not limited to this dialog either. It can therefore be used in messages to the UAC even outside this dialog. The UAS then constructs the state of the dialog. This state MUST be maintained for the duration of the dialog. If the request arrived over TLS, and the Request-URI contained a SIPS URI, the ""secure"" flag is set to TRUE. The route set MUST be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters. If no Record-Route header field is present in the request, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the request. The remote sequence number MUST be set to the value of the sequence number in the CSeq header field of the request. The local sequence number MUST be empty. The call identifier component of the dialog ID MUST be set to the value of the Call-ID in the request. The local tag component of the dialog ID MUST be set to the tag in the To field in the response to the request (which always includes a tag), and the remote tag component of the dialog ID MUST be set to the tag from the From field in the request. A UAS MUST be prepared to receive a request without a tag in the From field, in which case the tag is considered to have a value of null. This is to maintain backwards compatibility with RFC 2543, which did not mandate From tags. The remote URI MUST be set to the URI in the From field, and the local URI MUST be set to the URI in the To field. 12.1.2 UAC Behavior When a UAC sends a request that can establish a dialog (such as an INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., the same SIP URI can be used in messages outside this dialog) in the Contact header field of the request. If the request has a Request- URI or a topmost Route header field value with a SIPS URI, the Contact header field MUST contain a SIPS URI. Rosenberg, et. al. Standards Track [Page 71] RFC 3261 SIP: Session Initiation Protocol June 2002 When a UAC receives a response that establishes a dialog, it constructs the state of the dialog. This state MUST be maintained for the duration of the dialog. If the request was sent over TLS, and the Request-URI contained a SIPS URI, the ""secure"" flag is set to TRUE. The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response. The local sequence number MUST be set to the value of the sequence number in the CSeq header field of the request. The remote sequence number MUST be empty (it is established when the remote UA sends a request within the dialog). The call identifier component of the dialog ID MUST be set to the value of the Call-ID in the request. The local tag component of the dialog ID MUST be set to the tag in the From field in the request, and the remote tag component of the dialog ID MUST be set to the tag in the To field of the response. A UAC MUST be prepared to receive a response without a tag in the To field, in which case the tag is considered to have a value of null. This is to maintain backwards compatibility with RFC 2543, which did not mandate To tags. The remote URI MUST be set to the URI in the To field, and the local URI MUST be set to the URI in the From field. 12.2 Requests within a Dialog Once a dialog has been established between two UAs, either of them MAY initiate new transactions as needed within the dialog. The UA sending the request will take the UAC role for the transaction. The UA receiving the request will take the UAS role. Note that these may be different roles than the UAs held during the transaction that established the dialog. Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an Rosenberg, et. al. Standards Track [Page 72] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. Note that an ACK is NOT a target refresh request. Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems. 12.2.1 UAC Behavior 12.2.1.1 Generating the Request A request within a dialog is constructed by using many of the components of the state stored as part of the dialog. The URI in the To field of the request MUST be set to the remote URI from the dialog state. The tag in the To header field of the request MUST be set to the remote tag of the dialog ID. The From URI of the request MUST be set to the local URI from the dialog state. The tag in the From header field of the request MUST be set to the local tag of the dialog ID. If the value of the remote or local tags is null, the tag parameter MUST be omitted from the To or From header fields, respectively. Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification. The Call-ID of the request MUST be set to the Call-ID of the dialog. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled)."
"Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. If the local sequence number is empty, an initial value MUST be chosen using the guidelines of Section 8.1.1.5. The method field in the CSeq header field value MUST match the method of the request. Rosenberg, et. al. Standards Track [Page 73] RFC 3261 SIP: Session Initiation Protocol June 2002 With a length of 32 bits, a client could generate, within a single call, one request a second for about 136 years before needing to wrap around. The initial value of the sequence number is chosen so that subsequent requests within the same call will not wrap around. A non-zero initial value allows clients to use a time- based initial sequence number. A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial sequence number. The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request. If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the remote target URI into the Route header field as the last value. For example, if the remote target is sip:user@remoteua and the route set contains: <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> The request will be formed with the following Request-URI and Route header field: METHOD sip:proxy1 Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> If the first URI of the route set does not contain the lr parameter, the proxy indicated does not understand the routing mechanisms described in this document and will act as specified in RFC 2543, replacing the Request-URI with the first Route header field value it receives while forwarding the message. Placing the Request-URI at the end of the Route header field preserves the Rosenberg, et. al. Standards Track [Page 74] RFC 3261 SIP: Session Initiation Protocol June 2002 information in that Request-URI across the strict router (it will be returned to the Request-URI when the request reaches a loose- router). A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. If the ""secure"" flag is true, that URI MUST be a SIPS URI. As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact address, should its address change during the duration of the dialog. However, requests that are not target refresh requests do not affect the remote target URI for the dialog. The rest of the request is formed as described in Section 8.1.1. Once the request has been constructed, the address of the server is computed and the request is sent, using the same procedures for requests outside of a dialog (Section 8.1.2). The procedures in Section 8.1.2 will normally result in the request being sent to the address indicated by the topmost Route header field value or the Request-URI if no Route header field is present. Subject to certain restrictions, they allow the request to be sent to an alternate address (such as a default outbound proxy not represented in the route set). 12.2.1.2 Processing the Responses The UAC will receive responses to the request from the transaction layer. If the client transaction returns a timeout, this is treated as a 408 (Request Timeout) response. The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a dialog. This behavior is described in Section 8.1.3.4. Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the Route header of the request. When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present. Rosenberg, et. al. Standards Track [Page 75] RFC 3261 SIP: Session Initiation Protocol June 2002 If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.) For INVITE initiated dialogs, terminating the dialog consists of sending a BYE. 12.2.2 UAS Behavior Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed. Note that some requests, such as INVITEs, affect several pieces of state. The UAS will receive the request from the transaction layer. If the request has a tag in the To header field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing dialogs. If there is a match, this is a mid-dialog request. In that case, the UAS first applies the same processing rules for requests outside of a dialog, discussed in Section 8.2. If the request has a tag in the To header field, but the dialog identifier does not match any existing dialogs, the UAS may have crashed and restarted, or it may have received a request for a different (possibly failed) UAS (the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS for which it is providing recovery). Another possibility is that the incoming request has been simply misrouted. Based on the To tag, the UAS MAY either accept or reject the request. Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers. If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction. Rosenberg, et. al. Standards Track [Page 76] RFC 3261 SIP: Session Initiation Protocol June 2002 Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog. If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request. If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition. When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that request, if present. 12.3 Termination of a Dialog Independent of the method, if a request outside of a dialog generates a non-2xx final response, any early dialogs created through provisional responses to that request are terminated. The mechanism for terminating confirmed dialogs is method specific. In this specification, the BYE method terminates a session and the dialog associated with it. See Section 15 for details. 13 Initiating a Session 13.1 Overview When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. The INVITE request asks a server to establish a session. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation. These UASs will frequently need to query the user about whether to accept the Rosenberg, et. al. Standards Track [Page 77] RFC 3261 SIP: Session Initiation Protocol June 2002 invitation. After some time, those UASs can accept the invitation (meaning the session is to be established) by sending a 2xx response. If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the reason for the rejection. Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. Because of the protracted amount of time it can take to receive final responses to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests (like OPTIONS). Once it receives a final response, the UAC needs to send an ACK for every final response it receives. The procedure for sending this ACK depends on the type of response. For final responses between 300 and 699, the ACK processing is done in the transaction layer and follows one set of rules (See Section 17). For 2xx responses, the ACK is generated by the UAC core. A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response. Therefore, when multiple 2xx responses are received from different remote UAs (because the INVITE forked), each 2xx establishes a different dialog. All these dialogs are part of the same call. This section provides details on the establishment of a session using INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and BYE. 13.2 UAC Processing 13.2.1 Creating the Initial INVITE Since the initial INVITE represents a request outside of a dialog, its construction follows the procedures of Section 8.1.1. Additional processing is required for the specific case of INVITE. An Allow header field (Section 20.5) SHOULD be present in the INVITE. It indicates what methods can be invoked within a dialog, on the UA sending the INVITE, for the duration of the dialog. For example, a UA capable of receiving INFO requests within a dialog [34] SHOULD include an Allow header field listing the INFO method. A Supported header field (Section 20.37) SHOULD be present in the INVITE. It enumerates all the extensions understood by the UAC. Rosenberg, et. al. Standards Track [Page 78] RFC 3261 SIP: Session Initiation Protocol June 2002 An Accept (Section 20.1) header field MAY be present in the INVITE. It indicates which Content-Types are acceptable to the UA, in both the response received by it, and in any subsequent requests sent to it within dialogs established by the INVITE. The Accept header field is especially useful for indicating support of various session description formats. The UAC MAY add an Expires header field (Section 20.19) to limit the validity of the invitation. If the time indicated in the Expires header field is reached and no final answer for the INVITE has been received, the UAC core SHOULD generate a CANCEL request for the INVITE, as per Section 9. A UAC MAY also find it useful to add, among others, Subject (Section 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) header fields. They all contain information related to the INVITE. The UAC MAY choose to add a message body to the INVITE. Section 8.1.1.10 deals with how to construct the header fields -- Content- Type among others -- needed to describe the message body. There are special rules for message bodies that contain a session description - their corresponding Content-Disposition is ""session"". SIP uses an offer/answer model where one UA sends a session description, called the offer, which contains a proposed description of the session. The offer indicates the desired communications means (audio, video, games), parameters of those means (such as codec types) and addresses for receiving media from the answerer. The other UA responds with another session description, called the answer, which indicates which communications means are accepted, the parameters that apply to those means, and addresses for receiving media from the offerer. An offer/answer exchange is within the context of a dialog, so that if a SIP INVITE results in multiple dialogs, each is a separate offer/answer exchange. The offer/answer model defines restrictions on when offers and answers can be made (for example, you cannot make a new offer while one is in progress). This results in restrictions on where the offers and answers can appear in SIP messages. In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The usage of offers and answers is further restricted. For the initial INVITE transaction, the rules are: o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response. Rosenberg, et. al. Standards Track [Page 79] RFC 3261 SIP: Session Initiation Protocol June 2002 o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. o If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer MUST be in the acknowledgement for that message (in this specification, ACK for a 2xx response). o After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer. o Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction. Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - the offer is in the INVITE, and the answer in the 2xx (and possibly in a 1xx as well, with the same value), or the offer is in the 2xx, and the answer is in the ACK. All user agents that support INVITE MUST support these two exchanges. The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be supported by all user agents as a means to describe sessions, and its usage for constructing offers and answers MUST follow the procedures defined in [13]. The restrictions of the offer-answer model just described only apply to bodies whose Content-Disposition header field value is ""session"". Therefore, it is possible that both the INVITE and the ACK contain a body message (for example, the INVITE carries a photo (Content- Disposition: render) and the ACK a session description (Content- Disposition: session)). If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition ""session"", while other content types imply ""render"". Rosenberg, et. al. Standards Track [Page 80] RFC 3261 SIP: Session Initiation Protocol June 2002 Once the INVITE has been created, the UAC follows the procedures defined for sending requests outside of a dialog (Section 8). This results in the construction of a client transaction that will ultimately send the request and deliver responses to the UAC. 13.2.2 Processing INVITE Responses Once the INVITE has been passed to the INVITE client transaction, the UAC waits for responses for the INVITE. If the INVITE client transaction returns a timeout rather than a response the TU acts as if a 408 (Request Timeout) response had been received, as described in Section 8.1.3. 13.2.2.1 1xx Responses Zero, one or multiple provisional responses may arrive before one or more final responses are received. Provisional responses for an INVITE request can create ""early dialogs"". If a provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing dialog, one is constructed using the procedures defined in Section 12.1.2. The early dialog will only be needed if the UAC needs to send a request to its peer within the dialog before the initial INVITE transaction completes. Header fields present in a provisional response are applicable as long as the dialog is in the early state (for example, an Allow header field in a provisional response contains the methods that can be used in the dialog while this is in the early state). 13.2.2.2 3xx Responses A 3xx response may contain one or more Contact header field values providing new addresses where the callee might be reachable. Depending on the status code of the 3xx response (see Section 21.3), the UAC MAY choose to try those new addresses. 13.2.2.3 4xx, 5xx and 6xx Responses A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final responses (which would only arrive under error conditions) MUST be ignored. All early dialogs are considered terminated upon reception of the non-2xx final response. Rosenberg, et. al. Standards Track [Page 81] RFC 3261 SIP: Session Initiation Protocol June 2002 After having received the non-2xx final response the UAC core considers the INVITE transaction completed. The INVITE client transaction handles the generation of ACKs for the response (see Section 17). 13.2.2.4 2xx Responses Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier. If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the ""confirmed"" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the ""confirmed"" state MUST be constructed using the procedures of Section 12.1.2. Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example. The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately. Once the ACK has been constructed, the procedures of [4] are used to determine the destination address, port and transport. However, the request is passed to the transport layer directly for transmission, rather than a client transaction. This is because the UAC core handles retransmissions of the ACK, not the transaction layer. The ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. Rosenberg, et. al. Standards Track [Page 82] RFC 3261 SIP: Session Initiation Protocol June 2002 The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive. If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that dialog, then the UAC MUST terminate the dialog by sending a BYE request as described in Section 15. 13.3 UAS Processing 13.3.1 Processing of the INVITE The UAS core will receive INVITE requests from the transaction layer. It first performs the request processing procedures of Section 8.2, which are applied for both requests inside and outside of a dialog. Assuming these processing states are completed without generating a response, the UAS core performs the additional processing steps: 1. If the request is an INVITE that contains an Expires header field, the UAS core sets a timer for the number of seconds indicated in the header field value. When the timer fires, the invitation is considered to be expired. If the invitation expires before the UAS has generated a final response, a 487 (Request Terminated) response SHOULD be generated. 2. If the request is a mid-dialog request, the method-independent processing described in Section 12.2.2 is first applied. It might also modify the session; Section 14 provides details. 3. If the request has a tag in the To header field but the dialog identifier does not match any of the existing dialogs, the UAS may have crashed and restarted, or may have received a request for a different (possibly failed) UAS. Section 12.2.2 provides guidelines to achieve a robust behavior under such a situation. Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes of establishing a new session. The INVITE may contain a session description, in which case the UAS is being presented with an offer for that session. It is possible that the user is already a participant in that session, even though the INVITE is outside of a dialog. This can happen when a user is invited to the same multicast conference by multiple other participants. If desired, the UAS MAY use identifiers within the session description to detect this duplication. For example, SDP Rosenberg, et. al. Standards Track [Page 83] RFC 3261 SIP: Session Initiation Protocol June 2002 contains a session id and version number in the origin (o) field. If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS MAY silently accept the INVITE (that is, send a 2xx response without prompting the user). If the INVITE does not contain a session description, the UAS is being asked to participate in a session, and the UAC has asked that the UAS provide the offer of the session. It MUST provide the offer in its first non-failure reliable message back to the UAC. In this specification, that is a 2xx response to the INVITE. The UAS can indicate progress, accept, redirect, or reject the invitation. In all of these cases, it formulates a response using the procedures described in Section 8.2.6. 13.3.1.1 Progress If the UAS is not able to answer the invitation immediately, it can choose to indicate some kind of progress to the UAC (for example, an indication that a phone is ringing). This is accomplished with a provisional response between 101 and 199. These provisional responses establish early dialogs and therefore follow the procedures of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY send as many provisional responses as it likes. Each of these MUST indicate the same dialog ID. However, these will not be delivered reliably. If the UAS desires an extended period of time to answer the INVITE, it will need to ask for an ""extension"" in order to prevent proxies from canceling the transaction. A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses. An INVITE transaction can go on for extended durations when the user is placed on hold, or when interworking with PSTN systems which allow communications to take place without answering the call. The latter is common in Interactive Voice Response (IVR) systems. 13.3.1.2 The INVITE is Redirected If the UAS decides to redirect the call, a 3xx response is sent. A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response SHOULD contain a Contact header field Rosenberg, et. al. Standards Track [Page 84] RFC 3261 SIP: Session Initiation Protocol June 2002 containing one or more URIs of new addresses to be tried. The response is passed to the INVITE server transaction, which will deal with its retransmissions. 13.3.1.3 The INVITE is Rejected A common scenario occurs when the callee is currently not willing or able to take additional calls at this end system. A 486 (Busy Here) SHOULD be returned in such a scenario. If the UAS knows that no other end system will be able to accept this call, a 600 (Busy Everywhere) response SHOULD be sent instead. However, it is unlikely that a UAS will be able to know this in general, and thus this response will not usually be used. The response is passed to the INVITE server transaction, which will deal with its retransmissions. A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected. 13.3.1.4 The INVITE is Accepted The UAS core generates a 2xx response. This response establishes a dialog, and therefore follows the procedures of Section 12.1.1 in addition to those of Section 8.2.6. A 2xx response to an INVITE SHOULD contain the Allow header field and the Supported header field, and MAY contain the Accept header field. Including these header fields allows the UAC to determine the features and extensions supported by the UAS for the duration of the call, without probing. If the INVITE request contained an offer, and the UAS had not yet sent an answer, the 2xx MUST contain an answer. If the INVITE did not contain an offer, the 2xx MUST contain an offer if the UAS had not yet sent an offer. Once the response has been constructed, it is passed to the INVITE server transaction. Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received. This is independent of whatever transport protocols are used to send the response. Rosenberg, et. al. Standards Track [Page 85] RFC 3261 SIP: Session Initiation Protocol June 2002 Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. 14 Modifying an Existing Session A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a session using the offer-answer model. Section 12 explains how to modify an existing dialog using a target refresh request (for example, changing the remote target URI of the dialog). This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE. Note that a single re-INVITE can modify the dialog and the parameters of the session at the same time. Either the caller or callee can modify an existing session. The behavior of a UA on detection of media failure is a matter of local policy. However, automated generation of re-INVITE or BYE is NOT RECOMMENDED to avoid flooding the network with traffic when there is congestion. In any case, if these messages are sent automatically, they SHOULD be sent after some randomized interval. Note that the paragraph above refers to automatically generated BYEs and re-INVITEs. If the user hangs up upon media failure, the UA would send a BYE request as usual. 14.1 UAC Behavior The same offer-answer model that applies to session descriptions in INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC that wants to add a media stream, for example, will create a new offer that contains this media stream, and send that in an INVITE request to its peer. It is important to note that the full description of the session, not just the change, is sent. This supports stateless session processing in various elements, and supports failover and recovery capabilities. Of course, a UAC MAY Rosenberg, et. al. Standards Track [Page 86] RFC 3261 SIP: Session Initiation Protocol June 2002 send a re-INVITE with no session description, in which case the first reliable non-failure response to the re-INVITE will contain the offer (in this specification, that is a 2xx response). If the session description format has the capability for version numbers, the offerer SHOULD indicate that the version of the session description has changed. The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set following the same rules as for regular requests within an existing dialog, described in Section 12. A UAC MAY choose not to add an Alert-Info header field or a body with Content-Disposition ""alert"" to re-INVITEs because UASs do not typically alert the user upon reception of a re-INVITE. Unlike an INVITE, which can fork, a re-INVITE will never fork, and therefore, only ever generate a single final response. The reason a re-INVITE will never fork is that the Request-URI identifies the target as the UA instance it established the dialog with, rather than identifying an address-of-record for the user. Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. 1. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE. 2. If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE. However, a UA MAY initiate a regular transaction while an INVITE transaction is in progress. A UA MAY also initiate an INVITE transaction while a regular transaction is in progress. If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued. Note that, as stated in Section 12.2.1.2, if the non-2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is received for the re- INVITE (that is, a timeout is returned by the INVITE client transaction), the UAC will terminate the dialog. Rosenberg, et. al. Standards Track [Page 87] RFC 3261 SIP: Session Initiation Protocol June 2002 If a UAC receives a 491 response to a re-INVITE, it SHOULD start a timer with a value T chosen as follows: 1. If the UAC is the owner of the Call-ID of the dialog ID (meaning it generated the value), T has a randomly chosen value between 2.1 and 4 seconds in units of 10 ms. 2. If the UAC is not the owner of the Call-ID of the dialog ID, T has a randomly chosen value of between 0 and 2 seconds in units of 10 ms. When the timer fires, the UAC SHOULD attempt the re-INVITE once more, if it still desires for that session modification to take place. For example, if the call was already hung up with a BYE, the re-INVITE would not take place. The rules for transmitting a re-INVITE and for generating an ACK for a 2xx response to re-INVITE are the same as for the initial INVITE (Section 13.2.1). 14.2 UAS Behavior Section 13.3.1 describes the procedure for distinguishing incoming re-INVITEs from incoming initial INVITEs and handling a re-INVITE for an existing dialog. A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received INVITE. If a UA receives a re-INVITE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly, possibly after asking the user for confirmation. Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference, add or delete media, or change from a unicast to a multicast conference. Rosenberg, et. al. Standards Track [Page 88] RFC 3261 SIP: Session Initiation Protocol June 2002 If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response for the re- INVITE. This response SHOULD include a Warning header field. If a UAS generates a 2xx response and never receives an ACK, it SHOULD generate a BYE to terminate the dialog. A UAS MAY choose not to generate 180 (Ringing) responses for a re- INVITE because UACs do not typically render this information to the user."
"For the same reason, UASs MAY choose not to use an Alert-Info header field or a body with Content-Disposition ""alert"" in responses to a re-INVITE. A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session. 15 Terminating a Session This section describes the procedures for terminating a session established by SIP. The state of the session and the state of the dialog are very closely related. When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, it also creates a session. As a result, each session is ""associated"" with a single dialog - the one which resulted in its creation. If an initial INVITE generates a non-2xx final response, that terminates all sessions (if any) and all dialogs (if any) that were created through responses to the request. By virtue of completing the transaction, a non-2xx final response also prevents further sessions from being created as a result of the INVITE. The BYE request is used to terminate a specific session or attempted session. In this case, the specific session is the one with the peer UA on the other side of the dialog. When a BYE is received on a dialog, any session associated with that dialog SHOULD terminate. A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs. Rosenberg, et. al. Standards Track [Page 89] RFC 3261 SIP: Session Initiation Protocol June 2002 However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out. If no SIP extensions have defined other application layer states associated with the dialog, the BYE also terminates the dialog. The impact of a non-2xx final response to INVITE on dialogs and sessions makes the use of CANCEL attractive. The CANCEL attempts to force a non-2xx response to the INVITE (in particular, a 487). Therefore, if a UAC wishes to give up on its call attempt entirely, it can send a CANCEL. If the INVITE results in 2xx final response(s) to the INVITE, this means that a UAS accepted the invitation while the CANCEL was in progress. The UAC MAY continue with the sessions established by any 2xx responses, or MAY terminate them with BYE. The notion of ""hanging up"" is not well defined within SIP. It is specific to a particular, albeit common, user interface. Typically, when the user hangs up, it indicates a desire to terminate the attempt to establish a session, and to terminate any sessions already created. For the caller's UA, this would imply a CANCEL request if the initial INVITE has not generated a final response, and a BYE to all confirmed dialogs after a final response. For the callee's UA, it would typically imply a BYE; presumably, when the user picked up the phone, a 2xx was generated, and so hanging up would result in a BYE after the ACK is received. This does not mean a user cannot hang up before receipt of the ACK, it just means that the software in his phone needs to maintain state for a short while in order to clean up properly. If the particular UI allows for the user to reject a call before its answered, a 403 (Forbidden) is a good way to express that. As per the rules above, a BYE can't be sent. 15.1 Terminating a Session with a BYE Request 15.1.1 UAC Behavior A BYE request is constructed as would any other request within a dialog, as described in Section 12. Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no Rosenberg, et. al. Standards Track [Page 90] RFC 3261 SIP: Session Initiation Protocol June 2002 response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated. 15.1.2 UAS Behavior A UAS first processes the BYE request according to the general UAS processing described in Section 8.2. A UAS core receiving a BYE request checks if it matches an existing dialog. If the BYE does not match an existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction Does Not Exist) response and pass that to the server transaction. This rule means that a BYE sent without tags by a UAC will be rejected. This is a change from RFC 2543, which allowed BYE without tags. A UAS core receiving a BYE request for an existing dialog MUST follow the procedures of Section 12.2.2 to process the request. Once done, the UAS SHOULD terminate the session (and therefore stop sending and listening for media). The only case where it can elect not to are multicast sessions, where participation is possible even if the other participant in the dialog has terminated its involvement in the session. Whether or not it ends its participation on the session, the UAS core MUST generate a 2xx response to the BYE, and MUST pass that to the server transaction for transmission. The UAS MUST still respond to any pending requests received for that dialog. It is RECOMMENDED that a 487 (Request Terminated) response be generated to those pending requests. 16 Proxy Behavior 16.1 Overview SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients. A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying the request before forwarding it to the next element. Responses will route through the same set of proxies traversed by the request in the reverse order. Being a proxy is a logical role for a SIP element. When a request arrives, an element that can play the role of a proxy first decides if it needs to respond to the request on its own. For instance, the request may be malformed or the element may need credentials from the client before acting as a proxy. The element MAY respond with any Rosenberg, et. al. Standards Track [Page 91] RFC 3261 SIP: Session Initiation Protocol June 2002 appropriate error code. When responding directly to a request, the element is playing the role of a UAS and MUST behave as described in Section 8.2. A proxy can operate in either a stateful or stateless mode for each new request. When stateless, a proxy acts as a simple forwarding element. It forwards each request downstream to a single element determined by making a targeting and routing decision based on the request. It simply forwards every response it receives upstream. A stateless proxy discards information about a message once the message has been forwarded. A stateful proxy remembers information (specifically, transaction state) about each incoming request and any requests it sends as a result of processing the incoming request. It uses this information to affect the processing of future messages associated with that request. A stateful proxy MAY choose to ""fork"" a request, routing it to multiple destinations. Any request that is forwarded to more than one location MUST be handled statefully. In some circumstances, a proxy MAY forward requests using stateful transports (such as TCP) without being transaction-stateful. For instance, a proxy MAY forward a request from one TCP connection to another transaction statelessly as long as it places enough information in the message to be able to forward the response down the same connection the request arrived on. Requests forwarded between different types of transports where the proxy's TU must take an active role in ensuring reliable delivery on one of the transports MUST be forwarded transaction statefully. A stateful proxy MAY transition to stateless operation at any time during the processing of a request, so long as it did not do anything that would otherwise prevent it from being stateless initially (forking, for example, or generation of a 100 response). When performing such a transition, all state is simply discarded. The proxy SHOULD NOT initiate a CANCEL request. Much of the processing involved when acting statelessly or statefully for a request is identical. The next several subsections are written from the point of view of a stateful proxy. The last section calls out those places where a stateless proxy behaves differently. 16.2 Stateful Proxy When stateful, a proxy is purely a SIP transaction processing engine. Its behavior is modeled here in terms of the server and client transactions defined in Section 17. A stateful proxy has a server transaction associated with one or more client transactions by a higher layer proxy processing component (see figure 3), known as a proxy core. An incoming request is processed by a server Rosenberg, et. al. Standards Track [Page 92] RFC 3261 SIP: Session Initiation Protocol June 2002 transaction. Requests from the server transaction are passed to a proxy core. The proxy core determines where to route the request, choosing one or more next-hop locations. An outgoing request for each next-hop location is processed by its own associated client transaction. The proxy core collects the responses from the client transactions and uses them to send responses to the server transaction. A stateful proxy creates a new server transaction for each new request received. Any retransmissions of the request will then be handled by that server transaction per Section 17. The proxy core MUST behave as a UAS with respect to sending an immediate provisional on that server transaction (such as 100 Trying) as described in Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 (Trying) responses to non-INVITE requests. This is a model of proxy behavior, not of software. An implementation is free to take any approach that replicates the external behavior this model defines. For all new requests, including any with unknown methods, an element intending to proxy the request MUST: 1. Validate the request (Section 16.3) 2. Preprocess routing information (Section 16.4) 3. Determine target(s) for the request (Section 16.5) +--------------------+ | | +---+ | | | C | | | | T | | | +---+ +---+ | Proxy | +---+ CT = Client Transaction | S | | ""Higher"" Layer | | C | | T | | | | T | ST = Server Transaction +---+ | | +---+ | | +---+ | | | C | | | | T | | | +---+ +--------------------+ Figure 3: Stateful Proxy Model Rosenberg, et. al. Standards Track [Page 93] RFC 3261 SIP: Session Initiation Protocol June 2002 4. Forward the request to each target (Section 16.6) 5. Process all responses (Section 16.7) 16.3 Request Validation Before an element can proxy a request, it MUST verify the message's validity. A valid message must pass the following checks: 1. Reasonable Syntax 2. URI scheme 3. Max-Forwards 4. (Optional) Loop Detection 5. Proxy-Require 6. Proxy-Authorization If any of these checks fail, the element MUST behave as a user agent server (see Section 8.2) and respond with an error code. Notice that a proxy is not required to detect merged requests and MUST NOT treat merged requests as an error condition. The endpoints receiving the requests will resolve the merge as described in Section 8.2.2.2. 1. Reasonable syntax check The request MUST be well-formed enough to be handled with a server transaction. Any components involved in the remainder of these Request Validation steps or the Request Forwarding section MUST be well-formed. Any other components, well-formed or not, SHOULD be ignored and remain unchanged when the message is forwarded. For instance, an element would not reject a request because of a malformed Date header field. Likewise, a proxy would not remove a malformed Date header field before forwarding a request. This protocol is designed to be extended. Future extensions may define new methods and header fields at any time. An element MUST NOT refuse to proxy a request because it contains a method or header field it does not know about. Rosenberg, et. al. Standards Track [Page 94] RFC 3261 SIP: Session Initiation Protocol June 2002 2. URI scheme check If the Request-URI has a URI whose scheme is not understood by the proxy, the proxy SHOULD reject the request with a 416 (Unsupported URI Scheme) response. 3. Max-Forwards check The Max-Forwards header field (Section 20.22) is used to limit the number of elements a SIP request can traverse. If the request does not contain a Max-Forwards header field, this check is passed. If the request contains a Max-Forwards header field with a field value greater than zero, the check is passed. If the request contains a Max-Forwards header field with a field value of zero (0), the element MUST NOT forward the request. If the request was for OPTIONS, the element MAY act as the final recipient and respond per Section 11. Otherwise, the element MUST return a 483 (Too many hops) response. 4. Optional Loop Detection check An element MAY check for forwarding loops before forwarding a request. If the request contains a Via header field with a sent- by value that equals a value placed into previous requests by the proxy, the request has been forwarded by this element before. The request has either looped or is legitimately spiraling through the element. To determine if the request has looped, the element MAY perform the branch parameter calculation described in Step 8 of Section 16.6 on this message and compare it to the parameter received in that Via header field. If the parameters match, the request has looped. If they differ, the request is spiraling, and processing continues. If a loop is detected, the element MAY return a 482 (Loop Detected) response. 5. Proxy-Require check Future extensions to this protocol may introduce features that require special handling by proxies. Endpoints will include a Proxy-Require header field in requests that use these features, telling the proxy not to process the request unless the feature is understood. Rosenberg, et. al. Standards Track [Page 95] RFC 3261 SIP: Session Initiation Protocol June 2002 If the request contains a Proxy-Require header field (Section 20.29) with one or more option-tags this element does not understand, the element MUST return a 420 (Bad Extension) response. The response MUST include an Unsupported (Section 20.40) header field listing those option-tags the element did not understand. 6. Proxy-Authorization check If an element requires credentials before forwarding a request, the request MUST be inspected as described in Section 22.3. That section also defines what the element must do if the inspection fails. 16.4 Route Information Preprocessing The proxy MUST inspect the Request-URI of the request. If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request. This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see Section 12.2.1.1). This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear. If the Request-URI contains a maddr parameter, the proxy MUST check to see if its value is in the set of addresses or domains the proxy is configured to be responsible for. If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated (explicitly or by default) in the Request-URI, the proxy MUST strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request. Rosenberg, et. al. Standards Track [Page 96] RFC 3261 SIP: Session Initiation Protocol June 2002 A request may arrive with a maddr matching the proxy, but on a port or transport different from that indicated in the URI. Such a request needs to be forwarded to the proxy using the indicated port and transport. If the first value in the Route header field indicates this proxy, the proxy MUST remove that value from the request. 16.5 Determining Request Targets Next, the proxy calculates the target(s) of the request. The set of targets will either be predetermined by the contents of the request or will be obtained from an abstract location service. Each target in the set is represented as a URI. If the Request-URI of the request contains an maddr parameter, the Request-URI MUST be placed into the target set as the only target URI, and the proxy MUST proceed to Section 16.6. If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6). There are many circumstances in which a proxy might receive a request for a domain it is not responsible for. A firewall proxy handling outgoing calls (the way HTTP proxies handle outgoing requests) is an example of where this is likely to occur. If the target set for the request has not been predetermined as described above, this implies that the element is responsible for the domain in the Request-URI, and the element MAY use whatever mechanism it desires to determine where to send the request. Any of these mechanisms can be modeled as accessing an abstract Location Service. This may consist of obtaining information from a location service created by a SIP Registrar, reading a database, consulting a presence server, utilizing other protocols, or simply performing an algorithmic substitution on the Request-URI. When accessing the location service constructed by a registrar, the Request-URI MUST first be canonicalized as described in Section 10.3 before being used as an index. The output of these mechanisms is used to construct the target set. If the Request-URI does not provide sufficient information for the proxy to determine the target set, it SHOULD return a 485 (Ambiguous) response. This response SHOULD contain a Contact header field containing URIs of new addresses to be tried. For example, an INVITE Rosenberg, et. al. Standards Track [Page 97] RFC 3261 SIP: Session Initiation Protocol June 2002 to sip:John.Smith@company.com may be ambiguous at a proxy whose location service has multiple John Smiths listed. See Section 21.4.23 for details. Any information in or about the request or the current environment of the element MAY be used in the construction of the target set. For instance, different sets may be constructed depending on contents or the presence of header fields and bodies, the time of day of the request's arrival, the interface on which the request arrived, failure of previous requests, or even the element's current level of utilization. As potential targets are located through these services, their URIs are added to the target set. Targets can only be placed in the target set once. If a target URI is already present in the set (based on the definition of equality for the URI type), it MUST NOT be added again. A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for. A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. If the proxy is not responsible for that URI, it will not recurse on 3xx or 416 responses as described below. If the Request-URI of the original request indicates a resource this proxy is responsible for, the proxy MAY continue to add targets to the set after beginning Request Forwarding. It MAY use any information obtained during that processing to determine new targets. For instance, a proxy may choose to incorporate contacts obtained in a redirect response (3xx) into the target set. If a proxy uses a dynamic source of information while building the target set (for instance, if it consults a SIP Registrar), it SHOULD monitor that source for the duration of processing the request. New locations SHOULD be added to the target set as they become available. As above, any given URI MUST NOT be added to the set more than once. Allowing a URI to be added to the set only once reduces unnecessary network traffic, and in the case of incorporating contacts from redirect requests prevents infinite recursion. For example, a trivial location service is a ""no-op"", where the target URI is equal to the incoming request URI. The request is sent to a specific next hop proxy for further processing. During request Rosenberg, et. al. Standards Track [Page 98] RFC 3261 SIP: Session Initiation Protocol June 2002 forwarding of Section 16.6, Item 6, the identity of that next hop, expressed as a SIP or SIPS URI, is inserted as the top-most Route header field value into the request. If the Request-URI indicates a resource at this proxy that does not exist, the proxy MUST return a 404 (Not Found) response. If the target set remains empty after applying all of the above, the proxy MUST return an error response, which SHOULD be the 480 (Temporarily Unavailable) response. 16.6 Request Forwarding As soon as the target set is non-empty, a proxy MAY begin forwarding the request. A stateful proxy MAY process the set in any order. It MAY process multiple targets serially, allowing each client transaction to complete before starting the next. It MAY start client transactions with every target in parallel. It also MAY arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel. A common ordering mechanism is to use the qvalue parameter of targets obtained from Contact header fields (see Section 20.10). Targets are processed from highest qvalue to lowest. Targets with equal qvalues may be processed in parallel. A stateful proxy must have a mechanism to maintain the target set as responses are received and associate the responses to each forwarded request with the original request. For the purposes of this model, this mechanism is a ""response context"" created by the proxy layer before forwarding the first request. For each target, the proxy forwards the request following these steps: 1. Make a copy of the received request 2. Update the Request-URI 3. Update the Max-Forwards header field 4. Optionally add a Record-route header field value 5. Optionally add additional header fields 6. Postprocess routing information 7. Determine the next-hop address, port, and transport Rosenberg, et. al. Standards Track [Page 99] RFC 3261 SIP: Session Initiation Protocol June 2002 8. Add a Via header field value 9. Add a Content-Length header field if necessary 10. Forward the new request 11. Set timer C Each of these steps is detailed below: 1. Copy request The proxy starts with a copy of the received request. The copy MUST initially contain all of the header fields from the received request. Fields not detailed in the processing described below MUST NOT be removed. The copy SHOULD maintain the ordering of the header fields as in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1). The proxy MUST NOT add to, modify, or remove the message body. An actual implementation need not perform a copy; the primary requirement is that the processing for each next hop begin with the same request. 2. Request-URI The Request-URI in the copy's start line MUST be replaced with the URI for this target. If the URI contains any parameters not allowed in a Request-URI, they MUST be removed. This is the essence of a proxy's role. This is the mechanism through which a proxy routes a request toward its destination. In some circumstances, the received Request-URI is placed into the target set without being modified. For that target, the replacement above is effectively a no-op. 3. Max-Forwards If the copy contains a Max-Forwards header field, the proxy MUST decrement its value by one (1). If the copy does not contain a Max-Forwards header field, the proxy MUST add one with a field value, which SHOULD be 70. Some existing UAs will not provide a Max-Forwards header field in a request. Rosenberg, et. al. Standards Track [Page 100] RFC 3261 SIP: Session Initiation Protocol June 2002 4. Record-Route If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it MUST insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present. Requests establishing a dialog may contain a preloaded Route header field. If this request is already part of a dialog, the proxy SHOULD insert a Record-Route header field value if it wishes to remain on the path of future requests in the dialog. In normal endpoint operation as described in Section 12, these Record- Route header field values will not have any effect on the route sets used by the endpoints. The proxy will remain on the path if it chooses to not insert a Record-Route header field value into requests that are already part of a dialog. However, it would be removed from the path when an endpoint that has failed reconstitutes the dialog. A proxy MAY insert a Record-Route header field value into any request. If the request does not initiate a dialog, the endpoints will ignore the value. See Section 12 for details on how endpoints use the Record-Route header field values to construct Route header fields. Each proxy in the path of a request chooses whether to add a Record-Route header field value independently - the presence of a Record-Route header field in a request does not obligate this proxy to add a value. The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI. This URI MUST contain an lr parameter (see Section 19.1.1). This URI MAY be different for each destination the request is forwarded to. The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport. The URI this proxy provides will be used by some other element to make a routing decision. This proxy, in general, has no way of knowing the capabilities of that element, so it must restrict itself to the mandatory elements of a SIP implementation: SIP URIs and either the TCP or UDP transports. Rosenberg, et. al. Standards Track [Page 101] RFC 3261 SIP: Session Initiation Protocol June 2002 The URI placed in the Record-Route header field MUST resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element. If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field. In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6), MUST insert a Record-Route header field that is not a SIPS URI. A proxy at a security perimeter must remain on the perimeter throughout the dialog. If the URI placed in the Record-Route header field needs to be rewritten when it passes back through in a response, the URI MUST be distinct enough to locate at that time. (The request may spiral through this proxy, resulting in more than one Record-Route header field value being added). Item 8 of Section 16.7 recommends a mechanism to make the URI sufficiently distinct. The proxy MAY include parameters in the Record-Route header field value. These will be echoed in some responses to the request such as the 200 (OK) responses to INVITE. Such parameters may be useful for keeping state in the message rather than the proxy. If a proxy needs to be in the path of any type of dialog (such as one straddling a firewall), it SHOULD add a Record-Route header field value to every request with a method it does not understand since that method may have dialog semantics. The URI a proxy places into a Record-Route header field is only valid for the lifetime of any dialog created by the transaction in which it occurs. A dialog-stateful proxy, for example, MAY refuse to accept future requests with that value in the Request-URI after the dialog has terminated. Non-dialog- stateful proxies, of course, have no concept of when the dialog has terminated, but they MAY encode enough information in the value to compare it against the dialog identifier of future requests and MAY reject requests not matching that information. Endpoints MUST NOT use a URI obtained from a Record-Route header field outside the dialog in which it was provided. See Rosenberg, et. al. Standards Track [Page 102] RFC 3261 SIP: Session Initiation Protocol June 2002 Section 12 for more information on an endpoint's use of Record-Route header fields. Record-routing may be required by certain services where the proxy needs to observe all messages in a dialog. However, it slows down processing and impairs scalability and thus proxies should only record-route if required for a particular service. The Record-Route process is designed to work for any SIP request that initiates a dialog. INVITE is the only such request in this specification, but extensions to the protocol MAY define others. 5. Add Additional Header Fields The proxy MAY add any other appropriate header fields to the copy at this point. 6. Postprocess routing information A proxy MAY have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination. A proxy MUST ensure that all such proxies are loose routers. Generally, this can only be known with certainty if the proxies are within the same administrative domain. This set of proxies is represented by a set of URIs (each of which contains the lr parameter). This set MUST be pushed into the Route header field of the copy ahead of any existing values, if present. If the Route header field is absent, it MUST be added, containing that list of URIs. If the proxy has a local policy that mandates that the request visit one specific proxy, an alternative to pushing a Route value into the Route header field is to bypass the forwarding logic of item 10 below, and instead just send the request to the address, port, and transport for that specific proxy. If the request has a Route header field, this alternative MUST NOT be used unless it is known that next hop proxy is a loose router. Otherwise, this approach MAY be used, but the Route insertion mechanism above is preferred for its robustness, flexibility, generality and consistency of operation. Furthermore, if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with that proxy. If the copy contains a Route header field, the proxy MUST inspect the URI in its first value. If that URI does not contain an lr parameter, the proxy MUST modify the copy as follows: Rosenberg, et. al. Standards Track [Page 103] RFC 3261 SIP: Session Initiation Protocol June 2002 - The proxy MUST place the Request-URI into the Route header field as the last value. - The proxy MUST then place the first Route header field value into the Request-URI and remove that value from the Route header field. Appending the Request-URI to the Route header field is part of a mechanism used to pass the information in that Request-URI through strict-routing elements. ""Popping"" the first Route header field value into the Request-URI formats the message the way a strict-routing element expects to receive it (with its own URI in the Request-URI and the next location to visit in the first Route header field value). 7. Determine Next-Hop Address, Port, and Transport The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI. Such a policy MUST NOT be used if the proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. However, this mechanism for sending the request through a specific next hop is NOT RECOMMENDED; instead a Route header field should be used for that purpose as described above. In the absence of such an overriding mechanism, the proxy applies the procedures listed in [4] as follows to determine where to send the request. If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy MUST apply those procedures to the Request-URI of the request. Otherwise, the proxy MUST apply the procedures to the first value in the Route header field, if present, else the Request-URI. The procedures will produce an ordered set of (address, port, transport) tuples. Independently of which URI is being used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the proxy MUST follow the procedures of [4] as if the input URI were a SIPS URI. As described in [4], the proxy MUST attempt to deliver the message to the first tuple in that set, and proceed through the set in order until the delivery attempt succeeds. For each tuple attempted, the proxy MUST format the message as appropriate for the tuple and send the request using a new client transaction as detailed in steps 8 through 10. Rosenberg, et. al. Standards Track [Page 104] RFC 3261 SIP: Session Initiation Protocol June 2002 Since each attempt uses a new client transaction, it represents a new branch. Thus, the branch parameter provided with the Via header field inserted in step 8 MUST be different for each attempt. If the client transaction reports failure to send the request or a timeout from its state machine, the proxy continues to the next address in that ordered set. If the ordered set is exhausted, the request cannot be forwarded to this element in the target set. The proxy does not need to place anything in the response context, but otherwise acts as if this element of the target set returned a 408 (Request Timeout) final response. 8. Add a Via header field value The proxy MUST insert a Via header field value into the copy before the existing Via header field values. The construction of this value follows the same guidelines of Section 8.1.1.7. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and contain the requisite magic cookie. Note that this implies that the branch parameter will be different for different instances of a spiraled or looped request through a proxy. Proxies choosing to detect loops have an additional constraint in the value they use for construction of the branch parameter."
"A proxy choosing to detect loops SHOULD create a branch parameter separable into two parts by the implementation. The first part MUST satisfy the constraints of Section 8.1.1.7 as described above. The second is used to perform loop detection and distinguish loops from spirals. Loop detection is performed by verifying that, when a request returns to a proxy, those fields having an impact on the processing of the request have not changed. The value placed in this part of the branch parameter SHOULD reflect all of those fields (including any Route, Proxy-Require and Proxy- Authorization header fields). This is to ensure that if the request is routed back to the proxy and one of those fields changes, it is treated as a spiral and not a loop (see Section 16.3). A common way to create this value is to compute a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI of the request received (before translation), the topmost Via header, and the sequence number from the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that may be present. The Rosenberg, et. al. Standards Track [Page 105] RFC 3261 SIP: Session Initiation Protocol June 2002 algorithm used to compute the hash is implementation-dependent, but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a reasonable choice. (Base64 is not permissible for a token.) If a proxy wishes to detect loops, the ""branch"" parameter it supplies MUST depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing. This is necessary to distinguish looped requests from requests whose routing parameters have changed before returning to this server. The request method MUST NOT be included in the calculation of the branch parameter. In particular, CANCEL and ACK requests (for non-2xx responses) MUST have the same branch value as the corresponding request they cancel or acknowledge. The branch parameter is used in correlating those requests at the server handling them (see Sections 17.2.3 and 9.2). 9. Add a Content-Length header field if necessary If the request will be sent to the next hop using a stream- based transport and the copy contains no Content-Length header field, the proxy MUST insert one with the correct value for the body of the request (see Section 20.14). 10. Forward Request A stateful proxy MUST create a new client transaction for this request as described in Section 17.1 and instructs the transaction to send the request using the address, port and transport determined in step 7. 11. Set timer C In order to handle the case where an INVITE request never generates a final response, the TU uses a timer which is called timer C. Timer C MUST be set for each client transaction when an INVITE request is proxied. The timer MUST be larger than 3 minutes. Section 16.7 bullet 2 discusses how this timer is updated with provisional responses, and Section 16.8 discusses processing when it fires. Rosenberg, et. al. Standards Track [Page 106] RFC 3261 SIP: Session Initiation Protocol June 2002 16.7 Response Processing When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST process the response (even if it is an informational response) as a stateless proxy (described below). If a match is found, the response is handed to the client transaction. Forwarding responses for which a client transaction (or more generally any knowledge of having sent an associated request) is not found improves robustness. In particular, it ensures that ""late"" 2xx responses to INVITE requests are forwarded properly. As client transactions pass responses to the proxy layer, the following processing MUST take place: 1. Find the appropriate response context 2. Update timer C for provisional responses 3. Remove the topmost Via 4. Add the response to the response context 5. Check to see if this response should be forwarded immediately 6. When necessary, choose the best final response from the response context If no final response has been forwarded after every client transaction associated with the response context has been terminated, the proxy must choose and forward the ""best"" response from those it has seen so far. The following processing MUST be performed on each response that is forwarded. It is likely that more than one response to each request will be forwarded: at least each provisional and one final response. 7. Aggregate authorization header field values if necessary 8. Optionally rewrite Record-Route header field values 9. Forward the response 10. Generate any necessary CANCEL requests Rosenberg, et. al. Standards Track [Page 107] RFC 3261 SIP: Session Initiation Protocol June 2002 Each of the above steps are detailed below: 1. Find Context The proxy locates the ""response context"" it created before forwarding the original request using the key described in Section 16.6. The remaining processing steps take place in this context. 2. Update timer C for provisional responses For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C for that client transaction. The timer MAY be reset to a different value, but this value MUST be greater than 3 minutes. 3. Via The proxy removes the topmost Via header field value from the response. If no Via header field values remain in the response, the response was meant for this element and MUST NOT be forwarded. The remainder of the processing described in this section is not performed on this message, the UAC processing rules described in Section 8.1.3 are followed instead (transport layer processing has already occurred). This will happen, for instance, when the element generates CANCEL requests as described in Section 10. 4. Add response to context Final responses received are stored in the response context until a final response is generated on the server transaction associated with this context. The response may be a candidate for the best final response to be returned on that server transaction. Information from this response may be needed in forming the best response, even if this response is not chosen. If the proxy chooses to recurse on any contacts in a 3xx response by adding them to the target set, it MUST remove them from the response before adding the response to the response context. However, a proxy SHOULD NOT recurse to a non-SIPS URI if the Request-URI of the original request was a SIPS URI. If Rosenberg, et. al. Standards Track [Page 108] RFC 3261 SIP: Session Initiation Protocol June 2002 the proxy recurses on all of the contacts in a 3xx response, the proxy SHOULD NOT add the resulting contactless response to the response context. Removing the contact before adding the response to the response context prevents the next element upstream from retrying a location this proxy has already attempted. 3xx responses may contain a mixture of SIP, SIPS, and non-SIP URIs. A proxy may choose to recurse on the SIP and SIPS URIs and place the remainder into the response context to be returned, potentially in the final response. If a proxy receives a 416 (Unsupported URI Scheme) response to a request whose Request-URI scheme was not SIP, but the scheme in the original received request was SIP or SIPS (that is, the proxy changed the scheme from SIP or SIPS to something else when it proxied a request), the proxy SHOULD add a new URI to the target set. This URI SHOULD be a SIP URI version of the non-SIP URI that was just tried. In the case of the tel URL, this is accomplished by placing the telephone-subscriber part of the tel URL into the user part of the SIP URI, and setting the hostpart to the domain where the prior request was sent. See Section 19.1.6 for more detail on forming SIP URIs from tel URLs. As with a 3xx response, if a proxy ""recurses"" on the 416 by trying a SIP or SIPS URI instead, the 416 response SHOULD NOT be added to the response context. 5. Check response for forwarding Until a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any provisional response other than 100 (Trying) - Any 2xx response If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context. This is a change from RFC 2543, which mandated that the proxy was to forward the 6xx response immediately. For an INVITE transaction, this approach had the problem that a 2xx response could arrive on another branch, in which case the proxy would Rosenberg, et. al. Standards Track [Page 109] RFC 3261 SIP: Session Initiation Protocol June 2002 have to forward the 2xx. The result was that the UAC could receive a 6xx response followed by a 2xx response, which should never be allowed to happen. Under the new rules, upon receiving a 6xx, a proxy will issue a CANCEL request, which will generally result in 487 responses from all outstanding client transactions, and then at that point the 6xx is forwarded upstream. After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any 2xx response to an INVITE request A stateful proxy MUST NOT immediately forward any other responses. In particular, a stateful proxy MUST NOT forward any 100 (Trying) response. Those responses that are candidates for forwarding later as the ""best"" response have been gathered as described in step ""Add Response to Context"". Any response chosen for immediate forwarding MUST be processed as described in steps ""Aggregate Authorization Header Field Values"" through ""Record-Route"". This step, combined with the next, ensures that a stateful proxy will forward exactly one final response to a non-INVITE request, and either exactly one non-2xx response or one or more 2xx responses to an INVITE request. 6. Choosing the best response A stateful proxy MUST send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules and all client transactions in this response context have been terminated. The stateful proxy MUST choose the ""best"" final response among those received and stored in the response context. If there are no final responses in the context, the proxy MUST send a 408 (Request Timeout) response to the server transaction. Otherwise, the proxy MUST forward a response from the responses stored in the response context. It MUST choose from the 6xx class responses if any exist in the context. If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context. The proxy MAY select any response within that chosen class. The proxy SHOULD Rosenberg, et. al. Standards Track [Page 110] RFC 3261 SIP: Session Initiation Protocol June 2002 give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen. A proxy which receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 503 means that the proxy knows it cannot service any requests, not just the one for the Request- URI in the request which generated the 503. If the only response that was received is a 503, the proxy SHOULD generate a 500 response and forward that upstream. The forwarded response MUST be processed as described in steps ""Aggregate Authorization Header Field Values"" through ""Record- Route"". For example, if a proxy forwarded a request to 4 locations, and received 503, 407, 501, and 404 responses, it may choose to forward the 407 (Proxy Authentication Required) response. 1xx and 2xx responses may be involved in the establishment of dialogs. When a request does not contain a To tag, the To tag in the response is used by the UAC to distinguish multiple responses to a dialog creating request. A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx response if the request did not contain one. A proxy MUST NOT modify the tag in the To header field of a 1xx or 2xx response. Since a proxy may not insert a tag into the To header field of a 1xx response to a request that did not contain one, it cannot issue non-100 provisional responses on its own. However, it can branch the request to a UAS sharing the same element as the proxy. This UAS can return its own provisional responses, entering into an early dialog with the initiator of the request. The UAS does not have to be a discreet process from the proxy. It could be a virtual UAS implemented in the same code space as the proxy. 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx response, the element is effectively acting as a UAS, issuing its own response, usually based on the responses received from downstream elements. An element SHOULD preserve the To tag when simply forwarding a 3-6xx response to a request that did not contain a To tag. A proxy MUST NOT modify the To tag in any forwarded response to a request that contains a To tag. Rosenberg, et. al. Standards Track [Page 111] RFC 3261 SIP: Session Initiation Protocol June 2002 While it makes no difference to the upstream elements if the proxy replaced the To tag in a forwarded 3-6xx response, preserving the original tag may assist with debugging. When the proxy is aggregating information from several responses, choosing a To tag from among them is arbitrary, and generating a new To tag may make debugging easier. This happens, for instance, when combining 401 (Unauthorized) and 407 (Proxy Authentication Required) challenges, or combining Contact values from unencrypted and unauthenticated 3xx responses. 7. Aggregate Authorization Header Field Values If the selected response is a 401 (Unauthorized) or 407 (Proxy Authentication Required), the proxy MUST collect any WWW- Authenticate and Proxy-Authenticate header field values from all other 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this response context and add them to this response without modification before forwarding. The resulting 401 (Unauthorized) or 407 (Proxy Authentication Required) response could have several WWW- Authenticate AND Proxy-Authenticate header field values. This is necessary because any or all of the destinations the request was forwarded to may have requested credentials. The client needs to receive all of those challenges and supply credentials for each of them when it retries the request. Motivation for this behavior is provided in Section 26. 8. Record-Route If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy MAY choose to rewrite the value before forwarding the response. This allows the proxy to provide different URIs for itself to the next upstream and downstream elements. A proxy may choose to use this mechanism for any reason. For instance, it is useful for multi-homed hosts. If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI. If the proxy received the request over a non-TLS connection, and sent it out over TLS, the proxy MUST rewrite the URI in the Record-Route header field to be a SIP URI. Rosenberg, et. al. Standards Track [Page 112] RFC 3261 SIP: Session Initiation Protocol June 2002 The new URI provided by the proxy MUST satisfy the same constraints on URIs placed in Record-Route header fields in requests (see Step 4 of Section 16.6) with the following modifications: The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge that the next upstream (as opposed to downstream) element that will be in the path of subsequent requests supports that transport. When a proxy does decide to modify the Record-Route header field in the response, one of the operations it performs is locating the Record-Route value that it had inserted. If the request spiraled, and the proxy inserted a Record-Route value in each iteration of the spiral, locating the correct value in the response (which must be the proper iteration in the reverse direction) is tricky. The rules above recommend that a proxy wishing to rewrite Record-Route header field values insert sufficiently distinct URIs into the Record-Route header field so that the right one may be selected for rewriting. A RECOMMENDED mechanism to achieve this is for the proxy to append a unique identifier for the proxy instance to the user portion of the URI. When the response arrives, the proxy modifies the first Record-Route whose identifier matches the proxy instance. The modification results in a URI without this piece of data appended to the user portion of the URI. Upon the next iteration, the same algorithm (find the topmost Record-Route header field value with the parameter) will correctly extract the next Record-Route header field value inserted by that proxy. Not every response to a request to which a proxy adds a Record-Route header field value will contain a Record-Route header field. If the response does contain a Record-Route header field, it will contain the value the proxy added. 9. Forward response After performing the processing described in steps ""Aggregate Authorization Header Field Values"" through ""Record-Route"", the proxy MAY perform any feature specific manipulations on the selected response. The proxy MUST NOT add to, modify, or remove the message body. Unless otherwise specified, the proxy MUST NOT remove any header field values other than the Via header field value discussed in Section 16.7 Item 3. In particular, the proxy MUST NOT remove any ""received"" parameter Rosenberg, et. al. Standards Track [Page 113] RFC 3261 SIP: Session Initiation Protocol June 2002 it may have added to the next Via header field value while processing the request associated with this response. The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost Via header field value. If the server transaction is no longer available to handle the transmission, the element MUST forward the response statelessly by sending it to the server transport. The server transaction might indicate failure to send the response or signal a timeout in its state machine. These errors would be logged for diagnostic purposes as appropriate, but the protocol requires no remedial action from the proxy. The proxy MUST maintain the response context until all of its associated transactions have been terminated, even after forwarding a final response. 10. Generate CANCELs If the forwarded response was a final response, the proxy MUST generate a CANCEL request for all pending client transactions associated with this response context. A proxy SHOULD also generate a CANCEL request for all pending client transactions associated with this response context when it receives a 6xx response. A pending client transaction is one that has received a provisional response, but no final response (it is in the proceeding state) and has not had an associated CANCEL generated for it. Generating CANCEL requests is described in Section 9.1. The requirement to CANCEL pending client transactions upon forwarding a final response does not guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE. 200 (OK) responses on more than one branch may be generated before the CANCEL requests can be sent and processed. Further, it is reasonable to expect that a future extension may override this requirement to issue CANCEL requests. 16.8 Processing Timer C If timer C should fire, the proxy MUST either reset the timer with any value it chooses, or terminate the client transaction. If the client transaction has received a provisional response, the proxy MUST generate a CANCEL request matching that transaction. If the client transaction has not received a provisional response, the proxy MUST behave as if the transaction received a 408 (Request Timeout) response. Rosenberg, et. al. Standards Track [Page 114] RFC 3261 SIP: Session Initiation Protocol June 2002 Allowing the proxy to reset the timer allows the proxy to dynamically extend the transaction's lifetime based on current conditions (such as utilization) when the timer fires. 16.9 Handling Transport Errors If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response. If the proxy is notified of an error when forwarding a response, it drops the response. The proxy SHOULD NOT cancel any outstanding client transactions associated with this response context due to this notification. If a proxy cancels its outstanding client transactions, a single malicious or misbehaving client can cause all transactions to fail through its Via header field. 16.10 CANCEL Processing A stateful proxy MAY generate a CANCEL to any other request it has generated at any time (subject to receiving a provisional response to that request as described in section 9.1). A proxy MUST cancel any pending client transactions associated with a response context when it receives a matching CANCEL request. A stateful proxy MAY generate CANCEL requests for pending INVITE client transactions based on the period specified in the INVITE's Expires header field elapsing. However, this is generally unnecessary since the endpoints involved will take care of signaling the end of the transaction. While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response context is not created for it. Instead, the proxy layer searches its existing response contexts for the server transaction handling the request associated with this CANCEL. If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request. In this case, the element is acting as a user agent server as defined in Section 8.2. Furthermore, the element MUST generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10. If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously). Rosenberg, et. al. Standards Track [Page 115] RFC 3261 SIP: Session Initiation Protocol June 2002 16.11 Stateless Proxy When acting statelessly, a proxy is a simple message forwarder. Much of the processing performed when acting statelessly is the same as when behaving statefully. The differences are detailed here. A stateless proxy does not have any notion of a transaction, or of the response context used to describe stateful proxy behavior. Instead, the stateless proxy takes messages, both requests and responses, directly from the transport layer (See section 18). As a result, stateless proxies do not retransmit messages on their own. They do, however, forward all retransmissions they receive (they do not have the ability to distinguish a retransmission from the original message). Furthermore, when handling a request statelessly, an element MUST NOT generate its own 100 (Trying) or any other provisional response. A stateless proxy MUST validate a request as described in Section 16.3 A stateless proxy MUST follow the request processing steps described in Sections 16.4 through 16.5 with the following exception: o A stateless proxy MUST choose one and only one target from the target set. This choice MUST only rely on fields in the message and time-invariant properties of the server. In particular, a retransmitted request MUST be forwarded to the same destination each time it is processed. Furthermore, CANCEL and non-Routed ACK requests MUST generate the same choice as their associated INVITE. A stateless proxy MUST follow the request processing steps described in Section 16.6 with the following exceptions: o The requirement for unique branch IDs across space and time applies to stateless proxies as well. However, a stateless proxy cannot simply use a random number generator to compute the first component of the branch ID, as described in Section 16.6 bullet 8. This is because retransmissions of a request need to have the same value, and a stateless proxy cannot tell a retransmission from the original request. Therefore, the component of the branch parameter that makes it unique MUST be the same each time a retransmitted request is forwarded. Thus for a stateless proxy, the branch parameter MUST be computed as a combinatoric function of message parameters which are invariant on retransmission. Rosenberg, et. al. Standards Track [Page 116] RFC 3261 SIP: Session Initiation Protocol June 2002 The stateless proxy MAY use any technique it likes to guarantee uniqueness of its branch IDs across transactions. However, the following procedure is RECOMMENDED. The proxy examines the branch ID in the topmost Via header field of the received request. If it begins with the magic cookie, the first component of the branch ID of the outgoing request is computed as a hash of the received branch ID. Otherwise, the first component of the branch ID is computed as a hash of the topmost Via, the tag in the To header field, the tag in the From header field, the Call-ID header field, the CSeq number (but not method), and the Request-URI from the received request. One of these fields will always vary across two different transactions. o All other message transformations specified in Section 16.6 MUST result in the same transformation of a retransmitted request. In particular, if the proxy inserts a Record-Route value or pushes URIs into the Route header field, it MUST place the same values in retransmissions of the request. As for the Via branch parameter, this implies that the transformations MUST be based on time-invariant configuration or retransmission-invariant properties of the request. o A stateless proxy determines where to forward the request as described for stateful proxies in Section 16.6 Item 10. The request is sent directly to the transport layer instead of through a client transaction. Since a stateless proxy must forward retransmitted requests to the same destination and add identical branch parameters to each of them, it can only use information from the message itself and time-invariant configuration data for those calculations. If the configuration state is not time-invariant (for example, if a routing table is updated) any requests that could be affected by the change may not be forwarded statelessly during an interval equal to the transaction timeout window before or after the change. The method of processing the affected requests in that interval is an implementation decision. A common solution is to forward them transaction statefully. Stateless proxies MUST NOT perform special processing for CANCEL requests. They are processed by the above rules as any other requests. In particular, a stateless proxy applies the same Route header field processing to CANCEL requests that it applies to any other request. Rosenberg, et. al. Standards Track [Page 117] RFC 3261 SIP: Session Initiation Protocol June 2002 Response processing as described in Section 16.7 does not apply to a proxy behaving statelessly. When a response arrives at a stateless proxy, the proxy MUST inspect the sent-by value in the first (topmost) Via header field value. If that address matches the proxy, (it equals a value this proxy has inserted into previous requests) the proxy MUST remove that header field value from the response and forward the result to the location indicated in the next Via header field value. The proxy MUST NOT add to, modify, or remove the message body. Unless specified otherwise, the proxy MUST NOT remove any other header field values. If the address does not match the proxy, the message MUST be silently discarded. 16.12 Summary of Proxy Route Processing In the absence of local policy to the contrary, the processing a proxy performs on a request containing a Route header field can be summarized in the following steps. 1. The proxy will inspect the Request-URI. If it indicates a resource owned by this proxy, the proxy will replace it with the results of running a location service. Otherwise, the proxy will not change the Request-URI. 2. The proxy will inspect the URI in the topmost Route header field value. If it indicates this proxy, the proxy removes it from the Route header field (this route node has been reached). 3. The proxy will forward the request to the resource indicated by the URI in the topmost Route header field value or in the Request-URI if no Route header field is present. The proxy determines the address, port and transport to use when forwarding the request by applying the procedures in [4] to that URI. If no strict-routing elements are encountered on the path of the request, the Request-URI will always indicate the target of the request. 16.12.1 Examples 16.12.1.1 Basic SIP Trapezoid This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing. Here is the flow. Rosenberg, et. al. Standards Track [Page 118] RFC 3261 SIP: Session Initiation Protocol June 2002 U1 sends: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com to P1. P1 is an outbound proxy. P1 is not responsible for domain.com, so it looks it up in DNS and sends it there. It also adds a Record-Route header field value: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p1.example.com;lr> P2 gets this. It is responsible for domain.com so it runs a location service and rewrites the Request-URI. It also adds a Record-Route header field value. There is no Route header field, so it resolves the new Request-URI to determine where to send the request: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr> The callee at u2.domain.com gets this and responds with a 200 OK: SIP/2.0 200 OK Contact: sip:callee@u2.domain.com Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr> The callee at u2 also sets its dialog state's remote target URI to sip:caller@u1.example.com and its route set to: (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>) This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its dialog state's remote target URI to sip:callee@u2.domain.com and its route set to: (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>) Since all the route set elements contain the lr parameter, U1 constructs the following BYE request: BYE sip:callee@u2.domain.com SIP/2.0 Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr> Rosenberg, et. al. Standards Track [Page 119] RFC 3261 SIP: Session Initiation Protocol June 2002 As any other element (including proxies) would do, it resolves the URI in the topmost Route header field value using DNS to determine where to send the request. This goes to P1. P1 notices that it is not responsible for the resource indicated in the Request-URI so it doesn't change it. It does see that it is the first value in the Route header field, so it removes that value, and forwards the request to P2: BYE sip:callee@u2.domain.com SIP/2.0 Route: <sip:p2.domain.com;lr> P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for domain.com, not u2.domain.com), so it doesn't change it. It does see itself in the first Route header field value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the Request-URI: BYE sip:callee@u2.domain.com SIP/2.0 16.12.1.2 Traversing a Strict-Routing Proxy In this scenario, a dialog is established across four proxies, each of which adds Record-Route header field values. The third proxy implements the strict-routing procedures specified in RFC 2543 and many works in progress. U1->P1->P2->P3->P4->U2 The INVITE arriving at U2 contains: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p4.domain.com;lr> Record-Route: <sip:p3.middle.com> Record-Route: <sip:p2.example.com;lr> Record-Route: <sip:p1.example.com;lr> Which U2 responds to with a 200 OK. Later, U2 sends the following BYE request to P4 based on the first Route header field value. BYE sip:caller@u1.example.com SIP/2.0 Route: <sip:p4.domain.com;lr> Route: <sip:p3.middle.com> Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> Rosenberg, et. al. Standards Track [Page 120] RFC 3261 SIP: Session Initiation Protocol June 2002 P4 is not responsible for the resource indicated in the Request-URI so it will leave it alone. It notices that it is the element in the first Route header field value so it removes it. It then prepares to send the request based on the now first Route header field value of sip:p3.middle.com, but it notices that this URI does not contain the lr parameter, so before sending, it reformats the request to be: BYE sip:p3.middle.com SIP/2.0 Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> Route: <sip:caller@u1.example.com> P3 is a strict router, so it forwards the following to P2: BYE sip:p2.example.com;lr SIP/2.0 Route: <sip:p1.example.com;lr> Route: <sip:caller@u1.example.com> P2 sees the request-URI is a value it placed into a Record-Route header field, so before further processing, it rewrites the request to be: BYE sip:caller@u1.example.com SIP/2.0 Route: <sip:p1.example.com;lr> P2 is not responsible for u1.example.com, so it sends the request to P1 based on the resolution of the Route header field value. P1 notices itself in the topmost Route header field value, so it removes it, resulting in: BYE sip:caller@u1.example.com SIP/2.0 Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the request to u1.example.com based on the Request-URI. 16.12.1.3 Rewriting Record-Route Header Field Values In this scenario, U1 and U2 are in different private namespaces and they enter a dialog through a proxy P1, which acts as a gateway between the namespaces. U1->P1->U2 Rosenberg, et. al. Standards Track [Page 121] RFC 3261 SIP: Session Initiation Protocol June 2002 U1 sends: INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 Contact: <sip:caller@u1.leftprivatespace.com> P1 uses its location service and sends the following to U2: INVITE sip:callee@rightprivatespace.com SIP/2.0 Contact: <sip:caller@u1.leftprivatespace.com> Record-Route: <sip:gateway.rightprivatespace.com;lr> U2 sends this 200 (OK) back to P1: SIP/2.0 200 OK Contact: <sip:callee@u2.rightprivatespace.com> Record-Route: <sip:gateway.rightprivatespace.com;lr> P1 rewrites its Record-Route header parameter to provide a value that U1 will find useful, and sends the following to U1: SIP/2.0 200 OK Contact: <sip:callee@u2.rightprivatespace.com> Record-Route: <sip:gateway.leftprivatespace.com;lr> Later, U1 sends the following BYE request to P1: BYE sip:callee@u2.rightprivatespace.com SIP/2.0 Route: <sip:gateway.leftprivatespace.com;lr> which P1 forwards to U2 as: BYE sip:callee@u2.rightprivatespace.com SIP/2.0 17 Transactions SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses. In the case of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction. The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility Rosenberg, et. al. Standards Track [Page 122] RFC 3261 SIP: Session Initiation Protocol June 2002 for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction. Transactions have a client side and a server side. The client side is known as a client transaction and the server side as a server transaction. The client transaction sends the request, and the server transaction sends the response. The client and server transactions are logical functions that are embedded in any number of elements. Specifically, they exist within user agents and stateful proxy servers. Consider the example in Section 4. In this example, the UAC executes the client transaction, and its outbound proxy executes the server transaction. The outbound proxy also executes a client transaction, which sends the request to a server transaction in the inbound proxy. That proxy also executes a client transaction, which in turn sends the request to a server transaction in the UAS. This is shown in Figure 4. +---------+ +---------+ +---------+ +---------+ | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | | |C||------->||S| |C||------->||S| |C||------->||S| | | |l|| ||e| |l|| ||e| |l|| ||e| | | |i|| ||r| |i|| ||r| |i|| ||r| | | |e|| ||v| |e|| ||v| |e|| ||v| | | |n|| ||e| |n|| ||e| |n|| ||e| | | |t|| ||r| |t|| ||r| |t|| ||r| | | | || || | | || || | | || || | | | |T|| ||T| |T|| ||T| |T|| ||T| | | |r|| ||r| |r|| ||r| |r|| ||r| | | |a|| ||a| |a|| ||a| |a|| ||a| | | |n|| ||n| |n|| ||n| |n|| ||n| | | |s||Response||s| |s||Response||s| |s||Response||s| | | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | +---------+ +---------+ +---------+ +---------+ UAC Outbound Inbound UAS Proxy Proxy Figure 4: Transaction relationships A stateless proxy does not contain a client or server transaction. The transaction exists between the UA or stateful proxy on one side, and the UA or stateful proxy on the other side. As far as SIP transactions are concerned, stateless proxies are effectively transparent."
"The purpose of the client transaction is to receive a request from the element in which the client is embedded (call this element the ""Transaction User"" or TU; it can be a UA or a stateful proxy), and reliably deliver the request to a server transaction. Rosenberg, et. al. Standards Track [Page 123] RFC 3261 SIP: Session Initiation Protocol June 2002 The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK). Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response. Similarly, the purpose of the server transaction is to receive requests from the transport layer and deliver them to the TU. The server transaction filters any request retransmissions from the network. The server transaction accepts responses from the TU and delivers them to the transport layer for transmission over the network. In the case of an INVITE transaction, it absorbs the ACK request for any final response excepting a 2xx response. The 2xx response and its ACK receive special treatment. This response is retransmitted only by a UAS, and its ACK generated only by the UAC. This end-to-end treatment is needed so that a caller knows the entire set of users that have accepted the call. Because of this special handling, retransmissions of the 2xx response are handled by the UA core, not the transaction layer. Similarly, generation of the ACK for the 2xx is handled by the UA core. Each proxy along the path merely forwards each 2xx response to INVITE and its corresponding ACK. 17.1 Client Transaction The client transaction provides its functionality through the maintenance of a state machine. The TU communicates with the client transaction through a simple interface. When the TU wishes to initiate a new transaction, it creates a client transaction and passes it the SIP request to send and an IP address, port, and transport to which to send it. The client transaction begins execution of its state machine. Valid responses are passed up to the TU from the client transaction. There are two types of client transaction state machines, depending on the method of the request passed by the TU. One handles client transactions for INVITE requests. This type of machine is referred to as an INVITE client transaction. Another type handles client transactions for all requests except INVITE and ACK. This is referred to as a non-INVITE client transaction. There is no client transaction for ACK. If the TU wishes to send an ACK, it passes one directly to the transport layer for transmission. Rosenberg, et. al. Standards Track [Page 124] RFC 3261 SIP: Session Initiation Protocol June 2002 The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is required in order to respond to an INVITE. The long delays expected for sending a response argue for a three-way handshake. On the other hand, requests of other methods are expected to complete rapidly. Because of the non-INVITE transaction's reliance on a two-way handshake, TUs SHOULD respond immediately to non-INVITE requests. 17.1.1 INVITE Client Transaction 17.1.1.1 Overview of INVITE Transaction The INVITE transaction consists of a three-way handshake. The client transaction sends an INVITE, the server transaction sends responses, and the client transaction sends an ACK. For unreliable transports (such as UDP), the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission. T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms. Nearly all of the transaction timers described here scale with T1, and changing T1 adjusts their values. The request is not retransmitted over reliable transports. After receiving a 1xx response, any retransmissions cease altogether, and the client waits for further responses. The server transaction can send additional 1xx responses, which are not transmitted reliably by the server transaction. Eventually, the server transaction decides to send a final response. For unreliable transports, that response is retransmitted periodically, and for reliable transports, it is sent once. For each final response that is received at the client transaction, the client transaction sends an ACK, the purpose of which is to quench retransmissions of the response. 17.1.1.2 Formal Description The state machine for the INVITE client transaction is shown in Figure 5. The initial state, ""calling"", MUST be entered when the TU initiates a new client transaction with an INVITE request. The client transaction MUST pass the request to the transport layer for transmission (see Section 18). If an unreliable transport is being used, the client transaction MUST start timer A with a value of T1. If a reliable transport is being used, the client transaction SHOULD NOT start timer A (Timer A controls request retransmissions). For any transport, the client transaction MUST start timer B with a value of 64*T1 seconds (Timer B controls transaction timeouts). When timer A fires, the client transaction MUST retransmit the request by passing it to the transport layer, and MUST reset the timer with a value of 2*T1. The formal definition of retransmit Rosenberg, et. al. Standards Track [Page 125] RFC 3261 SIP: Session Initiation Protocol June 2002 within the context of the transaction layer is to take the message previously sent to the transport layer and pass it to the transport layer once more. When timer A fires 2*T1 seconds later, the request MUST be retransmitted again (assuming the client transaction is still in this state). This process MUST continue so that the request is retransmitted with intervals that double after each transmission. These retransmissions SHOULD only be done while the client transaction is in the ""calling"" state. The default value for T1 is 500 ms. T1 is an estimate of the RTT between the client and server transactions. Elements MAY (though it is NOT RECOMMENDED) use smaller values of T1 within closed, private networks that do not permit general Internet connection. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. Whatever the value of T1, the exponential backoffs on retransmissions described in this section MUST be used. If the client transaction is still in the ""Calling"" state when timer B fires, the client transaction SHOULD inform the TU that a timeout has occurred. The client transaction MUST NOT generate an ACK. The value of 64*T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport. If the client transaction receives a provisional response while in the ""Calling"" state, it transitions to the ""Proceeding"" state. In the ""Proceeding"" state, the client transaction SHOULD NOT retransmit the request any longer. Furthermore, the provisional response MUST be passed to the TU. Any further provisional responses MUST be passed up to the TU while in the ""Proceeding"" state. When in either the ""Calling"" or ""Proceeding"" states, reception of a response with status code from 300-699 MUST cause the client transaction to transition to ""Completed"". The client transaction MUST pass the received response up to the TU, and the client transaction MUST generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) and then pass the ACK to the transport layer for transmission. The ACK MUST be sent to the same address, port, and transport to which the original request was sent. The client transaction SHOULD start timer D when it enters the ""Completed"" state, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction can remain in the ""Completed"" state when unreliable transports are used. This is equal to Timer H in the INVITE server transaction, whose Rosenberg, et. al. Standards Track [Page 126] RFC 3261 SIP: Session Initiation Protocol June 2002 default is 64*T1. However, the client transaction does not know the value of T1 in use by the server transaction, so an absolute minimum of 32s is used instead of basing Timer D on T1. Any retransmissions of the final response that are received while in the ""Completed"" state MUST cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response MUST NOT be passed up to the TU. A retransmission of the response is defined as any response which would match the same client transaction based on the rules of Section 17.1.3. Rosenberg, et. al. Standards Track [Page 127] RFC 3261 SIP: Session Initiation Protocol June 2002 |INVITE from TU Timer A fires |INVITE sent Reset A, V Timer B fires INVITE sent +-----------+ or Transport Err. +---------| |---------------+inform TU | | Calling | | +-------->| |-------------->| +-----------+ 2xx | | | 2xx to TU | | |1xx | 300-699 +---------------+ |1xx to TU | ACK sent | | | resp. to TU | 1xx V | | 1xx to TU -----------+ | | +---------| | | | | |Proceeding |-------------->| | +-------->| | 2xx | | +-----------+ 2xx to TU | | 300-699 | | | ACK sent, | | | resp. to TU| | | | | NOTE: | 300-699 V | | ACK sent +-----------+Transport Err. | transitions | +---------| |Inform TU | labeled with | | | Completed |-------------->| the event | +-------->| | | over the action | +-----------+ | to take | ^ | | | | | Timer D fires | +--------------+ | - | | | V | +-----------+ | | | | | Terminated|<--------------+ | | +-----------+ Figure 5: INVITE client transaction If timer D fires while the client transaction is in the ""Completed"" state, the client transaction MUST move to the terminated state. When in either the ""Calling"" or ""Proceeding"" states, reception of a 2xx response MUST cause the client transaction to enter the ""Terminated"" state, and the response MUST be passed up to the TU. The handling of this response depends on whether the TU is a proxy Rosenberg, et. al. Standards Track [Page 128] RFC 3261 SIP: Session Initiation Protocol June 2002 core or a UAC core. A UAC core will handle generation of the ACK for this response, while a proxy core will always forward the 200 (OK) upstream. The differing treatment of 200 (OK) between proxy and UAC is the reason that handling of it does not take place in the transaction layer. The client transaction MUST be destroyed the instant it enters the ""Terminated"" state. This is actually necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core. Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no match and therefore be passed to the core. 17.1.1.3 Construction of the ACK Request This section specifies the construction of ACK requests sent within the client transaction. A UAC core that generates an ACK for 2xx MUST instead follow the rules described in Section 13. The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the ""original request""). The To header field in the ACK MUST equal the To header field in the response being acknowledged, and therefore will usually differ from the To header field in the original request by the addition of the tag parameter. The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request. The CSeq header field in the ACK MUST contain the same value for the sequence number as was present in the original request, but the method parameter MUST be equal to ""ACK"". Rosenberg, et. al. Standards Track [Page 129] RFC 3261 SIP: Session Initiation Protocol June 2002 If the INVITE request whose response is being acknowledged had Route header fields, those header fields MUST appear in the ACK. This is to ensure that the ACK can be routed properly through any downstream stateless proxies. Although any request MAY contain a body, a body in an ACK is special since the request cannot be rejected if the body is not understood. Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, but if done, the body types are restricted to any that appeared in the INVITE, assuming that the response to the INVITE was not 415. If it was, the body in the ACK MAY be any type listed in the Accept header field in the 415. For example, consider the following request: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 INVITE The ACK request for a non-2xx final response to this request would look like this: ACK sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob <sip:bob@biloxi.com>;tag=99sa0xk From: Alice <sip:alice@atlanta.com>;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 ACK 17.1.2 Non-INVITE Client Transaction 17.1.2.1 Overview of the non-INVITE Transaction Non-INVITE transactions do not make use of ACK. They are simple request-response interactions. For unreliable transports, requests are retransmitted at an interval which starts at T1 and doubles until it hits T2. If a provisional response is received, retransmissions continue for unreliable transports, but at an interval of T2. The server transaction retransmits the last response it sent, which can be a provisional or final response, only when a retransmission of the request is received. This is why request retransmissions need to continue even after a provisional response; they are to ensure reliable delivery of the final response. Rosenberg, et. al. Standards Track [Page 130] RFC 3261 SIP: Session Initiation Protocol June 2002 Unlike an INVITE transaction, a non-INVITE transaction has no special handling for the 2xx response. The result is that only a single 2xx response to a non-INVITE is ever delivered to a UAC. 17.1.2.2 Formal Description The state machine for the non-INVITE client transaction is shown in Figure 6. It is very similar to the state machine for INVITE. The ""Trying"" state is entered when the TU initiates a new client transaction with a request. When entering this state, the client transaction SHOULD set timer F to fire in 64*T1 seconds. The request MUST be passed to the transport layer for transmission. If an unreliable transport is in use, the client transaction MUST set timer E to fire in T1 seconds. If timer E fires while still in this state, the timer is reset, but this time with a value of MIN(2*T1, T2). When the timer fires again, it is reset to a MIN(4*T1, T2). This process continues so that retransmissions occur with an exponentially increasing interval that caps at T2. The default value of T2 is 4s, and it represents the amount of time a non-INVITE server transaction will take to respond to a request, if it does not respond immediately. For the default values of T1 and T2, this results in intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. If Timer F fires while the client transaction is still in the ""Trying"" state, the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the ""Terminated"" state. If a provisional response is received while in the ""Trying"" state, the response MUST be passed to the TU, and then the client transaction SHOULD move to the ""Proceeding"" state. If a final response (status codes 200-699) is received while in the ""Trying"" state, the response MUST be passed to the TU, and the client transaction MUST transition to the ""Completed"" state. If Timer E fires while in the ""Proceeding"" state, the request MUST be passed to the transport layer for retransmission, and Timer E MUST be reset with a value of T2 seconds. If timer F fires while in the ""Proceeding"" state, the TU MUST be informed of a timeout, and the client transaction MUST transition to the terminated state. If a final response (status codes 200-699) is received while in the ""Proceeding"" state, the response MUST be passed to the TU, and the client transaction MUST transition to the ""Completed"" state. Once the client transaction enters the ""Completed"" state, it MUST set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. The ""Completed"" state exists to buffer any additional response retransmissions that may be received (which is why the client transaction remains there only for Rosenberg, et. al. Standards Track [Page 131] RFC 3261 SIP: Session Initiation Protocol June 2002 unreliable transports). T4 represents the amount of time the network will take to clear messages between client and server transactions. The default value of T4 is 5s. A response is a retransmission when it matches the same transaction, using the rules specified in Section 17.1.3. If Timer K fires while in this state, the client transaction MUST transition to the ""Terminated"" state. Once the transaction is in the terminated state, it MUST be destroyed immediately. 17.1.3 Matching Responses to Client Transactions When the transport layer in the client receives a response, it has to determine which client transaction will handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place. The branch parameter in the top Via header field is used for this purpose. A response matches a client transaction under two conditions: 1. If the response has the same value of the branch parameter in the top Via header field as the branch parameter in the top Via header field of the request that created the transaction. 2. If the method parameter in the CSeq header field matches the method of the request that created the transaction. The method is needed since a CANCEL request constitutes a different transaction, but shares the same value of the branch parameter. If a request is sent via multicast, it is possible that it will generate multiple responses from different servers. These responses will all have the same branch parameter in the topmost Via, but vary in the To tag. The first response received, based on the rules above, will be used, and others will be viewed as retransmissions. That is not an error; multicast SIP provides only a rudimentary ""single-hop-discovery-like"" service that is limited to processing a single response. See Section 18.1.1 for details. Rosenberg, et. al. Standards Track [Page 132] RFC 3261 SIP: Session Initiation Protocol June 2002 17.1.4 Handling Transport Errors |Request from TU |send request Timer E V send request +-----------+ +---------| |-------------------+ | | Trying | Timer F | +-------->| | or Transport Err.| +-----------+ inform TU | 200-699 | | | resp. to TU | |1xx | +---------------+ |resp. to TU | | | | | Timer E V Timer F | | send req +-----------+ or Transport Err. | | +---------| | inform TU | | | |Proceeding |------------------>| | +-------->| |-----+ | | +-----------+ |1xx | | | ^ |resp to TU | | 200-699 | +--------+ | | resp. to TU | | | | | | V | | +-----------+ | | | | | | | Completed | | | | | | | +-----------+ | | ^ | | | | | Timer K | +--------------+ | - | | | V | NOTE: +-----------+ | | | | transitions | Terminated|<------------------+ labeled with | | the event +-----------+ over the action to take Figure 6: non-INVITE client transaction When the client transaction sends a request to the transport layer to be sent, the following procedures are followed if the transport layer indicates a failure. Rosenberg, et. al. Standards Track [Page 133] RFC 3261 SIP: Session Initiation Protocol June 2002 The client transaction SHOULD inform the TU that a transport failure has occurred, and the client transaction SHOULD transition directly to the ""Terminated"" state. The TU will handle the failover mechanisms described in [4]. 17.2 Server Transaction The server transaction is responsible for the delivery of requests to the TU and the reliable transmission of responses. It accomplishes this through a state machine. Server transactions are created by the core when a request is received, and transaction handling is desired for that request (this is not always the case). As with the client transactions, the state machine depends on whether the received request is an INVITE request. 17.2.1 INVITE Server Transaction The state diagram for the INVITE server transaction is shown in Figure 7. When a server transaction is constructed for a request, it enters the ""Proceeding"" state. The server transaction MUST generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it MAY generate a 100 (Trying) response. This provisional response is needed to quench request retransmissions rapidly in order to avoid network congestion. The 100 (Trying) response is constructed according to the procedures in Section 8.2.6, except that the insertion of tags in the To header field of the response (when none was present in the request) is downgraded from MAY to SHOULD NOT. The request MUST be passed to the TU. The TU passes any number of provisional responses to the server transaction. So long as the server transaction is in the ""Proceeding"" state, each of these MUST be passed to the transport layer for transmission. They are not sent reliably by the transaction layer (they are not retransmitted by it) and do not cause a change in the state of the server transaction. If a request retransmission is received while in the ""Proceeding"" state, the most recent provisional response that was received from the TU MUST be passed to the transport layer for retransmission. A request is a retransmission if it matches the same server transaction based on the rules of Section 17.2.3. If, while in the ""Proceeding"" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not Rosenberg, et. al. Standards Track [Page 134] RFC 3261 SIP: Session Initiation Protocol June 2002 retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction MUST then transition to the ""Terminated"" state. While in the ""Proceeding"" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response MUST be passed to the transport layer for transmission, and the state machine MUST enter the ""Completed"" state. For unreliable transports, timer G is set to fire in T1 seconds, and is not set to fire for reliable transports. This is a change from RFC 2543, where responses were always retransmitted, even over reliable transports. When the ""Completed"" state is entered, timer H MUST be set to fire in 64*T1 seconds for all transports. Timer H determines when the server transaction abandons retransmitting the response. Its value is chosen to equal Timer B, the amount of time a client transaction will continue to retry sending a request. If timer G fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2. This is identical to the retransmit behavior for requests in the ""Trying"" state of the non-INVITE client transaction. Furthermore, while in the ""Completed"" state, if a request retransmission is received, the server SHOULD pass the response to the transport for retransmission. If an ACK is received while the server transaction is in the ""Completed"" state, the server transaction MUST transition to the ""Confirmed"" state. As Timer G is ignored in this state, any retransmissions of the response will cease. If timer H fires while in the ""Completed"" state, it implies that the ACK was never received. In this case, the server transaction MUST transition to the ""Terminated"" state, and MUST indicate to the TU that a transaction failure has occurred. Rosenberg, et. al. Standards Track [Page 135] RFC 3261 SIP: Session Initiation Protocol June 2002 |INVITE |pass INV to TU INVITE V send 100 if TU won't in 200ms send response+-----------+ +--------| |--------+101-199 from TU | | Proceeding| |send response +------->| |<-------+ | | Transport Err. | | Inform TU | |--------------->+ +-----------+ | 300-699 from TU | |2xx from TU | send response | |send response | | +------------------>+ | | INVITE V Timer G fires | send response+-----------+ send response | +--------| |--------+ | | | Completed | | | +------->| |<-------+ | +-----------+ | | | | ACK | | | - | +------------------>+ | Timer H fires | V or Transport Err.| +-----------+ Inform TU | | | | | Confirmed | | | | | +-----------+ | | | |Timer I fires | |- | | | V | +-----------+ | | | | | Terminated|<---------------+ | | +-----------+ Figure 7: INVITE server transaction Rosenberg, et. al. Standards Track [Page 136] RFC 3261 SIP: Session Initiation Protocol June 2002 The purpose of the ""Confirmed"" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response. When this state is entered, timer I is set to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. Once timer I fires, the server MUST transition to the ""Terminated"" state. Once the transaction is in the ""Terminated"" state, it MUST be destroyed immediately. As with client transactions, this is needed to ensure reliability of the 2xx responses to INVITE. 17.2.2 Non-INVITE Server Transaction The state machine for the non-INVITE server transaction is shown in Figure 8. The state machine is initialized in the ""Trying"" state and is passed a request other than INVITE or ACK when initialized. This request is passed up to the TU. Once in the ""Trying"" state, any further request retransmissions are discarded. A request is a retransmission if it matches the same server transaction, using the rules specified in Section 17.2.3. While in the ""Trying"" state, if the TU passes a provisional response to the server transaction, the server transaction MUST enter the ""Proceeding"" state. The response MUST be passed to the transport layer for transmission. Any further provisional responses that are received from the TU while in the ""Proceeding"" state MUST be passed to the transport layer for transmission. If a retransmission of the request is received while in the ""Proceeding"" state, the most recently sent provisional response MUST be passed to the transport layer for retransmission. If the TU passes a final response (status codes 200-699) to the server while in the ""Proceeding"" state, the transaction MUST enter the ""Completed"" state, and the response MUST be passed to the transport layer for transmission. When the server transaction enters the ""Completed"" state, it MUST set Timer J to fire in 64*T1 seconds for unreliable transports, and zero seconds for reliable transports. While in the ""Completed"" state, the server transaction MUST pass the final response to the transport layer for retransmission whenever a retransmission of the request is received. Any other final responses passed by the TU to the server transaction MUST be discarded while in the ""Completed"" state. The server transaction remains in this state until Timer J fires, at which point it MUST transition to the ""Terminated"" state. The server transaction MUST be destroyed the instant it enters the ""Terminated"" state. Rosenberg, et. al. Standards Track [Page 137] RFC 3261 SIP: Session Initiation Protocol June 2002 17.2.3 Matching Requests to Server Transactions When a request is received from the network by the server, it has to be matched to an existing transaction. This is accomplished in the following manner. The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie ""z9hG4bK"", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if: 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and 3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE. This matching rule applies to both INVITE and non-INVITE transactions alike. The sent-by value is used as part of the matching process because there could be accidental or malicious duplication of branch parameters from different clients. If the branch parameter in the top Via header field is not present, or does not contain the magic cookie, the following procedures are used. These exist to handle backwards compatibility with RFC 2543 compliant implementations. The INVITE request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq, and top Via header field match those of the INVITE request which created the transaction. In this case, the INVITE is a retransmission of the original one that created the transaction. The ACK request matches a transaction if the Request- URI, From tag, Call-ID, CSeq number (not the method), and top Via header field match those of the INVITE request which created the transaction, and the To tag of the ACK matches the To tag of the response sent by the server transaction. Matching is done based on the matching rules defined for each of those header fields. Inclusion of the tag in the To header field in the ACK matching process helps disambiguate ACK for 2xx from ACK for other responses Rosenberg, et. al. Standards Track [Page 138] RFC 3261 SIP: Session Initiation Protocol June 2002 at a proxy, which may have forwarded both responses (This can occur in unusual conditions. Specifically, when a proxy forked a request, and then crashes, the responses may be delivered to another proxy, which might end up forwarding multiple responses upstream). An ACK request that matches an INVITE transaction matched by a previous ACK is considered a retransmission of that previous ACK. Rosenberg, et. al. Standards Track [Page 139] RFC 3261 SIP: Session Initiation Protocol June 2002 |Request received |pass to TU V +-----------+ | | | Trying |-------------+ | | | +-----------+ |200-699 from TU | |send response |1xx from TU | |send response | | | Request V 1xx from TU | send response+-----------+send response| +--------| |--------+ | | | Proceeding| | | +------->| |<-------+ | +<--------------| | | |Trnsprt Err +-----------+ | |Inform TU | | | | | | |200-699 from TU | | |send response | | Request V | | send response+-----------+ | | +--------| | | | | | Completed |<------------+ | +------->| | +<--------------| | |Trnsprt Err +-----------+ |Inform TU | | |Timer J fires | |- | | | V | +-----------+ | | | +-------------->| Terminated| | | +-----------+ Figure 8: non-INVITE server transaction For all other request methods, a request is matched to a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq (including the method), and top Via header field match those of the request that created the transaction. Matching is done based on the matching Rosenberg, et. al. Standards Track [Page 140] RFC 3261 SIP: Session Initiation Protocol June 2002 rules defined for each of those header fields. When a non-INVITE request matches an existing transaction, it is a retransmission of the request that created that transaction. Because the matching rules include the Request-URI, the server cannot match a response to a transaction. When the TU passes a response to the server transaction, it must pass it to the specific server transaction for which the response is targeted. 17.2.4 Handling Transport Errors When the server transaction sends a response to the transport layer to be sent, the following procedures are followed if the transport layer indicates a failure. First, the procedures in [4] are followed, which attempt to deliver the response to a backup. If those should all fail, based on the definition of failure in [4], the server transaction SHOULD inform the TU that a failure has occurred, and SHOULD transition to the terminated state. 18 Transport The transport layer is responsible for the actual transmission of requests and responses over network transports. This includes determination of the connection to use for a request or response in the case of connection-oriented transports. The transport layer is responsible for managing persistent connections for transport protocols like TCP and SCTP, or TLS over those, including ones opened to the transport layer. This includes connections opened by the client or server transports, so that connections are shared between client and server transport functions. These connections are indexed by the tuple formed from the address, port, and transport protocol at the far end of the connection. When a connection is opened by the transport layer, this index is set to the destination IP, port and transport. When the connection is accepted by the transport layer, this index is set to the source IP address, port number, and transport. Note that, because the source port is often ephemeral, but it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by the transport layer will frequently not be reused. The result is that two proxies in a ""peering"" relationship using a connection- oriented transport frequently will have two connections in use, one for transactions initiated in each direction. Rosenberg, et. al. Standards Track [Page 141] RFC 3261 SIP: Session Initiation Protocol June 2002 It is RECOMMENDED that connections be kept open for some implementation-defined duration after the last message was sent or received over that connection. This duration SHOULD at least equal the longest amount of time the element would need in order to bring a transaction from instantiation to the terminated state. This is to make it likely that transactions are completed over the same connection on which they are initiated (for example, request, response, and in the case of INVITE, ACK for non-2xx responses). This usually means at least 64*T1 (see Section 17.1.1.1 for a definition of T1). However, it could be larger in an element that has a TU using a large value for timer C (bullet 11 of Section 16.6), for example. All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them. 18.1 Clients 18.1.1 Sending Requests The client side of the transport layer is responsible for sending the request and receiving responses. The user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly TTL for multicast destinations. If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers. The 200 byte ""buffer"" between the message size and the MTU accommodates the fact that the response in SIP can be larger than the request. This happens due to the addition of Record-Route header field values to the responses to INVITE, for example."
"With the extra buffer, the response can be about 170 bytes larger than the request, and still not be fragmented on IPv4 (about 30 bytes Rosenberg, et. al. Standards Track [Page 142] RFC 3261 SIP: Session Initiation Protocol June 2002 is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU. If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not support TCP. It is anticipated that this behavior will be deprecated in a future revision of this specification. A client that sends a request to a multicast address MUST add the ""maddr"" parameter to its Via header field value containing the destination multicast address, and for IPv4, SHOULD add the ""ttl"" parameter with a value of 1. Usage of IPv6 multicast is not defined in this specification, and will be a subject of future standardization when the need arises. These rules result in a purposeful limitation of multicast in SIP. Its primary function is to provide a ""single-hop-discovery-like"" service, delivering a request to a group of homogeneous servers, where it is only required to process the response from any one of them. This functionality is most useful for registrations. In fact, based on the transaction processing rules in Section 17.1.3, the client transaction will accept the first response, and view any others as retransmissions because they all contain the same Via branch identifier. Before a request is sent, the client transport MUST insert a value of the ""sent-by"" field into the Via header field. This field contains an IP address or host name, and port. The usage of an FQDN is RECOMMENDED. This field is used for sending responses under certain conditions, described below. If the port is absent, the default value depends on the transport. It is 5060 for UDP, TCP and SCTP, 5061 for TLS. For reliable transports, the response is normally sent on the connection on which the request was received. Therefore, the client transport MUST be prepared to receive the response on the same connection used to send the request. Under error conditions, the server may attempt to open a new connection to send the response. To handle this case, the transport layer MUST also be prepared to receive an incoming connection on the source IP address from which the request was sent and port number in the ""sent-by"" field. It also Rosenberg, et. al. Standards Track [Page 143] RFC 3261 SIP: Session Initiation Protocol June 2002 MUST be prepared to receive incoming connections on any address and port that would be selected by a server based on the procedures described in Section 5 of [4]. For unreliable unicast transports, the client transport MUST be prepared to receive responses on the source IP address from which the request is sent (as responses are sent back to the source address) and the port number in the ""sent-by"" field. Furthermore, as with reliable transports, in certain cases the response will be sent elsewhere. The client MUST be prepared to receive responses on any address and port that would be selected by a server based on the procedures described in Section 5 of [4]. For multicast, the client transport MUST be prepared to receive responses on the same multicast group and port to which the request is sent (that is, it needs to be a member of the multicast group it sent the request to.) If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection MAY be opened and used. If a request is sent using multicast, it is sent to the group address, port, and TTL provided by the transport user. If a request is sent using unicast unreliable transports, it is sent to the IP address and port provided by the transport user. 18.1.2 Receiving Responses When a response is received, the client transport examines the top Via header field value. If the value of the ""sent-by"" parameter in that header field value does not correspond to a value that the client transport is configured to insert into requests, the response MUST be silently discarded. If there are any client transactions in existence, the client transport uses the matching procedures of Section 17.1.3 to attempt to match the response to an existing transaction. If there is a match, the response MUST be passed to that transaction. Otherwise, the response MUST be passed to the core (whether it be stateless proxy, stateful proxy, or UA) for further processing. Handling of these ""stray"" responses is dependent on the core (a proxy will forward them, while a UA will discard, for example). Rosenberg, et. al. Standards Track [Page 144] RFC 3261 SIP: Session Initiation Protocol June 2002 18.2 Servers 18.2.1 Receiving Requests A server SHOULD be prepared to receive requests on any IP address, port and transport combination that can be the result of a DNS lookup on a SIP or SIPS URI [4] that is handed out for the purposes of communicating with that server. In this context, ""handing out"" includes placing a URI in a Contact header field in a REGISTER request or a redirect response, or in a Record-Route header field in a request or response. A URI can also be ""handed out"" by placing it on a web page or business card. It is also RECOMMENDED that a server listen for requests on the default SIP ports (5060 for TCP and UDP, 5061 for TLS over TCP) on all public interfaces. The typical exception would be private networks, or when multiple server instances are running on the same host. For any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP. This is because a message may need to be sent using TCP, rather than UDP, if it is too large. As a result, the converse is not true. A server need not listen for UDP on a particular address and port just because it is listening on that same address and port for TCP. There may, of course, be other reasons why a server needs to listen for UDP on a particular address and port. When the server transport receives a request over any transport, it MUST examine the value of the ""sent-by"" parameter in the top Via header field value. If the host portion of the ""sent-by"" parameter contains a domain name, or if it contains an IP address that differs from the packet source address, the server MUST add a ""received"" parameter to that Via header field value. This parameter MUST contain the source address from which the packet was received. This is to assist the server transport layer in sending the response, since it must be sent to the source IP address from which the request came. Consider a request received by the server transport which looks like, in part: INVITE sip:bob@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060 The request is received with a source IP address of 192.0.2.4. Before passing the request up, the transport adds a ""received"" parameter, so that the request would look like, in part: INVITE sip:bob@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 Rosenberg, et. al. Standards Track [Page 145] RFC 3261 SIP: Session Initiation Protocol June 2002 Next, the server transport attempts to match the request to a server transaction. It does so using the matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed to that transaction for processing. If no match is found, the request is passed to the core, which may decide to construct a new server transaction for that request. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed. 18.2.2 Sending Responses The server transport uses the value of the top Via header field in order to determine where to send a response. It MUST follow the following process: o If the ""sent-protocol"" is a reliable transport protocol such as TCP or SCTP, or TLS over those, the response MUST be sent using the existing connection to the source of the original request that created the transaction, if that connection is still open. This requires the server transport to maintain an association between server transactions and transport connections. If that connection is no longer open, the server SHOULD open a connection to the IP address in the ""received"" parameter, if present, using the port in the ""sent-by"" value, or the default port for that transport, if no port is specified. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. o Otherwise, if the Via header field value contains a ""maddr"" parameter, the response MUST be forwarded to the address listed there, using the port indicated in ""sent-by"", or port 5060 if none is present. If the address is a multicast address, the response SHOULD be sent using the TTL indicated in the ""ttl"" parameter, or with a TTL of 1 if that parameter is not present. o Otherwise (for unreliable unicast transports), if the top Via has a ""received"" parameter, the response MUST be sent to the address in the ""received"" parameter, using the port indicated in the ""sent-by"" value, or using port 5060 if none is specified explicitly. If this fails, for example, elicits an ICMP ""port unreachable"" response, the procedures of Section 5 of [4] SHOULD be used to determine where to send the response. Rosenberg, et. al. Standards Track [Page 146] RFC 3261 SIP: Session Initiation Protocol June 2002 o Otherwise, if it is not receiver-tagged, the response MUST be sent to the address indicated by the ""sent-by"" value, using the procedures in Section 5 of [4]. 18.3 Framing In the case of message-oriented transports (such as UDP), if the message has a Content-Length header field, the message body is assumed to contain that many bytes. If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. If the transport packet ends before the end of the message body, this is considered an error. If the message is a response, it MUST be discarded. If the message is a request, the element SHOULD generate a 400 (Bad Request) response. If the message has no Content-Length header field, the message body is assumed to end at the end of the transport packet. In the case of stream-oriented transports such as TCP, the Content- Length header field indicates the size of the body. The Content- Length header field MUST be used with stream oriented transports. 18.4 Error Handling Error handling is independent of whether the message was a request or response. If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP error, the behavior depends on the type of ICMP error. Host, network, port or protocol unreachable errors, or parameter problem errors SHOULD cause the transport layer to inform the transport user of a failure in sending. Source quench and TTL exceeded ICMP errors SHOULD be ignored. If the transport user asks for a request to be sent over a reliable transport, and the result is a connection failure, the transport layer SHOULD inform the transport user of a failure in sending. 19 Common Message Components There are certain components of SIP messages that appear in various places within SIP messages (and sometimes, outside of them) that merit separate discussion. Rosenberg, et. al. Standards Track [Page 147] RFC 3261 SIP: Session Initiation Protocol June 2002 19.1 SIP and SIPS Uniform Resource Indicators A SIP or SIPS URI identifies a communications resource. Like all URIs, SIP and SIPS URIs may be placed in web pages, email messages, or printed literature. They contain sufficient information to initiate and maintain a communication session with the resource. Examples of communications resources include the following: o a user of an online service o an appearance on a multi-line phone o a mailbox on a messaging system o a PSTN number at a gateway service o a group (such as ""sales"" or ""helpdesk"") in an organization A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain. Any resource described by a SIP URI can be ""upgraded"" to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely. 19.1.1 SIP and SIPS URI Components The ""sip:"" and ""sips:"" schemes follow the guidelines in RFC 2396 [5]. They use a form similar to the mailto URL, allowing the specification of SIP request-header fields and the SIP message-body. This makes it possible to specify the subject, media type, or urgency of sessions initiated by using a URI on a web page or in an email message. The formal syntax for a SIP or SIPS URI is presented in Section 25. Its general form, in the case of a SIP URI, is: sip:user:password@host:port;uri-parameters?headers The format for a SIPS URI is the same, except that the scheme is ""sips"" instead of sip. These tokens, and some of the tokens in their expansions, have the following meanings: user: The identifier of a particular resource at the host being addressed. The term ""host"" in this context frequently refers to a domain. The ""userinfo"" of a URI consists of this user field, the password field, and the @ sign following them. The userinfo part of a URI is optional and MAY be absent when the Rosenberg, et. al. Standards Track [Page 148] RFC 3261 SIP: Session Initiation Protocol June 2002 destination host does not have a notion of users or when the host itself is the resource being identified. If the @ sign is present in a SIP or SIPS URI, the user field MUST NOT be empty. If the host being addressed can process telephone numbers, for instance, an Internet telephony gateway, a telephone- subscriber field defined in RFC 2806 [9] MAY be used to populate the user field. There are special escaping rules for encoding telephone-subscriber fields in SIP and SIPS URIs described in Section 19.1.2. password: A password associated with the user. While the SIP and SIPS URI syntax allows this field to be present, its use is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URIs) has proven to be a security risk in almost every case where it has been used. For instance, transporting a PIN number in this field exposes the PIN. Note that the password field is just an extension of the user portion. Implementations not wishing to give special significance to the password portion of the field MAY simply treat ""user:password"" as a single string. host: The host providing the SIP resource. The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is RECOMMENDED whenever possible. port: The port number where the request is to be sent. URI parameters: Parameters affecting a request constructed from the URI. URI parameters are added after the hostport component and are separated by semi-colons. URI parameters take the form: parameter-name ""="" parameter-value Even though an arbitrary number of URI parameters may be included in a URI, any given parameter-name MUST NOT appear more than once. This extensible mechanism includes the transport, maddr, ttl, user, method and lr parameters. Rosenberg, et. al. Standards Track [Page 149] RFC 3261 SIP: Session Initiation Protocol June 2002 The transport parameter determines the transport mechanism to be used for sending SIP messages, as specified in [4]. SIP can use any network transport protocol. Parameter names are defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST indicate a reliable transport. The maddr parameter indicates the server address to be contacted for this user, overriding any address derived from the host field. When an maddr parameter is present, the port and transport components of the URI apply to the address indicated in the maddr parameter value. [4] describes the proper interpretation of the transport, maddr, and hostport in order to obtain the destination address, port, and transport for sending a request. The maddr field has been used as a simple form of loose source routing. It allows a URI to specify a proxy that must be traversed en-route to the destination. Continuing to use the maddr parameter this way is strongly discouraged (the mechanisms that enable it are deprecated). Implementations should instead use the Route mechanism described in this document, establishing a pre-existing route set if necessary (see Section 8.1.1.1). This provides a full URI to describe the node to be traversed. The ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP. For example, to specify a call to alice@atlanta.com using multicast to 239.255.255.1 with a ttl of 15, the following URI would be used: sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value ""phone"" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it. The method of the SIP request constructed from the URI can be specified with the method parameter. Rosenberg, et. al. Standards Track [Page 150] RFC 3261 SIP: Session Initiation Protocol June 2002 The lr parameter, when present, indicates that the element responsible for this resource implements the routing mechanisms specified in this document. This parameter will be used in the URIs proxies place into Record-Route header field values, and may appear in the URIs in a pre-existing route set. This parameter is used to achieve backwards compatibility with systems implementing the strict-routing mechanisms of RFC 2543 and the rfc2543bis drafts up to bis-05. An element preparing to send a request based on a URI not containing this parameter can assume the receiving element implements strict-routing and reformat the message to preserve the information in the Request-URI. Since the uri-parameter mechanism is extensible, SIP elements MUST silently ignore any uri-parameters that they do not understand. Headers: Header fields to be included in a request constructed from the URI. Headers fields in the SIP request can be specified with the ""?"" mechanism within a URI. The header names and values are encoded in ampersand separated hname = hvalue pairs. The special hname ""body"" indicates that the associated hvalue is the message-body of the SIP request. Table 1 summarizes the use of SIP and SIPS URI components based on the context in which the URI appears. The external column describes URIs appearing anywhere outside of a SIP message, for instance on a web page or business card. Entries marked ""m"" are mandatory, those marked ""o"" are optional, and those marked ""-"" are not allowed. Elements processing URIs SHOULD ignore any disallowed components if they are present. The second column indicates the default value of an optional element if it is not present. ""--"" indicates that the element is either not optional, or has no default value. URIs in Contact header fields have different restrictions depending on the context in which the header field appears. One set applies to messages that establish and maintain dialogs (INVITE and its 200 (OK) response). The other applies to registration and redirection messages (REGISTER, its 200 (OK) response, and 3xx class responses to any method). Rosenberg, et. al. Standards Track [Page 151] RFC 3261 SIP: Session Initiation Protocol June 2002 19.1.2 Character Escaping Requirements dialog reg./redir. Contact/ default Req.-URI To From Contact R-R/Route external user -- o o o o o o password -- o o o o o o host -- m m m m m m port (1) o - - o o o user-param ip o o o o o o method INVITE - - - - - o maddr-param -- o - - o o o ttl-param 1 o - - o - o transp.-param (2) o - - o o o lr-param -- o - - - o o other-param -- o o o o o o headers -- - - - o - o (1): The default port value is transport and scheme dependent. The default is 5060 for sip: using UDP, TCP, or SCTP. The default is 5061 for sip: using TLS over TCP and sips: over TCP. (2): The default transport is scheme dependent. For sip:, it is UDP. For sips:, it is TCP. Table 1: Use and default values of URI components for SIP header field values, Request-URI and references SIP follows the requirements and guidelines of RFC 2396 [5] when defining the set of characters that must be escaped in a SIP URI, and uses its """"%"" HEX HEX"" mechanism for escaping. From RFC 2396 [5]: The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding [5]. Excluded US- ASCII characters (RFC 2396 [5]), such as space and control characters and characters used as URI delimiters, also MUST be escaped. URIs MUST NOT contain unescaped space and control characters. For each component, the set of valid BNF expansions defines exactly which characters may appear unescaped. All other characters MUST be escaped. For example, ""@"" is not in the set of characters in the user component, so the user ""j@s0n"" must have at least the @ sign encoded, as in ""j%40s0n"". Rosenberg, et. al. Standards Track [Page 152] RFC 3261 SIP: Session Initiation Protocol June 2002 Expanding the hname and hvalue tokens in Section 25 show that all URI reserved characters in header field names and values MUST be escaped. The telephone-subscriber subset of the user component has special escaping considerations. The set of characters not reserved in the RFC 2806 [9] description of telephone-subscriber contains a number of characters in various syntax elements that need to be escaped when used in SIP URIs. Any characters occurring in a telephone-subscriber that do not appear in an expansion of the BNF for the user rule MUST be escaped. Note that character escaping is not allowed in the host component of a SIP or SIPS URI (the % character is not valid in its expansion). This is likely to change in the future as requirements for Internationalized Domain Names are finalized. Current implementations MUST NOT attempt to improve robustness by treating received escaped characters in the host component as literally equivalent to their unescaped counterpart. The behavior required to meet the requirements of IDN may be significantly different. 19.1.3 Example SIP and SIPS URIs sip:alice@atlanta.com sip:alice:secretword@atlanta.com;transport=tcp sips:alice@atlanta.com?subject=project%20x&priority=urgent sip:+1-212-555-1212:1234@gateway.com;user=phone sips:1212@gateway.com sip:alice@192.0.2.4 sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com sip:alice;day=tuesday@atlanta.com The last sample URI above has a user field value of ""alice;day=tuesday"". The escaping rules defined above allow a semicolon to appear unescaped in this field. For the purposes of this protocol, the field is opaque. The structure of that value is only useful to the SIP element responsible for the resource. 19.1.4 URI Comparison Some operations in this specification require determining whether two SIP or SIPS URIs are equivalent. In this specification, registrars need to compare bindings in Contact URIs in REGISTER requests (see Section 10.3.). SIP and SIPS URIs are compared for equality according to the following rules: o A SIP and SIPS URI are never equivalent. Rosenberg, et. al. Standards Track [Page 153] RFC 3261 SIP: Session Initiation Protocol June 2002 o Comparison of the userinfo of SIP and SIPS URIs is case- sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise. o The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs. o Characters other than those in the ""reserved"" set (see RFC 2396 [5]) are equivalent to their """"%"" HEX HEX"" encoding. o An IP address that is the result of a DNS lookup of a host name does not match that host name. o For two URIs to be equal, the user, password, host, and port components must match. A URI omitting the user component will not match a URI that includes one. A URI omitting the password component will not match a URI that includes one. A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value. For instance, a URI omitting the optional port component will not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-parameter, user-parameter, and method components. Defining sip:user@host to not be equivalent to sip:user@host:5060 is a change from RFC 2543. When deriving addresses from URIs, equivalent addresses are expected from equivalent URIs. The URI sip:user@host:5060 will always resolve to port 5060. The URI sip:user@host may resolve to other ports through the DNS SRV mechanisms detailed in [4]. o URI uri-parameter components are compared as follows: - Any uri-parameter appearing in both URIs must match. - A user, ttl, or method uri-parameter appearing in only one URI never matches, even if it contains the default value. - A URI that includes an maddr parameter will not match a URI that contains no maddr parameter. - All other uri-parameters appearing in only one URI are ignored when comparing the URIs. Rosenberg, et. al. Standards Track [Page 154] RFC 3261 SIP: Session Initiation Protocol June 2002 o URI header components are never ignored. Any present header component MUST be present in both URIs and match for the URIs to match. The matching rules are defined for each header field in Section 20. The URIs within each of the following sets are equivalent: sip:%61lice@atlanta.com;transport=TCP sip:alice@AtLanTa.CoM;Transport=tcp sip:carol@chicago.com sip:carol@chicago.com;newparam=5 sip:carol@chicago.com;security=on sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com sip:alice@atlanta.com?subject=project%20x&priority=urgent sip:alice@atlanta.com?priority=urgent&subject=project%20x The URIs within each of the following sets are not equivalent: SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) sip:alice@AtLanTa.CoM;Transport=UDP sip:bob@biloxi.com (can resolve to different ports) sip:bob@biloxi.com:5060 sip:bob@biloxi.com (can resolve to different transports) sip:bob@biloxi.com;transport=udp sip:bob@biloxi.com (can resolve to different port and transports) sip:bob@biloxi.com:6000;transport=tcp sip:carol@chicago.com (different header component) sip:carol@chicago.com?Subject=next%20meeting sip:bob@phone21.boxesbybob.com (even though that's what sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) Note that equality is not transitive: o sip:carol@chicago.com and sip:carol@chicago.com;security=on are equivalent o sip:carol@chicago.com and sip:carol@chicago.com;security=off are equivalent Rosenberg, et. al. Standards Track [Page 155] RFC 3261 SIP: Session Initiation Protocol June 2002 o sip:carol@chicago.com;security=on and sip:carol@chicago.com;security=off are not equivalent 19.1.5 Forming Requests from a URI An implementation needs to take care when forming requests directly from a URI. URIs from business cards, web pages, and even from sources inside the protocol such as registered contacts may contain inappropriate header fields or body parts. An implementation MUST include any provided transport, maddr, ttl, or user parameter in the Request-URI of the formed request. If the URI contains a method parameter, its value MUST be used as the method of the request. The method parameter MUST NOT be placed in the Request-URI. Unknown URI parameters MUST be placed in the message's Request-URI. An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis. An implementation SHOULD NOT honor these obviously dangerous header fields: From, Call-ID, CSeq, Via, and Record-Route. An implementation SHOULD NOT honor any requested Route header field values in order to not be used as an unwitting agent in malicious attacks. An implementation SHOULD NOT honor requests to include header fields that may cause it to falsely advertise its location or capabilities. These include: Accept, Accept-Encoding, Accept-Language, Allow, Contact (in its dialog usage), Organization, Supported, and User- Agent. An implementation SHOULD verify the accuracy of any requested descriptive header fields, including: Content-Disposition, Content- Encoding, Content-Language, Content-Length, Content-Type, Date, Mime-Version, and Timestamp. If the request formed from constructing a message from a given URI is not a valid SIP request, the URI is invalid. An implementation MUST NOT proceed with transmitting the request. It should instead pursue the course of action due an invalid URI in the context it occurs. The constructed request can be invalid in many ways. These include, but are not limited to, syntax error in header fields, invalid combinations of URI parameters, or an incorrect description of the message body. Rosenberg, et. al. Standards Track [Page 156] RFC 3261 SIP: Session Initiation Protocol June 2002 Sending a request formed from a given URI may require capabilities unavailable to the implementation. The URI might indicate use of an unimplemented transport or extension, for example. An implementation SHOULD refuse to send these requests rather than modifying them to match their capabilities. An implementation MUST NOT send a request requiring an extension that it does not support. For example, such a request can be formed through the presence of a Require header parameter or a method URI parameter with an unknown or explicitly unsupported value. 19.1.6 Relating SIP URIs and tel URLs When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI. Thus, tel:+358-555-1234567;postd=pp22 becomes sip:+358-555-1234567;postd=pp22@foo.com;user=phone or sips:+358-555-1234567;postd=pp22@foo.com;user=phone not sip:+358-555-1234567@foo.com;postd=pp22;user=phone or sips:+358-555-1234567@foo.com;postd=pp22;user=phone In general, equivalent ""tel"" URLs converted to SIP or SIPS URIs in this fashion may not produce equivalent SIP or SIPS URIs. The userinfo of SIP and SIPS URIs are compared as a case-sensitive string. Variance in case-insensitive portions of tel URLs and reordering of tel URL parameters does not affect tel URL equivalence, but does affect the equivalence of SIP URIs formed from them. For example, tel:+358-555-1234567;postd=pp22 tel:+358-555-1234567;POSTD=PP22 are equivalent, while sip:+358-555-1234567;postd=pp22@foo.com;user=phone sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone Rosenberg, et. al. Standards Track [Page 157] RFC 3261 SIP: Session Initiation Protocol June 2002 are not. Likewise, tel:+358-555-1234567;postd=pp22;isub=1411 tel:+358-555-1234567;isub=1411;postd=pp22 are equivalent, while sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone are not. To mitigate this problem, elements constructing telephone-subscriber fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold any case-insensitive portion of telephone-subscriber to lower case, and order the telephone-subscriber parameters lexically by parameter name, excepting isdn-subaddress and post-dial, which occur first and in that order. (All components of a tel URL except for future- extension parameters are defined to be compared case-insensitive.) Following this suggestion, both tel:+358-555-1234567;postd=pp22 tel:+358-555-1234567;POSTD=PP22 become sip:+358-555-1234567;postd=pp22@foo.com;user=phone and both tel:+358-555-1234567;tsp=a.b;phone-context=5 tel:+358-555-1234567;phone-context=5;tsp=a.b become sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone 19.2 Option Tags Option tags are unique identifiers used to designate new options (extensions) in SIP. These tags are used in Require (Section 20.32), Proxy-Require (Section 20.29), Supported (Section 20.37) and Unsupported (Section 20.40) header fields. Note that these options appear as parameters in those header fields in an option-tag = token form (see Section 25 for the definition of token). Rosenberg, et. al. Standards Track [Page 158] RFC 3261 SIP: Session Initiation Protocol June 2002 Option tags are defined in standards track RFCs. This is a change from past practice, and is instituted to ensure continuing multi- vendor interoperability (see discussion in Section 20.32 and Section 20.37). An IANA registry of option tags is used to ensure easy reference. 19.3 Tags The ""tag"" parameter is used in the To and From header fields of SIP messages. It serves as a general mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from each participant in the dialog. When a UA sends a request outside of a dialog, it contains a From tag only, providing ""half"" of the dialog ID. The dialog is completed from the response(s), each of which contributes the second half in the To header field. The forking of SIP requests means that multiple dialogs can be established from a single request. This also explains the need for the two-sided dialog identifier; without a contribution from the recipients, the originator could not disambiguate the multiple dialogs established from a single request. When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. A property of this selection requirement is that a UA will place a different tag into the From header of an INVITE than it would place into the To header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a common case for ""hairpinning"" of calls in PSTN gateways. Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags. Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation-specific. Tags are helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server after a failure. A UAS can select the tag in such a way that a backup can recognize a request as part of a dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other state associated with it. 20 Header Fields The general syntax for header fields is covered in Section 7.3. This section lists the full set of header fields along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 [8]. Examples of each header field are given. Rosenberg, et. al. Standards Track [Page 159] RFC 3261 SIP: Session Initiation Protocol June 2002 Information about header fields in relation to methods and proxy processing is summarized in Tables 2 and 3. The ""where"" column describes the request and response types in which the header field can be used. Values in this column are: R: header field may only appear in requests; r: header field may only appear in responses; 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; c: header field is copied from the request to the response. An empty entry in the ""where"" column indicates that the header field may be present in all requests and responses. The ""proxy"" column describes the operations a proxy may perform on a header field: a: A proxy can add or concatenate the header field if not present. m: A proxy can modify an existing header field value. d: A proxy can delete a header field value. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. The next six columns relate to the presence of a header field in a method: c: Conditional; requirements on the header field depend on the context of the message. m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: The header field is optional. t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent. Rosenberg, et. al. Standards Track [Page 160] RFC 3261 SIP: Session Initiation Protocol June 2002 *: The header field is required if the message body is not empty. See Sections 20.14, 20.15 and 7.4 for details. -: The header field is not applicable. ""Optional"" means that an element MAY include the header field in a request or response, and a UA MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 20.32). A ""mandatory"" header field MUST be present in a request, and MUST be understood by the UAS receiving the request."
"A mandatory response header field MUST be present in the response, and the header field MUST be understood by the UAC processing the response. ""Not applicable"" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request. Similarly, a header field labeled ""not applicable"" for a response means that the UAS MUST NOT place the header field in the response, and the UAC MUST ignore the header field in the response. A UA SHOULD ignore extension header parameters that are not understood. A compact form of some common header field names is also defined for use when overall message size is an issue. The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. 20.1 Accept The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server SHOULD assume a default value of application/sdp. An empty Accept header field means that no formats are acceptable. Rosenberg, et. al. Standards Track [Page 161] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alert-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * CSeq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Table 2: Summary of header fields, A--O Rosenberg, et. al. Standards Track [Page 162] RFC 3261 SIP: Session Initiation Protocol June 2002 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o Table 3: Summary of header fields, P--Z; (1): copied with possible addition of tag Accept: application/sdp;level=1, application/x-private, text/html 20.2 Accept-Encoding The Accept-Encoding header field is similar to Accept, but restricts the content-codings [H3.5] that are acceptable in the response. See [H14.3]. The semantics in SIP are identical to those defined in [H14.3]. An empty Accept-Encoding header field is permissible. It is equivalent to Accept-Encoding: identity, that is, only the identity encoding, meaning no encoding, is permissible. If no Accept-Encoding header field is present, the server SHOULD assume a default value of identity. Rosenberg, et. al. Standards Track [Page 163] RFC 3261 SIP: Session Initiation Protocol June 2002 This differs slightly from the HTTP definition, which indicates that when not present, any encoding can be used, but the identity encoding is preferred. Example: Accept-Encoding: gzip 20.3 Accept-Language The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-Language header field is present, the server SHOULD assume all languages are acceptable to the client. The Accept-Language header field follows the syntax defined in [H14.4]. The rules for ordering the languages based on the ""q"" parameter apply to SIP as well. Example: Accept-Language: da, en-gb;q=0.8, en;q=0.7 20.4 Alert-Info When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS. When present in a 180 (Ringing) response, the Alert-Info header field specifies an alternative ringback tone to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature. The Alert-Info header field can introduce security risks. These risks and the ways to handle them are discussed in Section 20.9, which discusses the Call-Info header field since the risks are identical. In addition, a user SHOULD be able to disable this feature selectively. This helps prevent disruptions that could result from the use of this header field by untrusted elements. Example: Alert-Info: <http://www.example.com/sounds/moo.wav> Rosenberg, et. al. Standards Track [Page 164] RFC 3261 SIP: Session Initiation Protocol June 2002 20.5 Allow The Allow header field lists the set of methods supported by the UA generating the message. All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. The absence of an Allow header field MUST NOT be interpreted to mean that the UA sending the message supports no methods. Rather, it implies that the UA is not providing any information on what methods it supports. Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of messages needed. Example: Allow: INVITE, ACK, OPTIONS, CANCEL, BYE 20.6 Authentication-Info The Authentication-Info header field provides for mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field. Syntax and semantics follow those specified in RFC 2617 [17]. Example: Authentication-Info: nextnonce=""47364c23432d2e131a5fb210812c"" 20.7 Authorization The Authorization header field contains authentication credentials of a UA. Section 22.2 overviews the use of the Authorization header field, and Section 22.4 describes the syntax and semantics when used with HTTP authentication. This header field, along with Proxy-Authorization, breaks the general rules about multiple header field values. Although not a comma- separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line using the usual rules described in Section 7.3. Rosenberg, et. al. Standards Track [Page 165] RFC 3261 SIP: Session Initiation Protocol June 2002 In the example below, there are no quotes around the Digest parameter: Authorization: Digest username=""Alice"", realm=""atlanta.com"", nonce=""84a4cc6f3082121f32b42a2187831a9e"", response=""7587245234b3434cc3412213e5f113a5432"" 20.8 Call-ID The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte. The compact form of the Call-ID header field is i. Examples: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the ""purpose"" parameter. The ""icon"" parameter designates an image suitable as an iconic representation of the caller or callee. The ""info"" parameter describes the caller or callee in general, for example, through a web page. The ""card"" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, <http://www.example.com/alice/> ;purpose=info Rosenberg, et. al. Standards Track [Page 166] RFC 3261 SIP: Session Initiation Protocol June 2002 20.10 Contact A Contact header field value provides a URI whose meaning depends on the type of request or response it is in. A Contact header field value can contain a display name, a URI with URI parameters, and header parameters. This document defines the Contact parameters ""q"" and ""expires"". These parameters are only used when the Contact is present in a REGISTER request or response, or in a 3xx response. Additional parameters may be defined in other specifications. When the header field value contains a display name, the URI including all URI parameters is enclosed in ""<"" and "">"". If no ""<"" and "">"" are present, all parameters after the URI are header parameters, not URI parameters. The display name can be tokens, or a quoted string, if a larger character set is desired. Even if the ""display-name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, semicolon, or question mark. There may or may not be LWS between the display-name and the ""<"". These rules for parsing a display name, URI and URI parameters, and header parameters also apply for the header fields To and From. The Contact header field has a role similar to the Location header field in HTTP. However, the HTTP header field only allows one address, unquoted. Since URIs can contain commas and semicolons as reserved characters, they can be mistaken for header or parameter delimiters, respectively. The compact form of the Contact header field is m (for ""moved""). Examples: Contact: ""Mr. Watson"" <sip:watson@worcester.bell-telephone.com> ;q=0.7; expires=3600, ""Mr. Watson"" <mailto:watson@bell-telephone.com> ;q=0.1 m: <sips:bob@192.0.2.4>;expires=60 Rosenberg, et. al. Standards Track [Page 167] RFC 3261 SIP: Session Initiation Protocol June 2002 20.11 Content-Disposition The Content-Disposition header field describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS. This SIP header field extends the MIME Content- Type (RFC 2183 [18]). Several new ""disposition-types"" of the Content-Disposition header are defined by SIP. The value ""session"" indicates that the body part describes a session, for either calls or early (pre-call) media. The value ""render"" indicates that the body part should be displayed or otherwise rendered to the user. Note that the value ""render"" is used rather than ""inline"" to avoid the connotation that the MIME body is displayed as a part of the rendering of the entire message (since the MIME bodies of SIP messages oftentimes are not displayed to users). For backward-compatibility, if the Content-Disposition header field is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition ""session"", while other content types are ""render"". The disposition type ""icon"" indicates that the body part contains an image suitable as an iconic representation of the caller or callee that could be rendered informationally by a user agent when a message has been received, or persistently while a dialog takes place. The value ""alert"" indicates that the body part contains information, such as an audio clip, that should be rendered by the user agent in an attempt to alert the user to the receipt of a request, generally a request that initiates a dialog; this alerting body could for example be rendered as a ring tone for a phone call after a 180 Ringing provisional response has been sent. Any MIME body with a ""disposition-type"" that renders content to the user should only be processed when a message has been properly authenticated. The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of ""optional"" and ""required"". If the handling parameter is missing, the value ""required"" SHOULD be assumed. The handling parameter is described in RFC 3204 [19]. If this header field is missing, the MIME type determines the default content disposition. If there is none, ""render"" is assumed. Example: Content-Disposition: session Rosenberg, et. al. Standards Track [Page 168] RFC 3261 SIP: Session Initiation Protocol June 2002 20.12 Content-Encoding The Content-Encoding header field is used as a modifier to the ""media-type"". When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms MUST be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a body to be compressed without losing the identity of its underlying media type. If multiple encodings have been applied to an entity-body, the content codings MUST be listed in the order in which they were applied. All content-coding values are case-insensitive. IANA acts as a registry for content-coding value tokens. See [H3.5] for a definition of the syntax for content-coding. Clients MAY apply content encodings to the body in requests. A server MAY apply content encodings to the bodies in responses. The server MUST only use encodings listed in the Accept-Encoding header field in the request. The compact form of the Content-Encoding header field is e. Examples: Content-Encoding: gzip e: tar 20.13 Content-Language See [H14.12]. Example: Content-Language: fr 20.14 Content-Length The Content-Length header field indicates the size of the message- body, in decimal number of octets, sent to the recipient. Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as transport, the header field MUST be used. The size of the message-body does not include the CRLF separating header fields and body. Any Content-Length greater than or equal to zero is a valid value. If no body is present in a message, then the Content-Length header field value MUST be set to zero. Rosenberg, et. al. Standards Track [Page 169] RFC 3261 SIP: Session Initiation Protocol June 2002 The ability to omit Content-Length simplifies the creation of cgi-like scripts that dynamically generate responses. The compact form of the header field is l. Examples: Content-Length: 349 l: 173 20.15 Content-Type The Content-Type header field indicates the media type of the message-body sent to the recipient. The ""media-type"" element is defined in [H3.7]. The Content-Type header field MUST be present if the body is not empty. If the body is empty, and a Content-Type header field is present, it indicates that the body of the specific type has zero length (for example, an empty audio file). The compact form of the header field is c. Examples: Content-Type: application/sdp c: text/html; charset=ISO-8859-4 20.16 CSeq A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical. Example: CSeq: 4711 INVITE 20.17 Date The Date header field contains the date and time. Unlike HTTP/1.1, SIP only supports the most recent RFC 1123 [20] format for dates. As in [H3.3], SIP restricts the time zone in SIP-date to ""GMT"", while RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. The Date header field reflects the time when the request or response is first sent. Rosenberg, et. al. Standards Track [Page 170] RFC 3261 SIP: Session Initiation Protocol June 2002 The Date header field can be used by simple end systems without a battery-backed clock to acquire a notion of current time. However, in its GMT form, it requires clients to know their offset from GMT. Example: Date: Sat, 13 Nov 2010 23:29:00 GMT 20.18 Error-Info The Error-Info header field provides a pointer to additional information about the error status response. SIP UACs have user interface capabilities ranging from pop-up windows and audio on PC softclients to audio-only on ""black"" phones or endpoints connected via gateways. Rather than forcing a server generating an error to choose between sending an error status code with a detailed reason phrase and playing an audio recording, the Error-Info header field allows both to be sent. The UAC then has the choice of which error indicator to render to the caller. A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if it were a Contact in a redirect and generate a new INVITE, resulting in a recorded announcement session being established. A non-SIP URI MAY be rendered to the user. Examples: SIP/2.0 404 The number you have dialed is not in service Error-Info: <sip:not-in-service-recording@atlanta.com> 20.19 Expires The Expires header field gives the relative time after which the message (or content) expires. The precise meaning of this is method dependent. The expiration time in an INVITE does not affect the duration of the actual session that may result from the invitation. Session description protocols may offer the ability to express time limits on the session duration, however. The value of this field is an integral number of seconds (in decimal) between 0 and (2**32)-1, measured from the receipt of the request. Rosenberg, et. al. Standards Track [Page 171] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Expires: 5 20.20 From The From header field indicates the initiator of the request. This may be different from the initiator of the dialog. Requests sent by the callee to the caller use the callee's address in the From header field. The optional ""display-name"" is meant to be rendered by a human user interface. A system SHOULD use the display name ""Anonymous"" if the identity of the client is to remain hidden. Even if the ""display- name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. Two From header fields are equivalent if their URIs match, and their parameters match. Extension parameters in one header field, not present in the other are ignored for the purposes of comparison. This means that the display name and presence or absence of angle brackets do not affect matching. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters. The compact form of the From header field is f. Examples: From: ""A. G. Bell"" <sip:agb@bell-telephone.com> ;tag=a48s From: sip:+12125551212@server.phone2net.com;tag=887s f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 20.21 In-Reply-To The In-Reply-To header field enumerates the Call-IDs that this call references or returns. These Call-IDs may have been cached by the client then included in this header field in a return call. This allows automatic call distribution systems to route return calls to the originator of the first call. This also allows callees to filter calls, so that only return calls for calls they originated will be accepted. This field is not a substitute for request authentication. Rosenberg, et. al. Standards Track [Page 172] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com 20.22 Max-Forwards The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain. The Max-Forwards value is an integer in the range 0-255 indicating the remaining number of times this request message is allowed to be forwarded. This count is decremented by each server that forwards the request. The recommended initial value is 70. This header field should be inserted by elements that can not otherwise guarantee loop detection. For example, a B2BUA should insert a Max-Forwards header field. Example: Max-Forwards: 6 20.23 Min-Expires The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server. This includes Contact header fields that are stored by a registrar. The header field contains a decimal integer number of seconds from 0 to (2**32)-1. The use of the header field in a 423 (Interval Too Brief) response is described in Sections 10.2.8, 10.3, and 21.4.17. Example: Min-Expires: 60 20.24 MIME-Version See [H19.4.1]. Example: MIME-Version: 1.0 Rosenberg, et. al. Standards Track [Page 173] RFC 3261 SIP: Session Initiation Protocol June 2002 20.25 Organization The Organization header field conveys the name of the organization to which the SIP element issuing the request or response belongs. The field MAY be used by client software to filter calls. Example: Organization: Boxes by Bob 20.26 Priority The Priority header field indicates the urgency of the request as perceived by the client. The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. For these decisions, a message containing no Priority header field SHOULD be treated as if it specified a Priority of ""normal"". The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways. The header field can have the values ""non-urgent"", ""normal"", ""urgent"", and ""emergency"", but additional values can be defined elsewhere. It is RECOMMENDED that the value of ""emergency"" only be used when life, limb, or property are in imminent danger. Otherwise, there are no semantics defined for this header field. These are the values of RFC 2076 [38], with the addition of ""emergency"". Examples: Subject: A tornado is heading our way! Priority: emergency or Subject: Weekend plans Priority: non-urgent 20.27 Proxy-Authenticate A Proxy-Authenticate header field value contains an authentication challenge. The use of this header field is defined in [H14.33]. See Section 22.3 for further details on its usage. Rosenberg, et. al. Standards Track [Page 174] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Proxy-Authenticate: Digest realm=""atlanta.com"", domain=""sip:ss1.carrier.com"", qop=""auth"", nonce=""f84f1cec41e6cbe5aea9c8e88d359"", opaque="""", stale=FALSE, algorithm=MD5 20.28 Proxy-Authorization The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication. A Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. See Section 22.3 for a definition of the usage of this header field. This header field, along with Authorization, breaks the general rules about multiple header field names. Although not a comma-separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line using the usual rules described in Section 7.3.1. Example: Proxy-Authorization: Digest username=""Alice"", realm=""atlanta.com"", nonce=""c60f3082ee1212b402a21831ae"", response=""245f23415f11432b3434341c022"" 20.29 Proxy-Require The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the proxy. See Section 20.32 for more details on the mechanics of this message and a usage example. Example: Proxy-Require: foo 20.30 Record-Route The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy. Examples of its use with the Route header field are described in Sections 16.12.1. Rosenberg, et. al. Standards Track [Page 175] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Record-Route: <sip:server10.biloxi.com;lr>, <sip:bigbox3.site3.atlanta.com;lr> 20.31 Reply-To The Reply-To header field contains a logical return URI that may be different from the From header field. For example, the URI MAY be used to return missed calls or unestablished sessions. If the user wished to remain anonymous, the header field SHOULD either be omitted from the request or populated in such a way that does not reveal any private information. Even if the ""display-name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. Example: Reply-To: Bob <sip:bob@biloxi.com> 20.32 Require The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. Although an optional header field, the Require MUST NOT be ignored if it is present. The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs. Example: Require: 100rel 20.33 Retry-After The Retry-After header field can be used with a 500 (Server Internal Error) or 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client and with a 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 Rosenberg, et. al. Standards Track [Page 176] RFC 3261 SIP: Session Initiation Protocol June 2002 (Decline) response to indicate when the called party anticipates being available again. The value of this field is a positive integer number of seconds (in decimal) after the time of the response. An optional comment can be used to indicate additional information about the time of callback. An optional ""duration"" parameter indicates how long the called party will be reachable starting at the initial time of availability. If no duration parameter is given, the service is assumed to be available indefinitely. Examples: Retry-After: 18000;duration=3600 Retry-After: 120 (I'm in a meeting) 20.34 Route The Route header field is used to force routing for a request through the listed set of proxies. Examples of the use of the Route header field are in Section 16.12.1. Example: Route: <sip:bigbox3.site3.atlanta.com;lr>, <sip:server10.biloxi.com;lr> 20.35 Server The Server header field contains information about the software used by the UAS to handle the request. Revealing the specific software version of the server might allow the server to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the Server header field a configurable option. Example: Server: HomeServer v2 20.36 Subject The Subject header field provides a summary or indicates the nature of the call, allowing call filtering without having to parse the session description. The session description does not have to use the same subject indication as the invitation. The compact form of the Subject header field is s. Rosenberg, et. al. Standards Track [Page 177] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Subject: Need more boxes s: Tech Support 20.37 Supported The Supported header field enumerates all the extensions supported by the UAC or UAS. The Supported header field contains a list of option tags, described in Section 19.2, that are understood by the UAC or UAS. A UA compliant to this specification MUST only include option tags corresponding to standards-track RFCs. If empty, it means that no extensions are supported. The compact form of the Supported header field is k. Example: Supported: 100rel 20.38 Timestamp The Timestamp header field describes when the UAC sent the request to the UAS. See Section 8.2.6 for details on how to generate a response to a request that contains the header field. Although there is no normative behavior defined here that makes use of the header, it allows for extensions or SIP applications to obtain RTT estimates. Example: Timestamp: 54 20.39 To The To header field specifies the logical recipient of the request. The optional ""display-name"" is meant to be rendered by a human-user interface. The ""tag"" parameter serves as a general mechanism for dialog identification. See Section 19.3 for details of the ""tag"" parameter. Rosenberg, et. al. Standards Track [Page 178] RFC 3261 SIP: Session Initiation Protocol June 2002 Comparison of To header fields for equality is identical to comparison of From header fields. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters. The compact form of the To header field is t. The following are examples of valid To header fields: To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 t: sip:+12125551212@server.phone2net.com 20.40 Unsupported The Unsupported header field lists the features not supported by the UAS. See Section 20.32 for motivation. Example: Unsupported: foo 20.41 User-Agent The User-Agent header field contains information about the UAC originating the request. The semantics of this header field are defined in [H14.43]. Revealing the specific software version of the user agent might allow the user agent to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the User-Agent header field a configurable option. Example: User-Agent: Softphone Beta1.5 20.42 Via The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses. The branch ID parameter in the Via header field values serves as a transaction identifier, and is used by proxies to detect loops. A Via header field value contains the transport protocol used to send the message, the client's host name or network address, and possibly the port number at which it wishes to receive responses. A Via header field value can also contain parameters such as ""maddr"", ""ttl"", ""received"", and ""branch"", whose meaning and use are described Rosenberg, et. al. Standards Track [Page 179] RFC 3261 SIP: Session Initiation Protocol June 2002 in other sections. For implementations compliant to this specification, the value of the branch parameter MUST start with the magic cookie ""z9hG4bK"", as discussed in Section 8.1.1.7. Transport protocols defined here are ""UDP"", ""TCP"", ""TLS"", and ""SCTP"". ""TLS"" means TLS over TCP. When a request is sent to a SIPS URI, the protocol still indicates ""SIP"", and the transport protocol is TLS. Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 ;branch=z9hG4bK77asjd The compact form of the Via header field is v. In this example, the message originated from a multi-homed host with two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong as to which network interface would be used. Erlang.bell- telephone.com noticed the mismatch and added a parameter to the previous hop's Via header field value, containing the address that the packet actually came from. The host or network address and port number are not required to follow the SIP URI syntax. Specifically, LWS on either side of the "":"" or ""/"" is allowed, as shown here: Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 Even though this specification mandates that the branch parameter be present in all requests, the BNF for the header field indicates that it is optional. This allows interoperation with RFC 2543 elements, which did not have to insert the branch parameter. Two Via header fields are equal if their sent-protocol and sent-by fields are equal, both have the same set of parameters, and the values of all parameters are equal. 20.43 Warning The Warning header field is used to carry additional information about the status of a response. Warning header field values are sent with responses and contain a three-digit warning code, host name, and warning text. The ""warn-text"" should be in a natural language that is most likely to be intelligible to the human user receiving the response. This decision can be based on any available knowledge, such as the location of the user, the Accept-Language field in a request, or the Rosenberg, et. al. Standards Track [Page 180] RFC 3261 SIP: Session Initiation Protocol June 2002 Content-Language field in a response. The default language is i- default [21]. The currently-defined ""warn-code""s are listed below, with a recommended warn-text in English and a description of their meaning. These warnings describe failures induced by the session description. The first digit of warning codes beginning with ""3"" indicates warnings specific to SIP. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories. 300 Incompatible network protocol: One or more network protocols contained in the session description are not available. 301 Incompatible network address formats: One or more network address formats contained in the session description are not available. 302 Incompatible transport protocol: One or more transport protocols described in the session description are not available. 303 Incompatible bandwidth units: One or more bandwidth measurement units contained in the session description were not understood. 304 Media type not available: One or more media types contained in the session description are not available. 305 Incompatible media format: One or more media formats contained in the session description are not available. 306 Attribute not understood: One or more of the media attributes in the session description are not supported. 307 Session description parameter not understood: A parameter other than those listed above was not understood. 330 Multicast not available: The site where the user is located does not support multicast. 331 Unicast not available: The site where the user is located does not support unicast communication (usually due to the presence of a firewall). Rosenberg, et. al. Standards Track [Page 181] RFC 3261 SIP: Session Initiation Protocol June 2002 370 Insufficient bandwidth: The bandwidth specified in the session description or defined by the media exceeds that known to be available. 399 Miscellaneous warning: The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action. 1xx and 2xx have been taken by HTTP/1.1. Additional ""warn-code""s can be defined through IANA, as defined in Section 27.2. Examples: Warning: 307 isi.edu ""Session parameter 'foo' not understood"" Warning: 301 isi.edu ""Incompatible network address type 'E.164'"" 20.44 WWW-Authenticate A WWW-Authenticate header field value contains an authentication challenge. See Section 22.2 for further details on its usage. Example: WWW-Authenticate: Digest realm=""atlanta.com"", domain=""sip:boxesbybob.com"", qop=""auth"", nonce=""f84f1cec41e6cbe5aea9c8e88d359"", opaque="""", stale=FALSE, algorithm=MD5 21 Response Codes The response codes are consistent with, and extend, HTTP/1.1 response codes. Not all HTTP/1.1 response codes are appropriate, and only those that are appropriate are given here. Other HTTP/1.1 response codes SHOULD NOT be used. Also, SIP defines a new class, 6xx. 21.1 Provisional 1xx Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response. Note that 1xx responses are not transmitted reliably. They never cause the client to send an ACK. Provisional (1xx) responses MAY contain message bodies, including session descriptions. Rosenberg, et. al."
"Standards Track [Page 182] RFC 3261 SIP: Session Initiation Protocol June 2002 21.1.1 100 Trying This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC. The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy. 21.1.2 180 Ringing The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback. 21.1.3 181 Call Is Being Forwarded A server MAY use this status code to indicate that the call is being forwarded to a different set of destinations. 21.1.4 182 Queued The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, ""5 calls queued; expected waiting time is 15 minutes"". The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call. 21.1.5 183 Session Progress The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress. 21.2 Successful 2xx The request was successful. 21.2.1 200 OK The request has succeeded. The information returned with the response depends on the method used in the request. Rosenberg, et. al. Standards Track [Page 183] RFC 3261 SIP: Session Initiation Protocol June 2002 21.3 Redirection 3xx 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. 21.3.1 300 Multiple Choices The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location. The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body. The choices SHOULD also be listed as Contact fields (Section 20.10). Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. UAs MAY use the Contact header field value for automatic redirection or MAY ask the user to confirm a choice. However, this specification does not define any standard for such automatic selection. This status response is appropriate if the callee can be reached at several different locations and the server cannot or prefers not to proxy the request. 21.3.2 301 Moved Permanently The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field (Section 20.10). The requestor SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed. 21.3.3 302 Moved Temporarily The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 20.10). The Request-URI of the new request uses the value of the Contact header field in the response. Rosenberg, et. al. Standards Track [Page 184] RFC 3261 SIP: Session Initiation Protocol June 2002 The duration of the validity of the Contact URI can be indicated through an Expires (Section 20.19) header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions. If the URI cached from the Contact header field fails, the Request- URI from the redirected request MAY be tried again a single time. The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI may be available. 21.3.4 305 Use Proxy The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs. 21.3.5 380 Alternative Service The call was not successful, but alternative services are possible. The alternative services are described in the message body of the response. Formats for such bodies are not defined here, and may be the subject of future standardization. 21.4 Request Failure 4xx 4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful. 21.4.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, ""Missing Call-ID header field"". 21.4.2 401 Unauthorized The request requires user authentication. This response is issued by UASs and registrars, while 407 (Proxy Authentication Required) is used by proxy servers. Rosenberg, et. al. Standards Track [Page 185] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.3 402 Payment Required Reserved for future use. 21.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated. 21.4.5 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. 21.4.6 405 Method Not Allowed The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. The response MUST include an Allow header field containing a list of valid methods for the indicated address. 21.4.7 406 Not Acceptable The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request. 21.4.8 407 Proxy Authentication Required This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. SIP access authentication is explained in Sections 26 and 22.3. This status code can be used for applications where access to the communication channel (for example, a telephony gateway) rather than the callee requires authentication. 21.4.9 408 Request Timeout The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time. Rosenberg, et. al. Standards Track [Page 186] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.10 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. 21.4.11 413 Request Entity Too Large The server is refusing to process a request because the request entity-body is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. 21.4.12 414 Request-URI Too Long The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. 21.4.13 415 Unsupported Media Type The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. UAC processing of this response is described in Section 8.1.3.5. 21.4.14 416 Unsupported URI Scheme The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. Client processing of this response is described in Section 8.1.3.5. 21.4.15 420 Bad Extension The server did not understand the protocol extension specified in a Proxy-Require (Section 20.29) or Require (Section 20.32) header field. The server MUST include a list of the unsupported extensions in an Unsupported header field in the response. UAC processing of this response is described in Section 8.1.3.5. Rosenberg, et. al. Standards Track [Page 187] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.16 421 Extension Required The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. Responses with this status code MUST contain a Require header field listing the required extensions. A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client. 21.4.17 423 Interval Too Brief The server is rejecting the request because the expiration time of the resource refreshed by the request is too short. This response can be used by a registrar to reject a registration whose Contact header field expiration time was too small. The use of this response and the related Min-Expires header field are described in Sections 10.2.8, 10.3, and 20.23. 21.4.18 480 Temporarily Unavailable The callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the ""do not disturb"" feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure. This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user. 21.4.19 481 Call/Transaction Does Not Exist This status indicates that the UAS received a request that does not match any existing dialog or transaction. 21.4.20 482 Loop Detected The server has detected a loop (Section 16.3 Item 4). Rosenberg, et. al. Standards Track [Page 188] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.21 483 Too Many Hops The server received a request that contains a Max-Forwards (Section 20.22) header field with the value zero. 21.4.22 484 Address Incomplete The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase. This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response. 21.4.23 485 Ambiguous The Request-URI was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs. Example response to a request with the Request-URI sip:lee@example.com: SIP/2.0 485 Ambiguous Contact: Carol Lee <sip:carol.lee@example.com> Contact: Ping Lee <sip:p.lee@example.com> Contact: Lee M. Foote <sips:lee.foote@example.com> Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response. 21.4.24 486 Busy Here The callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response MAY indicate a better time to call in the Retry-After header field. The user could also be available Rosenberg, et. al. Standards Track [Page 189] RFC 3261 SIP: Session Initiation Protocol June 2002 elsewhere, such as through a voice mail service. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call. 21.4.25 487 Request Terminated The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself. 21.4.26 488 Not Acceptable Here The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. 21.4.27 491 Request Pending The request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes how such ""glare"" situations are resolved. 21.4.28 493 Undecipherable The request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. This response MAY have a single body containing an appropriate public key that should be used to encrypt MIME bodies sent to this UA. Details of the usage of this response code can be found in Section 23.2. 21.5 Server Failure 5xx 5xx responses are failure responses given when a server itself has erred. 21.5.1 500 Server Internal Error The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds. If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field. Rosenberg, et. al. Standards Track [Page 190] RFC 3261 SIP: Session Initiation Protocol June 2002 21.5.2 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies forward all requests regardless of method.) Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported. 21.5.3 502 Bad Gateway The server, while acting as a gateway or proxy, received an invalid response from the downstream server it accessed in attempting to fulfill the request. 21.5.4 503 Service Unavailable The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response. A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable). 21.5.5 504 Server Time-out The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server. 21.5.6 505 Version Not Supported The server does not support, or refuses to support, the SIP protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. Rosenberg, et. al. Standards Track [Page 191] RFC 3261 SIP: Session Initiation Protocol June 2002 21.5.7 513 Message Too Large The server was unable to process the request since the message length exceeded its capabilities. 21.6 Global Failures 6xx 6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI. 21.6.1 600 Busy Everywhere The callee's end system was contacted successfully but the callee is busy and does not wish to take the call at this time. The response MAY indicate a better time to call in the Retry-After header field. If the callee does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This status response is returned only if the client knows that no other end point (such as a voice mail system) will answer the request. Otherwise, 486 (Busy Here) should be returned. 21.6.2 603 Decline The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request. 21.6.3 604 Does Not Exist Anywhere The server has authoritative information that the user indicated in the Request-URI does not exist anywhere. 21.6.4 606 Not Acceptable The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable. A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response MAY contain a list of reasons in a Warning header field describing why the session described cannot be supported. Warning reason codes are listed in Section 20.43. Rosenberg, et. al. Standards Track [Page 192] RFC 3261 SIP: Session Initiation Protocol June 2002 A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response. This status response is returned only if the client knows that no other end point will answer the request. 22 Usage of HTTP Authentication SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it MAY challenge the initiator of the request to provide assurance of its identity. Once the originator has been identified, the recipient of the request SHOULD ascertain whether or not this user is authorized to make the request in question. No authorization systems are recommended or discussed in this document. The ""Digest"" authentication mechanism described in this section provides message authentication and replay protection only, without message integrity or confidentiality. Protective measures above and beyond those provided by Digest need to be taken to prevent active attackers from modifying SIP requests and responses. Note that due to its weak security, the usage of ""Basic"" authentication has been deprecated. Servers MUST NOT accept credentials using the ""Basic"" authorization scheme, and servers also MUST NOT challenge with ""Basic"". This is a change from RFC 2543. 22.1 Framework The framework for SIP authentication closely parallels that of HTTP (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical (although the usage of ""Basic"" as a scheme is not permitted). In SIP, a UAS uses the 401 (Unauthorized) response to challenge the identity of a UAC. Additionally, registrars and redirect servers MAY make use of 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead MAY use the 407 (Proxy Authentication Required) Rosenberg, et. al. Standards Track [Page 193] RFC 3261 SIP: Session Initiation Protocol June 2002 response. The requirements for inclusion of the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages are identical to those described in RFC 2617 [17]. Since SIP does not have the concept of a canonical root URL, the notion of protection spaces is interpreted differently in SIP. The realm string alone defines the protection domain. This is a change from RFC 2543, in which the Request-URI and the realm together defined the protection domain. This previous definition of protection domain caused some amount of confusion since the Request-URI sent by the UAC and the Request-URI received by the challenging server might be different, and indeed the final form of the Request-URI might not be known to the UAC. Also, the previous definition depended on the presence of a SIP URI in the Request-URI and seemed to rule out alternative URI schemes (for example, the tel URL). Operators of user agents or proxy servers that will authenticate received requests MUST adhere to the following guidelines for creation of a realm string for their server: o Realm strings MUST be globally unique. It is RECOMMENDED that a realm string contain a hostname or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17]. o Realm strings SHOULD present a human-readable identifier that can be rendered to a user. For example: INVITE sip:bob@biloxi.com SIP/2.0 Authorization: Digest realm=""biloxi.com"", <...> Generally, SIP authentication is meaningful for a specific realm, a protection domain. Thus, for Digest authentication, each such protection domain has its own set of usernames and passwords. If a server does not require authentication for a particular request, it MAY accept a default username, ""anonymous"", which has no password (password of """"). Similarly, UACs representing many users, such as PSTN gateways, MAY have their own device-specific username and password, rather than accounts for particular users, for their realm. While a server can legitimately challenge most SIP requests, there are two requests defined by this document that require special handling for authentication: ACK and CANCEL. Rosenberg, et. al. Standards Track [Page 194] RFC 3261 SIP: Session Initiation Protocol June 2002 Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK. Although the CANCEL method does take a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place). When a UAC receives a challenge, it SHOULD render to the user the contents of the ""realm"" parameter in the challenge (which appears in either a WWW-Authenticate header field or Proxy-Authenticate header field) if the UAC device does not already know of a credential for the realm in question. A service provider that pre-configures UAs with credentials for its realm should be aware that users will not have the opportunity to present their own credentials for this realm when challenged at a pre-configured device. Finally, note that even if a UAC can locate credentials that are associated with the proper realm, the potential exists that these credentials may no longer be valid or that the challenging server will not accept these credentials for whatever reason (especially when ""anonymous"" with no password is submitted). In this instance a server may repeat its challenge, or it may respond with a 403 Forbidden. A UAC MUST NOT re-attempt requests with the credentials that have just been rejected (though the request may be retried if the nonce was stale). 22.2 User-to-User Authentication When a UAS receives a request from a UAC, the UAS MAY authenticate the originator before the request is processed. If no credentials (in the Authorization header field) are provided in the request, the UAS can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status code. The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the realm. Rosenberg, et. al. Standards Track [Page 195] RFC 3261 SIP: Session Initiation Protocol June 2002 An example of the WWW-Authenticate header field in a 401 challenge is: WWW-Authenticate: Digest realm=""biloxi.com"", qop=""auth,auth-int"", nonce=""dcd98b7102dd2f0e8b11d0f600bfb0c093"", opaque=""5ccc069c403ebaf9f0171e9517f40e41"" When the originating UAC receives the 401 (Unauthorized), it SHOULD, if it is able, re-originate the request with the proper credentials. The UAC may require input from the originating user before proceeding. Once authentication credentials have been supplied (either directly by the user, or discovered in an internal keyring), UAs SHOULD cache the credentials for a given value of the To header field and ""realm"" and attempt to re-use these values on the next request for that destination. UAs MAY cache credentials in any way they would like. If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of ""anonymous"" and no password (a password of """"). Once credentials have been located, any UA that wishes to authenticate itself with a UAS or registrar -- usually, but not necessarily, after receiving a 401 (Unauthorized) response -- MAY do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the UA for the realm of the resource being requested as well as parameters required in support of authentication and replay protection. An example of the Authorization header field is: Authorization: Digest username=""bob"", realm=""biloxi.com"", nonce=""dcd98b7102dd2f0e8b11d0f600bfb0c093"", uri=""sip:bob@biloxi.com"", qop=auth, nc=00000001, cnonce=""0a4f113b"", response=""6629fae49393a05397450978507c4ef1"", opaque=""5ccc069c403ebaf9f0171e9517f40e41"" When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request. Rosenberg, et. al. Standards Track [Page 196] RFC 3261 SIP: Session Initiation Protocol June 2002 22.3 Proxy-to-User Authentication Similarly, when a UAC sends a request to a proxy server, the proxy server MAY authenticate the originator before the request is processed. If no credentials (in the Proxy-Authorization header field) are provided in the request, the proxy can challenge the originator to provide credentials by rejecting the request with a 407 (Proxy Authentication Required) status code. The proxy MUST populate the 407 (Proxy Authentication Required) message with a Proxy- Authenticate header field value applicable to the proxy for the requested resource. The use of Proxy-Authenticate and Proxy-Authorization parallel that described in [17], with one difference. Proxies MUST NOT add values to the Proxy-Authorization header field. All 407 (Proxy Authentication Required) responses MUST be forwarded upstream toward the UAC following the procedures for any other response. It is the UAC's responsibility to add the Proxy-Authorization header field value containing credentials for the realm of the proxy that has asked for authentication. If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different. When the originating UAC receives the 407 (Proxy Authentication Required) it SHOULD, if it is able, re-originate the request with the proper credentials. It should follow the same procedures for the display of the ""realm"" parameter that are given above for responding to 401. If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of ""anonymous"" and no password (a password of """"). The UAC SHOULD also cache the credentials used in the re-originated request. The following rule is RECOMMENDED for proxy credential caching: If a UA receives a Proxy-Authenticate header field value in a 401/407 response to a request with a particular Call-ID, it should incorporate credentials for that realm in all subsequent requests that contain the same Call-ID. These credentials MUST NOT be cached across dialogs; however, if a UA is configured with the realm of its local outbound proxy, when one exists, then the UA MAY cache Rosenberg, et. al. Standards Track [Page 197] RFC 3261 SIP: Session Initiation Protocol June 2002 credentials for that realm across dialogs. Note that this does mean a future request in a dialog could contain credentials that are not needed by any proxy along the Route header path. Any UA that wishes to authenticate itself to a proxy server -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) response -- MAY do so by including a Proxy- Authorization header field value with the request. The Proxy- Authorization request-header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization header field value consists of credentials containing the authentication information of the UA for the proxy and/or realm of the resource being requested. A Proxy-Authorization header field value applies only to the proxy whose realm is identified in the ""realm"" parameter (this proxy may previously have demanded authentication using the Proxy-Authenticate field). When multiple proxies are used in a chain, a Proxy- Authorization header field value MUST NOT be consumed by any proxy whose realm does not match the ""realm"" parameter specified in that value. Note that if an authentication scheme that does not support realms is used in the Proxy-Authorization header field, a proxy server MUST attempt to parse all Proxy-Authorization header field values to determine whether one of them has what the proxy server considers to be valid credentials. Because this is potentially very time- consuming in large networks, proxy servers SHOULD use an authentication scheme that supports realms in the Proxy-Authorization header field. If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may wish to challenge the UAC. In this case, the forking proxy server is responsible for aggregating these challenges into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be placed into the single response that is sent by the forking proxy to the UA; the ordering of these header field values is not significant. When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has retried the request with valid credentials. A forking proxy may forward a request simultaneously to multiple proxy servers that require authentication, each of which in turn will not forward the request until the originating UAC has authenticated itself in their respective realm. If the UAC does not provide credentials for Rosenberg, et. al. Standards Track [Page 198] RFC 3261 SIP: Session Initiation Protocol June 2002 each challenge, the proxy servers that issued the challenges will not forward requests to the UA where the destination user might be located, and therefore, the virtues of forking are largely lost. When resubmitting its request in response to a 401 (Unauthorized) or 407 (Proxy Authentication Required) that contains multiple challenges, a UAC MAY include an Authorization value for each WWW- Authenticate value and a Proxy-Authorization value for each Proxy- Authenticate value for which the UAC wishes to supply a credential. As noted above, multiple credentials in a request SHOULD be differentiated by the ""realm"" parameter. It is possible for multiple challenges associated with the same realm to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication Required). This can occur, for example, when multiple proxies within the same administrative domain, which use a common realm, are reached by a forking request. When it retries a request, a UAC MAY therefore supply multiple credentials in Authorization or Proxy-Authorization header fields with the same ""realm"" parameter value. The same credentials SHOULD be used for the same realm. 22.4 The Digest Authentication Scheme This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to SIP. The SIP scheme usage is almost completely identical to that for HTTP [17]. Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], SIP servers supporting RFC 2617 MUST ensure they are backwards compatible with RFC 2069. Procedures for this backwards compatibility are specified in RFC 2617. Note, however, that SIP servers MUST NOT accept or request Basic authentication. The rules for Digest authentication follow those defined in [17], with ""HTTP/1.1"" replaced by ""SIP/2.0"" in addition to the following differences: 1. The URI included in the challenge has the following BNF: URI = SIP-URI / SIPS-URI 2. The BNF in RFC 2617 has an error in that the 'uri' parameter of the Authorization header field for HTTP Digest Rosenberg, et. al. Standards Track [Page 199] RFC 3261 SIP: Session Initiation Protocol June 2002 authentication is not enclosed in quotation marks. (The example in Section 3.5 of RFC 2617 is correct.) For SIP, the 'uri' MUST be enclosed in quotation marks. 3. The BNF for digest-uri-value is: digest-uri-value = Request-URI ; as defined in Section 25 4. The example procedure for choosing a nonce based on Etag does not work for SIP. 5. The text in RFC 2617 [17] regarding cache operation does not apply to SIP. 6. RFC 2617 [17] requires that a server check that the URI in the request line and the URI included in the Authorization header field point to the same resource. In a SIP context, these two URIs may refer to different users, due to forwarding at some proxy. Therefore, in SIP, a server MAY check that the Request-URI in the Authorization header field value corresponds to a user for whom the server is willing to accept forwarded or direct requests, but it is not necessarily a failure if the two fields are not equivalent. 7. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when SIP messages have no body) that the hash of the entity-body resolves to the MD5 hash of an empty string, or: H(entity-body) = MD5("""") = ""d41d8cd98f00b204e9800998ecf8427e"" 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent. Therefore, any algorithms that have a dependency on the cnonce (including ""MD5-Sess"") require that the qop directive be sent. Use of the ""qop"" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since RFC 2543 was based on RFC 2069, the ""qop"" parameter must unfortunately remain optional for clients and servers to receive. However, servers MUST always send a ""qop"" parameter in WWW-Authenticate and Proxy-Authenticate header field values. If a client receives a ""qop"" parameter in a challenge header field, it MUST send the ""qop"" parameter in any resulting authorization header field. Rosenberg, et. al. Standards Track [Page 200] RFC 3261 SIP: Session Initiation Protocol June 2002 RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. RFC 2617 [17] defines mechanisms for backwards compatibility using the qop attribute in the request. These mechanisms MUST be used by a server to determine if the client supports the new mechanisms in RFC 2617 that were not specified in RFC 2069."
"23 S/MIME SIP messages carry MIME bodies and the MIME standard includes mechanisms for securing MIME contents to ensure both integrity and confidentiality (including the 'multipart/signed' and 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] and RFC 2633 [24]). Implementers should note, however, that there may be rare network intermediaries (not typical proxy servers) that rely on viewing or modifying the bodies of SIP messages (especially SDP), and that secure MIME may prevent these sorts of intermediaries from functioning. This applies particularly to certain types of firewalls. The PGP mechanism for encrypting the header fields and bodies of SIP messages described in RFC 2543 has been deprecated. 23.1 S/MIME Certificates The certificates that are used to identify an end-user for the purposes of S/MIME differ from those used by servers in one important respect - rather than asserting that the identity of the holder corresponds to a particular hostname, these certificates assert that the holder is identified by an end-user address. This address is composed of the concatenation of the ""userinfo"" ""@"" and ""domainname"" portions of a SIP or SIPS URI (in other words, an email address of the form ""bob@biloxi.com""), most commonly corresponding to a user's address-of-record. These certificates are also associated with keys that are used to sign or encrypt bodies of SIP messages. Bodies are signed with the private key of the sender (who may include their public key with the message as appropriate), but bodies are encrypted with the public key of the intended recipient. Obviously, senders must have foreknowledge of the public key of recipients in order to encrypt message bodies. Public keys can be stored within a UA on a virtual keyring. Rosenberg, et. al. Standards Track [Page 201] RFC 3261 SIP: Session Initiation Protocol June 2002 Each user agent that supports S/MIME MUST contain a keyring specifically for end-users' certificates. This keyring should map between addresses of record and corresponding certificates. Over time, users SHOULD use the same certificate when they populate the originating URI of signaling (the From header field) with the same address-of-record. Any mechanisms depending on the existence of end-user certificates are seriously limited in that there is virtually no consolidated authority today that provides certificates for end-user applications. However, users SHOULD acquire certificates from known public certificate authorities. As an alternative, users MAY create self- signed certificates. The implications of self-signed certificates are explored further in Section 26.4.2. Implementations may also use pre-configured certificates in deployments in which a previous trust relationship exists between all SIP entities. Above and beyond the problem of acquiring an end-user certificate, there are few well-known centralized directories that distribute end-user certificates. However, the holder of a certificate SHOULD publish their certificate in any public directories as appropriate. Similarly, UACs SHOULD support a mechanism for importing (manually or automatically) certificates discovered in public directories corresponding to the target URIs of SIP requests. 23.2 S/MIME Key Exchange SIP itself can also be used as a means to distribute public keys in the following manner. Whenever the CMS SignedData message is used in S/MIME for SIP, it MUST contain the certificate bearing the public key necessary to verify the signature. When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-INVITE request outside the context of a dialog, the UAC SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS service is EnvelopedData (and the public key of the target user is known), the UAC SHOULD send the EnvelopedData message encapsulated within a SignedData message. When a UAS receives a request containing an S/MIME CMS body that includes a certificate, the UAS SHOULD first validate the certificate, if possible, with any available root certificates for certificate authorities. The UAS SHOULD also determine the subject of the certificate (for S/MIME, the SubjectAltName will contain the appropriate identity) and compare this value to the From header field Rosenberg, et. al. Standards Track [Page 202] RFC 3261 SIP: Session Initiation Protocol June 2002 of the request. If the certificate cannot be verified, because it is self-signed, or signed by no known authority, or if it is verifiable but its subject does not correspond to the From header field of request, the UAS MUST notify its user of the status of the certificate (including the subject of the certificate, its signer, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified and the subject of the certificate corresponds to the From header field of the SIP request, or if the user (after notification) explicitly authorizes the use of the certificate, the UAS SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or a response to a non-INVITE request outside the context of a dialog, the UAS SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS service is EnvelopedData, the UAS SHOULD send the EnvelopedData message encapsulated within a SignedData message. When a UAC receives a response containing an S/MIME CMS body that includes a certificate, the UAC SHOULD first validate the certificate, if possible, with any appropriate root certificate. The UAC SHOULD also determine the subject of the certificate and compare this value to the To field of the response; although the two may very well be different, and this is not necessarily indicative of a security breach. If the certificate cannot be verified because it is self-signed, or signed by no known authority, the UAC MUST notify its user of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified, and the subject of the certificate corresponds to the To header field in the response, or if the user (after notification) explicitly authorizes the use of the certificate, the UAC SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. If the UAC had not transmitted its own certificate to the UAS in any previous transaction, it SHOULD use a CMS SignedData body for its next request or response. On future occasions, when the UA receives requests or responses that contain a From header field corresponding to a value in its keyring, the UA SHOULD compare the certificate offered in these messages with the existing certificate in its keyring. If there is a discrepancy, the UA MUST notify its user of a change of the certificate (preferably in terms that indicate that this is a potential security breach) and acquire the user's permission before continuing to Rosenberg, et. al. Standards Track [Page 203] RFC 3261 SIP: Session Initiation Protocol June 2002 process the signaling. If the user authorizes this certificate, it SHOULD be added to the keyring alongside any previous value(s) for this address-of-record. Note well however, that this key exchange mechanism does not guarantee the secure exchange of keys when self-signed certificates, or certificates signed by an obscure authority, are used - it is vulnerable to well-known attacks. In the opinion of the authors, however, the security it provides is proverbially better than nothing; it is in fact comparable to the widely used SSH application. These limitations are explored in greater detail in Section 26.4.2. If a UA receives an S/MIME body that has been encrypted with a public key unknown to the recipient, it MUST reject the request with a 493 (Undecipherable) response. This response SHOULD contain a valid certificate for the respondent (corresponding, if possible, to any address of record given in the To header field of the rejected request) within a MIME body with a 'certs-only' ""smime-type"" parameter. A 493 (Undecipherable) sent without any certificate indicates that the respondent cannot or will not utilize S/MIME encrypted messages, though they may still support S/MIME signatures. Note that a user agent that receives a request containing an S/MIME body that is not optional (with a Content-Disposition header ""handling"" parameter of ""required"") MUST reject the request with a 415 Unsupported Media Type response if the MIME type is not understood. A user agent that receives such a response when S/MIME is sent SHOULD notify its user that the remote device does not support S/MIME, and it MAY subsequently resend the request without S/MIME, if appropriate; however, this 415 response may constitute a downgrade attack. If a user agent sends an S/MIME body in a request, but receives a response that contains a MIME body that is not secured, the UAC SHOULD notify its user that the session could not be secured. However, if a user agent that supports S/MIME receives a request with an unsecured body, it SHOULD NOT respond with a secured body, but if it expects S/MIME from the sender (for example, because the sender's From header field value corresponds to an identity on its keychain), the UAS SHOULD notify its user that the session could not be secured. A number of conditions that arise in the previous text call for the notification of the user when an anomalous certificate-management event occurs. Users might well ask what they should do under these circumstances. First and foremost, an unexpected change in a certificate, or an absence of security when security is expected, are Rosenberg, et. al. Standards Track [Page 204] RFC 3261 SIP: Session Initiation Protocol June 2002 causes for caution but not necessarily indications that an attack is in progress. Users might abort any connection attempt or refuse a connection request they have received; in telephony parlance, they could hang up and call back. Users may wish to find an alternate means to contact the other party and confirm that their key has legitimately changed. Note that users are sometimes compelled to change their certificates, for example when they suspect that the secrecy of their private key has been compromised. When their private key is no longer private, users must legitimately generate a new key and re-establish trust with any users that held their old key. Finally, if during the course of a dialog a UA receives a certificate in a CMS SignedData message that does not correspond with the certificates previously exchanged during a dialog, the UA MUST notify its user of the change, preferably in terms that indicate that this is a potential security breach. 23.3 Securing MIME bodies There are two types of secure MIME bodies that are of interest to SIP: use of these bodies should follow the S/MIME specification [24] with a few variations. o ""multipart/signed"" MUST be used only with CMS detached signatures. This allows backwards compatibility with non-S/MIME- compliant recipients. o S/MIME bodies SHOULD have a Content-Disposition header field, and the value of the ""handling"" parameter SHOULD be ""required."" o If a UAC has no certificate on its keyring associated with the address-of-record to which it wants to send a request, it cannot send an encrypted ""application/pkcs7-mime"" MIME message. UACs MAY send an initial request such as an OPTIONS message with a CMS detached signature in order to solicit the certificate of the remote side (the signature SHOULD be over a ""message/sip"" body of the type described in Section 23.4). Note that future standardization work on S/MIME may define non-certificate based keys. o Senders of S/MIME bodies SHOULD use the ""SMIMECapabilities"" (see Section 2.5.2 of [24]) attribute to express their capabilities and preferences for further communications. Note especially that senders MAY use the ""preferSignedData"" Rosenberg, et. al. Standards Track [Page 205] RFC 3261 SIP: Session Initiation Protocol June 2002 capability to encourage receivers to respond with CMS SignedData messages (for example, when sending an OPTIONS request as described above). o S/MIME implementations MUST at a minimum support SHA1 as a digital signature algorithm, and 3DES as an encryption algorithm. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for these algorithms with the ""SMIMECapabilities"" attribute. o Each S/MIME body in a SIP message SHOULD be signed with only one certificate. If a UA receives a message with multiple signatures, the outermost signature should be treated as the single certificate for this body. Parallel signatures SHOULD NOT be used. The following is an example of an encrypted S/MIME SDP body within a SIP message: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Disposition: attachment; filename=smime.p7m handling=required ******************************************************* * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=- * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * ******************************************************* Rosenberg, et. al. Standards Track [Page 206] RFC 3261 SIP: Session Initiation Protocol June 2002 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP As a means of providing some degree of end-to-end authentication, integrity or confidentiality for SIP header fields, S/MIME can encapsulate entire SIP messages within MIME bodies of type ""message/sip"" and then apply MIME security to these bodies in the same manner as typical SIP bodies. These encapsulated SIP requests and responses do not constitute a separate dialog or transaction, they are a copy of the ""outer"" message that is used to verify integrity or to supply additional information. If a UAS receives a request that contains a tunneled ""message/sip"" S/MIME body, it SHOULD include a tunneled ""message/sip"" body in the response with the same smime-type. Any traditional MIME bodies (such as SDP) SHOULD be attached to the ""inner"" message so that they can also benefit from S/MIME security. Note that ""message/sip"" bodies can be sent as a part of a MIME ""multipart/mixed"" body if any unsecured MIME types should also be transmitted in a request. 23.4.1 Integrity and Confidentiality Properties of SIP Headers When the S/MIME integrity or confidentiality mechanisms are used, there may be discrepancies between the values in the ""inner"" message and values in the ""outer"" message. The rules for handling any such differences for all of the header fields described in this document are given in this section. Note that for the purposes of loose timestamping, all SIP messages that tunnel ""message/sip"" SHOULD contain a Date header in both the ""inner"" and ""outer"" headers. 23.4.1.1 Integrity Whenever integrity checks are performed, the integrity of a header field should be determined by matching the value of the header field in the signed body with that in the ""outer"" messages using the comparison rules of SIP as described in 20. Header fields that can be legitimately modified by proxy servers are: Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- Authorization. If these header fields are not intact end-to-end, implementations SHOULD NOT consider this a breach of security. Changes to any other header fields defined in this document constitute an integrity violation; users MUST be notified of a discrepancy. Rosenberg, et. al. Standards Track [Page 207] RFC 3261 SIP: Session Initiation Protocol June 2002 23.4.1.2 Confidentiality When messages are encrypted, header fields may be included in the encrypted body that are not present in the ""outer"" message. Some header fields must always have a plaintext version because they are required header fields in requests and responses - these include: To, From, Call-ID, CSeq, Contact. While it is probably not useful to provide an encrypted alternative for the Call-ID, CSeq, or Contact, providing an alternative to the information in the ""outer"" To or From is permitted. Note that the values in an encrypted body are not used for the purposes of identifying transactions or dialogs - they are merely informational. If the From header field in an encrypted body differs from the value in the ""outer"" message, the value within the encrypted body SHOULD be displayed to the user, but MUST NOT be used in the ""outer"" header fields of any future messages. Primarily, a user agent will want to encrypt header fields that have an end-to-end semantic, including: Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server, and Warning. If any of these header fields are present in an encrypted body, they should be used instead of any ""outer"" header fields, whether this entails displaying the header field values to users or setting internal states in the UA. They SHOULD NOT however be used in the ""outer"" headers of any future messages. If present, the Date header field MUST always be the same in the ""inner"" and ""outer"" headers. Since MIME bodies are attached to the ""inner"" message, implementations will usually encrypt MIME-specific header fields, including: MIME-Version, Content-Type, Content-Length, Content- Language, Content-Encoding and Content-Disposition. The ""outer"" message will have the proper MIME header fields for S/MIME bodies. These header fields (and any MIME bodies they preface) should be treated as normal MIME header fields and bodies received in a SIP message. It is not particularly useful to encrypt the following header fields: Min-Expires, Timestamp, Authorization, Priority, and WWW- Authenticate. This category also includes those header fields that can be changed by proxy servers (described in the preceding section). UAs SHOULD never include these in an ""inner"" message if they are not Rosenberg, et. al. Standards Track [Page 208] RFC 3261 SIP: Session Initiation Protocol June 2002 included in the ""outer"" message. UAs that receive any of these header fields in an encrypted body SHOULD ignore the encrypted values. Note that extensions to SIP may define additional header fields; the authors of these extensions should describe the integrity and confidentiality properties of such header fields. If a SIP UA encounters an unknown header field with an integrity violation, it MUST ignore the header field. 23.4.2 Tunneling Integrity and Authentication Tunneling SIP messages within S/MIME bodies can provide integrity for SIP header fields if the header fields that the sender wishes to secure are replicated in a ""message/sip"" MIME body signed with a CMS detached signature. Provided that the ""message/sip"" body contains at least the fundamental dialog identifiers (To, From, Call-ID, CSeq), then a signed MIME body can provide limited authentication. At the very least, if the certificate used to sign the body is unknown to the recipient and cannot be verified, the signature can be used to ascertain that a later request in a dialog was transmitted by the same certificate-holder that initiated the dialog. If the recipient of the signed MIME body has some stronger incentive to trust the certificate (they were able to validate it, they acquired it from a trusted repository, or they have used it frequently) then the signature can be taken as a stronger assertion of the identity of the subject of the certificate. In order to eliminate possible confusions about the addition or subtraction of entire header fields, senders SHOULD replicate all header fields from the request within the signed body. Any message bodies that require integrity protection MUST be attached to the ""inner"" message. If a Date header is present in a message with a signed body, the recipient SHOULD compare the header field value with its own internal clock, if applicable. If a significant time discrepancy is detected (on the order of an hour or more), the user agent SHOULD alert the user to the anomaly, and note that it is a potential security breach. If an integrity violation in a message is detected by its recipient, the message MAY be rejected with a 403 (Forbidden) response if it is a request, or any existing dialog MAY be terminated. UAs SHOULD notify users of this circumstance and request explicit guidance on how to proceed. Rosenberg, et. al. Standards Track [Page 209] RFC 3261 SIP: Session Initiation Protocol June 2002 The following is an example of the use of a tunneled ""message/sip"" body: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: multipart/signed; protocol=""application/pkcs7-signature""; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: message/sip INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <bob@biloxi.com> From: Alice <alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 pc33.atlanta.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required Rosenberg, et. al. Standards Track [Page 210] RFC 3261 SIP: Session Initiation Protocol June 2002 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 23.4.3 Tunneling Encryption It may also be desirable to use this mechanism to encrypt a ""message/sip"" MIME body within a CMS EnvelopedData message S/MIME body, but in practice, most header fields are of at least some use to the network; the general use of encryption with S/MIME is to secure message bodies like SDP rather than message headers. Some informational header fields, such as the Subject or Organization could perhaps warrant end-to-end security. Headers defined by future SIP applications might also require obfuscation. Another possible application of encrypting header fields is selective anonymity. A request could be constructed with a From header field that contains no personal information (for example, sip:anonymous@anonymizer.invalid). However, a second From header field containing the genuine address-of-record of the originator could be encrypted within a ""message/sip"" MIME body where it will only be visible to the endpoints of a dialog. Note that if this mechanism is used for anonymity, the From header field will no longer be usable by the recipient of a message as an index to their certificate keychain for retrieving the proper S/MIME key to associated with the sender. The message must first be decrypted, and the ""inner"" From header field MUST be used as an index. In order to provide end-to-end integrity, encrypted ""message/sip"" MIME bodies SHOULD be signed by the sender. This creates a ""multipart/signed"" MIME body that contains an encrypted body and a signature, both of type ""application/pkcs7-mime"". Rosenberg, et. al. Standards Track [Page 211] RFC 3261 SIP: Session Initiation Protocol June 2002 In the following example, of an encrypted and signed message, the text boxed in asterisks (""*"") is encrypted: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:pc33.atlanta.com> Content-Type: multipart/signed; protocol=""application/pkcs7-signature""; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m handling=required Content-Length: 231 *********************************************************** * Content-Type: message/sip * * * * INVITE sip:bob@biloxi.com SIP/2.0 * * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * * To: Bob <bob@biloxi.com> * * From: Alice <alice@atlanta.com>;tag=1928301774 * * Call-ID: a84b4c76e66710 * * CSeq: 314159 INVITE * * Max-Forwards: 70 * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Contact: <sip:alice@pc33.atlanta.com> * * * * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=Session SDP * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * *********************************************************** Rosenberg, et. al. Standards Track [Page 212] RFC 3261 SIP: Session Initiation Protocol June 2002 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 24 Examples In the following examples, we often omit the message body and the corresponding Content-Length and Content-Type header fields for brevity. 24.1 Registration Bob registers on start-up. The message flow is shown in Figure 9. Note that the authentication usually required for registration is not shown for simplicity. biloxi.com Bob's registrar softphone | | | REGISTER F1 | |<---------------| | 200 OK F2 | |--------------->| Figure 9: SIP Registration Example F1 REGISTER Bob -> Registrar REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0 Rosenberg, et. al. Standards Track [Page 213] RFC 3261 SIP: Session Initiation Protocol June 2002 The registration expires after two hours. The registrar responds with a 200 OK: F2 200 OK Registrar -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Bob <sip:bob@biloxi.com>;tag=2493k59kd From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0 24.2 Session Setup This example contains the full details of the example session setup in Section 4. The message flow is shown in Figure 1. Note that these flows show the minimum required set of header fields - some other header fields such as Allow and Supported would normally be present. F1 INVITE Alice -> atlanta.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Rosenberg, et. al. Standards Track [Page 214] RFC 3261 SIP: Session Initiation Protocol June 2002 F2 100 Trying atlanta.com proxy -> Alice SIP/2.0 100 Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 F3 INVITE atlanta.com proxy -> biloxi.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 69 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) F4 100 Trying biloxi.com proxy -> atlanta.com proxy SIP/2.0 100 Trying Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 215] RFC 3261 SIP: Session Initiation Protocol June 2002 F5 INVITE biloxi.com proxy -> Bob INVITE sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) F6 180 Ringing Bob -> biloxi.com proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 216] RFC 3261 SIP: Session Initiation Protocol June 2002 F8 180 Ringing atlanta.com proxy -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 F9 200 OK Bob -> biloxi.com proxy SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) F10 200 OK biloxi.com proxy -> atlanta.com proxy SIP/2.0 200 OK Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Rosenberg, et. al. Standards Track [Page 217] RFC 3261 SIP: Session Initiation Protocol June 2002 F11 200 OK atlanta.com proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) F12 ACK Alice -> Bob ACK sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0 The media session between Alice and Bob is now established. Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq numbering space, which, in this example, begins with 231. Since Bob is making the request, the To and From URIs and tags have been swapped. F13 BYE Bob -> Alice BYE sip:alice@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 218] RFC 3261 SIP: Session Initiation Protocol June 2002 F14 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 The SIP Call Flows document [40] contains further examples of SIP messages. 25 Augmented BNF for the SIP Protocol All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that are used by this specification, and not repeated here. Implementers need to be familiar with the notation and content of RFC 2234 in order to understand this specification. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions to clarify the use of rule names. The use of square brackets is redundant syntactically. It is used as a semantic hint that the specific parameter is optional to use. 25.1 Basic Rules The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986. alphanum = ALPHA / DIGIT Rosenberg, et. al. Standards Track [Page 219] RFC 3261 SIP: Session Initiation Protocol June 2002 Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include: reserved = "";"" / ""/"" / ""?"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" unreserved = alphanum / mark mark = ""-"" / ""_"" / ""."" / ""!"" / ""~"" / ""*"" / ""'"" / ""("" / "")"" escaped = ""%"" HEXDIG HEXDIG SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS construct is used when linear white space is optional, generally between tokens and separators. LWS = [*WSP CRLF] 1*WSP ; linear whitespace SWS = [LWS] ; sep whitespace To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines this construct. HCOLON = *( SP / HTAB ) "":"" SWS The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful. In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set. TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) TEXT-UTF8char = %x21-7E / UTF8-NONASCII UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF Rosenberg, et. al. Standards Track [Page 220] RFC 3261 SIP: Session Initiation Protocol June 2002 A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT- UTF8-TRIM value. Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case. LHEX = DIGIT / %x61-66 ;lowercase a-f Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise stated, tokens are case- insensitive. These special characters MUST be in a quoted string to be used within a parameter value. The word construct is used in Call-ID to allow most separators to be used. token = 1*(alphanum / ""-"" / ""."" / ""!"" / ""%"" / ""*"" / ""_"" / ""+"" / ""`"" / ""'"" / ""~"" ) separators = ""("" / "")"" / ""<"" / "">"" / ""@"" / "","" / "";"" / "":"" / ""\"" / DQUOTE / ""/"" / ""["" / ""]"" / ""?"" / ""="" / ""{"" / ""}"" / SP / HTAB word = 1*(alphanum / ""-"" / ""."" / ""!"" / ""%"" / ""*"" / ""_"" / ""+"" / ""`"" / ""'"" / ""~"" / ""("" / "")"" / ""<"" / "">"" / "":"" / ""\"" / DQUOTE / ""/"" / ""["" / ""]"" / ""?"" / ""{"" / ""}"" ) When tokens are used or separators are used between elements, whitespace is often allowed before or after these characters: STAR = SWS ""*"" SWS ; asterisk SLASH = SWS ""/"" SWS ; slash EQUAL = SWS ""="" SWS ; equal LPAREN = SWS ""("" SWS ; left parenthesis RPAREN = SWS "")"" SWS ; right parenthesis RAQUOT = "">"" SWS ; right angle quote LAQUOT = SWS ""<""; left angle quote COMMA = SWS "","" SWS ; comma SEMI = SWS "";"" SWS ; semicolon COLON = SWS "":"" SWS ; colon LDQUOT = SWS DQUOTE; open double quotation mark RDQUOT = DQUOTE SWS ; close double quotation mark Rosenberg, et. al. Standards Track [Page 221] RFC 3261 SIP: Session Initiation Protocol June 2002 Comments can be included in some SIP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing ""comment"" as part of their field value definition. In all other fields, parentheses are considered part of the field value. comment = LPAREN *(ctext / quoted-pair / comment) RPAREN ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII / LWS ctext includes all chars except left and right parens and backslash. A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings, quotation marks ("") and backslashes (\) need to be escaped. quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII The backslash character (""\"") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation. quoted-pair = ""\"" (%x00-09 / %x0B-0C / %x0E-7F) SIP-URI = ""sip:"" [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = ""sips:"" [ userinfo ] hostport uri-parameters [ headers ] userinfo = ( user / telephone-subscriber ) [ "":"" password ] ""@"" user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = ""&"" / ""="" / ""+"" / ""$"" / "","" / "";"" / ""?"" / ""/"" password = *( unreserved / escaped / ""&"" / ""="" / ""+"" / ""$"" / "","" ) hostport = host [ "":"" port ] host = hostname / IPv4address / IPv6reference hostname = *( domainlabel ""."" ) toplabel [ ""."" ] domainlabel = alphanum / alphanum *( alphanum / ""-"" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / ""-"" ) alphanum Rosenberg, et. al. Standards Track [Page 222] RFC 3261 SIP: Session Initiation Protocol June 2002 IPv4address = 1*3DIGIT ""."" 1*3DIGIT ""."" 1*3DIGIT ""."" 1*3DIGIT IPv6reference = ""["" IPv6address ""]"" IPv6address = hexpart [ "":"" IPv4address ] hexpart = hexseq / hexseq ""::"" [ hexseq ] / ""::"" [ hexseq ] hexseq = hex4 *( "":"" hex4) hex4 = 1*4HEXDIG port = 1*DIGIT The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, however, that any characters allowed there that are not allowed in the user part of the SIP URI MUST be escaped. uri-parameters = *( "";"" uri-parameter) uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param transport-param = ""transport="" ( ""udp"" / ""tcp"" / ""sctp"" / ""tls"" / other-transport) other-transport = token user-param = ""user="" ( ""phone"" / ""ip"" / other-user) other-user = token method-param = ""method="" Method ttl-param = ""ttl="" ttl maddr-param = ""maddr="" host lr-param = ""lr"" other-param = pname [ ""="" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = ""["" / ""]"" / ""/"" / "":"" / ""&"" / ""+"" / ""$"" headers = ""?"" header *( ""&"" header ) header = hname ""="" hvalue hname = 1*( hnv-unreserved / unreserved / escaped ) hvalue = *( hnv-unreserved / unreserved / escaped ) hnv-unreserved = ""["" / ""]"" / ""/"" / ""?"" / "":"" / ""+"" / ""$"" SIP-message = Request / Response Request = Request-Line *( message-header ) CRLF [ message-body ] Request-Line = Method SP Request-URI SP SIP-Version CRLF Request-URI = SIP-URI / SIPS-URI / absoluteURI absoluteURI = scheme "":"" ( hier-part / opaque-part ) hier-part = ( net-path / abs-path ) [ ""?"" query ] net-path = ""//"" authority [ abs-path ] abs-path = ""/"" path-segments Rosenberg, et. al."
"Standards Track [Page 223] RFC 3261 SIP: Session Initiation Protocol June 2002 opaque-part = uric-no-slash *uric uric = reserved / unreserved / escaped uric-no-slash = unreserved / escaped / "";"" / ""?"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" path-segments = segment *( ""/"" segment ) segment = *pchar *( "";"" param ) param = *pchar pchar = unreserved / escaped / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" scheme = ALPHA *( ALPHA / DIGIT / ""+"" / ""-"" / ""."" ) authority = srvr / reg-name srvr = [ [ userinfo ""@"" ] hostport ] reg-name = 1*( unreserved / escaped / ""$"" / "","" / "";"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" ) query = *uric SIP-Version = ""SIP"" ""/"" 1*DIGIT ""."" 1*DIGIT message-header = (Accept / Accept-Encoding / Accept-Language / Alert-Info / Allow / Authentication-Info / Authorization / Call-ID / Call-Info / Contact / Content-Disposition / Content-Encoding / Content-Language / Content-Length / Content-Type / CSeq / Date / Error-Info / Expires / From / In-Reply-To / Max-Forwards / MIME-Version / Min-Expires / Organization / Priority / Proxy-Authenticate / Proxy-Authorization / Proxy-Require / Record-Route / Reply-To Rosenberg, et. al. Standards Track [Page 224] RFC 3261 SIP: Session Initiation Protocol June 2002 / Require / Retry-After / Route / Server / Subject / Supported / Timestamp / To / Unsupported / User-Agent / Via / Warning / WWW-Authenticate / extension-header) CRLF INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps ACKm = %x41.43.4B ; ACK in caps OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps BYEm = %x42.59.45 ; BYE in caps CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / extension-method extension-method = token Response = Status-Line *( message-header ) CRLF [ message-body ] Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF Status-Code = Informational / Redirection / Success / Client-Error / Server-Error / Global-Failure / extension-code extension-code = 3DIGIT Reason-Phrase = *(reserved / unreserved / escaped / UTF8-NONASCII / UTF8-CONT / SP / HTAB) Informational = ""100"" ; Trying / ""180"" ; Ringing / ""181"" ; Call Is Being Forwarded / ""182"" ; Queued / ""183"" ; Session Progress Rosenberg, et. al. Standards Track [Page 225] RFC 3261 SIP: Session Initiation Protocol June 2002 Success = ""200"" ; OK Redirection = ""300"" ; Multiple Choices / ""301"" ; Moved Permanently / ""302"" ; Moved Temporarily / ""305"" ; Use Proxy / ""380"" ; Alternative Service Client-Error = ""400"" ; Bad Request / ""401"" ; Unauthorized / ""402"" ; Payment Required / ""403"" ; Forbidden / ""404"" ; Not Found / ""405"" ; Method Not Allowed / ""406"" ; Not Acceptable / ""407"" ; Proxy Authentication Required / ""408"" ; Request Timeout / ""410"" ; Gone / ""413"" ; Request Entity Too Large / ""414"" ; Request-URI Too Large / ""415"" ; Unsupported Media Type / ""416"" ; Unsupported URI Scheme / ""420"" ; Bad Extension / ""421"" ; Extension Required / ""423"" ; Interval Too Brief / ""480"" ; Temporarily not available / ""481"" ; Call Leg/Transaction Does Not Exist / ""482"" ; Loop Detected / ""483"" ; Too Many Hops / ""484"" ; Address Incomplete / ""485"" ; Ambiguous / ""486"" ; Busy Here / ""487"" ; Request Terminated / ""488"" ; Not Acceptable Here / ""491"" ; Request Pending / ""493"" ; Undecipherable Server-Error = ""500"" ; Internal Server Error / ""501"" ; Not Implemented / ""502"" ; Bad Gateway / ""503"" ; Service Unavailable / ""504"" ; Server Time-out / ""505"" ; SIP Version not supported / ""513"" ; Message Too Large Rosenberg, et. al. Standards Track [Page 226] RFC 3261 SIP: Session Initiation Protocol June 2002 Global-Failure = ""600"" ; Busy Everywhere / ""603"" ; Decline / ""604"" ; Does not exist anywhere / ""606"" ; Not Acceptable Accept = ""Accept"" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range = ( ""*/*"" / ( m-type SLASH ""*"" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-param = (""q"" EQUAL qvalue) / generic-param qvalue = ( ""0"" [ ""."" 0*3DIGIT ] ) / ( ""1"" [ ""."" 0*3(""0"") ] ) generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string Accept-Encoding = ""Accept-Encoding"" HCOLON [ encoding *(COMMA encoding) ] encoding = codings *(SEMI accept-param) codings = content-coding / ""*"" content-coding = token Accept-Language = ""Accept-Language"" HCOLON [ language *(COMMA language) ] language = language-range *(SEMI accept-param) language-range = ( ( 1*8ALPHA *( ""-"" 1*8ALPHA ) ) / ""*"" ) Alert-Info = ""Alert-Info"" HCOLON alert-param *(COMMA alert-param) alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Allow = ""Allow"" HCOLON [Method *(COMMA Method)] Authorization = ""Authorization"" HCOLON credentials credentials = (""Digest"" LWS digest-response) / other-response digest-response = dig-resp *(COMMA dig-resp) dig-resp = username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username = ""username"" EQUAL username-value username-value = quoted-string digest-uri = ""uri"" EQUAL LDQUOT digest-uri-value RDQUOT digest-uri-value = rquest-uri ; Equal to request-uri as specified by HTTP/1.1 message-qop = ""qop"" EQUAL qop-value Rosenberg, et. al. Standards Track [Page 227] RFC 3261 SIP: Session Initiation Protocol June 2002 cnonce = ""cnonce"" EQUAL cnonce-value cnonce-value = nonce-value nonce-count = ""nc"" EQUAL nc-value nc-value = 8LHEX dresponse = ""response"" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT auth-param = auth-param-name EQUAL ( token / quoted-string ) auth-param-name = token other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token Authentication-Info = ""Authentication-Info"" HCOLON ainfo *(COMMA ainfo) ainfo = nextnonce / message-qop / response-auth / cnonce / nonce-count nextnonce = ""nextnonce"" EQUAL nonce-value response-auth = ""rspauth"" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT Call-ID = ( ""Call-ID"" / ""i"" ) HCOLON callid callid = word [ ""@"" word ] Call-Info = ""Call-Info"" HCOLON info *(COMMA info) info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) info-param = ( ""purpose"" EQUAL ( ""icon"" / ""info"" / ""card"" / token ) ) / generic-param Contact = (""Contact"" / ""m"" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *(SEMI contact-params) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI display-name = *(token LWS)/ quoted-string contact-params = c-p-q / c-p-expires / contact-extension c-p-q = ""q"" EQUAL qvalue c-p-expires = ""expires"" EQUAL delta-seconds contact-extension = generic-param delta-seconds = 1*DIGIT Content-Disposition = ""Content-Disposition"" HCOLON disp-type *( SEMI disp-param ) disp-type = ""render"" / ""session"" / ""icon"" / ""alert"" / disp-extension-token Rosenberg, et. al. Standards Track [Page 228] RFC 3261 SIP: Session Initiation Protocol June 2002 disp-param = handling-param / generic-param handling-param = ""handling"" EQUAL ( ""optional"" / ""required"" / other-handling ) other-handling = token disp-extension-token = token Content-Encoding = ( ""Content-Encoding"" / ""e"" ) HCOLON content-coding *(COMMA content-coding) Content-Language = ""Content-Language"" HCOLON language-tag *(COMMA language-tag) language-tag = primary-tag *( ""-"" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA Content-Length = ( ""Content-Length"" / ""l"" ) HCOLON 1*DIGIT Content-Type = ( ""Content-Type"" / ""c"" ) HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter) m-type = discrete-type / composite-type discrete-type = ""text"" / ""image"" / ""audio"" / ""video"" / ""application"" / extension-token composite-type = ""message"" / ""multipart"" / extension-token extension-token = ietf-token / x-token ietf-token = token x-token = ""x-"" token m-subtype = extension-token / iana-token iana-token = token m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string CSeq = ""CSeq"" HCOLON 1*DIGIT LWS Method Date = ""Date"" HCOLON SIP-date SIP-date = rfc1123-date rfc1123-date = wkday "","" SP date1 SP time SP ""GMT"" date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) time = 2DIGIT "":"" 2DIGIT "":"" 2DIGIT ; 00:00:00 - 23:59:59 wkday = ""Mon"" / ""Tue"" / ""Wed"" / ""Thu"" / ""Fri"" / ""Sat"" / ""Sun"" month = ""Jan"" / ""Feb"" / ""Mar"" / ""Apr"" / ""May"" / ""Jun"" / ""Jul"" / ""Aug"" / ""Sep"" / ""Oct"" / ""Nov"" / ""Dec"" Error-Info = ""Error-Info"" HCOLON error-uri *(COMMA error-uri) Rosenberg, et. al. Standards Track [Page 229] RFC 3261 SIP: Session Initiation Protocol June 2002 error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Expires = ""Expires"" HCOLON delta-seconds From = ( ""From"" / ""f"" ) HCOLON from-spec from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-param = tag-param / generic-param tag-param = ""tag"" EQUAL token In-Reply-To = ""In-Reply-To"" HCOLON callid *(COMMA callid) Max-Forwards = ""Max-Forwards"" HCOLON 1*DIGIT MIME-Version = ""MIME-Version"" HCOLON 1*DIGIT ""."" 1*DIGIT Min-Expires = ""Min-Expires"" HCOLON delta-seconds Organization = ""Organization"" HCOLON [TEXT-UTF8-TRIM] Priority = ""Priority"" HCOLON priority-value priority-value = ""emergency"" / ""urgent"" / ""normal"" / ""non-urgent"" / other-priority other-priority = token Proxy-Authenticate = ""Proxy-Authenticate"" HCOLON challenge challenge = (""Digest"" LWS digest-cln *(COMMA digest-cln)) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = ""realm"" EQUAL realm-value realm-value = quoted-string domain = ""domain"" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT URI = absoluteURI / abs-path nonce = ""nonce"" EQUAL nonce-value nonce-value = quoted-string opaque = ""opaque"" EQUAL quoted-string stale = ""stale"" EQUAL ( ""true"" / ""false"" ) algorithm = ""algorithm"" EQUAL ( ""MD5"" / ""MD5-sess"" / token ) qop-options = ""qop"" EQUAL LDQUOT qop-value *("","" qop-value) RDQUOT qop-value = ""auth"" / ""auth-int"" / token Proxy-Authorization = ""Proxy-Authorization"" HCOLON credentials Rosenberg, et. al. Standards Track [Page 230] RFC 3261 SIP: Session Initiation Protocol June 2002 Proxy-Require = ""Proxy-Require"" HCOLON option-tag *(COMMA option-tag) option-tag = token Record-Route = ""Record-Route"" HCOLON rec-route *(COMMA rec-route) rec-route = name-addr *( SEMI rr-param ) rr-param = generic-param Reply-To = ""Reply-To"" HCOLON rplyto-spec rplyto-spec = ( name-addr / addr-spec ) *( SEMI rplyto-param ) rplyto-param = generic-param Require = ""Require"" HCOLON option-tag *(COMMA option-tag) Retry-After = ""Retry-After"" HCOLON delta-seconds [ comment ] *( SEMI retry-param ) retry-param = (""duration"" EQUAL delta-seconds) / generic-param Route = ""Route"" HCOLON route-param *(COMMA route-param) route-param = name-addr *( SEMI rr-param ) Server = ""Server"" HCOLON server-val *(LWS server-val) server-val = product / comment product = token [SLASH product-version] product-version = token Subject = ( ""Subject"" / ""s"" ) HCOLON [TEXT-UTF8-TRIM] Supported = ( ""Supported"" / ""k"" ) HCOLON [option-tag *(COMMA option-tag)] Timestamp = ""Timestamp"" HCOLON 1*(DIGIT) [ ""."" *(DIGIT) ] [ LWS delay ] delay = *(DIGIT) [ ""."" *(DIGIT) ] To = ( ""To"" / ""t"" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param ) to-param = tag-param / generic-param Unsupported = ""Unsupported"" HCOLON option-tag *(COMMA option-tag) User-Agent = ""User-Agent"" HCOLON server-val *(LWS server-val) Rosenberg, et. al. Standards Track [Page 231] RFC 3261 SIP: Session Initiation Protocol June 2002 Via = ( ""Via"" / ""v"" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-ttl = ""ttl"" EQUAL ttl via-maddr = ""maddr"" EQUAL host via-received = ""received"" EQUAL (IPv4address / IPv6address) via-branch = ""branch"" EQUAL token via-extension = generic-param sent-protocol = protocol-name SLASH protocol-version SLASH transport protocol-name = ""SIP"" / token protocol-version = token transport = ""UDP"" / ""TCP"" / ""TLS"" / ""SCTP"" / other-transport sent-by = host [ COLON port ] ttl = 1*3DIGIT ; 0 to 255 Warning = ""Warning"" HCOLON warning-value *(COMMA warning-value) warning-value = warn-code SP warn-agent SP warn-text warn-code = 3DIGIT warn-agent = hostport / pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string pseudonym = token WWW-Authenticate = ""WWW-Authenticate"" HCOLON challenge extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) message-body = *OCTET 26 Security Considerations: Threat Model and Security Usage Recommendations SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial. Security solutions are needed that are deployable today, without extensive coordination, in a wide variety of environments and usages. In order to meet these diverse needs, several distinct mechanisms applicable to different aspects and usages of SIP will be required. Rosenberg, et. al. Standards Track [Page 232] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that the security of SIP signaling itself has no bearing on the security of protocols used in concert with SIP such as RTP, or with the security implications of any specific bodies SIP might carry (although MIME security plays a substantial role in securing SIP). Any media associated with a session can be encrypted end-to-end independently of any associated SIP signaling. Media encryption is outside the scope of this document. The considerations that follow first examine a set of classic threat models that broadly identify the security needs of SIP. The set of security services required to address these threats is then detailed, followed by an explanation of several security mechanisms that can be used to provide these services. Next, the requirements for implementers of SIP are enumerated, along with exemplary deployments in which these security mechanisms could be used to improve the security of SIP. Some notes on privacy conclude this section. 26.1 Attacks and Threat Models This section details some threats that should be common to most deployments of SIP. These threats have been chosen specifically to illustrate each of the security services that SIP requires. The following examples by no means provide an exhaustive list of the threats against SIP; rather, these are ""classic"" threats that demonstrate the need for particular security services that can potentially prevent whole categories of threats. These attacks assume an environment in which attackers can potentially read any packet on the network - it is anticipated that SIP will frequently be used on the public Internet. Attackers on the network may be able to modify packets (perhaps at some compromised intermediary). Attackers may wish to steal services, eavesdrop on communications, or disrupt sessions. 26.1.1 Registration Hijacking The SIP registration mechanism allows a user agent to identify itself to a registrar as a device at which a user (designated by an address of record) is located. A registrar assesses the identity asserted in the From header field of a REGISTER message to determine whether this request can modify the contact addresses associated with the address-of-record in the To header field. While these two fields are frequently the same, there are many valid deployments in which a third-party may register contacts on a user's behalf. Rosenberg, et. al. Standards Track [Page 233] RFC 3261 SIP: Session Initiation Protocol June 2002 The From header field of a SIP request, however, can be modified arbitrarily by the owner of a UA, and this opens the door to malicious registrations. An attacker that successfully impersonates a party authorized to change contacts associated with an address-of- record could, for example, de-register all existing contacts for a URI and then register their own device as the appropriate contact address, thereby directing all requests for the affected user to the attacker's device. This threat belongs to a family of threats that rely on the absence of cryptographic assurance of a request's originator. Any SIP UAS that represents a valuable service (a gateway that interworks SIP requests with traditional telephone calls, for example) might want to control access to its resources by authenticating requests that it receives. Even end-user UAs, for example SIP phones, have an interest in ascertaining the identities of originators of requests. This threat demonstrates the need for security services that enable SIP entities to authenticate the originators of requests. 26.1.2 Impersonating a Server The domain to which a request is destined is generally specified in the Request-URI. UAs commonly contact a server in this domain directly in order to deliver a request. However, there is always a possibility that an attacker could impersonate the remote server, and that the UA's request could be intercepted by some other party. For example, consider a case in which a redirect server at one domain, chicago.com, impersonates a redirect server at another domain, biloxi.com. A user agent sends a request to biloxi.com, but the redirect server at chicago.com answers with a forged response that has appropriate SIP header fields for a response from biloxi.com. The forged contact addresses in the redirection response could direct the originating UA to inappropriate or insecure resources, or simply prevent requests for biloxi.com from succeeding. This family of threats has a vast membership, many of which are critical. As a converse to the registration hijacking threat, consider the case in which a registration sent to biloxi.com is intercepted by chicago.com, which replies to the intercepted registration with a forged 301 (Moved Permanently) response. This response might seem to come from biloxi.com yet designate chicago.com as the appropriate registrar. All future REGISTER requests from the originating UA would then go to chicago.com. Prevention of this threat requires a means by which UAs can authenticate the servers to whom they send requests. Rosenberg, et. al. Standards Track [Page 234] RFC 3261 SIP: Session Initiation Protocol June 2002 26.1.3 Tampering with Message Bodies As a matter of course, SIP UAs route requests through trusted proxy servers. Regardless of how that trust is established (authentication of proxies is discussed elsewhere in this section), a UA may trust a proxy server to route a request, but not to inspect or possibly modify the bodies contained in that request. Consider a UA that is using SIP message bodies to communicate session encryption keys for a media session. Although it trusts the proxy server of the domain it is contacting to deliver signaling properly, it may not want the administrators of that domain to be capable of decrypting any subsequent media session. Worse yet, if the proxy server were actively malicious, it could modify the session key, either acting as a man-in-the-middle, or perhaps changing the security characteristics requested by the originating UA. This family of threats applies not only to session keys, but to most conceivable forms of content carried end-to-end in SIP. These might include MIME bodies that should be rendered to the user, SDP, or encapsulated telephony signals, among others. Attackers might attempt to modify SDP bodies, for example, in order to point RTP media streams to a wiretapping device in order to eavesdrop on subsequent voice communications. Also note that some header fields in SIP are meaningful end-to-end, for example, Subject. UAs might be protective of these header fields as well as bodies (a malicious intermediary changing the Subject header field might make an important request appear to be spam, for example). However, since many header fields are legitimately inspected or altered by proxy servers as a request is routed, not all header fields should be secured end-to-end. For these reasons, the UA might want to secure SIP message bodies, and in some limited cases header fields, end-to-end. The security services required for bodies include confidentiality, integrity, and authentication. These end-to-end services should be independent of the means used to secure interactions with intermediaries such as proxy servers. 26.1.4 Tearing Down Sessions Once a dialog has been established by initial messaging, subsequent requests can be sent that modify the state of the dialog and/or session. It is critical that principals in a session can be certain that such requests are not forged by attackers. Rosenberg, et. al. Standards Track [Page 235] RFC 3261 SIP: Session Initiation Protocol June 2002 Consider a case in which a third-party attacker captures some initial messages in a dialog shared by two parties in order to learn the parameters of the session (To tag, From tag, and so forth) and then inserts a BYE request into the session. The attacker could opt to forge the request such that it seemed to come from either participant. Once the BYE is received by its target, the session will be torn down prematurely. Similar mid-session threats include the transmission of forged re- INVITEs that alter the session (possibly to reduce session security or redirect media streams as part of a wiretapping attack). The most effective countermeasure to this threat is the authentication of the sender of the BYE. In this instance, the recipient needs only know that the BYE came from the same party with whom the corresponding dialog was established (as opposed to ascertaining the absolute identity of the sender). Also, if the attacker is unable to learn the parameters of the session due to confidentiality, it would not be possible to forge the BYE. However, some intermediaries (like proxy servers) will need to inspect those parameters as the session is established. 26.1.5 Denial of Service and Amplification Denial-of-service attacks focus on rendering a particular network element unavailable, usually by directing an excessive amount of network traffic at its interfaces. A distributed denial-of-service attack allows one network user to cause multiple network hosts to flood a target host with a large amount of network traffic. In many architectures, SIP proxy servers face the public Internet in order to accept requests from worldwide IP endpoints. SIP creates a number of potential opportunities for distributed denial-of-service attacks that must be recognized and addressed by the implementers and operators of SIP systems. Attackers can create bogus requests that contain a falsified source IP address and a corresponding Via header field that identify a targeted host as the originator of the request and then send this request to a large number of SIP network elements, thereby using hapless SIP UAs or proxies to generate denial-of-service traffic aimed at the target. Similarly, attackers might use falsified Route header field values in a request that identify the target host and then send such messages to forking proxies that will amplify messaging sent to the target. Rosenberg, et. al. Standards Track [Page 236] RFC 3261 SIP: Session Initiation Protocol June 2002 Record-Route could be used to similar effect when the attacker is certain that the SIP dialog initiated by the request will result in numerous transactions originating in the backwards direction. A number of denial-of-service attacks open up if REGISTER requests are not properly authenticated and authorized by registrars. Attackers could de-register some or all users in an administrative domain, thereby preventing these users from being invited to new sessions. An attacker could also register a large number of contacts designating the same host for a given address-of-record in order to use the registrar and any associated proxy servers as amplifiers in a denial-of-service attack. Attackers might also attempt to deplete available memory and disk resources of a registrar by registering huge numbers of bindings. The use of multicast to transmit SIP requests can greatly increase the potential for denial-of-service attacks. These problems demonstrate a general need to define architectures that minimize the risks of denial-of-service, and the need to be mindful in recommendations for security mechanisms of this class of attacks. 26.2 Security Mechanisms From the threats described above, we gather that the fundamental security services required for the SIP protocol are: preserving the confidentiality and integrity of messaging, preventing replay attacks or message spoofing, providing for the authentication and privacy of the participants in a session, and preventing denial-of-service attacks. Bodies within SIP messages separately require the security services of confidentiality, integrity, and authentication. Rather than defining new security mechanisms specific to SIP, SIP reuses wherever possible existing security models derived from the HTTP and SMTP space. Full encryption of messages provides the best means to preserve the confidentiality of signaling - it can also guarantee that messages are not modified by any malicious intermediaries. However, SIP requests and responses cannot be naively encrypted end-to-end in their entirety because message fields such as the Request-URI, Route, and Via need to be visible to proxies in most network architectures so that SIP requests are routed correctly. Note that proxy servers need to modify some features of messages as well (such as adding Via header field values) in order for SIP to function. Proxy servers must therefore be trusted, to some degree, by SIP UAs. To this purpose, low-layer security mechanisms for SIP are recommended, which Rosenberg, et. al. Standards Track [Page 237] RFC 3261 SIP: Session Initiation Protocol June 2002 encrypt the entire SIP requests or responses on the wire on a hop- by-hop basis, and that allow endpoints to verify the identity of proxy servers to whom they send requests. SIP entities also have a need to identify one another in a secure fashion. When a SIP endpoint asserts the identity of its user to a peer UA or to a proxy server, that identity should in some way be verifiable. A cryptographic authentication mechanism is provided in SIP to address this requirement. An independent security mechanism for SIP message bodies supplies an alternative means of end-to-end mutual authentication, as well as providing a limit on the degree to which user agents must trust intermediaries. 26.2.1 Transport and Network Layer Security Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and integrity. Oftentimes, certificates are used in the establishment of lower-layer security, and these certificates can also be used to provide a means of authentication in many architectures. Two popular alternatives for providing security at the transport and network layer are, respectively, TLS [25] and IPSec [26]. IPSec is a set of network-layer protocol tools that collectively can be used as a secure replacement for traditional IP (Internet Protocol). IPSec is most commonly used in architectures in which a set of hosts or administrative domains have an existing trust relationship with one another. IPSec is usually implemented at the operating system level in a host, or on a security gateway that provides confidentiality and integrity for all traffic it receives from a particular interface (as in a VPN architecture). IPSec can also be used on a hop-by-hop basis. In many architectures IPSec does not require integration with SIP applications; IPSec is perhaps best suited to deployments in which adding security directly to SIP hosts would be arduous. UAs that have a pre-shared keying relationship with their first-hop proxy server are also good candidates to use IPSec. Any deployment of IPSec for SIP would require an IPSec profile describing the protocol tools that would be required to secure SIP. No such profile is given in this document. Rosenberg, et. al. Standards Track [Page 238] RFC 3261 SIP: Session Initiation Protocol June 2002 TLS provides transport-layer security over connection-oriented protocols (for the purposes of this document, TCP); ""tls"" (signifying TLS over TCP) can be specified as the desired transport protocol within a Via header field value or a SIP-URI. TLS is most suited to architectures in which hop-by-hop security is required between hosts with no pre-existing trust association. For example, Alice trusts her local proxy server, which after a certificate exchange decides to trust Bob's local proxy server, which Bob trusts, hence Bob and Alice can communicate securely. TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on a hop-by-hop basis in SIP, thus a UA that sends requests over TLS to a proxy server has no assurance that TLS will be used end-to-end. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at a minimum by implementers when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, redirect servers, and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other ciphersuite. 26.2.2 SIPS URI Scheme The SIPS URI scheme adheres to the syntax of the SIP URI (described in 19), although the scheme string is ""sips"" rather than ""sip"". The semantics of SIPS are very different from the SIP URI, however. SIPS allows resources to specify that they should be reached securely. A SIPS URI can be used as an address-of-record for a particular user - the URI by which the user is canonically known (on their business cards, in the From header field of their requests, in the To header field of REGISTER requests). When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured. The SIPS scheme is applicable to many of the other ways in which SIP URIs are used in SIP today in addition to the Request-URI, including in addresses-of-record, contact addresses (the contents of Contact headers, including those of REGISTER methods), and Route headers. In each instance, the SIPS URI scheme allows these existing fields to Rosenberg, et. al. Standards Track [Page 239] RFC 3261 SIP: Session Initiation Protocol June 2002 designate secure resources. The manner in which a SIPS URI is dereferenced in any of these contexts has its own security properties which are detailed in [4]. The use of SIPS in particular entails that mutual TLS authentication SHOULD be employed, as SHOULD the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the authentication process SHOULD be validated with root certificates held by the client; failure to validate a certificate SHOULD result in the failure of the request. Note that in the SIPS URI scheme, transport is independent of TLS, and thus ""sips:alice@atlanta.com;transport=tcp"" and ""sips:alice@atlanta.com;transport=sctp"" are both valid (although note that UDP is not a valid transport for SIPS). The use of ""transport=tls"" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports. 26.2.3 HTTP Authentication SIP provides a challenge capability, based on HTTP authentication, that relies on the 401 and 407 response codes as well as header fields for carrying challenges and credentials. Without significant modification, the reuse of the HTTP Digest authentication scheme in SIP allows for replay protection and one-way authentication. The usage of Digest authentication in SIP is detailed in Section 22. 26.2.4 S/MIME As is discussed above, encrypting entire SIP messages end-to-end for the purpose of confidentiality is not appropriate because network intermediaries (like proxy servers) need to view certain header fields in order to route messages correctly, and if these intermediaries are excluded from security associations, then SIP messages will essentially be non-routable. However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, securing these bodies end-to-end without affecting message headers. S/MIME can provide end-to-end confidentiality and integrity for message bodies, as well as mutual authentication. It is also possible to use S/MIME to provide a form of integrity and confidentiality for SIP header fields through SIP message tunneling. Rosenberg, et. al. Standards Track [Page 240] RFC 3261 SIP: Session Initiation Protocol June 2002 The usage of S/MIME in SIP is detailed in Section 23. 26.3 Implementing Security Mechanisms 26.3.1 Requirements for Implementers of SIP Proxy servers, redirect servers, and registrars MUST implement TLS, and MUST support both mutual and one-way authentication. It is strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also be capable of acting as a TLS server. Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname. UAs MAY have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. All SIP elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers). All SIP elements that support TLS MUST also support the SIPS URI scheme. Proxy servers, redirect servers, registrars, and UAs MAY also implement IPSec or other lower-layer security protocols. When a UA attempts to contact a proxy server, redirect server, or registrar, the UAC SHOULD initiate a TLS connection over which it will send SIP messages. In some architectures, UASs MAY receive requests over such TLS connections as well. Proxy servers, redirect servers, registrars, and UAs MUST implement Digest Authorization, encompassing all of the aspects required in 22. Proxy servers, redirect servers, and registrars SHOULD be configured with at least one Digest realm, and at least one ""realm"" string supported by a given server SHOULD correspond to the server's hostname or domainname. UAs MAY support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23. If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it SHOULD be capable of reusing these to verify S/MIME certificates, as appropriate. A UA MAY hold root certificates specifically for validating S/MIME certificates. Rosenberg, et. al. Standards Track [Page 241] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that is it anticipated that future security extensions may upgrade the normative strength associated with S/MIME as S/MIME implementations appear and the problem space becomes better understood. 26.3.2 Security Solutions The operation of these security mechanisms in concert can follow the existing web and email security models to some degree. At a high level, UAs authenticate themselves to servers (proxy servers, redirect servers, and registrars) with a Digest username and password; servers authenticate themselves to UAs one hop away, or to another server one hop away (and vice versa), with a site certificate delivered by TLS. On a peer-to-peer level, UAs trust the network to authenticate one another ordinarily; however, S/MIME can also be used to provide direct authentication when the network does not, or if the network itself is not trusted. The following is an illustrative example in which these security mechanisms are used by various UAs and servers to prevent the sorts of threats described in Section 26.1. While implementers and network administrators MAY follow the normative guidelines given in the remainder of this section, these are provided only as example implementations. 26.3.2.1 Registration When a UA comes online and registers with its local administrative domain, it SHOULD establish a TLS connection with its registrar (Section 10 describes how the UA reaches its registrar). The registrar SHOULD offer a certificate to the UA, and the site identified by the certificate MUST correspond with the domain in which the UA intends to register; for example, if the UA intends to register the address-of-record 'alice@atlanta.com', the site certificate must identify a host within the atlanta.com domain (such as sip.atlanta.com). When it receives the TLS Certificate message, the UA SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid, revoked, or if it does not identify the appropriate party, the UA MUST NOT send the REGISTER message and otherwise proceed with the registration. When a valid certificate has been provided by the registrar, the UA knows that the registrar is not an attacker who might redirect the UA, steal passwords, or attempt any similar attacks. Rosenberg, et. al. Standards Track [Page 242] RFC 3261 SIP: Session Initiation Protocol June 2002 The UA then creates a REGISTER request that SHOULD be addressed to a Request-URI corresponding to the site certificate received from the registrar. When the UA sends the REGISTER request over the existing TLS connection, the registrar SHOULD challenge the request with a 401 (Proxy Authentication Required) response. The ""realm"" parameter within the Proxy-Authenticate header field of the response SHOULD correspond to the domain previously given by the site certificate. When the UAC receives the challenge, it SHOULD either prompt the user for credentials or take an appropriate credential from a keyring corresponding to the ""realm"" parameter in the challenge. The username of this credential SHOULD correspond with the ""userinfo"" portion of the URI in the To header field of the REGISTER request. Once the Digest credentials have been inserted into an appropriate Proxy-Authorization header field, the REGISTER should be resubmitted to the registrar. Since the registrar requires the user agent to authenticate itself, it would be difficult for an attacker to forge REGISTER requests for the user's address-of-record. Also note that since the REGISTER is sent over a confidential TLS connection, attackers will not be able to intercept the REGISTER to record credentials for any possible replay attack. Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that has just completed registration."
"Because the UA has already authenticated the server on the other side of the TLS connection, all requests that come over this connection are known to have passed through the proxy server - attackers cannot create spoofed requests that appear to have been sent through that proxy server. 26.3.2.2 Interdomain Requests Now let's say that Alice's UA would like to initiate a session with a user in a remote administrative domain, namely ""bob@biloxi.com"". We will also say that the local administrative domain (atlanta.com) has a local outbound proxy. The proxy server that handles inbound requests for an administrative domain MAY also act as a local outbound proxy; for simplicity's sake we'll assume this to be the case for atlanta.com (otherwise the user agent would initiate a new TLS connection to a separate server at this point). Assuming that the client has completed the registration Rosenberg, et. al. Standards Track [Page 243] RFC 3261 SIP: Session Initiation Protocol June 2002 process described in the preceding section, it SHOULD reuse the TLS connection to the local proxy server when it sends an INVITE request to another user. The UA SHOULD reuse cached credentials in the INVITE to avoid prompting the user unnecessarily. When the local outbound proxy server has validated the credentials presented by the UA in the INVITE, it SHOULD inspect the Request-URI to determine how the message should be routed (see [4]). If the ""domainname"" portion of the Request-URI had corresponded to the local domain (atlanta.com) rather than biloxi.com, then the proxy server would have consulted its location service to determine how best to reach the requested user. Had ""alice@atlanta.com"" been attempting to contact, say, ""alex@atlanta.com"", the local proxy would have proxied to the request to the TLS connection Alex had established with the registrar when he registered. Since Alex would receive this request over his authenticated channel, he would be assured that Alice's request had been authorized by the proxy server of the local administrative domain. However, in this instance the Request-URI designates a remote domain. The local outbound proxy server at atlanta.com SHOULD therefore establish a TLS connection with the remote proxy server at biloxi.com. Since both of the participants in this TLS connection are servers that possess site certificates, mutual TLS authentication SHOULD occur. Each side of the connection SHOULD verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages. The atlanta.com proxy server, for example, SHOULD verify at this stage that the certificate received from the remote side corresponds with the biloxi.com domain. Once it has done so, and TLS negotiation has completed, resulting in a secure channel between the two proxies, the atlanta.com proxy can forward the INVITE request to biloxi.com. The proxy server at biloxi.com SHOULD inspect the certificate of the proxy server at atlanta.com in turn and compare the domain asserted by the certificate with the ""domainname"" portion of the From header field in the INVITE request. The biloxi proxy MAY have a strict security policy that requires it to reject requests that do not match the administrative domain from which they have been proxied. Such security policies could be instituted to prevent the SIP equivalent of SMTP 'open relays' that are frequently exploited to generate spam. Rosenberg, et. al. Standards Track [Page 244] RFC 3261 SIP: Session Initiation Protocol June 2002 This policy, however, only guarantees that the request came from the domain it ascribes to itself; it does not allow biloxi.com to ascertain how atlanta.com authenticated Alice. Only if biloxi.com has some other way of knowing atlanta.com's authentication policies could it possibly ascertain how Alice proved her identity. biloxi.com might then institute an even stricter policy that forbids requests that come from domains that are not known administratively to share a common authentication policy with biloxi.com. Once the INVITE has been approved by the biloxi proxy, the proxy server SHOULD identify the existing TLS channel, if any, associated with the user targeted by this request (in this case ""bob@biloxi.com""). The INVITE should be proxied through this channel to Bob. Since the request is received over a TLS connection that had previously been authenticated as the biloxi proxy, Bob knows that the From header field was not tampered with and that atlanta.com has validated Alice, although not necessarily whether or not to trust Alice's identity. Before they forward the request, both proxy servers SHOULD add a Record-Route header field to the request so that all future requests in this dialog will pass through the proxy servers. The proxy servers can thereby continue to provide security services for the lifetime of this dialog. If the proxy servers do not add themselves to the Record-Route, future messages will pass directly end-to-end between Alice and Bob without any security services (unless the two parties agree on some independent end-to-end security such as S/MIME). In this respect the SIP trapezoid model can provide a nice structure where conventions of agreement between the site proxies can provide a reasonably secure channel between Alice and Bob. An attacker preying on this architecture would, for example, be unable to forge a BYE request and insert it into the signaling stream between Bob and Alice because the attacker has no way of ascertaining the parameters of the session and also because the integrity mechanism transitively protects the traffic between Alice and Bob. 26.3.2.3 Peer-to-Peer Requests Alternatively, consider a UA asserting the identity ""carol@chicago.com"" that has no local outbound proxy. When Carol wishes to send an INVITE to ""bob@biloxi.com"", her UA SHOULD initiate a TLS connection with the biloxi proxy directly (using the mechanism described in [4] to determine how to best to reach the given Request-URI). When her UA receives a certificate from the biloxi proxy, it SHOULD be verified normally before she passes her INVITE across the TLS connection. However, Carol has no means of proving Rosenberg, et. al. Standards Track [Page 245] RFC 3261 SIP: Session Initiation Protocol June 2002 her identity to the biloxi proxy, but she does have a CMS-detached signature over a ""message/sip"" body in the INVITE. It is unlikely in this instance that Carol would have any credentials in the biloxi.com realm, since she has no formal association with biloxi.com. The biloxi proxy MAY also have a strict policy that precludes it from even bothering to challenge requests that do not have biloxi.com in the ""domainname"" portion of the From header field - it treats these users as unauthenticated. The biloxi proxy has a policy for Bob that all non-authenticated requests should be redirected to the appropriate contact address registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>. Carol receives the redirection response over the TLS connection she established with the biloxi proxy, so she trusts the veracity of the contact address. Carol SHOULD then establish a TCP connection with the designated address and send a new INVITE with a Request-URI containing the received contact address (recomputing the signature in the body as the request is readied). Bob receives this INVITE on an insecure interface, but his UA inspects and, in this instance, recognizes the From header field of the request and subsequently matches a locally cached certificate with the one presented in the signature of the body of the INVITE. He replies in similar fashion, authenticating himself to Carol, and a secure dialog begins. Sometimes firewalls or NATs in an administrative domain could preclude the establishment of a direct TCP connection to a UA. In these cases, proxy servers could also potentially relay requests to UAs in a way that has no trust implications (for example, forgoing an existing TLS connection and forwarding the request over cleartext TCP) as local policy dictates. 26.3.2.4 DoS Protection In order to minimize the risk of a denial-of-service attack against architectures using these security solutions, implementers should take note of the following guidelines. When the host on which a SIP proxy server is operating is routable from the public Internet, it SHOULD be deployed in an administrative domain with defensive operational policies (blocking source-routed traffic, preferably filtering ping traffic). Both TLS and IPSec can also make use of bastion hosts at the edges of administrative domains that participate in the security associations to aggregate secure tunnels and sockets. These bastion hosts can also take the brunt of denial-of-service attacks, ensuring that SIP hosts within the administrative domain are not encumbered with superfluous messaging. Rosenberg, et. al. Standards Track [Page 246] RFC 3261 SIP: Session Initiation Protocol June 2002 No matter what security solutions are deployed, floods of messages directed at proxy servers can lock up proxy server resources and prevent desirable traffic from reaching its destination. There is a computational expense associated with processing a SIP transaction at a proxy server, and that expense is greater for stateful proxy servers than it is for stateless proxy servers. Therefore, stateful proxies are more susceptible to flooding than stateless proxy servers. UAs and proxy servers SHOULD challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests. Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication Required) status response amplifies the problem of an attacker using a falsified header field value (such as Via) to direct traffic to a third party. In summary, the mutual authentication of proxy servers through mechanisms such as TLS significantly reduces the potential for rogue intermediaries to introduce falsified requests or responses that can deny service. This commensurately makes it harder for attackers to make innocent SIP nodes into agents of amplification. 26.4 Limitations Although these security mechanisms, when applied in a judicious manner, can thwart many threats, there are limitations in the scope of the mechanisms that must be understood by implementers and network operators. 26.4.1 HTTP Digest One of the primary limitations of using HTTP Digest in SIP is that the integrity mechanisms in Digest do not work very well for SIP. Specifically, they offer protection of the Request-URI and the method of a message, but not for any of the header fields that UAs would most likely wish to secure. The existing replay protection mechanisms described in RFC 2617 also have some limitations for SIP. The next-nonce mechanism, for example, does not support pipelined requests. The nonce-count mechanism should be used for replay protection. Another limitation of HTTP Digest is the scope of realms. Digest is valuable when a user wants to authenticate themselves to a resource with which they have a pre-existing association, like a service Rosenberg, et. al. Standards Track [Page 247] RFC 3261 SIP: Session Initiation Protocol June 2002 provider of which the user is a customer (which is quite a common scenario and thus Digest provides an extremely useful function). By way of contrast, the scope of TLS is interdomain or multirealm, since certificates are often globally verifiable, so that the UA can authenticate the server with no pre-existing association. 26.4.2 S/MIME The largest outstanding defect with the S/MIME mechanism is the lack of a prevalent public key infrastructure for end users. If self- signed certificates (or certificates that cannot be verified by one of the participants in a dialog) are used, the SIP-based key exchange mechanism described in Section 23.2 is susceptible to a man-in-the- middle attack with which an attacker can potentially inspect and modify S/MIME bodies. The attacker needs to intercept the first exchange of keys between the two parties in a dialog, remove the existing CMS-detached signatures from the request and response, and insert a different CMS-detached signature containing a certificate supplied by the attacker (but which seems to be a certificate for the proper address-of-record). Each party will think they have exchanged keys with the other, when in fact each has the public key of the attacker. It is important to note that the attacker can only leverage this vulnerability on the first exchange of keys between two parties - on subsequent occasions, the alteration of the key would be noticeable to the UAs. It would also be difficult for the attacker to remain in the path of all future dialogs between the two parties over time (as potentially days, weeks, or years pass). SSH is susceptible to the same man-in-the-middle attack on the first exchange of keys; however, it is widely acknowledged that while SSH is not perfect, it does improve the security of connections. The use of key fingerprints could provide some assistance to SIP, just as it does for SSH. For example, if two parties use SIP to establish a voice communications session, each could read off the fingerprint of the key they received from the other, which could be compared against the original. It would certainly be more difficult for the man-in- the-middle to emulate the voices of the participants than their signaling (a practice that was used with the Clipper chip-based secure telephone). The S/MIME mechanism allows UAs to send encrypted requests without preamble if they possess a certificate for the destination address- of-record on their keyring. However, it is possible that any particular device registered for an address-of-record will not hold the certificate that has been previously employed by the device's current user, and that it will therefore be unable to process an Rosenberg, et. al. Standards Track [Page 248] RFC 3261 SIP: Session Initiation Protocol June 2002 encrypted request properly, which could lead to some avoidable error signaling. This is especially likely when an encrypted request is forked. The keys associated with S/MIME are most useful when associated with a particular user (an address-of-record) rather than a device (a UA). When users move between devices, it may be difficult to transport private keys securely between UAs; how such keys might be acquired by a device is outside the scope of this document. Another, more prosaic difficulty with the S/MIME mechanism is that it can result in very large messages, especially when the SIP tunneling mechanism described in Section 23.4 is used. For that reason, it is RECOMMENDED that TCP should be used as a transport protocol when S/MIME tunneling is employed. 26.4.3 TLS The most commonly voiced concern about TLS is that it cannot run over UDP; TLS requires a connection-oriented underlying transport protocol, which for the purposes of this document means TCP. It may also be arduous for a local outbound proxy server and/or registrar to maintain many simultaneous long-lived TLS connections with numerous UAs. This introduces some valid scalability concerns, especially for intensive ciphersuites. Maintaining redundancy of long-lived TLS connections, especially when a UA is solely responsible for their establishment, could also be cumbersome. TLS only allows SIP entities to authenticate servers to which they are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, nor any other mechanism specified in this document, allows clients to authenticate proxy servers to whom they cannot form a direct TCP connection. 26.4.4 SIPS URIs Actually using TLS on every segment of a request path entails that the terminating UAS must be reachable over TLS (perhaps registering with a SIPS URI as a contact address). This is the preferred use of SIPS. Many valid architectures, however, use TLS to secure part of the request path, but rely on some other mechanism for the final hop to a UAS, for example. Thus SIPS cannot guarantee that TLS usage will be truly end-to-end. Note that since many UAs will not accept incoming TLS connections, even those UAs that do support TLS may be required to maintain persistent TLS connections as described in the TLS limitations section above in order to receive requests over TLS as a UAS. Rosenberg, et. al. Standards Track [Page 249] RFC 3261 SIP: Session Initiation Protocol June 2002 Location services are not required to provide a SIPS binding for a SIPS Request-URI. Although location services are commonly populated by user registrations (as described in Section 10.2.1), various other protocols and interfaces could conceivably supply contact addresses for an AOR, and these tools are free to map SIPS URIs to SIP URIs as appropriate. When queried for bindings, a location service returns its contact addresses without regard for whether it received a request with a SIPS Request-URI. If a redirect server is accessing the location service, it is up to the entity that processes the Contact header field of a redirection to determine the propriety of the contact addresses. Ensuring that TLS will be used for all of the request segments up to the target domain is somewhat complex. It is possible that cryptographically authenticated proxy servers along the way that are non-compliant or compromised may choose to disregard the forwarding rules associated with SIPS (and the general forwarding rules in Section 16.6). Such malicious intermediaries could, for example, retarget a request from a SIPS URI to a SIP URI in an attempt to downgrade security. Alternatively, an intermediary might legitimately retarget a request from a SIP to a SIPS URI. Recipients of a request whose Request-URI uses the SIPS URI scheme thus cannot assume on the basis of the Request-URI alone that SIPS was used for the entire request path (from the client onwards). To address these concerns, it is RECOMMENDED that recipients of a request whose Request-URI contains a SIP or SIPS URI inspect the To header field value to see if it contains a SIPS URI (though note that it does not constitute a breach of security if this URI has the same scheme but is not equivalent to the URI in the To header field). Although clients may choose to populate the Request-URI and To header field of a request differently, when SIPS is used this disparity could be interpreted as a possible security violation, and the request could consequently be rejected by its recipient. Recipients MAY also inspect the Via header chain in order to double-check whether or not TLS was used for the entire request path until the local administrative domain was reached. S/MIME may also be used by the originating UAC to help ensure that the original form of the To header field is carried end-to-end. If the UAS has reason to believe that the scheme of the Request-URI has been improperly modified in transit, the UA SHOULD notify its user of a potential security breach. Rosenberg, et. al. Standards Track [Page 250] RFC 3261 SIP: Session Initiation Protocol June 2002 As a further measure to prevent downgrade attacks, entities that accept only SIPS requests MAY also refuse connections on insecure ports. End users will undoubtedly discern the difference between SIPS and SIP URIs, and they may manually edit them in response to stimuli. This can either benefit or degrade security. For example, if an attacker corrupts a DNS cache, inserting a fake record set that effectively removes all SIPS records for a proxy server, then any SIPS requests that traverse this proxy server may fail. When a user, however, sees that repeated calls to a SIPS AOR are failing, they could on some devices manually convert the scheme from SIPS to SIP and retry. Of course, there are some safeguards against this (if the destination UA is truly paranoid it could refuse all non-SIPS requests), but it is a limitation worth noting. On the bright side, users might also divine that 'SIPS' would be valid even when they are presented only with a SIP URI. 26.5 Privacy SIP messages frequently contain sensitive information about their senders - not just what they have to say, but with whom they communicate, when they communicate and for how long, and from where they participate in sessions. Many applications and their users require that this sort of private information be hidden from any parties that do not need to know it. Note that there are also less direct ways in which private information can be divulged. If a user or service chooses to be reachable at an address that is guessable from the person's name and organizational affiliation (which describes most addresses-of- record), the traditional method of ensuring privacy by having an unlisted ""phone number"" is compromised. A user location service can infringe on the privacy of the recipient of a session invitation by divulging their specific whereabouts to the caller; an implementation consequently SHOULD be able to restrict, on a per-user basis, what kind of location and availability information is given out to certain classes of callers. This is a whole class of problem that is expected to be studied further in ongoing SIP work. In some cases, users may want to conceal personal information in header fields that convey identity. This can apply not only to the From and related headers representing the originator of the request, but also the To - it may not be appropriate to convey to the final destination a speed-dialing nickname, or an unexpanded identifier for a group of targets, either of which would be removed from the Request-URI as the request is routed, but not changed in the To Rosenberg, et. al. Standards Track [Page 251] RFC 3261 SIP: Session Initiation Protocol June 2002 header field if the two were initially identical. Thus it MAY be desirable for privacy reasons to create a To header field that differs from the Request-URI. 27 IANA Considerations All method names, header field names, status codes, and option tags used in SIP applications are registered with IANA through instructions in an IANA Considerations section in an RFC. The specification instructs the IANA to create four new sub- registries under http://www.iana.org/assignments/sip-parameters: Option Tags, Warning Codes (warn-codes), Methods and Response Codes, added to the sub-registry of Header Fields that is already present there. 27.1 Option Tags This specification establishes the Option Tags sub-registry under http://www.iana.org/assignments/sip-parameters. Option tags are used in header fields such as Require, Supported, Proxy-Require, and Unsupported in support of SIP compatibility mechanisms for extensions (Section 19.2). The option tag itself is a string that is associated with a particular SIP option (that is, an extension). It identifies the option to SIP endpoints. Option tags are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC must include the following information, which appears in the IANA registry along with the RFC number of the publication. o Name of the option tag. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (Section 25) characters only. o Descriptive text that describes the extension. 27.2 Warn-Codes This specification establishes the Warn-codes sub-registry under http://www.iana.org/assignments/sip-parameters and initiates its population with the warn-codes listed in Section 20.43. Additional warn-codes are registered by RFC publication. Rosenberg, et. al. Standards Track [Page 252] RFC 3261 SIP: Session Initiation Protocol June 2002 The descriptive text for the table of warn-codes is: Warning codes provide information supplemental to the status code in SIP response messages when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. The ""warn-code"" consists of three digits. A first digit of ""3"" indicates warnings specific to SIP. Until a future specification describes uses of warn-codes other than 3xx, only 3xx warn-codes may be registered. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories. 27.3 Header Field Names This obsoletes the IANA instructions about the header sub-registry under http://www.iana.org/assignments/sip-parameters. The following information needs to be provided in an RFC publication in order to register a new header field name: o The RFC number in which the header is registered; o the name of the header field being registered; o a compact form version for that header field, if one is defined; Some common and widely used header fields MAY be assigned one-letter compact forms (Section 7.3.3). Compact forms can only be assigned after SIP working group review, followed by RFC publication. 27.4 Method and Response Codes This specification establishes the Method and Response-Code sub- registries under http://www.iana.org/assignments/sip-parameters and initiates their population as follows. The initial Methods table is: Rosenberg, et. al. Standards Track [Page 253] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITE [RFC3261] ACK [RFC3261] BYE [RFC3261] CANCEL [RFC3261] REGISTER [RFC3261] OPTIONS [RFC3261] INFO [RFC2976] The response code table is initially populated from Section 21, the portions labeled Informational, Success, Redirection, Client-Error, Server-Error, and Global-Failure. The table has the following format: Type (e.g., Informational) Number Default Reason Phrase [RFC3261] The following information needs to be provided in an RFC publication in order to register a new response code or method: o The RFC number in which the method or response code is registered; o the number of the response code or name of the method being registered; o the default reason phrase for that response code, if applicable; 27.5 The ""message/sip"" MIME type. This document registers the ""message/sip"" MIME media type in order to allow SIP messages to be tunneled as bodies within SIP, primarily for end-to-end security purposes. This media type is defined by the following information: Media type name: message Media subtype name: sip Required parameters: none Optional parameters: version version: The SIP-Version number of the enclosed message (e.g., ""2.0""). If not present, the version defaults to ""2.0"". Encoding scheme: SIP messages consist of an 8-bit header optionally followed by a binary MIME data object. As such, SIP messages must be treated as binary. Under normal circumstances SIP messages are transported over binary-capable transports, no special encodings are needed. Rosenberg, et. al. Standards Track [Page 254] RFC 3261 SIP: Session Initiation Protocol June 2002 Security considerations: see below Motivation and examples of this usage as a security mechanism in concert with S/MIME are given in 23.4. 27.6 New Content-Disposition Parameter Registrations This document also registers four new Content-Disposition header ""disposition-types"": alert, icon, session and render. The authors request that these values be recorded in the IANA registry for Content-Dispositions. Descriptions of these ""disposition-types"", including motivation and examples, are given in Section 20.11. Short descriptions suitable for the IANA registry are: alert the body is a custom ring tone to alert the user icon the body is displayed as an icon to the user render the body should be displayed to the user session the body describes a communications session, for example, as RFC 2327 SDP body 28 Changes From RFC 2543 This RFC revises RFC 2543. It is mostly backwards compatible with RFC 2543. The changes described here fix many errors discovered in RFC 2543 and provide information on scenarios not detailed in RFC 2543. The protocol has been presented in a more cleanly layered model here. We break the differences into functional behavior that is a substantial change from RFC 2543, which has impact on interoperability or correct operation in some cases, and functional behavior that is different from RFC 2543 but not a potential source of interoperability problems. There have been countless clarifications as well, which are not documented here. 28.1 Major Functional Changes o When a UAC wishes to terminate a call before it has been answered, it sends CANCEL. If the original INVITE still returns a 2xx, the UAC then sends BYE. BYE can only be sent on an existing call leg (now called a dialog in this RFC), whereas it could be sent at any time in RFC 2543. o The SIP BNF was converted to be RFC 2234 compliant. Rosenberg, et. al. Standards Track [Page 255] RFC 3261 SIP: Session Initiation Protocol June 2002 o SIP URL BNF was made more general, allowing a greater set of characters in the user part. Furthermore, comparison rules were simplified to be primarily case-insensitive, and detailed handling of comparison in the presence of parameters was described. The most substantial change is that a URI with a parameter with the default value does not match a URI without that parameter. o Removed Via hiding. It had serious trust issues, since it relied on the next hop to perform the obfuscation process. Instead, Via hiding can be done as a local implementation choice in stateful proxies, and thus is no longer documented. o In RFC 2543, CANCEL and INVITE transactions were intermingled. They are separated now. When a user sends an INVITE and then a CANCEL, the INVITE transaction still terminates normally. A UAS needs to respond to the original INVITE request with a 487 response. o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 allowed the UAS not to send a response to INVITE when a BYE was received. That is disallowed here. The original INVITE needs a response. o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs need to support both UDP and TCP. o In RFC 2543, a forking proxy only passed up one challenge from downstream elements in the event of multiple challenges. In this RFC, proxies are supposed to collect all challenges and place them into the forwarded response. o In Digest credentials, the URI needs to be quoted; this is unclear from RFC 2617 and RFC 2069 which are both inconsistent on it. o SDP processing has been split off into a separate specification [13], and more fully specified as a formal offer/answer exchange process that is effectively tunneled through SIP. SDP is allowed in INVITE/200 or 200/ACK for baseline SIP implementations; RFC 2543 alluded to the ability to use it in INVITE, 200, and ACK in a single transaction, but this was not well specified. More complex SDP usages are allowed in extensions. Rosenberg, et. al. Standards Track [Page 256] RFC 3261 SIP: Session Initiation Protocol June 2002 o Added full support for IPv6 in URIs and in the Via header field. Support for IPv6 in Via has required that its header field parameters allow the square bracket and colon characters. These characters were previously not permitted. In theory, this could cause interop problems with older implementations. However, we have observed that most implementations accept any non-control ASCII character in these parameters. o DNS SRV procedure is now documented in a separate specification [4]. This procedure uses both SRV and NAPTR resource records and no longer combines data from across SRV records as described in RFC 2543. o Loop detection has been made optional, supplanted by a mandatory usage of Max-Forwards. The loop detection procedure in RFC 2543 had a serious bug which would report ""spirals"" as an error condition when it was not. The optional loop detection procedure is more fully and correctly specified here. o Usage of tags is now mandatory (they were optional in RFC 2543), as they are now the fundamental building blocks of dialog identification. o Added the Supported header field, allowing for clients to indicate what extensions are supported to a server, which can apply those extensions to the response, and indicate their usage with a Require in the response. o Extension parameters were missing from the BNF for several header fields, and they have been added. o Handling of Route and Record-Route construction was very underspecified in RFC 2543, and also not the right approach. It has been substantially reworked in this specification (and made vastly simpler), and this is arguably the largest change. Backwards compatibility is still provided for deployments that do not use ""pre-loaded routes"", where the initial request has a set of Route header field values obtained in some way outside of Record-Route. In those situations, the new mechanism is not interoperable. o In RFC 2543, lines in a message could be terminated with CR, LF, or CRLF. This specification only allows CRLF. Rosenberg, et. al. Standards Track [Page 257] RFC 3261 SIP: Session Initiation Protocol June 2002 o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. It is now well specified; if a request had a Route header field, its CANCEL or ACK for a non-2xx response to the request need to carry the same Route header field values. ACKs for 2xx responses use the Route values learned from the Record-Route of the 2xx responses. o RFC 2543 allowed multiple requests in a single UDP packet. This usage has been removed. o Usage of absolute time in the Expires header field and parameter has been removed. It caused interoperability problems in elements that were not time synchronized, a common occurrence. Relative times are used instead. o The branch parameter of the Via header field value is now mandatory for all elements to use. It now plays the role of a unique transaction identifier. This avoids the complex and bug- laden transaction identification rules from RFC 2543. A magic cookie is used in the parameter value to determine if the previous hop has made the parameter globally unique, and comparison falls back to the old rules when it is not present. Thus, interoperability is assured. o In RFC 2543, closure of a TCP connection was made equivalent to a CANCEL. This was nearly impossible to implement (and wrong) for TCP connections between proxies. This has been eliminated, so that there is no coupling between TCP connection state and SIP processing. o RFC 2543 was silent on whether a UA could initiate a new transaction to a peer while another was in progress. That is now specified here. It is allowed for non-INVITE requests, disallowed for INVITE. o PGP was removed. It was not sufficiently specified, and not compatible with the more complete PGP MIME. It was replaced with S/MIME. o Added the ""sips"" URI scheme for end-to-end TLS. This scheme is not backwards compatible with RFC 2543. Existing elements that receive a request with a SIPS URI scheme in the Request-URI will likely reject the request. This is actually a feature; it ensures that a call to a SIPS URI is only delivered if all path hops can be secured. Rosenberg, et. al. Standards Track [Page 258] RFC 3261 SIP: Session Initiation Protocol June 2002 o Additional security features were added with TLS, and these are described in a much larger and complete security considerations section. o In RFC 2543, a proxy was not required to forward provisional responses from 101 to 199 upstream. This was changed to MUST. This is important, since many subsequent features depend on delivery of all provisional responses from 101 to 199. o Little was said about the 503 response code in RFC 2543. It has since found substantial use in indicating failure or overload conditions in proxies. This requires somewhat special treatment. Specifically, receipt of a 503 should trigger an attempt to contact the next element in the result of a DNS SRV lookup. Also, 503 response is only forwarded upstream by a proxy under certain conditions. o RFC 2543 defined, but did no sufficiently specify, a mechanism for UA authentication of a server. That has been removed. Instead, the mutual authentication procedures of RFC 2617 are allowed. o A UA cannot send a BYE for a call until it has received an ACK for the initial INVITE. This was allowed in RFC 2543 but leads to a potential race condition. o A UA or proxy cannot send CANCEL for a transaction until it gets a provisional response for the request. This was allowed in RFC 2543 but leads to potential race conditions. o The action parameter in registrations has been deprecated. It was insufficient for any useful services, and caused conflicts when application processing was applied in proxies. o RFC 2543 had a number of special cases for multicast. For example, certain responses were suppressed, timers were adjusted, and so on. Multicast now plays a more limited role, and the protocol operation is unaffected by usage of multicast as opposed to unicast. The limitations as a result of that are documented. o Basic authentication has been removed entirely and its usage forbidden. Rosenberg, et. al. Standards Track [Page 259] RFC 3261 SIP: Session Initiation Protocol June 2002 o Proxies no longer forward a 6xx immediately on receiving it. Instead, they CANCEL pending branches immediately. This avoids a potential race condition that would result in a UAC getting a 6xx followed by a 2xx. In all cases except this race condition, the result will be the same - the 6xx is forwarded upstream. o RFC 2543 did not address the problem of request merging. This occurs when a request forks at a proxy and later rejoins at an element. Handling of merging is done only at a UA, and procedures are defined for rejecting all but the first request. 28.2 Minor Functional Changes o Added the Alert-Info, Error-Info, and Call-Info header fields for optional content presentation to users. o Added the Content-Language, Content-Disposition and MIME-Version header fields. o Added a ""glare handling"" mechanism to deal with the case where both parties send each other a re-INVITE simultaneously. It uses the new 491 (Request Pending) error code."
"o Added the In-Reply-To and Reply-To header fields for supporting the return of missed calls or messages at a later time. o Added TLS and SCTP as valid SIP transports. o There were a variety of mechanisms described for handling failures at any time during a call; those are now generally unified. BYE is sent to terminate. o RFC 2543 mandated retransmission of INVITE responses over TCP, but noted it was really only needed for 2xx. That was an artifact of insufficient protocol layering. With a more coherent transaction layer defined here, that is no longer needed. Only 2xx responses to INVITEs are retransmitted over TCP. o Client and server transaction machines are now driven based on timeouts rather than retransmit counts. This allows the state machines to be properly specified for TCP and UDP. o The Date header field is used in REGISTER responses to provide a simple means for auto-configuration of dates in user agents. o Allowed a registrar to reject registrations with expirations that are too short in duration. Defined the 423 response code and the Min-Expires for this purpose. Rosenberg, et. al. Standards Track [Page 260] RFC 3261 SIP: Session Initiation Protocol June 2002 29 Normative References [1] Handley, M. and V. Jacobson, ""SDP: Session Description Protocol"", RFC 2327, April 1998. [2] Bradner, S., ""Key words for use in RFCs to Indicate Requirement Levels"", BCP 14, RFC 2119, March 1997. [3] Resnick, P., ""Internet Message Format"", RFC 2822, April 2001. [4] Rosenberg, J. and H. Schulzrinne, ""SIP: Locating SIP Servers"", RFC 3263, June 2002. [5] Berners-Lee, T., Fielding, R. and L. Masinter, ""Uniform Resource Identifiers (URI): Generic Syntax"", RFC 2396, August 1998. [6] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)"", RFC 3268, June 2002. [7] Yergeau, F., ""UTF-8, a transformation format of ISO 10646"", RFC 2279, January 1998. [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, ""Hypertext Transfer Protocol -- HTTP/1.1"", RFC 2616, June 1999. [9] Vaha-Sipila, A., ""URLs for Telephone Calls"", RFC 2806, April 2000. [10] Crocker, D. and P. Overell, ""Augmented BNF for Syntax Specifications: ABNF"", RFC 2234, November 1997. [11] Freed, F. and N. Borenstein, ""Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"", RFC 2046, November 1996. [12] Eastlake, D., Crocker, S. and J. Schiller, ""Randomness Recommendations for Security"", RFC 1750, December 1994. [13] Rosenberg, J. and H. Schulzrinne, ""An Offer/Answer Model with SDP"", RFC 3264, June 2002. [14] Postel, J., ""User Datagram Protocol"", STD 6, RFC 768, August 1980. [15] Postel, J., ""DoD Standard Transmission Control Protocol"", RFC 761, January 1980. Rosenberg, et. al. Standards Track [Page 261] RFC 3261 SIP: Session Initiation Protocol June 2002 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, ""Stream Control Transmission Protocol"", RFC 2960, October 2000. [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, ""HTTP authentication: Basic and Digest Access Authentication"", RFC 2617, June 1999. [18] Troost, R., Dorner, S. and K. Moore, ""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"", RFC 2183, August 1997. [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, ""MIME media types for ISUP and QSIG Objects"", RFC 3204, December 2001. [20] Braden, R., ""Requirements for Internet Hosts - Application and Support"", STD 3, RFC 1123, October 1989. [21] Alvestrand, H., ""IETF Policy on Character Sets and Languages"", BCP 18, RFC 2277, January 1998. [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, ""Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"", RFC 1847, October 1995. [23] Housley, R., ""Cryptographic Message Syntax"", RFC 2630, June 1999. [24] Ramsdell B., ""S/MIME Version 3 Message Specification"", RFC 2633, June 1999. [25] Dierks, T. and C. Allen, ""The TLS Protocol Version 1.0"", RFC 2246, January 1999. [26] Kent, S. and R. Atkinson, ""Security Architecture for the Internet Protocol"", RFC 2401, November 1998. 30 Informative References [27] R. Pandya, ""Emerging mobile and personal communication systems,"" IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, ""RTP: A Transport Protocol for Real-Time Applications"", RFC 1889, January 1996. Rosenberg, et. al. Standards Track [Page 262] RFC 3261 SIP: Session Initiation Protocol June 2002 [29] Schulzrinne, H., Rao, R. and R. Lanphier, ""Real Time Streaming Protocol (RTSP)"", RFC 2326, April 1998. [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, ""Megaco Protocol Version 1.0"", RFC 3015, November 2000. [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, ""SIP: Session Initiation Protocol"", RFC 2543, March 1999. [32] Hoffman, P., Masinter, L. and J. Zawinski, ""The mailto URL scheme"", RFC 2368, July 1998. [33] E. M. Schooler, ""A multicast user directory service for synchronous rendezvous,"" Master's Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996. [34] Donovan, S., ""The SIP INFO Method"", RFC 2976, October 2000. [35] Rivest, R., ""The MD5 Message-Digest Algorithm"", RFC 1321, April 1992. [36] Dawson, F. and T. Howes, ""vCard MIME Directory Profile"", RFC 2426, September 1998. [37] Good, G., ""The LDAP Data Interchange Format (LDIF) - Technical Specification"", RFC 2849, June 2000. [38] Palme, J., ""Common Internet Message Headers"", RFC 2076, February 1997. [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, ""An Extension to HTTP: Digest Access Authentication"", RFC 2069, January 1997. [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, ""SIP Call Flow Examples"", Work in Progress. [41] E. M. Schooler, ""Case study: multimedia conference control in a packet-switched teleconferencing system,"" Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359. Rosenberg, et. al. Standards Track [Page 263] RFC 3261 SIP: Session Initiation Protocol June 2002 [42] H. Schulzrinne, ""Personal mobility for multimedia services in the Internet,"" in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996. [43] Floyd, S., ""Congestion Control Principles"", RFC 2914, September 2000. Rosenberg, et. al. Standards Track [Page 264] RFC 3261 SIP: Session Initiation Protocol June 2002 A Table of Timer Values Table 4 summarizes the meaning and defaults of the various timers used by this specification. Timer Value Section Meaning ---------------------------------------------------------------------- T1 500ms default Section 17.1.1.1 RTT Estimate T2 4s Section 17.1.2.2 The maximum retransmit interval for non-INVITE requests and INVITE responses T4 5s Section 17.1.2.2 Maximum duration a message will remain in the network Timer A initially T1 Section 17.1.1.2 INVITE request retransmit interval, for UDP only Timer B 64*T1 Section 17.1.1.2 INVITE transaction timeout timer Timer C > 3min Section 16.6 proxy INVITE transaction bullet 11 timeout Timer D > 32s for UDP Section 17.1.1.2 Wait time for response 0s for TCP/SCTP retransmits Timer E initially T1 Section 17.1.2.2 non-INVITE request retransmit interval, UDP only Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction timeout timer Timer G initially T1 Section 17.2.1 INVITE response retransmit interval Timer H 64*T1 Section 17.2.1 Wait time for ACK receipt Timer I T4 for UDP Section 17.2.1 Wait time for 0s for TCP/SCTP ACK retransmits Timer J 64*T1 for UDP Section 17.2.2 Wait time for 0s for TCP/SCTP non-INVITE request retransmits Timer K T4 for UDP Section 17.1.2.2 Wait time for 0s for TCP/SCTP response retransmits Table 4: Summary of timers Rosenberg, et. al. Standards Track [Page 265] RFC 3261 SIP: Session Initiation Protocol June 2002 Acknowledgments We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments and suggestions. Detailed comments were provided by Ofir Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick Workman. Brian Rosen provided the compiled BNF. Jean Mahoney provided technical writing assistance. This work is based, inter alia, on [41,42]. Rosenberg, et. al. Standards Track [Page 266] RFC 3261 SIP: Session Initiation Protocol June 2002 Authors' Addresses Authors addresses are listed alphabetically for the editors, the writers, and then the original authors of RFC 2543. All listed authors actively contributed large amounts of text to this document. Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63102 USA EMail: alan.johnston@wcom.com Rosenberg, et. al. Standards Track [Page 267] RFC 3261 SIP: Session Initiation Protocol June 2002 Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520 USA EMail: jon.peterson@neustar.com Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA EMail: rsparks@dynamicsoft.com Mark Handley International Computer Science Institute 1947 Center St, Suite 600 Berkeley, CA 94704 USA EMail: mjh@icir.org Eve Schooler AT&T Labs-Research 75 Willow Road Menlo Park, CA 94025 USA EMail: schooler@research.att.com Rosenberg, et. al. Standards Track [Page 268] RFC 3261 SIP: Session Initiation Protocol June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an ""AS IS"" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg, et. al. Standards Track [Page 269] 3GPP TS 29.329 V17.0.0 (2022-04) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Sh Interface based on the Diameter protocol; Protocol details (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 5 1 Scope 6 2 References 6 3 Definitions, symbols and abbreviations 7 3.1 Definitions 7 3.2 Abbreviations 7 4 General 7 5 Use of the Diameter base protocol 8 6 Diameter application for Sh interface 8 6.1 Command-Code values 8 6.1.1 User-Data-Request (UDR) Command 8 6.1.2 User-Data-Answer (UDA) Command 9 6.1.3 Profile-Update-Request (PUR) Command 10 6.1.4 Profile-Update-Answer (PUA) Command 10 6.1.5 Subscribe-Notifications-Request (SNR) Command 11 6.1.6 Subscribe-Notifications-Answer (SNA) Command 11 6.1.7 Push-Notification-Request (PNR) Command 12 6.1.8 Push-Notifications-Answer (PNA) Command 12 6.2 Result-Code AVP values 13 6.2.1 Success 13 6.2.2 Permanent Failures 13 6.2.2.1 DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED (5100) 13 6.2.2.2 DIAMETER_ERROR_OPERATION_NOT_ALLOWED (5101) 13 6.2.2.3 DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ (5102) 13 6.2.2.4 DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED (5103) 13 6.2.2.5 DIAMETER_ERROR_USER_DATA_CANNOT_BE_NOTIFIED (5104) 13 6.2.2.6 DIAMETER_ERROR_TOO_MUCH_DATA (5008) 13 6.2.2.7 DIAMETER_ERROR_TRANSPARENT_DATA OUT_OF_SYNC (5105) 13 6.2.2.8 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) 13 6.2.2.9 DIAMETER_ERROR_SUBS_DATA_ABSENT (5106) 13 6.2.2.10 DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA (5107) 14 6.2.2.11 DIAMETER_ERROR_DSAI_NOT_AVAILABLE (5108) 14 6.2.2.12 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) 14 6.2.3 Transient Failures 14 6.2.3.1 DIAMETER_USER_DATA_NOT_AVAILABLE (4100) 14 6.2.3.2 DIAMETER_PRIOR_UPDATE_IN_PROGRESS (4101) 14 6.3 AVPs 15 6.3.1 User-Identity AVP 16 6.3.2 MSISDN AVP 16 6.3.3 User-Data AVP 16 6.3.4 Data-Reference AVP 16 6.3.5 Service-Indication AVP 17 6.3.6 Subs-Req-Type AVP 17 6.3.7 Requested-Domain AVP 18 6.3.7A Requested-Nodes AVP 18 6.3.8 Current-Location AVP 18 6.3.9 Server-Name AVP 18 6.3.10 Identity-Set AVP 18 6.3.11 Supported-Features AVP 18 6.3.12 Feature-List-ID AVP 19 6.3.13 Feature-List AVP 19 6.3.14 Supported-Applications AVP 19 6.3.15 Public-Identity AVP 19 6.3.16 Expiry-Time AVP 19 6.3.17 Send-Data-Indication AVP 19 6.3.18 DSAI-Tag AVP 19 6.3.19 Wildcarded-Public-Identity AVP 19 6.3.20 Wildcarded-IMPU AVP 19 6.3.21 Session-Priority AVP 19 6.3.22 One-Time-Notification AVP 19 6.3.23 Serving-Node-Indication AVP 20 6.3.24 Repository-Data-ID AVP 20 6.3.25 Sequence-Number AVP 20 6.3.26 Pre-paging-Supported AVP 20 6.3.27 Local-Time-Zone-Indication AVP 20 6.3.28 UDR-Flags 20 6.3.29 Call-Reference-Info AVP 21 6.3.30 Call-Reference-Number AVP 21 6.3.31 AS-Number AVP 21 6.3.32 OC-Supported-Features 21 6.3.33 OC-OLR 21 6.3.34 DRMP AVP 21 6.3.35 Load 21 6.4 Use of namespaces 21 6.4.1 AVP codes 21 6.4.2 Experimental-Result-Code AVP values 22 6.4.3 Command Code values 22 6.4.4 Application-ID value 22 7 Special Requirements 23 7.1 Version Control 23 Annex A (informative): Change history 24 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope The present document defines a transport protocol for use in the IP multimedia (IM) Core Network (CN) subsystem based on the Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15]. The present document is applicable to: - The Sh interface between an AS and the HSS. - The Sh interface between an SCS and the HSS. Whenever it is possible this document specifies the requirements for this protocol by reference to specifications produced by the IETF within the scope of Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15]. Where this is not possible, extensions to the Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15] are defined within this document. 2 References The following documents contain provisions, which through reference in this text constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TSÊ29.328 ""IP Multimedia (IM) Subsystem Sh interface; signalling flows and message contents"". [2] 3GPP TSÊ33.210 ""3G Security; Network Domain Security; IP Network Layer Security"". [3] IETF RFC 2960 ""Stream Control Transmission Protocol"". [4] Void. [5] IETF RFC 2234 ""Augmented BNF for syntax specifications"". [6] 3GPP TSÊ29.229 ""Cx and Dx Interfaces based on the Diameter protocol; protocol details"". [7] IETF RFC 3589 ""Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5"". [8] ITU-TÊRecommendationÊE.164: ""The international public telecommunication numbering plan"". [9] 3GPP TRÊ33.978 ""Security aspects of early IP Multimedia Subsystem (IMS) (Release 6)"". [10] 3GPP TSÊ29.364 ""IMS Application Server Service Data Descriptions for AS interoperability"". [11] 3GPP TSÊ29.002 ""Mobile Application Part (MAP) specification"". [12] IETF RFC 7683: ""Diameter Overload Indication Conveyance"". [13] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [14] IETFÊRFCÊ8583: ""Diameter Load Information Conveyance"". Ê[15] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [16]] 3GPP TSÊ29.336: ""Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications"". 3 Definitions, symbols and abbreviations 3.1 Definitions Refer to IETFÊRFCÊ6733Ê[15] for the definitions of some terms used in this document. For the purposes of the present document, the following terms and definitions apply. Attribute-Value Pair: see IETFÊRFCÊ6733Ê[15], it corresponds to an Information Element in a Diameter message. Server: SIP-server. User data: user profile data. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AAA Authentication, Authorization and Accounting AS Application Server ABNF Augmented Backus-Naur Form AVP Attribute-Value Pair CN Core Network DRMP Diameter Routing Message Priority DSCP Differentiated Services Code Point HSS Home Subscriber Server IANA Internet Assigned Numbers Authority IETF Internet Engineering Task Force IMS IP Multimedia Subsystem NDS Network Domain Security RFC Request For Comment SCTP Stream Control Transport Protocol UCS Universal Character Set URL Uniform Resource Locator UTF UCS Transformation Formats 4 General he Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and event codes specified in clauseÊ6 of this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) are unmodified. 5 Use of the Diameter base protocol The same clarifications of clauseÊ5 of 3GPP TSÊ29.229Ê[6] shall apply to the Sh interface. An exception is that the application identifier for this application is defined in chapter 6. 6 Diameter application for Sh interface This clause specifies a Diameter application that allows a Diameter server and a Diameter client: - to download and update transparent and non-transparent user data - to request and send notifications on changes on user data The Sh interface protocol is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP ( http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the Sh interface application is 16777217 (allocated by IANA). 6.1 Command-Code values This clause defines Command-Code values for this Diameter application. Every command is defined by means of the ABNF syntax (as defined in RFC 2234Ê[5]), according to the Command Code Format (CCF) specification defined in IETFÊRFCÊ6733Ê[15]. Whenever the definition and use of an AVP is not specified in this document, what is stated in 3GPP TSÊ29.229Ê[6] shall apply. NOTE: As the Diameter commands described in this specification have been defined based on the former specification of the Diameter base protocol, the Vendor-Specific-Application-Id AVP is still listed as a required AVP (an AVP indicated as {AVP}) in the command code format specifications defined in this specification to avoid backward compatibility issues, even if the use of this AVP has been deprecated in the new specification of the Diameter base protocol (IETFÊRFCÊ6733Ê[15]). The command codes for the Sh interface application are taken from the range allocated by IANA in IETF RFC 3589Ê[7] as assigned in this specification. For these commands, the Application-ID field shall be set to 16777217 (application identifier of the Sh interface application, allocated by IANA). The following Command Codes are defined in this specification: Table 6.1.1: Command-Code values Command-Name Abbreviation Code Clause User-Data-Request UDR 306 6.1.1 User-Data-Answer UDA 306 6.1.2 Profile-Update-Request PUR 307 6.1.3 Profile-Update-Answer PUA 307 6.1.4 Subscribe-Notifications-Request SNR 308 6.1.5 Subscribe-Notifications-Answer SNA 308 6.1.6 Push-Notification-Request PNR 309 6.1.7 Push-Notification-Answer PNA 309 6.1.8 6.1.1 User-Data-Request (UDR) Command The User-Data-Request (UDR) command, indicated by the Command-Code field set to 306 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to request user data. Message Format < User-Data -Request> ::= < Diameter Header: 306, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ Server-Name ] *[ Service-Indication ] *{ Data-Reference } *[ Identity-Set ] [ Requested-Domain ] [ Current-Location ] *[ DSAI-Tag ] [ Session-Priority ] [ User-Name ] [ Requested-Nodes ] [ Serving-Node-Indication ] [ Pre-paging-Supported ] [ Local-Time-Zone-Indication ] [ UDR-Flags ] [ Call-Reference-Info ] [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.2 User-Data-Answer (UDA) Command The User-Data-Answer (UDA) command, indicated by the Command-Code field set to 306 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the User-Data-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < User-Data-Answer > ::= < Diameter Header: 306, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Data ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.3 Profile-Update-Request (PUR) Command The Profile-Update-Request (PUR) command, indicated by the Command-Code field set to 307 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to update user data in the server. Message Format < Profile-Update-Request > ::= < Diameter Header: 307, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Name ] *{ Data-Reference } { User-Data } [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] NOTE: More than one Data-Reference AVP may be present in the message only if both the AS and the HSS support the Update-Eff-Enhance feature. How the AS knows whether the HSS supports the Update-Eff-Enhance feature is implementation issue, e.g. the AS can get the information from a previous PUA message. 6.1.4 Profile-Update-Answer (PUA) Command The Profile-Update-Answer (PUA) command, indicated by the Command-Code field set to 307 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Profile-Update-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Profile-Update-Answer > ::=< Diameter Header: 307, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ Repository-Data-ID ] [ Data-Reference ] *[ Supported-Features ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] NOTE: The Data-Reference AVP may be present in the message only if both the AS and the HSS support the Update-Eff-Enhance feature. 6.1.5 Subscribe-Notifications-Request (SNR) Command The Subscribe-Notifications-Request (SNR) command, indicated by the Command-Code field set to 308 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to request notifications of changes in user data. Message Format < Subscribe-Notifications-Request > ::= < Diameter Header: 308, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] *[ Service-Indication ] [ Send-Data-Indication ] [ Server-Name ] { Subs-Req-Type } *{ Data-Reference } *[ Identity-Set ] [ Expiry-Time ] *[ DSAI-Tag ] [One-Time-Notification] [ User-Name ] [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.6 Subscribe-Notifications-Answer (SNA) Command The Subscribe-Notifications-Answer command, indicated by the Command-Code field set to 308 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Subscribe-Notifications-Request command. The Result-Code or Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Subscribe-Notifications-Answer > ::= < Diameter Header: 308, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } [ Result-Code ] [ Experimental-Result ] { Origin-Host } { Origin-Realm } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] *[ Supported-Features ] [ User-Data ] [ Expiry-Time ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.7 Push-Notification-Request (PNR) Command The Push-Notification-Request (PNR) command, indicated by the Command-Code field set to 309 and the 'R' bit set in the Command Flags field, is sent by a Diameter server to a Diameter client in order to notify changes in the user data in the server. Message Format < Push-Notification-Request > ::= < Diameter Header: 309, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Name ] { User-Data } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.8 Push-Notifications-Answer (PNA) Command The Push-Notifications-Answer (PNA) command, indicated by the Command-Code field set to 309 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Push-Notification-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Push-Notification-Answer > ::=< Diameter Header: 309, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.2 Result-Code AVP values This clause defines new result code values that must be supported by all Diameter implementations that conform to this specification. The result codes defined in 3GPP TSÊ29.229Ê[6] are also applicable. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and Result-Code AVP shall be absent. 6.2.1 Success Result codes that fall within the Success category are used to inform a peer that a request has been successfully completed. No result codes within this category have been defined so far. 6.2.2 Permanent Failures Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not be attempted again. 6.2.2.1 DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED (5100) The data received by the AS is not supported or recognized. 6.2.2.2 DIAMETER_ERROR_OPERATION_NOT_ALLOWED (5101) The requested operation is not allowed for the user 6.2.2.3 DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ (5102) The requested user data is not allowed to be read. 6.2.2.4 DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED (5103) The requested user data is not allowed to be modified. 6.2.2.5 DIAMETER_ERROR_USER_DATA_CANNOT_BE_NOTIFIED (5104) The requested user data is not allowed to be notified on changes. 6.2.2.6 DIAMETER_ERROR_TOO_MUCH_DATA (5008) The size of the data pushed to the receiving entity exceeds its capacity. This error code is defined in 3GPP TSÊ29.229Ê[6]. 6.2.2.7 DIAMETER_ERROR_TRANSPARENT_DATA OUT_OF_SYNC (5105) The request to update the repository data at the HSS could not be completed because the requested update is based on an out-of-date version of the repository data. That is, the sequence number in the Sh-Update Request message, does not match with the immediate successor of the associated sequence number stored for that repository data at the HSS. It is also used where an AS tries to create a new set of repository data when the identified repository data already exists in the HSS. 6.2.2.8 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) See 3GPP TSÊ29.229Ê[6] clauseÊ6.2.2.11. 6.2.2.9 DIAMETER_ERROR_SUBS_DATA_ABSENT (5106) The Application Server requested to subscribe to changes to Repository Data that is not present in the HSS. 6.2.2.10 DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA (5107) The AS received a notification of changes of some information to which it is not subscribed. 6.2.2.11 DIAMETER_ERROR_DSAI_NOT_AVAILABLE (5108) The Application Server addressed a DSAI not configured in the HSS. 6.2.2.12 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) See 3GPP TSÊ29.229Ê[6] 6.2.3 Transient Failures Errors that fall within the transient failures category are those used to inform a peer that the request could not be satisfied at the time that it was received. The request may be able to be satisfied in the future. 6.2.3.1 DIAMETER_USER_DATA_NOT_AVAILABLE (4100) The requested user data is not available at this time to satisfy the requested operation. 6.2.3.2 DIAMETER_PRIOR_UPDATE_IN_PROGRESS (4101) The request to update data at the HSS could not be completed for one of the following reasons: - If the Data Reference is Repository Data, then the related Repository Data is currently being updated by another entity; - If the Data Reference is other than Repository Data, then the related data is currently being updated. 6.3 AVPs The following table describes the Diameter AVPs defined for the Sh interface protocol, their AVP Code values, types, possible flag values and whether the AVP may or not be encrypted. Table 6.3.1: Diameter Multimedia Application AVPs AVP Flag rules Attribute Name AVP Code Clause defined Value Type Must May Should not Must not May Encrypt User-Identity 700 6.3.1 Grouped M, V No MSISDN 701 6.3.2 OctetString M, V No User-Data 702 6.3.3 OctetString M, V No Data-Reference 703 6.3.4 Enumerated M, V No Service-Indication 704 6.3.5 OctetString M, V No Subs-Req-Type 705 6.3.6 Enumerated M, V No Requested-Domain 706 6.3.7 Enumerated M, V No Current-Location 707 6.3.8 Enumerated M, V No Identity-Set 708 6.3.10 Enumerated V M No Expiry-Time 709 6.3.16 Time V M No Send-Data-Indication 710 6.3.17 Enumerated V M No Server-Name 602 6.3.9 UTF8String M, V No Supported-Features 628 6.3.11 Grouped V M No Feature-List-ID 629 6.3.12 Unsigned32 V M No Feature-List 630 6.3.13 Unsigned32 V M No Supported-Applications 631 6.3.14 Grouped V M No Public-Identity 601 6.3.15 UTF8String M, V No DSAI-Tag 711 6.3.18 OctetString M, V No Wildcarded-Public-Identity 634 6.3.19 UTF8String V M No Wildcarded-IMPU 636 6.3.20 UTF8String V M No Session-Priority 650 6.3.21 Enumerated V M No One-Time-Notification 712 6.3.22 Enumerated V M No Requested-Nodes 713 6.3.7A Unsigned32 V M No Serving-Node-Indication 714 6.3.23 Enumerated V M No Repository-Data-ID 715 6.3.24 Grouped V M No Sequence-Number 716 6.3.25 Unsigned32 V M No Pre-paging-Supported 717 6.3.26 Enumerated V M No Local-Time-Zone-Indication 718 6.3.27 Enumerated V M No UDR-Flags 719 6.3.28 Unsigned32 V M No Call-Reference-Info 720 6.3.29 Grouped V M No Call-Reference-Number 721 6.3.30 OctetString V M No AS-Number 722 6.3.31 OctetString V M No OC-Supported-Features 621 NOTE 3 6.3.32 Grouped M, V No OC-OLR 623 NOTE 3 6.3.33 Grouped M, V No DRMP 301 NOTE 4 6.3.34 Enumerated M, V No Load NOTE 5 6.3.35 Grouped M, V No NOTE 1: The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see 3GPP TSÊ29.229Ê[6]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. NOTE 3: The value of these attributes is defined in IETFÊRFCÊ7683Ê[12]. NOTE 4: The value of this attribute is defined in IETFÊRFCÊ7944Ê[13]. NOTE 5: The value of this attribute is defined in IETFÊRFCÊ8583Ê[14]. The following table specifies the Diameter AVPs re-used by the Sh interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within Sh. Table 6.3/2: Sh re-used Diameter AVPs Attribute Name Reference Comments M-bit External-Identifier 3GPP TSÊ29.336Ê[16] Must set NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: ""Must set"", ""Must not set"". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. 6.3.1 User-Identity AVP The User-Identity AVP is of type Grouped. This AVP contains either a Public- Identity AVP or an MSISDN AVP or an External-Identifier AVP. AVP format User-Identity ::= <AVP header: 700 10415> [Public-Identity] [MSISDN] [External-Identifier] *[AVP] 6.3.2 MSISDN AVP The MSISDN AVP is of type OctetString. This AVP contains an MSISDN, in international number format as described in ITU-T Rec E.164Ê[8], encoded as a TBCD-string, i.e. digits from 0 through 9 are encoded 0000 to 1001; 1111 is used as a filler when there is an odd number of digits; bits 8 to 5 of octet n encode digit 2n; bits 4 to 1 of octet n encode digit 2(n-1)+1. 6.3.3 User-Data AVP The User-Data AVP is of type OctetString. This AVP contains the user data requested in the UDR/UDA, SNR/SNA and PNR/PNA operations and the data to be modified in the PUR/PUA operation. The exact content and format of this AVP is described in 3GPP TSÊ29.328Ê[1] Annex C as Sh-Data. 6.3.4 Data-Reference AVP The Data-Reference AVP is of type Enumerated, and indicates the type of the requested user data in the operation UDR and SNR. Its exact values and meaning is defined in 3GPP TSÊ29.328Ê[1]."
"The following values are defined (more details are given in 3GPP TSÊ29.328Ê[1]): RepositoryData (0) IMSPublicIdentity (10) IMSUserState (11) S-CSCFName (12) InitialFilterCriteria (13) This value is used to request initial filter criteria relevant to the requesting AS LocationInformation (14) UserState (15) ChargingInformation (16) MSISDN (17) PSIActivation (18) DSAI (19) ServiceLevelTraceInfo (21) IPAddressSecureBindingInformation (22) ServicePriorityLevel (23) SMSRegistrationInfo (24) UEReachabilityForIP (25) TADSinformation (26) STN-SR (27) UE-SRVCC-Capability (28) ExtendedPriority (29) CSRN (30) ReferenceLocationInformation (31) IMSI (32) IMSPrivateUserIdentity (33) IMEISV (34) UE-5G-SRVCC-Capability (35) NOTE: Value 20 is reserved. 6.3.5 Service-Indication AVP The Service-Indication AVP is of type OctetString. This AVP contains the Service Indication that identifies a service or a set of services in an AS and the related repository data in the HSS. Standardized values of Service-Indication identifying a standardized service or set of services in the AS and standardized format of the related repository data are defined in 3GPP TSÊ29.364Ê[10]. 6.3.6 Subs-Req-Type AVP The Subs-Req-Type AVP is of type Enumerated, and indicates the type of the subscription-to-notifications request. The following values are defined: Subscribe (0) This value is used by an AS to subscribe to notifications of changes in data. Unsubscribe (1) This value is used by an AS to unsubscribe to notifications of changes in data. 6.3.7 Requested-Domain AVP The Requested-Domain AVP is of type Enumerated, and indicates the access domain for which certain data (e.g. user state) are requested. The following values are defined: CS-Domain (0) The requested data apply to the CS domain. PS-Domain (1) The requested data apply to the PS domain. 6.3.7A Requested-Nodes AVP The Requested-Nodes AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.7A/1: Table 6.3.7A/1: Requested-Nodes Bit Name Description 0 MME The requested data apply to the MME 1 SGSN The requested data apply to the SGSN 2 3GPP-AAA-SERVER-TWAN The requested data apply to the 3GPP AAA Server for TWAN 3 AMF The requested data apply to the AMF (for 3GPP access) 6.3.8 Current-Location AVP The Current-Location AVP is of type Enumerated, and indicates whether an active location retrieval has to be initiated or not: DoNotNeedInitiateActiveLocationRetrieval (0) The request indicates that the initiation of an active location retrieval is not required. InitiateActiveLocationRetrieval (1) It is requested that an active location retrieval is initiated. 6.3.9 Server-Name AVP The Server-Name contains a SIP-URL used to identify an AS. See 3GPP TSÊ29.229Ê[6] for further description of this AVP. 6.3.10 Identity-Set AVP The Identity-Set AVP is of type Enumerated and indicates the requested set of IMS Public Identities. The following values are defined: ALL_IDENTITIES (0) REGISTERED_IDENTITIES (1) IMPLICIT_IDENTITIES (2) ALIAS_IDENTITIES (3) 6.3.11 Supported-Features AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.29. 6.3.12 Feature-List-ID AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.30. 6.3.13 Feature-List AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.31. 6.3.14 Supported-Applications AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.32. 6.3.15 Public-Identity AVP The Public-Identity AVP contains a Public User Identity. See 3GPP TSÊ29.229Ê[6] for the definition of this AVP. 6.3.16 Expiry-Time AVP The Expiry-Time AVP is of type Time. This AVP contains the expiry time of subscriptions to notifications in the HSS. 6.3.17 Send-Data-Indication AVP The Send-Data-Indication AVP is of type Enumerated. If present it indicates that the sender requests the User-Data. The following values are defined: USER_DATA_NOT_REQUESTED (0) USER_DATA_REQUESTED (1) 6.3.18 DSAI-Tag AVP The DSAI-Tag AVP is of type OctetString. This AVP contains the DSAI-Tag identifying the instance of the Dynamic Service Activation Information being accessed for the Public Identity. 6.3.19 Wildcarded-Public-Identity AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.35 for the definition of theWildcarded-Public-Identity AVP. This AVP only contains a Wildcarded PSI over Sh interface. 6.3.20 Wildcarded-IMPU AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.43. 6.3.21 Session-Priority AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.56. 6.3.22 One-Time-Notification AVP The One-Time-Notification AVP is of type Enumerated. If present it indicates that the sender requests to be notified only one time. The following values are defined: ONE_TIME_NOTIFICATION_REQUESTED (0) This AVP is only applicable to UE reachability for IP (25) 6.3.23 Serving-Node-Indication AVP The Serving-Node-Indication AVP is of type Enumerated. If present it indicates that the sender does not require any location information other than the Serving Node Addresses/Identities requested (e.g. MME name, VLR number). Other location information (e.g. Global Cell ID, Tracking Area ID) may be absent. The following values are defined: ONLY_SERVING_NODES_REQUIRED (0) 6.3.24 Repository-Data-ID AVP The Repository-Data-ID AVP is of type Grouped. This AVP shall contain a Service-Indication AVP and a Sequence-Number AVP. AVP format Repository-Data-ID ::= <AVP header: 715 10415> {Service-Indication} {Sequence-Number} *[AVP] 6.3.25 Sequence-Number AVP The Sequence-Number AVP is of type Unsigned32. This AVP contains a number associated to a repository data. 6.3.26 Pre-paging-Supported AVP The Pre-paging-Supported AVP is of type Enumerated. It indicates whether the sender supports pre-paging or not. The following values are defined: PREPAGING_NOT_SUPPORTED (0) PREPAGING_SUPPORTED (1) If this AVP is not present in the command, the default value is PREPAGING_NOT_SUPPORTED (0). 6.3.27 Local-Time-Zone-Indication AVP The Local-Time-Zone-Indication AVP is of type Enumerated. If present it indicates that the Local Time Zone information (time zone and daylight saving time) of the visited network where the UE is attached is requested with or without other location information. The following values are defined: ONLY_LOCAL_TIME_ZONE_REQUESTED (0) LOCAL_TIME_ZONE_WITH_LOCATION_INFO_REQUESTED (1) 6.3.28 UDR-Flags The UDR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in 3GPPÊTSÊ29.328Ê[1]. Table 6.3.28/1: UDR-Flags Bit Name 0 Location-Information-EPS-Supported 1 RAT-Type-Requested NOTE: Bits not defined in this table shall be cleared by the sender of the request and discarded by the receiver of the request. 6.3.29 Call-Reference-Info AVP The Call-Reference-Info AVP is of type Grouped. This AVP shall contain a Call-Reference-Number AVP and an AS-Number AVP. AVP format Call-Reference-Info ::= <AVP header: 720 10415> {Call-Reference-Number} {AS-Number} *[AVP] 6.3.30 Call-Reference-Number AVP The Call-Reference-Number AVP is of type OctetString. The exact content and format of this AVP is described in 3GPP TSÊ29.002Ê[11]. 6.3.31 AS-Number AVP The AS-Number AVP is of type OctetString. The exact content and format of this AVP corresponds to the gmsc-address parameter described in 3GPP TSÊ29.002Ê[11]. 6.3.32 OC-Supported-Features The OC-Supported-Features AVP is of type Grouped and it is defined in IETF RFC 7683Ê[12]. This AVP is used to support Diameter overload control mechanism. 6.3.33 OC-OLR The OC-OLR AVP is of type Grouped and it is defined in IETF RFC 7683Ê[12]. This AVP is used to support Diameter overload control mechanism. 6.3.34 DRMP AVP The DRMP AVP is of type Enumerated and it is defined in IETFÊRFCÊ7944Ê[13]. This AVP allows the HSS/SLF and the AS/OSA SCS to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message. 6.3.35 Load The Load AVP is of type Grouped and it is defined in IETFÊRFCÊ8583Ê[14]. This AVP is used to support the Diameter load control mechanism. 6.4 Use of namespaces This clause contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA. 6.4.1 AVP codes This specification assigns the AVP values from the AVP Code namespace managed by 3GPP for its Diameter vendor-specific applications. See clauseÊ6.3 for the assignment of the namespace in this specification. 6.4.2 Experimental-Result-Code AVP values This specification has assigned Experimental-Result-Code AVP values 4100-4101 and 5100-5105. See clauseÊ6.2. 6.4.3 Command Code values This specification assigns the values 306-309 from the range allocated by IANA to 3GPP in IETF RFC 3589Ê[7]. 6.4.4 Application-ID value IANA has allocated the value 16777217 for the 3GPP Sh interface application. 7 Special Requirements 7.1 Version Control The version control mechanisms specified in 3GPP TSÊ29.229Ê[6] clauses 7.1, 7.2 and 7.3 apply to this specification. The following table of features shall apply to the Sh interface. Table 7.1.1: Features of feature list 1 used in Sh Feature bit Feature M/O Description 0 Notif-Eff M This feature is applicable to the UDR/UDA, SNR/SNA and PNR/PNA command pairs. It requires support in both the HSS and the AS. If multiple subscriptions to notifications are associated with a Public User Identity, the HSS may combine the notifications for multiple Data References and/or Service Indications and/or Identity Sets into a single Push-Notification-Request message. The User-Data-Request / Answer and the Subscribe-Notifications-Request / Answer allow multiple Data References, Service Indications and Identity Sets. The User-Data-Answer and Push-Notification-Request allow combining multiple DataReference items resulting in the User Data AVP including a single XML document with the separable XML clauses populated. 1 Update-Eff O This feature is applicable to the PUR/PUA commands. If both the HSS and the AS support this feature, a PUR command where the Data reference type is Repository Data, may contain an XML document with several Repository Data instances. 2 Update-Eff-Enhance O This feature is an enhancement of the Update-Eff feature and requires Update-Eff is supported. It is applicable to the PUR/PUA commands. If both the HSS and the AS support this feature, a PUR command may contain an XML document with several Data instances. 3 Additional-MSISDN O This feature is applicable to UDR/UDA commands. It requires support in both HSS and AS. If enabled, it extends the information returned with DataReference=17. Instead of returning only MSISDN, it includes ExtendedMSISDN. See 3GPP TSÊ29.328Ê[1] for more information. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""MOM"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. The following table shall apply to the Sh interface; the column Application identifier lists the used application identifiers on Sh and 3GPP. Table 7.1.2: Application identifiers used in Sh Application identifier First applied 16777217 3GPP Rel-5 Annex A (informative): Change history Change history Date Meeting TDoc CR Rev Cat Subject/Comment New version June 2002 CN#16 NP-020266 Version 2.0.1 present in CN#16 for approval 5.0.0 Sep 2002 CN#17 NP-020450 2 1 Cancellation of subscriptions to notifications 5.1.0 Sep 2002 CN#17 NP-020450 3 1 Addition of AVPs to User-Data-Request 5.1.0 Dec 2002 CN#18 NP-020592 6 - Error handling in HSS when being updated with too much data 5.2.0 Mar 2003 CN#19 NP-030102 005 1 Initial Filter Criteria 5.3.0 Mar 2003 CN#19 NP-030102 007 2 Update after Diameter has become RFC 5.3.0 Mar 2003 CN#19 NP-030102 011 - Missing code-point in Data-Reference AVP 5.3.0 Mar 2003 CN#19 NP-030102 013 - Registration State Alignment 5.3.0 Mar 2003 CN#19 NP-030102 008 - Correction of the Application Server Identification type for Initial Filter Criteria usage 5.3.0 Mar 2003 CN#19 NP-030102 009 - Clarification on Sh interface for charging purposes 5.3.0 Jun 2003 CN#20 NP-030216 014 1 Co-ordination of Update of Repository Data 5.4.0 Jun 2003 CN#20 NP-030216 015 1 Command code correction for UDA plus editorial corrections 5.4.0 Jun 2003 CN#20 NP-030216 016 - Correction on Current-Location AVP values 5.4.0 Jun 2003 CN#20 NP-030216 018 - Correction to the use of User-Identity 5.4.0 Jun 2003 CN#20 NP-030216 019 1 Correction to the use of Data-Reference 5.4.0 Dec 2003 CN#22 Editorial changes in application IDs and references [4] and [7]. 5.4.1 Mar 2004 CN#23 NP-040135 031 1 Add MSISDN to set of Data that may be downloaded 5.5.0 Mar 2004 CN#23 NP-040055 032 2 Introduction of 'Identity-Set' AVP 6.0.0 Jun 2004 CN#24 NP-040216 037 - Correction to description of Data Reference AVP value 10 6.1.0 Jun 2004 CN#24 NP-040216 035 1 Correction of reference for definition of MSISDN 6.1.0 Sep 2004 CN#25 NP-040394 043 - Incorrect Data-Reference AVP in Subscriber Notification Answer Command 6.2.0 Sep 2004 CN#25 NP-040395 046 1 Application version control 6.2.0 Sep 2004 CN#25 NP-040394 041 1 Public-Identity is unspecified for the Sh interface 6.2.0 Sep 2004 CN#25 NP-040395 045 1 Single Public_Identity required in Grouped User-Identity AVP 6.2.0 Sep 2004 CN#25 NP-040394 049 - Correction of the Application-Id code 6.2.0 Sep 2004 CN#25 NP-040412 051 1 Re-numbering of 3GPP specific AVP codes 6.2.0 Dec 2004 CN#26 NP-040578 053 - Sh ABNF corrections 6.3.0 Mar 2005 CN#27 NP-050031 057 1 Introduction of Failed AVP 6.4.0 Mar 2005 CN#27 NP-050031 064 - Sh-Update needs to include Data-Reference to be future proof 6.4.0 Jun 2005 CT#28 CP-050216 069 - Sh UDR correction 6.5.0 Jun 2005 CT#28 CP-050087 070 - Correction of references 6.5.0 Jun 2005 CT#28 CP-050087 071 1 Corrections to message parameters 6.5.0 Jun 2005 CT#28 CP-050087 072 1 Miscellaneous Corrections 6.5.0 Jun 2005 CT#28 CP-050216 074 - Correction to allow realm based routing 6.5.0 Sep 2005 CT#29 CP-050424 075 - Identity-Set correction 6.6.0 Sep 2005 CT#29 CP-050422 095 1 State the condition for encryption of the Data Reference 6.6.0 Sep 2005 CT#29 CP-050423 097 1 Early IMS Security based protection for the Ut interface 6.6.0 Dec 2005 CT#30 CP-050625 098 3 Notification & Query Efficiency 7.0.0 Dec 2005 CT#30 CP-050625 099 1 Management of subscriptions 7.0.0 Mar 2006 CT#31 CP-060084 0100 1 User-Data in the response to Sh-Subs-Notif 7.1.0 Mar 2006 CT#31 CP-060084 0101 3 New error indications for the Sh-Subs-Notif procedure 7.1.0 Jun 2006 CT#32 CP-060319 0105 2 Sh interface efficiency improvement 7.2.0 Sep 2006 CT#33 CP-060417 0107 2 Introduction of Activation State Information for IMS (DSAI) 7.3.0 Sep 2006 CT#33 CP-060417 0108 - Addition of AVPs in SNR and SNA 7.3.0 Sep 2006 CT#33 CP-060417 0110 1 Public User Identity Grouping Information 7.3.0 Sep 2006 CT#33 CP-060405 0112 - Missing Data Reference value 7.3.0 Sep 2006 CT#33 CP-060417 0113 1 Errors to be sent in response to Sh-Notif 7.3.0 Sep 2007 CT#37 CP-070527 0118 - Define User-Data AVP 7.4.0 Sep 2007 CT#37 CP-070527 0119 1 Wildcarded PSI as key in the Sh Interface 7.4.0 Nov 2007 CT#38 CP-070743 0120 - ABNF correction for UDR and SNR 7.5.0 Nov 2007 CT#38 CP-070743 0121 1 PNR for Subscriptions to Notifications for all Identity Sets 7.5.0 Mar 2008 CT#39 CP-080019 0122 - Wildcarded Public User Identities 8.0.0 Jun 2008 CT#40 CP-080267 0123 1 DSAI Corrections 8.1.0 Jun 2008 CT#40 CP-080702 0130 1 Service Indication for standardized services 8.2.0 Jun 2008 CT#40 CP-080883 0132 1 Correction of Identity-Set AVP 8.2.0 Mar 2009 CT#43 CP-090042 0134 1 AliasesRepositoryData removal 8.3.0 Jun 2009 CT#44 CP-090305 0136 Missing data-reference for GIBA 8.4.0 Dec 2009 CT#46 CP-090778 0138 Session-Priority AVP 8.5.0 Dec 2009 CT#46 Upgraded unchanged from Rel-8 9.0.0 Mar 2010 CT#47 CP-100033 0143 1 IP-SM-GW UE reachability handling over Sh 9.1.0 Mar 2010 CT#47 CP-100048 0144 1 Sh handling of T-ADS 9.1.0 Mar 2010 CT#47 CP-100206 0148 3 EPS Subcsriber State and Location Information Request 9.1.0 Jun 2010 CT#48 CP-100275 0149 EPS state and location retrieval 9.2.0 Jun 2010 CT#48 CP-100279 0154 1 9.2.0 Sep 2010 CT#49 CP-100447 0157 1 Correction to the Value of Data-Reference AVP 9.3.0 Sep 2010 CT#49 CP-100454 0160 1 Correction on Requested-Domain 9.3.0 Sep 2010 CT#49 CP-100466 0158 2 Usage of IMSI and IMPI for user identification over Sh 10.0.0 Sep 2010 CT#49 CP-100466 0159 3 Location data including only serving node address 10.0.0 Sep 2010 CT#49 CP-100466 0163 3 Update-Eff feature 10.0.0 Dec 2010 CT#50 CP-100699 0164 2 Enhanced SRVCC 10.1.0 Mar 2011 CT#51 CP-110257 0168 2 MPS over Sh 10.2.0 Mar 2011 CT#51 CP-110075 0170 2 Retrieval of CSRN from HSS 10.2.0 Jun 2011 CT#52 CP-110370 0175 1 Pre-paging Support Indicator for CSRN 10.3.0 Jun 2011 CT#52 CP-110370 0176 1 Clarification on Notif-Eff description for SNR/SNA 10.3.0 Jun 2011 CT#52 CP-110370 0177 - Missing Repository-Data-ID AVP in PUA 10.3.0 Jun 2011 CT#52 CP-110383 0173 2 Reference Location over Sh interface 11.0.0 Dec 2011 CT#54 CP-110781 0189 - Correction on Wildcarded Public Identity 11.1.0 Mar 2012 CT#55 CP-120035 0194 2 Update of Multiple Data Instances in Sh-Update 11.2.0 Jun 2012 CT#56 CP-120240 0195 3 Local Time for NPLI 11.3.0 Sep 2012 CT#57 CP-120481 0197 A-MSISDN handling over Sh 11.4.0 Sep 2012 CT#57 CP-120481 0198 1 Local Time Zone 11.4.0 Dec 2012 CT#58 CP-120743 0202 1 EPS LocationInformation Support 11.5.0 Mar 2013 CT#59 CP-130020 0208 1 PS Location Info request with RAT-type 11.6.0 Mar 2013 CT#59 CP-130020 0210 1 Pre-paging-Supported and Local-Time-Zone-Indication AVPs 11.6.0 Mar 2013 CT#59 CP-130031 0200 1 Sh IMSI retrieval 12.0.0 Jun 2013 CT#60 CP-130374 0211 1 MTRR on Sh 12.1.0 Mar 2014 CT#63 CP-140027 0214 1 Multiple notification due to the Update-Eff feature 12.2.0 Jun 2014 CT#64 CP-140262 0217 - Private User Identity retrieval 12.3.0 Jun 2014 CT#64 CP-140262 0218 - UE Reachability for IP 12.3.0 Sep 2014 CT#65 CP-140515 0219 - Session-Priority reference 12.4.0 Sep 2014 CT#65 CP-140509 0220 1 Diameter Overload Control Over Sh 12.4.0 Dec 2014 CT#66 CP-140773 0222 - M-bit clarification 12.5.0 Dec 2014 CT#66 CP-140779 0223 - Retrieval of TWAN-Id over Sh 12.5.0 Dec 2014 CT#66 CP-140790 0224 - DOIC reference update 12.5.0 Dec 2015 CT#70 CP-150759 0226 1 Update reference to DOIC new IETF RFC 12.6.0 Dec 2015 CT#70 CP-150849 0227 4 Support of the DRMP AVP over Sh/Dh 13.0.0 2016-09 CT#73 CP-160431 0228 1 Request to update data while a previous update request is in progress 14.0.0 2016-12 CT#74 CP-160649 0236 1 RAT type included in EPS location information 14.1.0 2016-12 CT#74 CP-160681 0237 1 Load Control 14.1.0 2016-12 CT#74 CP-160664 0239 1 Correction to change IETF drmp draft version to official RFC 7944 14.1.0 2017-03 CT#75 CP-170035 0241 - Notif-Eff feature description correction 14.2.0 2017-03 CT#75 CP-170035 0245 1 UDR flag description 14.2.0 2017-03 CT#75 CP-170048 0243 1 Update of reference for the Diameter base protocol 14.2.0 2017-03 CT#75 CP-170048 0244 - Cardinality of the Failed-AVP AVP in answer 14.2.0 2017-06 CT#76 CP-171018 0248 1 Support for signaling transport level packet marking 14.3.0 2017-06 CT#76 CP-171040 0246 1 External Identifier on Sh 15.0.0 2018-06 CT#80 CP-181131 0249 - Requested Node AMF 15.1.0 2019-09 CT#85 CP-192094 0251 2 draft-ietf-dime-load published as RFC 8583 15.2.0 2020-07 CT#88e - - - Update to Rel-16 version (MCC) 16.0.0 2020-12 CT#91e CP-203022 0253 1 Incomplete implemented CR 16.1.0 2021-03 CT#91e CP-210044 0354 - IMEISV and 5G SRVCC Capability missing in Data Reference AVP 16.2.0 2022-04 - - - - - Update to Rel-17 version (MCC) 17.0.0 3GPP TS 29.329 V17.0.0 (2022-04) 14 Release 17 3GPP 3GPP TS 29.229 V17.2.0 (2022-06) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Cx and Dx interfaces based on the Diameter protocol; Protocol details (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 6 1 Scope 7 2 References 7 3 Definitions, symbols and abbreviations 8 3.1 Definitions 8 3.2 Abbreviations 9 4 General 9 5 Use of the Diameter base protocol 9 5.1 Securing Diameter Messages 9 5.2 Accounting functionality 9 5.3 Use of sessions 9 5.4 Transport protocol 10 5.5 Routing considerations 10 5.6 Advertising Application Support 10 6 Diameter application for Cx interface 11 6.1 Command-Code values 11 6.1.1 User-Authorization-Request (UAR) Command 11 6.1.2 User-Authorization-Answer (UAA) Command 12 6.1.3 Server-Assignment-Request (SAR) Command 12 6.1.4 Server-Assignment-Answer (SAA) Command 13 6.1.5 Location-Info-Request (LIR) Command 14 6.1.6 Location-Info-Answer (LIA) Command 14 6.1.7 Multimedia-Auth-Request (MAR) Command 14 6.1.8 Multimedia-Auth-Answer (MAA) Command 15 6.1.9 Registration-Termination-Request (RTR) Command 15 6.1.10 Registration-Termination-Answer (RTA) Command 16 6.1.11 Push-Profile-Request (PPR) Command 16 6.1.12 Push-Profile-Answer (PPA) Command 17 6.2 Result-Code AVP values 17 6.2.1 Success 17 6.2.1.1 DIAMETER_FIRST_REGISTRATION (2001) 17 6.2.1.2 DIAMETER_SUBSEQUENT_REGISTRATION (2002) 17 6.2.1.3 DIAMETER_UNREGISTERED_SERVICE (2003) 17 6.2.1.4 DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED (2004) 18 6.2.1.5 Void 18 6.2.2 Permanent Failures 18 6.2.2.1 DIAMETER_ERROR_USER_UNKNOWN (5001) 18 6.2.2.2 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) 18 6.2.2.3 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003) 18 6.2.2.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) 18 6.2.2.5 DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED (5005) 18 6.2.2.6 DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED (5006) 18 6.2.2.7 DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (5007) 18 6.2.2.8 DIAMETER_ERROR_TOO_MUCH_DATA (5008) 18 6.2.2.9 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA (5009) 19 6.2.2.10 Void 19 6.2.2.11 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) 19 6.2.2.12 DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED (5012) 19 6.3 AVPs 19 6.3.0 General 19 6.3.1 Visited-Network-Identifier AVP 22 6.3.2 Public-Identity AVP 22 6.3.3 Server-Name AVP 22 6.3.4 Server-Capabilities AVP 23 6.3.5 Mandatory-Capability AVP 23 6.3.6 Optional-Capability AVP 23 6.3.7 User-Data AVP 23 6.3.8 SIP-Number-Auth-Items AVP 23 6.3.9 SIP-Authentication-Scheme AVP 23 6.3.10 SIP-Authenticate AVP 24 6.3.11 SIP-Authorization AVP 24 6.3.12 SIP-Authentication-Context AVP 24 6.3.13 SIP-Auth-Data-Item AVP 24 6.3.14 SIP-Item-Number AVP 25 6.3.15 Server-Assignment-Type AVP 25 6.3.16 Deregistration-Reason AVP 26 6.3.17 Reason-Code AVP 26 6.3.18 Reason-Info AVP 26 6.3.19 Charging-Information AVP 27 6.3.20 Primary-Event-Charging-Function-Name AVP 27 6.3.21 Secondary-Event-Charging-Function-Name AVP 27 6.3.22 Primary-Charging-Collection-Function-Name AVP 27 6.3.23 Secondary-Charging-Collection-Function-Name AVP 27 6.3.24 User-Authorization-Type AVP 27 6.3.25 Void 28 6.3.26 User-Data-Already-Available AVP 28 6.3.27 Confidentiality-Key AVP 28 6.3.28 Integrity-Key AVP 28 6.3.29 Supported-Features AVP 28 6.3.30 Feature-List-ID AVP 29 6.3.31 Feature-List AVP 29 6.3.32 Supported-Applications AVP 29 6.3.33 Associated-Identities AVP 29 6.3.34 Originating-Request AVP 29 6.3.35 Wildcarded-Public-Identity AVP 29 6.3.36 SIP-Digest-Authenticate AVP 29 6.3.37 Digest-Realm AVP 30 6.3.38 Void 30 6.3.39 Digest-Algorithm AVP 30 6.3.40 Digest-QoP AVP 30 6.3.41 Digest-HA1 AVP 30 6.3.42 Line-Identifier AVP 30 6.3.43 Wildcarded-IMPU AVP 30 6.3.44 UAR-Flags AVP 30 6.3.45 Loose-Route-Indication AVP 31 6.3.46 SCSCF-Restoration-Info AVP 31 6.3.47 Path AVP 31 6.3.48 Contact AVP 31 6.3.49 Subscription-Info AVP 31 6.3.49.1 Call-ID-SIP-Header AVP 32 6.3.49.2 From-SIP-Header AVP 32 6.3.49.3 To-SIP-Header AVP 32 6.3.49.4 Record-Route AVP 32 6.3.50 Associated-Registered-Identities AVP 32 6.3.51 Multiple-Registration-Indication 32 6.3.52 Restoration-Info AVP 32 6.3.53 Framed-IP-Address AVP 33 6.3.54 Framed-IPv6-Prefix AVP 33 6.3.55 Framed-Interface-Id AVP 33 6.3.56 Session-Priority AVP 33 6.3.57 Identity-with-Emergency-Registration AVP 33 6.3.58 Priviledged-Sender-Indication AVP 33 6.3.59 LIA-Flags 34 6.3.60 OC-Supported-Features 34 6.3.61 OC-OLR 34 6.3.62 Initial-CSeq-Sequence-Number AVP 34 6.3.63 SAR-Flags 34 6.3.64 Allowed-WAF-WWSF-Identities AVP 34 6.3.65 WebRTC-Authentication-Function-Name AVP 35 6.3.66 WebRTC-Web-Server-Function-Name AVP 35 6.3.67 DRMP AVP 35 6.3.68 Load 35 6.3.69 RTR-Flags 35 6.3.70 P-CSCF-Subscription-Info AVP 35 6.3.71 Registration-Time-Out 35 6.3.72 Alternate-Digest-Algorithm AVP 36 6.3.73 Alternate-Digest-HA1 AVP 36 6.3.74 Failed-PCSCF 36 6.3.75 PCSCF-FQDN 36 6.3.76 PCSCF-IP-Address 36 6.4 Use of namespaces 36 6.4.1 AVP codes 36 6.4.2 Experimental-Result-Code AVP values 36 6.4.3 Command Code values 36 6.4.4 Application-ID value 36 7 Special Requirements 37 7.1 Version Control 37 7.1.1 Defining a new feature 37 7.1.2 Changing the version of the interface 40 7.2 Supported features 40 7.2.1 Dynamic discovery of supported features 40 7.3 Interface versions 41 7.3.1 Discovery of supported interface versions 41 Annex A (informative): Change history 43 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope The present document defines a transport protocol for use in the IP multimedia (IM) Core Network (CN) subsystem based on Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28]. The present document is applicable to: - The Cx interface between the I-CSCF/S-CSCF and the HSS. - The Dx interface between the I-CSCF/S-CSCF and the SLF. Whenever it is possible, this document specifies the requirements for this protocol by reference to specifications produced by the IETF within the scope of Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28]. Where this is not possible, extensions to Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28] are defined within this document. 2 References The following documents contain provisions, which through reference in this text constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPPÊTSÊ29.228: ""IP Multimedia (IM) Subsystem Cx and Dx interface; signalling flows and message contents"". [2] 3GPPÊTSÊ33.210: ""3G Security; Network Domain Security; IP Network Layer Security"". [3] IETFÊRFCÊ3261: ""SIP: Session Initiation Protocol"". [4] IETFÊRFCÊ2396: ""Uniform Resource Identifiers (URI): generic syntax"". [5] Void. [6] Void. [7] IETFÊRFCÊ2234: ""Augmented BNF for syntax specifications"". [8] IETFÊRFCÊ3966: ""The tel URI for Telephone Numbers"". [9] Void. [10] Void. [11] 3GPPÊTSÊ29.329: ""Sh Interface based on the Diameter protocol; protocol details"". [12] IETFÊRFCÊ3589: ""Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5"". [13] 3GPPÊTSÊ23.003: ""Numbering, addressing and identification"". [14] Void. [15] IETFÊRFCÊ4740: ""Diameter Session Initiation Protocol (SIP) Application"". [16] 3GPPÊTSÊ29.328: ""IP Multimedia (IM) Subsystem Sh interface; Signalling flows and message contents"". [17] IETFÊRFCÊ3327: ""Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts"". [18] 3GPPÊTSÊ29.273: ""3GPP EPS AAA interfaces"". [19] IETFÊRFCÊ4005: ""Diameter Network Access Server Application"". [20] IETFÊRFCÊ4590: "" RADIUS Extension for Digest Authentication"". [21] IETFÊRFCÊ4960: ""Stream Control Transmission Protocol"". [22] IETFÊRFCÊ3162: ""RADIUS and IPv6"". [23] IETFÊRFCÊ7683: ""Diameter Overload Indication Conveyance"". [24] 3GPPÊTSÊ23.380: ""IMS Restoration Procedures"". [25] IETF draft-holmberg-sipcore-auth-id-01: ""Authorization server identity"". Editor's note: The above document cannot be formally referenced until it is published as an RFC. [26] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [27] IEFTÊRFCÊ8583: ""Diameter Load Information Conveyance"". [28] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [29] IETFÊRFCÊ7616: ""HTTP Digest Access Authentication"". 3 Definitions, symbols and abbreviations 3.1 Definitions Refer to IETFÊRFCÊ6733Ê[28] for the definitions of some terms used in this document. For the purposes of the present document, the following terms and definitions apply. Attribute-Value Pair: see IETFÊRFCÊ6733Ê[28], it corresponds to an Information Element in a Diameter message. Diameter Multimedia client: a client that implements the Diameter Multimedia application. The client is one of the communicating Diameter peers that usually initiate transactions. Examples in 3GPP are the I-CSCF and S-CSCF. Diameter Multimedia server: a server that implements the Diameter Multimedia application. A Diameter Multimedia server that also supported the NASREQ and MobileIP applications would be referred to as a Diameter server. An example of a Diameter Multimedia server in 3GPP is the HSS. Registration: SIP-registration. Server: SIP-server. User data: user profile data. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AAA Authentication, Authorization and Accounting ABNF Augmented Backus-Naur Form AVP Attribute-Value Pair CN Core Network CSCF Call Session Control Function DSCP Differentiated Services Code Point DRMP Diameter Routing Message Priority HSS Home Subscriber Server IANA Internet Assigned Numbers Authority I-CSCF Interrogating CSCF IETF Internet Engineering Task Force IMS IP Multimedia Subsystem NDS Network Domain Security RFC Request For Comments S-CSCF Serving CSCF SCTP Stream Control Transport Protocol SIP Session Initiation Protocol SLF Server Locator Function UCS Universal Character Set URL Uniform Resource Locator UTF UCS Transformation Formats WAF WebRTC Authentication Function WWSF WebRTC Web Server Function 4 General The Diameter base protocol as specified in IETFÊRFCÊ6733Ê[28] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and event codes specified in clauseÊ5 of this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) are unmodified. 5 Use of the Diameter base protocol With the clarifications listed in the following clauses the Diameter base protocol defined by IETFÊRFCÊ6733Ê[28] shall apply. 5.1 Securing Diameter Messages For secure transport of Diameter messages, see 3GPPÊTSÊ33.210Ê[2]. 5.2 Accounting functionality Accounting functionality (Accounting Session State Machine, related command codes and AVPs) is not used on the Cx interface. 5.3 Use of sessions Both between the I-CSCF and the HSS and between the S-CSCF and the HSS, Diameter sessions are implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client does not need to send any re-authorization or session termination requests to the server. The Diameter base protocol includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions. The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETFÊRFCÊ6733Ê[28]. As a consequence, the server does not maintain any state information about this session and the client does not need to send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 5.4 Transport protocol Diameter messages over the Cx and the Dx interfaces shall make use of SCTP IETFÊRFCÊ4960Ê[21]. 5.5 Routing considerations This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host. If an I-CSCF or S-CSCF knows the address/name of the HSS for a certain user, both the Destination-Realm and Destination-Host AVPs shall be present in the request. Otherwise, only the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. the SLF or a Diameter Proxy Agent (see 3GPPÊTSÊ29.228Ê[1]), based on the Diameter routing table in the client. If the next Diameter node is an SLF, then once the SLF has returned the address or the destination HSS (using Redirect-Host AVP), the redirected request to the HSS shall include both Destination-Realm and Destination-Host AVPs. If the next Diameter node is a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the destination HSS. The Diameter Proxy Agent, based on the result of this determination of the destination HSS, shall modify the Destination-Realm AVP and Destination-Host AVP of the request appropriately. The Diameter Proxy Agent shall then append a Route-Record AVP to the request and shall send the request to the destination HSS. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an I-CSCF or an S-CSCF. If the response is routed back to a Diameter Proxy Agent, the Diameter Proxy Agent shall send the response back to the I-CSCF or S-CSCF without modifying the Origin-Realm AVP and Origin-Host AVP. The response shall contain the Origin-Realm AVP set to the realm of the HSS together with the Origin-Host AVP set to the HSS that sent the response. The S-CSCF shall store the HSS realm and HSS address for each Public Identity, after the first request sent to the User Identity to HSS resolution function. Requests initiated by the HSS towards an S-CSCF shall include both Destination-Host and Destination-Realm AVPs. The HSS obtains the Destination-Host AVP to use in requests towards an S-CSCF, from the Origin-Host AVP received in previous requests from the S-CSCF. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the HSS. Destination-Realm AVP is declared as mandatory in the ABNF for all requests. 5.6 Advertising Application Support The HSS, S-CSCF and I-CSCF shall advertise support of the Diameter Multimedia Application by including the value of the application identifier (see clauseÊ6) in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The vendor identifier value of 3GPP (10415) and ETSI (13019) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. Note: The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETFÊRFCÊ6733Ê[28]. 6 Diameter application for Cx interface This clause specifies a Diameter application that allows a Diameter Multimedia server and a Diameter Multimedia client: - to exchange location information - to authorize a user to access the IMS - to exchange authentication information - to download and handle changes in the user data stored in the server The Cx interface protocol is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the Cx/Dx interface application is 16777216 (allocated by IANA). 6.1 Command-Code values This clause defines Command-Code values for this Diameter application. Every command is defined by means of the ABNF syntax IETFÊRFCÊ2234Ê[7], according to the Command Code Format (CCF) specification defined in IETFÊRFCÊ6733Ê[28]. Whenever the definition and use of an AVP is not specified in this document, what is stated in IETFÊRFCÊ6733Ê[28] shall apply. NOTE: As the Diameter commands described in this specification have been defined based on the former specification of the Diameter base protocol, the Vendor-Specific-Application-Id AVP is still listed as a required AVP (an AVP indicated as {AVP}) in the command code format specifications defined in this specification to avoid backward compatibility issues, even if the use of this AVP has been deprecated in the new specification of the Diameter base protocol (IETFÊRFCÊ6733Ê[28]). The command codes for the Cx/Dx interface application are taken from the range allocated by IANA in IETFÊRFCÊ3589Ê[12] as assigned in this specification. For these commands, the Application-ID field shall be set to 16777216 (application identifier of the Cx/Dx interface application, allocated by IANA). The following Command Codes are defined in this specification: Table 6.1.1: Command-Code values Command-Name Abbreviation Code Clause User-Authorization-Request UAR 300 6.1.1 User-Authorization-Answer UAA 300 6.1.2 Server-Assignment-Request SAR 301 6.1.3 Server-Assignment-Answer SAA 301 6.1.4 Location-Info-Request LIR 302 6.1.5 Location-Info-Answer LIA 302 6.1.6 Multimedia-Auth-Request MAR 303 6.1.7 Multimedia-Auth-Answer MAA 303 6.1.8 Registration-Termination-Request RTR 304 6.1.9 Registration-Termination-Answer RTA 304 6.1.10 Push-Profile-Request PPR 305 6.1.11 Push-Profile-Answer PPA 305 6.1.12 6.1.1 User-Authorization-Request (UAR) Command The User-Authorization-Request (UAR) command, indicated by the Command-Code field set to 300 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request the authorization of the registration of a multimedia user."
"Message Format < User-Authorization-Request> ::= < Diameter Header: 300, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } { Visited-Network-Identifier } [ User-Authorization-Type ] [ UAR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.2 User-Authorization-Answer (UAA) Command The User-Authorization-Answer (UAA) command, indicated by the Command-Code field set to 300 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the User-Authorization-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < User-Authorization-Answer> ::= < Diameter Header: 300, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Server-Name ] [ Server-Capabilities ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.3 Server-Assignment-Request (SAR) Command The Server-Assignment-Request (SAR) command, indicated by the Command-Code field set to 301 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request it to store the name of the server that is currently serving the user. Message Format <Server-Assignment-Request> ::= < Diameter Header: 301, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ User-Name ] [ OC-Supported-Features ] *[ Supported-Features ] *[ Public-Identity ] [ Wildcarded-Public-Identity ] { Server-Name } { Server-Assignment-Type } { User-Data-Already-Available } [ SCSCF-Restoration-Info ] [ Multiple-Registration-Indication ] [ Session-Priority ] [ SAR-Flags ] [ Failed-PCSCF ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.4 Server-Assignment-Answer (SAA) Command The Server-Assignment-Answer (SAA) command, indicated by the Command-Code field set to 301 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Server-Assignment-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. If Result-Code or Experimental-Result does not inform about an error, the User-Data AVP shall contain the information that the S-CSCF needs to give service to the user. Message Format <Server-Assignment-Answer> ::= < Diameter Header: 301, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ User-Name ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ User-Data ] [ Charging-Information ] [ Associated-Identities ] [ Loose-Route-Indication ] *[ SCSCF-Restoration-Info ] [ Associated-Registered-Identities ] [ Server-Name ] [ Wildcarded-Public-Identity ] [ Priviledged-Sender-Indication ] [ Allowed-WAF-WWSF-Identities ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.5 Location-Info-Request (LIR) Command The Location-Info-Request (LIR) command, indicated by the Command-Code field set to 302 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request name of the server that is currently serving the user. Message Format <Location-Info-Request> ::= < Diameter Header: 302, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } [ Originating-Request ] [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } [ User-Authorization-Type ] [ Session-Priority ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.6 Location-Info-Answer (LIA) Command The Location-Info-Answer (LIA) command, indicated by the Command-Code field set to 302 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Location-Info-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format <Location-Info-Answer> ::= < Diameter Header: 302, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Server-Name ] [ Server-Capabilities ] [ Wildcarded-Public-Identity ] [ LIA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.7 Multimedia-Auth-Request (MAR) Command The Multimedia-Auth-Request (MAR) command, indicated by the Command-Code field set to 303 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia client to a Diameter Multimedia server in order to request security information. Message Format < Multimedia-Auth-Request > ::= < Diameter Header: 303, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Realm } [ Destination-Host ] { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] { Public-Identity } { SIP-Auth-Data-Item } { SIP-Number-Auth-Items } { Server-Name } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.8 Multimedia-Auth-Answer (MAA) Command The Multimedia-Auth-Answer (MAA) command, indicated by the Command-Code field set to 303 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Multimedia-Auth-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < Multimedia-Auth-Answer > ::= < Diameter Header: 303, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ User-Name ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ Public-Identity ] [ SIP-Number-Auth-Items ] *[SIP-Auth-Data-Item ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.9 Registration-Termination-Request (RTR) Command The Registration-Termination-Request (RTR) command, indicated by the Command-Code field set to 304 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter Multimedia client in order to request the de-registration of a user. Message Format <Registration-Termination-Request> ::= < Diameter Header: 304, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Realm } { User-Name } [ Associated-Identities ] *[ Supported-Features ] *[ Public-Identity ] { Deregistration-Reason } RTR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.10 Registration-Termination-Answer (RTA) Command The Registration-Termination-Answer (RTA) command, indicated by the Command-Code field set to 304 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Registration-Termination-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format <Registration-Termination-Answer> ::= < Diameter Header: 304, PXY, 16777216 > < Session-Id > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Associated-Identities ] *[ Supported-Features ] *[ Identity-with-Emergency-Registration ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.11 Push-Profile-Request (PPR) Command The Push-Profile-Request (PPR) command, indicated by the Command-Code field set to 305 and the 'R' bit set in the Command Flags field, is sent by a Diameter Multimedia server to a Diameter Multimedia client in order to update the subscription data and for SIP Digest authentication the authentication data of a multimedia user in the Diameter Multimedia client whenever a modification has occurred in the subscription data or digest password that constitutes the data used by the client. Message Format < Push-Profile-Request > ::= < Diameter Header: 305, REQ, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] [ User-Data ] [ Charging-Information ] [ SIP-Auth-Data-Item ] [ Allowed-WAF-WWSF-Identities ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.12 Push-Profile-Answer (PPA) Command The Push-Profile-Answer (PPA) command, indicated by the Command-Code field set to 305 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Push-Profile-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2. Message Format < Push-Profile-Answer > ::= < Diameter Header: 305, PXY, 16777216 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.2 Result-Code AVP values This clause defines new result code values that must be supported by all Diameter implementations that conform to this specification. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and Result-Code AVP shall be absent. 6.2.1 Success Result codes that fall within the Success category are used to inform a peer that a request has been successfully completed. 6.2.1.1 DIAMETER_FIRST_REGISTRATION (2001) The HSS informs the I-CSCF that: - The user is authorized to register this public identity; - A S-CSCF shall be assigned to the user. 6.2.1.2 DIAMETER_SUBSEQUENT_REGISTRATION (2002) The HSS informs the I-CSCF that: - The user is authorized to register this public identity; - A S-CSCF is already assigned and there is no need to select a new one. 6.2.1.3 DIAMETER_UNREGISTERED_SERVICE (2003) The HSS informs the I-CSCF that: - The public identity is not registered but has services related to unregistered state; - A S-CSCF shall be assigned to the user. 6.2.1.4 DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED (2004) The HSS informs to the S-CSCF that: - The de-registration is completed; - The S-CSCF name is not stored in the HSS. 6.2.1.5 Void 6.2.2 Permanent Failures Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not be attempted again. 6.2.2.1 DIAMETER_ERROR_USER_UNKNOWN (5001) A message was received for a user or a wildcarded identity that is unknown. 6.2.2.2 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) A message was received with a public identity and a private identity for a user, and the server determines that the public identity does not correspond to the private identity. 6.2.2.3 DIAMETER_ERROR_IDENTITY_NOT_REGISTERED (5003) A query for location information is received for a public identity that has not been registered before. The user to which this identity belongs cannot be given service in this situation. 6.2.2.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) The user is not allowed to roam in the visited network. 6.2.2.5 DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED (5005) The identity has already a server assigned and the registration status does not allow that it is overwritten. 6.2.2.6 DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED (5006) The authentication scheme indicated in an authentication request is not supported. 6.2.2.7 DIAMETER_ERROR_IN_ASSIGNMENT_TYPE (5007) The identity being registered has already the same server assigned and the registration status does not allow the server assignment type or the Public Identity type received in the request is not allowed for the indicated server-assignment-type. 6.2.2.8 DIAMETER_ERROR_TOO_MUCH_DATA (5008) The volume of the data pushed to the receiving entity exceeds its capacity. NOTE: This error code is also used in 3GPPÊTSÊ29.329Ê[11]. 6.2.2.9 DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA (5009) The S-CSCF informs HSS that the received subscription data contained information, which was not recognised or supported. 6.2.2.10 Void 6.2.2.11 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) A request application message was received indicating that the origin host requests that the command pair would be handled using a feature which is not supported by the destination host. 6.2.2.12 DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED (5012) This error is used when the HSS supports the P-CSCF-Restoration-mechanism feature, but none of the user serving node(s) supports it, as described by 3GPPÊTSÊ23.380Ê[24] clauseÊ5.4. 6.3 AVPs 6.3.0 General The following table describes the Diameter AVPs defined by 3GPP for the Cx interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415) if not otherwise indicated. Table 6.3.0.1: Diameter Multimedia Application AVPs AVP Flag rules Attribute Name AVP Code Clause defined Value Type Must May Should not Must not May Encr. Visited-Network-Identifier 600 6.3.1 OctetString M, V No Public-Identity 601 6.3.2 UTF8String M, V No Server-Name 602 6.3.3 UTF8String M, V No Server-Capabilities 603 6.3.4 Grouped M, V No Mandatory-Capability 604 6.3.5 Unsigned32 M, V No Optional-Capability 605 6.3.6 Unsigned32 M, V No User-Data 606 6.3.7 OctetString M, V No SIP-Number-Auth-Items 607 6.3.8 Unsigned32 M, V No SIP-Authentication-Scheme 608 6.3.9 UTF8String M, V No SIP-Authenticate 609 6.3.10 OctetString M, V No SIP-Authorization 610 6.3.11 OctetString M, V No SIP-Authentication-Context 611 6.3.12 OctetString M, V No SIP-Auth-Data-Item 612 6.3.13 Grouped M, V No SIP-Item-Number 613 6.3.14 Unsigned32 M, V No Server-Assignment-Type 614 6.3.15 Enumerated M, V No Deregistration-Reason 615 6.3.16 Grouped M, V No Reason-Code 616 6.3.17 Enumerated M, V No Reason-Info 617 6.3.18 UTF8String M, V No Charging-Information 618 6.3.19 Grouped M, V No Primary-Event-Charging-Function-Name 619 6.3.20 DiameterURI M, V No Secondary-Event-Charging-Function-Name 620 6.3.21 DiameterURI M, V No Primary-Charging-Collection-Function-Name 621 6.3.22 DiameterURI M, V No Secondary-Charging-Collection-Function-Name 622 6.3.23 DiameterURI M, V No User-Authorization-Type 623 6.3.24 Enumerated M, V No User-Data-Already-Available 624 6.3.26 Enumerated M, V No Confidentiality-Key 625 6.3.27 OctetString M, V No Integrity-Key 626 6.3.28 OctetString M, V No Supported-Features 628 6.3.29 Grouped V M No Feature-List-ID 629 6.3.30 Unsigned32 V M No Feature-List 630 6.3.31 Unsigned32 V M No Supported-Applications 631 6.3.32 Grouped V M No Associated-Identities 632 6.3.33 Grouped V M No Originating-Request 633 6.3.34 Enumerated M,V No Wildcarded-Public-Identity 634 6.3.35 UTF8String V M No SIP-Digest-Authenticate 635 6.3.36 Grouped V M No Digest-Realm 104 NOTE 3 6.3.37 UTF8String M V No Digest-Algorithm 111 NOTE 3 6.3.39 UTF8String M V No Digest-QoP 110 NOTE 3 6.3.40 UTF8String M V No Digest-HA1 121 NOTE 3 6.3.41 UTF8String M V No UAR-Flags 637 6.3.44 Unsigned32 V M No Loose-Route-Indication 638 6.3.45 Enumerated V M No SCSCF-Restoration-Info 639 6.3.46 Grouped V M No Path 640 6.3.47 OctetString V M No Contact 641 6.3.48 OctetString V M No Subscription-Info 642 6.3.49 Grouped V M No Call-ID-SIP-Header 643 6.3.49.1 OctetString V M No From-SIP-Header 644 6.3.49.2 OctetString V M No To-SIP-Header 645 6.3.49.3 OctetString V M No Record-Route 646 6.3.49.4 OctetString V M No Associated-Registered-Identities 647 6.3.50 Grouped V M No Multiple-Registration-Indication 648 6.3.51 Enumerated V M No Restoration-Info 649 6.3.52 Grouped V M No Session-Priority 650 6.3.56 Enumerated V M No Identity-with-Emergency-Registration 651 6.3.57 Grouped V M No Priviledged-Sender-Indication 652 6.3.58 Enumerated V M No LIA-Flags 653 6.3.59 Unsigned32 V M No OC-Supported-Features 621 NOTE 4 6.3.60 Grouped M, V No OC-OLR 623 NOTE 4 6.3.61 Grouped M, V No Initial-CSeq-Sequence-Number 654 6.3.62 Unsigned32 V M No SAR-Flags 655 6.3.63 Unsigned32 V M No Allowed-WAF-WWSF-Identities 656 6.3.64 Grouped V M No WebRTC-Authentication-Function-Name 657 6.3.65 UTF8String V M No WebRTC-Web-Server-Function-Name 658 6.3.66 UTF8String V M No DRMP 301 NOTE 5 6.3.67 Enumerated M, V No Load NOTE 6 6.3.68 Grouped M, V No RTR-Flags 659 6.3.69 Unsigned32 V M No P-CSCF-Subscription-Info 660 6.3.70 Grouped V M No Registration-Time-Out 661 6.3.71 Time V M No Alternate-Digest-Algorithm 662 NOTEÊ7 6.3.72 UTF8String V M No Alternate-Digest-HA1 663 NOTEÊ7 6.3.73 UTF8String V M No Failed-PCSCF 664 6.3.74 Grouped V M No PCSCF-FQDN 665 6.3.75 DiameterIdentity V M No PCSCF-IP-Address 666 6.3.76 Address V M No NOTE 1: The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETFÊRFCÊ6733Ê[28]. NOTE 1a: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. NOTE 2: Depending on the concrete command. NOTE 3: The value of these attributes is defined in IETFÊRFCÊ4590Ê[20]. NOTE 4: The value of these attributes is defined in IETFÊRFCÊ7683Ê[23]. NOTE 5: The value of this attribute is defined in IETFÊRFCÊ7944Ê[26]. NOTE 6: The value of this attribute is defined in IEFTÊRFCÊ8583Ê[27]. NOTEÊ7: The Alternate-Digest-HA1 AVP is defined in the same way as Digest-HA1 AVP in accordance with IETFÊRFCÊ7616Ê[29]. If the Alternate-Digest-HA1 AVP is present, the Digest-HA1 AVP shall also be present and the Digest-HA1 AVP shall contain the MD5 hash. The algorithm of the Alternate-Digest-HA1 AVP shall be determined by the Alternate-Digest-Algorithm AVP. 6.3.1 Visited-Network-Identifier AVP The Visited-Network-Identifier AVP is of type OctetString. This AVP contains an identifier that helps the HSS to identify the visited network (e.g. the visited network domain name). Coding of octets is H-PLMN operator specific. The I-CSCF maps a received P-Visited-Network-ID onto an Octet String value that is consistently configured in I-CSCF and HSS to uniquely identify the visited network. 6.3.2 Public-Identity AVP The Public-Identity AVP is of type UTF8String. This AVP contains the public identity of a user in the IMS. The syntax of this AVP corresponds either to a SIP URL (with the format defined in IETFÊRFCÊ3261Ê[3] and IETFÊRFCÊ2396Ê[4]) or a TEL URL (with the format defined in IETFÊRFCÊ3966Ê[8]). Both SIP URL and TEL URL shall be in canonical form, as described in 3GPPÊTSÊ23.003Ê[13]. 6.3.3 Server-Name AVP The Server-Name AVP is of type UTF8String. This AVP contains a SIP-URL (as defined in IETFÊRFCÊ3261Ê[3] and IETFÊRFCÊ2396Ê[4]), used to identify a SIP server (e.g. S-CSCF name). 6.3.4 Server-Capabilities AVP The Server-Capabilities AVP is of type Grouped. This AVP contains information to assist the I-CSCF in the selection of an S-CSCF. AVP format Server-Capabilities ::= <AVP header: 603 10415> *[Mandatory-Capability] *[Optional-Capability] *[Server-Name] *[AVP] 6.3.5 Mandatory-Capability AVP The Mandatory-Capability AVP is of type Unsigned32. Each value included in this AVP can be used to represent a single determined mandatory capability or a set of capabilities of an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1] (clauseÊ6.7). 6.3.6 Optional-Capability AVP The Optional-Capability AVP is of type Unsigned32. Each value included in this AVP can be used to represent a single determined optional capability or a set of capabilities of an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1] (clauseÊ6.7). 6.3.7 User-Data AVP The User-Data AVP is of type OctetString. This AVP contains the user data required to give service to a user. The exact content and format of this AVP is described in 3GPPÊTSÊ29.228Ê[1]. 6.3.8 SIP-Number-Auth-Items AVP The SIP-Number-Auth-Items AVP is of type Unsigned32. When used in a request, the SIP-Number-Auth-Items indicates the number of authentication vectors the S-CSCF is requesting. This can be used, for instance, when the client is requesting several pre-calculated authentication vectors. In the answer message, the SIP-Number-Auth-Items AVP indicates the actual number of SIP-Auth-Data-Item AVPs provided by the Diameter server. 6.3.9 SIP-Authentication-Scheme AVP The Authentication-Scheme AVP is of type UTF8String and indicates the authentication scheme used in the authentication of SIP messages. The following values are defined: - ""Digest-AKAv1-MD5"": it indicates IMS-AKA authentication scheme. NOTEÊ1: The S-CSCF uses the ""Digest-AKAv1-MD5"" authentication scheme towards the HSS for Digest-AKAv1 and Digest-AKAv2 versions. E.g. digest algorithms ""AKAv1-MD5"" and ""AKAv2-SHA-256"" require from the HSS the same procedures i.e. the same authentication information: random number RAND, authentication token AUTN, expected response XRES, cipher key CK and integrity key IK. NOTEÊ2: The ""AKAv1-MD5"" digest AKA algorithm is only supported for backward compatibility. - ""SIP Digest"": it indicates SIP Digest authentication scheme. - ""NASS-Bundled"": it indicates NASS Bundled authentication scheme. - ""Early IMS Security"": it indicates GPRS-IMS-Bundled authentication scheme. - ""Unknown"": it indicates that the authentication scheme to be used is unknown at this point. 6.3.10 SIP-Authenticate AVP The SIP-Authenticate AVP is of type OctetString and contains specific parts of the data portion of the WWW-Authenticate or Proxy-Authenticate SIP headers that are to be present in a SIP response. It shall contain, binary encoded, the concatenation of the authentication challenge RAND and the token AUTN. See 3GPPÊTSÊ33.203Ê[3] for further details about RAND and AUTN. The Authentication Information has a fixed length of 32 octets; the 16 most significant octets shall contain the RAND, the 16 least significant octets shall contain the AUTN. 6.3.11 SIP-Authorization AVP The SIP-Authorization AVP is of type OctetString and contains specific parts of the data portion of the Authorization or Proxy-Authorization SIP headers suitable for inclusion in a SIP request. When included in an Authentication Request, it shall contain the concatenation of RAND, as sent to the terminal, and AUTS, as received from the terminal. RAND and AUTS shall both be binary encoded. See 3GPPÊTSÊ33.203Ê[3] for further details about RAND and AUTS. The Authorization Information has a fixed length of 30 octets; the 16 most significant octets shall contain the RAND, the 14 least significant octets shall contain the AUTS. When included in an Authentication Request Response, it shall contain, binary encoded, the expected response XRES. See 3GPPÊTSÊ33.203Ê[3] for further details about XRES. 6.3.12 SIP-Authentication-Context AVP The SIP-Authentication-Context AVP is of type OctectString. 6.3.13 SIP-Auth-Data-Item AVP The SIP-Auth-Data-Item is of type Grouped, and contains the authentication and/or authorization information for the Diameter client. AVP format SIP-Auth-Data-Item :: = < AVP Header : 612 10415 > [ SIP-Item-Number ] [ SIP-Authentication-Scheme ] [ SIP-Authenticate ] [ SIP-Authorization ] [ SIP-Authentication-Context ] [ Confidentiality-Key ] [ Integrity-Key ] [ SIP-Digest-Authenticate ] [ Framed-IP-Address ] [ Framed-IPv6-Prefix ] [ Framed-Interface-Id ] *Ê[ Line-Identifier ] *Ê[AVP] 6.3.14 SIP-Item-Number AVP The SIP-Item-Number AVP is of type Unsigned32. 6.3.15 Server-Assignment-Type AVP The Server-Assignment-Type AVP is of type Enumerated, and indicates the type of server update, request or notification being performed in a Server-Assignment-Request operation. The following values are defined: NO_ASSIGNMENT (0) This value is used to request from HSS the user profile assigned to one or more public identities and to retrieve the S-CSCF restoration information for a registered Public User Identity, without affecting the registration state of those identities. REGISTRATION (1) The request is generated as a consequence of a first registration of an identity. RE_REGISTRATION (2) The request corresponds to the re-registration of an identity or update of the S-CSCF Restoration Information. UNREGISTERED_USER (3) The request is generated in the following cases: - The S-CSCF received a request for a Public Identity that is not registered, or - An AS sent an originating request on behalf of a Public Identity that is not registered, or - The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with only one Private User Identity and started the P-CSCF Restoration procedure including the P-CSCF Restoration Indication in the request to the HSS. TIMEOUT_DEREGISTRATION (4) The SIP registration timer of an identity has expired. USER_DEREGISTRATION (5) The S-CSCF has received a user initiated de-registration request. TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME (6) The request is generated in the following cases: The SIP registration timer of an identity has expired. The S-CSCF keeps the user data stored in the S-CSCF and requests HSS to store the S-CSCF name. The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with only one Private User Identity and started the PCRF-based P-CSCF Restoration procedure. USER_DEREGISTRATION_STORE_SERVER_NAME (7) The S-CSCF has received a user initiated de-registration request. The S-CSCF keeps the user data stored in the S-CSCF and requests HSS to store the S-CSCF name. ADMINISTRATIVE_DEREGISTRATION (8) The request is generated in the following cases: - The S-CSCF, due to administrative reasons or network issues, has performed the de-registration of an identity. - The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with more than one Private User Identity and started the P-CSCF Restoration procedure including the P-CSCF Restoration Indication in the request to the HSS. The S-CSCF identified a P-CSCF failure for a Public User Identity that is registered with more than one Private User Identity and started the PCRF-based P-CSCF Restoration procedure. AUTHENTICATION_FAILURE (9) The authentication of a user has failed. AUTHENTICATION_TIMEOUT (10) The authentication timeout has occurred. DEREGISTRATION_TOO_MUCH_DATA (11) The S-CSCF has requested user profile information from the HSS and has received a volume of data higher than it can accept. AAA_USER_DATA_REQUEST (12) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. PGW_UPDATE (13) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. RESTORATION (14) Used in the SWx protocol, defined in 3GPPÊTSÊ29.273Ê[18]. This value is not used in the Cx protocol. 6.3.16 Deregistration-Reason AVP The Deregistration-Reason AVP is of type Grouped, and indicates the reason for a de-registration operation. AVP format Deregistration-Reason :: = < AVP Header : 615 10415 > { Reason-Code } [ Reason-Info ] *Ê[AVP] 6.3.17 Reason-Code AVP The Reason-Code AVP is of type Enumerated, and defines the reason for the network initiated de-registration. The following values are defined: PERMANENT_TERMINATION (0) NEW_SERVER_ASSIGNED (1) SERVER_CHANGE (2) REMOVE_S-CSCF (3) The detailed behaviour of the S-CSCF is defined in 3GPPÊTSÊ29.228Ê[1]. 6.3.18 Reason-Info AVP The Reason-Info AVP is of type UTF8String, and contains textual information to inform the user about the reason for a de-registration. 6.3.19 Charging-Information AVP The Charging-Information is of type Grouped, and contains the addresses of the charging functions. AVP format Charging-Information :: = < AVP Header : 618 10415 > [ Primary-Event-Charging-Function-Name ] [ Secondary-Event-Charging-Function-Name ] [ Primary-Charging-Collection-Function-Name ] [ Secondary-Charging-Collection-Function-Name ] *[ AVP] 6.3.20 Primary-Event-Charging-Function-Name AVP The Primary-Event-Charging-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Primary Online Charging Function. The receiving network element shall extract the FQDN of the DiameterURI in this AVP and may use it as content of the Destination-Host AVP for the Diameter accounting requests. The parent domain of the FQDN in the DiameterURI shall be used as Destination-Realm. The number of labels used for the Destination-Realm shall be determined before the Charging Information is provisioned and may be a configuration option. NOTE: A FQDN is an absolute domain name including a subdomain and its parent domain. The subdomain and the parent domain contain one or more labels separated by dots. 6.3.21 Secondary-Event-Charging-Function-Name AVP The Secondary-Event-Charging-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Secondary Online Charging Function. The Destination-Host and Destination-Realm values for the Diameter accounting requests should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.22 Primary-Charging-Collection-Function-Name AVP The Primary-Charging-Collection-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Primary Charging Data Function. The Destination-Host and Destination-Realm values for the Diameter accounting requests should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.23 Secondary-Charging-Collection-Function-Name AVP The Secondary-Charging-Collection-Function-Name AVP is of type DiameterURI. This AVP contains the address of the Secondary Charging Data Function. The Destination-Host and Destination-Realm for the Diameter accounting requests values should be extracted from the DiameterURI in the way indicated in clauseÊ6.3.20. 6.3.24 User-Authorization-Type AVP The User-Authorization-Type AVP is of type Enumerated, and indicates the type of user authorization being performed in a User Authorization operation, i.e. UAR command. The following values are defined: REGISTRATION (0) This value is used in case of the initial registration or re-registration. I-CSCF determines this from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is not equal to zero. This is the default value. DE_REGISTRATION (1) This value is used in case of the de-registration. I-CSCF determines this from the Expires field or expires parameter in Contact field in the SIP REGISTER method if it is equal to zero. REGISTRATION_AND_CAPABILITIES (2) This value is used when the I-CSCF explicitly requests S-CSCF capability information from the HSS. The I-CSCF shall use this value when the user's current S-CSCF, which is stored in the HSS, cannot be contacted and a new S-CSCF needs to be selected 6.3.25 Void 6.3.26 User-Data-Already-Available AVP The User-Data-Already-Available AVP is of type Enumerated, and indicates to the HSS whether or not the S-CSCF already has the part of the user profile that it needs to serve the user. The following values are defined: USER_DATA_NOT_AVAILABLE (0) The S-CSCF does not have the data that it needs to serve the user. USER_DATA_ALREADY_AVAILABLE (1) The S-CSCF already has the data that it needs to serve the user. 6.3.27 Confidentiality-Key AVP The Confidentiality-Key is of type OctetString, and contains the Confidentiality Key (CK). 6.3.28 Integrity-Key AVP The Integrity-Key is of type OctetString, and contains the Integrity Key (IK). 6.3.29 Supported-Features AVP The Supported-Features AVP is of type Grouped. If this AVP is present it may inform the destination host about the features that the origin host supports for the application. The Feature-List AVP contains a list of supported features of the origin host. The Vendor-Id AVP and the Feature-List-ID AVP shall together identify which feature list is carried in the Supported-Features AVP for the Application-ID present in the command header. Where a Supported-Features AVP is used to identify features that have been defined by 3GPP, the Vendor-Id AVP shall contain the vendor ID of 3GPP. Vendors may define proprietary features, but it is strongly recommended that the possibility is used only as the last resort. Where the Supported-Features AVP is used to identify features that have been defined by a vendor other than 3GPP, it shall contain the vendor ID of the specific vendor in question. If there are multiple feature lists defined by the same vendor and the same application, the Feature-List-ID AVP shall differentiate those lists from one another. The destination host shall use the value of the Feature-List-ID AVP to identify the feature list. AVP format Supported-Features ::= < AVP header: 628 10415 > { Vendor-Id } { Feature-List-ID } { Feature-List } *[AVP] 6.3.30 Feature-List-ID AVP The Feature-List-ID AVP is of type Unsigned32 and it contains the identity of a feature list. 6.3.31 Feature-List AVP The Feature-List AVP is of type Unsigned32 and it contains a bit mask indicating the supported features of an application. When the bit set, indicates the corresponding feature is supported by the application. For the Cx application, the meaning of the bits has been defined in 7.1.1. 6.3.32 Supported-Applications AVP The Supported-Applications AVP is of type Grouped and it contains the supported application identifiers of a Diameter node. AVP format Supported-Applications ::= < AVP header: 631 10415 > *[ Auth-Application-Id ] *[ Acct-Application-Id ] *[ Vendor-Specific-Application-Id ] *[ AVP ] 6.3.33 Associated-Identities AVP The Associated-Identities AVP is of type Grouped and it contains the private user identities associated to an IMS subscription. AVP format Associated-Identities ::= < AVP header: 632, 10415 > *[ User-Name ] *[ AVP ] 6.3.34 Originating-Request AVP The Originating-Request AVP is of type Enumerated. The following value is defined: ORIGINATING (0) This value indicates to the HSS that the request is related to an AS originating SIP request in the Location-Information-Request operation. 6.3.35 Wildcarded-Public-Identity AVP The Wildcarded-Public-Identity AVP is of type UTF8String. This AVP contains a Wildcarded PSI or Wildcarded Public User Identity stored in the HSS. The syntax of the contents of this AVP is described in 3GPPÊTSÊ23.003Ê[13]. 6.3.36 SIP-Digest-Authenticate AVP The SIP-Digest-Authenticate is of type Grouped and it contains a reconstruction of either the SIP WWW-Authenticate or Proxy-Authentication header fields specified in IETFÊRFCÊ7616Ê[29]. AVP format SIP-Digest-Authenticate ::= < AVP Header: 635 10415> { Digest-Realm } Ê[ Digest-Algorithm ] { Digest-QoP } { Digest-HA1} [ Alternate-Digest-Algorithm ] [ Alternate-Digest-HA1 ] *[ AVP ] 6.3.37 Digest-Realm AVP The Digest-Realm AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.38 Void 6.3.39 Digest-Algorithm AVP The Digest-Algorithm AVP is defined in IETFÊRFCÊ4740Ê[15] and contains values as defined in IETFÊRFCÊ7616Ê[29]. NOTE: The MD5 algorithm is only supported for backward compatibility. 6.3.40 Digest-QoP AVP The Digest-QoP AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.41 Digest-HA1 AVP The Digest-HA1 AVP is defined in IETFÊRFCÊ4740Ê[15]. 6.3.42 Line-Identifier AVP The Line-Identifier AVP is of type OctetString. This AVP has Vendor Id ETSI (13019) and AVP code 500. This AVP contains a fixed broadband access line identifier associated with the user. 6.3.43 Wildcarded-IMPU AVP The Wildcarded-IMPU AVP is of type UTF8String. This AVP contains a Wildcarded Public User Identity stored in the HSS. The syntax of the contents of this AVP is described in 3GPPÊTSÊ23.003Ê[13]. Note: This AVP is used by Sh interface as specified in the 3GPPÊTSÊ29.328Ê[16] and 3GPPÊTSÊ29.329Ê[11]. 6.3.44 UAR-Flags AVP The UAR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in the following table: Table 6.3.44.1: UAR-Flags Bit Name Description 0 IMS Emergency Registration This bit, when set, indicates that the request corresponds to an IMS Emergency Registration. Bits not defined in this table shall be cleared by the sending I-CSCF and discarded by the receiving HSS. 6.3.45 Loose-Route-Indication AVP The Loose-Route-Indication AVP is of type Enumerated and indicates to the S-CSCF whether or not the loose route mechanism is required to serve the registered Public User Identities. The following values are defined: LOOSE_ROUTE_NOT_REQUIRED (0) LOOSE_ROUTE_REQUIRED (1) 6.3.46 SCSCF-Restoration-Info AVP The SCSCF-Restoration-Info AVP is of type Grouped and it contains the information required for an S-CSCF to handle the requests for a user. AVP format SCSCF-Restoration-Info ::= < AVP Header: 639, 10415> { User-Name } 1*{ Restoration-Info } [ Registration-Time-Out ] [ SIP-Authentication-Scheme ] *[ AVP ] 6.3.47 Path AVP The Path AVP is of type OctetString and it contains a comma separated list of SIP proxies in the Path header as defined in IETFÊRFCÊ3327Ê[17]. 6.3.48 Contact AVP The Contact AVP is of type OctetString and it contains the Contact Addresses and Parameters in the Contact header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49 Subscription-Info AVP The Subscription-Info AVP is of type Grouped and it contains the UE's subscription information. The Contact AVP contains the Contact Address and Parameters in the Contact header of the subscription request. AVP format Subscription-Info ::= < AVP Header: 642, 10415> { Call-ID-SIP-Header } { From-SIP-Header } { To-SIP-Header } { Record-Route } {Contact} *[ AVP ] 6.3.49.1 Call-ID-SIP-Header AVP The Call-ID-SIP-Header AVP is of type OctetString and it contains the information in the Call-ID header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.2 From-SIP-Header AVP The From-SIP-Header AVP is of type OctetString and it contains the information in the From header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.3 To-SIP-Header AVP The To-SIP-Header AVP is of type OctetString and it contains the information in the To header as defined in IETFÊRFCÊ3261Ê[11]. 6.3.49.4 Record-Route AVP The Record-Route AVP is of type OctetString and it contains a comma separated list of Record Route header(s) as defined in IETFÊRFCÊ3261Ê[11]. 6.3.50 Associated-Registered-Identities AVP The Associated-Registered-Identities AVP is of type Grouped and it contains the Private User Identities registered with the Public User Identity received in the request command. AVP format Associated-Registered-Identities ::= < AVP header: 647, 10415 > *[ User-Name ] *[ AVP ] 6.3.51 Multiple-Registration-Indication The Multiple-Registration-Indication AVP is of type Enumerated and indicates to the HSS whether or not the request is related to a multiple registration. The following values are defined: NOT_MULTIPLE_REGISTRATION (0) MULTIPLE_REGISTRATION (1) 6.3.52 Restoration-Info AVP The Restoration-Info AVP is of type Grouped and it contains the information related to a specific registration required for an S-CSCF to handle the requests for a user. The Contact AVP contains the Contact Address and Parameters in the Contact header of the registration request. AVP format Restoration-Info ::= < AVP Header: 649, 10415> { Path } { Contact } [ Initial-CSeq-Sequence-Number ] [ Call-ID-SIP-Header ] [ Subscription-Info ] [ P-CSCF-Subscription-Info ] *[ AVP ] 6.3.53 Framed-IP-Address AVP The Framed-IP-Address AVP is defined in IETFÊRFCÊ4005Ê[19]. 6.3.54 Framed-IPv6-Prefix AVP The Framed-IPv6-Prefix AVP is defined in IETFÊRFCÊ4005Ê[19], and it shall be encoded as defined in IETFÊRFCÊ3162Ê[22]. 6.3.55 Framed-Interface-Id AVP The Framed-Interface-Id AVP is defined in IETFÊRFCÊ4005Ê[19]. 6.3.56 Session-Priority AVP The Session-Priority AVP is of type Enumerated and indicates to the HSS the session's priority. The following values are defined: PRIORITY-0 (0) PRIORITY-1 (1) PRIORITY-2 (2) PRIORITY-3 (3) PRIORITY-4 (4) PRIORITY-0 is the highest priority. The value of the AVP when sent to the HSS is mapped from the value received by the CSCF as described in 3GPPÊTSÊ24.229 table A.162. The mapping is operator specific. This AVP may be placed as close to the Diameter header as possible in order to potentially allow optimized processing at the receiver. 6.3.57 Identity-with-Emergency-Registration AVP The Identity-with-Emergency-Registration AVP is of type Grouped and it contains a pair of private/public user identities which are emergency registered. AVP format Identity-with-Emergency-Registration ::= < AVP header: 651, 10415 > { User-Name } { Public-Identity } *[ AVP ] 6.3.58 Priviledged-Sender-Indication AVP The Priviledged-Sender-Indication AVP is of type Enumerated and indicates to the S-CSCF whether or not the Private User Identity shall be considered as a priviledged sender. The following values are defined: NOT_PRIVILEDGED_SENDER (0)PRIVILEDGED_SENDER (1) 6.3.59 LIA-Flags The LIA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.59.1. Table 6.3.59.1: LIA-Flags Bit Name Description 0 PSI Direct Routing Indication This bit, when set, indicates the request corresponds to PSI Direct Routing, what implies that HSS returns an AS name in Server-Name AVP. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving I-CSCF. 6.3.60 OC-Supported-Features The OC-Supported-Features AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[23]."
"This AVP is used to support Diameter overload control mechanism. 6.3.61 OC-OLR The OC-OLR AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[23]. This AVP is used to support Diameter overload control mechanism. 6.3.62 Initial-CSeq-Sequence-Number AVP The Initial-CSeq-Sequence-Number AVP is of type Unsigned32, and it contains the sequence number of the CSeq header field contained in the initial successful REGISTER request, as defined in IETFÊRFCÊ3261Ê[11]. 6.3.63 SAR-Flags The SAR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in the following table: Table 6.3.63.1: SAR-Flags Bit Name Description 0 P-CSCF Restoration Indication This bit, when set, indicates that the P-CSCF-Restoration-mechanism feature shall be executed, as described in 3GPPÊTSÊ23.380Ê[24], clauseÊ5.4. This AVP is optionally present only when Server-Assignment-Type takes the value ADMINISTRATIVE_DEREGISTRATION or UNREGISTERED_USER. Note: Bits not defined in this table shall be cleared by the sending S-CSCF and discarded by the receiving HSS. 6.3.64 Allowed-WAF-WWSF-Identities AVP The Allowed-WAF-WWSF-Identities AVP is of type Grouped and contains the addresses of the WAFs and WWSFs allowed for the subscription. AVP format Allowed-WAF-WWSF-Identities :: = < AVP Header : 656 10415 > *[ WebRTC-Authentication-Function-Name ] *[ WebRTC-Web-Server-Function-Name ] *[ AVP] 6.3.65 WebRTC-Authentication-Function-Name AVP The WebRTC-Authentication-Function-Name AVP is of type UTF8String and contains the address of a WAF allowed for the subscription. For the format of the string see IETF draft-holmberg-sipcore-auth-id-01Ê[25]. 6.3.66 WebRTC-Web-Server-Function-Name AVP The WebRTC-Web-Server-Function-Name AVP is of type UTF8String and contains the address of a WWSF allowed for the subscription. For the format of the string see IETF draft-holmberg-sipcore-auth-id-01Ê[25]. 6.3.67 DRMP AVP The DRMP AVP is of type Enumerated and it is defined in IETFÊRFCÊ7944Ê[26]. This AVP allows the HSS/SLF and the S-CSCF/I-CSCF to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message. 6.3.68 Load The Load AVP is of type Grouped and it is defined in IEFTÊRFCÊ8583Ê[27]. This AVP is used to support the Diameter load control mechanism. 6.3.69 RTR-Flags The RTR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.69.1. Table 6.3.69.1: RTR-Flags Bit Name Description 0 Reference Location Information change This bit, when set, indicates the request is sent due to change of Reference Location Information. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving I-CSCF. 6.3.70 P-CSCF-Subscription-Info AVP The P-CSCF-Subscription-Info AVP is of type Grouped and it contains the P-CSCF''s subscription information. The Contact AVP contains the Contact Address and Parameters in the Contact header of the subscription request. AVP format P-CSCF-Subscription-Info ::= < AVP Header: 660, 10415> { Call-ID-SIP-Header } { From-SIP-Header } { To-SIP-Header } { Contact } *[ AVP ] 6.3.71 Registration-Time-Out The Registration-Time-Out AVP is of type Time (see IETFÊRFCÊ6733Ê[28]), and contains the point of time at which the UE's registration expires. 6.3.72 Alternate-Digest-Algorithm AVP The Alternate-Digest-Algorithm AVP contains algorithm values specified in IETFÊRFCÊ7616Ê[29]. NOTE: The MD5 algorithm is only supported for backward compatibility and can only be provided within the Digest-Algorithm AVP. 6.3.73 Alternate-Digest-HA1 AVP The Alternate-Digest-HA1 AVP contains H(A1) value specified in IETFÊRFCÊ7616Ê[29]. 6.3.74 Failed-PCSCF The Failed-PCSCF AVP is of type Grouped and contains the FQDN and/or IP addresses of the failed P-CSCF. AVP format Failed-PCSCF ::= < AVP Header: 664, 10415> [ PCSCF-FQDN ] *[ PCSCF-IP-Address ] *[ AVP ] 6.3.75 PCSCF-FQDN The PCSCF-FQDN AVP is of type DiameterIdentity and contains the FQDN of the P-CSCF. 6.3.76 PCSCF-IP-Address The PCSCF-IP-Address AVP is of type Address and contains the IPv4 or IPv6 address of the P-CSCF. 6.4 Use of namespaces This clause contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA. 6.4.1 AVP codes This specification assigns the AVP values from the AVP Code namespace managed by 3GPP for its Diameter vendor-specific applications. See clauseÊ6.3 for the assignment of the namespace in this specification. 6.4.2 Experimental-Result-Code AVP values This specification has assigned Experimental-Result-Code AVP values 2001-2005 and 5001-5011. See clauseÊ6.2. 6.4.3 Command Code values This specification assigns the values 300-305 from the range allocated by IANA to 3GPP in IETFÊRFCÊ3589Ê[12]. 6.4.4 Application-ID value IANA has allocated the value 16777216 for the 3GPP Cx interface application. 7 Special Requirements 7.1 Version Control New functionality - i.e. functionality beyond the Rel-5 standard - shall be introduced by post-Rel-5 versions of this specification to the Diameter applications as follows: 1. If possible, the new functionality shall be defined optional. 2. If backwards incompatible changes can not be avoided, the new functionality should be introduced as a feature, see 7.1.1. 3. If the change would be backwards incompatible even as if it was defined as a feature, a new version of the interface shall be created by changing the application identifier of the Diameter application, see 7.1.2. 7.1.1 Defining a new feature The base functionality for the Cx is the 3GPP Rel-5 standard and a feature is an extension to that functionality. A feature is a functional entity that has a significant meaning to the operation of a Diameter application i.e. a single new parameter without a substantial meaning to the functionality of the Diameter endpoints should not be defined to be a new feature. If the support for a feature is defined mandatory in a post-Rel-5 versions of this specification, the feature concept enables interworking between Diameter endpoints regardless of whether they support all, some or none of the features of the application. Features should be defined so that they are independent from one another. The content of a feature shall be defined as a part of the specification of the affected application messages. If new AVPs are added to the commands because of the new feature, the new AVPs shall have the 'M' bit cleared and the AVP shall not be defined mandatory in the command ABNF. The support for a feature may be defined to be mandatory behaviour of a node. As an option to defining a feature, an extension to S-CSCF functionality for post-Rel-5 version may be defined as part of the list of mandatory capabilities that is used by the I-CSCF during the process of selecting an S-CSCF, as described in 3GPPÊTSÊ29.228Ê[1]. Any new feature should be taken into account in the definition of the list of mandatory and optional S-CSCF capabilities. Guidelines for the definition of S-CSCF Capabilities are described in 3GPPÊTSÊ29.228Ê[1]. The following table of features shall apply to the Cx interface. Table 7.1.1: Features of Feature-List-ID 1 used in Cx Feature bit Feature M/O Description 0 SiFC O Shared iFC sets This feature is applicable for the SAR/SAA and PPR/PPA command pairs. If both the HSS and the S-CSCF support this feature, subsets of Initial Filter Criteria may be shared by several service profiles and the HSS shall download the shared iFC sets implicitly by downloading the unique identifiers of the shared iFC sets to the S-CSCF. By means of a locally administered database, the S-CSCF then maps the downloaded identifiers onto the shared iFC sets. If the DSAI feature, as defined in 3GPPÊTSÊ29.328Ê[16], is also active with the shared iFC sets feature then the HSS shall behave as described below: If the DSAI feature is active with the shared iFC sets feature and if all the iFCs bounding to a Shared iFC set are not masked by the DSAI, the HSS shall download the unique identifier of the shared iFC set to the S-CSCF. If some iFCs or all the iFCs bounding to a shared iFC set are masked by the DSAI, the HSS shall not download the identifier of the shared iFC set. Instead the HSS shall - download the remaining non masked iFCs of the shared iFC set explicitly or - download suitable identifiers of other shared iFC sets, i.e. those covering exactly the remaining non masked iFCs and which do not contain masked iFCs or - download a combination of identifiers of shared iFC sets and explicit iFCs which cover exactly the remaining non masked iFCs. If the S-CSCF does not support this feature, the HSS shall not download identifiers of shared iFC sets. Instead as a default behavior the HSS shall (by means of a locally administered database) download the iFCs of a shared iFC set explicitly. If the HSS does not support this feature, no special default behaviour is required for the S-CSCF. Note: In using this feature option, the network operator is responsible for keeping the local databases in the S-CSCFs and HSSs consistent. 1 AliasInd M Alias Indication This feature is applicable for the SAR/SAA and PPR/PPA command pairs. If both the HSS and the S-CSCF support this feature, different aliases groups may be sent within the same service profile. Identities within the same service profile that are aliases shall be sent with identical alias group ID. If the S-CSCF does not support this feature, the HSS shall send within the service profile only those identities that are aliases. Public User Identities that are not aliases of each other shall be sent in different service profiles even if these service profiles have exactly the same Core Network Service Authorization, Initial Filter Criteria, and Shared iFC Set information and these service profiles only differ in the contained Public User Identities. This is done in order to allow backwards compatibility since part of the handling of aliases in the S-CSCF was there before this indication was required and it applied to identities that share the same service profile and implicit registration set. In this case, the S-CSCF does not provide any additional treatment of aliases than that which existed before this indication was required. If the HSS does not support this feature, no special default behaviour is required for the S-CSCF. Note: All identities included in a single SAA or PPR command are always within one implicit registration set. 2 IMSRestorationInd O IMS Restoration Indication This feature is applicable for the UAR/UAA, LIR/LIA, SAR/SAA command pairs. If both the HSS and the I-CSCF support this feature, in case the S-CSCF currently assigned in the HSS to the Public User Identity cannot be contacted the I-CSCF shall trigger the assignment of a new S-CSCF. If both the HSS and the S-CSCF support this feature, the S-CSCF shall send S-CSCF Restoration Information to the HSS. The HSS shall send this information element in SAA to the S-CSCF when required. If the S-CSCF does not support this feature, the HSS shall not send the IMS Restoration Information to the S-CSCF. 3 P-CSCF-Restoration-mechanism O HSS-based P-CSCF Restoration mechanism. This feature is applicable for the SAR/SAA command pair. If both the HSS and the S-CSCF support this feature, the S-CSCF shall send the P-CSCF-Restoration-Indication in SAR-Flags AVP to the HSS when required as described by 3GPPÊTSÊ23.380Ê[24] clauseÊ5.4. If the HSS does not support this feature, the S-CSCF shall not send the P-CSCF-Restoration-Indication to HSS. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""MOM"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. The origin host may discover the supported features of the destination host with the dynamic discovery mechanism defined in 7.2 or via local O&M interfaces. 7.1.2 Changing the version of the interface The version of an interface shall be changed by a future version of this specification only if there is no technically feasible means to avoid backwards incompatible changes to the Diameter application, i.e. to the current version of the interface. However, if the incompatible changes can be capsulated within a feature, there is no need to change the version of the interface. The versioning of an interface shall be implemented by assigning a new application identifier for the interface. This procedure is in line with the Diameter base protocol (see IETFÊRFCÊ3588) which defines that if an incompatible change is made to a Diameter application, a new application identifier shall be assigned for the Diameter application. The following table shall apply to the Cx interface, column Application identifier lists the used application identifiers on Cx and 3GPP. Table 7.1.2: Application identifiers used in Cx Application identifier First applied 16777216 3GPP Rel-5 The origin host may discover which versions of an interface the destination host supports within the capabilities exchange (i.e. CER/CEA command), via the error messages defined in the clauseÊ7.3 or via local O&M interfaces. 7.2 Supported features Features that are not indicated in the Supported-Features AVPs within a given application message shall not be used to construct that message. A request application message shall always be compliant with the list of supported features indicated in the Supported-Features AVPs within the application message. If a feature does not have an effect on constructing an application message, the message is by definition compliant with the feature. If no features are indicated in the application message, no features - i.e. no extensions to Rel-5 - shall be used to construct the application message. An answer application message shall always indicate in the Supported-Features AVPs the complete set of features supported by the sender of the answer application message. An answer application message shall be compliant with the features commonly supported by the sender of the request and answer application messages. The sender of a request application message shall discover for a given application message pair which features a destination host supports as described in 7.2.1. The discovered features of one command pair may be applicable to other command pairs within the application. Different commands within an application may support a different set of features. After discovering the features a destination host supports for a given application message pair, the sender of the request application message may store the information on the supported features of the destination host and it may use the features the destination host supports to construct the subsequent request application messages sent to the destination host. 7.2.1 Dynamic discovery of supported features When sending a request application message to a destination host whose supported features the sender does not know, the request application message shall include the Supported-Features AVP containing the set of features required to process the request and generate the answer. An exception to this is where the origin host does not use any features to construct the request application message and it is not prepared to accept an answer application message which is constructed by making use of any features. For this exception the origin host need not include the Supported-Features AVP within the message. The Supported-Features AVP within a request application message shall always have the 'M' bit set and within an answer application message the AVP shall never have the 'M' bit set. An exception to this is where the origin host does not use any supported feature to construct the request application message but is prepared to accept an answer application message which is constructed by making use of supported features. For this exception it is optional for the origin host to set the 'M' bit of the Supported-Features AVP within the request application message. On receiving a request application message, the destination host shall do one of the following: - If it supports all features indicated in the Supported-Features AVPs within the request message, the answer application message shall include Supported-Features AVPs identifying the complete set of features that it supports. The Experimental-Result-Code AVP shall not be set to DIAMETER_ERROR_FEATURE_UNSUPPORTED. - If the request application message does not contain any Supported-Features AVPs, the answer application message shall include either Supported-Features AVPs identifying the complete set of features that it supports or, if it does not support any features, no Supported-Features AVPs shall be present. The Experimental-Result-Code AVP shall not be set to DIAMETER_ERROR_FEATURE_UNSUPPORTED. - If it does not support all the features indicated in the Supported-Features AVPs with the 'M' bit set, it shall return the answer application message with the Experimental-Result-Code AVP set to DIAMETER_ERROR_FEATURE_UNSUPPORTED and it shall include also Supported-Features AVPs containing lists of all features that it supports. - If it does not support Supported-Features AVP and it receives a request application message containing Supported-Features AVPs with the 'M' bit set, it will return the answer application message with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED and a Failed-AVP AVP containing at least one Supported-Features AVP as received in the request application message. If an answer application message is received with the Experimental-Result-Code AVP set to DIAMETER_ERROR_FEATURE_UNSUPPORTED or with the Result-Code AVP set to DIAMETER_AVP_UNSUPPORTED, the sender of the request application message may, based on the information in the received Supported-Features AVP or the lack of the AVP in the message, re-send the Diameter message containing only the common supported features. 7.3 Interface versions The sender of the request application message may discover which versions of an interface a destination host supports together with the capabilities exchange (i.e. CER/CEA command pair) and with error mechanisms defined to the application messages in 7.3.1. The sender of the request application message should store information on all versions of the interface the destination host supports. The sender of the request application message should use the latest common version of the application supported by the destination host to send the request. If the receiver of the request application message itself or the versions of the interface it supports are not yet known, the sender of the request application message should use the latest supported version of the interface of the Diameter peer (i.e. Diameter proxy, redirect or relay agent) discovered during the capabilities exchange. If the Diameter peer is a redirect or relay agent, which advertises the 0xffffffff as an application identifier, the sender of the request application message shall use its own latest supported version of the interface when initiating the request. 7.3.1 Discovery of supported interface versions When a Diameter agent receives a request application message and the Diameter agent doesn't find any upstream peer that would support the application identifier indicated in the request, the Diameter agent shall return the result code DIAMETER_UNABLE_TO_DELIVER and it may also return the list of the application identifiers, which are supported by the destination host of the request application message. The supported application identifiers are carried in the answer application message in the Supported-Applications grouped AVP. Message format for the answer application message (based on the RFC 3588, clauseÊ7.2) is as follows: <answer-message> ::= < Diameter Header: code, ERRÊ[PXY] > 0*1< Session-Id > { Origin-Host } { Origin-Realm } { Result-Code } [ Origin-State-Id ] [ Error-Reporting-Host ] [ Proxy-Info ] [ Supported-Applications ] *Ê[ AVP ] If the receiver of a request application message does not support the application identifier indicated in the message, it shall return the result code DIAMETER_APPLICATION_UNSUPPORTED and it may also return the list of all application identifiers it supports. The supported application identifiers are carried in the Supported-Applications grouped AVP. The error message format is as specified above. If an answer application message is received with Result-Code AVP set to DIAMETER_UNABLE_TO_DELIVER or Experimental-Result-Code AVP set to DIAMETER_APPLICATION_UNSUPPORTED and the message contains the Supported-Applications AVP, the receiver of the answer application message may select, based on the information in the Supported-Applications AVP, the latest common version of the interface with the destination host and re-send the Diameter message with a structure conforming to the ABNF of that release. Annex A (informative): Change history Date TSGÊ# TSG Doc. CR# Rev Cat Subject/Comment Out Jun 2002 CN#16 NP-020265 Version 2.0.0 approved at CN#16 5.0.0 Sep 2002 CN#17 NP-020449 001 - Add a reference to the new IETFÊRFCÊon SCTP checksum 5.1.0 Sep 2002 CN#17 NP-020449 003 - Wrong format of Charging Function Addresses 5.1.0 Sep 2002 CN#17 NP-020449 005 - Editorial mistake in the definition of command MAA 5.1.0 Dec 2002 CN#18 NP-020587 006 - Addition of User-Name AVP to SAA 5.2.0 Dec 2002 CN#18 NP-020587 007 - Editorial correction of SIP-Auth-Data-Item AVP definition 5.2.0 Dec 2002 CN#18 NP-020589 008 1 Clarification of REGISTRATION_AND_CAPABILITIES value 5.2.0 Dec 2002 CN#18 NP-020588 009 - Correction in charging information 5.2.0 Dec 2002 CN#18 NP-020590 010 1 Error handling in S-CSCF when receiving too much data 5.2.0 Mar 2003 CN#19 NP-030101 012 1 Update TS 29.229 after Diameter has become RFC 5.3.0 Mar 2003 CN#19 NP-030101 015 1 Clarification on Re-allocation of S-CSCF 5.3.0 Mar 2003 CN#19 NP-030101 018 1 Handling of non supported data in the S-CSCF when the profile is being updated. 5.3.0 Mar 2003 CN#19 NP-030101 014 - Correction to the values of User-Authorizatin-Type AVP 5.3.0 Mar 2003 CN#19 NP-030101 013 - Replacement of the NAS-Session-Key AVP 5.3.0 Jun 2003 CN#20 NP-030215 019 - Conditionality of User-Name AVP in Server-Assignment-Answer 5.4.0 Sep 2003 CN#21 NP-030383 022 1 Critical Correction on the PPR command code 5.5.0 Dec 2003 CN#22 NP-030500 021 1 The S-CSCF name needs to be checked always in MAR and SAR 5.6.0 Dec 2003 CN#22 NP-030500 027 - User-Authorization-Type 5.6.0 Dec 2003 CN#22 NP-030518 029 - Clarification of inclusion of elements in Charging Information 5.6.0 Dec 2003 CN#22 Application IDs and references updated 5.6.0 Mar 2004 CN#23 NP-040055 035 - Error for no identification in SAR command 6.0.0 Jun 2004 CN#24 NP-040215 037 1 Update of the charging addresses from HSS 6.1.0 Jun 2004 CN#24 NP-040215 043 - Multimedia-Auth-Request (MAR) Command Message Format Corrections 6.1.0 Jun 2004 CN#24 NP-040215 050 2 Use of Vendor-Id by 3GPP 6.1.0 Sep 2004 CN#25 NP-040395 065 2 Application version control 6.2.0 Sep 2004 CN#25 NP-040401 056 - Optimization of User Profile Download 6.2.0 Sep 2004 CN#25 NP-040396 058 - Simplification of the User Profile Split concept 6.2.0 Sep 2004 CN#25 NP-040401 061 - Correction of the Application-Id code 6.2.0 Sep 2004 CN#25 NP-040412 063 1 Re-numbering of 3GPP specific AVP codes 6.2.0 Dec 2004 CN#26 NP-040523 070 - Cx ABNF corrections 6.3.0 Mar 2005 CN#27 NP-050030 078 2 Correction of authentication-related AVPs 6.4.0 Mar 2005 CN#27 NP-050037 079 - TEL-URI reference update 6.4.0 Mar 2005 CN#27 NP-050030 082 1 Introduction of Failed-AVP 6.4.0 Jun 2005 CT#28 CP-050086 087 - Correction of reference 6.5.0 Jun 2005 CT#28 CP-050086 089 1 Editorial corrections 6.5.0 Jun 2005 CT#28 CP-050086 088 2 Corrections to message parameters 6.5.0 Sep 2005 CT#29 CP-050440 091 2 Private identities on the Cx 6.6.0 Sep 2005 CT#29 CP-050282 093 1 Charging-Information correction 6.6.0 Sep 2005 CT#29 CP-050296 094 - Error code cleanup 6.6.0 Dec 2005 CT#30 CP-050611 095 1 Removal of overhead in Private Identities handling in RTR 6.7.0 Dec 2005 CT#30 CP-050611 098 1 Incorrect Definition of Supported-Applications AVP 6.7.0 Jan 2006 Rel-7 version was created because of ETSI TISPAN references. 7.0.0 Mar 2006 CT#31 CP-060084 0099 - Supported Features Text missing 7.1.0 Jun 2006 CT#32 CP-060302 0108 - S-CSCF reselection removal 7.2.0 Jun 2006 CT#32 CP-060308 0110 3 Definition of new Feature for Cx 7.2.0 Sep 2006 CT#33 CP-060417 0114 3 AS originating requests on behalf of a user 7.3.0 Sep 2006 CT#33 CP-060405 0118 2 Correction of discovery of supported features in Sh and Cx 7.3.0 Sep 2006 CT#33 CP-060417 0119 1 Sharing feature support information between command pairs 7.3.0 Dec 2006 CT#34 CP-060566 0124 1 Optimization of handling of Wildcarded PSIs 7.4.0 Mar 2007 CT#35 CP-070020 0125 1 M-bit in SupportedFeatures AVP 7.5.0 Sep 2007 CT#37 CP-070520 0129 - Misalignment of Mandatory Items in the MAR 7.6.0 Nov 2007 CT#38 CP-070744 0132 6 Add alias as a new feature 7.7.0 Nov 2007 CT#38 CP-070755 0130 4 Updates to 29.229 for Digest on the Cx interface 8.0.0 Mar 2008 CT#39 CP-080022 0138 2 Update 29.229 for Supporting NASS-Bundled-Authentication 8.1.0 Mar 2008 CT#39 CP-080019 0139 - SIP Digest password push 8.1.0 Mar 2008 CT#39 CP-080019 0141 2 Wildcarded Public User Identities 8.1.0 Jun 2008 CT#40 CP-080261 0145 1 Correction to the behavior of the HSS defined in the SiFC feature 8.2.0 Jun 2008 CT#40 CP-080261 0146 2 Realm and Host to be used for Charging 8.2.0 Sep 2008 CT#41 CP-080456 0149 1 Emergency Public User Identity Removal 8.3.0 Sep 2008 CT#41 CP-080460 0155 1 Support of ""Loose-Route"" indication from HSS 8.3.0 Sep 2008 CT#41 CP-080463 0156 1 Cx Impacts of IMS Restoration Procedures 8.3.0 Sep 2008 CT#41 CP-080463 0158 Add IMS Restoration as a new feature 8.3.0 Sep 2008 CT#41 CP-080463 0159 1 Addition of Registered Private Identities in SAA 8.3.0 Sep 2008 CT#41 CP-080460 0160 1 Add Assigned S-CSCF name to SAA 8.3.0 Dec 2008 CT#42 CP-080708 0163 Removal of Digest Domain 8.4.0 Dec 2008 CT#42 CP-080708 0166 2 Diameter Proxy Agent - an alternative User Identity to HSS resolution mechanism 8.4.0 Mar 2009 CT#43 CP-090026 0167 Multiple Registrations in Registration 8.5.0 Mar 2009 CT#43 CP-090026 0168 1 Restoration Information for Multiple Registrations 8.5.0 Mar 2009 CT#43 CP-090026 0169 Update for Restoration 8.5.0 Mar 2009 CT#43 CP-090051 0170 1 Definition of Server-Assignment-Type values in Cx 8.5.0 Mar 2009 CT#43 CP-090028 0171 Support for GPRS IMS Bundled Authentication (GIBA) in Cx 8.5.0 Mar 2009 CT#43 CP-090025 0172 Use of canonical form for SIP URI/tel URI in Cx interface 8.5.0 Mar 2009 CT#43 CP-090026 0175 1 Comma separated list for Path, Contact and Record-Route AVPs 8.5.0 Jun 2009 CT#44 CP-090484 0176 2 Contact storage in reg event subscription 8.6.0 Jun 2009 CT#44 CP-090303 0177 1 Comma separated list for path AVP 8.6.0 Sep CT#45 CP-090526 0181 Dx over SCTP 8.7.0 Dec 2009 CT#46 CP-090784 0182 2 SIP Digest AVP Flag Settings 8.8.0 Dec 2009 CT#46 CP-090781 0185 1 Unregistered user clarification 8.8.0 Dec 2009 CT#46 CP-090778 0188 2 Session-Priority AVP 8.8.0 Dec 2009 CT#46 CP-091030 0189 Validity of Feature Bit Value in Feature-List AVP 8.8.0 Dec 2009 CT#46 Upgraded unchanged from Rel-8 9.0.0 Mar 2010 CT#47 CP-100239 0195 1 Wildcarded Public Identity 9.1.0 Mar 2010 CT#47 CP-100031 0199 Wildcarded Public Identities handling 9.1.0 Jun 2010 CT#48 CP-100412 0205 1 Digest AVPs wrongly defined 9.2.0 Sep 2010 CT#49 CP-100447 0207 2 Wildcarded Identities handling 9.3.0 Sep 2010 CT#49 CP-100442 0209 2 Mandatory and optional capabilities handling 9.3.0 Sep 2010 CT#49 CP-100442 0212 Reference to SCTP IETFÊRFCÊobsolete 9.3.0 Sep 2010 CT#49 CP-100463 0213 2 Restoration Data Backup 9.3.0 Sep 2010 CT#49 CP-100447 0216 Encoding of Framed-IPv6-Prefix AVP 9.3.0 2011-03 - - - - Update to Rel-10 version (MCC) 10.0.0 Jun 2011 CT#52 CP-110349 0224 2 Handling of RTR for Emergency Registration 10.1.0 Jun 2011 CT#52 CP-110349 0227 Error in assignment type for backward compatibility scenarios 10.1.0 Jun 2011 CT#52 CP-110349 0230 User-Authorization-Type AVP error in description 10.1.0 Sep 2011 CT#53 CP-110566 0233 1 Priviledged sender 10.2.0 Dec 2011 CT#54 CP-110781 0240 1 Restoration of Wildcarded-IMPU AVP 10.3.0 Dec 2011 CT#54 CP-110812 0235 2 Server Assignment Type AVP definition 11.0.0 Sep 2012 CT#57 CP-120440 0247 1 Emergency registrations do not affect registration status 11.1.0 Dec 2012 CT#58 CP-120743 0251 2 PSI direct routing with restoration procedures 11.2.0 Mar 2013 CT#59 CP-130011 0258 1 Originating-request AVP in LIR 11.3.0 Jun 2013 CT#60 CP-130374 0260 1 Supported-Feature AVP carries list of features specific to the Application-ID 11.4.0 Jun 2013 CT#60 CP-130380 0259 - Visited Network ID coding 12.0.0 Dec 2013 CT#62 CP-130627 0263 1 Session-Priority AVP 12.1.0 Jun 2014 CT#64 CP-140243 0264 2 Diameter Overload Control Over Cx 12.2.0 Sep 2014 CT#65 CP-140515 0265 1 T-GRUU restoration 12.3.0 Sep 2014 CT#65 CP-140506 0266 2 P-CSCF Restoration indication 12.3.0 Dec 2014 CT#66 CP-140794 0268 2 P-CSCF Restoration mechanism new feature 12.4.0 Dec 2014 CT#66 CP-140794 0270 1 P-CSCF Restoration mechanism new error 12.4.0 Dec 2014 CT#66 CP-140773 0269 - M-bit clarification 12.4.0 Mar 2015 CT#67 CP-150023 0273 1 SIP-Authentication-Scheme AVP encoding 12.5.0 Jun 2015 CT#68 CP-150261 0274 - SAR-Flags inclusion in SAR command 12.6.0 Sep 2015 CT#69 CP-150428 0276 1 SIP-Auth-Data-Item sub AVPs clarifications 12.7.0 Sep 2015 CT#69 CP-150436 0275 1 Server-Assignment-Type AVP update to consider P-CSCF Restoration 12.7.0 Dec 2015 CT#70 CP-150754 0279 2 Allowed WAF and/or WWSF Identities 12.8.0 Dec 2015 CT#70 CP-150759 0281 1 Update reference to DOIC new IETF RFC 12.8.0 Dec 2015 CT#70 CP-150768 0282 2 Support of the DRMP AVP over Cx/Dx 13.0.0 2016-12 CT#74 CP-160664 0284 1 Correction to change IETF drmp draft version to official RFC 7944 13.1.0 2016-12 CT#74 CP-160681 0283 1 Load Control 14.0.0 2017-03 CT#75 CP-170048 0285 1 Update of reference for the Diameter base protocol 14.1.0 2017-03 CT#75 CP-170048 0286 - Cardinality of the Failed-AVP AVP in answer 14.1.0 2017-06 CT#76 CP-171018 0288 1 Support for signaling transport level packet marking 14.2.0 2018-06 CT#80 - - - Update to Rel-15 version (MCC) 15.0.0 2019-03 CT#83 CP-190035 0289 1 Reference Location Information change 15.1.0 2019-09 CT#85 CP-192094 0293 2 draft-ietf-dime-load published as RFC 8583 15.2.0 2019-09 CT#85 CP-192125 0291 - Add P-CSCF subscription info to Restoration information 16.0.0 2019-12 CT#86 CP-193040 0294 - S-CSCF restoration after registration timer expiry 16.1.0 2020-06 CT#88e CP-201053 0295 - Support of PCRF-based P-CSCF restoration 16.2.0 2021-12 CT#94e CP-213104 0297 - B Update of SIP Digest Access Authentication 17.0.0 2022-03 CT#95e CP-220052 0300 - F Reference identity for RFC 7616 17.1.0 2022-03 CT#95e CP-220052 0301 2 B Support of the hash value for alternate SIP Digest algorithm 17.1.0 2022-03 CT#95e CP-220054 0298 - B Failed P-CSCF 17.1.0 2022-06 CT#96 CP-221041 0303 - F IMS authentication using AKAv2-SHA-256 digest AKA algorithm 17.2.0 3GPP TS 29.229 V17.2.0 (2022-06) 14 Release 17 3GPP ................. 7...................... 7.......................... 8.......... 9 eoTCAP Format 7 Reference Manual MC versions: 8.0.1 Last update: 2021-06-25 Document revision: 8.0 Revision History Revision Last update Description 1.0 2019-02-06 This Format Reference Manual released for eoTCAP format 7.0. 2.0 2019-04-03 Updated filling Rule of the following fields: - Data Record Type (#111, #113), section 5.2.1.4 Common - Data Record Type - MAP Ð Number of MO SMS, section 5.2.8.2 - MAP Ð MO SMS Success, section 5.2.8.3 - MAP Ð Number of MT SMS, section 5.2.8.4 - MAP Ð MT SMS Success, section 5.2.8.5 Updated filling rule of the fields #111 and #113 in Data Record Type, section 5.2.1.4 Common - Data Record Type 3.0 2019-08-07 Removed filling rules for field description. Updated sections: á5 DR File Structure á5.2.5 CAP Fields áAdded Operator Country Code in section 6.3OperatorE212 6.1 CellAdded section 4 DR File Exchange protocol 4.0 2019-10-25 Description improved for the Common - Success field. 5.0 2020-01-08 Updated sections 3.1.1.8 Common - First Leg Destination Point Code, 3.1.1.17 Common Ð Last Leg Originating Point Code and 3.1.1.18 Common - Last Leg Destination Point Code. ÒMCLS TableÓ column added at Chapter 3 DR Format. 6.0 2020-10-22 Added the following generations to sect. 2.2 List of Generations: - eoTCAP-CAP-DeDup - eoTCAP-INAP-DeDup Updated table in sect. 4.1 Cell Updated sect. 3.2.7.1 Common Ð Success 7.0 2020-11-18 Updated MCLS Cell table in section 4.1 Cell. 8.0 2021-06-25 Updated sections: á 3.2.7.6 Common - Length of SCCP FWD Messages á 3.2.7.7 Common - Length of SCCP BWD Messages á 3.2.7.10 Common - Number of SCCP BWD Messages á 3.2.8.2 MAP Ð Number of MO SMS á 3.2.8.3 MAP Ð MO SMS Success á 3.2.8.4 MAP - Number of MT SMS á 3.2.8.5 MAP Ð MT SMS Success ©2021 Anritsu. All Rights Reserved. Specifications subject to change without notice. Table of Contents ..................................................................................................... 6 1 Introduction ................................................................................................................ 6 List of compatible FIDs Differences with respect to previous eoTCAP 6.0 version References 2 eoTCAP DR Content ..................................................................................................... 8 Scenario List of Generations 2.2.1 eoTCAP-CAP ...................................................................................................................................... 9 2.2.2 eoTCAP-CAP-DeDup ........................................................................................................................ 10 2.2.3 eoTCAP-MAP................................................................................................................................... 10 2.2.4 eoTCAP-INAP .................................................................................................................................. 10 2.2.5 eoTCAP-INAP-DeDup ...................................................................................................................... 11 2.2.6 eoTCAP-AP ...................................................................................................................................... 11 2.2.7 eoTCAP-OP ...................................................................................................................................... 11 2.2.8 eoTCAP-BELL-800 ............................................................................................................................ 11 2.2.9 eoTCAP-BELL-AIN ............................................................................................................................ 11 2.2.10 eoTCAP-BELL-LIDB .......................................................................................................................... 11 2.2.11 eoTCAP-MAP-E2E-SMS ................................................................................................................... 11 DR File Structure ........................................................................................................ 13 DR Format ..................................................................................................................... 13 eoTCAP DR Fields Description ........................................................................................ 41 Common Fields ............................................................................................................................... 41 WHITE TCAP Fields .......................................................................................................................... 81 BELL TCAP Fields ........................................................................................................................... 102 MAP Fields .................................................................................................................................... 110 CAP Fields ..................................................................................................................................... 122 INAP Fields .................................................................................................................................... 139 Common Measures ...................................................................................................................... 157 MAP Measures ............................................................................................................................. 170 4 MCLS Enrichments for eoLive .................................................................................. 173 Cell .............................................................................................................................. 173 Service Key .................................................................................................................. 175 Cause .......................................................................................................................... 175 OperatorE212 .............................................................................................................. 177 Device ......................................................................................................................... 180 CertifiedDevice ............................................................................................................ 181 MobileSubscriber ........................................................................................................ 182 FixedSubscriber ........................................................................................................... 183 Operator Prefix............................................................................................................ 185 IMSIPrefix .................................................................................................................... 186 ISDNPrefix ................................................................................................................... 187 Operator Signalling Point ............................................................................................. 188 5 Monitored procedures ............................................................................................ 190 6 Appendix A. Property field definition ...................................................................... 196 Binary Formats ............................................................................................................ 196 Display Format ............................................................................................................ 196 Text Format ................................................................................................................. 197 Special Property .......................................................................................................... 198 Aggregation Roles ....................................................................................................... 199 1 Introduction This document specifies the eoTCAP TDR File Structure v.7.0 generated by eoXDR server for MasterClaw eoLive, eoSearch, and eoFinder Application. This specification is based on: - MAP_CSDR on any compatible FID. MAP protocol stack is widely used in the world except in USA. - CAP_CSDR on any compatible FID. CAMEL protocol stack is widely used in the world except in USA. - INAP_CSDR on any compatible FID. - TCAP-AP_CSDR on any compatible FID. - BELL_TCAP_OP on any compatible FID. - BELL_TCAP_800 on any compatible FID. - BELL_AIN on any compatible FID. - BELL_LIDB on any compatible FID. List of compatible FIDs CSDR Format Name FID (Value) Protocol Layer CAP_CSDR_FID_693 693 CAP/CAMEL CAP_CSDR_FID_645 645 CAP/CAMEL MAP_CSDR_FID_629 629 MAP INAP_CSDR_FID_694 694 INAP INAP_CSDR_FID_646 646 INAP TCAP-AP_CSDR_FID_630 630 TCAP-AP BELLCORE_TCAP_OP_CSDR_FID_548 548 TCAP-OP BELL_TCAP_800_CSDR_FID_563 563 BELL_TCAP_800 BELLAIN_CSDR_FID_564 564 BELL_AIN BELLCORE_LIDB_CSDR_FID_567 567 BELL_LIDB Differences with respect to previous eoTCAP 6.0 version New fields Common Ð VLR Number Normalization Added field to normalize: Common Ð VLR Number Modified Fields INAP Ð Additional Error Reason (Modified Display Format) New eoTCAP DWH Dimensions VLR NUMBER References CAP_CSDR_693 CAP_CSDR_645 MAP_CSDR_FID_629 INAP_CSDR_FID_694 INAP_CSDR_FID_646 WHITE_TCAP_AP_CSDR_630 BELLCORE_TCAP_OP_CSDR_FID_548 BELL_TCAP_800_CSDR_FID_563 BELLAIN_CSDR_FID_564 BELLCORE_LIDB_CSDR_FID_567 2 eoTCAP DR Content Scenario This section provides a high level description of the DR content in terms of: á Monitored network á Monitored procedure/call/transaction Monitored Network Data is collected from links surrounding the various service elements (SCP etc.) or interconnect links. The services supported in this application are LNP, MNP LIDB, CLASS, TCAP operations, LIDB, IS41, CAP and MAP. Each stored transaction record (TDR) contains data from the lower SCCP protocol layer, the TCAP layer, and some information from the upper service application layer. Two protocol stacks are supported: - CAP/MAP/INAP (over TCAP/SCCP). - TCAP-OP (LNP, MNP LIDB, CLASS, TCAP operations, LIDB, IS41 (over TCAP/SCCP)). - TCAP-AP Monitored procedure/call/transaction The DR provides signalling data from the TCAP protocol focusing on the following procedures: á Voice Call Send Authentication Info Send Routing Info ÔandÕ Provide Roaming Number Mobile Originating Call Mobile Terminating Call á Location Update Location Cancel Location Send Routing Info For LCS Subscriber Location Report á Data Session Update GPRS Location Send Routing Info For GPRS MS Initiated PDP Context Activation NW Initiated PDP Context Activation á Short Message services Send Routing Info For SM Mobile Originating SMS Mobile Terminating SMS E2E SMS á Supplementary Services Register SS Erase SS Activate SS Deactivate SS Interrogate SS Process Unstructured SS Request Unstructured SS Request Unstructured SS Notify á INAP Services List of Generations 2.2.1 eoTCAP-CAP This generation produces data record related to CAP transactions with a one to one relation to the incoming CAP CSDRs (no correlation rules are defined). In case of MEGACSDR option enabled, the information about first and last leg will be filled in the data record. 2.2.2 eoTCAP-CAP-DeDup This generation performs a deduplication process on incoming CAP MEGACSDRs and produces a data record for each leg of the CAP transaction. The MEGACSDR option in CAP must be active in order to produce consistent results. Note: The deduplication process is intended to split only the MEGACSDR into single legs, no need to remove duplicated legs because of the following assumption: If SIGTRAN/TDM linksets around STPs are monitored on different probes, that traffic must be redirected to single probe. 2.2.3 eoTCAP-MAP This generation perform a correlation of MAP CSDRs in order to obtain a single data record with information about the first and last leg of the MAP transaction. This generation could be run: 1. On customer operator internal links only. á If routing is SPC (Signalling Point Code) based, the correlation rule is based on OTID/ LABEL_OPC and DTID /LABEL_DPC (as second look-up). á If routing is Global Title based, then the correlation rule is based on it (see option 2 below). 2. On inter-operator/international links only. OTID, GTCALLING_NO and DTID, BACKCLG_NO (as second look-up). Second look-up is applied as additional rule at same time together with 1st rule. Example, for case 1 two CSDR A and B will be correlated if: OTID/ LABEL_OPC: A.OTID=B.OTID e A.LABEL_OPC= B.LABEL_OPC Or with second lookup DTID /LABEL_DPC: A.OTID=B.DTID e A.LABEL_OPC= B.LABEL_DPC 2.2.4 eoTCAP-INAP This generation produces data record related to INAP transactions with a one to one relation to the incoming INAP CSDRs (no correlation rules are defined). In case of MEGACSDR option enabled, the information about first and last leg will be filled in the data record. 2.2.5 eoTCAP-INAP-DeDup This generation performs a deduplication process on incoming INAP MEGACSDRs and produces a data record for each leg of the INAP transaction. The MEGACSDR option in INAP must be active in order to produce consistent results."
"Note: The deduplication process is intended to split only the MEGACSDR into single legs, no need to remove duplicated legs because of the following assumption: If SIGTRAN/TDM linksets around STPs are monitored on different probes, that traffic must be redirected to single probe. 2.2.6 eoTCAP-AP This generation produces data record related to TCAP_AP transactions with a one to one relation to the incoming TCAP_AP CSDRs (no correlation rules are defined). 2.2.7 eoTCAP-OP This generation produces data record related to TCAP_OP transactions with a one to one relation to the incoming TCAP_OP CSDRs (no correlation rules are defined). 2.2.8 eoTCAP-BELL-800 This generation produces data record related to BELL_TCAP_800 transactions with a one to one relation to the incoming BELL_TCAP_800 CSDRs (no correlation rules are defined). 2.2.9 eoTCAP-BELL-AIN This generation produces data record related to BELL_AIN transactions with a one to one relation to the incoming BELL_AIN CSDRs (no correlation rules are defined). 2.2.10 eoTCAP-BELL-LIDB This generation produces data record related to BELL_LIDB transactions with a one to one relation to the incoming BELL_ LIDB CSDRs (no correlation rules are defined). 2.2.11 eoTCAP-MAP-E2E-SMS This generation performs a correlation of MAP CSDRs in order to obtain a single data record for an end to end SMS scenario (SMS submit + SMS Delivery) CSDR Filters: The First Dialogue can be any MAP Dialogue with TP_MTI=1 (SMS-SUBMIT) Correlation Keys: [First Dialogue].MSISDN=[Second Dialogue].TP_OA [First Dialogue].PAYLOAD_SZ=[Second Dialogue].PAYLOAD_SZ Time Constraints: Start Time (First Dialogue) < Start time (Second Dialogue) <= 5 minutes (First Dialogue) DR File Structure A eoTCAP DR File contains a list of eoTCAP Transaction Data Records within a time interval [start time, end time). The date and time fields of eoTCAP TDRs within the file refers to the completion time of the transaction and it is always in the interval [start time, end time). eoTCAP TDRs in the file are not ordered w.r.t any of the fields. The file format stores Data Records in a proprietary binary format. DR Format # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path COMMON FIELDS 1 Start_Date_and_time Common - Start Time BF_INTEGER 8 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Measures/Common 2 End_Date_and_time Common - End Time BF_INTEGER 8 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Measures/Common 3 LAYER_TYPE Common Ð DR Generation Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 4 DATA_RECORD_TYPE Common - Data Record Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 5 VIOLATION Common Ð Violation BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 6 TIMEOUT Common Ð Timeout BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 7 LABEL_OPC Common Ð First Leg Originating Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 8 LABEL_DPC Common - First Leg Destination Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 9 SOURCE_IP Common - First Leg Source IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 10 DESTINATION_IP Common - First Leg Destination IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 11 SOURCE_SWITCH Common - First Leg Source Network Node BF_STRING 80 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 12 SOURCE_SWITCH_ROLE Common - First Leg Source Network Node Type BF_STRING 30 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 13 DEST_SWITCH Common - First Leg Destination Network Node BF_STRING 80 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common 14 DEST_SWITCH_ROLE Common - First Leg Destination Network Node Type BF_STRING 30 DF_STRING Network AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 15 SOURCE_SP Common - First Leg Source Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 16 DEST_SP Common - First Leg Destination Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 17 LL_LABEL_OPC Common Ð Last Leg Originating Point Code BF_INTEGER 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 18 LL_LABEL_DPC Common - Last Leg Destination Point Code BF_INTEGER 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 19 LL_SOURCE_IP Common Ð Last Leg Source IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 20 LL_DESTINATION_IP Common Ð Last Leg Destination IP Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 21 LL_SOURCE_SWITCH Common - Last Leg Source Network Node BF_STRING 80 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 22 LL_SOURCE_SWITCH_ROLE Common Ð Last Leg Source Network Node Type BF_STRING 30 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 23 LL_DEST_SWITCH Common Ð Last Leg Destination Network Node BF_STRING 80 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 24 LL_DEST_SWITCH_ROLE Common Ð Last Leg Destination Network Node Type BF_STRING 30 DF_STRING Network Switch AR_AGGREGABLE_ALWAYS Objects/Common 25 LL_SOURCE_SP Common Ð Last Leg Source Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 26 LL_DEST_SP Common - Last Leg Destination Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 27 CALLING_NO Common - Calling Party Number BF_STRING 22 DF_DIGITS FixedSubscriber, OperatorPrefix, ISDNPrefix FixedSubscriber, OperatorPrefix, ISDNPrefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 28 CALLED_NO Common - Called Party Number BF_STRING 22 DF_DIGITS FixedSubscriber, OperatorPrefix, ISDNPrefix FixedSubscriber, OperatorPrefix, ISDNPrefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 29 PAYMENT_PLAN Common - Payment Plan BF_INTEGER 1 DF_DEC_ENUM MobileSubscriber Payment Plan AR_AGGREGABLE_ALWAYS Objects/Common 30 LINKSET_NAME Common Ð First Leg Forward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 31 LINKSET_NAME_BACKWARD Common - First Leg Backward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 32 LL_LINKSET_NAME Common - Last Leg Forward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common 33 LL_LINKSET_NAME_BACKWARD Common - Last Leg Backward Linkset Name BF_STRING 80 DF_STRING Linkset AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 34 OTID Common Ð OTID BF_INTEGER 4 DF_HEX AR_AGGREGABLE_NEVER Objects/Common 35 DTID Common Ð DTID BF_INTEGER 4 DF_HEX AR_AGGREGABLE_NEVER Objects/Common 36 BACKCLG_NO Common - SCCP Back Calling Number BF_STRING 22 DF_DIGITS AR_AGGREGABLE_WITHFILTER Objects/Common 37 SCCP_CALLED_PARTY Common - SCCP Called Party Global Title BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/Common 38 SCCP_CALLING_PARTY Common - SCCP Calling Party Global Title BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 39 CALLED_SSN Common - Called SSN BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 40 CALLING_SSN Common - Calling SSN BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 41 SCCP_RETCAUSE Common - SCCP Return Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/Common 42 TCAP_ABORT_CAUSE Common - TCAP Abort Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/Common 43 SIO Common - Service Information Octet BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/Common 44 SERVICE_KEY Common - Service Key BF_STRING 4 BF_STRING ServiceKey ServiceKey AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 45 CONV_TIME_INT Common Ð Conversation Time Interval BF_STRING 64 DF_STRING Conversation Time Interval Conversation Time Interval AR_AGGREGABLE_ALWAYS Objects/Common 46 IMSI Common Ð IMSI BF_STRING 16 DF_DIGITS MobileSubscriber, OperatorE212, IMSIPrefix Mobile Subscriber, Operator E212, IMSI Prefix SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 47 MSISDN Common Ð MSISDN BF_STRING 22 DF_DIGITS OperatorPrefix,FixedSubscriber OperatorPrefix,FixedSubscriber SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 48 IMEI Common Ð IMEI BF_STRING 16 DF_DIGITS CertifiedDevice Certified Device SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common 49 TAC Common - Device TAC BF_STRING 8 DF_DIGITS Device Device SP_NUMBER AR_AGGREGABLE_WITHFILTER Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 50 LOCATION_INFO Common - Location Information BF_STRING 20 DF_DIGITS OperatorPrefix Location Info, OperatorPrefix AR_AGGREGABLE_ALWAYS Objects/Common 51 PLMN_ID Common Ð PLMN ID BF_STRING 6 DF_STRING Operator E212 AR_AGGREGABLE_WITHRANK Objects/Common 52 SCCP_CALLING_OPC Common Ð SCCP Calling Party Number Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 53 SCCP_CALLING_SP Common Ð SCCP Calling Party Number Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 54 SCCP_CALLED_OPC Common Ð SCCP Terminating Party Number Point Code BF_STRING 91 DF_FULLYQUALIFIED_POINT_CODE SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/Common 55 SCCP_CALLED_SP Common Ð SCCP Called Party Number Signalling Point BF_STRING 80 DF_STRING OperatorSP Signalling Point AR_AGGREGABLE_ALWAYS Objects/Common 56 VLR_NUMBER Common Ð VLR Number BF_STRING 22 DF_DIGITS VLR Number AR_AGGREGABLE_ALWAYS Object/Common WHITE TCAP FIELDS 101 TCAPAP_APPL_OP_CODE WHITE TCAP - Application Operation Code BF_INTEGER 2 DF_HEX_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/WHITE TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 102 TCAPAP_APPL_ERROR_CODE WHITE TCAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/WHITE TCAP BELL TCAP FIELDS 150 BTCAP_OPERATION_CODE BELL TCAP - Application Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 151 BTCAP_LAST_OPERATION_CODE BELL TCAP - Last Application Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 152 BTCAP_APPL_ERROR_CODE BELL TCAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 153 BTCAP_REJECT_PROBLEM BELL TCAP Ð Reject Problem BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 154 BTCAP_TRANSLATION_TYPE BELL TCAP Ð Translation Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 155 BTCAP_GTT_REQUESTED BELL TCAP - GTT Requested BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 156 BTCAP_TCAP_800_TERMINATION_INDICATOR BELL TCAP Ð TCAP 800 Termination Indicator BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 157 BTCAP_AINT_ERROR_CAUSE BELL TCAP Ð AIN Error Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/BELL TCAP 158 BTCAP_TCAP_OP_LINE_SERVICE_TYPE BELL TCAP Ð TCAP OP Line Service Type BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 159 BTCAP_LIDB_SERVICE_OR_EQUIP_INDICATOR BELL TCAP Ð LIDB Service or Equipment Indicator BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/BELL TCAP MAP FIELDS 201 MAP_FL_OP_CODE MAP Ð First Leg Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 202 MAP_FL_ER_CODE MAP - First Leg Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 203 MAP_FL_USRERR_REASON MAP Ð First Leg Additional Error Reason BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 204 MAP_FL_TP_SCTS MAP Ð First Leg SMS Service Centre Time Stamp BF_INTEGER 4 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Objects/MAP 205 MAP_LL_OP_CODE MAP Ð Last Leg Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 206 MAP_LL_ER_CODE MAP - Last Leg Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 207 MAP_LL_USRERR_REASON MAP Ð Last Leg Additional Error Reason BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/MAP 208 MAP_LL_TP_SCTS MAP Ð Last Leg SMS Service Centre Time Stamp BF_INTEGER 4 DF_ABSOLUTE_TIME AR_AGGREGABLE_NEVER Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 209 MAP_TP_MR MAP Ð SMS Message Reference Number BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Objects/MAP 210 MAP_ABSENT_SUBSCRIBER_DIAG_SM MAP - GSM Absent Reason BF_INTEGER 4 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 211 MAP_MSRN MAP ÐMSRN BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/MAP 212 MAP_USSD_STR MAP - USSD String BF_STRING 128 DF_STRING SP_USSD AR_AGGREGABLE_WITHFILTER Objects/MAP 213 MAP_SERVCENT_ADDR MAP - Service Centre Address BF_STRING 22 DF_DIGITS OperatorPrefix OperatorPrefix AR_AGGREGABLE_WITHFILTER Objects/MAP 214 MAP_SGSN_ADDRESS MAP - SGSN Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 215 MAP_GGSN_ADDRESS MAP - GGSN Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 216 MAP_H_GMLC_ADDRESS MAP - Home GMLC Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 217 MAP_V_GMLC_ADDRESS MAP - Visited GMLC Address BF_BYTES 16 DF_IP SP_ENDPOINTDETAILS AR_AGGREGABLE_ALWAYS Objects/MAP 218 MAP_TP_OA_ALPHANUM MAP - TP Origination Address Alphanumeric BF_STRING 12 DF_STRING SMS Service SP_ ENDPOINTDETAILS AR_AGGREGABLE_WITHRANK Objects/MAP 219 MAP_TP_DA_ALPHANUM MAP - TP Destination Address Alphanumeric BF_STRING 12 DF_STRING SP_ ENDPOINTDETAILS AR_AGGREGABLE_WITHRANK Objects/MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 220 MAP_TP_MTI MAP Ð TP Message Type Indicator BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/MAP 221 MAP_SMS_DELIV_TIME_INT MAP Ð SMS Delivery Time Interval BF_STRING 64 DF_STRING SMSDeliveryTime Interval SMSDeliveryTime Interval AR_AGGREGABLE_ALWAYS Objects/MAP CAP FIELDS 301 CAP_OP_CODE CAP Ð Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 302 CAP_LAST_OPERATION CAP - Last Operation BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 303 CAP_OPERATION_MASK CAP - Operation Mask BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/CAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 304 CAP_ER_CODE CAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 305 CAP_ER_REASON CAP - Additional Error Reason BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 306 CAP_CAUSE CAP - Response Cause BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/CAP 307 CAP_DEST_ADDRESS CAP - Destination Routing Address BF_STRING 22 DF_DIGITS Destination Address AR_AGGREGABLE_WITHFILTER Objects/CAP 308 CAP_EVENT_REPORT_CAUSE CAP - Event Report Cause BF_INTEGER 1 DF_ENUM Cause cause AR_AGGREGABLE_ALWAYS Objects/CAP 309 CAP_EVENT_TYPE_MET CAP - Event Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 310 CAP_REPORTED_EVENT CAP - Reported Event BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/CAP 311 CAP_CELL_IDENTITY CAP Ð Cell Identity BF_STRING 30 DF_STRING Cell Cell AR_AGGREGABLE_WITHRANK Objects/CAP INAP FIELDS 401 INAP_OP_CODE INAP Ð Operation Code BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 402 INAP_LAST_OPERATION INAP - Last Operation BF_INTEGER 1 DF_DEC_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 403 INAP_OPERATION_MASK1 INAP - Operation Mask1 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 404 INAP_OPERATION_MASK2 INAP - Operation Mask2 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 405 INAP_OPERATION_MASK3 INAP - Operation Mask3 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 406 INAP_OPERATION_MASK4 INAP - Operation Mask4 BF_INTEGER 4 DF_BINARY_ENUM AR_AGGREGABLE_NEVER Objects/INAP 407 INAP_ER_CODE INAP - Application Error Code BF_INTEGER 1 DF_DEC_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP 408 INAP_ER_REASON INAP - Additional Error Reason BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP 409 INAP_CAUSE INAP - Response Cause BF_INTEGER 1 DF_ENUM Cause Cause AR_AGGREGABLE_ALWAYS Objects/INAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 410 INAP_DEST_ROUT_ADDRESS INAP - Destination Routing Address BF_STRING 22 DF_DIGITS Destination Address AR_AGGREGABLE_WITHFILTER Objects/INAP 411 INAP_EVENT_TYPE_MET INAP - Event Type BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 412 INAP_REPORTED_EVENT INAP - Reported Event BF_INTEGER 1 DF_ENUM automatic AR_AGGREGABLE_ALWAYS Objects/INAP 413 INAP_GENERIC_NUMBER INAP - Generic Number BF_STRING 22 DF_DIGITS ISDNPrefix ISDNPrefix AR_AGGREGABLE_WITHFILTER Objects/INAP COMMON MEASURES 501 SUCCESS Common - Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 502 TRANS_TIME Common - Transaction Duration BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 503 RESPONSE_TIME Common - Response Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 504 CONV_TIME Common Ð Conversation Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / Common 505 SCCP_MSGLEN Common - Total Length of SCCP Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 506 TX_SCCP_MSGLEN Common - Total Length of SCCP FWD Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 507 RX_SCCP_MSGLEN Common - Total Length of SCCP BWD Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 508 NUMOF_SCCPMSG Common - Number of SCCP Messages BF_INTEGER 2 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 509 NUMOF_TXSCCP_MSGS Common - Number of SCCP FWD Messages BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 510 NUMOF_RXSCCP_MSGS Common - Number of SCCP BWD Messages BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common 511 ANSWERED_CALL Common Ð Answered Call BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 512 DROPPED_CALL Common Ð Dropped Call BF_INTEGER 1 DF_DEC AR_AGGREGABLE_ALWAYS Measures / Common MAP MEASURES 601 MAP_PAYLOAD_SZ MAP - SMS Payload Size BF_INTEGER 2 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 602 MAP_NUMBER_OF_MO_SMS_MESSAGES MAP Ð Number of MO SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 603 MAP_MO_SMS_SUCC MAP Ð MO SMS Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / MAP 604 MAP_NUMBER_OF_MT_SMS_MESSAGES MAP - Number of MT SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP # Name (internal) Description (visible to the user) Binary Format Size Display Format MCLS Table DWH Dimension Security eoLive Aggregation Role Field Path 605 MAP_MT_SMS_SUCC MAP Ð MT SMS Success BF_INTEGER 1 DF_BOOLEAN AR_AGGREGABLE_ALWAYS Measures / MAP 606 MAP_NO_CONCA_SMS MAP - Number of Concatenated SMS BF_INTEGER 1 DF_DEC AR_AGGREGABLE_NEVER Measures / MAP 607 MAP_SMS_SUBMIT_TIME MAP Ð SMS Submit Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / MAP 608 MAP_SMS_DELIV_TIME MAP Ð SMS Delivery Time BF_INTEGER 4 DF_RELATIVE_TIME AR_AGGREGABLE_NEVER Measures / MAP SPECIAL FIELDS 705 Call Trace Jump N/A BF_STRING 184 N/A N/A N/A N/A TABLE 1 ATTRIBUTES OF EOTCAP TDR eoTCAP DR Fields Description Common Fields Common - Start Time Applicable Protocols: All This is the time stamp for start of the transaction. The time stamp is UTC time milli seconds since 1 Jan 1970 0:00. This field is computed using the StartTimeStmpSec and StartmsPart CSDR fields. Common - End Time Applicable Protocols: All This is the time stamp for completion of the transaction. The time stamp is UTC time milli seconds since 1 Jan 1970 0:00. Common Ð DR Generation Type Applicable Protocols: All This field is an enumerated one used to distinguish the signalling interface of the data record. It can assume the following values depending on the CSDR source: Value Exported Description 1. TCAP-AP 2. MAP 3. CAP 4. INAP 5. TCAP-OP 6. TCAP-800 Value Exported Description 7. AIN 8. LIDB 9. CAP Single Leg 10. INAP Single Leg Common - Data Record Type Applicable Protocols: All It indicates the type of procedure/activity done (or being done) by the user. CSDR Type = CAP Value Name Description 1 CAP Mobile Originating Call Mobile Originating Call 2 CAP Mobile Terminating Call Mobile Terminating Call 3 CAP Mobile Originating SMS Mobile Originating SMS 4 CAP Mobile Terminating SMS Mobile Terminating SMS 5 CAP MS Initiated PDP Context Activation MS Initiated PDP Context Activation 6 CAP NW Initiated PDP Context Activation NW Initiated PDP Context Activation 99 Other CAP procedure CSDR Type = MAP Value Name Description 100 MAP Update Location Location Update procedure is initiated by the VLR towards the HLR in order to update the subscriber location information related to the CS domain. 101 MAP Cancel Location Cancel Location procedure is initiated when the subscriber moves into another VLR area or into another PLMN. 102 MAP Provide Roaming Number MSC initiates this procedure when a mobile terminating call has to be routed towards a roamer subscriber visiting the network. 103 MAP Register SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to register data related to a supplementary service. The VLR will relay the message to the HLR. 104 MAP Erase SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a supplementary procedure. The VLR will relay the message to the HLR. 105 MAP Activate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to activate a supplementary procedure. The VLR will relay the message to the HLR. 106 MAP Deactivate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to deactivate a supplementary procedure. The VLR will relay the message to the HLR. 107 MAP Interrogate SS This procedure is used between the MSC and the VLR and between the VLR and the HLR to retrieve information related to a supplementary procedure. The VLR Value Name Description will relay the message to the HLR if necessary. 108 MAP Send Routing Info Send Routing Info procedure is initiated by the MSC/VLR towards the HLR to retrieve subscriber information related to the CS domain. 109 MAP Update GPRS Location Update GPRS Location procedure is initiated by the SGSN/VLR towards the HLR in order to update the subscriber location information related to the PS domain. 110 MAP Send Routing Info For GPRS Send Routing Info For GPRS procedure is initiated by the GGSN towards the HLR to retrieve subscriber information related to the PS domain. 111 MAP Mobile Terminating SMS Mobile Terminating SMS 112 MAP Send Routing Info For SM Send Routing Info For SM procedure is initiated by the Gateway MSC towards the HLR to retrieve information needed for routing the short message to the servicing MSC. 113 MAP Mobile Originating SMS Mobile Originating SMS 114 MAP Authentication VLR may initiate the Authentication procedure (Send Authentication Info). It is used to ensure security and deny services to unauthorized services. This procedure can be done periodically. 115 MAP Process Unstructured SS Request This procedure is used between the MSC and the VLR, between the VLR and the HLR, between the HLR and gsmSCF and between the HLR and HLR to relay information in order to allow unstructured supplementary service operation. Value Name Description 116 MAP Unstructured SS Request This procedure is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires information from the mobile user, in connection with unstructured supplementary service handling. 117 MAP Unstructured SS Notify This procedure is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires a notification to be sent to the mobile user, in connection with unstructured supplementary services handling. 118 MAP Send Routing Info For LCS Send Routing Info For LCS procedure is initiated by the GMLC towards the HLR to retrieve subscriber information related to the Location based Services. 119 MAP Subscriber Location Report Subscriber Location Report procedure is initiated by the SGSN/VLR towards the HLR to provide the GMLC the location of a subscriber. 120 MAP Ð Correlated SMS 199 Other MAP procedure CSDR Type = INAP Value Name Description 200 INAP Initial DP 201 INAP Retrieve/Assist Request Instructions 299 Other INAP procedure CSDR Type = TCAP-AP Value Name Description 300 TCAP-AP traffic CSDR Type =BELL TCAP-OP Value Name Description 400 TCAP OP Query (CNAM Service) CSDR Type = BELL TCAP-800 Value Name Description 500 TCAP 800 Query (Toll Free Call) CSDR Type = BELL TCAP-800 Value Name Description 600 AIN Query CSDR Type = BELL LIDB Value Name Description 700 LIDB Query Common Ð Violation Applicable Protocols: All It indicates if the sequence contains all messages or some error condition happened. Value Name 0 No Violation 1 Missing End or Response Message 2 Only Begin or Query Message 3 Only Continue or Conversation Message Common Ð Timeout Applicable Protocols: All Timeout identifies the type of timeout that occurred during processing of the signalling data. Note that timeout field does not refer to network timeouts but refer only to the timeouts used by the network monitoring system. Value Timeout Description CAP CSDR MAP CSDR INAP CSDR WHITE_TCAP_AP CSDR TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 0 No Timeout 0 0 0 0 0 0 0 0 1 Sequence Timeout 1 1 1 1 1 1 1 1 2 Short Call (Not used in CSR mode) 2 2 2 3 Long Call (Not used in CSR mode) 3 3 3 Value Timeout Description CAP CSDR MAP CSDR INAP CSDR WHITE_TCAP_AP CSDR TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 4 Out of Error State 4 4 4 5 User Timeout 5 5 5 6 More-To-Come Timeout 6 - 6 7 Short Timeout 7 6 - 8 SMS Short Timeout 8 - - 9 Medium Timeout 9 7 - 10 Long Timeout 10 9 11 Wait for End Abort Timeout 11 - - 16 Medium-Long Timeout - 8 - 17 Pre-arranged END Timeout - - 7 Common Ð First Leg Originating Point Code Applicable Protocols: All Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR LABEL_OPC Originating Point Code of transaction MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_AIN_CSDR BELL_LIDB_CSDR Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: LABEL_OPC LABEL_OPC_LEG_2 LABEL_OPC_LEG_3 LABEL_OPC_LEG_4 LABEL_OPC_LEG_5 LABEL_OPC_LEG_6 LABEL_OPC_LEG_7 LABEL_OPC_LEG_8 LABEL_OPC_LEG_9 LABEL_OPC_LEG_10 Common - First Leg Destination Point Code Applicable Protocols: All Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR LABEL_DPC Destination Point Code of transaction MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_AIN_CSDR BELL_LIDB_CSDR Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: LABEL_DPC LABEL_DPC_LEG_2 LABEL_DPC_LEG_3 LABEL_DPC_LEG_4 LABEL_DPC_LEG_5 LABEL_DPC_LEG_6 LABEL_DPC_LEG_7 LABEL_DPC_LEG_8 LABEL_DPC_LEG_9 LABEL_DPC_LEG_10 Common - First Leg Source IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Source IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format. MAP_CSDR SOURCE_IP CAP_CSDR SOURCE_IP INAP_CSDR SOURCE_IP TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_AIN_CSDR - BELL_LIDB_CSDR - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: SOURCE_IP SOURCE_IP_LEG_2 SOURCE_IP_LEG_3 SOURCE_IP_LEG_4 SOURCE_IP_LEG_5 SOURCE_IP_LEG_6 SOURCE_IP_LEG_7 SOURCE_IP_LEG_8 SOURCE_IP_LEG_9 SOURCE_IP_LEG_10 Common - First Leg Destination IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Destination IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format. MAP_CSDR DESTINATION_IP CAP_CSDR DESTINATION_IP INAP_CSDR DESTINATION_IP TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from younger BEGIN (or QUERY) Else itÕs filled from younger CONTINUE (or CONVERSATION) CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: DESTINATION_IP DESTINATION_IP_LEG_2 DESTINATION_IP_LEG_3 DESTINATION_IP_LEG_4 DESTINATION_IP_LEG_5 DESTINATION_IP_LEG_6 DESTINATION_IP_LEG_7 DESTINATION_IP_LEG_8 DESTINATION_IP_LEG_9 DESTINATION_IP_LEG_10 Common - First Leg Source Network Node Applicable Protocols: All This field identifies the name of the First Leg Source Network Node by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Network node name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Source Network Node Type Applicable Protocols: All This field identifies the Role of the First Leg Source Network Node by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Network node type is calculated using the same filling rule of the other generations exploiting the following CAP/INAP CSDR fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Network Node Applicable Protocols: All This field identifies the Role of the First Leg Destination Network Node by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. CAP/INAP De-duplicated Generations: First Leg Destination Network node name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Network Node Type Applicable Protocols: All This field identifies the Role of the First Leg Destination Network Node by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Destination IP Address. CAP/INAP De-duplicated Generations: First Leg Destination Network node type is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Source Signalling Point Applicable Protocols: All This field identifies the name of the First Leg Source Signalling Point by means of OPC field or Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Source IP Address. CAP/INAP De-duplicated Generations: First Leg Source Signalling Point name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_OPC SOURCE_IP VLAN_ID LABEL_OPC_LEG_2 SOURCE_IP_LEG_2 VLAN_ID_LEG_2 LABEL_OPC_LEG_3 SOURCE_IP_LEG_3 VLAN_ID_LEG_3 LABEL_OPC_LEG_4 SOURCE_IP_LEG_4 VLAN_ID_LEG_4 LABEL_OPC_LEG_5 SOURCE_IP_LEG_5 VLAN_ID_LEG_5 LABEL_OPC_LEG_6 SOURCE_IP_LEG_6 VLAN_ID_LEG_6 LABEL_OPC_LEG_7 SOURCE_IP_LEG_7 VLAN_ID_LEG_7 LABEL_OPC_LEG_8 SOURCE_IP_LEG_8 VLAN_ID_LEG_8 LABEL_OPC_LEG_9 SOURCE_IP_LEG_9 VLAN_ID_LEG_9 LABEL_OPC_LEG_10 SOURCE_IP_LEG_10 VLAN_ID_LEG_10 Common - First Leg Destination Signalling Point Applicable Protocols: All This field identifies the name of the First Leg Destination Signalling Point by means of DPC field or Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for protocols CAP, MAP and INAP. VLAN ID value is not present in eoTCAP Data Record. The value is taken from CAP CSDR, MAP CSDR and INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only destination IP Address. CAP/INAP De-duplicated Generations: First Leg Destination Signalling Point name is calculated using the same filling rule of the other generations exploiting the following CAP/INAP fields: LABEL_DPC DESTINATION_IP VLAN_ID LABEL_DPC_LEG_2 DESTINATION_IP_LEG_2 VLAN_ID_LEG_2 LABEL_DPC_LEG_3 DESTINATION_IP_LEG_3 VLAN_ID_LEG_3 LABEL_DPC_LEG_4 DESTINATION_IP_LEG_4 VLAN_ID_LEG_4 LABEL_DPC_LEG_5 DESTINATION_IP_LEG_5 VLAN_ID_LEG_5 LABEL_DPC_LEG_6 DESTINATION_IP_LEG_6 VLAN_ID_LEG_6 LABEL_DPC_LEG_7 DESTINATION_IP_LEG_7 VLAN_ID_LEG_7 LABEL_DPC_LEG_8 DESTINATION_IP_LEG_8 VLAN_ID_LEG_8 LABEL_DPC_LEG_9 DESTINATION_IP_LEG_9 VLAN_ID_LEG_9 LABEL_DPC_LEG_10 DESTINATION_IP_LEG_10 VLAN_ID_LEG_10 Common Ð Last Leg Originating Point Code Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP Generations CAP, MAP, INAP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Originating Point Code of the last leg of the transaction MAP_CSDR LABEL_OPC CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR LAST_OPC BELL_TCAP_800_CSDR LAST_OPC BELL_LIDB_CSDR LAST_OPC BELL_AIN LAST_OPC Filling criteria: in case of full load sharing it is filled from If BEGIN (or QUERY) present, then it is filled from younger BEGIN (or QUERY) Else it is filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found LABEL_OPC_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Destination Point Code Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Destination Point Code of the last leg of the transaction MAP_CSDR LABEL_DPC CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR LAST_DPC BELL_TCAP_800_CSDR LAST_DPC BELL_LIDB_CSDR LAST_DPC BELL_AIN LAST_DPC Filling criteria: in case of full load sharing it is filled from If BEGIN (or QUERY) present, then it is filled from younger BEGIN (or QUERY) Else it is filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found LABEL_DPC_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Source IP Address Applicable Protocols: MAP CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Source IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format in the last leg of transaction MAP_CSDR SOURCE_IP CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from: If BEGIN (or QUERY) present, then itÕs filled from older BEGIN (or QUERY) Else itÕs filled from older CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found SOURCE_IP_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Destination IP Address Applicable Protocols: MAP, CAP, INAP Generations CAP, MAP, INAP, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - It represents Destination IP Address present in Internet Header. It stores IP address in IPv4 or IPv6 format in the last leg of transaction MAP_CSDR DESTINATION_IP CAP_CSDR See below INAP_CSDR - TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - Filling criteria: in case of full load sharing itÕs filled from If BEGIN (or QUERY) present, then itÕs filled from younger BEGIN (or QUERY) Else itÕs filled from younger CONTINUE (or CONVERSATION) CAP/INAP CSDR It is filled in case of MEGACSDR Set N=10 Starting from N=10 to N=2 (N--) it is filled from the first found DESTINATION_IP_LEG_N not NULL Else NULL. CAP/INAP De-duplicated Generations: This field should not be filled Common - Last Leg Source Network Node Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Source Network Node by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin."
"The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN The last leg IP Address + VLAN lookup is available only for MAP, CAP and INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP and INAP CSDRs. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Source IP Address. Common - Last Leg Source Network Node Type Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the role of the Last Leg Source Network Node by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDRs. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Source IP Address. Common - Last Leg Destination Network Node Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Destination Network Node by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last Leg Destination IP Address. Common - Last Leg Destination Network Node Type Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the role of the Last Leg Destination Network Node by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that last leg IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Common - Last Leg Source Signalling Point Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Source Signalling Point by means of last leg OPC field or last leg Source IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last leg Source IP Address. Common Ð Last Leg Destination Signalling Point Applicable Protocols: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN, CAP, INAP This field identifies the name of the Last Leg Destination Signalling Point by means of last leg DPC field or last leg Destination IP address + VLAN ID. In case of IP address + VLAN, three possible configurations are available, which can be set by Masterclaw Administrator in qxdrs.nin. The possible configurations are: á UseCorrelateVLAN á UseAlwaysVLAN (default) á IgnoreVLAN Note that IP Address + VLAN lookup is available only for MAP, CAP, INAP protocol. VLAN ID value is not present in eoTCAP Data Record. The value is taken from MAP, CAP, INAP CSDR. Note that when configuration UseCorrelateVLAN or UseAlwaysVLAN is set, if the VLAN ID is not present in traffic, lookup will be performed considering only Last leg Source IP Address. Common - Calling Party Number Applicable Protocols: MAP, CAP, INAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN CSDR Type CSDR field Description TCAP-AP_CSDR - Indicates Calling party number (TCAP-OP, TCAP-800, LIDB, AIN, CAP, INAP CSDRs) or the address of the originating Short Message Entity (MAP CSDR) MAP_CSDR TP_OA CAP_CSDR CALLING_NO INAP_CSDR INAP_CALLING_PARTY_NO TCAP-OP_CSDR CALLING_PARTY or CALLING_DN BELL_TCAP_800_CSDR CALLING_PARTY BELL_LIDB_CSDR LIDB_ANI_CALLING_NUMBER or LIDB_CALLING_DIRECTORY_NUMBER BELL_AIN CALLING_NO Common - Called Party Number Applicable Protocols: MAP, CAP, INAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Generations CAP, MAP, INAP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field Description TCAP-AP_CSDR - Indicates Called party number (TCAP-OP, TCAP-800, LIDB, AIN, CAP, INAP CSDRs) or the address of the destinating Short Message Entity (MAP CSDR) MAP_CSDR TP_DA CAP_CSDR CALLED_NO INAP_CSDR INAP_CALLED_PARTY_NO TCAP-OP_CSDR CALLED_PARTY BELL_TCAP_800_CSDR CALLED_PARTY BELL_LIDB_CSDR LIDB_DIALLED_NUMBER BELL_AIN CALLED_NO CAP De-duplicated Generation: It exploits the following CAP fields: CALLED_NO CALLED_NO_LEG_2 CALLED_NO_LEG_3 CALLED_NO_LEG_4 CALLED_NO_LEG_5 CALLED_NO_LEG_6 CALLED_NO_LEG_7 CALLED_NO_LEG_8 CALLED_NO_LEG_9 CALLED_NO_LEG_10 INAP De-duplicated Generation: It exploits the following INAP fields: INAP_CALLED_PARTY_NO INAP_CALLED_PARTY_NO_LEG_2 INAP_CALLED_PARTY_NO_LEG_3 INAP_CALLED_PARTY_NO_LEG_4 INAP_CALLED_PARTY_NO_LEG_5 INAP_CALLED_PARTY_NO_LEG_6 INAP_CALLED_PARTY_NO_LEG_7 INAP_CALLED_PARTY_NO_LEG_8 INAP_CALLED_PARTY_NO_LEG_9 INAP_CALLED_PARTY_NO_LEG_10 Common - Payment Plan Applicable protocol: TCAP, MAP, CAP, INAP It is based on lookup of IMSI on MCLS Mobile Subscriber table (ÒPlanÓ column). This feature is optional. MCLS Table: Mobile Subscriber The lookup will be made on the IMSI CSDR field. Enumeration Value: 0 Pre-paid subscriber 1 Post-paid subscriber Common Ð First Leg Forward Linkset Name Applicable protocol: All The Linkset Name is retrieved from the MasterClaw Configuration database CDB. This is the Linkset Name concerning the BEGIN or QUERY PDU or any message initiating the transaction. Common Ð First Leg Backward Linkset Name Applicable protocol: All The Linkset Name is retrieved from the MasterClaw Configuration database CDB. This is the Linkset Name concerning the first message sent in response to the first message initiating the transaction. Common Ð Last Leg Forward Linkset Name Applicable protocol: All CSDR Type CSDR field Description TCAP-AP_CSDR - This is the Linkset Name of the first forward message in last leg of the sequence. MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR LAST_LINKSET_TXID BELL_TCAP_800_CSDR LAST_LINKSET_TXID CSDR Type CSDR field Description BELL_LIDB_CSDR LAST_LINKSET_TXID BELL_AIN LAST_LINKSET_TXID Common Ð Last Leg Backward Linkset Name Applicable protocol: All CSDR Type CSDR field Description TCAP-AP_CSDR - This is the Linkset Name of the first backward message in last leg of the sequence. MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR LAST_LINKSET_RXID BELL_TCAP_800_CSDR LAST_LINKSET_RXID BELL_LIDB_CSDR LAST_LINKSET_RXID BELL_AIN LAST_LINKSET_RXID Common - OTID Applicable protocol: All 32-Bit long Originating Transaction ID of TCAP. Filled from: Filled with the OTID of BEGIN message or from DTID of END/CONTINUE message whichever comes first in the sequence. CSDR Type CSDR field Description TCAP-AP_CSDR OTID Originating Transaction ID of TCAP MAP_CSDR CAP_CSDR CSDR Type CSDR field Description INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common Ð DTID Applicable protocol: All 32-bit long Destination Transaction ID of TCAP Filled from: Filled with the OTID of CONTINUE message if present in the sequence CSDR Type CSDR field Description TCAP-AP_CSDR DTID Destination Transaction ID of TCAP MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common Ð SCCP Back Calling Number Applicable protocol: MAP, TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN The 'address information part' of the 'calling party global titleÕ, which is carried in the TCAP CONTINUE/END operation. Also from BEGIN operation if only UDT/XUDT (BEGIN) and UDTS/XUDTS (BEGIN) forms a sequence. Q713 (section 3.4), E164, E214 Generations CAP, MAP, INAP, TCAP-AP, MAP-E2E-SMS CSDR Type CSDR field TCAP-AP_CSDR BACKCLG_NO MAP_CSDR CAP_CSDR See below INAP_CSDR TCAP-OP_CSDR - BELL_TCAP_800_CSDR - BELL_LIDB_CSDR - BELL_AIN - CAP/INAP CSDR Check in this order the following CAP/INAP fields: 1- BACKCLG_NO 2- BACKCLG_NO_LEG_N (for N=2 to N=10, N++) Common Ð SCCP Back Calling Number = the first found CAP/INAP field not NULL If no field is found Common Ð SCCP Back Calling Number = NULL CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: BACKCLG_NO BACKCLG_NO_LEG_2 BACKCLG_NO_LEG_3 BACKCLG_NO_LEG_4 BACKCLG_NO_LEG_5 BACKCLG_NO_LEG_6 BACKCLG_NO_LEG_7 BACKCLG_NO_LEG_8 BACKCLG_NO_LEG_9 BACKCLG_NO_LEG_10 Common - Called Party Global Title Applicable protocol: All The 'address information part' of the 'called party global titleÕ, which is carried in the TCAP BEGIN/CONTINUE/END operation. Q713 (section 3.4), E164, E214 Generations CAP, MAP, INAP, TCAP-AP, TCAP-OP, BELL-800, BELL-AIN, BELL-LIDB, MAP-E2E-SMS CSDR Type CSDR field TCAP-AP_CSDR GTCALLED_NO MAP_CSDR GTCALLED_NO CAP_CSDR SCCP_CALLED_PARTY INAP_CSDR SCCP_CALLED_PARTY TCAP-OP_CSDR SCCP_CALLED_PARTY BELL_TCAP_800_CSDR SCCP_CALLED_PARTY BELL_LIDB_CSDR SCCP_CALLED_PARTY BELL_AIN SCCP_CALLED_PARTY CAP/INAP De-duplicated Generations: It exploits the following CAP/INAP fields: SCCP_CALLED_PARTY SCCP_CALLED_PARTY_LEG_2 SCCP_CALLED_PARTY_LEG_3 SCCP_CALLED_PARTY_LEG_4 SCCP_CALLED_PARTY_LEG_5 SCCP_CALLED_PARTY_LEG_6 SCCP_CALLED_PARTY_LEG_7 SCCP_CALLED_PARTY_LEG_8 SCCP_CALLED_PARTY_LEG_9 SCCP_CALLED_PARTY_LEG_10 Common - Calling Party Global Title Applicable protocol: All The 'address information part' of the 'called party global titleÕ, which is carried in the TCAP BEGIN/CONTINUE/END operation. Q713 (section 3.4), E164, E214 Common - Called SSN Applicable protocol: All It represents the Called Sub System Number, Part of SCCP called party sub system. Q.713 (section 3.4.2.2) CSDR Type CSDR field TCAP-AP_CSDR CALLED_SSN MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Value Definition 0 SSN not known not used Value Definition 1 SCCP Management 3 ISDN User Part 4 OMAP 5 MAP 6 HLR 7 VLR 8 MSC 9 EIR 10 AUC 11 ISDN Supplementary Services 12 INAP 13 broadband ISDN Edge To Edge 14 TC Test Responder 15 SINAP 142 RANAP 143 RNSAP 145 GMLC 146 CAP 147 GSMSCF 148 SIWF 149 SGSN 150 GGSN 192 BSSAP 241 INAPCS2 Value Definition 248 MTXMUP 249 HLRMUP 252 BSAP 254 BSSAP Table for MAP/CAP Common - Calling SSN Applicable protocol: All It represents the Calling Sub System Number, part of SCCP called party sub system. Q.713 (section 3.4.2.2) CSDR Type CSDR field TCAP-AP_CSDR CALLING_SSN MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN See Called SSN for value list. Common - SCCP Return Cause Applicable protocol: All This field contains the result of procedure at SCCP layer. Common - TCAP Abort Cause Applicable protocol: All This field contains the result of procedure at TCAP layer. Common - Service Information Octet Applicable protocol: All The service information octet of message contains the service indicator and sub service field (which contains network indicator and spare bits). It is used to distinguish the network service carried in SCCP layer. Value SIO (Enumeration) 0 SNM 1 SNT 3 international SCCP 4 TUP 5 international ISUP 6 DUP 7 DUP1 8 MTUP 9 BISUP 10 SISUP 128 national SNM 129 national SNT 131 national SCCP 132 national TUP 133 national ISUP 192 nSNM* 193 nSNT* 195 nSCCP* 196 nTUP* Value SIO (Enumeration) 197 nISUP 255 undefined field CSDR Type CSDR field Description TCAP-AP_CSDR SIO The service information octet of message signal units contains the service indicator and sub service field (which contains network indicator and spare bits) MAP_CSDR CAP_CSDR INAP_CSDR TCAP-OP_CSDR BELL_TCAP_800_CSDR BELL_LIDB_CSDR BELL_AIN Common - Service Key Applicable Protocols: CAP, INAP, MAP CAP: it represents a CAP/CAMEL service descriptor. The interpretation is operator dependent. INAP: it represents an INAP service descriptor. The interpretation is operator dependent. MAP: it defines the ServiceKey field of VLR CAMEL subscription info Common Ð Conversation Time Interval Applicable Protocols: CAP, INAP This field identifies the Conversation Time Interval by means of a lookup of the Conversation Time field on MCLS table Conversation Interval Standard Formatting: Column CTI_INTERVAL_NAME CTI_LOWER_VALUE CTI_UPPER_VALUE Default table value: Conversation Time Interval Name Conversation Time Lower Value (s) Conversation Time Upper Value (s) 0-30 s 0 30 30-60 s 30 60 60-900 s 60 900 900-1800 s 900 1800 1800-3600 s 1800 3600 >=3600 s 3600 Factor conversion: 1000 (from msec to sec) Common - IMSI Applicable protocol: TCAP-AP, MAP, CAP, INAP Common - MSISDN Applicable protocol: TCAP-AP, MAP, CAP, INAP MAP: This field is mandatory only in successful cases because it is contained in the Insert Subscriber Data from HLR that follow the GSM/GPRS Update Location only in case of success. This parameter refers to the Directory number used to call GSM subscriber. The structure of a GSM directory number consists of country code, the national destination code and the subscriber number. MSISDN number (Reference GSM 09.02 V4.6.0, 5.6.2.17) TCAP-AP: IMSI lookup via MICS. CAP: IMSI lookup via MICS. INAP IMSI lookup via MICS. TCAP-OP: N.A. BELL_TCAP_800: N.A. BELL_LIDB: N.A. BELL_AIN: N.A. Common - IMEI Applicable protocol:, MAP, CAP International Mobile Equipment identity number. CAP CSDR: itÕs filled by ÒINITIAL DPÓ, ÒINITIAL DP SMSÓ & ÒINITIAL DP GPRSÓ. MAP CSDR: itÕs filled by ÒPrepare HandoverÓ, ÒUpdate LocationÓ, ÒUpdate GPRS LocationÓ, ÒUE Identity IE from CN INVOKE TRACE message of RANAP layer over MAP Common - Device TAC Applicable protocol: MAP, CAP TAC (Type of Allocation) is composed by the first eight digits of IMEI. TAC code identifies the device manufacturer and the model. Common - Location Information Applicable protocol: TCAP-OP, MAP, INAP Common Ð PLMN ID Applicable protocol: MAP, CAP It conveys the identity of the network to which the UE is attached according to the ITU-T E.212 standard. Common Ð SCCP Calling Party Number Point Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Common Ð SCCP Calling Party Number Signalling Point Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN This field identifies the Calling Party Number signalling point name by means of a lookup of: - SCCP Calling Party Number Point Code Common Ð SCCP Called Party Number Point Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Common Ð SCCP Called Party Number Signalling Point This field identifies the Called Party Number signalling point name by means of a lookup of: - SCCP Called Party Number Point Code - Common Ð VLR Number This field identifies the ISDN Number of the VLR Applicable protocol: MAP, CAP, INAP WHITE TCAP Fields WHITE TCAP - Application Operation Code It represents the first operation invoked at TCAP layer. Application Operation Code Opcode Description EINAPV21 0x0101 EINAPV21 Activate Resource 0x0102 EINAPV21 Activity Test 0x0103 EINAPV21 Congestion Control 0x0104 EINAPV21 Create 0x0105 EINAPV21 Event 0x0106 EINAPV21 Free 0x0107 EINAPV21 Generate 0x0108 EINAPV21 Handover 0x0109 EINAPV21 Charging Information 0x010A EINAPV21 Join 0x010B EINAPV21 Monitor 0x010C EINAPV21 Open Special Function 0x010D EINAPV21 Provide Instructions 0x010E EINAPV21 Release Resource 0x010F EINAPV21 Reset Timer Opcode Description 0x0110 EINAPV21 Retrieve 0x0111 EINAPV21 sCF Reset Indication 0x0112 EINAPV21 Split 0x0113 EINAPV21 sSF Reset Indication 0x0114 EINAPV21 Transfer Control 0x0115 EINAPV21 Update 0x0116 EINAPV21 Backward Information 0x0117 EINAPV21 Call Control INAPCS1P 0x0200 INAPCS1P InitialDP 0x0210 INAPCS1P Retrieve / Assist Request Instructions 0x0211 INAPCS1P Establish Temporary Connection 0x0212 INAPCS1P Disconnect Forward Connection 0x0213 INAPCS1P Connect To Resource 0x0214 INAPCS1P Connect 0x0215 INAPCS1P Update 0x0216 INAPCS1P Release Call 0x0217 INAPCS1P Request Report BCSM Event 0x0218 INAPCS1P Event Report BCSM 0x0219 INAPCS1P Request Notification Charging Event 0x021A INAPCS1P Event Notification Charging 0x021B INAPCS1P Collect Information 0x021F INAPCS1P Continue 0x0220 INAPCS1P Initiate Call Attempt Opcode Description 0x0221 INAPCS1P Reset Timer 0x0222 INAPCS1P Furnish Charging Information 0x0223 INAPCS1P Apply Charging 0x0224 INAPCS1P Apply Charging Report 0x0229 INAPCS1P Call Gap 0x022A INAPCS1P Activate Service Filtering 0x022B INAPCS1P Service Filtering Response 0x022C INAPCS1P Call Information Report 0x022D INAPCS1P Call Information Request 0x022E INAPCS1P Send Charging Information 0x022F INAPCS1P Play Announcement 0x0230 INAPCS1P Prompt And Collect User Information 0x0231 INAPCS1P Specialised Resource Report 0x0235 INAPCS1P Cancel 0x0236 INAPCS1P Activity Test 0x02F8 INAPCS1P Signalling Information 0x02FA INAPCS1P Release Call Party Connection 0x02FB INAPCS1P Reconnect 0x02FC INAPCS1P Hold Call Party Connection 0x02FD INAPCS1P HandOver 0x02FE INAPCS1P Dialogue User Information 0x02FF INAPCS1P Call Limit ETSI_INAP 0x0300 ETSI_INAP InitialDP Opcode Description 0x0310 ETSI_INAP Retrieve / Assist Request Instructions 0x0311 ETSI_INAP Establish Temporary Connection 0x0312 ETSI_INAP Disconnect Forward Connection 0x0313 ETSI_INAP Connect To Resource 0x0314 ETSI_INAP Connect 0x0315 ETSI_INAP Update 0x0316 ETSI_INAP Release Call 0x0317 ETSI_INAP Request Report BCSM Event 0x0318 ETSI_INAP Event Report BCSM 0x0319 ETSI_INAP Request Notification Charging Event 0x031A ETSI_INAP Event Notification Charging 0x031B ETSI_INAP Collect Information 0x031F ETSI_INAP Continue 0x0320 ETSI_INAP Initiate Call Attempt 0x0321 ETSI_INAP Reset Timer 0x0322 ETSI_INAP Furnish Charging Information 0x0323 ETSI_INAP Apply Charging 0x0324 ETSI_INAP Apply Charging Report 0x0329 ETSI_INAP Call Gap 0x032A ETSI_INAP Activate Service Filtering 0x032B ETSI_INAP Service Filtering Response 0x032C ETSI_INAP Call Information Report 0x032D ETSI_INAP Call Information Request 0x032E ETSI_INAP Send Charging Information Opcode Description 0x032F ETSI_INAP Play Announcement 0x0330 ETSI_INAP Prompt And Collect User Information 0x0331 ETSI_INAP Specialised Resource Report 0x0335 ETSI_INAP Cancel 0x0336 ETSI_INAP Activity Test ETSI_CAP 0x0400 ETSI_CAP InitialDP 0x0410 ETSI_CAP Assist Request Instructions 0x0411 ETSI_CAP Establish Temporary Connection 0x0412 ETSI_CAP Disconnect Forward Connection 0x0413 ETSI_CAP Connect To Resource 0x0414 ETSI_CAP Connect 0x0416 ETSI_CAP Release Call 0x0417 ETSI_CAP Request Report BCSM Event 0x0418 ETSI_CAP Event Report BCSM 0x041F ETSI_CAP Continue 0x0420 ETSI_CAP Initiate Call Attempt 0x0421 ETSI_CAP Reset Timer 0x0422 ETSI_CAP Furnish Charging Information 0x0423 ETSI_CAP Apply Charging 0x0424 ETSI_CAP Apply Charging Report 0x0429 ETSI_CAP Call Gap 0x042C ETSI_CAP Call Information Report 0x042D ETSI_CAP Call Information Request Opcode Description 0x042E ETSI_CAP Send Charging Information 0x042F ETSI_CAP Play Announcement 0x0430 ETSI_CAP Prompt And Collect User Information 0x0431 ETSI_CAP Specialized Resource Report 0x0435 ETSI_CAP Cancel 0x0437 ETSI_CAP Activity Test 0x0438 ETSI_CAP Continue With Argument 0x043C ETSI_CAP InitialDP SMS 0x043D ETSI_CAP Furnish Charging Information SMS 0x043E ETSI_CAP Connect SMS 0x043F ETSI_CAP Request Report SMS Event 0x0440 ETSI_CAP Event Report SMS 0x0441 ETSI_CAP Continue SMS 0x0442 ETSI_CAP Release SMS 0x0443 ETSI_CAP Reset Timer SMS 0x0446 ETSI_CAP Activity Test GPRS 0x0447 ETSI_CAP Apply Charging GPRS 0x0448 ETSI_CAP Apply Charging Report GPRS 0x0449 ETSI_CAP Cancel GPRS 0x044A ETSI_CAP Connect GPRS 0x044B ETSI_CAP Continue GPRS 0x044C ETSI_CAP Entity Released GPRS 0x044D ETSI_CAP Furnish Charging Information GPRS 0x044E ETSI_CAP InitialDP GPRS Opcode Description 0x044F ETSI_CAP Release GPRS 0x0450 ETSI_CAP Event Report GPRS 0x0451 ETSI_CAP Request Report GPRS Event 0x0452 ETSI_CAP Reset Timer GPRS 0x0453 ETSI_CAP Send Charging Information GPRS 0x045A ETSI_CAP Disconnect Leg 0x045D ETSI_CAP Move Leg 0x045F ETSI_CAP Split Leg 0x0460 ETSI_CAP Entity Released 0x0461 ETSI_CAP Play Tone 0x04FF ETSI_CAP undefined field ETSI_MAP 0x0502 ETSI_MAP Update Location 0x0503 ETSI_MAP Cancel Location 0x0504 ETSI_MAP Provide Roaming Number 0x0505 ETSI_MAP Note Subscriber Data Modified 0x0506 ETSI_MAP Resume Call Handling 0x0507 ETSI_MAP Insert Subscriber Data 0x0508 ETSI_MAP Delete Subscriber Data 0x0509 ETSI_MAP Send Parameters 0x050A ETSI_MAP Register SS 0x050B ETSI_MAP Erase SS 0x050C ETSI_MAP Activate SS 0x050D ETSI_MAP Deactivate SS Opcode Description 0x050E ETSI_MAP Interrogate SS 0x050F ETSI_MAP Authentication Failure Report 0x0511 ETSI_MAP Register Password 0x0512 ETSI_MAP Get Password 0x0513 ETSI_MAP Process Unstructured SS-Data 0x0514 ETSI_MAP Release Resources 0x0515 ETSI_MAP MT Forward SM VGCS 0x0516 ETSI_MAP Send Routing Info 0x0517 ETSI_MAP Update Gprs Location 0x0518 ETSI_MAP Send Routing Info For GPRS 0x0519 ETSI_MAP Failure Report 0x051A ETSI_MAP Note MS Present For GPRS 0x051C ETSI_MAP Perform Handover 0x051D ETSI_MAP Send End Signal 0x051E ETSI_MAP Perform Subsequent Handover 0x051F ETSI_MAP Provide SIWFS Number 0x0520 ETSI_MAP SIW FS Signalling Modify 0x0521 ETSI_MAP Process Access Signalling 0x0522 ETSI_MAP Forward Access Signalling 0x0523 ETSI_MAP Note Internal Handover 0x0525 ETSI_MAP Reset 0x0526 ETSI_MAP Forward Check SS-Indication 0x0527 ETSI_MAP Prepare Group Call 0x0528 ETSI_MAP Send Group Call End Signal Opcode Description 0x0529 ETSI_MAP Process Group Call Signalling 0x052A ETSI_MAP Forward Group Call Signalling 0x052B ETSI_MAP Check IMEI 0x052C ETSI_MAP MT-ForwardSM 0x052D ETSI_MAP Send Routing Info For SM 0x052E ETSI_MAP MO-ForwardSM 0x052F ETSI_MAP Report SM-Delivery Status 0x0530 ETSI_MAP Note Subscriber Present 0x0531 ETSI_MAP Alert Service Centre Without Result 0x0532 ETSI_MAP Activate Trace Mode 0x0533 ETSI_MAP Deactivate Trace Mode 0x0534 ETSI_MAP Trace Subscriber Activity 0x0536 ETSI_MAP Begin Subscriber Activity 0x0537 ETSI_MAP Send Identification 0x0538 ETSI_MAP Send Authentication Info 0x0539 ETSI_MAP Restore Data 0x053A ETSI_MAP Send IMSI 0x053B ETSI_MAP Process Unstructured SS Request 0x053C ETSI_MAP Unstructured SS Request 0x053D ETSI_MAP Unstructured SS Notify 0x053E ETSI_MAP Any Time Subscription Interrogation 0x053F ETSI_MAP Inform Service Centre 0x0540 ETSI_MAP Alert Service Centre 0x0541 ETSI_MAP Any Time Modification Opcode Description 0x0542 ETSI_MAP Ready For SM 0x0543 ETSI_MAP Purge MS 0x0544 ETSI_MAP Prepare Handover 0x0545 ETSI_MAP Prepare Subsequent Handover 0x0546 ETSI_MAP Provide Subscriber Info 0x0547 ETSI_MAP Any Time Interrogation 0x0548 ETSI_MAP SS-Invocation Notification 0x0549 ETSI_MAP Set Reporting State 0x054A ETSI_MAP Status Report 0x054B ETSI_MAP Remote User Free 0x054C ETSI_MAP Register CC-Entry 0x054D ETSI_MAP Erase CC-Entry 0x054E ETSI_MAP Secure Transport Class1 0x054F ETSI_MAP Secure Transport Class2 0x0550 ETSI_MAP Secure Transport Class3 0x0551 ETSI_MAP Secure Transport Class4 0x0552 ETSI_MAP Provide Subscriber Location 0x0553 ETSI_MAP Send Group Call Information 0x0554 ETSI_MAP Send Routing Info For LCS 0x0555 ETSI_MAP Subscriber Location Report 0x0556 ETSI_MAP IST-Alert 0x0557 ETSI_MAP IST-Command 0x0558 ETSI_MAP Note MM-Event 0x05FF ETSI_MAP Undefined Field Opcode Description BEL IS41D 0x0601 BEL IS41D HandOff Measurement Request 0x0602 BEL IS41D Facilities Directive 0x0603 BEL IS41D Mobile on channel 0x0604 BEL IS41D HandOff Back 0x0605 BEL IS41D Facilities Release 0x0606 BEL IS41D Qualification Request 0x0607 BEL IS41D Qualification Directive 0x0608 BEL IS41D Blocking 0x0609 BEL IS41D Unblocking 0x060A BEL IS41D Reset Circuit 0x060B BEL IS41D TrunkTest 0x060C BEL IS41D Trunk Test Disconnect 0x060D BEL IS41D Registration Notification 0x060E BEL IS41D Registration Cancellation 0x060F BEL IS41D Location Request 0x0610 BEL IS41D Routing Request 0x0611 BEL IS41D Feature Request 0x0612 BEL IS41D Service Profile Request 0x0613 BEL IS41D Service Profile Directive 0x0614 BEL IS41D Unreliable Roamer Data Dir 0x0615 BEL IS41D Call Data Request 0x0616 BEL IS41D MS Inactive 0x0617 BEL IS41D Transfer To Number Request Opcode Description 0x0618 BEL IS41D Redirection Request 0x0619 BEL IS41D HandOff To Third 0x061A BEL IS41D Flash Request 0x061B BEL IS41D Authentication Directive 0x061C BEL IS41D Authentication Request 0x061D BEL IS41D Base Station Challenge 0x061E BEL IS41D Authentication Failure Report 0x061F BEL IS41D Count Request 0x0620 BEL IS41D InterSystemPage 0x0621 BEL IS41D Unsolicited Response 0x0622 BEL IS41D Bulk Deregistration 0x0623 BEL IS41D HandOff Measurement Request 2 0x0624 BEL IS41D Facilities Directive 2 0x0625 BEL IS41D HandOff Back 2 0x0626 BEL IS41D HandOff To Third 2 0x0627 BEL IS41D Authentication Directive Forward 0x0628 BEL IS41D Authentication Status Report 0x0629 BEL IS41D Reserved 0x062A BEL IS41D Information Directive 0x062B BEL IS41D Information Forward 0x062C BEL IS41D Inter System Answer 0x062D BEL IS41D Inter System Page 2 0x062E BEL IS41D Inter System Setup 0x062F BEL IS41D Origination Request Opcode Description 0x0630 BEL IS41D Random Variable Request 0x0631 BEL IS41D Redirection Directive 0x0632 BEL IS41D Remote User Interaction Dir 0x0633 BEL IS41D SMS Delivery Backward 0x0634 BEL IS41D SMS Delivery Forward 0x0635 BEL IS41D SMS Delivery Point To Point 0x0636 BEL IS41D SMS Notification 0x0637 BEL IS41D SMS Request 0x0639 BEL IS41D Number Portability Request 0x063A BEL IS41D Analyzed Information 0x063B BEL IS41D Connection Failure Report 0x063C BEL IS41D Connect Resource 0x063D BEL IS41D Disconnect Resource 0x063E BEL IS41D Facility Selected & Available 0x063F BEL IS41D Instruction Request 0x0640 BEL IS41D Modify 0x0641 BEL IS41D Reset Timer 0x0642 BEL IS41D Search 0x0643 BEL IS41D Seize Resource 0x0644 BEL IS41D SRF Directive 0x0645 BEL IS41D T Busy 0x0646 BEL IS41D T No Answer 0x0647 BEL IS41D ServiceRequest 0x0648 BEL IS41D Bulk Disconnection Opcode Description 0x0649 BEL IS41D Call Control Directive 0x064A BEL IS41D O Answer 0x064B BEL IS41D O Disconnect 0x064C BEL IS41D Call Recovery Report 0x064D BEL IS41D T Answer 0x064E BEL IS41D T Disconnect 0x064F BEL IS41D Unreliable Call Data TCAPOP 0x0701 TCAPOP Dequeue Call 0x0702 TCAPOP Queue Call 0x0703 TCAPOP Voice Message Retrieved 0x0704 TCAPOP Voice Message Available 0x0705 TCAPOP Cancel 0x0706 TCAPOP Security 0x0707 TCAPOP Report assist Termination 0x0708 TCAPOP Temporary Handover 0x0709 TCAPOP Automatic Code Gap 0x070A TCAPOP When Party Free 0x070B TCAPOP Indicate Information Provided 0x070C TCAPOP Indicate Information Waiting 0x070D TCAPOP Play announcement abd collect Digits 0x070E TCAPOP Play Announcement 0x070F TCAPOP Forward Disconnect 0x0710 TCAPOP Disconnect Opcode Description 0x0711 TCAPOP Temporary Connect 0x0712 TCAPOP Connect 0x0713 TCAPOP Assist 0x0714 TCAPOP Start 0x0715 TCAPOP Bill Call 0x0716 TCAPOP Set Value 0x0717 TCAPOP Provide Value INAPCS2 0x800 initialDP 0x801 originationAttemptAuthorized 0x802 collectedInformation 0x803 analysedInformation 0x804 routeSelectFailure 0x805 oCalledPartyBusy 0x806 oNoAnswer 0x807 oAnswer 0x808 oDisconnect 0x809 termAttemptAuthorized 0x80A tBusy 0x80B tNoAnswer 0x80C tAnswer 0x80D tDisconnect 0x80E oMidCall 0x80F tMidCall Opcode Description 0x810 assistRequestInstructions 0x811 establishTemporaryConnection 0x812 disconnectForwardConnection 0x813 connectToResource 0x814 connect 0x815 holdCallInNetwork 0x816 releaseCall 0x817 requestReportBCSMEvent 0x818 eventReportBCSM 0x819 requestNotificationChargingEvent 0x81A eventNotificationCharging 0x81B collectInformation 0x81C analyseInformation 0x81D selectRoute 0x81E selectFacility 0x81F continue 0x820 initiateCallAttempt 0x821 resetTimer 0x822 furnishChargingInformation 0x823 applyCharging 0x824 applyChargingReport 0x825 requestCurrentStatusReport 0x826 requestEveryStatusChangeReport 0x827 requestFirstStatusMatchReport Opcode Description 0x828 statusReport 0x829 callGap 0x82A activateServiceFiltering 0x82B serviceFilteringResponse 0x82C callInformationReport 0x82D callInformationRequest 0x82E sendChargingInformation 0x82F playAnnouncement 0x830 promptAndCollectUserInformation 0x831 specializedResourceReport 0x835 cancel 0x836 cancelStatusReportRequest 0x837 activityTest 0x850 facilitySelectedAndAvailable 0x851 originationAttempt 0x852 terminationAttempt 0x853 oAbandon 0x854 oSuspended 0x855 tSuspended 0x856 dFCWithArgument 0x857 authorizeTermination 0x858 continueWithArgument 0x859 createCallSegmentAssociation 0x85A disconnectLeg Opcode Description 0x85B mergeCallSegments 0x85C moveCallSegments 0x85D moveLeg 0x85E reconnect 0x85F splitLeg 0x860 entityReleased 0x861 manageTriggerData 0x862 requestReportUTSI 0x864 sendSTUI 0x865 reportUTSI 0x866 sendFacilityInformation 0x867 requestReportFacilityEvent 0x868 eventReportFacility 0x86B promptAndReceiveMessage 0x86C scriptInformation 0x86D scriptEvent 0x86E scriptRun 0x86F scriptClose 0x870 establishChargingRecord 0x871 handlingInformationRequest 0x872 handlingInformationResult 0x873 networkCapability 0x874 notificationProvided 0x875 confirmedNotificationProvided Opcode Description 0x876 provideUserInformation 0x877 confirmedReportChargingInformation 0x878 reportChargingInformation 0x879 requestNotification 0x87A activationReceivedAndAuthorized 0x87B initiateAssociation 0x87C associationReleaseRequested 0x87D componentReceived 0x87E releaseAssociation 0x87F requestReportBCUSMEvent 0x882 sendComponent NOKIA_INAP 0x900 initialDP 0x910 assistRequestInstructions 0x911 establishTemporaryConnection 0x912 disconnectForwardConnection 0x913 connectToResource 0x914 connect 0x916 releaseCall 0x917 requestReportBCSMEvent 0x918 eventReportBCSM 0x919 requestNotificationChargingEvent 0x91A eventNotificationCharging 0x91B collectInformation Opcode Description 0x91F continue 0x920 initiateCallAttempt 0x921 resetTimer 0x922 furnishChargingInformation 0x923 applyCharging 0x924 applyChargingReport 0x929 callGap 0x92A activateServiceFiltering 0x92B serviceFilteringResponse 0x92C callInformationReport 0x92D callInformationRequest 0x92E sendChargingInformation 0x92F playAnnouncement 0x930 promptAndCollectUserInformation 0x931 specializedResourceReport 0x935 cancel 0x937 activityTest SINAP 0xA00 sinapInitialDP 0xA10 sinapAssistRequestInstructions 0xA11 sinapEstablishTemporaryConnection 0xA12 disconnectForwardConnection 0xA13 sinapConnectToResource 0xA14 sinapConnect Opcode Description 0xA16 sinapReleaseCall 0xA17 sinapRequestReportBCSMEvent 0xA18 sinapEventReportBCSM 0xA19 requestNotificationChargingEvent 0xA1A eventNotificationCharging 0xA1B collectInformation 0xA1F continue 0xA20 sinapInitiateCallAttempt 0xA21 sinapResetTimer 0xA22 furnishChargingInformation 0xA23 sinapApplyCharging 0xA24 sinapApplyChargingReport 0xA29 sinapCallGap 0xA2A activateServiceFiltering 0xA2B serviceFilteringResponse 0xA2C sinapCallInformationReport 0xA2D sinapCallInformationRequest 0xA2E sinapSendChargingInformation 0xA2F sinapPlayAnnouncement 0xA30 sinapPromptAndCollectUserInformation 0xA31 specializedResourceReport 0xA35 sinapCancel 0xA56 sinapDisconnectForwardConnectionWithArgument 0xA58 sinapContinueWithArgument Opcode Description 0xA5A sinapDisconnectLeg 0xA5B sinapMergeCallSegments 0xA5F sinapSplitLeg 0xA60 sinapEntityReleased 0xA62 manageTriggerData 0xA63 releaseLeg 0xA6D sinapScriptEvent 0xA6E sinapScriptRun WHITE TCAP - Application Error Code This field has to be filled with error codes of EINAPV21, INAPCS1P, ETSI_CAP,ETSI_MAP, ETSI_INAP,INAPCS2,NOKIA_INAP,SINAP,BELIS41D,TCAPOP layers when Return Error Component comes with their Error Code Value. BELL TCAP Fields BELL TCAP Ð Application Operation Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 257 Parameter Provide Value X X 258 Parameter Set Value X x 513 Charging Bill Call X X 769 Provide Instructions Start X x X 770 Provide Instructions Assist X X 1025 Connection Control Connect X x X 1026 Connection Control Temporary Connect X X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 1027 Connection Control Disconnect X X 1028 Connection Control Forward Disconnect X X 1281 Caller Interaction Play Announcement X x X 1282 Caller Interaction PA and Collect Digits X X 1283 Caller Interaction Indicate Information Waiting X 1284 Caller Interaction Indicate Information Provided X 1537 Send Notification When Party Free X x X 1793 Network Management Automatic Code Gap X x X 2049 Procedural Temporary Handover X X 2050 Procedural Report Assist Termination X 2051 Procedural Security X x x 2305 Operation Control Cancel X 2561 Report Event Voice Message Available X 2562 Report Event Voice Message Retrieved X 32257 Miscellaneous Queue Call X 32258 Miscellaneous Dequeue Call x 26116 callInfoFromResource X 28161 close X 26118 cTRClear X 25604 failureOutcome X 25603 infoAnalyzed X 25602 infoCollected X 25623 networkBusy X 25611 oAnswer X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 25614 oAbandon X 25607 oCalledPartyBusy X 25626 oDisconnect X 25615 oMidCall X 25609 oNoAnswer X 25625 oSuspended X 25612 oTermSeized X 25624 originationAttempt X 26114 resourceClear X 25617 successOutcome X 25610 tAnswer X 25606 tBusy X 25618 tDisconnect X 25619 tMidCall X 25608 tNoAnswer X 25605 terminationAttempt X 25613 termResourceAvailable X 25620 timeout X 25862 acknowledge X 25857 analyzeRoute X 25858 authorizeTermination X 26115 cancelResourceEvent X 25861 collectInformation X 26117 connectToResource X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 25869 continue X 25863 createCall X 25859 disconnect X 25864 disconnectLeg X 27137 forwardCall X 25865 mergeCall X 25866 moveLeg X 25860 offerCall X 25867 originateCall X 25870 reconnect X 26113 sendToResource X 25868 splitLeg X 26881 acg X 26883 acgGlobalCtrlRestore X 26884 acgOverflow X 26885 controlRequest X 26882 echoRequest X 27649 furnishAMAInformation X 26369 monitorForChange X 26371 monitorSuccess X 27394 nCAData X 27393 nCARequest X 26626 queryRequest X 27905 requestReportBCMEvent X Value Interpretation TCAP_OP CSDR BELL_TCAP_800 BELL_AIN BELL_LIDB 26373 sendNotification X 26370 statusReported X 26372 terminationNotification X 26627 update X 26625 updateRequest X 28417 reportError X 25627 oDTMFEnteredArg X 26889 setTimerArg X 25628 tDTMFEnteredArg X 26886c activityTestArg X 26887 callTypeRequestArg X BELL TCAP Ð Last Application Operation Code Applicable protocol: TCAP-OP, BELL LIDB, BELL AIN BELL TCAP Ð Application Error Code Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP Ð Reject Problem Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP Ð Translation Type Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB, BELL AIN BELL TCAP - GTT REQUESTED Applicable protocol: TCAP-OP, BELL TCAP 800, BELL LIDB BELL TCAP Ð TCAP 800 Termination Indicator Applicable protocol: BELL TCAP 800 CSDR Type CSDR field Description BELL_TCAP_800_CSDR TERMIN_INDIC This field indicates the termination indicator. BELL TCAP Ð AIN Error Cause Applicable protocol: BELL AIN CSDR Type CSDR field Description BELL_AIN ER_REASON Contains a reason for those transactions having an error carrying additional information. This parameter is sent to identify the application error detected at the SSP or SCP. This field and the ÔErrorCodeÕ field specify the exact error and reason. BELL TCAP Ð TCAP OP Line Service Type Applicable protocol: BELL TCAP OP CSDR Type CSDR field Description BELL_TCAP_OP_CSDR SERVICE_TYPE This field indicates which line service type is associated with a DN and also whether a DN is applicable to both originating and terminating service Value Interpretation 0 Individual 1 Coin 2 Multiline Hunt 3 PBX 4 Choke Value Interpretation 5 Series Completion 6 Unassigned DN 7 Multi-Party 8 Non-specific 9 Temporarily out of Service BELL TCAP Ð LIDB Service or Equipment Indicator Applicable protocol: BELL TCAP OP, BELL LIDB CSDR Type CSDR field Description BELL_LIDB_CSDR LIDB_SERVICE_EQUIPMENT_INDICATOR This parameter indicates the type of service or equipment associated with the line originating the call. Value Interpretation 1 POTS Line (Business/Residential) 2 LEC Public - Standard Interface - Postpay Overtime 3 POTS Line - Residential - Message rate 1 4 POTS Line - Residential - Message rate 2 5 LEC Semi-Public 6 POTS Line - Business - flat rate 7 POTS Line - Business - message rate 1 8 Coinless (non-IPP) 9 Coinless (IPP) 10 LEC Prepaid Telecommunications Card Station 11 POTS Line - Business - message rate 2 Value Interpretation 12 LEC Public - Standard Interface - Prepay Overtime 13 LEC Public - Alternate Interface 14 IC Public - Standard Interface 15 IC Public -Alternate Interface 16 POTS line - Residential - flat rate 17 Voice Quote - without tax 18 Voice Quote - with tax 19 IPP - Standard Interface 20 IPP - Alternate Interface 21 Hospital 22 Prison (non-IPP) 23 Auto Quote - without tax 24 Auto Quote - with tax 25 Dormitory Line 26 Centrex Line 27 PBX Line 28 Prison (IPP) 29 WATS Line 30 Cellular 31 Pager 32 Personal Communication Service (PCS) 33 Feature Group A (FGA) 34 Mobile 35 LEC Public - Special Billing - Postpay Overtime Value Interpretation 36 LEC Public - Special Billing - Prepay Overtime 37 Public - Incompatible Network Interface 38 Cellular-Rate 1 39 Cellular-Rate 2 40 POTS Line - Business - Single-Line 41 POTS Line - Business - Multi-Line 42 Public-Postpay 255 Reserved MAP Fields MAP Ð First Leg Operation Code It represents the first operation invoked at MAP layer related to the first leg of the MAP transaction in case of correlated generation. Value Operation Name 2 updateLocation 3 cancelLocation 4 provideRoamingNumber 5 noteSubscriberDataModified 6 resumeCallHandling 7 insertSubscriberData 8 deleteSubscriberData 9 sendParameters 10 registerSS 11 eraseSS 12 activateSS Value Operation Name 13 deactivateSS 14 interrogateSS 15 authenticationFailureReport 17 registerPassword 18 getPassword 19 processUnstructuredSS-Data 20 ReleaseResources 21 mt-ForwardSM-VGCS 22 sendRoutingInfo 23 updateGprsLocation 24 sendRoutingInfoForGprs 25 failureReport 26 noteMsPresentForGprs 28 performHandover 29 sendEndSignal 30 performSubsequentHandover 31 provideSIWFSNumber 32 SIWFSSignallingModify 33 processAccessSignalling 34 forwardAccessSignalling 35 noteInternalHandover 37 reset 38 forwardCheckSS-Indication 39 prepareGroupCall 40 sendGroupCallEndSignal 41 processGroupCallSignalling 42 forwardGroupCallSignalling 43 checkIMEI Value Operation Name 44 MT-ForwardSM 45 sendRoutingInfoForSM 46 MO-ForwardSM 47 reportSM-DeliveryStatus 48 noteSubscriberPresent 49 alertServiceCentreWithoutResult 50 activateTraceMode 51 deactivateTraceMode 52 traceSubscriberActivity 54 beginSubscriberActivity 55 sendIdentification 56 sendAuthenticationInfo 57 restoreData 58 sendIMSI 59 processUnstructuredSSRequest 60 unstructuredSSRequest 61 unstructuredSSNotify 62 anyTimeSubscriptionInterrogation 63 informServiceCentre 64 alertServiceCentre 65 anyTimeModification 66 readyForSM 67 purgeMS 68 prepareHandover 69 prepareSubsequentHandover 70 provideSubscriberInfo 71 anyTimeInterrogation 72 SS-InvocationNotification 73 setReportingState Value Operation Name 74 statusReport 75 remoteUserFree 76 registerCC-Entry 77 eraseCC-Entry 78 secureTransportClass1 79 secureTransportClass2 80 secureTransportClass3 81 secureTransportClass4 83 provideSubscriberLocation 84 sendGroupCallInfo 85 sendRoutingInfoForLCS 86 subscriberLocationReport 87 IST-Alert 88 IST-Command 89 noteMM-Event 255 undefined field MAP Ð First Leg Application Error Code It represents the error code of the procedure at application layer (MAP) related to the first leg of the transaction in case of correlated generation. Value Error Name 1 unknownSubscriber 8 roamingNotAllowed 13 callBarred 15 cug-Reject 27 absentSubscriber 32 sm-DeliveryFailure Value Error Name 34 systemFailure 37 pw-RegistrationFailure 53 unauthorizedLCSClient 54 positionMethodFailure 21 facilityNotSupported 45 busySubscriber 31 subscriberBusyForMT-SMS 254 Invalid combination of Error Code and User ErrorReason MAP Ð First Leg Additional Error Reason This field specifies the error reason for those MAP transactions having error carrying additional information related to the first leg of the transaction in case of correlated generation. MAP Ð First Leg SMS Service Centre Time Stamp This filed is filled with the absolute time stamp that is offered to the recipient of a short message on when the message arrived at the SM-TL entity of the SC related to the first leg of the transaction in case of correlated generation. MAP Ð Last Leg Operation Code It represents the first operation invoked at MAP layer related to the last leg of the transaction in case of correlated generation. Value Operation Name 2 updateLocation 3 cancelLocation 4 provideRoamingNumber 5 noteSubscriberDataModified 6 resumeCallHandling 7 insertSubscriberData Value Operation Name 8 deleteSubscriberData 9 sendParameters 10 registerSS 11 eraseSS 12 activateSS 13 deactivateSS 14 interrogateSS 15 authenticationFailureReport 17 registerPassword 18 getPassword 19 processUnstructuredSS-Data 20 ReleaseResources 21 mt-ForwardSM-VGCS 22 sendRoutingInfo 23 updateGprsLocation 24 sendRoutingInfoForGprs 25 failureReport 26 noteMsPresentForGprs 28 performHandover 29 sendEndSignal 30 performSubsequentHandover 31 provideSIWFSNumber 32 SIWFSSignallingModify 33 processAccessSignalling 34 forwardAccessSignalling 35 noteInternalHandover 37 reset 38 forwardCheckSS-Indication 39 prepareGroupCall Value Operation Name 40 sendGroupCallEndSignal 41 processGroupCallSignalling 42 forwardGroupCallSignalling 43 checkIMEI 44 MT-ForwardSM 45 sendRoutingInfoForSM 46 MO-ForwardSM 47 reportSM-DeliveryStatus 48 noteSubscriberPresent 49 alertServiceCentreWithoutResult 50 activateTraceMode 51 deactivateTraceMode 52 traceSubscriberActivity 54 beginSubscriberActivity 55 sendIdentification 56 sendAuthenticationInfo 57 restoreData 58 sendIMSI 59 processUnstructuredSSRequest 60 unstructuredSSRequest 61 unstructuredSSNotify 62 anyTimeSubscriptionInterrogation 63 informServiceCentre 64 alertServiceCentre 65 anyTimeModification 66 readyForSM 67 purgeMS 68 prepareHandover Value Operation Name 69 prepareSubsequentHandover 70 provideSubscriberInfo 71 anyTimeInterrogation 72 SS-InvocationNotification 73 setReportingState 74 statusReport 75 remoteUserFree 76 registerCC-Entry 77 eraseCC-Entry 78 secureTransportClass1 79 secureTransportClass2 80 secureTransportClass3 81 secureTransportClass4 83 provideSubscriberLocation 84 sendGroupCallInfo 85 sendRoutingInfoForLCS 86 subscriberLocationReport 87 IST-Alert 88 IST-Command 89 noteMM-Event 255 undefined field MAP Ð Last Leg Application Error Code It represents the error code of the procedure at application layer (MAP) related to the first leg of the transaction in case of correlated generation. Value Error Name 1 unknownSubscriber 8 roamingNotAllowed Value Error Name 13 callBarred 15 cug-Reject 27 absentSubscriber 32 sm-DeliveryFailure 34 systemFailure 37 pw-RegistrationFailure 53 unauthorizedLCSClient 54 positionMethodFailure 21 facilityNotSupported 45 busySubscriber 31 subscriberBusyForMT-SMS 254 Invalid combination of Error Code and User ErrorReason MAP Ð Last Leg Additional Error Reason This field specifies the error reason for those MAP transactions having error carrying additional information related to the last leg of the transaction in case of correlated generation. MAP Ð Last Leg SMS Service Centre Time Stamp This filed is filled with the absolute time stamp that is offered to the recipient of a short message on when the message arrived at the SM-TL entity of the SC related to the last leg of the transaction in case of correlated generation. MAP - SMS Message Reference Number The TP Message Reference field gives an integer representation of a reference number of the SMS SUBMIT or SMS COMMAND submitted to the Service Centre by the Mobile station. MAP - GSM Absent Reason This parameter represents the reason why the subscriber is absent MAP - MSRN A Mobile Station Roaming Number (MSRN) is an E.164 defined telephone number used to route telephone calls in a mobile network from a GMSC (Gateway Mobile Switching Centre) to the target MSC. It can also be defined as a directory number temporarily assigned to a mobile for a mobile terminated call. (Reference GSM 09.02 V5.3.0, 8.3.3) MAP - USSD String This fields contains a string of unstructured information in an Unstructured Supplementary Service Data operation ItÕs filled by: Process Unstructured SS, Unstructured SS Request and Unstructured SS Notify whichever comes first in the sequence."
"Note: This field would be filled only in case of dcs value indicating 7-bit and will not be filled if in case dcs value is 8-bit/UCS2 as the support in application is temporarily not available. MAP - Service Centre Address This parameter designates the address of a short message service centre. This field may also be carried by SM-RP-DA and SM-RP-OA parameters. SMS Service Centre Address (Reference GSM 09.02, 5.6.2.27). MAP - SGSN Address This parameter designates the address of a SGSN. Update GPRS Location, Send Routing Info for GPRS and Note MS Present for GPRS messages may also carry this field. SGSN Address (Reference 3GPP TS 29.002 sec 7.6.2.39). MAP - GGSN Address This parameter designates the address of a GGSN. Update GPRS Location Failure Report and Note MS Present for GPRS messages may also carry this field. GGSN Address (Reference 3GPP TS 29.002 sec 7.6.2.40). MAP - Home GMLC Address This parameter refers to the IP address of Home Gateway mobile location centre. (3GPP TS 29.002 sec 7.6.2.61). ItÕs filled from: ProvideSubscriberLocation and SubscriberLocationReport operations. MAP - Visited GMLC Address This parameter refers to the IP address of Visitor Gateway mobile location centre. (3GPP TS 29.002 sec 7.6.2.59). ItÕs filled from: UpdateLocation, UpdateGprsLocation and RoutingInfoforLCS MAP - TP Origination Address Alphanumeric This field is filled from 'MAP_MO/MT_FORWARD_SHORT_MESSAGE and MT Forwared SM VGCSÕ in SM-RP-UI IE whichever comes first in the sequence. GSM 29.002, 7.6.2.11 Additional number: TS 100 974 V7.5.1, 7.6.2.46 + 12.1 MAP - TP Destination Address Alphanumeric This field is filled from 'MAP_MO/MT_FORWARD_SHORT_MESSAGE and MT Forwarded SM VGCSÕ in SM-RP-UI IE whichever comes first in the sequence. GSM 29.002, 7.6.2.11 Additional number: TS 100 974 V7.5.1, 7.6.2.46 + 12.1 MAP Ð TP Message Type Indicator This field specifies the SMS TP message type. MAP Ð SMS Delivery Time Interval This field identifies the SMS Delivery Time Interval by means of a lookup of the SMS Delivery Time field on MCLS table SMS Delivery Time Interval. MCLS Table: SMS Delivery Time Interval Standard Formatting: Column SDTI_INTERVAL_NAME SDTI _LOWER_VALUE SDTI _UPPER_VALUE Default value table: SMS Delivery Time Interval Name SMS Delivery Time Lower Value (s) SMS Delivery Time Upper Value (s) 0-6 s 0 6 7-11 s 7 11 12-30 s 12 30 >=30 30 Factor conversion: 1000 (from msec to sec) CAP Fields CAP - Operation Code It represents the first operation invoked at CAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement Value Operation Name 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest 56 ContinueWith Argument 60 initialDPSMS 61 furnish Charging InformationSMS 62 connectSMS 63 requestReportSMSEvent 64 eventReportSMS 65 continueSMS 66 releaseSMS 67 resetTimerSMS 70 activityTestGPRS 71 apply Charging GPRS 72 applyChargingReportGPRS 73 cancelGPRS 74 connectGPRS 75 continueGPRS 76 entityReleasedGPRS 77 furnishChargingInformationGPRS 78 initialDPGPRS 79 releaseGPRS 80 eventReportGPRS Value Operation Name 81 requestReportGPRSEvent 82 resetTimerGPRS 83 sendChargingInformationGPRS 90 DisconnectLeg 93 Move Leg 95 Split Leg 96 Entity Released 97 Play Tone 255 undefined field CAP - Last Operation Code It represents the last operation invoked at CAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 31 continue 32 InitiateCallAttempt Value Operation Name 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest 56 ContinueWith Argument 60 initialDPSMS 61 furnish Charging InformationSMS 62 connectSMS 63 requestReportSMSEvent 64 eventReportSMS 65 continueSMS 66 releaseSMS 67 resetTimerSMS 70 activityTestGPRS 71 apply Charging GPRS Value Operation Name 72 applyChargingReportGPRS 73 cancelGPRS 74 connectGPRS 75 continueGPRS 76 entityReleasedGPRS 77 furnishChargingInformationGPRS 78 initialDPGPRS 79 releaseGPRS 80 eventReportGPRS 81 requestReportGPRSEvent 82 resetTimerGPRS 83 sendChargingInformationGPRS 255 undefined field CAP - Operation Mask S.No Interpretation (Enumeration) Bit Position 1 Initial DP/GPRS/SMS 0 2 Apply charging / GPRS 1 3 Disconnect Forward Connection 2 4 ConnectToResource 3 5 Connect / GPRS /SMS 4 6 ReleaseCall / GPRS / SMS 5 7 Continue / GPRS / SMS 6 8 ResetTimer / GPRS /SMS 7 9 FurnishChargingInfo / GPRS / SMS 8 10 CallGap 9 11 CallInformationReport 10 S.No Interpretation (Enumeration) Bit Position 12 CallInformationRequest 11 13 PlayAnnouncement 12 14 PromptAddCollectUserInfo 13 15 SpecializedResourceReport 14 16 ActivityTest / GPRS 15 17 ApplyChargingReport / GPRS 16 18 Cancel / GPRS 17 19 AssistRequestInstructions 18 20 SendChargingInfo / GPRS 19 21 EntityReleasedGPRS 20 22 EventReportBCSM / GPRS / SMS 21 23 RequestReport BCSM/GPRS/SMS 22 24 EstablishTemporaryConnection 23 25 ContinueWithArgument 24 26 InitiateCallAttempt 25 27 DisconnectLeg 26 28 MoveLeg 27 29 SplitLeg 28 30 EntityReleased 29 31 PlayTone 30 32 Spare 31 CAP - Application Error Code It represents the error code of the procedure at application layer (CAP). Value Error Name 0 Cancelled 1 Cancel Failed 3 eTC Failed 4 Improper Caller Response 6 Missing Customer Record Value Error Name 7 Missing Parameters 8 Parameter Out of Range 10 Requested Info Error 11 System Failure 12 Task Refused 13 Unavailable Resource 14 Unexpected Component Sequence 15 Unexpected Data Value 16 Unexpected Parameter 17 Unknown Leg ID 50 Unknown PDP ID 51 Unknown CS ID CAP - Additional Error Reason This field specifies the error reason for those CAP transactions having error carrying additional information. Code Text 0 unknown Operation 1 tooLate 2 operationNotCancellable 3 unknownRequestedInfo 4 requestedInfoNotAvailable 5 unavailableResources 6 componentFailure Code Text 7 basicCallProcessingException 8 resourceStatusFailure 9 endUserFailure 10 generic 11 unobtainable 12 congestion CAP - Response Cause It is additional error at CAP layer. Release cause of CAP InitialDP, ReleaseCall, EventReportBCSM or CallInformationReport accordingly to Q.850. Cause value of RPcause of ReleaseSMS SMScause from EventSpecificInformation-SMS of EventReportSMS GPRScause of EntityReleasedGPRS or ReleaseGPRS Cause of ÒCallSegmentFailureÓ component present in ÒENTITY RELEASEDÓ ÒMO-SMSCauseÓ from ÒEventSpecificInformationSMSÓ of ÒEVENT REPORT SMSÓ ÒMT-SMSCauseÓ from ÒEventSpecificInformationSMSÓ of ÒEVENT REPORT SMSÓ Cause from ÒBCSM-FailureÓ of ÒENTITY RELEASEDÓ 1, unallocated (unassigned) number 2, no route to specified transit network 3, no route to destination 4, send special information tone 5, misdialled trunk prefix 6, channel unacceptable 7, call awarded and being delivered in an established channel 8, preemption 9, preemption - circuit reserved for reuse 16, normal call clearing 17, user busy 18, no user responding 19, no answer from user (user alerted) 20, subscriber absent 21, call rejected 22, number changed 26, non-selected user clearing 27, destination out of order 28, invalid number format (address incomplete) 29, facility rejected 30, response to STATUS ENQUIRY 31, normal, unspecified 34, no circuit/channel available 38, network out of order 39, permanent frame mode connection out of service 40, permanent frame mode connection operational 41, temporary failure 42, switching equipment congestion 43, access information discarded 44, requested circuit/channel not available 46, precedence call blocked 47, resource unavailable, unspecified 49, quality of service unavailable 50, requested facility not subscribed 53, outgoing calls barred within CUG 55, incoming calls barred within CUG 57, bearer capability not authorized 58, bearer capability not presently available 62, inconsistency in designated outgoing access information and subscriber class 63, service or option not availalbe, unspecified 65, bearer capability not implemented 66, channel type not implemented 69, requested facility not implemented 70, only restricted digital information bearer capability is available 79, service or option not implemented, unspecified 81, invalid call reference value 82, identified channel does not exist 83, A suspended call exists, but this call identity does not 84, call identity in use 85, no call suspended 86, call having the requested call identity has been cleared 87, user not member of CUG 88, incompatible destination 90, non-existent CUG 91, invalid transit network selection 95, invalid message, unspecified 96, mandatory information element is missing 97, message type non-existent or not implemented 98, message not compatible with call state or message type non-existent or not implemented 99, information element/parameter non-existent or not implemented 100, invalid information element contents 101, message not compatible with call state 102, recovery on timer expiry 103, parameter non-existent or not implemented, passed on 110, message with unrecognized parameter, discarded 111, protocol error, unspecified 127, interworking, unspecified 255, NO CC Cause CAP - Destination Routing Address C-party address (DestinationRoutingAddress). Filled From: Connect or DestinationSubscriberNumber from ConnectSMS or InitialDPSMS or part of EventSpecificInformation. Or EventReportBCSM CAP - Event Report Cause It is applicable for CAP CSDR only. Event Report Cause can be present in any of the sequence routeSelectFailureSpecificInfo, oCalledPartyBusySpecificInfo, oDisconnectSpecificInfo, tBusySpecificInfo, tDisconnectSpecificInfo and oAbandonSpecificInfo present in EventReportBCSM or CallInformationReport. EventReportCause Value Description 0 system failure 1 unallocated (unassigned) number 2 no route to specified transit network 3 no route to destination 4 send special information tone 5 misdialled trunk prefix 6 channel unacceptable 7 call awarded and being delivered in an established channel 8 preemption 9 preemption - circuit reserved for reuse 10 call barred 16 normal call clearing 17 user busy 18 no user responding 19 no answer from user (user alerted) 20 subscriber absent 21 call rejected EventReportCause Value Description 22 number changed 23 redirection to new destination 25 exchange routing error 26 non-selected user clearing 27 destination out of order 28 invalid number format (address incomplete) 29 facility rejected 30 response to STATUS ENQUIRY 31 normal, unspecified 34 no circuit/channel available 38 network out of order 39 permanent frame mode connection out of service 40 permanent frame mode connection operational 41 temporary failure 42 switching equipment congestion 43 access information discarded 44 requested circuit/channel not available 46 precedence call blocked 47 resource unavailable, unspecified 49 quality of service unavailable 50 requested facility not subscribed 53 outgoing calls barred within CUG 55 incoming calls barred within CUG 57 bearer capability not authorized EventReportCause Value Description 58 bearer capability not presently available 62 inconsistency in designated outgoing access information and subscriber class 63 service or option not availalbe, unspecified 65 bearer capability not implemented 66 channel type not implemented 69 requested facility not implemented 70 only restricted digital information bearer capability is available 79 service or option not implemented, unspecified 81 invalid call reference value 82 identified channel does not exist 83 A suspended call exists, but this call identity does not 84 call identity in use 85 no call suspended 86 call having the requested call identity has been cleared 87 user not member of CUG 88 incompatible destination 90 non-existent CUG 91 invalid transit network selection 95 invalid message, unspecified 96 mandatory information element is missing 97 message type non-existent or not implemented 98 message not compatible with call state or message type non-existent or not implemented EventReportCause Value Description 99 information element/parameter non-existent or not implemented 100 invalid information element contents 101 message not compatible with call state 102 recovery on timer expiry 103 parameter non-existent or not implemented, passed on 110 message with unrecognized parameter, discarded 111 protocol error, unspecified 127 interworking, unspecified 128 Request accepted 192 Non-existent 193 Invalid message format 194 IMSI not known 195 MS is GPRS Detached 196 MS is not GPRS Responding 197 MS Refuses 198 Version not supported 199 No resources available 200 Service not supported 201 Mandatory IE incorrect 202 Mandatory IE missing 203 Optional IE incorrect 204 System failure 205 Roaming restriction EventReportCause Value Description 206 P-TMSI Signature mismatch 207 GPRS connection suspended 208 Authentication failure 209 User authentication failed 210 Context not found 211 All dynamic PDP addresses are occupied 212 No memory is available 213 Relocation failure 214 Unknown mandatory extension header 215 Semantic error in the TFT operation 216 Syntactic error in the TFT operation 217 Semantic errors in packet filter(s) 218 Syntactic errors in packet filter(s) 219 Missing or unknown APN 220 Unknown PDP address or PDP type 221 PDP context without TFT already activated 222 APN access denied - no subscription 223 APN Restriction type incompatibility with currently active PDP Contexts 224 MS MBMS Capabilities Insufficient 225 Invalid Correlation-ID 226 MBMS Bearer Context Superseded 254 route not permitted CAP - Event Type The BCSM DP event triggering the InitialDP or the SMSEvent triggering the InitialDPSMS or the GPRSEvent triggering the InitialDPGPRS. In order to interpret this field the field OperationCode has to be taken into account. In case of CAMEL Phase 1 and 2, the following table is a reference for SRS. Code Text 1 orig Attempt Authorized 2 collect Info 3 analyzed Information 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect 18 TAbandon 255 undefined field CAP - Reported Event Code Text 1 orig Attempt Authorized 2 Collected Info 3 analyzed Information or detached 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 11 pdp-ContextEstablishment 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect 18 TAbandon 19 oTermSeized 27 callAccepted 50 oChangeOfPosition 51 tChangeOfPosition 255 Undefined field CAP Ð Cell Identity INAP Fields INAP - Operation Code It represents the first operation invoked at INAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 25 request notification charging event 26 event notification charging 27 collect information 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap Value Operation Name 42 activate service filtering 43 service filtering response 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest INAP - Last Operation Code It represents the last operation invoked at INAP layer. Value Operation Name 0 initialDP 16 assistRequestInstructions 17 establishTemporaryConnection 18 disconnectForwardConnection 19 connectToResource 20 connect 22 releaseCall 23 requestReportBCSMEvent 24 eventReportBCSM 25 request notification charging event Value Operation Name 26 event notification charging 27 collect information 31 continue 32 InitiateCallAttempt 33 resetTimer 34 furnish Charging Information 35 Apply Charging 36 applyChargingReport 41 callGap 42 activate service filtering 43 service filtering response 44 callInformationReport 45 callInformationRequest 46 send Charging Information 47 playAnnouncement 48 promptAndCollect UserInformation 49 specializedResourceReport 53 cancel 55 activityTest INAP - Operation Mask1 By Default Opcode values refer to ETSI INAP (including CZECH INAP), for other INAP variants it is mentioned specifically. If it is unknown, opcode for particular variant it is not mentioned for that particular bit. Bit Position Opcode 0 (LSB) Initial DP In CHINA INAP: Initial DP In Siemens INAP: Initial DP In INAP LW: Initial DP In INAPCS1P: Initial DP In INAPCS2: Initial DP 1 In EINAPV21: Activate Resource In INAPCS2: OriginationAttemptAuthorized In INAPCS1P: ApplyCharging 2 In EINAPV21: Activity Test In INAPCS1P: ConnectToResource In INAPCS2: CollectedInformation 3 In EINAPV21: CongestionControl In INAP LW: Connect In INAPCS1P: Connect In INAPCS2: AnalysedInformation 4 In EINAPV21: Create In INAP LW: ReleaseCall In INAPCS1P: ReleaseCall In INAPCS2: RouteSelectFailure 5 In EINAPV21: Event In INAP LW: Continue In INAPCS1P: Continue In INAPCS2: OcalledPartyBusy 6 In EINAPV21: Free In INAP LW: ResetTimer In INAPCS1P: ResetTimer In INAPCS2: Onoanswer 7 In EINAPV21: Generate In INAPCS1P: FurnishChargingInformation Bit Position Opcode In INAPCS2: Oanswer 8 In EINAPV21: HandOver In INAPCS1P: CallGap In INAPCS2: Odisconnect 9 In EINAPV21: ChargingInformation In INAPCS1P: CallInformationReport In INAPCS2: TermAttemptAuthorized 10 In EINAPV21: Join In INAPCS1P: CallInformationRequest In INAPCS2: Tbusy 11 In EINAPV21: Monitor In INAPCS1P: Playannouncement In INAPCS2: Tnoanswer 12 In EINAPV21: OpenSpecificFunction In INAPCS1P: PromptAndCollectUserInformation In INAPCS2: Tanswer 13 In EINAPV21: ProvideInstructions In INAPCS1P: SpecializedResourceReport In INAPCS2: Tdisconnect 14 In EINAPV21: ReleaseResource In INAPCS1P: ApplyChargingReport In INAPCS2: Omidcall 15 In EINAPV21: Reset Timer In INAPCS1P: Cancel In INAPCS2: Tmidcall 16 AssistRequestInstructions In CHINA INAP: AssistRequestInstructions In Siemens INAP: AssistRequestInstructions In EINAPV21: Retrieve Bit Position Opcode In INAPCS2: AssistRequestInstructions In INAPCS1P: AssistRequestInstructions 17 EstablishTemporaryConnection In CHINA INAP: EstablishTemporaryConnection In Siemens INAP: EstablishTemporaryConnection In EINAPV21: SCF Reset Indication In INAPCS2: EstablishTemporaryConnection In INAPCS1P: SendChargingInformation 18 DisconnectForwardConnection In CHINA INAP: DisconnectForwardConnection In EINAPV21: Split In Siemens INAP: DisconnectForwardConnection In INAPCS2: DisconnectForwardConnection In INAPCS1P: EventReportBcsm 19 ConnectToResource In CHINA INAP: ConnectToResource In EINAPV21: SSF Reset Indication In INAPCS2: ConnectToResource In INAPCS1P: RequestReportBcsmEvent 20 Connect In CHINA INAP: Connect In EINAPV21: Transfer Control In Siemens INAP: Connect In INAPCS2: Connect In INAPCS1P: EstablishTemporaryConnection 21 In EINAPV21: Update In INAPCS2: HoldCallInNetwork In INAPCS1P: ActivateServiceFiltering 22 ReleaseCall In CHINA INAP: ReleaseCall Bit Position Opcode In EINAPV21: Backward Information In Siemens INAP: ReleaseCall In INAPCS2: ReleaseCall In INAPCS1P: CollectInformation 23 RequestReportBCSMEvent In EINAPV21: Call Control In CHINA INAP: RequestReportBCSMEvent In Siemens INAP: RequestReportBCSMEvent In INAPCS2: RequestReportBCSMEvent In INAPCS1P: EventNotificationCharging 24 EventReportBCSM In CHINA INAP: EventReportBCSM In Siemens INAP: EventReportBCSM In INAPCS2: EventReportBCSM In INAPCS1P: InitiateCallAttempt 25 RequestNotificationChargingEvent In Siemens INAP: RequestNotificationChargingEvent In INAPCS2: RequestNotificationChargingEvent In INAPCS1P: ServiceFilteringResponse 26 EventNotificationCharging In INAPCS2: EventNotificationCharging In Siemens INAP: EventNotificationCharging In INAPCS1P: RequestNotificationChargingEvent 27 CollectInformation In CHINA INAP: CollectInformation In Siemens INAP: CollectInformation In INAPCS2: CollectInformation In INAPCS1P: DisconnectForwardConnection 28 In INAPCS2: AnalyseInformation In INAPCS1P: ActivityTest Bit Position Opcode 29 In INAPCS2: SelectRoute 30 In INAPCS2: SelectFacility 31 Continue In CHINA INAP: Continue In Siemens INAP: Continue In INAPCS2: Continue INAP - Operation Mask2 Bit Position Opcode 0 InitiateCallAttempt In CHINA INAP: InitiateCallAttempt In Siemens INAP: InitiateCallAttempt In INAPCS2P: InitiateCallAttempt In INAPCS1P: Retrive 1 ResetTimer In CHINA INAP: ResetTimer In Siemens INAP: ResetTimer In INAPCS2: ResetTimer In INAPCS1P: Update 2 FurnishChargingInformation In CHINA INAP: FurnishChargingInformation In Siemens INAP: FurnishChargingInformation In INAPCS2: FurnishChargingInformation In INAPCS1P: CallLimit 3 ApplyCharging In CHINA INAP: ApplyCharging In Siemens INAP: ApplyCharging In INAPCS2P: ApplyCharging In INAPCS1P: DialogueUserInformation Bit Position Opcode 4 ApplyChargingReport In CHINA INAP: ApplyChargingReport In Siemens INAP: ApplyChargingReport In INAPCS2: ApplyChargingReport In INAPCS1P: HandOver 5 In INAPCS2: RequestCurrentStatusReport In INAPCS1P: HoldCallPartyConnection 6 In INAPCS1P: Reconnect In INAPCS2: RequestEveryStatusChangeReport 7 In INAPCS1P: ReleaseCallPartyConnection In INAPCS2: RequestFirstStatusMatchReport 8 In INAPCS1P: SignallingInformation In INAPCS2: StatusReport 9 CallGap In CHINA INAP: CallGap In INAPCS2: CallGap In Siemens INAP: CallGap In INAP LW: Continue With Argument In INAPCS1P: Continue With Argument 10 ActivateServiceFiltering In CHINA INAP: ActivateServiceFiltering In Siemens INAP: ActivateServiceFiltering In INAPCS2: ActivateServiceFiltering 11 ServiceFilteringResponse In CHINA INAP: ServiceFilteringResponse In Siemens INAP: ServiceFilteringResponse In INAPCS2: ServiceFilteringResponse 12 CallInformationReport In CHINA INAP: CallInformationReport Bit Position Opcode In INAPCS2: CallInformationReport In Siemens INAP: CallInformationReport 13 CallInformationRequest In CHINA INAP: CallInformationRequest In INAPCS2: CallInformationRequest In Siemens INAP: CallInformationRequest 14 SendChargingInformation In CHINA INAP: SendChargingInformation In Siemens INAP: SendChargingInformation In INAPCS2: SendChargingInformation 15 PlayAnnouncement In CHINA INAP: PlayAnnouncement In INAPCS2: PlayAnnouncement In Siemens INAP: PlayAnnouncement 16 PromptAndCollectUserInformation In CHINA INAP: PromptAndCollectUserInformation In Siemens INAP: PromptAndCollectUserInformation In INAPCS2: PromptAndCollectUserInformation 17 SpecializedResourceReport In CHINA INAP: SpecializedResourceReport In Siemens INAP: SpecializedResourceReport In INAPCS2: SpecializedResourceReport 18 Unknown opcode 19 Unknown opcode 20 Unknown opcode 21 Cancel In CHINA INAP: Cancel In Siemens INAP: Cancel In INAPCS2: Cancel Bit Position Opcode 22 In INAPCS2: CancelStatusReportRequest 23 ActivityTest In CHINA INAP: ActivityTest In Siemens INAP: ActivityTest In INAPCS2: ActivityTest 24 In Siemens INAP: ContinueWithArgument 25 Unknown opcode 26 Unknown opcode 27 Unknown opcode 28 In Siemens INAP: InitialDpSms 29 In Siemens INAP: FurnishChargingInformationSms 30 In Siemens INAP: ConnectSms 31 In Siemens INAP: RequestReportSmsEvent INAP - Operation Mask3 Bit Position Opcode 0 In Siemens INAP: EventReportSms 1 In Siemens INAP: ContinueSms 2 In Siemens INAP: ReleaseSms 3 In Siemens INAP: ResetTimerSms 4 Unknown opcode 5 Unknown opcode 6 In Siemens INAP: ActivityTestGprs 7 In Siemens INAP: ApplyChargingGprs 8 In Siemens INAP: ApplyChargingReportGprs Bit Position Opcode 9 In Siemens INAP: CancelGprs 10 In Siemens INAP: ConnectGprs 11 In Siemens INAP: ContinueGprs 12 In Siemens INAP: EntityReleasedGprs 13 In Siemens INAP: FurnishChargingInformationGprs 14 In Siemens INAP: InitialDpGprs 15 In Siemens INAP: ReleaseGprs 16 In Siemens INAP: EventReportGprs In INAPCS2: FacilitySelectedAndAvailable 17 In Siemens INAP: RequestReportGprsEvent In INAPCS2: OriginationAttempt 18 In Siemens INAP: ResetTimerGprs In INAPCS2: TerminationAttempt 19 In Siemens INAP: SendChargingInformationGprs In INAPCS2: Oabandon 20 In INAPCS2: Osuspended 21 In INAPCS2: Tsuspended 22 In Siemens INAP: DisconnectForwardConnectionWithArgument In INAPCS2: DisconnectForwardConnectionWithArgument 23 In INAPCS2: AuthorizeTermination 24 In Siemens INAP: ContinueWithArgument In INAPCS2: ContinueWithArgument 25 In INAPCS2: CreateCallSegmentAssociation 26 In Siemens INAP: DisconnectLeg In INAPCS2: DisconnectLeg Bit Position Opcode 27 In Siemens INAP: MergeCallSegments In INAPCS2: MergeCallSegments 28 In INAPCS2: MoveCallSegments 29 In CHINA INAP: ALC Split In INAPCS2: MoveLeg 30 In INAPCS2: Reconnect 31 In Siemens INAP: SplitLeg In INAPCS2: SplitLeg INAP - Operation Mask4 Bit Position Opcode 0 In Siemens INAP: EntityReleased In INAPCS2: EntityReleased 1 In INAPCS2: ManageTriggerData 2 In CHINA INAP: ALC Join In Siemens INAP: ManageTriggerData In INAPCS2: RequestReportUtsi 3 In CHINA INAP: ALC Free In Siemens INAP: ReleaseLeg 4 In INAPCS2: SendStui 5 In INAPCS2: ReportUtsi 6 In INAPCS2: SendFacilityInformation 7 In INAPCS2: RequestReportFacilityEvent 8 In INAPCS2: EventReportFacility 9 Unknown opcode 10 In INAPCS2: SendComponent Bit Position Opcode 11 In INAPCS2: PromptAndReceiveMessage 12 In INAPCS2: ScriptInformation 13 In Siemens INAP: ScriptEvent In INAPCS2: ScriptEvent 14 In Siemens INAP: ScriptRun In INAPCS2: ScriptRun 15 In INAPCS2: ScriptClose 16 In INAPCS2: EstablishChargingRecord 17 In INAPCS2: HandlingInformationRequest 18 In INAPCS2: HandlingInformationResult 19 In INAPCS2: NetworkCapability 20 In INAPCS2: NotificationProvided 21 In INAPCS2: ConfirmedNotificationProvided 22 In INAPCS2: ProvideUserInformation 23 In INAPCS2: ConfirmedReportChargingInformation 24 In INAPCS2: ReportchargingInformation 25 In INAPCS2: RequestNotification 26 In INAPCS2: ActivationReceivedAndAuthorized 27 In INAPCS2: InitiateAssociation 28 In INAPCS2: AssociationReleaseRequested 29 In INAPCS2: ComponentReceived 30 In INAPCS2: ReleaseAssociation 31 In INAPCS2: RequestReportBcusmEvent INAP - Application Error Code It represents the error code of the procedure at INAP application layer. INAP - Additional Error Reason This field specifies the error reason for those INAP transactions having error carrying additional information. Code Text 0 unknown Operation 1 tooLate 2 operationNotCancellable 3 unknownRequestedInfo 4 requestedInfoNotAvailable 5 unavailableResources 6 componentFailure 7 basicCallProcessingException 8 resourceStatusFailure 9 endUserFailure 10 generic 11 unobtainable 12 congestion INAP - Response Cause Indicates the reason for the release at INAP Layer. Release cause of EventReportBCSM or CallInformationReport or ReleaseCall. In case INAP LW only ReleaseCall can fill this field. In EINAPV21 this field is filled from CauseIndicator of Event / Free message, whichever comes first in the sequence. In China Inap, ALCFree can also fill this field. In INAPCS2, this field is filled from DisconnectLeg, OAbandon, ODisconnect, ReleaseCall, TDisconnect, EventReportBCSM, CallGap, ActivateServiceFiltering, NotificationProvidedMsg messages. INAP - Destination Routing Address INAP - Event Type The BCSM DP event triggering the InitialDP or the SMSEvent triggering the InitialDPSMS or the GPRSEvent triggering the InitialDPGPRS. In order to interpret this field the field OperationCode has to be taken into account. In case of CAMEL Phase 1 and 2, the following table is a reference for SRS. Code Text 1 orig Attempt Authorized 2 collect Info 3 analysed Information 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer Code Text 16 TMidCall 17 TDisconnect 18 TAbandon 255 undefined field INAP - Reported Event Code Text 1 orig Attempt Authorized 2 Collected Info 3 analyzed Information or detached 4 route SelectFailure 5 OCalled Party Busy 6 ONoAnswer 7 OAnswer 8 OMidCall 9 ODisconnect 10 OAbandon 11 pdp-ContextEstablishment 12 term Attempt Authorized 13 TCalled Par tyBusy 14 tnoAnswer 15 TAnswer 16 TMidCall 17 TDisconnect Code Text 18 TAbandon 19 oTermSeized 27 callAccepted 50 oChangeOfPosition 51 tChangeOfPosition 255 Undefined field INAP - Generic Number CSDR Type CSDR field Description INAP_CSDR GENERIC_NUMBER This field contains the Number information sent in either direction to enhance network operation or for supplementary services Common Measures Common Ð Success The success field is used in conjunction with each data record type to categorize a data record transaction as successful or not. CSDR Type = CAP Value Name Success Failure 1 CAP Mobile Originating Call See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 2 CAP Mobile Terminating Call See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 3 CAP Mobile Originating SMS See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 4 CAP Mobile Terminating SMS See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 5 CAP MS Initiated PDP Context Activation See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table 6 CAP NW Initiated PDP Context Activation See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table Value Name Success Failure 99 Other CAP procedure See CAP Success Rule at the end of this table See CAP Failure Rule at the end of this table CAP Success Rule A CAP transaction is considered ""successful"" when no errors occurred at CAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( CAP_ER_CODE is Empty OR (CAP_ER_CODE is NOT Network Error AND CAP_ER_CODE is NOT User Error) ) AND ( CAP_ER_REASON is Empty OR (CAP_ER_REASON is NOT Network Error AND CAP_ER_REASON is NOT User Error) ) AND ( CAP_CAUSE is Empty OR (CAP_CAUSE is NOT Network Error AND CAP_CAUSE is NOT User Error) ) AND ( TCAP_ABORT_CAUSE is Empty OR (TCAP_ABORT_CAUSE is NOT Network Error AND TCAP_ABORT_CAUSE is NOT User Error) ) AND ( SCCP_RETCAUSE is Empty OR (SCCP_RETCAUSE is NOT Network Error AND SCCP_RETCAUSE is NOT User Error) ) CAP Failure Rule A CAP transaction is considered ""Failed"" when an error occurred at CAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (CAP_ER_CODE is Network Error OR CAP_ER_CODE is User Error) ) OR ( (CAP_ER_REASON is Network Error OR CAP_ER_REASON is User Error) ) OR ( (CAP_CAUSE is Network Error OR CAP_CAUSE is User Error) ) OR ( (TCAP_ABORT_CAUSE is Network Error OR TCAP_ABORT_CAUSE is User Error) ) OR ( (SCCP_RETCAUSE is Network Error OR SCCP_RETCAUSE is User Error) ) CSDR Type = MAP Value Name Success Failure 100 MAP Update Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 101 MAP Cancel Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 102 MAP Provide Roaming Number See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 103 MAP Register SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 104 MAP Erase SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 105 MAP Activate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table Value Name Success Failure 106 MAP Deactivate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 107 MAP Interrogate SS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 108 MAP Send Routing Info See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 109 MAP Update GPRS Location See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 110 MAP Send Routing Info For GPRS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 111 MAP Mobile Terminating SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 112 MAP Send Routing Info For SM See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 113 MAP Mobile Originating SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table Value Name Success Failure 114 MAP Authentication See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 115 MAP Process Unstructured SS Request See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 116 MAP Unstructured SS Request See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 117 MAP Unstructured SS Notify See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 118 MAP Send Routing Info For LCS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 119 MAP Subscriber Location Report See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 120 MAP Ð Correlated SMS See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table 199 Other MAP procedure See MAP Success Rule at the end of this table See MAP Failure Rule at the end of this table MAP Success Rule A MAP transaction is considered ""successful"" when no errors occurred at MAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( MAP_ SCCP_RETCAUSE is Empty OR (MAP_ SCCP_RETCAUSE is NOT Network Error AND MAP_ SCCP_RETCAUSE is NOT User Error) ) AND ( MAP_ TCAP_ABORT_CAUSE is Empty OR (MAP_ TCAP_ABORT_CAUSE is NOT Network Error AND MAP_ TCAP_ABORT_CAUSE is NOT User Error) ) AND ( MAP_ER_CODE is Empty OR (MAP_ ER_CODE is NOT Network Error AND MAP_ ER_CODE is NOT User Error) ) MAP Failure Rule A MAP transaction is considered ""Failed"" when an error occurred at MAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (MAP_ SCCP_RETCAUSE is Network Error OR MAP_ SCCP_RETCAUSE is User Error) ) OR ( (MAP_ TCAP_ABORT_CAUSE is Network Error OR MAP_ TCAP_ABORT_CAUSE is User Error) ) OR ( (MAP_ ER_CODE is Network Error OR MAP_ ER_CODE is User Error) ) CSDR Type = INAP Value Name Success Failure 200 INAP Initial DP See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table 201 INAP Retrieve/Assist Request Instructions See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table 299 Other INAP procedure See INAP Success Rule at the end of this table See INAP Failure Rule at the end of this table INAP Success Rule An INAP transaction is considered ""successful"" when no errors occurred at INAP, TCAP, SCCP layers, and when the transaction is complete (that is, no messages are missing) VIOLATION=0 (No Violation) AND ( INAP_ER_CODE is Empty OR (INAP_ER_CODE is NOT Network Error AND INAP_ER_CODE is NOT User Error) ) AND ( INAP_ER_REASON is Empty OR (INAP_ER_REASON is NOT Network Error AND INAP_ER_REASON is NOT User Error) ) AND ( INAP_CAUSE is Empty OR (INAP_CAUSE is NOT Network Error AND INAP_CAUSE is NOT User Error) ) AND ( TCAP_ABORT_CAUSE is Empty OR (TCAP_ABORT_CAUSE is NOT Network Error AND TCAP_ABORT_CAUSE is NOT User Error) ) AND ( SCCP_RETCAUSE is Empty OR (SCCP_RETCAUSE is NOT Network Error AND SCCP_RETCAUSE is NOT User Error) ) INAP Failure Rule An INAP transaction is considered ""Failed"" when an error occurred at INAP, TCAP or SCCP layers, or when the transaction is not complete (that is, some messages are missing). It is the complementary of the success rule. VIOLATION is NOT 0 OR ( (INAP_ER_CODE is Network Error OR INAP_ER_CODE is User Error) ) OR ( (INAP_ER_REASON is Network Error OR INAP_ER_REASON is User Error) ) OR ( (INAP_CAUSE is Network Error OR INAP_CAUSE is User Error) ) OR ( (TCAP_ABORT_CAUSE is Network Error OR TCAP_ABORT_CAUSE is User Error) ) OR ( (SCCP_RETCAUSE is Network Error OR SCCP_RETCAUSE is User Error) ) CSDR Type = TCAP-AP Value Name Success Failure 300 TCAP-AP traffic TCAPAP_APPL_ERROR_CODE is NOT Network Error OR is EMPTY TCAPAP_APPL_ERROR_CODE is Network Error CSDR Type = BELL TCAP-OP Value Name Success Failure 400 TCAP OP Query (CNAM Service) (OP_ERROR_CODE is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) OP_ERROR_CODE is Network Error OR BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL TCAP-800 Value Name Success Failure 500 TCAP 800 Query (Toll Free Call) (ERROR_CODE_800 is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) ERROR_CODE_800 is Network Error OR BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL TCAP-800 Value Name Success Failure 600 AIN Query (ER_CODE is NOT Network Error OR is EMPTY) AND ER_CODE is Network Error OR Value Name Success Failure (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) BTCAP_REJECT_PROBLEM is Network Error CSDR Type = BELL LIDB Value Name Success Failure 700 LIDB Query (LIDB_ERROR_CODE is NOT Network Error OR is EMPTY) AND (BTCAP_REJECT_PROBLEM is NOT Network Error OR is EMPTY) LIDB_ERROR_CODE is Network Error OR BTCAP_REJECT_PROBLEM is Network Error Common - Transaction Duration This field holds the time difference between the first and last message in the sequence (in units of milliseconds). This means that, in case of timeout sequences, the timer value will not be included in TransactionTime calculation. Common - Response Time Time in millisecond from the first invoke operation to the next operation in the other direction in case of full sequences. Common Ð Conversation Time It represents the total talk time for a MO/MT call (CAP/INAP layers). Common - Total Length of SCCP Messages It is the total length of SCCP messages in forward and backward direction. Common - Length of SCCP FWD Messages It is the total length of SCCP messages in forward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Length of SCCP BWD Messages It is the total length of SCCP messages in backward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Number of SCCP Messages It is the total number of SCCP messages in forward and backward direction. Common - Number of SCCP FWD Messages It is the total number of SCCP messages in forward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP PDU message to be captured by 2 different probes, otherwise we risk to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common - Number of SCCP BWD Messages It is the total number of SCCP messages in backward direction. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP message to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same SCCP message to be present in more than one correlated MAP CSDR. Common Ð Answered Call Applicable protocol: CAP, INAP This flag indicates if a call is either answe or not for CAP and INAP protocols. Common Ð Dropped Call Applicable protocol: CAP, INAP This flag indicates if a call is either dropped or not for CAP and INAP protocols. Note: a call can be considered droppped only when it is answered. MAP Measures MAP - SMS Payload Size This field contains the length of TP-UDL in octets from SM-RP-UI parameter. MAP Ð Number of MO SMS This field contains the number of SMS submitted by the subscriber."
"Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP Ð MO SMS Success This field indicates if the MO SMS was successfully submitted to the service centre. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP - Number of MT SMS This field counts the number of MT SMS delivered by the service centre. Note: in case of multiple correlated MAP CSDRs this field is correctly filled only if the probe deploy has been made in such a way that it is not possible for the same MAP SMS messages to be captured by 2 different probes, otherwise it is possible to count twice the same SCCP message. It must not be possible for the same MAP SMS message to be present in more than one correlated MAP CSDR. MAP Ð MT SMS Success This field indicates if the MT SMS was successfully delivered to the final user. Note: MT SMS status report are not included in this measure, for those transactions use instead the Data Record Type 111 and Common- Success. MAP - Number of Concatenated SMS The number of concatenated SMS is calculated according to the last 5 bits of [MAP].FLAGS2 CSDR field converted in decimal. 16,17,18,19,20 Concatenated SMS Count 0 - No SMS 1 - SMS not concatenated 2 - 2 Concatenated SMS 3 - 3 Concatenated SMS 4 - 4 Concatenated SMS 5 - 5 Concatenated SMS 6 - 6 Concatenated SMS 7 - 7 Concatenated SMS 8 - 8 Concatenated SMS 9 - 9 Concatenated SMS 10 - 10 Concatenated SMS 11 - 11 Concatenated SMS 12 - 12 Concatenated SMS 13 Ð 13 Concatenated SMS 14 - 14 Concatenated SMS 15 - 15 Concatenated SMS 16 - 16 Concatenated SMS 17 - 17 Concatenated SMS 18 - 18 Concatenated SMS 19 - 19 Concatenated SMS 20 - 20 Concatenated SMS 21 - 21 Concatenated SMS 22 - 22 Concatenated SMS 23 - 23 Concatenated SMS 24 - 24 Concatenated SMS 25 - 25 Concatenated SMS 26 - 26 Concatenated SMS 27 - 27 Concatenated SMS 28 - 28 Concatenated SMS 29 - 29 Concatenated SMS 30 - 30 Concatenated SMS 31 - 31 or more concatenated SMS Description: This subfield represents the number of short messages in Long SMS which is filled from IE Maximum number of Short message. This value might differ from Number of MO SMS messages, Number of MT SMS messages CSDR fields. As the ÔMaximum number of Short messageÕ IE represents the total number of expected SM in entire sequence (and is same in all subsequent messages in sequence), the number will be accurate even when messages are missing in Sequence due to loadsharing. No additional computing at QXTS/QXDRS is required for this field. MAP Ð SMS Submit Time This field specifies the time needed to submit an SMS and it is calculated as the MAP transaction duration needed to forward the MO SMS to the Service Centre. MAP Ð SMS Delivery Time This field specifies the time needed to deliver the SMS and it is calculated as the time difference between ÒEnd Time Stamp Ð TP Service Centre TimeStampÓ in milliseconds 4 MCLS Enrichments for eoLive Cell MC table: Cell (Miner=YES) Lookup Type: Match Lookup DR Key MCLS Key Enriched description prefix CAP_CELL_IDENTITY Cell-ID CAP Ð Cell Identity Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Cell Name WITHRANK NO YES Type Type ALWAYS YES YES Group Cell Group ALWAYS NO YES Paging Domain Paging Domain ALWAYS NO YES Paging Area Code Paging Domain Code WITHRANK NO YES PLMN PLMN ID ALWAYS NO YES Radio Controller Node ID Radio Node ID WITHRANK NO NO Radio Controller Node Name Radio Node Name WITHRANK NO YES Core Node ID Controlling Node ID WITHRANK NO NO Core Node Name Controlling Node Name WITHRANK NO YES Core Pool Name Core Network Node Pool ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Latitude Latitude WITHRANK NO YES Longitude Longitude WITHRANK NO YES Broadcast Power Broadcast Power WITHRANK NO YES Azimuth Azimuth WITHRANK NO YES Beam Width Beam Width WITHRANK NO YES Frequency Bands Frequency Bands ALWAYS NO YES Region Region ALWAYS NO YES Manufacturer Manufacturer ALWAYS NO YES Operational Status Operational Status ALWAYS NO YES City City ALWAYS NO YES Province Province ALWAYS NO YES ZIP Code ZIP Code ALWAYS NO YES LAC LAC WITHRANK NO NO SAC SAC WITHRANK NO NO Note: Manufacturer, Operational Status, City, Province and ZIP Code are available only from MasterClaw 8.0. The miner functions (implemented either by MCLS or by DWH) will fill the following columns: á Name: It will be filled by CAP_CELL_IDENTITY á Paging Domain: It will be filled by [CAP].LOCATION_AREA_ID CSDR field Service Key MC table: ServiceKey (Miner=NO) Lookup Type: Match Key MCLS Key Enriched description prefix SERVICE_KEY Service_Key Common - Service Standard Formatting: Display Name Internal Name Aggregation Rank Enum Visible for Application (eoLive/BO) Name Name ALWAYS NO NO Group Group ALWAYS NO NO Layer Layer ALWAYS NO NO Cause MC table: Cause (Miner=NO) Lookup Type: Match Lookup DR Key MCLS Key Enriched description prefix ÒSCCP_RET_CAUSE: Ó + SCCP_RETCAUSE ID Common - SCCP Return Cause ÒTCAP: Ó + TCAP_ABORT_CAUSE Common - TCAP Abort Cause ÒTCAP_APPL: Ò + TCAPAP_APPL_ERROR_CODE TCAP AP - Application Error Code ÒBELL_TCAP_APPL: Ò + BTCAP_APPL_ERROR_CODE BELL TCAP - Application Error Code ÒBELL_TCAP_REJ: Ò + BTCAP_REJECT_PROBLEM BELL TCAP Ð Reject Problem ÒBELL_TCAP_800: Ò + BTCAP_TCAP_800_TERMINATION_INDICATOR BELL TCAP Ð TCAP 800 Termination Indication ÒBELL_TCAP_AIN: Ò + BTCAP_AINT_ERROR_CAUSE BELL TCAP - AIN Error Cause ÒMAP: Ò + MAP_FL_ER_CODE MAP - First Leg Application Error Code ÒMAP_USER_ERR: Ò + MAP_FL_USRERR_REASON MAP Ð First Leg Additional Error Reason ÒMAP: Ò + MAP_LL_ER_CODE MAP - Last Leg Application Error Code ÒMAP_USER_ERR: Ò + MAP_LL_USRERR_REASON MAP Ð Last Leg Additional Error Reason ÒCAP: Ò + CAP_ER_CODE CAP - Application Error Code ÒINAP_CAP_ADD_ERR: Ò + CAP_ER_REASON CAP - Additional Error Reason ÒQ.931: Ò + CAP_CAUSE CAP - Response Cause ÒQ.931: Ò + CAP_EVENT_REPORT_CAUSE CAP - Event Report Cause ÒINAP: Ò + INAP_ER_CODE INAP - Application Error Code ÒINAP_CAP_ADD_ERR: Ò + INAP_ER_REASON INAP - Additional Error Reason ÒQ.931: Ò + INAP_CAUSE INAP - Response Cause Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Type Type ALWAYS YES YES Code Code ALWAYS YES NO Description Name NEVER NO NO Group Group ALWAYS NO YES is Network Error NetworkError ALWAYS YES YES is User Error UserError ALWAYS YES YES Next Best Action Next best action NO is Drop Error DropError ALWAYS YES YES OperatorE212 MC Table: OperatorE212 (Miner= NO) Lookup Type: Prefix (for IMSI), Match (for PLMN_ID) DR Lookup Key MCLS Key Enriched description prefix IMSI Prefix Common Ð Subscriber PLMN_ID Common Ð PLMN ID Remember: All enriched fields of PLMN_ID must be NOT visible on eoLive/eoFinder Applications. ONLY the enriched field ÒCommon Ð PLMN ID Operator is HomeÓ is visible in eoLive/eoFinder Applications, because it is used in eoxdr component for the eoRoaming-CP-Core-SDR generation. Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Prefix Prefix ALWAYS NO YES Operator Name Name ALWAYS NO YES Operator Country Name Country ALWAYS NO YES Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES Operator MCC MCC ALWAYS NO YES Operator MNC MNC ALWAYS NO YES Operator Country Code CC ALWAYS NO NO (visible only in eoSight/InSight) Device MC Table: Device (Miner=ON) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix TAC TAC Common - Device Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Manufacturer Manufacturer ALWAYS NO YES Model Model WITH RANK NO YES Terminal Type Terminal Type ALWAYS YES YES OS Vendor OS Vendor ALWAYS NO YES OS Type OS Type ALWAYS YES YES OS Version OS Version ALWAYS NO YES GSM GSM ALWAYS YES YES UMTS UMTS ALWAYS YES YES LTE LTE ALWAYS YES YES Frequency Bands Frequency Bands ALWAYS NO NO Display Size Primary Display Size ALWAYS NO YES Group Group ALWAYS NO YES Test Group Test Group ALWAYS NO YES Make and Model MakeAndModel WITH RANK NO YES CertifiedDevice MC Table: CertifiedDevice (Miner = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix IMEI IMEI Common Ð Certified Device Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) TAC TAC WITH RANK NO NO Serial Number Serial Number ALWAYS NO NO Software Version Software Version ALWAYS NO YES is Subsidized Subsidized ALWAYS YES YES is Certified Certified ALWAYS YES YES MobileSubscriber MC Table: MobileSubscriber (Miner = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix IMSI IMSI Common - Subscriber Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Name WITH FILTER NO YES Gender Gender ALWAYS YES YES Birth Date Birth Date WITH RANK NO YES Birth Place Birth Place WITH RANK NO YES Home Place Home Place WITH RANK NO YES Subscription Start Date Subscription start date WITH RANK NO YES Type Type ALWAYS YES YES Importance Importance ALWAYS YES YES Enterprise Name Enterprise name WITH RANK NO YES Department Name Enterprise part WITH RANK NO YES Plan Plan ALWAYS NO YES Options Options WITH RANK NO YES Notes Notes WITH RANK NO YES Tariff Tariff Plan ALWAYS YES YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Service Segment Service Segment ALWAYS YES YES Enterprise Importance Enterprise Importance ALWAYS YES YES Department Importance Enterprise part Importance ALWAYS YES YES Enterprice Description Enterprice Description NEVER NO NO Enterprice Part Description Enterprice part Description NEVER NO NO FixedSubscriber MC Table: FixedSubscriber (MINER = NO) Lookup type: Match Lookup DR Key MCLS Key Enriched description prefix CALLING_PARTY ISDN Common - Calling Party CALLED_PARTY Common - Called Party MSISDN Common - User Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Name Name WITH FILTER NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Gender Gender ALWAYS YES YES Birth Date Birth Date WITH RANK NO YES Birth Place Birth Place WITH RANK NO YES Home Place Home Place WITH RANK NO YES Subscription Start Date Subscription start date WITH RANK NO YES Type Type ALWAYS YES YES Importance Importance ALWAYS YES YES Enterprise Name Enterprise name WITH RANK NO YES Department Name Enterprise part WITH RANK NO YES Plan Plan ALWAYS NO YES Options Options WITH RANK NO YES Notes Notes WITH RANK NO YES Tariff Tariff Plan ALWAYS YES YES Service Segment Service Segment ALWAYS YES YES Enterprise Importance Enterprise Importance ALWAYS YES YES Department Importance Enterprise part Importance ALWAYS YES YES Enterprice Description Enterprice Description NEVER NO NO Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/BO/eoSight) Enterprice Part Description Enterprice part Description NEVER NO NO Operator Prefix MC Table: OperatorPrefix (MINER = NO) Lookup type: Prefix Key MCLS Key Enriched description prefix CALLING_NO Prefix Common - Calling Party CALLED_NO Common - Called Party MAP_MSRN MAP Ð MSRN MSISDN Common Ð MSISDN SCCP_CALLED_PARTY Common - SCCP Called Party Global Title SCCP_CALLING_PARTY Common - SCCP Calling Party Global Title MAP_SERVCENT_ADDR MAP - Service Centre Address LOCATION_INFO Common Ð Network Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Prefix Prefix ALWAYS NO YES Operator Name Name ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Country Name Country ALWAYS NO YES Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES Operator Country Code CC ALWAYS NO NO Operator National Destination Code NDC ALWAYS NO NO IMSIPrefix MC Table: IMSIPrefix (Miner = NO) Lookup type: Prefix Lookup DR Key MCLS Key Enriched description prefix IMSI Prefix Common - Subscriber Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Prefix ALWAYS NO YES Prefix Name Name ALWAYS NO YES Prefix Description Description NEVER NO YES Prefix Group Group ALWAYS NO YES Prefix Group 2 Group2 ALWAYS NO YES ISDNPrefix MCLS table: ISDNPrefix (Miner = NO) Lookup type=Prefix Lookup DR Key MCLS Key Enriched description prefix CALLING_NO Prefix Common - Calling Party CALLED_NO Common - Called Party INAP_GENERIC_NUMBER INAP - Generic Number Standard Formatting: Display Name Internal Name eolive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Prefix ALWAYS NO YES Display Name Internal Name eolive Aggregation Rank Enum Visible for Application (eoLive/ BO/eoSight) Prefix Name Name ALWAYS NO YES Prefix Description Description NEVER NO YES Prefix Group Group ALWAYS NO YES Prefix Group 2 Group2 ALWAYS NO YES Operator Signalling Point MCLS table: OperatorSP (Miner = NO) Lookup type=Match DR Lookup Key MCLS Key Enriched description prefix SOURCE_SP SP Name Common - First Leg Source Signalling Point DEST_SP Common Ð First Leg Destination Signalling Point LL_SOURCE_SP Common Ð Last Leg Source Signalling Point LL_DEST_SP Common Ð Last Leg Destination Signalling Point SCCP_CALLING_SP Common Ð SCCP Calling Party Number Signalling Point SCCP_CALLED_SP Common Ð SCCP Called Party Number Signalling Point Standard Formatting: Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator Name Name ALWAYS NO YES Operator Country Name Country ALWAYS NO YES Display Name Internal Name eoLive Aggregation Rank Enum Visible for Application (eoLive/ BO) Operator is Corporate Partner Corporate Partner ALWAYS YES YES Operator is Interconnect Partner Inter Connect Partner ALWAYS YES YES Operator is Roaming Partner Roaming Partner ALWAYS YES YES Operator Country Full Name Country Name ALWAYS NO YES Operator is Home Home ALWAYS YES YES Interconnect Operator Type InterconnectPartner type ALWAYS YES YES Operator Group OperatorGroup ALWAYS NO YES Operator Region Region ALWAYS NO YES 5 Monitored procedures This table contains a list of procedures supported by the TDR format. It shall be considered as example. Procedure/Activity CSDR Failure/Success Additional Info Mobile Originating Call CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country, IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, Call Duration, CAP Operation Code, Event Type, Reported Event, Destination Address, Location Information, TAC Mobile Terminating Call CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, Call Duration, CAP Operation Code, Event Type, Reported Event, Destination Address, Location Information, TAC Mobile Originating SMS CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, CAP Operation Code, Event Type, Reported Event, Location Information, TAC Mobile Terminating SMS CAP Event Report Cause / CAP Application Error Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, CAP Timeout, Called SSN, Calling SSN, Service Key, Called Number, Calling Number, CAP Operation Code, Event Type, Reported Event, Location Information, TAC MS Initiated PDP Context Activation CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, CAP Operation Code, Event Type, Reported Event,TAC NW Initiated PDP Context Activation CAP Event Report Cause / CAP Application Error Code/ Additional CAP Error Reason/CAP Response Cause/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , CAP Timeout, Called SSN, Calling SSN, Service Key, CAP Operation Code, Event Type, Reported Event, TAC Update Location MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Cancel Location MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Procedure/Activity CSDR Failure/Success Additional Info Code, Location Information Provide Roaming Number MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Register SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Erase SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Activate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Deactivate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Interrogate SS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, SS Code Set, MAP Operation Code Send Routing Info MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Update GPRS Location MAP MAP Application Error Code/Additional MAP Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Error Reason/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Send Routing Info For GPRS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Mobile Terminating SMS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Send Routing Info For SM MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI , MAP Timeout, Back Calling Number, MAP Operation Code Mobile Originating SMS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Authentication MAP MAP Application Error Code/Additional MAP Subscriber Operator Procedure/Activity CSDR Failure/Success Additional Info Error Reason/TCAP Abort Cause/SCCP Return Cause Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code Process Unstructured SS Request MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Unstructured SS Request MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause MAP Timeout, Back Calling Number, MAP Operation Code Unstructured SS Notify MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI,MAP Timeout, Back Calling Number, MAP Operation Code Send Routing Info For LCS MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code, Location Information Subscriber Location Report MAP MAP Application Error Code/Additional MAP Error Reason/TCAP Abort Cause/SCCP Return Cause Subscriber Operator Name, Subscriber Operator Country,IMSI, MAP Timeout, Back Calling Number, MAP Operation Code,TAC 6 Appendix A. Property field definition Binary Formats The binary format may assume one of the followings values: Format Description BF_INTEGER Integer value. The size column specifies the integer type: 1 = byte 2 = word 4 = dword 8 = qword BF_BYTES Bytes The size column specifies the number of bytes. BF_STRING String of characters. The size column specifies the max length. BF_FLOATING Floating. The size is ignored. Display Format The display format may assume one of the following formats: Format Description DF_DIGIT It identifies a BCD number DF_STRING The value is displayed as a sequence of Latin-1 characters. DF_ENUM Only the description associated to the value is displayed, e.g.: Test Call Format Description DF_DEC_ENUM Both value, as decimal number, and description are displayed, e.g.: 13 Test Call DF_HEX_ENUM Both value, as hexadecimal number, and description are displayed, e.g.: C4 nTUP DF_ABSOLUTE_TIME The field is a date shown as: ""yyyy-MM-dd HH:mm:ss"". DF_RELATIVE_TIME The field is a date shown as: ""HH:mm:ss.SSS"". DF_BINARY_ENUM The field is displayed in binary form. DF_POINT_CODE The fiels is a point code, e.g: 2-112-0 Broendby DF_CIC The field is a CIC, eg: 127-31 DF_DEC The field is displayed as a decimal value. DF_HEX The field is displayed as a hexadecimal value. DF_IP The field is displayed as an IP address (either IPv4 or IPv6) according to [RFC2373]. DF_FIXEDPOINT The field is a floating number, e.g.: 3.69 DF_BOOLEAN The field is a Boolean, e.g. 0 False DF_FULLYQUALIFIED_POINT_CODE The fiels is a point code, e.g: 2-112-0 Broendby Text Format The text format (used only when DR are generated in csv format) may assume one of the following formats: Format Description DF_STRING DF_DEC DF_HEX Special Property The special property may assume one of the following formats: Special Property Description SP_SUBSCRIBER_MARKER The field represents a Subscriber identifier. SP_START_TIME The field represents the start time of a dialogue/trail. SP_END_TIME The field represents the end time of a dialogue/trail. SP_IMSI The field represents an IMSI. SP_MSISDN The field represents a MSISDN. SP_SOURCE_ADDRESS The field represents an originating address, e.g. Originating Point Code or Source IP Address. SP_DESTINATION_ADDRESS The field represents a destination address, e.g. Destination Point Code or Destination IP Address. SP_OTHER_ADDRESS The field represents an address that cannot be categorized as Source or Destination. SP_GLOBALTITLE The field represents a Global Title, e.g. SCCP Calling Numer. SP_CALLTRACEJUMP The field represent an ID used by the client application to jump to CSDR and PDU details. Aggregation Roles The aggregation role of a field could be: Role Description AR_AGGREGABLE_ALWAYS The field can always be aggregated. AR_AGGREGABLE_WITHFILTER The field can be aggregated only if the eoLive User impose filter on this field to reduce the number of different values. AR_AGGREGABLE_NEVER The field can never be used in aggregation. AR_AGGREGABLE_WITHRANK The field can be used in aggregation but only in presence of rank operation (e.g. Top). 3GPP TS 23.078 V17.0.0 (2022-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Customised Applications for Mobile network Enhanced Logic (CAMEL) Phase 4; Stage 2 (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. Keywords UMTS, GSM, CAMEL, stage 2, network 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2020, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved."
"UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 19 1 Scope 20 1.1 Support of partial implementation of CAMEL phaseÊ4 21 1.1.1 CAMEL PhaseÊ4 CSIs 21 1.1.2 CAMEL PhaseÊ4 Functionalities 21 2 References 23 3 Definitions and abbreviations 26 3.1 Definitions 26 3.2 Abbreviations 28 4 Circuit switched Call Control 30 4.1 Architecture 30 4.1.1 Functional Entities used for CAMEL 30 4.1.2 Interfaces defined for CAMEL 31 4.1.2.1 HLR - VLR interface 31 4.1.2.2 GMSC - HLR interface 31 4.1.2.3 GMSC - gsmSSF interface 31 4.1.2.4 gsmSSF - gsmSCF interface 31 4.1.2.5 MSC - gsmSSF interface 31 4.1.2.6 gsmSCF - HLR interface 31 4.1.2.7 gsmSCF - gsmSRF interface 31 4.1.2.8 GMSC - MSC interface 31 4.2 Detection Points (DPs) 32 4.2.1 Definition and description 32 4.2.1.1 Arming/disarming mechanism 32 4.2.1.2 Criteria 33 4.2.1.2.1 Criteria at DPÊCollected_Info 33 4.2.1.2.2 Criteria at DPÊAnalysed_Information 34 4.2.1.2.3 Criteria at DPÊRoute_Select_Failure 36 4.2.1.2.4 Criteria at DPÊTerminating_Attempt_Authorised 36 4.2.1.2.5 Criteria at DPÊT_Busy and T_No_Answer 37 4.2.1.3 Relationship 37 4.2.2 DP processing rules 38 4.3 Description of CAMEL Subscriber Data 38 4.3.1 Originating CAMEL Subscription Information (O CSI) 38 4.3.1.1 TDP List 38 4.3.1.2 gsmSCF address 38 4.3.1.3 Service Key 38 4.3.1.4 Default Call Handling 38 4.3.1.5 DP criteria 38 4.3.1.6 CAMEL Capability Handling 39 4.3.1.7 CSI state 39 4.3.1.8 Notification flag 39 4.3.2 Dialled Service CAMEL Subscription Information (D CSI) 39 4.3.2.1 DP criteria 39 4.3.2.2 gsmSCF address 39 4.3.2.3 Service Key 39 4.3.2.4 Default Call Handling 39 4.3.2.5 CAMEL Capability Handling 39 4.3.2.6 CSI state 39 4.3.2.7 Notification flag 40 4.3.3 Network CAMEL Service Information (N CSI) 40 4.3.4 Translation Information Flag CAMEL Subscription Information (TIF CSI) 40 4.3.4.1 Translation Information Flag 40 4.3.4.2 Notification flag 40 4.3.5 Terminating CAMEL Subscription Information (in the GMSC) (T CSI) 40 4.3.5.1 TDP List 40 4.3.5.2 gsmSCF address 40 4.3.5.3 Service Key 40 4.3.5.4 Default Call Handling 40 4.3.5.5 DP criteria 41 4.3.5.6 CAMEL Capability Handling 41 4.3.5.7 CSI state 41 4.3.5.8 Notification flag 41 4.3.6 VMSC Terminating CAMEL Subscription Information (VT CSI) 41 4.3.6.1 TDP List 41 4.3.6.2 gsmSCF address 41 4.3.6.3 Service Key 41 4.3.6.4 Default Call Handling 41 4.3.6.5 DP criteria 41 4.3.6.6 CAMEL Capability Handling 41 4.3.6.7 CSI state 42 4.3.6.8 Notification flag 42 4.3.7 Other CAMEL data 42 4.3.7.1 Location information/Subscriber state Interrogation 42 4.3.7.2 gsmSCF address list for CSI 42 4.3.8 Trunk Originated CAMEL Service Information (TO-CSI) 42 4.4 Description of CAMEL BCSMs 43 4.4.1 General Handling 43 4.4.2 Originating Basic Call State Model (O BCSM) 43 4.4.2.1 Description of O BCSM 43 4.4.2.1.1 Description of the call model (PICs) 45 4.4.3 Terminating Basic Call State Model (T BCSM) 49 4.4.3.1 Description of T BCSM 49 4.4.3.1.1 Description of the call model (PICs) 50 4.4.4 Rules for Implicit Disarming of Event Detection Points 53 4.4.5 BCSM Modelling of Call Scenarios 55 4.4.5.1 Mobile Originated Call 55 4.4.5.2 Mobile Terminated Call at the GMSC or VMSC 55 4.4.5.3 Call Forwarding at the GMSC or VMSC 56 4.4.5.4 gsmSCF Initiated Call 57 4.4.5.5 Trunk Originated Call 57 4.4.6 Leg Handling 58 4.4.6.1 Leg is created 58 4.4.6.2 Leg continues to exist 58 4.4.6.3 Leg is released 59 4.4.6.4 Leg is moved 59 4.5 Procedures for CAMEL 59 4.5.1 Overall SDL architecture 59 4.5.2 Handling of mobile originated calls 65 4.5.2.1 Handling of mobile originated calls in the originating MSC 65 4.5.2.1.1 Actions of the MSC on receipt of Int_Error 66 4.5.2.1.2 Actions of the MSC on receipt of Int_Continue 66 4.5.2.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument 66 4.5.2.1.4 Actions of the MSC on receipt of Int_Connect 66 4.5.2.1.5 Actions of the MSC on receipt of Int_Release_Call 67 4.5.2.1.6 Actions of the MSC on receipt of Int_Disconnect_Leg (Leg 2) 67 4.5.2.1.7 Actions of the MSC on receipt of Int_Apply_Warning_Tone 67 4.5.2.1.8 Action of the MSC in procedure CAMEL_OCH_MSC_ANSWER 67 4.5.2.1.9 Action of the MSC in procedure CAMEL_OCH_ETC 68 4.5.2.1.10 Procedure CAMEL_OCH_LEG1_MSC 68 4.5.2.1.11 Process CAMEL_O_CHANGE_OF_POSITION_MSC 68 4.5.2.1.12 Procedure CAMEL_Start_TNRy 68 4.5.2.2 Handling of mobile originating calls in the originating VLR 148 4.5.3 Retrieval of routeing information 151 4.5.3.1 Retrieval of routeing information in the GMSC 151 4.5.3.1.1 Action of the GMSC on receipt of Int_Release_Call 151 4.5.3.1.2 Action of the GMSC on receipt of Int_Error 151 4.5.3.1.3 Action of the GMSC on receipt of Int_Continue 152 4.5.3.1.4 Action of the GMSC on receipt of Int_Continue_With_Argument 152 4.5.3.1.5 Action of the GMSC on receipt of Int_Connect 152 4.5.3.1.6 Action of the GMSC on receipt of Send_Routeing_Info Negative Response (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.7 Action of the GMSC on receipt of Send_Routeing_Info ack with MSRN (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.8 Action of the GMSC on receipt of Send_Routeing_Info ack with FTN (in state Wait_For_Routeing_Info_2) 153 4.5.3.1.9 Action of the GMSC on receipt of Send_Routeing_Info ack with O CSI and/or D CSI and FTN (at state Wait_For_Routeing_Info_2) 153 4.5.3.1.10 Action of the GMSC in procedure CAMEL_MT_ETC 153 4.5.3.1.11 Action of the GMSC in procedure CAMEL_MT_GMSC_Notify_CF 153 4.5.3.1.12 Action of the MSC on receipt of Int_Disconnect_Leg (Leg 2) 153 4.5.3.2 Retrieval of routeing information in the HLR 207 4.5.3.3 Handling of provide roaming number request in the VLR 215 4.5.4 Handling of mobile terminating calls 217 4.5.4.1 Handling of mobile terminating calls in the terminating VMSC 217 4.5.4.1.1 Action of the VMSC in procedure CAMEL_MT_VMSC_Notify_CF 217 4.5.4.1.2 Action of MSC on receipt of Int_Disconnect_Leg (Leg 2) 217 4.5.4.1.3 Procedure CAMEL_ICH_LEG2_MSC 218 4.5.4.1.4 Process CAMEL_T_CHANGE_OF_POSITION_MSC 218 4.5.4.2 Handling of mobile terminating calls in the VLR 255 4.5.5 Handling of forwarded calls 257 4.5.5.1 Procedure CAMEL_CF_MSC_INIT: handling of Int_Continue_With_Argument 257 4.5.5.2 Procedure CAMEL_CF_MSC_INIT: handling of Int_Connect 257 4.5.5.3 Procedure CAMEL_CF_MSC_INIT: handling of Int_Disconnect_Leg (Leg 2) 257 4.5.5.4 Action of the MSC in procedure CAMEL_CF_MSC_ANSWER 257 4.5.5.5 Action of the MSC in procedure CAMEL_CF_ETC 258 4.5.6 Handling of gsmSCF initiated calls 304 4.5.6.1 Handling of gsmSCF initiated calls in the MSC 304 4.5.6.1.1 Actions of the MSC on receipt of Int_Error 304 4.5.6.1.2 Actions of the MSC on receipt of Int_Continue 304 4.5.6.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument 304 4.5.6.1.4 Actions of the MSC on receipt of Int_Disconnect_Leg 304 4.5.6.1.5 Actions of the MSC on receipt of Int_Release_Call 304 4.5.6.2 Handling of gsmSCF initiated calls in the VLR 323 4.5.7 Handling of mobile calls in the gsmSSF 326 4.5.7.1 Call duration control 326 4.5.7.1.1 Information flow for call duration control 326 4.5.7.1.2 Audible indicators for call duration control 329 4.5.7.2 The gsmSCF control of e values 329 4.5.7.2.1 Procedure Handle_SCI 329 4.5.7.2.2 Process Tsw_For_SCI 330 4.5.7.3 Behaviour of the gsmSSF in the process CS_gsmSSF 333 4.5.7.3.1 Actions of the gsmSSF on receipt of CAP_Request_Report_BCSM_Event (in the state Waiting_For_Instructions) 333 4.5.7.3.2 Actions of the gsmSSF on receipt of CAP_Continue (in the state Waiting_For_Instructions) 333 4.5.7.3.3 Actions of the gsmSSF on receipt of CAP_Release_Call (in the state Monitoring) 333 4.5.7.3.4 Actions of the gsmSSF on receipt of Int_DP_T_Busy or Int_DP_T_No_Answer including the parameter Call Forwarded (in the state Monitoring) 333 4.5.7.4 Outstanding Request Counter and Rules for CAMEL 333 4.5.7.5 Process CS_gsmSSF and procedures 334 4.5.7.6 Process gsmSSF_SSME_FSM and procedures 412 4.5.7.7 Process CSA_gsmSSF and procedures 416 4.5.8 Assisting case 440 4.5.9 Procedure CAMEL_Provide_Subscriber_Info 450 4.5.10 CAMEL specific handling of location updating and data restoration 453 4.5.11 Cross phase compatibility 453 4.5.12 Handling of North American Carrier Information 453 4.5.13 Handling of trunk originated calls 453 4.5.13.1 Procedure CAMEL_TOC_Dialled_Services 454 4.5.13.2 Procedure CAMEL_TOC_MSC_INIT 454 4.5.13.3 Procedure CAMEL_NDS_TOC_INIT 454 4.5.13.4 Procedure CAMEL_TOC_LEG1_MSC 454 4.6 Description of information flows 474 4.6.1 gsmSSF to gsmSCF information flows 475 4.6.1.1 Activity Test ack 475 4.6.1.1.1 Description 475 4.6.1.1.2 Information Elements 475 4.6.1.2 Apply Charging Report 475 4.6.1.2.1 Description 475 4.6.1.2.2 Information Elements 475 4.6.1.3 Call Information Report 476 4.6.1.3.1 Description 476 4.6.1.3.2 Information Elements 476 4.6.1.4 Disconnect Leg ack 477 4.6.1.4.1 Description 477 4.6.1.4.2 Information Elements 477 4.6.1.5 Entity Released 477 4.6.1.5.1 Description 477 4.6.1.5.2 Information Elements 477 4.6.1.6 Event Report BCSM 477 4.6.1.6.1 Description 477 4.6.1.6.2 Information Elements 477 4.6.1.7 Initiate Call Attempt ack 481 4.6.1.7.1 Description 481 4.6.1.7.2 Information Elements 481 4.6.1.8 Initial DP 482 4.6.1.8.1 Description 482 4.6.1.8.2 Information Elements 482 4.6.1.9 Move Leg ack 488 4.6.1.9.1 Description 488 4.6.1.9.2 Information Elements 488 4.6.1.10 Split Leg ack 488 4.6.1.10.1 Description 488 4.6.1.10.2 Information Elements 488 4.6.2 gsmSCF to gsmSSF information flows 488 4.6.2.1 Activity Test 488 4.6.2.1.1 Description 488 4.6.2.1.2 Information Elements 488 4.6.2.2 Apply Charging 488 4.6.2.2.1 Description 488 4.6.2.2.2 Information Elements 489 4.6.2.3 Call Gap 490 4.6.2.3.1 Description 490 4.6.2.3.2 Information Elements 490 4.6.2.4 Call Information Request 492 4.6.2.4.1 Description 492 4.6.2.4.2 Information Elements 492 4.6.2.5 Cancel 492 4.6.2.5.1 Description 492 4.6.2.5.2 Information Elements 492 4.6.2.5A Collect Information 493 4.6.2.5A.1 Description 493 4.6.2.5A.2 Information Elements 493 4.6.2.6 Connect 493 4.6.2.6.1 Description 493 4.6.2.6.2 Information Elements 493 4.6.2.7 Connect To Resource 495 4.6.2.7.1 Description 495 4.6.2.7.2 Information Elements 495 4.6.2.8 Continue 496 4.6.2.8.1 Description 496 4.6.2.8.2 Information Elements 496 4.6.2.9 Continue With Argument 496 4.6.2.9.1 Description 496 4.6.2.9.2 Information Elements 497 4.6.2.10 Disconnect Forward Connection 498 4.6.2.10.1 Description 498 4.6.2.10.2 Information Elements 498 4.6.2.11 Disconnect Forward Connection With Argument 499 4.6.2.11.1 Description 499 4.6.2.11.2 Information Elements 499 4.6.2.12 Disconnect Leg 499 4.6.2.12.1 Description 499 4.6.2.12.2 Information Elements 499 4.6.2.13 Establish Temporary Connection 499 4.6.2.13.1 Description 499 4.6.2.13.2 Information Elements 499 4.6.2.14 Furnish Charging Information 500 4.6.2.14.1 Description 500 4.6.2.14.2 Information Elements 500 4.6.2.15 Initiate Call Attempt 501 4.6.2.15.1 Description 501 4.6.2.15.2 Information Elements 501 4.6.2.16 Move Leg 501 4.6.2.16.1 Description 501 4.6.2.16.2 Information Elements 501 4.6.2.17 Play Tone 502 4.6.2.17.1 Description 502 4.6.4.17.2 Information Elements 502 4.6.2.18 Release Call 502 4.6.2.18.1 Description 502 4.6.2.18.2 Information Elements 502 4.6.2.19 Request Report BCSM Event 503 4.6.2.19.1 Description 503 4.6.2.19.2 Information Elements 503 4.6.2.20 Reset Timer 505 4.6.2.20.1 Description 505 4.6.2.20.2 Information Elements 505 4.6.2.21 Send Charging Information 505 4.6.2.21.1 Description 505 4.6.2.21.2 Information Elements 506 4.6.2.22 Split Leg 506 4.6.2.22.1 Description 506 4.6.2.22.2 Information Elements 507 4.6.3 Optional (Service logic dependent) gsmSCF to gsmSRF information flows 507 4.6.3.1 Activity Test 507 4.6.3.1.1 Description 507 4.6.3.1.2 Information Elements 507 4.6.3.2 Cancel 507 4.6.3.2.1 Description 507 4.6.3.2.2 Information Elements 507 4.6.3.3 Play Announcement 507 4.6.3.3.1 Description 507 4.6.3.3.2 Information Elements 508 4.6.3.4 Prompt And Collect User Information 508 4.6.3.4.1 Description 508 4.6.3.4.2 Information Elements 508 4.6.4 gsmSRF to gsmSCF information flows 509 4.6.4.1 Activity Test ack 509 4.6.4.1.1 Description 509 4.6.4.1.2 Information Elements 509 4.6.4.2 Assist Request Instructions 510 4.6.4.2.1 Description 510 4.6.4.2.2 Information Elements 510 4.6.4.3 Prompt And Collect User Information ack 510 4.6.4.3.1 Description 510 4.6.4.3.2 Information Elements 510 4.6.4.4 Specialized Resource Report 510 4.6.4.4.1 Description 510 4.6.4.4.2 Information Elements 510 4.6.5 gsmSCF to Assisting SSF information flows 510 4.6.5.1 Activity Test 510 4.6.5.1.1 Description 510 4.6.5.1.2 Information Elements 510 4.6.5.2 Cancel 511 4.6.5.2.1 Description 511 4.6.5.2.2 Information Elements 511 4.6.5.3 Connect To Resource 511 4.6.5.3.1 Description 511 4.6.5.4 Disconnect Forward Connection 511 4.6.5.4.1 Description 511 4.6.5.4.2 Information Elements 511 4.6.5.5 Play Announcement 511 4.6.5.5.1 Description 511 4.6.5.6 Prompt And Collect User Information 511 4.6.5.6.1 Description 511 4.6.5.7 Reset Timer 511 4.6.5.7.1 Description 511 4.6.6 Assisting SSF to gsmSCF information flows 512 4.6.6.1 Activity Test ack 512 4.6.6.1.1 Description 512 4.6.6.1.2 Information Elements 512 4.6.6.2 Assist Request Instructions 512 4.6.6.2.1 Description 512 4.6.6.3 Prompt And Collect User Information ack (received information) 512 4.6.6.3.1 Description 512 4.6.6.4 Specialized Resource Report 512 4.6.6.4.1 Description 512 4.6.7 HLR to VLR information flows 512 4.6.7.1 Delete Subscriber Data 512 4.6.7.1.1 Description 512 4.6.7.1.2 Information Elements 512 4.6.7.2 Insert Subscriber Data 513 4.6.7.2.1 Description 513 4.6.7.2.2 Information Elements 513 4.6.7.3 Provide Subscriber Info 513 4.6.7.3.1 Description 513 4.6.7.4 Provide Roaming Number 514 4.6.7.4.1 Description 514 4.6.7.4.2 Information Elements 514 4.6.8 VLR to HLR information flows 514 4.6.8.1 Insert Subscriber Data ack 514 4.6.8.1.1 Description 514 4.6.8.1.2 Information Elements 515 4.6.8.2 Provide Subscriber Info ack 515 4.6.8.2.1 Description 515 4.6.8.3 Update Location 515 4.6.8.3.1 Description 515 4.6.8.3.2 Information Elements 515 4.6.8.4 Restore Data 515 4.6.8.4.1 Description 515 4.6.8.4.2 Information Elements 516 4.6.9 HLR to GMSC information flows 516 4.6.9.1 Send Routeing Info ack 516 4.6.9.1.1 Description 516 4.6.9.1.2 Information Elements 516 4.6.10 GMSC to HLR information flows 517 4.6.10.1 Send Routeing Info 517 4.6.10.1.1 Description 517 4.6.10.1.2 Information Elements 518 4.6.11 VMSC to GMSC information flows 518 4.6.11.1 Resume Call Handling 518 4.6.11.1.1 Description 518 4.6.11.1.2 Information Elements 518 4.6.12 MSC to VLR information flows 519 4.6.12.1 Send Info For ICA 519 4.6.12.1.1 Description 519 4.6.12.1.2 Information Elements 519 4.6.12.2 Send Info For Incoming Call 519 4.6.12.2.1 Description 519 4.6.12.2.2 Information Elements 519 4.6.12.3 Send Info For MT Reconnected Call 519 4.6.12.3.1 Description 519 4.6.12.3.2 Information Elements 519 4.6.12.4 Send Info For Outgoing Call 520 4.6.12.4.1 Description 520 4.6.12.4.2 Information Elements 520 4.6.12.5 Send Info For Reconnected Call 520 4.6.12.5.1 Description 520 4.6.12.5.2 Information Elements 520 4.6.13 VLR to MSC information flows 520 4.6.13.1 Complete Call 520 4.6.13.1.1 Description 520 4.6.13.1.2 Information Elements 521 4.6.13.2 Continue CAMEL Handling 521 4.6.13.2.1 Description 521 4.6.13.2.2 Information Elements 521 4.6.13.3 Process Call Waiting 522 4.6.13.3.1 Description 522 4.6.13.3.2 Information Elements 522 4.6.13.4 Send Info For ICA negative response 522 4.6.13.4.1 Description 522 4.6.13.4.2 Information Elements 522 4.6.13.5 Send Info For Incoming Call ack 522 4.6.13.5.1 Description 522 4.6.13.5.1 Information Elements 522 4.6.13.6 Send Info For Incoming Call negative response 523 4.6.13.6.1 Description 523 4.6.13.6.2 Information Elements 523 4.6.13.7 Send Info For MT Reconnected Call ack 523 4.6.13.7.1 Description 523 4.6.13.7.2 Information Elements 523 4.6.13.8 Send Info For MT Reconnected Call negative response 523 4.6.13.8.1 Description 523 4.6.13.8.2 Information Elements 523 4.6.13.9 Send Info For Reconnected Call ack 524 4.6.13.9.1 Description 524 4.6.13.9.2 Information Elements 524 4.6.13.10 Send Info For Reconnected Call negative response 524 4.6.13.10.1 Description 524 4.6.13.10.2 Information Elements 524 4.6.14 Internal MSC information flows 524 4.6.14.1 Perform Call Forwarding ack 524 4.6.14.1.1 Description 524 4.6.14.1.2 Information Elements 524 4.6.15 gsmSCF to HLR information flows 524 4.6.15.1 Send Routeing Info 524 4.6.15.1.1 Description 524 4.6.15.1.2 Information Elements 525 4.6.16 HLR to gsmSCF information flows 525 4.6.16.1 Send Routeing Info ack 525 4.6.16.1.1 Description 525 4.6.16.2 Send Routeing Info negative response 525 4.6.16.2.1 Description 525 4.7 Interaction with supplementary services 526 4.7.1 Line identification 526 4.7.2 Call forwarding services 526 4.7.2.1 Registration of Call Forwarding 526 4.7.2.2 Invocation of Call Forwarding 527 4.7.2.3 Invocation of Call Deflection 528 4.7.3 Call Barring services 528 4.7.4 Closed User Group 528 5 USSD to/from gsmSCF 529 5.1 Architecture 529 5.1.1 Functional Entities used for CAMEL 529 5.1.2 Interfaces defined for CAMEL 530 5.1.2.1 gsmSCF - HLR interface 530 5.2 Description of CAMEL Subscriber Data 530 5.2.1 USSD CAMEL Subscription Information (U CSI) 530 5.2.1.1 Service Code 530 5.2.1.2 gsmSCF address 530 5.3 Content of the USSD General CAMEL Service Information (UG CSI) 530 5.3.1 Service Code 530 5.3.2 gsmSCF address 530 5.4 Procedures 530 5.4.1 MS Initiated USSD 530 5.4.2 gsmSCF Initiated USSD 531 5.5 Description of information flows 531 5.5.1 gsmSCF to HLR information flows 531 5.5.1.1 Unstructured SS Request 531 5.5.1.1.1 Description 531 5.5.1.1.2 Information Elements 531 5.5.1.2 Unstructured SS Notify 532 5.5.1.2.1 Description 532 5.5.1.2.2 Information Elements 532 5.5.1.3 Process Unstructured SS Data ack 532 5.5.1.3.1 Description 532 5.5.1.3.2 Information Elements 532 5.5.1.4 Process Unstructured SS Request ack 532 5.5.1.4.1 Description 532 5.5.1.4.2 Information Elements 532 5.5.2 HLR to gsmSCF information flows 533 5.5.2.1 Unstructured SS Request ack 533 5.5.2.1.1 Description 533 5.5.2.1.2 Information Elements 533 5.5.2.2 Unstructured SS Notify ack 533 5.5.2.2.1 Description 533 5.5.2.2.2 Information Elements 533 5.5.2.3 Process Unstructured SS Data 533 5.5.2.3.1 Description 533 5.5.2.3.2 Information Elements 533 5.5.2.4 Process Unstructured SS Request 533 5.5.2.4.1 Description 533 5.5.2.4.2 Information Elements 533 5.5.2.5 Begin Subscriber Activity 534 5.5.2.5.1 Description 534 5.5.2.5.2 Information Elements 534 6 GPRS interworking 534 6.1 Architecture 534 6.1.1 Functional Entities used for CAMEL 534 6.1.2 Interfaces defined for CAMEL 535 6.1.2.1 SGSN - gprsSSF interface 535 6.1.2.2 gprsSSF - gsmSCF interface 535 6.1.2.3 HLR - SGSN interface 535 6.2 Detection Points (DPs) 535 6.2.1 Definition and description 535 6.2.2 Relationship, DP processing rules and GPRS dialogue 536 6.3 Description of CAMEL Subscriber Data 536 6.3.1 GPRS CAMEL Subscription Information (GPRS CSI) 536 6.3.1.1 gsmSCF Address 536 6.3.1.2 Service Key 536 6.3.1.3 Default GPRS Handling 536 6.3.1.4 TDP List 536 6.3.1.5 CAMEL Capability Handling 537 6.3.1.6 CSI state 537 6.3.1.7 Notification flag 537 6.3.2 gsmSCF address list for CSI 537 6.4 Description of CAMEL State Models 537 6.4.1 General Handling 537 6.4.2 GPRS Attach/Detach State Model 537 6.4.2.1 Description of the Attach/Detach model (PIAs) 538 6.4.2.1.1 Detached 538 6.4.2.1.2 Attached 539 6.4.3 GPRS PDP Context State Model 539 6.4.3.1 Description of the PDP Context model (PIAs) 540 6.4.3.1.1 Idle 541 6.4.3.1.2 PDP Context Setup 541 6.4.3.1.3 PDP Context Established 541 6.4.3.1.4 Change of Position Context 542 6.4.4 GPRS CAMEL Scenarios 542 6.4.4.1 GPRS CAMEL Scenario 1 542 6.4.4.2 GPRS CAMEL Scenario 2 543 6.4.5 SGSN Routeing Area Update 544 6.4.5.1 Intra-SGSN Routeing Area Update 544 6.4.5.2 Inter-SGSN Routeing Area Update 544 6.4.6 Rules for Implicit Disarming of Detection Points 545 6.5 Procedures for CAMEL GPRS 546 6.5.1 Overall SDL Architecture 546 6.5.2 Handling GPRS in the SGSN 546 6.5.2.1 Actions of the SGSN on receipt of Int_Error 547 6.5.2.2 Actions of the SGSN on receipt of Int_Continue 547 6.5.2.3 Handling of GPRS Attach/Detach 548 6.5.2.4 Handling of GPRS Routeing Area Update 551 6.5.2.5 Handling of PDP Context establishment and deactivation 555 6.5.3 Handling GPRS in the gprsSSF 561 6.5.3.1 Process GPRS_SSF 561 6.5.3.2 Process GPRS_Dialogue_Handler 561 6.5.3.3 Procedure Handle_AC_GPRS 561 6.5.3.4 Procedure Handle_ACR_GPRS 561 6.5.3.5 Procedure Complete_FCI_Record_GPRS 562 6.5.3.6 Procedure Handle_SCI_GPRS 562 6.5.3.6.1 Handling of SCI_GPRS for the Session 562 6.5.3.6.2 Handling of SCI_GPRS for a PDP Context 563 6.5.3.7 Procedure Handle_PDP_Acknowledgement 564 6.5.3.8 GPRS duration and volume control 564 6.5.3.8.1 Examples of information flows for GPRS session and PDP context control 564 6.5.3.8.2 TC guard timer 567 6.5.3.9 SDL diagrams for process GPRS_SSF and procedures 569 6.6 Description of information flows 606 6.6.1 gprsSSF to gsmSCF Information Flows 606 6.6.1.1 Activity Test GPRS ack 606 6.6.1.1.1 Description 606 6.6.1.1.2 Information Elements 606 6.6.1.2 Apply Charging Report GPRS 606 6.6.1.2.1 Description 606 6.6.1.2.2 Information Elements 606 6.6.1.3 Entity Released GPRS 607 6.6.1.3.1 Description 607 6.6.1.3.2 Information Elements 607 6.6.1.4 Event Report GPRS 607 6.6.1.4.1 Description 607 6.6.1.4.2 Information Elements 608 6.6.1.5 Initial DP GPRS 610 6.6.1.5.1 Description 610 6.6.1.5.2 Information Elements 610 6.6.2 gsmSCF to gprsSSF Information Flows 611 6.6.2.1 Activity Test GPRS 611 6.6.2.1.1 Description 611 6.6.2.1.2 Information Elements 611 6.6.2.2 Apply Charging GPRS 612 6.6.2.2.1 Description 612 6.6.2.2.2 Information Elements 612 6.6.2.3 Apply Charging Report GPRS ack 612 6.6.2.3.1 Description 612 6.6.2.3.2 Information Elements 612 6.6.2.4 Cancel GPRS 612 6.6.2.4.1 Description 612 6.6.2.4.2 Information Elements 612 6.6.2.5 Connect GPRS 613 6.6.2.5.1 Description 613 6.6.2.5.2 Information Elements 613 6.6.2.6 Continue GPRS 613 6.6.2.6.1 Description 613 6.6.2.6.2 Information Elements 613 6.6.2.7 Entity Released GPRS ack 613 6.6.2.7.1 Description 613 6.6.2.7.2 Information Elements 613 6.6.2.8 Event Report GPRS ack 613 6.6.2.8.1 Description 613 6.6.2.8.2 Information Elements 614 6.6.2.9 Furnish Charging Information GPRS 614 6.6.2.9.1 Description 614 6.6.2.9.2 Information Elements 614 6.6.2.10 Release GPRS 615 6.6.2.10.1 Description 615 6.6.2.10.2 Information Elements 615 6.6.2.11 Request Report GPRS Event 615 6.6.2.11.1 Description 615 6.6.2.11.2 Information Elements 615 6.6.2.12 Reset Timer GPRS 615 6.6.2.12.1 Description 615 6.6.2.12.2 Information Elements 616 6.6.2.13 Send Charging Information GPRS 616 6.6.2.13.1 Description 616 6.6.2.13.2 Information Elements 616 6.6.3 HLR to SGSN Information Flows 617 6.6.3.1 Delete Subscriber Data 617 6.6.3.1.1 Description 617 6.6.3.1.2 Information Elements 617 6.6.3.2 Insert Subscriber Data 617 6.6.3.2.1 Description 617 6.6.3.2.2 Information Elements 617 6.6.4 SGSN to HLR Information Flows 617 6.6.4.1 Insert Subscriber Data ack 617 6.6.4.1.1 Description 617 6.6.4.1.2 Information Elements 618 6.6.4.2 Update GPRS Location 618 6.6.4.2.1 Description 618 6.6.4.2.2 Information Elements 618 7 Short Message Services 618 7.1 Architecture 618 7.1.1 Functional Entities used for CAMEL 618 7.1.2 Interfaces defined for CAMEL 620 7.1.2.1 HLR - VLR interface 620 7.1.2.2 HLR - SGSN interface 620 7.1.2.3 gsmSSF - gsmSCF interface 620 7.1.2.4 gprsSSF - gsmSCF interface 620 7.1.2.5 MSC - gsmSSF interface 620 7.1.2.6 SGSN - gprsSSF interface 621 7.1.2.7 MSC - VLR interface 621 7.1.2.8 MSC - SMSC interface 621 7.1.2.9 SGSN - SMSC interface 621 7.2 Detection Points (DPs) 621 7.2.1 Criteria at DP SMS Delivery Request 621 7.3 Description of CAMEL Subscriber Data 621 7.3.1 Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI) 621 7.3.1.1 gsmSCF address 621 7.3.1.2 Service Key 621 7.3.1.3 Default SMS Handling 621 7.3.1.4 TDP List 622 7.3.1.5 CAMEL Capability Handling 622 7.3.1.6 CSI state 622 7.3.1.7 Notification flag 622 7.3.2 Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI) 622 7.3.2.1 gsmSCF address 622 7.3.2.2 Service Key 622 7.3.2.3 Default SMS Handling 622 7.3.2.4 TDP List 622 7.3.2.5 DP criteria 622 7.3.2.6 CAMEL Capability Handling 622 7.3.2.7 CSI state 622 7.3.2.8 Notification flag 623 7.3.3 gsmSCF address list for CSI 623 7.4 Description of SMS State Models 623 7.4.1 General Handling 623 7.4.2 Mobile Originating SMS State Models 623 7.4.2.1 Description of MO SMS state model 623 7.4.2.1.1 Description of the MO SMS state model (PIAs) 624 7.4.3 Mobile Terminating SMS State Model 625 7.4.3.1 Description of MT SMS state model 625 7.4.3.1.1 Description of the MT SMS state model (PIAs) 626 7.5 Procedures for CAMEL SMS 628 7.5.1 Functional architecture for CAMEL MO SMS services 628 7.5.2 Handling of mobile originating SMS 628 7.5.2.1 Handling of mobile originating SMS in the originating MSC or SGSN 628 7.5.2.1.1 Actions of the MSC or SGSN on receipt of Int_Error 629 7.5.2.1.2 Actions of the MSC or SGSN on receipt of Int_Continue_SMS 629 7.5.2.1.3 Actions of the MSC or SGSN on receipt of Int_Connect_SMS 629 7.5.2.1.4 Actions of the MSC or SGSN on receipt of Int_Release_SMS 629 7.5.2.1.5 Allocation of SMS Reference Number 629 7.5.2.2 Handling of A_MM_Release and A_LLC_Release 629 7.5.2.3 Handling of time-out from SMSC 629 7.5.2.4 Handling of mobile originating SMS in the VLR 634 7.5.3 Functional architecture for CAMEL MT SMS services 636 7.5.4 Handling of mobile terminating SMS 636 7.5.4.1 Handling of mobile terminating SMS in the terminating MSC or SGSN 636 7.5.4.1.1 Procedure CAMEL_T_SMS_INIT; 637 7.5.4.1.2 Procedure CAMEL_T_SMS_DELIVERED 637 7.5.4.1.3 Procedure CAMEL_T_SMS_FAILURE 637 7.5.4.1.4 Allocation of SMS Reference Number 638 7.5.4.2 Handling of mobile terminating SMS in the VLR 643 7.5.4.3 CAMEL subscription check for mobile terminating SMS in the SGSN 645 7.5.5 Handling of mobile originating and mobile terminating SMS in the gsmSSF or gprsSSF 647 7.5.5.1 Process SMS_SSF 647 7.5.5.2 Process Complete_SMS_FCI_Record 647 7.6 Description of information flows 657 7.6.1 gsmSSF or gprsSSF to gsmSCF information flows 657 7.6.1.1 Event Report SMS 657 7.6.1.1.1 Description 657 7.6.1.1.2 Information Elements 657 7.6.1.2 Initial DP SMS 657 7.6.1.2.1 Description 657 7.6.1.2.2 Information Elements 658 7.6.2 gsmSCF to gsmSSF or gprsSSF information flows 660 7.6.2.1 Connect SMS 660 7.6.2.1.1 Description 660 7.6.2.1.2 Information Elements 660 7.6.2.2 Continue SMS 660 7.6.2.2.1 Description 660 7.6.2.2.2 Information Elements 660 7.6.2.3 Furnish Charging Information SMS 660 7.6.2.3.1 Description 660 7.6.2.3.2 Information Elements 661 7.6.2.4 Release SMS 661 7.6.2.4.1 Description 661 7.6.2.4.2 Information Elements 661 7.6.2.5 Request Report SMS Event 661 7.6.2.5.1 Description 661 7.6.2.5.2 Information Elements 662 7.6.2.6 Reset Timer SMS 662 7.6.2.6.1 Description 662 7.6.2.6.2 Information Elements 662 7.6.3 HLR to VLR or SGSN information flows 662 7.6.3.1 Delete Subscriber Data 662 7.6.3.1.1 Description 662 7.6.3.1.2 Information Elements 662 7.6.3.2 Insert Subscriber Data 662 7.6.3.2.1 Description 662 7.6.3.2.2 Information Elements 662 7.6.4 VLR or SGSN to HLR information flows 663 7.6.4.1 Insert Subscriber Data ack 663 7.6.4.2 Update Location 663 7.6.4.3 Update GPRS Location 663 7.6.4.3.1 Description 663 7.6.4.3.2 Information Elements 663 7.6.5 VLR to MSC Information Flows 664 7.6.5.1 Continue CAMEL SMS Handling 664 7.6.5.1.1 Description 664 7.6.5.1.2 Information Elements 664 7.6.5.2 Send Info For MO SMS ack 664 7.6.5.2.1 Description 664 7.6.5.2.2 Information Elements 664 7.6.6 MSC to VLR Information Flows 664 7.6.6.1 Send Info For MT SMS 664 7.6.6.1.1 Description 664 7.6.6.1.2 Information Elements 664 8 SS Notifications 665 8.1 Architecture 665 8.1.1 Functional Entities used for CAMEL 665 8.1.2 Interfaces defined for SS Notifications 665 8.1.2.1 MSC - gsmSCF interface 665 8.1.2.2 HLR - gsmSCF interface 665 8.1.2.3 VLR - MSC interface 666 8.1.2.4 HLR-VLR interface 666 8.2 Description of CAMEL Subscriber Data 666 8.2.1 Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI) 666 8.2.1.1 Notification criteria 666 8.2.1.2 gsmSCF address 666 8.2.1.3 CSI state 666 8.2.1.4 Notification flag 666 8.2.2 gsmSCF address list for CSI 666 8.3 Procedures for CAMEL 666 8.3.1 Handling of Supplementary Service Invocation Notification 666 8.4 Description of information flows 667 8.4.1 MSC to gsmSCF information flows 667 8.4.1.1 SS Invocation Notification 667 8.4.1.1.1 Description 667 8.4.1.1.2 Information Elements 668 8.4.2 HLR to VLR information flows 668 8.4.2.1 Delete Subscriber Data 668 8.4.2.1.1 Description 668 8.4.2.1.2 Information Elements 668 8.4.2.2 Insert Subscriber Data 668 8.4.2.2.1 Description 668 8.4.2.2.2 Information Elements 668 8.4.3 HLR to gsmSCF information flows 668 8.4.3.1 SS Invocation Notification 668 8.4.3.1.2 Information Elements 669 8.4.4 VLR to MSC information flows 669 8.4.4.1 Invoke SS result 669 8.4.4.1.1 Description 669 8.4.4.1.2 Information Elements 669 8.4.4.2 Send Info For Incoming Call ack 669 8.4.4.2.1 Description 669 8.4.4.2.2 Information Elements 669 9 Mobility Management 670 9.1 Architecture 670 9.1.1 Functional Entities used for CAMEL 670 9.1.2 Interfaces defined for CAMEL 671 9.1.2.2 VLR - gsmSCF interface 671 9.1.2.3 SGSN - gsmSCF interface 671 9.2 Description of CAMEL Subscriber Data 671 9.2.1 Mobility Management CAMEL Subscription Information (M CSI) 671 9.2.1.1 Mobility Management Triggers 671 9.2.1.2 gsmSCF address 671 9.2.1.3 Service Key 671 9.2.1.4 CSI state 672 9.2.1.5 Notification flag 672 9.2.2 Mobility Management for GPRS CAMEL Subscription Information (MG CSI) 672 9.2.2.1 Mobility Management Triggers 672 9.2.2.2 gsmSCF address 672 9.2.2.3 Service Key 672 9.2.2.4 CSI state 672 9.2.2.5 Notification flag 672 9.2.3 gsmSCF address list for CSI 672 9.3 Procedures for Mobility management 673 9.3.1 Procedures for Mobility management for CS subscriber 673 9.3.1.1 Procedure descriptions 675 9.3.1.1.1 Procedure Set_Notification_Type 675 9.3.1.1.2 Procedure Notify_gsmSCF 677 9.3.2 Procedures for Mobility management for GPRS subscriber 679 9.3.2.1 Procedure CAMEL_PS_Notification 680 9.4 Description of information flows 684 9.4.1 VLR or SGSN to gsmSCF information flows 684 9.4.1.1 Mobility Management event Notification 684 9.4.1.1.1 Description 684 9.4.1.1.2 Information Elements 684 9.4.2 SGSN to HLR information flows 685 9.4.2.1 Update GPRS Location 685 9.4.3 VLR to HLR information flows 685 9.4.3.1 Update Location 685 9.4.3.2 Restore Data 685 9.4.4 HLR to VLR or SGSN information flows 685 9.4.4.1 Delete Subscriber Data 685 9.4.4.1.1 Description 685 9.4.4.1.2 Information Elements 685 9.4.4.2 Insert Subscriber Data 686 9.4.4.2.1 Description 686 9.4.4.2.2 Information Elements 686 10 Control and interrogation of subscription data 687 10.1 Architecture 687 10.1.1 Functional Entities used for CAMEL 687 10.1.2 Interfaces defined for CAMEL 687 10.1.2.1 gsmSCF - HLR 687 10.2 Procedures for CAMEL 687 10.2.1 Any Time Subscription Interrogation 687 10.2.2 Any Time Modification 690 10.2.3 Notify Subscriber Data Change 707 10.3 Description of information flows 710 10.3.1 gsmSCF to HLR information flows 710 10.3.1.1 Any Time Modification Request 710 10.3.1.1.1 Description 710 10.3.1.1.2 Information Elements 710 10.3.1.2 Any Time Subscription Interrogation Request 712 10.3.1.2.1 Description 712 10.3.1.2.2 Information Elements 713 10.3.1.3 Notify Subscriber Data Change response 713 10.3.1.3.1 Description 713 10.3.1.3.2 Information Elements 714 10.3.2 HLR to gsmSCF information flows 714 10.3.2.1 Any Time Modification ack 714 10.3.2.1.1 Description 714 10.3.2.1.2 Information Elements 714 10.3.2.2 Any Time Subscription Interrogation ack 716 10.3.2.2.1 Description 716 10.3.2.2.2 Information Elements 716 10.3.2.3 Notify Subscriber Data Change 718 10.3.2.3.1 Description 718 10.3.2.3.2 Information Elements 719 10.3.3 IP-SM-GW to HLR information flows 721 10.3.3.1 Any Time Modification Request 721 10.3.3.1.1 Description 721 10.3.3.1.2 Information Elements 721 10.3.4 HLR to IP-SM-GW information flows 721 10.3.4.1 Any Time Modification ack 721 10.3.4.1.1 Description 721 10.3.4.1.2 Information Elements 722 11 Subscriber Location and State retrieval 722 11.1 Architecture 722 11.1.1 Functional Entities used for CAMEL 722 11.1.2 Interfaces defined for CAMEL 723 11.1.2.1 gsmSCF - GMLC interface 723 11.1.2.2 GMLC - gsmSCF interface 723 11.1.2.3 gsmSCF - HLR 723 11.1.2.4 HLR - gsmSCF 724 11.1.2.5 HLR - SGSN 724 11.1.2.5 SGSN - HLR 724 11.2 Procedures for CAMEL 724 11.2.1 Location Services 724 11.2.2 Any Time Interrogation 726 11.2.3 Provide Subscriber Information in the SGSN 728 11.2.3.1 Procedure CAMEL_Provide_Subscriber_Info_SGSN 728 11.2.3.2 Procedure CAMEL_Active_Info_Retrieval_SGSN 728 11.3 Description of information flows 734 11.3.1 gsmSCF to GMLC information flows 734 11.3.1.1 Any Time Interrogation Request 734 11.3.1.1.1 Description 734 11.3.1.1.2 Information Elements 734 11.3.2 GMLC to gsmSCF information flows 734 11.3.2.1 Any Time Interrogation ack 734 11.3.2.1.1 Description 734 11.3.2.1.2 Information Elements 734 11.3.3 gsmSCF to HLR information flows 735 11.3.3.1 Any Time Interrogation Request 735 11.3.3.1.1 Description 735 11.3.3.1.2 Information Elements 735 11.3.4 HLR to gsmSCF information flows 736 11.3.4.1 Any Time Interrogation ack 736 11.3.4.1.1 Description 736 11.3.4.1.2 Information Elements 736 11.3.5 HLR to SGSN information flows 737 11.3.5.1 Provide Subscriber Info 737 11.3.5.1.1 Description 737 11.3.5.1.2 Information Elements 737 11.3.6 SGSN to HLR information flows 737 11.3.6.1 Provide Subscriber Info ack 737 11.3.6.1.1 Description 737 11.3.6.1.2 Information Elements 738 12 Subscriber Mobile Number Portability status retrieval 739 12.1 Architecture 739 12.1.1 Functional Entities used for CAMEL 739 12.1.2 Interfaces defined for CAMEL 740 12.1.2.1 gsmSCF - MNPÊSRF interface 740 12.1.2.2 MNPÊSRF - gsmSCF interface 740 12.2 Procedures for CAMEL 740 12.2.1 Provide MNP Information 740 12.2.1.1 CAMEL_Provide_MNP_Info with ATI 740 12.3 Description of information flows 742 12.3.1 gsmSCF to MNPÊSRF information flows 742 12.3.1.1 Any Time Interrogation Request 742 12.3.1.1.1 Description 742 12.3.1.1.2 Information Elements 742 12.3.2 MNPÊSRF to gsmSCF information flows 742 12.3.2.1 Any Time Interrogation ack 742 12.3.2.1.1 Description 742 12.3.2.1.2 Information Elements 742 Annex A (informative): Handling of Apply Charging GPRS and Apply Charging Report GPRS 744 Annex B (informative): Change history 747 Foreword This Technical Specification (TS) has been produced by the 3rd Generation Partnership Project (3GPP). The present document specifies the stageÊ2 description for the fourth phaseÊ(see 3GPP TSÊ22.078Ê[6]) of the Customized Applications for Mobile network Enhanced Logic (CAMEL) feature within the 3GPP system. The contents of present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will then be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. 1 Scope The present document specifies the stageÊ2 description for the fourth phaseÊ(see 3GPP TSÊ22.078Ê[6]) of the Customized Applications for Mobile network Enhanced Logic (CAMEL) feature which provides the mechanisms to support services of operators which are not covered by standardized services even when roaming outside the HPLMN. The CAMEL feature is a network feature and not a supplementary service. It is a tool to help the network operator to provide the subscribers with the operator specific services even when roaming outside the HPLMN. In the present document, the GSM Service Control Function (gsmSCF) is treated as being part of the HPLMN. The regulatory environment in some countries may require the possibility that the gsmSCF and the HPLMN are controlled by different operators, and the gsmSCF and the HPLMN are therefore distinct entities. The fourth phase of the CAMEL feature supports, in addition to the third phase of the CAMEL: - Interactions with Optimal Routing; - Call Party Handling; - DTMF Mid call procedure for Mobile Originated and Mobile Terminating calls; - Inclusion of flexible tone injection; - Provision of location information of called subscriber; - Provide location information during ongoing call; - CAMEL control over MT SMS; - Notification of GPRS mobility management to CSE; - Inclusion of ODB data in Any Time Modification; - Enhancement of Any Time Interrogation and Provide Subscriber Information for PS Domain; - Mobile Number Portability database interrogation; - Criteria for the provision of location information during ongoing call; - Enhanced Dialled Services; - Enhancement to Establish Temporary Connection; - CAMEL control of trunk originated calls. CAMEL applicability to IP-based multimedia services is introduced in the fourth phase of the CAMEL. It is specified in 3GPP TSÊ23.278Ê[29]. CAMEL is not applicable to Emergency Setup (TSÊ12), i.e. if an Emergency call is requested, then the gsmSSF shall not be invoked. The mechanism described in the present document addresses especially the need for information exchange between the VPLMN or IPLMN and the HPLMN for support of operator specific services. Any user procedures for the control of operator specific services are outside the scope of the present document. Subscribers who have subscribed to operator specific services and therefore need the functional support of the CAMEL feature shall be marked in the HPLMN and VPLMN. In case a subscriber is marked to need CAMEL support, the appropriate procedures which provide the necessary information to the VPLMN or the HPLMN are invoked. It is possible for the HPLMN to instruct the VPLMN or IPLMN to interact with a gsmSCF which is controlled by the HPLMN. The specification of operator specific services is outside the scope of the present document. 1.1 Support of partial implementation of CAMEL phaseÊ4 A functional entity (VMSC, GMSC or SGSN) may support the complete CAMEL phaseÊ4 functionality or, as a network option, it may support the complete CAMEL phaseÊ3 functionality and a partial implementation of CAMEL phaseÊ4. If a functional entity supports any part of CAMEL phaseÊ4, then the HLR is informed of the CAMEL phaseÊ4 CSIs supported. An SGSN may also indicate support of the Provide Subscriber Information IF. To indicate support of a specific CSI, a functional entity shall have the ability to trigger on any initial service event possible for that CSI. If a VMSC or GMSC supports any of the CAMEL phaseÊ4 circuit switched CSIs (O CSI, D CSI, T CSI or VT CSI), then the gsmSCF is informed of the CAMEL phaseÊ4 circuit switched functionalities offered. The gsmSCF shall not send information flows or parameters that conflict with the functionalities offered by the VMSC or GMSC. If a CAMEL subscriber attempts to register in a VMSC or SGSN which supports at least one CAMEL phaseÊ4 CSI or the enhancement of Provide Subscriber Information IF, then the VMSC or SGSN indicates in the registration request to the HLR the phase of CAMEL which the VMSC or SGSN supports (at least phaseÊ4). In addition, the VMSC or SGSN indicates which CAMEL phaseÊ4 CSIs may be downloaded. An SGSN may also indicate support of the Provide Subscriber Information IF. If a GMSC supports at least one CAMEL phaseÊ4 CSI, then the GMSC indicates in the Send Routeing Info to the HLR the phase of CAMEL which the GMSC supports (at least phaseÊ4). In addition, the GMSC indicates which CAMEL phaseÊ4 CSIs may be downloaded. If a VMSC/gsmSSF or GMSC/gsmSSF initiates contact with the gsmSCF using the Initial DP IF, or acknowledges a gsmSCF initiated contact using the Initiate Call Attempt ack IF, then the VMSC/gsmSSF or GMSC/gsmSSF indicates in the IF the CAMEL phaseÊ4 functionalities offered to the gsmSCF. If a VLR initiates contact with the gsmSCF using a Mobility Management Event Notification IF, then the VLR or SGSN indicates in the IF the functionalities offered to the gsmSCF. 1.1.1 CAMEL PhaseÊ4 CSIs A network entity may indicate to the HLR an offer of support for the following CAMEL phaseÊ4 CSIs: - CAMEL phaseÊ4 O CSI; - CAMEL phaseÊ4 D CSI; - CAMEL phaseÊ4 T CSI; - CAMEL phaseÊ4 VT CSI; - CAMEL phaseÊ4 MT SMS CSI; - CAMEL phaseÊ4 MG CSI; CAMEL control of trunk originated calls; - Reporting of additional dialled digits. An SGSN may also indicate support of the CAMEL phaseÊ4 Provide Subscriber Information IF. A functional entity (VMSC, GMSC or SGSN) may offer the CSIs in any combination applicable for this entity. A functional entity shall indicate to the HLR all the CSIs it offers. The HLR may ignore the offer of the supported CSIs if they are not applicable for the sending entity, but it shall not reject the operation in this case."
"1.1.2 CAMEL PhaseÊ4 Functionalities The CAMEL phaseÊ4 functionalities which may be offered to the gsmSCF are the following: - Creating additional parties in a call, Creating a new call (Initiate Call Attempt); - Placing an individual call party on hold or moving an individual call party to Call Segment 1, when Call Segment 1 does not exist (Split Leg); - Connecting an individual call party to the group (Move Leg); - Releasing an individual call party (Disconnect Leg); - Indication of the release of a call party or call segment (Entity Released); - Enhancements for subscriber interactions with the gsmSCF (Disconnect Forward Connection With Argument); - Inclusion of flexible tone injection (Play Tone); - DTMF Mid call procedure for MO and VT calls (DPÊO_Mid_Call, DPÊT_Mid_Call); - Provision of Charge Indicator at answer DP (Charge Indicator at DPÊO_Answer, DPÊT_Answer); - Support of Alerting DP (DPÊO_Term_Seized, DPÊCall_Accepted); - Provision of location information of subscriber at alerting DP (Location information at DPÊO_Term_Seized, DPÊCall_Accepted); - Provision of location information during an ongoing call (DPÊO_Change_Of_Position, DPÊT_Change_Of_Position); - Interactions with Basic Optimal Routeing (Basic OR Interrogation Requested in Connect and Continue With Argument, Route Not Permitted in DPÊO_Abandon); - Warning tone enhancements (Burstlist for Audible Indicator); - Enhancements of Call Forwarding indication (Forwarding Destination Number); - Criteria for the provision of location information during ongoing call (Criteria for DPÊO_Change_Of_Position and DPÊT_Change_Of_Position); - Subscribed Enhanced Dialled services (see description below); - Serving Network Enhanced Dialled Services (see description below); - SCUDIF notification during active phase of the call (DP O_Service_Change and T_Service_Change) ; and Collection of additional dialled digits (Arming CollectedInfo DP as EDP-R). For the Subscribed Enhanced Dialled Services and Serving Network Enhanced Dialled Services, the following information flows apply in addition to the information flows allowed at TDPÊAnalysed_Information since CAMEL phaseÊ3: Apply Charging, Call Information Request, Cancel (all requests) and Request Report BCSM Event together with their acknowledgements and reportings. In addition, all the other offered CAMEL phaseÊ4 functionalities apply also to the enhanced dialled services. A functional entity (VMSC or GMSC) may offer the functionalities in any combination applicable for this entity and applicable to the offered CSIs. A functional entity (VMSC or GMSC) shall indicate to the gsmSCF all the functionallities it offers. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TRÊ21.905: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Vocabulary for 3GPP Specifications"". [2] 3GPP TSÊ22.004: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General on supplementary "". [3] 3GPP TSÊ22.024: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Description of Charge Advice Information (CAI)"". [4] 3GPP TSÊ22.041: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Operator Determined Barring (ODB)"". [5] 3GPP TSÊ22.071: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Location Services (LCS); Service description, StageÊ1"". [6] 3GPP TSÊ22.078: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Customised Applications for Mobile network Enhanced Logic (CAMEL); Service description, StageÊ1"". [7] 3GPP TSÊ23.003: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Numbering, addressing and identification"". [8] 3GPP TSÊ23.008: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Organization of subscriber data"". [9] 3GPP TSÊ23.011: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Supplementary Services"". [10] 3GPP TSÊ23.012: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Location management procedures"". [11] 3GPP TSÊ23.015: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Operator Determined Barring (ODB)"". [12] 3GPP TSÊ23.018: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Basic call handling; Technical realization"". [13] 3GPP TSÊ23.032: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Universal Geographical Area Description (GAD)"". [14] 3GPP TSÊ23.040: ""3rd Generation Partnership Project; Technical Specification Group Terminals; Technical realization of the Short Message Service (SMS)"". [15] 3GPP TSÊ23.060: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; General Packet Radio Service (GPRS); Service description; StageÊ2"". [16] 3GPP TSÊ23.072: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Deflection (CD) Supplementary Service; StageÊ2"". [17] 3GPP TSÊ23.066: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Mobile Number Portability (MNP); Technical realization; StageÊ2"". [18] 3GPP TSÊ23.073: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Localised Service Area (SoLSA); StageÊ2"". [19] 3GPP TSÊ23.079: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Support of Optimal Routeing (SOR); Technical realization"". [20] 3GPP TSÊ23.082: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Forwarding (CF) supplementary services; StageÊ2"". [21] 3GPP TSÊ23.084: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Multi Party (MPTY) supplementary service; StageÊ2"". [22] 3GPP TSÊ23.085: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Closed User Group (CUG) supplementary service; StageÊ2"". [23] 3GPP TSÊ23.088: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Call Barring (CB) Supplementary Services; StageÊ2"". [24] 3GPP TSÊ23.090: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Unstructured Supplementary Service Data (USSD); StageÊ2"". [25] 3GPP TSÊ23.091: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Explicit Call Transfer (ECT) supplementary service; StageÊ2"". [26] 3GPP TSÊ23.093: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Completion of Calls to Busy Subscriber (CCBS); StageÊ2"". [27] 3GPP TSÊ23.172: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification; StageÊ2"". [28] 3GPP TSÊ23.271: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Functional stageÊ2 description of LCS"". [29] 3GPP TSÊ23.278: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) - IP Multimedia System (IMS) interworking; Stage 2"". [30] 3GPP TSÊ24.008: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile radio interface layer 3 specification; Core Network Protocols; StageÊ3"". [31] 3GPP TSÊ24.011: ""3rd Generation Partnership Project; Technical Specification Group Core Network; PointÊ-ÊtoÊ-ÊPoint (PP) Short Message Service (SMS); support on mobile radio interface"". [32] 3GPP TSÊ25.305: ""3rd Generation Partnership Project; Technical Specification Group Radio Access Network; Stage 2 Functional Specification of UE Positioning in UTRAN"". [33] 3GPP TSÊ25.413: ""3rd Generation Partnership Project; Technical Specification Group Radio Access Network; UTRAN Iu interface RANAP signalling"". [34] 3GPP TSÊ29.002: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Mobile Application Part (MAP) specification"". [35] 3GPP TSÊ29.007: ""3rd Generation Partnership Project; Technical Specification Group Core Network; General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN)"". [36] 3GPP TSÊ29.078: ""3rd Generation Partnership Project; Technical Specification Group Core Network; Customised Applications for Mobile network Enhanced Logic (CAMEL) PhaseÊ4 CAMEL Application Part (CAP) specification"". [37] 3GPP TSÊ32.250: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging management; Circuit Switched (CS) domain charging"". [38] 3GPP TSÊ32.251: ""3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Telecommunication Management; Charging management; Packet Switched (PS) domain charging"". [39] 3GPP TSÊ48.008: ""3rd Generation Partnership Project; Technical Specification Group GSM EDGE Radio Access Network; Mobile-services Switching Centre - Base Station System (MSCÊ-ÊBSS) interface; LayerÊ3 specification"". [40] ETSI ENÊ300Ê356-1 (V3.2.2): ""Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 3 for the international interface; Part 1: Basic services[ITU T Recommendations Q.761 to Q.764 (1997), modified]"". [41] ETSI ENÊ301Ê070-1 (V1.2.2): ""Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) versionÊ3 interactions with the Intelligent Network Application Part (INAP); Part 1: Protocol specificationÊ[ITU T Recommendation Q.1600 (1997), modified]"". [42] GSM TRÊ03.47: ""Example protocol stacks for interconnecting; Service Centre(s) (SC) and Mobile-services Switching Centre(s) (MSC)"". [43] ITU T Recommendation Q.763, DecemberÊ1999: ""Signalling System No.Ê7Ê-ÊISDN user part formats and codes"". [44] ITU T Recommendation Q.1224, SeptemberÊ1997: ""Distributed Functional Plane for Intelligent Network Capability SetÊ2"". [45] 3GPP TSÊ23.087: ""3rd Generation Partnership Project; Technical Specification Group Core Network; User-to-User Signalling (UUS) Supplementary Service - Stage 2"". [46] 3GPP TSÊ43.059: ""3rd Generation Partnership Project; Technical Specification Group GSM/EDGE Radio Access Network; Functional stage 2 description of Location Services (LCS) in GERAN"". [47] 3GPP TSÊ23.081: ""Line identification supplementary services; Stage 2"". [48] 3GPP TSÊ23.083: ""Call Waiting (CW) and Call Hold (HOLD) supplementary services; Stage 2"". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions apply: Basic Call State Model (BCSM): BCSM provides a high-level model of GMSC- or MSC/VLR-activities required to establish and maintain communication paths for users. As such, it identifies a set of basic call activities in a GMSC or MSC/VLR and shows how these activities are joined together to process a basic call. Call Control Function (CCF): CCF is the Call Control Function in the network that provides call/service processing and control (see ITU T Recommendation Q.1224Ê[44]). Call Party Handling (CPH) Information Flow: Any of the Disconnect Leg, Move Leg or Split Leg information flows. Call Segment: A call segment contains one or more legs that are controlled by the same CS_gsmSSF instance. The call parties in the same call segment can communicate with each other (using a conference bridge if necessary). Call segments are identified by a number, eg. CSID1 is the call segment with id numberÊ1. Call Segment Association (CSA): A CSA contains one or more call segments. Legs can be moved between call segments within the CSA. There is a single CAP dialogue between the CSA and the gsmSCF. Detection Points (DP): points in processing at which notifications (to the service logic) can occur and transfer of control (to the gsmSCF) is possible are called Detection Points (DPs). Dialled Service CAMEL Subscription Information (D CSI): D CSI identifies the subscriber as having originating CAMEL dialled services. Forwarding MSC: MSC which is either an MSC invoking a standardized Call Forwarding supplementary service or Call Deflection supplementary service; or an MSC invoking a CAMEL based call forwarding service. Gateway MLC (GMLC): functional entity that allows external LCS Clients to request real-time information about a Mobile Station. The information that can be requested from the GMLC is: - location of Mobile Station See 3GPP TSÊ23.271Ê[28] and 3GPP TSÊ25.305Ê[32] or 3GPP TSÊ43.059Ê[46] for information on the GMLC. Geodetic Information: information defining the location of a mobile station, coded according to ITU T Recommendation Q.763Ê[43]. The derivation of this information from other information defining the location of a mobile station is a network operator option. If an entity derives the geodetic information it shall also provide the equivalent geographical information. Geographical Information: information defining the location of a mobile station, coded according to 3GPP TSÊ23.032Ê[13]. GPRS CAMEL Subscription Information (GPRS CSI): GPRS CSI identifies the subscriber as having GPRS CAMEL services. GPRS Dialogue: A dialogue between the gprsSSF and the gsmSCF. A single GPRS Dialogue may consist of one or more TCAP dialogues. Only one TCAP dialogue shall exists at one point in time for one gprsDialogue. GPRS Service Switching Function (gprsSSF): functional entity that interfaces the SGSN to the gsmSCF. The concept of the gprsSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network. GPRS Session: GPRS session starts when the GPRS subscriber attaches to the GPRS data network. It ends when the GPRS subscriber detaches from the GPRS data network. GSM Service Control Function (gsmSCF): functional entity that contains the CAMEL service logic to implement OSS. It interfaces with the gsmSSF, the gsmSRF, the GMLC and the HLR. GSM Service Switching Function (gsmSSF): functional entity that interfaces the MSC or GMSC to the gsmSCF. The concept of the gsmSSF is derived from the IN SSF, but uses different triggering mechanisms because of the nature of the mobile network. GSM Specialised Resource Function (gsmSRF): functional entity which provides various specialized resources. It interfaces with the gsmSCF and with the MSC. This entity is defined in ITU T Recommendation Q.1224Ê[44] with variations defined in the present document. Inter-connecting MSC: MSC which provides CAMEL support for incoming trunk calls. Location Information: indicates the location of the Mobile Station. The provision of location information is independent of the MS status. As part of the location information, an indication of the age of this information may be delivered. Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI): MO SMS CSI identifies the subscriber as having MO SMS CAMEL services. MO SMS CSI (CAMEL PhaseÊ4) is identical to SMS CSI (CAMEL PhaseÊ3). Mobile Station State: similar to Subscriber State, but associated only with a Mobile Station, not with a subscriber. Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI): MT SMS CSI identifies the subscriber as having MT SMS CAMEL services. Mobility Management event CAMEL Subscription Information (M CSI): M CSI identifies the subscriber as having Mobility Management event notification CAMEL services. Mobility Management event GPRS CAMEL Subscription Information (MG CSI): MG CSI identifies the GPRS subscriber as having Mobility Management event notification CAMEL services. NA (North American): prefix attached to certain information items used by North American PLMNs in connection with routing a call to a preferred or dialled long distance carrier. Network CAMEL Service Information (N CSI): N CSI identifies services offered on a per-network basis by the serving PLMN operator for all subscribers. Originating Basic Call State Model (O BCSM): originating half of the BCSM. The O BCSM corresponds to that portion of the BCSM associated with the originating party. Originating CAMEL Subscription Information (O CSI): O CSI identifies the subscriber as having originating CAMEL services. Point In Association (PIA): PIAs identify MSC/VLR or SGSN activities associated with one or more basic association/connection states of interest to OSS service logic instances. Point In Call (PIC): PICs identify MSC/VLR (GMSC) activities associated with one or more basic call/connection states of interest to OSS service logic instances. Service Key: Service Key identifies to the gsmSCF the service logic. The Service Key is administered by the HPLMN, and is passed transparently by the VPLMN/IPLMN to the gsmSCF. The Service Key is a part of the T/O/VT/D/GPRS/SMS/M CSI. Serving MLC: functional entity that performs location information retrieval. Short Message Control Protocol (SM-CP): Protocol between the MSC or SGSN and the MS. This protocol, which is specified in 3GPP TSÊ24.011Ê[31], is used to carry RPDU elements between the MSC or SGSN and the MS. Short Message Service Centre (SMSC): also abbreviation SC is used for SMSC. Subscriber State: see 3GPP TSÊ22.078Ê[6]. Supplementary Service Notification CAMEL Subscription Information (SS CSI): SS CSI identifies the subscriber as having supplementary service invocation notification CAMEL services. Terminating Basic Call State Model (T BCSM): terminating half of the BCSM. The T BCSM corresponds to that portion of the BCSM associated with the terminating party. Terminating CAMEL Subscription Information (in the GMSC) (T CSI): T CSI identifies the subscriber as having terminating CAMEL services in the GMSC. Translation Information Flag (TIF CSI): TIF CSI is a flag in the CAMEL subscriber data which indicates that when the subscriber registers a forwarded-to number, that the HLR shall not attempt to perform any translation, number format checks, prohibited FTN checks, call barring checks. Trunk Originated CAMEL Service Information (TO-CSI): TO-CSI identifies services offered by the PLMN operator to all incoming calls on a specific MSC trunk. USSD CAMEL Subscription Information (U CSI): U CSI identifies a set of subscriber specific mappings from a USSD service code to a gsmSCF address. USSD General CAMEL Service Information (UG CSI): UG CSI globally identifies a set of mappings from a USSD service code to a gsmSCF address. The global mapping applies to all HPLMN subscribers. If, for a particular service code, both U CSI and UG CSI are applicable then the U CSI shall take precedence. VMSC Terminating CAMEL Subscription Information (VT CSI): VT CSI identifies the subscriber as having terminating CAMEL services in the VMSC. 3.2 Abbreviations Abbreviations used in the present document are listed in 3GPP TRÊ21.905Ê[1]. For the purposes of the present document, the following abbreviations apply: BCSM Basic Call State Model CAMEL Customized Applications for Mobile network Enhanced Logic CPH Call Party Handling CS Call Segment CS Circuit Switched CSA Call Segment Association CSG Closed Subscriber Group CSID Call Segment (followed by an identification Number e.g. CSID1) DP Detection Point DTN Deflected To Number D CSI Dialled Services CAMEL Subscription Information EDP Event Detection Point EDS Enhanced Dialled Services FTN Forwarded To Number GMLC Gateway MLC GMSC Gateway MSC GPRS General Packet Radio Service gprsSSF GPRS Service Switching Function GPRS CSI GPRS CAMEL Subscription Information gsmSCF GSM Service Control Function gsmSRF GSM Specialised Resource Function gsmSSF GSM Service Switching Function HLR Home Location Register HPLMN Home PLMN ICA Initiate Call Attempt IE Information Element IF Information Flow IP Intelligent Peripheral IPLMN Interrogating PLMN LCS Location Services LSA Localised Service Area M CSI Mobility Management event Notification CAMEL Subscription Information MF Mobile Forwarding MG CSI Mobility Management event Notification GPRS CAMEL Subscription Information MLC Mobile Location Centre MNP Mobile Number Portability MNPÊSRF Mobile Number Portability Signalling Relay Function MO Mobile Originating MO SMS CSI Mobile Originated Short Message Service CAMEL Subscription Information MSC Mobile service Switching Centre MT Mobile Terminating MT Mobile Terminating in GMSC MT SMS CSI Mobile Terminating Short Message Service CAMEL Subscription Information N CSI Network CAMEL Service Information NA North American NNI Network Node Interface O BCSM Originating Basic Call State Model O CSI Originating CAMEL Subscription Information ODB Operator Determined Barring OR Optimal Routeing OSS Operator Specific Service PDP Packet Data Protocol PIC Point In Call PLMN Public Land Mobile Network SGSN Serving GPRS Support Node SLPI Service Logic Program Instance SM Short Message SM-CP Short Message Control Protocol SMF Service Management Function SMLC Serving MLC SMRSE Short Message Relay Service Element SMS Short Message Service SMSC Short Message Service Centre SMS CSI Short Message Service CAMEL Subscription Information SS CSI Supplementary Service Notification CAMEL Subscription Information T BCSM Terminating Basic Call State Model T CSI Terminating CAMEL Subscription Information (in the GMSC) TDP Trigger Detection Point TO-CSI Trunk Originated CAMEL Service Information TPDU Transfer Protocol Data Unit TIF CSI Translation Information Flag U CSI USSD CAMEL Subscription Information UG CSI USSD General CAMEL Service Information UNI User Network Interface VLR Visitor Location Register VPLMN Visited PLMN VT Mobile Terminating in VMSC VT CSI VMSC Terminating CAMEL Subscription Information 4 Circuit switched Call Control 4.1 Architecture 4.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support CAMEL. Also the additions needed to the basic functionality are described. FigureÊ4.1 shows the functional entities involved in calls requiring CAMEL support. The architecture is applicable to the forth phase of CAMEL. Figure 4.1: Functional architecture for support of CAMEL HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription regarding O CSI, D CSI, T CSI, VT CSI and TIF CSI. The O CSI is sent to the VLR at Location Update, on data restoration or if the O CSI is updated by administrative action. The D CSI is sent to the VLR at Location Update, on data restoration or if the D CSI is updated by administrative action. The VT CSI is sent to the VLR at Location Update, on data restoration or if the VT CSI is updated by administrative action. The TIF CSI is sent to the VLR at Location Update, on data restoration or if the TIF CSI is updated by administrative action. The O/D/T CSI is sent to the GMSC when the HLR responds to a request for routeing information. GMSC: When processing the calls for subscribers requiring CAMEL support, the GMSC receives an O/D/T CSI from the HLR, indicating the GMSC to request instructions from the gsmSSF. The GMSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the GMSC. MSC: When processing the calls for subscribers requiring CAMEL support, the MSC receives an O CSI and / or D CSI and / or VT CSI from the VLR indicating the MSC to request instructions from the gsmSSF. The MSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the MSC. VLR: The VLR stores the O CSI, D CSI, VT CSI and TIF CSI as a part of the subscriber data for subscribers roaming in the VLR area. gsmSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. gsmSRF: see subclauseÊ3.1. 4.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 4.1.2.1 HLR - VLR interface This interface is used to send the CAMEL related subscriber data to the visited PLMN and for provision of MSRN. The interface is also used to retrieve subscriber status and location information of the mobile subscriber or to indicate suppression of announcement for a CAMEL service. 4.1.2.2 GMSC - HLR interface This interface is used at terminating calls to exchange routeing information, subscriber status, location information, subscription information and suppression of announcements. The CAMEL related subscriber data that is passed to the IPLMN is sent over this interface. 4.1.2.3 GMSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 4.1.2.4 gsmSSF - gsmSCF interface This interface is used by the gsmSCF to control a call in a certain gsmSSF and to request the gsmSSF to establish a connection with a gsmSRF. Relationships on this interface are opened as a result of the gsmSSF sending a request for instructions to the gsmSCF or opened as a result of the gsmSCF sending a request to the gsmSSF to initiate a new call. 4.1.2.5 MSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 4.1.2.6 gsmSCF - HLR interface This interface is used by the gsmSCF to request information from the HLR. As a network operator option the HLR may refuse to provide the information requested by the gsmSCF. 4.1.2.7 gsmSCF - gsmSRF interface This interface is used by the gsmSCF to instruct the gsmSRF to play tones/announcements to the users. 4.1.2.8 GMSC - MSC interface This interface is used to transfer control of a call from a VMSC back to a GMSC for optimal routeing. 4.2 Detection Points (DPs) 4.2.1 Definition and description Certain basic call events may be visible to the GSM Service Control Function (gsmSCF). The DPs are the points in call at which these events are detected. The DPs for Mobile Originated Calls and Mobile Terminated Calls are described in subclausesÊ4.4.2 and 4.4.3. A DP can be armed in order to notify the gsmSCF that the DP was encountered, and potentially to allow the gsmSCF to influence subsequent handling of the call. If the DP is not armed, the processing entity continues the processing without gsmSCF involvement. Three different types of DPs are identified: - Trigger Detection Point - Request (TDP R). This detection point is statically armed and initiates a CAMEL control relationship when encountered and there is no existing relationship due to the same CSI. Processing is suspended when the DP is encountered. - Event Detection Point - Request (EDP R). This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is suspended when encountering the DP and the gsmSSF waits for instructions from the gsmSCF. - Event Detection Point - Notification (EDP N). This detection point is dynamically armed within the context of a CAMEL control relationship. Processing is not suspended when encountering the DP. The DPs are characterized in the following subclauses. 4.2.1.1 Arming/disarming mechanism A DP may be statically armed or dynamically armed. The following arming rules apply: - A DP for mobile terminating call handling is statically armed in the GMSC as a result of T CSI delivery from the HLR. A DP for mobile terminating call handling is statically armed in the VMSC as a result of VT CSI delivery from the VLR. A DP for forwarding leg handling is statically armed in the GMSC as result of O CSI and/or D CSI delivery from the HLR. A DP for mobile originating call or forwarded leg handling is statically armed in the VMSC as a result of O CSI and/or D CSI delivery from the VLR. - A DP is dynamically armed by the gsmSCF within the context of a CAMEL control relationship (between the gsmSSF and the gsmSCF). - A Request Report BCSM Event information flow for a detection point for a leg overwrites any previous Request Report BCSM Event information flow for that detection point for that leg. The following disarming rules apply: - A statically armed DP is disarmed when the O CSI, D CSI, T CSI or VT CSI that caused the DP to be statically armed is withdrawn in the HLR. Only TDP Rs can be disarmed using this mechanism. - If an armed EDP is met, then it is disarmed. - If an EDP is met that causes the release of the related leg, then all EDPs related to that leg are disarmed. - If a call is released, then all EDPs related to that call are disarmed. - If an EDP is met, then other EDPs are disarmed, in accordance with the implicit disarming rule table (seeÊsubclauseÊ4.4.4). - If an EDP is armed, it can be explicitly disarmed by the gsmSCF by means of the Request Report BCSM Event information flow. 4.2.1.2 Criteria Criteria are the conditions that must be met in order for the gsmSSF to request instructions from the gsmSCF. 4.2.1.2.1 Criteria at DPÊCollected_Info The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR may decide not to include the DPÊCollected_Info trigger criteria in the subscriber data sent to the GMSC if the trigger criteria for the call are not met. For optimally routed late forwarded calls, the MSC may decide not to include the DPÊCollected_Info trigger criteria in the Resume Call Handling information flow sent to the GMSC, if the trigger criteria for the call are not met. The following criteria are applicable for DPÊCollected_Info: - Destination number triggering criterion: The HLR may store a list of up to 10 destination numbers and/or up to 3 number lengths. There is no restriction on the nature of address. There is no restriction on the numbering plan indicator. This criterion may be defined to be either ""enabling"" or ""inhibiting"". - Basic service triggering criterion: The HLR may store a list of up to 5 basic service codes, each of which may represent an individual basic service or a basic service group. Compound basic service group codes, as defined in 3GPP TSÊ29.002Ê[34], are not allowed for conditional triggering. This list is a triggering list. - Forwarding triggering criterion: The HLR may store an indicator that triggering shall occur only for a call which has been subject to the Call Forwarding supplementary service, Call Deflection supplementary service or CAMEL call forwarding. This criterion may be defined to be either ""enabling"" or ""inhibiting"". For MO calls, triggering at DPÊCollected_Info shall be strictly based on the number received over the access network. No service selection information, such as ? and # digits, or carrier selection information, dialled by the subscriber, shall be removed from the number before conditional triggering check takes place. For MF calls at the VMSC, triggering at DPÊCollected_Info shall be strictly based on the number received over the access network (the Deflected-to-Number in the case of Call Deflection), the Forwarded-to-Number retained in the VLR or the Destination Routing Address received in the Connect information flow from the gsmSCF during a Terminating CAMEL Service at the VMSC. No service selection information or carrier selection information shall be removed from the number before conditional triggering check takes place. For MF calls at the GMSC, triggering at DPÊCollected_Info shall be strictly based on the Forwarded-to-Number received from HLR, on the Destination Routing Address received in the Connect information flow from the gsmSCF during a Terminating CAMEL Service or on the Forwarded-to-Number received in the Resume Call Handling information flow. No service selection information or carrier selection information shall be removed from the number before conditional triggering check takes place. One or more DP criteria may be applicable. All applicable triggering criteria must be satisfied before the dialogue is established with the gsmSCF. If the destination number triggering criterion is enabling, then the gsmSSF may establish a dialogue with the gsmSCF if: - the destination number matches one of the destination number strings defined in the list, or - the length of the destination number matches one of the destination number lengths defined in the list. In this test the destination number matches one of the destination number strings in the list if: - the nature of address of destination number is the same as the nature of address of the destination number string (The numbering plan indicator is not compared); - the destination number is at least as long as the destination number string in the list, and - all the digits in the destination number string in the list match the leading digits of the destination number. If the destination number triggering criterion is inhibiting, then the gsmSSF may establish a dialogue with the gsmSCF if: - the destination number does not match any of the destination number strings defined in the list, and - the length of the destination number does not match any of the destination number lengths defined in the list. In this test the destination number matches one of the destination number strings in the list if: - the nature of address of the destination number is the same as the nature of address of the destination number string (The numbering plan indicator is not compared); - the destination number is at least as long as the destination number string in the list, and - all the digits in the destination number string in the list match the leading digits of the destination number. The basic service triggering criterion is met if the basic service for the call matches a stored individual basic service code or is a member of the group defined by a stored basic service group code. For a SCUDIF call (see 3GPP TSÊ23.172Ê[27]), the basic service triggering criterion is met if one or both the preferred basic service and the less preferred basic service for the call match a stored individual basic service code or is a member of the group defined by a stored basic service group code. For the purpose of this paragraph a general bearer service is a member of the corresponding bearer service group. If the forwarding triggering criterion is enabling, then the gsmSSF may establish a dialogue with the gsmSCF only if the call has been subject to CAMEL call forwarding or the Call Forwarding supplementary service. If the forwarding triggering criterion is inhibiting, then the gsmSSF may establish a dialogue with the gsmSCF only if the call has not been subject to CAMEL call forwarding or the Call Forwarding supplementary service. 4.2.1.2.2 Criteria at DPÊAnalysed_Information 4.2.1.2.2.1 General The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR shall always include the trigger criteria in the subscriber data sent to the GMSC because that the HLR can not check the criteria applicable at DPÊAnalysed_Info, since the number that the criteria check shall be based on, may be modified by a Mobile Terminating or Mobile Forwarding Service Logic for this call. For optimally routed late forwarded calls, the MSC shall always include the trigger criteria in the Resume Call Handling information flow sent to the GMSC because the MSC can not check the criteria applicable at DPÊAnalysed_Info, since the number that the criteria check shall be based on, may be modified by a Mobile Terminating or Mobile Forwarding Service Logic for this call. The following criteria are applicable for DPÊAnalysed_Information: - Destination number triggering criterion: The HLR may store a list of up to 10 destination numbers. There is no restriction on the nature of address. There is no restriction on the numbering plan indicator. NOTE: The order in which the destination number criteria are checked in the MSC or GMSC is not determined. Hence, overlapping destination number criteria (e.g. use of ""0800"" and ""0800123"" for two different services) should be avoided, because they lead to unpredictable behaviour (i.e. either service might be triggered). For MO calls, triggering at DPÊAnalysed_Info shall be based on the called party number received over the access network or the Destination Routing Address in the Connect information flow from the gsmSCF during a Mobile Originating CAMEL Service. For MF calls at the VMSC, triggering at DPÊAnalysed_Info shall be based on the number received over the access network (the Deflected-to-Number in the case of Call Deflection), the Forwarded-to-Number retained in the VLR, or the Destination Routing Address in the Connect information flow from the gsmSCF during a Mobile Terminated or Mobile Forwarded CAMEL Service. For MF calls at the GMSC, triggering at DPÊAnalysed_Info shall be based on the Forwarded-to-Number received from the HLR, on the Destination Routing Address received in the Connect information flow from gsmSCF during a Mobile Terminated or Mobile Forwarded CAMEL Service, or on the Forwarded-to-Number received in the Resume Call Handling information flow. For NP calls, triggering at DPÊAnalysed_Info shall be based on the number received from gsmSCF. An NP call that is created in the VMSC or GMSC of the served subscriber may be subject to D CSI service and N CSI service. An NP call that is created in an MSC other than the VMSC or GMSC of the served subscriber, may be subject to N CSI service. For NC calls, triggering at DPÊAnalysed_Info shall be based on the number received from the gsmSCF. An NC call may be subject to N CSI service. 4.2.1.2.2.2 Removal of information significant to the serving entity In order to decide whether triggering shall take place, the trigger criteria need to be compared with the address information. Before the comparison takes place the following information shall be removed from the destination address information: - Operator specific service selection information that is recognised and treated locally in the serving entity. This shall not lead to a change of the type of number indicator of the address information. - Carrier selection information. If the removal of carrier selection information also removes international or national (trunk) prefixes (depending on regulatory requirements), then the type of number indicator of the address information shall be changed to ""international number"" or ""national (significant) number"" respectively. Otherwise the type of number indicator shall remain unchanged. The address information in a subsequent Initial DP information flow at DPÊAnalysed_Info shall not contain the removed information, however in the further call handling the serving entity shall invoke the requested services (e.g. carrier selection). 4.2.1.2.2.3 Number comparison The following procedure shall be performed for the comparison of the destination number triggering criterion and the address information in the given order. 1. The numbering plan indicators of the destination number triggering criterion and the destination number are ignored. 2. The type of number/nature of address indicators of the destination number triggering criterion and the destination number are compared. If there is a match of the type of number indicator, then the check shall be performed by comparing the digits as defined in step 6. If there is no match of the type of number the comparison procedure shall continue as follows. 3. If either or both of the address information and destination number triggering criterion includes a types of number/nature of address indicator other than ""unknown"", ""national (significant) number"" or ""international number"" then the destination number does not match the destination number triggering criterion. Otherwise the comparison procedure shall continue as follows. 4."
"If there is a number (address information or destination number triggering criterion) with type of number/nature of address ""unknown"" this number shall be translated based on the numbering plan of the serving entity in either of the following ways: - if the leading digits refer to an international prefix then those digits shall be removed and the type of number/nature of address shall be set to ""international number"". - if the leading digits refer to a national (trunk) prefix then those digits shall be removed and the type of number/nature of address shall be set to ""national (significant) number"". If the leading digits refer neither to an international prefix nor to a national (trunk) prefix, then the destination number does not match the destination number triggering criterion. If there is a match of the type of number/nature of address indicator after this number modification, then the check shall be performed by comparing the digits as defined in step 6, otherwise the comparison procedure shall continue as follows. 5. If the type of number/nature of address of the address information or of the destination number triggering criterion is ""national (significant) number"" this number shall be translated based on the numbering plan of the serving entity to international format by adding the country code of the serving entity to the number string. After this modification the destination number triggering criterion and the destination number shall be in international format and shall be checked by comparing the digits as defined in step 6. 6 If the number of digits in the address information are compared with the number of digits in the destination number triggering criterion, then there is a match if: - the destination number is at least as long as the destination number string of the destination number triggering criterion, and - all the digits in the destination number string of the destination number triggering criterion match the leading digits of the destination number. The check described in this subclause shall be repeated for every number contained in the destination number triggering criterion of the D CSI until there is a match DPÊAnalysed_Info is triggered, or until all the destination numbers have been checked without a match. In the latter case DPÊAnalysed_Info is not triggered. The procedures for the destination number triggering criterion check for N CSI are network specific. The modifications of the address information described in this subclause shall only be done for comparison purposes, i.e. they shall not affect the format of the destination address information sent in the Initial DP information flow. 4.2.1.2.3 Criteria at DPÊRoute_Select_Failure The HLR may store a list of up to 5 cause values. The criteria for a mobile originating call are checked in the originating MSC. The criteria for a mobile forwarded call are checked in the forwarding MSC. For early forwarded calls in the GMSC, the HLR shall always include the trigger criteria in the subscriber data sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the O CSI to the GMSC. For optimally routed late forwarded calls, the MSC shall always include the trigger criteria in the Resume Call Handling information flow sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the O CSI to the GMSC. The following criteria are applicable for DPÊRoute_Select_Failure: - Release cause code. The trigger criteria are met if the cause code received from ISUP is equal to at least one of the cause codes in the trigger criteria list. For the purpose of trigger criteria check, the MSC performing the triggering check shall use the ""cause value"" field of the ISUP ""cause indicators"" parameter, as defined in ITU T Recommendation Q.763Ê[43]. If an O BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. 4.2.1.2.4 Criteria at DPÊTerminating_Attempt_Authorised The HLR may store a list of up to 5 basic service codes, each of which may represent an individual basic service or a basic service group. Compound basic service group codes, as defined in 3GPP TSÊ29.002Ê[34], are not allowed for conditional triggering. This list is a triggering list. The criteria for DPÊTerminating_Attempt_Authorised are checked in the HLR for the GMSC or in the VLR for the MSC. The HLR shall only include T CSI in the CAMEL subscription information sent to the GMSC if the criteria are met. The VLR shall only include VT CSI in the CAMEL subscription information sent to the MSC if the criteria are met. The basic service criterion is met if the basic service for the call matches a stored individual basic service code or is a member of the group defined by a stored basic service group code. For a SCUDIF call (see 3GPP TSÊ23.172Ê[27]), the basic service triggering criterion is met if one or both the preferred basic service and the less preferred basic service for the call match a stored individual basic service code or is a member of the group defined by a stored basic service group code.For the purpose of this paragraph a general bearer service is a member of the corresponding bearer service group. 4.2.1.2.5 Criteria at DPÊT_Busy and T_No_Answer The HLR may store a list of up to 5 cause values. The criteria for a mobile terminating call are checked in the GMSC or in MSC. For mobile terminating calls in the GMSC, the HLR shall include the trigger criteria in the subscriber data sent to the GMSC because the cause code received from ISUP is used in the trigger criteria check. The cause code is not known at the time of sending the T CSI to the GMSC. If the Send Routeing Info ack information flow includes the Not Reachable FTN, then the HLR may decide not to include the trigger criteria, if the HLR has identified that T CSI includes DPÊT_Busy with cause code Not Reachable. If the Send Routeing Info ack information flow includes the Not Reachable FTN and also T CSI, including DPÊT_Busy with cause code, then the not reachable condition shall be mapped to an ISUP release code, which shall be used for the triggering check. For Mobile terminating calls in the VMSC, the trigger criteria are received in the VT CSI from the HLR in the Insert Subscriber Data information flow. The triggering is based on the ISUP release cause code (call set up result). The following criteria are applicable for DPÊT_Busy and DPÊT_No_Answer: - Release cause code. If the cause code is received from ISUP, then the trigger criteria are met if the cause code is equal to at least one of the cause codes in the trigger criteria list. For this check, the MSC shall use the ""cause value"" field of the ISUP ""cause indicators"" parameter, as defined in ITU T Recommendation Q.763Ê[43]. If the cause code is received from MAP, then the trigger criteria are met if the cause code is equal to at least one of the cause codes in the trigger criteria list. For this check, the MSC shall use the cause values as defined in tableÊ4.1. If the trigger criteria are satisfied, then the corresponding Service Logic shall be invoked. If a T BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. When the Resume Call Handling information flow is received in the GMSC and the subscriber has T CSI then the forwarding reason in the Resume Call Handling information flow shall be used to perform the trigger criteria check for DPÊT_Busy or DPÊT_No_Answer. If a match is found, then the corresponding Service Logic shall be invoked. If a T BCSM was already invoked and there is a relationship with the gsmSCF at that moment, then no additional relationship shall be initiated. Table 4.1: Mapping of Send Info For Incoming Call (SIFIC) ack, Send Routeing Info ack (SRI ack) or Resume Call Handling (RCH) to ISUP release causes for triggering criteria check SIFIC ack / SRI ack / RCH ""forwarding reason"" ISUP release cause number ISUP release cause name MS not reachable 20 Subscriber absent MS Busy 17 User busy Call deflection (note) 21 Call rejected No reply 19 No answer from user (user alerted) NOTE: Call Deflection is used only in the Resume Call Handling information flow, and in the VMSC. The same code point in the Send Routeing Info ack indicates CFU. However, the CFU invocation in the GMSC triggers the Terminating_Attempt_Authorised DP; thus the reason code mapping is not needed in the CFU case. 4.2.1.3 Relationship If an armed DP is encountered, the gsmSSF provides an information flow via the already established relationship with the gsmSCF. A relationship between the gsmSSF and the gsmSCF for the purpose of operator specific service processing is considered to be a CAMEL relationship. There are two types of CAMEL relationships: - A CAMEL control relationship if the gsmSCF is able to influence the call processing via the relationship. - A CAMEL monitor relationship if the gsmSCF is not able to influence the call processing via the relationship. 4.2.2 DP processing rules The gsmSSF shall apply the following set of rules during DP processing to ensure a single point of control: - EDPs are disarmed by the gsmSSF as they are encountered and reported to the gsmSCF, when the occurrence of another EDP causes the implicit disarming of the EDP or when the leg clears. - A control relationship persists as long as there is 1 or more EDP R armed for this portion of the call or if the Process CS_gsmSSF is in any state except Monitoring or Idle. - A control relationship changes to a monitor relationship if the control relationship does not persist and: - 1 or more EDP N is armed, or - 1 or more Call information Report is outstanding, or - an Apply Charging Report is outstanding. - If a control relationship does not persist and does not change to a monitor relationship then the relationship terminates. A monitor relationship terminates if there are neither EDP Ns armed nor reports outstanding or if the call clears. 4.3 Description of CAMEL Subscriber Data 4.3.1 Originating CAMEL Subscription Information (O CSI) This subclause defines the contents of the Originating CAMEL Subscription Information. 4.3.1.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊCollected_Info and DPÊRoute_Select_Failure. 4.3.1.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.1.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.1.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.1.5 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.1.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a VLR or GMSC any data for a CAMEL phase later than that which the CAMEL capability handling indicates. E.g. if the CAMEL Capability Handling indicates CAMEL phaseÊ1 then the HLR shall not send triggering criteria to the VLR. Different CSIs may contain different values of CAMEL Capability Handling. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.1.7 CSI state The CSI state indicates whether the O CSI is active or not. 4.3.1.8 Notification flag The notification flag indicates whether the change of the O CSI shall trigger Notification on Change of Subscriber Data. 4.3.2 Dialled Service CAMEL Subscription Information (D CSI) This subclause defines the contents of the Dialled Service CAMEL Subscription Information. 4.3.2.1 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.2.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. A gsmSCF address shall be associated with each DP criterion. 4.3.2.3 Service Key The Service Key identifies to the gsmSCF the service logic to be used. A Service Key shall be associated with each DP criteria. 4.3.2.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is submitted to call gapping in the gsmSSF. A default call handling shall be associated with each DP criteria. 4.3.2.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.2.6 CSI state The CSI state indicates whether the D CSI is active or not. 4.3.2.7 Notification flag The notification flag indicates whether changes of the D CSI shall trigger the Notification on Change of Subscriber Data. 4.3.3 Network CAMEL Service Information (N CSI) The N CSI identifies services offered on a per-network basis by the serving PLMN operator for all subscribers and, if applicable, for all incoming trunk originated calls. This CSI shall be stored in the MSC. 4.3.4 Translation Information Flag CAMEL Subscription Information (TIF CSI) 4.3.4.1 Translation Information Flag The TIF CSI in the CAMEL Subscriber data indicates, - when the subscriber registers a forwarded-to number, that the HLR shall not attempt to perform any translation, number format checks, prohibited FTN checks or call barring checks. (see 3GPP TSÊ23.082Ê[20]). - when the subscriber invokes the Call Deflection supplementary service, that the VLR shall not attempt to perform any translation, number format checks, prohibited DTN checks, call barring checks. (seeÊ3GPP TSÊ23.072Ê[16]). 4.3.4.2 Notification flag The notification flag indicates whether the change of the TIF CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.5 Terminating CAMEL Subscription Information (in the GMSC) (T CSI) This subclause defines the contents of the Terminating CAMEL Subscription Information. 4.3.5.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊTerminating_Attempt_Authorised, DPÊT_Busy, and DPÊT_No_Answer. 4.3.5.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.5.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.5.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.5.5 DP criteria The DP criteria indicate whether the gsmSSF shall request instructions from the gsmSCF. 4.3.5.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a GMSC any data for a CAMEL phase later than that which the CAMEL capability handling indicates. Different CSIs may contain different values of CAMEL Capability Handling. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the GMSC, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (e.g. support of a lower version of CSI). 4.3.5.7 CSI state The CSI state indicates whether the T CSI is active or not. 4.3.5.8 Notification flag The notification flag indicates whether the change of the T CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.6 VMSC Terminating CAMEL Subscription Information (VT CSI) This subclause defines the contents of the Terminating CAMEL Subscription Information for the VMSC. 4.3.6.1 TDP List The TDP List indicates on which detection point triggering shall take place. The following trigger detection points are possible: DPÊTerminating_Attempt_Authorised, DPÊT_Busy, and DPÊT_No_Answer. 4.3.6.2 gsmSCF address The gsmSCF address indicates the address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. Different gsmSCF addresses may be associated with different TDPs. 4.3.6.3 Service Key The Service Key indicates to the gsmSCF the service logic to be used. Different Service Keys may be associated with different TDPs. 4.3.6.4 Default Call Handling The Default Call Handling indicates whether the call shall be released or continued as requested if there is an error in the gsmSSF to gsmSCF dialogue or if the call is subject to call gapping in the gsmSSF. A default call handling shall be associated with each Service Key. 4.3.6.5 DP criteria The DP criteria indicate whether the gsmSSF shall request the gsmSCF for instructions. 4.3.6.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is requested by the gsmSCF for the service. The HLR shall not include in a CSI which it sends to a VLR any data for a CAMEL phase later than that which the CAMEL capability handling indicates. NOTE: If CAMEL is not supported or if a lower phase of CAMEL is supported in the VLR, the HLR can decide on a subscriber basis to apply ODB, perform normal call handling or perform operator specific handling (eventually support of a lower version of CSI). 4.3.6.7 CSI state The CSI state indicates whether the VT CSI is active or not. 4.3.6.8 Notification flag The notification flag indicates whether the change of the VT CSI shall trigger Notification on Change of Subscriber Data or not. 4.3.7 Other CAMEL data 4.3.7.1 Location information/Subscriber state Interrogation This data indicates whether additional subscriber information shall be sent to the GMSC as part of the terminating call handling. - an indication that the HLR shall send the location information of the called subscriber. - an indication that the HLR shall send the subscriber state of the called subscriber. 4.3.7.2 gsmSCF address list for CSI The gsmSCF address list for CSI indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 4.3.8 Trunk Originated CAMEL Service Information (TO-CSI) The TO CSI identifies services offered on a MSC basis by the serving PLMN operator for all incoming calls on a specific MSC trunk. This CSI shall be stored in the MSC. The contents of the TO-CSI is outside the scope of this specification. When processing trunk originating calls requiring CAMEL support, the TO-CSI informs the MSC to request instructions from the gsmSSF. The MSC monitors on request the call states (events) and informs the gsmSSF of these states during processing, enabling the gsmSSF to control the execution of the call in the MSC. Certain basic call events may be visible to the GSM Service Control Function (gsmSCF). The DPs are the points in call at which these events are detected. The DPs for Trunk Originated Calls are described in subclausesÊ4.4.2. Dynamic arming/ disarming rules for TO calls are specified in subclause 4.2.1.1. Static arming/ disarming of DP Collected_Info for TO calls shall use the following rules: - A DP for trunk originating call is statically armed in the MSC as a result of TO CSI for the specific MSC trunk. - A statically armed DP is disarmed when the TO CSI that caused the DP to be statically armed is withdrawn from the MSC. TDP Criteria may be defined for the case when collection of dialled digits has been performed. Criteria may be based on the contents and/ or length of the dialled number, basic service, call type or other information at the discretion of the network operator, however this is outside the scope of this specification. DP processing rules for TO calls are defined in subclause 4.2.2. 4.4 Description of CAMEL BCSMs 4.4.1 General Handling The BCSM is used to describe the actions in an MSC or GMSC or VMSC during originating, forwarded or terminating calls. The BCSM identifies the points in basic call processing when Operator Specific Service (OSS) logic instances (accessed through the gsmSCF) are permitted to interact with basic call control capabilities. FigureÊ4.2 shows the components that have been identified to describe a BCSM. Figure 4.2: BCSM Components 4.4.2 Originating Basic Call State Model (O BCSM) 4.4.2.1 Description of O BCSM The O BCSM is used to describe the actions in an MSC during originating (MSC) , forwarded (MSC or GMSC) and trunk originating (MSC) calls. When encountering a DP the O BCSM processing is suspended at the DP and the MSC or GMSC indicates this to the gsmSSF which determines what action, if any, shall be taken if the DP is armed. For gsmSCF initiated new calls the O BCSM is initially suspended at DPÊCollected_Info. NOTE: The DPÊO_Busy also includes the 'not reachable' case. Figure 4.3: Originating BCSM for CAMEL The table below defines the different DPs which apply to mobile originating and forwarded calls and trunk originating calls. Table 4.2: Description of O BCSM DPs in the MSC CAMEL Detection Point: DP Type Description: DPÊCollected_Info TDP R, EDP-R (note 7) Indication that the O CSI is analysed, the gsmSCF has initiated a call attempt (in this case the DP is neither triggered nor reported) or additional digits have been collected. DPÊAnalysed_Information TDP RÊ(noteÊ2) Availability of routeing address and nature of address. DPÊRoute_Select_Failure TDP RÊ(noteÊ3), EDP N, EDP R Indication that the call establishment failed. DPÊO_Busy EDP N, EDP R Indication that: - a busy indication is received from the terminating party, - a not reachable event is determined from a cause IE in the ISUP Release message. DPÊO_No_Answer EDP N, EDP R Indication that: - an application timer associated with the O_No_Answer DP expires, - a no answer event is determined from a cause IE in the ISUP Release message. DPÊO_Term_Seized EDP N, EDP R Indication that the called party is being alerted. DPÊO_Answer EDP N, EDP R Indication that the call is accepted and answered by the terminating party. DPÊO_Mid_Call EDP N, EDP R Indication that a service/service feature indication is received from the originating party (DTMF - noteÊ4, noteÊ5). DPÊO_Change_Of_Position EDP N Indication that the originating party has changed position (noteÊ6). DPÊO_Disconnect EDP N, EDP R A disconnect indication is received from the originating party or from the terminating party. DPÊO_Abandon EDP N, EDP R Indication that a disconnect indication is received from the originating party during the call establishment procedure. DPÊO_Service_Change EDP N Indication that the bearer service has changed. NOTE 1: The DPs are defined in ITU T Recommendation Q.1224Ê[44]. NOTE 2: For TDP R Analysed_Information new relationship to gsmSCF is opened. NOTE 3: DPÊRoute_Select_Failure shall be reported as TDP R when there is no relationship to gsmSCF. If a relationship to gsmSCF is already open, it shall be reported as EDP R or EDP N if armed so. DP Route_Select_Failure cannot be armed as TDP-R for Trunk Originating Calls. NOTE 4: DTMF is only applicable for the Mobile Originating or Trunk Originating Call in the VMSC. DTMF is not applicable at the O_Alerting PIC. NOTE 5: Call Processing is suspended at DPÊO_Mid_Call if a Call Party Handling information flow is handled. However, the DP is not reported. NOTE 6: DPÊO_Change_Of_Position is applicable only for the Mobile Originating Call in the VMSC. NOTE 7: DP Collected_Info as a EDP-R is applicable only for Trunk Originating Calls. 4.4.2.1.1 Description of the call model (PICs) This subclause describes the call model for originating and forwarded calls. For each PIC a description can be found of the entry events, functions and exit events. It should be noted that although the names used for PICs match those used in ITU T Recommendation Q.1224Ê[44] the specific descriptions differ. 4.4.2.1.1.1 O_Null & Authorise_Origination_Attempt_Collect_Info Entry events: - Disconnection and clearing of a previous call (DPÊO_Disconnect) or default handling of exceptions by gsmSSF/(G)MSC completed. - Abandon event is reported from Analyse_Information or Routing and Alerting PIC. - Exception event is reported. - gsmSCF requests additional digits (DP CollectedInfo or DP AnalysedInfo). Actions: If entry event is 'gsmSCF requests additional digits' then MSC starts collecting additional digits. Otherwise: - Interface is idled. - Mobile Originating call: - SETUP information flow containing the dialled number is received from MS, preceeding call leg or originating exchange. - The supplementary service ""barring of all outgoing calls"" is checked and invoked if necessary. - The ODB category ""barring of all outgoing calls"" is checked and ODB is invoked if necessary. NOTE: the ODB category ""barring of all outgoing calls when roaming"" causes the HLR to send the category ""barring of all outgoing call"" if the VLR is not in the HPLMN. - CUG checks done in the originating MSC/VLR are performed. - Information being analysed e.g. O-CSI is analysed. - Trunk Originating call: - The initial information flow containing the complete dialled number or an initial information package/ dialling string is received from the trunk interface. - Any operator specific service checks done in the originating MSC are performed. - Information being analysed e.g., TO CSI is analysed. Exit events: If entry event was 'gsmSCF requests additional digits' then: - Additional digits collected. - Inter-digit timer expires - An exception condition is encountered. For example, collection of additional digits fails due to a lack of switch resources (e.g. no digit receivers are available) or calling party abandons call. Otherwise: - Originating CSI is analysed. - Trunk Originating CSI is analysed. - An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP. Example exception condition: Calling party abandons call. 4.4.2.1.1.2 Analyse_Information Entry events: - Originating CSI is analysed. (DPÊCollectedÊInfo). - Trunk Originating CSI is analysed (DP Collected Info). - Additional digits collected (DP Collected Info) in trunk originated call. - The gsmSCF has initiated a call attempt (DPÊCollected_Info). In this case the DP has neither been triggered nor has it been reported. - New routeing information is received when the Busy event (DPÊO_Busy), Route Select Failure event (DPÊRoute_Select_Failure), Not Reachable event (DPÊO_Busy) or No Answer event (DPÊO_No_Answer) is reported from the Routing and Alerting PIC. - New routeing information is received when the Disconnect event is reported from the O_Active PIC. Actions: - Compare the called party number with the dialled services information. Exit events: - Availability of routeing address and nature of address. (DPÊAnalysed_Information). - An exception condition is encountered (e.g. invalid number); this leads to the O_Exception PIC. - The calling party abandons the call; this leads to the O_Abandon DP. 4.4.2.1.1.3 Routing Entry events: - Availability of routeing address and nature of address. (DPÊAnalysed_Information). Actions: - Information is being analysed and/or translated according to dialling plan to determine routeing address. - Routeing address being interpreted. - Mobile Originating or forwarded call: Outgoing barring services and ODB categories not already applied are checked and invoked if necessary. - Trunk Originating call: Any operator specific service checks in the originating MSC are performed. Exit events: - An alerting indication (ISUP ACM) is received from the terminating party; this leads to the O_Term_Seized DP. - The attempt to select the route for the call fails; this leads to the Route_Select_Failure DP. - A busy indication is received from the terminating party; this leads to the O_Busy DP. - A not reachable indication is received from the terminating party; this leads to the O_Busy DP. - A no reply indication is received from the terminating party or a no reply condition is determined at the MSC/ gsmSSF; this leads to the O_No_Answer DP - An indication is received from the terminating half BCSM that the call is accepted and answered by the terminating party; this leads to O_Answer DP. - The calling party abandons the call' this leads to the O_Abandon DP. - An exception condition is encountered; this leads to the O_Exception PIC. 4.4.2.1.1.4 O_Alerting Entry events: - Called Party is being alerted (DPÊO_Term_Seized). - Continue is received in O_Mid_Call DP. Actions: - Call is being processed by the terminating half BCSM. Waiting for indication from terminating half BCSM that the call has been answered by terminating party. - Send a notification to the gsmSCF if the originating party changes position and DPÊO_Change_Of_Position is armed. Exit events: - An indication is received from the terminating half BCSM that the call is accepted and answered by the terminating party; this leads to the O_Answer DP. - A route select failure indication is received from the terminating party; this leads to the Route_Select_Failure DP. - A busy indication is received from the terminating party; this leads to the O_Busy DP. - A not reachable indication is received from the terminating party; this leads to the O_Busy DP. - A no reply indication is received from the terminating party or a no reply condition is determined at the MSC/ gsmSSF; this leads to the O_No_Answer DP. - The calling party abandons the call; this leads to the O_Abandon DP. - An exception condition is encountered; this leads to the O_Exception PIC. 4.4.2.1.1.5 O_Active Entry events: - Indication from the terminating half BCSM that the call is accepted and answered by the terminating party. (DPÊO_Answer) - Continue is received in O_Mid_Call DP. Actions: - Connection established between originating party and terminating party. Call supervision is provided. - Send a notification to the gsmSCF if the originating party changes position and DPÊO_Change_Of_Position is armed. - Send a notification to the gsmSCF if the bearer is changed due to the SCUDIF and DPÊO_Service_Change is armed. - Call release is awaited. Exit events: - A service/service feature request is received from the originating party (DTMF) or DPÊO_Mid_Call is used for Call Party Handling (DPÊO_Mid_Call). - A disconnection indication is received from the originating party, or received from the terminating party via the terminating half BCSM (DPÊO_Disconnect). - An exception condition is encountered. 4.4.2.1.1.6 O_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIC can not be met. Actions: - Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If any relationship exists between the gsmSSF and the gsmSCF, the gsmSSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion. - The (G)MSC/gsmSSF should make use of vendor-specific procedures to ensure release of resources within the (G)MSC/gsmSSF, so that line, trunk and other resources are made available for new calls. Exit events: - Default handling of the exception condition by gsmSSF/(G)MSC completed. 4.4.3 Terminating Basic Call State Model (T BCSM) 4.4.3.1 Description of T BCSM The T BCSM is used to describe the actions in a GMSC and in a VMSC during terminating calls. When encountering a DP the T BCSM processing is suspended at the DP and the GMSC or VMSC indicates this to the gsmSSF which determines what action, if any, shall be taken if the DP is armed. Figure 4.4: T BCSM in the GMSC or VMSC In the table below the different DPs (in the T BCSM) are described. Table 4.3: Description of T BCSM DPs in the GMSC or VMSC CAMEL Detection Point: DP Type Description: DPÊTerminating_Attempt_ Authorised TDP R Indication that the T CSI / VT CSI is analysed. DPÊT_Busy TDP RÊ(noteÊ2), EDP N, EDP R Indication that: - a busy indication is received from the destination exchange, - Busy event is determined in the visited MSC, - Not reachable or call establishment failure event is determined from the HLR response or upon a cause IE in the ISUP Release message. DPÊT_No_Answer TDP R (noteÊ2), EDP N, EDP R Indication that: - an application timer associated with the T_No_Answer DP expires - a no answer event is determined from a cause IE in the ISUP Release message. DPÊCall_Accepted EDP N, EDP R Indication that the called party is being alerted. DPÊT_Answer EDP N, EDP R Call is accepted and answered by terminating party. DPÊT_Mid_Call EDP N, EDP R Indication that a service/service feature is received from the terminating party (DTMF - noteÊ3, noteÊ4). DPÊT_Change_Of_Position EDP N Indication that the terminating party has changed position (noteÊ5). DPÊT_Disconnect EDP N, EDP R A disconnect indication is received from the terminating party or from the originating party. DPÊT_Abandon EDP N, EDP R A disconnect indication is received from the originating party during the call establishment procedure. DPÊT_Service_Change EDP N Indication that the bearer service has changed. NOTE 1: The DPs are defined in ITU T Recommendation Q.1224Ê[44]. NOTE 2: DPÊT_No_Answer and DPÊT_Busy shall be reported as TDP R when there is no relationship to gsmSCF. If a relationship to gsmSCF is already open, it shall be reported as EDP R or EDP N if armed so. NOTE 3: DTMF is only applicable for the VMSC but not for the GMSC. DTMF is not applicable at the T_Alerting PIC. NOTE 4: Call Processing is suspended at DPÊT_Mid_Call if a Call Party Handling information flow is handled. However, the DP is not reported. NOTE 5: DPÊT_Change_Of_Position is applicable only for the Mobile Terminating Call in the VMSC. 4.4.3.1.1 Description of the call model (PICs) This subclause describes the call model for terminating calls in the GMSC and in the VMSC. For each PIC a description can be found of the entry events, functions, information available and exit events. It should be noted that although the names used for PICs match those used in ITU T Recommendation Q.1224Ê[44] the specific descriptions differ. 4.4.3.1.1.1 T_Null Entry events: - Disconnection and clearing of a previous call (DPÊT_Disconnect) or default handling of exceptions by gsmSSF/GMSC or VMSC completed. - Abandon event is reported from Terminating Call Handling PIC. - Exception event is reported. Actions: - Interface is idled. - If ISUP Initial Address Message is received, the appropriate information is analysed. - If the T BCSM is in the GMSC, a Send Routeing Info information flow is sent to the HLR. - If the T BCSM is in the VMSC, a Send Info For Incoming Call information flow is sent to the VLR. - If the T BCSM is in the GMSC: - The supplementary services ""barring of all incoming calls"" and ""barring of incoming calls when roaming"" are checked in the HLR and invoked if necessary. - The ODB categories ""barring of all incoming calls"" and ""barring of incoming calls when roaming"" are checked in the HLR and ODB is invoked if necessary. - The supplementary service ""CUG"" is checked in the HLR and invoked if necessary. - T CSI/VT CSI is received and analysed. Exit events: - Response is received from HLR or VLR and terminating CSI (if available) is analysed. - An exception condition is encountered. For this PIC, if the call encounters one of these exceptions during the PIC processing, the exception event is not visible because there is no corresponding DP. Example exception condition is: - The calling party abandons call. 4.4.3.1.1.2 Terminating Call Handling Entry events: - Response is received from HLR or VLR and terminating CSI (if available) is analysed (DPÊTerminating_Attempt_Authorised). - New routeing information is received when a Busy or not reachable event (DPÊT_Busy) or a No Answer event (DPÊT_No_Answer) is reported from the Terminating Call Handling PIC. - New routeing information is received when a Disconnect event is reported from the T_Active PIC."
"NOTE: The HLR may use MAP signalling to indicate to the GMSC before the call is extended to the destination VMSC that the terminating party is not reachable, or the destination VMSC may use telephony signalling to indicate to the GMSC after the call has been extended to the destination VMSC that the terminating party is not reachable. Actions: - The response from the HLR or VLR is analysed. - Routeing address and call type are interpreted. The next route or terminating access is selected. - The Call Forwarding supplementary service is invoked if necessary. Exit events: - The call is accepted and answered by terminating party; this leads to the T_Answer DP. - An indication is received that the called party is being alerted; this leads to the Call_Accepted DP. - An exception condition is encountered; this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC or GMSC was not successful. - The calling party abandons the call; this leads to the T_Abandon DP. - The terminating access is busy in the VMSC or a busy indication is received from the destination exchange in the GMSC; this leads to the T_Busy DP. - A not reachable event detected or failure of attempt to select the route for the terminating leg in the GMSC fails or the MS cannot be reached in the VMSC; this leads to the T_Busy DP. - The no reply timer expires; this leads to the T_No_Answer DP. 4.4.3.1.1.3 T_Alerting Entry events: - Called party is being alerted (DPÊCall_Accepted) - Continue is received in T_Mid_Call DP. Actions: - Waiting for the call to be answered by terminating party. - The Call Forwarding supplementary service is invoked if necessary. - Send a notification to the gsmSCF if the terminating party changes position and DPÊT_Change_Of_Position is armed. Exit events: - The call is accepted and answered by terminating party; this leads to the T_Answer DP. - An exception condition is encountered; this leads to the T_Exception PIC. Example exception conditions: the call setup to the MSC or GMSC was not successful. - The calling party abandons the call; this leads to the T_Abandon DP. - A busy indication (UDUB) is received from the destination exchange; this leads to the T_Busy DP. - A not reachable event is detected or the attempt to select the route for the terminating leg in the GMSC fails or the MS cannot be reached in the VMSC; this leads to the T_Busy DP. - The no reply timer expires; this leads to the T_No_Answer DP. - A Call Party Handling information flow is executed; this leads to the T_Mid_Call DP. 4.4.3.1.1.4 T_Active Entry events: - Indication that the call is accepted and answered by the terminating party. (DPÊT_Answer). - Continue is received in T_Mid_Call DP. Actions: - Connection established between originating party and terminating party. Call supervision is being provided. - Send a notification to the gsmSCF if the terminating party changes position and DPÊT_Change_Of_Position is armed. - Send a notification to the gsmSCF if the bearer is changed due to the SCUDIF and DPÊT_Service_Change is armed. - Wait for call release. Exit events: - A disconnection indication is received from the terminating party, or received from the originating party via the originating half BCSM; this leads to the T_Disconnect DP. - An exception condition is encountered. In addition to the specific examples listed above, exception events include any type of failure that means that the normal exit events for a PIC cannot be met. - A service/service feature request is received from the called party (DTMF) or a Call Party Handling information flow is executed; this leads to the T_Mid_Call DP. 4.4.3.1.1.5 T_Exception Entry events: - An exception condition is encountered. In addition to the specific examples listed above, exception events include any type of failure, which means that the normal exit events for PIC cannot be met. Actions: - Default handling of the exception condition is being provided. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If any relationship exists between the gsmSSF and the gsmSCF, the gsmSSF shall send an error information flow closing the relationships and indicating that any outstanding call handling instructions will not run to completion. - The GMSC or VMSC / gsmSSF should make use of vendor-specific procedures to ensure release of resources within the GMSC or VMSC / gsmSSF, so that line, trunk and other resources are made available for new calls. Exit events: - Default handling of the exception condition by gsmSSF/GMSC is completed. 4.4.4 Rules for Implicit Disarming of Event Detection Points The tables below give the rules for implicit disarming of event detection points. Implicit EDP disarming rules are specified in the tables below for Originating BCSM and Terminating BCSM respectively. Each table specifies which EDP's shall be disarmed (i.e. MonitorMode set to Transparent) if/when each EDP is encountered, irrespective of the EDP's Monitor Mode (Transparent, Notify And Continue, or Request). When EDPs armed with MonitorMode 'Request' (EDP Rs) are encountered, any implicit EDP disarming shall take place before reporting the EDP and transiting the gsmSSF to the Waiting_For_Instruction state (if not already suspended in the Waiting_For_Instruction state). If the BCSM has encountered DPÊO/T_Answer then an originator release must be detected as a DPÊO/T_Disconnect. The table entry 'X' means that if the DP is encountered (independently of arming and reporting to the gsmSCF) the marked DP is implicitly disarmed. It shall be possible to rearm explicitly an implicitly disarmed DP, e.g. for follow on call. Table 4.4: Implicit disarmed DPs in the O BCSM Encountered DP Implicit disarmed DPs Collected_Info Route_Select_Failure O_Busy O_No_Answer O_Answer O_Mid_Call Leg 1 O_Disconnect Leg 1 O_Disconnect any other Leg O_Abandon O_Term_Seized O_Change_Of_Position O_Service_Change Collected_Info X Route_Select_Failure X X X X X X O_Busy X X X X X X O_No_Answer X X X X X X O_Answer X X X X X X O_Mid_Call Leg 1 (noteÊ1) X O_Disconnect Leg 1 X X X X X O_Disconnect any other Leg X X X X X X O_Abandon X X X X X X O_Term_Seized X O_Change_Of_Position (noteÊ1) X O_Service_Change (noteÊ1) X Note 1 If the Automatic Rearm IE was present in the Request Report BCSM Event information flow for the O_Change_Of_Position DP, O_Service_Change or the O_Mid_Call DP and armed as EDP N, then the DP shall be automatically rearmed by the gsmSSF when it is encountered. Table 4.5: Implicit disarmed DPs in the T BCSM Encountered DP Implicit disarmed DPs T_Busy T_No_Answer T_Answer T_Mid_Call Leg 2 T_Disconnect Leg 1 T_Disconnect Leg 2 T_Abandon Call_Accepted T_Change_Of_Position T_Service_Change T_Busy X X X X X X X X T_No_Answer X X X X X X X X T_Answer X X X X X T_Mid_Call Leg 2 (noteÊ1) X T_Disconnect Leg 1 X X T_Disconnect Leg 2 X X X X X X X X T_Abandon X X Call_Accepted X T_Change_Of_Position (noteÊ1) X T_Service_Change (noteÊ1) X Note 1 If the Automatic Rearm IE was present in the Request Report BCSM Event information flow for the T_Change_Of_Position DP, T_Service_Change or the T_Mid_Call DP and armed as EDP N, then the DP shall be automatically rearmed by the gsmSSF when it is encountered. 4.4.5 BCSM Modelling of Call Scenarios This subclause describes how the BCSMs defined above are used to model CS call scenarios. For each scenario the used and unused BCSMs involved in the call are shown. In some cases these models may have an allocation to physical nodes different from that shown. However, the physical separation of the logical functions shown shall not impact the modelling. This subclause describes the call scenarios without optimal routeing. If optimal routeing is invoked then the physical configurations may be different from those shown, but the modelling is not changed. CAMEL may be applied simultaneously and independently for each subscriber involved in a call. This is not shown in these scenarios. Subscribers other than those being served by CAMEL may be either PSTN subscribers, other subscribers or any other addressable subscriber. 4.4.5.1 Mobile Originated Call For the call from A to B, an instance of the O BCSM will be created in the MSC (labelled ""O(A B)""). If the A party has an active O CSI or D CSI, or the MSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship with gsmSCF(1) shall be established. Figure 4.5: BCSM Scenario for Mobile Originated Call 4.4.5.2 Mobile Terminated Call at the GMSC or VMSC For the call from A to B, an instance of the T BCSM will be created in the GMSC (labelled ""T(A B)"") and an instance of the T BCSM will be created in the VMSC (labelled ""T(A B)""). If the B party has an active T CSI in the GMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC and the gsmSCF(1) shall be established. If the B party has an active VT CSI in the VMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the VMSC and the gsmSCF(2) shall be established. The relationships with gsmSCF (1) and gsmSCF(2) may exist simultaneously. The two gsmSCF endpoints of the relationships are treated independently. The nodes gsmSCF (1) and gsmSCF (2) may be the same or different entities. Figure 4.6: BCSM Scenario for Mobile Terminated Calls at the GMSC or VMSC 4.4.5.3 Call Forwarding at the GMSC or VMSC If the B party has an active T CSI in the GMSC or VT CSI in the VMSC and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(1) shall be established. Following processing at the GMSC or VMSC the call will be extended to the VMSC serving the B party. This VMSC may be physically integrated with the GMSC. A new call leg to a ""C"" party shall be created if: - a Call Forwarding supplementary service or Call Deflection supplementary service forwards the call to C. An instance of the O BCSM O(B C) will be created for the forwarding leg. If the B party has an active O CSI or D CSI in the GMSC or VMSC, or the GMSC or VMSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(2) shall be established. If the GMSC or VMSC receives the 'Suppress O-CSI' parameter, then O CSI shall not be used for the forwarding leg or deflecting leg; or - a CAMEL service in a control relationship with T(A B) performs a CAMEL-based call forwarding by using a Connect information flow. An instance of the O BCSM O(B C) will be created for the forwarding leg. If the B party has an active O CSI or D CSI in the GMSC or VMSC, or the GMSC or VMSC has an active N CSI, and the trigger criteria, if present, are fulfilled, then a CAMEL control relationship between the GMSC or VMSC and the gsmSCF(2) shall be established. The O CSI shall be used for the forwarding leg only if the last Connect information flow includes the ""O CSI applicable"" flag. The relationship with gsmSCF (1) and the relationship with gsmSCF(2) may exist simultaneously. The two relationships are treated independently at the GMSC. The instance of the BCSM T(A B) and the instance of the BCSM O(B C) are linked by an internal interface which is assumed to behave in a similar way to an ISUP interface. The nodes gsmSCF (1) and gsmSCF (2) may be the same or different physical entities. Figure 4.7: BCSM Scenario for Call Forwarding at the GMSC or VMSC 4.4.5.4 gsmSCF Initiated Call When the gsmSCF wishes to originate a new call, the gsmSCF establishes communication with the network using CAP signalling. When the gsmSCF wishes to originate a new leg within an existing call, the gsmSCF uses the already established communication with the gsmSSF. It sends an Initiate Call Attempt information flow which shall contain the address of the called party. Afterwards the gsmSCF shall instruct the gsmSSF to continue with the call processing. The MSC constructs an ISUP Initial Address Message using the parameters received from the gsmSCF and sends it to the destination exchange. The O BCSM for the gsmSCF initiated call to B (labelled ""O(M B)"") is invoked on request of the gsmSCF. A control relationship with gsmSCF (1) is created for the initiation of a new call. NOTE: The term ISUP is used to denote UNI or NNI signalling system used in a given network. Figure 4.8: BCSM Scenario for gsmSCF Initiated New Call 4.4.5.5 Trunk Originated Call For the call from A to B, an instance of the O BCSM will be created in the MSC (labelled ""O(A B)""). If the MSC has an active TO CSI for the trunk on which the call has originated, or an active N-CSI, and the trigger criteria (if present) are fulfilled, then a CAMEL control relationship with gsmSCF(1) shall be established. Figure 4.4.5.5.1: BCSM Scenario for Trunk Originated Call 4.4.6 Leg Handling A call may consist of several call parties with each party connected to the call, e.g. there may be a calling party and several called parties. From a call handling point of view it is necessary to distinguish between a leg, which is a concept internal to the call handling model, and a connection, which is the external link to the party. A connection to the call party will be set up using telephony (e.g. ISUP) or radio access signalling. The outgoing leg already exists when the connection is set up. On the other hand, if a connection is released, e.g. because the destination user is busy, the leg still exists, and the gsmSCF can send a Connect Information Flow to connect this leg to another call party. 4.4.6.1 Leg is created For the purposes of the formal description, one or more legs are created in the following cases: - When a call is to be established, i.e. when an incoming Setup or ISUP IAM is being handled or when a call is to be forwarded, the incoming leg (leg1) and the outgoing leg (leg2) are created before the first CS_gsmSSF process is invoked for that call in this MSC. In particular, this applies before the Call Control Function (CCF) sends DP_Collected_Info (for originating, forwarded or deflected calls) or DP_Terminating_Attempt_Authorised (for terminating calls) to the CS_gsmSSF process; - When the CS_gsmSSF process receives an Initiate Call Attempt Information Flow, an outgoing leg is created. 4.4.6.2 Leg continues to exist For the purposes of the formal description, a leg continues to exist in the following cases: - The CCF sends any DP to the CS_gsmSSF the leg will continue to exist at least until the CS_gsmSSF instructs the CCF to continue its processing for the leg; - A connection to a called party is not successful and the gsmSCF sends a new Connect Information Flow for that leg; - A called party releases her connection and the gsmSCF sends a new Connect Information Flow for that leg; - The CS_gsmSSF processes either of the Call Party Handling Information Flows Move Leg and Split Leg; 4.4.6.3 Leg is released Before a leg is released the corresponding connection is released. All outstanding reports for the leg are sent to the gsmSCF and the corresponding call records are closed. For the purposes of the formal description, a leg ceases to exist when any of the following events occurs: - The calling party releases the connection, the CCF sends a DP to the CS_gsmSSF and the CCF receives Int_Continue or Int_Continue_With_Argument from the CS_gsmSSF process; - A connection to a called party is not successful (DPs Route_Select_Failure, O_Busy, O_No_Answer, T_Busy and T_No_Answer), the CCF sends a DP to the CS_gsmSSF and the CCF does not receive Int_Connect for that outgoing leg from the CS_gsmSSF; - The called party releases her connection, the CCF sends a DP to the CS_gsmSSF and the CCF does not receive Int_Connect for that outgoing leg from the CS_gsmSSF; - The CCF receives Int_Disconnect_Leg from the CS_gsmSSF; - The timer Tcp expires for a leg and the condition ""Release if duration exceeded"" is true for that leg; - The CCF receives Int_Release_Call from the CS_gsmSSF. If a call is released, either on instruction from the CS_gsmSSF or on normal call handling without any CAMEL interaction, then all legs involved in the call cease to exist. 4.4.6.4 Leg is moved A leg can be moved from one call segment (source call segment) to another call segment (target call segment) as a result of a Move Leg or Split Leg information flow. When the CSA_gsmSSF receives a Split Leg Information Flow it creates a new call segment and moves the specified leg into this call segment. When the CSA_gsmSSF receives a Move Leg Information Flow it moves the specified leg into call segmentÊ1. A leg is no longer contained in the source call segment when the source CS_gsmSSF receives Int_Export_Leg_ack from the CCF. A leg is contained in the target call segment when the target CS_gsmSSF receives Int_Import_Leg_ack from the CCF. 4.5 Procedures for CAMEL The SDLs in the present document illustrate how CAMEL modifies the normal call handling. They do not attempt to show all the details of call handling in nodes that support CAMEL. Relevant parts of 3GPP TSÊ23.018Ê[12] apply in addition to these SDLs. For example, some inputs leading to unsuccessful call attempts are not shown on these diagrams - corresponding clauses in 3GPP TSÊ23.018Ê[12] apply. Note that in some SDL processes and procedures the Release information flow may be sent on both an access interface and an inter-switch interface. If the message is sent on a UNI, its effect is the same as a Release transaction information flow. The text in this clause is a supplement to the definition in the SDL diagrams; it does not duplicate the information in the SDL diagrams. 4.5.1 Overall SDL architecture The following mapping from the SDL procedures to the Intelligent Network concepts apply: SDL process Description SDL process specification CSA_gsmSSF Call Segment Association (CSA). The CSA SDL process distributes the CAP operations to the appropriate Call Segment(s). 3GPP TSÊ23.078 CS_gsmSSF Call Segment (CS). Controls one or more BCSMs. 3GPP TSÊ23.078 OCH_MSC O BCSM in VMSC for Mobile Originating call controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_OCH_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_OCH_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_OCH_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 MT_GMSC T BCSM in the GMSC controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Terminating_Attempt_Authorised), then the call is not routed to the destination and the process spawns the child process CAMEL_MT_LEG1_GMSC to control LegÊ1. The process MT_GMSC terminates. If Answer is received, the process spawns the child process CAMEL_MT_LEG1_GMSC to control LegÊ1 and calls the procedure CAMEL_MT_LEG2_GMSC to control LegÊ2. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 MT_CF_MSC O BCSM in the redirecting MSC for Call Forwarding supplementary service, or Call Deflection supplementary service, or for CAMEL-based call forwarding. This process controls both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_MT_CF_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_MT_CF_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_MT_CF_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 ICH_MSC T BCSM in the VMSC controlling both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Terminating_Attempt_Authorised), then the call is not routed to the destination and the process spawns the child process CAMEL_ICH_LEG1_MSC to control LegÊ1. The process ICH_MSC terminates. If Answer is received, the process spawns the child process CAMEL_ICH_LEG1_MSC to control LegÊ1 and calls the procedure CAMEL_ICH_LEG2_MSC to control LegÊ2. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 TO_MSC O-BCSM in the inter-connecting MSC for trunk originated calls. This process controls both LegÊ1 and LegÊ2. If CAP Disconnect LegÊ(legÊ2) is received at the initial detection point (Collected_Info), then the call is not routed to the destination and the process calls the procedure CAMEL_TOC_LEG1_MSC to control LegÊ1. If Answer is received, the process spawns the child process CAMEL_MT_CF_LEG2_MSC to control LegÊ2 and calls the procedure CAMEL_TOC_LEG1_MSC to control LegÊ1. The handling of the legs after answer is completely separate. 3GPP TSÊ23.018 Assisting_MSC The process in the MSC to handle an assist request. 3GPP TSÊ23.078 CAMEL_ICA_MSC O BCSM for gsmSCF initiated new call, or for new party set-up. This process controls the new leg. 3GPP TSÊ23.078 The following general rules apply: 1 There is only one CSA per CAP dialogue. 2 The CSA controls one or more Call Segments. 3 A Call Segment controls one or more BCSMs. Due to Call Party Handling, legs may be moved from one Call Segment to another and new Call Segments may be created. When legs are moved they take their properties with them, i.e. armed EDPs and pending reports. 4 Legs are not moved between BCSMs. 5 The active legs in the same Call Segment have a voice connection. They hear each other and the same in-band tone and announcements. The following exceptions exist: - Apply Charging IF: the warning tone associated with the Apply Charging IF is played to a single call party in the Call Segment. - Play Tone IF: the flexible tone from the Play Tone IF may be played to a single call party in the Call Segment. The following diagrams shows the overall architecture for the SDL diagrams. Figure 4.9-1: Outgoing case (gsmSSF relay) Figure 4.9-2: Outgoing case (direct path gsmSCF to gsmSRF or assist with relay) Figure 4.9-3: Terminating GMSC case (gsmSSF relay) Figure 4.9-4: Terminating GMSC case (direct path gsmSCF to gsmSRF or assist with relay) NOTE: The ICH_MSC may also be connected via an A interface to the terminating Mobile Station. Figure 4.9-5: Terminating VMSC case (gsmSSF relay) NOTE: The ICH_MSC may also be connected via an A interface to the terminating Mobile Station Figure 4.9-6: Terminating VMSC case (direct path gsmSCF to gsmSRF or assist with relay) Figure 4.9-7: Assisting case Figure 4.9-8: gsmSCF initiated call case (gsmSSF relay) Figure 4.9-9: Trunk Originating case (gsmSSF relay) 4.5.2 Handling of mobile originated calls 4.5.2.1 Handling of mobile originated calls in the originating MSC The functional behaviour of the originating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_OCH_MSC_INIT; - Procedure CAMEL_MO_Dialled_Services; - Procedure CAMEL_OCH_MSC_ALERTING; - Procedure CAMEL_OCH_MSC_ANSWER; - Procedure CAMEL_OCH_MSC1; - Procedure CAMEL_OCH_MSC2; - Procedure CAMEL_OCH_MSC_DISC1; - Procedure CAMEL_OCH_MSC_DISC2; - Procedure CAMEL_OCH_MSC_DISC3; - Procedure CAMEL_OCH_MSC_DISC4; - Procedure CAMEL_Disconnect_CTR_SRF; - Procedure CAMEL_OCH_ETC; - Procedure CAMEL_OCH_CTR; - Procedure CAMEL_Start_TNRy; - Procedure CAMEL_Stop_TNRy; - Procedure CAMEL_Store_Destination_Address; - Procedure CAMEL_Modify_CUG_Info; - Procedure CAMEL_N_CSI_CHECK_MSC; - Procedure CAMEL_OCH_LEG1_MSC; - Procedure CHECK_DIGIT_STRING_MSC; - Process CAMEL_OCH_LEG2_MSC; - Process CAMEL_OCH_RECONNECT_MSC; - Procedure CAMEL_EXPORT_LEG_MSC; - Process CAMEL_O_CHANGE_OF_POSITION_MSC; - Procedure CAMEL_O_SCUDIF_MSC. NOTE: Procedure CAMEL_OCH_MSC_DISC3 applies to CAMEL PhaseÊ1 only. The procedure Send_Access_Connect_If_Required is specified in 3GPP TSÊ23.018Ê[12]. The procedure CAMEL_OCH_LEG1_MSC supervises the originating party only. The process CAMEL_OCH_LEG2_MSC supervises the terminating party only. Hence, signals from the BSS are received by the procedure CAMEL_OCH_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_OCH_LEG2_MSC. The following paragraphs give details on the behaviour of the MSC in the procedures CAMEL_OCH_MSC_INIT, CAMEL_OCH_ETC, CAMEL_OCH_ANSWER and CAMEL_Store_Destination_Address. 4.5.2.1.1 Actions of the MSC on receipt of Int_Error The MSC checks the default Call Handling parameter in the relevant CSI. If the default call handling is release call, a Release is sent to the MS and an Abort to the VLR. The MSC then releases all call resources and the procedure CAMEL_OCH_MSC_INIT ends. If the default call handling is continue call, the MSC continues processing without CAMEL support. It sends Send_Info_For_Ougoing_Call to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.2 Actions of the MSC on receipt of Int_Continue The MSC continues processing without any modification of call parameters. At DPÊAnalysed_Information it sends Send Info For Ougoing Call information flow to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument The MSC continues processing with modified call parameters. The MSC shall replace the call parameters by the information received in the Int_Continue_With_Argument signal. Call parameters which are not included in the Int_Continue_With_Argument signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.2.1.4 Actions of the MSC on receipt of Int_Connect The MSC continues processing with modified call parameters. The MSC shall transparently modify the call parameters with the received information. The MSC then sends a PROGRESS message to the MS. Call parameters which are not included in the Int_Connect signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. At DPÊCollected_Information the MSC sets the O CSI suppression parameter. If D CSI and N CSI are not present, the MSC sends a Send Info For Outgoing Call to the VLR and waits in state Wait_For_MO_Call_Result. At DPÊAnalysed_Information it sets the D CSI suppression parameter, sends a Send Info For Outgoing Call to the VLR and waits in state Wait_For_MO_Call_Result. 4.5.2.1.5 Actions of the MSC on receipt of Int_Release_Call A Release is sent to the MS, an abort to the VLR and a Release is sent to the destination exchange. The release cause received in the Int_Release_Call signal is used. The MSC then releases all call resources and the procedure CAMEL_OCH_MSC_INIT ends. 4.5.2.1.6 Actions of the MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.2.1.7 Actions of the MSC on receipt of Int_Apply_Warning_Tone This section applies to all call cases. The MSC will play a tone to the indicated leg or call segment. The following special cases exist when there is already an existing tone to a leg or call segment: 1 If the MSC is playing a tone to a leg and the Int_Apply_Warning_Tone instructs the MSC to play a tone for another leg (in the same or a different call segment), then the tones will be played independently; 2 The tones for different call segments are independent; 3 If the MSC is playing a tone to a leg and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that leg, then the MSC will stop the existing tone and the latter tone will be played for that leg. 4 If the MSC is playing a tone to a call segment and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that call segment, then the MSC will stop the existing tone and the latter tone will be played for that call segment. 5 If the MSC is playing a tone for the call segment and the Int_Apply_Warning_Tone instructs the MSC to play another tone for a leg in that call segment, then the particular leg shall hear (as an MSC option) either: a The latter tone only, or b Two tones. As an MSC option, the two tones may be played in parallel or in a sequence. The other leg(s) shall keep hearing the (old) call segment tone. 6 If the MSC is playing a tone for a leg and the Int_Apply_Warning_Tone instructs the MSC to play another tone for that call segment, then the particular leg shall either hear (as an MSC option): a The latter tone only, or b Two tones. As an MSC option, the two tones may be played in parallel or in a sequence. The other leg(s) shall start hearing the new call segment tone. 4.5.2.1.8 Action of the MSC in procedure CAMEL_OCH_MSC_ANSWER If the MSC received a destination address from the GMSC in the ISUP Answer or Connect Message, the MSC relays the destination address to the gsmSSF in the Int_DP_O_Answer signal. NOTEÊ1: The sending of e-parameters by the gsmSCF after receiving the DP_O_Answer indication may be to late. NOTEÊ2: If the MO call is not subject to Basic OR, then the destination address is generated by the MSC. If the MO call is subject to Basic OR, the MSC will receive a destination address from the GMSC in the ISUP Answer or Connect Message. 4.5.2.1.9 Action of the MSC in procedure CAMEL_OCH_ETC In procedure CAMEL_OCH_ETC (sheet 2) the MSC will remain in the Wait_For_Assisting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). If a Progress Message is sent towards the MS the progress indicator shall indicate ""In Band Information"". 4.5.2.1.10 Procedure CAMEL_OCH_LEG1_MSC The Int_DTMF_Digit_Received information flow is received from an internal process in the MSC that receives DTMF signalling from the MS. The handling of the internal process that receives DTMF signalling is out of scope of the present document. The playing of the received DTMF tones to the other parties in the call segment is out of scope of the present document. 4.5.2.1.11 Process CAMEL_O_CHANGE_OF_POSITION_MSC The signals HANDOVER COMPLETE and HANDOVER PERFORMED are specified in 3GPP TSÊ48.008Ê[39]. Signals RELOCATION REQUEST ACKNOWLEDGE, LOCATION REPORT and LOCATION REPORTING COMMAND are specified in 3GPP TSÊ25.413Ê[33]. 4.5.2.1.12 Procedure CAMEL_Start_TNRy The recommended value range in the gsmSSF for the default TNRy timer for CAMEL handling is 10 seconds to 3 minutes. The CSE provided TNRy value is applied only once per outgoing leg. The decision ""TNRy received?"" decision box goes to ""No"" branch if the TNRy duration has been used for once and no new timer value has been received since previous call of this procedure. The task box ""Cancel TNRy received"" ensures that the gsmSCF provided timer is applied only once per call leg. The task box prevents the use of previously received timer value from the gsmSCF in subsequent calls (e.g. as in the case of a follow-on call). For example: The gsmSCF arms O_No_Answer EDP and also sent a TNRy timer duration. The call fails and EDP O_No_Answer is reported to the gsmSCF. The gsmSCF sends a Connect (i.e. follow-on call), and also arms EDP O_No_Answer, but this time, with no TNRy timer duration included. The gsmSSF does not use the TNRy timer previously provided by the gsmSCF. Instead, the network's default TNRy timer is used if available for the follow-on call. Figure 4.10-1: Procedure CAMEL_OCH_MSC_INIT (sheet 1) Figure 4.10-2: Procedure CAMEL_OCH_MSC_INIT (sheet 2) Figure 4.10-3: Procedure CAMEL_OCH_MSC_INIT (sheet 3) Figure 4.10-4: Procedure CAMEL_OCH_MSC_INIT (sheet 4) Figure 4.11-1: Procedure CAMEL_MO_Dialled_Services (sheet 1) Figure 4.11-2: Procedure CAMEL_MO_Dialled_Services (sheet 2) Figure 4.11-3: Procedure CAMEL_MO_Dialled_Services (sheet 3) Figure 4.12-1: Procedure CAMEL_SDS_MO_Init (sheet 1) Figure 4.12-2: Procedure CAMEL_SDS_MO_INIT (sheet 2) Figure 4.12-3: Procedure CAMEL_SDS_MO_INIT (sheet 3) Figure 4.12-4: Procedure CAMEL_SDS_MO_INIT (sheet 4) Figure 4.13-1: Procedure CAMEL_NDS_MO_INIT (sheet 1) Figure 4.13-2: Procedure CAMEL_NDS_MO_INIT (sheet 2) Figure 4.13-3: Procedure CAMEL_NDS_MO_INIT (sheet 3) Figure 4.13-4: Procedure CAMEL_NDS_MO_INIT (sheet 4) Figure 4.14-1: Procedure CAMEL_OCH_MSC_ALERTING (sheet 1) Figure 4.14-2: Procedure CAMEL_OCH_MSC_ALERTING (sheet 2) Figure 4.14-3: Procedure CAMEL_OCH_MSC_ALERTING (sheet 3) Figure 4.15-1: Procedure CAMEL_OCH_MSC_ANSWER (sheet 1) Figure 4.15-2: Procedure CAMEL_OCH_ANSWER (sheet 2) Figure 4.15-3: Procedure CAMEL_OCH_ANSWER (sheet 3) Figure 4.16-1: Procedure CAMEL_OCH_MSC1 (sheet 1) Figure 4.16-2: Procedure CAMEL_OCH_MSC1 (sheet 2) Figure 4.16-3: Procedure CAMEL_OCH_MSC1 (sheet 3) Figure 4.17-1: Procedure CAMEL_OCH_MSC2 (sheet 1) Figure 4.17-2: Procedure CAMEL_OCH_MSC2 (sheet 2) Figure 4.17-3: Procedure CAMEL_OCH_MSC2 (sheet 3) Figure 4.18-1: Procedure CAMEL_OCH_MSC_DISC1 (sheet 1) Figure 4.19-1: Procedure CAMEL_OCH_MSC_DISC2 (sheet 1) Figure 4.19-2: Procedure CAMEL_OCH_MSC_DISC2 (sheet 2) Figure 4.20-1: Procedure CAMEL_OCH_MSC_DISC3 (sheet 1) Figure 4.21-1: Procedure CAMEL_OCH_MSC_DISC4 (sheet 1) Figure 4.22-1: Procedure CAMEL_Disconnect_CTR_SRF (sheet 1) Figure 4.23-1: Procedure CAMEL_OCH_ETC (sheet 1) Figure 4.23-2: Procedure CAMEL_OCH_ETC (sheet 2) Figure 4.23-3: Procedure CAMEL_OCH_ETC (sheet 3) Figure 4.23-4: Procedure CAMEL_OCH_ETC (sheet 4) Figure 4.24-1: Procedure CAMEL_OCH_CTR (sheet 1) Figure 4.24-2: Procedure CAMEL_OCH_CTR (sheet 2) Figure 4.24-3: Procedure CAMEL_OCH_CTR (sheet 3) Figure 4.24-4: Procedure CAMEL_OCH_CTR (sheet 4) Figure 4.24-5: Procedure CAMEL_OCH_CTR (sheet 5) Figure 4.25-1: Procedure CAMEL_Start_TNRy (sheet 1) Figure 4.26-1: Procedure CAMEL_Stop_TNRy (sheet 1) Figure 4.27-1: Procedure CAMEL_Store_Destination_Address (sheet 1) Figure 4.28-1: Procedure CAMEL_Modify_CUG_Info (sheet 1) Figure 4.29-1: Procedure CAMEL_N_CSI_CHECK_MSC (sheet 1) Figure 4.30-1: Procedure CAMEL_OCH_LEG1_MSC (sheet 1) Figure 4.30-2: Procedure CAMEL_OCH_LEG1_MSC (sheet 2) Figure 4.30-3: Procedure CAMEL_OCH_LEG1_MSC (sheet 3) Figure 4.30-4: Procedure CAMEL_OCH_LEG1_MSC (sheet 4) Figure 4.30-5: Procedure CAMEL_OCH_LEG1_MSC (sheet 5) Figure 4.30-6: Procedure CAMEL_OCH_LEG1_MSC (sheet 6) Figure 4.30-7: Procedure CAMEL_OCH_LEG1_MSC (sheet 7) Figure 4.30-8: Procedure CAMEL_OCH_LEG1_MSC (sheet 8) Figure 4.30-9: Procedure CAMEL_OCH_LEG1_MSC (sheet 9) Figure 4.30-10: Procedure CAMEL_OCH_LEG1_MSC (sheet 10) Figure 4.30-11: Procedure CAMEL_OCH_LEG1_MSC (sheet 11) Figure 4.30-12: Procedure CAMEL_OCH_LEG1_MSC (sheet 12) Figure 4.30-13: Procedure CAMEL_OCH_LEG1_MSC (sheet 13) Figure 4.31-1: Procedure CHECK_DIGIT_STRING_MSC (sheet 1) Figure 4.32-1: Process CAMEL_OCH_LEG2_MSC (sheet 1) Figure 4.32-2: Process CAMEL_OCH_LEG2_MSC (sheet 2) Figure 4.33-1: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 1) Figure 4.33-2: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 2) Figure 4.33-3: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 3) Figure 4.33-4: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 4) Figure 4.33-5: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 5) Figure 4.33-6: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 6) Figure 4.33-7: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 7) Figure 4.33-8: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 8) Figure 4.33-9: Procedure CAMEL_OCH_RECONNECT_MSC (sheet 9) Figure 4.34-1: Procedure CAMEL_EXPORT_LEG_MSC (sheet 1) Figure 4.34-2: Procedure CAMEL_EXPORT_LEG_MSC (sheet 2) Figure 4.35-1: Process CAMEL_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.36-1: Process CAMEL_O_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.36-2: Process CAMEL_O_CHANGE_OF_POSITION_MSC (sheet 2) Figure 4.37-1: Procedure Check_Criteria_Change_Of_Position (sheet 1) Figure 4.38-1: Procedure CAMEL_O_SCUDIF_MSC (sheet 1) 4.5.2.2 Handling of mobile originating calls in the originating VLR The functional behaviour of the originating VLR is specified in 3GPP TSÊ23.018Ê[12]. The procedure specific to CAMEL are specified in this subclause: - Procedure CAMEL_OCH_VLR; - Process CAMEL_Reconnected_Call_VLR. Figure 4.39-1: Procedure CAMEL_OCH_VLR (sheet 1) Figure 4.40-1: Process CAMEL_Reconnected_Call_VLR (sheet 1) 4.5.3 Retrieval of routeing information 4.5.3.1 Retrieval of routeing information in the GMSC The functional behaviour of the GMSC is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_Set_ORA_Parameters; - Procedure CAMEL_MT_GMSC_INIT; - Procedure CAMEL_MT_MSC_ALERTING; - Procedure CAMEL_MT_GMSC_ANSWER; - Procedure CAMEL_MT_GMSC_DISC1; - Procedure CAMEL_MT_GMSC_DISC2; - Procedure CAMEL_MT_GMSC_DISC3; - Procedure CAMEL_MT_GMSC_DISC4; - Procedure CAMEL_MT_GMSC_DISC5; - Procedure CAMEL_MT_GMSC_DISC6; - Procedure CAMEL_MT_CTR; - Procedure CAMEL_MT_ETC; - Procedure CAMEL_Start_TNRy; - Procedure CAMEL_Stop_TNRy; - Procedure CAMEL_MT_GMSC_Notify_CF; - Procedure CAMEL_MT_LEG2_GMSC; - Process CAMEL_MT_LEG1_GMSC; - Procedure CAMEL_MT_RECONNECT_GMSC; - Procedure CAMEL_T_SCUDIF_MSC. NOTE: Procedure CAMEL_MT_GMSC_DISC3 applies to CAMEL PhaseÊ1 only. The procedure Send_ACM_If_Required is specified in 3GPP TSÊ23.018Ê[12]. The procedure CAMEL_MT_LEG2_GMSC supervises the terminating party only. The process CAMEL_MT_LEG1_GMSC supervises the originating party only. Hence, signals from the destination exchange are received by the procedure CAMEL_MT_LEG2_GMSC and signals from the originating exchange are received by the process CAMEL_MT_LEG1_GMSC. The following paragraphs give details on the behaviour of the GMSC in the procedure CAMEL_MT_GMSC_INIT. 4.5.3.1.1 Action of the GMSC on receipt of Int_Release_Call An ISUP Release message is sent to the originating exchange and resources are released. 4.5.3.1.2 Action of the GMSC on receipt of Int_Error The GMSC checks the default call handling parameter in the T CSI. If the default call handling is release call, an ISUP Release message is sent to the originating exchange. The MSC then releases all call resources and the procedure CAMEL_MT_GMSC_INIT returns result=fail. If the default call handling is continue call, the MSC continues call handling without CAMEL support. 4.5.3.1.3 Action of the GMSC on receipt of Int_Continue If an FTN has been stored then the information received from the HLR is used to overwrite the corresponding call parameters. Note that the MSISDN is replaced by the FTN as the called party number. The redirection counter is incremented. If no FTN has been stored then a Send Routeing Info information flow including a T CSI suppression parameter is sent to the HLR. The Send Routing Info information flow includes an indication of which CAMEL Phases are supported by the GMSC/gsmSSF. 4.5.3.1.4 Action of the GMSC on receipt of Int_Continue_With_Argument If an FTN has been stored then the information received from the HLR is used to overwrite the corresponding call parameters. The MSISDN is replaced by the FTN as the called party number. The redirection counter is incremented."
"If no FTN has been stored then a Send Routeing Info information flow including a T CSI suppression parameter is sent to the HLR. The Send Routing Info information flow includes an indication of which CAMEL phases are supported by the GMSC/gsmSSF. The MSC shall replace the call parameters by the information received in the Int_Continue_With_Argument signal. Call parameters which are not included in the Int_Continue_With_Argument message are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.3.1.5 Action of the GMSC on receipt of Int_Connect If the Destination Number received from the gsmSCF (via the gsmSSF) is the same as the ISUP called party number, i.e. the MSISDN, the following parameters, if received, are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]): Calling Partys Category and Generic Number. If received, the Announcement Suppression Indicator is stored. The further processing is described in subclauseÊ4.5.3.1.3 with the addition that the Announcement Suppression indicator, if stored, is sent to the HLR in the Send Routeing Info message. If: - the Destination Number received from the gsmSCF (via the gsmSSF) is not the same as the stored ISUP called party number, i.e. the MSISDN, and - a CUG active indication was received from the HLR, and - CUG information was received in the ISUP IAM for the incoming call; then an exception event is reported to the process CS_gsmSSF, an ISUP Release Message is sent to the originating exchange. The MSC then releases all call resources and the procedure CAMEL_MT_GMSC_INIT returns result=fail. Otherwise the following parameters, if received, are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]): Destination Number, Calling Partys Category, Generic Number, Original Called Party ID, Redirecting Party ID and Redirection Information. Call parameters that are not included in the Int_Connect signal are unchanged. As a network operator option loop prevention mechanisms may cause the redirection information to be ignored or modified (e.g., if the Redirection counter has been decreased). Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. 4.5.3.1.6 Action of the GMSC on receipt of Send_Routeing_Info Negative Response (in state Wait_For_Routeing_Info_2) An exception event is reported to the process CS_gsmSSF. If the Announcement Suppression indicator has been received from the gsmSCF (via the gsmSSF) any announcements or tones shall be suppressed. 4.5.3.1.7 Action of the GMSC on receipt of Send_Routeing_Info ack with MSRN (in state Wait_For_Routeing_Info_2) An ISUP IAM with the MSRN as the called party number is constructed. 4.5.3.1.8 Action of the GMSC on receipt of Send_Routeing_Info ack with FTN (in state Wait_For_Routeing_Info_2) The information received from the HLR is used to overwrite the corresponding call parameters (for details see 3GPP TSÊ23.018Ê[12]). The redirection counter is incremented. 4.5.3.1.9 Action of the GMSC on receipt of Send_Routeing_Info ack with O CSI and/or D CSI and FTN (at state Wait_For_Routeing_Info_2) The information received from the HLR is used to overwrite corresponding call parameters. The redirection counter is incremented. The Called Party Number is set to the FTN. The O CSI and/or D CSI is stored. 4.5.3.1.10 Action of the GMSC in procedure CAMEL_MT_ETC In the procedure CAMEL_MT_ETC (sheet 2) the GMSC will remain in the Wait_For_Assiting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). If a Progress Message is sent towards the MS the progress indicator shall indicate ""In Band Information"". 4.5.3.1.11 Action of the GMSC in procedure CAMEL_MT_GMSC_Notify_CF The Forwarding reason is taken from the Send Routeing Info ack information flow (for early call forwarding) or the Resume Call Handling information flow (for Optimal Routeing of Late Call Forwarding). The Int_DP_T_No_Answer signal and Int_DP_T_Busy signal include a parameter to indicate that the call has encountered conditional call forwarding. The gsmSSF will transfer this parameter to the Event Report BCSM information flow which it sends to the gsmSCF. 4.5.3.1.12 Action of the MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. Figure 4.41-1: Procedure CAMEL_Set_ORA_Parameters (sheet 1) Figure 4.42-1: Procedure CAMEL_MT_GMSC_INIT (sheet 1) Figure 4.42-2: Procedure CAMEL_MT_GMSC_INIT (sheet 2) Figure 4.42-3: Procedure CAMEL_MT_GMSC_INIT (sheet 3) Figure 4.42-4: Procedure CAMEL_MT_GMSC_INIT (sheet 4) Figure 4.42-5: Procedure CAMEL_MT_GMSC_INIT (sheet 5) Figure 4.42-6: Procedure CAMEL_MT_GMSC_INIT (sheet 6) Figure 4.42-7: Procedure CAMEL_MT_GMSC_INIT (sheet 7) Figure 4.42-8: Procedure CAMEL_MT_GMSC_INIT (sheet 8) Figure 4.43-1: Procedure CAMEL_MT_MSC_ALERTING (sheet 1) Figure 4.43-2: Procedure CAMEL_MT_MSC_ALERTING (sheet 2) Figure 4.43-3: Procedure CAMEL_MT_MSC_ALERTING (sheet 3) Figure 4.44-1: Procedure CAMEL_MT_GMSC_ANSWER (sheet 1) Figure 4.44-2: Procedure CAMEL_MT_GMSC_ANSWER (sheet 2) Figure 4.44-3: Procedure CAMEL_MT_GMSC_ANSWER (sheet 3) Figure 4.45-1: Procedure CAMEL_MT_GMSC_DISC1 (sheet 1) Figure 4.46-1: Procedure CAMEL_MT_GMSC_DISC2 (sheet 1) Figure 4.46-2: Procedure CAMEL_MT_GMSC_DISC2 (sheet 2) Figure 4.47-1: Procedure CAMEL_MT_GMSC_DISC3 (sheet 1) Figure 4.48-1: Procedure CAMEL_MT_GMSC_DISC4 (sheet 1) Figure 4.48-2: Procedure CAMEL_MT_GMSC_DISC4 (sheet 2) Figure 4.48-3: Procedure CAMEL_MT_GMSC_DISC4 (sheet 3) Figure 4.49-1: Procedure CAMEL_MT_GMSC_DISC5 (sheet 1) Figure 4.49-2: Procedure CAMEL_MT_GMSC_DISC5 (sheet 2) Figure 4.49-3: Procedure CAMEL_MT_GMSC_DISC5 (sheet 3) Figure 4.50-1: Procedure CAMEL_MT_GMSC_DISC6 (sheet 1) Figure 4.51-1: Procedure CAMEL_MT_ETC (sheet 1) Figure 4.51-2: Procedure CAMEL_MT_ETC (sheet 2) Figure 4.51-3: Procedure CAMEL_MT_ETC (sheet 3) Figure 4.51-4: Procedure CAMEL_MT_ETC (sheet 4) Figure 4.52-1: Procedure CAMEL_MT_CTR (sheet 1) Figure 4.52-2: Procedure CAMEL_MT_CTR (sheet 2) Figure 4.52-3: Procedure CAMEL_MT_CTR (sheet 3) Figure 4.52-4: Procedure CAMEL_MT_CTR (sheet 4) Figure 4.52-5: Procedure CAMEL_MT_CTR (sheet 5) Figure 4.53-1: Procedure CAMEL_MT_GMSC_Notify_CF (sheet 1) Figure 4.53-2: Procedure CAMEL_MT_GMSC_Notify_CF (sheet 2) Figure 4.54-1: Procedure CAMEL_MT_LEG2_GMSC (sheet 1) Figure 4.54-2: Procedure CAMEL_MT_LEG2_GMSC (sheet 2) Figure 4.54-3: Procedure CAMEL_MT_LEG2_GMSC (sheet 3) Figure 4.55-1: Process CAMEL_MT_LEG1_GMSC (sheet 1) Figure 4.55-2: Process CAMEL_MT_LEG1_GMSC (sheet 2) Figure 4.55-3: Process CAMEL_MT_LEG1_GMSC (sheet 3) Figure 4.55-4: Process CAMEL_MT_LEG1_GMSC (sheet 4) Figure 4.55-5: Process CAMEL_MT_LEG1_GMSC (sheet 5) Figure 4.56-1: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 1) Figure 4.56-2: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 2) Figure 4.56-3: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 3) Figure 4.56-4: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 4) Figure 4.56-5: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 5) Figure 4.56-6: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 6) Figure 4.56-7: Procedure CAMEL_MT_RECONNECT_GMSC (sheet 7) Figure 4.57-1: Procedure CAMEL_T_SCUDIF_MSC (sheet 1) 4.5.3.2 Retrieval of routeing information in the HLR The functional behaviour of the HLR is specified in 3GPP TSÊ23.018Ê[12]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_HLR_INIT; - Procedure CAMEL_CSI_Check_HLR; - Procedure CAMEL_O_CSI_CHECK_HLR; - Procedure CAMEL_D_CSI_CHECK_HLR; - Procedure CAMEL_T_CSI_CHECK_HLR; - Procedure CAMEL_CHECK_SII2_CDTI. The procedure CAMEL_Provide_Subscriber_Info is specified in subclauseÊ4.5.9. Figure 4.58-1: Procedure CAMEL_HLR_INIT (sheet 1) Figure 4.58-2: Procedure CAMEL_HLR_INIT (sheet 2) Figure 4.59-1: Procedure CAMEL_CSI_Check_HLR (sheet 1) Figure 4.60-1: Procedure CAMEL_O_CSI_CHECK_HLR (sheet 1) Figure 4.61-1: Procedure CAMEL_D_CSI_CHECK_HLR (sheet 1) Figure 4.62-1: Procedure CAMEL_T_CSI_CHECK_HLR (sheet 1) Figure 4.63-1: Procedure CAMEL_CHECK_SII2_CDTI (sheet 1) 4.5.3.3 Handling of provide roaming number request in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ23.018Ê[12]. The procedure specific to CAMEL is specified in this subclause: - Procedure CAMEL_SET_SOA. Figure 4.64-1: Procedure CAMEL_SET_SOA (sheet 1) 4.5.4 Handling of mobile terminating calls 4.5.4.1 Handling of mobile terminating calls in the terminating VMSC The functional behaviour of the terminating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The behaviour specific to CAMEL is: - the inclusion of the O CSI and/or D CSI parameter in the Perform Call Forwarding information flow sent to the process MT_CF_MSC if O CSI and/or D CSI was received in the Send Info For Incoming Call ack information flow; - the requirement to suppress the connection of announcements or tones if the VLR includes the suppression of announcements parameter in the Send Info For Incoming Call negative response information flow. The processes and procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_ICH_VLR; - Procedure CAMEL_O_CSI_Check_VLR; - Procedure CAMEL_D_CSI_Check_VLR; - Procedure CAMEL_VT_CSI_Check_VLR; - Procedure CAMEL_ICH_MSC_INIT; - Procedure CAMEL_MT_VMSC_Notify_CF; - Procedure CAMEL_ICH_LEG2_MSC; - Procedure CAMEL_ICH_LEG2_CF_MSC; - Process CAMEL_ICH_LEG1_MSC; - Procedure CAMEL_ICH_RECONNECT_MSC; - Process CAMEL_T_CHANGE_OF_POSITION_MSC. The procedure CAMEL_ICH_LEG2_MSC supervises the terminating party only. The procedure CAMEL_ICH_LEG2_CF_MSC supervises the forwarded-to party only. The process CAMEL_ICH_LEG1_MSC supervises the originating party only. Hence, signals from the BSS are received by the procedure CAMEL_ICH_LEG2_MSC, signals from the destination exchange are received by the procedure CAMEL_ICH_LEG2_CF_MSC and signals from the originating exchange are received by the process CAMEL_ICH_LEG1_MSC. 4.5.4.1.1 Action of the VMSC in procedure CAMEL_MT_VMSC_Notify_CF The Forwarding reason is taken from the Complete Call information flow from the VLR. The Int_DP_T_No_Answer signal and Int_DP_T_Busy signal include a parameter to indicate that the call has encountered conditional call forwarding. The gsmSSF will transfer this parameter to the Event Report BCSM information flow which it sends to the gsmSCF. 4.5.4.1.2 Action of MSC on receipt of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.4.1.3 Procedure CAMEL_ICH_LEG2_MSC The Int_DTMF_Digit_Received information flow is received from an internal process in the MSC that receives DTMF signalling from the MS. The handling of the internal process that receives DTMF signalling is out of scope of the present document. The playing of the received DTMF tones to the other parties in the call segment is out of scope of the present document. 4.5.4.1.4 Process CAMEL_T_CHANGE_OF_POSITION_MSC The signals HANDOVER COMPLETE and HANDOVER PERFORMED are specified in 3GPP TSÊ48.008Ê[39]. Signals RELOCATION REQUEST ACKNOWLEDGE, LOCATION REPORT and LOCATION REPORTING COMMAND are specified in 3GPP TSÊ25.413Ê[33]. Figure 4.65-1: Procedure CAMEL_ICH_VLR (sheet 1) Figure 4.66-1: Procedure CAMEL_O_CSI_Check_VLR (sheet 1) Figure 4.67-1: Procedure CAMEL_D_CSI_Check_VLR (sheet 1) Figure 4.68-1: Procedure CAMEL_VT_CSI_Check_VLR (sheet 1) Figure 4.69-1: Procedure CAMEL_ICH_MSC_INIT (sheet 1) Figure 4.69-2: Procedure CAMEL_ICH_MSC_INIT (sheet 2) Figure 4.69-3: Procedure CAMEL_ICH_MSC_INIT (sheet 3) Figure 4.69-4: Procedure CAMEL_ICH_MSC_INIT (sheet 4) Figure 4.69-5: Procedure CAMEL_ICH_MSC_INIT (sheet 5) Figure 4.70-1: Procedure CAMEL_MT_VMSC_Notify_CF (sheet 1) Figure 4.70-2: Procedure CAMEL_MT_VMSC_Notify_CF (sheet 2) Figure 4.71-1: Procedure CAMEL_ICH_LEG2_MSC (sheet 1) Figure 4.71-2: Procedure CAMEL_ICH_LEG2_MSC (sheet 2) Figure 4.71-3: Procedure CAMEL_ICH_LEG2_MSC (sheet 3) Figure 4.71-4: Procedure CAMEL_ICH_LEG2_MSC (sheet 4) Figure 4.71-5: Procedure CAMEL_ICH_LEG2_MSC (sheet 5) Figure 4.71-6: Procedure CAMEL_ICH_LEG2_MSC (sheet 6) Figure 4.71-7: Procedure CAMEL_ICH_LEG2_MSC (sheet 7) Figure 4.71-8: Procedure CAMEL_ICH_LEG2_MSC (sheet 8) Figure 4.71-9: Procedure CAMEL_ICH_LEG2_MSC (sheet 9) Figure 4.72-1: Process CAMEL_ICH_LEG2_CF_MSC (sheet 1) Figure 4.72-2: Process CAMEL_ICH_LEG2_CF_MSC (sheet 2) Figure 4.73-1: Process CAMEL_ICH_LEG1_MSC (sheet 1) Figure 4.73-2: Process CAMEL_ICH_LEG1_MSC (sheet 2) Figure 4.73-3: Process CAMEL_ICH_LEG1_MSC (sheet 3) Figure 4.73-4: Process CAMEL_ICH_LEG1_MSC (sheet 4) Figure 4.73-5: Process CAMEL_ICH_LEG1_MSC (sheet 5) Figure 4.74-1: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 1) Figure 4.74-2: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 2) Figure 4.74-3: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 3) Figure 4.74-4: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 4) Figure 4.74-5: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 5) Figure 4.74-6: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 6) Figure 4.74-7: Procedure CAMEL_ICH_RECONNECT_MSC (sheet 7) Figure 4.75-1: Process CAMEL_T_CHANGE_OF_POSITION_MSC (sheet 1) Figure 4.75-2: Procedure CAMEL_T_CHANGE_OF_POSITION_MSC (sheet 2) 4.5.4.2 Handling of mobile terminating calls in the VLR The functional behaviour of the terminating VLR is specified in 3GPP TSÊ23.018Ê[12]. The process specific to CAMEL is specified in this subclause: - Process Reconnected_MT_Call_VLR. The behaviour specific to CAMEL is: - the inclusion of the O CSI and/or D CSI parameter in the Send Info For Incoming Call ack information flow if the call is to be forwarded and O CSI and/or D CSI is included in the subscriber data for that subscriber in the VLR; - the inclusion of the suppression of announcements parameter in the Send Info For Incoming Call negative response information flow if it was received in the Provide Roaming Number information flow from the HLR. Figure 4.76-1: Process Reconnected_MT_Call_VLR (sheet 1) 4.5.5 Handling of forwarded calls The handling of forwarded calls in the GMSC or the terminating VMSC is specified in 3GPP TSÊ23.018Ê[12]. The processes and procedures specific to CAMEL are specified in this subclause. - Procedure CAMEL_Check_ORLCF_VMSC; - Procedure CAMEL_CF_MSC_INIT; - Procedure CAMEL_CF_MSC_ALERTING; - Procedure CAMEL_CF_MSC_ANSWER; - Procedure CAMEL_CF_ETC; - Procedure CAMEL_CF_CTR; - Procedure CAMEL_MT_CF_LEG1_MSC; - Process CAMEL_MT_CF_LEG2_MSC; - Procedure CAMEL_MF_RECONNECT_MSC. The procedure CAMEL_MT_CF_LEG1_MSC supervises the originating party only. The process CAMEL_MT_CF_LEG2_MSC supervises the forwarding-to party only. Hence, signals from the originating exchange are received by the procedure CAMEL_MT_CF_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_MT_CF_LEG2_MSC. A mobile terminated call can be forwarded either in the GMSC (indicated by provision of Forwarded-To-Number from the HLR or gsmSCF) or in the MSC (indicated by provision of Forwarded-To-Number from the VLR). 4.5.5.1 Procedure CAMEL_CF_MSC_INIT: handling of Int_Continue_With_Argument The received parameters are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]). Call parameters which are not included in the Int_Continue_With_Argument signal are unchanged. Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. 4.5.5.2 Procedure CAMEL_CF_MSC_INIT: handling of Int_Connect The received parameters are used to overwrite the corresponding ISUP parameters (for mapping see 3GPP TSÊ29.078Ê[36]. Call parameters which are not included in the Int_Connect signal are unchanged. As a network operator option, loop prevention mechanisms may cause the redirection information to be ignored or modified (e.g., if the Redirection counter has been decreased). Signalling limitations or regulatory requirements may require the Calling Partys Category, Generic Number, Original Called Party Number and Redirecting Party ID to be ignored or modified. The network signalling system shall indicate that this is an internal network number. 4.5.5.3 Procedure CAMEL_CF_MSC_INIT: handling of Int_Disconnect_Leg (Leg 2) If the MSC receives Int_Disconnect_Leg (Leg 2) signal from the gsmSSF, in response to an Initial DP information flow, the MSC will continue the handling of the calling party (Leg1) without routeing the call to a destination. 4.5.5.4 Action of the MSC in procedure CAMEL_CF_MSC_ANSWER If the MSC received a destination address from the GMSC in the ISUP Answer or ISUP Connect Message then the MSC relays the destination address to the gsmSSF in the Int_DP_O_Answer signal. 4.5.5.5 Action of the MSC in procedure CAMEL_CF_ETC In procedure CAMEL_CF_ETC (sheet 2) the GMSC or terminating VMSC will remain in the Wait_For_Assisting_Answer state until it receives an ISUP Answer Message (ANM) or timeout occurs. This is to ensure that a call record is always generated for every successful establishment of a temporary connection to a gsmSRF, especially in the case where the connection is between PLMNs. NOTE: This means that it may not be possible to access an SRF which does not generate an ISUP Answer Message (ANM). Figure 4.77-1: Procedure CAMEL_Check_ORLCF_VMSC (sheet 1) Figure 4.77-2: Procedure CAMEL_Check_ORLCF_VMSC (sheet 2) Figure 4.78-1: Procedure CAMEL_CF_Dialled_Services (sheet 1) Figure 4.79-1: Procedure CAMEL_CF_MSC_INIT (sheet 1) Figure 4.79-2: Procedure CAMEL_CF_MSC_INIT (sheet 2) Figure 4.79-3: Procedure CAMEL_CF_MSC_INIT (sheet 3) Figure 4.79-4: Procedure CAMEL_CF_MSC_INIT (sheet 4) Figure 4.80-1: Procedure CAMEL_SDS_CF_INIT (sheet 1) Figure 4.80-2: Procedure CAMEL_SDS_CF_INIT (sheet 2) Figure 4.80-3: Procedure CAMEL_SDS_CF_INIT (sheet 3) Figure 4.80-4: Procedure CAMEL_SDS_CF_INIT (sheet 4) Figure 4.81-1: Procedure CAMEL_NDS_CF_INIT (sheet 1) Figure 4.81-2: Procedure CAMEL_NDS_CF_INIT (sheet 2) Figure 4.81-3: Procedure CAMEL_NDS_CF_INIT (sheet 3) Figure 4.81-4: Procedure CAMEL_NDS_CF_INIT (sheet 4) Figure 4.82-1: Procedure CAMEL_CF_MSC_ALERTING (sheet 1) Figure 4.82-2: Procedure CAMEL_CF_MSC_ALERTING (sheet 2) Figure 4.82-3: Procedure CAMEL_CF_MSC_ALERTING (sheet 3) Figure 4.83-1: Procedure CAMEL_CF_MSC_ANSWER (sheet 1) Figure 4.83-2: Procedure CAMEL_CF_MSC_ANSWER (sheet 2) Figure 4.83-3: Procedure CAMEL_CF_MSC_ANSWER (sheet 3) Figure 4.84-1: Procedure CAMEL_CF_ETC (sheet 1) Figure 4.84-2: Procedure CAMEL_CF_ETC (sheet 2) Figure 4.84-3: Procedure CAMEL_CF_ETC (sheet 3) Figure 4.84-4: Procedure CAMEL_CF_ETC (sheet 4) Figure 4.85-1: Procedure CAMEL_CF_CTR (sheet 1) Figure 4.85-2: Procedure CAMEL_CF_CTR (sheet 2) Figure 4.85-3: Procedure CAMEL_CF_CTR (sheet 3) Figure 4.85-4: Procedure CAMEL_CF_CTR (sheet 4) Figure 4.85-5: Procedure CAMEL_CF_CTR (sheet 5) Figure 4.86-1: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 1) Figure 4.86-2: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 2) Figure 4.86-3: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 3) Figure 4.86-4: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 4) Figure 4.86-5: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 5) Figure 4.86-6: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 6) Figure 4.86-7: Procedure CAMEL_MT_CF_LEG1_MSC (sheet 7) Figure 4.87-1: Process CAMEL_MT_CF_LEG2_MSC (sheet 1) Figure 4.87-2: Process CAMEL_MT_CF_LEG2_MSC (sheet 2) Figure 4.88-1: Procedure CAMEL_MF_RECONNECT_MSC (sheet 1) Figure 4.88-2: Procedure CAMEL_MF_RECONNECT_MSC (sheet 2) Figure 4.88-3: Procedure CAMEL_MF_RECONNECT_MSC (sheet 3) Figure 4.88-4: Procedure CAMEL_MF_RECONNECT_MSC (sheet 4) Figure 4.88-5: Procedure CAMEL_MF_RECONNECT_MSC (sheet 5) Figure 4.88-6: Procedure CAMEL_MF_RECONNECT_MSC (sheet 6) 4.5.6 Handling of gsmSCF initiated calls 4.5.6.1 Handling of gsmSCF initiated calls in the MSC Handling of gsmSCF initiated calls in the MSC involves the following process and procedures: - Process CAMEL_ICA_MSC; - Procedure CAMEL_ICA_MSC_ALERTING; - Procedure CAMEL_ICA_MSC_ANSWER; - Procedure CAMEL_ICA_MSC1; - Procedure CAMEL_ICA_MSC2; - Procedure CAMEL_ICA_Dialled_Services. The Process CAMEL_ ICA_MSC handles both gsmSCF initiated new calls and gsmSCF initiated new parties. The following paragraphs give details on the behaviour of the MSC in the process CAMEL_ICA_MSC. 4.5.6.1.1 Actions of the MSC on receipt of Int_Error The process CAMEL_ICA_MSC returns to idle. 4.5.6.1.2 Actions of the MSC on receipt of Int_Continue The MSC continues processing without any modification of call parameters. 4.5.6.1.3 Actions of the MSC on receipt of Int_Continue_With_Argument The MSC continues processing with modification of call parameters. 4.5.6.1.4 Actions of the MSC on receipt of Int_Disconnect_Leg A Release is sent to the destination exchange if required. The release cause received in the Int_Disconnect_Leg signal is used. The process CAMEL_ICA_MSC returns to idle. 4.5.6.1.5 Actions of the MSC on receipt of Int_Release_Call A Release is sent to the destination exchange if required. The release cause received in the Int_Release_Call signal is used. The MSC then releases all call resources and the process CAMEL_ ICA_MSC returns to idle. Figure 4.89-1: Process CAMEL_ICA_MSC (sheet 1) Figure 4.89-2: Process CAMEL_ICA_MSC (sheet 2) Figure 4.89-3: Process CAMEL_ICA_MSC (sheet 3) Figure 4.89-4: Process CAMEL_ICA_MSC (sheet 4) Figure 4.89-5: Process CAMEL_ICA_MSC (sheet 5) Figure 4.89-6: Process CAMEL_ICA_MSC (sheet 6) Figure 4.89-7: Process CAMEL_ICA_MSC (sheet 7) Figure 4.89-8: Process CAMEL_ICA_MSC (sheet 8) Figure 4.89-9: Process CAMEL_ICA_MSC (sheet 9) Figure 4.90-1: Procedure CAMEL_ICA_MSC_ALERTING (sheet 1) Figure 4.90-2: Process CAMEL_ICA_MSC_ALERTING (sheet 2) Figure 4.90-3: Process CAMEL_ICA_MSC_ALERTING (sheet 3) Figure 4.91-1: Procedure CAMEL_ICA_MSC_ANSWER (sheet 1) Figure 4.91-2: Process CAMEL_ICA_MSC_ANSWER (sheet 2) Figure 4.91-3: Process CAMEL_ICA_MSC_ANSWER (sheet 3) Figure 4.92-1: Procedure CAMEL_ICA_MSC1 (sheet 1) Figure 4.93-1: Procedure CAMEL_ICA_MSC2 (sheet 1) Figure 4.94-1: Procedure CAMEL_ICA_Dialled_Services (sheet 1) 4.5.6.2 Handling of gsmSCF initiated calls in the VLR Handling of gsmSCF initiated calls in the VLR involves the following process and procedures: - Process CAMEL_ICA_VLR. Figure 4.95-1: Process CAMEL_ICA_VLR (sheet 1) Figure 4.95-2: Process CAMEL_ICA_VLR (sheet 2) 4.5.7 Handling of mobile calls in the gsmSSF Handling of mobile calls in the gsmSSF involves the following processes and procedures: - Process CS_gsmSSF; - Procedures and process Check_Criteria; - Procedure Connect_To_Resource; - Procedure Handle_AC; - Procedure Handle_ACR; - Procedure Handle_CIR; - Procedure Handle_CIR_leg; - Procedure Complete_FCI_record; - Procedure Complete_all_FCI_records; - Procedure Handle_SCI; - Process CSA_gsmSSF; - Procedure Handle_O_Answer; - Procedure Handle_T_Answer. The detailed error handling for the process CS_gsmSSF and the associated procedures is specified in 3GPP TSÊ29.078Ê([36]). 4.5.7.1 Call duration control 4.5.7.1.1 Information flow for call duration control The following diagram shows the handling of the different timers that are used in the process CS_gsmSSF and in the procedures Handle_AC, Handle_ACR, Handle_CIR. Timers Tssf, Tcp, Tsw, Tw and DELTA are defined in the process CS_gsmSSF. Figure 4.96: Information flow for call control duration The following diagram shows an example of the handling of call duration control for CPH configurations. Figure 4.96a: Information flow for call control duration in CPH configurations 4.5.7.1.2 Audible indicators for call duration control The gsmSCF may instruct the gsmSSF to play either a fixed sequence of tones or a variable sequence of tones with the Apply Charging information flow. The gsmSCF may also instruct the gsmSSF to play a variable sequence of tones with the Play Tone information flow. For the case of the fixed sequence of tones, the gsmSSF shall play a single sequence of three tones. The duration of each of the tones shall be 200Êmilliseconds with an intertone interval of 200Êmilliseconds. This shall be played 30Êseconds before the end of a call period. For the case of a variable sequence of tones, or a burst list, the gsmSCF shall indicate the number of tones per burst, the number of bursts to be played, the tone duration, interval between the tones and the interval between the bursts. In addition, the gsmSCF shall indicate in the Apply Charging information flow, the warning time before call period expiry at which the playing of the burst list shall start. FigureÊ4.97 provides a graphical representation of the variable burst list in the case where there are three tones per burst and three bursts in the burst list. The Warning Period in figureÊ4.97 applies to the Apply Charging information flow only. Figure 4.97: Representation of burst list 4.5.7.2 The gsmSCF control of e values 4.5.7.2.1 Procedure Handle_SCI There are independent Tariff Switch Timers for the control of the call duration Tsw(pty) and for the gsmSCF control of e values Tsw(SCI). The gsmSCF control of e values is via the Send Charging Information information flow. The following terminology has been used for e parameters: - Applicable and in use. The set of e parameters is currently applicable in the MSC and the set has been sent to the MS. - Applicable but waiting. The set of e parameters is currently applicable in the MSC but the set has not yet been sent to the MS. - Applicable but not in use. The set of e parameters is currently applicable in the MSC but it cannot be sent to the MS, e.g. because the Advice of Charge supplementary service is not subscribed. - Stored. The set of e parameters is not yet applicable. The stored set of e parameters becomes applicable when a tariff switch occurs. The table below defines the actions of the Procedure Handle_SCI. Table 4.6: Handling of SCI in the gsmSSF received Tsw(SCI) and set of e parameters in the SCI information flow Primary dialogue (note 1) Secondary dialogue (noteÊ2,Ê8) no active call / SRF connection active call / SRF connection Tsw(SCI) not running and no e parameters stored Tsw(SCI) running and e parameters stored Tsw(SCI) not running and no e parameters stored Tsw(SCI) running and e parameters stored Tsw(SCI) not received 1 set send 1st set to MSC stop Tsw(SCI); discard stored set; send 1st set to MSC send 1st set to MSC stop Tsw(SCI); discard stored set; send 1st set to MSC send 1st set to MSC Tsw(SCI) not received 2 sets error error error error error Tsw(SCI) received 1 set error error store 1st set; start Tsw(SCI) stop Tsw(SCI); discard stored set; store 1st set; start new Tsw(SCI) error Tsw(SCI) received 2 sets send 1st set to MSC, store 2nd set; start Tsw(SCI) stop Tsw(SCI); discard stored set; send 1st set to MSC; store 2nd set; start new Tsw(SCI) error error send 1st set to MSC; store 2nd set; start Tsw(SCI) NOTEÊ1: Primary dialogue: The primary dialogue is initiated due to TDPÊCollected_Info, TDPÊAnalysed_Information, or TDPÊRoute_Select_Failure, TDPÊTerminating_Attempt_Authorised, TDPÊT_Busy or TDP T_No_Answer. A dialogue initiated due to TDP Analysed_Information is only the primary dialogue, if there is no ongoing dialogue due to TDP Collected_Info. NOTEÊ2: Secondary dialogue: The secondary dialogue is initiated due to TDPÊAnalysed_Information. NOTEÊ3: The condition ""active call / SRF connection"" is true if there is at least one active leg in this call (CSA) or if an SRF is connected to a Call Segment in this CSA. Incoming legs are active after an answer is sent and before the leg begins to release. Outgoing legs are active after an answer is received and before the leg is begins to release. NOTEÊ4: If the gsmSSF sends a set of e parameters to the MSC this will overwrite the current set of e parameters in the MSC, if e parameters are applicable in the MSC. NOTEÊ5: The MSC shall store the received e parameters to be sent subsequently to the MS. The MSC shall send these e parameters to the MS in a Connect message or in a Facility message. NOTEÊ6: Secondary dialogue gsmSCF can only give e parameter(s)/Tsw(SCI) when they have not previously been provided by the primary dialogue gsmSCF. After secondary dialogue gsmSCF gives e parameter(s) / Tsw(SCI), Primary dialogue gsmSCF shall not give further on-line charging instructions (i.e. Send Charging Information). For D CSI, this is ensured by service subscription restriction by a home network operator. For N CSI, this is ensured by a roaming agreement between the home network operator and the visited network operator or is only applicable within a home network. NOTEÊ7: When a gsmSCF relationship is closed then the stored e parameters given by that dialogue are discarded. Any Tariff Switch timer (Tsw(SCI)) is also stopped when the gsmSCF relationship is closed. If the gsmSCF has given any e parameters which are not stored but which are applicable (regardless of whether they are applicable and in use, applicable but waiting, or applicable but not in use) when the gsmSCF relationship is closed, those e parameters are also valid after the gsmSCF relationship is closed. If any subsequent CAP dialogues give e parameters those new e parameters shall overwrite the applicable e parameters given by the preceding CAP dialogues. NOTEÊ8: The secondary dialogue is not applicable to VT calls. NOTE 9: Service Logic designers shall take care when using SCI in both primary dialogue and secondary dialogue, if these dialogues use different versions of CAMEL. In such a case it is e.g. possible that a Tariff Switch timer (Tsw(SCI))Êinformation received in the primary dialogue is overwritten by a Tariff Switch timer (Tsw(SCI)) information received in the secondary dialogue. 4.5.7.2.2 Process Tsw_For_SCI The process Tsw_For_SCI exists per call. That is there is one process instance per CSA. The Tariff Switch Timers for the gsmSCF control of e values Tsw(SCI). Figure 4.98-1: Process Tsw_For_SCI (sheet 1) Figure 4.98-2: Process Tsw_For_SCI (sheet 2) 4.5.7.3 Behaviour of the gsmSSF in the process CS_gsmSSF The following paragraphs give details on the behaviour of the gsmSSF in the process CS_gsmSSF. 4.5.7.3.1 Actions of the gsmSSF on receipt of CAP_Request_Report_BCSM_Event (in the state Waiting_For_Instructions) The process CS_gsmSSF arms the requested EDP, if the arming rules are fulfilled and returns to the state Waiting_For_Instructions. The gsmSCF may request EDPs for any one or more of Answer, Busy, No Answer, Abandon, Route Select Failure and Disconnect event for a party in the call. 4.5.7.3.2 Actions of the gsmSSF on receipt of CAP_Continue (in the state Waiting_For_Instructions) An Int_Continue signal is sent to instruct the GMSC or MSC to continue the call set-up with the original call parameters. 4.5.7.3.3 Actions of the gsmSSF on receipt of CAP_Release_Call (in the state Monitoring) When a control relationship exists between the gsmSCF and gsmSSF (at least one EDP R is armed), the gsmSCF may spontaneously instruct the gsmSSF to release the call at any time using the Release Call information flow. The Release Call information flow shall not be sent from the gsmSCF if only monitor relationship exists between the gsmSSF and the gsmSCF. 4.5.7.3.4 Actions of the gsmSSF on receipt of Int_DP_T_Busy or Int_DP_T_No_Answer including the parameter Call Forwarded (in the state Monitoring) If the handling of Int_DP_T_Busy signal or Int_DP_T_No_Answer signal including the parameter Call Forwarded leads to the gsmSSF sending a CAP_Event_Report_BCSM to the gsmSCF, the gsmSSF shall include the parameter Call Forwarded in the Event Specific Information BCSM. 4.5.7.4 Outstanding Request Counter and Rules for CAMEL In the following the rules on handling of the 'outstanding requests' variables in the process CS_gsmSSF are given. They are storing the number of required resumptions. 1) There shall be one outstanding requests variable ORC_Leg (legID) per leg to handle TDP R and EDP R reports and ICA. 2) In addition there shall be one outstanding requests variable ORC_CS (CSID) per call segment to handle the CPH IFs. 3) A leg will only be resumed if the ORC_Leg (legID) variable for this leg and the ORC_CS (CSID) for the call segment containing the leg are 0. 4) Events that cause the suspension of the call processing are signalling events armed as TDP Rs or EDP Rs, or the processing of a CPH IF (Disconnect Leg, Split Leg or Move Leg) or Initiate Call Attempt sent by the gsmSCF. a) For TDP R or EDP R events the number of required resumptions relative to the associated leg will be incremented by 1. For TDP-R, the associated leg is always leg 2. b) For CPH IFs the number of required resumptions per call segment will be set to one if it is still 0. Otherwise the number of resumptions remains unchanged. For Split Leg the number of required resumptions for each of the source call segment and the target call segment will be set to one if it is still 0 c) For ICA the number of required resumptions relative to the associated leg will be set to 1. 5) In addition the CS_gsmSSF stores information about the events (DP with the associated leg, CPH) that require resumption and keep track of the order of events for TDP Rs and EDP Rs for each leg . The order of resumptions for a leg shall be the order in which the suspension events occured for that leg. 6) For DP event resumption Continue with Argument with legID or Continue are valid. If not otherwise stated below, for each received resumption the number of required resumption for that leg will be decremented by 1 if it was a valid resumption for the event that has to be handled first. Decrementing of the outstanding requests variables does not go below 0. 7) For CPH resumption Continue with Argument with CSID is valid. On receipt of the resumption the number of required resumptions for that call segment will be set to 0. 8) For ICA resumption Continue with Argument with LegId is valid. On receipt of the resumption the number of required resumptions for that Leg will be set to 0. 9) If Continue with Argument with neither LegID nor CSID is received, then the number of resumptions required for the leg that was reported will be decremented by 1. If reporting is performed on more than one leg, then the related leg will be selected following the sequence of the reporting. 10) If Continue is received, then the number of resumptions required for the leg that was reported will be decremented by 1. If reporting is performed on more than one leg, then the related leg will be selected following the sequence of the reporting. 11) The processing of a Connect with a LegID causes the number of required resumptions for that leg to be decremented by 1. The processing of a Connect without a LegID causes the number of resumptions for the LegID = 2 to be set to 0. 12) The processing of Tssf expiry and of TC Abort causes the number of resumptions required to be set to 0 and the call processing to be resumed. All stored resumption events are discarded. 13) On receipt of a Disconnect Leg the number of resumptions required for the corresponding leg is set to 0. 14) If Release Call is used, nothing needs to be resumed. 4.5.7.5 Process CS_gsmSSF and procedures Figure 4.99-1: Process CS_gsmSSF (sheet 1) Figure 4.99-2: Process CS_gsmSSF (sheet 2) Figure 4.99-3: Process CS_gsmSSF (sheet 3) Figure 4.99-4: Process CS_gsmSSF (sheet 4) Figure 4.99-5: Process CS_gsmSSF (sheet 5) Figure 4.99-6: Process CS_gsmSSF (sheet 6) Figure 4.99-7: Process CS_gsmSSF (sheet 7) Figure 4.99-8: Process CS_gsmSSF (sheet 8) Figure 4.99-9: Process CS_gsmSSF (sheet 9) Figure 4.99-10: Process CS_gsmSSF (sheet 10) Figure 4.99-11: Process CS_gsmSSF (sheet 11) Figure 4.99-12: Process CS_gsmSSF (sheet 12) Figure 4.99-13: Process CS_gsmSSF (sheet 13) Figure 4.99-14: Process CS_gsmSSF (sheet 14) Figure 4.99-15: Process CS_gsmSSF (sheet 15) Figure 4.99-16: Process CS_gsmSSF (sheet 16) Figure 4.99-17: Process CS_gsmSSF (sheet 17) Figure 4.99-18: Process CS_gsmSSF (sheet 18) Figure 4.99-19: Process CS_gsmSSF (sheet 19) Figure 4.99-20: Process CS_gsmSSF (sheet 20) Figure 4.99-21: Process CS_gsmSSF (sheet 21) Figure 4.99-21A: Process CS_gsmSSF (sheet 21A) Figure 4.99-22: Process CS_gsmSSF (sheet 22) Figure 4.99-23: Process CS_gsmSSF (sheet 23) Figure 4.99-24: Process CS_gsmSSF (sheet 24) Figure 4.99-25: Process CS_gsmSSF (sheet 25) Figure 4.99-26: Process CS_gsmSSF (sheet 26) Figure 4.99-27: Process CS_gsmSSF (sheet 27) Figure 4.99-28: Process CS_gsmSSF (sheet 28) Figure 4.99-29: Process CS_gsmSSF (sheet 29) Figure 4.99-29a: Process CS_gsmSSF (sheet 29a) Figure 4.99-30: Process CS_gsmSSF (sheet 30) Figure 4.99-31: Process CS_gsmSSF (sheet 31) Figure 4.99-32: Process CS_gsmSSF (sheet 32) Figure 4.99-33: Process CS_gsmSSF (sheet 33) Figure 4.99-34: Process CS_gsmSSF (sheet 34) Figure 4.99-35: Process CS_gsmSSF (sheet 35) Figure 4.99-36: Process CS_gsmSSF (sheet 36) Figure 4.99-37: Process CS_gsmSSF (sheet 37) Figure 4.99-38: Process CS_gsmSSF (sheet 38) Figure 4.99-39: Process CS_gsmSSF (sheet 39) Figure 4.99-40: Process CS_gsmSSF (sheet 40) Figure 4.99-41: Process CS_gsmSSF (sheet 41) Figure 4.99-42: Process CS_gsmSSF (sheet 42) Figure 4.99-43: Process CS_gsmSSF (sheet 43) Figure 4.99-44: Process CS_gsmSSF (sheet 44) Figure 4.99-45: Process CS_gsmSSF (sheet 45) Figure 4.99-46: Process CS_gsmSSF (sheet 46) Figure 4.99-47: Process CS_gsmSSF (sheet 47) Figure 4.99-48: Process CS_gsmSSF (sheet 48) Figure 4.99-49: Process CS_gsmSSF (sheet 49) Figure 4.99-50: Process CS_gsmSSF (sheet 50) Figure 4.99-51: Process CS_gsmSSF (sheet 51) Figure 4.99-52: Process CS_gsmSSF (sheet 52) Figure 4.99-53: Process CS_gsmSSF (sheet 53) Figure 4.99-54: Process CS_gsmSSF (sheet 54) Figure 4.99-55: Process CS_gsmSSF (sheet 55) Figure 4.99-56: Process CS_gsmSSF (sheet 56) Figure 4.99-57: Process CS_gsmSSF (sheet 57) Figure 4.99-58: Process CS_gsmSSF (sheet 58) Figure 4.99-59: Process CS_gsmSSF (sheet 59) Figure 4.99-60: Process CS_gsmSSF (sheet 60) Figure 4.99-61: Process CS_gsmSSF (sheet 61) Figure 4.99-62: Process CS_gsmSSF (sheet 62) Figure 4.100-1: Procedure Check_Criteria_Collected_Info (sheet 1) Figure 4.101-1: Procedure Check_Criteria_Analysed_Info (sheet 1) Figure 4.102-1: Procedure Check_Criteria_Unsuccessful (sheet 1) Figure 4.103-1: Procedure Connect_To_Resource (sheet 1) Figure 4.104-1: Procedure Handle_AC (sheet 1) Figure 4.105-1: Procedure Handle_ACR (sheet 1) Figure 4.106-1: Procedure Handle_CIR (sheet 1) Figure 4.107-1: Procedure Handle_CIR_leg (sheet 1) Figure 4.108-1: Procedure Complete_FCI_record (sheet 1) Figure 4.109-1: Procedure Complete_all_FCI_records (sheet 1) Figure 4.110-1: Procedure Handle_O_Answer (sheet 1) Figure 4.111-1: Procedure Handle_T_Answer (sheet 1) Figure 4.112-1: Procedure UpdateSignalling (sheet 1) 4.5.7.6 Process gsmSSF_SSME_FSM and procedures One process is instantiated for each Call Gap information flow received from a gsmSCF. Figure 4.113-1: Process gsm_SSME_SSF (sheet 1) Figure 4.113-2: Process gsm_SSME_SSF (sheet 2) NOTE: CG Int and CG Reject internal variables are initiated with False value. Figure 4.114-1: Procedure Store_Call_Gap_Criteria (sheet 1) Figure 4.115-1: Procedure Check_Gap_Criteria (sheet 1) Figure 4.115A-1: Procedure Check_Criteria_for_TOC (sheet 1) 4.5.7.7 Process CSA_gsmSSF and procedures The call gap information flow can only be received for an opened transaction between the CSA_gsmSSF and the gsmSCF. Figure 4.116-1: Process CSA_gsmSSF (sheet 1) Figure 4.116-2: Process CSA_gsmSSF (sheet 2) Figure 4.116-3: Process CSA_gsmSSF (sheet 3) Figure 4.116-4: Process CSA_gsmSSF (sheet 4) Figure 4.116-5: Process CSA_gsmSSF (sheet 5) Figure 4.116-6: Process CSA_gsmSSF (sheet 6) Figure 4.116-7: Process CSA_gsmSSF (sheet 7) Figure 4.116-8: Process CSA_gsmSSF (sheet 8) Figure 4.116-9: Process CSA_gsmSSF (sheet 9) Figure 4.116-10: Process CSA_gsmSSF (sheet 10) Figure 4.116-11: Process CSA_gsmSSF (sheet 11) Figure 4.116-12: Process CSA_gsmSSF (sheet 12) Figure 4.116-13: Process CSA_gsmSSF (sheet 13) Figure 4.116-14: Process CSA_gsmSSF (sheet 14) Figure 4.116-15: Process CSA_gsmSSF (sheet 15) Figure 4.116-16: Process CSA_gsmSSF (sheet 16) Figure 4.116-17: Process CSA_gsmSSF (sheet 17) Figure 4.116-18: Process CSA_gsmSSF (sheet 18) Figure 4.116-19: Process CSA_gsmSSF (sheet 19) Figure 4.116-20: Process CSA_gsmSSF (sheet 20) Figure 4.116-21: Process CSA_gsmSSF (sheet 21) Figure 4.116-22: Process CSA_gsmSSF (sheet 22) Figure 4.116-23: Process CSA_gsmSSF (sheet 23) 4.5.8 Assisting case Assisting case involves the following processes: - CAMEL_Assisting_MSC, - Assisting_gsmSSF. The detailed error handling for these 2 processes is specified in 3GPP TSÊ29.078Ê[36]. Figure 4.117-1: Process CAMEL_Assisting_MSC (sheet 1) Figure 4.117-2: Process CAMEL_Assisting_MSC (sheet 2) Figure 4.117-3: Process CAMEL_Assisting_MSC (sheet 3) Figure 4.118-1: Process Assisting_gsmSSF (sheet 1) Figure 4.118-2: Process Assisting_gsmSSF (sheet 2) Figure 4.118-3: Process Assisting_gsmSSF (sheet 3) Figure 4.118-4: Process Assisting_gsmSSF (sheet 4) Figure 4.118-5: Process Assisting_gsmSSF (sheet 5) Figure 4.118-6: Process Assisting_gsmSSF (sheet 6) 4.5.9 Procedure CAMEL_Provide_Subscriber_Info The procedure CAMEL_Provide_Subscriber_Info is called either during Retrieval of routeing information in the HLR or as a result of reception of the Any Time Interrogation information flow from the gsmSCF. The HLR sends a Provide Subscriber Info information flow to the VLR or SGSN dependent on the setting of the parameter ""requested domain"" received from the calling process. If the VLR or SGSN returns a Provide Subscriber Info ack information flow, then the HLR uses the received information to set the Subscriber Info to be returned to the calling process. As a network option, the HLR may use the information received from the VLR, such as Cell Id, Location Area Id or Service Area Id, to derive the Location Number and/or Geographical Information. The HLR may use the information received from the SGSN, such as Cell Id, Location Area Id, Service Area Id or Routeing Area Identity, to derive the Location Number and/or Geographical Information. This mapping is network-specific and outside the scope of the present document. NOTE: The handling in the VLR of Provide Subscriber Info is defined in 3GPP TSÊ23.018Ê[12]."
"The handling in the SGSN of Provide Subscriber Info is defined in clauseÊ11. Figure 4.119-1: Procedure CAMEL_Provide_Subscriber_Info (sheet 1) Figure 4.119-2: Procedure CAMEL_Provide_Subscriber_Info (sheet 2) 4.5.10 CAMEL specific handling of location updating and data restoration When requesting a location update or data restoration the VLR shall indicate to the HLR which CAMEL phases it supports and which CAMEL phaseÊ4 CSIs can be downloaded. The HLR may then send CAMEL subscription data to the VLR or, if some different handling is required, data for substitute handling. The CAMEL subscription data sent by the HLR shall comply with the indication of supported CAMEL phases and supported CAMEL phase 4 CSIs as received from the VLR. When the location update has been completed, the MSC/VLR in which the subscriber is registered after the location update shall check the M CSI. If a Mobility Management notification to the gsmSCF is required for this subscriber, then the MSC/VLR shall send the notification to the gsmSCF. Refer to subclauseÊ9.2.1 for a description of M CSI and the conditions under which a notification shall be sent. 4.5.11 Cross phase compatibility To avoid a case by case fallback between the gsmSSF and the gsmSCF, the gsmSSF shall use the CAP phase corresponding to the CAMEL phase negotiated on the HLR-VLR interface when it opens a dialogue with the gsmSCF. The HLR-VLR negotiation of CAMEL phase is per subscriber. 4.5.12 Handling of North American Carrier Information The following procedures apply only when the HPLMN of the CAMEL subscriber and either the VPLMN (for a mobile originated or forwarded call) or the IPLMN (for a mobile terminated call or forwarded call) are both North American. A gsmSCF may then provide the gsmSSF with any of the following North American (NA) carrier related information items. - NA Carrier Information; - NA Originating Line Information; - NA Charge Number. A gsmSSF shall use the received information items both to select any long distance carrier needed for the call and to provide certain information needed by this carrier. Any required information items not received shall be defaulted to those that would normally apply to the call in the absence of an interaction with a gsmSCF. If any NA information item received from the gsmSCF is found to be invalid, the gsmSSF may either, as an operator option, release the call or behave as if the invalid information item had not been sent. If the carrier specified in the Carrier parameter is not supported in the VPLMN or IPLMN, the gsmSSF may either, as an operator option, release the call or substitute for the unsupported carrier a preferred carrier of the VPLMN or IPLMN. Support of the NA Originating Line Information and Charge Number parameters is an operator option in a VPLMN based on roaming agreements with the operators of other PLMNs, A gsmSSF may ignore these items when received from certain or all gsmSCFs located in other PLMNs and replace them with the corresponding default items for an MO, MF, MT or VT call. 4.5.13 Handling of trunk originated calls The handling of trunk originated calls in the inter-connecting MSC is specified in 3GPP TSÊ23.018Ê[12] subclause 7.5. The processes and procedures specific to CAMEL are specified in this subclause. - Procedure CAMEL_TOC_Dialled_Services; - Procedure CAMEL_TOC_MSC_INIT; - Procedure CAMEL_NDS_TOC_INIT; - Procedure CAMEL_TOC_LEG1_MSC. The procedure CAMEL_TOC_LEG1_MSC supervises the originating party only. The process CAMEL_MT_CF_LEG2_MSC supervises the called-to party only. Hence, signals from the originating exchange are received by the procedure CAMEL_TOC_LEG1_MSC and signals from the destination exchange are received by the process CAMEL_MT_CF_LEG2_MSC. 4.5.13.1 Procedure CAMEL_TOC_Dialled_Services Void 4.5.13.2 Procedure CAMEL_TOC_MSC_INIT Sheet 1: Decision ""First procedure call"": The procedure call formal parameter (FPAR) values ""First"" or ""NotFirst"" indicate whether the gsmSSF instance has been invoked for this call at the Collected_Information DP. - First_ The gsmSSF has not been invoked. - NotFirst: The gsmSSF has been invoked earlier and the gsmSSF is waiting for additional digits. The gsmSSF may not have triggered a CAP dialogue to gsmSCF. 4.5.13.3 Procedure CAMEL_NDS_TOC_INIT Sheet 1: Decision ""First procedure call"": The procedure call formal parameter (FPAR) values ""First"" or ""NotFirst"" indicate whether the gsmSSF instance has been invoked for this call at Analysed_Information DP. The dialled services invoke a different instance of gsmSSF than at the Collected_Information DP. - First_ The gsmSSF has not been invoked. - NotFirst: The gsmSSF has been invoked earlier and the gsmSSF is waiting for additional digits. The gsmSSF may not have triggered a CAP dialogue to gsmSCF. 4.5.13.4 Procedure CAMEL_TOC_LEG1_MSC Void Figure 4.119A-1: Procedure CAMEL_TOC_Dialled_Services (sheet 1) Figure 4.119B-1: Procedure CAMEL_TOC_MSC_INIT (sheet 1) Figure 4.119B-2: Procedure CAMEL_TOC_MSC_INIT (sheet 2) Figure 4.119B-3: Procedure CAMEL_TOC_MSC_INIT (sheet 3) Figure 4.119B-4: Procedure CAMEL_TOC_MSC_INIT (sheet 4) Figure 4.119B-5: Procedure CAMEL_TOC_MSC_INIT (sheet 5) Figure 4.119B-6: Procedure CAMEL_TOC_MSC_INIT (sheet 6) Figure 4.119B-7: Procedure CAMEL_TOC_MSC_INIT (sheet 7) Figure 4.119C-1: Procedure CAMEL_NDS_TOC_INIT (sheet 1) Figure 4.119C-2: Procedure CAMEL_NDS_TOC_INIT (sheet 2) Figure 4.119C-3: Procedure CAMEL_NDS_TOC_INIT (sheet 3) Figure 4.119C-4: Procedure CAMEL_NDS_TOC_INIT (sheet 4) Figure 4.119C-5: Procedure CAMEL_NDS_TOC_INIT (sheet 5) Figure 4.119D-1: Procedure CAMEL_TOC_LEG1_MSC (sheet 1) Figure 4.119D-2: Procedure CAMEL_TOC_LEG1_MSC (sheet 2) Figure 4.119D-3: Procedure CAMEL_TOC_LEG1_MSC (sheet 3) Figure 4.119D-4: Procedure CAMEL_TOC_LEG1_MSC (sheet 4) Figure 4.119D-5: Procedure CAMEL_TOC_LEG1_MSC (sheet 5) Figure 4.119D-6: Procedure CAMEL_TOC_LEG1_MSC (sheet 6) Figure 4.119D-7: Procedure CAMEL_TOC_LEG1_MSC (sheet 7) 4.6 Description of information flows This clause contains the detailed description of the information flows used by CAMEL for Circuit Switched call control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E), Optional (O) or not applicable (-) for each different traffic case applicable to the following CSI: - MO Mobile Originating call in the VMSC (O CSI, D CSI or N CSI dialogue); - MF Mobile Forwarded call in the VMSC or the GMSC as in figure 4.7 (O CSI, D CSI or N CSI dialogue); - MT Mobile Terminating call in the GMSC (T CSI dialogue); - VT Mobile Terminating call in the VMSC (VT CSI dialogue); - NC gsmSCF initiated new call; - NP gsmSCF initiated new party in an existing call; - TO Trunk Originating call in the MSC (TO-CSI or N-CSI dialogue). If the IEs in one table apply in all the possible cases listed above or no distinction is needed, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included for the corresponding traffic case. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted for the corresponding traffic case. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. it is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The distinction between MO, MF, MT, VT, NC, NP and TO calls is not applicable to all Information Flows. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSSF shall functionally support all IEs which can be sent to it. - The gsmSCF may silently discard any IE which it does not functionally support. - The gsmSRF shall return an error if it does not functionally support an IE which it receives. - The HLR may silently discard any IE which it does not functionally support. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.078Ê[36]. 4.6.1 gsmSSF to gsmSCF information flows 4.6.1.1 Activity Test ack 4.6.1.1.1 Description This IF is the response to the Activity Test. 4.6.1.1.2 Information Elements This IF contains no information elements. 4.6.1.2 Apply Charging Report 4.6.1.2.1 Description This IF is used by the gsmSSF to report to the gsmSCF the information requested in the Apply Charging IF. 4.6.1.2.2 Information Elements Information element name Status Description Call Result M This IE contains the charging information provided by the gsmSSF. Call Result contains the following information elements: Information element name Status Description Time Duration Charging Result M This IE is described in a table below. Time Duration Charging Result contains the following information elements: Information element name Status Description Time Information M This IE is described in a table below. Party To Charge M This IE is received in the related Apply Charging IF to correlate the result to the request. This IE shall be a copy of the corresponding IE received in the Apply Charging IF. ACh Charging Address M This IE identifies the call party to which the Apply Charging Report IF applies. This IE is described in a table below. Leg Active M This IE indicates whether the call leg is active or not. When the ACR is sent because of a change in CPH configuration legActive=FALSE shall be used. Call Leg Released At Tcp Expiry S This IE is an indication that the gsmSSF has released the call leg or the Temporary Connection or SRF Connection, due to Tcp expiry. It shall be present when Apply Charging Report is sent due to Tcp expiry and the gsmSSF has released the call leg or the Temporary Connection or SRF Connection (because 'Release If Duration Exceeded' was present in the Apply Charging IF). In all other cases, this IE shall be absent. Time Information contains the following information elements: Information element name Status Description Time If No Tariff Switch S,E This IE shall be present if no tariff switch has occurred since the reception of the first Apply Charging IF for the connection to the Called Party, the Temporary Connection, or the gsmSRF connection, otherwise it shall be absent. If Answer was detected for the connection to the Called Party, the Temporary Connection or the gsmSRF connection, then the elapsed time since detection of Answer shall be reported. For a change in a CPH configuration the particular time when the legs in a CS are connected shall be taken as Answer. If answer was not detected, it shall be set to ""0"". Time If Tariff Switch S,E This IE shall be present if a tariff switch has occurred since the reception of the first Apply Charging IF for the connection to the Called Party, the Temporary Connection, or the gsmSRF connection, otherwise it shall be absent. ACh Charging Address contains the following information elements: Information element name Status Description Leg ID E This IE indicates that the Apply Charging Report IF applies to the specified leg. SRF Connection E This IE indicates that the Apply Charging Report IF applies to the Temporary Connection or SRF Connection 4.6.1.3 Call Information Report 4.6.1.3.1 Description This IF is used to send specific call information for a single call party to the gsmSCF as requested by the gsmSCF in a previous Call Information Request IF. 4.6.1.3.2 Information Elements Information element name Status Description Requested Information List M This IE specifies the requested information. Leg ID M This IE indicates the party in the call for which information shall be collected. 4.6.1.4 Disconnect Leg ack 4.6.1.4.1 Description This IF is the successful response to the Disconnect Leg IF. 4.6.1.4.2 Information Elements This IF contains no information elements. 4.6.1.5 Entity Released 4.6.1.5.1 Description This IF is used to inform the gsmSCF about the release of a logical entity (CS or BCSM) caused by exception or errors. It is sent by the CSA FSM if this information cannot be conveyed within an TC_ABORT or TC_END because the TC dialogue has to be kept because of other existing logical entities (CS or BCSM) in this CSA which are not affected by this error/exception. This IF is not sent if the last CS was released. The IF Entity Released is not used if the release of the entity can be reported through other IFs, e.g. Event Report BCSM, Call Information Report. 4.6.1.5.2 Information Elements Information element name Status Description CS Failure E This IE indicates that an CS has been released. BCSM Failure E This IE indicates that a leg has been released. CS Failure contains the following information elements: Information element name Status Description Call Segment ID M This IE identifies the released CS. Cause C This IE indicates the cause for releasing the CS. The Cause may be used by the gsmSCF to decide how to continue the call handling. BCSM Failure contains the following information elements: Information element name Status Description Leg ID M This IE identifies the released leg. Cause C This IE indicates the cause for releasing the leg. The cause may be used by the gsmSCF to decide handling. 4.6.1.6 Event Report BCSM 4.6.1.6.1 Description This IF is used to notify the gsmSCF of a call-related event (i.e. BCSM events as answer and disconnect) previously requested by the gsmSCF in a Request Report BCSM Event IF. 4.6.1.6.2 Information Elements Information element name MO MF MT VT NC NP TO Description Event Type BCSM M M M M M M M This IE specifies the type of event that is reported. Event Specific Information BCSM C C C C C C C This IE indicates the call related information specific to the event. Leg ID M M M M M M M This IE indicates the party in the call for which the event is reported. Misc Call Info M M M M M M M This IE indicates the DP type. If the Event Type BCSM IE contains either O_Answer or T_Answer, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Destination Address M M M M M M M This IE specifies the destination address for the call leg. The NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of destination address may be zero. OR - C C - - - - This IE indicates that the call was subject to basic Optimal Routeing as specified in 3GPP TSÊ23.079Ê[19]. Forwarded Call - M C C - - - This IE indicates that the call has been subject to a Call Forwarding supplementary service. Charge Indicator S S S S S S S This IE specifies the value which will be stored in the Call Data Record. See ITU T Recommendation Q.763Ê[43]. Ext Basic Service Code S S S S - - S This IE is used for SCUDIF calls. It indicates the type of basic service, i.e. teleservice or bearer service. It indicates the service active at answer for the SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27]). Ext Basic Service Code 2 S S S S - - S This IE is used for SCUDIF calls. It indicates the type of basic service, i.e. teleservice or bearer service. It indicates the service which is not active at answer for the SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27]). It shall be present if the negotiation of the SCUDIF services resulted in both basic services for the SCUDIF call. Otherwise shall be absent. If the Event Type BCSM IE contains either O_Mid_Call or T_Mid_Call, then the Event Specific Information BCSM IE contains the following information element: Information element name MO MF MT VT NC NP TO Description Midcall Info M - - M - - M This IE is described in a table below. MidCall Info contains the following information elements: Information element name MO MF MT VT NC NP TO Description DTMF Digits Completed S,E - - S,E - - S,E This IE contains the detected mid-call digits. This IE shall be present when triggering takes place after the minimum number of digits has been detected. DTMF Digits Timeout S,E - - S,E - - S,E This IE contains the detected mid-call digits. This IE shall be present when triggering takes place before the minimum number of digits has been detected. If the Event Type BCSM IE contains one of Route_Select_Failure, O_Busy, O_Disconnect or T_Disconnect, then the Event Specific Information BCSM IE contains the following information element: Information element name MO MF MT VT NC NP TO Description Cause C C C C C C C This IE indicates the cause. If the Event Type BCSM IE contains T_Busy, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Cause - - C C - - This IE indicates the cause. Call forwarded - - C C - - This IE indicates that the call may be forwarded by the appropriate Call Forwarding supplementary service or Call Deflection supplementary service. If T_Busy is reported from the GMSC, then this IE shall be present in the following cases: - The event is triggered by the reception of an FTN in the 2nd Send Routeing Info ack from the HLR; - The event is triggered by the reception of the Resume Call Handling information flow from the VMSC. If T_Busy is reported from the VMSC, then this IE shall be present in the following cases: - The event is triggered by the invocation of conditional call forwarding (Busy or Not_Reachable); - The event notification is triggered by the invocation of Call Deflection. Route Not permitted - - S - - - This IE indicates that the further call setup will not take place in this GMSC due to the rules of basic optimal routeing. See 3GPP TSÊ23.079Ê[19]. Forwarding Destination Number - - C C - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarded IE is present. Otherwise, it shall be absent. If the Event Type BCSM IE contains T_No_Answer, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Call Forwarded - - C C - - This IE indicates that the call may be forwarded by the appropriate Call Forwarding supplementary service. If T_No_Answer is reported from the GMSC, then this IE shall be present in the following cases: - The event is triggered by the reception of the Resume Call Handling information flow from the VMSC. If the T_No_Answer is reported from the VMSC, then this IE shall be present in the following cases: - The event is triggered by the invocation of conditional call forwarding (No_Answer). Forwarding Destination Number - - C C - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarded IE is present. Otherwise, it shall be absent. If the Event Type BCSM IE contains Call_Accepted or O_Term_Seized, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Location Information C - - C - - - See subclauseÊ4.6.1.8 with VLR Number IE as ""- (not applicable)"". NOTE If gsmSCF does not arm DPÊO_Change_Of_Position, then the Location Information reported at DPÊO_Term_Seized may be the same as the Location Information reported at DPÊCollected_Information, even when the subscriber has changed location between DPÊCollected Information and DPÊO_Term_Seized. If the Event Type BCSM IE contains O_Change_Of_Position or T_Change_Of_Position, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP Description Location Information C - - C - - See subclauseÊ4.6.1.8 with VLR Number IE as ""- (not applicable)"". Met DP Criteria List S - - S - - This IE is described in a table below. It carries the list of criteria that were triggered and met for the reporting of the change of position event. It shall be present if change of position control info was received in the request. Met DP Criteria List contains a list of up to 10 instances of the following information element: Information element name MO MF MT VT NC NP Description Met DP Criterion M - - M - - Each Met DP Criterion IE is one of the 6 possibilities indicated in the table below. If multiple instances of the Met DP Criterion IE have the same value, this is not an error. Each instance of the Met DP Criterion IE contains one of the following information elements: Information element name MO MF MT VT NC NP Description Cell Global ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the cell specified in this IE. Furthermore it indicates whether the handover was into or out of the cell. Service Area ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the service area specified in this IE. Furthermore it indicates whether the handover was into or out of the service area. Location Area ID E - - E - - This IE indicates that the mobile station performed handover across the boundary of the location area specified in this IE. Furthermore it indicates whether the handover was into or out of the location area. Inter System Handover E - - E - - This IE indicates that the mobile station performed inter system handover. Furthermore it indicates whether the handover was from GSM to UMTS or from UMTS to GSM. Inter PLMN Handover E - - E - - This IE indicates that the mobile station performed inter PLMN handover. Inter MSC Handover E - - E - - This IE indicates that the mobile station performed inter MSC handover. If the Event Type BCSM IE contains O_Abandon, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Route Not Permitted - S - - - - - This IE indicates that the further call setup will not take place in this MSC due to the rules of basic optimal routeing. See 3GPP TSÊ23.079Ê[19]. If the Event Type BCSM IE contains one of O_Service_Change or T_Service_Change, then the Event Specific Information BCSM IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Ext Basic Service Code M M M M - - M This IE indicates the new basic service code after a successful bearer service modification. Nature of Service Change C C C C - - C This IE indicates the nature of the service change (User initiated service change or network initiated service change). Shall be present if available. Initiator of Service Change M M M M - - M This IE indicates the initiator of the service change (A side or B side) If the Event Type BCSM IE contains O_No_Answer, then the Event Specific Information BCSM IE is not included. If the Event Type BCSM IE contains Collected_Info, then the Event Specific Information BCSM IE contains the following information elements: Information element name TO Description Called Party Number M The contents of the Called Party Number parameter are as follows: - Nature of address indicator Ð set to the same value as the Called Party Number parameter sent in InitialDP: - Numbering plan indicator Ð set to the same value as the Called Party Number parameter sent in InitialDP; - Address signals: - If 'N' relevant digits, or more, have been collected and the end of pulsing signal (ST) has not been received, then all relevant digits shall be reported plus a filler digit, if necessary (note 1) - If the end of pulsing signal (ST) has been received then all relevant digits shall be reported, plus the end of pulsing signal and a filler digit, if necessary (note 1) - If the inter-digit timer expires in the MSC then all relevant digits shall be reported plus a filler digit, if necessary (notes 1 & 2). Note 1: The relevant digits are the digits originally reported in InitialDP plus any additional relevant digits collected as a result of the CollectInformation operation(s). Note 2: If the inter-digit timer expires before any additional relevant digits have been collected then the digits reported are the same as those previously reported in InitialDP or EventReportBCSM. Note 3: Some dialled digits may not be relevant for reporting. Relevant digits are determined by operator defined rules in the MSC, e.g. operator specific service selection information may not be reported. The MSC/ gsmSSF compares 'N' against the digits to be reported. 4.6.1.7 Initiate Call Attempt ack 4.6.1.7.1 Description This IF is the successful response to the Initiate Call Attempt IF. 4.6.1.7.2 Information Elements Information element name NC NP Description Supported CAMEL Phases M M This IE indicates the CAMEL Phases supported. Offered CAMEL4 Functionalities M M This IE is described in subclause 4.6.1.8. This IE indicates the CAMEL phaseÊ4 functionalities offered. Release Call Argument Extension Allowed O - This IE indicates whether the gsmSCF is allowed to use network specific IE in the Release Call IF. 4.6.1.8 Initial DP 4.6.1.8.1 Description This IF is generated by the gsmSSF when a trigger is detected at a DP in the BCSM, to request instructions from the gsmSCF. 4.6.1.8.2 Information Elements (Note: IEs in the NC columns in this IF may need further study.) Information element name MO MF MT VT NC NP TO Description Additional Calling Party Number C C C C - C C This IE contains the calling party number provided by the access signalling system of the calling user or received from the gsmSCF due to the previous CAMEL processing. Called Party Number C M M M - M M This IE contains the number used to identify the called party in the forward direction. For MO and MF calls this IE is used in the case of TDP Route_Select_Failure (this is the destination number used to route the call) and in the case of TDP Busy and TDP No Reply (this is the MSISDN when the destination number used for the call is an MSRN, or in the case of unsuccessful call establishment received from the HLR via the MAP interface, otherwise it is the number used to route the call). For VT calls when there is no forwarding pending this is the MSISDN received in the Provide Roaming Number; if the MSISDN is not available, the basic MSISDN is used. For the MT and VT call case when there is call forwarding or call deflection pending, this is the MSISDN, i.e. not the forwarded-to or deflected-to number. If the Initial DP IF is sent at TDP Route_Select_Failure or TDP Analysed_Information then the NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of the destination address may be zero. For TO calls this IE is used to identify the called party in the forward direction. It is used in the case of TDP Collected_Information and TDP Analysed_Information. The number contained in this IE shall be the relevant digits, for reporting purposes, of the number received in the telephony signalling system call establishment message (e.g. ISUP IAM). The number may or may not include the end of pulsing signal (ST). Called Party BCD Number C - - - - - - This IE contains the number used to identify the called party in the forward direction. It is used for an MO call in all cases except in the case of TDP Route_Select_Failure. For the TDP Collected_Information, the number contained in this IE shall be identical to the number received over the access network. It may e.g. include service selection information, such as ? and # digits, or carrier selection information dialled by the subscriber. For the TDP Analysed_Information, the number contained in this IE shall be the dialled number received over the network access or received from a gsmSCF in a Connect IF, Service selection information, such as * and # digits may be present (see subclauseÊ4.2.1.2.2); carrier selection information dialled by the subscriber is not present. Calling Party Number M C C C - C C This IE carries the calling party number to identify the calling party or the origin of the call. Calling Partys Category M C C C - C C This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). CallGap Encountered C C C C - C C This IE indicates the type of gapping which has been applied to the related call. This IE shall be present only if a call gapping context is applicable to the Initial DP IF. Call Reference Number M M M M - M M This IE may be used by the gsmSCF for inclusion in a network optional gsmSCF call record. It has to be coupled with the identity of the MSC which allocated it in order to define unambiguously the identity of the call. For MO calls, the call reference number is set by the serving VMSC and included in the MO call record. For MT calls, the call reference number is set by the GMSC and included in the RCF call record in the GMSC and in the MT call record in the terminating MSC. For VT calls, the call reference number is set by the GMSC and included in the RCF call record in the GMSC and in the MT call record in the terminating MSC. For MF calls, the call reference number is set by the GMSC and included in the CF record in the forwarding MSC. For the setting of the Call Reference Number for NP calls, see the corresponding call case above (MO, MT, VT or MF). For TO calls, the call reference number is set by the inter-connecting MSC. Cause C C C C - - - This IE indicates the cause specific to the armed BCSM DP event. This IE is applicable to DPÊRoute_Select_Failure and DPÊT_Busy. The cause may be used by the gsmSCF to decide how to continue the call handling. Event Type BCSM M M M M - M M This IE indicates the armed BCSM DP event, resulting in the Initial DP IF. For the TO traffic case this will be 'CollectedInformation' or 'AnalysedInformation'. IMSI M M M M - S - This IE identifies the mobile subscriber. For the NP case, the IMSI is mandatory if the new party is initiated in an MO, MF, MT, or VT call, otherwise it shall be absent. IP SSP Capabilities C C C C - C C This IE indicates which SRF resources are supported within the gsmSSF and are available. If this IE is absent, it indicates that no gsmSRF is attached and available. Location Information M - C M - - - This IE is described in a table below. Location Number M C C C - - C For mobile originated calls this IE represents the location of the calling party. For all other call scenarios this IE contains the location number received in the incoming ISUP signalling. MSC Address M M M M - M M For MO calls, the MSC Address carries the international E.164 address of the serving VMSC. For MT calls, the MSC Address carries the international E.164 address of the GMSC. For VT calls, the MSC Address carries the international E.164 address of the serving VMSC. For MF calls, the MSC Address carries the international E.164 address of the forwarding MSC. For NP case, see the corresponding call case above (MO, MT, VT or MF). For TO calls, the MSC Address carries the international E.164 address of the inter-connecting MSC. GMSC Address - M - M - S - For MF calls, the GMSC Address carries the international E.164 address of the GMSC. For VT calls, the GMSC Address carries the international E.164 address of the GMSC. For NP calls, the GMSC Address is mandatory if the new party is initiated in an MF call or in a VT call, otherwise it shall be absent. The GMSC Address carries the international E.164 address of the GMSC. Carrier S S S S - S S This IE is described in a table below. This IE may be present when the VPLMN and the HPLMN of the subscriber are both North American. For MO calls, this IE shall identify any carrier that was explicitly selected by the calling subscriber. If no carrier was explicitly selected, this IE shall contain the calling subscriber's subscribed carrier. For MT and VT calls, the IE shall contain the carrier subscribed to by the called subscriber. For MF calls, the IE shall contain the carrier subscribed to by the forwarding subscriber. For TO calls, this IE shall identify any carrier that was explicitly selected by the calling party or redirecting party, as received from the telephony signalling system (e.g. ISUP IAM). Original Called Party ID C C C C - - C This IE carries the dialled digits if the call has met call forwarding on the route to the gsmSSF. This IE shall also be sent if it was received from the gsmSCF due to previous CAMEL processing. Redirecting Party ID C C C C - - C This IE indicates the directory number the call was redirected from. This IE shall also be sent if it was received from the gsmSCF due to previous CAMEL processing. Redirection Information C C C C - - C This IE contains forwarding related information, such as the redirection counter. Service Key M M M M - M M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application within the gsmSCF. Subscriber State - - C C - - - This IE indicates the status of the MS. The states are: - CAMEL Busy: The MS is engaged on a transaction for a mobile originating or terminated circuit-switched call. - Network Determined Not Reachable: The network can determine from its internal data that the MS is not reachable. - Assumed Idle: The state of the MS is neither ""CAMEL Busy"" nor ""Network Determined Not Reachable"". - Not provided from VLR. Time And Timezone M M M M - M M This IE contains the time that the gsmSSF was triggered, and the time zone in which gsmSSF resides. Call Forwarding SS Pending - - C C - - - If the Initial DP IF is sent from the GMSC, then this IE shall be present in the following cases: - The GMSC has received an FTN in the 1st Send Routeing Info ack IF from the HLR. - The GMSC has received an FTN in the 2nd Send Routeing Info ack IF from the HLR and no relationship with the gsmSCF exists at that moment. - The GMSC has received the Resume Call Handling IF from the VMSC and no relationship with the gsmSCF exists at that moment. If the Initial DP IF is sent from the VMSC, then this IE shall be present in the following cases: - Conditional call forwarding is invoked and no relationship with the gsmSCF exists at that moment. - Call Deflection is invoked and no relationship with the gsmSCF exists at that moment. Forwarding Destination Number - - C C - - - This IE contains the Forwarded-to-Number or the Deflected-to-Number. It shall be present if the Call Forwarding SS Pending IE is present, otherwise it shall be absent. Service Interaction Indicators Two C C C C - C C The IE is described in a table below. This IE is present if it is received in the ISUP message or due to previous CAMEL processing. CUG Index C - - - - C - See 3GPP TSÊ23.085Ê[22] for details of this IE. CUG Interlock Code C C C C - C C This IE shall be set according to 3GPP TSÊ23.085Ê[22] unless modified by the gsmSCF via the Connect or Continue With Argument IFs. Outgoing Access Indicator C C C C - C C This IE shall be set according to the 3GPP TSÊ23.085Ê[22] unless modified by the gsmSCF via the Connect or Continue With Argument IFs. MS Classmark 2 C - - - - - - This IE contains the MS classmark 2, which is sent by the MS when it requests access to setup the MO call or responds to paging in the CS domain. IMEI (with software version) C - - - - - - This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Supported CAMEL Phases M M M M M M M This IE indicates the CAMEL Phases supported by the GMSC or the VMSC. Offered CAMEL4 Functionalities M M M M M M M This IE is described in a table below. This IE indicates the CAMEL phaseÊ4 functionalities offered by the GMSC or the VMSC."
"Bearer Capability M C C C - C C This IE indicates the bearer capability connection to the user. For a SCUDIF call (as defined in 3GPP TSÊ23.172Ê[27] this IE indicates the Bearer CapabilityÊof the preferred service. Bearer CapabilityÊ2 C C C C - - C This IE indicates the bearer capability of the less preferred service for a SCUDIF call. Ext-Basic Service Code C C C C - C C This IE indicates the basic service, i.e. teleservice or bearer service. For a SCUDIF call this IE indicates the basic service of the preferred service Ext-Basic Service CodeÊ2 C C C C - - C This IE indicates the basic service of the less preferred service for a SCUDIF call. High Layer Compatibility C C C C - C C This IE indicates the high layer compatibility, which will be used to determine the ISDN-teleservice of a connected ISDN terminal. For a SCUDIF call this IE indicates the high layer compatibility of the preferred service. High Layer Compatibility 2 C C C C - C C This IE indicates the high layer compatibility of the less preferred service for a SCUDIF call. Low Layer Compatibility C C C C - C C This IE indicates the low layer compatibility, which will be used to determine the ISDN bearer capability of a connected ISDN terminal. For a SCUDIF call this IE indicates the Low Layer Compatibility of the preferred service. Low Layer Compatibility 2 C C C C - C C This IE indicates the low layer compatibility of the less preferred service for a SCUDIF call. Enhanced Dialled Services Allowed S S - - S S S This IE indicates that the gsmSCF may use the Enhanced Dialled Services (EDS). This IE shall be included if and only if all of following four conditions are fulfilled: - this IF is sent due to triggering on DP Analysed_Information; and - the EDS functionality is offered for this call (as indicated in the Offered CAMEL4 Functionalities); and - there is no more than one outgoing leg within this call; and - there is no other CAMEL dialogue active for the leg for which this IF is sent. User-to-User Service activation request O O O O - - O This IE may be sent if it is received in a call control message. See 3GPP TSÊ23.087Ê[45], 3GPP TSÊ24.008Ê[30], and ETSI ENÊ300Ê356 1Ê[40] for details of this IE. User-to-User Information O O O O - - O This IE may be sent if it is received in a call control message. See 3GPP TSÊ23.087Ê[45], 3GPP TSÊ24.008Ê[30], and ETSI ENÊ300Ê356 1Ê[40] for details of this IE. Collect Information Allowed - - - - - - S This IE indicates whether the gsmSCF is allowed to use Collect Information for the armed BCSM DP event. This IE shall only be included when the armed BCSM DP event is 'CollectedInformation' or 'AnalysedInformation'. Note: This IE shall only be included for the 'AnalysedInformation' BCSM DP event if the 'Enhanced Dialled Services Allowed' IE is also present. Release Call Argument Extension Allowed O O O O - O O This IE indicates whether the gsmSCF is allowed to use network specific IE in the Release Call IF. Offered CAMEL4 Functionalities contains the following information elements: Information element name Status Description Initiate Call Attempt S This IE indicates that the gsmSCF may send to the gsmSSF the Initiate Call Attempt IF. Split Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Split Leg IF. Move Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Move Leg IF. Disconnect Leg S This IE indicates that the gsmSCF may send to the gsmSSF the Disconnect Leg IF. Entity Released S This IE indicates that the gsmSSF will send to the gsmSCF the Entity Released IF, when appropriate. DFC With Argument S This IE indicates that the gsmSCF may send to the gsmSSF the Disconnect Forward Connection With Argument IF. Play Tone S This IE indicates that the gsmSCF may send to the gsmSSF the Play Tone IF. DTMF Mid Call S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_MidCall or T_MidCall DP. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. Charging Indicator S This IE indicates that the Charge Indicator IE may be present in the Event Report BCSM IF reporting the O_Answer or T_Answer DP. Alerting DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Term_Seized or Call_Accepted DP. Location At Alerting S This IE indicates that the Location Information IE shall be present (if available) in the Event Report BCSM IF reporting the O_Term_Seized or Call_Accepted DP. Change Of Position DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Change_Of_Position or T_Change_Of_Position DPs. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. OR Interactions S This IE indicates that the gsmSCF may send to the gsmSSF the Basic OR Interrogation Requested IE in the Connect or Continue With Argument IF. This IE indicates that the Route Not Permitted IE may be present in the Event Report BCSM IF reporting the O_Abandon DP. Warning Tone Enhancements S This IE indicates that the gsmSCF may send to the gsmSSF the Burstlist IE (within the Audible Indicator IE) in an Apply Charging IF. CF Enhancements S This IE indicates that the Forwarding Destination Number IE may be present in the Event Report BCSM IF reporting the T_Busy or T_No_Answer DP. Criteria for Change Of Position DP S This IE indicates that the gsmSCF may send to the gsmSSF in the Request Report BCSM Event IF criteria for reporting the report of O_Change_Of_Position or T_Change_Of_Position. Subscribed Enhanced Dialled Services S This IE indicates that Subscribed Enhanced Dialled Services is offered. Serving Network Enhanced Dialled Services S This IE indicates that Serving Network Enhanced Dialled Services is offered. Service Change DP S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the O_Service_Change or T_Service_Change DPs. The gsmSCF may instruct the gsmSSF to automatically re-arm the DP, when encountered. Collect Information S This IE indicates that the gsmSCF may instruct the gsmSSF to arm the CollectedInfo EDP and order the MSC to collect a specific number of additional dialled digits. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name MO MF MT VT NC NP Description Location Number - - C C - - See 3GPP TSÊ23.018Ê[12]. Service area ID C,E - C,E C,E - - See 3GPP TSÊ23.018Ê[12]. Cell ID C,E - C,E C,E - - See 3GPP TSÊ23.018Ê[12]. Geographical information C - C C - - See 3GPP TSÊ23.018Ê[12]. Geodetic information C - C C - - See 3GPP TSÊ23.018Ê[12]. VLR number M - C M - - See 3GPP TSÊ23.018Ê[12]. Age Of location information M - C C - - See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - - - - - - Not applicable Location area ID C,E - C,E C,E - - See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S - S S - - This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority shall be present. See 3GPP TSÊ23.073Ê[18]. This IE shall be present if available and SoLSA is supported, otherwise it shall be absent. User CSG Information C - C - - - See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID - - C,E - - - See 3GPP TSÊ23.018Ê[12]. Tracking area ID - - C,E - - - See 3GPP TSÊ23.018Ê[12]. Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M - M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M - M M This IE indicates the way the carrier was selected, i.e.: - dialled - subscribed Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator C C C C - C C This IE is described in a table below. HOLD Treatment Indicator C - - C - C - This IE indicates whether the CAMEL subscriber can invoke HOLD for the call. CW Treatment Indicator C - - C - C - This IE indicates whether CW can be applied for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator C - - C - C - This IE indicates whether the call leg can become part of an ECT call initiated by the CAMEL subscriber. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator C C C C - C C This IE indicates whether the call leg can become part of a MPTY call initiated by the called subscriber. Call Diversion Treatment Indicator C C C C - C C This IE indicates whether the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. 4.6.1.9 Move Leg ack 4.6.1.9.1 Description This IF is the successful response to the Move Leg IF. 4.6.1.9.2 Information Elements This IF contains no information elements. 4.6.1.10 Split Leg ack 4.6.1.10.1 Description This IF is the successful response to the Split Leg IF. 4.6.1.10.2 Information Elements This IF contains no information elements. 4.6.2 gsmSCF to gsmSSF information flows 4.6.2.1 Activity Test 4.6.2.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gsmSSF. If the relationship is still in existence, then the gsmSSF will respond. If no reply is received, then the gsmSCF will assume that the gsmSSF has failed in some way and will take appropriate action. 4.6.2.1.2 Information Elements This IF contains no information elements. 4.6.2.2 Apply Charging 4.6.2.2.1 Description This IF is used to instruct the gsmSSF to apply charging mechanisms to control the call duration. 4.6.2.2.2 Information Elements Information element name MO MF MT VT NC NP TO Description ACh Billing Charging Characteristics M M M M M M M This IE specifies the charging related information to be provided by the gsmSSF and the conditions on which this information has to be provided back to the gsmSCF. Party To Charge M M M M M M M This IE shall be reflected in the corresponding IE of the Apply Charging Report IF. This IE has no effect on the charging procedures in the MSC. ACh Charging Address M M M M M M M This IE identifies the call party to which the Apply Charging IF applies. This IE is described in a table below. ACh Billing Charging Characteristics contains the following information element: Information element name MO MF MT VT NC NP TO Description Time Duration Charging M M M M M M M This IE is described in a table below. Time Duration Charging contains the following information elements: Information element name MO MF MT VT NC NP TO Description Max Call Period Duration M M M M M M M This IE indicates the maximum call period duration timer. Tariff Switch Interval O O O O O O O This IE indicates the tariff switch time until the next tariff switch applies for this call leg. Release If Duration Exceeded O O O O O O O This IE indicates that the call leg, SRF connection or Temporary connection shall be released when the Max call Period Duration expires. The cause used in the Release IF shall be ""normal unspecified"". The default handling is to continue the call. Audible Indicator O - O O O O O This IE is described in a table below. Audible Indicator IE contains the following information elements: Information element name MO MF MT VT NC NP TO Description Tone E - E E E E E This IE indicates that a fixed sequence of tones shall be played to the CAMEL subscriber. In the NC case, the first party created will receive the warning tone. In the TO case the calling party will receive the warning tone. If present, this IE indicates that 30 seconds before the Max Call Period Duration timer expires, a fixed sequence of tones consisting of 3 tones of 900 Hz, with a 200 milliseconds tone duration and a 200 milliseconds intertone duration shall be played. Burstlist E - E E E E E This IE is described in the table below. This IE indicates a variable sequence of bursts that shall be played during the call period to the CAMEL subscriber. In the NC case, the first party created will receive the warning tone. In the TO case the calling party will receive the warning tone. Burstlist IE contains the following information elements: Information element name Status Description Warning Period M This IE indicates the time, before the Max Call Period Duration timer expires, when the Play Burst List IE shall start. Number Of Bursts M This IE indicates the number of bursts to be played. There may be up to three bursts. Burst Interval M This IE indicates the time interval between successive bursts. Number Of Tones In Burst M This IE indicates the number of tones to be played in each burst. There may be up to three tones per burst. The tone is fixed to 900 Hz. Tone Duration M This IE indicates the duration of a tone in a burst. Tone Interval M This IE indicates the time interval between successive tones in a burst. NOTE Service logic designers should note that the total duration of the Burst List should not exceed the WarningPeriod IE, otherwise an incomplete Burst List will be played to the served party. ACh Charging Address contains the following information elements: Information element name MO MF MT VT NC NP TO Description Leg ID E E E E E E E This IE indicates that the Apply Charging IF applies to the specified leg. SRF Connection E E E E E E E This IE indicates that the Apply Charging IF applies to the Temporary Connection or SRF Connection 4.6.2.3 Call Gap 4.6.2.3.1 Description This IF is used to activate/modify/remove a call gap mechanism in the gsmSSF. The call gap mechanism is used to reduce the rate at which specific service requests are sent to a gsmSCF. A Call Gap IF can only be sent on an opened dialogue between a gsmSCF and a gsmSSF. It is possible to have several call gapping conditions applicable to the same gsmSSF (i.e. each conditions was activated for a defined Service (identified by the service Key) by a defined gsmSCF (identified by the gsmSCF address). 4.6.2.3.2 Information Elements Information element name Status Description Gap Criteria M This IE specifies the criteria for a call to be subject to call gapping. Gap Indicators M This IE indicates the gapping characteristics. Control Type O This IE indicates the reason for activating call gapping. The value ""gsmSCF Overloaded"" indicates that an automatic congestion detection and control mechanism in the gsmSCF has detected a congestion situation. The value ""Manually Initiated"" indicates that the service and/or network/service management centre has detected a congestion situation, or any other situation that requires manually initiated controls. The Control Type ""Manually Initiated"" will have priority over a ""gsmSCF Overloaded"" call gap. Note that Non-IN controlled traffic control mechanism can also apply to an exchange with the gsmSSF functionality. As the non-IN controlled traffic control is within the MSC, this traffic control has implicit priority over the IN controlled traffic control. The non-IN controlled traffic control may also have some influence on the IN call. Therefore it is recommended to take measures to coordinate several traffic control mechanisms. The non-IN controlled traffic control and co-ordination of several traffic control mechanisms are out of the scope of the present document. Gap Treatment O This IE indicates how calls that were rejected due to the call gapping condition and have Default Call Handling as ""Release Call"" shall be treated. Gap Criteria contains one of the following information elements: Information element name Status Description Basic Gap Criteria O,E This IE is a choice of various basic criteria. Compound Gap Criteria O,E This IE is a choice of various criteria including a gsmSCF ID. Compound Gap Criteria contains the following information elements: Information element name Status Description Basic Gap Criteria M This IE is a choice of various criteria. gsmSCF ID O This IE contains the address of the gsmSCF which initiated the Call Gapping. Basic Gap Criteria contains one of the following information elements: Information element name Status Description Called Address O,E This IE contains a string of digits. For each call attempt where the leading digits of the dialled number match this specific value, the call gapping treatment shall be applied to the call. Service O,E This IE contains a service key value. For each call attempt where the service key match this specific value, the call gapping treatment shall be applied to the call. Called Address And Service O,E This IE contains a specific string of digits and a service key value. For each call attempt where the leading digits of the dialled number and the service key of a call match these specific values, the call gapping treatment shall be applied to the call. Calling Address And Service O,E This IE contains a specific string of digits and a service key value. For each call attempt where the leading digits of the calling party number and the service key match these specific values, the call gapping treatment shall be applied to the call. Gap Indicators contains the following information elements: Information element name Status Description Duration M This IE specifies the total time interval during which call gapping for the specified gap criteria will be active. A duration of 0 indicates that gapping is to be removed. A duration of -2 indicates a network specific duration. Other values indicate the duration in seconds. Interval M This IE specifies the minimum time between calls being allowed through. An interval of 0 indicates that calls meeting the gap criteria are not to be rejected. An interval of -1 indicates that all calls meeting the gap criteria are to be rejected. Other values indicate the interval in milliseconds. Gap Treatment contains one of the following elements: Information element name Status Description Information To Send O,E This IE indicates an announcement or a tone to be sent to the calling party. At the tone or announcement, the call shall be released. Release Cause O,E If the call is to be released, this IE indicates the specific cause value to be sent in the Release IF. See ETSI ENÊ300Ê356 1Ê[40] for the coding. Information To Send contains one of the following elements: Information element name Status Description In-band Info O,E This IE specifies the in-band information to be sent. Tone O,E This IE specifies a tone to be sent to the end-user. In-band Info contains the following information elements: Information element name Status Description Message ID M This IE is described in a table below. This IE indicates the message(s) to be sent. Message Duration O This parameter indicates the maximum time in seconds that the message shall be played/repeated. ZERO indicates endless repetition. Message Id contains the following element: Information element name Status Description Elementary Message ID O This IE indicates a single announcement. 4.6.2.4 Call Information Request 4.6.2.4.1 Description This IF is used to request the gsmSSF to record specific information about a single call party and report it to the gsmSCF (with a Call Information Report IF). 4.6.2.4.2 Information Elements Information element name Status Description Requested Information Type List M This IE is described in a table below. This IE specifies a list of specific items of information which are requested. Leg ID M This IE indicates the party in the call for which the information shall be collected. Requested Information Type List contains the following information elements: Information element name Status Description Call Attempt Elapsed Time O This IE indicates that the Call Attempt Elapsed Time is requested in the Call Information Report. Call Attempt Elapsed Time is the duration between the end of the CAMEL processing initiating call setup (Connect, Continue or Continue With Argument IF) and the received answer indication from the called party side. For the Calling Party, the value of Call Attempt Elapsed Time in the Call Information Report shall be set to 0. Call Stop Time O This IE indicates that the Call Stop Time is requested in the Call Information Report. Call Stop Time is the time stamp when the connection is released. Call Connected Elapsed Time O This IE indicates that the Call Connected Elapsed Time is requested in the Call Information Report. Call Connected Elapsed Time is the duration between the received answer indication from the called party side and the release of the connection. For a Calling Party, it indicates the duration between the sending of the Initial DP IF and the release of that party. Release Cause O This IE indicates that the Release Cause for the call party is requested in the Call Information Report. 4.6.2.5 Cancel 4.6.2.5.1 Description This IF is used by the gsmSCF to request the gsmSSF to cancel all EDPs and reports. 4.6.2.5.2 Information Elements Information element name Status Description All Requests M This IE indicates that all active requests for the Event Report BCSM, Apply Charging Report and Call Information Report IFs shall be cancelled. 4.6.2.5A Collect Information 4.6.2.5A.1 Description This IF is used to instruct the gsmSSF to collect additional dialled digits from the calling party and report them to the gsmSCF. The use of this operation is only appropriate for a call which has not yet left the set-up phase. NOTE: It is advisable to avoid the use of gsmSCF-initiated user interaction while additional digits are being collected. Interaction with a Specialised Resource Function (SRF) may result in an ACM being sent to the originating node which will prevent any further dialled digits being sent. NOTE: If the gsmSCF sends CAP Connect before the dialling is complete then no further digits can be collected from the calling party. 4.6.2.5A.2 Information Elements This IF contains no information elements. 4.6.2.6 Connect 4.6.2.6.1 Description This IF is used to request the gsmSSF to perform the call processing actions to route a call to a specific destination. To do so, the gsmSSF may use destination information from the calling party and existing call set-up information depending on the information provided by the gsmSCF. The gsmSCF shall not send this IF when there is a CSA with a single call segment which includes only legÊ1. 4.6.2.6.2 Information Elements Information element name MO MF MT VT NC NP TO Description Alerting Pattern - - O O - - - This IE indicates the kind of Alerting Pattern to be applied. Calling Partys Category O O O O O O O This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). Destination Routing Address M M M M M M M This IE contains the called party number towards which the call is to be routed. The NatureOfAddress indicator may contain a national-specific value. For some national-specific NatureOfAddress indicator values the length of the digit part of the destination address may be zero. The gsmSCF may use national-specific NatureOfAddress indicator values of the gsmSSF country. Generic Number O O O O O O O This IE contains the generic number. Its used to convey the additional calling party number, which e.g. could be used to modify the calling line ID presented to the called user. Carrier O O O O O O O This IE is described in a table below. NA Originating Line Information O O O O O O O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O O O O O O O This IE identifies the chargeable number for the usage of a North American carrier. O CSI Applicable - - O O - - - This IE indicates that the O CSI, if present shall be applied on the outgoing leg. Suppress N-CSI - - - - - - O This IE indicates that N CSI, if present, shall be suppressed for the trunk originated call. Original Called Party ID O O O O O O O This IE carries the dialled digits if the call has met call forwarding on route to the gsmSSF or is forwarded by the gsmSCF. Leg To Be Connected S S S S S S S This IE indicates the leg to which the Connect IF applies. The gsmSCF shall include this IE if: - The CSA has more than one call segment, or - The CSA has a single call segment, which contains: - one leg, which is not legÊ2; or - two legs, which are not legÊ1 and legÊ2, or - more than two legs. Otherwise this IE may be present or absent as required by the service logic. This IE shall not indicate leg1. Redirecting Party ID O O O O O O O This IE indicates the directory number the call was redirected from. Redirection Information O O O O O O O This IE contains forwarding related information, such as redirecting counter. Suppression Of Announcements - - O O O O - This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Service Interaction Indicators Two O O O O O O O This IE is described in a table below. CUG Interlock Code O O O O O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Outgoing Access Indicator O O O O O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Basic OR interrogation requested O O - - O O O This IE indicates that a Basic Optimal Routeing interrogation is requested for the call. If Basic Optimal Routeing is successful, this will be reported to the gsmSCF in the Answer event report. This IE shall be ignored if the VMSC associated with the gsmSSF does not support Basic Optimal Routeing. This IE shall be ignored if it is received in a gsmSSF which is handling the MF call case in the GMSC function of the forwarding subscriber. Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M M M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M M M M This IE indicates the way the carrier was selected e.g.: - dialled; - subscribed. Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator O O O O O O O This IE is described in a table below. Backward Service Interaction Indicator O O O O - - O This IE is described in a table below. HOLD Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of HOLD by the CAMEL subscriber. CW Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of CW for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the call leg to become part of an ECT call initiated by the CAMEL subscriber. Connected number treatment indicator O O O O - - O This IE indicates the treatment of the connected number at the originating side. Non-CUG Call O O O O O O O This IE indicates that no parameters for CUG should be used for the call (i.e. the call should be a non-CUG call). Shall be absent if one or more of CUG Interlock Code and Outgoing Access Indicator is present in the IF. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O O - O This IE allows the gsmSCF to disallow the call leg to become part of a MPTY call initiated by the CAMEL subscriber. Call Diversion Treatment Indicator O O O O O - O This IE allows the gsmSCF to disallow the Call Forwarding or Call Deflection supplementary services for this call. Calling Party Restriction Indicator O O O O O O O This IE allows the gsmSCF to mark the CLI as Restricted for the call. Backward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O - O O This IE allows the gsmSCF to disallow the call leg to become part of a MPTY call initiated by the calling subscriber. Call Completion Treatment Indicator O O O O - O O This IE allows the gsmSCF to disallow a CCBS request to be made for the call. See also 3GPP TSÊ23.093Ê[26] for description. 4.6.2.7 Connect To Resource 4.6.2.7.1 Description This IF is used to connect a call from the gsmSSF to a gsmSRF. 4.6.2.7.2 Information Elements Information element name Status Description Resource Address M This IE indicates the address of the gsmSRF to which the connection shall be established. It is described in a table below. Service Interaction Indicators Two O This IE indicates whether or not a bothway through connection is required between the call segment and the calling party. When there is no calling party connected to the call segment, then the gsmSSF shall ignore this IE, if received. The handling when this IE is not present is defined in ETSI ENÊ301Ê070 1 ([41]). Call Segment ID M This IE indicates the call segment to be connected to the resource. The subsequent user interaction shall apply to all parties connected to the call segment. Resource Address contains the following information elements: Information element name Status Description IP Routing Address E This IE indicates the routeing address to set up a connection between the call segment and the gsmSRF. None E This IE indicates that the call segment shall be connected to a predefined gsmSRF. 4.6.2.8 Continue 4.6.2.8.1 Description This IF requests the gsmSSF to proceed with call processing at the DP at which it previously suspended call processing to await gsmSCF instructions. The gsmSSF completes DP processing, and continues basic call processing (i.e. proceeds to the next point in call in the BCSM) without substituting new data from the gsmSCF. The gsmSCF may send this operation only when there is a CSA with a single call segment which includes: - only legÊ1, or - only legÊ2, or - legÊ1 and legÊ2 but no other legs. 4.6.2.8.2 Information Elements This IF contains no information elements. 4.6.2.9 Continue With Argument 4.6.2.9.1 Description This IF requests the gsmSSF to continue the call processing with modified information at the DP at which it previously suspended call processing to await gsmSCF instructions or to continue call processing after a Call Party Handling IF was received. The gsmSSF completes DP processing if necessary, and continues basic call processing (i.e. proceeds to the next point in call in the BCSM) with the modified call setup information as received from the gsmSCF. This IF may also be used to continue call processing after an Initiate Call Attempt IF and Call Party Handling IF. The gsmSCF can send modified call information at DPÊCollected_Info and at DPÊAnalysed_Info, as listed in the MO and MF columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information at DPÊTermination_Attempt_Authorised, as listed in the MT and VT columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information immediately after sending an Initiate Call Attempt IF, as listed in the NC and NP columns in subclauseÊ4.6.2.9.2. The gsmSCF can send modified call information at DP Collected_Info and at DP_Analysed_Info, as listed in the TO column in subclause 4.6.2.9.2. In all other cases, Continue With Argument shall contain no other IE than Leg ID or Call Segment ID. When this IF is used to resume the processing of an Initiate Call Attempt IF, then a Leg ID shall be included and Call Segment ID shall be absent. When this IF is used to resume the processing of a Call Party Handling IF, then a Call Segment ID shall be included and Leg ID shall be absent. When this IF is used to resume processing after an EDP-R or TDP-R, then a Leg ID shall be included and Call Segment ID shall be absent. The following exception exists: if this IF is used to resume processing after an EDP R or TDP R in one of the following scenarios: - the CSA has one Call Segment only, which includes legÊ1 only; - the CSA has one Call Segment only, which includes legÊ2 only; - the CSA has one Call Segment only, which includes legÊ1 and legÊ2, but no other legs; then, the Leg ID may be present or absent, as required by the Service Logic. 4.6.2.9.2 Information Elements Information element name MO MF MT VT NC NP TO Description Alerting Pattern - - O O O - - This IE indicates the kind of Alerting Pattern to be applied. Calling Partys Category O O O O O O O This IE indicates the type of calling party (e.g., operator, pay phone, ordinary subscriber). Generic Number O O O O O O O This IE contains the generic number. It is used to convey the additional calling party number, which e.g. could be used to modify the calling line ID presented to the called user. Carrier O O O O O O O This IE is described in a table below. NA Originating Line Information O O O O O O O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O O O O O O O This IE identifies the chargeable number for the usage of a North American carrier. Suppression Of Announcements - - O O O O - This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Service Interaction Indicators Two O O O O O O O This IE is described in a table below. CUG Interlock Code O O - - O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Outgoing Access Indicator O O - - O O O See 3GPP TSÊ23.085Ê[22] for details of this IE. Basic OR Interrogation Requested O O - - O O,S O This IE indicates that a Basic Optimal Routeing interrogation is requested for the call. If Basic Optimal Routeing is successful, this will be reported to the gsmSCF in the Answer event report. This IE shall be ignored if the VMSC associated with the gsmSSF does not support Basic Optimal Routeing. This IE shall be ignored if it is received in a gsmSSF which is handling the MF call case in the GMSC function of the forwarding subscriber. For an NP call leg, this IE can only be included if the original call was an MO or NC call. Leg ID O,E O,E O,E O,E O,E O,E O,E This IE indicates the party for which call processing is to be resumed. Call Segment ID O,E O,E O,E O,E O,E O,E O,E This IE indicates the call segment for which call processing is to be resumed. Suppress O CSI - - O O - - - This IE indicates that O CSI shall be suppressed for the forwarding leg or deflecting leg. Suppress D CSI - - - - - O - This IE indicates that D CSI shall be suppressed for the new call leg. This IE can only be included if this IE is sent to the VMSC or GMSC of the CAMEL subscriber. Suppress N CSI - - - - O O O This IE indicates that N CSI shall be suppressed for the new call leg or trunk originated call. Suppress Outgoing Call Barring - - - - - O - This IE indicates that Outgoing Call Barrings for the created leg shall be suppressed. This IE can only be included if the Initiate Call Attempt IF is sent to the VMSC of the CAMEL subscriber."
"Carrier contains the following information elements: Information element name MO MF MT VT NC NP TO Description Carrier Identification Code M M M M M M M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M M M M M M M This IE indicates the way the carrier was selected, i.e.: - dialled - subscribed Service Interaction Indicators Two contains the following information elements: Information element name MO MF MT VT NC NP TO Description Forward Service Interaction Indicator O O O O O O O This IE is described in a table below. Backward Service Interaction Indicator O O O O - - O This IE is described in a table below. HOLD Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of HOLD by the CAMEL subscriber. CW Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the invocation of CW for a call to the CAMEL subscriber whilst this call is ongoing. ECT Treatment Indicator O - - O - - - This IE allows the gsmSCF to disallow the call leg to become part of an ECT call initiated by the CAMEL subscriber. Connected Number Treatment Indicator O O O O - - - This IE indicates the treatment of the connected number at the originating side. Non-CUG Call O O - - - O O This IE indicates that no parameters for CUG should be used for the call (i.e. the call should be a non-CUG call). This IE shall be absent if one or more of CUG Interlock Code and Outgoing Access Indicator are present in the IF. Forward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O O O O This IE indicates whether the call leg can become part of a MPTY call initiated by the called subscriber. Call Diversion Treatment Indicator O O O O O O O This IE indicates whether the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. Calling Party Restriction Indicator O O O O O O O This IE allows the gsmSCF to mark the CLI as Restricted for the call. Backward Service Interaction Indicator contains the following information elements: Information element name MO MF MT VT NC NP TO Description Conference Treatment Indicator O O O O - - O This IE indicates if the call leg can become part of a MPTY call initiated by the calling subscriber. Call Completion Treatment Indicator O O O O - - O This IE indicates whether a CCBS request can be made for the call. See also 3GPP TSÊ23.093Ê[26] for description. 4.6.2.10 Disconnect Forward Connection 4.6.2.10.1 Description This IF is used: - to disconnect a connection with a gsmSRF previously established with a Connect To Resource IF; - to disconnect an initiating gsmSSF from an assisting gsmSSF and its associated gsmSRF. The IF is sent to the initiating gsmSSF. 4.6.2.10.2 Information Elements This IF contains no information elements. 4.6.2.11 Disconnect Forward Connection With Argument 4.6.2.11.1 Description This IF is used in the following two cases: 1) To clear a connection to a gsmSRF: This IF is used to explicitly disconnect a connection to a resource (gsmSRF) established previously with a Connect To Resource or an Establish Temporary Connection IF. It is used for a forward disconnection from the gsmSSF. 2) To clear a connection to an assisting SSF: This IF is sent to the non-assisting SSF of a pair of SSFs involved in an assist procedure. It is used to disconnect the temporary connection between the initiating SSF and the assisting SSF. 4.6.2.11.2 Information Elements Information element name Status Description Call Segment ID M This IE indicates the call segment in the call to be disconnected from the resource or the temporary connection. 4.6.2.12 Disconnect Leg 4.6.2.12.1 Description This IF is used to request the gsmSSF to release a specific leg associated with the call at any phase. All other legs in this call are retained. If the last leg of the call segment is disconnected, then the call segment is deleted. 4.6.2.12.2 Information Elements Information element name Status Description Leg To Be Released M This IE indicates the party in the call to be released. Release Cause O This IE indicates to the gsmSSF the reason for releasing the identified party. This may be used by the MSC or GMSC for generating specific tones to the party to be released or to fill in the ""cause"" IE in the Release IF. 4.6.2.13 Establish Temporary Connection 4.6.2.13.1 Description This IF is used to create a connection between an initiating gsmSSF and an assisting gsmSSF as a part of the assist procedure. It can also be used to create a connection between a gsmSSF and a gsmSRF. 4.6.2.13.2 Information Elements Information element name Status Description Assisting SSP IP Routing Address M This IE indicates the destination address of the gsmSRF or assisting gsmSSF for the assist procedure. As a network operator option, the Assisting gsmSSF IP Routing Address may contain embedded within it, a ""Correlation ID"" and ""gsmSCF ID"", but only if ""Correlation ID"" and ""gsmSCF ID"" are not specified separately. Correlation ID O This IE is used for: - the correlation of dialogues from the initiating gsmSSF-> gsmSCF with dialogues from gsmSRF -> gsmSCF; - the correlation of dialogues from the initiating gsmSSF-> gsmSCF with dialogues from assisting gsmSSF -> gsmSCF. Carrier O This IE is described in a table below. NA Originating Line Information O This IE identifies the type of number in the Charge Number (e.g. subscriber versus PLMN operator number). Charge Number O This IE identifies the chargeable number for the usage of a North American carrier. gsmSCF ID O This IE indicates the gsmSCF identifier. Service Interaction Indicators Two O This IE indicates whether or not a bothway through connection is required between the call segment and the calling party. When there is no calling party connected to the call segment, then the gsmSSF shall ignore this IE, if received. The handling when this IE is not present is defined in ETSI ENÊ301Ê070 1Ê[41]. Call Segment ID M This IE indicates the call segment to be connected to the resource. The subsequent user interaction shall apply to all parties connected to the call segment. Original Called Party ID O This IE may be used to identify the original called party. If present, it shall be included in the ISUP IAM for the Temporary Connection. Support of this IE in the gsmSSF is an implementation option. Calling Party Number O This IE may be used to identify the calling party. If present, it shall be included in the ISUP IAM for the Temporary Connection. Support of this IE in the gsmSSF is an implementation option. Carrier contains the following information elements: Information element name Status Description Carrier Identification Code M This IE uniquely identifies a North American long distance carrier. Carrier Selection Information M This IE indicates the way the carrier was selected, i.e.: - dialled; - subscribed. 4.6.2.14 Furnish Charging Information 4.6.2.14.1 Description This IF is used to request the gsmSSF to include call related information in the CAMEL specific logical call record. The logical call record is created when the Furnish Charging Information IF is received and a logical call record for that leg does not exist. For modelling purposes the logical call record is buffered in the gsmSSF. The gsmSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then the free format data are moved to the corresponding CDR and the logical call record is deleted. The gsmSCF can send multiple concatenated Furnish Charging Information IFs per leg for completion. The total maximum of free format data is 160 octets per leg. The 160 octets may be sent in one or more FCI IFs. If there are incomplete free format data and new Furnish Charging Information IF(s) is/are received to overwrite the non-completed data, then the non-complete data are discarded and the gsmSCF can send another 160 octets per leg. The SDLs of the present document define when logical call records are completed. After the completion the gsmSCF can send another 160 octets of the free format data in one or more Furnish Charging Information IFs for the called leg. 4.6.2.14.2 Information Elements Information element name Status Description FCI Billing Charging Characteristics M This IE is described in a table below. FCI Billing Charging Characteristics contains the following information element: Information element name Status Description FCIBCCCAMEL Sequence 1 M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information elements: Information element name Status Description Free Format Data M This IE contains the free format data to be inserted in the CAMEL logical call record. Party To Charge M This IE indicates the party for whom a CAMEL logical call record will be created. Append Free Format Data O This IE indicates that the gsmSSF shall append the free format data to the logical call record. - If this IE is present and indicates ""Append"", the gsmSSF shall append the free format data received in this IF to the free format data already present in the logical call record for that leg of the call. - If this IE is absent or indicates ""Overwrite"", then the gsmSSF shall overwrite all free format data already present in the logical call record for that leg of the call, by the free format data received in this IF. If no logical call record exists for that leg of the call, then the gsmSSF shall ignore this IE. 4.6.2.15 Initiate Call Attempt 4.6.2.15.1 Description This IF is used to request the gsmSSF to create a new party in an existing call (NP), or to create a completely new call (NC). The created leg is an originating call. The address information provided by the gsmSCF is used. 4.6.2.15.2 Information Elements Information element name NC NP Description Destination Routeing Address M M This IE contains the called party number towards which the call is to be routed. For calls to an MS this can e.g. be (but shall not be limited to) the MSISDN (for routeing via a GMSC) or the MSRN received from the HLR (for routeing direct to the VMSC). Calling Party Number M - This IE identifies which number shall be regarded as the calling party for the created call. Leg To Be Created M M This IE indicates the legID to be assigned to the newly created party. The leg ID shall be 3 or higher. New Call Segment M M This IE indicates the CS ID to be assigned to the newly created call segment. Call Reference Number M - This IE may be used by the gsmSCF for inclusion in a network optional gsmSCF call record. The call reference number is included by the MSC in the call record. gsmSCF Address M - This IE contains the address of the gsmSCF which initiated the new call. This IE is required for a unique Call Reference. Suppress T CSI O O This IE indicates that T CSI shall be suppressed on the terminating leg. 4.6.2.16 Move Leg 4.6.2.16.1 Description This IF requests the gsmSSF to move a leg to CSID1. After the move the source call segment is deleted. In moving the specified leg, the conditions of the leg: the armed EDPs, the Stored e parameters, the Non-completed CAMEL logical call records, and the Call Information Report pending, are also applied for the same leg after the move. 4.6.2.16.2 Information Elements Information element name Status Description Leg ID To Move M This IE indicates the leg that shall be moved. 4.6.2.17 Play Tone 4.6.2.17.1 Description This IF is used to play a variable sequence of tones to a particular leg or call segment using the MSC's tone generator. Refer to subclauseÊ4.5.7.1.2 for a graphical representation of the variable sequence of tones. In order to avoid tone bursts being played in close succession to the same party or group of parties, the gsmSCF is responsible for careful use of this IF especially when warning tones have been scheduled using the Apply Charging IF. 4.6.4.17.2 Information Elements Information element name Status Description Leg or Call Segment M This IE is described in a table below. This IE indicates the leg or call segment. Burst List M This IE is described in a table below. This IE indicates a variable sequence of bursts. Leg or Call Segment contains the following information elements: Information element name Status Description Call Segment ID E This IE indicates the call segment to which tones shall be played. Leg ID E This IE indicates the leg to which tones shall be played. Burst List contains the following information elements: Information element name Status Description Number of bursts M This IE indicates the number of bursts to be played. There may be up to three bursts. Burst interval M This IE indicates the time interval between successive bursts. Number of tones in burst M This IE indicates the number of tones to be played in each burst. There may be up to three tones per burst. The tone is fixed to 900 Hz. Tone Duration M This IE indicates the duration of each tone in a burst. Tone Interval M This IE indicates the time interval between successive tones in a burst. 4.6.2.18 Release Call 4.6.2.18.1 Description This IF is used by the gsmSCF to tear down an existing call at any phase of the call for all parties involved in the call. 4.6.2.18.2 Information Elements Information element name Status Description Release Cause E This IE indicates the Release Cause for the call. This may be used by the MSC or GMSC for generating specific tones to the different parties in the call or to fill in the ""cause"" in the Release IF. Release Cause With Extensions E This IE indicates the Release Cause for the call. This may be used by the MSC or GMSC for generating specific tones to the different parties in the call or to fill in the ""cause"" in the Release IF. This IE may include additional network specific IE. It may be used by the gsmSCF only if the Initial DP IF or ICA Ack contained the 'Release Call Argument Extension Allowed' IE. 4.6.2.19 Request Report BCSM Event 4.6.2.19.1 Description This IF is used to request the gsmSSF to monitor for a call-related event, then send a notification back to the gsmSCF when the event is detected (see Event Report BCSM). 4.6.2.19.2 Information Elements Information element name MO MF MT VT NC NP TO Description BCSM Event M M M M M M M This IE specifies the event or events for which a report is requested. BCSM Event contains the following information elements: Information element name MO MF MT VT NC NP TO Description Event type M M M M M M M This IE specifies the type of event for which a report is requested. Leg ID C C C C C M C This IE indicates the party in the call for which the event shall be armed or disarmed. Monitor Mode M M M M M M M If this IE is ""interrupted"" then the event shall be reported as a request, if this IE is ""notify and continue"" then the event shall be reported as a notification, if this IE is ""transparent"" then the event shall not be reported. DP Specific Criteria O O O O O O O This IE is described in a table below. Automatic Rearm O O O O - - O This IE indicates that the detection point shall be automatically rearmed by the gsmSSF when it is encountered. This IE may be present only if the Event Type is O_Mid_Call, T_Mid_Call, O_Change_Of_Position, T_Change_Of_Position, O_Service_Change or T_Service_Change and the Monitor Mode is ""notify and continue"". The MF and MT cases apply for O_Service_Change or T_Service_Change DPs only. The TO case applies for O_Mid_Call and O_Service_Change DPs only. DP Specific Criteria contains the following information elements: Information element name MO MF MT VT NC NP TO Description Application Timer O O O O O O O This IE carries additional timer duration information (timer values for No_Answer event) required for arming the No_Answer EDPs in the gsmSSF. The TNRy timer (value defined between 10Êseconds and 40Êseconds) shall be shorter than the network no answer timer. Mid Call Control Info O - - O - - O This IE is described in a table below. This IE carries the criterion for the detection and reporting of the mid-call event. If this IE is absent, then mid-call triggering shall take place when the first digit has been entered by the user. Change of Position Control Info O - - O - - - This IE is described in a table below. It carries the list of criteria for the reporting of the change of position event. If the DP Specific Criteria IE is absent, then the criteria for any change of position shall be regarded as fulfilled. Number of Digits - - - - - - O This IE indicates the number of additional digits requested by the gsmSCF to be collected by the gsmSSF before the CollectedInfo event is reported, excluding the digits reported already. It excludes the end of pulsing signal (ST) Inter Digit Timeout - - - - - - O This IE carries additional timer duration information required for arming the CollectedInfo event in the gsmSSF. The IE indicates the maximum duration allowed between receipt of successive digits from the calling party. The Inter Digit timer value shall be shorter than the network inter-digit timer. The MSC/ gsmSSF shall use the network inter-digit timer duration as the default duration. If one or more CollectInformation operations are received in a call then the latest received value overwrites the previous value. If the latest CollectInformation does not include this IE then the previous value applies. NOTE If a Request Report BCSM Event information flow overwrites previous Request Report BCSM Event information flow which contained Application Timer IE for No_Answer DP, the behaviour of the gsmSSF is unpredictable. Mid Call Control Info contains the following information elements: Information element name MO MF MT VT NC NP TO Description Minimum Number Of Digits M - - M - - M This IE indicates the minimum number of digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. Maximum Number Of Digits M - - M - - M This IE indicates the maximum number of digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. If triggering takes place due to the detection of the maximum number of digits and the End of reply digit string, if present, is partially detected, then the partially detected End of reply digit string shall be included in the digit string to be reported to the gsmSCF. End of Reply Digit String O - - O - - O This IE, if present, indicates the digit string that denotes the end of the digits to be collected. If triggering takes place due to the detection of the End of reply digit string, then this string shall be included in the digit string to be reported to the gsmSCF. If the interdigit timeout expires when the Start Digit String, if present, is complete and the Minimum Number Of Digits has been detected and the End Digit String, if present, has been partially detected then triggering shall take place. The partially detected End Of Reply Digit String shall be included in the string to be reported to the gsmSCF. Cancel Digit String O - - O - - O This IE, if present, indicates the digit string that indicates that the input shall be erased and that digit collection, including the start digit string, if present, shall start afresh. Start Digit String O - - O - - O This IE, if present, indicates the digit string that denotes the start of the digits to be collected. If this IE is absent, then the first digit entered forms part of the digits to be collected. When triggering takes place, then the Start digit string shall be included in the digit string to be reported to the gsmSCF. Inter Digit Timeout M - - M - - M This IE indicates the maximum duration allowed between receipt of successive digits from the MS. For the TO case, this IE indicates the maximum duration allowed between receipt of successive digits from the calling party. Change of Position Control Info contains a list of up to 10 instances of the following information element: Information element name MO MF MT VT NC NP Description Change Of Location M - - M - - Each Change Of Location IE is one of the 6 possibilities indicated in the table below. If multiple instances of the Change Of Location IE have the same value, this is not an error. Each instance of the Change Of Location IE contains one of the following information elements: Information element name MO MF MT VT NC NP Description Cell Global ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the cell specified in this IE, i.e. handover into or out of the cell. Service Area ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the service area specified in this IE, i.e. handover into or out of the service area. Location Area ID O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs handover across the boundary of the location area specified in this IE, i.e. handover into or out of the location area. Inter-System Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-system handover. Inter-PLMN Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-PLMN handover. Inter-MSC Handover O,E - - O,E - - This IE indicates that the criteria are fulfilled if the mobile station performs inter-MSC handover. 4.6.2.20 Reset Timer 4.6.2.20.1 Description This IF is used to reset a timer. 4.6.2.20.2 Information Elements Information element name Status Description Timer Value M This IE specifies the value to which the indicated timer shall be set. Timer ID O This IE indicates which timer shall be reset. It shall be set to 'Tssf'. Call Segment ID M This IE indicates for which Call Segment in the gsmSSF the timer shall be reset. 4.6.2.21 Send Charging Information 4.6.2.21.1 Description This IF is used to send e parameters from the gsmSCF to the gsmSSF. If Charge Advice Information (CAI) is received from the gsmSCF, it shall replace the CAI which would be generated by the MSC and inhibit any further generation of CAI by the MSC. Further processing of the CAI by the MSC shall be in accordance with the Advice of Charge supplementary service. If the subscriber is not provisioned with the Advice of Charge supplementary service or if the VPLMN does not support this service, then no e parameters shall be sent to the MS and no error due to this fact shall be sent back to the gsmSCF. The IF is only used in the MO case or in the VT case. NOTE: If CAI is received from the gsmSCF after charge information has been generated by the MSC and sent to the MS, the behaviour of the service may be unpredictable or incorrect; the service designer should therefore ensure that the first set of CAI is sent to the gsmSSF before charge information is sent to the MS. 4.6.2.21.2 Information Elements Information element name MO MF MT VT NC NP Description SCI Billing Charging Characteristics M - - M - - This IE defines the Advice Of Charge related information to be provided to the Mobile Station. Leg ID M - - M - - This IE indicates the leg to which the charging information shall be sent. SCI Billing Charging Characteristics contains the following information elements: Information element name MO MF MT VT NC NP Description AoC After Answer S,E - - S,E - - This IE is described in a table below. This IE is present after an Answer event has been detected from the called party, the current connected SRF or the temporary connection. AoC Before Answer S,E - - S,E - - This IE is described in a table below. This IE is present before an Answer event has been detected from the called party, the current connected SRF or the temporary connection. AoC Before Answer contains the following information elements: Information element name MO MF MT VT NC NP Description AoC Initial M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. AoC Subsequent O - - O - - This IE is described in a table below. AoC Subsequent contains the following information elements: Information element name MO MF MT VT NC NP Description CAI Elements M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O - - O - - This IE indicates the tariff switch time until the next tariff switch applies. AoC After Answer contains the following information elements: Information element name MO MF MT VT NC NP Description CAI Elements M - - M - - This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O - - O - - This IE indicates the tariff switch time until the next tariff switch applies. 4.6.2.22 Split Leg 4.6.2.22.1 Description This IF is used to request the gsmSSF to separate a leg from CSID1 and move it to a new call segment. If CSID1 does not exist, then this IF is used to request the gsmSSF to move a leg into a newly created CSID1. In splitting the specified leg, the conditions of the leg: the armed EDPs, the Stored e parameters, the Non-completed CAMEL logical call records, and the Call Information Report pending, are also applied for the same leg after split. 4.6.2.22.2 Information Elements Information element name Status Description Leg To Be Split M This IE indicates the leg in the call to be split. New Call Segment M This IE indicates the Call Segment ID to be assigned to the new call segment. 4.6.3 Optional (Service logic dependent) gsmSCF to gsmSRF information flows 4.6.3.1 Activity Test 4.6.3.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gsmSRF. If the relationship is still in existence, then the gsmSRF will respond. If no reply is received, then the gsmSCF will assume that the gsmSRF has failed in some way and will take the appropriate action. 4.6.3.1.2 Information Elements This IF contains no information elements. 4.6.3.2 Cancel 4.6.3.2.1 Description This IF is used by the gsmSCF to request the gsmSRF to cancel a correlated previous IF. 4.6.3.2.2 Information Elements Information element name Status Description Invoke ID E This IE specifies the IF to be cancelled. This IE may be used when the Cancel IF is used in a single call segment CSA or when the Cancel IF is sent by the gsmSCF to an Intelligent Peripheral. Call Segment To Cancel E This IE may be used when the Cancel IF is used in a single call segment CSA or in a multi call segment CSA. This IE is described in a table below. This IE shall not be used when the Cancel IF is sent by the gsmSCF to an Intelligent Peripheral. Call Segment To Cancel contains the following information elements: Information element name Status Description Invoke ID M This IE specifies the IF to be cancelled. Call Segment ID M This IE specifies to which call segment the cancellation of the user interaction IF shall apply. 4.6.3.3 Play Announcement 4.6.3.3.1 Description This IF is used for inband interaction. 4.6.3.3.2 Information Elements Information element name Status Description Information To Send M This IE is described in a table below. Disconnect From IP Forbidden M This IE indicates whether or not the gsmSRF may be disconnected from the user when all information has been sent. Request Announcement Complete Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when all information has been sent. Request Announcement Started Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when the first announcement or tone starts. Call Segment ID S This IE indicates the call segment to which the user interaction shall apply. This IE shall be absent if this IF is sent by the gsmSCF to an Intelligent Peripheral. Information To Send contains the following information elements: Information element name Status Description Inband Info E This IE is described in a table below. Tone E This IE is described in a table below. Inband Info contains the following information elements: Information element name Status Description Message ID M This IE is described in a table below. Number Of Repetitions M This IE indicates the maximum number of times the message shall be sent to the end-user. Duration O This IE indicates the maximum duration time in seconds that the message shall be played/repeated. Zero indicates endless repetition. Interval O This IE indicates the time interval in seconds between two repetitions. Message ID contains the following information elements: Information element name Status Description Elementary Message ID E This IE indicates a single announcement Text E This IE indicates a text to be sent. The text shall be transformed to inband information (speech) by the gsmSRF. Elementary Message IDs E This IE indicates a sequence of announcements Variable Message E This IE indicates an announcement with one or more variable parts. Tone contains the following information elements: Information element name Status Description Tone ID M This IE indicates the tone to be sent. Duration O This IE indicates the maximum duration in seconds that the message shall be played/repeated. Zero indicates endless repetition. 4.6.3.4 Prompt And Collect User Information 4.6.3.4.1 Description This IF is used to interact with a call party in order to collect information. 4.6.3.4.2 Information Elements Information element name Status Description Collected Info M This IE is described in a table below. Information To Send O This IE is described in subclauseÊ4.6.3.3.2. This IE indicates an announcement or a tone to be sent to the end user by the gsmSRF. Disconnect From IP Forbidden M This IE indicates whether the gsmSRF may be disconnected from the user when all information has been sent. Request Announcement Started Notification M This IE indicates whether or not a Specialized Resource Report shall be sent to the gsmSCF when the first announcement or tone starts. Call Segment ID S This IE indicates the call segment to which the user interaction shall apply. This IE shall be absent if this IF is sent by the gsmSCF to an Intelligent Peripheral. Collected Info contains the following information element: Information element name Status Description Collected Digits M This IE is described in a table below. Collected Digits contains the following information elements: Information element name Status Description Minimum Number Of Digits M This IE indicates the minimum number of valid digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. Maximum Number Of Digits M This IE specifies the maximum number of valid digits to be collected. The value of this IE includes the length of the Start digit string, if present, and the length of the End of reply digit string, if present. End Of Reply Digit O This IE indicates the digit(s) used to signal the end of input. Cancel Digit O If this IE is present then the cancel digit can be entered by the user to request a possible retry. Start Digit O If this IE is present then the start digit(s) indicates the start of the valid digits to be collected. First Digit Time Out O If this IE is present then the first digit shall be received before the expiration of the first digit timer expiration. Inter Digit Time Out O If this IE is present then any subsequent valid or invalid digit shall be received by the gsmSRF before the inter digit timer expires. Error Treatment O This IE indicates what specific action shall be taken by the gsmSRF in the event of error conditions occurring. Interruptable Ann Ind O If this IE is set to TRUE (default value) then the announcement is interrupted after the first valid or invalid digit received by the gsmSRF. If this IE is present and explicitly set to FALSE then the announcement will not be interrupted after the first digit is received by the gsmSRF. Voice Information O If this IE is set to FALSE (default value) then all valid or invalid digits are entered by DTMF. If this IE is set to TRUE then the calling user is required to provide all valid or invalid information by speech. Voice Back O If this IE is set to FALSE (default value) then no voice back information is given by the gsmSRF. If this IE is set to TRUE then the valid input digits received by the gsmSRF will be announced back to the calling user immediately after the end of input is received. 4.6.4 gsmSRF to gsmSCF information flows 4.6.4.1 Activity Test ack 4.6.4.1.1 Description This IF is the response to the Activity Test. 4.6.4.1.2 Information Elements This IF contains no information elements. 4.6.4.2 Assist Request Instructions 4.6.4.2.1 Description This IF is sent to the gsmSCF by a gsmSSF which is acting as the assisting gsmSSF or by a gsmSRF. 4.6.4.2.2 Information Elements Information element name Status Description Correlation ID M This IE is used to associate the Assist Request Instructions IF from an assisting gsmSSF or by a gsmSRF with the Initial DP IF from the initiating gsmSSF. IP SSP Capabilities M This IE indicates which SRF resources are attached, available and supported within the MSC where the gsmSSF resides or the IP in which the gsmSRF resides. 4.6.4.3 Prompt And Collect User Information ack 4.6.4.3.1 Description This IF is used by the gsmSRF to indicate the result of a Prompt And Collect User Information IF. 4.6.4.3.2 Information Elements Information element name Status Description Digits Response C This IE indicates the digit sequence received from the end user. 4.6.4.4 Specialized Resource Report 4.6.4.4.1 Description This IF is used when a Specialized Resource Report was requested in a Play Announcement IF or in a Prompt and Collect User Information IF. 4.6.4.4.2 Information Elements Information element name Status Description All Announcements Complete E This IE indicates that all the announcements and tones are complete. First Announcement Started E This IE indicates that the first announcement or tone has started. 4.6.5 gsmSCF to Assisting SSF information flows 4.6.5.1 Activity Test 4.6.5.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and assistSSF. If the relationship is still in existence, then the assistSSF will respond. If no reply is received, then the gsmSCF will assume that the assistSSF has failed in some way and will take the appropriate action. 4.6.5.1.2 Information Elements This IF contains no information elements. 4.6.5.2 Cancel 4.6.5.2.1 Description This IF is used by the gsmSCF to request the assisting gsmSSF to cancel a correlated previous IF. 4.6.5.2.2 Information Elements Information element name Status Description Invoke ID M This IE specifies the IF to be cancelled. 4.6.5.3 Connect To Resource 4.6.5.3.1 Description This IF is described in subclauseÊ4.6.2.7. The following difference applies: - The Call Segment ID information element is not used. 4.6.5.4 Disconnect Forward Connection 4.6.5.4.1 Description This IF is used to disconnect a connection with a gsmSRF previously established with a Connect To Resource IF. 4.6.5.4.2 Information Elements This IF contains no information elements. 4.6.5.5 Play Announcement 4.6.5.5.1 Description This IF is described in subclauseÊ4.6.3.3. The following difference applies: - The Call Segment ID information element is not used. 4.6.5.6 Prompt And Collect User Information 4.6.5.6.1 Description This IF is described in subclauseÊ4.6.3.4."
"The following difference applies: - The Call Segment ID information element is not used. 4.6.5.7 Reset Timer 4.6.5.7.1 Description This IF is described in subclauseÊ4.6.2.20. The following difference applies: - The Call Segment ID information element is not used. 4.6.6 Assisting SSF to gsmSCF information flows 4.6.6.1 Activity Test ack 4.6.6.1.1 Description This IF is the response to the Activity Test. 4.6.6.1.2 Information Elements This IF contains no information elements. 4.6.6.2 Assist Request Instructions 4.6.6.2.1 Description This IF is described in subclauseÊ4.6.4.2. 4.6.6.3 Prompt And Collect User Information ack (received information) 4.6.6.3.1 Description This IF is described in subclauseÊ4.6.4.3. 4.6.6.4 Specialized Resource Report 4.6.6.4.1 Description This IF is described in subclauseÊ4.6.4.4. 4.6.7 HLR to VLR information flows 4.6.7.1 Delete Subscriber Data 4.6.7.1.1 Description This IF is used by an HLR to delete CAMEL subscription data from a VLR. It is specified in 3GPP TSÊ29.002Ê[34]. 4.6.7.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O,E This IE identifies that all CSIs shall be deleted from the subscriber data in the VLR. Specific CSI Withdraw O,E This IE indicates that one or more specific elements of CAMEL Subscription Info shall be deleted from the VLR. The specific elements of CAMEL Subscription Info which may be deleted are: - O CSI with TDP criteria for O CSI; - TIF CSI; - D CSI; - VT CSI with TDP criteria for VT CSI. This IE should not be present when CAMEL Subscription Info Withdraw is present. 4.6.7.2 Insert Subscriber Data 4.6.7.2.1 Description This IF is used by an HLR to update a VLR with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 4.6.7.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information elements for circuit switched call control: Information element name Status Description O CSI O This IE is described in a table below. This IE identifies the subscriber as having originating CAMEL services. D CSI O This IE is described in a table below. This IE identifies the subscriber as having originating CAMEL dialled services. VT CSI O This IE is described in a table below. This IE identifies the subscriber as having terminating CAMEL services in the VMSC. TIF CSI O See 3GPP TSÊ23.072Ê[16]. O CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.1 Service Key M This IE is described in subclauseÊ4.3.1. Default Call Handling M This IE is described in subclauseÊ4.3.1. TDP List M This IE is described in subclauseÊ4.3.1. DP Criteria O This IE is described in subclauseÊ4.3.1. CAMEL Capability Handling C This IE is described in subclauseÊ4.3.1. If this IE is absent, this indicates that CAMEL phaseÊ1 support is requested. D CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.2. Service Key M This IE is described in subclauseÊ4.3.2. Default Call Handling M This IE is described in subclauseÊ4.3.2. DP Criteria M This IE is described in subclauseÊ4.3.2. CAMEL Capability Handling M This IE is described in subclauseÊ4.3.2. The CAMEL Capability Handling shall indicate CAMEL phaseÊ3 or higher. VT CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.6. Service Key M This IE is described in subclauseÊ4.3.6. Default Call Handling M This IE is described in subclauseÊ4.3.6. TDP List M This IE is described in subclauseÊ4.3.6. DP Criteria O This IE is described in subclauseÊ4.3.6. CAMEL Capability Handling M This IE is described in subclauseÊ4.3.6. The CAMEL Capability Handling shall indicate CAMEL phaseÊ3 or higher. 4.6.7.3 Provide Subscriber Info 4.6.7.3.1 Description This IF is described in TSÊ23.018Ê[12]; it is used by the HLR to request information (any one or more of subscriber state, subscriber location, IMEI & software version and MS classmark information for the CS domain) from the VLR at any time. 4.6.7.4 Provide Roaming Number 4.6.7.4.1 Description This IF is specified in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to request a roaming number from the VLR. 4.6.7.4.2 Information Elements Provide Roaming Number contains the following CAMEL specific information elements: Information element name Status Description Suppression Of Announcements S This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. It shall be present if the HLR received it in the Send Routeing Info IF. Call Reference Number M This IE carries the Call Reference Number provided by the GMSC or the gsmSCF in the Send Routeing Info IF. GMSC Or gsmSCF Address M This IE is the E.164 address of the GMSC for an MT call or the E.164 address of the gsmSCF for a gsmSCF initiated call. Alerting Pattern S This IE indicates the kind of Alerting Pattern to be applied. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info IF. Supported CAMEL Phases in Interrogating Node S This IE indicates the CAMEL Phases supported in the GMSC or the gsmSCF. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. Offered CAMEL4 CSIs in Interrogating Node S This IE indicates the CAMEL phaseÊ4 CSIs offered in the GMSC or the gsmSCF. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. This IE is described in a table below. Suppress VT CSI S This IE indicates that VT CSI shall be suppressed for the called party. This IE shall be present if the HLR received it in the Send Routeing Info IF. OR not Supported In GMSC S This IE indicates that the VMSC should not attempt to invoke Optimal Routeing of late call forwarding. It shall be present if this IF was triggered by a Send Routeing IF for a gsmSCF initiated call. Offered CAMEL4 CSIs in Interrogating Node contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. It shall be present if the HLR received it from the GMSC or the gsmSCF in the Send Routeing Info. 4.6.8 VLR to HLR information flows 4.6.8.1 Insert Subscriber Data ack 4.6.8.1.1 Description This IF is used by the VLR to indicate to the HLR the result of the Insert Subscriber Data IF. It is specified in 3GPP TSÊ29.002Ê[34]. 4.6.8.1.2 Information Elements Insert Subscriber Data ack contains the following CAMEL specific information elements: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the VMSC/VLR. It shall be present when a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if a CSI has been included in the Insert Subscriber Data IF and the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. 4.6.8.2 Provide Subscriber Info ack 4.6.8.2.1 Description This IF is described in TSÊ23.018Ê[12]; it is used by the VLR to provide the requested information to the HLR. 4.6.8.3 Update Location 4.6.8.3.1 Description This IF is used by the VLR to provide information about supported CAMEL phases to the HLR. 4.6.8.3.2 Information Elements Update Location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which phases of CAMEL are supported. It shall be present if a CAMEL phase higher than phaseÊ1 is supported. Otherwise may be absent. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. 4.6.8.4 Restore Data 4.6.8.4.1 Description This IF is used by the VLR to provide the information about supported CAMEL phases to the HLR. 4.6.8.4.2 Information Elements Restore Data contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which phases of CAMEL are supported. It shall be present if a CAMEL phase higher than phaseÊ1 is supported. Otherwise may be absent. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI 4.6.9 HLR to GMSC information flows 4.6.9.1 Send Routeing Info ack 4.6.9.1.1 Description This IF is specified in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to transfer the requested routeing information to the GMSC. 4.6.9.1.2 Information Elements Send Routeing Info ack contains the following CAMEL specific information elements: Information element name Status Description Location Information C This IE indicates the location of the served subscriber. O CSI S O CSI is defined in subclauseÊ4.3.1. This IE identifies the subscriber as having originating CAMEL services. It shall be present if O CSI is active, and CFU or CFNRc has been invoked, or if both O CSI and T CSI are active. D CSI S D CSI is defined in subclauseÊ4.3.2. This IE identifies the subscriber as having originating CAMEL dialled services. It shall be present if D CSI is active, and CFU or CFNRc has been invoked, or if both D CSI and T CSI are active. Subscriber State C This IE indicates the state of the MS. The possible values of the IE are: - CAMEL Busy: The VLR has indicated that the MS is engaged in a transaction for a mobile originating or terminated circuit-switched call. - Network Determined Not Reachable: The HLR or VLR has indicated that the network can determine from its internal data that the MS is not reachable. - Assumed Idle: The VLR has indicated that the state of the MS is neither ""CAMEL Busy"" nor ""Network Determined Not Reachable"". - Not Provided From VLR: The VLR did not provide any information on subscriber state even though it was requested. T CSI S This IE is described in a table below. This IE identifies the subscriber as having terminating CAMEL services. It shall be present if T CSI is active and no Suppress T CSI indicator is present in the Send Routeing Info IF. Basic Service Code C This IE indicates the type of basic service, i.e. teleservice or bearer service. CUG Subscription Flag S This IE indicates if the called party has a CUG subscription. It shall be present only if the T CSI is active and included in the Send Routing Information ack IF. Supported CAMEL Phases In VMSC S This IE indicates the supported CAMEL phases of the VLR. It shall be present if known by the HLR, otherwise it shall be absent. Offered CAMEL4 CSIs In VMSC S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC. It shall be present if known by the HLR, otherwise it shall be absent. VMSC Address M This IE indicates the E.164 address of the VMSC in whose area the B subscriber is currently registered. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number C See 3GPP TSÊ23.018Ê[12]. The HLR shall include the internally stored VLR Number. Current Location Retrieved - Not applicable Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S This IE indicates the LSA identity associated with the current position of the MS. Shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. If there are multiple matches the LSA ID with the highest priority shall be sent. See 3GPP TSÊ23.073Ê[18]. E-UTRAN Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E See 3GPP TSÊ23.018Ê[12]. T CSI contains the following information elements: Information element name Status Description gsmSCF Address M This IE is described in subclauseÊ4.3.5. Service Key M This IE is described in subclauseÊ4.3.5. Default Call Handling M This IE is described in subclauseÊ4.3.5. TDP List M This IE is described in subclauseÊ4.3.5. DP Criteria S This IE is described in subclauseÊ4.3.5. The HLR shall send only the criteria associated with DPÊT_Busy or DPÊT_No_Answer, if available. CAMEL Capability Handling C This IE is described in subclauseÊ4.3.5. If this IE is absent then this indicates that CAMEL phaseÊ1 support is requested. Offered CAMEL4 CSIs In VMSC contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. It shall be present if known by the HLR, otherwise it shall be absent. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. It shall be present if known by the HLR, otherwise it shall be absent. VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI. It shall be present if known by the HLR, otherwise it shall be absent. MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. It shall be present if known by the HLR, otherwise it shall be absent. 4.6.10 GMSC to HLR information flows 4.6.10.1 Send Routeing Info 4.6.10.1.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request information from the HLR to route an MT call. 4.6.10.1.2 Information Elements Send Routeing Info contains the following CAMEL specific information elements: Information element name Status Description Alerting Pattern S This IE indicates the kind of Alerting Pattern to be applied. It shall be present if it was received from the gsmSCF or set by the gsmSSF. Suppression Of Announcement S This IE indicates that announcements or tones generated as a result of unsuccessful call setup shall be suppressed. It shall be present in the interrogation if available, i.e. when it has been received from the gsmSCF. Suppress T CSI S This IE indicates that T CSI shall be suppressed. It shall always be present in the second interrogation or if it was received from the gsmSCF due to an Initiate Call Attempt IF. Supported CAMEL Phases M This IE lists the supported CAMEL phases in the GMSC. Offered CAMEL4 CSIs M This IE indicates the CAMEL phaseÊ4 CSIs offered in the GMSC. This IE is described in a table below. Call Reference Number M This IE carries the Call Reference Number allocated for the call by the GMSC. It shall be allocated once per call and present in both first and second interrogations. GMSC Address M This IE is the E.164 address of the GMSC. Call Diversion Treatment Indicator S This IE indicates whether or not the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. It shall be present if it was received within Forward Service Interaction Indicator in Service Interaction Indicators Two from the ISUP Initial Address Message or previous CAMEL processing. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. 4.6.11 VMSC to GMSC information flows 4.6.11.1 Resume Call Handling 4.6.11.1.1 Description This IF is described in 3GPP TSÊ23.079Ê[19], it is used to request the GMSC to take over handling the call so that it can be forwarded from the GMSC. 4.6.11.1.2 Information Elements Resume Call Handling contains the following CAMEL specific information elements: Information element name Status Description O CSI S This IE indicates that CAMEL handling applies for an optimally routed late forwarded call. This IE shall be present if CAMEL handling applies; otherwise it shall be absent. Trigger criteria for DPÊCollected_Information, if present, shall be omitted from this IF. Trigger criteria for DPÊRoute_Select_Failure, if present, shall be included in this IF. D CSI S This IE indicates that CAMEL handling applies for an optimally routed late forwarded call. This IE shall be present if CAMEL handling applies; otherwise it shall be absent. 4.6.12 MSC to VLR information flows 4.6.12.1 Send Info For ICA 4.6.12.1.1 Description This IF is used to request the VLR to provide information to handle an outgoing call leg created by the gsmSCF. 4.6.12.1.2 Information Elements Information element name NP Description Called Number M This IE indicates the E.164 number of the call leg destination. IMSI M This IE is the IMSI of the served CAMEL subscriber. CUG Index C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress Preferential CUG C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress CUG Outgoing Access C For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppress Outgoing Call Barring C This IE indicates that outgoing call barrings shall be suppressed for the call leg. Suppress D CSI S This IE indicates that D CSI shall be suppressed. It shall always be present in the second interrogation. N CSI Available S This IE indicates that N CSI is available in MSC. It shall be present in the first interrogation if N CSI is available in the MSC. Non CUG Call S This IE indicates that no parameters for CUG should be used for the call. It shall be present if received from gsmSCF. CUG Interlock Code S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if received from gsmSCF. Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if received from gsmSCF. 4.6.12.2 Send Info For Incoming Call 4.6.12.2.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request the VLR to provide information to handle an incoming call. 4.6.12.2.2 Information Elements Send Info For Incoming Call contains the following CAMEL specific information elements: Information element name Status Description Suppress VT CSI S This IE indicates that VT CSI shall be suppressed. It shall never be present in the first interrogation; it shall always be present in the second interrogation. Call Diversion Treatment Indicator S This IE indicates whether or not the call can be forwarded using the Call Forwarding or Call Deflection supplementary services. It shall be present if received within the Forward Service Interaction Indicator in the Service Interaction Indicators Two from the IAM or previous CAMEL processing. 4.6.12.3 Send Info For MT Reconnected Call 4.6.12.3.1 Description This IF is used to request the VLR to provide information to handle a reconnected MT call. 4.6.12.3.2 Information Elements Information element name Required Description Called Number M E.164 number of the call destination. 4.6.12.4 Send Info For Outgoing Call 4.6.12.4.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to request the VLR to provide information to handle an outgoing call. 4.6.12.4.2 Information Elements Send Info For Outgoing Call contains the following CAMEL specific information elements: Information element name Status Description Suppress O CSI S This IE indicates that O CSI shall be suppressed. It shall always be present in the second interrogation. Suppress D CSI S This IE indicates that D CSI shall be suppressed. It shall always be present in the second interrogation. N CSI Available S This IE indicates that N CSI is available in MSC. It shall be present in the first interrogation if N CSI is available in the MSC. 4.6.12.5 Send Info For Reconnected Call 4.6.12.5.1 Description This IF is used to request the VLR to provide information to handle a reconnected MO call. 4.6.12.5.2 Information Elements Information element name Status Description Called Number M This IE indicates the E.164 number of the call destination. Bearer Service S,E This IE indicates the bearer service required for the MO call, derived from the CS bearer capability information received in the setup request from the MS. One of bearer service or teleservice shall be present. Teleservice S,E This IE indicates the teleservice required for the MO call, derived from the CS bearer capability information received in the setup request from the MS or from the emergency setup request from the MS. One of bearer service or teleservice shall be present. CUG Index S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress Preferential CUG S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress CUG Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if it was received in the setup request from the MS. Suppress O CSI S This IE indicates that O CSI shall be suppressed. It shall always be present in the second interrogation. 4.6.13 VLR to MSC information flows 4.6.13.1 Complete Call 4.6.13.1.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to instruct the MSC to continue the connection of a call. 4.6.13.1.2 Information Elements Complete Call contains the following CAMEL specific information elements: Information element name MO MF MT VT NC NP Description O CSI S - - - - - This IE indicates that CAMEL handling applies for an MO call. It shall be present in the response to the first interrogation for an MO call if CAMEL handling applies; otherwise it shall be absent. It shall be absent from the response to the second interrogation for an MO call. D CSI C - - - - C This IE identifies the subscriber as having originating CAMEL dialled services. Call Reference Number - - - M - - This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address - - - M - - This IE is the E.164 address of the GMSC. 4.6.13.2 Continue CAMEL Handling 4.6.13.2.1 Description This IF is used to instruct the MSC to continue the CAMEL specific handling. 4.6.13.2.2 Information Elements Information element name Status Description VT CSI M This IE identifies the subscriber as having terminating CAMEL services in the VMSC. IMSI M This IE contains the IMSI of the B subscriber. MSISDN S This IE contains the E.164 number of the B subscriber. It will be used to create the redirecting number presented to the C subscriber. It shall be present if the call is to be forwarded or if it has been provided by the HLR in the Provide Roaming Number IF, otherwise it shall be absent. CUG Interlock S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if the VLR has determined that the forwarded call is to be treated as a CUG call in accordance with the rules in 3GPP TSÊ23.085Ê[22], otherwise it shall be absent. CUG Outgoing Access S For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. It shall be present if the VLR has determined that the forwarded call is to be treated as a CUG call with outgoing access in accordance with the rules in 3GPP TSÊ23.085Ê[22], otherwise it shall be absent. Location Information S This IE contains the information to define the location of the MS: see definition in 3GPP TSÊ23.018Ê[12]. It shall be present if location information was requested and is available; otherwise it shall be absent. GMSC-Address M This IE is the E.164 address of the GMSC which was received in the Provide Roaming Number. Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. ExtBasic Service Code M This IE indicates the type of basic service, i.e. teleservice or bearer service. Subscriber State M This IE indicates the status of the MS. The states are: - CAMELBusy: The MS is engaged on a transaction for a mobile originating or terminated circuit-switched call. - NetworkDeterminedNotReachable: The network can determine from its internal data that the MS is not reachable. - AssumedIdle: The state of the MS is neither ""CAMELBusy"" nor ""NetworkDeterminedNotReachable"". 4.6.13.3 Process Call Waiting 4.6.13.3.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to instruct the MSC to continue the connection of a waiting call. 4.6.13.3.2 Information Elements Process Call Waiting contains the following CAMEL specific information elements: Information element name Status Description Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address M This IE is the E.164 address of the GMSC. 4.6.13.4 Send Info For ICA negative response 4.6.13.4.1 Description This IF is used to indicate that the outgoing call leg for which the MSC requested subscription information shall not be connected. 4.6.13.4.2 Information Elements The negative response information elements can take the following values: - Bearer service not provisioned; - Call barred (Operator determined barring); - Call barred (Supplementary service barring); - CUG reject (Inconsistent access information - index incompatible with basic service); - CUG reject (Inconsistent access information - no CUG selected); - CUG reject (Outgoing calls barred within the CUG); - CUG reject (Unknown CUG index); - Teleservice not provisioned. 4.6.13.5 Send Info For Incoming Call ack 4.6.13.5.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to indicate that the incoming call for which the MSC requested subscription information shall be forwarded. 4.6.13.5.1 Information Elements Send Info For Incoming Call ack contains the following CAMEL specific information elements: Information element name Status Description O CSI S This IE indicates that originating CAMEL service handling applies for a forwarded call. It shall be present if originating CAMEL service handling applies; otherwise it shall be absent. D CSI S This IE indicates that originating CAMEL dialled service handling applies for a forwarded call. It shall be present if originating CAMEL dialled service handling applies; otherwise it shall be absent. Suppression Of Announcement S This IE indicates that announcements or tones generated when the call is forwarded shall be suppressed. It shall be present if it was received in the Provide Roaming Number for this call. Call Reference Number M This IE carries the Call Reference Number provided by the HLR in the Provide Roaming Number IF. GMSC Address M This IE is the E.164 address of the GMSC. Supported CAMEL Phases S This IE lists the supported CAMEL phases in the GMSC. It shall be present if the VLR received it from the HLR in the Provide Roaming Number. 4.6.13.6 Send Info For Incoming Call negative response 4.6.13.6.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used to indicate that the incoming call for which the MSC requested subscription information shall not be connected. 4.6.13.6.2 Information Elements Send Info For Incoming Call negative response contains the following CAMEL specific information element which may be attached as an IE to any of the negative response values defined in 3GPP TSÊ23.018Ê[12]: Information element name Status Description Suppression Of Announcement S This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. It shall be present if it was received in the Provide Roaming Number for this call. 4.6.13.7 Send Info For MT Reconnected Call ack 4.6.13.7.1 Description This IF is used to instruct the MSC to continue the connection of a reconnected MT call. 4.6.13.7.2 Information Elements Information element name Required Description O CSI S This IE indicates that originating CAMEL service handling applies for the reconnected call. It shall be present if originating CAMEL service handling applies; otherwise it shall be absent. D CSI S This IE indicates that originating CAMEL dialled service handling applies for the reconnected call. It shall be present if originating CAMEL dialled service handling applies; otherwise it shall be absent. 4.6.13.8 Send Info For MT Reconnected Call negative response 4.6.13.8.1 Description This IF is used to indicate that the reconnected MT call for which the MSC requested subscription information shall not be connected. 4.6.13.8.2 Information Elements The negative response information element can take the following value: - CUG reject 4.6.13.9 Send Info For Reconnected Call ack 4.6.13.9.1 Description This IF is used to instruct the MSC to continue the connection of a reconnected MO call. 4.6.13.9.2 Information Elements Send Info For Reconnected Call ack does not contain any information elements. 4.6.13.10 Send Info For Reconnected Call negative response 4.6.13.10.1 Description This IF is used to indicate that the reconnected MO call for which the MSC requested subscription information shall not be connected. 4.6.13.10.2 Information Elements The negative response information element can take the following value: - Call barred (Operator determined barring); - Call barred (Supplementary service barring). 4.6.14 Internal MSC information flows 4.6.14.1 Perform Call Forwarding ack 4.6.14.1.1 Description This IF is defined in 3GPP TSÊ23.018Ê[12]; it is used to inform the MSC that Call Forwarding is taking place. 4.6.14.1.2 Information Elements Perform Call Forwarding ack is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Forwarded-to Number M If the Forwarded-to Number is not available due to CAMEL handling (a Disconnect Leg IF has been received for Leg 2), then the MSC shall populate this parameter with a dummy number. 4.6.15 gsmSCF to HLR information flows 4.6.15.1 Send Routeing Info 4.6.15.1.1 Description This IF is defined in 3GPP TSÊ23.018Ê[12] and subclauseÊ4.6.10.1; it is used to request information from the HLR to route a gsmSCF initiated call. Refer to 3GPP TSÊ29.007Ê[35] for the usage of ISDN BC, ISDN LLC, ISDN HLC and MSISDN for the selection of the PLMN Basic Service. 4.6.15.1.2 Information Elements Send Routeing Info from the gsmSCF contains the following information elements: Information element name Status Description MSISDN M This IE indicates the MSISDN of the called subscriber. Alerting Pattern O This IE indicates the kind of Alerting Pattern to be applied. CUG Interlock O For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. CUG Outgoing Access O For the definition of this IE, see 3GPP TSÊ23.085Ê[22]. Suppression Of Announcement O This IE indicates that announcements or tones generated as a result of unsuccessful call establishment shall be suppressed. Suppress T CSI M This IE indicates that CAMEL subscription information should not be returned in the first Send Routeing Info ack (to avoid the need for a second interrogation). Supported CAMEL Phases M This IE indicates the CAMEL Phases supported by the gsmSCF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered by the gsmSCF. This IE shall be present when the Supported CAMEL Phases IE indicates support of CAMEL PhaseÊ4. This IE is described in a table below. Call Reference Number M This IE carries the Call Reference Number allocated for the call by the gsmSCF. GMSC Or gsmSCF Address M This IE is the E.164 address of the gsmSCF. Call Diversion Treatment Indicator O This IE indicates whether or not the call is allowed to be forwarded on behalf of the called party using the Call Forwarding supplementary service. Pre-paging Supported S This IE shall be present if the gsmSCF supports pre-paging, otherwise it shall be absent. Interrogation Type M This IE shall contain the value ""Basic Call"". Long FTN Supported O This IE indicates that the gsmSCF supports Long Forwarded to Numbers. gsmSCF Initiated Call M This IE indicates that the IF was originated by a gsmSCF. Suppress Incoming Call Barring O This IE indicates that Incoming Call Barrings shall be suppressed for the called party. Suppress VT CSI O This IE indicates that VT CSI shall be suppressed. ISDN BC O ISDN bearer capability. See 3GPP TSÊ23.018Ê[12]. ISDN LLC O ISDN lower layer compatibility. See 3GPP TSÊ23.018Ê[12]. ISDN HLC O ISDN higher layer compatibility. See 3GPP TSÊ23.018Ê[12]. Suppress MT SS O This IE indicates the MT supplementary services that shall be suppressed for the called party. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI. D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI. T CSI S This IE indicates the offer of CAMEL phaseÊ4 T CSI. 4.6.16 HLR to gsmSCF information flows 4.6.16.1 Send Routeing Info ack 4.6.16.1.1 Description This IF is described in subclauseÊ4.6.9.1; it is used by the HLR to transfer the requested routeing information to the gsmSCF. 4.6.16.2 Send Routeing Info negative response 4.6.16.2.1 Description This IF is described in 3GPP TSÊ23.018Ê[12]; it is used by the HLR to indicate that the routeing information is not available. 4.7 Interaction with supplementary services When the gsmSCF initiates a call to a subscriber, the gsmSCF can indicate to the HLR the MT supplementary services that shall be suppressed for this call. 4.7.1 Line identification For a call subject to CAMEL control, the gsmSCF shall have the option to send the Calling Party Restriction Indicator to the gsmSSF. This information element will be sent to the MSC and shall indicate whether the CLI Presentation Indicator present in the Calling Party Number shall be set by CAMEL action to Restricted. 4.7.2 Call forwarding services 4.7.2.1 Registration of Call Forwarding The functional behaviour for the registration of the Call Forwarding supplementary service is defined in 3GPP TSÊ23.082Ê[20]. The procedure specific to CAMEL is defined in this subclause: - CAMEL_Check_CF_Interaction. Figure 4.120-1: Procedure CAMEL_Check_CF_Interaction (sheet 1) 4.7.2.2 Invocation of Call Forwarding The functional behaviour for the invocation of the Call Forwarding supplementary service is defined in 3GPP TSÊ23.018Ê[12] and 3GPP TSÊ23.082Ê[20]. The following additional requirements apply. When Call Forwarding is invoked for a CAMEL subscriber with O CSI, the gsmSSF shall send the FTN to the gsmSCF in the format in which it was received from the HLR. When Call Forwarding is invoked for a CAMEL subscriber with D CSI or if an N CSI is present in the forwarding MSC, then the FTN shall be treated as defined in subclauseÊ4.2.1.2.2. If the Service Interaction Indicators Two parameter was included in the Initial Address Message, the Continue With Argument information flow or the Connect message, the appropriate indicator shall be applied for the forwarded call. An HLR shall not send an FTN which is not in international format to a GMSC which does not support CAMEL phaseÊ2, i.e. if the HLR is handling a request from a GMSC for routeing information and the forwarded-to number is registered in a format other than international, the service logic in the HLR shall behave as if the call forwarding is provisioned but not registered. 4.7.2.3 Invocation of Call Deflection The functional behaviour for the invocation of the Call Deflection supplementary service is defined in 3GPP TSÊ23.018Ê[12] and 3GPP TSÊ23.072Ê[16]. The following additional requirements apply. When Call Deflection is invoked by a CAMEL subscriber with O CSI, the gsmSSF shall send the DTN to the gsmSCF in the format in which it was received from the MS. When Call Deflection is invoked by a CAMEL subscriber with D CSI or if a N CSI is present in the VMSC, then the DTN shall be treated as defined in subclauseÊ4.2.1.2.2. If the Service Interaction Indicators Two parameter was included in the Initial Address Message, the Continue With Argument information flow or the Connect information flow, the appropriate indicator shall be applied for the deflected call. 4.7.3 Call Barring services When a CAMEL subscriber with O CSI and TIF CSI attempts to activate a conditional call barring service (BOIC,BOIC-exHC), the HLR shall not check the interactions with call forwarding."
"When the gsmSCF initiates a call to a subscriber, the gsmSCF can indicate to the HLR that incoming call barrings shall be suppressed for this call. When the gsmSCF creates an additional call leg in an existing call, the gsmSCF can indicate to the VLR (via the gsmSSF and MSC) that outgoing call barrings shall be suppressed for this call leg. 4.7.4 Closed User Group For a CUG subscriber with CAMEL services: - The HLR shall store (and transfer to the VLR) the necessary subscriber data to ensure that the served subscriber is not unnecessarily prevented by CUG constraints from originating calls. - The HLR shall store the necessary subscriber data to ensure that the served subscriber is not unnecessarily prevented by CUG constraints from receiving calls. For an MO, MF or TO call, the CUG information for that call shall be sent to the gsmSCF in the Initial DP information flow. If the gsmSCF returns a Continue information flow, the call shall continue with the original CUG information unchanged. If the gsmSCF returns a Connect or Continue With Argument information flow, the CUG handling in table 4.7 applies. Table 4.7: CUG handling on receipt of Connect or Continue With Argument for an MO, MF or TO call CUG parameters in information flow Handling Non-CUG call (note 1) Remove CUG information for the call and continue as a non-CUG call CUG information (note 2) Call shall continue with modified CUG information No CUG information Call shall continue with original CUG information NOTE 1: Received in Service Interaction Indicators Two IE. NOTE 2: CUG information consists of at least one of CUG Interlock Code and Outgoing Access Indicator. For an MT call which is to be routed to the terminating subscriber, the CUG information shall be extracted from the Send Routeing Information ack and sent to the gsmSCF in the Initial DP, but the gsmSCF shall not have the ability to change the CUG information for the call. For an VT call which is to be routed to the terminating subscriber, the CUG information shall be extracted from the incoming ISUP IAM and sent to the gsmSCF in the Initial DP, but the gsmSCF shall not have the ability to change the CUG information for the call. For an MT or VT call which is subject to CAMEL forwarding, the gsmSCF shall return a Connect information flow and the CUG handling in table 4.7 applies. 5 USSD to/from gsmSCF 5.1 Architecture 5.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support CAMEL handling of USSD to/from gsmSCF. The functional model of USSD in an HLR that supports CAMEL is shown in figureÊ5.1. The phaseÊ2 USSD handler is defined in 3GPP TSÊ23.090Ê[24]. PhaseÊ1 USSD information flows may be relayed from the HLR to the gsmSCF. CAMEL introduces a ""CAMEL USSD application"" which is invoked by the USSD handler. The CAMEL USSD functional entities and application behaviour is specified in this subclause. Figure 5.1: Handling of USSD to and from a CAMEL subscriber HLR: The HLR stores for subscribers requiring CAMEL support the information relevant to the current subscription regarding U CSI. The UG CSI is stored as global data applicable to all subscribers. The U CSI and the UG CSI are stored in the HLR only. gsmSCF: see subclauseÊ3.1. 5.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 5.1.2.1 gsmSCF - HLR interface This interface is used for USSD information flows, both for gsmSCF-initiated dialogues and MS-initiated dialogues (relayed via HLR). It is a network operator option whether to support or not USSD information flows on this interface. 5.2 Description of CAMEL Subscriber Data 5.2.1 USSD CAMEL Subscription Information (U CSI) The subscription information specified in this subclause is for information only. This subclause defines the contents of the USSD CAMEL Subscription Information (U CSI). The U CSI consists of a list of pairs of the following two parameters. 5.2.1.1 Service Code Service code for a specific application in a gsmSCF which interacts with the user by USSD. 5.2.1.2 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber and a particular service code. The address shall be an E.164 number to be used for routeing. 5.3 Content of the USSD General CAMEL Service Information (UG CSI) The service information specified in this subclause is for information only. This subclause defines the contents of the USSD General CAMEL Service Information (UG CSI). The allocation of the UG CSI is independent from a particular subscriber. The UG CSI consists of a list of pairs of the following two parameters. 5.3.1 Service Code Service code for a specific application in a gsmSCF which interacts with the user by USSD. 5.3.2 gsmSCF address Address to be used to access the gsmSCF for a particular service code. The address shall be an E.164 number to be used for routeing. 5.4 Procedures 5.4.1 MS Initiated USSD For the behaviour of the USSD handler in HLR when receiving a MS initiated USSD see 3GPP TSÊ23.090Ê[24]. When the USSD handler has determined that the service code present in the received USSD does not indicate that an USSD application in the HLR shall be invoked it shall route the USSD to the USSD application specific for CAMEL, i.e. the CAMEL USSD application. The procedure at the CAMEL USSD application at the HLR is implementation dependent. The following text describes a recommended procedure. The CAMEL USSD application shall check the U CSI data assigned to the specific subscriber. If the service code is present in the U CSI the USSD is routed to the gsmSCF given by the gsmSCF address stored against the service code in the U CSI. If the service code is not present in the U CSI (or the subscriber does not have U CSI defined) then the CAMEL USSD application shall check the UG CSI data assigned to the HLR. If the service code is present in the UG CSI then the USSD is routed to the gsmSCF given by the gsmSCF address stored against the service code in the UG CSI. If the service code is not present in U CSI or UG CSI an error (unknown application) is returned to the USSD handler. 5.4.2 gsmSCF Initiated USSD The HLR may at any time receive a USSD information flow from the gsmSCF. If the subscriber can be contacted, the HLR shall set up a transaction to the VLR and forward the information flow unchanged. Any further information exchange between the gsmSCF and MSC shall be transparent to the VLR and the HLR. When one transaction is released, the HLR shall release the other. If an error is received from the MSC, the VLR shall release the transaction to the HLR and the HLR shall release the transaction to the gsmSCF. 5.5 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for USSD handling. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The HLR shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.002Ê[34]. 5.5.1 gsmSCF to HLR information flows 5.5.1.1 Unstructured SS Request 5.5.1.1.1 Description This IF is used for the gsmSCF to request data from the MS via the HLR. 5.5.1.1.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the MS. Data Coding Scheme M This IE indicates the characteristics of the USSD string. IMSI S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. MSISDN S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. Alerting Pattern O This IE indicates an alerting pattern to be sent to the MS. 5.5.1.2 Unstructured SS Notify 5.5.1.2.1 Description This IF is used for the gsmSCF to send data to the MS via the HLR. 5.5.1.2.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the MS. Data Coding Scheme M This IE indicates the characteristics of the USSD string. IMSI S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. MSISDN S,E This IE identifies the subscriber for which the information is requested. It shall be present if this IF is the first IF in a USSD dialogue, otherwise it shall be absent. Alerting Pattern O This IE indicates an alerting pattern to be sent to the MS. 5.5.1.3 Process Unstructured SS Data ack 5.5.1.3.1 Description This IF is used for the gsmSCF to send the response to the MS via the HLR for the MS initiated IF. 5.5.1.3.2 Information Elements The following information element is required: Information element name Status Description SS User Data C This IE contains the string that will be sent to the MS. 5.5.1.4 Process Unstructured SS Request ack 5.5.1.4.1 Description This IF is used for the gsmSCF to send the response to the MS via the HLR for the MS initiated IF. 5.5.1.4.2 Information Elements Information element name Status Description USSD String S This IE contains the string that will be sent to the MS. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. Data Coding Scheme S This IE indicates the characteristics of the USSD string. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. 5.5.2 HLR to gsmSCF information flows 5.5.2.1 Unstructured SS Request ack 5.5.2.1.1 Description This IF is used for the MS to send to the gsmSCF via the HLR for the gsmSCF initiated IF. 5.5.2.1.2 Information Elements Information element name Status Description USSD String C This IE contains the string that will be sent to the gsmSCF. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. Data Coding Scheme C This IE indicates the characteristics of the USSD string. It shall be present if the Data Coding Scheme is present; otherwise it shall be absent. 5.5.2.2 Unstructured SS Notify ack 5.5.2.2.1 Description This IF is used for the MS to via the HLR acknowledge to the gsmSCF that the notification was received. 5.5.2.2.2 Information Elements This IE contains no information element. 5.5.2.3 Process Unstructured SS Data 5.5.2.3.1 Description This IF is used for the MS to request data from gsmSCF via the HLR. 5.5.2.3.2 Information Elements Information element name Status Description SS User Data M This IE contains the string that was received from the MS. 5.5.2.4 Process Unstructured SS Request 5.5.2.4.1 Description This IF is used for the MS to request data from the gsmSCF via the HLR. 5.5.2.4.2 Information Elements Information element name Status Description USSD String M This IE contains the string that will be sent to the gsmSCF, including the Service Code. Data Coding Scheme M This IE indicates the characteristics of the USSD string IMSI M This IE identifies the subscriber. MSISDN S This IE contains the basic MSISDN of the subscriber who has requested the USSD IF. This IE is used as an operator option. Originating Entity Number M This IE identifies the functional entity initiating the information flow. In this case, this shall be the address of the HLR. 5.5.2.5 Begin Subscriber Activity 5.5.2.5.1 Description This IF is used by the HLR to start subscriber activity towards the gsmSCF for USSD purposes. 5.5.2.5.2 Information Elements Information element name Status Description IMSI M This IE identifies the subscriber. Originating Entity Number M This IE identifies the functional entity initiating the subscriber activity. In this case, this shall be the address of the HLR. 6 GPRS interworking 6.1 Architecture 6.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support GPRS interworking for CAMEL. FigureÊ6.1 shows the functional entities involved in a GPRS session requiring CAMEL support. The architecture is applicable to the third phase of CAMEL or higher. Figure 6.1: Functional architecture for support of CAMEL HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription GPRS CSI. SGSN: When processing GPRS Attach requests or Inter-SGSN Routeing Area Updates for subscribers requiring CAMEL support, the SGSN receives a GPRS CSI from the HLR, indicating the SGSN to request instructions from the gprsSSF. The SGSN monitors on request the GPRS events and informs the gprsSSF of these events during processing, enabling the gprsSSF to control the execution of the GPRS session or individual PDP contexts in the SGSN. gprsSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. 6.1.2 Interfaces defined for CAMEL 6.1.2.1 SGSN - gprsSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 6.1.2.2 gprsSSF - gsmSCF interface This interface is used by the gsmSCF to control a GPRS session or individual PDP Context in a certain gprsSSF. GPRS dialogues between the gprsSSF and the gsmSCF on this interface are opened as a result of the gprsSSF sending a request for instructions to the gsmSCF. A GPRS dialogue is composed of a sequence of TC dialogues linked together by the same reference. The GPRS dialogue handler allows the TC dialogue handling. 6.1.2.3 HLR - SGSN interface This interface is used to send CAMEL related subscriber data to a visited GPRS network, e.g. GPRS CSI. 6.2 Detection Points (DPs) 6.2.1 Definition and description GPRS events may be made visible to the gsmSCF. The DPs are the points in association at which these events are detected. The DPs for GPRS Session and PDP Context are described in subclauseÊ6.4.2 and subclauseÊ6.4.3. A DP can be armed in order to notify the gsmSCF that the GPRS event was encountered, and to allow the gsmSCF to influence subsequent handling of the GPRS Session, or the PDP Context. If the DP is not armed, the processing entity continues the processing without gsmSCF involvement at this DP. Three different types of DPs are identified: - Trigger Detection Point-Request (TDP R): This detection point is statically armed and may initiate a CAMEL control relationship. This CAMEL control relationship is within a new GPRS dialogue. When the GPRS event is encountered and reported, processing is suspended. - Event Detection Point- Request (EDP R): This detection point is dynamically armed within the context of a CAMEL control relationship. When the GPRS event is encountered, and reported, processing is suspended and the gprsSSF waits for instructions from the gsmSCF. - Event Detection Point-Notification (EDP N): This detection point is dynamically armed within the context of a CAMEL control relationship. When the GPRS event is encountered and reported, processing is not suspended. Arming/disarming mechanism: A DP may be statically armed or dynamically armed. The following arming rules apply: - DPs for GPRS Session and PDP Context are statically armed as a result of the GPRS CSI analysis in the SGSN. - DPs may be dynamically armed by the gsmSCF within the context of a CAMEL control relationship. In scenarioÊ1 which is described in the subclauseÊ6.4.4.1, PDP context related DPs may be armed as generic DP or as non-generic DP. The following disarming rules apply: - A statically armed DP is disarmed when the GPRS CSI is withdrawn in the HLR. Only TDP Rs can be disarmed using this mechanism. - If the GPRS Session is released, then all EDPs related to the GPRS Session are disarmed. - If a PDP context is released, then all non-generically armed EDPs related to that PDP context are disarmed. - If a non-generically armed EDP is met, then EDPs for the GPRS Session or that PDP Context are disarmed, in accordance with the implicit disarming rule (see subclauseÊ6.4.6). - Armed EDPs may be explicitly disarmed by the gsmSCF by means of the Request Report BCSM Event information flow. 6.2.2 Relationship, DP processing rules and GPRS dialogue A relationship between the State Models (in the gprsSSF) and the gsmSCF for the purpose of operator specific service processing is considered to be a CAMEL relationship. There are two types of CAMEL relationships: monitor relationship and control relationship. - A CAMEL control relationship: the gsmSCF is able to influence the GPRS Session/PDP Context via the relationship for the given state model. - A CAMEL monitor relationship: the gsmSCF is not able to influence the GPRS Session/PDP Context via the relationship for the given state model. A control relationship persists as long as there is one or more EDP R armed for this instance of the state model, or if the gprsSSF is in the state Waiting For Instruction for this instance of state model. A control relationship changes to a monitor relationship if the conditions for a control relationship are no longer fulfilled and one or more EDP N is armed or one or more Apply Charging Report GPRS is outstanding for this instance of the state model. If no EDP Ns are armed and no Apply Charging Reports GPRS are outstanding for this instance of the state model, the relationship terminates. A GPRS dialogue exists between gprsSSF and gsmSCF if at least one of the following conditions is fulfilled: - There is at least one EDP armed, - At least one report is pending, - gprsSSF is in state Waiting_For_Instructions. 6.3 Description of CAMEL Subscriber Data 6.3.1 GPRS CAMEL Subscription Information (GPRS CSI) This subclause defines the contents of the GPRS CAMEL Subscription Information. 6.3.1.1 gsmSCF Address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 6.3.1.2 Service Key The Service Key identifies to the gsmSCF the service logic that shall apply. 6.3.1.3 Default GPRS Handling The Default GPRS Handling indicates whether the GPRS session or PDP context shall be released or continued as requested in case of error in the gprsSSF to gsmSCF dialogue. 6.3.1.4 TDP List The TDP List indicates on which detection point triggering shall take place. 6.3.1.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. 6.3.1.6 CSI state The CSI state indicates whether the GPRS CSI is active or not. 6.3.1.7 Notification flag The notification flag indicates whether the change of the GPRS CSI shall trigger Notification on Change of Subscriber Data or not. 6.3.2 gsmSCF address list for CSI The gsmSCF address list contains a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 6.4 Description of CAMEL State Models GPRS can support multiple PDP contexts simultaneously for an attached subscriber, requiring the behaviour of a GPRS session to be modelled by two state models, one for the attach/detach procedures (GPRS Attach/Detach State Model) and the other for modelling individual PDP Contexts (GPRS PDP Context State Model). 6.4.1 General Handling The GPRS State Model is used to describe the actions in an SGSN during processing of a GPRS session or PDP Contexts. The GPRS State Model identifies the points in basic GPRS processing when Operator Specific Service (OSS) logic instances (accessed through the gsmSCF) are permitted to interact with basic GPRS control capabilities. FigureÊ6.2shows the components that have been identified to describe a GPRS State Model. Figure 6.2: GPRS State Model Components 6.4.2 GPRS Attach/Detach State Model The GPRS Attach/Detach State Model is used to model the behaviour of the GPRS attach/detach procedures. When encountering a DP the Attach/Detach State Model processing is suspended at the DP and the SGSN indicates this to the gprsSSF which determines what action, if any, shall be taken in case the DP is armed. Figure 6.3: GPRS Attach/Detach State Model Table 6.1: Description of GPRS Attach/Detach DPs in the SGSN CAMEL Detection Point DP Type Description DP Attach TDP R A request to attach is received. DP Change of Position GPRS Session TDP R1), EDP N Routeing Area Update is accepted. DP Detach EDP N, EDP R A detach request is received either from the MS, the SGSN or a 'Cancel Location' received from HLR or Inter SGSN Routeing update occurred in the old SGSN. Note 1: Change of Position GPRS Session is reported as TDP R in the case of Inter SGSN Routeing Area Update (provided that this DP is statically armed in GPRS CSI). Change of Position GPRS Session is reported as EDP N in the case of Intra SGSN Routeing Area Update (provided that this DP is dynamically armed by the Service Logic). 6.4.2.1 Description of the Attach/Detach model (PIAs) This subclause describes the model for the attach and detach a GPRS session in the SGSN. For each PIA a description can be found of the entry events, actions and exit events. 6.4.2.1.1 Detached Entry events: - Detach (user or network initiated) and clearing of a previous GPRS session. - Processing of exceptional conditions. Actions: - Interface is idled. - Attach request is received from MS containing the IMSI/P-TMSI and the type of attach requested and, the identity of the MS is established (IMSI) (DP Attach), or Inter-SGSN Routeing Area Update Request is accepted (DP Change of Position GPRS Session). - Information being analyzed, e.g. GPRS CSI is analyzed. Exit events: - GPRS CSI is analyzed (DP Attach or DP Change of Position GPRS Session). 6.4.2.1.2 Attached Entry events: - GPRS CSI is analyzed (DP Attach). Actions: - MM contexts are established at the MS and the SGSN. Exit events: - A GPRS Detach request is received from the MS or from the network (DP Detach). - Intra-SGSN Routeing Area Update is accepted (DP Change of Position GPRS Session). - An exception is encountered. The GPRS Attach/Detach State Model shall only have one or more GPRS PDP Context State Models associated with it when in the Attached state. A GPRS PDP Context State Model cannot exist without its associated GPRS Attach/Detach State Model being in the Attached state. Closure of the GPRS Attach/Detach State Model via a detach will result in the idling of all associated GPRS PDP Context State Models and the release of the associated GPRS PDP Contexts. It shall not be necessary to trigger a relationship from the GPRS Attach/Detach State Model to the gsmSCF in order for triggering to occur in an associated GPRS PDP Context State Model. However, in this latter case a GPRS Attach/Detach State Model shall still exist at the SGSN. This is so that CSE-initiated detach events sent within a given GPRS PDP Context relationship shall result in the GPRS Attach/Detach State Model transiting to the Detached state. As noted above, in this state no PDP Contexts can exist and so all associated GPRS PDP Context State Models will transit to state Idle. 6.4.3 GPRS PDP Context State Model The GPRS PDP Context State Model is used to model the behaviour for the GPRS PDP Context procedures. There is one PDP Context State Model per GPRS PDP context. When encountering a DP the PDP Context State Model processing is suspended at the DP and the SGSN indicates this to the gprsSSF which determines what action, if any, shall be taken in case the DP is armed. Figure 6.4: GPRS PDP Context State Model Table 6.2: Description of GPRS PDP Context DPs in the SGSN CAMEL Detection Point DP Type Description DP PDP Context Establishment TDP R1), EDP R, EDP N Activate PDP Context request is received from the MS. DP PDP Context Establishment Acknowledgement TDP R2), EDP R, EDP N Create PDP Context response is received from the GGSN. DP PDP Context Disconnection EDP N, EDP R Deactivate PDP Context Request is received from the MS, Delete PDP Context request is received from the GGSN. Inter SGSN Routeing update occurred in old SGSN. DP Change of Position Context TDP R3), EDP N, EDP R Routeing Area Update is accepted. NOTE 1: The PDP Context Establishment shall be reported as TDP R (provided that this DP is statically armed in GPRS CSI) if there is no relationship with the gsmSCF. If there is a relationship with the gsmSCF it shall be reported as EDP R or EDP N if armed so. NOTE 2: The PDP Context Establishment Acknowledgement shall be reported as TDP R (provided that this DP is statically armed in GPRS CSI) if there is no relationship with gsmSCF. If there is a relationship with the gsmSCF, it shall be reported as EDP R or EDP N if armed so. NOTE 3: Change of Position Context is reported as TDP-R in the case of Inter-SGSN Routeing Area Update (provided that this DP is statically armed in GPRS CSI) if there is no relationship with the gsmSCF. Change of Position Context is reported as EDP N or EDP R in the case of Inter-SGSN Routeing Area Update (provided that this DP is armed as generic EDP) if there is a relationship with the gsmSCF. Change of Position Context is reported as EDP N in the case of Intra-SGSN Routeing Area Update (provided that this DP is dynamically armed by the Service Logic). 6.4.3.1 Description of the PDP Context model (PIAs) This subclause describes the model for PDP Context State Model in the SGSN. For each PIA a description can be found of the entry events, actions and exit events. 6.4.3.1.1 Idle Entry events: - Deactivation (user or network initiated) and clearing of a previous PDP Context. - Processing of exceptional conditions. Actions: - Interface is idled. - Activate PDP Context request is received from MS (containing NSAPI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options), or Inter-SGSN Routeing Area Update is accepted (DP Change of Position Context). - Information being analyzed, e.g. GPRS CSI is analyzed. Exit events: - GPRS CSI is analyzed (DP PDP Context Establishment or DP Change of Position Context, new SGSN). 6.4.3.1.2 PDP Context Setup Entry events: - GPRS CSI is analyzed (DP PDP Context Establishment). Actions: - APN and GGSN selection procedure is performed for a primary PDP context as specified in Annex A of 3GPP TSÊ23.060Ê[15]. APN and GGSN selection procedure is not performed for a secondary PDP context. - Access Point Name is verified against the subscription. If the gsmSCF has provided an Access Point Name then the Access Point Name provided by the gsmSCF is checked against the subscription. For details refer to 3GPP TSÊ23.060Ê[15] Annex A. - The operator determined barring category ""Barring of all Packet Oriented Services "" is checked and invoked if necessary. - The operator determined barring category ""Barring of Packet Oriented Services from access points that are within the HPLMN whilst the subscriber is roaming in a VPLMN"" is checked and invoked if necessary. - The operator determined barring category ""Barring of Packet Oriented Services from access points that are within the roamed to VPLMN"" is checked and invoked if necessary. - The SGSN ensures that an already active PDP context is not reactivated. - GGSN address is derived from the Access Point Name by interrogation of a DNS. The Access Point Name consists of a Network Identifier and an Operator Identifier. - Create PDP Context Request is sent to the GGSN. Exit events: - Create PDP Context Response is received from the GGSN (DP PDP Context Establishment Acknowledgement). - An exception is encountered. 6.4.3.1.3 PDP Context Established Entry events: - GPRS CSI is analyzed (DP PDP Context Establishment Acknowledgement or DP Change of Position Context). Actions: - PDP context is established at the MS and the SGSN. Exit events: - Deactivation of the PDP Context is received from the MS or the GGSN, or is due to an inter SGSN routing area update (DP PDP Context Disconnection, old SGSN). - Intra-SGSN Routeing Area Update Request is received from the MS (DP Change of Position Context). - Inter-SGSN Routeing Area Update (DP Change of Position Context, new SGSN). - An exception is encountered. 6.4.3.1.4 Change of Position Context Entry events: - Inter SGSN Routing Area update accepted (new SGSN). - Intra SGSN Routeing Area update request received from the MS. Actions: - PDP Context (containing NSAPI, PDP Type, PDP Address, Access Point Name, QoS Requested, PDP Configuration Options) is reestablished in case of Inter-SGSN Routeing Area update accepted (new SGSN). - Intra SGSN Routeing Area updated. Exit events: - reestablishement of the PDP context at the new SGSN and return to PDP context established in case of inter SGSN Routeing Area update accepted in new SGSN (PIA PDP context established). - Routeing Area update completed in case of intra SGSN Routeing Area update (PIA PDP context established). 6.4.4 GPRS CAMEL Scenarios Two different scenarios are applicable for CAMEL control of GPRS. Scenario 1: Scenario 1 allows CAMEL control of the GPRS session and of multiple PDP contexts related to this session within a single GPRS dialogue. Scenario 2: Scenario 2 allows CAMEL control of single PDP contexts. Multiple PDP contexts are controlled in this scenario via multiple GPRS dialogues. ScenarioÊ1 and scenarioÊ2 are mutually exclusive, i.e. it is not possible to use both for one GPRS session at the same time in one SGSN. A GPRS session is involved in GPRS CAMEL at one moment in time either by using scenarioÊ1 or by using possible multiple instances of scenarioÊ2. GPRS sessions in different SGSNs are independent from a CAMEL perspective. 6.4.4.1 GPRS CAMEL Scenario 1 ScenarioÊ1 allows CAMEL control of the GPRS session and of multiple PDP contexts related to this session within a single GPRS dialogue (Session dialogue). Figure 6.5: GPRS CAMEL Scenario 1 A GPRS dialogue in scenarioÊ1 always consists of one GPRS Attach/Detach State Model and optionally of additional multiple GPRS PDP Context State Models related to the Attach/Detach State Model for the GPRS session. There is at most one GPRS Attach/Detach State Model per non idle GPRS session in one SGSN and at most one PDP Context State Model per active GPRS PDP context in one SGSN. The various PDP Context State Models are treated independently of each other. The GPRS dialogue and the relationship between the GPRS Attach/Detach State Model and the gsmSCF are always initiated using the TDPs of the GPRS Attach/Detach State Model. The gsmSCf requests further control or monitoring of individual GPRS PDP contexts using the Request Report GPRS Event information flow. To be informed about new individual PDP contexts the gsmSCF arms the DP 'PDP Context Establishment' or the DP 'PDP Context Establishment Acknowledgement' generically, i.e. without a PDP ID, as an EDP. To be informed about the handed over PDP contexts the gsmSCF arms the DP 'Change of Position Context' generically as an EDP N or EDP R. Each GPRS PDP context is identified by a PDP ID. The PDP ID is assigned by the SGSN during PDP context establishment. The PDP ID is unique within one GPRS dialogue. The Request Report GPRS Event information flows to control new or handed over PDP contexts do not include a PDP ID. There is no 'PDP ID' related to the GPRS Attach/Detach State Model. The PDP Id is reported to the gsmSCF in the first event notification for that PDP context. 6.4.4.2 GPRS CAMEL Scenario 2 ScenarioÊ2 allows CAMEL control of single PDP contexts. Multiple PDP contexts are controlled in this scenario via multiple GPRS dialogues (PDP Context dialogues). Figure 6.6: GPRS CAMEL Scenario 2 A GPRS dialogue in scenarioÊ2 consists of a single GPRS PDP Context State Model. There is no GPRS Attach/Detach State Model involved in this scenario. There is at most one PDP Context State Model per active GPRS PDP context in one SGSN. There might be multiple GPRS dialogues in scenariosÊ2 for one GPRS session, each of the dialogues controlling a single GPRS PDP context. The various GPRS dialogues are independent of each other. The GPRS dialogue and the relationship between the GPRS PDP Context State Model and the gsmSCF are always initiated using the TDPs for the GPRS PDP Context State Model. Control of further individual GPRS PDP contexts in the same GPRS dialogue as in scenarioÊ1 is not possible. There are no PDP IDs in this scenario. 6.4.5 SGSN Routeing Area Update 6.4.5.1 Intra-SGSN Routeing Area Update Intra-SGSN Routeing Area Update will be detected via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and via the DPs 'Change of Position Context' for the individual PDP contexts using the GPRS PDP Context State Models. It will be reported via an EDP N if the necessary EDP N is armed. 6.4.5.2 Inter-SGSN Routeing Area Update Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. Scenario 1: Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected in the new SGSN via the DP 'Change of Position GPRS Session' for the session using the GPRS Attach/Detach State Model and in the new SGSN via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. In this scenario the DP 'Change of Position GPRS Session' is armed as a TDP R. If the Routeing Area Update is accepted the gprsSSF reports this TDP R to the gsmSCF using the Initial DP GPRS information flow. To be informed about new PDP contexts the gsmSCF arms the DP 'PDP Context Establishment' or the DP 'PDP Context Establishment Acknowledgement' generically as EDP R or EDP N. The DPs 'Change of Position Context' for the PDP contexts which have been handed over will be reported with all necessary information to the gsmSCF when the gprsSSF is continued, i.e. it is not longer waiting for instructions. Contexts which are not continued in the new SGSN are not reported. The EDPs for new PDP contexts are reported as usual. The Detach in the old SGSN is reported to the gsmSCF, provided this event is armed. All outstanding reports in the old SGSN are sent to the gsmSCF and all open CDRs are closed. Scenario 2: Inter-SGSN Routeing Area Update from the old SGSN to the new SGSN will be detected in the new SGSN via the DPs 'Change of Position Context' using the GPRS PDP Context State Models for the individual PDP contexts which have been handed over. In this scenario the DP 'Change of Position Context' is armed as TDP R. If the Routeing Area Update is accepted the gprsSSF reports these TDP Rs PDP contexts which have been handed over to the gsmSCF using the Initial DP GPRS information flows in multiple GPRS dialogues. The PDP Context Disconnection in the old SGSN is reported to the gsmSCF, provided this event is armed. All outstanding reports in the old SGSN are sent to the gsmSCF and the open CDR is closed. 6.4.6 Rules for Implicit Disarming of Detection Points The two tables below give the rules for implicit disarming of event detection points. Implicit EDP disarming rules are specified for the Attach/Detach State Model and PDP Context State Model. The tables specify which EDP's shall be disarmed (i.e. MonitorMode set to Transparent) if/when each EDP is encountered, irrespective of the EDP's MonitorMode (Transparent, NotifyAndContinue, or Request). EDPs which are armed generically for GPRS PDP Context State Models shall only be implicitly disarmed at the end of the GPRS dialogue. Explicit disarming is possible."
"When EDP's are armed with MonitorMode 'Request' (EDP Rs) are encountered, any implicit EDP disarming shall take place before reporting the EDP and transiting the gprsSSF to the WFI state (if not already suspended in the WFI state). The table entry 'X' means that if one DP occurs (independently of arming and reporting to the gsmSCF) the marked one is implicitly disarmed. It shall be possible to rearm explicitly an implicitly disarmed DP. Table 6.3: Implicit disarming rules for Scenario 1 (the rules apply for non-generically armed DPs) Encountered DP Implicit disarmed DPs Change of Position GPRS Session Change of Position Context Detach PDP Context Establishment PDP Context Establishment Acknowledgement PDP Context Disconnection Change of Position GPRS Session Change of Position Context Detach X X X X X X PDP Context Establishment PDP Context Establishment Acknowledgement X PDP Context Disconnection X X X Table 6.4: Implicit disarming rules for Scenario 2 (the rules apply for non-generically armed DPs) Encountered DP Implicit disarmed DPs Change of Position Context PDP Context Establishment Acknowledgement PDP Context Disconnection PDP Context Establishment Acknowledgement X PDP Context Disconnection X X X Change of Position Context 6.5 Procedures for CAMEL GPRS 6.5.1 Overall SDL Architecture Figure 6.7: Architecture for CAMEL/GPRS interworking 6.5.2 Handling GPRS in the SGSN The functional behaviour of the SGSN is specified in 3GPP TSÊ23.060Ê[15]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_GPRS_Attach; - Procedure CAMEL_GPRS_Detach; - Procedure CAMEL_GPRS_Routeing_Area_Update_Session; - Procedure CAMEL_GPRS_Routeing_Area_Update_Context; - Procedure CAMEL_GPRS_PDP_Context_Establishment; - Procedure CAMEL_GPRS_Create_PDP_Context_Establishment_Acknowledgement; - Procedure CAMEL_GPRS_Change_Of_QoS; - Procedure CAMEL_GPRS_PDP_Context_Disconnection. 6.5.2.1 Actions of the SGSN on receipt of Int_Error The SGSN checks the default GPRS Handling parameter in GPRS CSI. If the default GPRS handling is release, a Detach indication is sent to the MS. The SGSN then releases all resources and the invoked CAMEL procedure ends. If the default GPRS handling is continue, the SGSN continues processing without CAMEL support. 6.5.2.2 Actions of the SGSN on receipt of Int_Continue The SGSN continues processing without any modification of GPRS parameters. 6.5.2.3 Handling of GPRS Attach/Detach Figure 6.8-1: Procedure CAMEL_GPRS_Attach (sheet 1) Figure 6.8-2: Procedure CAMEL_GPRS_Attach (sheet 2) Figure 6.9-1: Procedure CAMEL_GPRS_Detach (sheet 1) 6.5.2.4 Handling of GPRS Routeing Area Update Figure 6.10-1: Procedure CAMEL_GPRS_Routeing_Area_Update_Session (sheet 1) Figure 6.10-2: Procedure CAMEL_GPRS_Routeing_Area_Update_Session (sheet 2) Figure 6.11-1: Procedure CAMEL_GPRS_Routeing_Area_Update_Context (sheet 1) Figure 6.11-2: Procedure CAMEL_GPRS_Routeing_Area_Update_Context (sheet 2) 6.5.2.5 Handling of PDP Context establishment and deactivation Figure 6.12-1: Procedure CAMEL_GPRS_PDP_Context_Establishment (sheet 1) Figure 6.12-2: Procedure CAMEL_GPRS_PDP_Context_Establishment (sheet 2) Figure 6.13-1: Procedure CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement (sheet 1) Figure 6.13-2: Procedure CAMEL_GPRS_PDP_Context_Establishment_Acknowledgement (sheet 2) Figure 6.14-1: Procedure CAMEL_GPRS_Change_Of_QoS (sheet 1) Figure 6.15-1: Procedure CAMEL_GPRS_PDP_Context_Disconnection (sheet 1) 6.5.3 Handling GPRS in the gprsSSF 6.5.3.1 Process GPRS_SSF A relationship exists between the gsmSCF and the Attach/Detach State Model and/or between the gsmSCF and every PDP Context State Model. The relationship may be in controlling or monitoring mode. When a Continue GPRS, Connect GPRS or Request Report GPRS Event information flow is received, then the relationship between the gsmSCF and the Attach/Detach State Model, and between the gsmSCF and a PDP Context State Model may be downgraded from controlling to monitoring. When Tssf expires, the CAMEL procedures that are waiting for an instruction from the gsmSCF shall receive an Int_Error signal. The Default GPRS Handling parameter determines the subsequent action of those CAMEL procedures. If the Default GPRS Handling parameter is set to 'Release', then: - if the GPRS Dialogue is controlling a GPRS Session, then the gprsSSF shall release the entire GPRS Session; - if the GPRS Dialogue is controlling a single PDP Context, then the gprsSSF shall release the PDP Context. The task box 'Open GPRS Dialogue' comprises all the tasks that are required for starting a GPRS dialogue. This includes, amongst others, the allocation of a GPRS Reference Number and the allocation of resources. The task box 'Terminate GPRS Dialogue' comprises all the tasks that are required for closing a GPRS dialogue. 6.5.3.2 Process GPRS_Dialogue_Handler When process gprsSSF sends a TC_End request primitive to process GPRS_Dialogue_Handler, then the corresponding TC_End TC Message shall be sent to the gsmSCF only when the following conditions have been fulfilled: - The gprsSSF has processed all information flows that the gprsSSF has received from the gsmSCF. - No information flows remain to be sent from the gprsSSF to the gsmSCF. - The gprsSSF is not waiting for a Result or Error component for any information flows that the gprsSSF has sent to the gsmSCF. 6.5.3.3 Procedure Handle_AC_GPRS Procedure Handle_AC_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Apply Charging GPRS procedure shall be executed for the Session - 'PDP Id'. The Apply Charging GPRS procedure shall be executed for the indicated PDP Context. SheetÊ3 in procedure Handle_AC_GPRS contains a check for the PDP Context duration (Tcp(PDP Id)) and PDP Context volume (Vc(PDP Id)). If the PDP Context delta timer (Dcp(PDP Id)) is equal to or larger than the duration threshold received in the Apply Charging GPRS operation or the PDP Context delta counter (Dc(PDP Id)) is equal to or larger than the volume threshold received in the Apply Charging GPRS operation, then the gprsSSF shall generate an internal signal to trigger the sending of an Apply Charging Report GPRS. If a QoS change has occurred prior to receiving Apply Charging GPRS but after the sending Apply Charging Report GPRS, then the gprsSSF shall generate an internal signal to trigger the sending of an Apply Charging Report GPRS, including the negotiated QoS. 6.5.3.4 Procedure Handle_ACR_GPRS Procedure Handle_ACR_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Apply Charging Report GPRS procedure shall be executed for the Session. This procedure checks if a Session Period report is pending and if so, sends this report to the gsmSCF. - 'PDP Id'. The Apply Charging Report GPRS procedure shall be executed for the indicated PDP Context. This procedure checks if a Context Volume report is pending and if so, sends this report to the gsmSCF. The procedure then checks if a Context Period is pending and if so, sends this report to the gsmSCF. - 'Session + PDPs'. The Apply Charging Report GPRS procedure shall be executed for the Session and all PDP Contexts. The sequence of checking the reports shall be as follows: 1) The procedure checks the pending Volume and Period reports for each PDP Context. 2) The procedure then checks the pending Period report for the Session. When a PDP Context Volume counter or PDP context Period timer expires or an Apply Charging GPRS is received when QoS change report is pending, then the procedure Apply Charging Report GPRS procedure is called with the PDP Id as input parameter. The procedure will then check both reports for that PDP Context. 6.5.3.5 Procedure Complete_FCI_Record_GPRS Procedure Complete_FCI_Record_GPRS is called from process gprsSSF with the following input parameters: - 'Session'. The Complete_FCI_Record_GPRS procedure shall be executed for the Session. - 'PDP Id'. The Complete_FCI_Record_GPRS procedure shall be executed for the indicated PDP Context. - 'Session + PDPs'. The Complete_FCI_Record_GPRS procedure shall be executed for the Session and all PDP Contexts. 6.5.3.6 Procedure Handle_SCI_GPRS For terminology see subclauseÊ4.5.7.2.1. The gsmSCF may send e parameters to the Session and to individual PDP Contexts. When e parameters are sent for the Session, the SGSN will forward these e parameters directly to the Mobile Station. When e parameters are sent for a PDP Context and that PDP Context is not yet acknowledged (= active), then the SGSN shall retain these parameters (pending parameters). These parameters will be sent to the Mobile Station when the PDP Context is acknowledged. The gsmSCF may send two sets of e parameters and a Tariff Switch for the Session or a PDP Context. The first set of e parameters shall be sent to the SGSN and the second set of e parameters shall be stored. This second set of e parameters shall be sent to the SGSN when the tariff switch expires. When the Tariff Switch for the Session expires, then the stored e parameters for the Session shall be sent to the SGSN. When the Tariff Switch for a PDP Context expires before that PDP Context is acknowledged, then the pending e parameters for that PDP Context shall be replaced by the stored e parameters for that PDP Context. The stored e parameters for that PDP Context shall be discarded. When the Tariff Switch for a PDP Context expires after that PDP Context has been acknowledged, then the stored e parameters for that PDP Context shall be sent to the SGSN. 6.5.3.6.1 Handling of SCI_GPRS for the Session 1) Precondition: no Tsw running for the Session: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw (Session)/store 2nd set of e parameters. 2) Precondition: Tsw running for the Session and no e parameters stored for the Session: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 3) Precondition: Tsw running for the Session and e parameters stored for the Session: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6.5.3.6.2 Handling of SCI_GPRS for a PDP Context 1) Precondition: before a PDP Context Establishment Acknowledgement event is detected and no Tsw running for this PDP Context: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw(PDP Id)/store 2nd set of e parameters; 2) Precondition: before a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and no e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 3) Precondition: before a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 4) Precondition: after a PDP Context Establishment Acknowledgement event is detected and no Tsw running for this PDP Context: if 1 set of e parameters received --> send e parameters to the SGSN; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> start Tsw(PDP Id)/store e parameters; if 2 sets of e parameters and Tariff Switch received --> send 1st set of e parameters to the SGSN/start Tsw(PDP Id)/store 2nd set of e parameters. 5) Precondition: after a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and no e parameters stored for this PDP Context; if 1 set of e parameters received --> store e parameters; if 2 sets of e parameters received --> send 1st set of e parameters to the SGSN/store 2nd set of e parameters; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6) Precondition: after a PDP Context Establishment Acknowledgement event is detected and Tsw running for this PDP Context and e parameters stored for this PDP Context: if 1 set of e parameters received --> error; if 2 sets of e parameters received --> error; if 1 set of e parameters and Tariff Switch received --> error; if 2 sets of e parameters and Tariff Switch received --> error. 6.5.3.7 Procedure Handle_PDP_Acknowledgement Procedure Handle_PDP_Acknowledgement is called when an event occurs that may signal the activation (= Acknowledgement) of a PDP Context. The event signal is passed on to the Handle_PDP_Acknowledgement procedure. 6.5.3.8 GPRS duration and volume control 6.5.3.8.1 Examples of information flows for GPRS session and PDP context control Figure 6.16-1: Example of information flows for GPRS session duration at GPRS attach and change of position session Figure 6.16-2: Example of information flows for PDP context duration control at context activation and change of position context Figure 6.16-3: Example of information flows for PDP context volume control at context activation and change of position context Note1: Vc threshold reached, Tcp is stopped. Note2: Tcp time out, Vc is stopped. Figure 6.16-4: Example of information flows for PDP context volume and duration control at context activation and change of position context These figures 6.16-1 to 6.16-4show examples of handling of the timers that are used in the process gprsSSF and in the procedures Handle_AC_GPRS and Handle_ACR_GPRS. Duration timers (Tsp for the GPRS session and one Tcp for each PDP context) are used if the charging is on duration of the GPRS session or a PDP context. Tariff Switch Timers (Tsw(Session) for the GPRS session and one Tsw(PDP Id) for each PDP context) define the start point of a new Tariff. Tsw(Session) is used for charging on duration. Tsw(PDP Id) is used for both methods of charging: duration charging and volume charging. If a PDP context is charged on duration and volume, only one Tsw(PDP Id) timer will be accepted from the gsmSCF for that PDP context. Delta timers measure the response time of the gsmSCF after an Apply Charging Report GPRS information flow: - Dsp for the GPRS session; this delta timer is used for GPRS session period timing. - Dcp for each PDP context; these delta timers are used for PDP context period timing. - Dc for each PDP context; these delta counters are used for PDP context volume counting. After the sending of Apply Charging Report GPRS, the gsmSCF may reply either with: - Apply Charging GPRS, if the gsmSCF sends a new duration because of the expiration of the previous period or because of QOS change. - Release GPRS, if the gsmSCF decides to release the GPRS session or PDP context. For a more detailed example of the handling of the Apply Charging GPRS and Apply Charging Report GPRS information flows, see Annex A. 6.5.3.8.2 TC guard timer 6.5.3.8.2.1 General When the gprsSSF sends an Apply Charging Report GPRS information flow to the gsmSCF, with SessionActive or ContextActive variable set to TRUE, then the gprsSSF shall start the TC guard timer. The gprsSSF shall also mark for the Session or PDP Context for which the Apply Charging Report GPRS was sent, that a corresponding Apply Charging GPRS information flow from the gsmSCF is expected. When the gprsSSF receives an Apply Charging GPRS information flow or a Release GPRS information flow, then the 'Waiting-for-AC' marking(s) for the Session or PDP Context shall be removed. The gprsSSF shall then check if the TC guard timer shall be stopped (task box 'Check TC guard timer'). The TC guard timer shall be stopped if there are no more Apply Charging GPRS information flows expected for the Session and all PDP Contexts. When an event occurs that results in the termination of a PDP Context, then the 'Waiting-for-AC' markings for that PDP Context shall be removed. The gprsSSF shall then check if the TC guard timer shall be stopped (task box 'Check TC guard timer'). The TC guard timer shall be stopped if there are no more Apply Charging GPRS information flows expected for the Session and all PDP Contexts. When the TC guard timer expires in state Monitoring, then the gprsSSF shall close the TC dialogue, provided that all conditions for closing the TC dialogue are fulfilled, i.e. there are no information flow results expected from the gsmSCF, no information flows or errors to be sent to the gsmSCF and no information flows from the gsmSCF received and waiting to be processed. When the TC guard timer expires in state Waiting_for_Instructions, then no action shall be taken. Service Designers should note that there may be additional timer(s) in the gprsSSF to supervise the response from the gsmSCF on the Apply Charging Report GPRS procedure. As a result of this, if the gsmSCF does not send an Apply Charging GPRS, Release GPRS or Cancel GPRS in response to an Apply Charging Report GPRS when the gprsSSF is awaiting such response, then service behaviour may be unpredictable. 6.5.3.8.2.2 Check TC guard timer This clause describes the actions to be taken in the task box 'Check TC guard timer'. The tasks to be executed in the 'Check TC guard timer' box depend on the event that resulted in execution of the task box. 6.5.3.8.2.2.1 Apply Charging GPRS If 'Check guard timer' is executed as a result of an Apply Charging GPRS information flow from the gsmSCF, then the appropriate 'Waiting-for-AC' marker shall be removed, depending on the information received in the Apply Charging GPRS information flow: - if the Apply Charging GPRS information flow carries a Session Time threshold, then the Session-Period 'Waiting-for-AC' marker shall be removed. - if the Apply Charging GPRS information flow carries a PDP Context Volume threshold, then the PDP Context-Volume 'Waiting-for-AC' marker shall be removed. - if the Apply Charging GPRS information flow carries a PDP Context Time threshold, then the PDP Context -Period 'Waiting-for-AC' marker shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.8.2.2.2 Release GPRS If 'Check TC guard timer' is executed as a result of a Release GPRS information flow from the gsmSCF, then the appropriate 'Waiting-for-AC' markers shall be removed, depending on the information received in the Release GPRS information flow: - if the Release GPRS information flow is for the Session, then the Session 'Waiting-for-AC' markers shall be removed. - if the Release GPRS information flow is for the PDP Context, then the PDP Context 'Waiting-for-AC' markers shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.8.2.2.3 PDP Context Disconnect If 'Check TC guard timer' is executed as a result of a PDP Context Disconnect signal from the SGSN, then the 'Waiting-for-AC' markers for that PDP Context shall be removed. The gprsSSF then checks if there is any 'Waiting-for-AC' marker for the Session or any PDP Context. If there is no 'Waiting-for-AC' marker remaining, then the TC guard timer shall be stopped. 6.5.3.9 SDL diagrams for process GPRS_SSF and procedures Figure 6.17-1: Process GPRS_SSF (sheet 1) Figure 6.17-2: Process GPRS_SSF (sheet 2) Figure 6.17-3: Process GPRS_SSF (sheet 3) Figure 6.17-4: Process GPRS_SSF (sheet 4) Figure 6.17-5: Process GPRS_SSF (sheet 5) Figure 6.17-6: Process GPRS_SSF (sheet 6) Figure 6.17-7: Process GPRS_SSF (sheet 7) Figure 6.17-8: Process GPRS_SSF (sheet 8) Figure 6.17-9: Process GPRS_SSF (sheet 9) Figure 6.17-10: Process GPRS_SSF (sheet 10) Figure 6.17-11: Process GPRS_SSF (sheet 11) Figure 6.17-12: Process GPRS_SSF (sheet 12) Figure 6.17-13: Process GPRS_SSF (sheet 13) Figure 6.17-14: Process GPRS_SSF (sheet 14) Figure 6.17-15: Process GPRS_SSF (sheet 15) Figure 6.17-16: Process GPRS_SSF (sheet 16) Figure 6.17-17: Process GPRS_SSF (sheet 17) Figure 6.17-18: Process GPRS_SSF (sheet 18) Figure 6.17-19: Process GPRS_SSF (sheet 19) Figure 6.17-20: Process GPRS_SSF (sheet 20) Figure 6.17-21: Process GPRS_SSF (sheet 21) Figure 6.17-22: Process GPRS_SSF (sheet 22) Figure 6.17-23: Process GPRS_SSF (sheet 23) Figure 6.18-1: Process GPRS_Dialogue_Handler (sheet 1) Figure 6.18-2: Process GPRS_Dialogue_Handler (sheet 2) Figure 6.18-3: Process GPRS_Dialogue_Handler (sheet 3) Figure 6.19-1: Procedure Handle_AC_GPRS (sheet 1) Figure 6.19-2: Procedure Handle_AC_GPRS (sheet 2) Figure 6.19-3: Procedure Handle_AC_GPRS (sheet 3) Figure 6.20-1: Procedure Handle_ACR_GPRS (sheet 1) Figure 6.20-2: Procedure Handle_ACR_GPRS (sheet 2) Figure 6.21-1: Procedure Handle_FCI_GPRS (sheet 1) Figure 6.22-1: Procedure Complete_FCI_Record_GPRS (sheet 1) Figure 6.23-1: Procedure Handle_SCI_GPRS (sheet 1) Figure 6.23-2: Procedure Handle_SCI_GPRS (sheet 2) Figure 6.23-3: Procedure Handle_SCI_GPRS (sheet 3) Figure 6.24-1: Procedure Handle_PDP_Acknowledgement (sheet 1) 6.6 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for GPRS control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34] and TSÊ29.078Ê[36]. 6.6.1 gprsSSF to gsmSCF Information Flows 6.6.1.1 Activity Test GPRS ack 6.6.1.1.1 Description This IF is the response to the Activity Test GPRS. 6.6.1.1.2 Information Elements This IF contains no information elements. 6.6.1.2 Apply Charging Report GPRS 6.6.1.2.1 Description This IF is used by the gprsSSF to report to the gsmSCF the information requested in the Apply Charging GPRS IF. In addition, this IF is used to notify the gsmSCF of changes in QoS. Note that there are several possible QoS profiles defined by the combinations of the different QoS attributes as defined in 3GPP TSÊ23.060Ê[15]. A PLMN may only support and charge on a limited subset of those QoS. It is recommended that changes in QoS are only reported in Apply Charging Report GPRS for those QoS profiles. 6.6.1.2.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Charging Result M This IE contains the charging information for the PDP provided by the gprsSSF. It is a choice between elapsed time and data volume. Quality Of Service C This IE is described in a table below. Active M This IE indicates if the GPRS session or PDP context is still established, or if it has been detached or deactivated. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Apply Charging Report GPRS applies to the GPRS Session. If this IE is present in the IF, then the Apply Charging Report GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. Charging Roll Over C This IE indicates which parameter(s) of the Charging Result have overflowed. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Quality of Service contains the following information element: Information element name Status Description Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN, as a result of a 'Modify PDP Context' request. This IE shall be included only if sending of the Apply Charging Report GPRS was triggered by a change in Quality of Service. This IE shall contain the negotiated QoS as on the time of sending the Apply Charging Report GPRS. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. 6.6.1.3 Entity Released GPRS 6.6.1.3.1 Description This IF is used by the gprsSSF to inform the gsmSCF at any phase that a GPRS Session has been detached or a PDP Context has been disconnected without reporting any EDP. 6.6.1.3.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. GPRS Cause M This IE contains the Cause value indicating the reason for the GPRS Session Detach event or the PDP Context Disconnection event. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Entity Released GPRS applies to the GPRS Session. If this IE is present in the IF, then the Entity Released GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.1.4 Event Report GPRS 6.6.1.4.1 Description This IF is used to notify the gsmSCF of a GPRS event previously requested by the gsmSCF in a Request Report GPRS Event IF. 6.6.1.4.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. GPRS Event Type M This IE specifies the type of event that is reported. Misc GPRS Info M This IE indicates the DP type (EDP N or EDP R). GPRS Event Specific Information M This IE is described in a table below. This IE contains information specific to the reported event. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Event Report GPRS applies to the GPRS Session. If this IE is present in the IF, then the Event Report GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. If the GPRS Event Type contains DP Change of Position GPRS Session, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Location Information In SGSN M See subclauseÊ7.6.1.2.2. If the GPRS Event Type contains DP Change of Position Context, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name S This IE identifies the Access Point Name to which the MS is connected. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Charging ID S This IE contains the Charging ID received from the GGSN for the PDP context. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Location Information In SGSN M See subclauseÊ7.6.1.2.2. End User Address S See subclauseÊ6.6.1.5.2. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Quality Of Service S This IE is described in a table below. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. Time And Time Zone S This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. GGSN Address S This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. It shall be present, if available, at inter-SGSN routing area update. It shall be absent at intra-SGSN routing area update. If the GPRS Event Type contains DP Detach or DP PDP context disconnection, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Initiating Entity M This IE identifies the entity that has initiated the disconnection or detachment. Routeing Area Update C This IE indicates that the Detach or Disconnection is due to inter-SGSN routeing area update. If the GPRS Event Type contains DP PDP context establishment, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name C This IE identifies the Access Point Name the MS has requested to connect to. End User Address C See subclauseÊ6.6.1.5.2. Quality Of Service M This IE is described in a table below. Location Information In SGSN M See subclauseÊ7.6.1.2.2. Time And Time Zone M This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. PDP Initiation Type M This IE indicates whether a PDP context was established as a result of a network-initiated request or as a result of a subscriber request. Secondary PDP Context C This IE indicates that the PDP context activation was requested for a secondary PDP context. See 3GPP TSÊ23.060Ê[15]. If the GPRS Event Type contains DP PDP context establishment acknowledgement, then the GPRS Event Specific Information IE contains the following information elements: Information element name Status Description Access Point Name M This IE identifies the Access Point Name to which the MS is connected. Charging ID M This IE contains the Charging ID received from the GGSN for the PDP context. End User Address M See subclauseÊ6.6.1.5.2. Quality Of Service M This IE is described in a table below. Location Information In SGSN M See subclauseÊ7.6.1.2.2. Time And Time Zone M This IE contains the time that the gprsSSF met the detection point, and the time zone the gprsSSF resides in. GGSN Address M This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Quality of Service contains the following information elements: Information element name Status Description Requested QoS C This IE identifies the QoS requested by the subscriber for the PDP Context. It shall be included if the EventReportGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Subscribed QoS C This IE identifies the subscribed QoS. It shall be included if the EventReportGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN. It shall be included if the EventReportGPRS is sent at PDP Context Establishment Acknowledgement and at Change of Position Context. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. 6.6.1.5 Initial DP GPRS 6.6.1.5.1 Description This IF is generated by the gprsSSF when a trigger is detected at a DP in the GPRS state models, to request instructions from the gsmSCF. 6.6.1.5.2 Information Elements Information element name Status Description Gprs Reference Number M This IE consists of a number assigned by the gprsSSF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. ServiceKey M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application/SLP within the gsmSCF. GPRS Event Type M This IE indicates the armed GPRS DP event resulting in the Initial DP IF. MSISDN M This IE contains the basic MSISDN of the MS. IMSI M This IE identifies the mobile subscriber. Time and Time zone M This IE contains the time that the gprsSSF was triggered, and the time zone in which the gprsSSF resides. GPRS MS Class C This IE contains the MS network and radio access capabilities. End User Address C This IE is described in a table below. Quality of Service C This IE is described in a table below. Access Point Name C This IE identifies the Access Point Name: - At DP Change Of Position Context contains the selected APN. - AT DP PDP Context Establishment contains the APN which the MS has requested. - AT DP PDP Context Establishment Acknowledgement contains the selected APN. Charging ID C This IE contains the Charging ID received from the GGSN for the PDP context. SGSN Capabilities C This IE specifies the capabilities of the SGSN to support the CAMEL interworking, e.g. support of Advice of Charge. Location Information in SGSN M This IE is described in subclauseÊ7.6.1.2.2. PDP Initiation Type C This IE indicates whether a PDP context was established as a result of a network-initiated request or as a result of a subscriber request. GGSN Address C This IE contains the GGSN address for control plane to which the MS is connected, see 3GPP TSÊ23.003Ê[7]. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Secondary PDP context C This IE indicates that the PDP context activation was requested for a secondary PDP context. See 3GPP TSÊ23.060Ê[15]. This IE is not sent if this IF is initiated at DP Change of Position Context. IMEI (with software version) C This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Quality of Service contains the following information elements: Information element name Status Description Requested QoS C This IE identifies the QoS requested by the subscriber for a new PDP Context. It shall be included if the InitialDPGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Subscribed QoS C This IE identifies the subscribed QoS. It shall be included if the InitialDPGPRS is sent at PDP Context Establishment, at PDP Context Establishment Acknowledgement and at Change of Position Context. Negotiated QoS C This IE identifies the QoS which was negotiated between the user, the SGSN and the GGSN. It shall be included if the Initial DP GPRS is sent at PDP Context Establishment Acknowledgement and at Change of Position Context. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS."
"It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. End User Address shall be populated as follows: - At DP Change Of Position Context in an Inter-SGSN Routeing Area Update: Initial DP GPRS and EventReportGPRS contain the selected value; - At DP PDP Context Establishment: Initial DP GPRS and Event Report GPRS contain the value which the MS has requested; - At DP PDP Context Establishment Acknowledgement: Initial DP GPRS and Event Report GPRS contain the selected value. Note that the PDP Address is not always available at this DP. For details see 3GPP TSÊ23.060Ê[15]. End User Address contains the following information elements: Information element name Status Description PDP Type Organization C This IE identifies the PDP Type Organisation (e.g. IETF). PDP Type Number C This IE identifies the PDP type, e.g. IPv4 or IPv6. PDP Address C This IE identifies the address of the subscriber for a new PDP Context. 6.6.2 gsmSCF to gprsSSF Information Flows 6.6.2.1 Activity Test GPRS 6.6.2.1.1 Description This IF is used to check for the continued existence of a relationship between the gsmSCF and gprsSSF. If the relationship is still in existence, then the gprsSSF will respond. If no reply is received, then the gsmSCF will assume that the gprsSSF has failed in some way and will take the appropriate action. 6.6.2.1.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. 6.6.2.2 Apply Charging GPRS 6.6.2.2.1 Description This IF is used for interacting from the gsmSCF with the gprsSSF charging mechanisms to control the charging of a GPRS session or a PDP Context. 6.6.2.2.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. Charging Characteristics M This IE specifies the charging related information to be provided by the gprsSSF and the conditions on which this information has to be provided back to the gsmSCF. It is a choice between granted volume and granted time for the data transfer. Time charging may be applied to GPRS Session or PDP Contexts; volume charging may be applied to PDP Context only. Tariff Switch Interval O This information element specifies the time until the next tariff switch occurrence. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Apply Charging GPRS applies to the GPRS Session. If this IE is present in the IF, then the Apply Charging GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.3 Apply Charging Report GPRS ack 6.6.2.3.1 Description This IF is the response to the Apply Charging Report GPRS. 6.6.2.3.2 Information Elements This IF contains no information elements. 6.6.2.4 Cancel GPRS 6.6.2.4.1 Description This IF is used by the gsmSCF to request the gprsSSF to cancel all EDPs and reports. 6.6.2.4.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Refer to 3GPP TSÊ29.078Ê[36] for the usage of this element. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then all pending reports of the GPRS Session and all pending reports of the PDP Contexts shall be cancelled and all armed events of the GPRS Session, all armed events of the PDP Contexts and all generically armed events shall be disarmed. If this IE is present in the IF, then all pending reports of the indicated PDP Context shall be cancelled and all armed events of the indicated PDP Context shall be disarmed. Scenario 2: This IE is not used in the IF. 6.6.2.5 Connect GPRS 6.6.2.5.1 Description This IF is used by the gsmSCF to request the gprsSSF to modify the APN used when establishing a PDP Context. This IF shall not be used for a secondary PDP context or for a network initiated PDP context. 6.6.2.5.2 Information Elements Information element name Status Description Access Point Name M This IE contains the Access Point Name (APN) to be used when establishing the PDP Context. The gsmSCF should provide an APN which is allowed by the served subscriber's subscription. The APN provided by the gsmSCF is used for selecting the primary PDP context as specified in 3GPP TSÊ23.060Ê[15]. The gsmSCF provided APN may consist of Network Identity (NI) only, or Network Identity and Operator Identity (OI). The APN provided by the gsmSCF replaces entirely the APN requested by the MS. If the gsmSCF does not provide OI in APN then the SGSN selects the OI independent of MS. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: There shall always be this IE present in this IF. This IE indicates the PDP Context to which the Connect GPRS applies. Scenario 2: This IE is not used in the IF. 6.6.2.6 Continue GPRS 6.6.2.6.1 Description This information flow requests the gprsSSF to proceed with processing at the DP at which it previously suspended processing to await gsmSCF instructions. The gprsSSF completes DP processing, and continues processing (i.e. proceeds to the next point in the Attach/Detach State Model or PDP Context State Model) without substituting new data from the gsmSCF. 6.6.2.6.2 Information Elements Information element name Status Description PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Continue GPRS applies to the GPRS Session. If this IE is present in the IF, then the Continue GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.7 Entity Released GPRS ack 6.6.2.7.1 Description This IF is the response to the Entity Released GPRS. 6.6.2.7.2 Information Elements This IF contains no information elements. 6.6.2.8 Event Report GPRS ack 6.6.2.8.1 Description This IF is the response to the Event Report GPRS. 6.6.2.8.2 Information Elements This IF contains no information elements. 6.6.2.9 Furnish Charging Information GPRS 6.6.2.9.1 Description This IF is used to request the gprsSSF to include information in the CAMEL specific logical call record. The logical call record is created when FCI-GPRS is received and a logical call record for that state model does not exist. For modelling purposes the logical call record is buffered in the gprsSSF. The gprsSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then its free format data are moved to the corresponding CDR and the logical call record is deleted. In the SGSN there is a separate Logical call record for the attach/detach state model and for each PDP context. The CSE can send multiple concatenated FCIs per Logical Call Record for completion. The total maximum of free format data is 160 octets per Logical Call Record. The 160 octets may be sent in one or more FCI IF. If there is incomplete free format data and one or more new FCI IFs is/are received to overwrite the incomplete data, then the incomplete data are discarded and the gsmSCF can send another 160 octets per CDR. 6.6.2.9.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. FCI GPRS Billing Charging Characteristics M This IE is described in a table below. FCI GPRS Billing Charging Characteristics contains the following information: Information element name Status Description FCIBCCCAMEL Sequence 1 M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information: Information element name Status Description Free Format Data M This IE contains free format data to be inserted in the CAMEL logical call record. Append Free Format Data O This IE indicates that the gprsSSF shall append the free format data to the Logical call record. In the SGSN there is a separate Logical call record for the attach/detach state model and for each PDP context. - If this IE is present indicating ""Append"", the gprsSSF shall append the free format data received in this IF to the free format data already present in the Logical call record for that GPRS session or PDP Context. - If this IE is absent or indicates ""Overwrite"", then the gprsSSF shall overwrite all free format data already present in the Logical call record for that GPRS session or PDP Context, by the free format data received in this IF. If no Logical call record exists yet for that GPRS session or PDP Context, then the gprsSSF shall ignore this IE. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Furnish Charging Information GPRS applies to the GPRS Session. If this IE is present in the IF, then the Furnish Charging Information GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. 6.6.2.10 Release GPRS 6.6.2.10.1 Description This IF is used by the gsmSCF to tear down an existing GPRS session or PDP Context at any time. 6.6.2.10.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. GPRS Cause M This IE contains the Cause value indicating the reason for releasing the GPRS session or PDP context. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Release GPRS applies to the GPRS Session, in which case the GPRS Session and all PDP Contexts shall be released. If this IE is present in the IF, then the Release GPRS applies to the indicated PDP Context, in which case the indicated PDP Context shall be released. Scenario 2: This IE is not used in the IF. 6.6.2.11 Request Report GPRS Event 6.6.2.11.1 Description This IF is used to request the gprsSSF to monitor for an event and send a notification back to the gsmSCF when the event is detected (see Event Report GPRS IF). 6.6.2.11.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. GPRS Event M This IE specifies the event or events of which a report is requested. PDP ID C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IF is used to arm an event related to the GPRS Session, then this IF shall not include this IE. If this IF is used to arm an event related to a specific PDP Context, then this IF shall include this IE for that PDP Context. If this IF is used to generically arm a PDP Context related event, then this IF shall not include this IE. Scenario 2: This IE is not used in the IF. GPRS Event contains the following information elements: Information element name Status Description GPRS Event type M This IE specifies the type of event of which a report is requested. Monitor Mode M This IE indicates how the event shall be reported. 6.6.2.12 Reset Timer GPRS 6.6.2.12.1 Description This IF is used to refresh the gprsSSF timer. 6.6.2.12.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. Timer ID M This IE specifies the default value for the Tssf timer. Timer Value M This IE specifies the value to which the timer Tssf shall be set. 6.6.2.13 Send Charging Information GPRS 6.6.2.13.1 Description This IF is used to send e parameters from the gsmSCF to the gprsSSF. If charge advice information is received from the gsmSCF, it shall replace the charge advice information which would be generated by the SGSN and inhibit any further generation of CAI by the SGSN. Further processing of the charge advice information by the SGSN shall be in accordance with the Advice of Charge supplementary service. If the SGSN supports Advice of Charge, then the gsmSCF may use this IF to send e parameters to the gprsSSF. However, if the subscriber is not provisioned with the Advice of Charge supplementary service, then no e parameters shall be sent to the MS and no error due to this fact shall be sent back to the gsmSCF. If the SGSN does not support Advice of Charge, then the gsmSCF shall not send e parameters to the gprsSSF. The SGSN's support of Advice of Charge is indicated in the Initial DP GPRS IF. NOTE: If charge advice information is received from the gsmSCF after charge information has been generated by the SGSN and sent to the MS, the behaviour of the service may be unpredictable or incorrect; the service designer should therefore ensure that the first set of charge advice information is sent to the gprsSSF before charge information is sent to the to the MS. 6.6.2.13.2 Information Elements Information element name Status Description Gprs Reference Number C This IE consists of a number assigned by the gprsSSF and a number assigned by the gsmSCF. It is used for TCAP dialogue segmentation. SCI GPRS Billing ChargingCharacteristics M This IE defines the Advice Of Charge related information to be provided to the Mobile Station, if supported by the SGSN. GPRS SCI Billing Charging Characteristics contains the following information elements: Information element name Status Description AOC GPRS M This IE is present after an Activate PDP Context Accept or Attach Accept has been received from the SGSN. This IE defines the Advice Of Charge related information to be provided to the Mobile Station, if supported by the SGSN. PDP Id C This IE identifies the PDP Context to which the IF applies. Scenario 1: If this IE is not present in the IF, then the Send Charging Information GPRS applies to the GPRS Session. If this IE is present in the IF, then the Send Charging Information GPRS applies to the indicated PDP Context. Scenario 2: This IE is not used in the IF. AOC GPRS contains the following information elements: Information element name Status Description AOC Initial M This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. AOC Subsequent O This IE is described in a table below. AOC Subsequent contains the following information elements: Information element name Status Description CAI Elements M This IE contains CAI elements as defined in 3GPP TSÊ22.024Ê[3]. Tariff Switch Interval O This IE indicates the tariff switch time until the next tariff switch applies. 6.6.3 HLR to SGSN Information Flows 6.6.3.1 Delete Subscriber Data 6.6.3.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from an SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.3.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in SGSN. Specific CSI Withdraw O This IE is used to indicate that only GPRS CSI shall be deleted from the SGSN. This IE should not be present when CAMEL Subscription Info Withdraw is present. 6.6.3.2 Insert Subscriber Data 6.6.3.2.1 Description This IF is specified in 3GPP TSÊ29.002Ê[34] and used by the HLR to insert subscriber data in the SGSN. 6.6.3.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information element: Information element name Status Description GPRS CSI O This IE identifies the subscriber as having CAMEL GPRS services. GPRS CSI contains the following information elements: Information element name Status Description GsmSCF Address M See subclauseÊ6.3.1.1. Service Key M See subclauseÊ6.3.1.2. Default Session Handling M See subclauseÊ6.3.1.3. TDP List M See subclauseÊ6.3.1.4. CAMEL Capability Handling M See subclauseÊ6.3.1.5. 6.6.4 SGSN to HLR Information Flows 6.6.4.1 Insert Subscriber Data ack 6.6.4.1.1 Description This IF is used by the SGSN to indicate to the HLR the result of the Insert Subscriber Data IF. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.4.1.2 Information Elements Insert Subscriber Data ack contains the following CAMEL specific information elements: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the SGSN. It shall be present when a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if a CSI has been included in the Insert Subscriber Data IF. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. It shall be present if a CSI has been included in the Insert Subscriber Data IF. MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI. It shall be present if a CSI has been included in the Insert Subscriber Data IF. PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancements of Provide Subscriber Information. 6.6.4.2 Update GPRS Location 6.6.4.2.1 Description This IF is used by the SGSN to indicate to the HLR the CAMEL phases supported by the SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 6.6.4.2.2 Information Elements Update GPRS location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE identifies which CAMEL phases are supported by the SGSN. The SGSN may indicate support of CAMEL phaseÊ3 or higher. It shall be present when the SGSN supports CAMEL. Offered CAMEL4 CSIs This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases"" IE indicates support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI. MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI. PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancements of Provide Subscriber Information. 7 Short Message Services 7.1 Architecture 7.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support Mobile Originating Short Message Service (MO SMS) and Mobile Terminating Short Message Service (MT SMS) interworking for CAMEL. FiguresÊ7.1-1 and 7.1-2 show the functional entities involved in MO SMS or MT SMS requiring CAMEL support. Further details of the architecture needed to support Mobile Originating Short Message Service (MO SMS) and Mobile Terminating Short Message Service (MT SMS) are given in 3GPP TSÊ23.040Ê[14]. Figure 7.1-1: Functional architecture for support of CAMEL control of MSC switched MO and MT SMS Figure 7.1-2: Functional architecture for support of CAMEL control of SGSN switched MO and MT SMS HLR: The HLR stores MO SMS CSI and/or MT SMS CSI. MO SMS CSI contains subscription information for subscribers that require CAMEL support of MO SMS. MT SMS CSI contains subscription information for subscribers that require CAMEL support of MT SMS. One or both of MO SMS CSI and MT SMS CSI are transferred to the VLR or to the SGSN on Location Update and Restore Data or when MO SMS CSI or MT SMS CSI has changed. VLR: The VLR receives the MO SMS CSI and MT SMS CSI for the subscriber from the HLR. MO SMS CSI and MT SMS CSI are used by the MSC to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. MSC: The MSC receives MO SMS CSI and MT SMS CSI from the VLR and uses this to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. SGSN: The SGSN receives the MO SMS CSI and MT SMS CSI for the subscriber from the HLR. The SGSN uses the MO SMS CSI and MT SMS CSI to determine whether a Service Logic shall be invoked for an MO SMS submission or MT SMS delivery. gprsSSF: see subclauseÊ3.1. gsmSSF: see subclauseÊ3.1. gsmSCF: see subclauseÊ3.1. SMSC: The Short Message Service Centre accepts messages submitted by an MS or other MO short message entity, stores them and delivers them to the destination MS or other MT short message entity. SMS-GMSC: The Short Message Service Gateway MSC receives short messages from the SMSC, interrogates the HLR for routeing information to deliver each short message and forwards each short message to the serving node (MSC or SGSN) for delivery to the destination MS. The SMS-GMSC may be physically integrated with the SMSC or with the MSC for the destination subscriber. SMS-IWMSC: The Short Message Service InterWorking MSC terminates the MAP signalling from the MSC or the SGSN for MO short message submission, and transfers the short message to the SMSC, The SMS-IWMSC may be physically integrated with the SMSC or with the MSC for the originating subscriber. 7.1.2 Interfaces defined for CAMEL 7.1.2.1 HLR - VLR interface This interface is used to send CAMEL related subscriber data (MO SMS CSI and MT SMS CSI) to a visited MSC/VLR or to remove CAMEL related subscriber data from a visited MSC/VLR. 7.1.2.2 HLR - SGSN interface This interface is used to send CAMEL related subscriber data (MO SMS CSI and MT SMS CSI) to a visited SGSN or to remove CAMEL related subscriber data from a visited SGSN. 7.1.2.3 gsmSSF - gsmSCF interface This interface is used by the gsmSCF to control the handling of MO SMS and MT SMS in the MSC. A relationship on this interface is opened as a result of the gsmSSF sending a request for instructions to the gsmSCF. 7.1.2.4 gprsSSF - gsmSCF interface This interface is used by the gsmSCF to control the handling of MO SMS and MT SMS in the SGSN. A relationship on this interface is opened as a result of the gprsSSF sending a request for instructions to the gsmSCF. 7.1.2.5 MSC - gsmSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 7.1.2.6 SGSN - gprsSSF interface This is an internal interface. The interface is described in the present document to make it easier to understand the handling of DPs (arming/disarming of DPs, DP processing etc.). 7.1.2.7 MSC - VLR interface This is an internal interface. The interface is described in the present document to make it easier to understand the internal information flow within the MSC/VLR. 7.1.2.8 MSC - SMSC interface This interface is used by the MSC to submit a SM to the SMSC and to deliver a SM to the MSC. 7.1.2.9 SGSN - SMSC interface This interface is used by the SGSN to submit a SM to the SMSC and to deliver a SM to the SGSN. 7.2 Detection Points (DPs) For the general handling of the DPs, see subclauseÊ4.2. 7.2.1 Criteria at DP SMS Delivery Request The HLR may store a criterion that indicates when triggering shall take place. The criterion for DPÊSMS_Delivery_Request consists of a list of TPDU types. Refer to 3GPP TSÊ23.040Ê[14] for the available TPDU types. When the TPDU type of the Short Message is present in the list of TPDU types, then triggering shall take place. Otherwise, triggering shall not take place. If no criterion is defined for a subscriber, then triggering shall take place regardless of the TPDU type of the Short Message. 7.3 Description of CAMEL Subscriber Data Note: CAMEL PhaseÊ3 specifies SMS CSI for MO SMS CAMEL Services. CAMEL PhaseÊ4 specifies MO SMS CSI for MO SMS CAMEL Services and MT SMS CSI for MT SMS CAMEL Services. SMS CSI and MO SMS CSI are, however, syntactically and functionally identical. 7.3.1 Mobile Originating Short Message Service CAMEL Subscription Information (MO SMS CSI) This subclause defines the contents of the Short Message Service CAMEL Subscription Information. 7.3.1.1 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 7.3.1.2 Service Key The Service Key identifies to the gsmSCF the service logic. 7.3.1.3 Default SMS Handling The Default SMS Handling indicates whether the Short Message submission shall be released or continued as requested in the case of error in the dialogue between gsmSCF and gsmSSF or gprsSSF. 7.3.1.4 TDP List The TDP List indicates on which detection point triggering shall take place. For MO SMS CSI only DPÊSMS_Collected_Info is used. 7.3.1.5 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. This parameter shall be set to CAMEL PhaseÊ3 7.3.1.6 CSI state The CSI state indicates whether the MO SMS CSI is active or not. 7.3.1.7 Notification flag The notification flag indicates whether the change of the MO SMS CSI shall trigger Notification on Change of Subscriber Data or not. 7.3.2 Mobile Terminating Short Message Service CAMEL Subscription Information (MT SMS CSI) This subclause defines the contents of the Mobile Terminating Short Message Service CAMEL Subscription Information. 7.3.2.1 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 7.3.2.2 Service Key The Service Key identifies to the gsmSCF the service logic. 7.3.2.3 Default SMS Handling The Default SMS Handling indicates whether the Short Message delivery shall be released or continued as requested in the case of error in the dialogue between gsmSCF and gsmSSF or gprsSSF. 7.3.2.4 TDP List The TDP List indicates on which detection point triggering shall take place. For MT SMS CSI only DPÊSMS_Delivery_Request is used. 7.3.2.5 DP criteria The DP criteria indicate whether the SMS_SSF shall request the gsmSCF for instructions. 7.3.2.6 CAMEL Capability Handling CAMEL Capability Handling indicates the phase of CAMEL which is asked by the gsmSCF for the service. This parameter shall be set to CAMEL PhaseÊ4. 7.3.2.7 CSI state The CSI state indicates whether the MT SMS CSI is active or not. 7.3.2.8 Notification flag The notification flag indicates whether the change of the MT SMS CSI shall trigger Notification on Change of Subscriber Data or not. 7.3.3 gsmSCF address list for CSI The gsmSCF address list indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI's. 7.4 Description of SMS State Models 7.4.1 General Handling See subclauseÊ4.4.1. The State Model for MO SMS handling contains Points in Association (PIA's) instead of Points in Call (PIC's). 7.4.2 Mobile Originating SMS State Models 7.4.2.1 Description of MO SMS state model The MO SMS state model is used to describe the actions in an MSC and in a SGSN during Mobile Originating SMS. Figure 7.2: MO SMS State Model Table 7.1: Description of MO SMS DPs in the MSC and SGSN CAMEL Detection Point DP Type Description DPÊSMS_Collected_Info TDP R Indication that the MO SMS CSI is analysed and a mobile originated short message is received. DPÊO_SMS_Failure EDP N, EDP R Indication that the SM submission to the Short Message Service Centre failed DPÊO_SMS_Submitted EDP N, EDP R Indication that the SM has been successfully submitted to the Short Message Service Centre. 7.4.2.1.1 Description of the MO SMS state model (PIAs) This subclause describes the state model for originating SMS transfer. For each PIA a description can be found of the entry events, actions and exit events. 7.4.2.1.1.1 SMS Null & Start & Authorize Entry events: - Previous MO SMS transfer to the SMSC completed (DPÊO_SMS_Submitted). - Exception event is reported. Actions: - Interface is idled. - Authentication. - Ciphering. - MO SMS subscription check. - RP-MO-DATA message containing the User Data and the SMSC address is received from MS. - The supplementary service ""barring of all outgoing calls"" is checked and invoked if necessary. - The ODB category ""barring of all outgoing calls"" is checked and ODB is invoked if necessary. Exit events: - MO SMS CSI is analysed. - An exception condition is encountered. 7.4.2.1.1.2 SMS Analyse & Routing Entry events: - MO SMS CSI is analysed (DPÊSMS_Collected_Info). Actions: - Information being analysed and/or translated to determine routeing address of the SMSC. - Outgoing barring services and ODB categories not already applied are checked and invoked if necessary. If any of the barring services or ODB categories prevents the submission of the MO SMS, then the MSC or SGSN shall generate the ""O_SMS_Failure"" event. The cause code to be used in that case shall be ""sM DeliveryFailure"". - The short message is sent to the SMSC. Exit events: - Acknowledge from the SMSC is received. (DPÊO_SMS_submitted). A positive acknowledgement is sent to the MS. - An exception condition is encountered - this leads to the SMS_Exception PIA. A negative acknowledgement is sent to the MS. - Attempt to select the route for the SMS fails (DPÊO_SMS_Failure). A negative acknowledgement is sent to the MS. - Negative acknowledgement from the SMSC is received (DPÊO_SMS_Failure). A negative acknowledgement is sent to the MS. 7.4.2.1.1.3 SMS_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIA cannot be met. Actions: - Default handling of the exception condition is applied. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If a relationship exists between the gsmSCF and gsmSSF or gprsSSF send an error information flow closing the relationship and indicating that any outstanding Short Message handling instructions will not run to completion. - The MSC/gsmSSF or SGSN/gprsSSF shall make use of vendor-specific procedures to ensure release of internal resources. Exit events: - Default handling of the exception condition by MSC/gsmSSF or SGSN/gprsSSF completed. 7.4.3 Mobile Terminating SMS State Model 7.4.3.1 Description of MT SMS state model The MT SMS state model is used to describe the actions in an MSC and in a SGSN during Mobile Terminating SMS. Figure 7.3: MT SMS State Model Table 7.2: Description of MT SMS DPs in the MSC and SGSN CAMEL Detection Point DP Type Description DPÊSMS_Delivery_Request TDP R Indication that the MT SMS CSI is analysed and a mobile terminating short message or status report is received. DPÊT_SMS_Failure EDP N, EDP R Indication that the SM delivery to the Mobile Station has failed DPÊT_SMS_Delivered EDP N, EDP R Indication that the SM has been successfully delivered to the Mobile Station. 7.4.3.1.1 Description of the MT SMS state model (PIAs) This subclause describes the state model for terminating SMS transfer. For each PIA a description can be found of the entry events, actions and exit events. 7.4.3.1.1.1 SMS Null & Start & Authorize Entry events: - MAP-MT-FORWARD-SHORT-MESSAGE message is received from SMS-GMSC. - Previous MT SMS transfer to the MS completed (DPÊT_SMS_Delivered). - Exception event is reported. Actions: - Interface is idled. - MT SMS subscription check. - MT SMS CSI is received from the VLR (in the MSC only). Exit events: - MT SMS CSI is analysed. - An exception condition is encountered. 7.4.3.1.1.2 SMS Delivery Entry events: - MT SMS CSI is analysed. (DPÊSMS_Delivery_Request). Actions: - Subscriber paging is performed, if required. - The short message is delivered to the MS. Exit events: - Acknowledge from the MS is received. (DPÊT_SMS_Delivered). A positive acknowledgement is sent to the SMSC. - An exception condition is encountered - this leads to the SMS_Exception PIA. A negative acknowledgement is sent to the SMSC. - Negative acknowledgement from the MS is received (DPÊT_SMS_Failure). A negative acknowledgement is sent to the SMSC. 7.4.3.1.1.3 SMS_Exception Entry events: - An exception condition is encountered. In addition to specific examples listed above, exception events include any type of failure, which means that the normal exit events for a PIA cannot be met. Actions: - Default handling of the exception condition is applied. This includes general actions necessary to ensure that no resources remain inappropriately allocated such as: - If a relationship exists between the gsmSCF and gsmSSF or gprsSSF send an error information flow closing the relationship and indicating that any outstanding Short Message handling instructions will not run to completion. - The MSC/gsmSSF or SGSN/gprsSSF shall make use of vendor-specific procedures to ensure release of internal resources. Exit events: - Default handling of the exception condition by MSC/gsmSSF or SGSN/gprsSSF completed. 7.5 Procedures for CAMEL SMS 7.5.1 Functional architecture for CAMEL MO SMS services Note 1: The functional entities depicted by means of dark shaded boxes in the figureÊ7.4 are not affected by CAMEL interaction with MO SMS. Note 2: The Relay Protocol between the MS and the MSC or SGSN is described in 3GPP TSÊ24.011Ê[31]. The Relay Protocol between the MSC or SGSN and the SMS-GMSC is described in 3GPP TSÊ29.002Ê[34]. The Relay Protocol between the SMS-GMSC and the SMSC is not standardised. Examples of this protocol are described in GSM TRÊ03.47Ê[42]. Figure 7.4: MO SMS via MSC or SGSN 7.5.2 Handling of mobile originating SMS 7.5.2.1 Handling of mobile originating SMS in the originating MSC or SGSN The functional behaviour of the originating MSC or SGSN is specified in 3GPP TSÊ29.002Ê[34] and 3GPP TSÊ23.060Ê[15]. The procedures specific to CAMEL are specified in this subclause: - Procedure CAMEL_O_SMS_INIT; - Procedure CAMEL_O_SMS_SUBMITTED; - Procedure CAMEL_O_SMS_FAILURE. A CAMEL Service may be invoked for the following Mobile Originated short message types: - Short Message Submission (TPDU type = SMS-SUBMIT) - Short Message Command (TPDU type = SMS-COMMAND) Refer to 3GPP TSÊ23.040Ê[14] for a description of the various TPDU types and to 3GPP TSÊ24.011Ê[31] for a description of the protocol elements of the Short Message Relay Layer (RPDUs). 7.5.2.1.1 Actions of the MSC or SGSN on receipt of Int_Error The MSC or SGSN checks the default SMS Handling parameter in MO SMS CSI. If the default SMS handling is 'releaseTransaction', a A_RP_ERROR is sent to the MS. The MSC or SGSN then releases all resources and the procedure CAMEL_O_SMS_INIT ends. If the default SMS handling is 'continueTransaction', the MSC or SGSN continues processing without CAMEL support. 7.5.2.1.2 Actions of the MSC or SGSN on receipt of Int_Continue_SMS The MSC or SGSN continues processing with modified SM parameters. The MSC or SGSN shall transparently modify the SMS parameters with the received information. Parameters which are not included in the Int_Continue_SMS signal are unchanged. 7.5.2.1.3 Actions of the MSC or SGSN on receipt of Int_Connect_SMS The MSC or SGSN continues processing with modified SM parameters. The MSC or SGSN shall transparently modify the SMS parameters with the received information. Barring is checked with the modified parameters. Parameters which are not included in the Int_Connect_SMS signal are unchanged. 7.5.2.1.4 Actions of the MSC or SGSN on receipt of Int_Release_SMS A_RP_ERROR is sent to the MS and the Short Message is deleted. The SMS cause received in the Int_Release_SMS signal is used. The MSC or SGSN then releases all resources and the procedure CAMEL_O_SMS_INIT ends. 7.5.2.1.5 Allocation of SMS Reference Number During the CAMEL handling of a Mobile Originated Short Message, the MSC or SGSN shall allocate an SMS Reference Number. This SMS Reference Number shall be placed in the SMS-MO Call Detail Record, together with the MSC Address or SGSN Number. This SMS Reference Number shall also be sent to the gsmSCF in the Initial DP SMS Information Flow, together with the MSC Address or SGSN Number. The combination of SMS Reference Number and MSC Address or SGSN Number forms a globally unique pair. This pair may be used for correlation of CDRs produced in the MSC or SGSN with CDRs produced in the gsmSCF. An SMS Reference Number shall be generated and placed in the SMS-MO Call Detail Record, for every Short Message, including the case when a Short Message forms part of a set of concatenated Short Messages."
"7.5.2.2 Handling of A_MM_Release and A_LLC_Release If the radio link with the subscriber is lost during the handling of a CAMEL procedure in the MSC or SGSN, then the MSC or SGSN sends signal A_MM_Release_ind or A_LLC_Release_ind to that procedure. This results in the termination of that CAMEL procedure. (Refer to 3GPP TSÊ29.002Ê[34] for details.) 7.5.2.3 Handling of time-out from SMSC If the MSC or SGSN does not receive a confirmation from the SMSC after submission of a Short Message, then the MSC or SGSN calls procedure CAMEL_O_SMS_FAILURE. (Refer to 3GPP TSÊ29.002Ê[34] for details.) Figure 7.5-1: Procedure CAMEL_O_SMS_INIT (sheet 1) Figure 7.5-2: Procedure CAMEL_O_SMS_INIT (sheet 2) Figure 7.5-3: Procedure CAMEL_O_SMS_INIT (sheet 3) Figure 7.6-1: Procedure CAMEL_O_SMS_SUBMITTED (sheet 1) Figure 7.7-1: Procedure CAMEL_O_SMS_FAILURE (sheet 1) 7.5.2.4 Handling of mobile originating SMS in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ29.002Ê[34] The handling specific to CAMEL is specified in the following procedure: - Procedure CAMEL_MO_SMS_VLR. Figure 7.8-1: Procedure CAMEL_MO_SMS_VLR (sheet 1) 7.5.3 Functional architecture for CAMEL MT SMS services Note 1: The functional entities depicted by means of dark shaded boxes in the figureÊ7.9 are not affected by CAMEL interaction with MT-SMS. Note 2: The Relay Protocol between the MS and the MSC or SGSN is described in 3GPP TSÊ24.011Ê[31]. The Relay Protocol between the MSC or SGSN and the SMS-GMSC is described in 3GPP TSÊ29.002Ê[34]. The Relay Protocol between the SMS-GMSC and the SMSC is not standardised. Examples of this protocol are described in GSM TRÊ03.47Ê[42]. Figure 7.9: MT SMS via MSC or SGSN 7.5.4 Handling of mobile terminating SMS 7.5.4.1 Handling of mobile terminating SMS in the terminating MSC or SGSN A CAMEL Service may be invoked for the following Mobile Terminated short message types: - Short Message Delivery (TPDU type = SMS-DELIVER) - Short Message Status Report (TPDU type = SMS-STATUS-REPORT) Refer to 3GPP TSÊ23.040Ê[14] for a description of the various TPDU types and to 3GPP TSÊ24.011Ê[31] for a description of the protocol elements of the Short Message Relay Layer (RPDUs). The functional behaviour of the terminating MSC or SGSN is specified in 3GPP TSÊ29.002Ê[34]. The procedures specific to CAMEL are specified in the following subclauses: 7.5.4.1.1 Procedure CAMEL_T_SMS_INIT; This procedure is called when a Short Message delivery attempt is received from the SMS-GMSC. If MT SMS CSI is present for the subscriber, then the SMS_SSF shall be invoked. Otherwise, the Short Message delivery attempt proceeds without CAMEL. When the SMS_SSF is invoked and the SMS_SSF has requested the gsmSCF for instructions, the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The gsmSCF has indicated that SM delivery may proceed. It may have supplied the SMS_SSF with a modified Calling Party Number. This Calling Party Number shall replace the TP-Originating-Address in the SMS-DELIVER TPDU. - Int_Release_SMS The gsmSCF has force-released SM delivery. The RP Cause received from the gsmSCF shall be conveyed to the SMS-GMSC in the RP-Cause component, in the RP-ERROR RPDU. - Int_Error A Tssf time-out or an internal SMS_SSF error has occurred; the SM has not been forwarded to the Mobile Station. If Default SMS Handling equals 'Continue', the SM delivery proceeds. Otherwise, SM delivery shall be aborted. In the latter case, the RP-Cause component, in the RP-ERROR RPDU shall be set to EquipmentProtocolError, in accordance with 3GPP TSÊ29.002Ê[34]. 7.5.4.1.2 Procedure CAMEL_T_SMS_DELIVERED This procedure is called when the MSC or SGSN has detected that delivery of the SM to the Mobile Station has succeeded. No event specific information is sent to the gsmSCF. When Short Message delivery attempt success has been reported to the gsmSCF, then the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The event was reported to the gsmSCF in interrupt mode. The gsmSCF has concluded CAMEL processing and has terminated the Service Logic. - Int_Continue The event was not reported to the gsmSCF or was reported in notification mode. - Int_Error A Tssf time-out has occurred. In all the above cases, the SM processing in the MSC or SGSN continues. 7.5.4.1.3 Procedure CAMEL_T_SMS_FAILURE This procedure is called when the MSC or SGSN has detected that delivery of the SM to the Mobile Station has failed. If the delivery failure is due to RP-ERROR RPDU received from the MS, then the MT SMS Cause in the event report to the gsmSCF shall be set to the RP-Cause component in the RP-ERROR-RPDU. Otherwise, if the delivery failure is due to internal failure in the MSC or SGSN, CP-ERROR from MS or time-out from the MS, then the MT SMS Cause in the event report to the gsmSCF shall be set to ""Protocol error, unspecified"", as defined in 3GPP TSÊ24.011Ê[31]. When Short Message delivery attempt failure has been reported to the gsmSCF, then the MSC or SGSN may receive the following responses from the SMS_SSF: - Int_Continue_SMS The event was reported to the gsmSCF in interrupt mode. The gsmSCF has concluded CAMEL processing and has terminated the Service Logic. - Int_Continue The event was not reported to the gsmSCF or was reported in notification mode. - Int_Error A Tssf time-out has occurred. In all the above cases, the SM processing in the MSC or SGSN continues. 7.5.4.1.4 Allocation of SMS Reference Number During the CAMEL handling of a Mobile Terminating Short Message, the MSC or SGSN shall allocate an SMS Reference Number. This SMS Reference Number shall be placed in the SMS-MT Call Detail Record, together with the MSC Address or SGSN Number. This SMS Reference Number shall also be sent to the gsmSCF in the Initial DP SMS Information Flow, together with the MSC Address or SGSN Number. The combination of SMS Reference Number and MSC Address or SGSN Number forms a globally unique pair. This pair may be used for correlation of CDRs produced in the MSC or SGSN with CDRs produced in the gsmSCF. An SMS Reference Number shall be generated and placed in the SMS-MT Call Detail Record, for every Short Message, including the case when a Short Message forms part of a set of concatenated Short Messages. Figure 7.10-1: Procedure CAMEL_T_SMS_INIT (sheet 1) Figure 7.10-2: Procedure CAMEL_T_SMS_INIT (sheet 2) Figure 7.11-1: Procedure CAMEL_T_SMS_FAILURE (sheet 1) Figure 7.12-1: Procedure CAMEL_T_SMS_DELIVERED (sheet 1) 7.5.4.2 Handling of mobile terminating SMS in the VLR The functional behaviour of the VLR is specified in 3GPP TSÊ29.002Ê[34]. The handling specific to CAMEL is specified in the following procedure: - Procedure CAMEL_MT_SMS_VLR. Figure 7.13-1: Procedure CAMEL_MT_SMS_VLR (sheet 1) 7.5.4.3 CAMEL subscription check for mobile terminating SMS in the SGSN The functional behaviour of the SGSN for delivery of MT shrt message is specified in 3GPP TSÊ29.002Ê[34]. The procedure for checking CAMEL capability and subscription information is specified in the following procedure: - Procedure CAMEL_MT_SMS_SGSN. Figure 7.14-1: Procedure CAMEL_MT_SMS_SGSN (sheet 1) 7.5.5 Handling of mobile originating and mobile terminating SMS in the gsmSSF or gprsSSF 7.5.5.1 Process SMS_SSF Sheet 1 The Int_Invoke SMS_SSF signal dictates which TDP shall be armed. For a Mobile Originated SMS service, the SMS_Collected_Info TDP shall be armed. For a Mobile Terminated SMS service, the SMS_Delivery_Request TDP shall be armed. Sheet 2 The Int_SMS_Failure signal may be received only for a MO-SMS service. It is received when a MS detach event occurs before the SMS_SSF is invoked. Sheet 3 The SMSC Address and Destination Subscriber Number may be received in CAP ConnectSMS only for a MO-SMS service. Sheet 4: For a MO-SMS service, the following events may be armed or disarmed: O_SMS_Submission, O_SMS_Failure. For a MT-SMS service, the following events may be armed or disarmed: T_SMS_Delivery, T_SMS_Failure. Sheet 5: For a MO-SMS service, the gsmSCF may place free-format charging data in the 'MOSMSRecord' CDR (in the MSC) or in the S-SMO-CDR (in the SGSN). For a MT-SMS service, the gsmSCF may place free-format charging data in the 'MTSMSRecord' (in the MSC) or in the S-SMT-CDR (in the SGSN). Refer to 3GPP TSÊ32.250Ê[37] and 3GPP TSÊ32.251Ê[38] for a description of these CDR types. Sheet 6: The Int_SMS_Failure signal in state Waiting_For_Instructions may be received for a MO-SMS service only. It is received when a MS detach event occurs before the gsmSCF has given instruction to continue SM processing. Sheet 7: When the SM submission or failure event occurs, both MO-SMS events shall be disarmed. When the SM delivery or failure event occurs, both MT-SMS events shall be disarmed. 7.5.5.2 Process Complete_SMS_FCI_Record Sheet 1: For a MO-SMS service, the 'MOSMSRecord' or 'S-SMO-CDR' shall be closed. For a MT-SMS service, the 'MTSMSRecord' or 'S-SMT-CDR' shall be closed. Figure 7.15-1: Process SMS_SSF (sheet 1) Figure 7.15-2: Process SMS_SSF (sheet 2) Figure 7.15-3: Process SMS_SSF (sheet 3) Figure 7.15-4: Process SMS_SSF (sheet 4) Figure 7.15-5: Process SMS_SSF (sheet 5) Figure 7.15-6: Process SMS_SSF (sheet 6) Figure 7.15-7: Process SMS_SSF (sheet 7) Figure 7.16-1: Procedure Check_Criteria_SMS_Delivery_Request (Sheet 1) Figure 7.17-1: Procedure Complete_SMS_FCI_record (sheet 1) 7.6 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for SMS control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Optional (O), Specific conditions (S), mutually Exclusive (E), or not applicable (-) for each different traffic case: Mobile Originating SMS (MO) and Mobile Terminating SMS (MT). If the IEs in one table apply in both the MO and MT cases, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The distinction between MO and MT SMS applies only to the Information Flows between the gsmSCF and the gsmSSF or gprsSSF. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34], TSÊ29.078Ê[36]. 7.6.1 gsmSSF or gprsSSF to gsmSCF information flows 7.6.1.1 Event Report SMS 7.6.1.1.1 Description This IF is used to notify the gsmSCF of an event previously requested by the gsmSCF in a Request Report SMS Event IF. 7.6.1.1.2 Information Elements Information element name MO MT Description Event Type M M This IE specifies the type of event that is reported. Event Specific Information C C This IE indicates the SMS related information specific to the event. Misc SMS Info M M This IE indicates the DP type. If the Event Type IE indicates O_SMS_Failure, then the Event Specific Information contains the following information element: Information element name MO MT Description MO_SMS Cause M - This IE indicates the reason of submission failure. If the Event Type IE indicates T_SMS_Failure, then the Event Specific Information contains the following information elements: Information element name MO MT Description MT_SMS Cause - M This IE indicates the reason of delivery failure. If the Event Type IE indicates O_SMS_Submitted or T_SMS_Delivered, then no Event Specific Information shall be sent to the gsmSCF. 7.6.1.2 Initial DP SMS 7.6.1.2.1 Description This IF is generated by the gsmSSF or gprsSSF when a trigger is detected at a DP in the state model, to request instructions from the gsmSCF. 7.6.1.2.2 Information Elements Information element name MO MT Description Destination Subscriber Number M - This IE contains a number to identify the Destination short message entity. The Destination Subscriber Number shall be retrieved from the TP-Destination-Address in the SMS-SUBMIT TPDU or the SMS-COMMAND TPDU. Called Party Number - M This IE contains a number to identify the subscriber for whom the Short Message is destined. The Called Party Number shall be the MSISDN of the served subscriber. Calling Party Number M C For MO SMS: This IE contains a number to identify the subscriber who requests the SM submission. The Calling Party Number shall be the MSISDN of the served subscriber. For MT SMS: This IE contains the address of the submitter of the short message. For SMS-DELIVER TPDU, the Calling Party Number shall be retrieved from the TP-Originating-Address in the SMS-DELIVER TPDU. For SMS-STATUS-REPORT TPDU, this element shall not be included in this IF. Event Type M M This IE indicates the armed event resulting in the Initial DP SMS IF. IMSI M M This IE identifies the mobile subscriber. Location Information In MSC C C This IE is described in a table below. Location Information In SGSN C C This IE is described in a table below. Service Key M M This IE indicates to the gsmSCF the requested CAMEL Service. It is used to address the required application/SLP within the gsmSCF. Time And Timezone M M This IE contains the time that the gsmSSF or gprsSSF was triggered, and the time zone the gsmSSF or gprsSSF resides in. TP Short Message Specific Information M M This IE contains the first octet of the applicable TPDU. For SMS-SUBMIT, the following elements may be included: - Message Type Indicator - Reject Duplicates - Validity Period Format - Status Report Request - User Data Header Indicator - Reply Path For SMS-COMMAND, the following elements may be included: - Message Type Indicator - User Data Header Indicator - Status Report Request For SMS-DELIVER, the following elements may be included: - Message Type Indicator - More Messages to Send - Status Report Indication - User Data Header Indicator - Reply Path For SMS-STATUS-REPORT, the following elements may be included: - Message Type Indicator - More Messages to Send - Status Report Qualifier - User Data Header Indicator Refer to 3GPP TSÊ23.040Ê[14] for an indication of which elements of this 1st octet are Mandatory and which elements are Conditional. TP Protocol Identifier M C This IE indicates the protocol used above SM-Transfer Layer. The TP Protocol Identifier shall be retrieved from the applicable TPDU. For SMS-STATUS-REPORT, the sending of this IE is Conditional, depending on its presence in the SMS-STATUS-REPORT TPDU. TP Data Coding Scheme C C This IE indicates the data coding scheme of the TP User Data field, and may indicate a message class. The message class may indicate e.g. the originator of the Short Message. The TP Data Coding Scheme shall be retrieved from the applicable TPDU. For SMS-COMMAND, this IE shall not be included in this IF. TP Validity Period S - This IE indicates the length of the validity period or the absolute time of the validity period termination. This IE is used only for the SMS-SUBMIT TPDU. The TP Validity Period, if available, shall be retrieved from the SMS-SUBMIT TPDU. For other TPDU, this IE shall not be included in this IF. SMSC Address M M For MO SMS: This IE defines the address of the SMSC to which the MO short message is intended to be submitted. It shall be retrieved from the RP-Destination-Address in the RP-MO-DATA RPDU. For MT SMS: This IE identifies the address of the SMSC from which the MT short message is originating. It shall be retrieved from the RP-Originating-Address in the RP-MT-DATA RPDU. SMS Reference Number M M This IE carries the SMS Reference Number. This Reference Number is allocated by the MSC or SGSN that processes the Short Message. It may be used by the gsmSCF for inclusion in a gsmSCF SMS record. MSC Address S S This IE carries the E.164 MSC Address. This IE shall be present if the Short Message processing takes place in an MSC. Otherwise shall be absent. SGSN Number S S This IE carries the Global Title of the SGSN. See 3GPP TSÊ23.060Ê[15]. This IE shall be present if the Short Message processing takes place in an SGSN. Otherwise shall be absent. GPRS MS Class C - This IE contains the MS network and radio access capabilities if the short message is being transferred through an SGSN. MS Classmark 2 C - This IE contains the MS classmark 2 if the short message is being transferred through an MSC. IMEI (with software version) C - This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. Note: Refer to 3GPP TSÊ23.040Ê[14] for a description and encoding of the various TP-DUs and RP-DUs. Location Information in MSC is based on the Location Information IE defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name MO MT Description Service area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. VLR number M M See 3GPP TSÊ23.018Ê[12]. Age of location information - M See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - - Not applicable Selected LSA Identity S S This IE is applicable only if SoLSA is supported by the MSC. This IE indicates the LSA identity associated with the current position of the MS. It shall be shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority shall be present. See 3GPP TSÊ23.073Ê[18]. User CSG Information C C See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location Information in SGSN is based on the Location Information For GPRS IE defined in the subclauseÊ11.3.6.1.2. The following differences and clarifications apply: Information element name MO MT Description Service area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E C,E See 3GPP TSÊ23.018Ê[12]. Routeing area ID C C See 3GPP TSÊ23.003Ê[7]. Geographical information C C See 3GPP TSÊ23.032Ê[13]. Geodetic information - - Not applicable Age of location information - - Not applicable Current Location Retrieved - - Not applicable User CSG Information C C See 3GPP TSÊ23.060Ê[15]. 7.6.2 gsmSCF to gsmSSF or gprsSSF information flows 7.6.2.1 Connect SMS 7.6.2.1.1 Description This IF is used to request the gsmSSF or gprsSSF to perform the actions to route the Short Message to a specific destination (for MO SMS) or to deliver the Short Message to the MS (for MT SMS). 7.6.2.1.2 Information Elements Information element name MO MT Description Calling Partys Number O O This IE indicates the subscriber who sent the SMS; possibly changed by the gsmSCF. If the Short Message type is SMS-SUBMIT or SMS-COMMAND, then this IE, if present, it shall replace the RP-Originating-Address in the RP-MO-DATA RPDU (CHOICE set to MSISDN). If the Short Message type is SMS-DELIVER, then this IE, if present, shall replace the TP-Originating-Address in the SMS-DELIVER TPDU. If the Short Message type is SMS-STATUS-REPORT, then this IE, if present, shall be ignored. Destination Subscriber Number O - This IE identifies the Destination short message entity; possibly changed by the gsmSCF. This IE, if present, shall replace the TP-Destination-Address in the SMS-SUBMIT TPDU or SMS-COMMAND-TPDU. SMSC Address O - This IE indicates the SMSC address to which the MO short message shall be submitted; possibly changed by the gsmSCF. This IE, if present, shall replace the RP-Destination-Address in the RP-MO-DATA RPDU (CHOICE set to serviceCentreAddressDA). 7.6.2.2 Continue SMS 7.6.2.2.1 Description This information flow requests the gsmSSF or gprsSSF to proceed normally. The gsmSSF or gprsSSF completes DP processing, and continues with the SMS handling. 7.6.2.2.2 Information Elements This IF contains no information elements. 7.6.2.3 Furnish Charging Information SMS 7.6.2.3.1 Description This IF is used to request the gsmSSF or gprsSSF to include information in the CAMEL specific logical MO SMS or MT SMS record. The logical call record is created when FCI-SMS is received and a logical call record for that short message does not exist. For modelling purposes the logical call record is buffered in the gsmSSF or gprsSSF. The gsmSSF or gprsSSF completes logical call records as defined in the SDLs. Once the logical call record is completed, then its free format data are moved to the corresponding CDR and the logical call record is deleted. The gsmSCF can send multiple concatenated FCIs per Short Message for completion. The total maximum of free format data is 160 octets per SM. The 160 octets may be sent in one or more FCI IFs. If there are incomplete free format data and new FCI IFs is/are received to overwrite the incomplete data, then the incomplete data are discarded and the gsmSCF can send another 160 octets per SM. 7.6.2.3.2 Information Elements Information element name MO MT Description FCI Billing Charging Characteristics M M This IE is described in a table below. FCI Billing Charging Characteristics contains the following information element: Information element name MO MT Description FCIBCCCAMEL Sequence 1 M M This IE is described in a table below. FCIBCCCAMEL Sequence 1 contains the following information elements: Information element name MO MT Description Free Format Data M M This IE contains free format data to be inserted in the CAMEL logical call record. Append Free Format Data O O This IE indicates that the gsmSSF or gprsSSF shall append the free format data to the Logical MO SMS or MT SMS record. - If this IE is present indicating ""Append"", the gsmSSF or gprsSSF shall append the free format data received in this IF to the free format data already present in the Logical MO SMS or MT SMS record. - If this IE is absent or indicates ""Overwrite"", then the gsmSSF shall overwrite all free format data already present in the Logical MO SMS or MT SMS record, by the free format data received in this IF. If no Logical MO SMS or MT SMS record exists yet, then the gsmSSF or gprsSSF shall ignore this IE. 7.6.2.4 Release SMS 7.6.2.4.1 Description This IF is used to tear down by the gsmSCF an existing SMS transfer. 7.6.2.4.2 Information Elements Information element name MO MT Description RP Cause M M SMS Cause. Indicates the SMS specific cause of the release. The cause is reported to the MS (in the case of MO SMS) or SMSC (in the case of MT SMS). For MO SMS, the RP Cause value shall be used to set the RP-Cause in the RP-ERROR RPDU sent to the MS. 3GPP TSÊ24.011Ê[31] specifies which RP-Cause values may be sent to the MS. For MT SMS, the RP Cause value shall be used to set the RP-Cause in the RP-ERROR RPDU sent to the SMSC. 3GPP TSÊ29.002Ê[34] specifies which RP-Cause values may be sent to the SMSC. 7.6.2.5 Request Report SMS Event 7.6.2.5.1 Description This IF is used to request the gsmSSF or gprsSSF to monitor for an event and to send a notification to the gsmSCF when the event is detected (see Event Report SMS IF). 7.6.2.5.2 Information Elements Information element name MO MT Description SMS Event M M This IE specifies the event or events of which a report is requested. SMS Event contains the following information elements: Information element name MO MT Description Event Type M M This IE specifies the type of event of which a report is requested. Monitor Mode M M This IE indicates how the event shall be reported. 7.6.2.6 Reset Timer SMS 7.6.2.6.1 Description This IF is used to refresh a gsmSSF or gprsSSF timer. 7.6.2.6.2 Information Elements Information element name MO MT Description Timer Value M M This IE specifies the value to which the indicated timer shall be set. Timer ID O O This IE indicates which timer shall be reset. It shall be set to 'Tssf'. 7.6.3 HLR to VLR or SGSN information flows 7.6.3.1 Delete Subscriber Data 7.6.3.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from a VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34] 7.6.3.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in VLR or SGSN. Specific CSI Withdraw O This IE is used to indicate that only MO SMS CSI or MT SMS CSI shall be deleted from the VLR or SGSN. This IE should not be present when CAMEL Subscription Info Withdraw is present. 7.6.3.2 Insert Subscriber Data 7.6.3.2.1 Description This IF is used by the HLR to insert subscriber data in the VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.3.2.2 Information Elements The Insert Subscriber Data contains the following CAMEL specific information elements: Information element name Status Description MO SMS CSI O This IE identifies the subscriber as having MO SMS CAMEL services. MT SMS CSI O This IE identifies the subscriber as having MT SMS CAMEL services. MO SMS CSI contains the following information elements: Information element name Status Description gsmSCF Address M See subclauseÊ7.3.1.1. Service Key M See subclauseÊ7.3.1.2. Default SMS Handling M See subclauseÊ7.3.1.3. CAMEL Capability Handling M See subclauseÊ7.3.1.5. SMS Triggers M See subclauseÊ7.3.1.4. It includes the following trigger: SMS_Collected_Info MT SMS CSI contains the following information elements: Information element name Status Description gsmSCF Address M See subclauseÊ7.3.2.1. Service Key M See subclauseÊ7.3.2.2. Default SMS Handling M See subclauseÊ7.3.2.3. CAMEL Capability Handling M See subclauseÊ7.3.2.6. SMS Triggers M See subclauseÊ7.3.2.4. It includes the following trigger: SMS_Delivery_Request. SMS Trigger Criteria C See subclauseÊ7.3.2.5. 7.6.4 VLR or SGSN to HLR information flows 7.6.4.1 Insert Subscriber Data ack See subclauseÊ4.6.8.1. This information flow is sent by the VLR. 7.6.4.2 Update Location See subclauseÊ4.6.8.3. 7.6.4.3 Update GPRS Location 7.6.4.3.1 Description This IF is used by the SGSN to indicate to the HLR the CAMEL phases and CAMEL phaseÊ4 CSIs offered by the SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.4.3.2 Information Elements Update GPRS location contains the following CAMEL specific information element: Information element name Status Description Supported CAMEL Phases S This IE indicates which CAMEL phases are supported by the SGSN. The SGSN may indicate support of CAMEL phaseÊ3 or higher. It shall be present when the SGSN supports CAMEL. Offered CAMEL4 CSIs S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases"" IE contains support of CAMEL phaseÊ4. Offered CAMEL4 CSIs contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI 7.6.5 VLR to MSC Information Flows 7.6.5.1 Continue CAMEL SMS Handling 7.6.5.1.1 Description This IF is used to instruct the MSC to continue the CAMEL specific handling. 7.6.5.1.2 Information Elements Information element name Status Description MT SMS CSI M This IE contains the CAMEL Subscription Information for MT SMS. IMSI M IMSI of the served subscriber. MSISDN M MSISDN of the served subscriber. 7.6.5.2 Send Info For MO SMS ack 7.6.5.2.1 Description This IF is used to transport MO SMS related subscription data from the VLR to the MSC. It is specified in 3GPP TSÊ29.002Ê[34]. 7.6.5.2.2 Information Elements Information element name Status Description MO SMS CSI C This IE contains the CAMEL Subscription Information for MO SMS. ODB Data C This IE contains ODB data. This information is used to apply ODB for a reconnected Short Message, if needed. CB SS Data C This IE contains CB SS data. This information is used to apply CB for a reconnected Short Message, if needed. 7.6.6 MSC to VLR Information Flows 7.6.6.1 Send Info For MT SMS 7.6.6.1.1 Description This IF is described in 3GPP TSÊ29.002Ê[34]; it is used to request the VLR to provide information to handle an MT SMS. 7.6.6.1.2 Information Elements Send Info For MT SMS contains the following CAMEL specific information element: Information element name Status Description Suppress MT SMS CSI S This IE indicates to the VLR that it shall not return MT SMS CSI to the MSC. This IE shall not be present in the first interrogation; it shall be present in the second interrogation. 8 SS Notifications 8.1 Architecture 8.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture needed to support Supplementary Service (SS) Notifications. FigureÊ8.1 shows the functional entities involved in sending SS Notifications. The architecture is applicable to the third phase of CAMEL or higher. Figure 8.1: Functional architecture for support of SS Notifications HLR: For subscribers requiring CAMEL support, the HLR stores the information relevant to the current subscription regarding SS CSI. The SS CSI is sent to the VLR at Location Update, on Data Restoration or if the SS CSI is updated by administrative action. When processing an invocation of the CCBS supplementary service, the HLR shall send a notification of the invocation of the supplementary service to the gsmSCF if required by the SS CSI. MSC: When processing an invocation of any of the supplementary services ECT, CD and MPTY, the MSC may receive an SS CSI from the VLR, indicating that a notification of the invocation of the supplementary service shall be sent to the gsmSCF. VLR: The VLR stores the SS CSI as a part of the subscriber data for subscribers roaming in the VLR area. gsmSCF: The gsmSCF receives the SS Invocation Notification from the MSC or HLR. 8.1.2 Interfaces defined for SS Notifications This subclause describes the different interfaces applicable to SS Notifications. It specifies on a high level the functions specific to SS Notifications. 8.1.2.1 MSC - gsmSCF interface This interface is used by the MSC to send supplementary service invocation notifications to the gsmSCF. The SS invocations that can be notified to the gsmSCF via this interface are Call Deflection (CD), Explicit Call Transfer (ECT) and Multi Party (MPTY). 8.1.2.2 HLR - gsmSCF interface This interface is used by the HLR to send supplementary service invocation notifications to the gsmSCF. The SS invocation that can be notified to the gsmSCF via this interface is Call Completion to Busy Subscriber (CCBS). 8.1.2.3 VLR - MSC interface This interface is used by the VLR to transfer SS CSI to the MSC. 8.1.2.4 HLR-VLR interface This interface is used by the HLR to send the SS CSI to the VLR or to remove SS CSI from the VLR. 8.2 Description of CAMEL Subscriber Data 8.2.1 Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI) This subclause defines the contents of the Supplementary Service Invocation Notification CAMEL Subscription Information (SS CSI). 8.2.1.1 Notification criteria This data indicates for which supplementary services notifications shall be sent. The supplementary services which may be indicated are ECT, CD, CCBS and MPTY. 8.2.1.2 gsmSCF address Address to be used to access the gsmSCF for a particular subscriber. The address shall be an E.164 number to be used for routeing. 8.2.1.3 CSI state The CSI state indicates whether the SS CSI is active or not. 8.2.1.4 Notification flag The notification flag indicates whether the change of the SS CSI shall trigger Notification on Change of Subscriber Data or not. 8.2.2 gsmSCF address list for CSI The gsmSCF address list indicates a list of gsmSCF addresses to which Notification on Change of Subscriber Data is to be sent. This list is common to all CSI. 8.3 Procedures for CAMEL 8.3.1 Handling of Supplementary Service Invocation Notification At the invocation of any of the services ECT, CD and MPTY the VLR checks whether the criteria for sending a notification are fulfilled, i.e. whether the subscriber is provisioned with the SS CSI and the particular invoked supplementary service is marked in the SS CSI. If this is the case a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS CSI. The processing of the particular SS invocation is not suspended. If the notification criteria are not fulfilled the processing of the particular supplementary service continues unchanged and no notification is sent. The sending of the notification is independent of call related CAMEL processing, i.e. processing indicated by O/D/T/VT CSI. On invocation of ECT, the VLR shall include the SS CSI in the Invoke ECT response message (see Process MAF027 in 3GPP TSÊ23.091Ê[25]) to the MSC if applicable for ECT. On invocation of MPTY, the VLR shall include the SS CSI in the Process MPTY message (see Process MPTY_MAF026 in 3GPP TSÊ23.084Ê[21]) to the MSC if applicable for MPTY. On invocation of CD, the VLR shall include the SS CSI in the Send Info For Incoming Call ack information flow to the MSC if applicable to CD (see 3GPP TSÊ23.072Ê[16]). When a subscriber activates a CCBS request, the HLR checks whether the criteria for sending a notification are fulfilled, i.e. whether - The subscriber is provisioned with an active SS CSI, and - CCBS is marked in the SS CSI. If the criteria are fulfilled, a notification is immediately sent to the gsmSCF given by the gsmSCF address contained in the SS CSI and the processing of the CCBS request continues. Whenever the state of the CCBS request changes (see 3GPP TSÊ23.093Ê[26]), an additional notification is immediately sent to the gsmSCF and the processing of the CCBS request continues. If the criteria are not fulfilled, the processing of the CCBS request continues unchanged and no notifications are sent. At the invocation of the CCBS supplementary service, the HLR checks whether the criteria for sending a notification are fulfilled, i.e. whether the subscriber is provisioned with the SS CSI and the particular invoked supplementary service is marked in the SS CSI. If this is the case, a notification is sent to the gsmSCF given by the gsmSCF address contained in the SS CSI. The processing of the SS invocation is not suspended. If the notification criteria are not fulfilled the processing of the particular supplementary service continues unchanged and no notification are sent. 8.4 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for notification of Supplementary Service invocation. Each Information Element (IE) is marked as Mandatory (M), Specific conditions (S) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. Details of errors and exceptions to these rules are specified in are specified in 3GPP TSÊ29.002Ê[34]. 8.4.1 MSC to gsmSCF information flows 8.4.1.1 SS Invocation Notification 8.4.1.1.1 Description This IF is generated by the MSC when it shall notify the gsmSCF of a supplementary service invocation. 8.4.1.1.2 Information Elements Information element name Status Description Notification Event M This IE indicates the supplementary service invocation, resulting in the SS Invocation Notification IF. Only the following supplementary services are allowed: Explicit Call Transfer, Call Deflection, Multi Party. Notification Event Specific Information S In the case of ECT, the sending entity shall include the called party for each call originated by the subscriber and relevant to the ECT invocation. Note: the subscriber may have originated zero, one or two calls relevant to the ECT service. In the case of CD, the deflected to number shall be included in this IE. In the case of MPTY, this IE shall be omitted. IMSI M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. MSISDN M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. 8.4.2 HLR to VLR information flows 8.4.2.1 Delete Subscriber Data 8.4.2.1.1 Description This IF is used by the HLR to delete CAMEL subscription data from a VLR. Ii is specified in 3GPP TSÊ29.002Ê[34]. 8.4.2.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements for SS Notifications: Information element name Status Description CAMEL Subscription Info Withdraw O This IE identifies that all CSIs shall be deleted from the subscriber data in the VLR. Specific CSI Withdraw O This IE is used to indicate that only SS CSI shall be deleted from the VLR. This IE should not be present when CAMEL Subscription Info Withdraw is present. 8.4.2.2 Insert Subscriber Data 8.4.2.2.1 Description This IF is used by an HLR to update a VLR with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 8.4.2.2.2 Information Elements The Insert Subscriber Data contains the following CAMEL specific information element for SS Notifications: Information element name Status Description SS CSI O This IE is described in subclauseÊ8.2.1. This IE identifies the subscriber as having supplementary service invocation notification services. It contains the Notification Criteria and gsmSCFAddress. When SS CSI is sent to the VLR, it shall not contain a marking for CCBS."
"8.4.3 HLR to gsmSCF information flows 8.4.3.1 SS Invocation Notification This IF is generated by the HLR when it shall notify the gsmSCF of a supplementary service invocation. 8.4.3.1.2 Information Elements Information element name Status Description Notification Event M This IE indicates the supplementary service invocation, resulting in the SS Invocation Notification IF. Only the following supplementary services are allowed: Completion of Calls to Busy Subscriber IMSI M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. MSISDN M This IE identifies the mobile subscriber who has invoked the supplementary service to be notified. B-Number M This IE indicates the destination address of the CCBS request. CCBS Request State M This IE identifies the current state of the CCBS request. It can be one of: - Request; - Recall; - Active; - Completed; - Suspended; - Frozen; - Deleted. 8.4.4 VLR to MSC information flows 8.4.4.1 Invoke SS result 8.4.4.1.1 Description This IF is used by the VLR to send SS CSI to the MSC. This IF is specified in 3GPP TSÊ29.002Ê[34]. 8.4.4.1.2 Information Elements The Invoke SS result contains the following CAMEL specific information element for SS Notifications: Information element name Status Description SS CSI C This IE is included when it is available in the VLR and either ECT or MPTY has been successfully invoked and that supplementary service has been marked for notification. 8.4.4.2 Send Info For Incoming Call ack 8.4.4.2.1 Description This IF is used by the VLR to send SS CSI to the MSC. This IF is specified in 3GPP TSÊ23.018Ê[12]. 8.4.4.2.2 Information Elements The Send Info For Incoming Call ack contains the following CAMEL specific information elements for SS Notifications: Information element name Status Description SS CSI S This IE is included when it is available in the VLR and CD has been successfully invoked and that supplementary service has been marked for notification. 9 Mobility Management 9.1 Architecture 9.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture required to support Mobility Management in CAMEL. FiguresÊ9.1-1 and 9.1-2 show the functional entities involved in CAMEL support of Mobility Management. The architecture in the figureÊ9.1-1 is applicable to the third phase of CAMEL or higher and the architecture in the figureÊ9.1-2 is applicable to the fourth phase of CAMEL. Figure 9.1-1: Functional architecture for CS subscriber support of CAMEL Figure 9.1-2: Functional architecture for GPRS subscriber support of CAMEL gsmSCF: see subclauseÊ3.1. HLR: The HLR contains Mobility management CAMEL Subscription Information (M CSI) for those CS subscribers that require CAMEL control of Mobility Management events and Mobility management GPRS CAMEL Subscription Information (MG CSI) for those GPRS subscribers that require CAMEL control of Mobility Management events. M CSI is sent to the VLR during the Location Update and Restore Data procedures or when M CSI is modified in the HLR. The M CSI is deleted in the VLR with the Delete Subscriber Data procedure. MG CSI is sent to the SGSN during the GPRS Location Updating procedure or when MG CSI is modified in the HLR. The MG CSI is deleted in the SGSN with the Delete Subscriber Data procedure. MS: Mobile Station. MSC: see subclauseÊ4.1. VLR: After having completed a Mobility Management event from a CS subscriber, the VLR may find it necessary to send a notification to the gsmSCF. The content of M CSI indicates which Mobility Management events shall be reported to the gsmSCF. SGSN: After having completed a Mobility Management event from a GPRS subscriber, the SGSN may find it necessary to send a notification to the gsmSCF. The content of MG CSI indicates which Mobility Management events shall be reported to the gsmSCF. 9.1.2 Interfaces defined for CAMEL This subclause describes the different interfaces applicable to CAMEL control of Mobility Management events. It specifies on a high level the functions specific to CAMEL. 9.1.2.2 VLR - gsmSCF interface This interface is used by the VLR to send Mobility Management event notifications to the gsmSCF. When processing a mobility management event, the VLR may find it necessary to send a notification to the gsmSCF, depending on the presence of M CSI for the subscriber and the contents of M CSI. 9.1.2.3 SGSN - gsmSCF interface This interface is used by the SGSN to send Mobility Management event notifications to the gsmSCF. When processing a mobility management event, the SGSN may find it necessary to send a notification to the gsmSCF, depending on the presence of MG CSI for the subscriber and the contents of MG CSI. 9.2 Description of CAMEL Subscriber Data 9.2.1 Mobility Management CAMEL Subscription Information (M CSI) This subclause specifies the contents of the Mobility Management CAMEL Subscription Information (M CSI). 9.2.1.1 Mobility Management Triggers This data indicates which Mobility Management events shall result in a notification to the gsmSCF. One or more events may be marked per subscriber. These events are: - Location update in the same VLR service area. - Location update to another VLR service area. - IMSI attach. - MS initiated IMSI detach (explicit detach). - Network initiated IMSI detach (implicit detach). 9.2.1.2 gsmSCF address This is the address of the gsmSCF where the Mobility Management event notification shall be sent to. The gsmSCF address is in E.164 format. 9.2.1.3 Service Key The Service Key is included in the notification information flow to the gsmSCF. It indicates to the gsmSCF which Service Logic shall be applied. 9.2.1.4 CSI state The CSI state indicates whether the M CSI is active or not. 9.2.1.5 Notification flag The notification flag indicates whether the change of the M CSI shall trigger Notification on Change of Subscriber Data or not. 9.2.2 Mobility Management for GPRS CAMEL Subscription Information (MG CSI) This subclause specifies the contents of the Mobility Management for GPRS CAMEL Subscription Information (MG CSI). 9.2.2.1 Mobility Management Triggers This data indicates which Mobility Management events shall result in a notification to the gsmSCF. One or more events may be marked per subscriber. These events are: - Routeing area update of MS to a different SGSN service area (update from mew SGSN); - Routeing area update of MS to a different SGSN service area (disconnect by detach); - Routeing area update of MS within the same SGSN service area; - GPRS attach (e.g. MS switched on, successful routeing area update after network initiated transfer to ""MS not reachable for paging""); - MS-initiated GPRS detach (e.g. MS switched off); - Network-initiated GPRS detach. - Network-initiated transfer to the ""not reachable for paging"" state (the network has not received a periodic routeing area update from the MS and assumes that the MS is unreachable). 9.2.2.2 gsmSCF address This is the address of the gsmSCF where the Mobility Management event notification shall be sent to. The gsmSCF address is in E.164 format. 9.2.2.3 Service Key The Service Key is included in the notification information flow to the gsmSCF. It indicates to the gsmSCF which Service Logic shall be applied. 9.2.2.4 CSI state The CSI state indicates whether the MG CSI is active or not. 9.2.2.5 Notification flag The notification flag indicates whether the change of the MG CSI shall trigger Notification on Change of Subscriber Data or not. 9.2.3 gsmSCF address list for CSI The gsmSCF address list indicates the gsmSCF addresses to which Notification on Change of Subscriber Data shall be sent. This list is common to all CSI. 9.3 Procedures for Mobility management 9.3.1 Procedures for Mobility management for CS subscriber The different procedures for Mobility Management are shown in Figures 9.2-1 to 9.2-5. Figure 9.2-1: Location Update within a single VLR Service Area. (The VLR Service area may be in the HPLMN or in the VPLMN.); Figure 9.2-2: Location Update from one VLR Service Area to another VLR Service Area. (Both VLR Service Areas are in the HPLMN or in the same VPLMN.); Figure 9.2-3: Location Update from one PLMN to another PLMN; - update from HPLMN to VPLMN; - update from VPLMN to HPLMN; - update from one VPLMN to another VPLMN. Figure 9.2-4: IMSI Detach (in HPLMN or in VPLMN); - explicit detach (the MS has been switched off by the subscriber); - implicit detach (the network has not received a periodic paging update from the MS and assumes that the MS is switched off or unreachable). Figure 9.2-5: IMSI Attach (in HPLMN or in VPLMN); - attach (the MS has been switched on by the subscriber - subscription data is still available in the VLR, no location update is needed). Figure 9.2-1: Location Update within a single VLR Service Area Figure 9.2-2: Location Update from one VLR Service Area to another VLR Service Area Figure 9.2-3: Location Update from one PLMN to another PLMN Figure 9.2-4: IMSI Detach (implicit/explicit) Figure 9.2-5: IMSI Attach When a Mobility Management Event has taken place and the processing has been completed, then the VLR may find it necessary to send a notification to the gsmSCF. The processing of the Mobility Management event in the VLR is not suspended by the sending of the notification nor is it in any way affected by the notification. The sending of a Mobility Management notification to gsmSCF is independent of other CAMEL subscription data for a subscriber. E.g. a subscriber may have M CSI without O CSI or VT CSI. The sending of a Mobility Management event notification is subscription based. Refer to subclauseÊ9.2.1 for a description of M CSI and the different Mobility Management events that may lead to a notification to the gsmSCF. 9.3.1.1 Procedure descriptions 9.3.1.1.1 Procedure Set_Notification_Type This procedure is called from process Update_Location_VLR in 3GPP TSÊ23.012Ê[10]. It checks the information element 'Location Update Type', which the VLR receives from the MSC via MAP_UPDATE_LOCATION_AREA service. This element identifies the type of Location Update requested by the mobile station. The possible values of this parameter are specified in 3GPP TSÊ24.008Ê[30]. The type of Location Update that was requested by the mobile station determines which Mobility Management notification information flow shall be sent to the gsmSCF. The values 'Periodic Updating' and 'Reserved' shall not lead to a Mobility Management notification to the gsmSCF. Figure 9.-1a: Procedure Set_Notification_Type (sheet 1) 9.3.1.1.2 Procedure Notify_gsmSCF This procedure is called from the process 'Update_Location_Area_VLR' and process 'Detach_IMSI_VLR' in 3GPP TSÊ23.012Ê[10]. It is also called from the process 'Update_Location_VLR' in 3GPP TSÊ29.002Ê[34]. The calling process passes on the variable 'Notify' to the procedure 'Notify_gsmSCF'. This variable indicates which Mobility Management notification may be necessary to be sent to the gsmSCF. If this variable has a value NULL, then no notification shall be sent to the gsmSCF. If a notification may be necessary to be sent to the gsmSCF, then the procedure checks the presence of M CSI. - If M CSI is present and the Mobility Management event indicated in the variable 'Notify' is marked in M CSI, then a notification shall be sent to the gsmSCF. - If M CSI is not present or the Mobility Management event indicated in the variable 'Notify' is not marked in M CSI, then no notification shall be sent to the gsmSCF. Figure 9.3-1: Procedure Notify_gsmSCF (sheet 1) 9.3.2 Procedures for Mobility management for GPRS subscriber The different procedures for Mobility Management are shown in figures 9.4-1 to 9.4-5. Figure 9.4-1: Routeing Area Update within SGSN Service Area Figure 9.4-2: Routeing Area Update from one SGSN Service Area to another SGSN Service Area Figure 9.4-3: Routeing Area Update from one PLMN to another PLMN Figure 9.4-4: Attach of MS Figure 9.4-5: GPRS detach When a Mobility Management Event has taken place and the processing has been completed, then the SGSN may have to send a notification to the gsmSCF. The sending of a Mobility Management notification to gsmSCF is independent of other CAMEL subscription data for a subscriber. E.g. a subscriber may have MG CSI without GPRS CSI. The sending of a Mobility Management event notification is subscription based. Refer to subclauseÊ9.2.2 for a description of MG CSI and the different Mobility Management events that may lead to a notification to the gsmSCF. 9.3.2.1 Procedure CAMEL_PS_Notification This procedure is called from processes in 3GPP TSÊ23.060Ê[15]. When this procedure is called, it checks the presence of MG CSI. If there is no MG CSI, then no notification is sent to the gsmSCF. Figure 9.5-1: Procedure CAMEL_PS_Notification (sheet 1) Figure 9.6-1: Procedure Set_PS_Notification_Type (sheet 1) Figure 9.7-1: Procedure Notify_PS_gsmSCF (sheet 1) 9.4 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for Mobility Management control. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E), Optional (O) or not applicable (-) for each different entity involved: VLR (VLR) and SGSN (SGSN) where distinction is applicable. If the IEs in one table apply in both VLR and SGSN, then the IEs are marked in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. An 'O'ÊIE may be included or omitted as required by the service logic. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support; - The VLR shall functionally support all IEs which can be sent to it; - The SGSN shall functionally support all IEs which can be sent to it. 9.4.1 VLR or SGSN to gsmSCF information flows 9.4.1.1 Mobility Management event Notification 9.4.1.1.1 Description This IF is generated by the VLR or SGSN to notify the gsmSCF of a Mobility Management event. 9.4.1.1.2 Information Elements Information element name VLR SGSN Description Event Met M M This IE indicates the type of Mobility Management event that lead to the notification. Refer to subclauseÊ9.2.1.1 for the CS subscriber and subclauseÊ9.2.2.1 for the GPRS subscriber. Service Key M M This IE indicates the Service Logic that the gsmSCF shall apply. IMSI M M This IE identifies the mobile subscriber to whom the Mobility Event applies. Basic MSISDN M M This IE identifies the mobile subscriber to whom the Mobility Event applies. Location Information for CS subscriber C - This IE is described in a table below. This IE indicates the current location of the MS. Location Information for GPRS subscriber - C This IE indicates the current location of the MS which is equivalent to the location info SGSN IE in subclauseÊ7.6.1.2. Supported CAMEL Phases M M This IE indicates the CAMEL Phases that are supported by the sending entity (VMSC/VLR or SGSN) in which the MS is registered after the mobility management event. Offered CAMEL4 Functionalities M - This IE is described in subclause 4.6.1.8. It indicates the CAMEL phaseÊ4 functionalities offered by the VMSC/VLR. Location Information for CS subscriber is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number M See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved - Not applicable Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity S This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18]. User CSG Information C See 3GPP TSÊ23.060Ê[15]. E-UTRAN Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C,E See 3GPP TSÊ23.018Ê[12]. 9.4.2 SGSN to HLR information flows 9.4.2.1 Update GPRS Location See subclauseÊ6.6.4.2. 9.4.3 VLR to HLR information flows 9.4.3.1 Update Location See subclauseÊ4.6.8.3. 9.4.3.2 Restore Data See subclauseÊ4.6.8.4. 9.4.4 HLR to VLR or SGSN information flows 9.4.4.1 Delete Subscriber Data 9.4.4.1.1 Description This IF is used by an HLR to delete CAMEL subscription data from a VLR or SGSN. It is specified in 3GPP TSÊ29.002Ê[34]. 9.4.4.1.2 Information Elements The Delete Subscriber Data IF contains the following CAMEL specific information elements for Mobility Management: Information element name VLR SGSN Description CAMEL Subscription Info Withdraw O O This IE identifies that all CSIs shall be deleted from the subscriber data in VLR or SGSN. Specific CSI Withdraw O O This IE is used to indicate that only M CSI or MG CSI shall be deleted from the VLR or SGSN respectively. It should not be present when CAMEL Subscription Info Withdraw is present. 9.4.4.2 Insert Subscriber Data 9.4.4.2.1 Description This IF is used by an HLR to update a VLR or SGSN with certain subscriber data. This IF is specified in 3GPP TSÊ29.002Ê[34]. 9.4.4.2.2 Information Elements Insert Subscriber Data contains the following CAMEL specific information elements for Mobility Management: Information element name VLR SGSN Description M CSI O - This IE identifies the CS subscriber as having mobility management notification services. It contains the events that shall be reported, the gsmSCF Address and the Service Key. MG CSI - O This IE identifies the GPRS subscriber as having mobility management notification services. It contains the events that shall be reported, the gsmSCF Address and the Service Key. M CSI contains the following information elements: Information element name Status Description GsmSCF Address M This IE is described in subclauseÊ9.2.1. Service Key M This IE is described in subclauseÊ9.2.1. Mobility Management Triggers M This IE indicates which Mobility Management events shall be reported to the gsmSCF. It shall contain one or more of the following elements: - Location update in the same VLR service area - Location update to another VLR service area - IMSI attach - MS initiated IMSI detach (explicit detach) - Network initiated IMSI detach (implicit detach) MG CSI contains the following information elements: Information element name Status Description GsmSCF Address M This IE is described in subclauseÊ9.2.2. Service Key M This IE is described in subclauseÊ9.2.2. Mobility Management Triggers M This IE is described in subclauseÊ9.2.2. 10 Control and interrogation of subscription data Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 10.1 Architecture 10.1.1 Functional Entities used for CAMEL This subclause describes the functional architecture required to support control and interrogation of subscription data. FigureÊ10.1 shows the functional entities involved in CAMEL support of control and interrogation of subscription data. Figure 10.1: Functional architecture for support of control and interrogation of subscription data gsmSCF: see subclauseÊ3.1. HLR: The HLR may provide an interface to the gsmSCF for the Any Time Subscription Interrogation and Any Time Modification procedures. The gsmSCF may provide an interface to the HLR for the Notify Subscriber Data Change procedure. 10.1.2 Interfaces defined for CAMEL This subclause describes the interface applicable to CAMEL control of subscription data. It specifies on a high level the functions specific to CAMEL. 10.1.2.1 gsmSCF - HLR This interface is used by the gsmSCF to interrogate or modify information in the HLR. As a network operator option, the HLR may refuse to provide or modify the information requested by the gsmSCF. This interface is also used by the HLR to notify the gsmSCF of a change of subscriber data. 10.2 Procedures for CAMEL 10.2.1 Any Time Subscription Interrogation Handling of Any Time Interrogation for Subscription Information Retrieval involves the following process: - CAMEL_ATSI_HLR. If an OSS needs the Subscription Information, the gsmSCF initiates a transaction to the HLR by sending an Any Time Subscription Interrogation Request. Figure 10.2-1: Process CAMEL_ATSI_HLR (sheet 1) Figure 10.2-2: Process CAMEL_ATSI_HLR (sheet 2) 10.2.2 Any Time Modification Handling of Any Time Modification involves the following process: - CAMEL_ATM_HLR. The following procedures are involved: - ATM_Modify_Data This procedure checks which data shall be modified and calls the appropriate data modification procedure. - ATM_Modify_CSI_Data If the CSI indicated in the ATM request is not available in the HLR, then an error is returned. Otherwise, the CSI state and/or Notification-to-CSE flag are set as instructed with the ATM request. - ATM_Modify_CF_Data When only the SS-code and (optionally) a Basic Service code are present in the ATM request, then all Call Forwarding data belonging to this SS code and basic service code is erased, the associated notificationToCSE flag is unchanged and the SS-Status is amended according to the state transition model defined in 3GPP TSÊ23.082Ê[20]. Otherwise, the behaviour is as follows: - If a valid SS-status (i.e., the content of the SS-status parameter takes one of the values defined in the State Transition Model for the corresponding Call Forwarding supplementary service, as specified in 3GPP TSÊ23.082Ê[20]) is present in the ATM request, then an SS state transition is performed. - If a valid FTN, FTN sub address or No Reply Condition Time is present in the ATM request, then the indicated variable is modified. - Before modification of CF data (SS state changed to 'registered', insert or change of FTN), the interaction checks between CF and ODB and between CF and CB shall be performed as described in 3GPP TSÊ23.015Ê[11] and TSÊ23.082Ê[20] respectively. The CF data shall only be modified if the changed new CF data does not conflict with the existing ODB or CB entries. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - If the modification is partially successful (e.g. succeeds for one Basic Service but fails for another Basic Service), then the operation is partially accepted by the HLR. The accepted changes are made in the HLR and the changed data is sent in the ATM acknowledgement. - ATM_Modify_CB_Data When only the SS-code and (optionally) a Basic Service code are present in the ATM request, then all Call Barring belonging to this SS code and basic service code is deactivated, the associated notificationToCSE flag is unchanged and the SS-Status is amended according to the state transition model defined in 3GPP TSÊ23.088Ê[23]. Otherwise, the behaviour is as follows: - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for the corresponding Call Barring supplementary service, as specified in 3GPP TSÊ23.088Ê[23]) is present in the ATM request, then an SS state transition is performed. - Before modification of CB data (SS state), the interaction checks between CF and CB shall be performed as described in 3GPP TSÊ23.088Ê[23]. The CB data shall only be modified if the changed new CB data does not conflict with the existing CF entries. - If a valid Password or 'Wrong password attempt counter' is present in the ATM request, then the indicated variable is modified. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_ODB_Data - If ODB data is not present in the ATM request, then it is assumed that the ODB data is not modified. When present, the modification is done by overwriting the existing ODB data. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - If the modification is partially successful (e.g. succeeds for one Basic Service but fails for another Basic Service), then the operation is partially accepted by the HLR. The accepted changes are made in the HLR and the changed data is sent in the ATM acknowledgement. - ATM_Modify_IP-SM-GW_Data - If Modification Instruction is ""activate"", the IP-SM-GW address is stored if not already pre-configured in the HLR and the process Subscriber_Present_HLR is invoked (see 3GPP TSÊ23.012Ê[10]). - If Modification Instruction is ""deactivate"" and there is no IP-SM-GW address pre-configured in the HLR, the stored IP-SM-GW address is deleted. - ATM_Modify_CW_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Call Waiting, as specified in 3GPP TSÊ23.083Ê[48]) is present in the ATM request, then the Call Waiting state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CH_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Call Hold, as specified in 3GPP TSÊ23.083Ê[48]) is present in the ATM request, then the Call Hold state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_ECT_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for Explicit Call Transfer, as specified in 3GPP TSÊ23.091Ê[25]) is present in the ATM request, then the Explicit Call Transfer state is changed accordingly, - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CLIP_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for CLIP, as specified in 3GPP TSÊ23.081Ê[47]) is present in the ATM request, then the Calling Line Identification Presentation state is changed accordingly, - If the Override Category is present, the Override Category is changed accordingly. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. - ATM_Modify_CLIR_Data - If a valid SS-status (i.e., the content of the SS-Status parameter takes one of the values defined in the State Transition Model for CLIR, as specified in 3GPP TS 23.081Ê[47]) is present in the ATM request, then the Calling Line Identification Restriction state is changed accordingly, - If the Override Category is present, the CLI Restriction Option is changed accordingly. - If an instruction to modify the notification-to-CSE flag is present in the ATM request, then the notification-to-CSE flag is modified. After having executed the Any Time Modification instruction from the gsmSCF, the HLR calls the procedure CAMEL_NSDC_HLR, which sends notifications to gsmSCF(s), if required. Figure 10.3-1: Process CAMEL_ATM_HLR (sheet 1) Figure 10.4-1: Procedure ATM_Modify_Data (sheet 1) Figure 10.4-2: Procedure ATM_Modify_Data (sheet 2) Figure 10.5-1: Procedure ATM_Modify_CSI_Data (sheet 1) Figure 10.6-1: Procedure ATM_Modify_CF_Data (sheet 1) Figure 10.6-2: Procedure ATM_Modify_CF_Data (sheet 2) Figure 10.7-1: Procedure ATM_Modify_CB_Data (sheet 1) Figure 10.7-2: Procedure ATM_Modify_CB_Data (sheet 2) Figure 10.8-1: Procedure ATM_Modify_ODB_Data (sheet 1) Figure 10.9-1: Procedure ATM_Modify_IP-SM-GW_Data (sheet 1) Figure 10.10-1: Procedure ATM_Modify_CH_Data (sheet 1) Figure 10.11-1: Procedure ATM_Modify_CW_Data (sheet 1) Figure 10.12-1: Procedure ATM_Modify_ECT_Data (sheet 1) Figure 10.13-1: Procedure ATM_Modify_CLIP_Data (sheet 1) Figure 10.14-1: Procedure ATM_Modify_CLIR_Data (sheet 1) 10.2.3 Notify Subscriber Data Change Changes of CSI, Call Forwarding data, Call Barring data, Call Waiting data, Call Hold data, Explicit Call transfer data, Calling line Identification Presentation data, Calling line Identification Restriction data or ODB data shall be notified only if the corresponding data is marked with the Notification-to-CSE flag. The HLR maintains a list of gsmSCF address(es) for Call Forwarding Data, Call Barring Data, ODB, Call Waiting data, Call Hold data, Explicit Call transfer data, Calling line Identification Presentation data, Calling line Identification Restriction data and CSI. When any of these items has been modified, a notification shall be sent to each gsmSCF in the corresponding list. The sending of a notification to the gsmSCF may be triggered by the following processes: - subscriber data change by administrative procedure; - subscriber data changed by subscriber; - subscriber data changed by Any Time Modification request from gsmSCF; - subscriber data changed due to a change of other subscriber data; - subscriber data change due to Location Update. When a change of subscriber data is requested by Any Time Modification, Any Time Modification acknowlegement is returned to the requesting gsmSCF confirming the status of the altered data. Separate Notifications of subscriber data change shall also be returned to the requesting gsmSCF for each other piece of altered data, but these shall not contain the requested change. Each gsmSCF shall be notified only once. Multiple occurrence of gsmSCF Address in these lists shall not lead to multiple notification. Handling of Notify Subscriber Data Change involves the following procedure: - CAMEL_NSDC_HLR. If a change of subscriber data needs to be notified to the gsmSCF, then the HLR initiates a transaction to the gsmSCF by sending Notify Subscriber Data Change information flow. Figure 10.9-1: Procedure CAMEL_NSDC_HLR (sheet 1) 10.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for control and interrogation of subscription data. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or Optional (O) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. An 'O'ÊIE may be included or omitted as required by the service logic. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF and the IP-SM-GW may silently discard any IE which it does not functionally support. - The HLR shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 10.3.1 gsmSCF to HLR information flows 10.3.1.1 Any Time Modification Request 10.3.1.1.1 Description This IF is used to modify information in the HLR at any time. 10.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN Modification Request For Call Forwarding SS Data E This IE is described in a table below. This IE indicates the data of Call Forwarding data to be modified. Modification Request For Call Barring SS Data E This IE is described in a table below. This IE indicates the data of call barring data to be modified. Modification Request For Operator Determined Barring Data E This IE is described in a table below. This IE indicates the data of operator determined barring data to be used. Modification Request For CAMEL Subscription Information E This IE is described in a table below. This IE indicates the Modification Request for CAMEL Subscription Information. Modification Request For Call Waiting SS Data E This IE is described in a table below. This IE indicates the data of Call Waiting data to be modified. Modification Request For Call Hold SS Data E This IE is described in a table below. This IE indicates the data of Call Hold data to be modified. Modification Request For Calling Line Identification Presentation SS Data E This IE is described in a table below. This IE indicates the data of Calling Line Identification Presentation data to be modified. Modification Request For Calling Line Identification Restriction SS Data E This IE is described in a table below. This IE indicates the data of Calling Line Identification Restriction data to be modified. Modification Request For Explicit Call Transfer SS Data E This IE is described in a table below. This IE indicates the data of Explicit Call Transfer data to be modified. Modification Request For Call Forwarding SS Data contains the following information elements: Information element name Status Description SS Code M This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Modification acknowledgement IF, only the following supplementary service codes are allowed for this IE; - call forwarding unconditional; - call forwarding on mobile subscriber busy; - call forwarding on no reply; - call forwarding on mobile subscriber not reachable. Basic Service O See 3GPP TSÊ29.002Ê[34]. SS Status O See 3GPP TSÊ23.011Ê[9]. Provisioning and withdrawal are not allowed for the gsmSCF. Forwarded-to Number O See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress O See 3GPP TSÊ29.002Ê[34]. No Reply Condition Time O See 3GPP TSÊ23.082Ê[20]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Barring SS Data contains the following information elements: Information element name Status Description SS Code M This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Modification acknowledgement IF, only the following supplementary service codes are allowed for this IE; - barring of all outgoing calls; - barring of outgoing international calls; - barring of outgoing international calls except those directed to the home PLMN; - barring of all incoming calls; - barring of incoming calls when roaming outside home PLMN Country. Basic Service O See 3GPP TSÊ29.002Ê[34]. SS Status O See 3GPP TS 23.011Ê[9]. Provisioning and withdrawal are not allowed for the gsmSCF. Password O See 3GPP TSÊ23.011Ê[9]. Wrong password attempts counter O See 3GPP TSÊ23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Operator Determined Barring Data contains the following information elements: Information element name Status Description ODB data O This IE contains ODB General Data and ODB HPLMN Specific Data to be imposed by this IF. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For CAMEL Subscription Information contains the following information elements: Information element name Status Description Requested CSI M This IE indicates which CSI shall be modified. Only one CSI may be changed in one ATM Request. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modify CSI State O This IE contains an instruction to activate or de-activate the CSI. Modification Request For Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Hold Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Call Waiting Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. Override Category O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. Modification Request For Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status O See 3GPP TS 23.011Ê[9]. CLI Restriction Option O See 3GPP TS 23.011Ê[9]. Modify Notification Flag O This IE contains an instruction to activate or de-activate the Notification-to-CSE flag. 10.3.1.2 Any Time Subscription Interrogation Request 10.3.1.2.1 Description This IF is used to request subscription information from the HLR at any time. 10.3.1.2.2 Information Elements Information element name Status Description GsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of subscriber information being requested: This shall consist of one or more of the following list: - supplementary service; this information is described in a table below, - Operator Determined Barring; - CAMEL Subscription Information; this information is described in a table below, - supported CAMEL phases in VLR; - supported CAMEL phases in SGSN; - MSISDNs and Basic Service Codes associated with the Subscriber Identity. - CSG Subscription Data, see 3GPP TS 29.002Ê[34]; - Call Waiting SS Data see 3GPP TS 29.002[34]; - Call Hold SS Data see 3GPP TS 29.002[34]; - Explicit Call Transfer Data see 3GPP TS 29.002[34]; - Calling Line Identification Presentattion Data see 3GPP TS 29.002[34]; - Calling Line Identification Restriction Data see 3GPP TS 29.002[34]. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN."
"Supplementary service contains the following information elements: Information element name Status Description SS Code M This IE indicates a supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Due to a restriction of the Any Time Subscription Interrogation acknowledgement IF, only the following supplementary service codes are allowed for this IE; - call forwarding unconditional; - call forwarding on mobile subscriber busy; - call forwarding on no reply; - call forwarding on mobile subscriber not reachable; - barring of all outgoing calls; - barring of outgoing international calls; - barring of outgoing international calls except those directed to the home PLMN; - barring of all incoming calls; - barring of incoming calls when roaming outside home PLMN Country. Basic Service O See 3GPP TSÊ29.002Ê[34]. CAMEL subscription information shall contain one of the following information elements: Information element name Status Description CAMEL Subscription Info S,E This IE indicates which CAMEL Subscription Information is requested. It shall be one of the following elements: O CSI/T CSI/VT CSI/TIF CSI/GPRS CSI/MO SMS CSI/SS CSI/M CSI/D CSI. Additional Requested CAMEL Subscription Info S,E This IE indicates which CAMEL Subscription Information is requested. It shall be one of the following elements: MT SMS CSI/ MG CSI. 10.3.1.3 Notify Subscriber Data Change response 10.3.1.3.1 Description This IF is used by the gsmSCF to respond to the HLR of the change of subscriber data notify. 10.3.1.3.2 Information Elements This IF contains no information elements. 10.3.2 HLR to gsmSCF information flows 10.3.2.1 Any Time Modification ack 10.3.2.1.1 Description This IF is used by the HLR to provide the modified information to the gsmSCF. 10.3.2.1.2 Information Elements Information element name Status Description Call Forwarding SS Data S This IE is described in a table below. It shall be present if it was modified. Call Barring SS Data S This IE is described in a table below. It shall be present if it was modified. Operator Determined Barring Information S This IE is described in a table below. It shall be present if it was modified. CAMEL Subscription Information S This IE is described in a table below. It shall be present if it was modified. Call Waiting SS Data S This IE is described in a table below. It shall be present if it was modified. Call Hold SS Data S This IE is described in a table below. It shall be present if it was modified. Calling Line Identification Presentation SS Data S This IE is described in a table below. It shall be present if it was modified. Calling Line Identification Restriction SS Data S This IE is described in a table below. It shall be present if it was modified. Explicit Call Transfer SS Data S This IE is described in a table below. It shall be present if it was modified. Call Forwarding SS Data contains the following information elements: Information element name Status Description SS Code S This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Only the SS code for which the modification applies is sent. Forwarding Feature List S This IE is described in a table below. If a Forwarding Feature List item is modified then all applicable fields within the item shall be sent. All modified Forwarding Feature List items shall be returned. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. The IE shall be sent if it was modified. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Timer C See 3GPP TSÊ23.082Ê[20]. Call Barring SS Data contains the following information elements: Information element name Status Description SS Code S This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Only the SS code for which the modification applies is sent. Call Barring Feature List S This IE is described in a table below. If a Call Barring Feature List item is modified then all applicable fields within the item shall be sent. All modified Call Barring Feature List items shall be returned. Password S See 3GPP TSÊ23.011Ê[9]. The IE shall be sent if it was modified. Wrong Password Attempts Counter S See 3GPP TSÊ23.011Ê[9]. The IE shall be sent if it was modified. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. The IE shall be sent if it was modified. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Information contains the following information elements: Information element name Status Description ODB Data C See subclauseÊ10.3.2.3 Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI S See subclauseÊ4.3.1. It shall be present if it was modified. D CSI S See subclauseÊ4.3.2. It shall be present if it was modified. T CSI S See subclauseÊ4.3.5. It shall be present if it was modified. VT CSI S See subclauseÊ4.3.6. It shall be present if it was modified. TIF CSI S See subclauseÊ4.3.4. It shall be present if it was modified. GPRS CSI S See subclauseÊ6.3.1. It shall be present if it was modified. MO SMS CSI S See subclauseÊ7.3.1. It shall be present if it was modified. MT SMS CSI S See subclauseÊ7.3.2. It shall be present if it was modified. SS CSI S See subclauseÊ8.2.1. It shall be present if it was modified. M CSI S See subclauseÊ9.2.1. It shall be present if it was modified. MG CSI S See subclauseÊ9.2.2. It shall be present if it was modified. Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified. Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. The IE shall be sent if it was modified. Call Hold Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. The IE shall be sent if it was modified. Call Waiting Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. The IE shall be sent if it was modified. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified Override Category S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. The IE shall be sent if it was modified. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status S It shall be present if it was modified CLI Restriction Option S It shall be present if it was modified Notification-to-CSE Flag S This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Restriction SS data. The IE shall be sent if it was modified. 10.3.2.2 Any Time Subscription Interrogation ack 10.3.2.2.1 Description This IF is used by the HLR to provide the requested subscription information to the gsmSCF. 10.3.2.2.2 Information Elements Information element name Status Description Call Forwarding SS Data C This IE is described in a table below. Call Barring SS Data C This IE is described in a table below. Operator Determined Barring Data C This IE is described in a table below. CAMEL Subscription Information C This IE is described in a table below. Supported CAMEL Phases In VLR C This IE indicates the CAMEL phase supported in the VLR. Offered CAMEL4 CSIs In VLR S This IE indicates the CAMEL phaseÊ4 CSIs offered in the VMSC/VLR. It shall be present if the ""Supported CAMEL Phases In VLR"" IE indicates CAMEL phaseÊ4. Supported CAMEL Phases In SGSN C This IE indicates the CAMEL phase supported in the SGSN. Offered CAMEL4 CSIs In SGSN S This IE indicates the CAMEL phaseÊ4 CSIs offered in the SGSN. It shall be present if the ""Supported CAMEL Phases In SGSN"" IE indicates support of CAMEL phaseÊ4. MSISDN-BS-List C This IE indicates the subscriber's MSISDN(s) and their associated Basic Service Codes. (Note) Call Waiting SS Data C This IE is described in a table below. Call Hold SS Data C This IE is described in a table below. Calling Line Identification Presentation SS Data C This IE is described in a table below. Calling Line Identification Restriction SS Data C This IE is described in a table below. Explicit Call Transfer SS Data C This IE is described in a table below. NOTE: The BASIC MSISDN is always first in the list. Call Forwarding SS Data contains the following information elements: Information element name Status Description Forwarding Feature List C This IE is described in a table below Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Time C See 3GPP TSÊ23.082Ê[20]. Call Barring SS Data contains the following information elements: Information element name Status Description Call Barring Feature List C This IE is described in a table below. Password C See 3GPP TSÊ23.011Ê[9]. Wrong Password Attempts Counter C See 3GPP TSÊ23.011Ê[9]. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Bata contains the following information elements: Information element name Status Description ODB General Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate. ODB HPLMN Specific Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI C See subclauseÊ4.3.1. D CSI C See subclauseÊ4.3.2. T CSI C See subclauseÊ4.3.5. VT CSI C See subclauseÊ4.3.6. TIF CSI C See subclauseÊ4.3.4. GPRS CSI C See subclauseÊ6.3.1. MO SMS CSI C See subclauseÊ7.3.1. MT SMS CSI C See subclauseÊ7.3.2. SS CSI C See subclauseÊ8.2.1. M CSI C See subclauseÊ9.2.1. MG CSI C See subclauseÊ9.2.2. Offered CAMEL4 CSIs in VLR contains the following information elements: Information element name Status Description O CSI S This IE indicates the offer of CAMEL phaseÊ4 O CSI D CSI S This IE indicates the offer of CAMEL phaseÊ4 D CSI VT CSI S This IE indicates the offer of CAMEL phaseÊ4 VT CSI MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI Offered CAMEL4 CSIs in SGSN contains the following information elements: Information element name Status Description MT SMS CSI S This IE indicates the offer of CAMEL phaseÊ4 MT SMS CSI MG CSI S This IE indicates the offer of CAMEL phaseÊ4 MG CSI PSI Enhancements S This IE indicates the offer of CAMEL phaseÊ4 Enhancement of Provide Subscriber Information Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. Call Hold Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. Call Waiting Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF Override Category C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was requested by the gsmSCF CLI Restriction Option C It shall be present if it was requested by the gsmSCF Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of C Calling Line Identification Restriction SS data. 10.3.2.3 Notify Subscriber Data Change 10.3.2.3.1 Description This IF is used by the HLR to notify to the gsmSCF of the change of subscriber data. This IF is sent at each time subscriber data is changed. 10.3.2.3.2 Information Elements Information element name Status Description IMSI M The IMSI is used to identify the subscriber. MSISDN M The MSISDN is used to identify the subscriber. Call Forwarding SS Data C This IE is described in a table below. Call Barring SS Data C This IE is described in a table below. Operator Determined Barring Data C This IE is described in a table below. CAMEL Subscription Information C This IE is described in a table below. CSG Subscription Data C See 3GPP TSÊ29.002Ê[34]. It shall be present if it was modified. Call Waiting SS Data C This IE is described in a table below. Call Hold SS Data C This IE is described in a table below. Calling Line Identification Presentation SS Data C This IE is described in a table below. Calling Line Identification Restriction SS Data C This IE is described in a table below. Explicit Call Transfer SS Data C This IE is described in a table below. Call Forwarding SS data contains the following information elements: Information element name Status Description SS Code C This IE indicates Call Forwarding supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Forwarding Feature List C This IE is described in a table below. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Forwarding SS data. Forwarding Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. Compound basic service codes can also be used in this IF if the subscriber has used a compound code when modifying the SS (e.g. all bearer services compound code). SS Status C See 3GPP TSÊ23.011Ê[9]. Forwarded-to Number C See 3GPP TSÊ23.082Ê[20]. Forwarded-to Subaddress C See 3GPP TSÊ29.002Ê[34]. Subscription Options C See 3GPP TSÊ23.082Ê[20]. No Reply Condition Timer C See 3GPP TSÊ23.082Ê[20]. Call Barring SS data contains the following information elements: Information element name Status Description SS Code C This IE indicates Call Barring supplementary service as defined in 3GPP TSÊ22.004Ê[2]. Call Barring Feature List C This IE is described in a table below. Password C See 3GPP TSÊ23.011Ê[9]. Wrong Password Attempts Counter C See 3GPP TSÊ23.011Ê[9]. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Barring SS data. Call Barring Feature List contains 1 to 32 items of the following information elements: Information element name Status Description Basic Service C See 3GPP TSÊ29.002Ê[34]. Compound basic service codes can also be used in this IF if the subscriber has used a compound code when modifying the SS (e.g. all bearer services compound code). SS Status C See 3GPP TSÊ23.011Ê[9]. Operator Determined Barring Data contains the following information elements: Information element name Status Description ODB General Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate. When the ODB general data is removed for the subscriber, this IE indicates that the set of subscribers features is empty. ODB HPLMN Specific Data C This IE indicates the set of subscribers features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. When the ODB HPLMN specific data is removed for the subscriber, this IE indicates that the set of subscribers features is empty. Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of ODB data. CAMEL Subscription Information contains the following information elements: Information element name Status Description O CSI S See subclauseÊ4.3.1. It shall be present if it was modified. D CSI S See subclauseÊ4.3.2. It shall be present if it was modified. T CSI S See subclauseÊ4.3.5. It shall be present if it was modified. VT CSI S See subclauseÊ4.3.6. It shall be present if it was modified. TIF CSI S See subclauseÊ4.3.4. It shall be present if it was modified. GPRS CSI S See subclauseÊ6.3.1. It shall be present if it was modified. MO SMS CSI S See subclauseÊ7.3.1. It shall be present if it was modified. MT SMS CSI S See subclauseÊ7.3.2. It shall be present if it was modified. SS CSI S See subclauseÊ8.2.1. It shall be present if it was modified. M CSI S See subclauseÊ9.2.1. It shall be present if it was modified. MG CSI S See subclauseÊ9.2.2. It shall be present if it was modified. Specific CSI Deleted List S This IE indicates that one or more specific elements of CAMEL Subscription Information have been deleted from the HLR. It shall indicate any of the following; - O CSI (with TDP criteria for O CSI); - T CSI (with TDP criteria for T CSI); - TIF CSI; - D CSI; - VT CSI with TDP criteria for VT CSI; - GPRS CSI; - MO SMS CSI; - MT SMS CSI with TDP criteria for MT SMS CSI; - SS CSI; - M CSI; - MG CSI. This IE shall be present if CSI is/are deleted. Explicit Call Transfer Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Explicit Call Transfer SS data. Call Hold Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Hold SS data. Call Waiting Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Call Waiting SS data. Calling Line Identification Presentation Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified Override Category C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of Calling Line Identification Presentation SS data. Calling Line Identification Restriction Data contains the following information elements: Information element name Status Description SS Status C It shall be present if it was modified CLI Restriction Option C It shall be present if it was modified Notification-to-CSE Flag C This IE indicates whether the gsmSCF is notified of a change of C Calling Line Identification Restriction SS data. 10.3.3 IP-SM-GW to HLR information flows 10.3.3.1 Any Time Modification Request 10.3.3.1.1 Description This IF is used to register the IP-SM-GW for a subscriber in the HLR. 10.3.3.1.2 Information Elements Information element name Status Description IP-SM-GW Address M This IE indicates the address of the interrogating IP-SM-GW. The IP-SM-GW Address shall be in international E.164 format. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN Modification Request For IP-SM-GW Data E This IE is described in a table below. This IE indicates the IP-SM-GW data to be modified. Modification Request For IP-SM-GW Data contains the following information elements: Information element name Status Description Modify Registration Flag M This IE contains an instruction to register or de-register the IP-SM-GW. 10.3.4 HLR to IP-SM-GW information flows 10.3.4.1 Any Time Modification ack 10.3.4.1.1 Description This IF is used by the HLR to acknowledge the registration or deregistration for a subscriber of the IP-SM-GW to the IP-SM-GW. 10.3.4.1.2 Information Elements This IF contains no information elements. 11 Subscriber Location and State retrieval Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 11.1 Architecture 11.1.1 Functional Entities used for CAMEL This subclause describes procedures for the retrieval of subscriber location and subscriber state information. Location Services is only supported in CAMEL PhaseÊ3 and higher. 1) The gsmSCF may request location information of a mobile station from the GMLC via Location Services. The information flow of Location Services is described in 3GPP TSÊ23.271Ê[28] and 25. 305Ê[32]. FigureÊ11.1-1 indicates the functional entities involved in the procedures for the retrieval of location information via location services. 2) The gsmSCF may request any of location information, subscriber state information, IMEI and MS Class of a mobile station from the HLR. Any of location information, subscriber state information, IMEI and MS Class may be requested either from the circuit switched or the packet switched domain. If any of location information, subscriber state information, IMEI and MS Class is requested by the gsmSCF, then the HLR may retrieve this information via the Provide Subscriber Information procedure from either the MSC/VLR or the SGSN. This procedure is defined in subclauseÊ4.5.9 of the present document. The interface for the provision of subscriber location and state information between HLR and MSC/VLR is described in 3GPP TSÊ23.018Ê[12]. The interface for the provision of subscriber location and state information between HLR and SGSN is described in this chapter. FigureÊ11.1-2 indicates the functional entities involved in the procedures for the retrieval of location information and/or subscriber state information from the circuit switched or packet switched domain. Figure 11.1-1: Functional architecture for CAMEL Support of Location Services Figure 11.1-2: Functional architecture for Any Time Interrogation gsmSCF: see subclauseÊ3.1. GMLC: A functional entity that allows external LCS Clients to request real-time information about a Mobile Station. The information that can be requested from the GMLC is the location of the mobile station. HLR: see subclauseÊ4.1. MSC/VLR: see subclauseÊ4.1. SGSN: see subclauseÊ6.1.1. The SGSN stores location and state information for each subscriber. Upon request this information is provided to the HLR. The information flows between the GMLC and functional entities other than the gsmSCF, have not been indicated in the functional architecture shown in figuresÊ11.1. These information flows are outside the scope of the present document. 11.1.2 Interfaces defined for CAMEL This subclause describes the interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 11.1.2.1 gsmSCF - GMLC interface This interface is used by the gsmSCF to request information (Mobile Station location) from the GMLC at any time. 11.1.2.2 GMLC - gsmSCF interface This interface is used by the GMLC to return the requested information (Mobile Station location) to the gsmSCF as requested by the gsmSCF via the Any Time Interrogation procedure. 11.1.2.3 gsmSCF - HLR This interface is used by the gsmSCF to interrogate the HLR. As a network operator option, the HLR may refuse to provide the information requested by the gsmSCF. 11.1.2.4 HLR - gsmSCF This interface is used by the HLR to return the requested information to the gsmSCF as requested by the gsmSCF via the Any Time Interrogation procedure. 11.1.2.5 HLR - SGSN This interface is used by the HLR to request information from the SGSN. 11.1.2.5 SGSN - HLR This interface is used by the SGSN to return the requested information to the HLR. 11.2 Procedures for CAMEL 11.2.1 Location Services Handling of Any Time Interrogation to obtain Location Information involves the following process: - CAMEL_ATI_GMLC. If an OSS needs to retrieve the active location of a Mobile Station, the gsmSCF initiates a transaction to the GMLC by sending a Any Time Interrogation Request. Figure 11.2-1: Process CAMEL_ATI_GMLC (sheet 1) 11.2.2 Any Time Interrogation Handling of Any Time Interrogation to obtain Subscriber State and Location Information involves the following process: - CAMEL_ATI_HLR. If an OSS needs the Subscriber State and/or the Location Information, the gsmSCF initiates a transaction to the HLR by sending an Any_Time_Interrogation Request. Figure 11.3-1: Process CAMEL_ATI_HLR (sheet 1) 11.2.3 Provide Subscriber Information in the SGSN The provision of Subscriber State and Location Information involves the following process and procedures: - CAMEL_Provide_Subscriber_Info_SGSN; - CAMEL_Active_Info_Retrieval_SGSN; - Retrieve_GPRS_MS_Class_If_Required; - Retrieve_IMEI_If_Required. 11.2.3.1 Procedure CAMEL_Provide_Subscriber_Info_SGSN If the SGSN receives a Provide Subscriber Info request, it performs procedures to obtain the requested information. The test ""Active retrieval required"" takes the ""Yes"" exit if any one or more of current location, GPRS MS class or IMEI is indicated in the Provide Subscriber Info request. 11.2.3.2 Procedure CAMEL_Active_Info_Retrieval_SGSN If the SGSN data show that the MS is in the ""Iu Connected"" state (i.e. it has an Iu connection established), the SGSN performs the Location Reporting Control procedure (Direct report) which is defined in 3GPP TSÊ25.413Ê[33]. The test ""Report on change of service area"" takes the ""Yes"" exit if the SGSN has performed the Location Reporting Control procedure with the Request Type IE set to ""Change of service area"". If the SGSN data show that the MS is in the ""A/Gb Ready"" state (i.e. it is transferring packet data over an A/Gb access connection) then the currently stored location information is up to date, and no further action is required. Figure 11.4-1: Process CAMEL_Provide_Subscriber_Info_SGSN (sheet 1) Figure 11.5-1: Procedure CAMEL_Active_Info_Retrieval_SGSN (sheet 1) Figure 11.5-2: Procedure CAMEL_Active_Info_Retrieval_SGSN (sheet 2) Figure 11.6-1: Procedure Retrieve_GPRS_MS_Class_If_Required (sheet 1) Figure 11.7-1: Procedure Retrieve_IMEI_If_Required (sheet 1) 11.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for the retrieval of information about the location and state of a subscriber. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or not applicable (-) in the ""Status"" column. An 'M'ÊIE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E'ÊIEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. A ' 'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stage 2 information. It is not a stage 3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The GMLC shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 11.3.1 gsmSCF to GMLC information flows 11.3.1.1 Any Time Interrogation Request 11.3.1.1.1 Description This IF is used to request information (Mobile Station location) from the GMLC. 11.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of information that is requested. It shall have the following value: - Mobile Station location Mobile Station Identity M This IE identifies the Mobile Station of which the information is requested. The identity shall be either: - IMSI, or - MSISDN 11.3.2 GMLC to gsmSCF information flows 11.3.2.1 Any Time Interrogation ack 11.3.2.1.1 Description This IF is used by the GMLC to provide the requested information to the gsmSCF. 11.3.2.1.2 Information Elements Information element name Status Description Location Information C This IE indicates the location of the Mobile Station. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Location number - Not applicable Service area ID - Not applicable Cell ID - Not applicable Geographical information C See 3GPP TSÊ23.032Ê[13]. The GMLC receives Extended Geographical Information from the MSC. The Extended Geographical Information shall be converted to the Geographical Information by the GMLC. VLR number - Not applicable Current Location Retrieved - Not applicable MSC number C The GMLC receives the MSC number from the HLR in the SendRoutingInfoForLCS MAP message. SGSN number C The GMLC receives the SGSN number from the HLR in the SendRoutingInfoForLCS MAP message. User CSG Information C See 3GPP TS 23.060Ê[15]. 11.3.3 gsmSCF to HLR information flows 11.3.3.1 Any Time Interrogation Request 11.3.3.1.1 Description This IF is used to request information (any one or more of subscriber state, subscriber location, IMEI (with software version) and MS classmark information for the requested domain) from the HLR at any time. 11.3.3.1.2 Information Elements Information element name Status Description Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be either: - IMSI, or - MSISDN. Requested Info M This IE indicates the type of subscriber information being requested. This IE is described in a table below. gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info contains the following information elements: Information element name Status Description Location Information O This IE indicates that the Location Information is requested. Subscriber State O This IE indicates that the Subscriber State is requested. Current Location O,S This IE indicates that the Current Location is requested. This IE shall not be present if Location Information is not present in Requested Info. Location Information in EPS Supported O,S This IE indicates by its presence that Location Information in EPS is supported. This IE should be present if Location Information is present in Requested Info and Location Information in EPS is supported. This IE shall not be present if Location Information is not present in Requested Info. Requested Domain M This IE indicates for which domain the subscriber info is requested. It shall be one of the following: - circuit switched domain; - packet switched domain. IMEI (with software version) O This IE indicates that the IMEI (with software version) is requested. MS class mark information for the requested domain O This IE indicates that the MS classmark information for the indicated domain is requested. Requested Info shall contain one or more of the following information elements: - Location Information; - Subscriber State; - IMEI (with software version); - MS classmark information for the requested domain. 11.3.4 HLR to gsmSCF information flows 11.3.4.1 Any Time Interrogation ack 11.3.4.1.1 Description This IF is used by the HLR to provide the requested subscriber location and/or subscriber state information to the gsmSCF. 11.3.4.1.2 Information Elements Information element name Status Description Location Information C, E1 This IE indicates the location of the served subscriber in the MSC/VLR. It shall be present only if requested by the gsmSCF. Location Information For GPRS C, E1 This IE indicates the location of the served subscriber in the SGSN. It shall be present only if requested by the gsmSCF. Subscriber State S, E2 This IE indicates the state of the MS in the CS domain. It shall be present only if requested by the gsmSCF. The possible values of the IE are: - CAMELBusy: The VLR has indicated that the MS is engaged in a transaction for a mobile originating or terminated circuit-switched call. - NetworkDeterminedNotReachable: The HLR or VLR has indicated that the network can determine from its internal data that the MS is not reachable. - AssumedIdle: The VLR has indicated that the state of the MS is neither ""CAMELBusy"" nor ""NetworkDeterminedNotReachable"". - NotProvidedFromVLR: The VLR did not provide any information on subscriber state even though it was requested. PS Domain Subscriber State S, E2 This IE indicates the state of the MS in the PS Domain. It shall be present only if requested by the gsmSCF. The possible values of the IE are: - Detached (see subclauseÊ11.3.5.1). - CAMEL attached, MS not reachable for paging (see subclauseÊ11.3.5.1). - CAMEL attached, MS may be reachable for paging (see subclauseÊ11.3.5.1). - CAMEL PDP active, MS not reachable for paging (see subclauseÊ11.3.5.1). - CAMEL PDP active, MS may be reachable for paging (see subclauseÊ11.3.5.1). - Not provided from SGSN: The SGSN does not support Provide Subscriber Info or it did not provide any information on subscriber state even though it was requested. - NetworkDeterminedNotReachable: The HLR has indicated that the network can determine from its internal data that the MS is not reachable. PDP Context Information List C This IE indicates the PDP context information (see the table in subclauseÊ11.3.5.1) for each PDP context which is active for the MS. It shall be present if the PS domain Subscriber State has the value ""CAMEL PDP active, MS not reachable for paging"" or ""CAMEL PDP active, MS may be reachable for paging""; otherwise it shall be absent. IMEI (with software version) C This IE contains the IMEISV (as defined in 3GPP TSÊ23.003Ê[7]) of the ME in use by the served subscriber. It shall be present only if requested by the gsmSCF. MS Classmark 2 C This IE contains the MS classmark 2, which is returned by the MS when it responds to paging in the CS domain. It shall be present only if requested by the gsmSCF. GPRS MS Class C This IE contains the MS network and radio access capabilities. It shall be present only if requested by the gsmSCF. Location Information is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. VLR Number C See 3GPP TSÊ23.018Ê[12]. The HLR shall include the internally stored VLR Number. Location area ID C,E See 3GPP TSÊ23.003Ê[7]. Selected LSA Identity C This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA Id with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18]. MSC number C E.164 number which identifies the VMSC in whose area the subscriber is currently registered. See 3GPP TSÊ23.003Ê[7]. If the HLR receives the MSC number from the VLR in the Provide Subscriber Info ack IF then the HLR shall ignore the MSC number. User CSG Information C See 3GPP TS 23.060Ê[15]. E-UTRAN Cell ID C, E See 3GPP TSÊ23.018Ê[12]. Tracking area ID C, E See 3GPP TSÊ23.018Ê[12]. Location Information for GPRS is defined in the subclause 11.3.6.1.2. The following differences apply: Information element name Status Description SGSN Number C See subclause 11.3.6.1.2. The HLR shall include the internally stored SGSN Number. 11.3.5 HLR to SGSN information flows 11.3.5.1 Provide Subscriber Info 11.3.5.1.1 Description This IF is used by the HLR to request information (subscriber state and/or location) from the SGSN at any time. 11.3.5.1.2 Information Elements This IF is defined in 3GPP TSÊ23.018Ê[12]. The following differences apply: Information element name Status Description LMSI - Not applicable. Requested Info M This IE indicates which of the following information the HLR requires: - Subscriber location; - Subscriber state; - Current location; - IMEI & Software version; - GPRS MS classmark information. 11.3.6 SGSN to HLR information flows 11.3.6.1 Provide Subscriber Info ack 11.3.6.1.1 Description This IF is used by the SGSN to provide the requested subscriber location and/or subscriber state information to the HLR. 11.3.6.1.2 Information Elements This IF is defined in 3GPP TSÊ23.018Ê[12]."
"The following differences apply: Information element name Status Description Subscriber State - Not applicable. PS domain Subscriber State C This IE indicates the status of the MS in the PS Domain. It shall be present only if requested by the HLR. The possible values of the IE are: - Detached: The SGSN has determined from its internal data that the MS is not attached to the network. - CAMEL attached, MS not reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network, but there is no PDP Context active, and the MS is not reachable for paging. - CAMEL attached, MS may be reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network, but there is no PDP Context active; the SGSN has not determined from its internal data that the MS is not reachable for paging. - CAMEL PDP active, MS not reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network there is at least on PDP context active, and the MS not reachable for paging. - CAMEL PDP active, MS may be reachable for paging: The SGSN has determined from its internal data that the MS is attached to the network and there is at least one PDP context active; the SGSN has not determined from its internal data that the MS is not reachable for paging. PDP Context Information List S This IE is described in a table below. This IE indicates the PDP context information for each PDP context which is active for the MS. It shall be present if the PS domain Subscriber State has the value ""CAMEL PDP active, MS not reachable for paging"" or ""CAMEL PDP active MS may be reachable for paging""; otherwise it shall be absent. Location Information For GPRS C This IE is described in a table below. It indicates the location of the MS. It shall be present only if requested by the HLR. IMEI (with software version) C This IE contains the IMEI & software version of the ME in use by the served subscriber. It shall be present only if requested by the HLR. GPRS MS Class C This IE contains the MS network and radio access capabilities. It shall be present only if requested by the HLR. PDP Context Information includes the following information elements: Information element name Status Description PDP Context Identifier M Index of the PDP context. PDP State C Packet data protocol state, INACTIVE or ACTIVE. PDP Type C PDP type, e.g., PPP or IP. PDP Address C PDP address, e.g., an IP address. APN Subscribed C The APN received from the HLR. APN in Use C The APN currently used. NSAPI C Network layer Service Access Point Identifier. TI C Transaction Identifier. TEID for Gn/Gp C Tunnel Endpoint Identifier for the Gn and Gp interfaces. TEID for Iu C Tunnel Endpoint Identifier for the Iu interface. GGSN Address in Use C The IP address of the GGSN currently used. The SGSN shall report the GGSN address in the same IP version as in the S CDR. See 3GPP TSÊ32.251Ê[38]. Subscribed QoS C The quality of service profile subscribed. Requested QoS C The quality of service profile requested. Negotiated QoS C The quality of service profile negotiated. Charging ID C Charging identifier, identifies charging records generated by SGSN and GGSN. PDP Context Charging Characteristics C The charging characteristics of this PDP context, e.g., normal, prepaid, flat-rate, and/or hot billing. RNC Address In Use C The IP address of the RNC currently used. Requested QoS Extension S This IE contains a supplement to the Requested QoS IE. It shall be present if the Requested QoS IE is present and the MS requested one or more of the following for the PDP context: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Subscribed QoS Extension S This IE contains a supplement to the Subscribed QoS IE. It shall be present if the Subsribed QoS IE is present and one or more of the following is part of the subscription profile in the HLR: - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Negotiated QoS Extension S This IE contains a supplement to the Negotiated QoS. It shall be present if the Negotiated QoS IE is present and one or more of the following was negotiated between the MS, the SGSN and the GGSN: - Source Statistics Descriptor; - Signalling Indication; - Maximum bit rate for downlink (extended); - Guaranteed bit rate for downlink (extended). Otherwise, it shall be absent. Location Information For GPRS includes the following information elements: Information element name Status Description Service area ID C,E See 3GPP TSÊ23.018Ê[12]. Cell ID C,E See 3GPP TSÊ23.018Ê[12]. Location area ID C,E See 3GPP TSÊ23.018Ê[12]. Routeing area ID C See 3GPP TSÊ23.003Ê[7]. Geographical information C See 3GPP TSÊ23.032Ê[13]. Geodetic information C See ITU TÊQ.763Ê[43]. Age of location information C See 3GPP TSÊ23.018Ê[12]. Current Location Retrieved C See 3GPP TSÊ23.018Ê[12]. SGSN number M Global Title of the SGSN. See 3GPP TSÊ23.060Ê[15]. Selected LSA Identity C This IE is applicable only if SoLSA is supported by the SGSN. This IE indicates the LSA identity associated with the current position of the MS. It shall be present if the LSA ID in the subscriber data matches the LSA ID of the current cell. In the case of multiple matches the LSA ID with the highest priority it shall be present. See 3GPP TSÊ23.073Ê[18] User CSG Information C See 3GPP TS 23.060Ê[15]. 12 Subscriber Mobile Number Portability status retrieval Support of the procedures described in this clause in CAMEL PhaseÊ4 is a network operator option. 12.1 Architecture 12.1.1 Functional Entities used for CAMEL This clause describes procedures for the retrieval of subscriber Mobile Number Portability (MNP) information. The gsmSCF may request subscriber MNP information of a mobile station from the MNP Signalling Relay Function (MNP SRF). FigureÊ12.1 indicates the functional entities involved in the procedures for the retrieval of MNP information. Figure 12.1: Functional architecture for CAMEL Support of providing MNP information gsmSCF: see subclauseÊ3.1. MNPÊSRF: A functional entity that supports the mobile number portability of a mobile station, which is described in 3GPP TSÊ23.066Ê[17]. Recipient Network: Network that receives the number in the porting process. This network becomes the subscription network when the porting process is complete. See 3GPP TSÊ23.066Ê[17]. Number Range Holder Network: Network to which the number range containing the ported number has been allocated. See 3GPP TSÊ23.066Ê[17]. 12.1.2 Interfaces defined for CAMEL This subclause describes the interfaces applicable to CAMEL. It specifies on a high level the functions specific to CAMEL. 12.1.2.1 gsmSCF - MNPÊSRF interface This interface is used by the gsmSCF to request MNP information from the MNPÊSRF at any time. 12.1.2.2 MNPÊSRF - gsmSCF interface This interface is used by the MNPÊSRF to return the requested MNP information to the gsmSCF, as requested by the gsmSCF via the Any Time Interrogation procedure. 12.2 Procedures for CAMEL 12.2.1 Provide MNP Information 12.2.1.1 CAMEL_Provide_MNP_Info with ATI The process for providing MNP information with Any Time Interrogation (ATI) is the following: - CAMEL_ATI_MNP. SheetÊ1: Details of the task box ""Query Number Portability Database"" may be obtained from 3GPP TSÊ23.066Ê[17]. The task box returns an indication whether the MSISDN is known or not. Figure 12.2-1: Process CAMEL_ATI_MNP (sheet 1) 12.3 Description of information flows This subclause contains the detailed description of the information flows used by CAMEL for the retrieval of MNP information about a subscriber. Each Information Element (IE) is marked as Mandatory (M), Conditional (C), Specific conditions (S), mutually Exclusive (E) or not applicable (-). An 'M' IE shall always be included. A 'C'ÊIE shall be included if the sending entity has the necessary information to populate the IE. The conditions for the inclusion of an 'S'ÊIE are shown in the 'Description' column of the definition table. When a set of 'E' IEs is shown in the definition of an Information Flow or compound IE, only one of those IEs may be included. A '-'ÊIE shall always be omitted. This categorization is a functional classification, i.e. it defines the requirements for the stageÊ2 information. It is not a stageÊ3 classification to be used for the ASN.1 syntax of the protocol. The following principles apply for the handling of the IEs by the receiving entity: - The gsmSCF may silently discard any IE which it does not functionally support. - The MNPÊSRF shall return an error if it does not functionally support an IE which it receives. Details of errors and exceptions to these rules are specified in 3GPP TSÊ29.002Ê[34]. 12.3.1 gsmSCF to MNPÊSRF information flows 12.3.1.1 Any Time Interrogation Request 12.3.1.1.1 Description This IF is used by the gsmSCF to request the MNP information for subscribers from the MNPÊSRF at any time. 12.3.1.1.2 Information Elements Information element name Status Description gsmSCF Address M This IE indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. Requested Info M This IE indicates the type of subscriber information that is requested. It shall have the following value: - MNP Requested Info. Subscriber Identity M This IE identifies the subscriber for which the information is requested. The identity shall be: - MSISDN. 12.3.2 MNPÊSRF to gsmSCF information flows 12.3.2.1 Any Time Interrogation ack 12.3.2.1.1 Description This IF is used by the MNPÊSRF to provide the requested MNP information for the subscriber to the gsmSCF. 12.3.2.1.2 Information Elements Information element name Status Description MNP Information Result M This IE contains the MNP information for the subscriber. It is described in a table below. MNP Information Result contains the following information: Information element name Status Description Routeing Number C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. IMSI C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. MSISDN C This IE shall be present, if requested by the gsmSCF. Refer to 3GPP TSÊ23.066Ê[17]. Number Portability Status C This IE shall be present, if requested by the gsmSCF. It may have one of the following values: - Not Known To Be Ported; - Own Number PortedOut; - Foreign Number Ported To Foreign Network; - Own Number Not Ported Out; - Foreign Number Ported In. Refer to 3GPP TSÊ23.066Ê[17]. Annex A (informative): Handling of Apply Charging GPRS and Apply Charging Report GPRS This Annex provides an example to demonstrate the handling of Apply Charging GPRS and Apply Charging Report GPRS. Figure A.1: Example of Handling of Apply Charging GPRS and Apply Charging Report GPRS In Figure A.1, data volumes transferred for the active PDP context are listed on the left-hand side of diagram. The following is a description of the example: a) Apply Charging GPRS threshold set to 2000, no tariff switch timer set. b) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. c) The gsmSCF sends another Apply Charging GPRS with a 2000 unit threshold. d) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. e) Another threshold (2000) is set by the gsmSCF in Apply Charging GPRS, and a tariff switch timer is set. f) After 2000 units have been transferred, Apply Charging Report GPRS is sent to the gsmSCF, as a tariff switch timer has expired since the last Apply Charging GPRS, values for volumeTariffSwitchInterval and Volume transferred since the tariff switch are sent. The gsmSCF stores the value volumeTariffSwitchInterval. g) The gsmSCF sends another Apply Charging GPRS with a 2000 unit threshold. h) After 2000 units of data have been transferred, an Apply Charging Report GPRS is sent to the gsmSCF. i) Apply Charging GPRS sets a tariff switch timer, which does not expire before the next Apply Charging Report GPRS. j) A change in QoS is reported so Apply Charging Report GPRS is returned to the gsmSCF containing VolumeIfNoTariffSwitch as no tariff switch has occurred since the last Apply Charging Report GPRS. The gsmSCF should store this value if the volume of data transferred at each QoS level is to be calculated. The Tsw sent in the previous Apply Charging GPRS is stopped. In this example the tariff switch timer (Tsw) does not expire before this QoS change. If Tsw had expired the Apply Charging Report GPRS would report the volumeTariffSwitchInterval in the normal way. k) An Apply Charging GPRS is sent giving a new threshold. This threshold is service logic dependent and does not rely on any previous value sent. In the example it is 'previous threshold - volume transferred since last threshold was set'. l) The VolumeSinceLastTariffSwitch is reported in the Apply Charging Report GPRS. Note: this includes data transferred before and after the QoS change. m) Note that a tariff switch timer is set and expires. n) A final Apply Charging Report GPRS is returned containing the data volume transferred since the last tariff switch, and also the total volume transferred at the previous tariff. The calculations made by the gsmSCF in this example are: a) Total Data Volume Transferred in this example: Total of all volumeTariffSwitchInterval received + final volumeSinceLastTariff switch is (5500 + 5000) + 1500 = 12000 units of data b) Data Volume transferred for each tariff: (periods separated by Tsw in figure A.1) - 1st Tariff: taken from Apply Charging Report GPRS (signal f)) volumeTariffSwitchInterval = 5500 units of data - 2nd Tariff: taken from Apply Charging Report GPRS (signal n)) volumeTariffSwitchInterval = 5000 units of data - 3rd Tariff: taken from VolumeSinceLastTariffSwitch (signal n)) volumeTariffSwitchInterval = 1500 units of data c) Data Volume Transferred at each QoS level (One QoS Change Occurs in figure A.1) - 1st QoS level (up to signal 10): All volumeTariffSwitchIntervals + final VolumeSinceLastTariffSwitch at QoS change is 5500 + 3200 = 8700 units of data. - 2nd QoS level (from signal 10 onwards): (Value of first VolumeTariffSwitchInterval received after QoS change - VolumeNoTariffSwitch Received directly after QoS change ) + Volume transferred since this tariff switch is (5000-3200) + 1500 = 3300 units of data. Note: The volume reported to the gsmSCF in an Apply Charging Report GPRS may exceed the threshold sent in the previous Apply Charging GPRS, e.g. if the delta timer exceeds the threshold received in the subsequent Apply Charging GPRS or a data packet is transferred causing the threshold to be exceeded. Annex B (informative): Change history Date TSGÊ# TSG Doc. CR Rev Subject/Comment New 2003-12 CN#22 NP-030526 553 3 23.078-CR553 Collective CR for Rel-6 Enhanced Dialled Services 6.0.0 2003-12 CN#22 NP-0305628 645 1 Change of position armed with criteria (check criteria in MSC) 6.0.0 2003-12 CN#22 NP-030528 647 1 Enhancements for the Partial Implementation for ""Change of position procedure armed with criteria"" 6.0.0 2004-03 CN#23 NP-040137 649 1 Missing DisconnectLeg Result 6.1.0 2004-03 CN#23 NP-040137 651 1 Correction to DP description tables 6.1.0 2004-03 CN#23 NP-040094 652 EDS and DisconnectLeg interworking 6.1.0 2004-03 CN#23 NP-040090 656 DP Triggering without having armed the TDP 6.1.0 2004-03 CN#23 NP-040145 657 1 No receipt of Int_DP_Analysed_Information in state Monitoring 6.1.0 2004-03 CN#23 NP-040138 682 2 Enhancement of Event Specific Information for DP 'Change of Position' 6.1.0 2004-03 CN#23 NP-040131 686 1 GPRS ODB reporting to CAMEL SCP 6.1.0 2004-03 CN#23 NP-040095 688 2 CAMEL4 SCUDIF notification during active call for prepay 6.1.0 2004-03 CN#23 NP-040138 689 1 NoReply timer clarification for follow-on calls 6.1.0 2004-03 CN#23 NP-040096 693 1 Adding the Layer Compatibility information elements over the gsmSSF Ð gsmSCF interface 6.1.0 2004-03 CN#23 NP-040136 694 Correction to dialed services triggering for NP and NC calls 6.1.0 2004-03 CN#23 NP-040136 695 Correction to No Answer handling (CAMEL_OCH_MSC2) 6.1.0 2004-03 CN#23 NP-040136 696 Correction to handling of DFC in CS_gsmSSF 6.1.0 2004-03 CN#23 NP-040136 697 Correction to both way through parameter for ETC and CTR 6.1.0 2004-03 CN#23 NP-040136 698 Correction to forwarded leg handling with Suppress O-CSI 6.1.0 2004-03 CN#23 NP-040136 699 Correction to ORLCF handling for CAMEL calls in VMSC 6.1.0 2004-03 CN#23 NP-040136 700 Handling of DFCWA in ETC and CTR procedures 6.1.0 2004-03 CN#23 NP-040137 701 Correction to CUG handling for NP calls 6.1.0 2004-03 CN#23 NP-040137 702 Correction to CAMEL_ICA_MSC (hanging connector) 6.1.0 2004-03 CN#23 NP-040137 703 Correction to Request Report BCSM Event handling in CSA_gsmSSF 6.1.0 2004-03 CN#23 NP-040137 704 Correction to Split Leg handling in CSA_gsmSSF 6.1.0 2004-03 CN#23 NP-040137 705 Correction to CS ID Prompt & Collect 6.1.0 2004-03 CN#23 NP-040137 706 Correction to SplitLeg preconditions 6.1.0 2004-03 CN#23 NP-040138 707 Correction to Disconnect Leg preconditions 6.1.0 2004-03 CN#23 NP-040136 708 Correction to Information Location at DP O_Term_Seized 6.1.0 2004-03 CN#23 NP-040138 710 Starting of Timer Tccd after ACR on DP 'Change of Position' 6.1.0 2004-03 CN#23 NP-040137 711 Correction to Tssf timer at Apply Charging 6.1.0 2004-03 CN#23 NP-040137 712 Allowing Export_leg at DP Alerting and DP Answer 6.1.0 2004-06 CN#24 NP-040249 685 3 IP version of GGSN address for CAMEL 6.2.0 2004-06 CN#24 NP-040249 716 3 Enhancement to User Interaction 6.2.0 2004-06 CN#24 NP-040207 721 1 Correction to Tssf timer 6.2.0 2004-06 CN#24 NP-040207 722 Correction to D-CSI suppression in Continue With Argument 6.2.0 2004-06 CN#24 NP-040249 723 Correction to CS_gsmSSF for call release 6.2.0 2004-06 CN#24 NP-040249 724 Stopping charging timers after CancelÊ[All] 6.2.0 2004-06 CN#24 NP-040207 725 Correction to Move Leg pre-condition 6.2.0 2004-06 CN#24 NP-040207 726 Correction to InitialDP IF for NP leg 6.2.0 2004-06 CN#24 NP-040207 727 Correction to User Interaction before Answer 6.2.0 2004-06 CN#24 NP-040207 728 Correction to Entity Released for individual call party 6.2.0 2004-09 CN#25 NP-040405 732 2 Support of User-to-User Information (UUI) in CAMEL InitialDP operation 6.3.0 2004-09 CN#25 NP-040406 731 Correcting status in the procedure CAMEL_MT_CTR(sheet 4) 6.3.0 2004-09 CN#25 NP-040406 732 Redundantly modifying call parameter in CAMEL_MT_GMSC_Notify_CF 6.3.0 2004-09 CN#25 NP-040406 733 Correcting SDL of Process CS_gsmSSF(sheet 7) 6.3.0 2004-09 CN#25 NP-040406 735 2 Appended a note in Process CAMEL_ICA_MSC 6.3.0 2004-09 CN#25 NP-040406 737 Correction to CAP SCI for calls with multiple CAP dialogues 6.3.0 2004-09 CN#25 NP-040406 738 Correction to CAMEL_ICA_MSC1 and CAMEL_ICA_MSC2 6.3.0 2004-09 CN#25 NP-040406 739 Removal of Int_O_Exception from CAMEL_OCH_MSC2 and CAMEL_MT_GMSC_DISC5 6.3.0 2004-09 CN#25 NP-040406 740 Correction to CAMEL_Modify_CUG_Info 6.3.0 2004-09 CN#25 NP-040406 741 Correction to CAMEL_EXPORT_LEG_MSC procedure 6.3.0 2004-09 CN#25 NP-040406 743 Correction to CS_gsmSSF for EDS 6.3.0 2004-09 CN#25 NP-040406 744 Correction to CS_gsmSSF for Tcp expiry 6.3.0 2004-09 CN#25 NP-040406 745 Correction to Handle_ACR procedure for Tccd timer 6.3.0 2004-09 CN#25 NP-040406 747 Correction to any Time Interrogation 6.3.0 2004-09 CN#25 NP-040406 730 1 Editorial correction 6.3.0 2004-12 CN#26 NP-040525 748 5 Clarification on Outstanding Request Counter (ORC) handling at EDP-R or TDP-R resumption 6.4.0 2004-12 CN#26 NP-040544 749 2 Correcting SDL of Process CS_gsmSSF (sheet 62) 6.4.0 2004-12 CN#26 NP-040544 752 Correction to Change of Position handling in gsmSSF 6.4.0 2004-12 CN#26 NP-040544 753 1 Correction in Sheet 18 of Process CSA_gsmSSF 6.4.0 2004-12 CN#26 NP-040544 757 1 Warning Tone 6.4.0 2005-01 CS_gsmSSF SDL file updated 6.4.1 2005-03 CN#27 NP-050051 762 1 CR 693 not implemented 6.5.0 2005-06 CT#28 CP-050097 763 1 Correction to DP T_No_Answer 6.6.0 2005-06 CT#28 CP-050097 765 Correction to conditional triggering for SCUDIF call 6.6.0 2005-06 CT#28 CP-050083 767 1 Correction to CAMEL_MO_Dialled_Services 6.6.0 2005-06 CT#28 CP-050097 769 Correction to Outstanding Request Counter setting at IDP handling 6.6.0 2005-06 CT#28 CP-050083 772 Correction to No_Answer handling in CAMEL_ICA_MSC2 6.6.0 2005-06 CT#28 CP-050083 774 Correction to CAMEL_ICA_MSC1 and CAMEL_ICA_MSC2 for gsmSSF process checking 6.6.0 2005-06 CT#28 CP-050083 776 Correction to EDP-N handling for ICA legs in Process CS_gsmSSF 6.6.0 2005-06 CT#28 CP-050097 780 4 NoReply Timer clarification 6.6.0 2005-06 CT#28 CP-050103 764 1 CAMEL procedures for trunk originated services 7.0.0 2005-09 CT#29 CP-050312 781 1 Trunk Originated CAMEL triggering Ð SDLs (re-introduce CR770) 7.1.0 2005-09 CT#29 CP-050312 784 2 Additions and clarifications for CAMEL trunk originated services 7.1.0 2005-09 CT#29 CP-050309 786 Adding a missing reference 7.1.0 2005-09 CT#29 CP-050309 789 Correction on Outstanding Request Counter handling 7.1.0 2005-09 CT#29 CP-050309 791 Correction on T_Disconnect handling 7.1.0 2005-12 CT#30 CP-050626 0792 2 Trunk Originated CAMEL triggering Ð DTMF and CollectInfo parameters in SDL 7.2.0 2005-12 CT#30 CP-050626 0793 1 Modification Procedure CAMEL_OCH_LEG1_MSC 11(13) 7.2.0 2006-03 CT#31 CP-060082 0794 Specification of gsmSCF Address format in AnyTime request messages 7.3.0 2006-06 CT#32 CP-060311 0796 1 Addition of information related to service change 7.4.0 2006-06 CT#32 CP-060336 0797 2 List of MSISDNs and Basic Service Code for MAP Any Time Subscription Interrogation. 7.4.0 2006-06 CT#32 CP-060300 0798 1 Corrections of Process CS_gsmSSF 7.4.0 2006-09 CT#33 CP-060414 0806 1 Response to ATI for GPRS information when PSI not supported in the SGSN 7.5.0 2006-09 CT#33 CP-060414 0807 SGSN number to be included in the ATI response 7.5.0 2006-12 CT#34 CP-060695 0810 1 Optional Suppress Terminating Services Bit String in SRI 7.6.0 2007-03 CT#35 CP-070030 0813 1 Addition of SMS over IP functionality 7.7.0 2007-06 CT#36 CP-070328 0815 Mobile Termination whilst the MS is moving to another MSC 7.8.0 2007-06 CT#36 CP-070326 0816 1 Correction of IP-SM-GW update in the HSS 7.8.0 2007-06 CT#36 CP-070325 0822 2 Adding a Information Element to Continue Camel Handling Information Flow 7.8.0 2007-06 CT#36 CP-070325 0823 Mutually exclusive elements in Location Information in MSC for Initial DP SMS 7.8.0 2007-06 CT#36 CP-070325 0824 1 Correction to DTMF detection in alerting phase 7.8.0 2007-09 CT#37 CP-070540 0814 4 AC/ACR Handling 7.9.0 2007-09 CT#37 CP-070540 0826 Correction to the Send Info For Incoming Call ack Information Flow 7.9.0 2008-12 CT#42 Upgrade to Release 8 without technical change 8.0.0 2009-09 CT#45 CP-090524 0831 2 Correction on ACR and Warning Tone Play Handling of Leg 1 when successful move of a leg 8.1.0 2009-12 - - - - Update to Rel-9 version (MCC) 9.0.0 2010-03 CT#47 CP-100029 0832 1 User CSG Information for CAMEL 9.1.0 2010-09 CT#49 CP-100449 0835 1 Correction for SMS via SGs charging 9.2.0 2010-09 CT#49 CP-100467 0836 2 Addition of SS codes to the ATSI and ATM procedures 10.0.0 2011-09 CT#53 CP-110732 0837 2 Extension parameter for Release Call 11.0.0 2011-12 CT#54 CP-110780 0841 1 Provide Subscriber Information handling for UE under LTE 11.1.0 2012-03 CT#55 CP-120038 0842 2 EPS Location in IDP SMS 11.2.0 2012-06 CT#56 CP-120244 0843 - EPS location in Initial DP 11.3.0 2012-06 CT#56 CP-120244 0844 - EPS location in MAP Note MM Event 11.3.0 2012-09 CT#61 CP-130468 0845 - Clarification of allowed values for SS-status in Any Time Modification procedure 12.0.0 2015-12 CT#70 - - - Update to Rel-13 version (MCC) 13.0.0 2017-03 CT#75 - - - Update to Rel-14 version (MCC) 14.0.0 2018-06 -CT#80 - - - Update to Rel-15 version (MCC) 15.0.0 2020-07 - - - - Update to Rel-16 version (MCC) 16.0.0 2022-03 - - - - Update to Rel-17 version (MCC) 17.0.0 3GPP TS 23.078 V17.0.0 (2022-03) 750 Release 17 3GPP Network Working Group J. Sjoberg Request for Comments: 4867 M. Westerlund Obsoletes: 3267 Ericsson Category: Standards Track A. Lakaniemi Nokia Q. Xie Motorola April 2007 RTP Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs Status of This Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ""Internet Official Protocol Standards"" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The IETF Trust (2007). Abstract This document specifies a Real-time Transport Protocol (RTP) payload format to be used for Adaptive Multi-Rate (AMR) and Adaptive Multi- Rate Wideband (AMR-WB) encoded speech signals. The payload format is designed to be able to interoperate with existing AMR and AMR-WB transport formats on non-IP networks. In addition, a file format is specified for transport of AMR and AMR-WB speech data in storage mode applications such as email. Two separate media type registrations are included, one for AMR and one for AMR-WB, specifying use of both the RTP payload format and the storage format. This document obsoletes RFC 3267. Sjoberg, et al. Standards Track [Page 1] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Table of Contents 1. Introduction ....................................................4 2. Conventions and Acronyms ........................................4 3. Background on AMR/AMR-WB and Design Principles ..................5 3.1. The Adaptive Multi-Rate (AMR) Speech Codec .................5 3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec .....6 3.3. Multi-Rate Encoding and Mode Adaptation ....................6 3.4. Voice Activity Detection and Discontinuous Transmission ....7 3.5. Support for Multi-Channel Session ..........................7 3.6. Unequal Bit-Error Detection and Protection .................8 3.6.1. Applying UEP and UED in an IP Network ...............8 3.7. Robustness against Packet Loss ............................10 3.7.1. Use of Forward Error Correction (FEC) ..............10 3.7.2. Use of Frame Interleaving ..........................12 3.8. Bandwidth-Efficient or Octet-Aligned Mode .................12 3.9. AMR or AMR-WB Speech over IP Scenarios ....................13 4. AMR and AMR-WB RTP Payload Formats .............................15 4.1. RTP Header Usage ..........................................15 4.2. Payload Structure .........................................17 4.3. Bandwidth-Efficient Mode ..................................17 4.3.1. The Payload Header .................................17 4.3.2. The Payload Table of Contents ......................18 4.3.3. Speech Data ........................................20 4.3.4. Algorithm for Forming the Payload ..................21 4.3.5. Payload Examples ...................................21 4.3.5.1. Single-Channel Payload Carrying a Single Frame ..............................21 4.3.5.2. Single-Channel Payload Carrying Multiple Frames ...........................22 4.3.5.3. Multi-Channel Payload Carrying Multiple Frames ...........................23 4.4. Octet-Aligned Mode ........................................25 4.4.1. The Payload Header .................................25 4.4.2. The Payload Table of Contents and Frame CRCs .......26 4.4.2.1. Use of Frame CRC for UED over IP ..........28 4.4.3. Speech Data ........................................30 4.4.4. Methods for Forming the Payload ....................31 4.4.5. Payload Examples ...................................32 4.4.5.1. Basic Single-Channel Payload Carrying Multiple Frames ..................32 4.4.5.2. Two-Channel Payload with CRC, Interleaving, and Robust Sorting ..........32 4.5. Implementation Considerations .............................33 4.5.1. Decoding Validation ................................34 5. AMR and AMR-WB Storage Format ..................................35 5.1. Single-Channel Header .....................................35 5.2. Multi-Channel Header ......................................36 Sjoberg, et al. Standards Track [Page 2] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5.3. Speech Frames .............................................37 6. Congestion Control .............................................38 7. Security Considerations ........................................38 7.1. Confidentiality ...........................................39 7.2. Authentication and Integrity ..............................39 8. Payload Format Parameters ......................................39 8.1. AMR Media Type Registration ...............................40 8.2. AMR-WB Media Type Registration ............................44 8.3. Mapping Media Type Parameters into SDP ....................47 8.3.1. Offer-Answer Model Considerations ..................48 8.3.2. Usage of Declarative SDP ...........................50 8.3.3. Examples ...........................................51 9. IANA Considerations ............................................53 10. Changes from RFC 3267 .........................................53 11. Acknowledgements ..............................................55 12. References ....................................................55 12.1. Normative References .....................................55 12.2. Informative References ...................................56 Sjoberg, et al. Standards Track [Page 3] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 1. Introduction This document obsoletes RFC 3267 and extends that specification with offer/answer rules. See Section 10 for the changes made to this format in relation to RFC 3267. This document specifies the payload format for packetization of AMR and AMR-WB encoded speech signals into the Real-time Transport Protocol (RTP) [8]. The payload format supports transmission of multiple channels, multiple frames per payload, the use of fast codec mode adaptation, robustness against packet loss and bit errors, and interoperation with existing AMR and AMR-WB transport formats on non-IP networks, as described in Section 3. The payload format itself is specified in Section 4. A related file format is specified in Section 5 for transport of AMR and AMR-WB speech data in storage mode applications such as email. In Section 8, two separate media type registrations are provided, one for AMR and one for AMR-WB. Even though this RTP payload format definition supports the transport of both AMR and AMR-WB speech, it is important to remember that AMR and AMR-WB are two different codecs and they are always handled as different payload types in RTP. 2. Conventions and Acronyms The key words ""MUST"", ""MUST NOT"", ""REQUIRED"", ""SHALL"", ""SHALL NOT"", ""SHOULD"", ""SHOULD NOT"", ""RECOMMENDED"", ""MAY"", and ""OPTIONAL"" in this document are to be interpreted as described in RFC 2119 [5]. The following acronyms are used in this document: 3GPP - the Third Generation Partnership Project AMR - Adaptive Multi-Rate (Codec) AMR-WB - Adaptive Multi-Rate Wideband (Codec) CMR - Codec Mode Request CN - Comfort Noise DTX - Discontinuous Transmission ETSI - European Telecommunications Standards Institute FEC - Forward Error Correction SCR - Source Controlled Rate Operation SID - Silence Indicator (the frames containing only CN parameters) VAD - Voice Activity Detection UED - Unequal Error Detection UEP - Unequal Error Protection Sjoberg, et al. Standards Track [Page 4] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The term ""frame-block"" is used in this document to describe the time-synchronized set of speech frames in a multi-channel AMR or AMR-WB session. In particular, in an N-channel session, a frame- block will contain N speech frames, one from each of the channels, and all N speech frames represents exactly the same time period. The byte order used in this document is network byte order, i.e., the most significant byte first. The bit order is also the most significant bit first. This is presented in all figures as having the most significant bit leftmost on a line and with the lowest number. Some bit fields may wrap over multiple lines in which cases the bits on the first line are more significant than the bits on the next line. 3. Background on AMR/AMR-WB and Design Principles AMR and AMR-WB were originally designed for circuit-switched mobile radio systems. Due to their flexibility and robustness, they are also suitable for other real-time speech communication services over packet-switched networks such as the Internet. Because of the flexibility of these codecs, the behavior in a particular application is controlled by several parameters that select options or specify the acceptable values for a variable. These options and variables are described in general terms at appropriate points in the text of this specification as parameters to be established through out-of-band means. In Section 8, all of the parameters are specified in the form of media subtype registrations for the AMR and AMR-WB encodings. The method used to signal these parameters at session setup or to arrange prior agreement of the participants is beyond the scope of this document; however, Section 8.3 provides a mapping of the parameters into the Session Description Protocol (SDP) [11] for those applications that use SDP. 3.1. The Adaptive Multi-Rate (AMR) Speech Codec The AMR codec was originally developed and standardized by the European Telecommunications Standards Institute (ETSI) for GSM cellular systems. It is now chosen by the Third Generation Partnership Project (3GPP) as the mandatory codec for third generation (3G) cellular systems [1]. The AMR codec is a multi-mode codec that supports eight narrow band speech encoding modes with bit rates between 4.75 and 12.2 kbps. The sampling frequency used in AMR is 8000 Hz and the speech encoding is performed on 20 ms speech frames. Therefore, each encoded AMR speech frame represents 160 samples of the original speech. Sjoberg, et al. Standards Track [Page 5] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Among the eight AMR encoding modes, three are already separately adopted as standards of their own. Particularly, the 6.7 kbps mode is adopted as PDC-EFR [18], the 7.4 kbps mode as IS-641 codec in TDMA [17], and the 12.2 kbps mode as GSM-EFR [16]. 3.2. The Adaptive Multi-Rate Wideband (AMR-WB) Speech Codec The Adaptive Multi-Rate Wideband (AMR-WB) speech codec [3] was originally developed by 3GPP to be used in GSM and 3G cellular systems. Similar to AMR, the AMR-WB codec is also a multi-mode speech codec. AMR-WB supports nine wide band speech coding modes with respective bit rates ranging from 6.6 to 23.85 kbps. The sampling frequency used in AMR-WB is 16000 Hz and the speech processing is performed on 20 ms frames. This means that each AMR-WB encoded frame represents 320 speech samples. 3.3. Multi-Rate Encoding and Mode Adaptation The multi-rate encoding (i.e., multi-mode) capability of AMR and AMR-WB is designed for preserving high speech quality under a wide range of transmission conditions. With AMR or AMR-WB, mobile radio systems are able to use available bandwidth as effectively as possible. For example, in GSM it is possible to dynamically adjust the speech encoding rate during a session so as to continuously adapt to the varying transmission conditions by dividing the fixed overall bandwidth between speech data and error protective coding. This enables the best possible trade-off between speech compression rate and error tolerance. To perform mode adaptation, the decoder (speech receiver) needs to signal the encoder (speech sender) the new mode it prefers. This mode change signal is called Codec Mode Request or CMR. Since in most sessions speech is sent in both directions between the two ends, the mode requests from the decoder at one end to the encoder at the other end are piggy-backed over the speech frames in the reverse direction. In other words, there is no out-of-band signaling needed for sending CMRs. Every AMR or AMR-WB codec implementation is required to support all the respective speech coding modes defined by the codec and must be able to handle mode switching to any of the modes at any time. However, some transport systems may impose limitations in the number of modes supported and how often the mode can change due to bandwidth Sjoberg, et al. Standards Track [Page 6] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 limitations or other constraints. For this reason, the decoder is allowed to indicate its acceptance of a particular mode or a subset of the defined modes for the session using out-of-band means. For example, the GSM radio link can only use a subset of at most four different modes in a given session. This subset can be any combination of the eight AMR modes for an AMR session or any combination of the nine AMR-WB modes for an AMR-WB session. Moreover, for better interoperability with GSM through a gateway, the decoder is allowed to use out-of-band means to set the minimum number of frames between two mode changes and to limit the mode change among neighboring modes only. Section 8 specifies a set of media type parameters that may be used to signal these mode adaptation controls at session setup. 3.4. Voice Activity Detection and Discontinuous Transmission Both codecs support voice activity detection (VAD) and generation of comfort noise (CN) parameters during silence periods. Hence, the codecs have the option to reduce the number of transmitted bits and packets during silence periods to a minimum. The operation of sending CN parameters at regular intervals during silence periods is usually called discontinuous transmission (DTX) or source controlled rate (SCR) operation. The AMR or AMR-WB frames containing CN parameters are called Silence Indicator (SID) frames. See more details about VAD and DTX functionality in [9] and [10]. 3.5. Support for Multi-Channel Session Both the RTP payload format and the storage format defined in this document support multi-channel audio content (e.g., a stereophonic speech session). Although AMR and AMR-WB codecs themselves do not support encoding of multi-channel audio content into a single bit stream, they can be used to separately encode and decode each of the individual channels. To transport (or store) the separately encoded multi-channel content, the speech frames for all channels that are framed and encoded for the same 20 ms periods are logically collected in a frame-block. At the session setup, out-of-band signaling must be used to indicate the number of channels in the session, and the order of the speech frames from different channels in each frame-block. When using SDP for signaling, the number of channels is specified in the rtpmap attribute and the order of channels carried in each frame-block is Sjoberg, et al. Standards Track [Page 7] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 implied by the number of channels as specified in Section 4.1 in [12]. 3.6. Unequal Bit-Error Detection and Protection The speech bits encoded in each AMR or AMR-WB frame have different perceptual sensitivity to bit errors. This property has been exploited in cellular systems to achieve better voice quality by using unequal error protection and detection (UEP and UED) mechanisms. The UEP/UED mechanisms focus the protection and detection of corrupted bits to the perceptually most sensitive bits in an AMR or AMR-WB frame. In particular, speech bits in an AMR or AMR-WB frame are divided into class A, B, and C, where bits in class A are the most sensitive and bits in class C the least sensitive (see Table 1 below for AMR and [4] for AMR-WB). An AMR or AMR-WB frame is only declared damaged if there are bit errors found in the most sensitive bits, i.e., the class A bits. On the other hand, it is acceptable to have some bit errors in the other bits, i.e., class B and C bits."
"Class A Total speech Index Mode bits bits ---------------------------------------- 0 AMR 4.75 42 95 1 AMR 5.15 49 103 2 AMR 5.9 55 118 3 AMR 6.7 58 134 4 AMR 7.4 61 148 5 AMR 7.95 75 159 6 AMR 10.2 65 204 7 AMR 12.2 81 244 8 AMR SID 39 39 Table 1. The number of class A bits for the AMR codec Moreover, a damaged frame is still useful for error concealment at the decoder since some of the less sensitive bits can still be used. This approach can improve the speech quality compared to discarding the damaged frame. 3.6.1. Applying UEP and UED in an IP Network To take full advantage of the bit-error robustness of the AMR and AMR-WB codec, the RTP payload format is designed to facilitate UEP/UED in an IP network. It should be noted however that the utilization of UEP and UED discussed below is OPTIONAL. Sjoberg, et al. Standards Track [Page 8] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 UEP/UED in an IP network can be achieved by detecting bit errors in class A bits and tolerating bit errors in class B/C bits of the AMR or AMR-WB frame(s) in each RTP payload. Link-layer protocols exist that do not discard packets containing bit errors, e.g., SLIP and some wireless links. With the Internet traffic pattern shifting towards a more multimedia-centric one, more link layers of such nature may emerge in the future. With transport layer support for partial checksums (for example, those supported by UDP-Lite [19]), bit error tolerant AMR and AMR-WB traffic could achieve better performance over these types of links. The relationship between UDP-Lite's partial checksum at the transport layer and the checksum coverage provided by the link-layer frame is described in UDP-Lite specification [19]. There are at least two basic approaches for carrying AMR and AMR-WB traffic over bit error tolerant IP networks: a) Utilizing a partial checksum to cover the IP, transport protocol (e.g., UDP-Lite), RTP and payload headers, and the most important speech bits of the payload. The IP, UDP and RTP headers need to be protected, and it is recommended that at least all class A bits are covered by the checksum. b) Utilizing a partial checksum to only cover the IP, transport protocol, RTP and payload headers, but an AMR or AMR-WB frame CRC to cover the class A bits of each speech frame in the RTP payload. In either approach, at least part of the class B/C bits are left without error-check and thus bit error tolerance is achieved. Note, it is still important that the network designer pays attention to the class B and C residual bit error rate. Though less sensitive to errors than class A bits, class B and C bits are not insignificant, and undetected errors in these bits cause degradation in speech quality. An example of residual error rates considered acceptable for AMR in the Universal Mobile Telecommunications System (UMTS) can be found in [24] and for AMR-WB in [25]. The application interface to the UEP/UED transport protocol (e.g., UDP-Lite) may not provide any control over the link error rate, especially in a gateway scenario. Therefore, it is incumbent upon the designer of a node with a link interface of this type to choose a residual bit error rate that is low enough to support applications such as AMR encoding when transmitting packets of a UEP/UED transport protocol. Sjoberg, et al. Standards Track [Page 9] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Approach 1 is bit efficient, flexible and simple, but comes with two disadvantages, namely, a) bit errors in protected speech bits will cause the payload to be discarded, and b) when transporting multiple AMR or AMR-WB frames in a RTP payload, there is the possibility that a single bit error in protected bits will cause all the frames to be discarded. These disadvantages can be avoided, if needed, with some overhead in the form of a frame-wise CRC (Approach 2). In problem a), the CRC makes it possible to detect bit errors in class A bits and use the frame for error concealment, which gives a small improvement in speech quality. For b), when transporting multiple frames in a payload, the CRCs remove the possibility that a single bit error in a class A bit will cause all the frames to be discarded. Avoiding that improves the speech quality when transporting multiple AMR or AMR-WB frames over links subject to bit errors. The choice between the above two approaches must be made based on the available bandwidth, and the desired tolerance to bit errors. Neither solution is appropriate for all cases. Section 8 defines parameters that may be used at session setup to choose between these approaches. 3.7. Robustness against Packet Loss The payload format supports several means, including forward error correction (FEC) and frame interleaving, to increase robustness against packet loss. 3.7.1. Use of Forward Error Correction (FEC) The simple scheme of repetition of previously sent data is one way of achieving FEC. Another possible scheme which is more bandwidth efficient is to use payload-external FEC, e.g., RFC 2733 [23], which generates extra packets containing repair data. The whole payload can also be sorted in sensitivity order to support external FEC schemes using UEP. There is also a work in progress on a generic version of such a scheme [22] that can be applied to AMR or AMR-WB payload transport. With AMR or AMR-WB, it is possible to use the multi-rate capability of the codec to send redundant copies of a frame using either the same mode or another mode, e.g., one with lower bandwidth. We describe such a scheme next. Sjoberg, et al. Standards Track [Page 10] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 This involves the simple retransmission of previously transmitted frame-blocks together with the current frame-block(s). This is done by using a sliding window to group the speech frame-blocks to send in each payload. Figure 1 below shows us an example. --+--------+--------+--------+--------+--------+--------+--------+-- | f(n-2) | f(n-1) | f(n) | f(n+1) | f(n+2) | f(n+3) | f(n+4) | --+--------+--------+--------+--------+--------+--------+--------+-- <---- p(n-1) ----> <----- p(n) -----> <---- p(n+1) ----> <---- p(n+2) ----> <---- p(n+3) ----> <---- p(n+4) ----> Figure 1: An example of redundant transmission In this example each frame-block is retransmitted one time in the following RTP payload packet. Here, f(n-2)..f(n+4) denotes a sequence of speech frame-blocks, and p(n-1)..p(n+4) a sequence of payload packets. The use of this approach does not require signaling at the session setup. However, a parameter for providing a maximum delay in transmitting any redundant frame is defined in Section 8. In other words, the speech sender can choose to use this scheme without consulting the receiver. This is because a packet containing redundant frames will not look different from a packet with only new frames. The receiver may receive multiple copies or versions (encoded with different modes) of a frame for a certain timestamp if no packet is lost. If multiple versions of the same speech frame are received, it is recommended that the mode with the highest rate be used by the speech decoder. This redundancy scheme provides the same functionality as the one described in RFC 2198, ""RTP Payload for Redundant Audio Data"" [27]. In most cases the mechanism in this payload format is more efficient and simpler than requiring both endpoints to support RFC 2198 in addition. There are two situations in which use of RFC 2198 is indicated: if the spread in time required between the primary and redundant encodings is larger than the duration of 5 frames, the bandwidth overhead of RFC 2198 will be lower; or, if a non-AMR codec is desired for the redundant encoding, the AMR payload format won't be able to carry it. The sender is responsible for selecting an appropriate amount of redundancy based on feedback about the channel, e.g., in RTCP Sjoberg, et al. Standards Track [Page 11] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 receiver reports. A sender should not base selection of FEC on the CMR, as this parameter most probably was set based on non-IP information, e.g., radio link performance measures. The sender is also responsible for avoiding congestion, which may be exacerbated by redundancy (see Section 6 for more details). 3.7.2. Use of Frame Interleaving To decrease protocol overhead, the payload design allows several speech frame-blocks to be encapsulated into a single RTP packet. One of the drawbacks of such an approach is that packet loss can cause loss of several consecutive speech frame-blocks, which usually causes clearly audible distortion in the reconstructed speech. Interleaving of frame-blocks can improve the speech quality in such cases by distributing the consecutive losses into a series of single frame- block losses. However, interleaving and bundling several frame- blocks per payload will also increase end-to-end delay and is therefore not appropriate for all types of applications. Streaming applications will most likely be able to exploit interleaving to improve speech quality in lossy transmission conditions. This payload design supports the use of frame interleaving as an option. For the encoder (speech sender) to use frame interleaving in its outbound RTP packets for a given session, the decoder (speech receiver) needs to indicate its support via out-of-band means (see Section 8). 3.8. Bandwidth-Efficient or Octet-Aligned Mode For a given session, the payload format can be either bandwidth efficient or octet aligned, depending on the mode of operation that is established for the session via out-of-band means. In the octet-aligned format, all the fields in a payload, including payload header, table of contents entries, and speech frames themselves, are individually aligned to octet boundaries to make implementations efficient. In the bandwidth-efficient format, only the full payload is octet aligned, so fewer padding bits are added. Note, octet alignment of a field or payload means that the last octet is padded with zeroes in the least significant bits to fill the octet. Also note that this padding is separate from padding indicated by the P bit in the RTP header. Between the two operation modes, only the octet-aligned mode has the capability to use the robust sorting, interleaving, and frame CRC to make the speech transport more robust to packet loss and bit errors. Sjoberg, et al. Standards Track [Page 12] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 3.9. AMR or AMR-WB Speech over IP Scenarios The primary scenario for this payload format is IP end-to-end between two terminals, as shown in Figure 2. This payload format is expected to be useful for both conversational and streaming services. +----------+ +----------+ | | IP/UDP/RTP/AMR or | | | TERMINAL |<----------------------->| TERMINAL | | | IP/UDP/RTP/AMR-WB | | +----------+ +----------+ Figure 2: IP terminal to IP terminal scenario A conversational service puts requirements on the payload format. Low delay is one very important factor, i.e., few speech frame-blocks per payload packet. Low overhead is also required when the payload format traverses low bandwidth links, especially as the frequency of packets will be high. For low bandwidth links, it is also an advantage to support UED, which allows a link provider to reduce delay and packet loss, or to reduce the utilization of link resources. A streaming service has less strict real-time requirements and therefore can use a larger number of frame-blocks per packet than a conversational service. This reduces the overhead from IP, UDP, and RTP headers. However, including several frame-blocks per packet makes the transmission more vulnerable to packet loss, so interleaving may be used to reduce the effect that packet loss will have on speech quality. A streaming server handling a large number of clients also needs a payload format that requires as few resources as possible when doing packetization. The octet-aligned and interleaving modes require the least amount of resources, while CRC, robust sorting, and bandwidth-efficient modes have higher demands. Another scenario is when AMR or AMR-WB encoded speech is transmitted from a non-IP system (e.g., a GSM or 3GPP UMTS network) to an IP/UDP/RTP VoIP terminal, and/or vice versa, as depicted in Figure 3. Sjoberg, et al. Standards Track [Page 13] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 AMR or AMR-WB over I.366.{2,3} or +------+ +----------+ 3G Iu or | | IP/UDP/RTP/AMR or | | <------------->| GW |<---------------------->| TERMINAL | GSM Abis | | IP/UDP/RTP/AMR-WB | | etc. +------+ +----------+ | GSM/ | IP network 3GPP UMTS network | Figure 3: GW to VoIP terminal scenario In such a case, it is likely that the AMR or AMR-WB frame is packetized in a different way in the non-IP network and will need to be re-packetized into RTP at the gateway. Also, speech frames from the non-IP network may come with some UEP/UED information (e.g., a frame quality indicator) that will need to be preserved and forwarded on to the decoder along with the speech bits. This is specified in Section 4.3.2. AMR's capability to do fast mode switching is exploited in some non- IP networks to optimize speech quality. To preserve this functionality in scenarios including a gateway to an IP network, a codec mode request (CMR) field is needed. The gateway will be responsible for forwarding the CMR between the non-IP and IP parts in both directions. The IP terminal should follow the CMR forwarded by the gateway to optimize speech quality going to the non-IP decoder. The mode control algorithm in the gateway must accommodate the delay imposed by the IP network on the IP terminal's response to CMR. The IP terminal should not set the CMR (see Section 4.3.1), but the gateway can set the CMR value on frames going toward the encoder in the non-IP part to optimize speech quality from that encoder to the gateway. The gateway can alternatively set a lower CMR value, if desired, as one means to control congestion on the IP network. A third likely scenario is that IP/UDP/RTP is used as transport between two non-IP systems, i.e., IP is originated and terminated in gateways on both sides of the IP transport, as illustrated in Figure 4 below. Sjoberg, et al. Standards Track [Page 14] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 AMR or AMR-WB AMR or AMR-WB over over I.366.{2,3} or +------+ +------+ I.366.{2,3} or 3G Iu or | | IP/UDP/RTP/AMR or | | 3G Iu or <------------->| GW |<------------------->| GW |<-------------> GSM Abis | | IP/UDP/RTP/AMR-WB | | GSM Abis etc. +------+ +------+ etc. | | GSM/ | IP network | GSM/ 3GPP UMTS network | | 3GPP UMTS network Figure 4: GW to GW scenario This scenario requires the same mechanisms for preserving UED/UEP and CMR information as in the single gateway scenario. In addition, the CMR value may be set in packets received by the gateways on the IP network side. The gateway should forward to the non-IP side a CMR value that is the minimum of three values: - the CMR value it receives on the IP side; - the CMR value it calculates based on its reception quality on the non-IP side; and - a CMR value it may choose for congestion control of transmission on the IP side. The details of the control algorithm are left to the implementation. 4. AMR and AMR-WB RTP Payload Formats The AMR and AMR-WB payload formats have identical structure, so they are specified together. The only differences are in the types of codec frames contained in the payload. The payload format consists of the RTP header, payload header, and payload data. 4.1. RTP Header Usage The format of the RTP header is specified in [8]. This payload format uses the fields of the header in a manner consistent with that specification. The RTP timestamp corresponds to the sampling instant of the first sample encoded for the first frame-block in the packet. The timestamp clock frequency is the same as the sampling frequency, so the timestamp unit is in samples. Sjoberg, et al. Standards Track [Page 15] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The duration of one speech frame-block is 20 ms for both AMR and AMR-WB. For AMR, the sampling frequency is 8 kHz, corresponding to 160 encoded speech samples per frame from each channel. For AMR-WB, the sampling frequency is 16 kHz, corresponding to 320 samples per frame from each channel. Thus, the timestamp is increased by 160 for AMR and 320 for AMR-WB for each consecutive frame-block. A packet may contain multiple frame-blocks of encoded speech or comfort noise parameters. If interleaving is employed, the frame- blocks encapsulated into a payload are picked according to the interleaving rules as defined in Section 4.4.1. Otherwise, each packet covers a period of one or more contiguous 20 ms frame-block intervals. In case the data from all the channels for a particular frame-block in the period is missing (for example, at a gateway from some other transport format), it is possible to indicate that no data is present for that frame-block rather than breaking a multi-frame- block packet into two, as explained in Section 4.3.2. To allow for error resiliency through redundant transmission, the periods covered by multiple packets MAY overlap in time. A receiver MUST be prepared to receive any speech frame multiple times, in exact duplicates, in different AMR rate modes, or with data present in one packet and not present in another. If multiple versions of the same speech frame are received, it is RECOMMENDED that the mode with the highest rate be used by the speech decoder. A given frame MUST NOT be encoded as speech in one packet and comfort noise parameters in another. The payload length is always made an integral number of octets by padding with zero bits if necessary. If additional padding is required to bring the payload length to a larger multiple of octets or for some other purpose, then the P bit in the RTP in the header may be set and padding appended as specified in [8]. The RTP header marker bit (M) SHALL be set to 1 if the first frame- block carried in the packet contains a speech frame which is the first in a talkspurt. For all other packets the marker bit SHALL be set to zero (M=0). The assignment of an RTP payload type for this new packet format is outside the scope of this document, and will not be specified here. It is expected that the RTP profile under which this payload format is being used will assign a payload type for this encoding or specify that the payload type is to be bound dynamically. Sjoberg, et al. Standards Track [Page 16] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.2. Payload Structure The complete payload consists of a payload header, a payload table of contents, and speech data representing one or more speech frame- blocks. The following diagram shows the general payload format layout: +----------------+-------------------+---------------- | payload header | table of contents | speech data ... +----------------+-------------------+---------------- Payloads containing more than one speech frame-block are called compound payloads. The following sections describe the variations taken by the payload format depending on whether the AMR session is set up to use the bandwidth-efficient mode or octet-aligned mode and any of the OPTIONAL functions for robust sorting, interleaving, and frame CRCs. Implementations SHOULD support both bandwidth-efficient and octet- aligned operation to increase interoperability. 4.3. Bandwidth-Efficient Mode 4.3.1. The Payload Header In bandwidth-efficient mode, the payload header simply consists of a 4-bit codec mode request: 0 1 2 3 +-+-+-+-+ | CMR | +-+-+-+-+ CMR (4 bits): Indicates a codec mode request sent to the speech encoder at the site of the receiver of this payload. The value of the CMR field is set to the frame type index of the corresponding speech mode being requested. The frame type index may be 0-7 for AMR, as defined in Table 1a in [2], or 0-8 for AMR-WB, as defined in Table 1a in [4]. CMR value 15 indicates that no mode request is present, and other values are for future use. The codec mode request received in the CMR field is valid until the next codec mode request is received, i.e., a newly received CMR value corresponding to a speech mode, or NO_DATA overrides the previously received CMR value corresponding to a speech mode or NO_DATA. Therefore, if a terminal continuously wishes to receive frames in the Sjoberg, et al. Standards Track [Page 17] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 same mode X, it needs to set CMR=X for all its outbound payloads, and if a terminal has no preference in which mode to receive, it SHOULD set CMR=15 in all its outbound payloads. If receiving a payload with a CMR value that is not a speech mode or NO_DATA, the CMR MUST be ignored by the receiver. In a multi-channel session, the codec mode request SHOULD be interpreted by the receiver of the payload as the desired encoding mode for all the channels in the session. An IP end-point SHOULD NOT set the codec mode request based on packet losses or other congestion indications, for several reasons: - The other end of the IP path may be a gateway to a non-IP network (such as a radio link) that needs to set the CMR field to optimize performance on that network. - Congestion on the IP network is managed by the IP sender, in this case, at the other end of the IP path. Feedback about congestion SHOULD be provided to that IP sender through RTCP or other means, and then the sender can choose to avoid congestion using the most appropriate mechanism. That may include adjusting the codec mode, but also includes adjusting the level of redundancy or number of frames per packet. The encoder SHOULD follow a received codec mode request, but MAY change to a lower-numbered mode if it so chooses, for example, to control congestion. The CMR field MUST be set to 15 for packets sent to a multicast group. The encoder in the speech sender SHOULD ignore codec mode requests when sending speech to a multicast session but MAY use RTCP feedback information as a hint that a codec mode change is needed. The codec mode selection MAY be restricted by a session parameter to a subset of the available modes. If so, the requested mode MUST be among the signalled subset (see Section 8). If the received CMR value is outside the signalled subset of modes, it MUST be ignored. 4.3.2. The Payload Table of Contents The table of contents (ToC) consists of a list of ToC entries, each representing a speech frame. Sjoberg, et al. Standards Track [Page 18] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 In bandwidth-efficient mode, a ToC entry takes the following format: 0 1 2 3 4 5 +-+-+-+-+-+-+ |F| FT |Q| +-+-+-+-+-+-+ F (1 bit): If set to 1, indicates that this frame is followed by another speech frame in this payload; if set to 0, indicates that this frame is the last frame in this payload. FT (4 bits): Frame type index, indicating either the AMR or AMR-WB speech coding mode or comfort noise (SID) mode of the corresponding frame carried in this payload. The value of FT is defined in Table 1a in [2] for AMR and in Table 1a in [4] for AMR-WB. FT=14 (SPEECH_LOST, only available for AMR-WB) and FT=15 (NO_DATA) are used to indicate frames that are either lost or not being transmitted in this payload, respectively. NO_DATA (FT=15) frame could mean either that no data for that frame has been produced by the speech encoder or that no data for that frame is transmitted in the current payload (i.e., valid data for that frame could be sent in either an earlier or later packet). If receiving a ToC entry with a FT value in the range 9-14 for AMR or 10-13 for AMR-WB, the whole packet SHOULD be discarded. This is to avoid the loss of data synchronization in the depacketization process, which can result in a huge degradation in speech quality. Note that packets containing only NO_DATA frames SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. Also, frame-blocks containing only NO_DATA frames at the end of a packet SHOULD NOT be transmitted in any payload format configuration, except in the case of interleaving. The AMR SCR/DTX is described in [6] and AMR-WB SCR/DTX in [7]. The extra comfort noise frame types specified in table 1a in [2] (i.e., GSM-EFR CN, IS-641 CN, and PDC-EFR CN) MUST NOT be used in this payload format because the standardized AMR codec is only required to implement the general AMR SID frame type and not those that are native to the incorporated encodings. Q (1 bit): Frame quality indicator. If set to 0, indicates the corresponding frame is severely damaged, and the receiver should set the RX_TYPE (see [6]) to either SPEECH_BAD or SID_BAD depending on the frame type (FT). Sjoberg, et al. Standards Track [Page 19] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The frame quality indicator is included for interoperability with the ATM payload format described in ITU-T I.366.2, the UMTS Iu interface [20], as well as other transport formats. The frame quality indicator enables damaged frames to be forwarded to the speech decoder for error concealment. This can improve the speech quality more than dropping the damaged frames. See Section 4.4.2.1 for more details. For multi-channel sessions, the ToC entries of all frames from a frame-block are placed in the ToC in consecutive order as defined in Section 4.1 in [12]. When multiple frame-blocks are present in a packet in bandwidth-efficient mode, they will be placed in the packet in order of their creation time. Therefore, with N channels and K speech frame-blocks in a packet, there MUST be N*K entries in the ToC, and the first N entries will be from the first frame-block, the second N entries will be from the second frame-block, and so on. The following figure shows an example of a ToC of three entries in a single-channel session using bandwidth-efficient mode. 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| FT |Q|1| FT |Q|0| FT |Q| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Below is an example of how the ToC entries will appear in the ToC of a packet carrying three consecutive frame-blocks in a session with two channels (L and R). +----+----+----+----+----+----+ | 1L | 1R | 2L | 2R | 3L | 3R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 1 Block 2 Block 3 4.3.3. Speech Data Speech data of a payload contains zero or more speech frames or comfort noise frames, as described in the ToC of the payload. Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame present in the speech data. Sjoberg, et al. Standards Track [Page 20] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Each speech frame represents 20 ms of speech encoded with the mode indicated in the FT field of the corresponding ToC entry. The length of the speech frame is implicitly defined by the mode indicated in the FT field. The order and numbering notation of the bits are as specified for Interface Format 1 (IF1) in [2] for AMR and [4] for AMR-WB. As specified there, the bits of speech frames have been rearranged in order of decreasing sensitivity, while the bits of comfort noise frames are in the order produced by the encoder. The resulting bit sequence for a frame of length K bits is denoted d(0), d(1), ..., d(K-1). 4.3.4. Algorithm for Forming the Payload The complete RTP payload in bandwidth-efficient mode is formed by packing bits from the payload header, table of contents, and speech frames in order (as defined by their corresponding ToC entries in the ToC list), and to bring the payload to octet alignment, 0 to 7 padding bits. Padding bits MUST be set to zero and MUST be ignored on reception. They are packed contiguously into octets beginning with the most significant bits of the fields and the octets. To be precise, the four-bit payload header is packed into the first octet of the payload with bit 0 of the payload header in the most significant bit of the octet. The four most significant bits (numbered 0-3) of the first ToC entry are packed into the least significant bits of the octet, ending with bit 3 in the least significant bit. Packing continues in the second octet with bit 4 of the first ToC entry in the most significant bit of the octet. If more than one frame is contained in the payload, then packing continues with the second and successive ToC entries. Bit 0 of the first data frame follows immediately after the last ToC bit, proceeding through all the bits of the frame in numerical order. Bits from any successive frames follow contiguously in numerical order for each frame and in consecutive order of the frames. If speech data is missing for one or more speech frame within the sequence, because of, for example, DTX, a ToC entry with FT set to NO_DATA SHALL be included in the ToC for each of the missing frames, but no data bits are included in the payload for the missing frame (see Section 4.3.5.2 for an example). 4.3.5. Payload Examples 4.3.5.1. Single-Channel Payload Carrying a Single Frame The following diagram shows a bandwidth-efficient AMR payload from a single-channel session carrying a single speech frame-block. Sjoberg, et al. Standards Track [Page 21] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 In the payload, no specific mode is requested (CMR=15), the speech frame is not damaged at the IP origin (Q=1), and the coding mode is AMR 7.4 kbps (FT=4). The encoded speech bits, d(0) to d(147), are arranged in descending sensitivity order according to [2]. Finally, two padding bits (P) are added to the end as padding to make the payload octet aligned. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=15|0| FT=4 |1|d(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d(147)|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.5.2. Single-Channel Payload Carrying Multiple Frames The following diagram shows a single-channel, bandwidth-efficient compound AMR-WB payload that contains four frames, of which one has no speech data. The first frame is a speech frame at 6.6 kbps mode (FT=0) that is composed of speech bits d(0) to d(131). The second frame is an AMR-WB SID frame (FT=9), consisting of bits g(0) to g(39). The third frame is a NO_DATA frame and does not carry any speech information, it is represented in the payload by its ToC entry. The fourth frame in the payload is a speech frame at 8.85 kbps mode (FT=1), it consists of speech bits h(0) to h(176). As shown below, the payload carries a mode request for the encoder on the receiver's side to change its future coding mode to AMR-WB 8.85 kbps (CMR=1). None of the frames are damaged at IP origin (Q=1). The encoded speech and SID bits, d(0) to d(131), g(0) to g(39), and h(0) to h(176), are arranged in the payload in descending sensitivity order according to [4]. (Note, no speech bits are present for the third frame.) Finally, seven zero bits are padded to the end to make the payload octet aligned. Sjoberg, et al. Standards Track [Page 22] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=1 |1| FT=0 |1|1| FT=9 |1|1| FT=15 |1|0| FT=1 |1|d(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d(131)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |g(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | g(39)|h(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | h(176)|P|P|P|P|P|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 4.3.5.3. Multi-Channel Payload Carrying Multiple Frames The following diagram shows a two-channel payload carrying 3 frame- blocks, i.e., the payload will contain 6 speech frames. In the payload, all speech frames contain the same mode 7.4 kbps (FT=4) and are not damaged at IP origin. The CMR is set to 15, i.e., no specific mode is requested. The two channels are defined as left (L) and right (R) in that order. The encoded speech bits is designated dXY(0).. dXY(K-1), where X = block number, Y = channel, and K is the number of speech bits for that mode. Exemplifying this, for frame-block 1 of the left channel, the encoded bits are designated as d1L(0) to d1L(147). Sjoberg, et al. Standards Track [Page 23] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=15|1|1L FT=4|1|1|1R FT=4|1|1|2L FT=4|1|1|2R FT=4|1|1|3L FT| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |4|1|0|3R FT=4|1|d1L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d1L(147)|d1R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d1R(147)|d2L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |d2L(147|d2R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d2R(147)|d3L(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d3L(147)|d3R(0) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | d3R(147)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Sjoberg, et al. Standards Track [Page 24] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4. Octet-Aligned Mode 4.4.1. The Payload Header In octet-aligned mode, the payload header consists of a 4-bit CMR, 4 reserved bits, and optionally, an 8-bit interleaving header, as shown below: 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 +-+-+-+-+-+-+-+-+- - - - - - - - | CMR |R|R|R|R| ILL | ILP | +-+-+-+-+-+-+-+-+- - - - - - - - CMR (4 bits): same as defined in Section 4.3.1. R: is a reserved bit that MUST be set to zero. All R bits MUST be ignored by the receiver. ILL (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled out-of-band for the session. ILL=L indicates to the receiver that the interleaving length is L+1, in number of frame-blocks. ILP (4 bits, unsigned integer): This is an OPTIONAL field that is present only if interleaving is signalled. ILP MUST take a value between 0 and ILL, inclusive, indicating the interleaving index for frame-blocks in this payload in the interleaving group. If the value of ILP is found greater than ILL, the payload SHOULD be discarded. ILL and ILP fields MUST be present in each packet in a session if interleaving is signalled for the session. Interleaving MUST be performed on a frame-block basis (i.e., NOT on a frame basis) in a multi-channel session. The following example illustrates the arrangement of speech frame- blocks in an interleaving group during an interleaving session. Here we assume ILL=L for the interleaving group that starts at speech frame-block n. We also assume that the first payload packet of the interleaving group is s, and the number of speech frame-blocks carried in each payload is N. Then we will have: Sjoberg, et al. Standards Track [Page 25] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Payload s (the first packet of this interleaving group): ILL=L, ILP=0, Carry frame-blocks: n, n+(L+1), n+2*(L+1), ..., n+(N-1)*(L+1) Payload s+1 (the second packet of this interleaving group): ILL=L, ILP=1, frame-blocks: n+1, n+1+(L+1), n+1+2*(L+1), ..., n+1+(N-1)*(L+1) ... Payload s+L (the last packet of this interleaving group): ILL=L, ILP=L, frame-blocks: n+L, n+L+(L+1), n+L+2*(L+1), ..., n+L+(N-1)*(L+1) The next interleaving group will start at frame-block n+N*(L+1). There will be no interleaving effect unless the number of frame- blocks per packet (N) is at least 2. Moreover, the number of frame- blocks per payload (N) and the value of ILL MUST NOT be changed inside an interleaving group. In other words, all payloads in an interleaving group MUST have the same ILL and MUST contain the same number of speech frame-blocks. The sender of the payload MUST only apply interleaving if the receiver has signalled its use through out-of-band means. Since interleaving will increase buffering requirements at the receiver, the receiver uses media type parameter ""interleaving=I"" to set the maximum number of frame-blocks allowed in an interleaving group to I."
"When performing interleaving, the sender MUST use a proper number of frame-blocks per payload (N) and ILL so that the resulting size of an interleaving group is less or equal to I, that is, N*(L+1)<=I. 4.4.2. The Payload Table of Contents and Frame CRCs The table of contents (ToC) in octet-aligned mode consists of a list of ToC entries where each entry corresponds to a speech frame carried in the payload and, optionally, a list of speech frame CRCs. That is, the ToC is as follows: +---------------------+ | list of ToC entries | +---------------------+ | list of frame CRCs | (optional) - - - - - - - - - - - Note, for ToC entries with FT=14 or 15, there will be no corresponding speech frame or frame CRC present in the payload. Sjoberg, et al. Standards Track [Page 26] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The list of ToC entries is organized in the same way as described for bandwidth-efficient mode in 4.3.2, with the following exception: when interleaving is used, the frame-blocks in the ToC will almost never be placed consecutively in time. Instead, the presence and order of the frame-blocks in a packet will follow the pattern described in 4.4.1. The following example shows the ToC of three consecutive packets, each carrying three frame-blocks, in an interleaved two-channel session. Here, the two channels are left (L) and right (R) with L coming before R, and the interleaving length is 3 (i.e., ILL=2). This results in the interleaving group size of 9 frame-blocks. Packet #1 --------- ILL=2, ILP=0: +----+----+----+----+----+----+ | 1L | 1R | 4L | 4R | 7L | 7R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 1 Block 4 Block 7 Packet #2 --------- ILL=2, ILP=1: +----+----+----+----+----+----+ | 2L | 2R | 5L | 5R | 8L | 8R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 2 Block 5 Block 8 Packet #3 --------- ILL=2, ILP=2: +----+----+----+----+----+----+ | 3L | 3R | 6L | 6R | 9L | 9R | +----+----+----+----+----+----+ |<------->|<------->|<------->| Frame- Frame- Frame- Block 3 Block 6 Block 9 Sjoberg, et al. Standards Track [Page 27] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 A ToC entry takes the following format in octet-aligned mode: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |F| FT |Q|P|P| +-+-+-+-+-+-+-+-+ F (1 bit): see definition in Section 4.3.2. FT (4 bits, unsigned integer): see definition in Section 4.3.2. Q (1 bit): see definition in Section 4.3.2. P bits: padding bits, MUST be set to zero, and MUST be ignored on reception. The list of CRCs is OPTIONAL. It only exists if the use of CRC is signalled out-of-band for the session. When present, each CRC in the list is 8 bits long and corresponds to a speech frame (NOT a frame- block) carried in the payload. Calculation and use of the CRC is specified in the next section. 4.4.2.1. Use of Frame CRC for UED over IP The general concept of UED/UEP over IP is discussed in Section 3.6. This section provides more details on how to use the frame CRC in the octet-aligned payload header together with a partial transport layer checksum to achieve UED. To achieve UED, one SHOULD use a transport layer checksum (for example, the one defined in UDP-Lite [19]) to protect the IP, transport protocol (e.g., UDP-Lite), and RTP headers, as well as the payload header and the table of contents in the payload. The frame CRC, when used, MUST be calculated only over all class A bits in the AMR or AMR-WB frame. Class B and C bits in the AMR or AMR-WB frame MUST NOT be included in the CRC calculation and SHOULD NOT be covered by the transport checksum. Note, the number of class A bits for various coding modes in AMR codec is specified as informative in [2] and is therefore copied into Table 1 in Section 3.6 to make it normative for this payload format. The number of class A bits for various coding modes in AMR-WB codec is specified as normative in Table 2 in [4], and the SID frame (FT=9) has 40 class A bits. These definitions of class A bits MUST be used for this payload format. Sjoberg, et al. Standards Track [Page 28] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 If the transport layer checksum or link layer checksum detects any errors within the protected (sensitive) part, it is assumed that the complete packet will be discarded as defined by UDP-Lite [19]. The receiver of the payload SHOULD examine the data integrity of the received class A bits by re-calculating the CRC over the received class A bits and comparing the result to the value found in the received payload header. If the two values mismatch, the receiver SHALL consider the class A bits in the receiver frame damaged and MUST clear the Q flag of the frame (i.e., set it to 0). This will subsequently cause the frame to be marked as SPEECH_BAD, if the FT of the frame is 0..7 for AMR or 0..8 for AMR-WB, or SID_BAD if the FT of the frame is 8 for AMR or 9 for AMR-WB, before it is passed to the speech decoder. See [6] and [7] more details. The following example shows an octet-aligned ToC with a CRC list for a payload containing 3 speech frames from a single-channel session (assuming none of the FTs is equal to 14 or 15): 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1| FT#1 |Q|P|P|1| FT#2 |Q|P|P|0| FT#3 |Q|P|P| CRC#1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC#2 | CRC#3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Each of the CRCs takes 8 bits 0 1 2 3 4 5 6 7 +---+---+---+---+---+---+---+---+ | c0| c1| c2| c3| c4| c5| c6| c7| +---+---+---+---+---+---+---+---+ (MSB) (LSB) and is calculated by the cyclic generator polynomial, C(x) = 1 + x^2 + x^3 + x^4 + x^8 where ^ is the exponentiation operator. In binary form, the polynomial appears as follows: 101110001 (MSB..LSB). The actual calculation of the CRC is made as follows: First, an 8-bit CRC register is reset to zero: 00000000. For each bit over which the CRC shall be calculated, an XOR operation is made between the rightmost (LSB) bit of the CRC register and the bit. The CRC Sjoberg, et al. Standards Track [Page 29] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 register is then right-shifted one step (each bit's significance is reduced by one), inputting a ""0"" as the leftmost bit (MSB). If the result of the XOR operation mentioned above is a ""1"", then ""10111000"" is bit-wise XOR-ed into the CRC register. This operation is repeated for each bit that the CRC should cover. In this case, the first bit would be d(0) for the speech frame for which the CRC should cover. When the last bit (e.g., d(54) for AMR 5.9 according to Table 1 in Section 3.6) has been used in this CRC calculation, the contents in CRC register should simply be copied to the corresponding field in the list of CRCs. Fast calculation of the CRC on a general-purpose CPU is possible using a table-driven algorithm. 4.4.3. Speech Data In octet-aligned mode, speech data is carried in a similar way to that in the bandwidth-efficient mode as discussed in Section 4.3.3, with the following exceptions: - The last octet of each speech frame MUST be padded with zero bits at the end if all bits in the octet are not used. The padding bits MUST be ignored on reception. In other words, each speech frame MUST be octet-aligned. - When multiple speech frames are present in the speech data (i.e., compound payload), the speech frames are arranged either one whole frame after another as usual, or with the octets of all frames interleaved together at the octet level, depending on the media type parameters negotiated for the payload type. Since the bits within each frame are ordered with the most error-sensitive bits first, interleaving the octets collects those sensitive bits from all frames to be nearer the beginning of the packet. This is called ""robust sorting order"" which allows the application of UED (such as UDP-Lite [19]) or UEP (such as the ULP [22]) mechanisms to the payload data. The details of assembling the payload are given in the next section. The use of robust sorting order for a payload type MUST be agreed via out-of-band means. Section 8 specifies a media type parameter for this purpose. Note, robust sorting order MUST only be performed on the frame level and thus is independent of interleaving, which is at the frame-block level, as described in Section 4.4.1. In other words, robust sorting can be applied to either non-interleaved or interleaved payload types. Sjoberg, et al. Standards Track [Page 30] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4.4. Methods for Forming the Payload Two different packetization methods, namely, normal order and robust sorting order, exist for forming a payload in octet-aligned mode. In both cases, the payload header and table of contents are packed into the payload the same way; the difference is in the packing of the speech frames. The payload begins with the payload header of one octet, or two octets if frame interleaving is selected. The payload header is followed by the table of contents consisting of a list of one-octet ToC entries. If frame CRCs are to be included, they follow the table of contents with one 8-bit CRC filling each octet. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no CRC present. The speech data follows the table of contents, or the CRCs if present. For packetization in the normal order, all of the octets comprising a speech frame are appended to the payload as a unit. The speech frames are packed in the same order as their corresponding ToC entries are arranged in the ToC list, with the exception that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame. For packetization in robust sorting order, the octets of all speech frames are interleaved together at the octet level. That is, the data portion of the payload begins with the first octet of the first frame, followed by the first octet of the second frame, then the first octet of the third frame, and so on. After the first octet of the last frame has been appended, the cycle repeats with the second octet of each frame. The process continues for as many octets as are present in the longest frame. If the frames are not all the same octet length, a shorter frame is skipped once all octets in it have been appended. The order of the frames in the cycle will be sequential if frame interleaving is not in use, or according to the interleave pattern specified in the payload header if frame interleaving is in use. Note that if a given frame has a ToC entry with FT=14 or 15, there will be no data octets present for that frame, so it is skipped in the robust sorting cycle. The UED and/or UEP is RECOMMENDED to cover at least the RTP header, payload header, table of contents, and class A bits of a sorted payload. Exactly how many octets need to be covered depends on the network and application. If CRCs are used together with robust sorting, only the RTP header, the payload header, and the ToC SHOULD be covered by UED/UEP. The means for communicating the number of octets to be covered to other layers performing UED/UEP is beyond the scope of this specification. Sjoberg, et al. Standards Track [Page 31] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 4.4.5. Payload Examples 4.4.5.1. Basic Single-Channel Payload Carrying Multiple Frames The following diagram shows an octet aligned payload from a single channel payload type that carries two AMR frames of 7.95 kbps coding mode (FT=5). In the payload, a codec mode request is sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. No frame CRC, interleaving, or robust sorting is in use. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=6 |R|R|R|R|1|FT#1=5 |Q|P|P|0|FT#2=5 |Q|P|P| f1(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f1(8..15) | f1(16..23) | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |f1(152..158) |P| f2(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f2(8..15) | f2(16..23) | .... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ... |f2(152..158) |P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note, in the above example, the last octet in both speech frames is padded with one zero bit to make it octet-aligned. 4.4.5.2. Two-Channel Payload with CRC, Interleaving, and Robust Sorting This example shows an octet aligned payload from a two-channel payload type. Two frame-blocks, each containing two speech frames of 7.95 kbps coding mode (FT=5), are carried in this payload. The two channels are left (L) and right (R) with L coming before R. In the payload, a codec mode request is also sent (CMR=6), requesting the encoder at the receiver's side to use AMR 10.2 kbps coding mode. Moreover, frame CRC, robust sorting, and frame-block interleaving are all enabled for the payload type. The interleaving length is 2 (ILL=1), and this payload is the first one in an interleaving group (ILP=0). Sjoberg, et al. Standards Track [Page 32] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The first two frames in the payload are the L and R channel speech frames of frame-block #1, consisting of bits f1L(0..158) and f1R(0..158), respectively. The next two frames are the L and R channel frames of frame-block #3, consisting of bits f3L(0..158) and f3R(0..158), respectively, due to interleaving. For each of the four speech frames, a CRC is calculated as CRC1L(0..7), CRC1R(0..7), CRC3L(0..7), and CRC3R(0..7), respectively. Finally, the payload is robust sorted. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CMR=6 |R|R|R|R| ILL=1 | ILP=0 |1|FT#1L=5|Q|P|P|1|FT#1R=5|Q|P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1|FT#3L=5|Q|P|P|0|FT#3R=5|Q|P|P| CRC1L | CRC1R | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC3L | CRC3R | f1L(0..7) | f1R(0..7) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(0..7) | f3R(0..7) | f1L(8..15) | f1R(8..15) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(8..15) | f3R(8..15) | f1L(16..23) | f1R(16..23) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | f3L(144..151) | f3R(144..151) |f1L(152..158)|P|f1R(152..158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |f3L(152..158)|P|f3R(152..158)|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Note, in the above example, the last octet in all four speech frames is padded with one zero bit to make it octet-aligned. 4.5. Implementation Considerations An application implementing this payload format MUST understand all the payload parameters in the out-of-band signaling used. For example, if an application uses SDP, all the SDP and media type parameters in this document MUST be understood. This requirement ensures that an implementation always can decide if it is capable or not of communicating. No operating mode of the payload format is mandatory to implement. The requirements of the application using the payload format should be used to determine what to implement. To achieve basic interoperability, an implementation SHOULD at least implement both bandwidth-efficient and octet-aligned modes for a single audio Sjoberg, et al. Standards Track [Page 33] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 channel. The other operating modes: interleaving, robust sorting, and frame-wise CRC (in both single and multi-channel) are OPTIONAL to implement. The mode-change-period, mode-change-capability, and mode-change- neighbor parameters are intended for signaling with GSM endpoints. When interoperability with GSM is desired, encoders SHOULD only perform codec mode changes to neighboring modes and in integer multiples of 40 ms (two frame-blocks), but decoders SHOULD accept codec mode changes at any time, i.e., for every frame-block. The encoder may arbitrarily select the initial phase (odd or even frame- block) where codec mode changes are performed, but then SHOULD stick to that phase as far as possible. However, in rare cases, handovers or other events (e.g., call forwarding) may change this phase and may also cause mode changes to non-neighboring modes. The decoder SHALL therefore be prepared to accept changes also in the other phase and to other modes. Section 8 specifies the usage of the parameters mode-change-period and mode-change-capability to indicate the desired behavior in applications. See 3GPP TS 26.103 [28] for preferred AMR and AMR-WB configurations for operation in GSM and 3GPP UMTS networks. In gateway scenarios, encoders can be requested through the ""mode-set"" parameter to use a limited mode-set that is supported by the link beyond the gateway. Further, to avoid congestion on that link, the encoder SHOULD limit the initial codec mode for a session to a lower mode, until at least one frame-block is received with rate control information. 4.5.1. Decoding Validation When processing a received payload packet, if the receiver finds that the calculated payload length, based on the information for the payload type and the values found in the payload header fields, does not match the size of the received packet, the receiver SHOULD discard the packet. This is because decoding a packet that has errors in its length field could severely degrade the speech quality. Sjoberg, et al. Standards Track [Page 34] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5. AMR and AMR-WB Storage Format The storage format is used for storing AMR or AMR-WB speech frames in a file or as an email attachment. Multiple channel content is supported. In general, an AMR or AMR-WB file has the following structure: +------------------+ | Header | +------------------+ | Speech frame 1 | +------------------+ : ... : +------------------+ | Speech frame n | +------------------+ Note, to preserve interoperability with already deployed implementations, single-channel content uses a file header format different from that of multi-channel content. There also exists another storage format for AMR and AMR-WB that is suitable for applications with more advanced demands on the storage format, like random access or synchronization with video. This format is the 3GPP-specified ISO-based multimedia file format 3GP [31]. Its media type is specified by RFC 3839 [32]. 5.1. Single-Channel Header A single-channel AMR or AMR-WB file header contains only a magic number. Different magic numbers are defined to distinguish AMR from AMR-WB. The magic number for single-channel AMR files MUST consist of ASCII character string: ""#!AMR\n"" (or 0x2321414d520a in hexadecimal). The magic number for single-channel AMR-WB files MUST consist of ASCII character string: ""#!AMR-WB\n"" (or 0x2321414d522d57420a in hexadecimal). Sjoberg, et al. Standards Track [Page 35] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Note, the ""\n"" is an important part of the magic numbers and MUST be included in the comparison, since, otherwise, the single-channel magic numbers above will become indistinguishable from those of the multi-channel files defined in the next section. 5.2. Multi-Channel Header The multi-channel header consists of a magic number followed by a 32-bit channel description field, giving the multi-channel header the following structure: +------------------+ | magic number | +------------------+ | chan-desc field | +------------------+ The magic number for multi-channel AMR files MUST consist of the ASCII character string: ""#!AMR_MC1.0\n"" (or 0x2321414d525F4D43312E300a in hexadecimal). The magic number for multi-channel AMR-WB files MUST consist of the ASCII character string: ""#!AMR-WB_MC1.0\n"" (or 0x2321414d522d57425F4D43312E300a in hexadecimal). The version number in the magic numbers refers to the version of the file format. The 32 bit channel description field is defined as: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reserved bits | CHAN | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Reserved bits: MUST be set to 0 when written, and a reader MUST ignore them. CHAN (4 bits, unsigned integer): Indicates the number of audio channels contained in this storage file. The valid values and the order of the channels within a frame-block are specified in Section 4.1 in [12]. Sjoberg, et al. Standards Track [Page 36] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 5.3. Speech Frames After the file header, speech frame-blocks consecutive in time are stored in the file. Each frame-block contains a number of octet- aligned speech frames equal to the number of channels, and stored in increasing order, starting with channel 1. Each stored speech frame starts with a one-octet frame header with the following format: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |P| FT |Q|P|P| +-+-+-+-+-+-+-+-+ The FT field and the Q bit are defined in the same way as in Section 4.3.2. The P bits are padding and MUST be set to 0, and MUST be ignored. Following this one octet header come the speech bits as defined in 4.4.3. The last octet of each frame is padded with zeroes, if needed, to achieve octet alignment. The following example shows an AMR frame in 5.9 kbps coding mode (with 118 speech bits) in the storage format. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |P| FT=2 |Q|P|P| | +-+-+-+-+-+-+-+-+ + | | + Speech bits for frame-block n, channel k + | | + +-+-+ | |P|P| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Non-received speech frames or frame-blocks between SID updates during non-speech periods MUST be stored as NO_DATA frames (frame type 15, as defined in [2] and [4]). Frames or frame-blocks lost in transmission MUST be stored as NO_DATA frames or SPEECH_LOST (frame type 14, only available for AMR-WB) in complete frame-blocks to keep synchronization with the original media. Comfort noise frames of other types than AMR SID (FT=8) (i.e., frame type 9, 10, and 11 for AMR) SHALL NOT be used in the AMR file format. Sjoberg, et al. Standards Track [Page 37] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 6. Congestion Control The general congestion control considerations for transporting RTP data apply to AMR or AMR-WB speech over RTP as well. However, the multi-rate capability of AMR and AMR-WB speech coding may provide an advantage over other payload formats for controlling congestion since the bandwidth demand can be adjusted by selecting a different coding mode. Another parameter that may impact the bandwidth demand for AMR and AMR-WB is the number of frame-blocks that are encapsulated in each RTP payload. Packing more frame-blocks in each RTP payload can reduce the number of packets sent and hence the overhead from IP/UDP/RTP headers, at the expense of increased delay. If forward error correction (FEC) is used to combat packet loss, the amount of redundancy added by FEC will need to be regulated so that the use of FEC itself does not cause a congestion problem. It is RECOMMENDED that AMR or AMR-WB applications using this payload format employ congestion control. The actual mechanism for congestion control is not specified but should be suitable for real- time flows, possibly ""TCP Friendly Rate Control"" [21]. 7. Security Considerations RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in [8] and in any used profile, like AVP [12] or SAVP [26]. As this format transports encoded speech, the main security issues include confidentiality, authentication, and integrity of the speech itself. The payload format itself does not have any built-in security mechanisms. External mechanisms, such as SRTP [26], need to be used for this functionality. Note that the appropriate mechanism to provide security to RTP and the payloads following this memo may vary. It is dependent on the application, the transport, and the signaling protocol employed. Therefore, a single mechanism is not sufficient, although if suitable the usage of SRTP [26] is RECOMMENDED. Other known mechanisms that may be used are IPsec [33] and TLS [34] (RTP over TCP), but other alternatives may also exist. This payload format does not exhibit any significant non-uniformity in the receiver side computational complexity for packet processing, and thus is unlikely to pose a denial-of-service threat due to the receipt of pathological data. Sjoberg, et al. Standards Track [Page 38] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 7.1. Confidentiality To achieve confidentiality of the encoded AMR or AMR-WB speech, all speech data bits will need to be encrypted. There is less of a need to encrypt the payload header or the table of contents due to a) that they only carry information about the requested speech mode, frame type, and frame quality, and b) that this information could be useful to some third party, e.g., quality monitoring. The packetization and unpacketization of the AMR and AMR-WB payload is done only at the endpoints. Therefore encryption should be performed after packet encapsulation, and decryption should be performed before packet decapsulation. Encryption may affect interleaving. Specifically, a change of keys should occur at the boundary between interleaving groups. If it is not done at that boundary on both endpoints, the speech quality will be degraded during the complete interleaving group for any receiver. The encryption mechanism may impact the robustness of the error correcting mechanism. This is discussed in Section 9.5 of SRTP [26]. From this, UED/UEP based on robust sorting may be difficult to apply when the payload data is encrypted. 7.2. Authentication and Integrity To authenticate the sender and to protect the integrity of the RTP packets in transit, an external mechanism has to be used. As stated before, it is RECOMMENDED that SRTP [26] be used for common interoperability. Note that the use of UED/UEP may be difficult to combine with some integrity protection mechanisms because any bit errors will cause the integrity check to fail. Data tampering by a man-in-the-middle attacker could result in erroneous depacketization/decoding that could lower the speech quality or produce unintelligible communications. Tampering with the CMR field may result in a different speech quality than desired. 8. Payload Format Parameters This section defines the parameters that may be used to select optional features of the AMR and AMR-WB payload formats. The parameters are defined here as part of the media type registrations for the AMR and AMR-WB speech codecs. The registrations are done following RFC 4855 [15] and the media registration rules [14]. Sjoberg, et al. Standards Track [Page 39] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 A mapping of the parameters into the Session Description Protocol (SDP) [11] is also provided for those applications that use SDP. Equivalent parameters could be defined elsewhere for use with control protocols that do not use media types or SDP. Two separate media type registrations are made, one for AMR and one for AMR-WB, because they are distinct encodings that must be distinguished by their own media type. Data formats are specified for both real-time transport in RTP and for storage type applications such as email attachments. 8.1. AMR Media Type Registration The media type for the Adaptive Multi-Rate (AMR) codec is allocated from the IETF tree since AMR is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real-time transfers via stored files. Note, any unspecified parameter MUST be ignored by the receiver. Media Type name: audio Media subtype name: AMR Required parameters: none Optional parameters: These parameters apply to RTP transfer only. octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed. mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma separated list of modes from the set: 0,...,7 (see Table 1a [2]). The SID frame type 8 and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type. Sjoberg, et al. Standards Track [Page 40] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by a period of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame- block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at any time during the session, i.e., N=1. mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change- period=2. If this parameter is not present, the mode- change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required. Thus, clients RECOMMENDED to have the capability to support transmission according to mode-change-capability=2. mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed. maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet. Sjoberg, et al. Standards Track [Page 41] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session. robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session. interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used. ptime: see RFC 4566 [11]. channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1. max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present. Encoding considerations: The Audio data is binary data, and must be encoded for non- binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14]. Security considerations: See Section 7 of RFC 4867. Public specification: RFC 4867 3GPP TS 26.090, 26.092, 26.093, 26.101 Sjoberg, et al. Standards Track [Page 42] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras. Additional information: The following applies to stored-file transfer methods: Magic numbers: single-channel: ASCII character string ""#!AMR\n"" (or 0x2321414d520a in hexadecimal) multi-channel: ASCII character string ""#!AMR_MC1.0\n"" (or 0x2321414d525F4D43312E300a in hexadecimal) File extensions: amr, AMR Macintosh file type code: ""amr "" (fourth character is space) AMR speech frames may also be stored in the file format ""3GP"" defined in 3GPP TS 26.244 [31], which is identified using the media types ""audio/3GPP"" or ""video/3GPP"" as registered by RFC 3839 [32]. Person & email address to contact for further information: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices. Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used. Author: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Change controller: IETF Audio/Video Transport working group delegated from the IESG. Sjoberg, et al. Standards Track [Page 43] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 8.2. AMR-WB Media Type Registration The media type for the Adaptive Multi-Rate Wideband (AMR-WB) codec is allocated from the IETF tree since AMR-WB is a widely used speech codec in general VoIP and messaging applications. This media type registration covers both real-time transfer via RTP and non-real- time transfers via stored files. Note, any unspecified parameter MUST be ignored by the receiver. Media Type name: audio Media subtype name: AMR-WB Required parameters: none Optional parameters: These parameters apply to RTP transfer only. octet-align: Permissible values are 0 and 1. If 1, octet-aligned operation SHALL be used. If 0 or if not present, bandwidth-efficient operation is employed. mode-set: Restricts the active codec mode set to a subset of all modes, for example, to be able to support transport channels such as GSM networks in gateway use cases. Possible values are a comma-separated list of modes from the set: 0,...,8 (see Table 1a [4]). The SID frame type 9, SPEECH_LOST (frame type 14), and NO_DATA (frame type 15) are never included in the mode set, but can always be used. If mode-set is specified, it MUST be abided, and frames encoded with modes outside of the subset MUST NOT be sent in any RTP payload or used in codec mode requests. If not present, all codec modes are allowed for the payload type. mode-change-period: Specifies a number of frame-blocks, N (1 or 2), that is the frame-block period at which codec mode changes are allowed for the sender. The initial phase of the interval is arbitrary, but changes must be separated by multiples of N frame-blocks, i.e., a value of 2 allows the sender to change mode every second frame- block. The value of N SHALL be either 1 or 2. If this parameter is not present, mode changes are allowed at Any time during the session, i.e., N=1. Sjoberg, et al. Standards Track [Page 44] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 mode-change-capability: Specifies if the client is capable to transmit with a restricted mode change period. The parameter may take value of 1 or 2. A value of 1 indicates that the client is not capable of restricting the mode change period to 2, and that the codec mode may be changed at any point. A value of 2 indicates that the client has the capability to restrict the mode change period to 2, and thus that the client can correctly interoperate with a receiver requiring a mode-change- period=2. If this parameter is not present, the mode- change restriction capability is not supported, i.e. mode-change-capability=1. To be able to interoperate fully with gateways to circuit switched networks (for example, GSM networks), transmissions with restricted mode changes (mode-change-capability=2) are required."
"Thus, clients are RECOMMENDED to have the capability to support transmission according to mode-change-capability=2. mode-change-neighbor: Permissible values are 0 and 1. If 1, the sender SHOULD only perform mode changes to the neighboring modes in the active codec mode set. Neighboring modes are the ones closest in bit rate to the current mode, either the next higher or next lower rate. If 0 or if not present, change between any two modes in the active codec mode set is allowed. maxptime: The maximum amount of media which can be encapsulated in a payload packet, expressed as time in milliseconds. The time is calculated as the sum of the time that the media present in the packet represents. The time SHOULD be an integer multiple of the frame size. If this parameter is not present, the sender MAY encapsulate any number of speech frames into one RTP packet. crc: Permissible values are 0 and 1. If 1, frame CRCs SHALL be included in the payload. If 0 or not present, CRCs SHALL NOT be used. If crc=1, this also implies automatically that octet-aligned operation SHALL be used for the session. robust-sorting: Permissible values are 0 and 1. If 1, the payload SHALL employ robust payload sorting. If 0 or if not present, simple payload sorting SHALL be used. If robust-sorting=1, this also implies automatically that octet-aligned operation SHALL be used for the session. Sjoberg, et al. Standards Track [Page 45] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 interleaving: Indicates that frame-block level interleaving SHALL be used for the session, and its value defines the maximum number of frame-blocks allowed in an interleaving group (see Section 4.4.1). If this parameter is not present, interleaving SHALL NOT be used. The presence of this parameter also implies automatically that octet-aligned operation SHALL be used. ptime: see RFC 2327 [11]. channels: The number of audio channels. The possible values (1-6) and their respective channel order is specified in Section 4.1 in [12]. If omitted, it has the default value of 1. max-red: The maximum duration in milliseconds that elapses between the primary (first) transmission of a frame and any redundant transmission that the sender will use. This parameter allows a receiver to have a bounded delay when redundancy is used. Allowed values are between 0 (no redundancy will be used) and 65535. If the parameter is omitted, no limitation on the use of redundancy is present. Encoding considerations: The Audio data is binary data, and must be encoded for non- binary transport; the Base64 encoding is suitable for email. When used in RTP context the data is framed as defined in [14]. Security considerations: See Section 7 of RFC 4867. Public specification: RFC 4867 3GPP TS 26.190, 26.192, 26.193, 26.201 Applications that use this media type: This media type is used in numerous applications needing transport or storage of encoded voice. Some examples include; Voice over IP, streaming media, voice messaging, and voice recording on digital cameras. Sjoberg, et al. Standards Track [Page 46] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Additional information: The following applies to stored-file transfer methods: Magic numbers: single-channel: ASCII character string ""#!AMR-WB\n"" (or 0x2321414d522d57420a in hexadecimal) multi-channel: ASCII character string ""#!AMR-WB_MC1.0\n"" (or 0x2321414d522d57425F4D43312E300a in hexadecimal) File extensions: awb, AWB Macintosh file type code: amrw Object identifier or OID: none AMR-WB speech frames may also be stored in the file format ""3GP"" defined in 3GPP TS 26.244 [31] and identified using the media type ""audio/3GPP"" or ""video/3GPP"" as registered by RFC 3839 [32]. Person & email address to contact for further information: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Intended usage: COMMON. This media type is widely used in streaming, VoIP, and messaging applications on many types of devices. Restrictions on usage: When this media type is used in the context of transfer over RTP, the RTP payload format specified in Section 4 SHALL be used. In all other contexts, the file format defined in Section 5 SHALL be used. Author: Magnus Westerlund <magnus.westerlund@ericsson.com> Ari Lakaniemi <ari.lakaniemi@nokia.com> Change controller: IETF Audio/Video Transport working group delegated from the IESG. 8.3. Mapping Media Type Parameters into SDP The information carried in the media type specification has a specific mapping to fields in the Session Description Protocol (SDP) [11], which is commonly used to describe RTP sessions. When SDP is used to specify sessions employing the AMR or AMR-WB codec, the mapping is as follows: Sjoberg, et al. Standards Track [Page 47] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - The media type (""audio"") goes in SDP ""m="" as the media name. - The media subtype (payload format name) goes in SDP ""a=rtpmap"" as the encoding name. The RTP clock rate in ""a=rtpmap"" MUST be 8000 for AMR and 16000 for AMR-WB, and the encoding parameters (number of channels) MUST either be explicitly set to N or omitted, implying a default value of 1. The values of N that are allowed are specified in Section 4.1 in [12]. - The parameters ""ptime"" and ""maxptime"" go in the SDP ""a=ptime"" and ""a=maxptime"" attributes, respectively. - Any remaining parameters go in the SDP ""a=fmtp"" attribute by copying them directly from the media type parameter string as a semicolon-separated list of parameter=value pairs. 8.3.1. Offer-Answer Model Considerations The following considerations apply when using SDP Offer-Answer procedures to negotiate the use of AMR or AMR-WB payload in RTP: - Each combination of the RTP payload transport format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) is unique in its bit-pattern and not compatible with any other combination. When creating an offer in an application desiring to use the more advanced features (crc, robust-sorting, interleaving, or more than one channel), the offerer is RECOMMENDED to also offer a payload type containing only the octet-aligned or bandwidth-efficient configuration with a single channel. If multiple configurations are of interest to the application, they may all be offered; however, care should be taken not to offer too many payload types. An SDP answerer MUST include, in the SDP answer for a payload type, the following parameters unmodified from the SDP offer (unless it removes the payload type): ""octet- align""; ""crc""; ""robust-sorting""; ""interleaving""; and ""channels"". The SDP offerer and answerer MUST generate AMR or AMR-WB packets as described by these parameters. - The ""mode-set"" parameter can be used to restrict the set of active AMR/AMR-WB modes used in a session. This functionality is primarily intended for gateways to access networks such as GSM or 3GPP UMTS, where the access network may be capable of supporting only a subset of AMR/AMR-WB modes. The 3GPP preferred codec configurations are defined in 3GPP TS 26.103 [25], and it is RECOMMENDED that other networks also needing to restrict the mode set follow the preferred codec configurations defined in 3GPP for greatest interoperability. Sjoberg, et al. Standards Track [Page 48] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 The parameter is bi-directional, i.e., the restricted set applies to media both to be received and sent by the declaring entity. If a mode set was supplied in the offer, the answerer SHALL return the mode-set unmodified or reject the payload type. However, the answerer is free to choose a mode-set in the answer only if no mode-set was supplied in the offer for a unicast two-peer session. The mode-set in the answer is binding both for offerer and answerer. Thus, an offerer supporting all modes and subsets SHOULD NOT include the mode- set parameter. For any other offerer it is RECOMMENDED to include each mode-set it can support as a separate payload type within the offer. For multicast sessions, the answerer SHALL only participate in the session if it supports the offered mode-set. Thus, it is RECOMMENDED that any offer for a multicast session include only the mode-set it will require the answerers to support, and that the mode-set be likely to be supported by all participants. - The parameters ""mode-change-period"" and ""mode-change- capability"" are intended to be used in sessions with gateways, for example, when interoperating with GSM networks. Both parameters are declarative and are combined to allow a session participant to determine if the payload type can be supported. The mode-change-period will indicate what the offerer or answerer requires of data it receives, while the mode-change- capability indicates its transmission capabilities. A mode-change-period=2 in the offer indicates a requirement on the answerer to send with a mode-change period of 2, i.e., support mode-change-capability=2. If the answerer requires mode-change-period=2, it SHALL only include it in the answer if the offerer either has indicated support with mode-change- capability=2 or has indicated mode-change-period=2; otherwise, the payload type SHALL be rejected. An offerer that supports mode-change-capability=2 SHALL include the parameter in all offers to ensure the greatest possible interoperability, unless it includes mode-change-period=2 in the offer. The mode- change-capability SHOULD be included in answers. It is then indicating the answerer's capability to transmit with that mode-change-period for the provided payload format configuration. The information is useful in future re-negotiation of the payload formats. - The parameter ""mode-change-neighbor"" is a recommendation to restrict the switching of codec modes to its neighbor and SHOULD be followed. It is intended to be used in gateway scenarios (for example, to GSM networks) where the support of Sjoberg, et al. Standards Track [Page 49] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 this parameter and the operations it implies improves interoperability. ""mode-change-neighbor"" is a declarative parameter. By including the parameter, the offerer or answerer indicates that it desires to receive streams with ""mode-change-neighbor"" restrictions. - In most cases, the parameters ""maxptime"" and ""ptime"" will not affect interoperability; however, the setting of the parameters can affect the performance of the application. The SDP offer- answer handling of the ""ptime"" parameter is described in RFC 3264 [13]. The ""maxptime"" parameter MUST be handled in the same way. - The parameter ""max-red"" is a stream property parameter. For send-only or send-recv unicast media streams, the parameter declares the limitation on redundancy that the stream sender will use. For recvonly streams, it indicates the desired value for the stream sent to the receiver. The answerer MAY change the value, but is RECOMMENDED to use the same limitation as the offer declares. In the case of multicast, the offerer MAY declare a limitation; this SHALL be answered using the same value. A media sender using this payload format is RECOMMENDED to always include the ""max-red"" parameter. This information is likely to simplify the media stream handling in the receiver. This is especially true if no redundancy will be used, in which case ""max-red"" is set to 0. As this parameter was not defined originally, some senders will not declare this parameter even if it will limit or not send redundancy at all. - Any unknown parameter in an offer SHALL be removed in the answer. 8.3.2. Usage of Declarative SDP In declarative usage, like SDP in RTSP [29] or SAP [30], the parameters SHALL be interpreted as follows: - The payload format configuration parameters (octet-align, crc, robust-sorting, interleaving, and channels) are all declarative, and a participant MUST use the configuration(s) that is provided for the session. More than one configuration may be provided if necessary by declaring multiple RTP payload types; however, the number of types should be kept small. Sjoberg, et al. Standards Track [Page 50] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - Any restriction of the AMR or AMR-WB encoder mode-switching and mode usage through the ""mode-set"", and ""mode-change-period"" MUST be followed by all participants of the session. The restriction indicated by ""mode-change-neighbor"" SHOULD be followed. Please note that such restrictions may be necessary if gateways to other transport systems like GSM participate in the session. Failure to consider such restrictions may result in failure for a peer behind such a gateway to correctly receive all or parts of the session. Also, if different restrictions are needed by different peers in the same session (unless a common subset of the restrictions exists), some peer will not be able to participate. Note that the usage of mode-change-capability is meaningless when no negotiation exists, and can thus be excluded in any declarations. - Any ""maxptime"" and ""ptime"" values should be selected with care to ensure that the session's participants can achieve reasonable performance. - The usage of ""max-red"" puts a global upper limit on the usage of redundancy that needs to be followed by all that understand the parameter. However, due to the late addition of this parameter, it may be ignored by some implementations. 8.3.3. Examples Some example SDP session descriptions utilizing AMR and AMR-WB encodings follow. In these examples, long a=fmtp lines are folded to meet the column width constraints of this document; the backslash (""\"") at the end of a line and the carriage return that follows it should be ignored. In an example of the usage of AMR in a possible GSM gateway-to- gateway scenario, the offerer is capable of supporting three different mode-sets and needs the mode-change-period to be 2 in combination with mode-change-neighbor restrictions. The other gateway can only support two of these mode-sets and removes the payload type 97 in the answer. If the offering GSM gateway only supports a single mode-set active at the same time, it should consider doing the 1 out of N selection procedures described in Section 10.2 of [13]: Sjoberg, et al. Standards Track [Page 51] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Offer: m=audio 49120 RTP/AVP 97 98 99 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,5,7; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 Answer: m=audio 49120 RTP/AVP 98 99 a=rtpmap:98 AMR/8000/1 a=fmtp:98 mode-set=0,2,3,6; mode-change-period=2; \< mode-change-capability=2; mode-change-neighbor=1 a=rtpmap:99 AMR/8000/1 a=fmtp:99 mode-set=0,2,3,4; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 The following example shows the usage of AMR between a non-GSM endpoint and a GSM gateway. The non-GSM offerer requires no restrictions of the mode-change-period or mode-change-neighbor, but must signal its mode-change-capability in the offer and abide by those restrictions in the answer. Offer: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2 a=maxptime:20 Answer: m=audio 49120 RTP/AVP 97 a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-set=0,2,4,7; mode-change-period=2; \ mode-change-capability=2; mode-change-neighbor=1 a=maxptime:20 Sjoberg, et al. Standards Track [Page 52] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Example of usage of AMR-WB in a possible VoIP scenario where UEP may be used (99) and a fallback declaration (98): m=audio 49120 RTP/AVP 99 98 a=rtpmap:98 AMR-WB/16000 a=fmtp:98 octet-align=1; mode-change-capability=2 a=rtpmap:99 AMR-WB/16000 a=fmtp:99 octet-align=1; crc=1; mode-change-capability=2 Example of usage of AMR-WB in a possible streaming scenario (two channel stereo): m=audio 49120 RTP/AVP 99 a=rtpmap:99 AMR-WB/16000/2 a=fmtp:99 interleaving=30 a=maxptime:100 Note that the payload format (encoding) names are commonly shown in upper case. MIME subtypes are commonly shown in lower case. These names are case-insensitive in both places. Similarly, parameter names are case-insensitive both in MIME types and in the default mapping to the SDP a=fmtp attribute. 9. IANA Considerations Two media types (audio/AMR and audio/AMR-WB) have been updated; see Section 8. 10. Changes from RFC 3267 The differences between RFC 3267 and this document are as follows: - Added clarification of behavior in regards to mode change period and mode-change neighbor that is expected from an IP client; see Section 4.5. - Updated the maxptime for better clarification. The sentence that previously read: ""The time SHOULD be a multiple of the frame size."" now says ""The time SHOULD be an integer multiple of the frame size."" This should have no impact on interoperability. - Updated the definition of the mode-set parameter for clarification. - Restricted the values for mode-change-period to 1 or 2, which are the values used in circuit-switched AMR systems. Sjoberg, et al. Standards Track [Page 53] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 - Added a new media type parameter Mode-Change-Capability that defaults to 1, which is the assumed behavior of any non-updated implementation. This enables the offer-answer procedures to work. - Changed mode-change-neighbor to indicate a recommended behavior rather than a required one. - Added an Offer-Answer Section, see Section 8.3.1. This will have implications on the interoperability to implementations that have guessed how to perform offer/answer negotiation of the payload parameters. - Clarified and aligned the unequal detection usage with the published UDP-Lite specification in Sections 3.6.1 and 4.4.2.1. This included replacing a normative statement about packet handling with an informative paragraph with a reference to UDP- Lite. - Clarified the bit order in the CRC calculation in Section 4.4.2.1. - Corrected the reference in Section 5.3 for the Q and FT fields. - Changed the padding bit definition in Sections 4.4.2 and 5.3 so that it is clear that they shall be ignored. - Added a clarification that comfort noise frames with frame type 9, 10, and 11 SHALL NOT be used in the AMR file format. - Clarified in Section 4.3.2 that the rules about not sending NO_DATA frames do apply for all payload format configurations with the exception of the interleaved mode. - The reference list has been updated to now published RFCs: RFC 3448, RFC 3550, RFC 3551, RFC 3711, RFC 3828, and RFC 4566. A reference to 3GPP TS 26.101 has also been added. - Added notes in storage format section and media type registration that AMR and AMR-WB frames can also be stored in the 3GP file format. - Added a media type parameter ""max-red"" that allows the sender to declare a bounded usage of redundancy. This parameter allows a receiver to optimize its function as it will know if redundancy will be used or not. If it is used, the maximum extra delay introduced by the sender (that is needed to be considered by the receiver to fully utilize the redundancy) will be known. The addition of this parameter should have no negative effects on older implementations as they are mandated to ignore unknown Sjoberg, et al. Standards Track [Page 54] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 parameters per RFC 3267. In addition, older implementations are required to operate as if the value of max-red is unknown and possibly infinite. - Updated the media type registration to comply with the new registration rules. - Moved section on decoding validation from Security Considerations to Implementation Considerations, where it makes more sense. - Clarified the application of encryption, integrity protection, and authentication mechanism to the payload. 11. Acknowledgements The authors would like to thank Petri Koskelainen, Bernhard Wimmer, Tim Fingscheidt, Sanjay Gupta, Stephen Casner, and Colin Perkins for their significant contributions made throughout the writing and reviewing of RFC 3267 and this replacement. The authors would also like to thank Richard Ejzak, Thomas Belling, and Gorry Fairhurst for their input on this replacement of RFC 3267. 12. References 12.1. Normative References [1] 3GPP TS 26.090, ""Adaptive Multi-Rate (AMR) speech transcoding"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [2] 3GPP TS 26.101, ""AMR Speech Codec Frame Structure"", version 4.1.0 (2001-06), 3rd Generation Partnership Project (3GPP). [3] 3GPP TS 26.190 ""AMR Wideband speech codec; Transcoding functions"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [4] 3GPP TS 26.201 ""AMR Wideband speech codec; Frame Structure"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [5] Bradner, S., ""Key words for use in RFCs to Indicate Requirement Levels"", BCP 14, RFC 2119, March 1997. [6] 3GPP TS 26.093, ""AMR Speech Codec; Source Controlled Rate operation"", version 4.0.0 (2000-12), 3rd Generation Partnership Project (3GPP). Sjoberg, et al. Standards Track [Page 55] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [7] 3GPP TS 26.193 ""AMR Wideband Speech Codec; Source Controlled Rate operation"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [8] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, ""RTP: A Transport Protocol for Real-Time Applications"", STD 64, RFC 3550, July 2003. [9] 3GPP TS 26.092, ""AMR Speech Codec; Comfort noise aspects"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [10] 3GPP TS 26.192 ""AMR Wideband speech codec; Comfort Noise aspects"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [11] Handley, M., Jacobson, V., and C. Perkins, ""SDP: Session Description Protocol"", RFC 4566, July 2006. [12] Schulzrinne, H. and S. Casner, ""RTP Profile for Audio and Video Conferences with Minimal Control"", STD 65, RFC 3551, July 2003. [13] Rosenberg, J. and H. Schulzrinne, ""An Offer/Answer Model with Session Description Protocol (SDP)"", RFC 3264, June 2002. [14] Freed, N. and J. Klensin, ""Media Type Specifications and Registration Procedures"", BCP 13, RFC 4288, December 2005. [15] Casner, S., ""Media Type Registration of RTP Payload Formats"", RFC 4855, February 2007. 12.2. Informative References [16] GSM 06.60, ""Enhanced Full Rate (EFR) speech transcoding"", version 8.0.1 (2000-11), European Telecommunications Standards Institute (ETSI). [17] ANSI/TIA/EIA-136-Rev.C, part 410 - ""TDMA Cellular/PCS Radio Interface, Enhanced Full Rate Voice Codec (ACELP)"". Formerly IS-641. TIA published standard, June 1 2001. [18] ARIB, RCR STD-27H, ""Personal Digital Cellular Telecommunication System RCR Standard"", Association of Radio Industries and Businesses (ARIB). [19] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., and G. Fairhurst, ""The Lightweight User Datagram Protocol (UDP-Lite)"", RFC 3828, July 2004. Sjoberg, et al. Standards Track [Page 56] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [20] 3GPP TS 25.415 ""UTRAN Iu Interface User Plane Protocols"", version 4.2.0 (2001-09), 3rd Generation Partnership Project (3GPP). [21] Handley, M., Floyd, S., Padhye, J., and J. Widmer, ""TCP Friendly Rate Control (TFRC): Protocol Specification"", RFC 3448, January 2003. [22] Li, A., et al., ""An RTP Payload Format for Generic FEC with Uneven Level Protection"", Work in Progress. [23] Rosenberg, J. and H. Schulzrinne, ""An RTP Payload Format for Generic Forward Error Correction"", RFC 2733, December 1999. [24] 3GPP TS 26.102, ""AMR speech codec interface to Iu and Uu"", version 4.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [25] 3GPP TS 26.202, ""AMR Wideband speech codec; Interface to Iu and Uu"", version 5.0.0 (2001-03), 3rd Generation Partnership Project (3GPP). [26] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, ""The Secure Real-time Transport Protocol (SRTP)"", RFC 3711, March 2004. [27] Perkins, C., Kouvelas, I., Hodson, O., Hardman, V., Handley, M., Bolot, J., Vega-Garcia, A., and S. Fosse-Parisis, ""RTP Payload for Redundant Audio Data"", RFC 2198, September 1997. [28] 3GPP TS 26.103, ""Speech codec list for GSM and UMTS"", version 5.5.0 (2004-09), 3rd Generation Partnership Project (3GPP). [29] Schulzrinne, H., Rao, A., and R. Lanphier, ""Real Time Streaming Protocol (RTSP)"", RFC 2326, April 1998. [30] Handley, M., Perkins, C., and E. Whelan, ""Session Announcement Protocol"", RFC 2974, October 2000. [31] 3GPP TS 26.244, ""3GPP file format (3GP)"", version 6.1.0 (2004- 09), 3rd Generation Partnership Project (3GPP). [32] Castagno, R. and D. Singer, ""MIME Type Registrations for 3rd Generation Partnership Project (3GPP) Multimedia files"", RFC 3839, July 2004. [33] Kent, S. and K. Seo, ""Security Architecture for the Internet Protocol"", RFC 4301, December 2005. Sjoberg, et al. Standards Track [Page 57] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 [34] Dierks, T. and E. Rescorla, ""The Transport Layer Security (TLS) Protocol Version 1.1"", RFC 4346, April 2006. ETSI documents are available from <http://www.etsi.org/>. 3GPP documents are available from <http://www.3gpp.org/>. TIA documents are available from <http://www.tiaonline.org/>. Authors' Addresses Johan Sjoberg Ericsson AB SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: Johan.Sjoberg@ericsson.com Magnus Westerlund Ericsson Research Ericsson AB SE-164 80 Stockholm, SWEDEN Phone: +46 8 7190000 EMail: Magnus.Westerlund@ericsson.com Ari Lakaniemi Nokia Research Center P.O.Box 407 FIN-00045 Nokia Group, FINLAND Phone: +358-71-8008000 EMail: ari.lakaniemi@nokia.com Qiaobing Xie Motorola, Inc. 1501 W. Shure Drive, 2-B8 Arlington Heights, IL 60004, USA Phone: +1-847-632-3028 EMail: Qiaobing.Xie@motorola.com Sjoberg, et al. Standards Track [Page 58] RFC 4867 RTP Payload Format for AMR and AMR-WB April 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an ""AS IS"" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at <%ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Sjoberg, et al. Standards Track [Page 59] Network Working Group J. Rosenberg Request for Comments: 3261 dynamicsoft Obsoletes: 2543 H. Schulzrinne Category: Standards Track Columbia U. G. Camarillo Ericsson A. Johnston WorldCom J. Peterson Neustar R. Sparks dynamicsoft M. Handley ICIR E. Schooler AT&T June 2002 SIP: Session Initiation Protocol Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the ""Internet Official Protocol Standards"" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes Session Initiation Protocol (SIP), an application-layer control (signaling) protocol for creating, modifying, and terminating sessions with one or more participants. These sessions include Internet telephone calls, multimedia distribution, and multimedia conferences. SIP invitations used to create sessions carry session descriptions that allow participants to agree on a set of compatible media types. SIP makes use of elements called proxy servers to help route requests to the user's current location, authenticate and authorize users for services, implement provider call-routing policies, and provide features to users. SIP also provides a registration function that allows users to upload their current locations for use by proxy servers. SIP runs on top of several different transport protocols. Rosenberg, et. al. Standards Track [Page 1] RFC 3261 SIP: Session Initiation Protocol June 2002 Table of Contents 1 Introduction ........................................ 8 2 Overview of SIP Functionality ....................... 9 3 Terminology ......................................... 10 4 Overview of Operation ............................... 10 5 Structure of the Protocol ........................... 18 6 Definitions ......................................... 20 7 SIP Messages ........................................ 26 7.1 Requests ............................................ 27 7.2 Responses ........................................... 28 7.3 Header Fields ....................................... 29 7.3.1 Header Field Format ................................. 30 7.3.2 Header Field Classification ......................... 32 7.3.3 Compact Form ........................................ 32 7.4 Bodies .............................................. 33 7.4.1 Message Body Type ................................... 33 7.4.2 Message Body Length ................................. 33 7.5 Framing SIP Messages ................................ 34 8 General User Agent Behavior ......................... 34 8.1 UAC Behavior ........................................ 35 8.1.1 Generating the Request .............................. 35 8.1.1.1 Request-URI ......................................... 35 8.1.1.2 To .................................................. 36 8.1.1.3 From ................................................ 37 8.1.1.4 Call-ID ............................................. 37 8.1.1.5 CSeq ................................................ 38 8.1.1.6 Max-Forwards ........................................ 38 8.1.1.7 Via ................................................. 39 8.1.1.8 Contact ............................................. 40 8.1.1.9 Supported and Require ............................... 40 8.1.1.10 Additional Message Components ....................... 41 8.1.2 Sending the Request ................................. 41 8.1.3 Processing Responses ................................ 42 8.1.3.1 Transaction Layer Errors ............................ 42 8.1.3.2 Unrecognized Responses .............................. 42 8.1.3.3 Vias ................................................ 43 8.1.3.4 Processing 3xx Responses ............................ 43 8.1.3.5 Processing 4xx Responses ............................ 45 8.2 UAS Behavior ........................................ 46 8.2.1 Method Inspection ................................... 46 8.2.2 Header Inspection ................................... 46 8.2.2.1 To and Request-URI .................................. 46 8.2.2.2 Merged Requests ..................................... 47 8.2.2.3 Require ............................................. 47 8.2.3 Content Processing .................................. 48 8.2.4 Applying Extensions ................................. 49 8.2.5 Processing the Request .............................. 49 Rosenberg, et. al. Standards Track [Page 2] RFC 3261 SIP: Session Initiation Protocol June 2002 8.2.6 Generating the Response ............................. 49 8.2.6.1 Sending a Provisional Response ...................... 49 8.2.6.2 Headers and Tags .................................... 50 8.2.7 Stateless UAS Behavior .............................. 50 8.3 Redirect Servers .................................... 51 9 Canceling a Request ................................. 53 9.1 Client Behavior ..................................... 53 9.2 Server Behavior ..................................... 55 10 Registrations ....................................... 56 10.1 Overview ............................................ 56 10.2 Constructing the REGISTER Request ................... 57 10.2.1 Adding Bindings ..................................... 59 10.2.1.1 Setting the Expiration Interval of Contact Addresses 60 10.2.1.2 Preferences among Contact Addresses ................. 61 10.2.2 Removing Bindings ................................... 61 10.2.3 Fetching Bindings ................................... 61 10.2.4 Refreshing Bindings ................................. 61 10.2.5 Setting the Internal Clock .......................... 62 10.2.6 Discovering a Registrar ............................. 62 10.2.7 Transmitting a Request .............................. 62 10.2.8 Error Responses ..................................... 63 10.3 Processing REGISTER Requests ........................ 63 11 Querying for Capabilities ........................... 66 11.1 Construction of OPTIONS Request ..................... 67 11.2 Processing of OPTIONS Request ....................... 68 12 Dialogs ............................................. 69 12.1 Creation of a Dialog ................................ 70 12.1.1 UAS behavior ........................................ 70 12.1.2 UAC Behavior ........................................ 71 12.2 Requests within a Dialog ............................ 72 12.2.1 UAC Behavior ........................................ 73 12.2.1.1 Generating the Request .............................. 73 12.2.1.2 Processing the Responses ............................ 75 12.2.2 UAS Behavior ........................................ 76 12.3 Termination of a Dialog ............................. 77 13 Initiating a Session ................................ 77 13.1 Overview ............................................ 77 13.2 UAC Processing ...................................... 78 13.2.1 Creating the Initial INVITE ......................... 78 13.2.2 Processing INVITE Responses ......................... 81 13.2.2.1 1xx Responses ....................................... 81 13.2.2.2 3xx Responses ....................................... 81 13.2.2.3 4xx, 5xx and 6xx Responses .......................... 81 13.2.2.4 2xx Responses ....................................... 82 13.3 UAS Processing ...................................... 83 13.3.1 Processing of the INVITE ............................ 83 13.3.1.1 Progress ............................................ 84 13.3.1.2 The INVITE is Redirected ............................ 84 Rosenberg, et. al. Standards Track [Page 3] RFC 3261 SIP: Session Initiation Protocol June 2002 13.3.1.3 The INVITE is Rejected .............................. 85 13.3.1.4 The INVITE is Accepted .............................. 85 14 Modifying an Existing Session ....................... 86 14.1 UAC Behavior ........................................ 86 14.2 UAS Behavior ........................................ 88 15 Terminating a Session ............................... 89 15.1 Terminating a Session with a BYE Request ............ 90 15.1.1 UAC Behavior ........................................ 90 15.1.2 UAS Behavior ........................................ 91 16 Proxy Behavior ...................................... 91 16.1 Overview ............................................ 91 16.2 Stateful Proxy ...................................... 92 16.3 Request Validation .................................. 94 16.4 Route Information Preprocessing ..................... 96 16.5 Determining Request Targets ......................... 97 16.6 Request Forwarding .................................. 99 16.7 Response Processing ................................. 107 16.8 Processing Timer C .................................. 114 16.9 Handling Transport Errors ........................... 115 16.10 CANCEL Processing ................................... 115 16.11 Stateless Proxy ..................................... 116 16.12 Summary of Proxy Route Processing ................... 118 16.12.1 Examples ............................................ 118 16.12.1.1 Basic SIP Trapezoid ................................. 118 16.12.1.2 Traversing a Strict-Routing Proxy ................... 120 16.12.1.3 Rewriting Record-Route Header Field Values .......... 121 17 Transactions ........................................ 122 17.1 Client Transaction .................................. 124 17.1.1 INVITE Client Transaction ........................... 125 17.1.1.1 Overview of INVITE Transaction ...................... 125 17.1.1.2 Formal Description .................................. 125 17.1.1.3 Construction of the ACK Request ..................... 129 17.1.2 Non-INVITE Client Transaction ....................... 130 17.1.2.1 Overview of the non-INVITE Transaction .............. 130 17.1.2.2 Formal Description .................................. 131 17.1.3 Matching Responses to Client Transactions ........... 132 17.1.4 Handling Transport Errors ........................... 133 17.2 Server Transaction .................................. 134 17.2.1 INVITE Server Transaction ........................... 134 17.2.2 Non-INVITE Server Transaction ....................... 137 17.2.3 Matching Requests to Server Transactions ............ 138 17.2.4 Handling Transport Errors ........................... 141 18 Transport ........................................... 141 18.1 Clients ............................................. 142 18.1.1 Sending Requests .................................... 142 18.1.2 Receiving Responses ................................. 144 18.2 Servers ............................................. 145 18.2.1 Receiving Requests .................................. 145 Rosenberg, et. al. Standards Track [Page 4] RFC 3261 SIP: Session Initiation Protocol June 2002 18.2.2 Sending Responses ................................... 146 18.3 Framing ............................................. 147 18.4 Error Handling ...................................... 147 19 Common Message Components ........................... 147 19.1 SIP and SIPS Uniform Resource Indicators ............ 148 19.1.1 SIP and SIPS URI Components ......................... 148 19.1.2 Character Escaping Requirements ..................... 152 19.1.3 Example SIP and SIPS URIs ........................... 153 19.1.4 URI Comparison ...................................... 153 19.1.5 Forming Requests from a URI ......................... 156 19.1.6 Relating SIP URIs and tel URLs ...................... 157 19.2 Option Tags ......................................... 158 19.3 Tags ................................................ 159 20 Header Fields ....................................... 159 20.1 Accept .............................................. 161 20.2 Accept-Encoding ..................................... 163 20.3 Accept-Language ..................................... 164 20.4 Alert-Info .......................................... 164 20.5 Allow ............................................... 165 20.6 Authentication-Info ................................. 165 20.7 Authorization ....................................... 165 20.8 Call-ID ............................................. 166 20.9 Call-Info ........................................... 166 20.10 Contact ............................................. 167 20.11 Content-Disposition ................................. 168 20.12 Content-Encoding .................................... 169 20.13 Content-Language .................................... 169 20.14 Content-Length ...................................... 169 20.15 Content-Type ........................................ 170 20.16 CSeq ................................................ 170 20.17 Date ................................................ 170 20.18 Error-Info .......................................... 171 20.19 Expires ............................................. 171 20.20 From ................................................ 172 20.21 In-Reply-To ......................................... 172 20.22 Max-Forwards ........................................ 173 20.23 Min-Expires ......................................... 173 20.24 MIME-Version ........................................ 173 20.25 Organization ........................................ 174 20.26 Priority ............................................ 174 20.27 Proxy-Authenticate .................................. 174 20.28 Proxy-Authorization ................................. 175 20.29 Proxy-Require ....................................... 175 20.30 Record-Route ........................................ 175 20.31 Reply-To ............................................ 176 20.32 Require ............................................. 176 20.33 Retry-After ......................................... 176 20.34 Route ............................................... 177 Rosenberg, et. al. Standards Track [Page 5] RFC 3261 SIP: Session Initiation Protocol June 2002 20.35 Server .............................................. 177 20.36 Subject ............................................. 177 20.37 Supported ........................................... 178 20.38 Timestamp ........................................... 178 20.39 To .................................................. 178 20.40 Unsupported ......................................... 179 20.41 User-Agent .......................................... 179 20.42 Via ................................................. 179 20.43 Warning ............................................. 180 20.44 WWW-Authenticate .................................... 182 21 Response Codes ...................................... 182 21.1 Provisional 1xx ..................................... 182 21.1.1 100 Trying .......................................... 183 21.1.2 180 Ringing ......................................... 183 21.1.3 181 Call Is Being Forwarded ......................... 183 21.1.4 182 Queued .......................................... 183 21.1.5 183 Session Progress ................................ 183 21.2 Successful 2xx ...................................... 183 21.2.1 200 OK .............................................. 183 21.3 Redirection 3xx ..................................... 184 21.3.1 300 Multiple Choices ................................ 184 21.3.2 301 Moved Permanently ............................... 184 21.3.3 302 Moved Temporarily ............................... 184 21.3.4 305 Use Proxy ....................................... 185 21.3.5 380 Alternative Service ............................. 185 21.4 Request Failure 4xx ................................. 185 21.4.1 400 Bad Request ..................................... 185 21.4.2 401 Unauthorized .................................... 185 21.4.3 402 Payment Required ................................ 186 21.4.4 403 Forbidden ....................................... 186 21.4.5 404 Not Found ....................................... 186 21.4.6 405 Method Not Allowed .............................. 186 21.4.7 406 Not Acceptable .................................. 186 21.4.8 407 Proxy Authentication Required ................... 186 21.4.9 408 Request Timeout ................................. 186 21.4.10 410 Gone ............................................ 187 21.4.11 413 Request Entity Too Large ........................ 187 21.4.12 414 Request-URI Too Long ............................ 187 21.4.13 415 Unsupported Media Type .......................... 187 21.4.14 416 Unsupported URI Scheme .......................... 187 21.4.15 420 Bad Extension ................................... 187 21.4.16 421 Extension Required .............................. 188 21.4.17 423 Interval Too Brief .............................. 188 21.4.18 480 Temporarily Unavailable ......................... 188 21.4.19 481 Call/Transaction Does Not Exist ................. 188 21.4.20 482 Loop Detected ................................... 188 21.4.21 483 Too Many Hops ................................... 189 21.4.22 484 Address Incomplete .............................. 189 Rosenberg, et. al. Standards Track [Page 6] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.23 485 Ambiguous ....................................... 189 21.4.24 486 Busy Here ....................................... 189 21.4.25 487 Request Terminated .............................. 190 21.4.26 488 Not Acceptable Here ............................. 190 21.4.27 491 Request Pending ................................. 190 21.4.28 493 Undecipherable .................................. 190 21.5 Server Failure 5xx .................................. 190 21.5.1 500 Server Internal Error ........................... 190 21.5.2 501 Not Implemented ................................. 191 21.5.3 502 Bad Gateway ..................................... 191 21.5.4 503 Service Unavailable ............................. 191 21.5.5 504 Server Time-out ................................. 191 21.5.6 505 Version Not Supported ........................... 192 21.5.7 513 Message Too Large ............................... 192 21.6 Global Failures 6xx ................................. 192 21.6.1 600 Busy Everywhere ................................. 192 21.6.2 603 Decline ......................................... 192 21.6.3 604 Does Not Exist Anywhere ......................... 192 21.6.4 606 Not Acceptable .................................. 192 22 Usage of HTTP Authentication ........................ 193 22.1 Framework ........................................... 193 22.2 User-to-User Authentication ......................... 195 22.3 Proxy-to-User Authentication ........................ 197 22.4 The Digest Authentication Scheme .................... 199 23 S/MIME .............................................. 201 23.1 S/MIME Certificates ................................. 201 23.2 S/MIME Key Exchange ................................. 202 23.3 Securing MIME bodies ................................ 205 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP ....................................... 207 23.4.1 Integrity and Confidentiality Properties of SIP Headers ............................................. 207 23.4.1.1 Integrity ........................................... 207 23.4.1.2 Confidentiality ..................................... 208 23.4.2 Tunneling Integrity and Authentication .............. 209 23.4.3 Tunneling Encryption ................................ 211 24 Examples ............................................ 213 24.1 Registration ........................................ 213 24.2 Session Setup ....................................... 214 25 Augmented BNF for the SIP Protocol .................. 219 25.1 Basic Rules ......................................... 219 26 Security Considerations: Threat Model and Security Usage Recommendations ............................... 232 26.1 Attacks and Threat Models ........................... 233 26.1.1 Registration Hijacking .............................. 233 26.1.2 Impersonating a Server .............................. 234 26.1.3 Tampering with Message Bodies ....................... 235 26.1.4 Tearing Down Sessions ............................... 235 Rosenberg, et. al."
"Standards Track [Page 7] RFC 3261 SIP: Session Initiation Protocol June 2002 26.1.5 Denial of Service and Amplification ................. 236 26.2 Security Mechanisms ................................. 237 26.2.1 Transport and Network Layer Security ................ 238 26.2.2 SIPS URI Scheme ..................................... 239 26.2.3 HTTP Authentication ................................. 240 26.2.4 S/MIME .............................................. 240 26.3 Implementing Security Mechanisms .................... 241 26.3.1 Requirements for Implementers of SIP ................ 241 26.3.2 Security Solutions .................................. 242 26.3.2.1 Registration ........................................ 242 26.3.2.2 Interdomain Requests ................................ 243 26.3.2.3 Peer-to-Peer Requests ............................... 245 26.3.2.4 DoS Protection ...................................... 246 26.4 Limitations ......................................... 247 26.4.1 HTTP Digest ......................................... 247 26.4.2 S/MIME .............................................. 248 26.4.3 TLS ................................................. 249 26.4.4 SIPS URIs ........................................... 249 26.5 Privacy ............................................. 251 27 IANA Considerations ................................. 252 27.1 Option Tags ......................................... 252 27.2 Warn-Codes .......................................... 252 27.3 Header Field Names .................................. 253 27.4 Method and Response Codes ........................... 253 27.5 The ""message/sip"" MIME type. ....................... 254 27.6 New Content-Disposition Parameter Registrations ..... 255 28 Changes From RFC 2543 ............................... 255 28.1 Major Functional Changes ............................ 255 28.2 Minor Functional Changes ............................ 260 29 Normative References ................................ 261 30 Informative References .............................. 262 A Table of Timer Values ............................... 265 Acknowledgments ................................................ 266 Authors' Addresses ............................................. 267 Full Copyright Statement ....................................... 269 1 Introduction There are many applications of the Internet that require the creation and management of a session, where a session is considered an exchange of data between an association of participants. The implementation of these applications is complicated by the practices of participants: users may move between endpoints, they may be addressable by multiple names, and they may communicate in several different media - sometimes simultaneously. Numerous protocols have been authored that carry various forms of real-time multimedia session data such as voice, video, or text messages. The Session Initiation Protocol (SIP) works in concert with these protocols by Rosenberg, et. al. Standards Track [Page 8] RFC 3261 SIP: Session Initiation Protocol June 2002 enabling Internet endpoints (called user agents) to discover one another and to agree on a characterization of a session they would like to share. For locating prospective session participants, and for other functions, SIP enables the creation of an infrastructure of network hosts (called proxy servers) to which user agents can send registrations, invitations to sessions, and other requests. SIP is an agile, general-purpose tool for creating, modifying, and terminating sessions that works independently of underlying transport protocols and without dependency on the type of session that is being established. 2 Overview of SIP Functionality SIP is an application-layer control protocol that can establish, modify, and terminate multimedia sessions (conferences) such as Internet telephony calls. SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility [27] - users can maintain a single externally visible identifier regardless of their network location. SIP supports five facets of establishing and terminating multimedia communications: User location: determination of the end system to be used for communication; User availability: determination of the willingness of the called party to engage in communications; User capabilities: determination of the media and media parameters to be used; Session setup: ""ringing"", establishment of session parameters at both called and calling party; Session management: including transfer and termination of sessions, modifying session parameters, and invoking services. SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) (RFC 1889 [28]) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) (RFC 2326 [29]) for controlling delivery of streaming media, the Media Rosenberg, et. al. Standards Track [Page 9] RFC 3261 SIP: Session Initiation Protocol June 2002 Gateway Control Protocol (MEGACO) (RFC 3015 [30]) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) (RFC 2327 [1]) for describing multimedia sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete services to the users. However, the basic functionality and operation of SIP does not depend on any of these protocols. SIP does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a ""caller ID"" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services. SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of network resource reservation capabilities. The nature of the services provided make security particularly important. To that end, SIP provides a suite of security services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity protection, and encryption and privacy services. SIP works with both IPv4 and IPv6. 3 Terminology In this document, the key words ""MUST"", ""MUST NOT"", ""REQUIRED"", ""SHALL"", ""SHALL NOT"", ""SHOULD"", ""SHOULD NOT"", ""RECOMMENDED"", ""NOT RECOMMENDED"", ""MAY"", and ""OPTIONAL"" are to be interpreted as described in BCP 14, RFC 2119 [2] and indicate requirement levels for compliant SIP implementations. 4 Overview of Operation This section introduces the basic operations of SIP using simple examples. This section is tutorial in nature and does not contain any normative statements. Rosenberg, et. al. Standards Track [Page 10] RFC 3261 SIP: Session Initiation Protocol June 2002 The first example shows the basic functions of SIP: location of an end point, signal of a desire to communicate, negotiation of session parameters to establish the session, and teardown of the session once established. Figure 1 shows a typical example of a SIP message exchange between two users, Alice and Bob. (Each message is labeled with the letter ""F"" and a number for reference by the text.) In this example, Alice uses a SIP application on her PC (referred to as a softphone) to call Bob on his SIP phone over the Internet. Also shown are two SIP proxy servers that act on behalf of Alice and Bob to facilitate the session establishment. This typical arrangement is often referred to as the ""SIP trapezoid"" as shown by the geometric shape of the dotted lines in Figure 1. Alice ""calls"" Bob using his SIP identity, a type of Uniform Resource Identifier (URI) called a SIP URI. SIP URIs are defined in Section 19.1. It has a similar form to an email address, typically containing a username and a host name. In this case, it is sip:bob@biloxi.com, where biloxi.com is the domain of Bob's SIP service provider. Alice has a SIP URI of sip:alice@atlanta.com. Alice might have typed in Bob's URI or perhaps clicked on a hyperlink or an entry in an address book. SIP also provides a secure URI, called a SIPS URI. An example would be sips:bob@biloxi.com. A call made to a SIPS URI guarantees that secure, encrypted transport (namely TLS) is used to carry all SIP messages from the caller to the domain of the callee. From there, the request is sent securely to the callee, but with security mechanisms that depend on the policy of the domain of the callee. SIP is based on an HTTP-like request/response transaction model. Each transaction consists of a request that invokes a particular method, or function, on the server and at least one response. In this example, the transaction begins with Alice's softphone sending an INVITE request addressed to Bob's SIP URI. INVITE is an example of a SIP method that specifies the action that the requestor (Alice) wants the server (Bob) to take. The INVITE request contains a number of header fields. Header fields are named attributes that provide additional information about a message. The ones present in an INVITE include a unique identifier for the call, the destination address, Alice's address, and information about the type of session that Alice wishes to establish with Bob. The INVITE (message F1 in Figure 1) might look like this: Rosenberg, et. al. Standards Track [Page 11] RFC 3261 SIP: Session Initiation Protocol June 2002 atlanta.com . . . biloxi.com . proxy proxy . . . Alice's . . . . . . . . . . . . . . . . . . . . Bob's softphone SIP Phone | | | | | INVITE F1 | | | |--------------->| INVITE F2 | | | 100 Trying F3 |--------------->| INVITE F4 | |<---------------| 100 Trying F5 |--------------->| | |<-------------- | 180 Ringing F6 | | | 180 Ringing F7 |<---------------| | 180 Ringing F8 |<---------------| 200 OK F9 | |<---------------| 200 OK F10 |<---------------| | 200 OK F11 |<---------------| | |<---------------| | | | ACK F12 | |------------------------------------------------->| | Media Session | |<================================================>| | BYE F13 | |<-------------------------------------------------| | 200 OK F14 | |------------------------------------------------->| | | Figure 1: SIP session setup example with SIP trapezoid INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bK776asdhds Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) The first line of the text-encoded message contains the method name (INVITE). The lines that follow are a list of header fields. This example contains a minimum required set. The header fields are briefly described below: Rosenberg, et. al. Standards Track [Page 12] RFC 3261 SIP: Session Initiation Protocol June 2002 Via contains the address (pc33.atlanta.com) at which Alice is expecting to receive responses to this request. It also contains a branch parameter that identifies this transaction. To contains a display name (Bob) and a SIP or SIPS URI (sip:bob@biloxi.com) towards which the request was originally directed. Display names are described in RFC 2822 [3]. From also contains a display name (Alice) and a SIP or SIPS URI (sip:alice@atlanta.com) that indicate the originator of the request. This header field also has a tag parameter containing a random string (1928301774) that was added to the URI by the softphone. It is used for identification purposes. Call-ID contains a globally unique identifier for this call, generated by the combination of a random string and the softphone's host name or IP address. The combination of the To tag, From tag, and Call-ID completely defines a peer-to-peer SIP relationship between Alice and Bob and is referred to as a dialog. CSeq or Command Sequence contains an integer and a method name. The CSeq number is incremented for each new request within a dialog and is a traditional sequence number. Contact contains a SIP or SIPS URI that represents a direct route to contact Alice, usually composed of a username at a fully qualified domain name (FQDN). While an FQDN is preferred, many end systems do not have registered domain names, so IP addresses are permitted. While the Via header field tells other elements where to send the response, the Contact header field tells other elements where to send future requests. Max-Forwards serves to limit the number of hops a request can make on the way to its destination. It consists of an integer that is decremented by one at each hop. Content-Type contains a description of the message body (not shown). Content-Length contains an octet (byte) count of the message body. The complete set of SIP header fields is defined in Section 20. The details of the session, such as the type of media, codec, or sampling rate, are not described using SIP. Rather, the body of a SIP message contains a description of the session, encoded in some other protocol format. One such format is the Session Description Protocol (SDP) (RFC 2327 [1]). This SDP message (not shown in the Rosenberg, et. al. Standards Track [Page 13] RFC 3261 SIP: Session Initiation Protocol June 2002 example) is carried by the SIP message in a way that is analogous to a document attachment being carried by an email message, or a web page being carried in an HTTP message. Since the softphone does not know the location of Bob or the SIP server in the biloxi.com domain, the softphone sends the INVITE to the SIP server that serves Alice's domain, atlanta.com. The address of the atlanta.com SIP server could have been configured in Alice's softphone, or it could have been discovered by DHCP, for example. The atlanta.com SIP server is a type of SIP server known as a proxy server. A proxy server receives SIP requests and forwards them on behalf of the requestor. In this example, the proxy server receives the INVITE request and sends a 100 (Trying) response back to Alice's softphone. The 100 (Trying) response indicates that the INVITE has been received and that the proxy is working on her behalf to route the INVITE to the destination. Responses in SIP use a three-digit code followed by a descriptive phrase. This response contains the same To, From, Call-ID, CSeq and branch parameter in the Via as the INVITE, which allows Alice's softphone to correlate this response to the sent INVITE. The atlanta.com proxy server locates the proxy server at biloxi.com, possibly by performing a particular type of DNS (Domain Name Service) lookup to find the SIP server that serves the biloxi.com domain. This is described in [4]. As a result, it obtains the IP address of the biloxi.com proxy server and forwards, or proxies, the INVITE request there. Before forwarding the request, the atlanta.com proxy server adds an additional Via header field value that contains its own address (the INVITE already contains Alice's address in the first Via). The biloxi.com proxy server receives the INVITE and responds with a 100 (Trying) response back to the atlanta.com proxy server to indicate that it has received the INVITE and is processing the request. The proxy server consults a database, generically called a location service, that contains the current IP address of Bob. (We shall see in the next section how this database can be populated.) The biloxi.com proxy server adds another Via header field value with its own address to the INVITE and proxies it to Bob's SIP phone. Bob's SIP phone receives the INVITE and alerts Bob to the incoming call from Alice so that Bob can decide whether to answer the call, that is, Bob's phone rings. Bob's SIP phone indicates this in a 180 (Ringing) response, which is routed back through the two proxies in the reverse direction. Each proxy uses the Via header field to determine where to send the response and removes its own address from the top. As a result, although DNS and location service lookups were required to route the initial INVITE, the 180 (Ringing) response can be returned to the caller without lookups or without state being Rosenberg, et. al. Standards Track [Page 14] RFC 3261 SIP: Session Initiation Protocol June 2002 maintained in the proxies. This also has the desirable property that each proxy that sees the INVITE will also see all responses to the INVITE. When Alice's softphone receives the 180 (Ringing) response, it passes this information to Alice, perhaps using an audio ringback tone or by displaying a message on Alice's screen. In this example, Bob decides to answer the call. When he picks up the handset, his SIP phone sends a 200 (OK) response to indicate that the call has been answered. The 200 (OK) contains a message body with the SDP media description of the type of session that Bob is willing to establish with Alice. As a result, there is a two-phase exchange of SDP messages: Alice sent one to Bob, and Bob sent one back to Alice. This two-phase exchange provides basic negotiation capabilities and is based on a simple offer/answer model of SDP exchange. If Bob did not wish to answer the call or was busy on another call, an error response would have been sent instead of the 200 (OK), which would have resulted in no media session being established. The complete list of SIP response codes is in Section 21. The 200 (OK) (message F9 in Figure 1) might look like this as Bob sends it out: SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com ;branch=z9hG4bKnashds8;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com ;branch=z9hG4bK77ef4c2312983.1;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com ;branch=z9hG4bK776asdhds ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710@pc33.atlanta.com CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) The first line of the response contains the response code (200) and the reason phrase (OK). The remaining lines contain header fields. The Via, To, From, Call-ID, and CSeq header fields are copied from the INVITE request. (There are three Via header field values - one added by Alice's SIP phone, one added by the atlanta.com proxy, and one added by the biloxi.com proxy.) Bob's SIP phone has added a tag parameter to the To header field. This tag will be incorporated by both endpoints into the dialog and will be included in all future Rosenberg, et. al. Standards Track [Page 15] RFC 3261 SIP: Session Initiation Protocol June 2002 requests and responses in this call. The Contact header field contains a URI at which Bob can be directly reached at his SIP phone. The Content-Type and Content-Length refer to the message body (not shown) that contains Bob's SDP media information. In addition to DNS and location service lookups shown in this example, proxy servers can make flexible ""routing decisions"" to decide where to send a request. For example, if Bob's SIP phone returned a 486 (Busy Here) response, the biloxi.com proxy server could proxy the INVITE to Bob's voicemail server. A proxy server can also send an INVITE to a number of locations at the same time. This type of parallel search is known as forking. In this case, the 200 (OK) is routed back through the two proxies and is received by Alice's softphone, which then stops the ringback tone and indicates that the call has been answered. Finally, Alice's softphone sends an acknowledgement message, ACK, to Bob's SIP phone to confirm the reception of the final response (200 (OK)). In this example, the ACK is sent directly from Alice's softphone to Bob's SIP phone, bypassing the two proxies. This occurs because the endpoints have learned each other's address from the Contact header fields through the INVITE/200 (OK) exchange, which was not known when the initial INVITE was sent. The lookups performed by the two proxies are no longer needed, so the proxies drop out of the call flow. This completes the INVITE/200/ACK three-way handshake used to establish SIP sessions. Full details on session setup are in Section 13. Alice and Bob's media session has now begun, and they send media packets using the format to which they agreed in the exchange of SDP. In general, the end-to-end media packets take a different path from the SIP signaling messages. During the session, either Alice or Bob may decide to change the characteristics of the media session. This is accomplished by sending a re-INVITE containing a new media description. This re- INVITE references the existing dialog so that the other party knows that it is to modify an existing session instead of establishing a new session. The other party sends a 200 (OK) to accept the change. The requestor responds to the 200 (OK) with an ACK. If the other party does not accept the change, he sends an error response such as 488 (Not Acceptable Here), which also receives an ACK. However, the failure of the re-INVITE does not cause the existing call to fail - the session continues using the previously negotiated characteristics. Full details on session modification are in Section 14. Rosenberg, et. al. Standards Track [Page 16] RFC 3261 SIP: Session Initiation Protocol June 2002 At the end of the call, Bob disconnects (hangs up) first and generates a BYE message. This BYE is routed directly to Alice's softphone, again bypassing the proxies. Alice confirms receipt of the BYE with a 200 (OK) response, which terminates the session and the BYE transaction. No ACK is sent - an ACK is only sent in response to a response to an INVITE request. The reasons for this special handling for INVITE will be discussed later, but relate to the reliability mechanisms in SIP, the length of time it can take for a ringing phone to be answered, and forking. For this reason, request handling in SIP is often classified as either INVITE or non- INVITE, referring to all other methods besides INVITE. Full details on session termination are in Section 15. Section 24.2 describes the messages shown in Figure 1 in full. In some cases, it may be useful for proxies in the SIP signaling path to see all the messaging between the endpoints for the duration of the session. For example, if the biloxi.com proxy server wished to remain in the SIP messaging path beyond the initial INVITE, it would add to the INVITE a required routing header field known as Record- Route that contained a URI resolving to the hostname or IP address of the proxy. This information would be received by both Bob's SIP phone and (due to the Record-Route header field being passed back in the 200 (OK)) Alice's softphone and stored for the duration of the dialog. The biloxi.com proxy server would then receive and proxy the ACK, BYE, and 200 (OK) to the BYE. Each proxy can independently decide to receive subsequent messages, and those messages will pass through all proxies that elect to receive it. This capability is frequently used for proxies that are providing mid-call features. Registration is another common operation in SIP. Registration is one way that the biloxi.com server can learn the current location of Bob. Upon initialization, and at periodic intervals, Bob's SIP phone sends REGISTER messages to a server in the biloxi.com domain known as a SIP registrar. The REGISTER messages associate Bob's SIP or SIPS URI (sip:bob@biloxi.com) with the machine into which he is currently logged (conveyed as a SIP or SIPS URI in the Contact header field). The registrar writes this association, also called a binding, to a database, called the location service, where it can be used by the proxy in the biloxi.com domain. Often, a registrar server for a domain is co-located with the proxy for that domain. It is an important concept that the distinction between types of SIP servers is logical, not physical. Bob is not limited to registering from a single device. For example, both his SIP phone at home and the one in the office could send registrations. This information is stored together in the location Rosenberg, et. al. Standards Track [Page 17] RFC 3261 SIP: Session Initiation Protocol June 2002 service and allows a proxy to perform various types of searches to locate Bob. Similarly, more than one user can be registered on a single device at the same time. The location service is just an abstract concept. It generally contains information that allows a proxy to input a URI and receive a set of zero or more URIs that tell the proxy where to send the request. Registrations are one way to create this information, but not the only way. Arbitrary mapping functions can be configured at the discretion of the administrator. Finally, it is important to note that in SIP, registration is used for routing incoming SIP requests and has no role in authorizing outgoing requests. Authorization and authentication are handled in SIP either on a request-by-request basis with a challenge/response mechanism, or by using a lower layer scheme as discussed in Section 26. The complete set of SIP message details for this registration example is in Section 24.1. Additional operations in SIP, such as querying for the capabilities of a SIP server or client using OPTIONS, or canceling a pending request using CANCEL, will be introduced in later sections. 5 Structure of the Protocol SIP is structured as a layered protocol, which means that its behavior is described in terms of a set of fairly independent processing stages with only a loose coupling between each stage. The protocol behavior is described as layers for the purpose of presentation, allowing the description of functions common across elements in a single section. It does not dictate an implementation in any way. When we say that an element ""contains"" a layer, we mean it is compliant to the set of rules defined by that layer. Not every element specified by the protocol contains every layer. Furthermore, the elements specified by SIP are logical elements, not physical ones. A physical realization can choose to act as different logical elements, perhaps even on a transaction-by-transaction basis. The lowest layer of SIP is its syntax and encoding. Its encoding is specified using an augmented Backus-Naur Form grammar (BNF). The complete BNF is specified in Section 25; an overview of a SIP message's structure can be found in Section 7. Rosenberg, et. al. Standards Track [Page 18] RFC 3261 SIP: Session Initiation Protocol June 2002 The second layer is the transport layer. It defines how a client sends requests and receives responses and how a server receives requests and sends responses over the network. All SIP elements contain a transport layer. The transport layer is described in Section 18. The third layer is the transaction layer. Transactions are a fundamental component of SIP. A transaction is a request sent by a client transaction (using the transport layer) to a server transaction, along with all responses to that request sent from the server transaction back to the client. The transaction layer handles application-layer retransmissions, matching of responses to requests, and application-layer timeouts. Any task that a user agent client (UAC) accomplishes takes place using a series of transactions. Discussion of transactions can be found in Section 17. User agents contain a transaction layer, as do stateful proxies. Stateless proxies do not contain a transaction layer. The transaction layer has a client component (referred to as a client transaction) and a server component (referred to as a server transaction), each of which are represented by a finite state machine that is constructed to process a particular request. The layer above the transaction layer is called the transaction user (TU). Each of the SIP entities, except the stateless proxy, is a transaction user. When a TU wishes to send a request, it creates a client transaction instance and passes it the request along with the destination IP address, port, and transport to which to send the request. A TU that creates a client transaction can also cancel it. When a client cancels a transaction, it requests that the server stop further processing, revert to the state that existed before the transaction was initiated, and generate a specific error response to that transaction. This is done with a CANCEL request, which constitutes its own transaction, but references the transaction to be cancelled (Section 9). The SIP elements, that is, user agent clients and servers, stateless and stateful proxies and registrars, contain a core that distinguishes them from each other. Cores, except for the stateless proxy, are transaction users. While the behavior of the UAC and UAS cores depends on the method, there are some common rules for all methods (Section 8). For a UAC, these rules govern the construction of a request; for a UAS, they govern the processing of a request and generating a response. Since registrations play an important role in SIP, a UAS that handles a REGISTER is given the special name registrar. Section 10 describes UAC and UAS core behavior for the REGISTER method. Section 11 describes UAC and UAS core behavior for the OPTIONS method, used for determining the capabilities of a UA. Rosenberg, et. al. Standards Track [Page 19] RFC 3261 SIP: Session Initiation Protocol June 2002 Certain other requests are sent within a dialog. A dialog is a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages and proper routing of requests between the user agents. The INVITE method is the only way defined in this specification to establish a dialog. When a UAC sends a request that is within the context of a dialog, it follows the common UAC rules as discussed in Section 8 but also the rules for mid-dialog requests. Section 12 discusses dialogs and presents the procedures for their construction and maintenance, in addition to construction of requests within a dialog. The most important method in SIP is the INVITE method, which is used to establish a session between participants. A session is a collection of participants, and streams of media between them, for the purposes of communication. Section 13 discusses how sessions are initiated, resulting in one or more SIP dialogs. Section 14 discusses how characteristics of that session are modified through the use of an INVITE request within a dialog. Finally, section 15 discusses how a session is terminated. The procedures of Sections 8, 10, 11, 12, 13, 14, and 15 deal entirely with the UA core (Section 9 describes cancellation, which applies to both UA core and proxy core). Section 16 discusses the proxy element, which facilitates routing of messages between user agents. 6 Definitions The following terms have special significance for SIP. Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the ""public address"" of the user. Back-to-Back User Agent: A back-to-back user agent (B2BUA) is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior. Rosenberg, et. al. Standards Track [Page 20] RFC 3261 SIP: Session Initiation Protocol June 2002 Call: A call is an informal term that refers to some communication between peers, generally set up for the purposes of a multimedia conversation. Call Leg: Another name for a dialog [31]; no longer used in this specification. Call Stateful: A proxy is call stateful if it retains state for a dialog from the initiating INVITE to the terminating BYE request. A call stateful proxy is always transaction stateful, but the converse is not necessarily true. Client: A client is any network element that sends SIP requests and receives SIP responses. Clients may or may not interact directly with a human user. User agent clients and proxies are clients. Conference: A multimedia session (see below) that contains multiple participants. Core: Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users. Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543. Downstream: A direction of message forwarding within a transaction that refers to the direction that requests flow from the user agent client to user agent server. Final Response: A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final. Header: A header is a component of a SIP message that conveys information about the message. It is structured as a sequence of header fields. Header Field: A header field is a component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a Rosenberg, et. al. Standards Track [Page 21] RFC 3261 SIP: Session Initiation Protocol June 2002 given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row. Header Field Value: A header field value is a single value; a header field consists of zero or more header field values. Home Domain: The domain providing service to a SIP user. Typically, this is the domain present in the URI in the address-of-record of a registration. Informational Response: Same as a provisional response. Initiator, Calling Party, Caller: The party initiating a session (and dialog) with an INVITE request. A caller retains this role from the time it sends the initial INVITE that established a dialog until the termination of that dialog. Invitation: An INVITE request. Invitee, Invited User, Called Party, Callee: The party that receives an INVITE request for the purpose of establishing a new session. A callee retains this role from the time it receives the INVITE until the termination of the dialog established by that INVITE. Location Service: A location service is used by a SIP redirect or proxy server to obtain information about a callee's possible location(s). It contains a list of bindings of address-of- record keys to zero or more contact addresses. The bindings can be created and removed in many ways; this specification defines a REGISTER method that updates the bindings. Loop: A request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors, and the procedures for detecting them and handling them are described by the protocol. Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in this specification for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from Rosenberg, et. al. Standards Track [Page 22] RFC 3261 SIP: Session Initiation Protocol June 2002 the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router. Message: Data sent between SIP elements as part of the protocol. SIP messages are either requests or responses. Method: The method is the primary function that a request is meant to invoke on a server. The method is carried in the request message itself. Example methods are INVITE and BYE. Outbound Proxy: A proxy that receives requests from a client, even though it may not be the server resolved by the Request-URI. Typically, a UA is manually configured with an outbound proxy, or can learn about one through auto-configuration protocols. Parallel Search: In a parallel search, a proxy issues several requests to possible user locations upon receiving an incoming request. Rather than issuing one request and then waiting for the final response before issuing the next request as in a sequential search, a parallel search issues requests without waiting for the result of previous requests. Provisional Response: A response used by the server to indicate progress, but that does not terminate a SIP transaction. 1xx responses are provisional, other responses are considered final. Proxy, Proxy Server: An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity ""closer"" to the targeted user. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it. Recursion: A client recurses on a 3xx response when it generates a new request to one or more of the URIs in the Contact header field in the response."
"Redirect Server: A redirect server is a user agent server that generates 3xx responses to requests it receives, directing the client to contact an alternate set of URIs. Rosenberg, et. al. Standards Track [Page 23] RFC 3261 SIP: Session Initiation Protocol June 2002 Registrar: A registrar is a server that accepts REGISTER requests and places the information it receives in those requests into the location service for the domain it handles. Regular Transaction: A regular transaction is any transaction with a method other than INVITE, ACK, or CANCEL. Request: A SIP message sent from a client to a server, for the purpose of invoking a particular operation. Response: A SIP message sent from a server to a client, for indicating the status of a request sent from the client to the server. Ringback: Ringback is the signaling tone produced by the calling party's application indicating that a called party is being alerted (ringing). Route Set: A route set is a collection of ordered SIP or SIPS URI which represent a list of proxies that must be traversed when sending a particular request. A route set can be learned, through headers like Record-Route, or it can be configured. Server: A server is a network element that receives requests in order to service them and sends back responses to those requests. Examples of servers are proxies, user agent servers, redirect servers, and registrars. Sequential Search: In a sequential search, a proxy server attempts each contact address in sequence, proceeding to the next one only after the previous has generated a final response. A 2xx or 6xx class final response always terminates a sequential search. Session: From the SDP specification: ""A multimedia session is a set of multimedia senders and receivers and the data streams flowing from senders to receivers. A multimedia conference is an example of a multimedia session."" (RFC 2327 [1]) (A session as defined for SDP can comprise one or more RTP sessions.) As defined, a callee can be invited several times, by different calls, to the same session. If SDP is used, a session is defined by the concatenation of the SDP user name, session id, network type, address type, and address elements in the origin field. SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response Rosenberg, et. al. Standards Track [Page 24] RFC 3261 SIP: Session Initiation Protocol June 2002 sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction. Spiral: A spiral is a SIP request that is routed to a proxy, forwarded onwards, and arrives once again at that proxy, but this time differs in a way that will result in a different processing decision than the original request. Typically, this means that the request's Request-URI differs from its previous arrival. A spiral is not an error condition, unlike a loop. A typical cause for this is call forwarding. A user calls joe@example.com. The example.com proxy forwards it to Joe's PC, which in turn, forwards it to bob@example.com. This request is proxied back to the example.com proxy. However, this is not a loop. Since the request is targeted at a different user, it is considered a spiral, and is a valid condition. Stateful Proxy: A logical entity that maintains the client and server transaction state machines defined by this specification during the processing of a request, also known as a transaction stateful proxy. The behavior of a stateful proxy is further defined in Section 16. A (transaction) stateful proxy is not the same as a call stateful proxy. Stateless Proxy: A logical entity that does not maintain the client or server transaction state machines defined in this specification when it processes requests. A stateless proxy forwards every request it receives downstream and every response it receives upstream. Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in this specification, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers. Target Refresh Request: A target refresh request sent within a dialog is defined as a request that can modify the remote target of the dialog. Transaction User (TU): The layer of protocol processing that resides above the transaction layer. Transaction users include the UAC core, UAS core, and proxy core. Rosenberg, et. al. Standards Track [Page 25] RFC 3261 SIP: Session Initiation Protocol June 2002 Upstream: A direction of message forwarding within a transaction that refers to the direction that responses flow from the user agent server back to the user agent client. URL-encoded: A character string encoded according to RFC 2396, Section 2.4 [5]. User Agent Client (UAC): A user agent client is a logical entity that creates a new request, and then uses the client transaction state machinery to send it. The role of UAC lasts only for the duration of that transaction. In other words, if a piece of software initiates a request, it acts as a UAC for the duration of that transaction. If it receives a request later, it assumes the role of a user agent server for the processing of that transaction. UAC Core: The set of processing functions required of a UAC that reside above the transaction and transport layers. User Agent Server (UAS): A user agent server is a logical entity that generates a response to a SIP request. The response accepts, rejects, or redirects the request. This role lasts only for the duration of that transaction. In other words, if a piece of software responds to a request, it acts as a UAS for the duration of that transaction. If it generates a request later, it assumes the role of a user agent client for the processing of that transaction. UAS Core: The set of processing functions required at a UAS that resides above the transaction and transport layers. User Agent (UA): A logical entity that can act as both a user agent client and user agent server. The role of UAC and UAS, as well as proxy and redirect servers, are defined on a transaction-by-transaction basis. For example, the user agent initiating a call acts as a UAC when sending the initial INVITE request and as a UAS when receiving a BYE request from the callee. Similarly, the same software can act as a proxy server for one request and as a redirect server for the next request. Proxy, location, and registrar servers defined above are logical entities; implementations MAY combine them into a single application. 7 SIP Messages SIP is a text-based protocol and uses the UTF-8 charset (RFC 2279 [7]). Rosenberg, et. al. Standards Track [Page 26] RFC 3261 SIP: Session Initiation Protocol June 2002 A SIP message is either a request from a client to a server, or a response from a server to a client. Both Request (section 7.1) and Response (section 7.2) messages use the basic format of RFC 2822 [3], even though the syntax differs in character set and syntax specifics. (SIP allows header fields that would not be valid RFC 2822 header fields, for example.) Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body. generic-message = start-line *message-header CRLF [ message-body ] start-line = Request-Line / Status-Line The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not. Except for the above difference in character sets, much of SIP's message and header field syntax is identical to HTTP/1.1. Rather than repeating the syntax and semantics here, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification (RFC 2616 [8]). However, SIP is not an extension of HTTP. 7.1 Requests SIP requests are distinguished by having a Request-Line for a start- line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character. The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements. Request-Line = Method SP Request-URI SP SIP-Version CRLF Method: This specification defines six methods: REGISTER for registering contact information, INVITE, ACK, and CANCEL for setting up sessions, BYE for terminating sessions, and OPTIONS for querying servers about their capabilities. SIP extensions, documented in standards track RFCs, may define additional methods. Rosenberg, et. al. Standards Track [Page 27] RFC 3261 SIP: Session Initiation Protocol June 2002 Request-URI: The Request-URI is a SIP or SIPS URI as described in Section 19.1 or a general URI (RFC 2396 [5]). It indicates the user or service to which this request is being addressed. The Request-URI MUST NOT contain unescaped spaces or control characters and MUST NOT be enclosed in ""<>"". SIP elements MAY support Request-URIs with schemes other than ""sip"" and ""sips"", for example the ""tel"" URI scheme of RFC 2806 [9]. SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme. SIP-Version: Both request and response messages include the version of SIP in use, and follow [H3.1] (with HTTP replaced by SIP, and HTTP/1.1 replaced by SIP/2.0) regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages MUST include a SIP-Version of ""SIP/2.0"". The SIP-Version string is case-insensitive, but implementations MUST send upper-case. Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference. 7.2 Responses SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character. No CR or LF is allowed except in the final CRLF sequence. Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase. While this specification suggests specific wording for the reason phrase, implementations MAY choose other text, for example, in the language indicated in the Accept-Language header field of the request. Rosenberg, et. al. Standards Track [Page 28] RFC 3261 SIP: Session Initiation Protocol June 2002 The first digit of the Status-Code defines the class of response. The last two digits do not have any categorization role. For this reason, any response with a status code between 100 and 199 is referred to as a ""1xx response"", any response with a status code between 200 and 299 as a ""2xx response"", and so on. SIP/2.0 allows six values for the first digit: 1xx: Provisional -- request received, continuing to process the request; 2xx: Success -- the action was successfully received, understood, and accepted; 3xx: Redirection -- further action needs to be taken in order to complete the request; 4xx: Client Error -- the request contains bad syntax or cannot be fulfilled at this server; 5xx: Server Error -- the server failed to fulfill an apparently valid request; 6xx: Global Failure -- the request cannot be fulfilled at any server. Section 21 defines these classes and describes the individual codes. 7.3 Header Fields SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding. This specification conforms to RFC 2234 [10] and uses only explicit whitespace and folding as an integral part of the grammar. [H4.2] also specifies that multiple header fields of the same field name whose value is a comma-separated list can be combined into one header field. That applies to SIP as well, but the specific rule is different because of the different grammars. Specifically, any SIP header whose grammar is of the form header = ""header-name"" HCOLON header-value *(COMMA header-value) allows for combining header fields of the same name into a comma- separated list. The Contact header field allows a comma-separated list unless the header field value is ""*"". Rosenberg, et. al. Standards Track [Page 29] RFC 3261 SIP: Session Initiation Protocol June 2002 7.3.1 Header Field Format Header fields follow the same generic header format as that given in Section 2.2 of RFC 2822 [3]. Each header field consists of a field name followed by a colon ("":"") and the field value. field-name: field-value The formal grammar for a message-header specified in Section 25 allows for an arbitrary amount of whitespace on either side of the colon; however, implementations should avoid spaces between the field name and the colon and use a single space (SP) between the colon and the field-value. Subject: lunch Subject : lunch Subject :lunch Subject: lunch Thus, the above are all valid and equivalent, but the last is the preferred form. Header fields can be extended over multiple lines by preceding each extra line with at least one SP or horizontal tab (HT). The line break and the whitespace at the beginning of the next line are treated as a single SP character. Thus, the following are equivalent: Subject: I know you're there, pick up the phone and talk to me! Subject: I know you're there, pick up the phone and talk to me! The relative order of header fields with different field names is not significant. However, it is RECOMMENDED that header fields which are needed for proxy processing (Via, Route, Record-Route, Proxy-Require, Max-Forwards, and Proxy-Authorization, for example) appear towards the top of the message to facilitate rapid parsing. The relative order of header field rows with the same field name is important. Multiple header field rows with the same field-name MAY be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list (that is, if follows the grammar defined in Section 7.3). It MUST be possible to combine the multiple header field rows into one ""field-name: field-value"" pair, without changing the semantics of the message, by appending each subsequent field-value to the first, each separated by a comma. The exceptions to this rule are the WWW-Authenticate, Authorization, Proxy- Authenticate, and Proxy-Authorization header fields. Multiple header Rosenberg, et. al. Standards Track [Page 30] RFC 3261 SIP: Session Initiation Protocol June 2002 field rows with these names MAY be present in a message, but since their grammar does not follow the general form listed in Section 7.3, they MUST NOT be combined into a single header field row. Implementations MUST be able to process multiple header field rows with the same name in any combination of the single-value-per-line or comma-separated value forms. The following groups of header field rows are valid and equivalent: Route: <sip:alice@atlanta.com> Subject: Lunch Route: <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Subject: Lunch Subject: Lunch Route: <sip:alice@atlanta.com>, <sip:bob@biloxi.com>, <sip:carol@chicago.com> Each of the following blocks is valid but not equivalent to the others: Route: <sip:alice@atlanta.com> Route: <sip:bob@biloxi.com> Route: <sip:carol@chicago.com> Route: <sip:bob@biloxi.com> Route: <sip:alice@atlanta.com> Route: <sip:carol@chicago.com> Route: <sip:alice@atlanta.com>,<sip:carol@chicago.com>, <sip:bob@biloxi.com> The format of a header field-value is defined per header-name. It will always be either an opaque sequence of TEXT-UTF8 octets, or a combination of whitespace, tokens, separators, and quoted strings. Many existing header fields will adhere to the general form of a value followed by a semi-colon separated sequence of parameter-name, parameter-value pairs: field-name: field-value *(;parameter-name=parameter-value) Rosenberg, et. al. Standards Track [Page 31] RFC 3261 SIP: Session Initiation Protocol June 2002 Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name MUST NOT appear more than once. When comparing header fields, field names are always case- insensitive. Unless otherwise stated in the definition of a particular header field, field values, parameter names, and parameter values are case-insensitive. Tokens are always case-insensitive. Unless specified otherwise, values expressed as quoted strings are case-sensitive. For example, Contact: <sip:alice@atlanta.com>;expires=3600 is equivalent to CONTACT: <sip:alice@atlanta.com>;ExPiReS=3600 and Content-Disposition: session;handling=optional is equivalent to content-disposition: Session;HANDLING=OPTIONAL The following two header fields are not equivalent: Warning: 370 devnull ""Choose a bigger pipe"" Warning: 370 devnull ""CHOOSE A BIGGER PIPE"" 7.3.2 Header Field Classification Some header fields only make sense in requests or responses. These are called request header fields and response header fields, respectively. If a header field appears in a message not matching its category (such as a request header field in a response), it MUST be ignored. Section 20 defines the classification of each header field. 7.3.3 Compact Form SIP provides a mechanism to represent common header field names in an abbreviated form. This may be useful when messages would otherwise become too large to be carried on the transport available to it (exceeding the maximum transmission unit (MTU) when using UDP, for example). These compact forms are defined in Section 20. A compact form MAY be substituted for the longer form of a header field name at any time without changing the semantics of the message. A header Rosenberg, et. al. Standards Track [Page 32] RFC 3261 SIP: Session Initiation Protocol June 2002 field name MAY appear in both long and short forms within the same message. Implementations MUST accept both the long and short forms of each header name. 7.4 Bodies Requests, including new requests defined in extensions to this specification, MAY contain message bodies unless otherwise noted. The interpretation of the body depends on the request method. For response messages, the request method and the response status code determine the type and interpretation of any message body. All responses MAY include a body. 7.4.1 Message Body Type The Internet media type of the message body MUST be given by the Content-Type header field. If the body has undergone any encoding such as compression, then this MUST be indicated by the Content- Encoding header field; otherwise, Content-Encoding MUST be omitted. If applicable, the character set of the message body is indicated as part of the Content-Type header-field value. The ""multipart"" MIME type defined in RFC 2046 [11] MAY be used within the body of the message. Implementations that send requests containing multipart message bodies MUST send a session description as a non-multipart message body if the remote implementation requests this through an Accept header field that does not contain multipart. SIP messages MAY contain binary bodies or body parts. When no explicit charset parameter is provided by the sender, media subtypes of the ""text"" type are defined to have a default charset value of ""UTF-8"". 7.4.2 Message Body Length The body length in bytes is provided by the Content-Length header field. Section 20.14 describes the necessary contents of this header field in detail. The ""chunked"" transfer encoding of HTTP/1.1 MUST NOT be used for SIP. (Note: The chunked encoding modifies the body of a message in order to transfer it as a series of chunks, each with its own size indicator.) Rosenberg, et. al. Standards Track [Page 33] RFC 3261 SIP: Session Initiation Protocol June 2002 7.5 Framing SIP Messages Unlike HTTP, SIP implementations can use UDP or other unreliable datagram protocols. Each such datagram carries one request or response. See Section 18 on constraints on usage of unreliable transports. Implementations processing SIP messages over stream-oriented transports MUST ignore any CRLF appearing before the start-line [H4.1]. The Content-Length header field value is used to locate the end of each SIP message in a stream. It will always be present when SIP messages are sent over stream-oriented transports. 8 General User Agent Behavior A user agent represents an end system. It contains a user agent client (UAC), which generates requests, and a user agent server (UAS), which responds to them. A UAC is capable of generating a request based on some external stimulus (the user clicking a button, or a signal on a PSTN line) and processing a response. A UAS is capable of receiving a request and generating a response based on user input, external stimulus, the result of a program execution, or some other mechanism. When a UAC sends a request, the request passes through some number of proxy servers, which forward the request towards the UAS. When the UAS generates a response, the response is forwarded towards the UAC. UAC and UAS procedures depend strongly on two factors. First, based on whether the request or response is inside or outside of a dialog, and second, based on the method of a request. Dialogs are discussed thoroughly in Section 12; they represent a peer-to-peer relationship between user agents and are established by specific SIP methods, such as INVITE. In this section, we discuss the method-independent rules for UAC and UAS behavior when processing requests that are outside of a dialog. This includes, of course, the requests which themselves establish a dialog. Security procedures for requests and responses outside of a dialog are described in Section 26. Specifically, mechanisms exist for the UAS and UAC to mutually authenticate. A limited set of privacy features are also supported through encryption of bodies using S/MIME. Rosenberg, et. al. Standards Track [Page 34] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1 UAC Behavior This section covers UAC behavior outside of a dialog. 8.1.1 Generating the Request A valid SIP request formulated by a UAC MUST, at a minimum, contain the following header fields: To, From, CSeq, Call-ID, Max-Forwards, and Via; all of these header fields are mandatory in all SIP requests. These six header fields are the fundamental building blocks of a SIP message, as they jointly provide for most of the critical message routing services including the addressing of messages, the routing of responses, limiting message propagation, ordering of messages, and the unique identification of transactions. These header fields are in addition to the mandatory request line, which contains the method, Request-URI, and SIP version. Examples of requests sent outside of a dialog include an INVITE to establish a session (Section 13) and an OPTIONS to query for capabilities (Section 11). 8.1.1.1 Request-URI The initial Request-URI of the message SHOULD be set to the value of the URI in the To field. One notable exception is the REGISTER method; behavior for setting the Request-URI of REGISTER is given in Section 10. It may also be undesirable for privacy reasons or convenience to set these fields to the same value (especially if the originating UA expects that the Request-URI will be changed during transit). In some special circumstances, the presence of a pre-existing route set can affect the Request-URI of the message. A pre-existing route set is an ordered set of URIs that identify a chain of servers, to which a UAC will send outgoing requests that are outside of a dialog. Commonly, they are configured on the UA by a user or service provider manually, or through some other non-SIP mechanism. When a provider wishes to configure a UA with an outbound proxy, it is RECOMMENDED that this be done by providing it with a pre-existing route set with a single URI, that of the outbound proxy. When a pre-existing route set is present, the procedures for populating the Request-URI and Route header field detailed in Section 12.2.1.1 MUST be followed (even though there is no dialog), using the desired Request-URI as the remote target URI. Rosenberg, et. al. Standards Track [Page 35] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.2 To The To header field first and foremost specifies the desired ""logical"" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or may not be the ultimate recipient of the request. The To header field MAY contain a SIP or SIPS URI, but it may also make use of other URI schemes (the tel URL (RFC 2806 [9]), for example) when appropriate. All SIP implementations MUST support the SIP URI scheme. Any implementation that supports TLS MUST support the SIPS URI scheme. The To header field allows for a display name. A UAC may learn how to populate the To header field for a particular request in a number of ways. Usually the user will suggest the To header field through a human interface, perhaps inputting the URI manually or selecting it from some sort of address book. Frequently, the user will not enter a complete URI, but rather a string of digits or letters (for example, ""bob""). It is at the discretion of the UA to choose how to interpret this input. Using the string to form the user part of a SIP URI implies that the UA wishes the name to be resolved in the domain to the right-hand side (RHS) of the at-sign in the SIP URI (for instance, sip:bob@example.com). Using the string to form the user part of a SIPS URI implies that the UA wishes to communicate securely, and that the name is to be resolved in the domain to the RHS of the at-sign. The RHS will frequently be the home domain of the requestor, which allows for the home domain to process the outgoing request. This is useful for features like ""speed dial"" that require interpretation of the user part in the home domain. The tel URL may be used when the UA does not wish to specify the domain that should interpret a telephone number that has been input by the user. Rather, each domain through which the request passes would be given that opportunity. As an example, a user in an airport might log in and send requests through an outbound proxy in the airport. If they enter ""411"" (this is the phone number for local directory assistance in the United States), that needs to be interpreted and processed by the outbound proxy in the airport, not the user's home domain. In this case, tel:411 would be the right choice. A request outside of a dialog MUST NOT contain a To tag; the tag in the To field of a request identifies the peer of the dialog. Since no dialog is established, no tag is present. For further information on the To header field, see Section 20.39. The following is an example of a valid To header field: To: Carol <sip:carol@chicago.com> Rosenberg, et. al. Standards Track [Page 36] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.3 From The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record. Like the To header field, it contains a URI and optionally a display name. It is used by SIP elements to determine which processing rules to apply to a request (for example, automatic call rejection). As such, it is very important that the From URI not contain IP addresses or the FQDN of the host on which the UA is running, since these are not logical names. The From header field allows for a display name. A UAC SHOULD use the display name ""Anonymous"", along with a syntactically correct, but otherwise meaningless URI (like sip:thisis@anonymous.invalid), if the identity of the client is to remain hidden. Usually, the value that populates the From header field in requests generated by a particular UA is pre-provisioned by the user or by the administrators of the user's local domain. If a particular UA is used by multiple users, it might have switchable profiles that include a URI corresponding to the identity of the profiled user. Recipients of requests can authenticate the originator of a request in order to ascertain that they are who their From header field claims they are (see Section 22 for more on authentication). The From field MUST contain a new ""tag"" parameter, chosen by the UAC. See Section 19.3 for details on choosing a tag. For further information on the From header field, see Section 20.20. Examples: From: ""Bob"" <sips:bob@biloxi.com> ;tag=a48s From: sip:+12125551212@phone2net.com;tag=887s From: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 8.1.1.4 Call-ID The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA. In a new request created by a UAC outside of any dialog, the Call-ID header field MUST be selected by the UAC as a globally unique identifier over space and time unless overridden by method-specific behavior. All SIP UAs must have a means to guarantee that the Call- ID header fields they produce will not be inadvertently generated by any other UA. Note that when requests are retried after certain Rosenberg, et. al. Standards Track [Page 37] RFC 3261 SIP: Session Initiation Protocol June 2002 failure responses that solicit an amendment to a request (for example, a challenge for authentication), these retried requests are not considered new requests, and therefore do not need new Call-ID header fields; see Section 8.1.3.5. Use of cryptographically random identifiers (RFC 1750 [12]) in the generation of Call-IDs is RECOMMENDED. Implementations MAY use the form ""localid@host"". Call-IDs are case-sensitive and are simply compared byte-by-byte. Using cryptographically random identifiers provides some protection against session hijacking and reduces the likelihood of unintentional Call-ID collisions. No provisioning or human interface is required for the selection of the Call-ID header field value for a request. For further information on the Call-ID header field, see Section 20.8. Example: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@foo.bar.com 8.1.1.5 CSeq The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request. For non-REGISTER requests outside of a dialog, the sequence number value is arbitrary. The sequence number value MUST be expressible as a 32-bit unsigned integer and MUST be less than 2**31. As long as it follows the above guidelines, a client may use any mechanism it would like to select CSeq header field values. Section 12.2.1.1 discusses construction of the CSeq for requests within a dialog. Example: CSeq: 4711 INVITE Rosenberg, et. al. Standards Track [Page 38] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.1.6 Max-Forwards The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response. A UAC MUST insert a Max-Forwards header field into each request it originates with a value that SHOULD be 70. This number was chosen to be sufficiently large to guarantee that a request would not be dropped in any SIP network when there were no loops, but not so large as to consume proxy resources when a loop does occur. Lower values should be used with caution and only in networks where topologies are known by the UA. 8.1.1.7 Via The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent. A Via header field value is added only after the transport that will be used to reach the next hop has been selected (which may involve the usage of the procedures in [4]). When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server. The branch parameter value MUST be unique across space and time for all requests sent by the UA. The exceptions to this rule are CANCEL and ACK for non-2xx responses. As discussed below, a CANCEL request will have the same value of the branch parameter as the request it cancels. As discussed in Section 17.1.1.3, an ACK for a non-2xx response will also have the same branch ID as the INVITE whose response it acknowledges. The uniqueness property of the branch ID parameter, to facilitate its use as a transaction ID, was not part of RFC 2543. The branch ID inserted by an element compliant with this specification MUST always begin with the characters ""z9hG4bK"". These 7 characters are used as a magic cookie (7 is deemed sufficient to ensure that an older RFC 2543 implementation would not pick such a value), so that servers receiving the request can determine that the branch ID was constructed in the fashion described by this Rosenberg, et. al. Standards Track [Page 39] RFC 3261 SIP: Session Initiation Protocol June 2002 specification (that is, globally unique). Beyond this requirement, the precise format of the branch token is implementation-defined. The Via header maddr, ttl, and sent-by components will be set when the request is processed by the transport layer (Section 18). Via processing for proxies is described in Section 16.6 Item 8 and Section 16.7 Item 3. 8.1.1.8 Contact The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in this specification, that includes only the INVITE request. For these requests, the scope of the Contact is global. That is, the Contact header field value contains the URI at which the UA would like to receive requests, and this URI MUST be valid even if used in subsequent requests outside of any dialogs. If the Request-URI or top Route header field value contains a SIPS URI, the Contact header field MUST contain a SIPS URI as well. For further information on the Contact header field, see Section 20.10. 8.1.1.9 Supported and Require If the UAC supports extensions to SIP that can be applied by the server to the response, the UAC SHOULD include a Supported header field in the request listing the option tags (Section 19.2) for those extensions. The option tags listed MUST only refer to extensions defined in standards-track RFCs. This is to prevent servers from insisting that clients implement non-standard, vendor-defined features in order to receive service. Extensions defined by experimental and informational RFCs are explicitly excluded from usage with the Supported header field in a request, since they too are often used to document vendor-defined extensions. If the UAC wishes to insist that a UAS understand an extension that the UAC will apply to the request in order to process the request, it MUST insert a Require header field into the request listing the option tag for that extension. If the UAC wishes to apply an extension to the request and insist that any proxies that are Rosenberg, et. al. Standards Track [Page 40] RFC 3261 SIP: Session Initiation Protocol June 2002 traversed understand that extension, it MUST insert a Proxy-Require header field into the request listing the option tag for that extension. As with the Supported header field, the option tags in the Require and Proxy-Require header fields MUST only refer to extensions defined in standards-track RFCs. 8.1.1.10 Additional Message Components After a new request has been created, and the header fields described above have been properly constructed, any additional optional header fields are added, as are any header fields specific to the method. SIP requests MAY contain a MIME-encoded message-body. Regardless of the type of body that a request contains, certain header fields must be formulated to characterize the contents of the body. For further information on these header fields, see Sections 20.11 through 20.15. 8.1.2 Sending the Request The destination for the request is then computed. Unless there is local policy specifying otherwise, the destination MUST be determined by applying the DNS procedures described in [4] as follows. If the first element in the route set indicated a strict router (resulting in forming the request as described in Section 12.2.1.1), the procedures MUST be applied to the Request-URI of the request."
"Otherwise, the procedures are applied to the first Route header field value in the request (if one exists), or to the request's Request-URI if there is no Route header field present. These procedures yield an ordered set of address, port, and transports to attempt. Independent of which URI is used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the UAC MUST follow the procedures of [4] as if the input URI were a SIPS URI. Local policy MAY specify an alternate set of destinations to attempt. If the Request-URI contains a SIPS URI, any alternate destinations MUST be contacted with TLS. Beyond that, there are no restrictions on the alternate destinations if the request contains no Route header field. This provides a simple alternative to a pre-existing route set as a way to specify an outbound proxy. However, that approach for configuring an outbound proxy is NOT RECOMMENDED; a pre-existing route set with a single URI SHOULD be used instead. If the request contains a Route header field, the request SHOULD be sent to the locations derived from its topmost value, but MAY be sent to any server that the UA is certain will honor the Route and Request-URI policies specified in this document (as opposed to those in RFC 2543). In particular, a UAC configured with an outbound proxy SHOULD Rosenberg, et. al. Standards Track [Page 41] RFC 3261 SIP: Session Initiation Protocol June 2002 attempt to send the request to the location indicated in the first Route header field value instead of adopting the policy of sending all messages to the outbound proxy. This ensures that outbound proxies that do not add Record-Route header field values will drop out of the path of subsequent requests. It allows endpoints that cannot resolve the first Route URI to delegate that task to an outbound proxy. The UAC SHOULD follow the procedures defined in [4] for stateful elements, trying each address until a server is contacted. Each try constitutes a new transaction, and therefore each carries a different topmost Via header field value with a new branch parameter. Furthermore, the transport value in the Via header field is set to whatever transport was determined for the target server. 8.1.3 Processing Responses Responses are first processed by the transport layer and then passed up to the transaction layer. The transaction layer performs its processing and then passes the response up to the TU. The majority of response processing in the TU is method specific. However, there are some general behaviors independent of the method. 8.1.3.1 Transaction Layer Errors In some cases, the response returned by the transaction layer will not be a SIP message, but rather a transaction layer error. When a timeout error is received from the transaction layer, it MUST be treated as if a 408 (Request Timeout) status code has been received. If a fatal transport error is reported by the transport layer (generally, due to fatal ICMP errors in UDP or connection failures in TCP), the condition MUST be treated as a 503 (Service Unavailable) status code. 8.1.3.2 Unrecognized Responses A UAC MUST treat any final response it does not recognize as being equivalent to the x00 response code of that class, and MUST be able to process the x00 response code for all classes. For example, if a UAC receives an unrecognized response code of 431, it can safely assume that there was something wrong with its request and treat the response as if it had received a 400 (Bad Request) response code. A UAC MUST treat any provisional response different than 100 that it does not recognize as 183 (Session Progress). A UAC MUST be able to process 100 and 183 responses. Rosenberg, et. al. Standards Track [Page 42] RFC 3261 SIP: Session Initiation Protocol June 2002 8.1.3.3 Vias If more than one Via header field value is present in a response, the UAC SHOULD discard the message. The presence of additional Via header field values that precede the originator of the request suggests that the message was misrouted or possibly corrupted. 8.1.3.4 Processing 3xx Responses Upon receipt of a redirection response (for example, a 301 response status code), clients SHOULD use the URI(s) in the Contact header field to formulate one or more new requests based on the redirected request. This process is similar to that of a proxy recursing on a 3xx class response as detailed in Sections 16.5 and 16.6. A client starts with an initial target set containing exactly one URI, the Request-URI of the original request. If a client wishes to formulate new requests based on a 3xx class response to that request, it places the URIs to try into the target set. Subject to the restrictions in this specification, a client can choose which Contact URIs it places into the target set. As with proxy recursion, a client processing 3xx class responses MUST NOT add any given URI to the target set more than once. If the original request had a SIPS URI in the Request- URI, the client MAY choose to recurse to a non-SIPS URI, but SHOULD inform the user of the redirection to an insecure URI. Any new request may receive 3xx responses themselves containing the original URI as a contact. Two locations can be configured to redirect to each other. Placing any given URI in the target set only once prevents infinite redirection loops. As the target set grows, the client MAY generate new requests to the URIs in any order. A common mechanism is to order the set by the ""q"" parameter value from the Contact header field value. Requests to the URIs MAY be generated serially or in parallel. One approach is to process groups of decreasing q-values serially and process the URIs in each q-value group in parallel. Another is to perform only serial processing in decreasing q-value order, arbitrarily choosing between contacts of equal q-value. If contacting an address in the list results in a failure, as defined in the next paragraph, the element moves to the next address in the list, until the list is exhausted. If the list is exhausted, then the request has failed. Rosenberg, et. al. Standards Track [Page 43] RFC 3261 SIP: Session Initiation Protocol June 2002 Failures SHOULD be detected through failure response codes (codes greater than 399); for network errors the client transaction will report any transport layer failures to the transaction user. Note that some response codes (detailed in 8.1.3.5) indicate that the request can be retried; requests that are reattempted should not be considered failures. When a failure for a particular contact address is received, the client SHOULD try the next contact address. This will involve creating a new client transaction to deliver a new request. In order to create a request based on a contact address in a 3xx response, a UAC MUST copy the entire URI from the target set into the Request-URI, except for the ""method-param"" and ""header"" URI parameters (see Section 19.1.1 for a definition of these parameters). It uses the ""header"" parameters to create header field values for the new request, overwriting header field values associated with the redirected request in accordance with the guidelines in Section 19.1.5. Note that in some instances, header fields that have been communicated in the contact address may instead append to existing request header fields in the original redirected request. As a general rule, if the header field can accept a comma-separated list of values, then the new header field value MAY be appended to any existing values in the original redirected request. If the header field does not accept multiple values, the value in the original redirected request MAY be overwritten by the header field value communicated in the contact address. For example, if a contact address is returned with the following value: sip:user@host?Subject=foo&Call-Info=<http://www.foo.com> Then any Subject header field in the original redirected request is overwritten, but the HTTP URL is merely appended to any existing Call-Info header field values. It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID used in the original redirected request, but the UAC MAY also choose to update the Call-ID header field value for new requests, for example. Finally, once the new request has been constructed, it is sent using a new client transaction, and therefore MUST have a new branch ID in the top Via field as discussed in Section 8.1.1.7. Rosenberg, et. al. Standards Track [Page 44] RFC 3261 SIP: Session Initiation Protocol June 2002 In all other respects, requests sent upon receipt of a redirect response SHOULD re-use the header fields and bodies of the original request. In some instances, Contact header field values may be cached at UAC temporarily or permanently depending on the status code received and the presence of an expiration interval; see Sections 21.3.2 and 21.3.3. 8.1.3.5 Processing 4xx Responses Certain 4xx response codes require specific UA processing, independent of the method. If a 401 (Unauthorized) or 407 (Proxy Authentication Required) response is received, the UAC SHOULD follow the authorization procedures of Section 22.2 and Section 22.3 to retry the request with credentials. If a 413 (Request Entity Too Large) response is received (Section 21.4.11), the request contained a body that was longer than the UAS was willing to accept. If possible, the UAC SHOULD retry the request, either omitting the body or using one of a smaller length. If a 415 (Unsupported Media Type) response is received (Section 21.4.13), the request contained media types not supported by the UAS. The UAC SHOULD retry sending the request, this time only using content with types listed in the Accept header field in the response, with encodings listed in the Accept-Encoding header field in the response, and with languages listed in the Accept-Language in the response. If a 416 (Unsupported URI Scheme) response is received (Section 21.4.14), the Request-URI used a URI scheme not supported by the server. The client SHOULD retry the request, this time, using a SIP URI. If a 420 (Bad Extension) response is received (Section 21.4.15), the request contained a Require or Proxy-Require header field listing an option-tag for a feature not supported by a proxy or UAS. The UAC SHOULD retry the request, this time omitting any extensions listed in the Unsupported header field in the response. In all of the above cases, the request is retried by creating a new request with the appropriate modifications. This new request constitutes a new transaction and SHOULD have the same value of the Call-ID, To, and From of the previous request, but the CSeq should contain a new sequence number that is one higher than the previous. Rosenberg, et. al. Standards Track [Page 45] RFC 3261 SIP: Session Initiation Protocol June 2002 With other 4xx responses, including those yet to be defined, a retry may or may not be possible depending on the method and the use case. 8.2 UAS Behavior When a request outside of a dialog is processed by a UAS, there is a set of processing rules that are followed, independent of the method. Section 12 gives guidance on how a UAS can tell whether a request is inside or outside of a dialog. Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed. UASs SHOULD process the requests in the order of the steps that follow in this section (that is, starting with authentication, then inspecting the method, the header fields, and so on throughout the remainder of this section). 8.2.1 Method Inspection Once a request is authenticated (or authentication is skipped), the UAS MUST inspect the method of the request. If the UAS recognizes but does not support the method of a request, it MUST generate a 405 (Method Not Allowed) response. Procedures for generating responses are described in Section 8.2.6. The UAS MUST also add an Allow header field to the 405 (Method Not Allowed) response. The Allow header field MUST list the set of methods supported by the UAS generating the message. The Allow header field is presented in Section 20.5. If the method is one supported by the server, processing continues. 8.2.2 Header Inspection If a UAS does not understand a header field in a request (that is, the header field is not defined in this specification or in any supported extension), the server MUST ignore that header field and continue processing the message. A UAS SHOULD ignore any malformed header fields that are not necessary for processing requests. 8.2.2.1 To and Request-URI The To header field identifies the original recipient of the request designated by the user identified in the From field. The original recipient may or may not be the UAS processing the request, due to call forwarding or other proxy operations. A UAS MAY apply any policy it wishes to determine whether to accept requests when the To Rosenberg, et. al. Standards Track [Page 46] RFC 3261 SIP: Session Initiation Protocol June 2002 header field is not the identity of the UAS. However, it is RECOMMENDED that a UAS accept requests even if they do not recognize the URI scheme (for example, a tel: URI) in the To header field, or if the To header field does not address a known or current user of this UAS. If, on the other hand, the UAS decides to reject the request, it SHOULD generate a response with a 403 (Forbidden) status code and pass it to the server transaction for transmission. However, the Request-URI identifies the UAS that is to process the request. If the Request-URI uses a scheme not supported by the UAS, it SHOULD reject the request with a 416 (Unsupported URI Scheme) response. If the Request-URI does not identify an address that the UAS is willing to accept requests for, it SHOULD reject the request with a 404 (Not Found) response. Typically, a UA that uses the REGISTER method to bind its address-of-record to a specific contact address will see requests whose Request-URI equals that contact address. Other potential sources of received Request-URIs include the Contact header fields of requests and responses sent by the UA that establish or refresh dialogs. 8.2.2.2 Merged Requests If the request has no tag in the To header field, the UAS core MUST check the request against ongoing transactions. If the From tag, Call-ID, and CSeq exactly match those associated with an ongoing transaction, but the request does not match that transaction (based on the matching rules in Section 17.2.3), the UAS core SHOULD generate a 482 (Loop Detected) response and pass it to the server transaction. The same request has arrived at the UAS more than once, following different paths, most likely due to forking. The UAS processes the first such request received and responds with a 482 (Loop Detected) to the rest of them. 8.2.2.3 Require Assuming the UAS decides that it is the proper element to process the request, it examines the Require header field, if present. The Require header field is used by a UAC to tell a UAS about SIP extensions that the UAC expects the UAS to support in order to process the request properly. Its format is described in Section 20.32. If a UAS does not understand an option-tag listed in a Require header field, it MUST respond by generating a response with status code 420 (Bad Extension). The UAS MUST add an Unsupported header field, and list in it those options it does not understand amongst those in the Require header field of the request. Rosenberg, et. al. Standards Track [Page 47] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that Require and Proxy-Require MUST NOT be used in a SIP CANCEL request, or in an ACK request sent for a non-2xx response. These header fields MUST be ignored if they are present in these requests. An ACK request for a 2xx response MUST contain only those Require and Proxy-Require values that were present in the initial request. Example: UAC->UAS: INVITE sip:watson@bell-telephone.com SIP/2.0 Require: 100rel UAS->UAC: SIP/2.0 420 Bad Extension Unsupported: 100rel This behavior ensures that the client-server interaction will proceed without delay when all options are understood by both sides, and only slow down if options are not understood (as in the example above). For a well-matched client-server pair, the interaction proceeds quickly, saving a round-trip often required by negotiation mechanisms. In addition, it also removes ambiguity when the client requires features that the server does not understand. Some features, such as call handling fields, are only of interest to end systems. 8.2.3 Content Processing Assuming the UAS understands any extensions required by the client, the UAS examines the body of the message, and the header fields that describe it. If there are any bodies whose type (indicated by the Content-Type), language (indicated by the Content-Language) or encoding (indicated by the Content-Encoding) are not understood, and that body part is not optional (as indicated by the Content- Disposition header field), the UAS MUST reject the request with a 415 (Unsupported Media Type) response. The response MUST contain an Accept header field listing the types of all bodies it understands, in the event the request contained bodies of types not supported by the UAS. If the request contained content encodings not understood by the UAS, the response MUST contain an Accept-Encoding header field listing the encodings understood by the UAS. If the request contained content with languages not understood by the UAS, the response MUST contain an Accept-Language header field indicating the languages understood by the UAS. Beyond these checks, body handling depends on the method and type. For further information on the processing of content-specific header fields, see Section 7.4 as well as Section 20.11 through 20.15. Rosenberg, et. al. Standards Track [Page 48] RFC 3261 SIP: Session Initiation Protocol June 2002 8.2.4 Applying Extensions A UAS that wishes to apply some extension when generating the response MUST NOT do so unless support for that extension is indicated in the Supported header field in the request. If the desired extension is not supported, the server SHOULD rely only on baseline SIP and any other extensions supported by the client. In rare circumstances, where the server cannot process the request without the extension, the server MAY send a 421 (Extension Required) response. This response indicates that the proper response cannot be generated without support of a specific extension. The needed extension(s) MUST be included in a Require header field in the response. This behavior is NOT RECOMMENDED, as it will generally break interoperability. Any extensions applied to a non-421 response MUST be listed in a Require header field included in the response. Of course, the server MUST NOT apply extensions not listed in the Supported header field in the request. As a result of this, the Require header field in a response will only ever contain option tags defined in standards- track RFCs. 8.2.5 Processing the Request Assuming all of the checks in the previous subsections are passed, the UAS processing becomes method-specific. Section 10 covers the REGISTER request, Section 11 covers the OPTIONS request, Section 13 covers the INVITE request, and Section 15 covers the BYE request. 8.2.6 Generating the Response When a UAS wishes to construct a response to a request, it follows the general procedures detailed in the following subsections. Additional behaviors specific to the response code in question, which are not detailed in this section, may also be required. Once all procedures associated with the creation of a response have been completed, the UAS hands the response back to the server transaction from which it received the request. 8.2.6.1 Sending a Provisional Response One largely non-method-specific guideline for the generation of responses is that UASs SHOULD NOT issue a provisional response for a non-INVITE request. Rather, UASs SHOULD generate a final response to a non-INVITE request as soon as possible. Rosenberg, et. al. Standards Track [Page 49] RFC 3261 SIP: Session Initiation Protocol June 2002 When a 100 (Trying) response is generated, any Timestamp header field present in the request MUST be copied into this 100 (Trying) response. If there is a delay in generating the response, the UAS SHOULD add a delay value into the Timestamp value in the response. This value MUST contain the difference between the time of sending of the response and receipt of the request, measured in seconds. 8.2.6.2 Headers and Tags The From field of the response MUST equal the From header field of the request. The Call-ID header field of the response MUST equal the Call-ID header field of the request. The CSeq header field of the response MUST equal the CSeq field of the request. The Via header field values in the response MUST equal the Via header field values in the request and MUST maintain the same ordering. If a request contained a To tag in the request, the To header field in the response MUST equal that of the request. However, if the To header field in the request did not contain a tag, the URI in the To header field in the response MUST equal the URI in the To header field; additionally, the UAS MUST add a tag to the To header field in the response (with the exception of the 100 (Trying) response, in which a tag MAY be present). This serves to identify the UAS that is responding, possibly resulting in a component of a dialog ID. The same tag MUST be used for all responses to that request, both final and provisional (again excepting the 100 (Trying)). Procedures for the generation of tags are defined in Section 19.3. 8.2.7 Stateless UAS Behavior A stateless UAS is a UAS that does not maintain transaction state. It replies to requests normally, but discards any state that would ordinarily be retained by a UAS after a response has been sent. If a stateless UAS receives a retransmission of a request, it regenerates the response and resends it, just as if it were replying to the first instance of the request. A UAS cannot be stateless unless the request processing for that method would always result in the same response if the requests are identical. This rules out stateless registrars, for example. Stateless UASs do not use a transaction layer; they receive requests directly from the transport layer and send responses directly to the transport layer. The stateless UAS role is needed primarily to handle unauthenticated requests for which a challenge response is issued. If unauthenticated requests were handled statefully, then malicious floods of unauthenticated requests could create massive amounts of Rosenberg, et. al. Standards Track [Page 50] RFC 3261 SIP: Session Initiation Protocol June 2002 transaction state that might slow or completely halt call processing in a UAS, effectively creating a denial of service condition; for more information see Section 26.1.5. The most important behaviors of a stateless UAS are the following: o A stateless UAS MUST NOT send provisional (1xx) responses. o A stateless UAS MUST NOT retransmit responses. o A stateless UAS MUST ignore ACK requests. o A stateless UAS MUST ignore CANCEL requests. o To header tags MUST be generated for responses in a stateless manner - in a manner that will generate the same tag for the same request consistently. For information on tag construction see Section 19.3. In all other respects, a stateless UAS behaves in the same manner as a stateful UAS. A UAS can operate in either a stateful or stateless mode for each new request. 8.3 Redirect Servers In some architectures it may be desirable to reduce the processing load on proxy servers that are responsible for routing requests, and improve signaling path robustness, by relying on redirection. Redirection allows servers to push routing information for a request back in a response to the client, thereby taking themselves out of the loop of further messaging for this transaction while still aiding in locating the target of the request. When the originator of the request receives the redirection, it will send a new request based on the URI(s) it has received. By propagating URIs from the core of the network to its edges, redirection allows for considerable network scalability. A redirect server is logically constituted of a server transaction layer and a transaction user that has access to a location service of some kind (see Section 10 for more on registrars and location services). This location service is effectively a database containing mappings between a single URI and a set of one or more alternative locations at which the target of that URI can be found. A redirect server does not issue any SIP requests of its own. After receiving a request other than CANCEL, the server either refuses the request or gathers the list of alternative locations from the Rosenberg, et. al. Standards Track [Page 51] RFC 3261 SIP: Session Initiation Protocol June 2002 location service and returns a final response of class 3xx. For well-formed CANCEL requests, it SHOULD return a 2xx response. This response ends the SIP transaction. The redirect server maintains transaction state for an entire SIP transaction. It is the responsibility of clients to detect forwarding loops between redirect servers. When a redirect server returns a 3xx response to a request, it populates the list of (one or more) alternative locations into the Contact header field. An ""expires"" parameter to the Contact header field values may also be supplied to indicate the lifetime of the Contact data. The Contact header field contains URIs giving the new locations or user names to try, or may simply specify additional transport parameters. A 301 (Moved Permanently) or 302 (Moved Temporarily) response may also give the same location and username that was targeted by the initial request but specify additional transport parameters such as a different server or multicast address to try, or a change of SIP transport from UDP to TCP or vice versa. However, redirect servers MUST NOT redirect a request to a URI equal to the one in the Request-URI; instead, provided that the URI does not point to itself, the server MAY proxy the request to the destination URI, or MAY reject it with a 404. If a client is using an outbound proxy, and that proxy actually redirects requests, a potential arises for infinite redirection loops. Note that a Contact header field value MAY also refer to a different resource than the one originally called. For example, a SIP call connected to PSTN gateway may need to deliver a special informational announcement such as ""The number you have dialed has been changed."" A Contact response header field can contain any suitable URI indicating where the called party can be reached, not limited to SIP URIs. For example, it could contain URIs for phones, fax, or irc (if they were defined) or a mailto: (RFC 2368 [32]) URL. Section 26.4.4 discusses implications and limitations of redirecting a SIPS URI to a non-SIPS URI. The ""expires"" parameter of a Contact header field value indicates how long the URI is valid. The value of the parameter is a number indicating seconds. If this parameter is not provided, the value of the Expires header field determines how long the URI is valid. Malformed values SHOULD be treated as equivalent to 3600. Rosenberg, et. al. Standards Track [Page 52] RFC 3261 SIP: Session Initiation Protocol June 2002 This provides a modest level of backwards compatibility with RFC 2543, which allowed absolute times in this header field. If an absolute time is received, it will be treated as malformed, and then default to 3600. Redirect servers MUST ignore features that are not understood (including unrecognized header fields, any unknown option tags in Require, or even method names) and proceed with the redirection of the request in question. 9 Canceling a Request The previous section has discussed general UA behavior for generating requests and processing responses for requests of all methods. In this section, we discuss a general purpose method, called CANCEL. The CANCEL request, as the name implies, is used to cancel a previous request sent by a client. Specifically, it asks the UAS to cease processing the request and to generate an error response to that request. CANCEL has no effect on a request to which a UAS has already given a final response. Because of this, it is most useful to CANCEL requests to which it can take a server long time to respond. For this reason, CANCEL is best for INVITE requests, which can take a long time to generate a response. In that usage, a UAS that receives a CANCEL request for an INVITE, but has not yet sent a final response, would ""stop ringing"", and then respond to the INVITE with a specific error response (a 487). CANCEL requests can be constructed and sent by both proxies and user agent clients. Section 15 discusses under what conditions a UAC would CANCEL an INVITE request, and Section 16.10 discusses proxy usage of CANCEL. A stateful proxy responds to a CANCEL, rather than simply forwarding a response it would receive from a downstream element. For that reason, CANCEL is referred to as a ""hop-by-hop"" request, since it is responded to at each stateful proxy hop. 9.1 Client Behavior A CANCEL request SHOULD NOT be sent to cancel a request other than INVITE. Since requests other than INVITE are responded to immediately, sending a CANCEL for a non-INVITE request would always create a race condition. Rosenberg, et. al. Standards Track [Page 53] RFC 3261 SIP: Session Initiation Protocol June 2002 The following procedures are used to construct a CANCEL request. The Request-URI, Call-ID, To, the numeric part of CSeq, and From header fields in the CANCEL request MUST be identical to those in the request being cancelled, including tags. A CANCEL constructed by a client MUST have only a single Via header field value matching the top Via value in the request being cancelled. Using the same values for these header fields allows the CANCEL to be matched with the request it cancels (Section 9.2 indicates how such matching occurs). However, the method part of the CSeq header field MUST have a value of CANCEL. This allows it to be identified and processed as a transaction in its own right (See Section 17). If the request being cancelled contains a Route header field, the CANCEL request MUST include that Route header field's values. This is needed so that stateless proxies are able to route CANCEL requests properly. The CANCEL request MUST NOT contain any Require or Proxy-Require header fields. Once the CANCEL is constructed, the client SHOULD check whether it has received any response (provisional or final) for the request being cancelled (herein referred to as the ""original request""). If no provisional response has been received, the CANCEL request MUST NOT be sent; rather, the client MUST wait for the arrival of a provisional response before sending the request. If the original request has generated a final response, the CANCEL SHOULD NOT be sent, as it is an effective no-op, since CANCEL has no effect on requests that have already generated a final response. When the client decides to send the CANCEL, it creates a client transaction for the CANCEL and passes it the CANCEL request along with the destination address, port, and transport. The destination address, port, and transport for the CANCEL MUST be identical to those used to send the original request. If it was allowed to send the CANCEL before receiving a response for the previous request, the server could receive the CANCEL before the original request. Note that both the transaction corresponding to the original request and the CANCEL transaction will complete independently. However, a UAC canceling a request cannot rely on receiving a 487 (Request Terminated) response for the original request, as an RFC 2543- compliant UAS will not generate such a response. If there is no final response for the original request in 64*T1 seconds (T1 is Rosenberg, et. al. Standards Track [Page 54] RFC 3261 SIP: Session Initiation Protocol June 2002 defined in Section 17.1.1.1), the client SHOULD then consider the original transaction cancelled and SHOULD destroy the client transaction handling the original request. 9.2 Server Behavior The CANCEL method requests that the TU at the server side cancel a pending transaction. The TU determines the transaction to be cancelled by taking the CANCEL request, and then assuming that the request method is anything but CANCEL or ACK and applying the transaction matching procedures of Section 17.2.3. The matching transaction is the one to be cancelled. The processing of a CANCEL request at a server depends on the type of server. A stateless proxy will forward it, a stateful proxy might respond to it and generate some CANCEL requests of its own, and a UAS will respond to it. See Section 16.10 for proxy treatment of CANCEL. A UAS first processes the CANCEL request according to the general UAS processing described in Section 8.2. However, since CANCEL requests are hop-by-hop and cannot be resubmitted, they cannot be challenged by the server in order to get proper credentials in an Authorization header field. Note also that CANCEL requests do not contain a Require header field. If the UAS did not find a matching transaction for the CANCEL according to the procedure above, it SHOULD respond to the CANCEL with a 481 (Call Leg/Transaction Does Not Exist). If the transaction for the original request still exists, the behavior of the UAS on receiving a CANCEL request depends on whether it has already sent a final response for the original request. If it has, the CANCEL request has no effect on the processing of the original request, no effect on any session state, and no effect on the responses generated for the original request. If the UAS has not issued a final response for the original request, its behavior depends on the method of the original request. If the original request was an INVITE, the UAS SHOULD immediately respond to the INVITE with a 487 (Request Terminated). A CANCEL request has no impact on the processing of transactions with any other method defined in this specification. Regardless of the method of the original request, as long as the CANCEL matched an existing transaction, the UAS answers the CANCEL request itself with a 200 (OK) response. This response is constructed following the procedures described in Section 8.2.6 noting that the To tag of the response to the CANCEL and the To tag in the response to the original request SHOULD be the same. The response to CANCEL is passed to the server transaction for transmission. Rosenberg, et. al. Standards Track [Page 55] RFC 3261 SIP: Session Initiation Protocol June 2002 10 Registrations 10.1 Overview SIP offers a discovery capability. If a user wants to initiate a session with another user, SIP must discover the current host(s) at which the destination user is reachable. This discovery process is frequently accomplished by SIP network elements such as proxy servers and redirect servers which are responsible for receiving a request, determining where to send it based on knowledge of the location of the user, and then sending it there. To do this, SIP network elements consult an abstract service known as a location service, which provides address bindings for a particular domain. These address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com, for example, to one or more URIs that are somehow ""closer"" to the desired user, sip:bob@engineering.biloxi.com, for example. Ultimately, a proxy will consult a location service that maps a received URI to the user agent(s) at which the desired recipient is currently residing. Registration creates bindings in a location service for a particular domain that associates an address-of-record URI with one or more contact addresses. Thus, when a proxy for that domain receives a request whose Request-URI matches the address-of-record, the proxy will forward the request to the contact addresses registered to that address-of-record. Generally, it only makes sense to register an address-of-record at a domain's location service when requests for that address-of-record would be routed to that domain. In most cases, this means that the domain of the registration will need to match the domain in the URI of the address-of-record. There are many ways by which the contents of the location service can be established. One way is administratively. In the above example, Bob is known to be a member of the engineering department through access to a corporate database. However, SIP provides a mechanism for a UA to create a binding explicitly. This mechanism is known as registration. Registration entails sending a REGISTER request to a special type of UAS known as a registrar. A registrar acts as the front end to the location service for a domain, reading and writing mappings based on the contents of REGISTER requests."
"This location service is then typically consulted by a proxy server that is responsible for routing requests for that domain. An illustration of the overall registration process is given in Figure 2. Note that the registrar and proxy server are logical roles that can be played by a single device in a network; for purposes of Rosenberg, et. al. Standards Track [Page 56] RFC 3261 SIP: Session Initiation Protocol June 2002 clarity the two are separated in this illustration. Also note that UAs may send requests through a proxy server in order to reach a registrar if the two are separate elements. SIP does not mandate a particular mechanism for implementing the location service. The only requirement is that a registrar for some domain MUST be able to read and write data to the location service, and a proxy or a redirect server for that domain MUST be capable of reading that same data. A registrar MAY be co-located with a particular SIP proxy server for the same domain. 10.2 Constructing the REGISTER Request REGISTER requests add, remove, and query bindings. A REGISTER request can add a new binding between an address-of-record and one or more contact addresses. Registration on behalf of a particular address-of-record can be performed by a suitably authorized third party. A client can also remove previous bindings or query to determine which bindings are currently in place for an address-of- record. Except as noted, the construction of the REGISTER request and the behavior of clients sending a REGISTER request is identical to the general UAC behavior described in Section 8.1 and Section 17.1. A REGISTER request does not establish a dialog. A UAC MAY include a Route header field in a REGISTER request based on a pre-existing route set as described in Section 8.1. The Record-Route header field has no meaning in REGISTER requests or responses, and MUST be ignored if present. In particular, the UAC MUST NOT create a new route set based on the presence or absence of a Record-Route header field in any response to a REGISTER request. The following header fields, except Contact, MUST be included in a REGISTER request. A Contact header field MAY be included: Request-URI: The Request-URI names the domain of the location service for which the registration is meant (for example, ""sip:chicago.com""). The ""userinfo"" and ""@"" components of the SIP URI MUST NOT be present. To: The To header field contains the address of record whose registration is to be created, queried, or modified. The To header field and the Request-URI field typically differ, as the former contains a user name. This address-of-record MUST be a SIP URI or SIPS URI. Rosenberg, et. al. Standards Track [Page 57] RFC 3261 SIP: Session Initiation Protocol June 2002 From: The From header field contains the address-of-record of the person responsible for the registration. The value is the same as the To header field unless the request is a third- party registration. Call-ID: All registrations from a UAC SHOULD use the same Call-ID header field value for registrations sent to a particular registrar. If the same client were to use different Call-ID values, a registrar could not detect whether a delayed REGISTER request might have arrived out of order. CSeq: The CSeq value guarantees proper ordering of REGISTER requests. A UA MUST increment the CSeq value by one for each REGISTER request with the same Call-ID. Contact: REGISTER requests MAY contain a Contact header field with zero or more values containing address bindings. UAs MUST NOT send a new registration (that is, containing new Contact header field values, as opposed to a retransmission) until they have received a final response from the registrar for the previous one or the previous REGISTER request has timed out. Rosenberg, et. al. Standards Track [Page 58] RFC 3261 SIP: Session Initiation Protocol June 2002 bob +----+ | UA | | | +----+ | |3)INVITE | carol@chicago.com chicago.com +--------+ V +---------+ 2)Store|Location|4)Query +-----+ |Registrar|=======>| Service|<=======|Proxy|sip.chicago.com +---------+ +--------+=======>+-----+ A 5)Resp | | | | | 1)REGISTER| | | | +----+ | | UA |<-------------------------------+ cube2214a| | 6)INVITE +----+ carol@cube2214a.chicago.com carol Figure 2: REGISTER example The following Contact header parameters have a special meaning in REGISTER requests: action: The ""action"" parameter from RFC 2543 has been deprecated. UACs SHOULD NOT use the ""action"" parameter. expires: The ""expires"" parameter indicates how long the UA would like the binding to be valid. The value is a number indicating seconds. If this parameter is not provided, the value of the Expires header field is used instead. Implementations MAY treat values larger than 2**32-1 (4294967295 seconds or 136 years) as equivalent to 2**32-1. Malformed values SHOULD be treated as equivalent to 3600. 10.2.1 Adding Bindings The REGISTER request sent to a registrar includes the contact address(es) to which SIP requests for the address-of-record should be forwarded. The address-of-record is included in the To header field of the REGISTER request. Rosenberg, et. al. Standards Track [Page 59] RFC 3261 SIP: Session Initiation Protocol June 2002 The Contact header field values of the request typically consist of SIP or SIPS URIs that identify particular SIP endpoints (for example, ""sip:carol@cube2214a.chicago.com""), but they MAY use any URI scheme. A SIP UA can choose to register telephone numbers (with the tel URL, RFC 2806 [9]) or email addresses (with a mailto URL, RFC 2368 [32]) as Contacts for an address-of-record, for example. For example, Carol, with address-of-record ""sip:carol@chicago.com"", would register with the SIP registrar of the domain chicago.com. Her registrations would then be used by a proxy server in the chicago.com domain to route requests for Carol's address-of-record to her SIP endpoint. Once a client has established bindings at a registrar, it MAY send subsequent registrations containing new bindings or modifications to existing bindings as necessary. The 2xx response to the REGISTER request will contain, in a Contact header field, a complete list of bindings that have been registered for this address-of-record at this registrar. If the address-of-record in the To header field of a REGISTER request is a SIPS URI, then any Contact header field values in the request SHOULD also be SIPS URIs. Clients should only register non-SIPS URIs under a SIPS address-of-record when the security of the resource represented by the contact address is guaranteed by other means. This may be applicable to URIs that invoke protocols other than SIP, or SIP devices secured by protocols other than TLS. Registrations do not need to update all bindings. Typically, a UA only updates its own contact addresses. 10.2.1.1 Setting the Expiration Interval of Contact Addresses When a client sends a REGISTER request, it MAY suggest an expiration interval that indicates how long the client would like the registration to be valid. (As described in Section 10.3, the registrar selects the actual time interval based on its local policy.) There are two ways in which a client can suggest an expiration interval for a binding: through an Expires header field or an ""expires"" Contact header parameter. The latter allows expiration intervals to be suggested on a per-binding basis when more than one binding is given in a single REGISTER request, whereas the former suggests an expiration interval for all Contact header field values that do not contain the ""expires"" parameter. Rosenberg, et. al. Standards Track [Page 60] RFC 3261 SIP: Session Initiation Protocol June 2002 If neither mechanism for expressing a suggested expiration time is present in a REGISTER, the client is indicating its desire for the server to choose. 10.2.1.2 Preferences among Contact Addresses If more than one Contact is sent in a REGISTER request, the registering UA intends to associate all of the URIs in these Contact header field values with the address-of-record present in the To field. This list can be prioritized with the ""q"" parameter in the Contact header field. The ""q"" parameter indicates a relative preference for the particular Contact header field value compared to other bindings for this address-of-record. Section 16.6 describes how a proxy server uses this preference indication. 10.2.2 Removing Bindings Registrations are soft state and expire unless refreshed, but can also be explicitly removed. A client can attempt to influence the expiration interval selected by the registrar as described in Section 10.2.1. A UA requests the immediate removal of a binding by specifying an expiration interval of ""0"" for that contact address in a REGISTER request. UAs SHOULD support this mechanism so that bindings can be removed before their expiration interval has passed. The REGISTER-specific Contact header field value of ""*"" applies to all registrations, but it MUST NOT be used unless the Expires header field is present with a value of ""0"". Use of the ""*"" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values. 10.2.3 Fetching Bindings A success response to any REGISTER request contains the complete list of existing bindings, regardless of whether the request contained a Contact header field. If no Contact header field is present in a REGISTER request, the list of bindings is left unchanged. 10.2.4 Refreshing Bindings Each UA is responsible for refreshing the bindings that it has previously established. A UA SHOULD NOT refresh bindings set up by other UAs. Rosenberg, et. al. Standards Track [Page 61] RFC 3261 SIP: Session Initiation Protocol June 2002 The 200 (OK) response from the registrar contains a list of Contact fields enumerating all current bindings. The UA compares each contact address to see if it created the contact address, using comparison rules in Section 19.1.4. If so, it updates the expiration time interval according to the expires parameter or, if absent, the Expires field value. The UA then issues a REGISTER request for each of its bindings before the expiration interval has elapsed. It MAY combine several updates into one REGISTER request. A UA SHOULD use the same Call-ID for all registrations during a single boot cycle. Registration refreshes SHOULD be sent to the same network address as the original registration, unless redirected. 10.2.5 Setting the Internal Clock If the response for a REGISTER request contains a Date header field, the client MAY use this header field to learn the current time in order to set any internal clocks. 10.2.6 Discovering a Registrar UAs can use three ways to determine the address to which to send registrations: by configuration, using the address-of-record, and multicast. A UA can be configured, in ways beyond the scope of this specification, with a registrar address. If there is no configured registrar address, the UA SHOULD use the host part of the address- of-record as the Request-URI and address the request there, using the normal SIP server location mechanisms [4]. For example, the UA for the user ""sip:carol@chicago.com"" addresses the REGISTER request to ""sip:chicago.com"". Finally, a UA can be configured to use multicast. Multicast registrations are addressed to the well-known ""all SIP servers"" multicast address ""sip.mcast.net"" (224.0.1.75 for IPv4). No well- known IPv6 multicast address has been allocated; such an allocation will be documented separately when needed. SIP UAs MAY listen to that address and use it to become aware of the location of other local users (see [33]); however, they do not respond to the request. Multicast registration may be inappropriate in some environments, for example, if multiple businesses share the same local area network. 10.2.7 Transmitting a Request Once the REGISTER method has been constructed, and the destination of the message identified, UACs follow the procedures described in Section 8.1.2 to hand off the REGISTER to the transaction layer. Rosenberg, et. al. Standards Track [Page 62] RFC 3261 SIP: Session Initiation Protocol June 2002 If the transaction layer returns a timeout error because the REGISTER yielded no response, the UAC SHOULD NOT immediately re-attempt a registration to the same registrar. An immediate re-attempt is likely to also timeout. Waiting some reasonable time interval for the conditions causing the timeout to be corrected reduces unnecessary load on the network. No specific interval is mandated. 10.2.8 Error Responses If a UA receives a 423 (Interval Too Brief) response, it MAY retry the registration after making the expiration interval of all contact addresses in the REGISTER request equal to or greater than the expiration interval within the Min-Expires header field of the 423 (Interval Too Brief) response. 10.3 Processing REGISTER Requests A registrar is a UAS that responds to REGISTER requests and maintains a list of bindings that are accessible to proxy servers and redirect servers within its administrative domain. A registrar handles requests according to Section 8.2 and Section 17.2, but it accepts only REGISTER requests. A registrar MUST not generate 6xx responses. A registrar MAY redirect REGISTER requests as appropriate. One common usage would be for a registrar listening on a multicast interface to redirect multicast REGISTER requests to its own unicast interface with a 302 (Moved Temporarily) response. Registrars MUST ignore the Record-Route header field if it is included in a REGISTER request. Registrars MUST NOT include a Record-Route header field in any response to a REGISTER request. A registrar might receive a request that traversed a proxy which treats REGISTER as an unknown request and which added a Record- Route header field value. A registrar has to know (for example, through configuration) the set of domain(s) for which it maintains bindings. REGISTER requests MUST be processed by a registrar in the order that they are received. REGISTER requests MUST also be processed atomically, meaning that a particular REGISTER request is either processed completely or not at all. Each REGISTER message MUST be processed independently of any other registration or binding changes. Rosenberg, et. al. Standards Track [Page 63] RFC 3261 SIP: Session Initiation Protocol June 2002 When receiving a REGISTER request, a registrar follows these steps: 1. The registrar inspects the Request-URI to determine whether it has access to bindings for the domain identified in the Request-URI. If not, and if the server also acts as a proxy server, the server SHOULD forward the request to the addressed domain, following the general behavior for proxying messages described in Section 16. 2. To guarantee that the registrar supports any necessary extensions, the registrar MUST process the Require header field values as described for UASs in Section 8.2.2. 3. A registrar SHOULD authenticate the UAC. Mechanisms for the authentication of SIP user agents are described in Section 22. Registration behavior in no way overrides the generic authentication framework for SIP. If no authentication mechanism is available, the registrar MAY take the From address as the asserted identity of the originator of the request. 4. The registrar SHOULD determine if the authenticated user is authorized to modify registrations for this address-of-record. For example, a registrar might consult an authorization database that maps user names to a list of addresses-of-record for which that user has authorization to modify bindings. If the authenticated user is not authorized to modify bindings, the registrar MUST return a 403 (Forbidden) and skip the remaining steps. In architectures that support third-party registration, one entity may be responsible for updating the registrations associated with multiple addresses-of-record. 5. The registrar extracts the address-of-record from the To header field of the request. If the address-of-record is not valid for the domain in the Request-URI, the registrar MUST send a 404 (Not Found) response and skip the remaining steps. The URI MUST then be converted to a canonical form. To do that, all URI parameters MUST be removed (including the user-param), and any escaped characters MUST be converted to their unescaped form. The result serves as an index into the list of bindings. Rosenberg, et. al. Standards Track [Page 64] RFC 3261 SIP: Session Initiation Protocol June 2002 6. The registrar checks whether the request contains the Contact header field. If not, it skips to the last step. If the Contact header field is present, the registrar checks if there is one Contact field value that contains the special value ""*"" and an Expires field. If the request has additional Contact fields or an expiration time other than zero, the request is invalid, and the server MUST return a 400 (Invalid Request) and skip the remaining steps. If not, the registrar checks whether the Call-ID agrees with the value stored for each binding. If not, it MUST remove the binding. If it does agree, it MUST remove the binding only if the CSeq in the request is higher than the value stored for that binding. Otherwise, the update MUST be aborted and the request fails. 7. The registrar now processes each contact address in the Contact header field in turn. For each address, it determines the expiration interval as follows: - If the field value has an ""expires"" parameter, that value MUST be taken as the requested expiration. - If there is no such parameter, but the request has an Expires header field, that value MUST be taken as the requested expiration. - If there is neither, a locally-configured default value MUST be taken as the requested expiration. The registrar MAY choose an expiration less than the requested expiration interval. If and only if the requested expiration interval is greater than zero AND smaller than one hour AND less than a registrar-configured minimum, the registrar MAY reject the registration with a response of 423 (Interval Too Brief). This response MUST contain a Min-Expires header field that states the minimum expiration interval the registrar is willing to honor. It then skips the remaining steps. Allowing the registrar to set the registration interval protects it against excessively frequent registration refreshes while limiting the state that it needs to maintain and decreasing the likelihood of registrations going stale. The expiration interval of a registration is frequently used in the creation of services. An example is a follow-me service, where the user may only be available at a terminal for a brief period. Therefore, registrars should accept brief registrations; a request should only be rejected if the interval is so short that the refreshes would degrade registrar performance. Rosenberg, et. al. Standards Track [Page 65] RFC 3261 SIP: Session Initiation Protocol June 2002 For each address, the registrar then searches the list of current bindings using the URI comparison rules. If the binding does not exist, it is tentatively added. If the binding does exist, the registrar checks the Call-ID value. If the Call-ID value in the existing binding differs from the Call-ID value in the request, the binding MUST be removed if the expiration time is zero and updated otherwise. If they are the same, the registrar compares the CSeq value. If the value is higher than that of the existing binding, it MUST update or remove the binding as above. If not, the update MUST be aborted and the request fails. This algorithm ensures that out-of-order requests from the same UA are ignored. Each binding record records the Call-ID and CSeq values from the request. The binding updates MUST be committed (that is, made visible to the proxy or redirect server) if and only if all binding updates and additions succeed. If any one of them fails (for example, because the back-end database commit failed), the request MUST fail with a 500 (Server Error) response and all tentative binding updates MUST be removed. 8. The registrar returns a 200 (OK) response. The response MUST contain Contact header field values enumerating all current bindings. Each Contact value MUST feature an ""expires"" parameter indicating its expiration interval chosen by the registrar. The response SHOULD include a Date header field. 11 Querying for Capabilities The SIP method OPTIONS allows a UA to query another UA or a proxy server as to its capabilities. This allows a client to discover information about the supported methods, content types, extensions, codecs, etc. without ""ringing"" the other party. For example, before a client inserts a Require header field into an INVITE listing an option that it is not certain the destination UAS supports, the client can query the destination UAS with an OPTIONS to see if this option is returned in a Supported header field. All UAs MUST support the OPTIONS method. The target of the OPTIONS request is identified by the Request-URI, which could identify another UA or a SIP server. If the OPTIONS is addressed to a proxy server, the Request-URI is set without a user part, similar to the way a Request-URI is set for a REGISTER request. Rosenberg, et. al. Standards Track [Page 66] RFC 3261 SIP: Session Initiation Protocol June 2002 Alternatively, a server receiving an OPTIONS request with a Max- Forwards header field value of 0 MAY respond to the request regardless of the Request-URI. This behavior is common with HTTP/1.1. This behavior can be used as a ""traceroute"" functionality to check the capabilities of individual hop servers by sending a series of OPTIONS requests with incremented Max-Forwards values. As is the case for general UA behavior, the transaction layer can return a timeout error if the OPTIONS yields no response. This may indicate that the target is unreachable and hence unavailable. An OPTIONS request MAY be sent as part of an established dialog to query the peer on capabilities that may be utilized later in the dialog. 11.1 Construction of OPTIONS Request An OPTIONS request is constructed using the standard rules for a SIP request as discussed in Section 8.1.1. A Contact header field MAY be present in an OPTIONS. An Accept header field SHOULD be included to indicate the type of message body the UAC wishes to receive in the response. Typically, this is set to a format that is used to describe the media capabilities of a UA, such as SDP (application/sdp). The response to an OPTIONS request is assumed to be scoped to the Request-URI in the original request. However, only when an OPTIONS is sent as part of an established dialog is it guaranteed that future requests will be received by the server that generated the OPTIONS response. Example OPTIONS request: OPTIONS sip:carol@chicago.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 Max-Forwards: 70 To: <sip:carol@chicago.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:alice@pc33.atlanta.com> Accept: application/sdp Content-Length: 0 Rosenberg, et. al. Standards Track [Page 67] RFC 3261 SIP: Session Initiation Protocol June 2002 11.2 Processing of OPTIONS Request The response to an OPTIONS is constructed using the standard rules for a SIP response as discussed in Section 8.2.6. The response code chosen MUST be the same that would have been chosen had the request been an INVITE. That is, a 200 (OK) would be returned if the UAS is ready to accept a call, a 486 (Busy Here) would be returned if the UAS is busy, etc. This allows an OPTIONS request to be used to determine the basic state of a UAS, which can be an indication of whether the UAS will accept an INVITE request. An OPTIONS request received within a dialog generates a 200 (OK) response that is identical to one constructed outside a dialog and does not have any impact on the dialog. This use of OPTIONS has limitations due to the differences in proxy handling of OPTIONS and INVITE requests. While a forked INVITE can result in multiple 200 (OK) responses being returned, a forked OPTIONS will only result in a single 200 (OK) response, since it is treated by proxies using the non-INVITE handling. See Section 16.7 for the normative details. If the response to an OPTIONS is generated by a proxy server, the proxy returns a 200 (OK), listing the capabilities of the server. The response does not contain a message body. Allow, Accept, Accept-Encoding, Accept-Language, and Supported header fields SHOULD be present in a 200 (OK) response to an OPTIONS request. If the response is generated by a proxy, the Allow header field SHOULD be omitted as it is ambiguous since a proxy is method agnostic. Contact header fields MAY be present in a 200 (OK) response and have the same semantics as in a 3xx response. That is, they may list a set of alternative names and methods of reaching the user. A Warning header field MAY be present. A message body MAY be sent, the type of which is determined by the Accept header field in the OPTIONS request (application/sdp is the default if the Accept header field is not present). If the types include one that can describe media capabilities, the UAS SHOULD include a body in the response for that purpose. Details on the construction of such a body in the case of application/sdp are described in [13]. Rosenberg, et. al. Standards Track [Page 68] RFC 3261 SIP: Session Initiation Protocol June 2002 Example OPTIONS response generated by a UAS (corresponding to the request in Section 11.1): SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKhjhs8ass877 ;received=192.0.2.4 To: <sip:carol@chicago.com>;tag=93810874 From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 63104 OPTIONS Contact: <sip:carol@chicago.com> Contact: <mailto:carol@chicago.com> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE Accept: application/sdp Accept-Encoding: gzip Accept-Language: en Supported: foo Content-Type: application/sdp Content-Length: 274 (SDP not shown) 12 Dialogs A key concept for a user agent is that of a dialog. A dialog represents a peer-to-peer SIP relationship between two user agents that persists for some time. The dialog facilitates sequencing of messages between the user agents and proper routing of requests between both of them. The dialog represents a context in which to interpret SIP messages. Section 8 discussed method independent UA processing for requests and responses outside of a dialog. This section discusses how those requests and responses are used to construct a dialog, and then how subsequent requests and responses are sent within a dialog. A dialog is identified at each UA with a dialog ID, which consists of a Call-ID value, a local tag and a remote tag. The dialog ID at each UA involved in the dialog is not the same. Specifically, the local tag at one UA is identical to the remote tag at the peer UA. The tags are opaque tokens that facilitate the generation of unique dialog IDs. A dialog ID is also associated with all responses and with any request that contains a tag in the To field. The rules for computing the dialog ID of a message depend on whether the SIP element is a UAC or UAS. For a UAC, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the To field of the message, and the local tag is set to the tag in the From Rosenberg, et. al. Standards Track [Page 69] RFC 3261 SIP: Session Initiation Protocol June 2002 field of the message (these rules apply to both requests and responses). As one would expect for a UAS, the Call-ID value of the dialog ID is set to the Call-ID of the message, the remote tag is set to the tag in the From field of the message, and the local tag is set to the tag in the To field of the message. A dialog contains certain pieces of state needed for further message transmissions within the dialog. This state consists of the dialog ID, a local sequence number (used to order requests from the UA to its peer), a remote sequence number (used to order requests from its peer to the UA), a local URI, a remote URI, remote target, a boolean flag called ""secure"", and a route set, which is an ordered list of URIs. The route set is the list of servers that need to be traversed to send a request to the peer. A dialog can also be in the ""early"" state, which occurs when it is created with a provisional response, and then transition to the ""confirmed"" state when a 2xx final response arrives. For other responses, or if no response arrives at all on that dialog, the early dialog terminates. 12.1 Creation of a Dialog Dialogs are created through the generation of non-failure responses to requests with specific methods. Within this specification, only 2xx and 101-199 responses with a To tag, where the request was INVITE, will establish a dialog. A dialog established by a non-final response to a request is in the ""early"" state and it is called an early dialog. Extensions MAY define other means for creating dialogs. Section 13 gives more details that are specific to the INVITE method. Here, we describe the process for creation of dialog state that is not dependent on the method. UAs MUST assign values to the dialog ID components as described below. 12.1.1 UAS behavior When a UAS responds to a request with a response that establishes a dialog (such as a 2xx to INVITE), the UAS MUST copy all Record-Route header field values from the request into the response (including the URIs, URI parameters, and any Record-Route header field parameters, whether they are known or unknown to the UAS) and MUST maintain the order of those values. The UAS MUST add a Contact header field to the response. The Contact header field contains an address where the UAS would like to be contacted for subsequent requests in the dialog (which includes the ACK for a 2xx response in the case of an INVITE). Generally, the host portion of this URI is the IP address or FQDN of the host. The URI provided in the Contact header field MUST be a SIP or SIPS URI. If the request that initiated the dialog contained a Rosenberg, et. al. Standards Track [Page 70] RFC 3261 SIP: Session Initiation Protocol June 2002 SIPS URI in the Request-URI or in the top Record-Route header field value, if there was any, or the Contact header field if there was no Record-Route header field, the Contact header field in the response MUST be a SIPS URI. The URI SHOULD have global scope (that is, the same URI can be used in messages outside this dialog). The same way, the scope of the URI in the Contact header field of the INVITE is not limited to this dialog either. It can therefore be used in messages to the UAC even outside this dialog. The UAS then constructs the state of the dialog. This state MUST be maintained for the duration of the dialog. If the request arrived over TLS, and the Request-URI contained a SIPS URI, the ""secure"" flag is set to TRUE. The route set MUST be set to the list of URIs in the Record-Route header field from the request, taken in order and preserving all URI parameters. If no Record-Route header field is present in the request, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the request. The remote sequence number MUST be set to the value of the sequence number in the CSeq header field of the request. The local sequence number MUST be empty. The call identifier component of the dialog ID MUST be set to the value of the Call-ID in the request. The local tag component of the dialog ID MUST be set to the tag in the To field in the response to the request (which always includes a tag), and the remote tag component of the dialog ID MUST be set to the tag from the From field in the request. A UAS MUST be prepared to receive a request without a tag in the From field, in which case the tag is considered to have a value of null. This is to maintain backwards compatibility with RFC 2543, which did not mandate From tags. The remote URI MUST be set to the URI in the From field, and the local URI MUST be set to the URI in the To field. 12.1.2 UAC Behavior When a UAC sends a request that can establish a dialog (such as an INVITE) it MUST provide a SIP or SIPS URI with global scope (i.e., the same SIP URI can be used in messages outside this dialog) in the Contact header field of the request. If the request has a Request- URI or a topmost Route header field value with a SIPS URI, the Contact header field MUST contain a SIPS URI. Rosenberg, et. al. Standards Track [Page 71] RFC 3261 SIP: Session Initiation Protocol June 2002 When a UAC receives a response that establishes a dialog, it constructs the state of the dialog. This state MUST be maintained for the duration of the dialog. If the request was sent over TLS, and the Request-URI contained a SIPS URI, the ""secure"" flag is set to TRUE. The route set MUST be set to the list of URIs in the Record-Route header field from the response, taken in reverse order and preserving all URI parameters. If no Record-Route header field is present in the response, the route set MUST be set to the empty set. This route set, even if empty, overrides any pre-existing route set for future requests in this dialog. The remote target MUST be set to the URI from the Contact header field of the response. The local sequence number MUST be set to the value of the sequence number in the CSeq header field of the request. The remote sequence number MUST be empty (it is established when the remote UA sends a request within the dialog). The call identifier component of the dialog ID MUST be set to the value of the Call-ID in the request. The local tag component of the dialog ID MUST be set to the tag in the From field in the request, and the remote tag component of the dialog ID MUST be set to the tag in the To field of the response. A UAC MUST be prepared to receive a response without a tag in the To field, in which case the tag is considered to have a value of null. This is to maintain backwards compatibility with RFC 2543, which did not mandate To tags. The remote URI MUST be set to the URI in the To field, and the local URI MUST be set to the URI in the From field. 12.2 Requests within a Dialog Once a dialog has been established between two UAs, either of them MAY initiate new transactions as needed within the dialog. The UA sending the request will take the UAC role for the transaction. The UA receiving the request will take the UAS role. Note that these may be different roles than the UAs held during the transaction that established the dialog. Requests within a dialog MAY contain Record-Route and Contact header fields. However, these requests do not cause the dialog's route set to be modified, although they may modify the remote target URI. Specifically, requests that are not target refresh requests do not modify the dialog's remote target URI, and requests that are target refresh requests do. For dialogs that have been established with an Rosenberg, et. al. Standards Track [Page 72] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITE, the only target refresh request defined is re-INVITE (see Section 14). Other extensions may define different target refresh requests for dialogs established in other ways. Note that an ACK is NOT a target refresh request. Target refresh requests only update the dialog's remote target URI, and not the route set formed from the Record-Route. Updating the latter would introduce severe backwards compatibility problems with RFC 2543-compliant systems. 12.2.1 UAC Behavior 12.2.1.1 Generating the Request A request within a dialog is constructed by using many of the components of the state stored as part of the dialog. The URI in the To field of the request MUST be set to the remote URI from the dialog state. The tag in the To header field of the request MUST be set to the remote tag of the dialog ID. The From URI of the request MUST be set to the local URI from the dialog state. The tag in the From header field of the request MUST be set to the local tag of the dialog ID. If the value of the remote or local tags is null, the tag parameter MUST be omitted from the To or From header fields, respectively. Usage of the URI from the To and From fields in the original request within subsequent requests is done for backwards compatibility with RFC 2543, which used the URI for dialog identification. In this specification, only the tags are used for dialog identification. It is expected that mandatory reflection of the original To and From URI in mid-dialog requests will be deprecated in a subsequent revision of this specification. The Call-ID of the request MUST be set to the Call-ID of the dialog. Requests within a dialog MUST contain strictly monotonically increasing and contiguous CSeq sequence numbers (increasing-by-one) in each direction (excepting ACK and CANCEL of course, whose numbers equal the requests being acknowledged or cancelled)."
"Therefore, if the local sequence number is not empty, the value of the local sequence number MUST be incremented by one, and this value MUST be placed into the CSeq header field. If the local sequence number is empty, an initial value MUST be chosen using the guidelines of Section 8.1.1.5. The method field in the CSeq header field value MUST match the method of the request. Rosenberg, et. al. Standards Track [Page 73] RFC 3261 SIP: Session Initiation Protocol June 2002 With a length of 32 bits, a client could generate, within a single call, one request a second for about 136 years before needing to wrap around. The initial value of the sequence number is chosen so that subsequent requests within the same call will not wrap around. A non-zero initial value allows clients to use a time- based initial sequence number. A client could, for example, choose the 31 most significant bits of a 32-bit second clock as an initial sequence number. The UAC uses the remote target and route set to build the Request-URI and Route header field of the request. If the route set is empty, the UAC MUST place the remote target URI into the Request-URI. The UAC MUST NOT add a Route header field to the request. If the route set is not empty, and the first URI in the route set contains the lr parameter (see Section 19.1.1), the UAC MUST place the remote target URI into the Request-URI and MUST include a Route header field containing the route set values in order, including all parameters. If the route set is not empty, and its first URI does not contain the lr parameter, the UAC MUST place the first URI from the route set into the Request-URI, stripping any parameters that are not allowed in a Request-URI. The UAC MUST add a Route header field containing the remainder of the route set values in order, including all parameters. The UAC MUST then place the remote target URI into the Route header field as the last value. For example, if the remote target is sip:user@remoteua and the route set contains: <sip:proxy1>,<sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4> The request will be formed with the following Request-URI and Route header field: METHOD sip:proxy1 Route: <sip:proxy2>,<sip:proxy3;lr>,<sip:proxy4>,<sip:user@remoteua> If the first URI of the route set does not contain the lr parameter, the proxy indicated does not understand the routing mechanisms described in this document and will act as specified in RFC 2543, replacing the Request-URI with the first Route header field value it receives while forwarding the message. Placing the Request-URI at the end of the Route header field preserves the Rosenberg, et. al. Standards Track [Page 74] RFC 3261 SIP: Session Initiation Protocol June 2002 information in that Request-URI across the strict router (it will be returned to the Request-URI when the request reaches a loose- router). A UAC SHOULD include a Contact header field in any target refresh requests within a dialog, and unless there is a need to change it, the URI SHOULD be the same as used in previous requests within the dialog. If the ""secure"" flag is true, that URI MUST be a SIPS URI. As discussed in Section 12.2.2, a Contact header field in a target refresh request updates the remote target URI. This allows a UA to provide a new contact address, should its address change during the duration of the dialog. However, requests that are not target refresh requests do not affect the remote target URI for the dialog. The rest of the request is formed as described in Section 8.1.1. Once the request has been constructed, the address of the server is computed and the request is sent, using the same procedures for requests outside of a dialog (Section 8.1.2). The procedures in Section 8.1.2 will normally result in the request being sent to the address indicated by the topmost Route header field value or the Request-URI if no Route header field is present. Subject to certain restrictions, they allow the request to be sent to an alternate address (such as a default outbound proxy not represented in the route set). 12.2.1.2 Processing the Responses The UAC will receive responses to the request from the transaction layer. If the client transaction returns a timeout, this is treated as a 408 (Request Timeout) response. The behavior of a UAC that receives a 3xx response for a request sent within a dialog is the same as if the request had been sent outside a dialog. This behavior is described in Section 8.1.3.4. Note, however, that when the UAC tries alternative locations, it still uses the route set for the dialog to build the Route header of the request. When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present. Rosenberg, et. al. Standards Track [Page 75] RFC 3261 SIP: Session Initiation Protocol June 2002 If the response for a request within a dialog is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout), the UAC SHOULD terminate the dialog. A UAC SHOULD also terminate a dialog if no response at all is received for the request (the client transaction would inform the TU about the timeout.) For INVITE initiated dialogs, terminating the dialog consists of sending a BYE. 12.2.2 UAS Behavior Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed. Note that some requests, such as INVITEs, affect several pieces of state. The UAS will receive the request from the transaction layer. If the request has a tag in the To header field, the UAS core computes the dialog identifier corresponding to the request and compares it with existing dialogs. If there is a match, this is a mid-dialog request. In that case, the UAS first applies the same processing rules for requests outside of a dialog, discussed in Section 8.2. If the request has a tag in the To header field, but the dialog identifier does not match any existing dialogs, the UAS may have crashed and restarted, or it may have received a request for a different (possibly failed) UAS (the UASs can construct the To tags so that a UAS can identify that the tag was for a UAS for which it is providing recovery). Another possibility is that the incoming request has been simply misrouted. Based on the To tag, the UAS MAY either accept or reject the request. Accepting the request for acceptable To tags provides robustness, so that dialogs can persist even through crashes. UAs wishing to support this capability must take into consideration some issues such as choosing monotonically increasing CSeq sequence numbers even across reboots, reconstructing the route set, and accepting out-of-range RTP timestamps and sequence numbers. If the UAS wishes to reject the request because it does not wish to recreate the dialog, it MUST respond to the request with a 481 (Call/Transaction Does Not Exist) status code and pass that to the server transaction. Rosenberg, et. al. Standards Track [Page 76] RFC 3261 SIP: Session Initiation Protocol June 2002 Requests that do not change in any way the state of a dialog may be received within a dialog (for example, an OPTIONS request). They are processed as if they had been received outside the dialog. If the remote sequence number is empty, it MUST be set to the value of the sequence number in the CSeq header field value in the request. If the remote sequence number was not empty, but the sequence number of the request is lower than the remote sequence number, the request is out of order and MUST be rejected with a 500 (Server Internal Error) response. If the remote sequence number was not empty, and the sequence number of the request is greater than the remote sequence number, the request is in order. It is possible for the CSeq sequence number to be higher than the remote sequence number by more than one. This is not an error condition, and a UAS SHOULD be prepared to receive and process requests with CSeq values more than one higher than the previous received request. The UAS MUST then set the remote sequence number to the value of the sequence number in the CSeq header field value in the request. If a proxy challenges a request generated by the UAC, the UAC has to resubmit the request with credentials. The resubmitted request will have a new CSeq number. The UAS will never see the first request, and thus, it will notice a gap in the CSeq number space. Such a gap does not represent any error condition. When a UAS receives a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that request, if present. 12.3 Termination of a Dialog Independent of the method, if a request outside of a dialog generates a non-2xx final response, any early dialogs created through provisional responses to that request are terminated. The mechanism for terminating confirmed dialogs is method specific. In this specification, the BYE method terminates a session and the dialog associated with it. See Section 15 for details. 13 Initiating a Session 13.1 Overview When a user agent client desires to initiate a session (for example, audio, video, or a game), it formulates an INVITE request. The INVITE request asks a server to establish a session. This request may be forwarded by proxies, eventually arriving at one or more UAS that can potentially accept the invitation. These UASs will frequently need to query the user about whether to accept the Rosenberg, et. al. Standards Track [Page 77] RFC 3261 SIP: Session Initiation Protocol June 2002 invitation. After some time, those UASs can accept the invitation (meaning the session is to be established) by sending a 2xx response. If the invitation is not accepted, a 3xx, 4xx, 5xx or 6xx response is sent, depending on the reason for the rejection. Before sending a final response, the UAS can also send provisional responses (1xx) to advise the UAC of progress in contacting the called user. After possibly receiving one or more provisional responses, the UAC will get one or more 2xx responses or one non-2xx final response. Because of the protracted amount of time it can take to receive final responses to INVITE, the reliability mechanisms for INVITE transactions differ from those of other requests (like OPTIONS). Once it receives a final response, the UAC needs to send an ACK for every final response it receives. The procedure for sending this ACK depends on the type of response. For final responses between 300 and 699, the ACK processing is done in the transaction layer and follows one set of rules (See Section 17). For 2xx responses, the ACK is generated by the UAC core. A 2xx response to an INVITE establishes a session, and it also creates a dialog between the UA that issued the INVITE and the UA that generated the 2xx response. Therefore, when multiple 2xx responses are received from different remote UAs (because the INVITE forked), each 2xx establishes a different dialog. All these dialogs are part of the same call. This section provides details on the establishment of a session using INVITE. A UA that supports INVITE MUST also support ACK, CANCEL and BYE. 13.2 UAC Processing 13.2.1 Creating the Initial INVITE Since the initial INVITE represents a request outside of a dialog, its construction follows the procedures of Section 8.1.1. Additional processing is required for the specific case of INVITE. An Allow header field (Section 20.5) SHOULD be present in the INVITE. It indicates what methods can be invoked within a dialog, on the UA sending the INVITE, for the duration of the dialog. For example, a UA capable of receiving INFO requests within a dialog [34] SHOULD include an Allow header field listing the INFO method. A Supported header field (Section 20.37) SHOULD be present in the INVITE. It enumerates all the extensions understood by the UAC. Rosenberg, et. al. Standards Track [Page 78] RFC 3261 SIP: Session Initiation Protocol June 2002 An Accept (Section 20.1) header field MAY be present in the INVITE. It indicates which Content-Types are acceptable to the UA, in both the response received by it, and in any subsequent requests sent to it within dialogs established by the INVITE. The Accept header field is especially useful for indicating support of various session description formats. The UAC MAY add an Expires header field (Section 20.19) to limit the validity of the invitation. If the time indicated in the Expires header field is reached and no final answer for the INVITE has been received, the UAC core SHOULD generate a CANCEL request for the INVITE, as per Section 9. A UAC MAY also find it useful to add, among others, Subject (Section 20.36), Organization (Section 20.25) and User-Agent (Section 20.41) header fields. They all contain information related to the INVITE. The UAC MAY choose to add a message body to the INVITE. Section 8.1.1.10 deals with how to construct the header fields -- Content- Type among others -- needed to describe the message body. There are special rules for message bodies that contain a session description - their corresponding Content-Disposition is ""session"". SIP uses an offer/answer model where one UA sends a session description, called the offer, which contains a proposed description of the session. The offer indicates the desired communications means (audio, video, games), parameters of those means (such as codec types) and addresses for receiving media from the answerer. The other UA responds with another session description, called the answer, which indicates which communications means are accepted, the parameters that apply to those means, and addresses for receiving media from the offerer. An offer/answer exchange is within the context of a dialog, so that if a SIP INVITE results in multiple dialogs, each is a separate offer/answer exchange. The offer/answer model defines restrictions on when offers and answers can be made (for example, you cannot make a new offer while one is in progress). This results in restrictions on where the offers and answers can appear in SIP messages. In this specification, offers and answers can only appear in INVITE requests and responses, and ACK. The usage of offers and answers is further restricted. For the initial INVITE transaction, the rules are: o The initial offer MUST be in either an INVITE or, if not there, in the first reliable non-failure message from the UAS back to the UAC. In this specification, that is the final 2xx response. Rosenberg, et. al. Standards Track [Page 79] RFC 3261 SIP: Session Initiation Protocol June 2002 o If the initial offer is in an INVITE, the answer MUST be in a reliable non-failure message from UAS back to UAC which is correlated to that INVITE. For this specification, that is only the final 2xx response to that INVITE. That same exact answer MAY also be placed in any provisional responses sent prior to the answer. The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. o If the initial offer is in the first reliable non-failure message from the UAS back to UAC, the answer MUST be in the acknowledgement for that message (in this specification, ACK for a 2xx response). o After having sent or received an answer to the first offer, the UAC MAY generate subsequent offers in requests based on rules specified for that method, but only if it has received answers to any previous offers, and has not sent any offers to which it hasn't gotten an answer. o Once the UAS has sent or received an answer to the initial offer, it MUST NOT generate subsequent offers in any responses to the initial INVITE. This means that a UAS based on this specification alone can never generate subsequent offers until completion of the initial transaction. Concretely, the above rules specify two exchanges for UAs compliant to this specification alone - the offer is in the INVITE, and the answer in the 2xx (and possibly in a 1xx as well, with the same value), or the offer is in the 2xx, and the answer is in the ACK. All user agents that support INVITE MUST support these two exchanges. The Session Description Protocol (SDP) (RFC 2327 [1]) MUST be supported by all user agents as a means to describe sessions, and its usage for constructing offers and answers MUST follow the procedures defined in [13]. The restrictions of the offer-answer model just described only apply to bodies whose Content-Disposition header field value is ""session"". Therefore, it is possible that both the INVITE and the ACK contain a body message (for example, the INVITE carries a photo (Content- Disposition: render) and the ACK a session description (Content- Disposition: session)). If the Content-Disposition header field is missing, bodies of Content-Type application/sdp imply the disposition ""session"", while other content types imply ""render"". Rosenberg, et. al. Standards Track [Page 80] RFC 3261 SIP: Session Initiation Protocol June 2002 Once the INVITE has been created, the UAC follows the procedures defined for sending requests outside of a dialog (Section 8). This results in the construction of a client transaction that will ultimately send the request and deliver responses to the UAC. 13.2.2 Processing INVITE Responses Once the INVITE has been passed to the INVITE client transaction, the UAC waits for responses for the INVITE. If the INVITE client transaction returns a timeout rather than a response the TU acts as if a 408 (Request Timeout) response had been received, as described in Section 8.1.3. 13.2.2.1 1xx Responses Zero, one or multiple provisional responses may arrive before one or more final responses are received. Provisional responses for an INVITE request can create ""early dialogs"". If a provisional response has a tag in the To field, and if the dialog ID of the response does not match an existing dialog, one is constructed using the procedures defined in Section 12.1.2. The early dialog will only be needed if the UAC needs to send a request to its peer within the dialog before the initial INVITE transaction completes. Header fields present in a provisional response are applicable as long as the dialog is in the early state (for example, an Allow header field in a provisional response contains the methods that can be used in the dialog while this is in the early state). 13.2.2.2 3xx Responses A 3xx response may contain one or more Contact header field values providing new addresses where the callee might be reachable. Depending on the status code of the 3xx response (see Section 21.3), the UAC MAY choose to try those new addresses. 13.2.2.3 4xx, 5xx and 6xx Responses A single non-2xx final response may be received for the INVITE. 4xx, 5xx and 6xx responses may contain a Contact header field value indicating the location where additional information about the error can be found. Subsequent final responses (which would only arrive under error conditions) MUST be ignored. All early dialogs are considered terminated upon reception of the non-2xx final response. Rosenberg, et. al. Standards Track [Page 81] RFC 3261 SIP: Session Initiation Protocol June 2002 After having received the non-2xx final response the UAC core considers the INVITE transaction completed. The INVITE client transaction handles the generation of ACKs for the response (see Section 17). 13.2.2.4 2xx Responses Multiple 2xx responses may arrive at the UAC for a single INVITE request due to a forking proxy. Each response is distinguished by the tag parameter in the To header field, and each represents a distinct dialog, with a distinct dialog identifier. If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the ""confirmed"" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the ""confirmed"" state MUST be constructed using the procedures of Section 12.1.2. Note that the only piece of state that is recomputed is the route set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example. The UAC core MUST generate an ACK request for each 2xx received from the transaction layer. The header fields of the ACK are constructed in the same way as for any request sent within a dialog (see Section 12) with the exception of the CSeq and the header fields related to authentication. The sequence number of the CSeq header field MUST be the same as the INVITE being acknowledged, but the CSeq method MUST be ACK. The ACK MUST contain the same credentials as the INVITE. If the 2xx contains an offer (based on the rules above), the ACK MUST carry an answer in its body. If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately. Once the ACK has been constructed, the procedures of [4] are used to determine the destination address, port and transport. However, the request is passed to the transport layer directly for transmission, rather than a client transaction. This is because the UAC core handles retransmissions of the ACK, not the transaction layer. The ACK MUST be passed to the client transport every time a retransmission of the 2xx final response that triggered the ACK arrives. Rosenberg, et. al. Standards Track [Page 82] RFC 3261 SIP: Session Initiation Protocol June 2002 The UAC core considers the INVITE transaction completed 64*T1 seconds after the reception of the first 2xx response. At this point all the early dialogs that have not transitioned to established dialogs are terminated. Once the INVITE transaction is considered completed by the UAC core, no more new 2xx responses are expected to arrive. If, after acknowledging any 2xx response to an INVITE, the UAC does not want to continue with that dialog, then the UAC MUST terminate the dialog by sending a BYE request as described in Section 15. 13.3 UAS Processing 13.3.1 Processing of the INVITE The UAS core will receive INVITE requests from the transaction layer. It first performs the request processing procedures of Section 8.2, which are applied for both requests inside and outside of a dialog. Assuming these processing states are completed without generating a response, the UAS core performs the additional processing steps: 1. If the request is an INVITE that contains an Expires header field, the UAS core sets a timer for the number of seconds indicated in the header field value. When the timer fires, the invitation is considered to be expired. If the invitation expires before the UAS has generated a final response, a 487 (Request Terminated) response SHOULD be generated. 2. If the request is a mid-dialog request, the method-independent processing described in Section 12.2.2 is first applied. It might also modify the session; Section 14 provides details. 3. If the request has a tag in the To header field but the dialog identifier does not match any of the existing dialogs, the UAS may have crashed and restarted, or may have received a request for a different (possibly failed) UAS. Section 12.2.2 provides guidelines to achieve a robust behavior under such a situation. Processing from here forward assumes that the INVITE is outside of a dialog, and is thus for the purposes of establishing a new session. The INVITE may contain a session description, in which case the UAS is being presented with an offer for that session. It is possible that the user is already a participant in that session, even though the INVITE is outside of a dialog. This can happen when a user is invited to the same multicast conference by multiple other participants. If desired, the UAS MAY use identifiers within the session description to detect this duplication. For example, SDP Rosenberg, et. al. Standards Track [Page 83] RFC 3261 SIP: Session Initiation Protocol June 2002 contains a session id and version number in the origin (o) field. If the user is already a member of the session, and the session parameters contained in the session description have not changed, the UAS MAY silently accept the INVITE (that is, send a 2xx response without prompting the user). If the INVITE does not contain a session description, the UAS is being asked to participate in a session, and the UAC has asked that the UAS provide the offer of the session. It MUST provide the offer in its first non-failure reliable message back to the UAC. In this specification, that is a 2xx response to the INVITE. The UAS can indicate progress, accept, redirect, or reject the invitation. In all of these cases, it formulates a response using the procedures described in Section 8.2.6. 13.3.1.1 Progress If the UAS is not able to answer the invitation immediately, it can choose to indicate some kind of progress to the UAC (for example, an indication that a phone is ringing). This is accomplished with a provisional response between 101 and 199. These provisional responses establish early dialogs and therefore follow the procedures of Section 12.1.1 in addition to those of Section 8.2.6. A UAS MAY send as many provisional responses as it likes. Each of these MUST indicate the same dialog ID. However, these will not be delivered reliably. If the UAS desires an extended period of time to answer the INVITE, it will need to ask for an ""extension"" in order to prevent proxies from canceling the transaction. A proxy has the option of canceling a transaction when there is a gap of 3 minutes between responses in a transaction. To prevent cancellation, the UAS MUST send a non-100 provisional response at every minute, to handle the possibility of lost provisional responses. An INVITE transaction can go on for extended durations when the user is placed on hold, or when interworking with PSTN systems which allow communications to take place without answering the call. The latter is common in Interactive Voice Response (IVR) systems. 13.3.1.2 The INVITE is Redirected If the UAS decides to redirect the call, a 3xx response is sent. A 300 (Multiple Choices), 301 (Moved Permanently) or 302 (Moved Temporarily) response SHOULD contain a Contact header field Rosenberg, et. al. Standards Track [Page 84] RFC 3261 SIP: Session Initiation Protocol June 2002 containing one or more URIs of new addresses to be tried. The response is passed to the INVITE server transaction, which will deal with its retransmissions. 13.3.1.3 The INVITE is Rejected A common scenario occurs when the callee is currently not willing or able to take additional calls at this end system. A 486 (Busy Here) SHOULD be returned in such a scenario. If the UAS knows that no other end system will be able to accept this call, a 600 (Busy Everywhere) response SHOULD be sent instead. However, it is unlikely that a UAS will be able to know this in general, and thus this response will not usually be used. The response is passed to the INVITE server transaction, which will deal with its retransmissions. A UAS rejecting an offer contained in an INVITE SHOULD return a 488 (Not Acceptable Here) response. Such a response SHOULD include a Warning header field value explaining why the offer was rejected. 13.3.1.4 The INVITE is Accepted The UAS core generates a 2xx response. This response establishes a dialog, and therefore follows the procedures of Section 12.1.1 in addition to those of Section 8.2.6. A 2xx response to an INVITE SHOULD contain the Allow header field and the Supported header field, and MAY contain the Accept header field. Including these header fields allows the UAC to determine the features and extensions supported by the UAS for the duration of the call, without probing. If the INVITE request contained an offer, and the UAS had not yet sent an answer, the 2xx MUST contain an answer. If the INVITE did not contain an offer, the 2xx MUST contain an offer if the UAS had not yet sent an offer. Once the response has been constructed, it is passed to the INVITE server transaction. Note, however, that the INVITE server transaction will be destroyed as soon as it receives this final response and passes it to the transport. Therefore, it is necessary to periodically pass the response directly to the transport until the ACK arrives. The 2xx response is passed to the transport with an interval that starts at T1 seconds and doubles for each retransmission until it reaches T2 seconds (T1 and T2 are defined in Section 17). Response retransmissions cease when an ACK request for the response is received. This is independent of whatever transport protocols are used to send the response. Rosenberg, et. al. Standards Track [Page 85] RFC 3261 SIP: Session Initiation Protocol June 2002 Since 2xx is retransmitted end-to-end, there may be hops between UAS and UAC that are UDP. To ensure reliable delivery across these hops, the response is retransmitted periodically even if the transport at the UAS is reliable. If the server retransmits the 2xx response for 64*T1 seconds without receiving an ACK, the dialog is confirmed, but the session SHOULD be terminated. This is accomplished with a BYE, as described in Section 15. 14 Modifying an Existing Session A successful INVITE request (see Section 13) establishes both a dialog between two user agents and a session using the offer-answer model. Section 12 explains how to modify an existing dialog using a target refresh request (for example, changing the remote target URI of the dialog). This section describes how to modify the actual session. This modification can involve changing addresses or ports, adding a media stream, deleting a media stream, and so on. This is accomplished by sending a new INVITE request within the same dialog that established the session. An INVITE request sent within an existing dialog is known as a re-INVITE. Note that a single re-INVITE can modify the dialog and the parameters of the session at the same time. Either the caller or callee can modify an existing session. The behavior of a UA on detection of media failure is a matter of local policy. However, automated generation of re-INVITE or BYE is NOT RECOMMENDED to avoid flooding the network with traffic when there is congestion. In any case, if these messages are sent automatically, they SHOULD be sent after some randomized interval. Note that the paragraph above refers to automatically generated BYEs and re-INVITEs. If the user hangs up upon media failure, the UA would send a BYE request as usual. 14.1 UAC Behavior The same offer-answer model that applies to session descriptions in INVITEs (Section 13.2.1) applies to re-INVITEs. As a result, a UAC that wants to add a media stream, for example, will create a new offer that contains this media stream, and send that in an INVITE request to its peer. It is important to note that the full description of the session, not just the change, is sent. This supports stateless session processing in various elements, and supports failover and recovery capabilities. Of course, a UAC MAY Rosenberg, et. al. Standards Track [Page 86] RFC 3261 SIP: Session Initiation Protocol June 2002 send a re-INVITE with no session description, in which case the first reliable non-failure response to the re-INVITE will contain the offer (in this specification, that is a 2xx response). If the session description format has the capability for version numbers, the offerer SHOULD indicate that the version of the session description has changed. The To, From, Call-ID, CSeq, and Request-URI of a re-INVITE are set following the same rules as for regular requests within an existing dialog, described in Section 12. A UAC MAY choose not to add an Alert-Info header field or a body with Content-Disposition ""alert"" to re-INVITEs because UASs do not typically alert the user upon reception of a re-INVITE. Unlike an INVITE, which can fork, a re-INVITE will never fork, and therefore, only ever generate a single final response. The reason a re-INVITE will never fork is that the Request-URI identifies the target as the UA instance it established the dialog with, rather than identifying an address-of-record for the user. Note that a UAC MUST NOT initiate a new INVITE transaction within a dialog while another INVITE transaction is in progress in either direction. 1. If there is an ongoing INVITE client transaction, the TU MUST wait until the transaction reaches the completed or terminated state before initiating the new INVITE. 2. If there is an ongoing INVITE server transaction, the TU MUST wait until the transaction reaches the confirmed or terminated state before initiating the new INVITE. However, a UA MAY initiate a regular transaction while an INVITE transaction is in progress. A UA MAY also initiate an INVITE transaction while a regular transaction is in progress. If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued. Note that, as stated in Section 12.2.1.2, if the non-2xx final response is a 481 (Call/Transaction Does Not Exist), or a 408 (Request Timeout), or no response at all is received for the re- INVITE (that is, a timeout is returned by the INVITE client transaction), the UAC will terminate the dialog. Rosenberg, et. al. Standards Track [Page 87] RFC 3261 SIP: Session Initiation Protocol June 2002 If a UAC receives a 491 response to a re-INVITE, it SHOULD start a timer with a value T chosen as follows: 1. If the UAC is the owner of the Call-ID of the dialog ID (meaning it generated the value), T has a randomly chosen value between 2.1 and 4 seconds in units of 10 ms. 2. If the UAC is not the owner of the Call-ID of the dialog ID, T has a randomly chosen value of between 0 and 2 seconds in units of 10 ms. When the timer fires, the UAC SHOULD attempt the re-INVITE once more, if it still desires for that session modification to take place. For example, if the call was already hung up with a BYE, the re-INVITE would not take place. The rules for transmitting a re-INVITE and for generating an ACK for a 2xx response to re-INVITE are the same as for the initial INVITE (Section 13.2.1). 14.2 UAS Behavior Section 13.3.1 describes the procedure for distinguishing incoming re-INVITEs from incoming initial INVITEs and handling a re-INVITE for an existing dialog. A UAS that receives a second INVITE before it sends the final response to a first INVITE with a lower CSeq sequence number on the same dialog MUST return a 500 (Server Internal Error) response to the second INVITE and MUST include a Retry-After header field with a randomly chosen value of between 0 and 10 seconds. A UAS that receives an INVITE on a dialog while an INVITE it had sent on that dialog is in progress MUST return a 491 (Request Pending) response to the received INVITE. If a UA receives a re-INVITE for an existing dialog, it MUST check any version identifiers in the session description or, if there are no version identifiers, the content of the session description to see if it has changed. If the session description has changed, the UAS MUST adjust the session parameters accordingly, possibly after asking the user for confirmation. Versioning of the session description can be used to accommodate the capabilities of new arrivals to a conference, add or delete media, or change from a unicast to a multicast conference. Rosenberg, et. al. Standards Track [Page 88] RFC 3261 SIP: Session Initiation Protocol June 2002 If the new session description is not acceptable, the UAS can reject it by returning a 488 (Not Acceptable Here) response for the re- INVITE. This response SHOULD include a Warning header field. If a UAS generates a 2xx response and never receives an ACK, it SHOULD generate a BYE to terminate the dialog. A UAS MAY choose not to generate 180 (Ringing) responses for a re- INVITE because UACs do not typically render this information to the user."
"For the same reason, UASs MAY choose not to use an Alert-Info header field or a body with Content-Disposition ""alert"" in responses to a re-INVITE. A UAS providing an offer in a 2xx (because the INVITE did not contain an offer) SHOULD construct the offer as if the UAS were making a brand new call, subject to the constraints of sending an offer that updates an existing session, as described in [13] in the case of SDP. Specifically, this means that it SHOULD include as many media formats and media types that the UA is willing to support. The UAS MUST ensure that the session description overlaps with its previous session description in media formats, transports, or other parameters that require support from the peer. This is to avoid the need for the peer to reject the session description. If, however, it is unacceptable to the UAC, the UAC SHOULD generate an answer with a valid session description, and then send a BYE to terminate the session. 15 Terminating a Session This section describes the procedures for terminating a session established by SIP. The state of the session and the state of the dialog are very closely related. When a session is initiated with an INVITE, each 1xx or 2xx response from a distinct UAS creates a dialog, and if that response completes the offer/answer exchange, it also creates a session. As a result, each session is ""associated"" with a single dialog - the one which resulted in its creation. If an initial INVITE generates a non-2xx final response, that terminates all sessions (if any) and all dialogs (if any) that were created through responses to the request. By virtue of completing the transaction, a non-2xx final response also prevents further sessions from being created as a result of the INVITE. The BYE request is used to terminate a specific session or attempted session. In this case, the specific session is the one with the peer UA on the other side of the dialog. When a BYE is received on a dialog, any session associated with that dialog SHOULD terminate. A UA MUST NOT send a BYE outside of a dialog. The caller's UA MAY send a BYE for either confirmed or early dialogs, and the callee's UA MAY send a BYE on confirmed dialogs, but MUST NOT send a BYE on early dialogs. Rosenberg, et. al. Standards Track [Page 89] RFC 3261 SIP: Session Initiation Protocol June 2002 However, the callee's UA MUST NOT send a BYE on a confirmed dialog until it has received an ACK for its 2xx response or until the server transaction times out. If no SIP extensions have defined other application layer states associated with the dialog, the BYE also terminates the dialog. The impact of a non-2xx final response to INVITE on dialogs and sessions makes the use of CANCEL attractive. The CANCEL attempts to force a non-2xx response to the INVITE (in particular, a 487). Therefore, if a UAC wishes to give up on its call attempt entirely, it can send a CANCEL. If the INVITE results in 2xx final response(s) to the INVITE, this means that a UAS accepted the invitation while the CANCEL was in progress. The UAC MAY continue with the sessions established by any 2xx responses, or MAY terminate them with BYE. The notion of ""hanging up"" is not well defined within SIP. It is specific to a particular, albeit common, user interface. Typically, when the user hangs up, it indicates a desire to terminate the attempt to establish a session, and to terminate any sessions already created. For the caller's UA, this would imply a CANCEL request if the initial INVITE has not generated a final response, and a BYE to all confirmed dialogs after a final response. For the callee's UA, it would typically imply a BYE; presumably, when the user picked up the phone, a 2xx was generated, and so hanging up would result in a BYE after the ACK is received. This does not mean a user cannot hang up before receipt of the ACK, it just means that the software in his phone needs to maintain state for a short while in order to clean up properly. If the particular UI allows for the user to reject a call before its answered, a 403 (Forbidden) is a good way to express that. As per the rules above, a BYE can't be sent. 15.1 Terminating a Session with a BYE Request 15.1.1 UAC Behavior A BYE request is constructed as would any other request within a dialog, as described in Section 12. Once the BYE is constructed, the UAC core creates a new non-INVITE client transaction, and passes it the BYE request. The UAC MUST consider the session terminated (and therefore stop sending or listening for media) as soon as the BYE request is passed to the client transaction. If the response for the BYE is a 481 (Call/Transaction Does Not Exist) or a 408 (Request Timeout) or no Rosenberg, et. al. Standards Track [Page 90] RFC 3261 SIP: Session Initiation Protocol June 2002 response at all is received for the BYE (that is, a timeout is returned by the client transaction), the UAC MUST consider the session and the dialog terminated. 15.1.2 UAS Behavior A UAS first processes the BYE request according to the general UAS processing described in Section 8.2. A UAS core receiving a BYE request checks if it matches an existing dialog. If the BYE does not match an existing dialog, the UAS core SHOULD generate a 481 (Call/Transaction Does Not Exist) response and pass that to the server transaction. This rule means that a BYE sent without tags by a UAC will be rejected. This is a change from RFC 2543, which allowed BYE without tags. A UAS core receiving a BYE request for an existing dialog MUST follow the procedures of Section 12.2.2 to process the request. Once done, the UAS SHOULD terminate the session (and therefore stop sending and listening for media). The only case where it can elect not to are multicast sessions, where participation is possible even if the other participant in the dialog has terminated its involvement in the session. Whether or not it ends its participation on the session, the UAS core MUST generate a 2xx response to the BYE, and MUST pass that to the server transaction for transmission. The UAS MUST still respond to any pending requests received for that dialog. It is RECOMMENDED that a 487 (Request Terminated) response be generated to those pending requests. 16 Proxy Behavior 16.1 Overview SIP proxies are elements that route SIP requests to user agent servers and SIP responses to user agent clients. A request may traverse several proxies on its way to a UAS. Each will make routing decisions, modifying the request before forwarding it to the next element. Responses will route through the same set of proxies traversed by the request in the reverse order. Being a proxy is a logical role for a SIP element. When a request arrives, an element that can play the role of a proxy first decides if it needs to respond to the request on its own. For instance, the request may be malformed or the element may need credentials from the client before acting as a proxy. The element MAY respond with any Rosenberg, et. al. Standards Track [Page 91] RFC 3261 SIP: Session Initiation Protocol June 2002 appropriate error code. When responding directly to a request, the element is playing the role of a UAS and MUST behave as described in Section 8.2. A proxy can operate in either a stateful or stateless mode for each new request. When stateless, a proxy acts as a simple forwarding element. It forwards each request downstream to a single element determined by making a targeting and routing decision based on the request. It simply forwards every response it receives upstream. A stateless proxy discards information about a message once the message has been forwarded. A stateful proxy remembers information (specifically, transaction state) about each incoming request and any requests it sends as a result of processing the incoming request. It uses this information to affect the processing of future messages associated with that request. A stateful proxy MAY choose to ""fork"" a request, routing it to multiple destinations. Any request that is forwarded to more than one location MUST be handled statefully. In some circumstances, a proxy MAY forward requests using stateful transports (such as TCP) without being transaction-stateful. For instance, a proxy MAY forward a request from one TCP connection to another transaction statelessly as long as it places enough information in the message to be able to forward the response down the same connection the request arrived on. Requests forwarded between different types of transports where the proxy's TU must take an active role in ensuring reliable delivery on one of the transports MUST be forwarded transaction statefully. A stateful proxy MAY transition to stateless operation at any time during the processing of a request, so long as it did not do anything that would otherwise prevent it from being stateless initially (forking, for example, or generation of a 100 response). When performing such a transition, all state is simply discarded. The proxy SHOULD NOT initiate a CANCEL request. Much of the processing involved when acting statelessly or statefully for a request is identical. The next several subsections are written from the point of view of a stateful proxy. The last section calls out those places where a stateless proxy behaves differently. 16.2 Stateful Proxy When stateful, a proxy is purely a SIP transaction processing engine. Its behavior is modeled here in terms of the server and client transactions defined in Section 17. A stateful proxy has a server transaction associated with one or more client transactions by a higher layer proxy processing component (see figure 3), known as a proxy core. An incoming request is processed by a server Rosenberg, et. al. Standards Track [Page 92] RFC 3261 SIP: Session Initiation Protocol June 2002 transaction. Requests from the server transaction are passed to a proxy core. The proxy core determines where to route the request, choosing one or more next-hop locations. An outgoing request for each next-hop location is processed by its own associated client transaction. The proxy core collects the responses from the client transactions and uses them to send responses to the server transaction. A stateful proxy creates a new server transaction for each new request received. Any retransmissions of the request will then be handled by that server transaction per Section 17. The proxy core MUST behave as a UAS with respect to sending an immediate provisional on that server transaction (such as 100 Trying) as described in Section 8.2.6. Thus, a stateful proxy SHOULD NOT generate 100 (Trying) responses to non-INVITE requests. This is a model of proxy behavior, not of software. An implementation is free to take any approach that replicates the external behavior this model defines. For all new requests, including any with unknown methods, an element intending to proxy the request MUST: 1. Validate the request (Section 16.3) 2. Preprocess routing information (Section 16.4) 3. Determine target(s) for the request (Section 16.5) +--------------------+ | | +---+ | | | C | | | | T | | | +---+ +---+ | Proxy | +---+ CT = Client Transaction | S | | ""Higher"" Layer | | C | | T | | | | T | ST = Server Transaction +---+ | | +---+ | | +---+ | | | C | | | | T | | | +---+ +--------------------+ Figure 3: Stateful Proxy Model Rosenberg, et. al. Standards Track [Page 93] RFC 3261 SIP: Session Initiation Protocol June 2002 4. Forward the request to each target (Section 16.6) 5. Process all responses (Section 16.7) 16.3 Request Validation Before an element can proxy a request, it MUST verify the message's validity. A valid message must pass the following checks: 1. Reasonable Syntax 2. URI scheme 3. Max-Forwards 4. (Optional) Loop Detection 5. Proxy-Require 6. Proxy-Authorization If any of these checks fail, the element MUST behave as a user agent server (see Section 8.2) and respond with an error code. Notice that a proxy is not required to detect merged requests and MUST NOT treat merged requests as an error condition. The endpoints receiving the requests will resolve the merge as described in Section 8.2.2.2. 1. Reasonable syntax check The request MUST be well-formed enough to be handled with a server transaction. Any components involved in the remainder of these Request Validation steps or the Request Forwarding section MUST be well-formed. Any other components, well-formed or not, SHOULD be ignored and remain unchanged when the message is forwarded. For instance, an element would not reject a request because of a malformed Date header field. Likewise, a proxy would not remove a malformed Date header field before forwarding a request. This protocol is designed to be extended. Future extensions may define new methods and header fields at any time. An element MUST NOT refuse to proxy a request because it contains a method or header field it does not know about. Rosenberg, et. al. Standards Track [Page 94] RFC 3261 SIP: Session Initiation Protocol June 2002 2. URI scheme check If the Request-URI has a URI whose scheme is not understood by the proxy, the proxy SHOULD reject the request with a 416 (Unsupported URI Scheme) response. 3. Max-Forwards check The Max-Forwards header field (Section 20.22) is used to limit the number of elements a SIP request can traverse. If the request does not contain a Max-Forwards header field, this check is passed. If the request contains a Max-Forwards header field with a field value greater than zero, the check is passed. If the request contains a Max-Forwards header field with a field value of zero (0), the element MUST NOT forward the request. If the request was for OPTIONS, the element MAY act as the final recipient and respond per Section 11. Otherwise, the element MUST return a 483 (Too many hops) response. 4. Optional Loop Detection check An element MAY check for forwarding loops before forwarding a request. If the request contains a Via header field with a sent- by value that equals a value placed into previous requests by the proxy, the request has been forwarded by this element before. The request has either looped or is legitimately spiraling through the element. To determine if the request has looped, the element MAY perform the branch parameter calculation described in Step 8 of Section 16.6 on this message and compare it to the parameter received in that Via header field. If the parameters match, the request has looped. If they differ, the request is spiraling, and processing continues. If a loop is detected, the element MAY return a 482 (Loop Detected) response. 5. Proxy-Require check Future extensions to this protocol may introduce features that require special handling by proxies. Endpoints will include a Proxy-Require header field in requests that use these features, telling the proxy not to process the request unless the feature is understood. Rosenberg, et. al. Standards Track [Page 95] RFC 3261 SIP: Session Initiation Protocol June 2002 If the request contains a Proxy-Require header field (Section 20.29) with one or more option-tags this element does not understand, the element MUST return a 420 (Bad Extension) response. The response MUST include an Unsupported (Section 20.40) header field listing those option-tags the element did not understand. 6. Proxy-Authorization check If an element requires credentials before forwarding a request, the request MUST be inspected as described in Section 22.3. That section also defines what the element must do if the inspection fails. 16.4 Route Information Preprocessing The proxy MUST inspect the Request-URI of the request. If the Request-URI of the request contains a value this proxy previously placed into a Record-Route header field (see Section 16.6 item 4), the proxy MUST replace the Request-URI in the request with the last value from the Route header field, and remove that value from the Route header field. The proxy MUST then proceed as if it received this modified request. This will only happen when the element sending the request to the proxy (which may have been an endpoint) is a strict router. This rewrite on receive is necessary to enable backwards compatibility with those elements. It also allows elements following this specification to preserve the Request-URI through strict-routing proxies (see Section 12.2.1.1). This requirement does not obligate a proxy to keep state in order to detect URIs it previously placed in Record-Route header fields. Instead, a proxy need only place enough information in those URIs to recognize them as values it provided when they later appear. If the Request-URI contains a maddr parameter, the proxy MUST check to see if its value is in the set of addresses or domains the proxy is configured to be responsible for. If the Request-URI has a maddr parameter with a value the proxy is responsible for, and the request was received using the port and transport indicated (explicitly or by default) in the Request-URI, the proxy MUST strip the maddr and any non-default port or transport parameter and continue processing as if those values had not been present in the request. Rosenberg, et. al. Standards Track [Page 96] RFC 3261 SIP: Session Initiation Protocol June 2002 A request may arrive with a maddr matching the proxy, but on a port or transport different from that indicated in the URI. Such a request needs to be forwarded to the proxy using the indicated port and transport. If the first value in the Route header field indicates this proxy, the proxy MUST remove that value from the request. 16.5 Determining Request Targets Next, the proxy calculates the target(s) of the request. The set of targets will either be predetermined by the contents of the request or will be obtained from an abstract location service. Each target in the set is represented as a URI. If the Request-URI of the request contains an maddr parameter, the Request-URI MUST be placed into the target set as the only target URI, and the proxy MUST proceed to Section 16.6. If the domain of the Request-URI indicates a domain this element is not responsible for, the Request-URI MUST be placed into the target set as the only target, and the element MUST proceed to the task of Request Forwarding (Section 16.6). There are many circumstances in which a proxy might receive a request for a domain it is not responsible for. A firewall proxy handling outgoing calls (the way HTTP proxies handle outgoing requests) is an example of where this is likely to occur. If the target set for the request has not been predetermined as described above, this implies that the element is responsible for the domain in the Request-URI, and the element MAY use whatever mechanism it desires to determine where to send the request. Any of these mechanisms can be modeled as accessing an abstract Location Service. This may consist of obtaining information from a location service created by a SIP Registrar, reading a database, consulting a presence server, utilizing other protocols, or simply performing an algorithmic substitution on the Request-URI. When accessing the location service constructed by a registrar, the Request-URI MUST first be canonicalized as described in Section 10.3 before being used as an index. The output of these mechanisms is used to construct the target set. If the Request-URI does not provide sufficient information for the proxy to determine the target set, it SHOULD return a 485 (Ambiguous) response. This response SHOULD contain a Contact header field containing URIs of new addresses to be tried. For example, an INVITE Rosenberg, et. al. Standards Track [Page 97] RFC 3261 SIP: Session Initiation Protocol June 2002 to sip:John.Smith@company.com may be ambiguous at a proxy whose location service has multiple John Smiths listed. See Section 21.4.23 for details. Any information in or about the request or the current environment of the element MAY be used in the construction of the target set. For instance, different sets may be constructed depending on contents or the presence of header fields and bodies, the time of day of the request's arrival, the interface on which the request arrived, failure of previous requests, or even the element's current level of utilization. As potential targets are located through these services, their URIs are added to the target set. Targets can only be placed in the target set once. If a target URI is already present in the set (based on the definition of equality for the URI type), it MUST NOT be added again. A proxy MUST NOT add additional targets to the target set if the Request-URI of the original request does not indicate a resource this proxy is responsible for. A proxy can only change the Request-URI of a request during forwarding if it is responsible for that URI. If the proxy is not responsible for that URI, it will not recurse on 3xx or 416 responses as described below. If the Request-URI of the original request indicates a resource this proxy is responsible for, the proxy MAY continue to add targets to the set after beginning Request Forwarding. It MAY use any information obtained during that processing to determine new targets. For instance, a proxy may choose to incorporate contacts obtained in a redirect response (3xx) into the target set. If a proxy uses a dynamic source of information while building the target set (for instance, if it consults a SIP Registrar), it SHOULD monitor that source for the duration of processing the request. New locations SHOULD be added to the target set as they become available. As above, any given URI MUST NOT be added to the set more than once. Allowing a URI to be added to the set only once reduces unnecessary network traffic, and in the case of incorporating contacts from redirect requests prevents infinite recursion. For example, a trivial location service is a ""no-op"", where the target URI is equal to the incoming request URI. The request is sent to a specific next hop proxy for further processing. During request Rosenberg, et. al. Standards Track [Page 98] RFC 3261 SIP: Session Initiation Protocol June 2002 forwarding of Section 16.6, Item 6, the identity of that next hop, expressed as a SIP or SIPS URI, is inserted as the top-most Route header field value into the request. If the Request-URI indicates a resource at this proxy that does not exist, the proxy MUST return a 404 (Not Found) response. If the target set remains empty after applying all of the above, the proxy MUST return an error response, which SHOULD be the 480 (Temporarily Unavailable) response. 16.6 Request Forwarding As soon as the target set is non-empty, a proxy MAY begin forwarding the request. A stateful proxy MAY process the set in any order. It MAY process multiple targets serially, allowing each client transaction to complete before starting the next. It MAY start client transactions with every target in parallel. It also MAY arbitrarily divide the set into groups, processing the groups serially and processing the targets in each group in parallel. A common ordering mechanism is to use the qvalue parameter of targets obtained from Contact header fields (see Section 20.10). Targets are processed from highest qvalue to lowest. Targets with equal qvalues may be processed in parallel. A stateful proxy must have a mechanism to maintain the target set as responses are received and associate the responses to each forwarded request with the original request. For the purposes of this model, this mechanism is a ""response context"" created by the proxy layer before forwarding the first request. For each target, the proxy forwards the request following these steps: 1. Make a copy of the received request 2. Update the Request-URI 3. Update the Max-Forwards header field 4. Optionally add a Record-route header field value 5. Optionally add additional header fields 6. Postprocess routing information 7. Determine the next-hop address, port, and transport Rosenberg, et. al. Standards Track [Page 99] RFC 3261 SIP: Session Initiation Protocol June 2002 8. Add a Via header field value 9. Add a Content-Length header field if necessary 10. Forward the new request 11. Set timer C Each of these steps is detailed below: 1. Copy request The proxy starts with a copy of the received request. The copy MUST initially contain all of the header fields from the received request. Fields not detailed in the processing described below MUST NOT be removed. The copy SHOULD maintain the ordering of the header fields as in the received request. The proxy MUST NOT reorder field values with a common field name (See Section 7.3.1). The proxy MUST NOT add to, modify, or remove the message body. An actual implementation need not perform a copy; the primary requirement is that the processing for each next hop begin with the same request. 2. Request-URI The Request-URI in the copy's start line MUST be replaced with the URI for this target. If the URI contains any parameters not allowed in a Request-URI, they MUST be removed. This is the essence of a proxy's role. This is the mechanism through which a proxy routes a request toward its destination. In some circumstances, the received Request-URI is placed into the target set without being modified. For that target, the replacement above is effectively a no-op. 3. Max-Forwards If the copy contains a Max-Forwards header field, the proxy MUST decrement its value by one (1). If the copy does not contain a Max-Forwards header field, the proxy MUST add one with a field value, which SHOULD be 70. Some existing UAs will not provide a Max-Forwards header field in a request. Rosenberg, et. al. Standards Track [Page 100] RFC 3261 SIP: Session Initiation Protocol June 2002 4. Record-Route If this proxy wishes to remain on the path of future requests in a dialog created by this request (assuming the request creates a dialog), it MUST insert a Record-Route header field value into the copy before any existing Record-Route header field values, even if a Route header field is already present. Requests establishing a dialog may contain a preloaded Route header field. If this request is already part of a dialog, the proxy SHOULD insert a Record-Route header field value if it wishes to remain on the path of future requests in the dialog. In normal endpoint operation as described in Section 12, these Record- Route header field values will not have any effect on the route sets used by the endpoints. The proxy will remain on the path if it chooses to not insert a Record-Route header field value into requests that are already part of a dialog. However, it would be removed from the path when an endpoint that has failed reconstitutes the dialog. A proxy MAY insert a Record-Route header field value into any request. If the request does not initiate a dialog, the endpoints will ignore the value. See Section 12 for details on how endpoints use the Record-Route header field values to construct Route header fields. Each proxy in the path of a request chooses whether to add a Record-Route header field value independently - the presence of a Record-Route header field in a request does not obligate this proxy to add a value. The URI placed in the Record-Route header field value MUST be a SIP or SIPS URI. This URI MUST contain an lr parameter (see Section 19.1.1). This URI MAY be different for each destination the request is forwarded to. The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge (such as in a private network) that the next downstream element that will be in the path of subsequent requests supports that transport. The URI this proxy provides will be used by some other element to make a routing decision. This proxy, in general, has no way of knowing the capabilities of that element, so it must restrict itself to the mandatory elements of a SIP implementation: SIP URIs and either the TCP or UDP transports. Rosenberg, et. al. Standards Track [Page 101] RFC 3261 SIP: Session Initiation Protocol June 2002 The URI placed in the Record-Route header field MUST resolve to the element inserting it (or a suitable stand-in) when the server location procedures of [4] are applied to it, so that subsequent requests reach the same SIP element. If the Request-URI contains a SIPS URI, or the topmost Route header field value (after the post processing of bullet 6) contains a SIPS URI, the URI placed into the Record-Route header field MUST be a SIPS URI. Furthermore, if the request was not received over TLS, the proxy MUST insert a Record-Route header field. In a similar fashion, a proxy that receives a request over TLS, but generates a request without a SIPS URI in the Request-URI or topmost Route header field value (after the post processing of bullet 6), MUST insert a Record-Route header field that is not a SIPS URI. A proxy at a security perimeter must remain on the perimeter throughout the dialog. If the URI placed in the Record-Route header field needs to be rewritten when it passes back through in a response, the URI MUST be distinct enough to locate at that time. (The request may spiral through this proxy, resulting in more than one Record-Route header field value being added). Item 8 of Section 16.7 recommends a mechanism to make the URI sufficiently distinct. The proxy MAY include parameters in the Record-Route header field value. These will be echoed in some responses to the request such as the 200 (OK) responses to INVITE. Such parameters may be useful for keeping state in the message rather than the proxy. If a proxy needs to be in the path of any type of dialog (such as one straddling a firewall), it SHOULD add a Record-Route header field value to every request with a method it does not understand since that method may have dialog semantics. The URI a proxy places into a Record-Route header field is only valid for the lifetime of any dialog created by the transaction in which it occurs. A dialog-stateful proxy, for example, MAY refuse to accept future requests with that value in the Request-URI after the dialog has terminated. Non-dialog- stateful proxies, of course, have no concept of when the dialog has terminated, but they MAY encode enough information in the value to compare it against the dialog identifier of future requests and MAY reject requests not matching that information. Endpoints MUST NOT use a URI obtained from a Record-Route header field outside the dialog in which it was provided. See Rosenberg, et. al. Standards Track [Page 102] RFC 3261 SIP: Session Initiation Protocol June 2002 Section 12 for more information on an endpoint's use of Record-Route header fields. Record-routing may be required by certain services where the proxy needs to observe all messages in a dialog. However, it slows down processing and impairs scalability and thus proxies should only record-route if required for a particular service. The Record-Route process is designed to work for any SIP request that initiates a dialog. INVITE is the only such request in this specification, but extensions to the protocol MAY define others. 5. Add Additional Header Fields The proxy MAY add any other appropriate header fields to the copy at this point. 6. Postprocess routing information A proxy MAY have a local policy that mandates that a request visit a specific set of proxies before being delivered to the destination. A proxy MUST ensure that all such proxies are loose routers. Generally, this can only be known with certainty if the proxies are within the same administrative domain. This set of proxies is represented by a set of URIs (each of which contains the lr parameter). This set MUST be pushed into the Route header field of the copy ahead of any existing values, if present. If the Route header field is absent, it MUST be added, containing that list of URIs. If the proxy has a local policy that mandates that the request visit one specific proxy, an alternative to pushing a Route value into the Route header field is to bypass the forwarding logic of item 10 below, and instead just send the request to the address, port, and transport for that specific proxy. If the request has a Route header field, this alternative MUST NOT be used unless it is known that next hop proxy is a loose router. Otherwise, this approach MAY be used, but the Route insertion mechanism above is preferred for its robustness, flexibility, generality and consistency of operation. Furthermore, if the Request-URI contains a SIPS URI, TLS MUST be used to communicate with that proxy. If the copy contains a Route header field, the proxy MUST inspect the URI in its first value. If that URI does not contain an lr parameter, the proxy MUST modify the copy as follows: Rosenberg, et. al. Standards Track [Page 103] RFC 3261 SIP: Session Initiation Protocol June 2002 - The proxy MUST place the Request-URI into the Route header field as the last value. - The proxy MUST then place the first Route header field value into the Request-URI and remove that value from the Route header field. Appending the Request-URI to the Route header field is part of a mechanism used to pass the information in that Request-URI through strict-routing elements. ""Popping"" the first Route header field value into the Request-URI formats the message the way a strict-routing element expects to receive it (with its own URI in the Request-URI and the next location to visit in the first Route header field value). 7. Determine Next-Hop Address, Port, and Transport The proxy MAY have a local policy to send the request to a specific IP address, port, and transport, independent of the values of the Route and Request-URI. Such a policy MUST NOT be used if the proxy is not certain that the IP address, port, and transport correspond to a server that is a loose router. However, this mechanism for sending the request through a specific next hop is NOT RECOMMENDED; instead a Route header field should be used for that purpose as described above. In the absence of such an overriding mechanism, the proxy applies the procedures listed in [4] as follows to determine where to send the request. If the proxy has reformatted the request to send to a strict-routing element as described in step 6 above, the proxy MUST apply those procedures to the Request-URI of the request. Otherwise, the proxy MUST apply the procedures to the first value in the Route header field, if present, else the Request-URI. The procedures will produce an ordered set of (address, port, transport) tuples. Independently of which URI is being used as input to the procedures of [4], if the Request-URI specifies a SIPS resource, the proxy MUST follow the procedures of [4] as if the input URI were a SIPS URI. As described in [4], the proxy MUST attempt to deliver the message to the first tuple in that set, and proceed through the set in order until the delivery attempt succeeds. For each tuple attempted, the proxy MUST format the message as appropriate for the tuple and send the request using a new client transaction as detailed in steps 8 through 10. Rosenberg, et. al. Standards Track [Page 104] RFC 3261 SIP: Session Initiation Protocol June 2002 Since each attempt uses a new client transaction, it represents a new branch. Thus, the branch parameter provided with the Via header field inserted in step 8 MUST be different for each attempt. If the client transaction reports failure to send the request or a timeout from its state machine, the proxy continues to the next address in that ordered set. If the ordered set is exhausted, the request cannot be forwarded to this element in the target set. The proxy does not need to place anything in the response context, but otherwise acts as if this element of the target set returned a 408 (Request Timeout) final response. 8. Add a Via header field value The proxy MUST insert a Via header field value into the copy before the existing Via header field values. The construction of this value follows the same guidelines of Section 8.1.1.7. This implies that the proxy will compute its own branch parameter, which will be globally unique for that branch, and contain the requisite magic cookie. Note that this implies that the branch parameter will be different for different instances of a spiraled or looped request through a proxy. Proxies choosing to detect loops have an additional constraint in the value they use for construction of the branch parameter."
"A proxy choosing to detect loops SHOULD create a branch parameter separable into two parts by the implementation. The first part MUST satisfy the constraints of Section 8.1.1.7 as described above. The second is used to perform loop detection and distinguish loops from spirals. Loop detection is performed by verifying that, when a request returns to a proxy, those fields having an impact on the processing of the request have not changed. The value placed in this part of the branch parameter SHOULD reflect all of those fields (including any Route, Proxy-Require and Proxy- Authorization header fields). This is to ensure that if the request is routed back to the proxy and one of those fields changes, it is treated as a spiral and not a loop (see Section 16.3). A common way to create this value is to compute a cryptographic hash of the To tag, From tag, Call-ID header field, the Request-URI of the request received (before translation), the topmost Via header, and the sequence number from the CSeq header field, in addition to any Proxy-Require and Proxy-Authorization header fields that may be present. The Rosenberg, et. al. Standards Track [Page 105] RFC 3261 SIP: Session Initiation Protocol June 2002 algorithm used to compute the hash is implementation-dependent, but MD5 (RFC 1321 [35]), expressed in hexadecimal, is a reasonable choice. (Base64 is not permissible for a token.) If a proxy wishes to detect loops, the ""branch"" parameter it supplies MUST depend on all information affecting processing of a request, including the incoming Request-URI and any header fields affecting the request's admission or routing. This is necessary to distinguish looped requests from requests whose routing parameters have changed before returning to this server. The request method MUST NOT be included in the calculation of the branch parameter. In particular, CANCEL and ACK requests (for non-2xx responses) MUST have the same branch value as the corresponding request they cancel or acknowledge. The branch parameter is used in correlating those requests at the server handling them (see Sections 17.2.3 and 9.2). 9. Add a Content-Length header field if necessary If the request will be sent to the next hop using a stream- based transport and the copy contains no Content-Length header field, the proxy MUST insert one with the correct value for the body of the request (see Section 20.14). 10. Forward Request A stateful proxy MUST create a new client transaction for this request as described in Section 17.1 and instructs the transaction to send the request using the address, port and transport determined in step 7. 11. Set timer C In order to handle the case where an INVITE request never generates a final response, the TU uses a timer which is called timer C. Timer C MUST be set for each client transaction when an INVITE request is proxied. The timer MUST be larger than 3 minutes. Section 16.7 bullet 2 discusses how this timer is updated with provisional responses, and Section 16.8 discusses processing when it fires. Rosenberg, et. al. Standards Track [Page 106] RFC 3261 SIP: Session Initiation Protocol June 2002 16.7 Response Processing When a response is received by an element, it first tries to locate a client transaction (Section 17.1.3) matching the response. If none is found, the element MUST process the response (even if it is an informational response) as a stateless proxy (described below). If a match is found, the response is handed to the client transaction. Forwarding responses for which a client transaction (or more generally any knowledge of having sent an associated request) is not found improves robustness. In particular, it ensures that ""late"" 2xx responses to INVITE requests are forwarded properly. As client transactions pass responses to the proxy layer, the following processing MUST take place: 1. Find the appropriate response context 2. Update timer C for provisional responses 3. Remove the topmost Via 4. Add the response to the response context 5. Check to see if this response should be forwarded immediately 6. When necessary, choose the best final response from the response context If no final response has been forwarded after every client transaction associated with the response context has been terminated, the proxy must choose and forward the ""best"" response from those it has seen so far. The following processing MUST be performed on each response that is forwarded. It is likely that more than one response to each request will be forwarded: at least each provisional and one final response. 7. Aggregate authorization header field values if necessary 8. Optionally rewrite Record-Route header field values 9. Forward the response 10. Generate any necessary CANCEL requests Rosenberg, et. al. Standards Track [Page 107] RFC 3261 SIP: Session Initiation Protocol June 2002 Each of the above steps are detailed below: 1. Find Context The proxy locates the ""response context"" it created before forwarding the original request using the key described in Section 16.6. The remaining processing steps take place in this context. 2. Update timer C for provisional responses For an INVITE transaction, if the response is a provisional response with status codes 101 to 199 inclusive (i.e., anything but 100), the proxy MUST reset timer C for that client transaction. The timer MAY be reset to a different value, but this value MUST be greater than 3 minutes. 3. Via The proxy removes the topmost Via header field value from the response. If no Via header field values remain in the response, the response was meant for this element and MUST NOT be forwarded. The remainder of the processing described in this section is not performed on this message, the UAC processing rules described in Section 8.1.3 are followed instead (transport layer processing has already occurred). This will happen, for instance, when the element generates CANCEL requests as described in Section 10. 4. Add response to context Final responses received are stored in the response context until a final response is generated on the server transaction associated with this context. The response may be a candidate for the best final response to be returned on that server transaction. Information from this response may be needed in forming the best response, even if this response is not chosen. If the proxy chooses to recurse on any contacts in a 3xx response by adding them to the target set, it MUST remove them from the response before adding the response to the response context. However, a proxy SHOULD NOT recurse to a non-SIPS URI if the Request-URI of the original request was a SIPS URI. If Rosenberg, et. al. Standards Track [Page 108] RFC 3261 SIP: Session Initiation Protocol June 2002 the proxy recurses on all of the contacts in a 3xx response, the proxy SHOULD NOT add the resulting contactless response to the response context. Removing the contact before adding the response to the response context prevents the next element upstream from retrying a location this proxy has already attempted. 3xx responses may contain a mixture of SIP, SIPS, and non-SIP URIs. A proxy may choose to recurse on the SIP and SIPS URIs and place the remainder into the response context to be returned, potentially in the final response. If a proxy receives a 416 (Unsupported URI Scheme) response to a request whose Request-URI scheme was not SIP, but the scheme in the original received request was SIP or SIPS (that is, the proxy changed the scheme from SIP or SIPS to something else when it proxied a request), the proxy SHOULD add a new URI to the target set. This URI SHOULD be a SIP URI version of the non-SIP URI that was just tried. In the case of the tel URL, this is accomplished by placing the telephone-subscriber part of the tel URL into the user part of the SIP URI, and setting the hostpart to the domain where the prior request was sent. See Section 19.1.6 for more detail on forming SIP URIs from tel URLs. As with a 3xx response, if a proxy ""recurses"" on the 416 by trying a SIP or SIPS URI instead, the 416 response SHOULD NOT be added to the response context. 5. Check response for forwarding Until a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any provisional response other than 100 (Trying) - Any 2xx response If a 6xx response is received, it is not immediately forwarded, but the stateful proxy SHOULD cancel all client pending transactions as described in Section 10, and it MUST NOT create any new branches in this context. This is a change from RFC 2543, which mandated that the proxy was to forward the 6xx response immediately. For an INVITE transaction, this approach had the problem that a 2xx response could arrive on another branch, in which case the proxy would Rosenberg, et. al. Standards Track [Page 109] RFC 3261 SIP: Session Initiation Protocol June 2002 have to forward the 2xx. The result was that the UAC could receive a 6xx response followed by a 2xx response, which should never be allowed to happen. Under the new rules, upon receiving a 6xx, a proxy will issue a CANCEL request, which will generally result in 487 responses from all outstanding client transactions, and then at that point the 6xx is forwarded upstream. After a final response has been sent on the server transaction, the following responses MUST be forwarded immediately: - Any 2xx response to an INVITE request A stateful proxy MUST NOT immediately forward any other responses. In particular, a stateful proxy MUST NOT forward any 100 (Trying) response. Those responses that are candidates for forwarding later as the ""best"" response have been gathered as described in step ""Add Response to Context"". Any response chosen for immediate forwarding MUST be processed as described in steps ""Aggregate Authorization Header Field Values"" through ""Record-Route"". This step, combined with the next, ensures that a stateful proxy will forward exactly one final response to a non-INVITE request, and either exactly one non-2xx response or one or more 2xx responses to an INVITE request. 6. Choosing the best response A stateful proxy MUST send a final response to a response context's server transaction if no final responses have been immediately forwarded by the above rules and all client transactions in this response context have been terminated. The stateful proxy MUST choose the ""best"" final response among those received and stored in the response context. If there are no final responses in the context, the proxy MUST send a 408 (Request Timeout) response to the server transaction. Otherwise, the proxy MUST forward a response from the responses stored in the response context. It MUST choose from the 6xx class responses if any exist in the context. If no 6xx class responses are present, the proxy SHOULD choose from the lowest response class stored in the response context. The proxy MAY select any response within that chosen class. The proxy SHOULD Rosenberg, et. al. Standards Track [Page 110] RFC 3261 SIP: Session Initiation Protocol June 2002 give preference to responses that provide information affecting resubmission of this request, such as 401, 407, 415, 420, and 484 if the 4xx class is chosen. A proxy which receives a 503 (Service Unavailable) response SHOULD NOT forward it upstream unless it can determine that any subsequent requests it might proxy will also generate a 503. In other words, forwarding a 503 means that the proxy knows it cannot service any requests, not just the one for the Request- URI in the request which generated the 503. If the only response that was received is a 503, the proxy SHOULD generate a 500 response and forward that upstream. The forwarded response MUST be processed as described in steps ""Aggregate Authorization Header Field Values"" through ""Record- Route"". For example, if a proxy forwarded a request to 4 locations, and received 503, 407, 501, and 404 responses, it may choose to forward the 407 (Proxy Authentication Required) response. 1xx and 2xx responses may be involved in the establishment of dialogs. When a request does not contain a To tag, the To tag in the response is used by the UAC to distinguish multiple responses to a dialog creating request. A proxy MUST NOT insert a tag into the To header field of a 1xx or 2xx response if the request did not contain one. A proxy MUST NOT modify the tag in the To header field of a 1xx or 2xx response. Since a proxy may not insert a tag into the To header field of a 1xx response to a request that did not contain one, it cannot issue non-100 provisional responses on its own. However, it can branch the request to a UAS sharing the same element as the proxy. This UAS can return its own provisional responses, entering into an early dialog with the initiator of the request. The UAS does not have to be a discreet process from the proxy. It could be a virtual UAS implemented in the same code space as the proxy. 3-6xx responses are delivered hop-by-hop. When issuing a 3-6xx response, the element is effectively acting as a UAS, issuing its own response, usually based on the responses received from downstream elements. An element SHOULD preserve the To tag when simply forwarding a 3-6xx response to a request that did not contain a To tag. A proxy MUST NOT modify the To tag in any forwarded response to a request that contains a To tag. Rosenberg, et. al. Standards Track [Page 111] RFC 3261 SIP: Session Initiation Protocol June 2002 While it makes no difference to the upstream elements if the proxy replaced the To tag in a forwarded 3-6xx response, preserving the original tag may assist with debugging. When the proxy is aggregating information from several responses, choosing a To tag from among them is arbitrary, and generating a new To tag may make debugging easier. This happens, for instance, when combining 401 (Unauthorized) and 407 (Proxy Authentication Required) challenges, or combining Contact values from unencrypted and unauthenticated 3xx responses. 7. Aggregate Authorization Header Field Values If the selected response is a 401 (Unauthorized) or 407 (Proxy Authentication Required), the proxy MUST collect any WWW- Authenticate and Proxy-Authenticate header field values from all other 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this response context and add them to this response without modification before forwarding. The resulting 401 (Unauthorized) or 407 (Proxy Authentication Required) response could have several WWW- Authenticate AND Proxy-Authenticate header field values. This is necessary because any or all of the destinations the request was forwarded to may have requested credentials. The client needs to receive all of those challenges and supply credentials for each of them when it retries the request. Motivation for this behavior is provided in Section 26. 8. Record-Route If the selected response contains a Record-Route header field value originally provided by this proxy, the proxy MAY choose to rewrite the value before forwarding the response. This allows the proxy to provide different URIs for itself to the next upstream and downstream elements. A proxy may choose to use this mechanism for any reason. For instance, it is useful for multi-homed hosts. If the proxy received the request over TLS, and sent it out over a non-TLS connection, the proxy MUST rewrite the URI in the Record-Route header field to be a SIPS URI. If the proxy received the request over a non-TLS connection, and sent it out over TLS, the proxy MUST rewrite the URI in the Record-Route header field to be a SIP URI. Rosenberg, et. al. Standards Track [Page 112] RFC 3261 SIP: Session Initiation Protocol June 2002 The new URI provided by the proxy MUST satisfy the same constraints on URIs placed in Record-Route header fields in requests (see Step 4 of Section 16.6) with the following modifications: The URI SHOULD NOT contain the transport parameter unless the proxy has knowledge that the next upstream (as opposed to downstream) element that will be in the path of subsequent requests supports that transport. When a proxy does decide to modify the Record-Route header field in the response, one of the operations it performs is locating the Record-Route value that it had inserted. If the request spiraled, and the proxy inserted a Record-Route value in each iteration of the spiral, locating the correct value in the response (which must be the proper iteration in the reverse direction) is tricky. The rules above recommend that a proxy wishing to rewrite Record-Route header field values insert sufficiently distinct URIs into the Record-Route header field so that the right one may be selected for rewriting. A RECOMMENDED mechanism to achieve this is for the proxy to append a unique identifier for the proxy instance to the user portion of the URI. When the response arrives, the proxy modifies the first Record-Route whose identifier matches the proxy instance. The modification results in a URI without this piece of data appended to the user portion of the URI. Upon the next iteration, the same algorithm (find the topmost Record-Route header field value with the parameter) will correctly extract the next Record-Route header field value inserted by that proxy. Not every response to a request to which a proxy adds a Record-Route header field value will contain a Record-Route header field. If the response does contain a Record-Route header field, it will contain the value the proxy added. 9. Forward response After performing the processing described in steps ""Aggregate Authorization Header Field Values"" through ""Record-Route"", the proxy MAY perform any feature specific manipulations on the selected response. The proxy MUST NOT add to, modify, or remove the message body. Unless otherwise specified, the proxy MUST NOT remove any header field values other than the Via header field value discussed in Section 16.7 Item 3. In particular, the proxy MUST NOT remove any ""received"" parameter Rosenberg, et. al. Standards Track [Page 113] RFC 3261 SIP: Session Initiation Protocol June 2002 it may have added to the next Via header field value while processing the request associated with this response. The proxy MUST pass the response to the server transaction associated with the response context. This will result in the response being sent to the location now indicated in the topmost Via header field value. If the server transaction is no longer available to handle the transmission, the element MUST forward the response statelessly by sending it to the server transport. The server transaction might indicate failure to send the response or signal a timeout in its state machine. These errors would be logged for diagnostic purposes as appropriate, but the protocol requires no remedial action from the proxy. The proxy MUST maintain the response context until all of its associated transactions have been terminated, even after forwarding a final response. 10. Generate CANCELs If the forwarded response was a final response, the proxy MUST generate a CANCEL request for all pending client transactions associated with this response context. A proxy SHOULD also generate a CANCEL request for all pending client transactions associated with this response context when it receives a 6xx response. A pending client transaction is one that has received a provisional response, but no final response (it is in the proceeding state) and has not had an associated CANCEL generated for it. Generating CANCEL requests is described in Section 9.1. The requirement to CANCEL pending client transactions upon forwarding a final response does not guarantee that an endpoint will not receive multiple 200 (OK) responses to an INVITE. 200 (OK) responses on more than one branch may be generated before the CANCEL requests can be sent and processed. Further, it is reasonable to expect that a future extension may override this requirement to issue CANCEL requests. 16.8 Processing Timer C If timer C should fire, the proxy MUST either reset the timer with any value it chooses, or terminate the client transaction. If the client transaction has received a provisional response, the proxy MUST generate a CANCEL request matching that transaction. If the client transaction has not received a provisional response, the proxy MUST behave as if the transaction received a 408 (Request Timeout) response. Rosenberg, et. al. Standards Track [Page 114] RFC 3261 SIP: Session Initiation Protocol June 2002 Allowing the proxy to reset the timer allows the proxy to dynamically extend the transaction's lifetime based on current conditions (such as utilization) when the timer fires. 16.9 Handling Transport Errors If the transport layer notifies a proxy of an error when it tries to forward a request (see Section 18.4), the proxy MUST behave as if the forwarded request received a 503 (Service Unavailable) response. If the proxy is notified of an error when forwarding a response, it drops the response. The proxy SHOULD NOT cancel any outstanding client transactions associated with this response context due to this notification. If a proxy cancels its outstanding client transactions, a single malicious or misbehaving client can cause all transactions to fail through its Via header field. 16.10 CANCEL Processing A stateful proxy MAY generate a CANCEL to any other request it has generated at any time (subject to receiving a provisional response to that request as described in section 9.1). A proxy MUST cancel any pending client transactions associated with a response context when it receives a matching CANCEL request. A stateful proxy MAY generate CANCEL requests for pending INVITE client transactions based on the period specified in the INVITE's Expires header field elapsing. However, this is generally unnecessary since the endpoints involved will take care of signaling the end of the transaction. While a CANCEL request is handled in a stateful proxy by its own server transaction, a new response context is not created for it. Instead, the proxy layer searches its existing response contexts for the server transaction handling the request associated with this CANCEL. If a matching response context is found, the element MUST immediately return a 200 (OK) response to the CANCEL request. In this case, the element is acting as a user agent server as defined in Section 8.2. Furthermore, the element MUST generate CANCEL requests for all pending client transactions in the context as described in Section 16.7 step 10. If a response context is not found, the element does not have any knowledge of the request to apply the CANCEL to. It MUST statelessly forward the CANCEL request (it may have statelessly forwarded the associated request previously). Rosenberg, et. al. Standards Track [Page 115] RFC 3261 SIP: Session Initiation Protocol June 2002 16.11 Stateless Proxy When acting statelessly, a proxy is a simple message forwarder. Much of the processing performed when acting statelessly is the same as when behaving statefully. The differences are detailed here. A stateless proxy does not have any notion of a transaction, or of the response context used to describe stateful proxy behavior. Instead, the stateless proxy takes messages, both requests and responses, directly from the transport layer (See section 18). As a result, stateless proxies do not retransmit messages on their own. They do, however, forward all retransmissions they receive (they do not have the ability to distinguish a retransmission from the original message). Furthermore, when handling a request statelessly, an element MUST NOT generate its own 100 (Trying) or any other provisional response. A stateless proxy MUST validate a request as described in Section 16.3 A stateless proxy MUST follow the request processing steps described in Sections 16.4 through 16.5 with the following exception: o A stateless proxy MUST choose one and only one target from the target set. This choice MUST only rely on fields in the message and time-invariant properties of the server. In particular, a retransmitted request MUST be forwarded to the same destination each time it is processed. Furthermore, CANCEL and non-Routed ACK requests MUST generate the same choice as their associated INVITE. A stateless proxy MUST follow the request processing steps described in Section 16.6 with the following exceptions: o The requirement for unique branch IDs across space and time applies to stateless proxies as well. However, a stateless proxy cannot simply use a random number generator to compute the first component of the branch ID, as described in Section 16.6 bullet 8. This is because retransmissions of a request need to have the same value, and a stateless proxy cannot tell a retransmission from the original request. Therefore, the component of the branch parameter that makes it unique MUST be the same each time a retransmitted request is forwarded. Thus for a stateless proxy, the branch parameter MUST be computed as a combinatoric function of message parameters which are invariant on retransmission. Rosenberg, et. al. Standards Track [Page 116] RFC 3261 SIP: Session Initiation Protocol June 2002 The stateless proxy MAY use any technique it likes to guarantee uniqueness of its branch IDs across transactions. However, the following procedure is RECOMMENDED. The proxy examines the branch ID in the topmost Via header field of the received request. If it begins with the magic cookie, the first component of the branch ID of the outgoing request is computed as a hash of the received branch ID. Otherwise, the first component of the branch ID is computed as a hash of the topmost Via, the tag in the To header field, the tag in the From header field, the Call-ID header field, the CSeq number (but not method), and the Request-URI from the received request. One of these fields will always vary across two different transactions. o All other message transformations specified in Section 16.6 MUST result in the same transformation of a retransmitted request. In particular, if the proxy inserts a Record-Route value or pushes URIs into the Route header field, it MUST place the same values in retransmissions of the request. As for the Via branch parameter, this implies that the transformations MUST be based on time-invariant configuration or retransmission-invariant properties of the request. o A stateless proxy determines where to forward the request as described for stateful proxies in Section 16.6 Item 10. The request is sent directly to the transport layer instead of through a client transaction. Since a stateless proxy must forward retransmitted requests to the same destination and add identical branch parameters to each of them, it can only use information from the message itself and time-invariant configuration data for those calculations. If the configuration state is not time-invariant (for example, if a routing table is updated) any requests that could be affected by the change may not be forwarded statelessly during an interval equal to the transaction timeout window before or after the change. The method of processing the affected requests in that interval is an implementation decision. A common solution is to forward them transaction statefully. Stateless proxies MUST NOT perform special processing for CANCEL requests. They are processed by the above rules as any other requests. In particular, a stateless proxy applies the same Route header field processing to CANCEL requests that it applies to any other request. Rosenberg, et. al. Standards Track [Page 117] RFC 3261 SIP: Session Initiation Protocol June 2002 Response processing as described in Section 16.7 does not apply to a proxy behaving statelessly. When a response arrives at a stateless proxy, the proxy MUST inspect the sent-by value in the first (topmost) Via header field value. If that address matches the proxy, (it equals a value this proxy has inserted into previous requests) the proxy MUST remove that header field value from the response and forward the result to the location indicated in the next Via header field value. The proxy MUST NOT add to, modify, or remove the message body. Unless specified otherwise, the proxy MUST NOT remove any other header field values. If the address does not match the proxy, the message MUST be silently discarded. 16.12 Summary of Proxy Route Processing In the absence of local policy to the contrary, the processing a proxy performs on a request containing a Route header field can be summarized in the following steps. 1. The proxy will inspect the Request-URI. If it indicates a resource owned by this proxy, the proxy will replace it with the results of running a location service. Otherwise, the proxy will not change the Request-URI. 2. The proxy will inspect the URI in the topmost Route header field value. If it indicates this proxy, the proxy removes it from the Route header field (this route node has been reached). 3. The proxy will forward the request to the resource indicated by the URI in the topmost Route header field value or in the Request-URI if no Route header field is present. The proxy determines the address, port and transport to use when forwarding the request by applying the procedures in [4] to that URI. If no strict-routing elements are encountered on the path of the request, the Request-URI will always indicate the target of the request. 16.12.1 Examples 16.12.1.1 Basic SIP Trapezoid This scenario is the basic SIP trapezoid, U1 -> P1 -> P2 -> U2, with both proxies record-routing. Here is the flow. Rosenberg, et. al. Standards Track [Page 118] RFC 3261 SIP: Session Initiation Protocol June 2002 U1 sends: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com to P1. P1 is an outbound proxy. P1 is not responsible for domain.com, so it looks it up in DNS and sends it there. It also adds a Record-Route header field value: INVITE sip:callee@domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p1.example.com;lr> P2 gets this. It is responsible for domain.com so it runs a location service and rewrites the Request-URI. It also adds a Record-Route header field value. There is no Route header field, so it resolves the new Request-URI to determine where to send the request: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr> The callee at u2.domain.com gets this and responds with a 200 OK: SIP/2.0 200 OK Contact: sip:callee@u2.domain.com Record-Route: <sip:p2.domain.com;lr> Record-Route: <sip:p1.example.com;lr> The callee at u2 also sets its dialog state's remote target URI to sip:caller@u1.example.com and its route set to: (<sip:p2.domain.com;lr>,<sip:p1.example.com;lr>) This is forwarded by P2 to P1 to U1 as normal. Now, U1 sets its dialog state's remote target URI to sip:callee@u2.domain.com and its route set to: (<sip:p1.example.com;lr>,<sip:p2.domain.com;lr>) Since all the route set elements contain the lr parameter, U1 constructs the following BYE request: BYE sip:callee@u2.domain.com SIP/2.0 Route: <sip:p1.example.com;lr>,<sip:p2.domain.com;lr> Rosenberg, et. al. Standards Track [Page 119] RFC 3261 SIP: Session Initiation Protocol June 2002 As any other element (including proxies) would do, it resolves the URI in the topmost Route header field value using DNS to determine where to send the request. This goes to P1. P1 notices that it is not responsible for the resource indicated in the Request-URI so it doesn't change it. It does see that it is the first value in the Route header field, so it removes that value, and forwards the request to P2: BYE sip:callee@u2.domain.com SIP/2.0 Route: <sip:p2.domain.com;lr> P2 also notices it is not responsible for the resource indicated by the Request-URI (it is responsible for domain.com, not u2.domain.com), so it doesn't change it. It does see itself in the first Route header field value, so it removes it and forwards the following to u2.domain.com based on a DNS lookup against the Request-URI: BYE sip:callee@u2.domain.com SIP/2.0 16.12.1.2 Traversing a Strict-Routing Proxy In this scenario, a dialog is established across four proxies, each of which adds Record-Route header field values. The third proxy implements the strict-routing procedures specified in RFC 2543 and many works in progress. U1->P1->P2->P3->P4->U2 The INVITE arriving at U2 contains: INVITE sip:callee@u2.domain.com SIP/2.0 Contact: sip:caller@u1.example.com Record-Route: <sip:p4.domain.com;lr> Record-Route: <sip:p3.middle.com> Record-Route: <sip:p2.example.com;lr> Record-Route: <sip:p1.example.com;lr> Which U2 responds to with a 200 OK. Later, U2 sends the following BYE request to P4 based on the first Route header field value. BYE sip:caller@u1.example.com SIP/2.0 Route: <sip:p4.domain.com;lr> Route: <sip:p3.middle.com> Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> Rosenberg, et. al. Standards Track [Page 120] RFC 3261 SIP: Session Initiation Protocol June 2002 P4 is not responsible for the resource indicated in the Request-URI so it will leave it alone. It notices that it is the element in the first Route header field value so it removes it. It then prepares to send the request based on the now first Route header field value of sip:p3.middle.com, but it notices that this URI does not contain the lr parameter, so before sending, it reformats the request to be: BYE sip:p3.middle.com SIP/2.0 Route: <sip:p2.example.com;lr> Route: <sip:p1.example.com;lr> Route: <sip:caller@u1.example.com> P3 is a strict router, so it forwards the following to P2: BYE sip:p2.example.com;lr SIP/2.0 Route: <sip:p1.example.com;lr> Route: <sip:caller@u1.example.com> P2 sees the request-URI is a value it placed into a Record-Route header field, so before further processing, it rewrites the request to be: BYE sip:caller@u1.example.com SIP/2.0 Route: <sip:p1.example.com;lr> P2 is not responsible for u1.example.com, so it sends the request to P1 based on the resolution of the Route header field value. P1 notices itself in the topmost Route header field value, so it removes it, resulting in: BYE sip:caller@u1.example.com SIP/2.0 Since P1 is not responsible for u1.example.com and there is no Route header field, P1 will forward the request to u1.example.com based on the Request-URI. 16.12.1.3 Rewriting Record-Route Header Field Values In this scenario, U1 and U2 are in different private namespaces and they enter a dialog through a proxy P1, which acts as a gateway between the namespaces. U1->P1->U2 Rosenberg, et. al. Standards Track [Page 121] RFC 3261 SIP: Session Initiation Protocol June 2002 U1 sends: INVITE sip:callee@gateway.leftprivatespace.com SIP/2.0 Contact: <sip:caller@u1.leftprivatespace.com> P1 uses its location service and sends the following to U2: INVITE sip:callee@rightprivatespace.com SIP/2.0 Contact: <sip:caller@u1.leftprivatespace.com> Record-Route: <sip:gateway.rightprivatespace.com;lr> U2 sends this 200 (OK) back to P1: SIP/2.0 200 OK Contact: <sip:callee@u2.rightprivatespace.com> Record-Route: <sip:gateway.rightprivatespace.com;lr> P1 rewrites its Record-Route header parameter to provide a value that U1 will find useful, and sends the following to U1: SIP/2.0 200 OK Contact: <sip:callee@u2.rightprivatespace.com> Record-Route: <sip:gateway.leftprivatespace.com;lr> Later, U1 sends the following BYE request to P1: BYE sip:callee@u2.rightprivatespace.com SIP/2.0 Route: <sip:gateway.leftprivatespace.com;lr> which P1 forwards to U2 as: BYE sip:callee@u2.rightprivatespace.com SIP/2.0 17 Transactions SIP is a transactional protocol: interactions between components take place in a series of independent message exchanges. Specifically, a SIP transaction consists of a single request and any responses to that request, which include zero or more provisional responses and one or more final responses. In the case of a transaction where the request was an INVITE (known as an INVITE transaction), the transaction also includes the ACK only if the final response was not a 2xx response. If the response was a 2xx, the ACK is not considered part of the transaction. The reason for this separation is rooted in the importance of delivering all 200 (OK) responses to an INVITE to the UAC. To deliver them all to the UAC, the UAS alone takes responsibility Rosenberg, et. al. Standards Track [Page 122] RFC 3261 SIP: Session Initiation Protocol June 2002 for retransmitting them (see Section 13.3.1.4), and the UAC alone takes responsibility for acknowledging them with ACK (see Section 13.2.2.4). Since this ACK is retransmitted only by the UAC, it is effectively considered its own transaction. Transactions have a client side and a server side. The client side is known as a client transaction and the server side as a server transaction. The client transaction sends the request, and the server transaction sends the response. The client and server transactions are logical functions that are embedded in any number of elements. Specifically, they exist within user agents and stateful proxy servers. Consider the example in Section 4. In this example, the UAC executes the client transaction, and its outbound proxy executes the server transaction. The outbound proxy also executes a client transaction, which sends the request to a server transaction in the inbound proxy. That proxy also executes a client transaction, which in turn sends the request to a server transaction in the UAS. This is shown in Figure 4. +---------+ +---------+ +---------+ +---------+ | +-+|Request |+-+ +-+|Request |+-+ +-+|Request |+-+ | | |C||------->||S| |C||------->||S| |C||------->||S| | | |l|| ||e| |l|| ||e| |l|| ||e| | | |i|| ||r| |i|| ||r| |i|| ||r| | | |e|| ||v| |e|| ||v| |e|| ||v| | | |n|| ||e| |n|| ||e| |n|| ||e| | | |t|| ||r| |t|| ||r| |t|| ||r| | | | || || | | || || | | || || | | | |T|| ||T| |T|| ||T| |T|| ||T| | | |r|| ||r| |r|| ||r| |r|| ||r| | | |a|| ||a| |a|| ||a| |a|| ||a| | | |n|| ||n| |n|| ||n| |n|| ||n| | | |s||Response||s| |s||Response||s| |s||Response||s| | | +-+|<-------|+-+ +-+|<-------|+-+ +-+|<-------|+-+ | +---------+ +---------+ +---------+ +---------+ UAC Outbound Inbound UAS Proxy Proxy Figure 4: Transaction relationships A stateless proxy does not contain a client or server transaction. The transaction exists between the UA or stateful proxy on one side, and the UA or stateful proxy on the other side. As far as SIP transactions are concerned, stateless proxies are effectively transparent."
"The purpose of the client transaction is to receive a request from the element in which the client is embedded (call this element the ""Transaction User"" or TU; it can be a UA or a stateful proxy), and reliably deliver the request to a server transaction. Rosenberg, et. al. Standards Track [Page 123] RFC 3261 SIP: Session Initiation Protocol June 2002 The client transaction is also responsible for receiving responses and delivering them to the TU, filtering out any response retransmissions or disallowed responses (such as a response to ACK). Additionally, in the case of an INVITE request, the client transaction is responsible for generating the ACK request for any final response accepting a 2xx response. Similarly, the purpose of the server transaction is to receive requests from the transport layer and deliver them to the TU. The server transaction filters any request retransmissions from the network. The server transaction accepts responses from the TU and delivers them to the transport layer for transmission over the network. In the case of an INVITE transaction, it absorbs the ACK request for any final response excepting a 2xx response. The 2xx response and its ACK receive special treatment. This response is retransmitted only by a UAS, and its ACK generated only by the UAC. This end-to-end treatment is needed so that a caller knows the entire set of users that have accepted the call. Because of this special handling, retransmissions of the 2xx response are handled by the UA core, not the transaction layer. Similarly, generation of the ACK for the 2xx is handled by the UA core. Each proxy along the path merely forwards each 2xx response to INVITE and its corresponding ACK. 17.1 Client Transaction The client transaction provides its functionality through the maintenance of a state machine. The TU communicates with the client transaction through a simple interface. When the TU wishes to initiate a new transaction, it creates a client transaction and passes it the SIP request to send and an IP address, port, and transport to which to send it. The client transaction begins execution of its state machine. Valid responses are passed up to the TU from the client transaction. There are two types of client transaction state machines, depending on the method of the request passed by the TU. One handles client transactions for INVITE requests. This type of machine is referred to as an INVITE client transaction. Another type handles client transactions for all requests except INVITE and ACK. This is referred to as a non-INVITE client transaction. There is no client transaction for ACK. If the TU wishes to send an ACK, it passes one directly to the transport layer for transmission. Rosenberg, et. al. Standards Track [Page 124] RFC 3261 SIP: Session Initiation Protocol June 2002 The INVITE transaction is different from those of other methods because of its extended duration. Normally, human input is required in order to respond to an INVITE. The long delays expected for sending a response argue for a three-way handshake. On the other hand, requests of other methods are expected to complete rapidly. Because of the non-INVITE transaction's reliance on a two-way handshake, TUs SHOULD respond immediately to non-INVITE requests. 17.1.1 INVITE Client Transaction 17.1.1.1 Overview of INVITE Transaction The INVITE transaction consists of a three-way handshake. The client transaction sends an INVITE, the server transaction sends responses, and the client transaction sends an ACK. For unreliable transports (such as UDP), the client transaction retransmits requests at an interval that starts at T1 seconds and doubles after every retransmission. T1 is an estimate of the round-trip time (RTT), and it defaults to 500 ms. Nearly all of the transaction timers described here scale with T1, and changing T1 adjusts their values. The request is not retransmitted over reliable transports. After receiving a 1xx response, any retransmissions cease altogether, and the client waits for further responses. The server transaction can send additional 1xx responses, which are not transmitted reliably by the server transaction. Eventually, the server transaction decides to send a final response. For unreliable transports, that response is retransmitted periodically, and for reliable transports, it is sent once. For each final response that is received at the client transaction, the client transaction sends an ACK, the purpose of which is to quench retransmissions of the response. 17.1.1.2 Formal Description The state machine for the INVITE client transaction is shown in Figure 5. The initial state, ""calling"", MUST be entered when the TU initiates a new client transaction with an INVITE request. The client transaction MUST pass the request to the transport layer for transmission (see Section 18). If an unreliable transport is being used, the client transaction MUST start timer A with a value of T1. If a reliable transport is being used, the client transaction SHOULD NOT start timer A (Timer A controls request retransmissions). For any transport, the client transaction MUST start timer B with a value of 64*T1 seconds (Timer B controls transaction timeouts). When timer A fires, the client transaction MUST retransmit the request by passing it to the transport layer, and MUST reset the timer with a value of 2*T1. The formal definition of retransmit Rosenberg, et. al. Standards Track [Page 125] RFC 3261 SIP: Session Initiation Protocol June 2002 within the context of the transaction layer is to take the message previously sent to the transport layer and pass it to the transport layer once more. When timer A fires 2*T1 seconds later, the request MUST be retransmitted again (assuming the client transaction is still in this state). This process MUST continue so that the request is retransmitted with intervals that double after each transmission. These retransmissions SHOULD only be done while the client transaction is in the ""calling"" state. The default value for T1 is 500 ms. T1 is an estimate of the RTT between the client and server transactions. Elements MAY (though it is NOT RECOMMENDED) use smaller values of T1 within closed, private networks that do not permit general Internet connection. T1 MAY be chosen larger, and this is RECOMMENDED if it is known in advance (such as on high latency access links) that the RTT is larger. Whatever the value of T1, the exponential backoffs on retransmissions described in this section MUST be used. If the client transaction is still in the ""Calling"" state when timer B fires, the client transaction SHOULD inform the TU that a timeout has occurred. The client transaction MUST NOT generate an ACK. The value of 64*T1 is equal to the amount of time required to send seven requests in the case of an unreliable transport. If the client transaction receives a provisional response while in the ""Calling"" state, it transitions to the ""Proceeding"" state. In the ""Proceeding"" state, the client transaction SHOULD NOT retransmit the request any longer. Furthermore, the provisional response MUST be passed to the TU. Any further provisional responses MUST be passed up to the TU while in the ""Proceeding"" state. When in either the ""Calling"" or ""Proceeding"" states, reception of a response with status code from 300-699 MUST cause the client transaction to transition to ""Completed"". The client transaction MUST pass the received response up to the TU, and the client transaction MUST generate an ACK request, even if the transport is reliable (guidelines for constructing the ACK from the response are given in Section 17.1.1.3) and then pass the ACK to the transport layer for transmission. The ACK MUST be sent to the same address, port, and transport to which the original request was sent. The client transaction SHOULD start timer D when it enters the ""Completed"" state, with a value of at least 32 seconds for unreliable transports, and a value of zero seconds for reliable transports. Timer D reflects the amount of time that the server transaction can remain in the ""Completed"" state when unreliable transports are used. This is equal to Timer H in the INVITE server transaction, whose Rosenberg, et. al. Standards Track [Page 126] RFC 3261 SIP: Session Initiation Protocol June 2002 default is 64*T1. However, the client transaction does not know the value of T1 in use by the server transaction, so an absolute minimum of 32s is used instead of basing Timer D on T1. Any retransmissions of the final response that are received while in the ""Completed"" state MUST cause the ACK to be re-passed to the transport layer for retransmission, but the newly received response MUST NOT be passed up to the TU. A retransmission of the response is defined as any response which would match the same client transaction based on the rules of Section 17.1.3. Rosenberg, et. al. Standards Track [Page 127] RFC 3261 SIP: Session Initiation Protocol June 2002 |INVITE from TU Timer A fires |INVITE sent Reset A, V Timer B fires INVITE sent +-----------+ or Transport Err. +---------| |---------------+inform TU | | Calling | | +-------->| |-------------->| +-----------+ 2xx | | | 2xx to TU | | |1xx | 300-699 +---------------+ |1xx to TU | ACK sent | | | resp. to TU | 1xx V | | 1xx to TU -----------+ | | +---------| | | | | |Proceeding |-------------->| | +-------->| | 2xx | | +-----------+ 2xx to TU | | 300-699 | | | ACK sent, | | | resp. to TU| | | | | NOTE: | 300-699 V | | ACK sent +-----------+Transport Err. | transitions | +---------| |Inform TU | labeled with | | | Completed |-------------->| the event | +-------->| | | over the action | +-----------+ | to take | ^ | | | | | Timer D fires | +--------------+ | - | | | V | +-----------+ | | | | | Terminated|<--------------+ | | +-----------+ Figure 5: INVITE client transaction If timer D fires while the client transaction is in the ""Completed"" state, the client transaction MUST move to the terminated state. When in either the ""Calling"" or ""Proceeding"" states, reception of a 2xx response MUST cause the client transaction to enter the ""Terminated"" state, and the response MUST be passed up to the TU. The handling of this response depends on whether the TU is a proxy Rosenberg, et. al. Standards Track [Page 128] RFC 3261 SIP: Session Initiation Protocol June 2002 core or a UAC core. A UAC core will handle generation of the ACK for this response, while a proxy core will always forward the 200 (OK) upstream. The differing treatment of 200 (OK) between proxy and UAC is the reason that handling of it does not take place in the transaction layer. The client transaction MUST be destroyed the instant it enters the ""Terminated"" state. This is actually necessary to guarantee correct operation. The reason is that 2xx responses to an INVITE are treated differently; each one is forwarded by proxies, and the ACK handling in a UAC is different. Thus, each 2xx needs to be passed to a proxy core (so that it can be forwarded) and to a UAC core (so it can be acknowledged). No transaction layer processing takes place. Whenever a response is received by the transport, if the transport layer finds no matching client transaction (using the rules of Section 17.1.3), the response is passed directly to the core. Since the matching client transaction is destroyed by the first 2xx, subsequent 2xx will find no match and therefore be passed to the core. 17.1.1.3 Construction of the ACK Request This section specifies the construction of ACK requests sent within the client transaction. A UAC core that generates an ACK for 2xx MUST instead follow the rules described in Section 13. The ACK request constructed by the client transaction MUST contain values for the Call-ID, From, and Request-URI that are equal to the values of those header fields in the request passed to the transport by the client transaction (call this the ""original request""). The To header field in the ACK MUST equal the To header field in the response being acknowledged, and therefore will usually differ from the To header field in the original request by the addition of the tag parameter. The ACK MUST contain a single Via header field, and this MUST be equal to the top Via header field of the original request. The CSeq header field in the ACK MUST contain the same value for the sequence number as was present in the original request, but the method parameter MUST be equal to ""ACK"". Rosenberg, et. al. Standards Track [Page 129] RFC 3261 SIP: Session Initiation Protocol June 2002 If the INVITE request whose response is being acknowledged had Route header fields, those header fields MUST appear in the ACK. This is to ensure that the ACK can be routed properly through any downstream stateless proxies. Although any request MAY contain a body, a body in an ACK is special since the request cannot be rejected if the body is not understood. Therefore, placement of bodies in ACK for non-2xx is NOT RECOMMENDED, but if done, the body types are restricted to any that appeared in the INVITE, assuming that the response to the INVITE was not 415. If it was, the body in the ACK MAY be any type listed in the Accept header field in the 415. For example, consider the following request: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 INVITE The ACK request for a non-2xx final response to this request would look like this: ACK sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKkjshdyff To: Bob <sip:bob@biloxi.com>;tag=99sa0xk From: Alice <sip:alice@atlanta.com>;tag=88sja8x Max-Forwards: 70 Call-ID: 987asjd97y7atg CSeq: 986759 ACK 17.1.2 Non-INVITE Client Transaction 17.1.2.1 Overview of the non-INVITE Transaction Non-INVITE transactions do not make use of ACK. They are simple request-response interactions. For unreliable transports, requests are retransmitted at an interval which starts at T1 and doubles until it hits T2. If a provisional response is received, retransmissions continue for unreliable transports, but at an interval of T2. The server transaction retransmits the last response it sent, which can be a provisional or final response, only when a retransmission of the request is received. This is why request retransmissions need to continue even after a provisional response; they are to ensure reliable delivery of the final response. Rosenberg, et. al. Standards Track [Page 130] RFC 3261 SIP: Session Initiation Protocol June 2002 Unlike an INVITE transaction, a non-INVITE transaction has no special handling for the 2xx response. The result is that only a single 2xx response to a non-INVITE is ever delivered to a UAC. 17.1.2.2 Formal Description The state machine for the non-INVITE client transaction is shown in Figure 6. It is very similar to the state machine for INVITE. The ""Trying"" state is entered when the TU initiates a new client transaction with a request. When entering this state, the client transaction SHOULD set timer F to fire in 64*T1 seconds. The request MUST be passed to the transport layer for transmission. If an unreliable transport is in use, the client transaction MUST set timer E to fire in T1 seconds. If timer E fires while still in this state, the timer is reset, but this time with a value of MIN(2*T1, T2). When the timer fires again, it is reset to a MIN(4*T1, T2). This process continues so that retransmissions occur with an exponentially increasing interval that caps at T2. The default value of T2 is 4s, and it represents the amount of time a non-INVITE server transaction will take to respond to a request, if it does not respond immediately. For the default values of T1 and T2, this results in intervals of 500 ms, 1 s, 2 s, 4 s, 4 s, 4 s, etc. If Timer F fires while the client transaction is still in the ""Trying"" state, the client transaction SHOULD inform the TU about the timeout, and then it SHOULD enter the ""Terminated"" state. If a provisional response is received while in the ""Trying"" state, the response MUST be passed to the TU, and then the client transaction SHOULD move to the ""Proceeding"" state. If a final response (status codes 200-699) is received while in the ""Trying"" state, the response MUST be passed to the TU, and the client transaction MUST transition to the ""Completed"" state. If Timer E fires while in the ""Proceeding"" state, the request MUST be passed to the transport layer for retransmission, and Timer E MUST be reset with a value of T2 seconds. If timer F fires while in the ""Proceeding"" state, the TU MUST be informed of a timeout, and the client transaction MUST transition to the terminated state. If a final response (status codes 200-699) is received while in the ""Proceeding"" state, the response MUST be passed to the TU, and the client transaction MUST transition to the ""Completed"" state. Once the client transaction enters the ""Completed"" state, it MUST set Timer K to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. The ""Completed"" state exists to buffer any additional response retransmissions that may be received (which is why the client transaction remains there only for Rosenberg, et. al. Standards Track [Page 131] RFC 3261 SIP: Session Initiation Protocol June 2002 unreliable transports). T4 represents the amount of time the network will take to clear messages between client and server transactions. The default value of T4 is 5s. A response is a retransmission when it matches the same transaction, using the rules specified in Section 17.1.3. If Timer K fires while in this state, the client transaction MUST transition to the ""Terminated"" state. Once the transaction is in the terminated state, it MUST be destroyed immediately. 17.1.3 Matching Responses to Client Transactions When the transport layer in the client receives a response, it has to determine which client transaction will handle the response, so that the processing of Sections 17.1.1 and 17.1.2 can take place. The branch parameter in the top Via header field is used for this purpose. A response matches a client transaction under two conditions: 1. If the response has the same value of the branch parameter in the top Via header field as the branch parameter in the top Via header field of the request that created the transaction. 2. If the method parameter in the CSeq header field matches the method of the request that created the transaction. The method is needed since a CANCEL request constitutes a different transaction, but shares the same value of the branch parameter. If a request is sent via multicast, it is possible that it will generate multiple responses from different servers. These responses will all have the same branch parameter in the topmost Via, but vary in the To tag. The first response received, based on the rules above, will be used, and others will be viewed as retransmissions. That is not an error; multicast SIP provides only a rudimentary ""single-hop-discovery-like"" service that is limited to processing a single response. See Section 18.1.1 for details. Rosenberg, et. al. Standards Track [Page 132] RFC 3261 SIP: Session Initiation Protocol June 2002 17.1.4 Handling Transport Errors |Request from TU |send request Timer E V send request +-----------+ +---------| |-------------------+ | | Trying | Timer F | +-------->| | or Transport Err.| +-----------+ inform TU | 200-699 | | | resp. to TU | |1xx | +---------------+ |resp. to TU | | | | | Timer E V Timer F | | send req +-----------+ or Transport Err. | | +---------| | inform TU | | | |Proceeding |------------------>| | +-------->| |-----+ | | +-----------+ |1xx | | | ^ |resp to TU | | 200-699 | +--------+ | | resp. to TU | | | | | | V | | +-----------+ | | | | | | | Completed | | | | | | | +-----------+ | | ^ | | | | | Timer K | +--------------+ | - | | | V | NOTE: +-----------+ | | | | transitions | Terminated|<------------------+ labeled with | | the event +-----------+ over the action to take Figure 6: non-INVITE client transaction When the client transaction sends a request to the transport layer to be sent, the following procedures are followed if the transport layer indicates a failure. Rosenberg, et. al. Standards Track [Page 133] RFC 3261 SIP: Session Initiation Protocol June 2002 The client transaction SHOULD inform the TU that a transport failure has occurred, and the client transaction SHOULD transition directly to the ""Terminated"" state. The TU will handle the failover mechanisms described in [4]. 17.2 Server Transaction The server transaction is responsible for the delivery of requests to the TU and the reliable transmission of responses. It accomplishes this through a state machine. Server transactions are created by the core when a request is received, and transaction handling is desired for that request (this is not always the case). As with the client transactions, the state machine depends on whether the received request is an INVITE request. 17.2.1 INVITE Server Transaction The state diagram for the INVITE server transaction is shown in Figure 7. When a server transaction is constructed for a request, it enters the ""Proceeding"" state. The server transaction MUST generate a 100 (Trying) response unless it knows that the TU will generate a provisional or final response within 200 ms, in which case it MAY generate a 100 (Trying) response. This provisional response is needed to quench request retransmissions rapidly in order to avoid network congestion. The 100 (Trying) response is constructed according to the procedures in Section 8.2.6, except that the insertion of tags in the To header field of the response (when none was present in the request) is downgraded from MAY to SHOULD NOT. The request MUST be passed to the TU. The TU passes any number of provisional responses to the server transaction. So long as the server transaction is in the ""Proceeding"" state, each of these MUST be passed to the transport layer for transmission. They are not sent reliably by the transaction layer (they are not retransmitted by it) and do not cause a change in the state of the server transaction. If a request retransmission is received while in the ""Proceeding"" state, the most recent provisional response that was received from the TU MUST be passed to the transport layer for retransmission. A request is a retransmission if it matches the same server transaction based on the rules of Section 17.2.3. If, while in the ""Proceeding"" state, the TU passes a 2xx response to the server transaction, the server transaction MUST pass this response to the transport layer for transmission. It is not Rosenberg, et. al. Standards Track [Page 134] RFC 3261 SIP: Session Initiation Protocol June 2002 retransmitted by the server transaction; retransmissions of 2xx responses are handled by the TU. The server transaction MUST then transition to the ""Terminated"" state. While in the ""Proceeding"" state, if the TU passes a response with status code from 300 to 699 to the server transaction, the response MUST be passed to the transport layer for transmission, and the state machine MUST enter the ""Completed"" state. For unreliable transports, timer G is set to fire in T1 seconds, and is not set to fire for reliable transports. This is a change from RFC 2543, where responses were always retransmitted, even over reliable transports. When the ""Completed"" state is entered, timer H MUST be set to fire in 64*T1 seconds for all transports. Timer H determines when the server transaction abandons retransmitting the response. Its value is chosen to equal Timer B, the amount of time a client transaction will continue to retry sending a request. If timer G fires, the response is passed to the transport layer once more for retransmission, and timer G is set to fire in MIN(2*T1, T2) seconds. From then on, when timer G fires, the response is passed to the transport again for transmission, and timer G is reset with a value that doubles, unless that value exceeds T2, in which case it is reset with the value of T2. This is identical to the retransmit behavior for requests in the ""Trying"" state of the non-INVITE client transaction. Furthermore, while in the ""Completed"" state, if a request retransmission is received, the server SHOULD pass the response to the transport for retransmission. If an ACK is received while the server transaction is in the ""Completed"" state, the server transaction MUST transition to the ""Confirmed"" state. As Timer G is ignored in this state, any retransmissions of the response will cease. If timer H fires while in the ""Completed"" state, it implies that the ACK was never received. In this case, the server transaction MUST transition to the ""Terminated"" state, and MUST indicate to the TU that a transaction failure has occurred. Rosenberg, et. al. Standards Track [Page 135] RFC 3261 SIP: Session Initiation Protocol June 2002 |INVITE |pass INV to TU INVITE V send 100 if TU won't in 200ms send response+-----------+ +--------| |--------+101-199 from TU | | Proceeding| |send response +------->| |<-------+ | | Transport Err. | | Inform TU | |--------------->+ +-----------+ | 300-699 from TU | |2xx from TU | send response | |send response | | +------------------>+ | | INVITE V Timer G fires | send response+-----------+ send response | +--------| |--------+ | | | Completed | | | +------->| |<-------+ | +-----------+ | | | | ACK | | | - | +------------------>+ | Timer H fires | V or Transport Err.| +-----------+ Inform TU | | | | | Confirmed | | | | | +-----------+ | | | |Timer I fires | |- | | | V | +-----------+ | | | | | Terminated|<---------------+ | | +-----------+ Figure 7: INVITE server transaction Rosenberg, et. al. Standards Track [Page 136] RFC 3261 SIP: Session Initiation Protocol June 2002 The purpose of the ""Confirmed"" state is to absorb any additional ACK messages that arrive, triggered from retransmissions of the final response. When this state is entered, timer I is set to fire in T4 seconds for unreliable transports, and zero seconds for reliable transports. Once timer I fires, the server MUST transition to the ""Terminated"" state. Once the transaction is in the ""Terminated"" state, it MUST be destroyed immediately. As with client transactions, this is needed to ensure reliability of the 2xx responses to INVITE. 17.2.2 Non-INVITE Server Transaction The state machine for the non-INVITE server transaction is shown in Figure 8. The state machine is initialized in the ""Trying"" state and is passed a request other than INVITE or ACK when initialized. This request is passed up to the TU. Once in the ""Trying"" state, any further request retransmissions are discarded. A request is a retransmission if it matches the same server transaction, using the rules specified in Section 17.2.3. While in the ""Trying"" state, if the TU passes a provisional response to the server transaction, the server transaction MUST enter the ""Proceeding"" state. The response MUST be passed to the transport layer for transmission. Any further provisional responses that are received from the TU while in the ""Proceeding"" state MUST be passed to the transport layer for transmission. If a retransmission of the request is received while in the ""Proceeding"" state, the most recently sent provisional response MUST be passed to the transport layer for retransmission. If the TU passes a final response (status codes 200-699) to the server while in the ""Proceeding"" state, the transaction MUST enter the ""Completed"" state, and the response MUST be passed to the transport layer for transmission. When the server transaction enters the ""Completed"" state, it MUST set Timer J to fire in 64*T1 seconds for unreliable transports, and zero seconds for reliable transports. While in the ""Completed"" state, the server transaction MUST pass the final response to the transport layer for retransmission whenever a retransmission of the request is received. Any other final responses passed by the TU to the server transaction MUST be discarded while in the ""Completed"" state. The server transaction remains in this state until Timer J fires, at which point it MUST transition to the ""Terminated"" state. The server transaction MUST be destroyed the instant it enters the ""Terminated"" state. Rosenberg, et. al. Standards Track [Page 137] RFC 3261 SIP: Session Initiation Protocol June 2002 17.2.3 Matching Requests to Server Transactions When a request is received from the network by the server, it has to be matched to an existing transaction. This is accomplished in the following manner. The branch parameter in the topmost Via header field of the request is examined. If it is present and begins with the magic cookie ""z9hG4bK"", the request was generated by a client transaction compliant to this specification. Therefore, the branch parameter will be unique across all transactions sent by that client. The request matches a transaction if: 1. the branch parameter in the request is equal to the one in the top Via header field of the request that created the transaction, and 2. the sent-by value in the top Via of the request is equal to the one in the request that created the transaction, and 3. the method of the request matches the one that created the transaction, except for ACK, where the method of the request that created the transaction is INVITE. This matching rule applies to both INVITE and non-INVITE transactions alike. The sent-by value is used as part of the matching process because there could be accidental or malicious duplication of branch parameters from different clients. If the branch parameter in the top Via header field is not present, or does not contain the magic cookie, the following procedures are used. These exist to handle backwards compatibility with RFC 2543 compliant implementations. The INVITE request matches a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq, and top Via header field match those of the INVITE request which created the transaction. In this case, the INVITE is a retransmission of the original one that created the transaction. The ACK request matches a transaction if the Request- URI, From tag, Call-ID, CSeq number (not the method), and top Via header field match those of the INVITE request which created the transaction, and the To tag of the ACK matches the To tag of the response sent by the server transaction. Matching is done based on the matching rules defined for each of those header fields. Inclusion of the tag in the To header field in the ACK matching process helps disambiguate ACK for 2xx from ACK for other responses Rosenberg, et. al. Standards Track [Page 138] RFC 3261 SIP: Session Initiation Protocol June 2002 at a proxy, which may have forwarded both responses (This can occur in unusual conditions. Specifically, when a proxy forked a request, and then crashes, the responses may be delivered to another proxy, which might end up forwarding multiple responses upstream). An ACK request that matches an INVITE transaction matched by a previous ACK is considered a retransmission of that previous ACK. Rosenberg, et. al. Standards Track [Page 139] RFC 3261 SIP: Session Initiation Protocol June 2002 |Request received |pass to TU V +-----------+ | | | Trying |-------------+ | | | +-----------+ |200-699 from TU | |send response |1xx from TU | |send response | | | Request V 1xx from TU | send response+-----------+send response| +--------| |--------+ | | | Proceeding| | | +------->| |<-------+ | +<--------------| | | |Trnsprt Err +-----------+ | |Inform TU | | | | | | |200-699 from TU | | |send response | | Request V | | send response+-----------+ | | +--------| | | | | | Completed |<------------+ | +------->| | +<--------------| | |Trnsprt Err +-----------+ |Inform TU | | |Timer J fires | |- | | | V | +-----------+ | | | +-------------->| Terminated| | | +-----------+ Figure 8: non-INVITE server transaction For all other request methods, a request is matched to a transaction if the Request-URI, To tag, From tag, Call-ID, CSeq (including the method), and top Via header field match those of the request that created the transaction. Matching is done based on the matching Rosenberg, et. al. Standards Track [Page 140] RFC 3261 SIP: Session Initiation Protocol June 2002 rules defined for each of those header fields. When a non-INVITE request matches an existing transaction, it is a retransmission of the request that created that transaction. Because the matching rules include the Request-URI, the server cannot match a response to a transaction. When the TU passes a response to the server transaction, it must pass it to the specific server transaction for which the response is targeted. 17.2.4 Handling Transport Errors When the server transaction sends a response to the transport layer to be sent, the following procedures are followed if the transport layer indicates a failure. First, the procedures in [4] are followed, which attempt to deliver the response to a backup. If those should all fail, based on the definition of failure in [4], the server transaction SHOULD inform the TU that a failure has occurred, and SHOULD transition to the terminated state. 18 Transport The transport layer is responsible for the actual transmission of requests and responses over network transports. This includes determination of the connection to use for a request or response in the case of connection-oriented transports. The transport layer is responsible for managing persistent connections for transport protocols like TCP and SCTP, or TLS over those, including ones opened to the transport layer. This includes connections opened by the client or server transports, so that connections are shared between client and server transport functions. These connections are indexed by the tuple formed from the address, port, and transport protocol at the far end of the connection. When a connection is opened by the transport layer, this index is set to the destination IP, port and transport. When the connection is accepted by the transport layer, this index is set to the source IP address, port number, and transport. Note that, because the source port is often ephemeral, but it cannot be known whether it is ephemeral or selected through procedures in [4], connections accepted by the transport layer will frequently not be reused. The result is that two proxies in a ""peering"" relationship using a connection- oriented transport frequently will have two connections in use, one for transactions initiated in each direction. Rosenberg, et. al. Standards Track [Page 141] RFC 3261 SIP: Session Initiation Protocol June 2002 It is RECOMMENDED that connections be kept open for some implementation-defined duration after the last message was sent or received over that connection. This duration SHOULD at least equal the longest amount of time the element would need in order to bring a transaction from instantiation to the terminated state. This is to make it likely that transactions are completed over the same connection on which they are initiated (for example, request, response, and in the case of INVITE, ACK for non-2xx responses). This usually means at least 64*T1 (see Section 17.1.1.1 for a definition of T1). However, it could be larger in an element that has a TU using a large value for timer C (bullet 11 of Section 16.6), for example. All SIP elements MUST implement UDP and TCP. SIP elements MAY implement other protocols. Making TCP mandatory for the UA is a substantial change from RFC 2543. It has arisen out of the need to handle larger messages, which MUST use TCP, as discussed below. Thus, even if an element never sends large messages, it may receive one and needs to be able to handle them. 18.1 Clients 18.1.1 Sending Requests The client side of the transport layer is responsible for sending the request and receiving responses. The user of the transport layer passes the client transport the request, an IP address, port, transport, and possibly TTL for multicast destinations. If a request is within 200 bytes of the path MTU, or if it is larger than 1300 bytes and the path MTU is unknown, the request MUST be sent using an RFC 2914 [43] congestion controlled transport protocol, such as TCP. If this causes a change in the transport protocol from the one indicated in the top Via, the value in the top Via MUST be changed. This prevents fragmentation of messages over UDP and provides congestion control for larger messages. However, implementations MUST be able to handle messages up to the maximum datagram packet size. For UDP, this size is 65,535 bytes, including IP and UDP headers. The 200 byte ""buffer"" between the message size and the MTU accommodates the fact that the response in SIP can be larger than the request. This happens due to the addition of Record-Route header field values to the responses to INVITE, for example."
"With the extra buffer, the response can be about 170 bytes larger than the request, and still not be fragmented on IPv4 (about 30 bytes Rosenberg, et. al. Standards Track [Page 142] RFC 3261 SIP: Session Initiation Protocol June 2002 is consumed by IP/UDP, assuming no IPSec). 1300 is chosen when path MTU is not known, based on the assumption of a 1500 byte Ethernet MTU. If an element sends a request over TCP because of these message size constraints, and that request would have otherwise been sent over UDP, if the attempt to establish the connection generates either an ICMP Protocol Not Supported, or results in a TCP reset, the element SHOULD retry the request, using UDP. This is only to provide backwards compatibility with RFC 2543 compliant implementations that do not support TCP. It is anticipated that this behavior will be deprecated in a future revision of this specification. A client that sends a request to a multicast address MUST add the ""maddr"" parameter to its Via header field value containing the destination multicast address, and for IPv4, SHOULD add the ""ttl"" parameter with a value of 1. Usage of IPv6 multicast is not defined in this specification, and will be a subject of future standardization when the need arises. These rules result in a purposeful limitation of multicast in SIP. Its primary function is to provide a ""single-hop-discovery-like"" service, delivering a request to a group of homogeneous servers, where it is only required to process the response from any one of them. This functionality is most useful for registrations. In fact, based on the transaction processing rules in Section 17.1.3, the client transaction will accept the first response, and view any others as retransmissions because they all contain the same Via branch identifier. Before a request is sent, the client transport MUST insert a value of the ""sent-by"" field into the Via header field. This field contains an IP address or host name, and port. The usage of an FQDN is RECOMMENDED. This field is used for sending responses under certain conditions, described below. If the port is absent, the default value depends on the transport. It is 5060 for UDP, TCP and SCTP, 5061 for TLS. For reliable transports, the response is normally sent on the connection on which the request was received. Therefore, the client transport MUST be prepared to receive the response on the same connection used to send the request. Under error conditions, the server may attempt to open a new connection to send the response. To handle this case, the transport layer MUST also be prepared to receive an incoming connection on the source IP address from which the request was sent and port number in the ""sent-by"" field. It also Rosenberg, et. al. Standards Track [Page 143] RFC 3261 SIP: Session Initiation Protocol June 2002 MUST be prepared to receive incoming connections on any address and port that would be selected by a server based on the procedures described in Section 5 of [4]. For unreliable unicast transports, the client transport MUST be prepared to receive responses on the source IP address from which the request is sent (as responses are sent back to the source address) and the port number in the ""sent-by"" field. Furthermore, as with reliable transports, in certain cases the response will be sent elsewhere. The client MUST be prepared to receive responses on any address and port that would be selected by a server based on the procedures described in Section 5 of [4]. For multicast, the client transport MUST be prepared to receive responses on the same multicast group and port to which the request is sent (that is, it needs to be a member of the multicast group it sent the request to.) If a request is destined to an IP address, port, and transport to which an existing connection is open, it is RECOMMENDED that this connection be used to send the request, but another connection MAY be opened and used. If a request is sent using multicast, it is sent to the group address, port, and TTL provided by the transport user. If a request is sent using unicast unreliable transports, it is sent to the IP address and port provided by the transport user. 18.1.2 Receiving Responses When a response is received, the client transport examines the top Via header field value. If the value of the ""sent-by"" parameter in that header field value does not correspond to a value that the client transport is configured to insert into requests, the response MUST be silently discarded. If there are any client transactions in existence, the client transport uses the matching procedures of Section 17.1.3 to attempt to match the response to an existing transaction. If there is a match, the response MUST be passed to that transaction. Otherwise, the response MUST be passed to the core (whether it be stateless proxy, stateful proxy, or UA) for further processing. Handling of these ""stray"" responses is dependent on the core (a proxy will forward them, while a UA will discard, for example). Rosenberg, et. al. Standards Track [Page 144] RFC 3261 SIP: Session Initiation Protocol June 2002 18.2 Servers 18.2.1 Receiving Requests A server SHOULD be prepared to receive requests on any IP address, port and transport combination that can be the result of a DNS lookup on a SIP or SIPS URI [4] that is handed out for the purposes of communicating with that server. In this context, ""handing out"" includes placing a URI in a Contact header field in a REGISTER request or a redirect response, or in a Record-Route header field in a request or response. A URI can also be ""handed out"" by placing it on a web page or business card. It is also RECOMMENDED that a server listen for requests on the default SIP ports (5060 for TCP and UDP, 5061 for TLS over TCP) on all public interfaces. The typical exception would be private networks, or when multiple server instances are running on the same host. For any port and interface that a server listens on for UDP, it MUST listen on that same port and interface for TCP. This is because a message may need to be sent using TCP, rather than UDP, if it is too large. As a result, the converse is not true. A server need not listen for UDP on a particular address and port just because it is listening on that same address and port for TCP. There may, of course, be other reasons why a server needs to listen for UDP on a particular address and port. When the server transport receives a request over any transport, it MUST examine the value of the ""sent-by"" parameter in the top Via header field value. If the host portion of the ""sent-by"" parameter contains a domain name, or if it contains an IP address that differs from the packet source address, the server MUST add a ""received"" parameter to that Via header field value. This parameter MUST contain the source address from which the packet was received. This is to assist the server transport layer in sending the response, since it must be sent to the source IP address from which the request came. Consider a request received by the server transport which looks like, in part: INVITE sip:bob@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060 The request is received with a source IP address of 192.0.2.4. Before passing the request up, the transport adds a ""received"" parameter, so that the request would look like, in part: INVITE sip:bob@Biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;received=192.0.2.4 Rosenberg, et. al. Standards Track [Page 145] RFC 3261 SIP: Session Initiation Protocol June 2002 Next, the server transport attempts to match the request to a server transaction. It does so using the matching rules described in Section 17.2.3. If a matching server transaction is found, the request is passed to that transaction for processing. If no match is found, the request is passed to the core, which may decide to construct a new server transaction for that request. Note that when a UAS core sends a 2xx response to INVITE, the server transaction is destroyed. This means that when the ACK arrives, there will be no matching server transaction, and based on this rule, the ACK is passed to the UAS core, where it is processed. 18.2.2 Sending Responses The server transport uses the value of the top Via header field in order to determine where to send a response. It MUST follow the following process: o If the ""sent-protocol"" is a reliable transport protocol such as TCP or SCTP, or TLS over those, the response MUST be sent using the existing connection to the source of the original request that created the transaction, if that connection is still open. This requires the server transport to maintain an association between server transactions and transport connections. If that connection is no longer open, the server SHOULD open a connection to the IP address in the ""received"" parameter, if present, using the port in the ""sent-by"" value, or the default port for that transport, if no port is specified. If that connection attempt fails, the server SHOULD use the procedures in [4] for servers in order to determine the IP address and port to open the connection and send the response to. o Otherwise, if the Via header field value contains a ""maddr"" parameter, the response MUST be forwarded to the address listed there, using the port indicated in ""sent-by"", or port 5060 if none is present. If the address is a multicast address, the response SHOULD be sent using the TTL indicated in the ""ttl"" parameter, or with a TTL of 1 if that parameter is not present. o Otherwise (for unreliable unicast transports), if the top Via has a ""received"" parameter, the response MUST be sent to the address in the ""received"" parameter, using the port indicated in the ""sent-by"" value, or using port 5060 if none is specified explicitly. If this fails, for example, elicits an ICMP ""port unreachable"" response, the procedures of Section 5 of [4] SHOULD be used to determine where to send the response. Rosenberg, et. al. Standards Track [Page 146] RFC 3261 SIP: Session Initiation Protocol June 2002 o Otherwise, if it is not receiver-tagged, the response MUST be sent to the address indicated by the ""sent-by"" value, using the procedures in Section 5 of [4]. 18.3 Framing In the case of message-oriented transports (such as UDP), if the message has a Content-Length header field, the message body is assumed to contain that many bytes. If there are additional bytes in the transport packet beyond the end of the body, they MUST be discarded. If the transport packet ends before the end of the message body, this is considered an error. If the message is a response, it MUST be discarded. If the message is a request, the element SHOULD generate a 400 (Bad Request) response. If the message has no Content-Length header field, the message body is assumed to end at the end of the transport packet. In the case of stream-oriented transports such as TCP, the Content- Length header field indicates the size of the body. The Content- Length header field MUST be used with stream oriented transports. 18.4 Error Handling Error handling is independent of whether the message was a request or response. If the transport user asks for a message to be sent over an unreliable transport, and the result is an ICMP error, the behavior depends on the type of ICMP error. Host, network, port or protocol unreachable errors, or parameter problem errors SHOULD cause the transport layer to inform the transport user of a failure in sending. Source quench and TTL exceeded ICMP errors SHOULD be ignored. If the transport user asks for a request to be sent over a reliable transport, and the result is a connection failure, the transport layer SHOULD inform the transport user of a failure in sending. 19 Common Message Components There are certain components of SIP messages that appear in various places within SIP messages (and sometimes, outside of them) that merit separate discussion. Rosenberg, et. al. Standards Track [Page 147] RFC 3261 SIP: Session Initiation Protocol June 2002 19.1 SIP and SIPS Uniform Resource Indicators A SIP or SIPS URI identifies a communications resource. Like all URIs, SIP and SIPS URIs may be placed in web pages, email messages, or printed literature. They contain sufficient information to initiate and maintain a communication session with the resource. Examples of communications resources include the following: o a user of an online service o an appearance on a multi-line phone o a mailbox on a messaging system o a PSTN number at a gateway service o a group (such as ""sales"" or ""helpdesk"") in an organization A SIPS URI specifies that the resource be contacted securely. This means, in particular, that TLS is to be used between the UAC and the domain that owns the URI. From there, secure communications are used to reach the user, where the specific security mechanism depends on the policy of the domain. Any resource described by a SIP URI can be ""upgraded"" to a SIPS URI by just changing the scheme, if it is desired to communicate with that resource securely. 19.1.1 SIP and SIPS URI Components The ""sip:"" and ""sips:"" schemes follow the guidelines in RFC 2396 [5]. They use a form similar to the mailto URL, allowing the specification of SIP request-header fields and the SIP message-body. This makes it possible to specify the subject, media type, or urgency of sessions initiated by using a URI on a web page or in an email message. The formal syntax for a SIP or SIPS URI is presented in Section 25. Its general form, in the case of a SIP URI, is: sip:user:password@host:port;uri-parameters?headers The format for a SIPS URI is the same, except that the scheme is ""sips"" instead of sip. These tokens, and some of the tokens in their expansions, have the following meanings: user: The identifier of a particular resource at the host being addressed. The term ""host"" in this context frequently refers to a domain. The ""userinfo"" of a URI consists of this user field, the password field, and the @ sign following them. The userinfo part of a URI is optional and MAY be absent when the Rosenberg, et. al. Standards Track [Page 148] RFC 3261 SIP: Session Initiation Protocol June 2002 destination host does not have a notion of users or when the host itself is the resource being identified. If the @ sign is present in a SIP or SIPS URI, the user field MUST NOT be empty. If the host being addressed can process telephone numbers, for instance, an Internet telephony gateway, a telephone- subscriber field defined in RFC 2806 [9] MAY be used to populate the user field. There are special escaping rules for encoding telephone-subscriber fields in SIP and SIPS URIs described in Section 19.1.2. password: A password associated with the user. While the SIP and SIPS URI syntax allows this field to be present, its use is NOT RECOMMENDED, because the passing of authentication information in clear text (such as URIs) has proven to be a security risk in almost every case where it has been used. For instance, transporting a PIN number in this field exposes the PIN. Note that the password field is just an extension of the user portion. Implementations not wishing to give special significance to the password portion of the field MAY simply treat ""user:password"" as a single string. host: The host providing the SIP resource. The host part contains either a fully-qualified domain name or numeric IPv4 or IPv6 address. Using the fully-qualified domain name form is RECOMMENDED whenever possible. port: The port number where the request is to be sent. URI parameters: Parameters affecting a request constructed from the URI. URI parameters are added after the hostport component and are separated by semi-colons. URI parameters take the form: parameter-name ""="" parameter-value Even though an arbitrary number of URI parameters may be included in a URI, any given parameter-name MUST NOT appear more than once. This extensible mechanism includes the transport, maddr, ttl, user, method and lr parameters. Rosenberg, et. al. Standards Track [Page 149] RFC 3261 SIP: Session Initiation Protocol June 2002 The transport parameter determines the transport mechanism to be used for sending SIP messages, as specified in [4]. SIP can use any network transport protocol. Parameter names are defined for UDP (RFC 768 [14]), TCP (RFC 761 [15]), and SCTP (RFC 2960 [16]). For a SIPS URI, the transport parameter MUST indicate a reliable transport. The maddr parameter indicates the server address to be contacted for this user, overriding any address derived from the host field. When an maddr parameter is present, the port and transport components of the URI apply to the address indicated in the maddr parameter value. [4] describes the proper interpretation of the transport, maddr, and hostport in order to obtain the destination address, port, and transport for sending a request. The maddr field has been used as a simple form of loose source routing. It allows a URI to specify a proxy that must be traversed en-route to the destination. Continuing to use the maddr parameter this way is strongly discouraged (the mechanisms that enable it are deprecated). Implementations should instead use the Route mechanism described in this document, establishing a pre-existing route set if necessary (see Section 8.1.1.1). This provides a full URI to describe the node to be traversed. The ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP. For example, to specify a call to alice@atlanta.com using multicast to 239.255.255.1 with a ttl of 15, the following URI would be used: sip:alice@atlanta.com;maddr=239.255.255.1;ttl=15 The set of valid telephone-subscriber strings is a subset of valid user strings. The user URI parameter exists to distinguish telephone numbers from user names that happen to look like telephone numbers. If the user string contains a telephone number formatted as a telephone-subscriber, the user parameter value ""phone"" SHOULD be present. Even without this parameter, recipients of SIP and SIPS URIs MAY interpret the pre-@ part as a telephone number if local restrictions on the name space for user name allow it. The method of the SIP request constructed from the URI can be specified with the method parameter. Rosenberg, et. al. Standards Track [Page 150] RFC 3261 SIP: Session Initiation Protocol June 2002 The lr parameter, when present, indicates that the element responsible for this resource implements the routing mechanisms specified in this document. This parameter will be used in the URIs proxies place into Record-Route header field values, and may appear in the URIs in a pre-existing route set. This parameter is used to achieve backwards compatibility with systems implementing the strict-routing mechanisms of RFC 2543 and the rfc2543bis drafts up to bis-05. An element preparing to send a request based on a URI not containing this parameter can assume the receiving element implements strict-routing and reformat the message to preserve the information in the Request-URI. Since the uri-parameter mechanism is extensible, SIP elements MUST silently ignore any uri-parameters that they do not understand. Headers: Header fields to be included in a request constructed from the URI. Headers fields in the SIP request can be specified with the ""?"" mechanism within a URI. The header names and values are encoded in ampersand separated hname = hvalue pairs. The special hname ""body"" indicates that the associated hvalue is the message-body of the SIP request. Table 1 summarizes the use of SIP and SIPS URI components based on the context in which the URI appears. The external column describes URIs appearing anywhere outside of a SIP message, for instance on a web page or business card. Entries marked ""m"" are mandatory, those marked ""o"" are optional, and those marked ""-"" are not allowed. Elements processing URIs SHOULD ignore any disallowed components if they are present. The second column indicates the default value of an optional element if it is not present. ""--"" indicates that the element is either not optional, or has no default value. URIs in Contact header fields have different restrictions depending on the context in which the header field appears. One set applies to messages that establish and maintain dialogs (INVITE and its 200 (OK) response). The other applies to registration and redirection messages (REGISTER, its 200 (OK) response, and 3xx class responses to any method). Rosenberg, et. al. Standards Track [Page 151] RFC 3261 SIP: Session Initiation Protocol June 2002 19.1.2 Character Escaping Requirements dialog reg./redir. Contact/ default Req.-URI To From Contact R-R/Route external user -- o o o o o o password -- o o o o o o host -- m m m m m m port (1) o - - o o o user-param ip o o o o o o method INVITE - - - - - o maddr-param -- o - - o o o ttl-param 1 o - - o - o transp.-param (2) o - - o o o lr-param -- o - - - o o other-param -- o o o o o o headers -- - - - o - o (1): The default port value is transport and scheme dependent. The default is 5060 for sip: using UDP, TCP, or SCTP. The default is 5061 for sip: using TLS over TCP and sips: over TCP. (2): The default transport is scheme dependent. For sip:, it is UDP. For sips:, it is TCP. Table 1: Use and default values of URI components for SIP header field values, Request-URI and references SIP follows the requirements and guidelines of RFC 2396 [5] when defining the set of characters that must be escaped in a SIP URI, and uses its """"%"" HEX HEX"" mechanism for escaping. From RFC 2396 [5]: The set of characters actually reserved within any given URI component is defined by that component. In general, a character is reserved if the semantics of the URI changes if the character is replaced with its escaped US-ASCII encoding [5]. Excluded US- ASCII characters (RFC 2396 [5]), such as space and control characters and characters used as URI delimiters, also MUST be escaped. URIs MUST NOT contain unescaped space and control characters. For each component, the set of valid BNF expansions defines exactly which characters may appear unescaped. All other characters MUST be escaped. For example, ""@"" is not in the set of characters in the user component, so the user ""j@s0n"" must have at least the @ sign encoded, as in ""j%40s0n"". Rosenberg, et. al. Standards Track [Page 152] RFC 3261 SIP: Session Initiation Protocol June 2002 Expanding the hname and hvalue tokens in Section 25 show that all URI reserved characters in header field names and values MUST be escaped. The telephone-subscriber subset of the user component has special escaping considerations. The set of characters not reserved in the RFC 2806 [9] description of telephone-subscriber contains a number of characters in various syntax elements that need to be escaped when used in SIP URIs. Any characters occurring in a telephone-subscriber that do not appear in an expansion of the BNF for the user rule MUST be escaped. Note that character escaping is not allowed in the host component of a SIP or SIPS URI (the % character is not valid in its expansion). This is likely to change in the future as requirements for Internationalized Domain Names are finalized. Current implementations MUST NOT attempt to improve robustness by treating received escaped characters in the host component as literally equivalent to their unescaped counterpart. The behavior required to meet the requirements of IDN may be significantly different. 19.1.3 Example SIP and SIPS URIs sip:alice@atlanta.com sip:alice:secretword@atlanta.com;transport=tcp sips:alice@atlanta.com?subject=project%20x&priority=urgent sip:+1-212-555-1212:1234@gateway.com;user=phone sips:1212@gateway.com sip:alice@192.0.2.4 sip:atlanta.com;method=REGISTER?to=alice%40atlanta.com sip:alice;day=tuesday@atlanta.com The last sample URI above has a user field value of ""alice;day=tuesday"". The escaping rules defined above allow a semicolon to appear unescaped in this field. For the purposes of this protocol, the field is opaque. The structure of that value is only useful to the SIP element responsible for the resource. 19.1.4 URI Comparison Some operations in this specification require determining whether two SIP or SIPS URIs are equivalent. In this specification, registrars need to compare bindings in Contact URIs in REGISTER requests (see Section 10.3.). SIP and SIPS URIs are compared for equality according to the following rules: o A SIP and SIPS URI are never equivalent. Rosenberg, et. al. Standards Track [Page 153] RFC 3261 SIP: Session Initiation Protocol June 2002 o Comparison of the userinfo of SIP and SIPS URIs is case- sensitive. This includes userinfo containing passwords or formatted as telephone-subscribers. Comparison of all other components of the URI is case-insensitive unless explicitly defined otherwise. o The ordering of parameters and header fields is not significant in comparing SIP and SIPS URIs. o Characters other than those in the ""reserved"" set (see RFC 2396 [5]) are equivalent to their """"%"" HEX HEX"" encoding. o An IP address that is the result of a DNS lookup of a host name does not match that host name. o For two URIs to be equal, the user, password, host, and port components must match. A URI omitting the user component will not match a URI that includes one. A URI omitting the password component will not match a URI that includes one. A URI omitting any component with a default value will not match a URI explicitly containing that component with its default value. For instance, a URI omitting the optional port component will not match a URI explicitly declaring port 5060. The same is true for the transport-parameter, ttl-parameter, user-parameter, and method components. Defining sip:user@host to not be equivalent to sip:user@host:5060 is a change from RFC 2543. When deriving addresses from URIs, equivalent addresses are expected from equivalent URIs. The URI sip:user@host:5060 will always resolve to port 5060. The URI sip:user@host may resolve to other ports through the DNS SRV mechanisms detailed in [4]. o URI uri-parameter components are compared as follows: - Any uri-parameter appearing in both URIs must match. - A user, ttl, or method uri-parameter appearing in only one URI never matches, even if it contains the default value. - A URI that includes an maddr parameter will not match a URI that contains no maddr parameter. - All other uri-parameters appearing in only one URI are ignored when comparing the URIs. Rosenberg, et. al. Standards Track [Page 154] RFC 3261 SIP: Session Initiation Protocol June 2002 o URI header components are never ignored. Any present header component MUST be present in both URIs and match for the URIs to match. The matching rules are defined for each header field in Section 20. The URIs within each of the following sets are equivalent: sip:%61lice@atlanta.com;transport=TCP sip:alice@AtLanTa.CoM;Transport=tcp sip:carol@chicago.com sip:carol@chicago.com;newparam=5 sip:carol@chicago.com;security=on sip:biloxi.com;transport=tcp;method=REGISTER?to=sip:bob%40biloxi.com sip:biloxi.com;method=REGISTER;transport=tcp?to=sip:bob%40biloxi.com sip:alice@atlanta.com?subject=project%20x&priority=urgent sip:alice@atlanta.com?priority=urgent&subject=project%20x The URIs within each of the following sets are not equivalent: SIP:ALICE@AtLanTa.CoM;Transport=udp (different usernames) sip:alice@AtLanTa.CoM;Transport=UDP sip:bob@biloxi.com (can resolve to different ports) sip:bob@biloxi.com:5060 sip:bob@biloxi.com (can resolve to different transports) sip:bob@biloxi.com;transport=udp sip:bob@biloxi.com (can resolve to different port and transports) sip:bob@biloxi.com:6000;transport=tcp sip:carol@chicago.com (different header component) sip:carol@chicago.com?Subject=next%20meeting sip:bob@phone21.boxesbybob.com (even though that's what sip:bob@192.0.2.4 phone21.boxesbybob.com resolves to) Note that equality is not transitive: o sip:carol@chicago.com and sip:carol@chicago.com;security=on are equivalent o sip:carol@chicago.com and sip:carol@chicago.com;security=off are equivalent Rosenberg, et. al. Standards Track [Page 155] RFC 3261 SIP: Session Initiation Protocol June 2002 o sip:carol@chicago.com;security=on and sip:carol@chicago.com;security=off are not equivalent 19.1.5 Forming Requests from a URI An implementation needs to take care when forming requests directly from a URI. URIs from business cards, web pages, and even from sources inside the protocol such as registered contacts may contain inappropriate header fields or body parts. An implementation MUST include any provided transport, maddr, ttl, or user parameter in the Request-URI of the formed request. If the URI contains a method parameter, its value MUST be used as the method of the request. The method parameter MUST NOT be placed in the Request-URI. Unknown URI parameters MUST be placed in the message's Request-URI. An implementation SHOULD treat the presence of any headers or body parts in the URI as a desire to include them in the message, and choose to honor the request on a per-component basis. An implementation SHOULD NOT honor these obviously dangerous header fields: From, Call-ID, CSeq, Via, and Record-Route. An implementation SHOULD NOT honor any requested Route header field values in order to not be used as an unwitting agent in malicious attacks. An implementation SHOULD NOT honor requests to include header fields that may cause it to falsely advertise its location or capabilities. These include: Accept, Accept-Encoding, Accept-Language, Allow, Contact (in its dialog usage), Organization, Supported, and User- Agent. An implementation SHOULD verify the accuracy of any requested descriptive header fields, including: Content-Disposition, Content- Encoding, Content-Language, Content-Length, Content-Type, Date, Mime-Version, and Timestamp. If the request formed from constructing a message from a given URI is not a valid SIP request, the URI is invalid. An implementation MUST NOT proceed with transmitting the request. It should instead pursue the course of action due an invalid URI in the context it occurs. The constructed request can be invalid in many ways. These include, but are not limited to, syntax error in header fields, invalid combinations of URI parameters, or an incorrect description of the message body. Rosenberg, et. al. Standards Track [Page 156] RFC 3261 SIP: Session Initiation Protocol June 2002 Sending a request formed from a given URI may require capabilities unavailable to the implementation. The URI might indicate use of an unimplemented transport or extension, for example. An implementation SHOULD refuse to send these requests rather than modifying them to match their capabilities. An implementation MUST NOT send a request requiring an extension that it does not support. For example, such a request can be formed through the presence of a Require header parameter or a method URI parameter with an unknown or explicitly unsupported value. 19.1.6 Relating SIP URIs and tel URLs When a tel URL (RFC 2806 [9]) is converted to a SIP or SIPS URI, the entire telephone-subscriber portion of the tel URL, including any parameters, is placed into the userinfo part of the SIP or SIPS URI. Thus, tel:+358-555-1234567;postd=pp22 becomes sip:+358-555-1234567;postd=pp22@foo.com;user=phone or sips:+358-555-1234567;postd=pp22@foo.com;user=phone not sip:+358-555-1234567@foo.com;postd=pp22;user=phone or sips:+358-555-1234567@foo.com;postd=pp22;user=phone In general, equivalent ""tel"" URLs converted to SIP or SIPS URIs in this fashion may not produce equivalent SIP or SIPS URIs. The userinfo of SIP and SIPS URIs are compared as a case-sensitive string. Variance in case-insensitive portions of tel URLs and reordering of tel URL parameters does not affect tel URL equivalence, but does affect the equivalence of SIP URIs formed from them. For example, tel:+358-555-1234567;postd=pp22 tel:+358-555-1234567;POSTD=PP22 are equivalent, while sip:+358-555-1234567;postd=pp22@foo.com;user=phone sip:+358-555-1234567;POSTD=PP22@foo.com;user=phone Rosenberg, et. al. Standards Track [Page 157] RFC 3261 SIP: Session Initiation Protocol June 2002 are not. Likewise, tel:+358-555-1234567;postd=pp22;isub=1411 tel:+358-555-1234567;isub=1411;postd=pp22 are equivalent, while sip:+358-555-1234567;postd=pp22;isub=1411@foo.com;user=phone sip:+358-555-1234567;isub=1411;postd=pp22@foo.com;user=phone are not. To mitigate this problem, elements constructing telephone-subscriber fields to place in the userinfo part of a SIP or SIPS URI SHOULD fold any case-insensitive portion of telephone-subscriber to lower case, and order the telephone-subscriber parameters lexically by parameter name, excepting isdn-subaddress and post-dial, which occur first and in that order. (All components of a tel URL except for future- extension parameters are defined to be compared case-insensitive.) Following this suggestion, both tel:+358-555-1234567;postd=pp22 tel:+358-555-1234567;POSTD=PP22 become sip:+358-555-1234567;postd=pp22@foo.com;user=phone and both tel:+358-555-1234567;tsp=a.b;phone-context=5 tel:+358-555-1234567;phone-context=5;tsp=a.b become sip:+358-555-1234567;phone-context=5;tsp=a.b@foo.com;user=phone 19.2 Option Tags Option tags are unique identifiers used to designate new options (extensions) in SIP. These tags are used in Require (Section 20.32), Proxy-Require (Section 20.29), Supported (Section 20.37) and Unsupported (Section 20.40) header fields. Note that these options appear as parameters in those header fields in an option-tag = token form (see Section 25 for the definition of token). Rosenberg, et. al. Standards Track [Page 158] RFC 3261 SIP: Session Initiation Protocol June 2002 Option tags are defined in standards track RFCs. This is a change from past practice, and is instituted to ensure continuing multi- vendor interoperability (see discussion in Section 20.32 and Section 20.37). An IANA registry of option tags is used to ensure easy reference. 19.3 Tags The ""tag"" parameter is used in the To and From header fields of SIP messages. It serves as a general mechanism to identify a dialog, which is the combination of the Call-ID along with two tags, one from each participant in the dialog. When a UA sends a request outside of a dialog, it contains a From tag only, providing ""half"" of the dialog ID. The dialog is completed from the response(s), each of which contributes the second half in the To header field. The forking of SIP requests means that multiple dialogs can be established from a single request. This also explains the need for the two-sided dialog identifier; without a contribution from the recipients, the originator could not disambiguate the multiple dialogs established from a single request. When a tag is generated by a UA for insertion into a request or response, it MUST be globally unique and cryptographically random with at least 32 bits of randomness. A property of this selection requirement is that a UA will place a different tag into the From header of an INVITE than it would place into the To header of the response to the same INVITE. This is needed in order for a UA to invite itself to a session, a common case for ""hairpinning"" of calls in PSTN gateways. Similarly, two INVITEs for different calls will have different From tags, and two responses for different calls will have different To tags. Besides the requirement for global uniqueness, the algorithm for generating a tag is implementation-specific. Tags are helpful in fault tolerant systems, where a dialog is to be recovered on an alternate server after a failure. A UAS can select the tag in such a way that a backup can recognize a request as part of a dialog on the failed server, and therefore determine that it should attempt to recover the dialog and any other state associated with it. 20 Header Fields The general syntax for header fields is covered in Section 7.3. This section lists the full set of header fields along with notes on syntax, meaning, and usage. Throughout this section, we use [HX.Y] to refer to Section X.Y of the current HTTP/1.1 specification RFC 2616 [8]. Examples of each header field are given. Rosenberg, et. al. Standards Track [Page 159] RFC 3261 SIP: Session Initiation Protocol June 2002 Information about header fields in relation to methods and proxy processing is summarized in Tables 2 and 3. The ""where"" column describes the request and response types in which the header field can be used. Values in this column are: R: header field may only appear in requests; r: header field may only appear in responses; 2xx, 4xx, etc.: A numerical value or range indicates response codes with which the header field can be used; c: header field is copied from the request to the response. An empty entry in the ""where"" column indicates that the header field may be present in all requests and responses. The ""proxy"" column describes the operations a proxy may perform on a header field: a: A proxy can add or concatenate the header field if not present. m: A proxy can modify an existing header field value. d: A proxy can delete a header field value. r: A proxy must be able to read the header field, and thus this header field cannot be encrypted. The next six columns relate to the presence of a header field in a method: c: Conditional; requirements on the header field depend on the context of the message. m: The header field is mandatory. m*: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. o: The header field is optional. t: The header field SHOULD be sent, but clients/servers need to be prepared to receive messages without that header field. If a stream-based protocol (such as TCP) is used as a transport, then the header field MUST be sent. Rosenberg, et. al. Standards Track [Page 160] RFC 3261 SIP: Session Initiation Protocol June 2002 *: The header field is required if the message body is not empty. See Sections 20.14, 20.15 and 7.4 for details. -: The header field is not applicable. ""Optional"" means that an element MAY include the header field in a request or response, and a UA MAY ignore the header field if present in the request or response (The exception to this rule is the Require header field discussed in 20.32). A ""mandatory"" header field MUST be present in a request, and MUST be understood by the UAS receiving the request."
"A mandatory response header field MUST be present in the response, and the header field MUST be understood by the UAC processing the response. ""Not applicable"" means that the header field MUST NOT be present in a request. If one is placed in a request by mistake, it MUST be ignored by the UAS receiving the request. Similarly, a header field labeled ""not applicable"" for a response means that the UAS MUST NOT place the header field in the response, and the UAC MUST ignore the header field in the response. A UA SHOULD ignore extension header parameters that are not understood. A compact form of some common header field names is also defined for use when overall message size is an issue. The Contact, From, and To header fields contain a URI. If the URI contains a comma, question mark or semicolon, the URI MUST be enclosed in angle brackets (< and >). Any URI parameters are contained within these brackets. If the URI is not enclosed in angle brackets, any semicolon-delimited parameters are header-parameters, not URI parameters. 20.1 Accept The Accept header field follows the syntax defined in [H14.1]. The semantics are also identical, with the exception that if no Accept header field is present, the server SHOULD assume a default value of application/sdp. An empty Accept header field means that no formats are acceptable. Rosenberg, et. al. Standards Track [Page 161] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________ Accept R - o - o m* o Accept 2xx - - - o m* o Accept 415 - c - c c c Accept-Encoding R - o - o o o Accept-Encoding 2xx - - - o m* o Accept-Encoding 415 - c - c c c Accept-Language R - o - o o o Accept-Language 2xx - - - o m* o Accept-Language 415 - c - c c c Alert-Info R ar - - - o - - Alert-Info 180 ar - - - o - - Allow R - o - o o o Allow 2xx - o - m* m* o Allow r - o - o o o Allow 405 - m - m m m Authentication-Info 2xx - o - o o o Authorization R o o o o o o Call-ID c r m m m m m m Call-Info ar - - - o o o Contact R o - - m o o Contact 1xx - - - o - - Contact 2xx - - - m o o Contact 3xx d - o - o o o Contact 485 - o - o o o Content-Disposition o o - o o o Content-Encoding o o - o o o Content-Language o o - o o o Content-Length ar t t t t t t Content-Type * * - * * * CSeq c r m m m m m m Date a o o o o o o Error-Info 300-699 a - o o o o o Expires - - - o - o From c r m m m m m m In-Reply-To R - - - o - - Max-Forwards R amr m m m m m m Min-Expires 423 - - - - - m MIME-Version o o - o o o Organization ar - - - o o o Table 2: Summary of header fields, A--O Rosenberg, et. al. Standards Track [Page 162] RFC 3261 SIP: Session Initiation Protocol June 2002 Header field where proxy ACK BYE CAN INV OPT REG ___________________________________________________________________ Priority R ar - - - o - - Proxy-Authenticate 407 ar - m - m m m Proxy-Authenticate 401 ar - o o o o o Proxy-Authorization R dr o o - o o o Proxy-Require R ar - o - o o o Record-Route R ar o o o o o - Record-Route 2xx,18x mr - o o o o - Reply-To - - - o - - Require ar - c - c c c Retry-After 404,413,480,486 - o o o o o 500,503 - o o o o o 600,603 - o o o o o Route R adr c c c c c c Server r - o o o o o Subject R - - - o - - Supported R - o o m* o o Supported 2xx - o o m* m* o Timestamp o o o o o o To c(1) r m m m m m m Unsupported 420 - m - m m m User-Agent o o o o o o Via R amr m m m m m m Via rc dr m m m m m m Warning r - o o o o o WWW-Authenticate 401 ar - m - m m m WWW-Authenticate 407 ar - o - o o o Table 3: Summary of header fields, P--Z; (1): copied with possible addition of tag Accept: application/sdp;level=1, application/x-private, text/html 20.2 Accept-Encoding The Accept-Encoding header field is similar to Accept, but restricts the content-codings [H3.5] that are acceptable in the response. See [H14.3]. The semantics in SIP are identical to those defined in [H14.3]. An empty Accept-Encoding header field is permissible. It is equivalent to Accept-Encoding: identity, that is, only the identity encoding, meaning no encoding, is permissible. If no Accept-Encoding header field is present, the server SHOULD assume a default value of identity. Rosenberg, et. al. Standards Track [Page 163] RFC 3261 SIP: Session Initiation Protocol June 2002 This differs slightly from the HTTP definition, which indicates that when not present, any encoding can be used, but the identity encoding is preferred. Example: Accept-Encoding: gzip 20.3 Accept-Language The Accept-Language header field is used in requests to indicate the preferred languages for reason phrases, session descriptions, or status responses carried as message bodies in the response. If no Accept-Language header field is present, the server SHOULD assume all languages are acceptable to the client. The Accept-Language header field follows the syntax defined in [H14.4]. The rules for ordering the languages based on the ""q"" parameter apply to SIP as well. Example: Accept-Language: da, en-gb;q=0.8, en;q=0.7 20.4 Alert-Info When present in an INVITE request, the Alert-Info header field specifies an alternative ring tone to the UAS. When present in a 180 (Ringing) response, the Alert-Info header field specifies an alternative ringback tone to the UAC. A typical usage is for a proxy to insert this header field to provide a distinctive ring feature. The Alert-Info header field can introduce security risks. These risks and the ways to handle them are discussed in Section 20.9, which discusses the Call-Info header field since the risks are identical. In addition, a user SHOULD be able to disable this feature selectively. This helps prevent disruptions that could result from the use of this header field by untrusted elements. Example: Alert-Info: <http://www.example.com/sounds/moo.wav> Rosenberg, et. al. Standards Track [Page 164] RFC 3261 SIP: Session Initiation Protocol June 2002 20.5 Allow The Allow header field lists the set of methods supported by the UA generating the message. All methods, including ACK and CANCEL, understood by the UA MUST be included in the list of methods in the Allow header field, when present. The absence of an Allow header field MUST NOT be interpreted to mean that the UA sending the message supports no methods. Rather, it implies that the UA is not providing any information on what methods it supports. Supplying an Allow header field in responses to methods other than OPTIONS reduces the number of messages needed. Example: Allow: INVITE, ACK, OPTIONS, CANCEL, BYE 20.6 Authentication-Info The Authentication-Info header field provides for mutual authentication with HTTP Digest. A UAS MAY include this header field in a 2xx response to a request that was successfully authenticated using digest based on the Authorization header field. Syntax and semantics follow those specified in RFC 2617 [17]. Example: Authentication-Info: nextnonce=""47364c23432d2e131a5fb210812c"" 20.7 Authorization The Authorization header field contains authentication credentials of a UA. Section 22.2 overviews the use of the Authorization header field, and Section 22.4 describes the syntax and semantics when used with HTTP authentication. This header field, along with Proxy-Authorization, breaks the general rules about multiple header field values. Although not a comma- separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line using the usual rules described in Section 7.3. Rosenberg, et. al. Standards Track [Page 165] RFC 3261 SIP: Session Initiation Protocol June 2002 In the example below, there are no quotes around the Digest parameter: Authorization: Digest username=""Alice"", realm=""atlanta.com"", nonce=""84a4cc6f3082121f32b42a2187831a9e"", response=""7587245234b3434cc3412213e5f113a5432"" 20.8 Call-ID The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte. The compact form of the Call-ID header field is i. Examples: Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4 20.9 Call-Info The Call-Info header field provides additional information about the caller or callee, depending on whether it is found in a request or response. The purpose of the URI is described by the ""purpose"" parameter. The ""icon"" parameter designates an image suitable as an iconic representation of the caller or callee. The ""info"" parameter describes the caller or callee in general, for example, through a web page. The ""card"" parameter provides a business card, for example, in vCard [36] or LDIF [37] formats. Additional tokens can be registered using IANA and the procedures in Section 27. Use of the Call-Info header field can pose a security risk. If a callee fetches the URIs provided by a malicious caller, the callee may be at risk for displaying inappropriate or offensive content, dangerous or illegal content, and so on. Therefore, it is RECOMMENDED that a UA only render the information in the Call-Info header field if it can verify the authenticity of the element that originated the header field and trusts that element. This need not be the peer UA; a proxy can insert this header field into requests. Example: Call-Info: <http://wwww.example.com/alice/photo.jpg> ;purpose=icon, <http://www.example.com/alice/> ;purpose=info Rosenberg, et. al. Standards Track [Page 166] RFC 3261 SIP: Session Initiation Protocol June 2002 20.10 Contact A Contact header field value provides a URI whose meaning depends on the type of request or response it is in. A Contact header field value can contain a display name, a URI with URI parameters, and header parameters. This document defines the Contact parameters ""q"" and ""expires"". These parameters are only used when the Contact is present in a REGISTER request or response, or in a 3xx response. Additional parameters may be defined in other specifications. When the header field value contains a display name, the URI including all URI parameters is enclosed in ""<"" and "">"". If no ""<"" and "">"" are present, all parameters after the URI are header parameters, not URI parameters. The display name can be tokens, or a quoted string, if a larger character set is desired. Even if the ""display-name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, semicolon, or question mark. There may or may not be LWS between the display-name and the ""<"". These rules for parsing a display name, URI and URI parameters, and header parameters also apply for the header fields To and From. The Contact header field has a role similar to the Location header field in HTTP. However, the HTTP header field only allows one address, unquoted. Since URIs can contain commas and semicolons as reserved characters, they can be mistaken for header or parameter delimiters, respectively. The compact form of the Contact header field is m (for ""moved""). Examples: Contact: ""Mr. Watson"" <sip:watson@worcester.bell-telephone.com> ;q=0.7; expires=3600, ""Mr. Watson"" <mailto:watson@bell-telephone.com> ;q=0.1 m: <sips:bob@192.0.2.4>;expires=60 Rosenberg, et. al. Standards Track [Page 167] RFC 3261 SIP: Session Initiation Protocol June 2002 20.11 Content-Disposition The Content-Disposition header field describes how the message body or, for multipart messages, a message body part is to be interpreted by the UAC or UAS. This SIP header field extends the MIME Content- Type (RFC 2183 [18]). Several new ""disposition-types"" of the Content-Disposition header are defined by SIP. The value ""session"" indicates that the body part describes a session, for either calls or early (pre-call) media. The value ""render"" indicates that the body part should be displayed or otherwise rendered to the user. Note that the value ""render"" is used rather than ""inline"" to avoid the connotation that the MIME body is displayed as a part of the rendering of the entire message (since the MIME bodies of SIP messages oftentimes are not displayed to users). For backward-compatibility, if the Content-Disposition header field is missing, the server SHOULD assume bodies of Content-Type application/sdp are the disposition ""session"", while other content types are ""render"". The disposition type ""icon"" indicates that the body part contains an image suitable as an iconic representation of the caller or callee that could be rendered informationally by a user agent when a message has been received, or persistently while a dialog takes place. The value ""alert"" indicates that the body part contains information, such as an audio clip, that should be rendered by the user agent in an attempt to alert the user to the receipt of a request, generally a request that initiates a dialog; this alerting body could for example be rendered as a ring tone for a phone call after a 180 Ringing provisional response has been sent. Any MIME body with a ""disposition-type"" that renders content to the user should only be processed when a message has been properly authenticated. The handling parameter, handling-param, describes how the UAS should react if it receives a message body whose content type or disposition type it does not understand. The parameter has defined values of ""optional"" and ""required"". If the handling parameter is missing, the value ""required"" SHOULD be assumed. The handling parameter is described in RFC 3204 [19]. If this header field is missing, the MIME type determines the default content disposition. If there is none, ""render"" is assumed. Example: Content-Disposition: session Rosenberg, et. al. Standards Track [Page 168] RFC 3261 SIP: Session Initiation Protocol June 2002 20.12 Content-Encoding The Content-Encoding header field is used as a modifier to the ""media-type"". When present, its value indicates what additional content codings have been applied to the entity-body, and thus what decoding mechanisms MUST be applied in order to obtain the media-type referenced by the Content-Type header field. Content-Encoding is primarily used to allow a body to be compressed without losing the identity of its underlying media type. If multiple encodings have been applied to an entity-body, the content codings MUST be listed in the order in which they were applied. All content-coding values are case-insensitive. IANA acts as a registry for content-coding value tokens. See [H3.5] for a definition of the syntax for content-coding. Clients MAY apply content encodings to the body in requests. A server MAY apply content encodings to the bodies in responses. The server MUST only use encodings listed in the Accept-Encoding header field in the request. The compact form of the Content-Encoding header field is e. Examples: Content-Encoding: gzip e: tar 20.13 Content-Language See [H14.12]. Example: Content-Language: fr 20.14 Content-Length The Content-Length header field indicates the size of the message- body, in decimal number of octets, sent to the recipient. Applications SHOULD use this field to indicate the size of the message-body to be transferred, regardless of the media type of the entity. If a stream-based protocol (such as TCP) is used as transport, the header field MUST be used. The size of the message-body does not include the CRLF separating header fields and body. Any Content-Length greater than or equal to zero is a valid value. If no body is present in a message, then the Content-Length header field value MUST be set to zero. Rosenberg, et. al. Standards Track [Page 169] RFC 3261 SIP: Session Initiation Protocol June 2002 The ability to omit Content-Length simplifies the creation of cgi-like scripts that dynamically generate responses. The compact form of the header field is l. Examples: Content-Length: 349 l: 173 20.15 Content-Type The Content-Type header field indicates the media type of the message-body sent to the recipient. The ""media-type"" element is defined in [H3.7]. The Content-Type header field MUST be present if the body is not empty. If the body is empty, and a Content-Type header field is present, it indicates that the body of the specific type has zero length (for example, an empty audio file). The compact form of the header field is c. Examples: Content-Type: application/sdp c: text/html; charset=ISO-8859-4 20.16 CSeq A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical. Example: CSeq: 4711 INVITE 20.17 Date The Date header field contains the date and time. Unlike HTTP/1.1, SIP only supports the most recent RFC 1123 [20] format for dates. As in [H3.3], SIP restricts the time zone in SIP-date to ""GMT"", while RFC 1123 allows any time zone. An RFC 1123 date is case-sensitive. The Date header field reflects the time when the request or response is first sent. Rosenberg, et. al. Standards Track [Page 170] RFC 3261 SIP: Session Initiation Protocol June 2002 The Date header field can be used by simple end systems without a battery-backed clock to acquire a notion of current time. However, in its GMT form, it requires clients to know their offset from GMT. Example: Date: Sat, 13 Nov 2010 23:29:00 GMT 20.18 Error-Info The Error-Info header field provides a pointer to additional information about the error status response. SIP UACs have user interface capabilities ranging from pop-up windows and audio on PC softclients to audio-only on ""black"" phones or endpoints connected via gateways. Rather than forcing a server generating an error to choose between sending an error status code with a detailed reason phrase and playing an audio recording, the Error-Info header field allows both to be sent. The UAC then has the choice of which error indicator to render to the caller. A UAC MAY treat a SIP or SIPS URI in an Error-Info header field as if it were a Contact in a redirect and generate a new INVITE, resulting in a recorded announcement session being established. A non-SIP URI MAY be rendered to the user. Examples: SIP/2.0 404 The number you have dialed is not in service Error-Info: <sip:not-in-service-recording@atlanta.com> 20.19 Expires The Expires header field gives the relative time after which the message (or content) expires. The precise meaning of this is method dependent. The expiration time in an INVITE does not affect the duration of the actual session that may result from the invitation. Session description protocols may offer the ability to express time limits on the session duration, however. The value of this field is an integral number of seconds (in decimal) between 0 and (2**32)-1, measured from the receipt of the request. Rosenberg, et. al. Standards Track [Page 171] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Expires: 5 20.20 From The From header field indicates the initiator of the request. This may be different from the initiator of the dialog. Requests sent by the callee to the caller use the callee's address in the From header field. The optional ""display-name"" is meant to be rendered by a human user interface. A system SHOULD use the display name ""Anonymous"" if the identity of the client is to remain hidden. Even if the ""display- name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. Two From header fields are equivalent if their URIs match, and their parameters match. Extension parameters in one header field, not present in the other are ignored for the purposes of comparison. This means that the display name and presence or absence of angle brackets do not affect matching. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters. The compact form of the From header field is f. Examples: From: ""A. G. Bell"" <sip:agb@bell-telephone.com> ;tag=a48s From: sip:+12125551212@server.phone2net.com;tag=887s f: Anonymous <sip:c8oqz84zk7z@privacy.org>;tag=hyh8 20.21 In-Reply-To The In-Reply-To header field enumerates the Call-IDs that this call references or returns. These Call-IDs may have been cached by the client then included in this header field in a return call. This allows automatic call distribution systems to route return calls to the originator of the first call. This also allows callees to filter calls, so that only return calls for calls they originated will be accepted. This field is not a substitute for request authentication. Rosenberg, et. al. Standards Track [Page 172] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: In-Reply-To: 70710@saturn.bell-tel.com, 17320@saturn.bell-tel.com 20.22 Max-Forwards The Max-Forwards header field must be used with any SIP method to limit the number of proxies or gateways that can forward the request to the next downstream server. This can also be useful when the client is attempting to trace a request chain that appears to be failing or looping in mid-chain. The Max-Forwards value is an integer in the range 0-255 indicating the remaining number of times this request message is allowed to be forwarded. This count is decremented by each server that forwards the request. The recommended initial value is 70. This header field should be inserted by elements that can not otherwise guarantee loop detection. For example, a B2BUA should insert a Max-Forwards header field. Example: Max-Forwards: 6 20.23 Min-Expires The Min-Expires header field conveys the minimum refresh interval supported for soft-state elements managed by that server. This includes Contact header fields that are stored by a registrar. The header field contains a decimal integer number of seconds from 0 to (2**32)-1. The use of the header field in a 423 (Interval Too Brief) response is described in Sections 10.2.8, 10.3, and 21.4.17. Example: Min-Expires: 60 20.24 MIME-Version See [H19.4.1]. Example: MIME-Version: 1.0 Rosenberg, et. al. Standards Track [Page 173] RFC 3261 SIP: Session Initiation Protocol June 2002 20.25 Organization The Organization header field conveys the name of the organization to which the SIP element issuing the request or response belongs. The field MAY be used by client software to filter calls. Example: Organization: Boxes by Bob 20.26 Priority The Priority header field indicates the urgency of the request as perceived by the client. The Priority header field describes the priority that the SIP request should have to the receiving human or its agent. For example, it may be factored into decisions about call routing and acceptance. For these decisions, a message containing no Priority header field SHOULD be treated as if it specified a Priority of ""normal"". The Priority header field does not influence the use of communications resources such as packet forwarding priority in routers or access to circuits in PSTN gateways. The header field can have the values ""non-urgent"", ""normal"", ""urgent"", and ""emergency"", but additional values can be defined elsewhere. It is RECOMMENDED that the value of ""emergency"" only be used when life, limb, or property are in imminent danger. Otherwise, there are no semantics defined for this header field. These are the values of RFC 2076 [38], with the addition of ""emergency"". Examples: Subject: A tornado is heading our way! Priority: emergency or Subject: Weekend plans Priority: non-urgent 20.27 Proxy-Authenticate A Proxy-Authenticate header field value contains an authentication challenge. The use of this header field is defined in [H14.33]. See Section 22.3 for further details on its usage. Rosenberg, et. al. Standards Track [Page 174] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Proxy-Authenticate: Digest realm=""atlanta.com"", domain=""sip:ss1.carrier.com"", qop=""auth"", nonce=""f84f1cec41e6cbe5aea9c8e88d359"", opaque="""", stale=FALSE, algorithm=MD5 20.28 Proxy-Authorization The Proxy-Authorization header field allows the client to identify itself (or its user) to a proxy that requires authentication. A Proxy-Authorization field value consists of credentials containing the authentication information of the user agent for the proxy and/or realm of the resource being requested. See Section 22.3 for a definition of the usage of this header field. This header field, along with Authorization, breaks the general rules about multiple header field names. Although not a comma-separated list, this header field name may be present multiple times, and MUST NOT be combined into a single header line using the usual rules described in Section 7.3.1. Example: Proxy-Authorization: Digest username=""Alice"", realm=""atlanta.com"", nonce=""c60f3082ee1212b402a21831ae"", response=""245f23415f11432b3434341c022"" 20.29 Proxy-Require The Proxy-Require header field is used to indicate proxy-sensitive features that must be supported by the proxy. See Section 20.32 for more details on the mechanics of this message and a usage example. Example: Proxy-Require: foo 20.30 Record-Route The Record-Route header field is inserted by proxies in a request to force future requests in the dialog to be routed through the proxy. Examples of its use with the Route header field are described in Sections 16.12.1. Rosenberg, et. al. Standards Track [Page 175] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Record-Route: <sip:server10.biloxi.com;lr>, <sip:bigbox3.site3.atlanta.com;lr> 20.31 Reply-To The Reply-To header field contains a logical return URI that may be different from the From header field. For example, the URI MAY be used to return missed calls or unestablished sessions. If the user wished to remain anonymous, the header field SHOULD either be omitted from the request or populated in such a way that does not reveal any private information. Even if the ""display-name"" is empty, the ""name-addr"" form MUST be used if the ""addr-spec"" contains a comma, question mark, or semicolon. Syntax issues are discussed in Section 7.3.1. Example: Reply-To: Bob <sip:bob@biloxi.com> 20.32 Require The Require header field is used by UACs to tell UASs about options that the UAC expects the UAS to support in order to process the request. Although an optional header field, the Require MUST NOT be ignored if it is present. The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs. Example: Require: 100rel 20.33 Retry-After The Retry-After header field can be used with a 500 (Server Internal Error) or 503 (Service Unavailable) response to indicate how long the service is expected to be unavailable to the requesting client and with a 404 (Not Found), 413 (Request Entity Too Large), 480 (Temporarily Unavailable), 486 (Busy Here), 600 (Busy), or 603 Rosenberg, et. al. Standards Track [Page 176] RFC 3261 SIP: Session Initiation Protocol June 2002 (Decline) response to indicate when the called party anticipates being available again. The value of this field is a positive integer number of seconds (in decimal) after the time of the response. An optional comment can be used to indicate additional information about the time of callback. An optional ""duration"" parameter indicates how long the called party will be reachable starting at the initial time of availability. If no duration parameter is given, the service is assumed to be available indefinitely. Examples: Retry-After: 18000;duration=3600 Retry-After: 120 (I'm in a meeting) 20.34 Route The Route header field is used to force routing for a request through the listed set of proxies. Examples of the use of the Route header field are in Section 16.12.1. Example: Route: <sip:bigbox3.site3.atlanta.com;lr>, <sip:server10.biloxi.com;lr> 20.35 Server The Server header field contains information about the software used by the UAS to handle the request. Revealing the specific software version of the server might allow the server to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the Server header field a configurable option. Example: Server: HomeServer v2 20.36 Subject The Subject header field provides a summary or indicates the nature of the call, allowing call filtering without having to parse the session description. The session description does not have to use the same subject indication as the invitation. The compact form of the Subject header field is s. Rosenberg, et. al. Standards Track [Page 177] RFC 3261 SIP: Session Initiation Protocol June 2002 Example: Subject: Need more boxes s: Tech Support 20.37 Supported The Supported header field enumerates all the extensions supported by the UAC or UAS. The Supported header field contains a list of option tags, described in Section 19.2, that are understood by the UAC or UAS. A UA compliant to this specification MUST only include option tags corresponding to standards-track RFCs. If empty, it means that no extensions are supported. The compact form of the Supported header field is k. Example: Supported: 100rel 20.38 Timestamp The Timestamp header field describes when the UAC sent the request to the UAS. See Section 8.2.6 for details on how to generate a response to a request that contains the header field. Although there is no normative behavior defined here that makes use of the header, it allows for extensions or SIP applications to obtain RTT estimates. Example: Timestamp: 54 20.39 To The To header field specifies the logical recipient of the request. The optional ""display-name"" is meant to be rendered by a human-user interface. The ""tag"" parameter serves as a general mechanism for dialog identification. See Section 19.3 for details of the ""tag"" parameter. Rosenberg, et. al. Standards Track [Page 178] RFC 3261 SIP: Session Initiation Protocol June 2002 Comparison of To header fields for equality is identical to comparison of From header fields. See Section 20.10 for the rules for parsing a display name, URI and URI parameters, and header field parameters. The compact form of the To header field is t. The following are examples of valid To header fields: To: The Operator <sip:operator@cs.columbia.edu>;tag=287447 t: sip:+12125551212@server.phone2net.com 20.40 Unsupported The Unsupported header field lists the features not supported by the UAS. See Section 20.32 for motivation. Example: Unsupported: foo 20.41 User-Agent The User-Agent header field contains information about the UAC originating the request. The semantics of this header field are defined in [H14.43]. Revealing the specific software version of the user agent might allow the user agent to become more vulnerable to attacks against software that is known to contain security holes. Implementers SHOULD make the User-Agent header field a configurable option. Example: User-Agent: Softphone Beta1.5 20.42 Via The Via header field indicates the path taken by the request so far and indicates the path that should be followed in routing responses. The branch ID parameter in the Via header field values serves as a transaction identifier, and is used by proxies to detect loops. A Via header field value contains the transport protocol used to send the message, the client's host name or network address, and possibly the port number at which it wishes to receive responses. A Via header field value can also contain parameters such as ""maddr"", ""ttl"", ""received"", and ""branch"", whose meaning and use are described Rosenberg, et. al. Standards Track [Page 179] RFC 3261 SIP: Session Initiation Protocol June 2002 in other sections. For implementations compliant to this specification, the value of the branch parameter MUST start with the magic cookie ""z9hG4bK"", as discussed in Section 8.1.1.7. Transport protocols defined here are ""UDP"", ""TCP"", ""TLS"", and ""SCTP"". ""TLS"" means TLS over TCP. When a request is sent to a SIPS URI, the protocol still indicates ""SIP"", and the transport protocol is TLS. Via: SIP/2.0/UDP erlang.bell-telephone.com:5060;branch=z9hG4bK87asdks7 Via: SIP/2.0/UDP 192.0.2.1:5060 ;received=192.0.2.207 ;branch=z9hG4bK77asjd The compact form of the Via header field is v. In this example, the message originated from a multi-homed host with two addresses, 192.0.2.1 and 192.0.2.207. The sender guessed wrong as to which network interface would be used. Erlang.bell- telephone.com noticed the mismatch and added a parameter to the previous hop's Via header field value, containing the address that the packet actually came from. The host or network address and port number are not required to follow the SIP URI syntax. Specifically, LWS on either side of the "":"" or ""/"" is allowed, as shown here: Via: SIP / 2.0 / UDP first.example.com: 4000;ttl=16 ;maddr=224.2.0.1 ;branch=z9hG4bKa7c6a8dlze.1 Even though this specification mandates that the branch parameter be present in all requests, the BNF for the header field indicates that it is optional. This allows interoperation with RFC 2543 elements, which did not have to insert the branch parameter. Two Via header fields are equal if their sent-protocol and sent-by fields are equal, both have the same set of parameters, and the values of all parameters are equal. 20.43 Warning The Warning header field is used to carry additional information about the status of a response. Warning header field values are sent with responses and contain a three-digit warning code, host name, and warning text. The ""warn-text"" should be in a natural language that is most likely to be intelligible to the human user receiving the response. This decision can be based on any available knowledge, such as the location of the user, the Accept-Language field in a request, or the Rosenberg, et. al. Standards Track [Page 180] RFC 3261 SIP: Session Initiation Protocol June 2002 Content-Language field in a response. The default language is i- default [21]. The currently-defined ""warn-code""s are listed below, with a recommended warn-text in English and a description of their meaning. These warnings describe failures induced by the session description. The first digit of warning codes beginning with ""3"" indicates warnings specific to SIP. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories. 300 Incompatible network protocol: One or more network protocols contained in the session description are not available. 301 Incompatible network address formats: One or more network address formats contained in the session description are not available. 302 Incompatible transport protocol: One or more transport protocols described in the session description are not available. 303 Incompatible bandwidth units: One or more bandwidth measurement units contained in the session description were not understood. 304 Media type not available: One or more media types contained in the session description are not available. 305 Incompatible media format: One or more media formats contained in the session description are not available. 306 Attribute not understood: One or more of the media attributes in the session description are not supported. 307 Session description parameter not understood: A parameter other than those listed above was not understood. 330 Multicast not available: The site where the user is located does not support multicast. 331 Unicast not available: The site where the user is located does not support unicast communication (usually due to the presence of a firewall). Rosenberg, et. al. Standards Track [Page 181] RFC 3261 SIP: Session Initiation Protocol June 2002 370 Insufficient bandwidth: The bandwidth specified in the session description or defined by the media exceeds that known to be available. 399 Miscellaneous warning: The warning text can include arbitrary information to be presented to a human user or logged. A system receiving this warning MUST NOT take any automated action. 1xx and 2xx have been taken by HTTP/1.1. Additional ""warn-code""s can be defined through IANA, as defined in Section 27.2. Examples: Warning: 307 isi.edu ""Session parameter 'foo' not understood"" Warning: 301 isi.edu ""Incompatible network address type 'E.164'"" 20.44 WWW-Authenticate A WWW-Authenticate header field value contains an authentication challenge. See Section 22.2 for further details on its usage. Example: WWW-Authenticate: Digest realm=""atlanta.com"", domain=""sip:boxesbybob.com"", qop=""auth"", nonce=""f84f1cec41e6cbe5aea9c8e88d359"", opaque="""", stale=FALSE, algorithm=MD5 21 Response Codes The response codes are consistent with, and extend, HTTP/1.1 response codes. Not all HTTP/1.1 response codes are appropriate, and only those that are appropriate are given here. Other HTTP/1.1 response codes SHOULD NOT be used. Also, SIP defines a new class, 6xx. 21.1 Provisional 1xx Provisional responses, also known as informational responses, indicate that the server contacted is performing some further action and does not yet have a definitive response. A server sends a 1xx response if it expects to take more than 200 ms to obtain a final response. Note that 1xx responses are not transmitted reliably. They never cause the client to send an ACK. Provisional (1xx) responses MAY contain message bodies, including session descriptions. Rosenberg, et. al."
"Standards Track [Page 182] RFC 3261 SIP: Session Initiation Protocol June 2002 21.1.1 100 Trying This response indicates that the request has been received by the next-hop server and that some unspecified action is being taken on behalf of this call (for example, a database is being consulted). This response, like all other provisional responses, stops retransmissions of an INVITE by a UAC. The 100 (Trying) response is different from other provisional responses, in that it is never forwarded upstream by a stateful proxy. 21.1.2 180 Ringing The UA receiving the INVITE is trying to alert the user. This response MAY be used to initiate local ringback. 21.1.3 181 Call Is Being Forwarded A server MAY use this status code to indicate that the call is being forwarded to a different set of destinations. 21.1.4 182 Queued The called party is temporarily unavailable, but the server has decided to queue the call rather than reject it. When the callee becomes available, it will return the appropriate final status response. The reason phrase MAY give further details about the status of the call, for example, ""5 calls queued; expected waiting time is 15 minutes"". The server MAY issue several 182 (Queued) responses to update the caller about the status of the queued call. 21.1.5 183 Session Progress The 183 (Session Progress) response is used to convey information about the progress of the call that is not otherwise classified. The Reason-Phrase, header fields, or message body MAY be used to convey more details about the call progress. 21.2 Successful 2xx The request was successful. 21.2.1 200 OK The request has succeeded. The information returned with the response depends on the method used in the request. Rosenberg, et. al. Standards Track [Page 183] RFC 3261 SIP: Session Initiation Protocol June 2002 21.3 Redirection 3xx 3xx responses give information about the user's new location, or about alternative services that might be able to satisfy the call. 21.3.1 300 Multiple Choices The address in the request resolved to several choices, each with its own specific location, and the user (or UA) can select a preferred communication end point and redirect its request to that location. The response MAY include a message body containing a list of resource characteristics and location(s) from which the user or UA can choose the one most appropriate, if allowed by the Accept request header field. However, no MIME types have been defined for this message body. The choices SHOULD also be listed as Contact fields (Section 20.10). Unlike HTTP, the SIP response MAY contain several Contact fields or a list of addresses in a Contact field. UAs MAY use the Contact header field value for automatic redirection or MAY ask the user to confirm a choice. However, this specification does not define any standard for such automatic selection. This status response is appropriate if the callee can be reached at several different locations and the server cannot or prefers not to proxy the request. 21.3.2 301 Moved Permanently The user can no longer be found at the address in the Request-URI, and the requesting client SHOULD retry at the new address given by the Contact header field (Section 20.10). The requestor SHOULD update any local directories, address books, and user location caches with this new value and redirect future requests to the address(es) listed. 21.3.3 302 Moved Temporarily The requesting client SHOULD retry the request at the new address(es) given by the Contact header field (Section 20.10). The Request-URI of the new request uses the value of the Contact header field in the response. Rosenberg, et. al. Standards Track [Page 184] RFC 3261 SIP: Session Initiation Protocol June 2002 The duration of the validity of the Contact URI can be indicated through an Expires (Section 20.19) header field or an expires parameter in the Contact header field. Both proxies and UAs MAY cache this URI for the duration of the expiration time. If there is no explicit expiration time, the address is only valid once for recursing, and MUST NOT be cached for future transactions. If the URI cached from the Contact header field fails, the Request- URI from the redirected request MAY be tried again a single time. The temporary URI may have become out-of-date sooner than the expiration time, and a new temporary URI may be available. 21.3.4 305 Use Proxy The requested resource MUST be accessed through the proxy given by the Contact field. The Contact field gives the URI of the proxy. The recipient is expected to repeat this single request via the proxy. 305 (Use Proxy) responses MUST only be generated by UASs. 21.3.5 380 Alternative Service The call was not successful, but alternative services are possible. The alternative services are described in the message body of the response. Formats for such bodies are not defined here, and may be the subject of future standardization. 21.4 Request Failure 4xx 4xx responses are definite failure responses from a particular server. The client SHOULD NOT retry the same request without modification (for example, adding appropriate authorization). However, the same request to a different server might be successful. 21.4.1 400 Bad Request The request could not be understood due to malformed syntax. The Reason-Phrase SHOULD identify the syntax problem in more detail, for example, ""Missing Call-ID header field"". 21.4.2 401 Unauthorized The request requires user authentication. This response is issued by UASs and registrars, while 407 (Proxy Authentication Required) is used by proxy servers. Rosenberg, et. al. Standards Track [Page 185] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.3 402 Payment Required Reserved for future use. 21.4.4 403 Forbidden The server understood the request, but is refusing to fulfill it. Authorization will not help, and the request SHOULD NOT be repeated. 21.4.5 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. This status is also returned if the domain in the Request-URI does not match any of the domains handled by the recipient of the request. 21.4.6 405 Method Not Allowed The method specified in the Request-Line is understood, but not allowed for the address identified by the Request-URI. The response MUST include an Allow header field containing a list of valid methods for the indicated address. 21.4.7 406 Not Acceptable The resource identified by the request is only capable of generating response entities that have content characteristics not acceptable according to the Accept header field sent in the request. 21.4.8 407 Proxy Authentication Required This code is similar to 401 (Unauthorized), but indicates that the client MUST first authenticate itself with the proxy. SIP access authentication is explained in Sections 26 and 22.3. This status code can be used for applications where access to the communication channel (for example, a telephony gateway) rather than the callee requires authentication. 21.4.9 408 Request Timeout The server could not produce a response within a suitable amount of time, for example, if it could not determine the location of the user in time. The client MAY repeat the request without modifications at any later time. Rosenberg, et. al. Standards Track [Page 186] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.10 410 Gone The requested resource is no longer available at the server and no forwarding address is known. This condition is expected to be considered permanent. If the server does not know, or has no facility to determine, whether or not the condition is permanent, the status code 404 (Not Found) SHOULD be used instead. 21.4.11 413 Request Entity Too Large The server is refusing to process a request because the request entity-body is larger than the server is willing or able to process. The server MAY close the connection to prevent the client from continuing the request. If the condition is temporary, the server SHOULD include a Retry- After header field to indicate that it is temporary and after what time the client MAY try again. 21.4.12 414 Request-URI Too Long The server is refusing to service the request because the Request-URI is longer than the server is willing to interpret. 21.4.13 415 Unsupported Media Type The server is refusing to service the request because the message body of the request is in a format not supported by the server for the requested method. The server MUST return a list of acceptable formats using the Accept, Accept-Encoding, or Accept-Language header field, depending on the specific problem with the content. UAC processing of this response is described in Section 8.1.3.5. 21.4.14 416 Unsupported URI Scheme The server cannot process the request because the scheme of the URI in the Request-URI is unknown to the server. Client processing of this response is described in Section 8.1.3.5. 21.4.15 420 Bad Extension The server did not understand the protocol extension specified in a Proxy-Require (Section 20.29) or Require (Section 20.32) header field. The server MUST include a list of the unsupported extensions in an Unsupported header field in the response. UAC processing of this response is described in Section 8.1.3.5. Rosenberg, et. al. Standards Track [Page 187] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.16 421 Extension Required The UAS needs a particular extension to process the request, but this extension is not listed in a Supported header field in the request. Responses with this status code MUST contain a Require header field listing the required extensions. A UAS SHOULD NOT use this response unless it truly cannot provide any useful service to the client. Instead, if a desirable extension is not listed in the Supported header field, servers SHOULD process the request using baseline SIP capabilities and any extensions supported by the client. 21.4.17 423 Interval Too Brief The server is rejecting the request because the expiration time of the resource refreshed by the request is too short. This response can be used by a registrar to reject a registration whose Contact header field expiration time was too small. The use of this response and the related Min-Expires header field are described in Sections 10.2.8, 10.3, and 20.23. 21.4.18 480 Temporarily Unavailable The callee's end system was contacted successfully but the callee is currently unavailable (for example, is not logged in, logged in but in a state that precludes communication with the callee, or has activated the ""do not disturb"" feature). The response MAY indicate a better time to call in the Retry-After header field. The user could also be available elsewhere (unbeknownst to this server). The reason phrase SHOULD indicate a more precise cause as to why the callee is unavailable. This value SHOULD be settable by the UA. Status 486 (Busy Here) MAY be used to more precisely indicate a particular reason for the call failure. This status is also returned by a redirect or proxy server that recognizes the user identified by the Request-URI, but does not currently have a valid forwarding location for that user. 21.4.19 481 Call/Transaction Does Not Exist This status indicates that the UAS received a request that does not match any existing dialog or transaction. 21.4.20 482 Loop Detected The server has detected a loop (Section 16.3 Item 4). Rosenberg, et. al. Standards Track [Page 188] RFC 3261 SIP: Session Initiation Protocol June 2002 21.4.21 483 Too Many Hops The server received a request that contains a Max-Forwards (Section 20.22) header field with the value zero. 21.4.22 484 Address Incomplete The server received a request with a Request-URI that was incomplete. Additional information SHOULD be provided in the reason phrase. This status code allows overlapped dialing. With overlapped dialing, the client does not know the length of the dialing string. It sends strings of increasing lengths, prompting the user for more input, until it no longer receives a 484 (Address Incomplete) status response. 21.4.23 485 Ambiguous The Request-URI was ambiguous. The response MAY contain a listing of possible unambiguous addresses in Contact header fields. Revealing alternatives can infringe on privacy of the user or the organization. It MUST be possible to configure a server to respond with status 404 (Not Found) or to suppress the listing of possible choices for ambiguous Request-URIs. Example response to a request with the Request-URI sip:lee@example.com: SIP/2.0 485 Ambiguous Contact: Carol Lee <sip:carol.lee@example.com> Contact: Ping Lee <sip:p.lee@example.com> Contact: Lee M. Foote <sips:lee.foote@example.com> Some email and voice mail systems provide this functionality. A status code separate from 3xx is used since the semantics are different: for 300, it is assumed that the same person or service will be reached by the choices provided. While an automated choice or sequential search makes sense for a 3xx response, user intervention is required for a 485 (Ambiguous) response. 21.4.24 486 Busy Here The callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. The response MAY indicate a better time to call in the Retry-After header field. The user could also be available Rosenberg, et. al. Standards Track [Page 189] RFC 3261 SIP: Session Initiation Protocol June 2002 elsewhere, such as through a voice mail service. Status 600 (Busy Everywhere) SHOULD be used if the client knows that no other end system will be able to accept this call. 21.4.25 487 Request Terminated The request was terminated by a BYE or CANCEL request. This response is never returned for a CANCEL request itself. 21.4.26 488 Not Acceptable Here The response has the same meaning as 606 (Not Acceptable), but only applies to the specific resource addressed by the Request-URI and the request may succeed elsewhere. A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. 21.4.27 491 Request Pending The request was received by a UAS that had a pending request within the same dialog. Section 14.2 describes how such ""glare"" situations are resolved. 21.4.28 493 Undecipherable The request was received by a UAS that contained an encrypted MIME body for which the recipient does not possess or will not provide an appropriate decryption key. This response MAY have a single body containing an appropriate public key that should be used to encrypt MIME bodies sent to this UA. Details of the usage of this response code can be found in Section 23.2. 21.5 Server Failure 5xx 5xx responses are failure responses given when a server itself has erred. 21.5.1 500 Server Internal Error The server encountered an unexpected condition that prevented it from fulfilling the request. The client MAY display the specific error condition and MAY retry the request after several seconds. If the condition is temporary, the server MAY indicate when the client may retry the request using the Retry-After header field. Rosenberg, et. al. Standards Track [Page 190] RFC 3261 SIP: Session Initiation Protocol June 2002 21.5.2 501 Not Implemented The server does not support the functionality required to fulfill the request. This is the appropriate response when a UAS does not recognize the request method and is not capable of supporting it for any user. (Proxies forward all requests regardless of method.) Note that a 405 (Method Not Allowed) is sent when the server recognizes the request method, but that method is not allowed or supported. 21.5.3 502 Bad Gateway The server, while acting as a gateway or proxy, received an invalid response from the downstream server it accessed in attempting to fulfill the request. 21.5.4 503 Service Unavailable The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. The server MAY indicate when the client should retry the request in a Retry-After header field. If no Retry-After is given, the client MUST act as if it had received a 500 (Server Internal Error) response. A client (proxy or UAC) receiving a 503 (Service Unavailable) SHOULD attempt to forward the request to an alternate server. It SHOULD NOT forward any other requests to that server for the duration specified in the Retry-After header field, if present. Servers MAY refuse the connection or drop the request instead of responding with 503 (Service Unavailable). 21.5.5 504 Server Time-out The server did not receive a timely response from an external server it accessed in attempting to process the request. 408 (Request Timeout) should be used instead if there was no response within the period specified in the Expires header field from the upstream server. 21.5.6 505 Version Not Supported The server does not support, or refuses to support, the SIP protocol version that was used in the request. The server is indicating that it is unable or unwilling to complete the request using the same major version as the client, other than with this error message. Rosenberg, et. al. Standards Track [Page 191] RFC 3261 SIP: Session Initiation Protocol June 2002 21.5.7 513 Message Too Large The server was unable to process the request since the message length exceeded its capabilities. 21.6 Global Failures 6xx 6xx responses indicate that a server has definitive information about a particular user, not just the particular instance indicated in the Request-URI. 21.6.1 600 Busy Everywhere The callee's end system was contacted successfully but the callee is busy and does not wish to take the call at this time. The response MAY indicate a better time to call in the Retry-After header field. If the callee does not wish to reveal the reason for declining the call, the callee uses status code 603 (Decline) instead. This status response is returned only if the client knows that no other end point (such as a voice mail system) will answer the request. Otherwise, 486 (Busy Here) should be returned. 21.6.2 603 Decline The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate. The response MAY indicate a better time to call in the Retry-After header field. This status response is returned only if the client knows that no other end point will answer the request. 21.6.3 604 Does Not Exist Anywhere The server has authoritative information that the user indicated in the Request-URI does not exist anywhere. 21.6.4 606 Not Acceptable The user's agent was contacted successfully but some aspects of the session description such as the requested media, bandwidth, or addressing style were not acceptable. A 606 (Not Acceptable) response means that the user wishes to communicate, but cannot adequately support the session described. The 606 (Not Acceptable) response MAY contain a list of reasons in a Warning header field describing why the session described cannot be supported. Warning reason codes are listed in Section 20.43. Rosenberg, et. al. Standards Track [Page 192] RFC 3261 SIP: Session Initiation Protocol June 2002 A message body containing a description of media capabilities MAY be present in the response, which is formatted according to the Accept header field in the INVITE (or application/sdp if not present), the same as a message body in a 200 (OK) response to an OPTIONS request. It is hoped that negotiation will not frequently be needed, and when a new user is being invited to join an already existing conference, negotiation may not be possible. It is up to the invitation initiator to decide whether or not to act on a 606 (Not Acceptable) response. This status response is returned only if the client knows that no other end point will answer the request. 22 Usage of HTTP Authentication SIP provides a stateless, challenge-based mechanism for authentication that is based on authentication in HTTP. Any time that a proxy server or UA receives a request (with the exceptions given in Section 22.1), it MAY challenge the initiator of the request to provide assurance of its identity. Once the originator has been identified, the recipient of the request SHOULD ascertain whether or not this user is authorized to make the request in question. No authorization systems are recommended or discussed in this document. The ""Digest"" authentication mechanism described in this section provides message authentication and replay protection only, without message integrity or confidentiality. Protective measures above and beyond those provided by Digest need to be taken to prevent active attackers from modifying SIP requests and responses. Note that due to its weak security, the usage of ""Basic"" authentication has been deprecated. Servers MUST NOT accept credentials using the ""Basic"" authorization scheme, and servers also MUST NOT challenge with ""Basic"". This is a change from RFC 2543. 22.1 Framework The framework for SIP authentication closely parallels that of HTTP (RFC 2617 [17]). In particular, the BNF for auth-scheme, auth-param, challenge, realm, realm-value, and credentials is identical (although the usage of ""Basic"" as a scheme is not permitted). In SIP, a UAS uses the 401 (Unauthorized) response to challenge the identity of a UAC. Additionally, registrars and redirect servers MAY make use of 401 (Unauthorized) responses for authentication, but proxies MUST NOT, and instead MAY use the 407 (Proxy Authentication Required) Rosenberg, et. al. Standards Track [Page 193] RFC 3261 SIP: Session Initiation Protocol June 2002 response. The requirements for inclusion of the Proxy-Authenticate, Proxy-Authorization, WWW-Authenticate, and Authorization in the various messages are identical to those described in RFC 2617 [17]. Since SIP does not have the concept of a canonical root URL, the notion of protection spaces is interpreted differently in SIP. The realm string alone defines the protection domain. This is a change from RFC 2543, in which the Request-URI and the realm together defined the protection domain. This previous definition of protection domain caused some amount of confusion since the Request-URI sent by the UAC and the Request-URI received by the challenging server might be different, and indeed the final form of the Request-URI might not be known to the UAC. Also, the previous definition depended on the presence of a SIP URI in the Request-URI and seemed to rule out alternative URI schemes (for example, the tel URL). Operators of user agents or proxy servers that will authenticate received requests MUST adhere to the following guidelines for creation of a realm string for their server: o Realm strings MUST be globally unique. It is RECOMMENDED that a realm string contain a hostname or domain name, following the recommendation in Section 3.2.1 of RFC 2617 [17]. o Realm strings SHOULD present a human-readable identifier that can be rendered to a user. For example: INVITE sip:bob@biloxi.com SIP/2.0 Authorization: Digest realm=""biloxi.com"", <...> Generally, SIP authentication is meaningful for a specific realm, a protection domain. Thus, for Digest authentication, each such protection domain has its own set of usernames and passwords. If a server does not require authentication for a particular request, it MAY accept a default username, ""anonymous"", which has no password (password of """"). Similarly, UACs representing many users, such as PSTN gateways, MAY have their own device-specific username and password, rather than accounts for particular users, for their realm. While a server can legitimately challenge most SIP requests, there are two requests defined by this document that require special handling for authentication: ACK and CANCEL. Rosenberg, et. al. Standards Track [Page 194] RFC 3261 SIP: Session Initiation Protocol June 2002 Under an authentication scheme that uses responses to carry values used to compute nonces (such as Digest), some problems come up for any requests that take no response, including ACK. For this reason, any credentials in the INVITE that were accepted by a server MUST be accepted by that server for the ACK. UACs creating an ACK message will duplicate all of the Authorization and Proxy-Authorization header field values that appeared in the INVITE to which the ACK corresponds. Servers MUST NOT attempt to challenge an ACK. Although the CANCEL method does take a response (a 2xx), servers MUST NOT attempt to challenge CANCEL requests since these requests cannot be resubmitted. Generally, a CANCEL request SHOULD be accepted by a server if it comes from the same hop that sent the request being canceled (provided that some sort of transport or network layer security association, as described in Section 26.2.1, is in place). When a UAC receives a challenge, it SHOULD render to the user the contents of the ""realm"" parameter in the challenge (which appears in either a WWW-Authenticate header field or Proxy-Authenticate header field) if the UAC device does not already know of a credential for the realm in question. A service provider that pre-configures UAs with credentials for its realm should be aware that users will not have the opportunity to present their own credentials for this realm when challenged at a pre-configured device. Finally, note that even if a UAC can locate credentials that are associated with the proper realm, the potential exists that these credentials may no longer be valid or that the challenging server will not accept these credentials for whatever reason (especially when ""anonymous"" with no password is submitted). In this instance a server may repeat its challenge, or it may respond with a 403 Forbidden. A UAC MUST NOT re-attempt requests with the credentials that have just been rejected (though the request may be retried if the nonce was stale). 22.2 User-to-User Authentication When a UAS receives a request from a UAC, the UAS MAY authenticate the originator before the request is processed. If no credentials (in the Authorization header field) are provided in the request, the UAS can challenge the originator to provide credentials by rejecting the request with a 401 (Unauthorized) status code. The WWW-Authenticate response-header field MUST be included in 401 (Unauthorized) response messages. The field value consists of at least one challenge that indicates the authentication scheme(s) and parameters applicable to the realm. Rosenberg, et. al. Standards Track [Page 195] RFC 3261 SIP: Session Initiation Protocol June 2002 An example of the WWW-Authenticate header field in a 401 challenge is: WWW-Authenticate: Digest realm=""biloxi.com"", qop=""auth,auth-int"", nonce=""dcd98b7102dd2f0e8b11d0f600bfb0c093"", opaque=""5ccc069c403ebaf9f0171e9517f40e41"" When the originating UAC receives the 401 (Unauthorized), it SHOULD, if it is able, re-originate the request with the proper credentials. The UAC may require input from the originating user before proceeding. Once authentication credentials have been supplied (either directly by the user, or discovered in an internal keyring), UAs SHOULD cache the credentials for a given value of the To header field and ""realm"" and attempt to re-use these values on the next request for that destination. UAs MAY cache credentials in any way they would like. If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of ""anonymous"" and no password (a password of """"). Once credentials have been located, any UA that wishes to authenticate itself with a UAS or registrar -- usually, but not necessarily, after receiving a 401 (Unauthorized) response -- MAY do so by including an Authorization header field with the request. The Authorization field value consists of credentials containing the authentication information of the UA for the realm of the resource being requested as well as parameters required in support of authentication and replay protection. An example of the Authorization header field is: Authorization: Digest username=""bob"", realm=""biloxi.com"", nonce=""dcd98b7102dd2f0e8b11d0f600bfb0c093"", uri=""sip:bob@biloxi.com"", qop=auth, nc=00000001, cnonce=""0a4f113b"", response=""6629fae49393a05397450978507c4ef1"", opaque=""5ccc069c403ebaf9f0171e9517f40e41"" When a UAC resubmits a request with its credentials after receiving a 401 (Unauthorized) or 407 (Proxy Authentication Required) response, it MUST increment the CSeq header field value as it would normally when sending an updated request. Rosenberg, et. al. Standards Track [Page 196] RFC 3261 SIP: Session Initiation Protocol June 2002 22.3 Proxy-to-User Authentication Similarly, when a UAC sends a request to a proxy server, the proxy server MAY authenticate the originator before the request is processed. If no credentials (in the Proxy-Authorization header field) are provided in the request, the proxy can challenge the originator to provide credentials by rejecting the request with a 407 (Proxy Authentication Required) status code. The proxy MUST populate the 407 (Proxy Authentication Required) message with a Proxy- Authenticate header field value applicable to the proxy for the requested resource. The use of Proxy-Authenticate and Proxy-Authorization parallel that described in [17], with one difference. Proxies MUST NOT add values to the Proxy-Authorization header field. All 407 (Proxy Authentication Required) responses MUST be forwarded upstream toward the UAC following the procedures for any other response. It is the UAC's responsibility to add the Proxy-Authorization header field value containing credentials for the realm of the proxy that has asked for authentication. If a proxy were to resubmit a request adding a Proxy-Authorization header field value, it would need to increment the CSeq in the new request. However, this would cause the UAC that submitted the original request to discard a response from the UAS, as the CSeq value would be different. When the originating UAC receives the 407 (Proxy Authentication Required) it SHOULD, if it is able, re-originate the request with the proper credentials. It should follow the same procedures for the display of the ""realm"" parameter that are given above for responding to 401. If no credentials for a realm can be located, UACs MAY attempt to retry the request with a username of ""anonymous"" and no password (a password of """"). The UAC SHOULD also cache the credentials used in the re-originated request. The following rule is RECOMMENDED for proxy credential caching: If a UA receives a Proxy-Authenticate header field value in a 401/407 response to a request with a particular Call-ID, it should incorporate credentials for that realm in all subsequent requests that contain the same Call-ID. These credentials MUST NOT be cached across dialogs; however, if a UA is configured with the realm of its local outbound proxy, when one exists, then the UA MAY cache Rosenberg, et. al. Standards Track [Page 197] RFC 3261 SIP: Session Initiation Protocol June 2002 credentials for that realm across dialogs. Note that this does mean a future request in a dialog could contain credentials that are not needed by any proxy along the Route header path. Any UA that wishes to authenticate itself to a proxy server -- usually, but not necessarily, after receiving a 407 (Proxy Authentication Required) response -- MAY do so by including a Proxy- Authorization header field value with the request. The Proxy- Authorization request-header field allows the client to identify itself (or its user) to a proxy that requires authentication. The Proxy-Authorization header field value consists of credentials containing the authentication information of the UA for the proxy and/or realm of the resource being requested. A Proxy-Authorization header field value applies only to the proxy whose realm is identified in the ""realm"" parameter (this proxy may previously have demanded authentication using the Proxy-Authenticate field). When multiple proxies are used in a chain, a Proxy- Authorization header field value MUST NOT be consumed by any proxy whose realm does not match the ""realm"" parameter specified in that value. Note that if an authentication scheme that does not support realms is used in the Proxy-Authorization header field, a proxy server MUST attempt to parse all Proxy-Authorization header field values to determine whether one of them has what the proxy server considers to be valid credentials. Because this is potentially very time- consuming in large networks, proxy servers SHOULD use an authentication scheme that supports realms in the Proxy-Authorization header field. If a request is forked (as described in Section 16.7), various proxy servers and/or UAs may wish to challenge the UAC. In this case, the forking proxy server is responsible for aggregating these challenges into a single response. Each WWW-Authenticate and Proxy-Authenticate value received in responses to the forked request MUST be placed into the single response that is sent by the forking proxy to the UA; the ordering of these header field values is not significant. When a proxy server issues a challenge in response to a request, it will not proxy the request until the UAC has retried the request with valid credentials. A forking proxy may forward a request simultaneously to multiple proxy servers that require authentication, each of which in turn will not forward the request until the originating UAC has authenticated itself in their respective realm. If the UAC does not provide credentials for Rosenberg, et. al. Standards Track [Page 198] RFC 3261 SIP: Session Initiation Protocol June 2002 each challenge, the proxy servers that issued the challenges will not forward requests to the UA where the destination user might be located, and therefore, the virtues of forking are largely lost. When resubmitting its request in response to a 401 (Unauthorized) or 407 (Proxy Authentication Required) that contains multiple challenges, a UAC MAY include an Authorization value for each WWW- Authenticate value and a Proxy-Authorization value for each Proxy- Authenticate value for which the UAC wishes to supply a credential. As noted above, multiple credentials in a request SHOULD be differentiated by the ""realm"" parameter. It is possible for multiple challenges associated with the same realm to appear in the same 401 (Unauthorized) or 407 (Proxy Authentication Required). This can occur, for example, when multiple proxies within the same administrative domain, which use a common realm, are reached by a forking request. When it retries a request, a UAC MAY therefore supply multiple credentials in Authorization or Proxy-Authorization header fields with the same ""realm"" parameter value. The same credentials SHOULD be used for the same realm. 22.4 The Digest Authentication Scheme This section describes the modifications and clarifications required to apply the HTTP Digest authentication scheme to SIP. The SIP scheme usage is almost completely identical to that for HTTP [17]. Since RFC 2543 is based on HTTP Digest as defined in RFC 2069 [39], SIP servers supporting RFC 2617 MUST ensure they are backwards compatible with RFC 2069. Procedures for this backwards compatibility are specified in RFC 2617. Note, however, that SIP servers MUST NOT accept or request Basic authentication. The rules for Digest authentication follow those defined in [17], with ""HTTP/1.1"" replaced by ""SIP/2.0"" in addition to the following differences: 1. The URI included in the challenge has the following BNF: URI = SIP-URI / SIPS-URI 2. The BNF in RFC 2617 has an error in that the 'uri' parameter of the Authorization header field for HTTP Digest Rosenberg, et. al. Standards Track [Page 199] RFC 3261 SIP: Session Initiation Protocol June 2002 authentication is not enclosed in quotation marks. (The example in Section 3.5 of RFC 2617 is correct.) For SIP, the 'uri' MUST be enclosed in quotation marks. 3. The BNF for digest-uri-value is: digest-uri-value = Request-URI ; as defined in Section 25 4. The example procedure for choosing a nonce based on Etag does not work for SIP. 5. The text in RFC 2617 [17] regarding cache operation does not apply to SIP. 6. RFC 2617 [17] requires that a server check that the URI in the request line and the URI included in the Authorization header field point to the same resource. In a SIP context, these two URIs may refer to different users, due to forwarding at some proxy. Therefore, in SIP, a server MAY check that the Request-URI in the Authorization header field value corresponds to a user for whom the server is willing to accept forwarded or direct requests, but it is not necessarily a failure if the two fields are not equivalent. 7. As a clarification to the calculation of the A2 value for message integrity assurance in the Digest authentication scheme, implementers should assume, when the entity-body is empty (that is, when SIP messages have no body) that the hash of the entity-body resolves to the MD5 hash of an empty string, or: H(entity-body) = MD5("""") = ""d41d8cd98f00b204e9800998ecf8427e"" 8. RFC 2617 notes that a cnonce value MUST NOT be sent in an Authorization (and by extension Proxy-Authorization) header field if no qop directive has been sent. Therefore, any algorithms that have a dependency on the cnonce (including ""MD5-Sess"") require that the qop directive be sent. Use of the ""qop"" parameter is optional in RFC 2617 for the purposes of backwards compatibility with RFC 2069; since RFC 2543 was based on RFC 2069, the ""qop"" parameter must unfortunately remain optional for clients and servers to receive. However, servers MUST always send a ""qop"" parameter in WWW-Authenticate and Proxy-Authenticate header field values. If a client receives a ""qop"" parameter in a challenge header field, it MUST send the ""qop"" parameter in any resulting authorization header field. Rosenberg, et. al. Standards Track [Page 200] RFC 3261 SIP: Session Initiation Protocol June 2002 RFC 2543 did not allow usage of the Authentication-Info header field (it effectively used RFC 2069). However, we now allow usage of this header field, since it provides integrity checks over the bodies and provides mutual authentication. RFC 2617 [17] defines mechanisms for backwards compatibility using the qop attribute in the request. These mechanisms MUST be used by a server to determine if the client supports the new mechanisms in RFC 2617 that were not specified in RFC 2069."
"23 S/MIME SIP messages carry MIME bodies and the MIME standard includes mechanisms for securing MIME contents to ensure both integrity and confidentiality (including the 'multipart/signed' and 'application/pkcs7-mime' MIME types, see RFC 1847 [22], RFC 2630 [23] and RFC 2633 [24]). Implementers should note, however, that there may be rare network intermediaries (not typical proxy servers) that rely on viewing or modifying the bodies of SIP messages (especially SDP), and that secure MIME may prevent these sorts of intermediaries from functioning. This applies particularly to certain types of firewalls. The PGP mechanism for encrypting the header fields and bodies of SIP messages described in RFC 2543 has been deprecated. 23.1 S/MIME Certificates The certificates that are used to identify an end-user for the purposes of S/MIME differ from those used by servers in one important respect - rather than asserting that the identity of the holder corresponds to a particular hostname, these certificates assert that the holder is identified by an end-user address. This address is composed of the concatenation of the ""userinfo"" ""@"" and ""domainname"" portions of a SIP or SIPS URI (in other words, an email address of the form ""bob@biloxi.com""), most commonly corresponding to a user's address-of-record. These certificates are also associated with keys that are used to sign or encrypt bodies of SIP messages. Bodies are signed with the private key of the sender (who may include their public key with the message as appropriate), but bodies are encrypted with the public key of the intended recipient. Obviously, senders must have foreknowledge of the public key of recipients in order to encrypt message bodies. Public keys can be stored within a UA on a virtual keyring. Rosenberg, et. al. Standards Track [Page 201] RFC 3261 SIP: Session Initiation Protocol June 2002 Each user agent that supports S/MIME MUST contain a keyring specifically for end-users' certificates. This keyring should map between addresses of record and corresponding certificates. Over time, users SHOULD use the same certificate when they populate the originating URI of signaling (the From header field) with the same address-of-record. Any mechanisms depending on the existence of end-user certificates are seriously limited in that there is virtually no consolidated authority today that provides certificates for end-user applications. However, users SHOULD acquire certificates from known public certificate authorities. As an alternative, users MAY create self- signed certificates. The implications of self-signed certificates are explored further in Section 26.4.2. Implementations may also use pre-configured certificates in deployments in which a previous trust relationship exists between all SIP entities. Above and beyond the problem of acquiring an end-user certificate, there are few well-known centralized directories that distribute end-user certificates. However, the holder of a certificate SHOULD publish their certificate in any public directories as appropriate. Similarly, UACs SHOULD support a mechanism for importing (manually or automatically) certificates discovered in public directories corresponding to the target URIs of SIP requests. 23.2 S/MIME Key Exchange SIP itself can also be used as a means to distribute public keys in the following manner. Whenever the CMS SignedData message is used in S/MIME for SIP, it MUST contain the certificate bearing the public key necessary to verify the signature. When a UAC sends a request containing an S/MIME body that initiates a dialog, or sends a non-INVITE request outside the context of a dialog, the UAC SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS service is EnvelopedData (and the public key of the target user is known), the UAC SHOULD send the EnvelopedData message encapsulated within a SignedData message. When a UAS receives a request containing an S/MIME CMS body that includes a certificate, the UAS SHOULD first validate the certificate, if possible, with any available root certificates for certificate authorities. The UAS SHOULD also determine the subject of the certificate (for S/MIME, the SubjectAltName will contain the appropriate identity) and compare this value to the From header field Rosenberg, et. al. Standards Track [Page 202] RFC 3261 SIP: Session Initiation Protocol June 2002 of the request. If the certificate cannot be verified, because it is self-signed, or signed by no known authority, or if it is verifiable but its subject does not correspond to the From header field of request, the UAS MUST notify its user of the status of the certificate (including the subject of the certificate, its signer, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified and the subject of the certificate corresponds to the From header field of the SIP request, or if the user (after notification) explicitly authorizes the use of the certificate, the UAS SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. When a UAS sends a response containing an S/MIME body that answers the first request in a dialog, or a response to a non-INVITE request outside the context of a dialog, the UAS SHOULD structure the body as an S/MIME 'multipart/signed' CMS SignedData body. If the desired CMS service is EnvelopedData, the UAS SHOULD send the EnvelopedData message encapsulated within a SignedData message. When a UAC receives a response containing an S/MIME CMS body that includes a certificate, the UAC SHOULD first validate the certificate, if possible, with any appropriate root certificate. The UAC SHOULD also determine the subject of the certificate and compare this value to the To field of the response; although the two may very well be different, and this is not necessarily indicative of a security breach. If the certificate cannot be verified because it is self-signed, or signed by no known authority, the UAC MUST notify its user of the status of the certificate (including the subject of the certificate, its signator, and any key fingerprint information) and request explicit permission before proceeding. If the certificate was successfully verified, and the subject of the certificate corresponds to the To header field in the response, or if the user (after notification) explicitly authorizes the use of the certificate, the UAC SHOULD add this certificate to a local keyring, indexed by the address-of-record of the holder of the certificate. If the UAC had not transmitted its own certificate to the UAS in any previous transaction, it SHOULD use a CMS SignedData body for its next request or response. On future occasions, when the UA receives requests or responses that contain a From header field corresponding to a value in its keyring, the UA SHOULD compare the certificate offered in these messages with the existing certificate in its keyring. If there is a discrepancy, the UA MUST notify its user of a change of the certificate (preferably in terms that indicate that this is a potential security breach) and acquire the user's permission before continuing to Rosenberg, et. al. Standards Track [Page 203] RFC 3261 SIP: Session Initiation Protocol June 2002 process the signaling. If the user authorizes this certificate, it SHOULD be added to the keyring alongside any previous value(s) for this address-of-record. Note well however, that this key exchange mechanism does not guarantee the secure exchange of keys when self-signed certificates, or certificates signed by an obscure authority, are used - it is vulnerable to well-known attacks. In the opinion of the authors, however, the security it provides is proverbially better than nothing; it is in fact comparable to the widely used SSH application. These limitations are explored in greater detail in Section 26.4.2. If a UA receives an S/MIME body that has been encrypted with a public key unknown to the recipient, it MUST reject the request with a 493 (Undecipherable) response. This response SHOULD contain a valid certificate for the respondent (corresponding, if possible, to any address of record given in the To header field of the rejected request) within a MIME body with a 'certs-only' ""smime-type"" parameter. A 493 (Undecipherable) sent without any certificate indicates that the respondent cannot or will not utilize S/MIME encrypted messages, though they may still support S/MIME signatures. Note that a user agent that receives a request containing an S/MIME body that is not optional (with a Content-Disposition header ""handling"" parameter of ""required"") MUST reject the request with a 415 Unsupported Media Type response if the MIME type is not understood. A user agent that receives such a response when S/MIME is sent SHOULD notify its user that the remote device does not support S/MIME, and it MAY subsequently resend the request without S/MIME, if appropriate; however, this 415 response may constitute a downgrade attack. If a user agent sends an S/MIME body in a request, but receives a response that contains a MIME body that is not secured, the UAC SHOULD notify its user that the session could not be secured. However, if a user agent that supports S/MIME receives a request with an unsecured body, it SHOULD NOT respond with a secured body, but if it expects S/MIME from the sender (for example, because the sender's From header field value corresponds to an identity on its keychain), the UAS SHOULD notify its user that the session could not be secured. A number of conditions that arise in the previous text call for the notification of the user when an anomalous certificate-management event occurs. Users might well ask what they should do under these circumstances. First and foremost, an unexpected change in a certificate, or an absence of security when security is expected, are Rosenberg, et. al. Standards Track [Page 204] RFC 3261 SIP: Session Initiation Protocol June 2002 causes for caution but not necessarily indications that an attack is in progress. Users might abort any connection attempt or refuse a connection request they have received; in telephony parlance, they could hang up and call back. Users may wish to find an alternate means to contact the other party and confirm that their key has legitimately changed. Note that users are sometimes compelled to change their certificates, for example when they suspect that the secrecy of their private key has been compromised. When their private key is no longer private, users must legitimately generate a new key and re-establish trust with any users that held their old key. Finally, if during the course of a dialog a UA receives a certificate in a CMS SignedData message that does not correspond with the certificates previously exchanged during a dialog, the UA MUST notify its user of the change, preferably in terms that indicate that this is a potential security breach. 23.3 Securing MIME bodies There are two types of secure MIME bodies that are of interest to SIP: use of these bodies should follow the S/MIME specification [24] with a few variations. o ""multipart/signed"" MUST be used only with CMS detached signatures. This allows backwards compatibility with non-S/MIME- compliant recipients. o S/MIME bodies SHOULD have a Content-Disposition header field, and the value of the ""handling"" parameter SHOULD be ""required."" o If a UAC has no certificate on its keyring associated with the address-of-record to which it wants to send a request, it cannot send an encrypted ""application/pkcs7-mime"" MIME message. UACs MAY send an initial request such as an OPTIONS message with a CMS detached signature in order to solicit the certificate of the remote side (the signature SHOULD be over a ""message/sip"" body of the type described in Section 23.4). Note that future standardization work on S/MIME may define non-certificate based keys. o Senders of S/MIME bodies SHOULD use the ""SMIMECapabilities"" (see Section 2.5.2 of [24]) attribute to express their capabilities and preferences for further communications. Note especially that senders MAY use the ""preferSignedData"" Rosenberg, et. al. Standards Track [Page 205] RFC 3261 SIP: Session Initiation Protocol June 2002 capability to encourage receivers to respond with CMS SignedData messages (for example, when sending an OPTIONS request as described above). o S/MIME implementations MUST at a minimum support SHA1 as a digital signature algorithm, and 3DES as an encryption algorithm. All other signature and encryption algorithms MAY be supported. Implementations can negotiate support for these algorithms with the ""SMIMECapabilities"" attribute. o Each S/MIME body in a SIP message SHOULD be signed with only one certificate. If a UA receives a message with multiple signatures, the outermost signature should be treated as the single certificate for this body. Parallel signatures SHOULD NOT be used. The following is an example of an encrypted S/MIME SDP body within a SIP message: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Disposition: attachment; filename=smime.p7m handling=required ******************************************************* * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=- * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * ******************************************************* Rosenberg, et. al. Standards Track [Page 206] RFC 3261 SIP: Session Initiation Protocol June 2002 23.4 SIP Header Privacy and Integrity using S/MIME: Tunneling SIP As a means of providing some degree of end-to-end authentication, integrity or confidentiality for SIP header fields, S/MIME can encapsulate entire SIP messages within MIME bodies of type ""message/sip"" and then apply MIME security to these bodies in the same manner as typical SIP bodies. These encapsulated SIP requests and responses do not constitute a separate dialog or transaction, they are a copy of the ""outer"" message that is used to verify integrity or to supply additional information. If a UAS receives a request that contains a tunneled ""message/sip"" S/MIME body, it SHOULD include a tunneled ""message/sip"" body in the response with the same smime-type. Any traditional MIME bodies (such as SDP) SHOULD be attached to the ""inner"" message so that they can also benefit from S/MIME security. Note that ""message/sip"" bodies can be sent as a part of a MIME ""multipart/mixed"" body if any unsecured MIME types should also be transmitted in a request. 23.4.1 Integrity and Confidentiality Properties of SIP Headers When the S/MIME integrity or confidentiality mechanisms are used, there may be discrepancies between the values in the ""inner"" message and values in the ""outer"" message. The rules for handling any such differences for all of the header fields described in this document are given in this section. Note that for the purposes of loose timestamping, all SIP messages that tunnel ""message/sip"" SHOULD contain a Date header in both the ""inner"" and ""outer"" headers. 23.4.1.1 Integrity Whenever integrity checks are performed, the integrity of a header field should be determined by matching the value of the header field in the signed body with that in the ""outer"" messages using the comparison rules of SIP as described in 20. Header fields that can be legitimately modified by proxy servers are: Request-URI, Via, Record-Route, Route, Max-Forwards, and Proxy- Authorization. If these header fields are not intact end-to-end, implementations SHOULD NOT consider this a breach of security. Changes to any other header fields defined in this document constitute an integrity violation; users MUST be notified of a discrepancy. Rosenberg, et. al. Standards Track [Page 207] RFC 3261 SIP: Session Initiation Protocol June 2002 23.4.1.2 Confidentiality When messages are encrypted, header fields may be included in the encrypted body that are not present in the ""outer"" message. Some header fields must always have a plaintext version because they are required header fields in requests and responses - these include: To, From, Call-ID, CSeq, Contact. While it is probably not useful to provide an encrypted alternative for the Call-ID, CSeq, or Contact, providing an alternative to the information in the ""outer"" To or From is permitted. Note that the values in an encrypted body are not used for the purposes of identifying transactions or dialogs - they are merely informational. If the From header field in an encrypted body differs from the value in the ""outer"" message, the value within the encrypted body SHOULD be displayed to the user, but MUST NOT be used in the ""outer"" header fields of any future messages. Primarily, a user agent will want to encrypt header fields that have an end-to-end semantic, including: Subject, Reply-To, Organization, Accept, Accept-Encoding, Accept-Language, Alert-Info, Error-Info, Authentication-Info, Expires, In-Reply-To, Require, Supported, Unsupported, Retry-After, User-Agent, Server, and Warning. If any of these header fields are present in an encrypted body, they should be used instead of any ""outer"" header fields, whether this entails displaying the header field values to users or setting internal states in the UA. They SHOULD NOT however be used in the ""outer"" headers of any future messages. If present, the Date header field MUST always be the same in the ""inner"" and ""outer"" headers. Since MIME bodies are attached to the ""inner"" message, implementations will usually encrypt MIME-specific header fields, including: MIME-Version, Content-Type, Content-Length, Content- Language, Content-Encoding and Content-Disposition. The ""outer"" message will have the proper MIME header fields for S/MIME bodies. These header fields (and any MIME bodies they preface) should be treated as normal MIME header fields and bodies received in a SIP message. It is not particularly useful to encrypt the following header fields: Min-Expires, Timestamp, Authorization, Priority, and WWW- Authenticate. This category also includes those header fields that can be changed by proxy servers (described in the preceding section). UAs SHOULD never include these in an ""inner"" message if they are not Rosenberg, et. al. Standards Track [Page 208] RFC 3261 SIP: Session Initiation Protocol June 2002 included in the ""outer"" message. UAs that receive any of these header fields in an encrypted body SHOULD ignore the encrypted values. Note that extensions to SIP may define additional header fields; the authors of these extensions should describe the integrity and confidentiality properties of such header fields. If a SIP UA encounters an unknown header field with an integrity violation, it MUST ignore the header field. 23.4.2 Tunneling Integrity and Authentication Tunneling SIP messages within S/MIME bodies can provide integrity for SIP header fields if the header fields that the sender wishes to secure are replicated in a ""message/sip"" MIME body signed with a CMS detached signature. Provided that the ""message/sip"" body contains at least the fundamental dialog identifiers (To, From, Call-ID, CSeq), then a signed MIME body can provide limited authentication. At the very least, if the certificate used to sign the body is unknown to the recipient and cannot be verified, the signature can be used to ascertain that a later request in a dialog was transmitted by the same certificate-holder that initiated the dialog. If the recipient of the signed MIME body has some stronger incentive to trust the certificate (they were able to validate it, they acquired it from a trusted repository, or they have used it frequently) then the signature can be taken as a stronger assertion of the identity of the subject of the certificate. In order to eliminate possible confusions about the addition or subtraction of entire header fields, senders SHOULD replicate all header fields from the request within the signed body. Any message bodies that require integrity protection MUST be attached to the ""inner"" message. If a Date header is present in a message with a signed body, the recipient SHOULD compare the header field value with its own internal clock, if applicable. If a significant time discrepancy is detected (on the order of an hour or more), the user agent SHOULD alert the user to the anomaly, and note that it is a potential security breach. If an integrity violation in a message is detected by its recipient, the message MAY be rejected with a 403 (Forbidden) response if it is a request, or any existing dialog MAY be terminated. UAs SHOULD notify users of this circumstance and request explicit guidance on how to proceed. Rosenberg, et. al. Standards Track [Page 209] RFC 3261 SIP: Session Initiation Protocol June 2002 The following is an example of the use of a tunneled ""message/sip"" body: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: multipart/signed; protocol=""application/pkcs7-signature""; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: message/sip INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <bob@biloxi.com> From: Alice <alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 147 v=0 o=UserA 2890844526 2890844526 IN IP4 here.com s=Session SDP c=IN IP4 pc33.atlanta.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required Rosenberg, et. al. Standards Track [Page 210] RFC 3261 SIP: Session Initiation Protocol June 2002 ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 23.4.3 Tunneling Encryption It may also be desirable to use this mechanism to encrypt a ""message/sip"" MIME body within a CMS EnvelopedData message S/MIME body, but in practice, most header fields are of at least some use to the network; the general use of encryption with S/MIME is to secure message bodies like SDP rather than message headers. Some informational header fields, such as the Subject or Organization could perhaps warrant end-to-end security. Headers defined by future SIP applications might also require obfuscation. Another possible application of encrypting header fields is selective anonymity. A request could be constructed with a From header field that contains no personal information (for example, sip:anonymous@anonymizer.invalid). However, a second From header field containing the genuine address-of-record of the originator could be encrypted within a ""message/sip"" MIME body where it will only be visible to the endpoints of a dialog. Note that if this mechanism is used for anonymity, the From header field will no longer be usable by the recipient of a message as an index to their certificate keychain for retrieving the proper S/MIME key to associated with the sender. The message must first be decrypted, and the ""inner"" From header field MUST be used as an index. In order to provide end-to-end integrity, encrypted ""message/sip"" MIME bodies SHOULD be signed by the sender. This creates a ""multipart/signed"" MIME body that contains an encrypted body and a signature, both of type ""application/pkcs7-mime"". Rosenberg, et. al. Standards Track [Page 211] RFC 3261 SIP: Session Initiation Protocol June 2002 In the following example, of an encrypted and signed message, the text boxed in asterisks (""*"") is encrypted: INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 To: Bob <sip:bob@biloxi.com> From: Anonymous <sip:anonymous@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Max-Forwards: 70 Date: Thu, 21 Feb 2002 13:02:03 GMT Contact: <sip:pc33.atlanta.com> Content-Type: multipart/signed; protocol=""application/pkcs7-signature""; micalg=sha1; boundary=boundary42 Content-Length: 568 --boundary42 Content-Type: application/pkcs7-mime; smime-type=enveloped-data; name=smime.p7m Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7m handling=required Content-Length: 231 *********************************************************** * Content-Type: message/sip * * * * INVITE sip:bob@biloxi.com SIP/2.0 * * Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 * * To: Bob <bob@biloxi.com> * * From: Alice <alice@atlanta.com>;tag=1928301774 * * Call-ID: a84b4c76e66710 * * CSeq: 314159 INVITE * * Max-Forwards: 70 * * Date: Thu, 21 Feb 2002 13:02:03 GMT * * Contact: <sip:alice@pc33.atlanta.com> * * * * Content-Type: application/sdp * * * * v=0 * * o=alice 53655765 2353687637 IN IP4 pc33.atlanta.com * * s=Session SDP * * t=0 0 * * c=IN IP4 pc33.atlanta.com * * m=audio 3456 RTP/AVP 0 1 3 99 * * a=rtpmap:0 PCMU/8000 * *********************************************************** Rosenberg, et. al. Standards Track [Page 212] RFC 3261 SIP: Session Initiation Protocol June 2002 --boundary42 Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename=smime.p7s; handling=required ghyHhHUujhJhjH77n8HHGTrfvbnj756tbB9HG4VQpfyF467GhIGfHfYT6 4VQpfyF467GhIGfHfYT6jH77n8HHGghyHhHUujhJh756tbB9HGTrfvbnj n8HHGTrfvhJhjH776tbB9HG4VQbnj7567GhIGfHfYT6ghyHhHUujpfyF4 7GhIGfHfYT64VQbnj756 --boundary42- 24 Examples In the following examples, we often omit the message body and the corresponding Content-Length and Content-Type header fields for brevity. 24.1 Registration Bob registers on start-up. The message flow is shown in Figure 9. Note that the authentication usually required for registration is not shown for simplicity. biloxi.com Bob's registrar softphone | | | REGISTER F1 | |<---------------| | 200 OK F2 | |--------------->| Figure 9: SIP Registration Example F1 REGISTER Bob -> Registrar REGISTER sip:registrar.biloxi.com SIP/2.0 Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0 Rosenberg, et. al. Standards Track [Page 213] RFC 3261 SIP: Session Initiation Protocol June 2002 The registration expires after two hours. The registrar responds with a 200 OK: F2 200 OK Registrar -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7 ;received=192.0.2.4 To: Bob <sip:bob@biloxi.com>;tag=2493k59kd From: Bob <sip:bob@biloxi.com>;tag=456248 Call-ID: 843817637684230@998sdasdh09 CSeq: 1826 REGISTER Contact: <sip:bob@192.0.2.4> Expires: 7200 Content-Length: 0 24.2 Session Setup This example contains the full details of the example session setup in Section 4. The message flow is shown in Figure 1. Note that these flows show the minimum required set of header fields - some other header fields such as Allow and Supported would normally be present. F1 INVITE Alice -> atlanta.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) Rosenberg, et. al. Standards Track [Page 214] RFC 3261 SIP: Session Initiation Protocol June 2002 F2 100 Trying atlanta.com proxy -> Alice SIP/2.0 100 Trying Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 F3 INVITE atlanta.com proxy -> biloxi.com proxy INVITE sip:bob@biloxi.com SIP/2.0 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 69 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) F4 100 Trying biloxi.com proxy -> atlanta.com proxy SIP/2.0 100 Trying Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 215] RFC 3261 SIP: Session Initiation Protocol June 2002 F5 INVITE biloxi.com proxy -> Bob INVITE sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 Max-Forwards: 68 To: Bob <sip:bob@biloxi.com> From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:alice@pc33.atlanta.com> Content-Type: application/sdp Content-Length: 142 (Alice's SDP not shown) F6 180 Ringing Bob -> biloxi.com proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 F7 180 Ringing biloxi.com proxy -> atlanta.com proxy SIP/2.0 180 Ringing Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 216] RFC 3261 SIP: Session Initiation Protocol June 2002 F8 180 Ringing atlanta.com proxy -> Alice SIP/2.0 180 Ringing Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 Contact: <sip:bob@192.0.2.4> CSeq: 314159 INVITE Content-Length: 0 F9 200 OK Bob -> biloxi.com proxy SIP/2.0 200 OK Via: SIP/2.0/UDP server10.biloxi.com;branch=z9hG4bK4b43c2ff8.1 ;received=192.0.2.3 Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) F10 200 OK biloxi.com proxy -> atlanta.com proxy SIP/2.0 200 OK Via: SIP/2.0/UDP bigbox3.site3.atlanta.com;branch=z9hG4bK77ef4c2312983.1 ;received=192.0.2.2 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) Rosenberg, et. al. Standards Track [Page 217] RFC 3261 SIP: Session Initiation Protocol June 2002 F11 200 OK atlanta.com proxy -> Alice SIP/2.0 200 OK Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds8 ;received=192.0.2.1 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 INVITE Contact: <sip:bob@192.0.2.4> Content-Type: application/sdp Content-Length: 131 (Bob's SDP not shown) F12 ACK Alice -> Bob ACK sip:bob@192.0.2.4 SIP/2.0 Via: SIP/2.0/UDP pc33.atlanta.com;branch=z9hG4bKnashds9 Max-Forwards: 70 To: Bob <sip:bob@biloxi.com>;tag=a6c85cf From: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 314159 ACK Content-Length: 0 The media session between Alice and Bob is now established. Bob hangs up first. Note that Bob's SIP phone maintains its own CSeq numbering space, which, in this example, begins with 231. Since Bob is making the request, the To and From URIs and tags have been swapped. F13 BYE Bob -> Alice BYE sip:alice@pc33.atlanta.com SIP/2.0 Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 Max-Forwards: 70 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 Rosenberg, et. al. Standards Track [Page 218] RFC 3261 SIP: Session Initiation Protocol June 2002 F14 200 OK Alice -> Bob SIP/2.0 200 OK Via: SIP/2.0/UDP 192.0.2.4;branch=z9hG4bKnashds10 From: Bob <sip:bob@biloxi.com>;tag=a6c85cf To: Alice <sip:alice@atlanta.com>;tag=1928301774 Call-ID: a84b4c76e66710 CSeq: 231 BYE Content-Length: 0 The SIP Call Flows document [40] contains further examples of SIP messages. 25 Augmented BNF for the SIP Protocol All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that are used by this specification, and not repeated here. Implementers need to be familiar with the notation and content of RFC 2234 in order to understand this specification. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions to clarify the use of rule names. The use of square brackets is redundant syntactically. It is used as a semantic hint that the specific parameter is optional to use. 25.1 Basic Rules The following rules are used throughout this specification to describe basic parsing constructs. The US-ASCII coded character set is defined by ANSI X3.4-1986. alphanum = ALPHA / DIGIT Rosenberg, et. al. Standards Track [Page 219] RFC 3261 SIP: Session Initiation Protocol June 2002 Several rules are incorporated from RFC 2396 [5] but are updated to make them compliant with RFC 2234 [10]. These include: reserved = "";"" / ""/"" / ""?"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" unreserved = alphanum / mark mark = ""-"" / ""_"" / ""."" / ""!"" / ""~"" / ""*"" / ""'"" / ""("" / "")"" escaped = ""%"" HEXDIG HEXDIG SIP header field values can be folded onto multiple lines if the continuation line begins with a space or horizontal tab. All linear white space, including folding, has the same semantics as SP. A recipient MAY replace any linear white space with a single SP before interpreting the field value or forwarding the message downstream. This is intended to behave exactly as HTTP/1.1 as described in RFC 2616 [8]. The SWS construct is used when linear white space is optional, generally between tokens and separators. LWS = [*WSP CRLF] 1*WSP ; linear whitespace SWS = [LWS] ; sep whitespace To separate the header name from the rest of value, a colon is used, which, by the above rule, allows whitespace before, but no line break, and whitespace after, including a linebreak. The HCOLON defines this construct. HCOLON = *( SP / HTAB ) "":"" SWS The TEXT-UTF8 rule is only used for descriptive field contents and values that are not intended to be interpreted by the message parser. Words of *TEXT-UTF8 contain characters from the UTF-8 charset (RFC 2279 [7]). The TEXT-UTF8-TRIM rule is used for descriptive field contents that are n t quoted strings, where leading and trailing LWS is not meaningful. In this regard, SIP differs from HTTP, which uses the ISO 8859-1 character set. TEXT-UTF8-TRIM = 1*TEXT-UTF8char *(*LWS TEXT-UTF8char) TEXT-UTF8char = %x21-7E / UTF8-NONASCII UTF8-NONASCII = %xC0-DF 1UTF8-CONT / %xE0-EF 2UTF8-CONT / %xF0-F7 3UTF8-CONT / %xF8-Fb 4UTF8-CONT / %xFC-FD 5UTF8-CONT UTF8-CONT = %x80-BF Rosenberg, et. al. Standards Track [Page 220] RFC 3261 SIP: Session Initiation Protocol June 2002 A CRLF is allowed in the definition of TEXT-UTF8-TRIM only as part of a header field continuation. It is expected that the folding LWS will be replaced with a single SP before interpretation of the TEXT- UTF8-TRIM value. Hexadecimal numeric characters are used in several protocol elements. Some elements (authentication) force hex alphas to be lower case. LHEX = DIGIT / %x61-66 ;lowercase a-f Many SIP header field values consist of words separated by LWS or special characters. Unless otherwise stated, tokens are case- insensitive. These special characters MUST be in a quoted string to be used within a parameter value. The word construct is used in Call-ID to allow most separators to be used. token = 1*(alphanum / ""-"" / ""."" / ""!"" / ""%"" / ""*"" / ""_"" / ""+"" / ""`"" / ""'"" / ""~"" ) separators = ""("" / "")"" / ""<"" / "">"" / ""@"" / "","" / "";"" / "":"" / ""\"" / DQUOTE / ""/"" / ""["" / ""]"" / ""?"" / ""="" / ""{"" / ""}"" / SP / HTAB word = 1*(alphanum / ""-"" / ""."" / ""!"" / ""%"" / ""*"" / ""_"" / ""+"" / ""`"" / ""'"" / ""~"" / ""("" / "")"" / ""<"" / "">"" / "":"" / ""\"" / DQUOTE / ""/"" / ""["" / ""]"" / ""?"" / ""{"" / ""}"" ) When tokens are used or separators are used between elements, whitespace is often allowed before or after these characters: STAR = SWS ""*"" SWS ; asterisk SLASH = SWS ""/"" SWS ; slash EQUAL = SWS ""="" SWS ; equal LPAREN = SWS ""("" SWS ; left parenthesis RPAREN = SWS "")"" SWS ; right parenthesis RAQUOT = "">"" SWS ; right angle quote LAQUOT = SWS ""<""; left angle quote COMMA = SWS "","" SWS ; comma SEMI = SWS "";"" SWS ; semicolon COLON = SWS "":"" SWS ; colon LDQUOT = SWS DQUOTE; open double quotation mark RDQUOT = DQUOTE SWS ; close double quotation mark Rosenberg, et. al. Standards Track [Page 221] RFC 3261 SIP: Session Initiation Protocol June 2002 Comments can be included in some SIP header fields by surrounding the comment text with parentheses. Comments are only allowed in fields containing ""comment"" as part of their field value definition. In all other fields, parentheses are considered part of the field value. comment = LPAREN *(ctext / quoted-pair / comment) RPAREN ctext = %x21-27 / %x2A-5B / %x5D-7E / UTF8-NONASCII / LWS ctext includes all chars except left and right parens and backslash. A string of text is parsed as a single word if it is quoted using double-quote marks. In quoted strings, quotation marks ("") and backslashes (\) need to be escaped. quoted-string = SWS DQUOTE *(qdtext / quoted-pair ) DQUOTE qdtext = LWS / %x21 / %x23-5B / %x5D-7E / UTF8-NONASCII The backslash character (""\"") MAY be used as a single-character quoting mechanism only within quoted-string and comment constructs. Unlike HTTP/1.1, the characters CR and LF cannot be escaped by this mechanism to avoid conflict with line folding and header separation. quoted-pair = ""\"" (%x00-09 / %x0B-0C / %x0E-7F) SIP-URI = ""sip:"" [ userinfo ] hostport uri-parameters [ headers ] SIPS-URI = ""sips:"" [ userinfo ] hostport uri-parameters [ headers ] userinfo = ( user / telephone-subscriber ) [ "":"" password ] ""@"" user = 1*( unreserved / escaped / user-unreserved ) user-unreserved = ""&"" / ""="" / ""+"" / ""$"" / "","" / "";"" / ""?"" / ""/"" password = *( unreserved / escaped / ""&"" / ""="" / ""+"" / ""$"" / "","" ) hostport = host [ "":"" port ] host = hostname / IPv4address / IPv6reference hostname = *( domainlabel ""."" ) toplabel [ ""."" ] domainlabel = alphanum / alphanum *( alphanum / ""-"" ) alphanum toplabel = ALPHA / ALPHA *( alphanum / ""-"" ) alphanum Rosenberg, et. al. Standards Track [Page 222] RFC 3261 SIP: Session Initiation Protocol June 2002 IPv4address = 1*3DIGIT ""."" 1*3DIGIT ""."" 1*3DIGIT ""."" 1*3DIGIT IPv6reference = ""["" IPv6address ""]"" IPv6address = hexpart [ "":"" IPv4address ] hexpart = hexseq / hexseq ""::"" [ hexseq ] / ""::"" [ hexseq ] hexseq = hex4 *( "":"" hex4) hex4 = 1*4HEXDIG port = 1*DIGIT The BNF for telephone-subscriber can be found in RFC 2806 [9]. Note, however, that any characters allowed there that are not allowed in the user part of the SIP URI MUST be escaped. uri-parameters = *( "";"" uri-parameter) uri-parameter = transport-param / user-param / method-param / ttl-param / maddr-param / lr-param / other-param transport-param = ""transport="" ( ""udp"" / ""tcp"" / ""sctp"" / ""tls"" / other-transport) other-transport = token user-param = ""user="" ( ""phone"" / ""ip"" / other-user) other-user = token method-param = ""method="" Method ttl-param = ""ttl="" ttl maddr-param = ""maddr="" host lr-param = ""lr"" other-param = pname [ ""="" pvalue ] pname = 1*paramchar pvalue = 1*paramchar paramchar = param-unreserved / unreserved / escaped param-unreserved = ""["" / ""]"" / ""/"" / "":"" / ""&"" / ""+"" / ""$"" headers = ""?"" header *( ""&"" header ) header = hname ""="" hvalue hname = 1*( hnv-unreserved / unreserved / escaped ) hvalue = *( hnv-unreserved / unreserved / escaped ) hnv-unreserved = ""["" / ""]"" / ""/"" / ""?"" / "":"" / ""+"" / ""$"" SIP-message = Request / Response Request = Request-Line *( message-header ) CRLF [ message-body ] Request-Line = Method SP Request-URI SP SIP-Version CRLF Request-URI = SIP-URI / SIPS-URI / absoluteURI absoluteURI = scheme "":"" ( hier-part / opaque-part ) hier-part = ( net-path / abs-path ) [ ""?"" query ] net-path = ""//"" authority [ abs-path ] abs-path = ""/"" path-segments Rosenberg, et. al."
"Standards Track [Page 223] RFC 3261 SIP: Session Initiation Protocol June 2002 opaque-part = uric-no-slash *uric uric = reserved / unreserved / escaped uric-no-slash = unreserved / escaped / "";"" / ""?"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" path-segments = segment *( ""/"" segment ) segment = *pchar *( "";"" param ) param = *pchar pchar = unreserved / escaped / "":"" / ""@"" / ""&"" / ""="" / ""+"" / ""$"" / "","" scheme = ALPHA *( ALPHA / DIGIT / ""+"" / ""-"" / ""."" ) authority = srvr / reg-name srvr = [ [ userinfo ""@"" ] hostport ] reg-name = 1*( unreserved / escaped / ""$"" / "","" / "";"" / "":"" / ""@"" / ""&"" / ""="" / ""+"" ) query = *uric SIP-Version = ""SIP"" ""/"" 1*DIGIT ""."" 1*DIGIT message-header = (Accept / Accept-Encoding / Accept-Language / Alert-Info / Allow / Authentication-Info / Authorization / Call-ID / Call-Info / Contact / Content-Disposition / Content-Encoding / Content-Language / Content-Length / Content-Type / CSeq / Date / Error-Info / Expires / From / In-Reply-To / Max-Forwards / MIME-Version / Min-Expires / Organization / Priority / Proxy-Authenticate / Proxy-Authorization / Proxy-Require / Record-Route / Reply-To Rosenberg, et. al. Standards Track [Page 224] RFC 3261 SIP: Session Initiation Protocol June 2002 / Require / Retry-After / Route / Server / Subject / Supported / Timestamp / To / Unsupported / User-Agent / Via / Warning / WWW-Authenticate / extension-header) CRLF INVITEm = %x49.4E.56.49.54.45 ; INVITE in caps ACKm = %x41.43.4B ; ACK in caps OPTIONSm = %x4F.50.54.49.4F.4E.53 ; OPTIONS in caps BYEm = %x42.59.45 ; BYE in caps CANCELm = %x43.41.4E.43.45.4C ; CANCEL in caps REGISTERm = %x52.45.47.49.53.54.45.52 ; REGISTER in caps Method = INVITEm / ACKm / OPTIONSm / BYEm / CANCELm / REGISTERm / extension-method extension-method = token Response = Status-Line *( message-header ) CRLF [ message-body ] Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF Status-Code = Informational / Redirection / Success / Client-Error / Server-Error / Global-Failure / extension-code extension-code = 3DIGIT Reason-Phrase = *(reserved / unreserved / escaped / UTF8-NONASCII / UTF8-CONT / SP / HTAB) Informational = ""100"" ; Trying / ""180"" ; Ringing / ""181"" ; Call Is Being Forwarded / ""182"" ; Queued / ""183"" ; Session Progress Rosenberg, et. al. Standards Track [Page 225] RFC 3261 SIP: Session Initiation Protocol June 2002 Success = ""200"" ; OK Redirection = ""300"" ; Multiple Choices / ""301"" ; Moved Permanently / ""302"" ; Moved Temporarily / ""305"" ; Use Proxy / ""380"" ; Alternative Service Client-Error = ""400"" ; Bad Request / ""401"" ; Unauthorized / ""402"" ; Payment Required / ""403"" ; Forbidden / ""404"" ; Not Found / ""405"" ; Method Not Allowed / ""406"" ; Not Acceptable / ""407"" ; Proxy Authentication Required / ""408"" ; Request Timeout / ""410"" ; Gone / ""413"" ; Request Entity Too Large / ""414"" ; Request-URI Too Large / ""415"" ; Unsupported Media Type / ""416"" ; Unsupported URI Scheme / ""420"" ; Bad Extension / ""421"" ; Extension Required / ""423"" ; Interval Too Brief / ""480"" ; Temporarily not available / ""481"" ; Call Leg/Transaction Does Not Exist / ""482"" ; Loop Detected / ""483"" ; Too Many Hops / ""484"" ; Address Incomplete / ""485"" ; Ambiguous / ""486"" ; Busy Here / ""487"" ; Request Terminated / ""488"" ; Not Acceptable Here / ""491"" ; Request Pending / ""493"" ; Undecipherable Server-Error = ""500"" ; Internal Server Error / ""501"" ; Not Implemented / ""502"" ; Bad Gateway / ""503"" ; Service Unavailable / ""504"" ; Server Time-out / ""505"" ; SIP Version not supported / ""513"" ; Message Too Large Rosenberg, et. al. Standards Track [Page 226] RFC 3261 SIP: Session Initiation Protocol June 2002 Global-Failure = ""600"" ; Busy Everywhere / ""603"" ; Decline / ""604"" ; Does not exist anywhere / ""606"" ; Not Acceptable Accept = ""Accept"" HCOLON [ accept-range *(COMMA accept-range) ] accept-range = media-range *(SEMI accept-param) media-range = ( ""*/*"" / ( m-type SLASH ""*"" ) / ( m-type SLASH m-subtype ) ) *( SEMI m-parameter ) accept-param = (""q"" EQUAL qvalue) / generic-param qvalue = ( ""0"" [ ""."" 0*3DIGIT ] ) / ( ""1"" [ ""."" 0*3(""0"") ] ) generic-param = token [ EQUAL gen-value ] gen-value = token / host / quoted-string Accept-Encoding = ""Accept-Encoding"" HCOLON [ encoding *(COMMA encoding) ] encoding = codings *(SEMI accept-param) codings = content-coding / ""*"" content-coding = token Accept-Language = ""Accept-Language"" HCOLON [ language *(COMMA language) ] language = language-range *(SEMI accept-param) language-range = ( ( 1*8ALPHA *( ""-"" 1*8ALPHA ) ) / ""*"" ) Alert-Info = ""Alert-Info"" HCOLON alert-param *(COMMA alert-param) alert-param = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Allow = ""Allow"" HCOLON [Method *(COMMA Method)] Authorization = ""Authorization"" HCOLON credentials credentials = (""Digest"" LWS digest-response) / other-response digest-response = dig-resp *(COMMA dig-resp) dig-resp = username / realm / nonce / digest-uri / dresponse / algorithm / cnonce / opaque / message-qop / nonce-count / auth-param username = ""username"" EQUAL username-value username-value = quoted-string digest-uri = ""uri"" EQUAL LDQUOT digest-uri-value RDQUOT digest-uri-value = rquest-uri ; Equal to request-uri as specified by HTTP/1.1 message-qop = ""qop"" EQUAL qop-value Rosenberg, et. al. Standards Track [Page 227] RFC 3261 SIP: Session Initiation Protocol June 2002 cnonce = ""cnonce"" EQUAL cnonce-value cnonce-value = nonce-value nonce-count = ""nc"" EQUAL nc-value nc-value = 8LHEX dresponse = ""response"" EQUAL request-digest request-digest = LDQUOT 32LHEX RDQUOT auth-param = auth-param-name EQUAL ( token / quoted-string ) auth-param-name = token other-response = auth-scheme LWS auth-param *(COMMA auth-param) auth-scheme = token Authentication-Info = ""Authentication-Info"" HCOLON ainfo *(COMMA ainfo) ainfo = nextnonce / message-qop / response-auth / cnonce / nonce-count nextnonce = ""nextnonce"" EQUAL nonce-value response-auth = ""rspauth"" EQUAL response-digest response-digest = LDQUOT *LHEX RDQUOT Call-ID = ( ""Call-ID"" / ""i"" ) HCOLON callid callid = word [ ""@"" word ] Call-Info = ""Call-Info"" HCOLON info *(COMMA info) info = LAQUOT absoluteURI RAQUOT *( SEMI info-param) info-param = ( ""purpose"" EQUAL ( ""icon"" / ""info"" / ""card"" / token ) ) / generic-param Contact = (""Contact"" / ""m"" ) HCOLON ( STAR / (contact-param *(COMMA contact-param))) contact-param = (name-addr / addr-spec) *(SEMI contact-params) name-addr = [ display-name ] LAQUOT addr-spec RAQUOT addr-spec = SIP-URI / SIPS-URI / absoluteURI display-name = *(token LWS)/ quoted-string contact-params = c-p-q / c-p-expires / contact-extension c-p-q = ""q"" EQUAL qvalue c-p-expires = ""expires"" EQUAL delta-seconds contact-extension = generic-param delta-seconds = 1*DIGIT Content-Disposition = ""Content-Disposition"" HCOLON disp-type *( SEMI disp-param ) disp-type = ""render"" / ""session"" / ""icon"" / ""alert"" / disp-extension-token Rosenberg, et. al. Standards Track [Page 228] RFC 3261 SIP: Session Initiation Protocol June 2002 disp-param = handling-param / generic-param handling-param = ""handling"" EQUAL ( ""optional"" / ""required"" / other-handling ) other-handling = token disp-extension-token = token Content-Encoding = ( ""Content-Encoding"" / ""e"" ) HCOLON content-coding *(COMMA content-coding) Content-Language = ""Content-Language"" HCOLON language-tag *(COMMA language-tag) language-tag = primary-tag *( ""-"" subtag ) primary-tag = 1*8ALPHA subtag = 1*8ALPHA Content-Length = ( ""Content-Length"" / ""l"" ) HCOLON 1*DIGIT Content-Type = ( ""Content-Type"" / ""c"" ) HCOLON media-type media-type = m-type SLASH m-subtype *(SEMI m-parameter) m-type = discrete-type / composite-type discrete-type = ""text"" / ""image"" / ""audio"" / ""video"" / ""application"" / extension-token composite-type = ""message"" / ""multipart"" / extension-token extension-token = ietf-token / x-token ietf-token = token x-token = ""x-"" token m-subtype = extension-token / iana-token iana-token = token m-parameter = m-attribute EQUAL m-value m-attribute = token m-value = token / quoted-string CSeq = ""CSeq"" HCOLON 1*DIGIT LWS Method Date = ""Date"" HCOLON SIP-date SIP-date = rfc1123-date rfc1123-date = wkday "","" SP date1 SP time SP ""GMT"" date1 = 2DIGIT SP month SP 4DIGIT ; day month year (e.g., 02 Jun 1982) time = 2DIGIT "":"" 2DIGIT "":"" 2DIGIT ; 00:00:00 - 23:59:59 wkday = ""Mon"" / ""Tue"" / ""Wed"" / ""Thu"" / ""Fri"" / ""Sat"" / ""Sun"" month = ""Jan"" / ""Feb"" / ""Mar"" / ""Apr"" / ""May"" / ""Jun"" / ""Jul"" / ""Aug"" / ""Sep"" / ""Oct"" / ""Nov"" / ""Dec"" Error-Info = ""Error-Info"" HCOLON error-uri *(COMMA error-uri) Rosenberg, et. al. Standards Track [Page 229] RFC 3261 SIP: Session Initiation Protocol June 2002 error-uri = LAQUOT absoluteURI RAQUOT *( SEMI generic-param ) Expires = ""Expires"" HCOLON delta-seconds From = ( ""From"" / ""f"" ) HCOLON from-spec from-spec = ( name-addr / addr-spec ) *( SEMI from-param ) from-param = tag-param / generic-param tag-param = ""tag"" EQUAL token In-Reply-To = ""In-Reply-To"" HCOLON callid *(COMMA callid) Max-Forwards = ""Max-Forwards"" HCOLON 1*DIGIT MIME-Version = ""MIME-Version"" HCOLON 1*DIGIT ""."" 1*DIGIT Min-Expires = ""Min-Expires"" HCOLON delta-seconds Organization = ""Organization"" HCOLON [TEXT-UTF8-TRIM] Priority = ""Priority"" HCOLON priority-value priority-value = ""emergency"" / ""urgent"" / ""normal"" / ""non-urgent"" / other-priority other-priority = token Proxy-Authenticate = ""Proxy-Authenticate"" HCOLON challenge challenge = (""Digest"" LWS digest-cln *(COMMA digest-cln)) / other-challenge other-challenge = auth-scheme LWS auth-param *(COMMA auth-param) digest-cln = realm / domain / nonce / opaque / stale / algorithm / qop-options / auth-param realm = ""realm"" EQUAL realm-value realm-value = quoted-string domain = ""domain"" EQUAL LDQUOT URI *( 1*SP URI ) RDQUOT URI = absoluteURI / abs-path nonce = ""nonce"" EQUAL nonce-value nonce-value = quoted-string opaque = ""opaque"" EQUAL quoted-string stale = ""stale"" EQUAL ( ""true"" / ""false"" ) algorithm = ""algorithm"" EQUAL ( ""MD5"" / ""MD5-sess"" / token ) qop-options = ""qop"" EQUAL LDQUOT qop-value *("","" qop-value) RDQUOT qop-value = ""auth"" / ""auth-int"" / token Proxy-Authorization = ""Proxy-Authorization"" HCOLON credentials Rosenberg, et. al. Standards Track [Page 230] RFC 3261 SIP: Session Initiation Protocol June 2002 Proxy-Require = ""Proxy-Require"" HCOLON option-tag *(COMMA option-tag) option-tag = token Record-Route = ""Record-Route"" HCOLON rec-route *(COMMA rec-route) rec-route = name-addr *( SEMI rr-param ) rr-param = generic-param Reply-To = ""Reply-To"" HCOLON rplyto-spec rplyto-spec = ( name-addr / addr-spec ) *( SEMI rplyto-param ) rplyto-param = generic-param Require = ""Require"" HCOLON option-tag *(COMMA option-tag) Retry-After = ""Retry-After"" HCOLON delta-seconds [ comment ] *( SEMI retry-param ) retry-param = (""duration"" EQUAL delta-seconds) / generic-param Route = ""Route"" HCOLON route-param *(COMMA route-param) route-param = name-addr *( SEMI rr-param ) Server = ""Server"" HCOLON server-val *(LWS server-val) server-val = product / comment product = token [SLASH product-version] product-version = token Subject = ( ""Subject"" / ""s"" ) HCOLON [TEXT-UTF8-TRIM] Supported = ( ""Supported"" / ""k"" ) HCOLON [option-tag *(COMMA option-tag)] Timestamp = ""Timestamp"" HCOLON 1*(DIGIT) [ ""."" *(DIGIT) ] [ LWS delay ] delay = *(DIGIT) [ ""."" *(DIGIT) ] To = ( ""To"" / ""t"" ) HCOLON ( name-addr / addr-spec ) *( SEMI to-param ) to-param = tag-param / generic-param Unsupported = ""Unsupported"" HCOLON option-tag *(COMMA option-tag) User-Agent = ""User-Agent"" HCOLON server-val *(LWS server-val) Rosenberg, et. al. Standards Track [Page 231] RFC 3261 SIP: Session Initiation Protocol June 2002 Via = ( ""Via"" / ""v"" ) HCOLON via-parm *(COMMA via-parm) via-parm = sent-protocol LWS sent-by *( SEMI via-params ) via-params = via-ttl / via-maddr / via-received / via-branch / via-extension via-ttl = ""ttl"" EQUAL ttl via-maddr = ""maddr"" EQUAL host via-received = ""received"" EQUAL (IPv4address / IPv6address) via-branch = ""branch"" EQUAL token via-extension = generic-param sent-protocol = protocol-name SLASH protocol-version SLASH transport protocol-name = ""SIP"" / token protocol-version = token transport = ""UDP"" / ""TCP"" / ""TLS"" / ""SCTP"" / other-transport sent-by = host [ COLON port ] ttl = 1*3DIGIT ; 0 to 255 Warning = ""Warning"" HCOLON warning-value *(COMMA warning-value) warning-value = warn-code SP warn-agent SP warn-text warn-code = 3DIGIT warn-agent = hostport / pseudonym ; the name or pseudonym of the server adding ; the Warning header, for use in debugging warn-text = quoted-string pseudonym = token WWW-Authenticate = ""WWW-Authenticate"" HCOLON challenge extension-header = header-name HCOLON header-value header-name = token header-value = *(TEXT-UTF8char / UTF8-CONT / LWS) message-body = *OCTET 26 Security Considerations: Threat Model and Security Usage Recommendations SIP is not an easy protocol to secure. Its use of intermediaries, its multi-faceted trust relationships, its expected usage between elements with no trust at all, and its user-to-user operation make security far from trivial. Security solutions are needed that are deployable today, without extensive coordination, in a wide variety of environments and usages. In order to meet these diverse needs, several distinct mechanisms applicable to different aspects and usages of SIP will be required. Rosenberg, et. al. Standards Track [Page 232] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that the security of SIP signaling itself has no bearing on the security of protocols used in concert with SIP such as RTP, or with the security implications of any specific bodies SIP might carry (although MIME security plays a substantial role in securing SIP). Any media associated with a session can be encrypted end-to-end independently of any associated SIP signaling. Media encryption is outside the scope of this document. The considerations that follow first examine a set of classic threat models that broadly identify the security needs of SIP. The set of security services required to address these threats is then detailed, followed by an explanation of several security mechanisms that can be used to provide these services. Next, the requirements for implementers of SIP are enumerated, along with exemplary deployments in which these security mechanisms could be used to improve the security of SIP. Some notes on privacy conclude this section. 26.1 Attacks and Threat Models This section details some threats that should be common to most deployments of SIP. These threats have been chosen specifically to illustrate each of the security services that SIP requires. The following examples by no means provide an exhaustive list of the threats against SIP; rather, these are ""classic"" threats that demonstrate the need for particular security services that can potentially prevent whole categories of threats. These attacks assume an environment in which attackers can potentially read any packet on the network - it is anticipated that SIP will frequently be used on the public Internet. Attackers on the network may be able to modify packets (perhaps at some compromised intermediary). Attackers may wish to steal services, eavesdrop on communications, or disrupt sessions. 26.1.1 Registration Hijacking The SIP registration mechanism allows a user agent to identify itself to a registrar as a device at which a user (designated by an address of record) is located. A registrar assesses the identity asserted in the From header field of a REGISTER message to determine whether this request can modify the contact addresses associated with the address-of-record in the To header field. While these two fields are frequently the same, there are many valid deployments in which a third-party may register contacts on a user's behalf. Rosenberg, et. al. Standards Track [Page 233] RFC 3261 SIP: Session Initiation Protocol June 2002 The From header field of a SIP request, however, can be modified arbitrarily by the owner of a UA, and this opens the door to malicious registrations. An attacker that successfully impersonates a party authorized to change contacts associated with an address-of- record could, for example, de-register all existing contacts for a URI and then register their own device as the appropriate contact address, thereby directing all requests for the affected user to the attacker's device. This threat belongs to a family of threats that rely on the absence of cryptographic assurance of a request's originator. Any SIP UAS that represents a valuable service (a gateway that interworks SIP requests with traditional telephone calls, for example) might want to control access to its resources by authenticating requests that it receives. Even end-user UAs, for example SIP phones, have an interest in ascertaining the identities of originators of requests. This threat demonstrates the need for security services that enable SIP entities to authenticate the originators of requests. 26.1.2 Impersonating a Server The domain to which a request is destined is generally specified in the Request-URI. UAs commonly contact a server in this domain directly in order to deliver a request. However, there is always a possibility that an attacker could impersonate the remote server, and that the UA's request could be intercepted by some other party. For example, consider a case in which a redirect server at one domain, chicago.com, impersonates a redirect server at another domain, biloxi.com. A user agent sends a request to biloxi.com, but the redirect server at chicago.com answers with a forged response that has appropriate SIP header fields for a response from biloxi.com. The forged contact addresses in the redirection response could direct the originating UA to inappropriate or insecure resources, or simply prevent requests for biloxi.com from succeeding. This family of threats has a vast membership, many of which are critical. As a converse to the registration hijacking threat, consider the case in which a registration sent to biloxi.com is intercepted by chicago.com, which replies to the intercepted registration with a forged 301 (Moved Permanently) response. This response might seem to come from biloxi.com yet designate chicago.com as the appropriate registrar. All future REGISTER requests from the originating UA would then go to chicago.com. Prevention of this threat requires a means by which UAs can authenticate the servers to whom they send requests. Rosenberg, et. al. Standards Track [Page 234] RFC 3261 SIP: Session Initiation Protocol June 2002 26.1.3 Tampering with Message Bodies As a matter of course, SIP UAs route requests through trusted proxy servers. Regardless of how that trust is established (authentication of proxies is discussed elsewhere in this section), a UA may trust a proxy server to route a request, but not to inspect or possibly modify the bodies contained in that request. Consider a UA that is using SIP message bodies to communicate session encryption keys for a media session. Although it trusts the proxy server of the domain it is contacting to deliver signaling properly, it may not want the administrators of that domain to be capable of decrypting any subsequent media session. Worse yet, if the proxy server were actively malicious, it could modify the session key, either acting as a man-in-the-middle, or perhaps changing the security characteristics requested by the originating UA. This family of threats applies not only to session keys, but to most conceivable forms of content carried end-to-end in SIP. These might include MIME bodies that should be rendered to the user, SDP, or encapsulated telephony signals, among others. Attackers might attempt to modify SDP bodies, for example, in order to point RTP media streams to a wiretapping device in order to eavesdrop on subsequent voice communications. Also note that some header fields in SIP are meaningful end-to-end, for example, Subject. UAs might be protective of these header fields as well as bodies (a malicious intermediary changing the Subject header field might make an important request appear to be spam, for example). However, since many header fields are legitimately inspected or altered by proxy servers as a request is routed, not all header fields should be secured end-to-end. For these reasons, the UA might want to secure SIP message bodies, and in some limited cases header fields, end-to-end. The security services required for bodies include confidentiality, integrity, and authentication. These end-to-end services should be independent of the means used to secure interactions with intermediaries such as proxy servers. 26.1.4 Tearing Down Sessions Once a dialog has been established by initial messaging, subsequent requests can be sent that modify the state of the dialog and/or session. It is critical that principals in a session can be certain that such requests are not forged by attackers. Rosenberg, et. al. Standards Track [Page 235] RFC 3261 SIP: Session Initiation Protocol June 2002 Consider a case in which a third-party attacker captures some initial messages in a dialog shared by two parties in order to learn the parameters of the session (To tag, From tag, and so forth) and then inserts a BYE request into the session. The attacker could opt to forge the request such that it seemed to come from either participant. Once the BYE is received by its target, the session will be torn down prematurely. Similar mid-session threats include the transmission of forged re- INVITEs that alter the session (possibly to reduce session security or redirect media streams as part of a wiretapping attack). The most effective countermeasure to this threat is the authentication of the sender of the BYE. In this instance, the recipient needs only know that the BYE came from the same party with whom the corresponding dialog was established (as opposed to ascertaining the absolute identity of the sender). Also, if the attacker is unable to learn the parameters of the session due to confidentiality, it would not be possible to forge the BYE. However, some intermediaries (like proxy servers) will need to inspect those parameters as the session is established. 26.1.5 Denial of Service and Amplification Denial-of-service attacks focus on rendering a particular network element unavailable, usually by directing an excessive amount of network traffic at its interfaces. A distributed denial-of-service attack allows one network user to cause multiple network hosts to flood a target host with a large amount of network traffic. In many architectures, SIP proxy servers face the public Internet in order to accept requests from worldwide IP endpoints. SIP creates a number of potential opportunities for distributed denial-of-service attacks that must be recognized and addressed by the implementers and operators of SIP systems. Attackers can create bogus requests that contain a falsified source IP address and a corresponding Via header field that identify a targeted host as the originator of the request and then send this request to a large number of SIP network elements, thereby using hapless SIP UAs or proxies to generate denial-of-service traffic aimed at the target. Similarly, attackers might use falsified Route header field values in a request that identify the target host and then send such messages to forking proxies that will amplify messaging sent to the target. Rosenberg, et. al. Standards Track [Page 236] RFC 3261 SIP: Session Initiation Protocol June 2002 Record-Route could be used to similar effect when the attacker is certain that the SIP dialog initiated by the request will result in numerous transactions originating in the backwards direction. A number of denial-of-service attacks open up if REGISTER requests are not properly authenticated and authorized by registrars. Attackers could de-register some or all users in an administrative domain, thereby preventing these users from being invited to new sessions. An attacker could also register a large number of contacts designating the same host for a given address-of-record in order to use the registrar and any associated proxy servers as amplifiers in a denial-of-service attack. Attackers might also attempt to deplete available memory and disk resources of a registrar by registering huge numbers of bindings. The use of multicast to transmit SIP requests can greatly increase the potential for denial-of-service attacks. These problems demonstrate a general need to define architectures that minimize the risks of denial-of-service, and the need to be mindful in recommendations for security mechanisms of this class of attacks. 26.2 Security Mechanisms From the threats described above, we gather that the fundamental security services required for the SIP protocol are: preserving the confidentiality and integrity of messaging, preventing replay attacks or message spoofing, providing for the authentication and privacy of the participants in a session, and preventing denial-of-service attacks. Bodies within SIP messages separately require the security services of confidentiality, integrity, and authentication. Rather than defining new security mechanisms specific to SIP, SIP reuses wherever possible existing security models derived from the HTTP and SMTP space. Full encryption of messages provides the best means to preserve the confidentiality of signaling - it can also guarantee that messages are not modified by any malicious intermediaries. However, SIP requests and responses cannot be naively encrypted end-to-end in their entirety because message fields such as the Request-URI, Route, and Via need to be visible to proxies in most network architectures so that SIP requests are routed correctly. Note that proxy servers need to modify some features of messages as well (such as adding Via header field values) in order for SIP to function. Proxy servers must therefore be trusted, to some degree, by SIP UAs. To this purpose, low-layer security mechanisms for SIP are recommended, which Rosenberg, et. al. Standards Track [Page 237] RFC 3261 SIP: Session Initiation Protocol June 2002 encrypt the entire SIP requests or responses on the wire on a hop- by-hop basis, and that allow endpoints to verify the identity of proxy servers to whom they send requests. SIP entities also have a need to identify one another in a secure fashion. When a SIP endpoint asserts the identity of its user to a peer UA or to a proxy server, that identity should in some way be verifiable. A cryptographic authentication mechanism is provided in SIP to address this requirement. An independent security mechanism for SIP message bodies supplies an alternative means of end-to-end mutual authentication, as well as providing a limit on the degree to which user agents must trust intermediaries. 26.2.1 Transport and Network Layer Security Transport or network layer security encrypts signaling traffic, guaranteeing message confidentiality and integrity. Oftentimes, certificates are used in the establishment of lower-layer security, and these certificates can also be used to provide a means of authentication in many architectures. Two popular alternatives for providing security at the transport and network layer are, respectively, TLS [25] and IPSec [26]. IPSec is a set of network-layer protocol tools that collectively can be used as a secure replacement for traditional IP (Internet Protocol). IPSec is most commonly used in architectures in which a set of hosts or administrative domains have an existing trust relationship with one another. IPSec is usually implemented at the operating system level in a host, or on a security gateway that provides confidentiality and integrity for all traffic it receives from a particular interface (as in a VPN architecture). IPSec can also be used on a hop-by-hop basis. In many architectures IPSec does not require integration with SIP applications; IPSec is perhaps best suited to deployments in which adding security directly to SIP hosts would be arduous. UAs that have a pre-shared keying relationship with their first-hop proxy server are also good candidates to use IPSec. Any deployment of IPSec for SIP would require an IPSec profile describing the protocol tools that would be required to secure SIP. No such profile is given in this document. Rosenberg, et. al. Standards Track [Page 238] RFC 3261 SIP: Session Initiation Protocol June 2002 TLS provides transport-layer security over connection-oriented protocols (for the purposes of this document, TCP); ""tls"" (signifying TLS over TCP) can be specified as the desired transport protocol within a Via header field value or a SIP-URI. TLS is most suited to architectures in which hop-by-hop security is required between hosts with no pre-existing trust association. For example, Alice trusts her local proxy server, which after a certificate exchange decides to trust Bob's local proxy server, which Bob trusts, hence Bob and Alice can communicate securely. TLS must be tightly coupled with a SIP application. Note that transport mechanisms are specified on a hop-by-hop basis in SIP, thus a UA that sends requests over TLS to a proxy server has no assurance that TLS will be used end-to-end. The TLS_RSA_WITH_AES_128_CBC_SHA ciphersuite [6] MUST be supported at a minimum by implementers when TLS is used in a SIP application. For purposes of backwards compatibility, proxy servers, redirect servers, and registrars SHOULD support TLS_RSA_WITH_3DES_EDE_CBC_SHA. Implementers MAY also support any other ciphersuite. 26.2.2 SIPS URI Scheme The SIPS URI scheme adheres to the syntax of the SIP URI (described in 19), although the scheme string is ""sips"" rather than ""sip"". The semantics of SIPS are very different from the SIP URI, however. SIPS allows resources to specify that they should be reached securely. A SIPS URI can be used as an address-of-record for a particular user - the URI by which the user is canonically known (on their business cards, in the From header field of their requests, in the To header field of REGISTER requests). When used as the Request-URI of a request, the SIPS scheme signifies that each hop over which the request is forwarded, until the request reaches the SIP entity responsible for the domain portion of the Request-URI, must be secured with TLS; once it reaches the domain in question it is handled in accordance with local security and routing policy, quite possibly using TLS for any last hop to a UAS. When used by the originator of a request (as would be the case if they employed a SIPS URI as the address-of-record of the target), SIPS dictates that the entire request path to the target domain be so secured. The SIPS scheme is applicable to many of the other ways in which SIP URIs are used in SIP today in addition to the Request-URI, including in addresses-of-record, contact addresses (the contents of Contact headers, including those of REGISTER methods), and Route headers. In each instance, the SIPS URI scheme allows these existing fields to Rosenberg, et. al. Standards Track [Page 239] RFC 3261 SIP: Session Initiation Protocol June 2002 designate secure resources. The manner in which a SIPS URI is dereferenced in any of these contexts has its own security properties which are detailed in [4]. The use of SIPS in particular entails that mutual TLS authentication SHOULD be employed, as SHOULD the ciphersuite TLS_RSA_WITH_AES_128_CBC_SHA. Certificates received in the authentication process SHOULD be validated with root certificates held by the client; failure to validate a certificate SHOULD result in the failure of the request. Note that in the SIPS URI scheme, transport is independent of TLS, and thus ""sips:alice@atlanta.com;transport=tcp"" and ""sips:alice@atlanta.com;transport=sctp"" are both valid (although note that UDP is not a valid transport for SIPS). The use of ""transport=tls"" has consequently been deprecated, partly because it was specific to a single hop of the request. This is a change since RFC 2543. Users that distribute a SIPS URI as an address-of-record may elect to operate devices that refuse requests over insecure transports. 26.2.3 HTTP Authentication SIP provides a challenge capability, based on HTTP authentication, that relies on the 401 and 407 response codes as well as header fields for carrying challenges and credentials. Without significant modification, the reuse of the HTTP Digest authentication scheme in SIP allows for replay protection and one-way authentication. The usage of Digest authentication in SIP is detailed in Section 22. 26.2.4 S/MIME As is discussed above, encrypting entire SIP messages end-to-end for the purpose of confidentiality is not appropriate because network intermediaries (like proxy servers) need to view certain header fields in order to route messages correctly, and if these intermediaries are excluded from security associations, then SIP messages will essentially be non-routable. However, S/MIME allows SIP UAs to encrypt MIME bodies within SIP, securing these bodies end-to-end without affecting message headers. S/MIME can provide end-to-end confidentiality and integrity for message bodies, as well as mutual authentication. It is also possible to use S/MIME to provide a form of integrity and confidentiality for SIP header fields through SIP message tunneling. Rosenberg, et. al. Standards Track [Page 240] RFC 3261 SIP: Session Initiation Protocol June 2002 The usage of S/MIME in SIP is detailed in Section 23. 26.3 Implementing Security Mechanisms 26.3.1 Requirements for Implementers of SIP Proxy servers, redirect servers, and registrars MUST implement TLS, and MUST support both mutual and one-way authentication. It is strongly RECOMMENDED that UAs be capable initiating TLS; UAs MAY also be capable of acting as a TLS server. Proxy servers, redirect servers, and registrars SHOULD possess a site certificate whose subject corresponds to their canonical hostname. UAs MAY have certificates of their own for mutual authentication with TLS, but no provisions are set forth in this document for their use. All SIP elements that support TLS MUST have a mechanism for validating certificates received during TLS negotiation; this entails possession of one or more root certificates issued by certificate authorities (preferably well-known distributors of site certificates comparable to those that issue root certificates for web browsers). All SIP elements that support TLS MUST also support the SIPS URI scheme. Proxy servers, redirect servers, registrars, and UAs MAY also implement IPSec or other lower-layer security protocols. When a UA attempts to contact a proxy server, redirect server, or registrar, the UAC SHOULD initiate a TLS connection over which it will send SIP messages. In some architectures, UASs MAY receive requests over such TLS connections as well. Proxy servers, redirect servers, registrars, and UAs MUST implement Digest Authorization, encompassing all of the aspects required in 22. Proxy servers, redirect servers, and registrars SHOULD be configured with at least one Digest realm, and at least one ""realm"" string supported by a given server SHOULD correspond to the server's hostname or domainname. UAs MAY support the signing and encrypting of MIME bodies, and transference of credentials with S/MIME as described in Section 23. If a UA holds one or more root certificates of certificate authorities in order to validate certificates for TLS or IPSec, it SHOULD be capable of reusing these to verify S/MIME certificates, as appropriate. A UA MAY hold root certificates specifically for validating S/MIME certificates. Rosenberg, et. al. Standards Track [Page 241] RFC 3261 SIP: Session Initiation Protocol June 2002 Note that is it anticipated that future security extensions may upgrade the normative strength associated with S/MIME as S/MIME implementations appear and the problem space becomes better understood. 26.3.2 Security Solutions The operation of these security mechanisms in concert can follow the existing web and email security models to some degree. At a high level, UAs authenticate themselves to servers (proxy servers, redirect servers, and registrars) with a Digest username and password; servers authenticate themselves to UAs one hop away, or to another server one hop away (and vice versa), with a site certificate delivered by TLS. On a peer-to-peer level, UAs trust the network to authenticate one another ordinarily; however, S/MIME can also be used to provide direct authentication when the network does not, or if the network itself is not trusted. The following is an illustrative example in which these security mechanisms are used by various UAs and servers to prevent the sorts of threats described in Section 26.1. While implementers and network administrators MAY follow the normative guidelines given in the remainder of this section, these are provided only as example implementations. 26.3.2.1 Registration When a UA comes online and registers with its local administrative domain, it SHOULD establish a TLS connection with its registrar (Section 10 describes how the UA reaches its registrar). The registrar SHOULD offer a certificate to the UA, and the site identified by the certificate MUST correspond with the domain in which the UA intends to register; for example, if the UA intends to register the address-of-record 'alice@atlanta.com', the site certificate must identify a host within the atlanta.com domain (such as sip.atlanta.com). When it receives the TLS Certificate message, the UA SHOULD verify the certificate and inspect the site identified by the certificate. If the certificate is invalid, revoked, or if it does not identify the appropriate party, the UA MUST NOT send the REGISTER message and otherwise proceed with the registration. When a valid certificate has been provided by the registrar, the UA knows that the registrar is not an attacker who might redirect the UA, steal passwords, or attempt any similar attacks. Rosenberg, et. al. Standards Track [Page 242] RFC 3261 SIP: Session Initiation Protocol June 2002 The UA then creates a REGISTER request that SHOULD be addressed to a Request-URI corresponding to the site certificate received from the registrar. When the UA sends the REGISTER request over the existing TLS connection, the registrar SHOULD challenge the request with a 401 (Proxy Authentication Required) response. The ""realm"" parameter within the Proxy-Authenticate header field of the response SHOULD correspond to the domain previously given by the site certificate. When the UAC receives the challenge, it SHOULD either prompt the user for credentials or take an appropriate credential from a keyring corresponding to the ""realm"" parameter in the challenge. The username of this credential SHOULD correspond with the ""userinfo"" portion of the URI in the To header field of the REGISTER request. Once the Digest credentials have been inserted into an appropriate Proxy-Authorization header field, the REGISTER should be resubmitted to the registrar. Since the registrar requires the user agent to authenticate itself, it would be difficult for an attacker to forge REGISTER requests for the user's address-of-record. Also note that since the REGISTER is sent over a confidential TLS connection, attackers will not be able to intercept the REGISTER to record credentials for any possible replay attack. Once the registration has been accepted by the registrar, the UA SHOULD leave this TLS connection open provided that the registrar also acts as the proxy server to which requests are sent for users in this administrative domain. The existing TLS connection will be reused to deliver incoming requests to the UA that has just completed registration."
"Because the UA has already authenticated the server on the other side of the TLS connection, all requests that come over this connection are known to have passed through the proxy server - attackers cannot create spoofed requests that appear to have been sent through that proxy server. 26.3.2.2 Interdomain Requests Now let's say that Alice's UA would like to initiate a session with a user in a remote administrative domain, namely ""bob@biloxi.com"". We will also say that the local administrative domain (atlanta.com) has a local outbound proxy. The proxy server that handles inbound requests for an administrative domain MAY also act as a local outbound proxy; for simplicity's sake we'll assume this to be the case for atlanta.com (otherwise the user agent would initiate a new TLS connection to a separate server at this point). Assuming that the client has completed the registration Rosenberg, et. al. Standards Track [Page 243] RFC 3261 SIP: Session Initiation Protocol June 2002 process described in the preceding section, it SHOULD reuse the TLS connection to the local proxy server when it sends an INVITE request to another user. The UA SHOULD reuse cached credentials in the INVITE to avoid prompting the user unnecessarily. When the local outbound proxy server has validated the credentials presented by the UA in the INVITE, it SHOULD inspect the Request-URI to determine how the message should be routed (see [4]). If the ""domainname"" portion of the Request-URI had corresponded to the local domain (atlanta.com) rather than biloxi.com, then the proxy server would have consulted its location service to determine how best to reach the requested user. Had ""alice@atlanta.com"" been attempting to contact, say, ""alex@atlanta.com"", the local proxy would have proxied to the request to the TLS connection Alex had established with the registrar when he registered. Since Alex would receive this request over his authenticated channel, he would be assured that Alice's request had been authorized by the proxy server of the local administrative domain. However, in this instance the Request-URI designates a remote domain. The local outbound proxy server at atlanta.com SHOULD therefore establish a TLS connection with the remote proxy server at biloxi.com. Since both of the participants in this TLS connection are servers that possess site certificates, mutual TLS authentication SHOULD occur. Each side of the connection SHOULD verify and inspect the certificate of the other, noting the domain name that appears in the certificate for comparison with the header fields of SIP messages. The atlanta.com proxy server, for example, SHOULD verify at this stage that the certificate received from the remote side corresponds with the biloxi.com domain. Once it has done so, and TLS negotiation has completed, resulting in a secure channel between the two proxies, the atlanta.com proxy can forward the INVITE request to biloxi.com. The proxy server at biloxi.com SHOULD inspect the certificate of the proxy server at atlanta.com in turn and compare the domain asserted by the certificate with the ""domainname"" portion of the From header field in the INVITE request. The biloxi proxy MAY have a strict security policy that requires it to reject requests that do not match the administrative domain from which they have been proxied. Such security policies could be instituted to prevent the SIP equivalent of SMTP 'open relays' that are frequently exploited to generate spam. Rosenberg, et. al. Standards Track [Page 244] RFC 3261 SIP: Session Initiation Protocol June 2002 This policy, however, only guarantees that the request came from the domain it ascribes to itself; it does not allow biloxi.com to ascertain how atlanta.com authenticated Alice. Only if biloxi.com has some other way of knowing atlanta.com's authentication policies could it possibly ascertain how Alice proved her identity. biloxi.com might then institute an even stricter policy that forbids requests that come from domains that are not known administratively to share a common authentication policy with biloxi.com. Once the INVITE has been approved by the biloxi proxy, the proxy server SHOULD identify the existing TLS channel, if any, associated with the user targeted by this request (in this case ""bob@biloxi.com""). The INVITE should be proxied through this channel to Bob. Since the request is received over a TLS connection that had previously been authenticated as the biloxi proxy, Bob knows that the From header field was not tampered with and that atlanta.com has validated Alice, although not necessarily whether or not to trust Alice's identity. Before they forward the request, both proxy servers SHOULD add a Record-Route header field to the request so that all future requests in this dialog will pass through the proxy servers. The proxy servers can thereby continue to provide security services for the lifetime of this dialog. If the proxy servers do not add themselves to the Record-Route, future messages will pass directly end-to-end between Alice and Bob without any security services (unless the two parties agree on some independent end-to-end security such as S/MIME). In this respect the SIP trapezoid model can provide a nice structure where conventions of agreement between the site proxies can provide a reasonably secure channel between Alice and Bob. An attacker preying on this architecture would, for example, be unable to forge a BYE request and insert it into the signaling stream between Bob and Alice because the attacker has no way of ascertaining the parameters of the session and also because the integrity mechanism transitively protects the traffic between Alice and Bob. 26.3.2.3 Peer-to-Peer Requests Alternatively, consider a UA asserting the identity ""carol@chicago.com"" that has no local outbound proxy. When Carol wishes to send an INVITE to ""bob@biloxi.com"", her UA SHOULD initiate a TLS connection with the biloxi proxy directly (using the mechanism described in [4] to determine how to best to reach the given Request-URI). When her UA receives a certificate from the biloxi proxy, it SHOULD be verified normally before she passes her INVITE across the TLS connection. However, Carol has no means of proving Rosenberg, et. al. Standards Track [Page 245] RFC 3261 SIP: Session Initiation Protocol June 2002 her identity to the biloxi proxy, but she does have a CMS-detached signature over a ""message/sip"" body in the INVITE. It is unlikely in this instance that Carol would have any credentials in the biloxi.com realm, since she has no formal association with biloxi.com. The biloxi proxy MAY also have a strict policy that precludes it from even bothering to challenge requests that do not have biloxi.com in the ""domainname"" portion of the From header field - it treats these users as unauthenticated. The biloxi proxy has a policy for Bob that all non-authenticated requests should be redirected to the appropriate contact address registered against 'bob@biloxi.com', namely <sip:bob@192.0.2.4>. Carol receives the redirection response over the TLS connection she established with the biloxi proxy, so she trusts the veracity of the contact address. Carol SHOULD then establish a TCP connection with the designated address and send a new INVITE with a Request-URI containing the received contact address (recomputing the signature in the body as the request is readied). Bob receives this INVITE on an insecure interface, but his UA inspects and, in this instance, recognizes the From header field of the request and subsequently matches a locally cached certificate with the one presented in the signature of the body of the INVITE. He replies in similar fashion, authenticating himself to Carol, and a secure dialog begins. Sometimes firewalls or NATs in an administrative domain could preclude the establishment of a direct TCP connection to a UA. In these cases, proxy servers could also potentially relay requests to UAs in a way that has no trust implications (for example, forgoing an existing TLS connection and forwarding the request over cleartext TCP) as local policy dictates. 26.3.2.4 DoS Protection In order to minimize the risk of a denial-of-service attack against architectures using these security solutions, implementers should take note of the following guidelines. When the host on which a SIP proxy server is operating is routable from the public Internet, it SHOULD be deployed in an administrative domain with defensive operational policies (blocking source-routed traffic, preferably filtering ping traffic). Both TLS and IPSec can also make use of bastion hosts at the edges of administrative domains that participate in the security associations to aggregate secure tunnels and sockets. These bastion hosts can also take the brunt of denial-of-service attacks, ensuring that SIP hosts within the administrative domain are not encumbered with superfluous messaging. Rosenberg, et. al. Standards Track [Page 246] RFC 3261 SIP: Session Initiation Protocol June 2002 No matter what security solutions are deployed, floods of messages directed at proxy servers can lock up proxy server resources and prevent desirable traffic from reaching its destination. There is a computational expense associated with processing a SIP transaction at a proxy server, and that expense is greater for stateful proxy servers than it is for stateless proxy servers. Therefore, stateful proxies are more susceptible to flooding than stateless proxy servers. UAs and proxy servers SHOULD challenge questionable requests with only a single 401 (Unauthorized) or 407 (Proxy Authentication Required), forgoing the normal response retransmission algorithm, and thus behaving statelessly towards unauthenticated requests. Retransmitting the 401 (Unauthorized) or 407 (Proxy Authentication Required) status response amplifies the problem of an attacker using a falsified header field value (such as Via) to direct traffic to a third party. In summary, the mutual authentication of proxy servers through mechanisms such as TLS significantly reduces the potential for rogue intermediaries to introduce falsified requests or responses that can deny service. This commensurately makes it harder for attackers to make innocent SIP nodes into agents of amplification. 26.4 Limitations Although these security mechanisms, when applied in a judicious manner, can thwart many threats, there are limitations in the scope of the mechanisms that must be understood by implementers and network operators. 26.4.1 HTTP Digest One of the primary limitations of using HTTP Digest in SIP is that the integrity mechanisms in Digest do not work very well for SIP. Specifically, they offer protection of the Request-URI and the method of a message, but not for any of the header fields that UAs would most likely wish to secure. The existing replay protection mechanisms described in RFC 2617 also have some limitations for SIP. The next-nonce mechanism, for example, does not support pipelined requests. The nonce-count mechanism should be used for replay protection. Another limitation of HTTP Digest is the scope of realms. Digest is valuable when a user wants to authenticate themselves to a resource with which they have a pre-existing association, like a service Rosenberg, et. al. Standards Track [Page 247] RFC 3261 SIP: Session Initiation Protocol June 2002 provider of which the user is a customer (which is quite a common scenario and thus Digest provides an extremely useful function). By way of contrast, the scope of TLS is interdomain or multirealm, since certificates are often globally verifiable, so that the UA can authenticate the server with no pre-existing association. 26.4.2 S/MIME The largest outstanding defect with the S/MIME mechanism is the lack of a prevalent public key infrastructure for end users. If self- signed certificates (or certificates that cannot be verified by one of the participants in a dialog) are used, the SIP-based key exchange mechanism described in Section 23.2 is susceptible to a man-in-the- middle attack with which an attacker can potentially inspect and modify S/MIME bodies. The attacker needs to intercept the first exchange of keys between the two parties in a dialog, remove the existing CMS-detached signatures from the request and response, and insert a different CMS-detached signature containing a certificate supplied by the attacker (but which seems to be a certificate for the proper address-of-record). Each party will think they have exchanged keys with the other, when in fact each has the public key of the attacker. It is important to note that the attacker can only leverage this vulnerability on the first exchange of keys between two parties - on subsequent occasions, the alteration of the key would be noticeable to the UAs. It would also be difficult for the attacker to remain in the path of all future dialogs between the two parties over time (as potentially days, weeks, or years pass). SSH is susceptible to the same man-in-the-middle attack on the first exchange of keys; however, it is widely acknowledged that while SSH is not perfect, it does improve the security of connections. The use of key fingerprints could provide some assistance to SIP, just as it does for SSH. For example, if two parties use SIP to establish a voice communications session, each could read off the fingerprint of the key they received from the other, which could be compared against the original. It would certainly be more difficult for the man-in- the-middle to emulate the voices of the participants than their signaling (a practice that was used with the Clipper chip-based secure telephone). The S/MIME mechanism allows UAs to send encrypted requests without preamble if they possess a certificate for the destination address- of-record on their keyring. However, it is possible that any particular device registered for an address-of-record will not hold the certificate that has been previously employed by the device's current user, and that it will therefore be unable to process an Rosenberg, et. al. Standards Track [Page 248] RFC 3261 SIP: Session Initiation Protocol June 2002 encrypted request properly, which could lead to some avoidable error signaling. This is especially likely when an encrypted request is forked. The keys associated with S/MIME are most useful when associated with a particular user (an address-of-record) rather than a device (a UA). When users move between devices, it may be difficult to transport private keys securely between UAs; how such keys might be acquired by a device is outside the scope of this document. Another, more prosaic difficulty with the S/MIME mechanism is that it can result in very large messages, especially when the SIP tunneling mechanism described in Section 23.4 is used. For that reason, it is RECOMMENDED that TCP should be used as a transport protocol when S/MIME tunneling is employed. 26.4.3 TLS The most commonly voiced concern about TLS is that it cannot run over UDP; TLS requires a connection-oriented underlying transport protocol, which for the purposes of this document means TCP. It may also be arduous for a local outbound proxy server and/or registrar to maintain many simultaneous long-lived TLS connections with numerous UAs. This introduces some valid scalability concerns, especially for intensive ciphersuites. Maintaining redundancy of long-lived TLS connections, especially when a UA is solely responsible for their establishment, could also be cumbersome. TLS only allows SIP entities to authenticate servers to which they are adjacent; TLS offers strictly hop-by-hop security. Neither TLS, nor any other mechanism specified in this document, allows clients to authenticate proxy servers to whom they cannot form a direct TCP connection. 26.4.4 SIPS URIs Actually using TLS on every segment of a request path entails that the terminating UAS must be reachable over TLS (perhaps registering with a SIPS URI as a contact address). This is the preferred use of SIPS. Many valid architectures, however, use TLS to secure part of the request path, but rely on some other mechanism for the final hop to a UAS, for example. Thus SIPS cannot guarantee that TLS usage will be truly end-to-end. Note that since many UAs will not accept incoming TLS connections, even those UAs that do support TLS may be required to maintain persistent TLS connections as described in the TLS limitations section above in order to receive requests over TLS as a UAS. Rosenberg, et. al. Standards Track [Page 249] RFC 3261 SIP: Session Initiation Protocol June 2002 Location services are not required to provide a SIPS binding for a SIPS Request-URI. Although location services are commonly populated by user registrations (as described in Section 10.2.1), various other protocols and interfaces could conceivably supply contact addresses for an AOR, and these tools are free to map SIPS URIs to SIP URIs as appropriate. When queried for bindings, a location service returns its contact addresses without regard for whether it received a request with a SIPS Request-URI. If a redirect server is accessing the location service, it is up to the entity that processes the Contact header field of a redirection to determine the propriety of the contact addresses. Ensuring that TLS will be used for all of the request segments up to the target domain is somewhat complex. It is possible that cryptographically authenticated proxy servers along the way that are non-compliant or compromised may choose to disregard the forwarding rules associated with SIPS (and the general forwarding rules in Section 16.6). Such malicious intermediaries could, for example, retarget a request from a SIPS URI to a SIP URI in an attempt to downgrade security. Alternatively, an intermediary might legitimately retarget a request from a SIP to a SIPS URI. Recipients of a request whose Request-URI uses the SIPS URI scheme thus cannot assume on the basis of the Request-URI alone that SIPS was used for the entire request path (from the client onwards). To address these concerns, it is RECOMMENDED that recipients of a request whose Request-URI contains a SIP or SIPS URI inspect the To header field value to see if it contains a SIPS URI (though note that it does not constitute a breach of security if this URI has the same scheme but is not equivalent to the URI in the To header field). Although clients may choose to populate the Request-URI and To header field of a request differently, when SIPS is used this disparity could be interpreted as a possible security violation, and the request could consequently be rejected by its recipient. Recipients MAY also inspect the Via header chain in order to double-check whether or not TLS was used for the entire request path until the local administrative domain was reached. S/MIME may also be used by the originating UAC to help ensure that the original form of the To header field is carried end-to-end. If the UAS has reason to believe that the scheme of the Request-URI has been improperly modified in transit, the UA SHOULD notify its user of a potential security breach. Rosenberg, et. al. Standards Track [Page 250] RFC 3261 SIP: Session Initiation Protocol June 2002 As a further measure to prevent downgrade attacks, entities that accept only SIPS requests MAY also refuse connections on insecure ports. End users will undoubtedly discern the difference between SIPS and SIP URIs, and they may manually edit them in response to stimuli. This can either benefit or degrade security. For example, if an attacker corrupts a DNS cache, inserting a fake record set that effectively removes all SIPS records for a proxy server, then any SIPS requests that traverse this proxy server may fail. When a user, however, sees that repeated calls to a SIPS AOR are failing, they could on some devices manually convert the scheme from SIPS to SIP and retry. Of course, there are some safeguards against this (if the destination UA is truly paranoid it could refuse all non-SIPS requests), but it is a limitation worth noting. On the bright side, users might also divine that 'SIPS' would be valid even when they are presented only with a SIP URI. 26.5 Privacy SIP messages frequently contain sensitive information about their senders - not just what they have to say, but with whom they communicate, when they communicate and for how long, and from where they participate in sessions. Many applications and their users require that this sort of private information be hidden from any parties that do not need to know it. Note that there are also less direct ways in which private information can be divulged. If a user or service chooses to be reachable at an address that is guessable from the person's name and organizational affiliation (which describes most addresses-of- record), the traditional method of ensuring privacy by having an unlisted ""phone number"" is compromised. A user location service can infringe on the privacy of the recipient of a session invitation by divulging their specific whereabouts to the caller; an implementation consequently SHOULD be able to restrict, on a per-user basis, what kind of location and availability information is given out to certain classes of callers. This is a whole class of problem that is expected to be studied further in ongoing SIP work. In some cases, users may want to conceal personal information in header fields that convey identity. This can apply not only to the From and related headers representing the originator of the request, but also the To - it may not be appropriate to convey to the final destination a speed-dialing nickname, or an unexpanded identifier for a group of targets, either of which would be removed from the Request-URI as the request is routed, but not changed in the To Rosenberg, et. al. Standards Track [Page 251] RFC 3261 SIP: Session Initiation Protocol June 2002 header field if the two were initially identical. Thus it MAY be desirable for privacy reasons to create a To header field that differs from the Request-URI. 27 IANA Considerations All method names, header field names, status codes, and option tags used in SIP applications are registered with IANA through instructions in an IANA Considerations section in an RFC. The specification instructs the IANA to create four new sub- registries under http://www.iana.org/assignments/sip-parameters: Option Tags, Warning Codes (warn-codes), Methods and Response Codes, added to the sub-registry of Header Fields that is already present there. 27.1 Option Tags This specification establishes the Option Tags sub-registry under http://www.iana.org/assignments/sip-parameters. Option tags are used in header fields such as Require, Supported, Proxy-Require, and Unsupported in support of SIP compatibility mechanisms for extensions (Section 19.2). The option tag itself is a string that is associated with a particular SIP option (that is, an extension). It identifies the option to SIP endpoints. Option tags are registered by the IANA when they are published in standards track RFCs. The IANA Considerations section of the RFC must include the following information, which appears in the IANA registry along with the RFC number of the publication. o Name of the option tag. The name MAY be of any length, but SHOULD be no more than twenty characters long. The name MUST consist of alphanum (Section 25) characters only. o Descriptive text that describes the extension. 27.2 Warn-Codes This specification establishes the Warn-codes sub-registry under http://www.iana.org/assignments/sip-parameters and initiates its population with the warn-codes listed in Section 20.43. Additional warn-codes are registered by RFC publication. Rosenberg, et. al. Standards Track [Page 252] RFC 3261 SIP: Session Initiation Protocol June 2002 The descriptive text for the table of warn-codes is: Warning codes provide information supplemental to the status code in SIP response messages when the failure of the transaction results from a Session Description Protocol (SDP) (RFC 2327 [1]) problem. The ""warn-code"" consists of three digits. A first digit of ""3"" indicates warnings specific to SIP. Until a future specification describes uses of warn-codes other than 3xx, only 3xx warn-codes may be registered. Warnings 300 through 329 are reserved for indicating problems with keywords in the session description, 330 through 339 are warnings related to basic network services requested in the session description, 370 through 379 are warnings related to quantitative QoS parameters requested in the session description, and 390 through 399 are miscellaneous warnings that do not fall into one of the above categories. 27.3 Header Field Names This obsoletes the IANA instructions about the header sub-registry under http://www.iana.org/assignments/sip-parameters. The following information needs to be provided in an RFC publication in order to register a new header field name: o The RFC number in which the header is registered; o the name of the header field being registered; o a compact form version for that header field, if one is defined; Some common and widely used header fields MAY be assigned one-letter compact forms (Section 7.3.3). Compact forms can only be assigned after SIP working group review, followed by RFC publication. 27.4 Method and Response Codes This specification establishes the Method and Response-Code sub- registries under http://www.iana.org/assignments/sip-parameters and initiates their population as follows. The initial Methods table is: Rosenberg, et. al. Standards Track [Page 253] RFC 3261 SIP: Session Initiation Protocol June 2002 INVITE [RFC3261] ACK [RFC3261] BYE [RFC3261] CANCEL [RFC3261] REGISTER [RFC3261] OPTIONS [RFC3261] INFO [RFC2976] The response code table is initially populated from Section 21, the portions labeled Informational, Success, Redirection, Client-Error, Server-Error, and Global-Failure. The table has the following format: Type (e.g., Informational) Number Default Reason Phrase [RFC3261] The following information needs to be provided in an RFC publication in order to register a new response code or method: o The RFC number in which the method or response code is registered; o the number of the response code or name of the method being registered; o the default reason phrase for that response code, if applicable; 27.5 The ""message/sip"" MIME type. This document registers the ""message/sip"" MIME media type in order to allow SIP messages to be tunneled as bodies within SIP, primarily for end-to-end security purposes. This media type is defined by the following information: Media type name: message Media subtype name: sip Required parameters: none Optional parameters: version version: The SIP-Version number of the enclosed message (e.g., ""2.0""). If not present, the version defaults to ""2.0"". Encoding scheme: SIP messages consist of an 8-bit header optionally followed by a binary MIME data object. As such, SIP messages must be treated as binary. Under normal circumstances SIP messages are transported over binary-capable transports, no special encodings are needed. Rosenberg, et. al. Standards Track [Page 254] RFC 3261 SIP: Session Initiation Protocol June 2002 Security considerations: see below Motivation and examples of this usage as a security mechanism in concert with S/MIME are given in 23.4. 27.6 New Content-Disposition Parameter Registrations This document also registers four new Content-Disposition header ""disposition-types"": alert, icon, session and render. The authors request that these values be recorded in the IANA registry for Content-Dispositions. Descriptions of these ""disposition-types"", including motivation and examples, are given in Section 20.11. Short descriptions suitable for the IANA registry are: alert the body is a custom ring tone to alert the user icon the body is displayed as an icon to the user render the body should be displayed to the user session the body describes a communications session, for example, as RFC 2327 SDP body 28 Changes From RFC 2543 This RFC revises RFC 2543. It is mostly backwards compatible with RFC 2543. The changes described here fix many errors discovered in RFC 2543 and provide information on scenarios not detailed in RFC 2543. The protocol has been presented in a more cleanly layered model here. We break the differences into functional behavior that is a substantial change from RFC 2543, which has impact on interoperability or correct operation in some cases, and functional behavior that is different from RFC 2543 but not a potential source of interoperability problems. There have been countless clarifications as well, which are not documented here. 28.1 Major Functional Changes o When a UAC wishes to terminate a call before it has been answered, it sends CANCEL. If the original INVITE still returns a 2xx, the UAC then sends BYE. BYE can only be sent on an existing call leg (now called a dialog in this RFC), whereas it could be sent at any time in RFC 2543. o The SIP BNF was converted to be RFC 2234 compliant. Rosenberg, et. al. Standards Track [Page 255] RFC 3261 SIP: Session Initiation Protocol June 2002 o SIP URL BNF was made more general, allowing a greater set of characters in the user part. Furthermore, comparison rules were simplified to be primarily case-insensitive, and detailed handling of comparison in the presence of parameters was described. The most substantial change is that a URI with a parameter with the default value does not match a URI without that parameter. o Removed Via hiding. It had serious trust issues, since it relied on the next hop to perform the obfuscation process. Instead, Via hiding can be done as a local implementation choice in stateful proxies, and thus is no longer documented. o In RFC 2543, CANCEL and INVITE transactions were intermingled. They are separated now. When a user sends an INVITE and then a CANCEL, the INVITE transaction still terminates normally. A UAS needs to respond to the original INVITE request with a 487 response. o Similarly, CANCEL and BYE transactions were intermingled; RFC 2543 allowed the UAS not to send a response to INVITE when a BYE was received. That is disallowed here. The original INVITE needs a response. o In RFC 2543, UAs needed to support only UDP. In this RFC, UAs need to support both UDP and TCP. o In RFC 2543, a forking proxy only passed up one challenge from downstream elements in the event of multiple challenges. In this RFC, proxies are supposed to collect all challenges and place them into the forwarded response. o In Digest credentials, the URI needs to be quoted; this is unclear from RFC 2617 and RFC 2069 which are both inconsistent on it. o SDP processing has been split off into a separate specification [13], and more fully specified as a formal offer/answer exchange process that is effectively tunneled through SIP. SDP is allowed in INVITE/200 or 200/ACK for baseline SIP implementations; RFC 2543 alluded to the ability to use it in INVITE, 200, and ACK in a single transaction, but this was not well specified. More complex SDP usages are allowed in extensions. Rosenberg, et. al. Standards Track [Page 256] RFC 3261 SIP: Session Initiation Protocol June 2002 o Added full support for IPv6 in URIs and in the Via header field. Support for IPv6 in Via has required that its header field parameters allow the square bracket and colon characters. These characters were previously not permitted. In theory, this could cause interop problems with older implementations. However, we have observed that most implementations accept any non-control ASCII character in these parameters. o DNS SRV procedure is now documented in a separate specification [4]. This procedure uses both SRV and NAPTR resource records and no longer combines data from across SRV records as described in RFC 2543. o Loop detection has been made optional, supplanted by a mandatory usage of Max-Forwards. The loop detection procedure in RFC 2543 had a serious bug which would report ""spirals"" as an error condition when it was not. The optional loop detection procedure is more fully and correctly specified here. o Usage of tags is now mandatory (they were optional in RFC 2543), as they are now the fundamental building blocks of dialog identification. o Added the Supported header field, allowing for clients to indicate what extensions are supported to a server, which can apply those extensions to the response, and indicate their usage with a Require in the response. o Extension parameters were missing from the BNF for several header fields, and they have been added. o Handling of Route and Record-Route construction was very underspecified in RFC 2543, and also not the right approach. It has been substantially reworked in this specification (and made vastly simpler), and this is arguably the largest change. Backwards compatibility is still provided for deployments that do not use ""pre-loaded routes"", where the initial request has a set of Route header field values obtained in some way outside of Record-Route. In those situations, the new mechanism is not interoperable. o In RFC 2543, lines in a message could be terminated with CR, LF, or CRLF. This specification only allows CRLF. Rosenberg, et. al. Standards Track [Page 257] RFC 3261 SIP: Session Initiation Protocol June 2002 o Usage of Route in CANCEL and ACK was not well defined in RFC 2543. It is now well specified; if a request had a Route header field, its CANCEL or ACK for a non-2xx response to the request need to carry the same Route header field values. ACKs for 2xx responses use the Route values learned from the Record-Route of the 2xx responses. o RFC 2543 allowed multiple requests in a single UDP packet. This usage has been removed. o Usage of absolute time in the Expires header field and parameter has been removed. It caused interoperability problems in elements that were not time synchronized, a common occurrence. Relative times are used instead. o The branch parameter of the Via header field value is now mandatory for all elements to use. It now plays the role of a unique transaction identifier. This avoids the complex and bug- laden transaction identification rules from RFC 2543. A magic cookie is used in the parameter value to determine if the previous hop has made the parameter globally unique, and comparison falls back to the old rules when it is not present. Thus, interoperability is assured. o In RFC 2543, closure of a TCP connection was made equivalent to a CANCEL. This was nearly impossible to implement (and wrong) for TCP connections between proxies. This has been eliminated, so that there is no coupling between TCP connection state and SIP processing. o RFC 2543 was silent on whether a UA could initiate a new transaction to a peer while another was in progress. That is now specified here. It is allowed for non-INVITE requests, disallowed for INVITE. o PGP was removed. It was not sufficiently specified, and not compatible with the more complete PGP MIME. It was replaced with S/MIME. o Added the ""sips"" URI scheme for end-to-end TLS. This scheme is not backwards compatible with RFC 2543. Existing elements that receive a request with a SIPS URI scheme in the Request-URI will likely reject the request. This is actually a feature; it ensures that a call to a SIPS URI is only delivered if all path hops can be secured. Rosenberg, et. al. Standards Track [Page 258] RFC 3261 SIP: Session Initiation Protocol June 2002 o Additional security features were added with TLS, and these are described in a much larger and complete security considerations section. o In RFC 2543, a proxy was not required to forward provisional responses from 101 to 199 upstream. This was changed to MUST. This is important, since many subsequent features depend on delivery of all provisional responses from 101 to 199. o Little was said about the 503 response code in RFC 2543. It has since found substantial use in indicating failure or overload conditions in proxies. This requires somewhat special treatment. Specifically, receipt of a 503 should trigger an attempt to contact the next element in the result of a DNS SRV lookup. Also, 503 response is only forwarded upstream by a proxy under certain conditions. o RFC 2543 defined, but did no sufficiently specify, a mechanism for UA authentication of a server. That has been removed. Instead, the mutual authentication procedures of RFC 2617 are allowed. o A UA cannot send a BYE for a call until it has received an ACK for the initial INVITE. This was allowed in RFC 2543 but leads to a potential race condition. o A UA or proxy cannot send CANCEL for a transaction until it gets a provisional response for the request. This was allowed in RFC 2543 but leads to potential race conditions. o The action parameter in registrations has been deprecated. It was insufficient for any useful services, and caused conflicts when application processing was applied in proxies. o RFC 2543 had a number of special cases for multicast. For example, certain responses were suppressed, timers were adjusted, and so on. Multicast now plays a more limited role, and the protocol operation is unaffected by usage of multicast as opposed to unicast. The limitations as a result of that are documented. o Basic authentication has been removed entirely and its usage forbidden. Rosenberg, et. al. Standards Track [Page 259] RFC 3261 SIP: Session Initiation Protocol June 2002 o Proxies no longer forward a 6xx immediately on receiving it. Instead, they CANCEL pending branches immediately. This avoids a potential race condition that would result in a UAC getting a 6xx followed by a 2xx. In all cases except this race condition, the result will be the same - the 6xx is forwarded upstream. o RFC 2543 did not address the problem of request merging. This occurs when a request forks at a proxy and later rejoins at an element. Handling of merging is done only at a UA, and procedures are defined for rejecting all but the first request. 28.2 Minor Functional Changes o Added the Alert-Info, Error-Info, and Call-Info header fields for optional content presentation to users. o Added the Content-Language, Content-Disposition and MIME-Version header fields. o Added a ""glare handling"" mechanism to deal with the case where both parties send each other a re-INVITE simultaneously. It uses the new 491 (Request Pending) error code."
"o Added the In-Reply-To and Reply-To header fields for supporting the return of missed calls or messages at a later time. o Added TLS and SCTP as valid SIP transports. o There were a variety of mechanisms described for handling failures at any time during a call; those are now generally unified. BYE is sent to terminate. o RFC 2543 mandated retransmission of INVITE responses over TCP, but noted it was really only needed for 2xx. That was an artifact of insufficient protocol layering. With a more coherent transaction layer defined here, that is no longer needed. Only 2xx responses to INVITEs are retransmitted over TCP. o Client and server transaction machines are now driven based on timeouts rather than retransmit counts. This allows the state machines to be properly specified for TCP and UDP. o The Date header field is used in REGISTER responses to provide a simple means for auto-configuration of dates in user agents. o Allowed a registrar to reject registrations with expirations that are too short in duration. Defined the 423 response code and the Min-Expires for this purpose. Rosenberg, et. al. Standards Track [Page 260] RFC 3261 SIP: Session Initiation Protocol June 2002 29 Normative References [1] Handley, M. and V. Jacobson, ""SDP: Session Description Protocol"", RFC 2327, April 1998. [2] Bradner, S., ""Key words for use in RFCs to Indicate Requirement Levels"", BCP 14, RFC 2119, March 1997. [3] Resnick, P., ""Internet Message Format"", RFC 2822, April 2001. [4] Rosenberg, J. and H. Schulzrinne, ""SIP: Locating SIP Servers"", RFC 3263, June 2002. [5] Berners-Lee, T., Fielding, R. and L. Masinter, ""Uniform Resource Identifiers (URI): Generic Syntax"", RFC 2396, August 1998. [6] Chown, P., ""Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS)"", RFC 3268, June 2002. [7] Yergeau, F., ""UTF-8, a transformation format of ISO 10646"", RFC 2279, January 1998. [8] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P. and T. Berners-Lee, ""Hypertext Transfer Protocol -- HTTP/1.1"", RFC 2616, June 1999. [9] Vaha-Sipila, A., ""URLs for Telephone Calls"", RFC 2806, April 2000. [10] Crocker, D. and P. Overell, ""Augmented BNF for Syntax Specifications: ABNF"", RFC 2234, November 1997. [11] Freed, F. and N. Borenstein, ""Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types"", RFC 2046, November 1996. [12] Eastlake, D., Crocker, S. and J. Schiller, ""Randomness Recommendations for Security"", RFC 1750, December 1994. [13] Rosenberg, J. and H. Schulzrinne, ""An Offer/Answer Model with SDP"", RFC 3264, June 2002. [14] Postel, J., ""User Datagram Protocol"", STD 6, RFC 768, August 1980. [15] Postel, J., ""DoD Standard Transmission Control Protocol"", RFC 761, January 1980. Rosenberg, et. al. Standards Track [Page 261] RFC 3261 SIP: Session Initiation Protocol June 2002 [16] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L. and V. Paxson, ""Stream Control Transmission Protocol"", RFC 2960, October 2000. [17] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A. and L. Stewart, ""HTTP authentication: Basic and Digest Access Authentication"", RFC 2617, June 1999. [18] Troost, R., Dorner, S. and K. Moore, ""Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field"", RFC 2183, August 1997. [19] Zimmerer, E., Peterson, J., Vemuri, A., Ong, L., Audet, F., Watson, M. and M. Zonoun, ""MIME media types for ISUP and QSIG Objects"", RFC 3204, December 2001. [20] Braden, R., ""Requirements for Internet Hosts - Application and Support"", STD 3, RFC 1123, October 1989. [21] Alvestrand, H., ""IETF Policy on Character Sets and Languages"", BCP 18, RFC 2277, January 1998. [22] Galvin, J., Murphy, S., Crocker, S. and N. Freed, ""Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted"", RFC 1847, October 1995. [23] Housley, R., ""Cryptographic Message Syntax"", RFC 2630, June 1999. [24] Ramsdell B., ""S/MIME Version 3 Message Specification"", RFC 2633, June 1999. [25] Dierks, T. and C. Allen, ""The TLS Protocol Version 1.0"", RFC 2246, January 1999. [26] Kent, S. and R. Atkinson, ""Security Architecture for the Internet Protocol"", RFC 2401, November 1998. 30 Informative References [27] R. Pandya, ""Emerging mobile and personal communication systems,"" IEEE Communications Magazine, Vol. 33, pp. 44--52, June 1995. [28] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, ""RTP: A Transport Protocol for Real-Time Applications"", RFC 1889, January 1996. Rosenberg, et. al. Standards Track [Page 262] RFC 3261 SIP: Session Initiation Protocol June 2002 [29] Schulzrinne, H., Rao, R. and R. Lanphier, ""Real Time Streaming Protocol (RTSP)"", RFC 2326, April 1998. [30] Cuervo, F., Greene, N., Rayhan, A., Huitema, C., Rosen, B. and J. Segers, ""Megaco Protocol Version 1.0"", RFC 3015, November 2000. [31] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, ""SIP: Session Initiation Protocol"", RFC 2543, March 1999. [32] Hoffman, P., Masinter, L. and J. Zawinski, ""The mailto URL scheme"", RFC 2368, July 1998. [33] E. M. Schooler, ""A multicast user directory service for synchronous rendezvous,"" Master's Thesis CS-TR-96-18, Department of Computer Science, California Institute of Technology, Pasadena, California, Aug. 1996. [34] Donovan, S., ""The SIP INFO Method"", RFC 2976, October 2000. [35] Rivest, R., ""The MD5 Message-Digest Algorithm"", RFC 1321, April 1992. [36] Dawson, F. and T. Howes, ""vCard MIME Directory Profile"", RFC 2426, September 1998. [37] Good, G., ""The LDAP Data Interchange Format (LDIF) - Technical Specification"", RFC 2849, June 2000. [38] Palme, J., ""Common Internet Message Headers"", RFC 2076, February 1997. [39] Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen, A., Sink, E. and L. Stewart, ""An Extension to HTTP: Digest Access Authentication"", RFC 2069, January 1997. [40] Johnston, A., Donovan, S., Sparks, R., Cunningham, C., Willis, D., Rosenberg, J., Summers, K. and H. Schulzrinne, ""SIP Call Flow Examples"", Work in Progress. [41] E. M. Schooler, ""Case study: multimedia conference control in a packet-switched teleconferencing system,"" Journal of Internetworking: Research and Experience, Vol. 4, pp. 99--120, June 1993. ISI reprint series ISI/RS-93-359. Rosenberg, et. al. Standards Track [Page 263] RFC 3261 SIP: Session Initiation Protocol June 2002 [42] H. Schulzrinne, ""Personal mobility for multimedia services in the Internet,"" in European Workshop on Interactive Distributed Multimedia Systems and Services (IDMS), (Berlin, Germany), Mar. 1996. [43] Floyd, S., ""Congestion Control Principles"", RFC 2914, September 2000. Rosenberg, et. al. Standards Track [Page 264] RFC 3261 SIP: Session Initiation Protocol June 2002 A Table of Timer Values Table 4 summarizes the meaning and defaults of the various timers used by this specification. Timer Value Section Meaning ---------------------------------------------------------------------- T1 500ms default Section 17.1.1.1 RTT Estimate T2 4s Section 17.1.2.2 The maximum retransmit interval for non-INVITE requests and INVITE responses T4 5s Section 17.1.2.2 Maximum duration a message will remain in the network Timer A initially T1 Section 17.1.1.2 INVITE request retransmit interval, for UDP only Timer B 64*T1 Section 17.1.1.2 INVITE transaction timeout timer Timer C > 3min Section 16.6 proxy INVITE transaction bullet 11 timeout Timer D > 32s for UDP Section 17.1.1.2 Wait time for response 0s for TCP/SCTP retransmits Timer E initially T1 Section 17.1.2.2 non-INVITE request retransmit interval, UDP only Timer F 64*T1 Section 17.1.2.2 non-INVITE transaction timeout timer Timer G initially T1 Section 17.2.1 INVITE response retransmit interval Timer H 64*T1 Section 17.2.1 Wait time for ACK receipt Timer I T4 for UDP Section 17.2.1 Wait time for 0s for TCP/SCTP ACK retransmits Timer J 64*T1 for UDP Section 17.2.2 Wait time for 0s for TCP/SCTP non-INVITE request retransmits Timer K T4 for UDP Section 17.1.2.2 Wait time for 0s for TCP/SCTP response retransmits Table 4: Summary of timers Rosenberg, et. al. Standards Track [Page 265] RFC 3261 SIP: Session Initiation Protocol June 2002 Acknowledgments We wish to thank the members of the IETF MMUSIC and SIP WGs for their comments and suggestions. Detailed comments were provided by Ofir Arkin, Brian Bidulock, Jim Buller, Neil Deason, Dave Devanathan, Keith Drage, Bill Fenner, Cedric Fluckiger, Yaron Goland, John Hearty, Bernie Hoeneisen, Jo Hornsby, Phil Hoffer, Christian Huitema, Hisham Khartabil, Jean Jervis, Gadi Karmi, Peter Kjellerstedt, Anders Kristensen, Jonathan Lennox, Gethin Liddell, Allison Mankin, William Marshall, Rohan Mahy, Keith Moore, Vern Paxson, Bob Penfield, Moshe J. Sambol, Chip Sharp, Igor Slepchin, Eric Tremblay, and Rick Workman. Brian Rosen provided the compiled BNF. Jean Mahoney provided technical writing assistance. This work is based, inter alia, on [41,42]. Rosenberg, et. al. Standards Track [Page 266] RFC 3261 SIP: Session Initiation Protocol June 2002 Authors' Addresses Authors addresses are listed alphabetically for the editors, the writers, and then the original authors of RFC 2543. All listed authors actively contributed large amounts of text to this document. Jonathan Rosenberg dynamicsoft 72 Eagle Rock Ave East Hanover, NJ 07936 USA EMail: jdrosen@dynamicsoft.com Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue New York, NY 10027 USA EMail: schulzrinne@cs.columbia.edu Gonzalo Camarillo Ericsson Advanced Signalling Research Lab. FIN-02420 Jorvas Finland EMail: Gonzalo.Camarillo@ericsson.com Alan Johnston WorldCom 100 South 4th Street St. Louis, MO 63102 USA EMail: alan.johnston@wcom.com Rosenberg, et. al. Standards Track [Page 267] RFC 3261 SIP: Session Initiation Protocol June 2002 Jon Peterson NeuStar, Inc 1800 Sutter Street, Suite 570 Concord, CA 94520 USA EMail: jon.peterson@neustar.com Robert Sparks dynamicsoft, Inc. 5100 Tennyson Parkway Suite 1200 Plano, Texas 75024 USA EMail: rsparks@dynamicsoft.com Mark Handley International Computer Science Institute 1947 Center St, Suite 600 Berkeley, CA 94704 USA EMail: mjh@icir.org Eve Schooler AT&T Labs-Research 75 Willow Road Menlo Park, CA 94025 USA EMail: schooler@research.att.com Rosenberg, et. al. Standards Track [Page 268] RFC 3261 SIP: Session Initiation Protocol June 2002 Full Copyright Statement Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an ""AS IS"" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. Rosenberg, et. al. Standards Track [Page 269] 3GPP TS 29.329 V17.0.0 (2022-04) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Sh Interface based on the Diameter protocol; Protocol details (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 5 1 Scope 6 2 References 6 3 Definitions, symbols and abbreviations 7 3.1 Definitions 7 3.2 Abbreviations 7 4 General 7 5 Use of the Diameter base protocol 8 6 Diameter application for Sh interface 8 6.1 Command-Code values 8 6.1.1 User-Data-Request (UDR) Command 8 6.1.2 User-Data-Answer (UDA) Command 9 6.1.3 Profile-Update-Request (PUR) Command 10 6.1.4 Profile-Update-Answer (PUA) Command 10 6.1.5 Subscribe-Notifications-Request (SNR) Command 11 6.1.6 Subscribe-Notifications-Answer (SNA) Command 11 6.1.7 Push-Notification-Request (PNR) Command 12 6.1.8 Push-Notifications-Answer (PNA) Command 12 6.2 Result-Code AVP values 13 6.2.1 Success 13 6.2.2 Permanent Failures 13 6.2.2.1 DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED (5100) 13 6.2.2.2 DIAMETER_ERROR_OPERATION_NOT_ALLOWED (5101) 13 6.2.2.3 DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ (5102) 13 6.2.2.4 DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED (5103) 13 6.2.2.5 DIAMETER_ERROR_USER_DATA_CANNOT_BE_NOTIFIED (5104) 13 6.2.2.6 DIAMETER_ERROR_TOO_MUCH_DATA (5008) 13 6.2.2.7 DIAMETER_ERROR_TRANSPARENT_DATA OUT_OF_SYNC (5105) 13 6.2.2.8 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) 13 6.2.2.9 DIAMETER_ERROR_SUBS_DATA_ABSENT (5106) 13 6.2.2.10 DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA (5107) 14 6.2.2.11 DIAMETER_ERROR_DSAI_NOT_AVAILABLE (5108) 14 6.2.2.12 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) 14 6.2.3 Transient Failures 14 6.2.3.1 DIAMETER_USER_DATA_NOT_AVAILABLE (4100) 14 6.2.3.2 DIAMETER_PRIOR_UPDATE_IN_PROGRESS (4101) 14 6.3 AVPs 15 6.3.1 User-Identity AVP 16 6.3.2 MSISDN AVP 16 6.3.3 User-Data AVP 16 6.3.4 Data-Reference AVP 16 6.3.5 Service-Indication AVP 17 6.3.6 Subs-Req-Type AVP 17 6.3.7 Requested-Domain AVP 18 6.3.7A Requested-Nodes AVP 18 6.3.8 Current-Location AVP 18 6.3.9 Server-Name AVP 18 6.3.10 Identity-Set AVP 18 6.3.11 Supported-Features AVP 18 6.3.12 Feature-List-ID AVP 19 6.3.13 Feature-List AVP 19 6.3.14 Supported-Applications AVP 19 6.3.15 Public-Identity AVP 19 6.3.16 Expiry-Time AVP 19 6.3.17 Send-Data-Indication AVP 19 6.3.18 DSAI-Tag AVP 19 6.3.19 Wildcarded-Public-Identity AVP 19 6.3.20 Wildcarded-IMPU AVP 19 6.3.21 Session-Priority AVP 19 6.3.22 One-Time-Notification AVP 19 6.3.23 Serving-Node-Indication AVP 20 6.3.24 Repository-Data-ID AVP 20 6.3.25 Sequence-Number AVP 20 6.3.26 Pre-paging-Supported AVP 20 6.3.27 Local-Time-Zone-Indication AVP 20 6.3.28 UDR-Flags 20 6.3.29 Call-Reference-Info AVP 21 6.3.30 Call-Reference-Number AVP 21 6.3.31 AS-Number AVP 21 6.3.32 OC-Supported-Features 21 6.3.33 OC-OLR 21 6.3.34 DRMP AVP 21 6.3.35 Load 21 6.4 Use of namespaces 21 6.4.1 AVP codes 21 6.4.2 Experimental-Result-Code AVP values 22 6.4.3 Command Code values 22 6.4.4 Application-ID value 22 7 Special Requirements 23 7.1 Version Control 23 Annex A (informative): Change history 24 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope The present document defines a transport protocol for use in the IP multimedia (IM) Core Network (CN) subsystem based on the Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15]. The present document is applicable to: - The Sh interface between an AS and the HSS. - The Sh interface between an SCS and the HSS. Whenever it is possible this document specifies the requirements for this protocol by reference to specifications produced by the IETF within the scope of Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15]. Where this is not possible, extensions to the Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15] are defined within this document. 2 References The following documents contain provisions, which through reference in this text constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TSÊ29.328 ""IP Multimedia (IM) Subsystem Sh interface; signalling flows and message contents"". [2] 3GPP TSÊ33.210 ""3G Security; Network Domain Security; IP Network Layer Security"". [3] IETF RFC 2960 ""Stream Control Transmission Protocol"". [4] Void. [5] IETF RFC 2234 ""Augmented BNF for syntax specifications"". [6] 3GPP TSÊ29.229 ""Cx and Dx Interfaces based on the Diameter protocol; protocol details"". [7] IETF RFC 3589 ""Diameter Command Codes for Third Generation Partnership Project (3GPP) Release 5"". [8] ITU-TÊRecommendationÊE.164: ""The international public telecommunication numbering plan"". [9] 3GPP TRÊ33.978 ""Security aspects of early IP Multimedia Subsystem (IMS) (Release 6)"". [10] 3GPP TSÊ29.364 ""IMS Application Server Service Data Descriptions for AS interoperability"". [11] 3GPP TSÊ29.002 ""Mobile Application Part (MAP) specification"". [12] IETF RFC 7683: ""Diameter Overload Indication Conveyance"". [13] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [14] IETFÊRFCÊ8583: ""Diameter Load Information Conveyance"". Ê[15] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [16]] 3GPP TSÊ29.336: ""Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications"". 3 Definitions, symbols and abbreviations 3.1 Definitions Refer to IETFÊRFCÊ6733Ê[15] for the definitions of some terms used in this document. For the purposes of the present document, the following terms and definitions apply. Attribute-Value Pair: see IETFÊRFCÊ6733Ê[15], it corresponds to an Information Element in a Diameter message. Server: SIP-server. User data: user profile data. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AAA Authentication, Authorization and Accounting AS Application Server ABNF Augmented Backus-Naur Form AVP Attribute-Value Pair CN Core Network DRMP Diameter Routing Message Priority DSCP Differentiated Services Code Point HSS Home Subscriber Server IANA Internet Assigned Numbers Authority IETF Internet Engineering Task Force IMS IP Multimedia Subsystem NDS Network Domain Security RFC Request For Comment SCTP Stream Control Transport Protocol UCS Universal Character Set URL Uniform Resource Locator UTF UCS Transformation Formats 4 General he Diameter base protocol as specified in IETFÊRFCÊ6733Ê[15] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and event codes specified in clauseÊ6 of this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) are unmodified. 5 Use of the Diameter base protocol The same clarifications of clauseÊ5 of 3GPP TSÊ29.229Ê[6] shall apply to the Sh interface. An exception is that the application identifier for this application is defined in chapter 6. 6 Diameter application for Sh interface This clause specifies a Diameter application that allows a Diameter server and a Diameter client: - to download and update transparent and non-transparent user data - to request and send notifications on changes on user data The Sh interface protocol is defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP ( http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the Sh interface application is 16777217 (allocated by IANA). 6.1 Command-Code values This clause defines Command-Code values for this Diameter application. Every command is defined by means of the ABNF syntax (as defined in RFC 2234Ê[5]), according to the Command Code Format (CCF) specification defined in IETFÊRFCÊ6733Ê[15]. Whenever the definition and use of an AVP is not specified in this document, what is stated in 3GPP TSÊ29.229Ê[6] shall apply. NOTE: As the Diameter commands described in this specification have been defined based on the former specification of the Diameter base protocol, the Vendor-Specific-Application-Id AVP is still listed as a required AVP (an AVP indicated as {AVP}) in the command code format specifications defined in this specification to avoid backward compatibility issues, even if the use of this AVP has been deprecated in the new specification of the Diameter base protocol (IETFÊRFCÊ6733Ê[15]). The command codes for the Sh interface application are taken from the range allocated by IANA in IETF RFC 3589Ê[7] as assigned in this specification. For these commands, the Application-ID field shall be set to 16777217 (application identifier of the Sh interface application, allocated by IANA). The following Command Codes are defined in this specification: Table 6.1.1: Command-Code values Command-Name Abbreviation Code Clause User-Data-Request UDR 306 6.1.1 User-Data-Answer UDA 306 6.1.2 Profile-Update-Request PUR 307 6.1.3 Profile-Update-Answer PUA 307 6.1.4 Subscribe-Notifications-Request SNR 308 6.1.5 Subscribe-Notifications-Answer SNA 308 6.1.6 Push-Notification-Request PNR 309 6.1.7 Push-Notification-Answer PNA 309 6.1.8 6.1.1 User-Data-Request (UDR) Command The User-Data-Request (UDR) command, indicated by the Command-Code field set to 306 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to request user data. Message Format < User-Data -Request> ::= < Diameter Header: 306, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ Server-Name ] *[ Service-Indication ] *{ Data-Reference } *[ Identity-Set ] [ Requested-Domain ] [ Current-Location ] *[ DSAI-Tag ] [ Session-Priority ] [ User-Name ] [ Requested-Nodes ] [ Serving-Node-Indication ] [ Pre-paging-Supported ] [ Local-Time-Zone-Indication ] [ UDR-Flags ] [ Call-Reference-Info ] [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.2 User-Data-Answer (UDA) Command The User-Data-Answer (UDA) command, indicated by the Command-Code field set to 306 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the User-Data-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < User-Data-Answer > ::= < Diameter Header: 306, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Data ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.3 Profile-Update-Request (PUR) Command The Profile-Update-Request (PUR) command, indicated by the Command-Code field set to 307 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to update user data in the server. Message Format < Profile-Update-Request > ::= < Diameter Header: 307, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Name ] *{ Data-Reference } { User-Data } [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] NOTE: More than one Data-Reference AVP may be present in the message only if both the AS and the HSS support the Update-Eff-Enhance feature. How the AS knows whether the HSS supports the Update-Eff-Enhance feature is implementation issue, e.g. the AS can get the information from a previous PUA message. 6.1.4 Profile-Update-Answer (PUA) Command The Profile-Update-Answer (PUA) command, indicated by the Command-Code field set to 307 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Profile-Update-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Profile-Update-Answer > ::=< Diameter Header: 307, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ Repository-Data-ID ] [ Data-Reference ] *[ Supported-Features ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] NOTE: The Data-Reference AVP may be present in the message only if both the AS and the HSS support the Update-Eff-Enhance feature. 6.1.5 Subscribe-Notifications-Request (SNR) Command The Subscribe-Notifications-Request (SNR) command, indicated by the Command-Code field set to 308 and the 'R' bit set in the Command Flags field, is sent by a Diameter client to a Diameter server in order to request notifications of changes in user data. Message Format < Subscribe-Notifications-Request > ::= < Diameter Header: 308, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] *[ Service-Indication ] [ Send-Data-Indication ] [ Server-Name ] { Subs-Req-Type } *{ Data-Reference } *[ Identity-Set ] [ Expiry-Time ] *[ DSAI-Tag ] [One-Time-Notification] [ User-Name ] [ OC-Supported-Features ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.6 Subscribe-Notifications-Answer (SNA) Command The Subscribe-Notifications-Answer command, indicated by the Command-Code field set to 308 and the 'R' bit cleared in the Command Flags field, is sent by a server in response to the Subscribe-Notifications-Request command. The Result-Code or Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Subscribe-Notifications-Answer > ::= < Diameter Header: 308, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } [ Result-Code ] [ Experimental-Result ] { Origin-Host } { Origin-Realm } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] *[ Supported-Features ] [ User-Data ] [ Expiry-Time ] [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.7 Push-Notification-Request (PNR) Command The Push-Notification-Request (PNR) command, indicated by the Command-Code field set to 309 and the 'R' bit set in the Command Flags field, is sent by a Diameter server to a Diameter client in order to notify changes in the user data in the server. Message Format < Push-Notification-Request > ::= < Diameter Header: 309, REQ, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } *[ Supported-Features ] { User-Identity } [ Wildcarded-Public-Identity ] [ Wildcarded-IMPU ] [ User-Name ] { User-Data } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.1.8 Push-Notifications-Answer (PNA) Command The Push-Notifications-Answer (PNA) command, indicated by the Command-Code field set to 309 and the 'R' bit cleared in the Command Flags field, is sent by a client in response to the Push-Notification-Request command. The Experimental-Result AVP may contain one of the values defined in clauseÊ6.2 or in 3GPP TSÊ29.229Ê[6]. Message Format < Push-Notification-Answer > ::=< Diameter Header: 309, PXY, 16777217 > < Session-Id > [ DRMP ] { Vendor-Specific-Application-Id } [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 6.2 Result-Code AVP values This clause defines new result code values that must be supported by all Diameter implementations that conform to this specification. The result codes defined in 3GPP TSÊ29.229Ê[6] are also applicable. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and Result-Code AVP shall be absent. 6.2.1 Success Result codes that fall within the Success category are used to inform a peer that a request has been successfully completed. No result codes within this category have been defined so far. 6.2.2 Permanent Failures Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not be attempted again. 6.2.2.1 DIAMETER_ERROR_USER_DATA_NOT_RECOGNIZED (5100) The data received by the AS is not supported or recognized. 6.2.2.2 DIAMETER_ERROR_OPERATION_NOT_ALLOWED (5101) The requested operation is not allowed for the user 6.2.2.3 DIAMETER_ERROR_USER_DATA_CANNOT_BE_READ (5102) The requested user data is not allowed to be read. 6.2.2.4 DIAMETER_ERROR_USER_DATA_CANNOT_BE_MODIFIED (5103) The requested user data is not allowed to be modified. 6.2.2.5 DIAMETER_ERROR_USER_DATA_CANNOT_BE_NOTIFIED (5104) The requested user data is not allowed to be notified on changes. 6.2.2.6 DIAMETER_ERROR_TOO_MUCH_DATA (5008) The size of the data pushed to the receiving entity exceeds its capacity. This error code is defined in 3GPP TSÊ29.229Ê[6]. 6.2.2.7 DIAMETER_ERROR_TRANSPARENT_DATA OUT_OF_SYNC (5105) The request to update the repository data at the HSS could not be completed because the requested update is based on an out-of-date version of the repository data. That is, the sequence number in the Sh-Update Request message, does not match with the immediate successor of the associated sequence number stored for that repository data at the HSS. It is also used where an AS tries to create a new set of repository data when the identified repository data already exists in the HSS. 6.2.2.8 DIAMETER_ERROR_FEATURE_UNSUPPORTED (5011) See 3GPP TSÊ29.229Ê[6] clauseÊ6.2.2.11. 6.2.2.9 DIAMETER_ERROR_SUBS_DATA_ABSENT (5106) The Application Server requested to subscribe to changes to Repository Data that is not present in the HSS. 6.2.2.10 DIAMETER_ERROR_NO_SUBSCRIPTION_TO_DATA (5107) The AS received a notification of changes of some information to which it is not subscribed. 6.2.2.11 DIAMETER_ERROR_DSAI_NOT_AVAILABLE (5108) The Application Server addressed a DSAI not configured in the HSS. 6.2.2.12 DIAMETER_ERROR_IDENTITIES_DONT_MATCH (5002) See 3GPP TSÊ29.229Ê[6] 6.2.3 Transient Failures Errors that fall within the transient failures category are those used to inform a peer that the request could not be satisfied at the time that it was received. The request may be able to be satisfied in the future. 6.2.3.1 DIAMETER_USER_DATA_NOT_AVAILABLE (4100) The requested user data is not available at this time to satisfy the requested operation. 6.2.3.2 DIAMETER_PRIOR_UPDATE_IN_PROGRESS (4101) The request to update data at the HSS could not be completed for one of the following reasons: - If the Data Reference is Repository Data, then the related Repository Data is currently being updated by another entity; - If the Data Reference is other than Repository Data, then the related data is currently being updated. 6.3 AVPs The following table describes the Diameter AVPs defined for the Sh interface protocol, their AVP Code values, types, possible flag values and whether the AVP may or not be encrypted. Table 6.3.1: Diameter Multimedia Application AVPs AVP Flag rules Attribute Name AVP Code Clause defined Value Type Must May Should not Must not May Encrypt User-Identity 700 6.3.1 Grouped M, V No MSISDN 701 6.3.2 OctetString M, V No User-Data 702 6.3.3 OctetString M, V No Data-Reference 703 6.3.4 Enumerated M, V No Service-Indication 704 6.3.5 OctetString M, V No Subs-Req-Type 705 6.3.6 Enumerated M, V No Requested-Domain 706 6.3.7 Enumerated M, V No Current-Location 707 6.3.8 Enumerated M, V No Identity-Set 708 6.3.10 Enumerated V M No Expiry-Time 709 6.3.16 Time V M No Send-Data-Indication 710 6.3.17 Enumerated V M No Server-Name 602 6.3.9 UTF8String M, V No Supported-Features 628 6.3.11 Grouped V M No Feature-List-ID 629 6.3.12 Unsigned32 V M No Feature-List 630 6.3.13 Unsigned32 V M No Supported-Applications 631 6.3.14 Grouped V M No Public-Identity 601 6.3.15 UTF8String M, V No DSAI-Tag 711 6.3.18 OctetString M, V No Wildcarded-Public-Identity 634 6.3.19 UTF8String V M No Wildcarded-IMPU 636 6.3.20 UTF8String V M No Session-Priority 650 6.3.21 Enumerated V M No One-Time-Notification 712 6.3.22 Enumerated V M No Requested-Nodes 713 6.3.7A Unsigned32 V M No Serving-Node-Indication 714 6.3.23 Enumerated V M No Repository-Data-ID 715 6.3.24 Grouped V M No Sequence-Number 716 6.3.25 Unsigned32 V M No Pre-paging-Supported 717 6.3.26 Enumerated V M No Local-Time-Zone-Indication 718 6.3.27 Enumerated V M No UDR-Flags 719 6.3.28 Unsigned32 V M No Call-Reference-Info 720 6.3.29 Grouped V M No Call-Reference-Number 721 6.3.30 OctetString V M No AS-Number 722 6.3.31 OctetString V M No OC-Supported-Features 621 NOTE 3 6.3.32 Grouped M, V No OC-OLR 623 NOTE 3 6.3.33 Grouped M, V No DRMP 301 NOTE 4 6.3.34 Enumerated M, V No Load NOTE 5 6.3.35 Grouped M, V No NOTE 1: The AVP header bit denoted as 'M', indicates whether support of the AVP is required. The AVP header bit denoted as 'V', indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see 3GPP TSÊ29.229Ê[6]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. NOTE 3: The value of these attributes is defined in IETFÊRFCÊ7683Ê[12]. NOTE 4: The value of this attribute is defined in IETFÊRFCÊ7944Ê[13]. NOTE 5: The value of this attribute is defined in IETFÊRFCÊ8583Ê[14]. The following table specifies the Diameter AVPs re-used by the Sh interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within Sh. Table 6.3/2: Sh re-used Diameter AVPs Attribute Name Reference Comments M-bit External-Identifier 3GPP TSÊ29.336Ê[16] Must set NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: ""Must set"", ""Must not set"". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. 6.3.1 User-Identity AVP The User-Identity AVP is of type Grouped. This AVP contains either a Public- Identity AVP or an MSISDN AVP or an External-Identifier AVP. AVP format User-Identity ::= <AVP header: 700 10415> [Public-Identity] [MSISDN] [External-Identifier] *[AVP] 6.3.2 MSISDN AVP The MSISDN AVP is of type OctetString. This AVP contains an MSISDN, in international number format as described in ITU-T Rec E.164Ê[8], encoded as a TBCD-string, i.e. digits from 0 through 9 are encoded 0000 to 1001; 1111 is used as a filler when there is an odd number of digits; bits 8 to 5 of octet n encode digit 2n; bits 4 to 1 of octet n encode digit 2(n-1)+1. 6.3.3 User-Data AVP The User-Data AVP is of type OctetString. This AVP contains the user data requested in the UDR/UDA, SNR/SNA and PNR/PNA operations and the data to be modified in the PUR/PUA operation. The exact content and format of this AVP is described in 3GPP TSÊ29.328Ê[1] Annex C as Sh-Data. 6.3.4 Data-Reference AVP The Data-Reference AVP is of type Enumerated, and indicates the type of the requested user data in the operation UDR and SNR. Its exact values and meaning is defined in 3GPP TSÊ29.328Ê[1]."
"The following values are defined (more details are given in 3GPP TSÊ29.328Ê[1]): RepositoryData (0) IMSPublicIdentity (10) IMSUserState (11) S-CSCFName (12) InitialFilterCriteria (13) This value is used to request initial filter criteria relevant to the requesting AS LocationInformation (14) UserState (15) ChargingInformation (16) MSISDN (17) PSIActivation (18) DSAI (19) ServiceLevelTraceInfo (21) IPAddressSecureBindingInformation (22) ServicePriorityLevel (23) SMSRegistrationInfo (24) UEReachabilityForIP (25) TADSinformation (26) STN-SR (27) UE-SRVCC-Capability (28) ExtendedPriority (29) CSRN (30) ReferenceLocationInformation (31) IMSI (32) IMSPrivateUserIdentity (33) IMEISV (34) UE-5G-SRVCC-Capability (35) NOTE: Value 20 is reserved. 6.3.5 Service-Indication AVP The Service-Indication AVP is of type OctetString. This AVP contains the Service Indication that identifies a service or a set of services in an AS and the related repository data in the HSS. Standardized values of Service-Indication identifying a standardized service or set of services in the AS and standardized format of the related repository data are defined in 3GPP TSÊ29.364Ê[10]. 6.3.6 Subs-Req-Type AVP The Subs-Req-Type AVP is of type Enumerated, and indicates the type of the subscription-to-notifications request. The following values are defined: Subscribe (0) This value is used by an AS to subscribe to notifications of changes in data. Unsubscribe (1) This value is used by an AS to unsubscribe to notifications of changes in data. 6.3.7 Requested-Domain AVP The Requested-Domain AVP is of type Enumerated, and indicates the access domain for which certain data (e.g. user state) are requested. The following values are defined: CS-Domain (0) The requested data apply to the CS domain. PS-Domain (1) The requested data apply to the PS domain. 6.3.7A Requested-Nodes AVP The Requested-Nodes AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 6.3.7A/1: Table 6.3.7A/1: Requested-Nodes Bit Name Description 0 MME The requested data apply to the MME 1 SGSN The requested data apply to the SGSN 2 3GPP-AAA-SERVER-TWAN The requested data apply to the 3GPP AAA Server for TWAN 3 AMF The requested data apply to the AMF (for 3GPP access) 6.3.8 Current-Location AVP The Current-Location AVP is of type Enumerated, and indicates whether an active location retrieval has to be initiated or not: DoNotNeedInitiateActiveLocationRetrieval (0) The request indicates that the initiation of an active location retrieval is not required. InitiateActiveLocationRetrieval (1) It is requested that an active location retrieval is initiated. 6.3.9 Server-Name AVP The Server-Name contains a SIP-URL used to identify an AS. See 3GPP TSÊ29.229Ê[6] for further description of this AVP. 6.3.10 Identity-Set AVP The Identity-Set AVP is of type Enumerated and indicates the requested set of IMS Public Identities. The following values are defined: ALL_IDENTITIES (0) REGISTERED_IDENTITIES (1) IMPLICIT_IDENTITIES (2) ALIAS_IDENTITIES (3) 6.3.11 Supported-Features AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.29. 6.3.12 Feature-List-ID AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.30. 6.3.13 Feature-List AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.31. 6.3.14 Supported-Applications AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.32. 6.3.15 Public-Identity AVP The Public-Identity AVP contains a Public User Identity. See 3GPP TSÊ29.229Ê[6] for the definition of this AVP. 6.3.16 Expiry-Time AVP The Expiry-Time AVP is of type Time. This AVP contains the expiry time of subscriptions to notifications in the HSS. 6.3.17 Send-Data-Indication AVP The Send-Data-Indication AVP is of type Enumerated. If present it indicates that the sender requests the User-Data. The following values are defined: USER_DATA_NOT_REQUESTED (0) USER_DATA_REQUESTED (1) 6.3.18 DSAI-Tag AVP The DSAI-Tag AVP is of type OctetString. This AVP contains the DSAI-Tag identifying the instance of the Dynamic Service Activation Information being accessed for the Public Identity. 6.3.19 Wildcarded-Public-Identity AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.35 for the definition of theWildcarded-Public-Identity AVP. This AVP only contains a Wildcarded PSI over Sh interface. 6.3.20 Wildcarded-IMPU AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.43. 6.3.21 Session-Priority AVP See 3GPP TSÊ29.229Ê[6] clauseÊ6.3.56. 6.3.22 One-Time-Notification AVP The One-Time-Notification AVP is of type Enumerated. If present it indicates that the sender requests to be notified only one time. The following values are defined: ONE_TIME_NOTIFICATION_REQUESTED (0) This AVP is only applicable to UE reachability for IP (25) 6.3.23 Serving-Node-Indication AVP The Serving-Node-Indication AVP is of type Enumerated. If present it indicates that the sender does not require any location information other than the Serving Node Addresses/Identities requested (e.g. MME name, VLR number). Other location information (e.g. Global Cell ID, Tracking Area ID) may be absent. The following values are defined: ONLY_SERVING_NODES_REQUIRED (0) 6.3.24 Repository-Data-ID AVP The Repository-Data-ID AVP is of type Grouped. This AVP shall contain a Service-Indication AVP and a Sequence-Number AVP. AVP format Repository-Data-ID ::= <AVP header: 715 10415> {Service-Indication} {Sequence-Number} *[AVP] 6.3.25 Sequence-Number AVP The Sequence-Number AVP is of type Unsigned32. This AVP contains a number associated to a repository data. 6.3.26 Pre-paging-Supported AVP The Pre-paging-Supported AVP is of type Enumerated. It indicates whether the sender supports pre-paging or not. The following values are defined: PREPAGING_NOT_SUPPORTED (0) PREPAGING_SUPPORTED (1) If this AVP is not present in the command, the default value is PREPAGING_NOT_SUPPORTED (0). 6.3.27 Local-Time-Zone-Indication AVP The Local-Time-Zone-Indication AVP is of type Enumerated. If present it indicates that the Local Time Zone information (time zone and daylight saving time) of the visited network where the UE is attached is requested with or without other location information. The following values are defined: ONLY_LOCAL_TIME_ZONE_REQUESTED (0) LOCAL_TIME_ZONE_WITH_LOCATION_INFO_REQUESTED (1) 6.3.28 UDR-Flags The UDR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in 3GPPÊTSÊ29.328Ê[1]. Table 6.3.28/1: UDR-Flags Bit Name 0 Location-Information-EPS-Supported 1 RAT-Type-Requested NOTE: Bits not defined in this table shall be cleared by the sender of the request and discarded by the receiver of the request. 6.3.29 Call-Reference-Info AVP The Call-Reference-Info AVP is of type Grouped. This AVP shall contain a Call-Reference-Number AVP and an AS-Number AVP. AVP format Call-Reference-Info ::= <AVP header: 720 10415> {Call-Reference-Number} {AS-Number} *[AVP] 6.3.30 Call-Reference-Number AVP The Call-Reference-Number AVP is of type OctetString. The exact content and format of this AVP is described in 3GPP TSÊ29.002Ê[11]. 6.3.31 AS-Number AVP The AS-Number AVP is of type OctetString. The exact content and format of this AVP corresponds to the gmsc-address parameter described in 3GPP TSÊ29.002Ê[11]. 6.3.32 OC-Supported-Features The OC-Supported-Features AVP is of type Grouped and it is defined in IETF RFC 7683Ê[12]. This AVP is used to support Diameter overload control mechanism. 6.3.33 OC-OLR The OC-OLR AVP is of type Grouped and it is defined in IETF RFC 7683Ê[12]. This AVP is used to support Diameter overload control mechanism. 6.3.34 DRMP AVP The DRMP AVP is of type Enumerated and it is defined in IETFÊRFCÊ7944Ê[13]. This AVP allows the HSS/SLF and the AS/OSA SCS to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message. 6.3.35 Load The Load AVP is of type Grouped and it is defined in IETFÊRFCÊ8583Ê[14]. This AVP is used to support the Diameter load control mechanism. 6.4 Use of namespaces This clause contains the namespaces that have either been created in this specification, or the values assigned to existing namespaces managed by IANA. 6.4.1 AVP codes This specification assigns the AVP values from the AVP Code namespace managed by 3GPP for its Diameter vendor-specific applications. See clauseÊ6.3 for the assignment of the namespace in this specification. 6.4.2 Experimental-Result-Code AVP values This specification has assigned Experimental-Result-Code AVP values 4100-4101 and 5100-5105. See clauseÊ6.2. 6.4.3 Command Code values This specification assigns the values 306-309 from the range allocated by IANA to 3GPP in IETF RFC 3589Ê[7]. 6.4.4 Application-ID value IANA has allocated the value 16777217 for the 3GPP Sh interface application. 7 Special Requirements 7.1 Version Control The version control mechanisms specified in 3GPP TSÊ29.229Ê[6] clauses 7.1, 7.2 and 7.3 apply to this specification. The following table of features shall apply to the Sh interface. Table 7.1.1: Features of feature list 1 used in Sh Feature bit Feature M/O Description 0 Notif-Eff M This feature is applicable to the UDR/UDA, SNR/SNA and PNR/PNA command pairs. It requires support in both the HSS and the AS. If multiple subscriptions to notifications are associated with a Public User Identity, the HSS may combine the notifications for multiple Data References and/or Service Indications and/or Identity Sets into a single Push-Notification-Request message. The User-Data-Request / Answer and the Subscribe-Notifications-Request / Answer allow multiple Data References, Service Indications and Identity Sets. The User-Data-Answer and Push-Notification-Request allow combining multiple DataReference items resulting in the User Data AVP including a single XML document with the separable XML clauses populated. 1 Update-Eff O This feature is applicable to the PUR/PUA commands. If both the HSS and the AS support this feature, a PUR command where the Data reference type is Repository Data, may contain an XML document with several Repository Data instances. 2 Update-Eff-Enhance O This feature is an enhancement of the Update-Eff feature and requires Update-Eff is supported. It is applicable to the PUR/PUA commands. If both the HSS and the AS support this feature, a PUR command may contain an XML document with several Data instances. 3 Additional-MSISDN O This feature is applicable to UDR/UDA commands. It requires support in both HSS and AS. If enabled, it extends the information returned with DataReference=17. Instead of returning only MSISDN, it includes ExtendedMSISDN. See 3GPP TSÊ29.328Ê[1] for more information. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""MOM"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. The following table shall apply to the Sh interface; the column Application identifier lists the used application identifiers on Sh and 3GPP. Table 7.1.2: Application identifiers used in Sh Application identifier First applied 16777217 3GPP Rel-5 Annex A (informative): Change history Change history Date Meeting TDoc CR Rev Cat Subject/Comment New version June 2002 CN#16 NP-020266 Version 2.0.1 present in CN#16 for approval 5.0.0 Sep 2002 CN#17 NP-020450 2 1 Cancellation of subscriptions to notifications 5.1.0 Sep 2002 CN#17 NP-020450 3 1 Addition of AVPs to User-Data-Request 5.1.0 Dec 2002 CN#18 NP-020592 6 - Error handling in HSS when being updated with too much data 5.2.0 Mar 2003 CN#19 NP-030102 005 1 Initial Filter Criteria 5.3.0 Mar 2003 CN#19 NP-030102 007 2 Update after Diameter has become RFC 5.3.0 Mar 2003 CN#19 NP-030102 011 - Missing code-point in Data-Reference AVP 5.3.0 Mar 2003 CN#19 NP-030102 013 - Registration State Alignment 5.3.0 Mar 2003 CN#19 NP-030102 008 - Correction of the Application Server Identification type for Initial Filter Criteria usage 5.3.0 Mar 2003 CN#19 NP-030102 009 - Clarification on Sh interface for charging purposes 5.3.0 Jun 2003 CN#20 NP-030216 014 1 Co-ordination of Update of Repository Data 5.4.0 Jun 2003 CN#20 NP-030216 015 1 Command code correction for UDA plus editorial corrections 5.4.0 Jun 2003 CN#20 NP-030216 016 - Correction on Current-Location AVP values 5.4.0 Jun 2003 CN#20 NP-030216 018 - Correction to the use of User-Identity 5.4.0 Jun 2003 CN#20 NP-030216 019 1 Correction to the use of Data-Reference 5.4.0 Dec 2003 CN#22 Editorial changes in application IDs and references [4] and [7]. 5.4.1 Mar 2004 CN#23 NP-040135 031 1 Add MSISDN to set of Data that may be downloaded 5.5.0 Mar 2004 CN#23 NP-040055 032 2 Introduction of 'Identity-Set' AVP 6.0.0 Jun 2004 CN#24 NP-040216 037 - Correction to description of Data Reference AVP value 10 6.1.0 Jun 2004 CN#24 NP-040216 035 1 Correction of reference for definition of MSISDN 6.1.0 Sep 2004 CN#25 NP-040394 043 - Incorrect Data-Reference AVP in Subscriber Notification Answer Command 6.2.0 Sep 2004 CN#25 NP-040395 046 1 Application version control 6.2.0 Sep 2004 CN#25 NP-040394 041 1 Public-Identity is unspecified for the Sh interface 6.2.0 Sep 2004 CN#25 NP-040395 045 1 Single Public_Identity required in Grouped User-Identity AVP 6.2.0 Sep 2004 CN#25 NP-040394 049 - Correction of the Application-Id code 6.2.0 Sep 2004 CN#25 NP-040412 051 1 Re-numbering of 3GPP specific AVP codes 6.2.0 Dec 2004 CN#26 NP-040578 053 - Sh ABNF corrections 6.3.0 Mar 2005 CN#27 NP-050031 057 1 Introduction of Failed AVP 6.4.0 Mar 2005 CN#27 NP-050031 064 - Sh-Update needs to include Data-Reference to be future proof 6.4.0 Jun 2005 CT#28 CP-050216 069 - Sh UDR correction 6.5.0 Jun 2005 CT#28 CP-050087 070 - Correction of references 6.5.0 Jun 2005 CT#28 CP-050087 071 1 Corrections to message parameters 6.5.0 Jun 2005 CT#28 CP-050087 072 1 Miscellaneous Corrections 6.5.0 Jun 2005 CT#28 CP-050216 074 - Correction to allow realm based routing 6.5.0 Sep 2005 CT#29 CP-050424 075 - Identity-Set correction 6.6.0 Sep 2005 CT#29 CP-050422 095 1 State the condition for encryption of the Data Reference 6.6.0 Sep 2005 CT#29 CP-050423 097 1 Early IMS Security based protection for the Ut interface 6.6.0 Dec 2005 CT#30 CP-050625 098 3 Notification & Query Efficiency 7.0.0 Dec 2005 CT#30 CP-050625 099 1 Management of subscriptions 7.0.0 Mar 2006 CT#31 CP-060084 0100 1 User-Data in the response to Sh-Subs-Notif 7.1.0 Mar 2006 CT#31 CP-060084 0101 3 New error indications for the Sh-Subs-Notif procedure 7.1.0 Jun 2006 CT#32 CP-060319 0105 2 Sh interface efficiency improvement 7.2.0 Sep 2006 CT#33 CP-060417 0107 2 Introduction of Activation State Information for IMS (DSAI) 7.3.0 Sep 2006 CT#33 CP-060417 0108 - Addition of AVPs in SNR and SNA 7.3.0 Sep 2006 CT#33 CP-060417 0110 1 Public User Identity Grouping Information 7.3.0 Sep 2006 CT#33 CP-060405 0112 - Missing Data Reference value 7.3.0 Sep 2006 CT#33 CP-060417 0113 1 Errors to be sent in response to Sh-Notif 7.3.0 Sep 2007 CT#37 CP-070527 0118 - Define User-Data AVP 7.4.0 Sep 2007 CT#37 CP-070527 0119 1 Wildcarded PSI as key in the Sh Interface 7.4.0 Nov 2007 CT#38 CP-070743 0120 - ABNF correction for UDR and SNR 7.5.0 Nov 2007 CT#38 CP-070743 0121 1 PNR for Subscriptions to Notifications for all Identity Sets 7.5.0 Mar 2008 CT#39 CP-080019 0122 - Wildcarded Public User Identities 8.0.0 Jun 2008 CT#40 CP-080267 0123 1 DSAI Corrections 8.1.0 Jun 2008 CT#40 CP-080702 0130 1 Service Indication for standardized services 8.2.0 Jun 2008 CT#40 CP-080883 0132 1 Correction of Identity-Set AVP 8.2.0 Mar 2009 CT#43 CP-090042 0134 1 AliasesRepositoryData removal 8.3.0 Jun 2009 CT#44 CP-090305 0136 Missing data-reference for GIBA 8.4.0 Dec 2009 CT#46 CP-090778 0138 Session-Priority AVP 8.5.0 Dec 2009 CT#46 Upgraded unchanged from Rel-8 9.0.0 Mar 2010 CT#47 CP-100033 0143 1 IP-SM-GW UE reachability handling over Sh 9.1.0 Mar 2010 CT#47 CP-100048 0144 1 Sh handling of T-ADS 9.1.0 Mar 2010 CT#47 CP-100206 0148 3 EPS Subcsriber State and Location Information Request 9.1.0 Jun 2010 CT#48 CP-100275 0149 EPS state and location retrieval 9.2.0 Jun 2010 CT#48 CP-100279 0154 1 9.2.0 Sep 2010 CT#49 CP-100447 0157 1 Correction to the Value of Data-Reference AVP 9.3.0 Sep 2010 CT#49 CP-100454 0160 1 Correction on Requested-Domain 9.3.0 Sep 2010 CT#49 CP-100466 0158 2 Usage of IMSI and IMPI for user identification over Sh 10.0.0 Sep 2010 CT#49 CP-100466 0159 3 Location data including only serving node address 10.0.0 Sep 2010 CT#49 CP-100466 0163 3 Update-Eff feature 10.0.0 Dec 2010 CT#50 CP-100699 0164 2 Enhanced SRVCC 10.1.0 Mar 2011 CT#51 CP-110257 0168 2 MPS over Sh 10.2.0 Mar 2011 CT#51 CP-110075 0170 2 Retrieval of CSRN from HSS 10.2.0 Jun 2011 CT#52 CP-110370 0175 1 Pre-paging Support Indicator for CSRN 10.3.0 Jun 2011 CT#52 CP-110370 0176 1 Clarification on Notif-Eff description for SNR/SNA 10.3.0 Jun 2011 CT#52 CP-110370 0177 - Missing Repository-Data-ID AVP in PUA 10.3.0 Jun 2011 CT#52 CP-110383 0173 2 Reference Location over Sh interface 11.0.0 Dec 2011 CT#54 CP-110781 0189 - Correction on Wildcarded Public Identity 11.1.0 Mar 2012 CT#55 CP-120035 0194 2 Update of Multiple Data Instances in Sh-Update 11.2.0 Jun 2012 CT#56 CP-120240 0195 3 Local Time for NPLI 11.3.0 Sep 2012 CT#57 CP-120481 0197 A-MSISDN handling over Sh 11.4.0 Sep 2012 CT#57 CP-120481 0198 1 Local Time Zone 11.4.0 Dec 2012 CT#58 CP-120743 0202 1 EPS LocationInformation Support 11.5.0 Mar 2013 CT#59 CP-130020 0208 1 PS Location Info request with RAT-type 11.6.0 Mar 2013 CT#59 CP-130020 0210 1 Pre-paging-Supported and Local-Time-Zone-Indication AVPs 11.6.0 Mar 2013 CT#59 CP-130031 0200 1 Sh IMSI retrieval 12.0.0 Jun 2013 CT#60 CP-130374 0211 1 MTRR on Sh 12.1.0 Mar 2014 CT#63 CP-140027 0214 1 Multiple notification due to the Update-Eff feature 12.2.0 Jun 2014 CT#64 CP-140262 0217 - Private User Identity retrieval 12.3.0 Jun 2014 CT#64 CP-140262 0218 - UE Reachability for IP 12.3.0 Sep 2014 CT#65 CP-140515 0219 - Session-Priority reference 12.4.0 Sep 2014 CT#65 CP-140509 0220 1 Diameter Overload Control Over Sh 12.4.0 Dec 2014 CT#66 CP-140773 0222 - M-bit clarification 12.5.0 Dec 2014 CT#66 CP-140779 0223 - Retrieval of TWAN-Id over Sh 12.5.0 Dec 2014 CT#66 CP-140790 0224 - DOIC reference update 12.5.0 Dec 2015 CT#70 CP-150759 0226 1 Update reference to DOIC new IETF RFC 12.6.0 Dec 2015 CT#70 CP-150849 0227 4 Support of the DRMP AVP over Sh/Dh 13.0.0 2016-09 CT#73 CP-160431 0228 1 Request to update data while a previous update request is in progress 14.0.0 2016-12 CT#74 CP-160649 0236 1 RAT type included in EPS location information 14.1.0 2016-12 CT#74 CP-160681 0237 1 Load Control 14.1.0 2016-12 CT#74 CP-160664 0239 1 Correction to change IETF drmp draft version to official RFC 7944 14.1.0 2017-03 CT#75 CP-170035 0241 - Notif-Eff feature description correction 14.2.0 2017-03 CT#75 CP-170035 0245 1 UDR flag description 14.2.0 2017-03 CT#75 CP-170048 0243 1 Update of reference for the Diameter base protocol 14.2.0 2017-03 CT#75 CP-170048 0244 - Cardinality of the Failed-AVP AVP in answer 14.2.0 2017-06 CT#76 CP-171018 0248 1 Support for signaling transport level packet marking 14.3.0 2017-06 CT#76 CP-171040 0246 1 External Identifier on Sh 15.0.0 2018-06 CT#80 CP-181131 0249 - Requested Node AMF 15.1.0 2019-09 CT#85 CP-192094 0251 2 draft-ietf-dime-load published as RFC 8583 15.2.0 2020-07 CT#88e - - - Update to Rel-16 version (MCC) 16.0.0 2020-12 CT#91e CP-203022 0253 1 Incomplete implemented CR 16.1.0 2021-03 CT#91e CP-210044 0354 - IMEISV and 5G SRVCC Capability missing in Data Reference AVP 16.2.0 2022-04 - - - - - Update to Rel-17 version (MCC) 17.0.0 3GPP TS 29.329 V17.0.0 (2022-04) 14 Release 17 3GPP 3GPP TS 29.228 V17.1.0 (2022-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 7 1 Scope 8 2 References 8 3 Definitions, symbols and abbreviations 9 3.1 Definitions 9 3.2 Abbreviations 10 4 Main Concept 11 5 General Architecture 11 5.1 Functional requirements of network entities 11 5.1.1 Functional requirements of P-CSCF 11 5.1.2 Functional requirements of I-CSCF 11 5.1.3 Functional requirements of S-CSCF 11 5.1.4 Functional requirements of HSS 11 5.1.5 Functional classification of Cx interface procedures 11 5.1.6 Functional Requirements of the Presentity Presence Proxy 12 6 Procedure Descriptions 12 6.1 Location management procedures 13 6.1.1 User registration status query 13 6.1.1.1 Detailed behaviour 14 6.1.2 S-CSCF registration/deregistration notification 16 6.1.2.1 Detailed behaviour 20 6.1.3 Network initiated de-registration by the HSS, administrative 25 6.1.3.1 Detailed behaviour 26 6.1.4 User location query 28 6.1.4.1 Detailed behaviour 29 6.2 User data handling procedures 30 6.2.1 User Profile download 30 6.2.2 HSS initiated update of User Information 30 6.2.2.1 Detailed behaviour 32 6.3 Authentication procedures 33 6.3.1 Detailed behaviour 36 6.4 User identity to HSS resolution 37 6.5 Implicit registration 38 6.5.1 S-CSCF initiated procedures 38 6.5.1.1 Registration 38 6.5.1.2 De-registration 38 6.5.1.3 Authentication 38 6.5.1.4 Downloading the user profile 38 6.5.1.5 Initiation of a session to a non-registered user 39 6.5.2 HSS initiated procedures 39 6.5.2.1 Update of User Profile 39 6.5.2.2 De-registration 39 6.5.2.3 Update of the Charging information 39 6.5.2.4 Update of the SIP Digest Authentication Data 39 6.5.2.5 Update of the Allowed WAF and/or WWSF Identities 40 6.6 Download of the Relevant User Profile and Charging Information and Allowed WAF and/or WWSF Identities 40 6.6.1 HSS initiated update of User Profile 40 6.6.2 S-CSCF operation 40 6.7 S-CSCF Assignment 40 7 Information element contents 43 7.1 Visited Network Identifier 43 7.2 Public User Identity 43 7.2a Public Service Identity 43 7.2b Wildcarded Public Identity 43 7.2c Void 43 7.3 Private User Identity 43 7.3a Private Service Identity 43 7.4 S-CSCF Name 43 7.4a AS Name 43 7.5 S-CSCF Capabilities 44 7.6 Result 44 7.7 User Profile 44 7.8 Server Assignment Type 44 7.9 Authentication Data 44 7.9.1 Item Number 44 7.9.2 Authentication Scheme 44 7.9.3 Authentication Information 44 7.9.4 Authorization Information 44 7.9.5 Confidentiality Key 44 7.9.6 Integrity Key 45 7.9.7 Authentication Context 45 7.9.8 Digest Authenticate 45 7.9.8.1 Digest Realm 45 7.9.8.2 Void 45 7.9.8.3 Digest Algorithm 45 7.9.8.4 Digest QoP 45 7.9.8.5 Digest HA1 45 7.9.8.6 Alternate Digest Algorithm 45 7.9.8.7 Alternate Digest HA1 45 7.9.9 Line Identifier 45 7.9.10 Framed IP Address 46 7.9.11 Framed IPv6 Prefix 46 7.9.12 Framed Interface Id 46 7.10 Number Authentication Items 46 7.11 Reason for de-registration 46 7.12 Charging information 46 7.13 Routing information 46 7.14 Type of authorization 46 7.15 Void 46 7.16 User Data Already Available 46 7.17 Associated Private Identities 46 7.18 Originating-Request 46 7.19 User Authorization Request Flags 47 7.20 Loose-Route Indication 47 7.21 S-CSCF Restoration Information 47 7.22 Associated Registered Private Identities 47 7.23 Multiple Registration Indication 47 7.24 Session-Priority 47 7.25 Identities with Emergency Registration 47 7.26 Priviledged-Sender Indication 47 7.27 LIA Flags 47 7.28 Server Assignment Request Flags 47 7.29 Allowed WAF and/or WWSF Identities 48 7.30 RTR Flags 48 7.31 Failed-PCSCF 48 8 Error handling procedures 48 8.1 Registration error cases 48 8.1.1 Cancellation of the old S-CSCF 48 8.1.2 Error in S-CSCF name 49 8.1.3 Error in S-CSCF assignment type 49 9 Protocol version identification 49 10 Operational Aspects 49 Annex A (normative): Mapping of Cx operations and terminology to Diameter 50 A.1 Introduction 50 A.2 Cx message to Diameter command mapping 50 A.3 Cx message parameters to Diameter AVP mapping 50 A.4 Message flows 51 A.4.1 RegistrationÐ user not registered 52 A.4.2 Registration Ð user currently registered 53 A.4.3 UE initiated de-registration 53 A.4.4 Network initiated de-registration 54 A.4.4.1 Registration timeout 54 A.4.4.2 Administrative de-registration 54 A.4.4.3 De-registration initiated by service platform 55 A.4.5 UE Terminating SIP session set-up 55 A.4.6 Initiation of a session to a non-registered user 56 A.4.6a AS originating session on behalf of a non-registered user 56 A.4.7 User Profile update 57 Annex B (informative): User profile UML model 58 B.1 General description 58 B.2 Service profile 58 B.2.1 Public Identification 59 B.2.1A Core Network Service Authorization 61 B.2.2 Initial Filter Criteria 62 B.2.3 Service Point Trigger 63 Annex C (informative): Conjunctive and Disjunctive Normal Form 65 Annex D (informative): High-level format for the User Profile 68 Annex E (normative): XML schema for the Cx interface user profile 69 Annex F (normative): Definition of parameters for service point trigger matching 74 Annex G (normative): Emergency registrations 74 Annex H (normative): Diameter overload control mechanism 75 H.1 General 75 H.2 HSS behaviour 75 H.3 I/S-CSCF behaviour 75 Annex I (Informative): Diameter overload node behaviour 76 I.1 Message prioritization 76 Annex J (normative): Diameter message priority mechanism 76 J.1 General 76 J.2 Cx/Dx interfaces 76 J.2.1 General 76 J.2.2 S-CSCF/I-CSCF behaviour 76 J.2.3 HSS/SLF behaviour 77 J.2.4 Interactions 77 Annex K (normative): Diameter load control mechanism 78 K.1 General 78 K.2 HSS behaviour 78 K.3 I-CSCF/S-CSCF behaviour 78 Annex L (informative): Change history 79 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope This 3GPP Technical Specification (TS) specifies: 1. The interactions between the HSS (Home Subscriber Server) and the CSCF (Call Session Control Functions), referred to as the Cx interface. 2. The interactions between the CSCF and the SLF (Server Locator Function), referred to as the Dx interface. 3. The interactions between the SIP Core and the SIP database, referred to as the Cx interface, for the Mission Critical Services, where this interface is named as AAA-1, as described in 3GPPÊTSÊ23.280Ê[30]. NOTE: In the 3GPPÊTSÊ23.280Ê[30] the term SIP database is used for the HSS and the term SIP Core is used for the P-CSCF, the I-CSCF and the S-CSCF when compared to this specification. The IP Multimedia (IM) Subsystem stage 2 is specified in 3GPPÊTSÊ23.228Ê[1] and the signalling flows for the IP multimedia call control based on SIP and SDP are specified in 3GPPÊTSÊ24.228Ê[2]. This document addresses the signalling flows for Cx and Dx interfaces. This document also addresses how the functionality of Px interface is accomplished. The Presence Service Stage 2 description (architecture and functional solution) is specified in 3GPPÊTSÊ23.141Ê[10]. 2 References [1] 3GPPÊTSÊ23.228: ""IP Multimedia (IM) Subsystem Ð Stage 2"". [2] 3GPPÊTSÊ24.228: ""Signalling flows for the IP multimedia call control based on SIP and SDP"". [3] 3GPPÊTSÊ33.203: ""Access security for IP-based services"". [4] 3GPPÊTSÊ23.002: ""Network architecture"". [5] 3GPPÊTSÊ29.229: ""Cx Interface based on Diameter Ð Protocol details"". [6] 3GPPÊTSÊ23.218: ""IP Multimedia (IM) Session Handling; IP Multimedia (IM) call model"". [7] IETFÊRFCÊ2045 ""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"". [8] 3GPPÊTSÊ24.229: ""IP Multimedia Call Control Protocol based on SIP and SDP"" Ð stage 3. [9] Void. [10] 3GPPÊTSÊ23.141: ""Presence Service; Architecture and Functional Description"". [11] IETFÊRFCÊ3261 ""SIP: Session Initiation Protocol"". [12] IETFÊRFCÊ4566 ""SDP: Session Description Protocol"". [13] IEEE 1003.1-2004, Part 1: Base Definitions. [14] IETFÊRFCÊ2486: ""The Network Access Identifier"". [15] IETFÊRFCÊ3966: ""The tel URI for Telephone Numbers"". [16] Void. [17] 3GPPÊTSÊ23.003: ""Numbering, addressing and identification"". [18] 3GPPÊTSÊ23.008: ""Organization of subscriber data"". [19] 3GPPÊTSÊ23.380: ""IMS Restoration Procedures"". [20] Void [21] IETFÊRFCÊ4005: ""Diameter Network Access Server Application"". [22] IETFÊRFCÊ4412: ""Communications Resource Priority for the Session Initiation Protocol (SIP)"". [23] 3GPPÊTSÊ23.167: ""IP Multimedia Subsystem (IMS) emergency sessions"". [24] IETFÊRFCÊ7683: ""Diameter Overload Indication Conveyance"". [25] 3GPPÊTSÊ22.153: ""Multimedia Priority Service"". [26] ANSI X3.4: ""Coded Character Set - 7-bit American Standard Code for Information Interchange"". [27] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [28] Void [29] IETFÊIETFÊRFCÊ8583: ""Diameter Load Information Conveyance"". [30] 3GPPÊTSÊ23.280: ""Common functional architecture to support mission critical services"". [31] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [32] 3GPPÊTSÊ24.323: ""3GPP IP Multimedia Subsystem (IMS) service level tracing management object (MO)"". [33] IETFÊRFCÊ7616: ""HTTP Digest Access Authentication"". 3 Definitions, symbols and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions given in TSÊ23.003Ê[17] apply: Distinct Public Service Identity Distinct Public User Identity Public Service Identity Public User Identity Wildcarded Public Service Identity Wildcarded Public User Identity For the purposes of the present document, the following terms and definitions apply. Common Part (of a user profile): Contains Initial Filter Criteria instances that should be evaluated both for registered and unregistered Public User Identities, or for unregistered Public Service Identities in the S-CSCF. Complete user profile: Contains the Initial Filter Criteria instances of all three different user profile parts; registered part, unregistered part and common part. IP Multimedia session: IP Multimedia session and IP Multimedia call are treated as equivalent in this specification. Authentication pending flag: A flag that indicates that the authentication of a Public User Identity - Private User Identity pair is pending and waiting for confirmation. Charging information: Data that is sent in the Charging-Information AVP. Allowed WAF and/or WWSF identities: A list of network addresses identifying WebRTC Authentication Functions (WAFs) and/or WebRTC Web Server Functions (WWSFs) allowed for a subscription. Implicitly registered Public User Identity set: A set of Public User Identities, which are registered and de-registered simultaneously when any of the Public User Identities belonging to that set is registered or de-registered. Not Registered State: Public Identity is not Registered and has no S-CSCF assigned. Private Identity: Either a Private User Identity or a Private Service Identity. Public Identity: Either a Public User Identity or a Public Service Identity. Registered Part (of a user profile): Contains Initial Filter Criteria instances that should be evaluated only for registered Public User Identities in the S-CSCF. iFCs from the registered part need not be evaluated when the Public Identity is unregistered. Registered State: Public User Identity is Registered at the request of the user and has an S-CSCF assigned. S-CSCF reassignment pending flag: A flag that is handled only when IMS Restoration Procedures are supported.and that indicates that the subscription may be reassigned to a new S-CSCF (i.e. the current S-CSCF is not responding) Unregistered part (of a user profile): Contains Initial Filter Criteria instances that should be evaluated only for unregistered Public Identities in the S-CSCF. iFCs from the unregistered part need not be evaluated when the Public User Identity is registered. Unregistered State: Public Identity is not Registered but has a serving S-CSCF assigned to execute Unregistered state services as a consequence of a terminating request, or an originating request from an AS on behalf of a user, or there is an S-CSCF keeping the user profile stored. User information: The user related data that the S-CSCF requests from the HSS or HSS pushes to the S-CSCF, e.g. user profile,charging information, allowed WAF and/or WWSF identities and authentication information. User profile: Data that is sent in the User-Data AVP. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AVP Attribute Value Pair C Conditional CSCF Call Session Control Function DRMP Diameter Routing Message Priority DSCP Differentiated Services Code Point GIBA GPRS-IMS-Bundled-Authentication HSS Home Subscriber Server IE Information Element IP Internet Protocol I-CSCF Interrogating CSCF IM IP Multimedia IMS IP Multimedia Subsystem M Mandatory MPS Multimedia Priority Service NASS Network Attachment SubSystem O Optional P-CSCF Proxy CSCF SIP Session Initiation Protocol SLF Server Locator Function S-CSCF Serving CSCF WAF WebRTC Authentication Function WWSF WebRTC Web Server Function 4 Main Concept This document presents the Cx interface related functional requirements of the communicating entities. It gives a functional classification of the procedures and describes the procedures and message parameters. Error handling flows, protocol version identification, etc. procedures are also included. 5 General Architecture This clause further specifies the architectural assumptions associated with the Cx reference point, building on TSÊ23.228Ê[1] and also the Px reference point building upon TSÊ23.141Ê[10]. 5.1 Functional requirements of network entities 5.1.1 Functional requirements of P-CSCF There is no requirement for the interaction between the P-CSCF and the HSS. 5.1.2 Functional requirements of I-CSCF The I-CSCF communicates with the HSS over the Cx interface. For functionality of the I-CSCF refer to TSÊ23.002Ê[4]. 5.1.3 Functional requirements of S-CSCF The S-CSCF communicates with the HSS over the Cx interface. For functionality of the S-CSCF refer to TSÊ23.002Ê[4]. 5.1.4 Functional requirements of HSS The HSS communicates with the I-CSCF and the S-CSCF over the Cx interface. For functionality of the HSS refer to TSÊ23.002Ê[4]. 5.1.5 Functional classification of Cx interface procedures Operations on the Cx interface are classified in functional groups: 1. Location management procedures - The operations regarding registration and de-registration. - Location retrieval operation. 2. User data handling procedures - The download of user information during registration and to support recovery mechanisms. - Operations to support the updating of user data and recovery mechanisms. 3. User authentication procedures 4. IMS Restoration Procedures (see TSÊ23.380Ê[19]) to support S-CSCF service interruption 5.1.6 Functional Requirements of the Presentity Presence Proxy The interaction between the Presentity Presence Proxy and the HSS, referred to as the Px interface, is handled using the mechanisms defined for the Cx interface. 6 Procedure Descriptions In the tables that describe the Information Elements transported by each command, each Information Element is marked as (M) Mandatory, (C) Conditional or (O) Optional in the Category ""Cat."" column. The application level specification overrides the ABNF defining the presence of the AVPs to be included in the Diameter commands. The category defined by the Information Element table shall always be the same, i.e. Optional; or more restrictive, i.e. Mandatory or Conditional, than the presence requirements defined by the ABNF syntax, e.g. a required AVP in the ABNF shall not be overridden by an Optional IE but an Optional AVP in the ABNF may be overridden by the Mandatory or Conditional IE Category. - A mandatory Information Element shall always be present in the command. If this Information Element is absent, an application error occurs at the receiver and an answer message shall be sent back to the originator of the request with the Result-Code set to DIAMETER_MISSING_AVP. This message shall also include a Failed-AVP AVP containing the missing Information Element i.e. the corresponding Diameter AVP defined by the AVP Code and the other fields set as expected for this Information Element. - A conditional Information Element (marked as (C) in the table) shall be present in the command if certain conditions are fulfilled. - If the receiver detects that those conditions are fulfilled and the Information Element is absent, an application error occurs and an answer message shall be sent back to the originator of the request with the Result-Code set to DIAMETER_MISSING_AVP. This message shall also include a Failed-AVP AVP containing the missing Information Element i.e. the corresponding Diameter AVP defined by the AVP Code and the other fields set as expected for this Information Element. - If those conditions are not fulfilled, the Information Element shall be absent."
"If however this Information Element appears in the message, it shall not cause an application error and it may be ignored by the receiver if this is not explicitly defined as an error case. Otherwise, an application error occurs at the receiver and an answer message with the Result-Code set to DIAMETER_AVP_NOT_ALLOWED shall be sent back to the originator of the request. A Failed-AVP AVP containing a copy of the corresponding Diameter AVP shall be included in this message. - An optional Information Element (marked as (O) in the table) may be present or absent in the command, at the discretion of the application at the sending entity. Absence or presence of this Information Element shall not cause an application error and may be ignored by the receiver. When a procedure is required to determine whether two S-CSCF names are equal, the rules for SIP URI comparison specified in RFC 3261 clauseÊ19.1.4 shall apply. When a procedure is required to determine the Public Identity used for an identity lookup in HSS and SLF, the HSS and SLF shall use the Public Identity from the SIP URI or Tel URI as contained in the Public-Identity AVP that is in canonical form as described by TSÊ23.003Ê[17]. Unknown permanent failure error codes shall be treated in the same way as DIAMETER_UNABLE_TO_COMPLY. For unknown transient failure error codes the request may be repeated, or handled in the same way as DIAMETER_UNABLE_TO_COMPLY. 6.1 Location management procedures 6.1.1 User registration status query This procedure is used between the I-CSCF and the HSS during SIP registrations. The procedure is invoked by the I-CSCF, corresponds to the combination of the functional level operations Cx-Query and Cx-Select-Pull (see TSÊ23.228Ê[1]) and is used: - To authorize the registration of the distinct Public User Identity, checking multimedia subsystem access permissions and roaming agreements. - To perform a first security check, determining whether the distinct Public User Identity in the message is associated with the Private User Identity sent in the message. - To obtain either the S-CSCF where the distinct Public User Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored), or the list of capabilities that the S-CSCF has to support. This procedure is mapped to the commands User-Authorization-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.1.1.1 and 6.1.1.2 detail the involved information elements. Table 6.1.1.1: User registration status query Information element name Mapping to Diameter AVP Cat. Description Public User Identity (See 7.2) Public-Identity M Public User Identity to be registered Visited Network Identifier (See 7.1) Visited-Network-Identifier M Identifier that allows the home network to identify the visited network Type of Authorization (See 7.14) User-Authorization-Type C Type of authorization requested by the I-CSCF. If the request corresponds to a de-registration, i.e. Expires field or expires parameter in Contact field in the REGISTER method is equal to zero, this AVP shall be present in the command and the value shall be set to DE-REGISTRATION. If the request corresponds to an initial registration or a re-registration, i.e. Expires field or expires parameter in Contact field in the REGISTER method is not equal to zero then this AVP may be absent from the command. If present its value shall be set to REGISTRATION. If the request corresponds to an initial registration or a re-registration or a de-registration and the I-CSCF explicitly queries the S-CSCF capabilities, then this AVP shall be present in the command and the value shall be set to REGISTRATION_AND_CAPABILITIES. The I-CSCF shall use this value when the S-CSCF currently assigned to the Public User Identity in the HSS, cannot be contacted and a new S-CSCF needs to be selected. The I-CSCF shall also use this value for RLOS related registrations when the S-CSCF currently assigned to the Public User Identity in the HSS does not support RLOS (see 3GPPÊTSÊ23.228Ê[1] annex Z) and a new S-CSCF (supporting RLOS) needs to be selected. RLOS support of the different S-CSCFs shall be locally configured in the I-CSCF, and this capability is independent on the subscribed capabilities received from HSS. Private User Identity (See 7.3) User-Name M Private User Identity Routing Information (See 7.13) Destination-Host, Destination-Realm C If the I-CSCF knows HSS name Destination-Host AVP shall be present in the command. Otherwise, only Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the I-CSCF. UAR Flags (See 7.19) UAR-Flags O This Information Element contains a set of indications. See 7.19 for the content of the information element. Table 6.1.1.2: User registration status response Information element name Mapping to Diameter AVP Cat. Description Result (See 7.6) Result-Code / Experimental-Result M Result of the operation. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. S-CSCF capabilities (See 7.5) Server-Capabilities O Required capabilities of the S-CSCF to be assigned to the IMS Subscription. S-CSCF Name (See 7.4) Server-Name C Name of the assigned S CSCF. 6.1.1.1 Detailed behaviour The HSS shall, in the following order (if there is an error in any of the following steps the HSS shall stop processing and return the corresponding error code, see TSÊ29.229Ê[5]): 0. If the HSS supports WebRTC as described in TSÊ23.228Ê[1] clause U.2.1.4, it shall check if the Private User Identity and the Public User Identity are managed by a third party, if so the HSS continues in step 4. NOTEÊ: How the HSS identifies that the Private User Identity and the Public User Identity are managed by a third party for WebRTC and how the HSS identifies the corresponding user profile are implementation specific. 1. Check that the Private User Identity and the Public User Identity exists in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 2. Check that the Public User Identity matches a distinct Public User Identity in the HSS. If it doesn't, the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 3. Check that the Public User Identity received in the request is associated with the Private User Identity received in the request. If not Experimental-Result-Code shall be set to DIAMETER_ERROR _IDENTITIES_DONT_MATCH. 4. Check whether the Public User Identity received in the request is barred from the establishment of multimedia sessions. - If it is an IMS Emergency Registration (by checking the UAR Flags) or the Public User Identity received in the request is not barred, continue to step 5. - Otherwise, the HSS shall check whether there are other non-barred Public User Identities to be implicitly registered with that one. - If so, continue to step 5. - If not, Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED. 5. Check the User-Authorization-Type received in the request: - If it is REGISTRATION or if User-Authorization-Type is absent from the request, the HSS shall check whether the UAR Flags indicate that this is an IMS Emergency Registration: - If it is not, and the Public User Identity is allowed to roam in the visited network (if not Experimental-Result-Code shall be set to DIAMETER_ERROR _ROAMING_NOT_ALLOWED) and authorized to register (if not Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED) then continue to step 6. - If it is an IMS Emergency Registration, authorization shall be granted and the HSS shall not perform any check regarding roaming. Continue to step 6. - If it is DE_REGISTRATION, the HSS may not perform any check regarding roaming. Continue to step 6. - If it is REGISTRATION_AND_CAPABILITIES, the HSS shall check whether the UAR Flags indicate that this is an IMS Emergency Registration: - If it is not, and the Public User Identity is allowed to roam in the visited network (if not Experimental-Result-Code shall be set to DIAMETER_ERROR _ROAMING_NOT_ALLOWED) and authorized to register (if not Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED). The HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. If Server-Capabilities AVP is absent, it indicates to the I-CSCF that it can select any available S-CSCF. If an S-CSCF is already assigned in the HSS and IMS Restoration Procedures are supported in the HSS, the HSS shall set the S-CSCF reassignment pending flag and shall allow overwriting of the S-CSCF name in the next SAR request. Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing. - If it is an IMS Emergency Registration, authorization shall be granted and the HSS shall not perform any check regarding roaming. The HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. The Server-Capabilities AVP may be absent, to indicate to the I-CSCF that it can select any available S-CSCF. Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing. 6. Check the state of the Public User Identity received in the request: - If it is registered, the HSS shall return the stored S-CSCF name. No S-CSCF capabilities shall be present in the response. If User-Authorization-Type is equal to REGISTRATION or is absent, Experimental-Result-Code shall be set to DIAMETER_SUBSEQUENT_REGISTRATION. If User-Authorization-Type is equal to DE-REGISTRATION, Result-Code shall be set to DIAMETER_SUCCESS. - If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored) and User-Authorization-Type is equal to DE-REGISTRATION, the HSS shall return the stored S-CSCF name and the Result-Code shall be set to DIAMETER_SUCCESS. If the User-Authorization-Type is equal to REGISTRATION or is absent, then the HSS shall return the stored S-CSCF name and the Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities. - If it is not registered yet, the HSS shall check the value of User-Authorization-Type received in the request: - If the value of User-Authorization-Type is DE_REGISTRATION and the Authentication pending flag is set, the HSS shall return the stored S-CSCF name and Experimental-Result-Code set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF capabilities. Otherwise, if Authentication pending flag is not set, the HSS shall not return any S-CSCF name or S-CSCF capabilities. The HSS shall set the Experimental-Result-Code to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED in the response. - If the value of User-Authorization-Type is REGISTRATION or is absent, then the HSS shall check if there is at least one Public User Identity within the IMS Subscription with an S-CSCF name assigned. - If there is at least one Public User Identity within the IMS Subscription that is registered, the HSS shall return the S-CSCF name assigned for that Public User Identity and Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities. - If there is at least one Public User Identity within the IMS Subscription that is unregistered (i.e registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored), then the HSS shall return the stored S-CSCF name and the Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities. - If there is no identity of the user within the same IMS Subscription that is registered or unregistered, the HSS shall check if there is an S-CSCF name stored for the user (e.g. the user is being authenticated by the S-CSCF as indicated by the Authentication pending flag). If it is, the HSS shall return the stored S-CSCF name and Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities. - If there is not any Public User Identity within the IMS Subscription with an S-CSCF name assigned, then the HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. The Server-Capabilities AVP may be absent, to indicate to the I-CSCF that it may select any available S-CSCF. Experimental-Result-Code shall be set to DIAMETER_FIRST_REGISTRATION. The HSS shall not return any S-CSCF name. If the HSS cannot fulfil received request, e.g. due to database error, it shall set Result-Code to DIAMETER_UNABLE_TO_COMPLY. No S-CSCF name or S-CSCF capabilities shall be present in the response. 6.1.2 S-CSCF registration/deregistration notification This procedure is used between the S-CSCF and the HSS. The procedure is invoked by the S-CSCF, corresponds to the combination of the operations Cx-Put and Cx-Pull (see TSÊ23.228Ê[1]) and is used: - To assign an S-CSCF to a Public Identity, or to clear the name of the S-CSCF assigned to one or more Public Identities. - To download from HSS the relevant user information for the S-CSCF. - To backup and retrieve the S-CSCF Restoration Information (see TSÊ23.380Ê[19]) in the HSS. - To provide a P-CSCF Restoration Indication, and optionally, the address of the failed P-CSCF, to the HSS and trigger P-CSCF Restoration mechanism. This procedure is mapped to the commands Server-Assignment-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.1.2.1 and 6.1.2.2 describe the involved information elements. Table 6.1.2.1: S-CSCF registration/deregistration notification request Information element name Mapping to Diameter AVP Cat. Description Public User Identity / Public Service Identity (See 7.2 and 7.2a) Public-Identity C Public Identity or list of Public Identities. One and only one Public Identity shall be present if the Server-Assignment-Type is any value other than TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, USER_DEREGISTRATION_STORE_SERVER_NAME or ADMINISTRATIVE_DEREGISTRATION. If Server-Assignment-Type indicates deregistration of some type and Private Identity is not present in the request, at least one Public Identity shall be present. S-CSCF Name (See 7.4) Server-Name M Name of the S-CSCF. Private User Identity / Private Service Identity (See 7.3 and 7.3a) User-Name C Private Identity. It shall be present if it is available when the S-CSCF issues the request. It may be absent during the initiation of a session to an unregistered Public Identity (Server-Assignment-Type shall contain the value UNREGISTERED_USER) or after S-CSCF recovery upon originating request different than REGISTER (Server-Assignment-Type shall contain the value NO_ASSIGNMENT). In case of de-registration, Server-Assignment-Type equal to TIMEOUT_DEREGISTRATION, ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME if no Public-Identity AVPs are present then User-Name AVP shall be present. Server Assignment Type (See 7.8) Server-Assignment-Type M Type of update, request or notification that the S-CSCF requests in the HSS (e.g: de-registration). See 3GPPÊTSÊ29.229Ê[5] for all the possible values. User Data Already Available (See 7.16) User-Data-Already-Available M This indicates if the user profile and charging information and, if supported and present in the subscription, allowed WAF and/or WWSF identities are already available in the S-CSCF. In the case where Server-Assignment-Type is not equal to NO_ASSIGNMENT, REGISTRATION, RE_REGISTRATION or UNREGISTERED_USER, the HSS shall not use User Data Already Available when processing the request. Routing Information (See 7.13) Destination-Host C If the S-CSCF knows the HSS name, the Destination-Host AVP shall be present in the command. This information is available if the request belongs to an already existing registration, e.g. in case of the re-registration, where the HSS name is stored in the S-CSCF. The HSS name is obtained from the Origin-Host AVP, which is received from the HSS, e.g. included in the MAA command. This information may not be available if the command is sent as a consequence of a session termination for an unregistered Public Identity. In this case the Destination-Host AVP is not present and the command is routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the S-CSCF. Wildcarded Public Identity (See 7.2b) Wildcarded-Public-Identity O If the request refers to a Wildcarded PSI or Wildcarded Public User Identity, and the Server-Asignment-Type is set to UNREGISTERED_USER, NO_ASSIGNMENT, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or TIMEOUT_DEREGISTRATION, the S-CSCF may include the corresponding Wildcarded PSI or Wildcarded Public User Identity in this information element. If this element is present, it shall be used by the HSS to identify the identity affected by the request. The terms Public Identity or Public Service Identity in the detailed behaviour refer then to the Wildcarded Public Identity. S-CSCF Restoration Information (See 7.21) SCSCF-Restoration-Info C When the S-CSCF supports IMS Restoration Procedures, if Server-Assignment-Type is REGISTRATION or RE_REGISTRATION, and any of the related restoration information changed compared to the previous one, the S-CSCF shall send this information element to the HSS. This information allows a later retrieval in case of an S-CSCF service interruption. Multiple-Registration-Indication (See 7.23) Multiple-Registration-Indication C When the S-CSCF supports IMS Restoration Procedures, if Server-Assignment-Type is REGISTRATION and the registration is a multiple registration and the Public User Identity is not stored as registered with the Private User Identity as in the request in the S-CSCF, the S-CSCF shall send this information element to the HSS. Session-Priority (See 7.24) Session-Priority O This information element, if present, shall indicate the session's priority to the HSS. SAR Flags (See 7.28) SAR-Flags O This Information Element contains a set of indications. See 7.28 for the content of the information element. Failed P-CSCF Failed-PCSCF O If present, this Information Element shall contain the address (FQDN and/or IP addresses) of a failed P-CSCF; it shall only be included if the SAR Flags IE contains the ""P-CSCF Restoration Indication"" (see clauseÊ7.28). Table 6.1.2.2: S-CSCF registration/deregistration notification response Information element name Mapping to Diameter AVP Cat. Description Private User Identity / Private Service Identity (See 7.3 and 7.3a) User-Name C Private Identity. It shall be present if it is available when the HSS sends the response. It may be absent in the following error case: when the Server-Assignment-Type of the request is UNREGISTERED_USER and the received Public Identity is not known by the HSS. Registration result (See 7.6) Result-Code / Experimental-Result M Result of registration. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. User Profile (See 7.7) User-Data C Relevant user profile. It shall be present when Server-Assignment-Type in the request is equal to NO_ASSIGNMENT, REGISTRATION, RE_REGISTRATION or UNREGISTERED_USER according to the rules defined in clauseÊ6.6. If the S-CSCF receives more data than it is prepared to accept, it shall perform the de-registration of the Private Identity with Server-Assignment-Type set to DEREGISTRATION_TOO_MUCH_DATA and send back a SIP 3xx or 480 (Temporarily Unavailable) response, which shall trigger the selection of a new S-CSCF by the I-CSCF, as specified in 3GPPÊTSÊ24.229Ê[8]. Charging Information (See 7.12) Charging-Information C Addresses of the charging functions. It shall be present when the User-Data AVP is sent to the S-CSCF according to the rules defined in clauseÊ6.6. When this parameter is included, either the Primary-Charging-Collection-Function-Name AVP or the Primary-Event-Charging-Function-Name AVP shall be included. All other elements shall be included if they are available. Associated Private Identities Associated-Identities O This AVP contains all Private Identities, which belong to the same IMS subscription as the Private Identity or Public Identity received in the SAR command. If the IMS subscription contains only single Private Identity this AVP shall not be present. Loose-Route Indication Loose-Route-Indication C This AVP indicates to the S-CSCF that loose-route mechanism shall be applied to the public identities contained in the user profile received from the HSS. If the loose-route mechanism is required, this AVP shall be present and set to LOOSE_ROUTE_REQUIRED. If the Loose-Route mechanism is not required, this AVP may be either absent or present. If present, it shall be set to LOOSE_ROUTE_NOT_REQUIRED. S-CSCF Restoration Information (See 7.21) SCSCF-Restoration-Info C This information shall be present if it was stored by the S-CSCF in the HSS and Server-Assignment-Type is either UNREGISTERED_USER or NO_ASSIGNMENT. This information shall also be present if it was stored by the S-CSCF in the HSS and the SAR indicates it is related to a multiple registration and Server-Assignment-Type is REGISTRATION. This information may be present if it was stored by the S-CSCF in the HSS and Server-Assignment-Type is either REGISTRATION or RE-REGISTRATION and there are other Private Identities different from the Private Identity received in the SAR command being registered with the Public Identity received in the SAR command. Associated Registered Private Identities (See 7.22) Associated-Registered-Identities C This AVP contains all Private Identities that were registered with the Public Identity received in the SAR command. The HSS shall send this information element if the IMS Restoration Procedures are supported and the value of Server-Assignment-Type in the request is REGISTRATION or RE_REGISTRATION and there are other Private Identities different from the Private Identity received in the SAR command being registered with the Public Identity received in the SAR command. Otherwise, this AVP shall not be present. S-CSCF Name (See 7.4) Server-Name C Name of the assigned S-CSCF. This AVP shall be present, if the requesting S-CSCF name is different from the previously assigned S-CSCF name stored in the HSS. Wildcarded Public Identity (See 7.2b) Wildcarded-Public-Identity C This AVP shall be present if: - the value of Server-Assignment-Type in the request was UNREGISTERED_USER or NO_ASSIGNMENT and - the Wildcarded-Public-Identity AVP in the request was not present and - the Public Identity in the request fell within the range of a Wildcarded Public User Identity in the HSS whose state is registered/unregistered. If this element is present, it shall be used by the S-CSCF to identify the identity affected by the request. Priviledged-Sender Indication (See 7.26) Priviledged-Sender-Indication O This AVP indicates if the Private User Identity shall be considered as a priviledged sender. If not present, it means that the Private User Identity is not considered a priviledged sender. Allowed WAF and/or WWSF Identities (See 7.29) Allowed-WAF-WWSF-Identities C Addresses of the WAFs and/or WWSFs the subscription is allowing to use. This AVP shall be present if both a) it is applicable for the subscription and b) the User-Data AVP is present. 6.1.2.1 Detailed behaviour On registering/deregistering a Public Identity the S-CSCF shall inform the HSS. The same procedure is used by the S-CSCF: - to get the user information which contains the user profile, the charging information and the allowed WAF and/or WWSF Identities. The relevant user profile downloaded is described in more detailed in clauses 6.5.1 and 6.6. - to provide a P-CSCF Restoration Indication to the HSS when the S-CSCF, supporting the HSS based P-CSCF restoration mechanism described in TSÊ23.380Ê[19], has identified a P-CSCF failure for a given UE and then triggers the P-CSCF Restoration mechanism execution for this UE. The Public-Identity AVP and User-Data AVPs in this command pair shall contain only one type of identities i.e. either only Public User Identities, or only Public Service Identities. User initiated registration/deregistration procedures (i.e. server-assignment-type is set to RE_REGISTRATION, USER_DEREGISTRATION, etc.) shall only be allowed for distinct Public User Identities. The HSS holds information about the state of registration of all the identities related to an IMS Subscription. The S-CSCF uses this procedure to update such states. For Shared Public User Identities, the S-CSCF shall initiate this procedure towards the HSS for each Private User Identity undergoing a Registration or Deregistration related to the Shared Public User Identity. For implicitly registered identities, the rules defined in ClauseÊ6.5.1 shall apply. When the request message was received because of a terminating session request, the HSS may prioritise the received request message according to priority level received within the Session-Priority AVP. NOTE 1: Refer to Annex J for HSS procedures associated with the handling of both the Session-Priority AVP and DRMP AVP received in the request message. The HSS shall, in the following order (in case of an error in any of the steps the HSS shall stop processing and return the corresponding error code, see TSÊ29.229Ê[5]): 1. Check that the Public Identity and Private Identity exist in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 2. The HSS may check whether the Private and Public Identities received in the request are associated in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH. 3. If more than one Public-Identity AVP is present and the Server-Assignment-Type is one of the values defined in Table 6.1.2.1 as applying for only one identity, then the Result Code shall be set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and no user information shall be returned. 4. The HSS shall check the Public Identity type received in the request. - If the identity in the request is a distinct Public User Identity, continue in step 5, otherwise the HSS shall check the server-assignment-type: If it indicates REGISTRATION, RE_REGISTRATION, USER_DEREGISTRATION, USER_DEREGISTRATION_STORE_SERVER_NAME, AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. - If the identity in the request is a Public Service Identity, then check if the PSI Activation State for that identity is active. If not, then the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN. 5. Check the Server Assignment Type value received in the request: - If it indicates REGISTRATION or RE_REGISTRATION, the HSS shall check whether the Public Identity is assigned for the S-CSCF requesting the data. If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF, and IMS restoration procedures are not supported or the S-CSCF reassignment pending flag is not set, the HSS shall include the name of the previously assigned S-CSCF in the response message andÊthe Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED. If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF and IMS restoration procedures are supported, and the S-CSCF reassignment pending flag is set, the HSS shall overwrite the S-CSCF name and shall reset the S-CSCF reassignment pending flag. If there is no S-CSCF assigned to the user or the requesting S-CSCF is the same as the previously assigned S-CSCF stored in the HSS,Êthe HSS shall download the relevant user information taking into consideration the value set in the User-Data-Already-Available AVP (see clauseÊ6.6). The Result-Code shall be set to DIAMETER_SUCCESS and the HSS shall set the registration state of the Public User Identity as registered (if not already registered). If the S-CSCF Restoration Information is included in the request and the HSS implements IMS Restoration procedures, and if it is RE_REGISTRATION, the HSS shall store this information. If the Public User Identity's authentication pending flag which is specific for the Private User Identity is set, the HSS shall clear it. If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription. If the loose-route mechanism is required for the registered Public User Identities, the Loose-Route-Indication AVP shall be added to the answer message. If there are multiple Private User Identities being registered with the Public Identity received in the request message, and the IMS Restoration Procedures are supported in the HSS, the Associated-Registered-Identities AVP shall be added to the answer message and it shall contain all Private User Identities being registered with the Public Identity, and subject to the operator policy, the HSS may include all stored S-CSCF Restoration Information groups associated to the Private User Identities in the response. NOTE 2: If the HSS returns all the S-CSCF Restoration Information groups in the response, the S-CSCF can ignore the Associated-Registered-Identities AVP and skip additional Server-Assignment-Request since the information is already made available. If it is REGISTRATION and the HSS implements IMS Restoration procedures, if multiple registration indication is included in the request and the Public User Identity is stored as registered in the HSS, and there is restoration information related to the Private User Identity, the HSS shall not overwrite the stored S-CSCF Restoration Information, instead, it shall send the stored S-CSCF restoration information together with the user profile in the SAA. Subject to the operator policy, if there is S-CSCF Restoration Information associated with several Private User Identities, the HSS may include all the S-CSCF Restoration Information groups in the response. The Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. Otherwise, the HSS shall store the received S-CSCF restoration information. The Result-Code shall be set to DIAMETER_SUCCESS. - If it indicates UNREGISTERED_USER, the following applies. If the P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS supporting the P-CSCF-Restoration-mechanism feature shall check whether at least one of the serving node(s) for corresponding user support this feature. If none of the serving nodes support the feature, the HSS shall stop processing this request and the Result-Code shall be set to DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED. The HSS shall check whether the Public Identity is assigned for the S-CSCF requesting the data: - If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF, and IMS restoration procedures are not supported or the S-CSCF reassignment pending flag is not set and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall include the name of the previously assigned S-CSCF in the response message andÊthe Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED. - If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF and IMS restoration procedures are supported, and the S-CSCF reassignment pending flag is set, the HSS shall overwrite the S-CSCF name and shall reset the S-CSCF reassignment pending flag. - If there is no S-CSCF assigned to the user or the requesting S-CSCF is the same as the previously assigned S-CSCF stored in the HSS, the HSS shall store the S-CSCF name. The HSS shall check the Public Identity registration state: - If the registration state of the Public Identity is not registered or unregistered, the HSS shall set or keep the registration state of the Public Identity as unregistered, i.e. registered as a consequence of an originating or terminating request and if a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP download the relevant user information. The Result-Code shall be set to DIAMETER_SUCCESS. If there are multiple Private User Identities associated to the Public User Identity in the HSS, the HSS shall arbitrarily select one of the Private User Identities and put it into the response message. - If the registration state of the Public Identity is registered and IMS restoration procedures are not supported, the HSS shall set the registration state of the Public identity as unregistered, clear any S-CSCF Restoration Information associated with the Public User Identity (if any) and if a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP download the relevant user information. The Result-Code shall be set to DIAMETER_SUCCESS. If there are multiple Private User Identities associated to the Public User Identity in the HSS, the HSS shall arbitrarily select one of the Private User Identities and put it into the response message. NOTE 3: The case where S-CSCF Restoration Information is stored in the HSS even though IMS Restoration Procedures are not supported corresponds to the situation where the HSS supports IMS Restoration Procedures but a new assigned S-CSCF does not, while the former S-CSCF supported this feature. - If the registration state of the Public Identity is registered and IMS restoration procedures are supported and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall include in the response all S-CSCF Restoration Information related with the Public User Identity. If there is S-CSCF Restoration Information associated with several Private User Identities, the HSS shall include all the S-CSCF Restoration Information groups in the response. The Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. - If the registration state of the Public Identity is Registered and IMS Restoration Procedures are supported and a P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS shall set the registration state of the Public identity as Unregistered and clear any S-CSCF Restoration Information associated with the Public User Identity (if any). The Result-Code shall be set to DIAMETER_SUCCESS. If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription. If the S-CSCF receives a wildcarded public identity from the I-CSCF, the S-CSCF shall use this wildcarded public identity to fetch the user profile (i.e.Êby sending a Cx-SAR including Wildcarded-Public-Identity AVP if the profile is not available) and registration information locally stored. If the S-CSCF does not receive a wildcarded public identity, the S-CSCF shall not perform wildcarded public identity matching and shall use the public identity received instead to fetch the user profile (i.e.Êby sending a Cx-SAR without including Wildcarded-Public-Identity AVP if the profile is not available) and registration information. NOTE 4: There may be SIP requests in which the S-CSCF does not receive information of a wildcarded public identity, e.g. originating call from an AS on behalf of a user. NOTE 5: Since a distinct public identity falling into the range of a wildcarded public identity can have a different service profile, the S-CSCF does not perform the wildcarded public identity matching against the public identity received to avoid using the wrong service profile. If the Wildcarded-Public-Identity AVP is not received and if the Public Identity falls within the range of a wildcarded public identity whose registration state is registered and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall not overwrite the registration state. The Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE and the HSS shall include the Wildcarded-Public-Identity AVP in the response. Upon reception of this error, the S-CSCF should behave as if it has received a wildcarded public identity in the first place. If SAR-Flags AVP includes a P-CSCF-Restoration-Indication, the HSS supporting the P-CSCF-RestorationÐmechanism feature shall send a P-CSCF restoration indication to the serving nodes where the IMSI associated to the received Private Identity is registered, i.e. SGSN and/or MME, using S6a/S6d IDR/IDA or Gr ISD request/answer as described in TSÊ23.380Ê[19] clauseÊ5.4. The Result-Code shall be set to DIAMETER_SUCCESS. - If it indicates TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or ADMINISTRATIVE_DEREGISTRATION, the following applies. If it indicates ADMINISTRATIVE_DEREGISTRATION and if the P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS supporting the P-CSCF-Restoration-mechanism feature shall check whether at least one of the serving node(s) for corresponding user support this feature. If none of the serving nodes support the feature, the HSS shall stop processing this request and the Result-Code shall be set to DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED. The HSS shall check the registration state for all the Public Identities in the request. - If a Private User Identity is present in the request, if the request did not contain Public Identities the HSS shall check the registration state of the Public Identities associated with the Private Identity identified in the request. For each Public Identity: - If the registration state of the Public User Identity is Registered, the HSS shall check if the Public User Identity is currently registered with one or more Private User Identities. - If the Public User Identity is currently registered with only one Private User Identity, the HSS shall set the registration state of the Public User Identity to Not Registered and clear the S-CSCF name and any S-CSCF Restoration Information associated with the Public User Identity. - If the Public User Identity is currently registered with more than one Private User Identity, the HSS shall keep the registration state of the Public User Identity as Registered and retain the S-CSCF name associated with the Public User Identity. The HSS shall remove any S-CSCF Restoration Information associated to the registration of this Public User Identity with this Private User Identity. - If a Private User Identity is absent in the request, if the Public User Identity is currently registered with more than one Private User Identity, the HSS shall stop processing this request and shall set the Result-Code to DIAMETER_MISSING_AVP. - if the registration state of the Public Identity is Unregistered, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity. In case of ADMINISTRATIVE_DEREGISTRATION, if SAR-Flags AVP includes a P-CSCF-Restoration-Indication, the HSS or combined HSS-UDM supporting the P-CSCF-Restoration-mechanism feature shall send a P-CSCF restoration indication to the serving nodes where the IMSI associated to the received Private Identity is registered, i.e. SGSN and/or MME, using S6a/S6d IDR/IDA or Gr ISD request/answer as described in TSÊ23.380Ê[19] clauseÊ5.4, and SMF and/or AMF, using the Nudm_UECM_P-CSCF-RestorationNotification service operation as described in TSÊ23.380Ê[19] clauseÊ5.8.4. The Result-Code shall be set to DIAMETER_SUCCESS - If it indicates TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or USER_DEREGISTRATION_STORE_SERVER_NAME the HSS decides whether to keep the S-CSCF name associated to the Private User Identity stored or not for all the Public User Identities that the S-CSCF indicated in the request. If no Public User Identity is present in the request, the Private User Identity shall be present."
"- If the HSS decides to keep the S-CSCF name stored the HSS shall keep the S-CSCF name stored for all the Public User Identities associated to the Private User Identity. The Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall check if each Public User Identity in the request is currently registered with one or more Private User Identities. If the request did not contain Public User Identities the HSS shall check if each Public User Identity associated with the Private User Identity in the request is currently registered with one or more Private User Identities. For each Public User Identity;- - If only one Private User Identity associated with the Public User Identity is currently registered with the Public User Identity, the HSS shall set the registration state of the Public User Identity to Unregistered and clear any S-CSCF Restoration Information associated with the Public User Identity - If more than one Private User Identity that shares that Public User Identity is currently registered with the Public User Identity the HSS shall keep the registration state of the Public User Identity as Registered. The HSS shall remove any S-CSCF Restoration Information associated to the registration of this Public User Identity with the Private User Identity in the request. - If the HSS decides not to keep the S-CSCF name the Experimental-Result shall be set to DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED. The HSS shall check if each Public User Identity in the request is currently registered with one or more Private User Identities. If the request did not contain Public User Identities the HSS shall check if each Public User Identity associated with the Private User Identity in the request is currently registered with one or more Private User Identities. For each Public User Identity;- - If only one Private User Identity associated with the Public User Identity is currently registered with the Public User Identity, the HSS shall set the registration state of the Public User Identity to Not Registered and clear the S-CSCF name associated with Public User Identity. - If more than one Private User Identity that shares that Public User Identity is currently registered with the Public User Identity the HSS shall keep the registration state of the Public User Identity as Registered. - If it indicates NO_ASSIGNMENT, the HSS checks whether the Public Identity is assigned for the S-CSCF requesting the data. If the requesting S-CSCF is not the same as the assigned S-CSCF and the S-CSCF reassignment pending flag is not set, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY, otherwise the HSS shall download the relevant user information and the Result-Code shall be set to DIAMETER_SUCCESS. If relevant S-CSCF Restoration Information is stored in the HSS and IMS Restoration Procedures are supported, it shall be added to the answer message. If there is S-CSCF Restoration Information associated with several Private User Identities, the HSS shall include all the S-CSCF Restoration Information groups in the response. If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription. NOTE 6: the check of the S-CSCF reassignment pending flag is needed since an S-CSCF supporting restoration procedures can receive a user initiated de-registration for a Public Identity for which it does not have any registration data (see TSÊ23.380Ê[19]). In such case, the S-CSCF indicates NO_ASSIGNMENT in Server-Assignment-Type to retrieve any possible restoration information from the HSS. - If it indicates AUTHENTICATION_FAILURE (e.g. there is a mismatch in IP-address secure binding information) or AUTHENTICATION_TIMEOUT (e.g. no response to Digest challenge), the HSS shall keep the registration state of the Public User Identity. The HSS shall check the registration state for the Public User Identity in the request and only if the registration state of the Public User Identity is Not Registered, the HSS shall clear the S-CSCF name associated with the Public User Identity. If the Public User Identity's authentication pending flag which is specific for the Private User Identity is set, the HSS shall clear it. The Result-Code shall be set to DIAMETER_SUCCESS. If the HSS cannot fulfil the received request, e.g. due to database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. The HSS shall not modify any registration state nor download any Public Identity information to the S-CSCF. See clauseÊ8.1.2 and 8.1.3 for the description of the handling of the error situations: reception of an S-CSCF name different from the one stored in the HSS and reception of a Server-Assignment-Type value not compatible with the registration state of the Public Identity. 6.1.3 Network initiated de-registration by the HSS, administrative In case of network initiated de-registration of by the HSS, the HSS change the state of the Public Identities to Not Registered and send a notification to the S-CSCF indicating the identities that shall be de-registered. The procedure is invoked by the HSS, corresponds to the functional level operation Cx-Deregister (see TSÊ23.228Ê[1]). This procedure is mapped to the commands Registration-Termination-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.1.3.1 and 6.1.3.2 describe the involved information elements. Table 6.1.3.1: Network Initiated Deregistration by HSS request Information element name Mapping to Diameter AVP Cat. Description Public User Identity / Public Service Identity (See 7.2 and 7.2a) Public-Identity C It contains the list of Public Identities that are de-registered, in the form of SIP URL or TEL URL. Public-Identity AVP shall be present if the de-registration reason code is NEW_SERVER_ASSIGNED. It may be present with the other reason codes. Private User Identity / Private Service Identity (See 7.3 and 7.3a) User-Name M It contains the Private Identity in the form of a NAI. The HSS shall always send a Private Identity that is known to the S-CSCF based on an earlier SAR/SAA procedure. Reason for de-registration (See 7.11) Deregistration-Reason M The HSS shall send to the S-CSCF a reason for the de-registration. The de-registration reason is composed of two parts: one textual message (if available) that is intended to be forwarded to the user that is de-registered, and one reason code (see 3GPPÊTSÊ29.229Ê[5]) that determines the behaviour of the S-CSCFÊ Routing Information (See 7.13) Destination-Host M It contains the name of the S-CSCF which originated the last update of the name of the multimedia server stored in the HSS for a given IMS Subscription. The address of the S-CSCF is the same as the Origin-Host AVP in the message sent from the S-CSCF. Associated Private Identities Associated-Identities O This AVP contains Private Identities, which belong to the same IMS subscription as the Private Identity in the User-Name AVP and should be de-registered together with that one. If the IMS subscription contains only a single Private Identity, this AVP shall not be present. RTR Flags (See 7.30) RTR-Flags O This information element contains a bit mask. See 7.30 for the meaning of the bits. Table 6.1.3.2: Network Initiated Deregistration by HSS response Information element name Mapping to Diameter AVP Cat. Description Result (See 7.6) Result-Code / Experimental-Result M This information element indicates the result of de-registration. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. Associated Private Identities Associated-Identities C This AVP shall be present if the S-CSCF de-registered more than one Private Identity with the request. It contains all Private Identities that have been deregistered together with the one in the User-Name AVP of the request. Identities with Emergency Registration (See 7.25) Identity-with-Emergency-Registration C This information element indicates a list of pairs of private and public user identities which have not been de-registered due to emergency registration. 6.1.3.1 Detailed behaviour The HSS shall de-register the affected identities and invoke this procedure to inform the S-CSCF. The S-CSCF shall remove all the information stored in the S-CSCF for the affected identities. The HSS may de-register: - One Public Identity or a list of Public Identities. HSS may include all Public User Identities associated with the User-Name AVP to the request. This option is applicable with all reason codes. - One or more Private Identities of the IMS Subscription with all associated Public Identities. No Public-Identity AVPs shall be present in this case. This option is applicable with reason codes PERMANENT_TERMINATION, SERVER_CHANGE, and REMOVE_S-CSCF. - All Public Service Identities that match a Wildcarded Public Service Identity. In this case the HSS may send one of the Public Service Identities that was received in the Server Assignment Request for that Wildcarded Public Service Identity and the associated Private Service Identity. - A Wildcarded Public User Identity. In this case the HSS shall send a distinct Public User Identity that belongs to the same implicit registration set as the Wildcarded Public User Identity and the associated Private User Identity. The HSS shall send in the Deregistration-Reason AVP the reason for the de-registration, composed by a textual message (if available) aimed for the user and a reason code that determines the action the S-CSCF has to perform. The possible reason codes are: - PERMANENT_TERMINATION: The HSS indicates to the S-CSCF that the S-CSCF will no longer be assigned to the Public Identity and associated implicitly registered/unregistered Public Identities (if any) for the Private Identity(ies) indicated in the request (e.g. due to an IMS subscription cancellation, or modification, or a removal of IP-address secure binding information when GIBA is used). This reason also indicates that no other S-CSCF can be assigned. The HSS shall check the registration state of the Public Identities. If no Public Identities are involved, the HSS shall check the registration state of the Public Identities associated with the Private User Identity identified. For each Public Identity: - If the registration state of the Public Identity is Registered, the HSS shall check if the Public User Identity is currently registered with one or more Private User Identities. - If the Public User Identity is currently registered with only one Private User Identity, the HSS shall check whether the Public User Identity is included in the information element Identities with Emergency Registrations returned by S-CSCF in the response. - If included, the HSS shall keep the S-CSCF name associated with the Public User Identity and set the registration state of the Public User Identity to Unregistered. - If not included, the HSS shall clear the S-CSCF name associated with the Public User Identity, and set the registration state of the Public User Identity to Not Registered The S-CSCF initiates the de-registration of the Public User Identity unless it is emergency registered. - If the Public User Identity is currently registered with more than one Private User Identity, the HSS shall keep the registration state of the Public User Identity as Registered and retain the S-CSCF name associated with the Public User Identity. The S-CSCF initiates the de-registration of the Public User Identity unless it is emergency registered. - If the registration state of the Public Identity is Unregistered, the HSS shall check whether this Public User Identity is included in the information element Identities with Emergency Registrations returned by S-CSCF in the response. - If included, the HSS shall keep the S-CSCF name associated with the Public User Identity. - If not included, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity. - NEW_SERVER_ASSIGNED: The HSS indicates to the S-CSCF that a new S-CSCF has been allocated to the IMS Subscription e.g. because the previous assigned S-CSCF was unavailable during a registration procedure. The S-CSCF shall remove all information for all of the Public Identities indicated in the request. - SERVER_CHANGE: The HSS indicates to the S-CSCF that the de-registration is requested to force the selection of new S-CSCF to assign to the IMS Subscription (e.g. when the S-CSCF capabilities are changed in the HSS or when the S-CSCF indicates that it has not enough memory for the updated User Profile). The HSS shall set the registration state to ""Not Registered"" and clear the S-CSCF name for all of the Public Identities affected by the request. If the S-CSCF does not indicate in the response all the Private Identities that were in the request, the HSS shall repeat this request for each of the remaining Private Identities in the IMS Subscription that are known to the S-CSCF. The S-CSCF should start the network initiated de-registration towards the user, i.e. all registrations within the IMS Subscription are de-registered and the user is asked to re-register to all existing registrations. - REMOVE_S-CSCF: The HSS indicates to the S-CSCF that the S-CSCF will no longer be assigned to an unregistered Public Identity(ies) (i.e registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) for a given IMS Subscription. The HSS shall check if an emergency registration exists in the S-CSCF, checking for each Public Identity contained in the request whether it is present in the information element Identities with Emergency Registrations returned by S-CSCF. - If an emergency registration does not exist in S-CSCF, for each Public Identity contained within the request, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity. The S-CSCF shall remove all information related to the Public User Identity contained within the request. - If an emergency registration exists in S-CSCF for one or more Public User Identities contained in the request, the S-CSCF should include the corresponding Private Identity /Public User Identity pairs in the information element Identities with Emergency Registrations in the answer. The HSS, when receiving such an answer, shall not change the registration state of the Public User Identities present in the information element Identities with Emergency Registrations and shall keep unchanged the S-CSCF name associated with these Public User Identities. Public Identities which are emergency registered in the S-CSCF shall not be de-registered when a Cx-Deregistration request with a -reason code of PERMANENT_TERMINATION or REMOVE_S-CSCF is received from the HSS. In this case - if all to be de-registered identities are emergency registered, a Result-Code set to DIAMETER_UNABLE_TO_COMPLY and a list of Private / Public Identity pairs which are emergency registered shall be returned to the HSS - if a proper subset of the to be de-registered identities are emergency registered, a Result-Code of DIAMETER_LIMITED_SUCCESS and a list of Private Identity / Public Identity pairs which are emergency registered shall be returned to the HSS. NOTE 1: If the Public Identity that is emergency registered has normal registration as well, then for the normal registration the S-CSCF will perform the detailed de-registration procedures towards the UE for each reason code as described in TSÊ24.229Ê[8]. NOTE 2: It is assumed that Public Identities which are implicitly registered along with an emergency registration are also emergency registered. The detailed de-registration procedures performed by the S-CSCF are described in TSÊ24.229Ê[8]. 6.1.4 User location query This procedure is used between the I-CSCF and the HSS to obtain the name of the S-CSCF assigned to a Public Identity, or the name of the AS hosting a PSI for direct routing. The procedure is invoked by the I-CSCF, is performed per Public Identity, and corresponds to the functional level operation Cx-Location-Query (see TSÊ23.228Ê[1]). This procedure is mapped to the commands Location Info Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.1.4.1 and 6.1.4.2 detail the involved information elements. Table 6.1.4.1: User Location query Information element name Mapping to Diameter AVP Cat. Description Public User Identity / Public Service Identity (See 7.2 and 7.2a) Public-Identity M Public Identity Routing information (See 7.13) Destination-Host, Destination-Realm C If the I-CSCF knows HSS name Destination-Host AVP shall be present in the command. Otherwise, only Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the I-CSCF. Originating Request (See 7.18) Originating-Request O It indicates that the request is related to an originating SIP message. Type of Authorization (See 7.14) User-Authorization-Type C This information element shall be present and set to REGISTRATION_AND_CAPABILITIES by the I-CSCF if IMS Restoration Procedures are supported and the S-CSCF currently assigned to the Public User Identity in the HSS cannot be contacted. Session Priority (See 7.24) Session-Priority O This information element, if present, shall indicate the session's priority to the HSS. Table 6.1.4.2: User Location response Information element name Mapping to Diameter AVP Cat. Description Result (See 7.6) Result-Code / Experimental-Result M Result of the operation. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. S-CSCF Name / AS name (See 7.4 and 7.4a) Server-Name C Name of the assigned S-CSCF for basic IMS routing or the name of the AS for direct routing. S-CSCF capabilities (See 7.5) Server-Capabilities O It contains the information to help the I-CSCF in the selection of the S-CSCF. Wildcarded Public Identity (See 7.2b) Wildcarded-Public-Identity O If the requests refers to a Wildcarded PSI or Wildcarded Public User Identity (the Public Identity in the request matches a Wildcarded PSI or Wildcarded Public User Identity in the HSS), the HSS shall include the corresponding Wildcarded Public Identity in this information element. The matching of distinct Public Identies takes precedence over the matching of wildcarded public identities. LIA Flags (See 7.27) LIA-Flags O This information element contains a bit mask. See 7.27 for the meaning of the bits. 6.1.4.1 Detailed behaviour The HSS may prioritise the received request message according to priority level received within the Session-Priority AVP. NOTE 1: Refer to Annex J for HSS procedures associated with the handling of both the Session-Priority AVP and DRMP AVP received in the request message. The HSS shall, in the following order (if an error occurs in any of the ste The HSS shall, in the following order (if an error occurs in any of the steps the HSS shall stop processing and return the corresponding error code, see TSÊ29.229Ê[5]): 1. Check that the Public Identity is known. If not the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 2. Check the type of the Public Identity contained in the request: - If this is a Public User Identity, continue to step 2a. - If this is a Public Service Identity: - Check if the PSI Activation State for that identity is active. If not, then the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN. - Check if the name of the AS hosting the Public Service Identity is stored in the HSS and that the request does not contain the Originating-Request AVP. - If this is the case, if IMS Restoration Procedures are supported, the HSS shall check if User-Authorization-Type was received in the request, and if the value is REGISTRATION_AND_CAPABILITIES: - If it is, the HSS shall reject the request with Result-Code set to DIAMETER_UNABLE_TO_COMPLY. - Otherwise, the HSS shall return the AS name and the Result-Code AVP shall be set to DIAMETER_SUCCESS. HSS may set PSI Direct Routing Indication bit in LIA-Flags AVP, then I-CSCF shall not perform IMS Restoration Procedures (see clauseÊ4.3.3 in TSÊ23.380Ê[19]). - Otherwise, continue to step 2a. 2a. If IMS Restoration procedures are supported, the HSS shall check if User-Authorization-Type was received in the request, and if the value is REGISTRATION_AND_CAPABILITIES: - If it is, then the HSS may return the Server-Capabilities AVP. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. If Server-Capabilities AVP is absent, it indicates to the I-CSCF that it can select any available S-CSCF. Also the HSS shall set the S-CSCF reassignment pending flag and allow overwriting of the S-CSCF name in the next SAR request, which enables the I-CSCF to select an S-CSCF. The Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing. - Otherwise, continue to step 3. 3. Check the state of the Public Identity received in the request, and where necessary, check if the Public Identity has terminating services related to the unregistered state. - If it is registered, the HSS shall return the stored S-CSCF name. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code AVP shall be set to DIAMETER_SUCCESS. - If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) the HSS shall return the S-CSCF name assigned for that Public Identity. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code shall be set to DIAMETER_SUCCESS. - If it is not registered, but either it has terminating services related to unregistered state or the request contains the Originating-Request AVP, the HSS shall check if there is at least one Public Identity within the IMS Subscription with an S-CSCF name assigned: - If this is the case the HSS shall return the S-CSCF name assigned for that Public Identity. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code shall be set to DIAMETER_SUCCESS. - If there is not any S-CSCF name assigned to a Public Identity within the IMS Subscription, the HSS may return information about the required S-CSCF capabilities, which enables the I-CSCF to select an S-CSCF. The Server-Capabilities AVP may be present. The HSS shall send the same server capability set that is sent in the user registration status response during the registration. If Server-Capabilities AVP is not present, the I-CSCF shall understand that any S-CSCF is suitable for the IMS Subscription. The Server-Name AVP shall not be present. The Experimental-Result-Code shall be set to DIAMETER_UNREGISTERED_SERVICE. - If it is not registered or unregistered, and the Public Identity has no terminating services related to the unregistered state and the request does not contain the Originating-Request AVP, the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED. If the HSS cannot fulfil the received request, e.g. due to database error, it shall set Result-Code to DIAMETER_UNABLE_TO_COMPLY. No S-CSCF name or S-CSCF capabilities shall be present in the response. 6.2 User data handling procedures 6.2.1 User Profile download As part of the registration procedure ( TSÊ23.228Ê[1]) S-CSCF obtains user data and service related information by means of the Cx-Put Resp operation (see 6.1.2). 6.2.2 HSS initiated update of User Information This procedure is initiated by the HSS to update at least one of the following user information in S-CSCF: - User profile information and/or - Charging information and/or - Allowed WAF and/or WWSF Identities and/or - SIP Digest authentication information in the S-CSCF. This procedure shall not be used by the HSS to add, delete, or update the value of the IMSI. This procedure corresponds to the functional level operation Cx-Update_Subscr_Data (see TSÊ23.228Ê[1]). This procedure is mapped to the commands Push-Profile-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.2.2.1 and 6.2.2.2 describe the involved information elements. Table 6.2.2.1: User Profile Update request Information element name Mapping to Diameter AVP Cat. Description Private User Identity / Private Service Identity (See 7.3 and 7.3a) User-Name M Private Identity. The HSS shall always send a Private Identity that is known to the S-CSCF based on an earlier SAR/SAA procedure. User profile (See 7.7) User-Data C Updated user profile (see clauses 6.5.2.1 and 6.6.1), with the format defined in clauseÊ7.7. It shall be present if the user profile is changed in the HSS. If the User-Data AVP is not present, the SIP-Auth-Data-Item or Charging-Information AVP or Allowed-WAF-WWSF-Identities AVP shall be present. Authentication Data (See 7.9) SIP-Auth-Data-Item C SIP Digest authentication information. It shall be present if the used authentication scheme is SIP Digest and when password change has occurred in the HSS. If the SIP-Auth-Data-Item AVP is not present, the Charging-Information or User-Data AVP or Allowed-WAF-WWSF-Identities AVP shall be present. See Table 6.3.6 for the contents of this information element. Charging Information (See 7.12) Charging-Information C Addresses of the charging functions. It shall be present if the charging addresses are changed in the HSS. If the Charging-Information AVP is not present, the SIP-Auth-Data-Item or User-Data AVP or Allowed-WAF-WWSF-Identities AVP shall be present. When this parameter is included, either the Primary-Charging-Collection-Function-Name AVP or the Primary-Event-Charging-Function-Name AVP shall be included. All other charging information shall be included if it is available. Routing Information (See 7.13) Destination-Host M It contains the name of the S-CSCF which originated the last update of the name of the multimedia server stored in the HSS for a given IMS Subscription. The address of the S-CSCF is the same as the Origin-Host AVP in the message sent from the S-CSCF. Allowed WAF and/or WWSF Identities (See 7.29) Allowed-WAF-WWSF-Identities C Addresses of the WAFs and/or WWSFs the subscription is allowing to use. It shall be present if the allowed WAF and/or WWSF identities are changed in the HSS. Table 6.2.2.2: User Profile Update response Information element name Mapping to Diameter AVP Cat. Description Result (See 7.6) Result-Code / Experimental-Result M This information element indicates the result of the update of User Profile in the S-CSCF. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. 6.2.2.1 Detailed behaviour The HSS shall make use of this procedure to update the relevant user information to the S-CSCF. See clauses 6.5.2.1 and 6.6.1 for the rules of user profile updating. See clauseÊ6.5.2.3 for the rules of Charging Information update. See clauseÊ6.5.2.4 for the rules of SIP Digest Authentication Data update. See clauseÊ6.5.2.5 for the rules of Allowed WAF and/or WWSF Identities update. If there are multiple registered Private User Identities associated to the Public User Identity in the HSS, the HSS shall send only single request and select arbitrarily one of the Private User Identities and put it into the request. For updates of the profile of a Wildcarded Public Identity, the HSS shall send only one single request. That request shall contain the Wildcarded Public Identity. The SIP-Auth-Data-Item AVP and/or Charging-Information AVP and/or the User-Data AVP shall be present in the request. If the User-Data AVP is present in the request, the S-CSCF shall overwrite, for the Public Identities indicated in the User profile included in the request, current information with the information received from the HSS, except in the error situations detailed in table 6.2.2.1.1. If the Charging-Information AVP is present in the request, the S-CSCF shall replace the existing charging information with the information received from the HSS. The SIP-Auth-Data-Item AVP shall be present if the command is sent in order to update SIP Digest authentication information due to a password change. If the S-CSCF receives data that it can not recognise, unsupported user data in a part of the request where it may not be ignored or more data than it can accept, it shall return the corresponding error code to the HSS as indicated in table 6.2.2.1.1. The S-CSCF shall not overwrite the data that it already has to give service to the IMS Subscription. The HSS shall initiate a network-initiated de-registration procedure towards the S-CSCF with Deregistration-Reason set to SERVER_CHANGE, which will trigger the assignment of a new S-CSCF. If the HSS receives DIAMETER_ERROR_USER_UNKNOWN from the S-CSCF in the Push-Profile-Answer, then the HSS shall re-send the request using another arbitrarily selected registered Private Identity (if any). If restoration procedures are not supported, the HSS shall set the unknown Private User Identity's registration status to ""not registered""; this will allow the synchronization of the registration status in HSS and S-CSCF. NOTE: If restoration procedures are supported, restoration procedures will ensure synchronization of the registration status in HSS and S-CSCF, i.e. the S-CSCFÊcan either immediately retrieve the S-CSCF restoration information for the registered Public User Identity (sending SAR with Server Assignment Type set to NO_ASSIGNMENT), or wait for reception of a SIP request. Table 6.2.2.1.1 details the valid result codes that the S-CSCF can return in the response. Table 6.2.2.1.1: User information update response valid result codes Result-Code AVP value Condition DIAMETER_SUCCESS The request succeeded. DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA The request failed. The S-CSCF informs the HSS that the received user information contained information, which was not recognised or supported by the S-CSCF due to unsupported S-CSCF capabilities. DIAMETER_ERROR_USER_UNKNOWN The request failed because the Private Identity is not found in S-CSCF. DIAMETER_ERROR_TOO_MUCH_DATA The request failed. The S-CSCF informs to the HSS that it tried to push too much data into the S-CSCF. DIAMETER_UNABLE_TO_COMPLY The request failed. 6.3 Authentication procedures This procedure is used between the S-CSCF and the HSS to exchange information to support the authentication between the end user and the home IMS network. The procedure is invoked by the S-CSCF, corresponds to the combination of the operations Cx-AV-Req and Cx-AV-Req-Resp (see TSÊ33.203Ê[3]) and is used: - To retrieve authentication vectors from the HSS. - To resolve synchronization failures between the sequence numbers in the UE and the HSS for authentication schemes that support this capability (e.g. IMS-AKA). - To promote the result of the NASS-level authentication to the IMS level. - To retrieve the IP-address secure binding information for GPRS-IMS-Bundled Authentication (GIBA) from the HSS. This procedure is mapped to the commands Multimedia-Auth-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.3.1 through 6.3.7 detail the involved information elements. Table 6.3.1: Authentication Request Information element name Mapping to Diameter AVP Cat. Description Public User Identity (See 7.2) Public-Identity M This information element contains the Distinct Public User Identity of the user Private User Identity (See 7.3) User-Name M This information element contains the Private User Identity Number Authentication Items (See 7.10) SIP-Number-Auth-Items M This information element indicates the number of authentication vectors requested. Certain authentication schemes do not support more than one set of authentication vectors (e.g. SIP Digest, GIBA). Authentication Data (See 7.9) SIP-Auth-Data-Item M See Table 6.3.2 for the contents of this information element. S-CSCF Name (See 7.4) Server-Name M This information element contains the name (SIP URL) of the S-CSCF. Routing Information (See 7.13) Destination-Host C If the S-CSCF knows the HSS name this AVP shall be present. This information is available if the MAR belongs to an already existing registration, e.g. in case of the re-registration, where the HSS name is stored in the S-CSCF. The HSS name is obtained from the Origin-Host AVP, which is received from the HSS, e.g. included in the MAA command. This information may not be available if the command is sent in case of the initial registration. In this case the Destination-Host AVP is not present and the command is routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the client. Table 6.3.2: Authentication Data content in Authentication Request Information element name Mapping to Diameter AVP Cat. Description Authentication Scheme (See 7.9.2) SIP-Authentication-Scheme M This information element indicates the authentication scheme. See 3GPPÊTSÊ29.229Ê[5] for a list of values Authentication Context (See 7.9.7) SIP-Authentication-Context C This information element shall contain authentication-related information relevant for performing the authentication. It shall be absent for IMS-AKA authentication schemes. Authorization Information (See 7.9.4) SIP-Authorization C This information element shall only be present for a request due to an IMS-AKA synchronization failure. If present, only IMS-AKA authentication schemes are allowed. Table 6.3.3: Void Table 6.3.4: Authentication Request Response Information element name Mapping to Diameter AVP Cat. Description User Identity (See 7.2) Public-Identity C Public User Identity. It shall be present when the result is DIAMETER_SUCCESS. Private User Identity (See 7.3) User-Name C Private User Identity. It shall be present when the result is DIAMETER_SUCCESS. Number Authentication Items (See 7.10) SIP-Number-Auth-Items C This information element indicates the number of authentication vectors delivered in the Authentication Data information element. It shall be present when the result is DIAMETER_SUCCESS. For SIP Digest, NASS Bundled authentication and GIBA this AVP shall be set to a value of 1. Authentication Data (See 7.9) SIP-Auth-Data-Item C If the SIP-Number-Auth-Items AVP is equal to zero or it is not present, then this information element shall not be present. See Table 6.3.5 for the contents of this information element. Result (See 7.6) Result-Code / Experimental-Result M This information element indicates the result of the operation. It shall be mapped to Result-Code AVP for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). It shall be mapped to Experimental-Result AVP for Cx/Dx errors. This information element is mapped to a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. Table 6.3.5: Authentication Data information element content in Authentication Request Response Information element name Mapping to Diameter AVP Cat. Description Item Number (See 7.9.1) SIP-Item-Number C This information element shall only be present for IMS-AKA authentication schemes. This information element shall be present when there are multiple occurrences of the Authentication Data information element in the Authentication Request Response, and the order in which they should be processed is significant. In this scenario, Authentication Data information elements with a low Item Number information element value should be processed before Authentication Data information elements with a high Item Number information element value. Authentication Scheme (See 7.9.2) SIP-Authentication-Scheme M This information element indicates the authentication scheme. Authentication Information (See 7.9.3) SIP-Authenticate C This information element shall only be present for IMS-AKA authentication schemes. Authorization Information (See 7.9.4) SIP-Authorization C This information element shall only be present for IMS-AKA authentication schemes. Confidentiality Key (See 7.9.5) Confidentiality-Key C This information element shall be present for IMS AKA authentication schemes. It shall contain the confidentiality key. Integrity Key (See 7.9.6) Integrity-Key C This information element shall only be present for IMS-AKA authentication schemes. This information element shall contain the integrity key. Digest Authenticate (See 7.9.8) SIP-Digest-Authenticate C This information element shall only be present for SIP Digest authentication scheme. See Table 6.3.7 for contents of this grouped AVP. Line Identifier (See 7.9.9) Line-Identifier C This information element shall only be present for NASS Bundled authentication scheme. This information element contains fixed broadband access line identifier associated to the user. This information element can be repeated. Framed IP Address (See 7.9.10) Framed-IP-Address C This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If the IP Address of the User is an IPv4 address, this AVP shall be included. Framed IPv6 Prefix (See 7.9.11) Framed-IPv6-Prefix C This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If the IP Address of the User is an IPv6 address, this AVP shall be included. Framed Interface Id (See 7.9.12) Framed-Interface-Id C This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If and only if the IP Address of the User is an IPv6 address and the Framed-IPv6-Prefix AVP alone is not unique for the user this AVP shall be included. Table 6.3.6: Void Table 6.3.7: Digest Authenticate information element content Ð Response for SIP Digest Information element name Mapping to Diameter AVP Cat. Description Digest Realm (See 7.9.8.1) Digest-Realm M This information element corresponds to the Realm parameter as defined in IETFÊRFCÊ7616Ê[33]. Digest Algorithm (See 7.9.8.3) Digest-Algorithm O This information element contains the algorithm as defined in IETFÊRFCÊ7616Ê[33]. If this information element is present, it shall contain ""MD5"". If neither the Digest Algorithm information element nor the Alternate Digest Algorithm information element are present, then the value ""MD5"" is assumed. (NOTEÊ1) Digest QoP (See 7.9.8.4) Digest-QoP M This information element contains the QoP as defined in IETFÊRFCÊ7616Ê[33]. This information element shall be set to a value of ""auth"" by the HSS. Digest HA1 (See 7.9.8.5) Digest-HA1 M This information element contains the H(A1) for algorithm ""MD5"" as defined in IETFÊRFCÊ7616Ê[33]. (NOTEÊ1) Alternate Digest Algorithm (See 7.9.8.6) Alternate-Digest-Algorithm O This information element contains the algorithm as defined in IETFÊRFCÊ7616Ê[33]. (NOTEÊ2) Alternate Digest HA1 (See 7.9.8.6) Alternate-Digest-HA1 O This information element contains the H(A1), as defined in IETFÊRFCÊ7616Ê[33]. (NOTEÊ2) NOTEÊ1: The MD5 algorithm is only supported for backward compatibility and may only be provided within the Digest Algorithm information element. NOTEÊ2: If the Alternate Digest HA1 information element is present, the Digest HA1 information element shall also be present and the Digest HA1 information element shall contain the MD5 hash. The algorithm of the Alternate Digest HA1 information element shall be determined by the Alternate Digest Algorithm information element."
"Table 6.3.8: Void Table 6.3.9: Void 6.3.1 Detailed behaviour The HSS shall, in the following order (in case of an error in any of the steps the HSS shall stop processing and return the corresponding error code, see TSÊ29.229Ê[5]): 1. Check that the Private User Identity and the Public User Identity exist in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 2. Check that the Public User Identity matches a distinct Public User Identity in the HSS. If it doesn't, the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 3. Check whether the Private and Public User Identities in the request are associated in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH. 4. Check the authentication scheme indicated in the request, and - if it is ""Unknown"", check the authentication scheme stored in HSS. If it is neither NASS-Bundled authentication nor SIP Digest authentication, Experimental-Result-Code shall be set to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED. - if not, check that the authentication scheme indicated in the request is supported. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED. This step is only applicable for IMS-AKA authentication. If the request indicates there is a synchronization failure, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS: - If they are identical the HSS shall process AUTS as described in TSÊ33.203Ê[3] and return the requested authentication information. The Result-Code shall be set to DIAMETER_SUCCESS. 5. Check the registration status of the Public User Identity received in the request: - If it is registered, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS: - If they are different, the HSS shall overwrite the S-CSCF name. If IMS restoration procedures are supported and the S-CSCF reassignment pending flag is set, the HSS shall reset the flag and keep the S-CSCF restoration information associated with the Public User Identity. The HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity's authentication pending flag which is specific to the Private User Identity received in the request. The Result-Code shall be set to DIAMETER_SUCCESS. - If they are identical, the HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. The Result-Code shall be set to DIAMETER_SUCCESS. - If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored) or not registered, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS: - If they are different or if there is no S-CSCF name stored in the HSS for any Public User Identity of the IMS subscription, the HSS shall store the S-CSCF name. The HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity's authentication pending flag which is specific to the Private User Identity which was received in the request. The Result-Code shall be set to DIAMETER_SUCCESS. - If they are identical, the HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity's authentication pending flag which is specific to the Private User Identity that was received in the request. The Result-Code shall be set to DIAMETER_SUCCESS. Exceptions to the cases specified here shall be treated by HSS as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY. No authentication information shall be returned. 6.4 User identity to HSS resolution The User identity to HSS resolution mechanism enables the I-CSCF and the S-CSCF to find the identity of the HSS, that holds the subscriber data for a given Public Identity when multiple and separately addressable HSSs have been deployed by the network operator. The resolution mechanism is not required in networks that utilise a single HSS. An example for a single HSS solution is server farm architecture. The resolution mechanism described in TSÊ23.228Ê[1] shall use a Subscription Locator Function (SLF) or a Diameter Proxy Agent. The I-CSCF and the S-CSCF accesses the SLF via the Dx interface. The Dx interface shall always be used in conjunction with the Cx interface. The Dx interface shall be based on the Diameter base protocol as specified in IETFÊRFCÊ6733Ê[31]. The SLF functionality shall use the routing mechanism provided by an enhanced Diameter redirect agent. The SLF or the Diameter Proxy Agent shall be able to determine the HSS identity. To get the HSS identity the I-CSCF and the S-CSCF shall send the Cx request normally destined to the HSS to a pre-configured Diameter address/name. - If this Cx Request is received by an SLF (acting as a Diameter redirect agent), the SLF shall determine the HSS identity and sends to the I-CSCF or S-CSCF a notification of redirection towards the HSS identity, in response to the Cx request. Multiple HSS identities may be included in the response, as specified in IETFÊRFCÊ6733Ê[31]. In such a case, the I-CSCF or the S-CSCF shall send the Cx Request to the first HSS identity in the ordered list received in the Cx Response from the SLF. If the I-CSCF or S-CSCF does not receive a successful response to the Cx Request, the I-CSCF or S-CSCF shall send a Cx Request to the next HSS identity in the ordered list. This procedure shall be repeated until a successful response from an HSS is received. - If this Cx Request is received by the Diameter Proxy Agent, the Diameter Proxy Agent shall determine the HSS identity based on the provided user identity and - if the Diameter load control mechanism is supported (see IETFÊIETFÊRFCÊ8583Ê[29]) - optionally also based on previously received load values from Load AVPs of type HOST. The Diameter Proxy Agent shall then forward the Cx request directly to the determined HSS. The I-CSCF and S-CSCF shall determine the HSS identity from the response to the Cx request received from the HSS. While the I-CSCF is stateless, the S-CSCF shall store the HSS identity/name/Realm, as specified in TSÊ23.228Ê[1] and shall use it in further Cx requests associated to the same IMS Public Identity. In networks where the use of the user identity to HSS resolution mechanism is required, each I-CSCF and S-CSCF shall be configured with the address/name of the SLF or the Diameter Proxy Agent to enable use of these resolution mechanisms. 6.5 Implicit registration Implicit registration is the mechanism by which a user is allowed to register simultaneously more than one of his/her Public User Identities. The HSS knows the identities that are to be implicitly registered when it receives the indication of the registration of an individual identity. What follows is an extension of the affected basic procedures. 6.5.1 S-CSCF initiated procedures The result of the S-CSCF initiated procedures affects all the Public User Identities that are configured in the HSS to be in the same implicitly registered Public User Identity set with the targeted individual Public User Identity. Where the S-CSCF initiated procedure affects the Registration state of the targeted Public User Identity, the Registration states of the Public User Identities in the associated implicitly registered Public User Identity set are affected in the same way. 6.5.1.1 Registration The notification of a registration of a Public User Identity implies the registration of the corresponding implicitly registered Public User Identity set. The user information downloaded in the response contains the Public User Identities of the implicitly registered Public User Identity set with the associated service profiles. This allows the S-CSCF to know which Public User Identities belong to the implicitly registered Public User Identity set. The S-CSCF shall take from the set of implicitly registered Public User Identities the first identity which is not barred, and use this as the default Public User Identity. The default Public User Identity shall be a distinct Public User Identity. 6.5.1.2 De-registration The de-registration of a Public User Identity implies the de-registration of the corresponding implicitly registered Public User Identity set, both in the HSS and in the S-CSCF. The S-CSCF shall include in the request a single Public User Identity to deregister all the Public User Identities that belong to the corresponding implicitly registered Public User Identity set. The de-registration of a Private User Identity implies the de-registration of all the corresponding Public User Identities, both in the HSS and in the S-CSCF. 6.5.1.3 Authentication Setting the authentication pending flag for a Public User Identity implies setting the authentication pending flag for each corresponding implicitly registered Public User Identity in the HSS. 6.5.1.4 Downloading the user profile If the S-CSCF requests to download a user profile from HSS, the user profile in the response shall contain the Public User Identities of the corresponding implicitly registered Public User Identity set with the associated service profiles. 6.5.1.5 Initiation of a session to a non-registered user The change of a Public User Identity to the Unregistered state due to the initiation of a session from/to a Public Identity that was in Not Registered state and the opposite change from Unregistered state to Not Registered state implies the same change for all the Public User Identities in the same Implicit Registration Set. 6.5.2 HSS initiated procedures 6.5.2.1 Update of User Profile A request sent by the HSS to update the user profile shall include only the Public User Identities of the implicitly registered Public User Identity set, with the associated service profiles (even if not updated). If other Public User Identities not associated with the implicitly registered Public User Identity set are affected, they shall be downloaded in separate commands. This procedure shall be used by the HSS to add a newly provisioned or Not Registered Public User Identity or Identities to an existing implicitly registered Public User Identity set that is in the state Registered or Unregistered. The added Public User Identity gets the registration state of the set it is added to. The HSS shall use this procedure if a Public User Identity or Identities are removed from the implicitly registered Public User Identity set that is in a state Registered or Unregistered. In practise, this is done by sending a PPR for the set without the removed identities. The S-CSCF shall remove all information stored in the S-CSCF for the removed identities. The HSS shall not use this procedure if there is no Public User Identities left in the implicitly registered Public User Identity set after the removal. In that case HSS shall use the RTR command instead. The HSS shall not use this procedure to change the default Public User Identity of the implicitly registered Public User Identity set that is in a state Registered. In that case the HSS shall use the RTR command to de-register the Public User Identity set. When a change of the Reference Location Information occurs (e.g.. a change of authorization), the HSS may use a network initiated de-registration instead of this procedure, and may indicate to the S-CSCF that the de-registration is sent due to change of Reference Location Information. Moving of a Public User Identity or Identities from one implicitly registered Public User Identity set to another set shall be done in two steps: First the identity or identities are removed from the ""old"" set as described above, then the identity or identities are added to the ""new"" set as described above. 6.5.2.2 De-registration A request sent by the HSS to de-register any of the identities included in an implicitly registered Public User Identity set shall affect all the Public User Identities of the deregistered set. The de-registration of a Private User Identity implies the de-registration of all the corresponding Public User Identities, both in the HSS and in the S-CSCF. 6.5.2.3 Update of the Charging information A request sent by the HSS to update the charging information shall include the Private User Identity for whom the charging information changed. If corresponding Public Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) and charging information is changed, the HSS should immediately push this information to the S-CSCF. 6.5.2.4 Update of the SIP Digest Authentication Data A request sent by the HSS to update the authentication data shall include the Private User Identity for whom the authentication data changed. If corresponding Public Identity is registered and authentication data is changed, the HSS should immediately push this information to the S-CSCF. If corresponding Public Identity is either not registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored), authentication pending flag is set and authentication data is changed, the HSS should immediately push this information to the S-CSCF. 6.5.2.5 Update of the Allowed WAF and/or WWSF Identities A request sent by the HSS to update the WAF and/or WWSF identities allowed for the subscription shall include the Private User Identity for whom this information changed. If corresponding Public Identity is registered and allowed WAF and/or WWSF identities are changed, the HSS should immediately push this information to the S-CSCF. 6.6 Download of the Relevant User Profile and Charging Information and Allowed WAF and/or WWSF Identities The download of the relevant user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities from the HSS to the S-CSCF depends on whether the user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities are already stored in the S-CSCF. If the SiFC feature is supported by the HSS and S-CSCF, the HSS shall download the identifiers of the shared iFC sets. If either the HSS or the S-CSCF does not support the SiFC feature, the HSS shall download the complete iFCs, and SiFC identifiers shall not be downloaded by the HSS. The SiFC feature is defined in TSÊ29.229Ê[5]. If User-Data-Already-Available is set to USER_DATA_NOT_AVAILABLE the HSS shall download the requested user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities. If the Public User Identity in the request is included in an implicitly registered Public User Identity set, the HSS shall include in the response the service profiles associated with all Public User Identities within the implicitly registered Public User Identity set to which the received Public User Identity belongs. If User-Data-Already-Available is set to USER_DATA_ALREADY_AVAILABLE, the HSS should not return any user profile or charging information data or allowed WAF and/or WWSF identities. The HSS may override User-Data-Already-Available set to USER_DATA_ALREADY_AVAILABLE and download the user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities. 6.6.1 HSS initiated update of User Profile The request to update the user profile in the S-CSCF includes only the Public User Identities of the implicitly registered Public User Identity set with the associated service profiles. See 6.5.2.1. If the Public Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) and there are changes in the user profile, the HSS should immediately push the complete user profile to the S-CSCF. 6.6.2 S-CSCF operation At deregistration of a Public User Identity, the S-CSCF shall store the user information if it sends Server-Assignment-Request command including Server-Assignment-Type AVP set to value USER_DEREGISTRATION_STORE_SERVER_NAME or TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME and the HSS responds with DIAMETER_SUCCESS. Otherwise the S-CSCF shall not keep user information. 6.7 S-CSCF Assignment The list of mandatory and optional capabilities received by an I-CSCF from the HSS allows operators to distribute users between S-CSCFs, depending on the different capabilities (e.g. features, role, geographical location) that each S-CSCF may have. Alternatively, an operator has the possibility to steer users to certain S-CSCFs. The operator shall define (possibly based on the functionality offered by each S-CSCF installed in the network) the exact meaning of the S-CSCF mandatory and optional capabilities available in his network. It is an operator task to allocate a unique value toÊrepresent a singleÊcapability (e.g. support of ""wildcarded PSI"") orÊa set of capabilities (e.g. support of ""alias"" and ""Shared IFC sets"" and ""wildcarded PSI"") and to use these values to identify capabilities that are mandatory and/or optional to support for a given subscription. It is a configuration task for the operator to ensure that the I-CSCF has a correct record of the capabily values received from the HSS for each S-CSCF available in his network. The I-CSCF and the HSS do not need to know the semantic of these values. This semantic is exclusively an operator issue. As a first choice, the I-CSCF shall select an S-CSCF that has all the mandatory and optional capabilities for the user. Only if that is not possible shall the I-CSCF apply a 'best-fit' algorithm. If more than one S-CSCF is identified that supports all mandatory capabilities the I-CSCF may then consider optional capabilities in selecting a specific S-CSCF. The 'best-fit' algorithm is implementation dependent and out of the scope of this specification. It is the responsibility of the operator to ensure that there are S-CSCFs which have mandatory capabilities indicated by the HSS for any given user. However, configuration errors may occur. If such errors occur and they prevent the I-CSCF from selecting an S-CSCF which meets the mandatory capabilities indicated by the HSS, the I-CSCF shall inform the operator via the O&M subsystem. As an alternative to selecting an S-CSCF based on the list of capabilities received from the HSS, it is possible to steer users to certain S-CSCFs. To do this, the operator may include one or more S-CSCF names as part of the capabilities of the user profile. The reason for the selection (e.g. all the users belonging to the same company/group could be in the same S-CSCF to implement a VPN service) and the method of selection are operator issues and out of the scope of this specification. If this alternative is chosen, the HSS shall include Server-Name AVPs in the Server-Capabilities AVP and should not include Mandatory-Capability AVPs or Optional-Capability AVPs in the Server-Capabilities AVP, and the I-CSCF when receiving Server-Name AVPs within the Server-Capabilities AVP shall discard any Mandatory-Capability AVP and any Optional-Capability AVP received within the Server-Capabilities AVP. The following table is a guideline for operators that records S-CSCF capabilities that need to be supported by an S-CSCF in order to serve a user or a service (identified by a Public User Identity or Public Service Identity), that cannot be served by an S-CSCF which is only compliant to a previous 3GPP release. Table 6.7: Guidelines for S-CSCF Capabilities Capability Mandatory or Optional (NOTE 1) Description Support of ""Wildcarded PSI"" M This capability indicates that the assigned S-CSCF shall support the handling of Wildcarded PSIs. Support of ""OrigUnreg SPT"" M This capability indicates that the assigned S-CSCF shall be able to process iFCs with a Session Case ""Originating_Unregistered"" received from the HSS in the user profile. Support of ""OrigCDIV SPT"" M This capability indicates that the assigned S-CSCF shall be able to process iFCs with a Session Case ""Originating_CDIV"" received from the HSS in the user profile. Support of ""Shared iFC sets"" O This capability indicates that the assigned S-CSCF may support the ""SiFC"" feature defined in the 3GPPÊTSÊ29.229Ê[5]. Support of ""Display Name"" O This capability indicates that the assigned S-CSCF may support the handling of ""Display Name"". The behaviour of the S-CSCF related to this missing data is the same as if the HSS did not send the Display Name. Support of ""Alias"" O This capability indicates that the assigned S-CSCF may support the ""AliasInd"" feature defined in 3GPPÊTSÊ29.229Ê[5]. Support of ""SIP Digest Authentication"" M This capability indicates that the assigned S-CSCF shall support the handling of SIP Digest Authentication. Support of ""NASS Bundled Authentication"" M This capability indicates that the assigned S-CSCF shall support the handling of NASS Bundled Authentication. Support of ""Wildcarded IMPUs"" M This capability indicates that the assigned S-CSCF shall support the handling of Wildcarded Public User Identities. Support of ""Loose-Route "" M This capability indicates that the assigned S-CSCF shall support the loose-route mechanism. Support of ""Service Level Trace"" M This capability indicates that the assigned S-CSCF shall support the Service Level Trace mechanism. Support of ""Priority Service"" M This capability indicates that the S-CSCF shall support a network default pre-configured namespace (e.g. ""wps"") and the associated Service Priority Level. See IETFÊRFCÊ4412Ê[22] and 3GPP TSÊ24.229Ê[8]. Support of ""Extended Priority "" (NOTE 2) M This capability indicates that the S-CSCF shall support the Priority Namespaces and their associated Priority Levels. See IETF RFC 4412Ê[22] and 3GPP TSÊ24.229Ê[8]. Support of ""Early IMS Security"" M This capability indicates that the assigned S-CSCF shall support GIBA. Support of ""Reference Location"" M This capability indicates that the assigned S-CSCF shall support the handling of reference location as defined in 3GPP TSÊ23.167Ê[23]. Support of ""Priviledged-Sender"" M This capability indicates that the S-CSCF shall support priviledged sender. See 3GPP TSÊ24.229Ê[8]. Support of ""IMSI"" M This capability indicates that the assigned S-CSCF shall support the handling of the IMSI. Support of ""Maximum Number of allowed simultaneous registrations"" M This capability indicates that the assigned S-CSCF shall support the handling of maximum number of allowed simultaneous registrations per user as received from the HSS. NOTE 1: Mandatory (M) corresponds to a Mandatory Capability that shall be supported by the assigned S-CSCF for a given user. The I-CSCF shall not select an S-CSCF that does not meet a mandatory capability. The selection of a S-CSCF not supporting this capability would lead to an unspecified network behaviour. Optional (O) corresponds to an Optional Capability that may be supported by the assigned S-CSCF for a given user. The selection of a S-CSCF that would not support this capability will not significantly affect the network behaviour. NOTE 2: Support of ""Extended Priority "" is backward compatible with continued support of the ""Priority Service"". 7 Information element contents 7.1 Visited Network Identifier This information element contains the domain name of the visited network. 7.2 Public User Identity This information element contains the Public User Identity. For definition of a Public User Identity, see TSÊ23.003Ê[17]. When GPRS-IMS-Bundled Authentication (GIBA) is used, a Temporary Public User Identity is derived from the IMSI used for bearer network access according to the rules in TSÊ23.003Ê[17]. 7.2a Public Service Identity This information element contains a Public Service Identity (PSI) that is hosted by an application server. For definition of a PSI, see TSÊ23.003Ê[17]. 7.2b Wildcarded Public Identity This information element contains a Wildcarded PSI that is hosted by an application server or a Wildcarded Public User Identity. For definition of a Wildcarded PSI and a Wildcarded Public User Identity, see TSÊ23.003Ê[17]. 7.2c Void 7.3 Private User Identity This information element contains the Private User Identity. For definition of a Private User Identity, see TSÊ23.003Ê[17]. When GPRS-IMS-Bundled Authentication (GIBA) is used, the Private User Identity is derived from the IMSI as specified in TSÊ33.203Ê[3]. 7.3a Private Service Identity This information element contains the Private Service Identity. For definition of a Private Service Identity, see TSÊ23.003Ê[17]. 7.4 S-CSCF Name This information element contains the S-CSCF Name of the S-CSCF assigned to an IMS Subscription. For definition of a S-CSCF Name, see TSÊ23.008Ê[18]. 7.4a AS Name This information element contains the AS Name of the AS hosting a Public Service Identity. For definition of AS Name, see TSÊ23.008Ê[18]. 7.5 S-CSCF Capabilities This information element carries information to assist the I-CSCF during the process of selecting an S-CSCF for a certain IMS Subscription. 7.6 Result This information element contains result of an operation. See TSÊ29.229Ê[5] for the possible values. 7.7 User Profile This information element contains the user profile in XML format. The user profile XML shall be valid against the user profile XML schema defined in Annex E. Annex B specifies the UML logical model of the user profile downloaded via the Cx interface. Annex D contains and informative, high level representation, of the wire representation of user profile data. 7.8 Server Assignment Type Indicates the type of server assignment. See TSÊ29.229Ê[5] for the list of existing values. 7.9 Authentication Data This information element is composed of the following sub-elements. 7.9.1 Item Number This information element indicates the order in which the authentication vectors are to be consumed. See TSÊ29.229Ê[5] for coding details. 7.9.2 Authentication Scheme This information element contains the authentication scheme, which is used to encode the authentication parameters. See TSÊ29.229Ê[5] for a list of values. 7.9.3 Authentication Information This information element is used to convey the challenge and authentication token used during the authentication procedure, see TSÊ33.203Ê[3] for more information. See TSÊ29.229Ê[5] for coding details. 7.9.4 Authorization Information This information element is used, in an authentication request, to indicate a failure of synchronization. In a response, it is used to convey the expected response to the challenge used to authenticate the user, see TSÊ33.203Ê[3] for more information. See TSÊ29.229Ê[5] for coding details. 7.9.5 Confidentiality Key This information element contains the confidentiality key, see TSÊ33.203Ê[3] for more information. See TSÊ29.229Ê[5] for coding details. 7.9.6 Integrity Key This information element contains the integrity key, see TSÊ33.203Ê[3] for more information. See TSÊ29.229Ê[5] for coding details. 7.9.7 Authentication Context his information element contains authentication-related information relevant for performing the authentication but that is not part of the SIP authentication headers. Some mechanisms (e.g. PGP, digest with quality of protection set to ""auth-int"" defined in IETFÊRFCÊ7616Ê[33], digest with predictive nonces or sip access digest) request that part or the whole SIP request (e.g. the SIP method) is passed to the entity performing the authentication. In such cases the SIPAuthentication-Context AVP shall be carrying such information. See TSÊ29.229Ê[5] for coding details. 7.9.8 Digest Authenticate This information element is composed of the following sub-elements. 7.9.8.1 Digest Realm This information element is part of the Digest authentication challenge, and corresponds to the Realm parameter as defined in IETFÊRFCÊ3261Ê[11]. This information element is used to convey the Realm to the S-CSCF during the SIP Digest authentication procedure. See TSÊ29.229Ê[5] for coding details. 7.9.8.2 Void 7.9.8.3 Digest Algorithm This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. See TSÊ29.229Ê[5] for coding details. 7.9.8.4 Digest QoP This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. It provides the Quality of Protection indication and has an effect on the digest computation. See TSÊ29.229Ê[5] for coding details. 7.9.8.5 Digest HA1 This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. See TSÊ29.229Ê[5] for coding details. 7.9.8.6 Alternate Digest Algorithm This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. See TSÊ29.229Ê[5] for coding details. 7.9.8.7 Alternate Digest HA1 This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. See TSÊ29.229Ê[5] for coding details. 7.9.9 Line Identifier This information element contains the line identifier of the user's network termination. See TSÊ29.229Ê[5] for coding details. 7.9.10 Framed IP Address See TSÊ29.229Ê[5] for more information. 7.9.11 Framed IPv6 Prefix See TSÊ29.229Ê[5] for more information. 7.9.12 Framed Interface Id See TSÊ29.229Ê[5] for more information. 7.10 Number Authentication Items This information element contains the number of authentication vectors requested or delivered. 7.11 Reason for de-registration This information element contains the reason for a de-registration procedure. 7.12 Charging information Addresses of the charging functions. See TSÊ29.229Ê[5]. 7.13 Routing information Information to route requests. 7.14 Type of authorization Type of authorization requested by the I-CSCF. See TSÊ29.229Ê[5] for a list of values. 7.15 Void Void 7.16 User Data Already Available This information element indicates to the HSS if the user profile is already available in the S-CSCF. See TSÊ29.229Ê[5] for a list of values. 7.17 Associated Private Identities This information element indicates to the S-CSCF the Private Identities, which belong to the same IMS Subscription as the Private Identity received in the request command. See TSÊ29.229Ê[5]. 7.18 Originating-Request This information element indicates to the HSS that the request is related to an originating SIP message. See 3GPP 29.229Ê[5]. 7.19 User Authorization Request Flags This information element carries the following indication (see 3GPP 29.229Ê[5] for coding details): - IMS Emergency Registration. 7.20 Loose-Route Indication This information element indicates to the S-CSCF that the loose-route mechanism shall be applied to the public identities contained in the user profile received from the HSS. See TSÊ29.229Ê[5]. This information is static data for the duration of the subscription or the validity of the IMS identity. Modification of this data result in Network Initiated Deregistration (SERVER_CHANGE); see clauseÊ6.1.3.1. 7.21 S-CSCF Restoration Information This information element contains information for the S-CSCF to handle traffic for a registered user. It is associated with the Private User Identity and the Implicit Registration Set that is affected by the SAR request. See TSÊ29.229Ê[5] for the contents of this information element. 7.22 Associated Registered Private Identities This information element indicates to the S-CSCF the Registered Private Identities, which were registered with the Public Identity received in the request command. See TSÊ29.229Ê[5]. 7.23 Multiple Registration Indication This information element indicates to the HSS that this is related to a multiple registration. See TSÊ29.229Ê[5]. 7.24 Session-Priority This information element indicates the session's priority level to the HSS. See TSÊ29.229Ê[5]. 7.25 Identities with Emergency Registration This information element indicates to the HSS a list of pairs of Private / Public Identities that are emergency registered. See TSÊ29.229Ê[5]. 7.26 Priviledged-Sender Indication This information element indicates to the S-CSCF that the Private User Identity shall be considered as a priviledged sender, as described in TSÊ24.229Ê[8]. 7.27 LIA Flags This information element carries the following indications. See TSÊ29.229Ê[5] for coding details. - PSI Direct Routing Indication 7.28 Server Assignment Request Flags This information element carries the following indication (see 3GPP 29.229Ê[5] for coding details): - P-CSCF Restoration Indication 7.29 Allowed WAF and/or WWSF Identities Addresses of the WebRTC Authentication Functions and/or WebRTC Web Server Functions allowed for a subscription. See TSÊ33.203Ê[3]. 7.30 RTR Flags This information element carries the following indications. See TSÊ29.229Ê[5] for coding details. - Reference Location Information change 7.31 Failed-PCSCF This information element indicates to the HSS the address of a failed P-CSCF, as detected by the S-CSCF. 8 Error handling procedures 8.1 Registration error cases This clause describes the handling of error cases, which can occur during the registration process. If the new and previously assigned S-CSCF names sent in the Multimedia-Auth-Request command are different and the Multimedia-Auth-Request is not indicating synchronisation failure (i.e. the request does not contain auts parameter), then the HSS shall overwrite the S-CSCF name. If the new and previously assigned S-CSCF names sent in a command other than the Multimedia-Auth-Request command are different and the S-CSCF reassignment pending flag is not set, then the HSS shall not overwrite the S-CSCF name; instead it shall send a response to the S-CSCF indicating an error. 8.1.1 Cancellation of the old S-CSCF It is possible that in certain situations the HSS receives a Multimedia-Auth-Request (MAR) command including a S-CSCF name, which is not the same as the previously assigned S-CSCF for the user. This can happen e.g. in case the new S-CSCF is selected due to a failure in the re-registration if the previously assigned S-CSCF does not respond to REGISTER message sent from the I-CSCF after a timeout. In this case, the new S-CSCF is assigned for the user and if registrations in the previously assigned S-CSCF exist for the user, these registrations in the old S-CSCF are handled locally in the old S-CSCF, e.g. re-registration timers in the old S-CSCF shall cancel the registrations. Additionally, the HSS should de-register the registrations in the old S-CSCF by using the Registration-Termination-Request command. In this case, the HSS shall first check whether the deregistration is really required by comparing the Diameter client address of the newly assigned S-CSCF received in the MAR command to the Diameter client address stored in the HSS. If the Diameter client addresses match, the deregistration shall not be initiated. Otherwise the deregistration should be initiated for all the registered Public User Identities for the corresponding IMS Subscription. HSS shall check whether IMS Restoration Procedures are supported to perform deregistration: - If supported, Registration-Termination-Request shall be sent for all Public User Identities (with their associated Private User Identities), with Deregistration-Reason AVP value set to NEW_SERVER_ASSIGNED. - Otherwise, Registration-Termination-Request shall be sent with different Deregistration-Reason AVP values, in the following order: 1. Deregistration-Reason AVP value set to NEW_SERVER_ASSIGNED, for the Public User Identity (with its associated Private User Identity), which is registered in the new S-CSCF. 2. Deregistration-Reason AVP value set to SERVER_CHANGE, for the user Public User Identities (with their associated Private User Identities), which are not yet registered in the new S-CSCF. 8.1.2 Error in S-CSCF name If the S-CSCF name sent in the Server-Assignment-Request command and the previously assigned S-CSCF name stored in the HSS are different and the S-CSCF reassignment pending flag is not set, then the HSS shall not overwrite the S-CSCF name. If the Server Assignment Type indicates NO_ASSIGNMENT, the HSS shall send a response to the S-CSCF with Result-Code value set to DIAMETER_UNABLE_TO_COMPLY. For all other Server Assignment Types, the HSS shall send a response to the S-CSCF with Experimental-Result-Code value set to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED. If the S-CSCF name sent in the Server-Assignment-Request command and the previously assigned S-CSCF name stored in the HSS are different and IMS Restoration Procedures are supported and the S-CSCF reassignment pending flag is set, then the HSS shall allow overwriting of the S-CSCF name and proceed with the processing of the SAR command as defined in clauseÊ6.1.2. 8.1.3 Error in S-CSCF assignment type If the Server-Assignment-Type in the Server-Assignment-Request command sent by the S-CSCF to the HSS is not allowed (i.e if the Server-Assignment-Type is not applicable based on the user state or it is not applicable based on the user identity type), the HSS shall send a response to the S-CSCF with the Experimental-Result-Code value set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. 9 Protocol version identification See TSÊ29.229Ê[5]. 10 Operational Aspects See TSÊ29.229Ê[5]. Annex A (normative): Mapping of Cx operations and terminology to Diameter A.1 Introduction This appendix gives mappings from Cx to Diameter protocol elements. Diameter protocol elements are defined in TSÊ29.229Ê[5]. A.2 Cx message to Diameter command mapping The following table defines the mapping between stage 2 operations and Diameter commands: Table A.2.1: Cx message to Diameter command mapping Cx message Source Destination Command-Name Abbreviation Cx-Query + Cx-Select-Pull I-CSCF HSS User-Authorization-Request UAR Cx-Query Resp + Cx-Select-Pull Resp HSS I-CSCF User-Authorization-Answer UAA Cx-Put + Cx-Pull S-CSCF HSS Server-Assignment-Request SAR Cx-Put Resp + Cx-Pull Resp HSS S-CSCF Server-Assignment-Answer SAA Cx-Location-Query I-CSCF HSS Location-Info-Request LIR Cx-Location-Query Resp HSS I-CSCF Location-Info-Answer LIA Cx-AuthDataReq S-CSCF HSS Multimedia-Authentication-Request MAR Cx-AuthDataResp HSS S-CSCF Multimedia-Authentication-Answer MAA Cx-Deregister HSS S-CSCF Registration-Termination-Request RTR Cx-Deregister Resp S-CSCF HSS Registration-Termination-Answer RTA Cx-Update_Subscr_Data HSS S-CSCF Push-Profile-Request PPR Cx-Update_Subscr_Data Resp S-CSCF HSS Push-Profile-Answer PPA A.3 Cx message parameters to Diameter AVP mapping The following table gives an overview about the mapping: Table A.3.1: Cx message parameters to Diameter AVP mapping Cx parameter AVP Name Visited Network Identifier Visited-Network-Identifier Public Identity Public-Identity Private Identity User-Name S-CSCF Name Server-Name AS Name S-CSCF capabilities Server-Capabilities Result Result-Code Experimental-Result-Code User profile User-Data Server Assignment Type Server-Assignment-Type Authentication data SIP-Auth-Data-Item Item Number SIP-Item-Number Authentication Scheme SIP-Authentication-Scheme Authentication Information SIP-Authenticate Authorization Information SIP-Authorization Confidentiality Key Confidentiality-Key Integrity Key Integrity-Key Number Authentication Items SIP-Number-Auth-Items Reason for de-registration Deregistration-Reason Charging Information Charging-Information Routing Information Destination-Host Type of Authorization Authorization-Type Associated Private Identities Associated-Identities Digest Authenticate SIP-Digest-Authenticate Digest Realm Digest-Realm Digest Algorithm Digest-Algorithm Digest QoP Digest-QoP Digest HA1 Digest-HA1 Alternate Digest Algorithm Alternate-Digest-Algorithm Alternate Digest HA1 Alternate-Digest-HA1 Line Identifier Line-Identifier Wildcarded Public Identity Wildcarded-Public Identity Loose-Route Indication Loose-Route-Indication S-CSCF Restoration Information SCSCF-Restoration-Info Multiple Registration Indication Multiple-Registration-Indication Priviledged-Sender Indication Priviledged-Sender-Indication LIA Flags LIA-Flags Allowed WAF and/or WWSF Identities Allowed-WAF-WWSF-Identities A.4 Message flows The following message flows give examples regarding which Diameter messages shall be sent in scenarios described in TSÊ23.228Ê[1]."
"A.4.1 RegistrationÐ user not registered Figure A.4.1.1: Registration Ð user not registered A.4.2 Registration Ð user currently registered Figure A.4.2.1: Re-registration A.4.3 UE initiated de-registration Figure A.4.3.1: UE initiated de-registration A.4.4 Network initiated de-registration A.4.4.1 Registration timeout Figure A.4.4.1.1: Network initiated de-registration Ð registration timeout A.4.4.2 Administrative de-registration Figure A.4.4.2.1: Network initiated de-registration Ð administrative de-registration A.4.4.3 De-registration initiated by service platform Figure A.4.4.3.1: Network initiated de-registration Ð initiated by service platform A.4.5 UE Terminating SIP session set-up Figure A.4.5.1: UE Terminating SIP session set-up A.4.6 Initiation of a session to a non-registered user Figure A.4.6.1: Initiation of a session to a non-registered user A.4.6a AS originating session on behalf of a non-registered user Figure A.4.6a.1: AS originating session on behalf of a non-registered user A.4.7 User Profile update Figure A.4.7.1: User profile update Annex B (informative): User profile UML model The purpose of this UML model is to define in an abstract level the structure of the user profile downloaded over the Cx interface and describe the purpose of the different information classes included in the user profile. B.1 General description The following picture gives an outline of the UML model of the user profile, which is downloaded from HSS to S-CSCF: Figure B.1.1: User Profile IMS Subscription class contains as a parameter the private user identity of the user in NAI format and the IMSI of the user, if available, as defined in TSÊ23.003Ê[17]. Each instance of the IMS Subscription class contains zero or one instance of the class Reference Location Information. The class Reference Location Information contains zero or one attribute AccessType, zero or one attribute AccessInfo, and zero or one attribute AccessValue. The attribute AccessType indicates the type of access for which the reference location of the user is defined (e.g. ADSL). The attribute AccessInfo indicates the type of the access information defined for the reference location of the user (e.g. dsl-location). The attribute AccessValue contains the location information (e.g. line identifier in fixed access networks) as configured by the operator. Each instance of the IMS Subscription class contains one or several instances of the class Service Profile. B.2 Service profile The following picture gives an outline of the UML model of the Service Profile class: Figure B.2.1: Service Profile Each instance of the Service Profile class consists of the following classes: - One or several instances of the Public-Identity class. PublicIdentity class contains the Public Identities associated with that service profile. The information in the CoreNetworkServicesAuthorization and InitialFilterCriteria classes apply to all PublicIdentification class instances, which are included in one ServiceProfile class. - An optional instance of the CoreNetworkServicesAuthorization class. If no instance of the CoreNetworkServicesAuthorization class is present, no filtering related to subscribed media or restriction on IMS Communication Service Identifiers applies in the S-CSCF. - Zero or several instances of the InitialFilterCriteria class. Each instance of the Service Profile class contains the following attributes: - Zero or more instances of the attribute SharedIFCSetID. A SharedIFCSetID attribute points to a set of Initial Filter Criteria locally administered and stored at the S-CSCF. Shared iFC Sets may be shared by several Service Profiles. B.2.1 Public Identification The following picture gives an outline of the UML model of Public Identification class: Figure B.2.1.1: Public Identification The attribute BarringIndication is of type Boolean. If it is absent, or if it is present and set to FALSE, the S-CSCF shall not restrict the use of that public user identity in any IMS communications. If it is present and set to TRUE, the S-CSCF shall prevent that public identity from being used in any IMS communication except registrations and re-registrations, as specified in TSÊ24.229Ê[8]. Public Identification class can contain an Identity attribute. The attribute IdentityType indicates the type of identity contained in each case. It could be either: - A distinct Public User Identity - A distinct Public Service Identity - A Wildcarded Public Service Identity - A non distinct Public User Identity, i.e. not explicitly provisioned in HSS. - A Wildcarded Public User Identity If the identity type is not present, it is assumed to be a distinct Public User Identity. The attribute WildcardedPSI may be present (when IdentityType is WildcardedPSI) and contains the Wildcarded Public Service Identity that matched the Public Service Identity. This Wildcarded Public Service identity shall be sent as stored in the HSS, that is, including the delimiter described in TSÊ23.003Ê[17]. The attribute DisplayName allows a name to be associated with a Public Identity. The attribute AliasIdentityGroupID indicates the Alias Public User Identity Set to which the Public User Identity belongs. If the ""AliasInd"" feature is supported, all Public User Identities shall have an AliasIdentityGroupID allocated. Within an IMS subscription Public User Identities that have the same AliasIdentityGroupID allocated shall be in the same implicit registration sets, and shall share their service profile and the same service data for each and every service, and shall be regarded as aliases of each other, as defined in the TSÊ23.008Ê[18]. If the ""AliasInd"" feature is not supported, all Public User Identities within an IMS subscription that are within the same implicit registration set and share their service profile shall be regarded aliases of each other. The attribute WildcardedIMPU shall be present when IdentityType is a non distinct IMPU or it may be optionally present when IdentityType is a Wildcarded IMPU. It contains the Wildcarded Public User Identity that matched the Public User Identity. This Wildcarded Public User identity shall be sent as stored in the HSS, that is, including the delimiter described in TSÊ23.003Ê[17]. The attribute ServiceLevelTraceInfo provides the Service Level Tracing Information that is related to the Public User Identity. If the ServiceLevelTraceInfo is present, service level tracing shall be enabled in the S-CSCF for the related Public User Identity according to the configuration data received. If the ServiceLevelTraceInfo is not present, service level tracing is disabled in the S-CSCF for the related Public User Identity. The attribute ServicePriorityLevel provides the Priority Level allowed for the Public User Identity, which can be used by the S-CSCF and other network elements for Priority Service. The attribute PriorityNamespace provides the Namespace as specified in IETFÊRFCÊ4412Ê[22] and to which the Extended Priority refers. The attribute PriorityLevel provides the Priority Level allowed for the Public User Identity, for the Extended Priority. Its value depends on the PriorityNamespace. The attribute MaxNumOfAllowedSimultRegs provides the maximum number of allowed simultaneous registrations for the Public User Identity. B.2.1A Core Network Service Authorization The following picture gives an outline of the UML model of Core Network Service Authorization class: Figure B.2.1A.1: Core Network Service Authorization Each instance of the Core Network Service Authorization class contains zero or one instance of the class Subscribed Media Profile Id. If no instance of the class Subscribed Media Profile Id is present, no filtering related to subscribed media applies in S-CSCF. The Subscribed Media Profile Id is of type Integer and identifies a media profile in the S-CSCF for the authorization of media parameters. Each instance of the Core Network Service Authorization class contains zero or one instance of the class List of Service Ids. If no instance of the class List of Service Ids is present, no restriction on IMS Communication Service Identifiers related applies in S-CSCF. Each instance of the class List of Service Ids contains zero or more instances of the class Service Id. The Service Id is of type String and identifies an IMS Communication Service Identifier that the subscriber is authorized to use. B.2.2 Initial Filter Criteria The following picture gives an outline of the UML model of Initial Filter Criteria class: Figure B.2.2.1.1: Initial Filter Criteria Each instance of the InitialFilterCriteria class includes the following attributes: - One instance of Priority attribute that indicates the priority of the Filter Criteria. The higher the Priority Number the lower the priority of the Filter Criteria is; i.e., a Filter Criteria with a higher value of Priority Number shall be assessed after the Filter Criteria with a smaller Priority Number have been assessed. The same priority shall not be assigned to more than one initial Filter Criterion. - An optional instance of ProfilePartIndicator attribute that is an enumerated type, with possible values ""REGISTERED and UNREGISTERED, indicating if the iFC is a part of the registered or unregistered user profile. If ProfilePartIndicator is missing from the iFC, the iFC is considered to be relevant to both the registered and unregistered parts of the user profile, i.e. belongs to the common part of the user profile. Each instance of the InitialFilterCriteria class consists of the following classes: - An optional instance of TriggerPoint class that describes the trigger points that should be checked in order to find out if the indicated Application Server should be contacted or not. Each TriggerPoint is a boolean expression in Conjunctive or Disjunctive Normal form (CNF of DNF). The absence of Trigger Point instance will indicate an unconditional triggering to Application Server. The attribute ConditionTypeCNF attribute defines how the set of SPTs are expressed, i.e. either an Ored set of ANDed sets of SPT statements or an ANDed set of Ored sets of statements. Individual SPT statements can also be negated. These combinations are termed, respectively, Disjunctive Normal Form (DNF) and Conjunctive Normal Form (CNF) for the SPT (see Annex C). Both DNF and CNF forms can be used. ConditionTypeCNF is a boolean that is TRUE when the Trigger Point associated with the FilterCriteria is a boolean expression in Conjunctive Normal Form (CNF) and FALSE if the Trigger Point is expressed in Disjunctive Normal Form (DNF) (see Annex C). Each TriggerPoint class is composed by 1 to n instances of the SPT (ServicePointTrigger) class. - One instance of ApplicationServer class that defines the application server, which is contacted, if the trigger points are met. Each instance of the ApplicationServer class includes following attributes: - One instance of ServerName attribute that is the SIP URL of the application server to contact. - An optional instance of DefaultHandling attribute that determines whether the dialog should be released if the Application Server could not be reached or not; it is of type enumerated and can take the values: SESSION_CONTINUED or SESSION_TERMINATED. - One optional instance of the ServiceInfo attribute. The ServiceInfo attribute allows to download to S-CSCF information that is to be transferred transparently to an Application Server when the trigger points of a filter criterion are satisfied. ServiceInfo is a string conveying that information. See TSÊ23.218Ê[6] for a description of the use of this information element. Each instance of the ApplicationServer class includes following classes: - One optional instance of the IncludeRegisterRequest class that indicates to the S-CSCF that the incoming SIP REGISTER request is to be transferred to an Application Server when the trigger points of a filter criterion are satisfied. See TSÊ23.218Ê[6] for a description of the use of this information element. - One optional instance of the IncludeRegisterResponse class that indicates to the S-CSCF that the final SIP response to the incoming SIP REGISTER request is to be transferred to an Application Server when the trigger points of a filter criterion are satisfied. See TSÊ23.218Ê[6] for a description of the use of this information element. B.2.3 Service Point Trigger The following picture gives an outline of the UML model of Service Point Trigger class: Figure B.2.3.1: Service Point Trigger The attribute Group of the class Service Point Trigger allows the grouping of SPTs that will configure the sub-expressions inside a CNF or DNF expression. For instance, in the following CNF expression (A+B).(C+D), A+B and C+D would correspond to different groups. In CNF, the attribute Group identifies the ORed sets of SPT instances. If the SPT belongs to different ORed sets, SPT can have more than one Group values assigned. At least one Group must be assigned for each SPT. In DNF, the attribute Group identifies the ANDed sets of SPT instances. If the SPT belongs to different ANDed sets, SPT can have more than one Group values assigned. At least one Group must be assigned for each SPI. The attribute ConditionNegated of the class Service Point Trigger defines whether the individual SPT instance is negated (i.e. NOT logical expression). NOTE: The operator should be aware that a negated Session Case implies that all other available session cases are set. The list of session cases depends on the release and can even be increased in the future, then a negated Session Case may end up triggering ASs unexpectedly (e.g. NOT ORIGINATED_REGISTERED may trigger only TERMINATING_UNREGISTERED and TERMINATING_REGISTERED, or as well ORIGINATING_UNREGISTERED and ORIGINATING_CDIV). The attribute RegistrationType of the class Service Point Trigger is relevant only to the SIP Method SPT with a value of ""REGISTER"" and its' support is optional in the HSS and in the S-CSCF. The RegistrationType may contain a list of values that define whether the SPT matches to REGISTER messages that are related to initial registrations, re-registrations, and/or de-registrations. If RegistrationTypes are given, the SIP Method SPT with a value of ""REGISTER"" shall match if any of the RegistrationTypes match and the S-CSCF supports the RegistrationType attribute. If the SIP Method SPT contains value ""REGISTER"", and no RegistrationType is given, or if the S-CSCF does not support the RegistrationType attribute, the SIP Method SPT matches to all REGISTER messages. The attribute RegistrationType may be discarded if it is present in an SPT other than SIP Method with value ""REGISTER"". Request-URI class defines SPT for the Request-URI. Request-URI contains attribute RequestURI. SIP Method class defines SPT for the SIP method. SIP Method contains attribute Method which holds the name of any SIP method. SIP Header class defines SPT for the presence or absence of any SIP header or for the content of any SIP header. SIP Header contains attribute Header which identifies the SIP Header, which is the SPT, and the Content attribute defines the value of the SIP Header if required. The absence of the Content attribute and ConditionNegated = TRUE indicates that the SPT is the absence of a determined SIP header. Session Case class represents an enumerated type, with possible values ""Originating"", ""Terminating_Registered"", ""Terminating_Unregistered"", ""Originating_Unregistered"", ""Originating_CDIV"" indicating whether the filter should be used by the S-CSCF handling the Originating, Terminating for a registered end user, Terminating for an unregistered end user, Originating for an unregistered end user, or Originating after Call Diversion services. Session Description Information class defines SPT for the content of any SDP field within the body of a SIP Method. The Line attribute identifies the line inside the session description. Content is a string defining the content of the line identified by Line. Annex C (informative): Conjunctive and Disjunctive Normal Form A Trigger Point expression is constructed out of atomic expressions (i.e. Service Point Trigger) linked by Boolean operators AND, OR and NOT. Any logical expression constructed in that way can be transformed to forms called Conjunctive Normal Form (CNF) and Disjunctive Normal Form (DNF). A Boolean expression is said to be in Conjunctive Normal Form if it is expressed as a conjunction of disjunctions of literals (positive or negative atoms), i.e. as an AND of clauses, each of which is the OR of one of more atomic expressions. Taking as an example the following trigger: Method = ""INVITE"" OR Method = ""MESSAGE"" OR (Method=""SUBSCRIBE"" AND NOT Header = ""from"" Content = ""joe"") The trigger can be split into the following atomic expressions: Method=""INVITE"" Method=""MESSAGE"" Method=""SUBSCRIBE"" NOT header=""from"" Content =""joe"" Grouping the atomic expressions, the CNF expression equivalent to the previous example looks like: (Method=""INVITE"" OR Method = ""MESSAGE"" OR Method=""SUBSCRIBE"") AND (Method=""INVITE"" OR Method = ""MESSAGE"" OR (NOT Header = ""from"" Content = ""joe"")) This result in two ""OR"" groups linked by ""AND"" (CNF): (Method=""INVITE"" OR Method = ""MESSAGE"" OR Method=""SUBSCRIBE"") (Method=""INVITE"" OR Method = ""MESSAGE"" OR (NOT Header = ""from"" Content = ""joe"")) The XML representation of the trigger is: <?xml version=""1.0"" encoding=""UTF-8""?> <IMSSubscription xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xsi:noNamespaceSchemaLocation=""CxDataType.xsd""> <PrivateID>IMPI1@homedomain.com</PrivateID> <ServiceProfile> <PublicIdentity> <BarringIndication>1</BarringIndication> <Identity> sip:IMPU1@homedomain.com </Identity> </PublicIdentity> <PublicIdentity> <Identity> sip:IMPU2@homedomain.com </Identity> </PublicIdentity> <InitialFilterCriteria> <Priority>0</Priority> <TriggerPoint> <ConditionTypeCNF>1</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>MESSAGE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>SUBSCRIBE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>1</Group> <Method>INVITE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>1</Group> <Method>MESSAGE</Method> </SPT> <SPT> <ConditionNegated>1</ConditionNegated> <Group>1</Group> <SIPHeader> <Header>From</Header> <Content>""joe""</Content> </SIPHeader> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:AS1@homedomain.com</ServerName> <DefaultHandling>0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </ServiceProfile> </IMSSubscription> A Boolean expression is said to be in Disjunctive Normal Form if it is expressed as a disjunction of conjunctions of literals (positive or negative atoms), i.e. as an OR of clauses, each of which is the AND of one of more atomic expressions. The previous example is already in DNF, composed by the following groups: Method=""INVITE"" Method=""MESSAGE"" Method=""SUBSCRIBE"" AND (NOT header=""from"" Content =""joe"") The XML representation of the trigger is: <?xml version=""1.0"" encoding=""UTF-8""?> <IMSSubscription xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xsi:noNamespaceSchemaLocation=""CxDataType.xsd""> <PrivateID>IMPI1@homedomain.com</PrivateID> <ServiceProfile> <PublicIdentity> <BarringIndication>1</BarringIndication> <Identity> sip:IMPU1@homedomain.com </Identity> </PublicIdentity> <PublicIdentity> <Identity> sip:IMPU2@homedomain.com </Identity> </PublicIdentity> <InitialFilterCriteria> <Priority>0</Priority> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>1</Group> <Method>MESSAGE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>2</Group> <Method>SUBSCRIBE</Method> </SPT> <SPT> <ConditionNegated>1</ConditionNegated> <Group>2</Group> <SIPHeader> <Header>From</Header> <Content>""joe""</Content> </SIPHeader> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:AS1@homedomain.com</ServerName> <DefaultHandling index=""0"">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </ServiceProfile> </IMSSubscription> Annex D (informative): High-level format for the User Profile The way the information shall be transferred through the Cx interface can be seen from a high-level point of view in the following picture: Figure D.1: Example of in-line format of user profile If more than one service profile is created, for example to assign a different set of filters to public identifiers 1 and 2 and public identity 3, the information shall be packaged in the following way: Figure D.2: Example of in-line format of user profile Annex E (normative): XML schema for the Cx interface user profile The file CxDataType_Rel11.xsd, attached to this specification, contains the XML schema for the user profile that is sent over the Cx interface. The user profile XML schema defines that are used in the user profile XML. The data that is allowed to be sent in the user profile may vary depending on the features supported by the Diameter end points, see TSÊ29.229Ê[5]. The user profile XML schema file is intended to be used by an XML parser. The version of the Cx application sending the user profile XML shall be the same as the version of the sent user profile XML and thus it implies the version of the user profile XML schema to be used to validate it. Table E.1 describes the data types and the dependencies among them that configure the user profile XML schema. Table E.1: XML schema for the Cx interface user profile: simple data types Data type Tag Base type Comments tPriority Priority integer >= 0 tProfilePartIndicator ProfilePartIndicator enumerated Possible values: 0 (REGISTERED) 1 (UNREGISTERED) tSharedIFCSetID SharedIFCSetID integer >= 0 tGroupID Group integer >= 0 tRegistrationType RegistrationType enumerated Possible values: 0 (INITIAL_REGISTRATION) 1 (RE-REGISTRATION) 2 (DE-REGISTRATION) tDefaultHandling DefaultHandling enumerated Possible values: 0 (SESSION_CONTINUED) 1 (SESSION_TERMINATED) tDirectionOfRequest SessionCase enumerated Possible values: 0 (ORIGINATING_REGISTERED) 1 TERMINATING_REGISTERED 2 (TERMINATING_UNREGISTERED) 3 (ORIGINATING_UNREGISTERED) 4 (ORIGINATING_CDIV) tPrivateID PrivateID anyURI Syntax described in IETF RFC 2486Ê[14] tSIP_URL Identity anyURI Syntax described in IETF RFC 3261Ê[11] or 3GPP TSÊ23003 (See Note 1) tTEL_URL Identity anyURI Syntax described in IETF RFC 3966Ê[15] or 3GPP TSÊ23003 (See Note 1) tIdentity Identity (union) Union of tSIP_URL, and tTEL_URL tIdentityType IdentityType enumerated Possible values: 0 (DISTINCT PUBLIC_USER_IDENTITY) 1 (DISTINCT_PSI) 2 (WILDCARDED_PSI) (See Note 2) 3 (NON_DISTINCT_IMPU) (See Note 3) 4 (WILDCARDED_IMPU) (See Note 4) tServiceInfo ServiceInfo string tString RequestURI, Method, Header, Content, Line, AccessType, AccessInfo, AccessValue string tBool ConditionTypeCNF, ConditionNegated, BarringIndication boolean Possible values: 0 (false) 1 (true) tSubscribedMediaProfileId SubscribedMediaProfileId integer >=0 tDisplayName DisplayName string tAliasIdentityGroupID AliasIdentityGroupID string tServiceLevelTraceInfo ServiceLevelTraceInfo string Syntax described in 3GPPÊTSÊ24.323Ê[32] tServicePriorityLevel ServicePriorityLevel enumerated Possible values: 0 (Highest priority) 1 2 3 4 (Lowest priority) tPriorityNamespace PriorityNamespace string Possible values are those of the namespaces that are defined in IETF RFC 4412Ê[22] or defined according to the IANA registration procedure described in IETF RFC 4412Ê[22] for Resource-Priority Namespaces. tPriorityLevel PriorityLevel string Possible values depend on the PriorityNamespace and are specified with the associated namespace that is defined in IETF RFC 4412Ê[22] or defined according to the IANA registration procedure described in IETF RFC 4412Ê[22] for Resource-Priority Namespaces tIMSI IMSI string Syntax described in 3GPP TSÊ23.003Ê[17]. ASCII encoded according to ANSI X3.4Ê[26]. tMaxNumOfAllowedSimultRegistrations MaxNumOfAllowedSimultRegistrations integer >= 1 NOTE 1: Only when the ""Identity"" tag is a Wildcarded Identity the syntax is described in 1Ê23.003Ê[17]. It applies to both WILDCARDED_IMPU and WILDCARDED_PSI. NOTE 2: Wildcarded PSI could optionally be included as well in tPublicIdentityExtension. NOTE 3: The IMPU is not explicitly provisioned in HSS. In this case, corresponding Wildcarded IMPU is included in tPublicIdentityExtension3. NOTE 4: WILDCARDED_IMPU indicates that the content of the identity in the ""Identity"" tag is a Wildcarded Public User Identity. In this case, Wildcarded IMPU could optionally be included as well in tPublicIdentityExtension3. Table E.2: XML schema for the Cx interface user profile: complex data types Data type Tag Compound of Tag Type Cardinality tIMSSubscription IMSSubscription PrivateID tPrivateID 1 ServiceProfile tServiceProfile (1 to n) Extension tIMSSubscriptionExtension (0 to 1) tIMSSubscriptionExtension Extension IMSI tIMSI (0 to 1) Extension tIMSSubscriptionExtension2 (0 to 1) tIMSSubscriptionExtension2 Extension ReferenceLocationInformation tReferenceLocationInformation (0 to n) (NOTEÊ5) tReferenceLocationInformation ReferenceLocationInformation AccessType tString (NOTEÊ4) (0 to 1) AccessInfo tString (NOTEÊ4) (0 to 1) AccessValue tString (NOTEÊ4) (0 to 1) tServiceProfile ServiceProfile PublicIdentity tPublicIdentity (1 to n? CoreNetworkServicesAuthorization CoreNetworkServicesAuthorization (0 to 1? InitialFilterCriteria tInitialFilterCriteria (0 to n) Extension tServiceProfileExtension (0 to 1) tServiceProfileExtension Extension SharedIFCSetID tSharedIFCSetID (0 to n) tCoreNetworkServicesAuthorization CoreNetworkServicesAuthorization SubscribedMediaProfileId tSubscribedMediaProfileId (0 to 1) Extension tCNServicesAuthorizationExtension (0 to 1) tPublicIdentity PublicIdentity BarringIndication tBool (0 to 1) Identity tIdentity 1 Extension tPublicIdentityExtension (0 to 1) tInitialFilterCriteria InitialFilterCriteria Priority tPriority 1 TriggerPoint tTrigger (0 to 1) ApplicationServer tApplicationServer 1 ProfilePartIndicator tProfilePartIndicator (0 to 1) tTrigger TriggerPoint ConditionTypeCNF tBool 1 SPT tSePoTri (1 to n) tSePoTri SPT ConditionNegated tBool (0 to 1) Group tGroupID (1 to n( Choice of RequestURI tString 1 Method tString 1 SIPHeader tHeader 1 SessionCase tDirectionOfRequest 1 SessionDescription tSessionDescription 1 Extension tSePoTriExtension (0 to 1) tSePoTriExtension Extension RegistrationType tRegistrationType (0 to 2) tHeader SIPHeader Header tString 1 Content tString (0 to 1) tSessionDescription SessionDescription Line tString 1 Content tString (0 to 1) tApplicationServer ApplicationServer ServerName tSIP_URL 1 DefaultHandling tDefaultHandling (0 to 1) ServiceInfo tServiceInfo (0 to 1) Extension tApplicationServerExtension (0 to 1) tApplicationServerExtension Extension IncludeRegisterRequest tIncludeRegisterRequest (0 to 1) IncludeRegisterResponse tIncludeRegisterResponse (0 to 1) tIncludeRegisterRequest IncludeRegisterRequest (NOTEÊ2) (NOTEÊ2) (0 to 1) tIncludeRegisterResponse tIncludeRegisterResponse (NOTEÊ2) (NOTEÊ2) (0 to 1) tPublicIdentityExtension Extension IdentityType tIdentityType (0 to 1) WildcardedPSI anyURI (NOTE 3) (0 to 1) Extension tPublicIdentityExtension2 (0 to 1) tPublicIdentityExtension2 Extension DisplayName tDisplayName (0 to 1) AliasIdentityGroupID tAliasIdentityGroupID (0 to 1) Extension tPublicIdentityExtension3 (0 to 1) tPublicIdentityExtension3 Extension WildcardedIMPU anyURI (NOTE 3) (0 to 1) ServiceLevelTraceInfo tServiceLevelTraceInfo (0 to 1) ServicePriorityLevel ServicePriorityLevel (0 to 1) Extension tPublicIdentityExtension4 (0 to 1) tPublicIdentityExtension4 Extension ExtendedPriority tExtendedPriority (0 to n) Extension tPublicIdentityExtension5 (0 to 1) tPublicIdentityExtension5 Extension MaxNumOfAllowedSimultRegistrations tMaxNumOfAllowedSimultRegistrations (0 to 1) tExtendedPriority ExtendedPriority PriorityNamespace tPriorityNamespace 1 PriorityLevel tPriorityLevel 1 tCNServicesAuthorizationExtension Extension ListOfServiceIds tListOfServiceIds (0 to 1) tListOfServiceIds ListOfServiceIds ServiceId tString (0 to n) NOTE 1: ""n"" shall be interpreted as non-bounded. NOTEÊ2: empty cells shall be interpreted as complex XML elements without defined content. NOTE 3: the syntax of Wildcarded Public User Identity and Wildcarded Service Identity shall be as described in 3GPP TSÊ23.003Ê[17]. NOTE 4: the syntax of AccessType, AccessInfo and AccessValue is as described in 3GPP TSÊ24.229Ê[8] for P-Access-Network-Info header fields: AccessType corresponds to the ""access-type"" field whereas AccessInfo and AccessValue correspond to the type and associated value defined for the ""access-info"" field. NOTE 5: the HSS shall not send more than one instance of ReferenceLocationInformation and if the S-CSCF receives more than one instance of ReferenceLocationInformation it may arbitrarily pick one for further processing. Annex F (normative): Definition of parameters for service point trigger matching Table F.1 defines the parameters that are transported in the user profile XML. Table F.1: Definition of parameters in the user profile XML Tag Description RequestURI RequestURI tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. For SIP URI, the regular expression shall be matched against the hostport of the SIP-URI. For definition of SIP-URI and hostport, see IETF RFC 3261Ê[11]. For Tel URI, the regular expression shall be matched against the telephone-subscriber of the telephone-uri. For definition of telephone-subscriber and telephone-uri, see IETF RFC 3966Ê[15]. SIPHeader A SIP Header SPT shall be evaluated separately against each header instance within the SIP message. The SIP Header SPT matches if at least one header occurrence matches the SPT. Header (of SIPHeader) Header tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. The regular expression shall be matched against the header-name of the SIP header. For definition of header and header-name, see IETF RFC 3261Ê[11]. Before matching the header-name to the pattern, all SWSs shall be removed from the header-name and all LWSs in the header-name shall be reduced to a single white space character (SP). For definition of SWS and LWS, see IETF RFC 3261Ê[11]. Content (of SIPHeader) Content tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. The regular expression shall be matched against the header-value of the SIP header. For definition of header and header-value, see IETF RFC 3261Ê[11]. If the SIP header contains several header-values in a comma-separated list, each of the header-value shall be matched against the pattern for the Content separately. Before matching the header-value to the pattern, all SWSs shall be removed from the header-value and all LWSs in the header-value shall be reduced to a single white space character (SP). For definition of SWS and LWS, see IETF RFC 3261Ê[11]. SessionDescription A Session Description SPT shall be evaluated separately against each SDP field instance within the SIP message. The Session Description SPT matches if at least one field occurrence matches the SPT. Line (of SessionDescription) Line tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. The regular expression shall be matched against the type of the field inside the session description. For definition of type, see clauseÊ6 in IETF RFC 4566Ê[12]. Content (of SessionDescription) Content tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. The regular expression shall be matched against the value of the field inside the session description. For definition of value, see clauseÊ6 in IETF RFC 4566Ê[12]. Annex G (normative): Emergency registrations S-CSCF and HSS shall handle emergency registrations as normal registrations with the following considerations: - Upon emergency registration, following cases apply: - If a normal registration for the same user does not exist, the S-CSCF shall download corresponding user profile from HSS, ensure that the HSS allocates S-CSCF name to this subscriber and the registration status is set to UNREGISTERED. - Otherwise, the S-CSCF shall ensure that the registration status of the user is not changed in the HSS. - Upon deregistration or expiration of the last normal session, if an emergency registration is still active for this subscriber, the S-CSCF shall ensure that the HSS keeps S-CSCF name allocated to this subscriber and the registration status is set to UNREGISTERED. - Upon expiration of an emergency registration, the S-CSCF shall ensure the registration status of the user is not changed in the HSS if there are other normal registrations of the user. Otherwise, the S-CSCF may send SAR to the HSS to remove its name and set the registration status of the user to NOT REGISTERED. - IMS Restoration procedures do not apply for IMS emergency sessions. Annex H (normative): Diameter overload control mechanism H.1 General Diameter overload control mechanism is an optional feature. IETFÊRFCÊ7683Ê[24] specifies a Diameter overload control mechanism which includes the definition and the transfer of related AVPs between Diameter nodes. It is recommended to make use of IETFÊRFCÊ7683Ê[24] on the Cx interface where, when applied, the I/S-CSCF shall behave as reacting nodes and the HSS as a reporting node. Depending on regional/national requirements and network operator policy, priority traffic (e.g. MPS as described in TSÊ22.153Ê[25]) shall be exempted from throttling due to Diameter overload control up to the point where requested traffic reduction cannot be achieved without throttling the priority traffic. H.2 HSS behaviour The HSS requests traffic reduction from the I/S-CSCF when the HSS is in an overload situation, including OC-OLR AVP in answer commands as described in IETFÊRFCÊ7683Ê[24]. The HSS identifies that it is in an overload situation by implementation specific means. For example, the HSS may take into account the traffic over the Cx interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources, etc. The HSS determines the specific contents of OC-OLR AVP in overload reports and the HSS decides when to send OC-OLR AVPs by implementation specific means. H.3 I/S-CSCF behaviour The I/S-CSCF applies required traffic reduction received in answer commands to subsequent applicable requests, as per IETFÊRFCÊ7683Ê[24]. The I/S-CSCF achieves requested traffic reduction by implementation specific means. For example, the I/S-CSCF may implement message throttling with prioritization or a message retaining mechanism for operations that can be postponed. Diameter requests related to priority traffic (e.g. MPS) and emergency, detected via the presence of priority information (e.g., Resource-Priority header field for MPS) in SIP messages as described in TSÊ24.229Ê[8], have the highest priority. Depending on regional/national regulatory and operator policies, these Diameter requests shall be the last to be throttled, when the I/S-CSCF has to apply traffic reduction. Relative priority amongst various priority traffic (e.g. MPS) and emergency traffic is subject to regional/national regulatory and operator policies. Annex I (Informative): Diameter overload node behaviour I.1 Message prioritization This clause describes possible behaviours of the I/S-CSCF regarding message prioritisation in an informative purpose. The I/S-CSCF may take the following into account when making throttling decisions: - Identification of the procedures that can be deferred (e.g. Deregistration Request), so to avoid to drop non deferrable procedures; - Prioritisation of certain types of request (e.g. between MAR and SAR for S-CSCF, and between LIR and UAR for I-CSCF) according to the context of their use, in particular: - Higher prioritisation of SAR commands for S-CSCF that are related to a registered user for a service, so to avoid the interruption of the registered service for the user; - Higher prioritisation of LIR commands for I-CSCF that are related to a requested service different from registration or deregistration, so to get more originating or terminating services provided to the user; - Skipping of optional authentication. - Priority level of a priority user (e.g., MPS user). Annex J (normative): Diameter message priority mechanism J.1 General IETFÊRFCÊ7944Ê[27] specifies a Diameter message priority mechanism that allows Diameter nodes to indicate the relative priority of Diameter messages. With this information, other Diameter nodes may leverage the relative priority of Diameter messages into routing, resource allocation, set the DSCP marking for transport of the associated Diameter message, and also abatement decisions when overload control is applied. J.2 Cx/Dx interfaces J.2.1 General The Diameter message priority mechanism is an optional feature. It is recommended to make use of IETFÊRFCÊ7944Ê[27] over the Cx/Dx interfaces of an operator network when the overload control defined in Annex H is applied on these Cx/Dx interfaces. J.2.2 S-CSCF/I-CSCF behaviour When the S-CSCF/I-CSCF supports the Diameter message priority mechanism, the S-CSCF/I-CSCF shall comply with IETFÊRFCÊ7944Ê[27]. The S-CSCF/I-CSCF sending a request shall determine the required priority according to its policies. When priority is required, the S-CSCF/I-CSCF shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level. When the S-CSCF/I-CSCF receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request. When the S-CSCF/I-CSCF receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, it may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response. If: - the S-CSCF/I-CSCF supports using the Diameter message priority mechanism for DSCP marking purposes, - the transport network utilizes DSCP marking, and - message-dependant DSCP marking is possible for the protocol stack transporting Diameter, then the S-CSCF/I-CSCF shall set the DSCP marking for transport of the request or response according to the required priority level. Diameter requests related to priority traffic (e.g. MPS as identified by the S-CSCF/I-CSCF through SIP procedures, emergency) shall contain a DRMP AVP with a high priority of which the level value is operator dependent. When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific. J.2.3 HSS/SLF behaviour When the HSS/SLF supports the Diameter message priority mechanism, the HSS/SLF shall comply with IETFÊRFCÊ7944Ê[27]. The HSS/SLF sending a request shall determine the required priority according to its policies. When priority is required, the HSS/SLF shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level. When the HSS/SLF receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request. When the HSS/SLF receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, it may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response. If: - the HSS/SLF supports using the Diameter message priority mechanism for DSCP marking purposes, - the transport network utilizes DSCP marking, and - message-dependant DSCP marking is possible for the protocol stack transporting Diameter, then the HSS/SLF shall set the DSCP marking for transport of the request or response according to the required priority level. When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific. J.2.4 Interactions If the HSS supporting the Diameter message priority mechanism receives the request message containing both the Session-Priority AVP and DRMP AVP, the HSS shall prioritize the request according to priority level received within the DRMP AVP. Annex K (normative): Diameter load control mechanism K.1 General The Diameter load control mechanism is an optional feature. It is recommended to make use of IETFÊIETFÊRFCÊ8583Ê[29] on the Cx interface where, when applied, the I-CSCF and the S-CSCF shall behave as reacting nodes and the HSS as a reporting node. K.2 HSS behaviour The HSS may report its current load by including a Load AVP of type HOST in answer commands as described in IETFÊIETFÊRFCÊ8583Ê[29]. The HSS calculates its current load by implementation specific means. For example, the HSS may take into account the traffic over the Cx interface or other interfaces, the level of usage of internal resources (e.g. CPU, memory), the access to external resources, etc. The HSS determines when to send Load AVPs of type HOST by implementation specific means. K.3 I-CSCF/S-CSCF behaviour When performing next hop Diameter Agent selection for requests that are routed based on realm, the I-CSCF/S-CSCF may take into account load values from Load AVPs of type PEER received from candidate next hop Diameter nodes, as per IETFÊIETFÊRFCÊ8583Ê[29]. Annex L (informative): Change history Date TSGÊ# TSG Doc."
"CR Rev Cat Subject/Comment New Jun 2002 CN#16 NP-020264 Version 2.0.0 approved at CN#16 5.0.0 Sep 2002 CN#17 NP-020449 001 2 Clarification of implicit registration 5.1.0 Sep 2002 CN#17 NP-020449 002 1 Clarification of user registration status query 5.1.0 Sep 2002 CN#17 NP-020449 003 1 Clarification of HSS initiated update of user profile 5.1.0 Sep 2002 CN#17 NP-020449 004 2 Clarification of MAR command 5.1.0 Sep 2002 CN#17 NP-020449 005 1 Conditionality of the SIP-Auth-Data-Item in MAA command 5.1.0 Dec 2002 CN#18 NP-020587 008 2 Rejection of registration of a Temporary Public Identity without active implicit registration 5.2.0 Dec 2002 CN#18 NP-020587 010 - Removal of upper bounds in Cx i/f user profile 5.2.0 Dec 2002 CN#18 NP-020587 011 - S-CSCF Assignment 5.2.0 Dec 2002 CN#18 NP-020587 012 - NAS-Session-Key AVPs in MAA command 5.2.0 Dec 2002 CN#18 NP-020587 013 1 Correction to detailed behaviour of user registration status query 5.2.0 Dec 2002 CN#18 NP-020587 014 1 Removing the DDF dependencies from Cx interface 5.2.0 Dec 2002 CN#18 NP-020587 015 1 Clarification of SERVER_CHANGE de-registration reason code 5.2.0 Dec 2002 CN#18 NP-020589 016 1 Clarification of User-Authorization-Type AVP usage within the UAR 5.2.0 Dec 2002 CN#18 NP-020587 017 1 Correction to HSS initiated update of user profile 5.2.0 Dec 2002 CN#18 NP-020588 019 - Correction in charging information 5.2.0 Dec 2002 CN#18 NP-020590 020 1 Error handling in S-CSCF when receiving too much data 5.2.0 Dec 2002 CN#18 NP-020587 021 1 Re-allocation of S-CSCF 5.2.0 Dec 2002 CN#18 NP-020591 022 - Correction of the SPI 5.2.0 Mar 2003 CN#19 NP-030101 025 1 Clarification of service profile download at service profile modification 5.3.0 Mar 2003 CN#19 NP-030101 028 - Filter ID field removal in InitialFilterCriteria class 5.3.0 Mar 2003 CN#19 NP-030101 030 1 Clarification of IMPU barring handling 5.3.0 Mar 2003 CN#19 NP-030101 032 1 The default public user identity in the Server-Assignment-Answer 5.3.0 Mar 2003 CN#19 NP-030101 034 2 Corrections to service profile 5.3.0 Mar 2003 CN#19 NP-030101 037 3 Handling of non supported data in the S-CSCF when the profile is being updated 5.3.0 Mar 2003 CN#19 NP-030101 024 1 Clarification of the HSS behaviour in REGISTRATION and DE_REGISTRATION procedures at IMPU checking time. 5.3.0 Mar 2003 CN#19 NP-030101 027 - Deletion of Annex F 5.3.0 Mar 2003 CN#19 NP-030101 029 - Clarification of User-Authorization-Type AVP usage within UAR 5.3.0 Mar 2003 CN#19 NP-030101 031 1 Update TS 29.228 after Diameter has become RFC 5.3.0 Mar 2003 CN#19 NP-030101 033 1 Replacement of the NAS-Session-Key AVP 5.3.0 Mar 2003 CN#19 NP-030101 035 2 Clarification on Re-allocation of S-CSCF 5.3.0 Mar 2003 CN#19 NP-030101 038 1 Change of SPI to SPT 5.3.0 Mar 2003 CN#19 NP-030101 040 1 Definition of the Subscribed Media Profile Identifier 5.3.0 Mar 2003 CN#19 NP-030101 026 - Error in definition of Service Point of Interest class 5.3.0 Jun 2003 CN#20 NP-030215 043 - Correct use of the Result-Code AVP 5.4.0 Jun 2003 CN#20 NP-030215 044 1 Conditionality of User-Name AVP in Server-Assignment-Answer 5.4.0 Jun 2003 CN#20 NP-030215 045 2 Corrections to the base 64 encoding examples 5.4.0 Jun 2003 CN#20 NP-030215 046 1 Deregistration of implicitly registered public user identities 5.4.0 Jun 2003 CN#20 NP-030215 047 - Clarification on the Server-Assignment-Type NO_ASSIGNMENT 5.4.0 Jun 2003 CN#20 NP-030215 048 1 Incorrect use of result-code 5.4.0 Jun 2003 CN#20 NP-030215 049 1 Misalignment in the Public-User-Identity IE 5.4.0 Jun 2003 CN#20 NP-030215 050 1 Duplicated Destination-Host AVP within MAR command code 5.4.0 Sep 2003 CN#21 NP-030383 042 3 Error in S-CSCF Assignment Type 5.5.0 Sep 2003 CN#21 NP-030383 051 2 Mistakes in the XML schema of 29.228-540 5.5.0 Sep 2003 CN#21 NP-030383 055 1 Extensibility of the public identity structure in the XML schema 5.5.0 Sep 2003 CN#21 NP-030394 041 2 Introduction of Presence Stage 3 (Px) to the Cx interface 6.0.0 Sep 2003 CN#21 NP-030394 052 - Sharing public identities across multiple UEs 6.0.0 Dec 2003 CN#22 NP-030585 057 3 Conditions for inclusion of Charging Information 6.1.0 Dec 2003 CN#22 NP-030500 060 1 MAR in synchronisation failure case 6.1.0 Dec 2003 CN#22 NP-030500 061 1 The S-CSCF name needs to be checked always in MAR 6.1.0 Dec 2003 CN#22 NP-030500 063 - Conditional AVPs in answer commands 6.1.0 Dec 2003 CN#22 NP-030500 065 1 Server-Assignment-Request 6.1.0 Dec 2003 CN#22 NP-030500 067 - Determination of User-Authorization-Type AVP based on registration expiration 6.1.0 Dec 2003 CN#22 NP-030500 069 2 Not registered state after deregistration with S-CSCF deleted at the HSS 6.1.0 Dec 2003 CN#22 NP-030500 071 - The extensibility of the XML schema 6.1.0 Dec 2003 CN#22 - Reference [9] updated 6.1.0 Mar 2004 CN#23 NP-040046 077 1 Clarification on S-CSCF-Name comparison 6.2.0 Mar 2004 CN#23 NP-040055 081 - Error for missing identification in SAR command 6.2.0 Mar 2004 CN#23 NP-040046 085 1 Conditions for inclusion of Public Identity in SAR 6.2.0 Mar 2004 CN#23 NP-040046 087 1 Correction to sending the Charging-Information AVP 6.2.0 Mar 2004 CN#23 NP-040046 089 - Correction to User-Authorization-Answer 6.2.0 Mar 2004 CN#23 NP-040046 091 - Default handling of error cases during IMS registration 6.2.0 Jun 2004 CN#24 NP-040215 097 2 Update of the charging addresses from HSS 6.3.0 Jun 2004 CN#24 NP-040215 095 1 Content of the User Profile 6.3.0 Jun 2004 CN#24 NP-040215 099 - Correction of SessionCase attribute ambiguity 6.3.0 Sep 2004 CN#25 NP-040416 109 1 LIR and services related to unregistered state 6.4.0 Sep 2004 CN#25 NP-040401 121 2 Triggering initial REGISTER messages 6.4.0 Sep 2004 CN#25 NP-040401 118 1 XML versioning 6.4.0 Sep 2004 CN#25 NP-040401 122 1 Optimization of User Profile Download 6.4.0 Sep 2004 CN#25 NP-040396 124 2 Simplification of the User Profile Split concept 6.4.0 Sep 2004 CN#25 NP-040416 120 3 Use of regular expressions 6.4.0 Dec 2004 CN#26 NP-040523 138 1 HSS initiated deregistration with ""not registered"" registration state 6.5.0 Dec 2004 CN#26 NP-040530 140 1 HSS initiated deregistration with user profile removal for permanent termination 6.5.0 Dec 2004 CN#26 NP-040523 142 2 HSS initiated deregistration using the network initiated de-registration procedure 6.5.0 Dec 2004 CN#26 NP-040530 146 1 Clarification of R6 authentication scheme 6.5.0 Dec 2004 CN#26 NP-040523 150 - Regular Expressions 6.5.0 Dec 2004 CN#26 NP-040530 155 - Correction to XML Root Element 6.5.0 Dec 2004 CN#26 NP-040530 156 1 Modification of User-Data-Already-Available in SAR command. 6.5.0 Dec 2004 CN#26 NP-040523 159 2 Handling of Information Element marked as (M), (C) or (O) 6.5.0 Mar 2005 CN#27 NP-050030 166 - Avoiding undesired deregistration 6.6.0 Mar 2005 CN#27 NP-050030 168 1 Correction to authentication procedures in not registered case 6.6.0 Mar 2005 CN#27 NP-050037 170 3 Clarification of behaviour for Shared Public User Identities 6.6.0 Mar 2005 CN#27 NP-050037 172 - Distribution of Cipher Key and Integrity Key 6.6.0 Apr 2005 Editorial correction on figure figure A.4.1.1 and on clauses: 6.1.4.1, 6.2.2, B.2.1 and 6.2.1.1 6.6.1 Jun 2005 CT#28 CP-050086 181 - TEL-URI reference correction 6.7.0 Jun 2005 CT#28 CP-050086 183 - Clarification on Server Capabilities 6.7.0 Jun 2005 CT#28 CP-050086 185 - Incorrect Implementation of CR172 6.7.0 Jun 2005 CT#28 CP-050081 188 1 Clarification of the content of SIP-Authentication-Context 6.7.0 Jun 2005 CT#28 CP-050086 192 - Syntax correction for XML 6.7.0 Sep 2005 CT#29 CP-050422 196 - Authentication Registration with synchronization failure, Data requested from HSS 6.8.0 Sep 2005 CT#29 CP-050296 200 Correction to XML Schema for SharedIFCSet 6.8.0 Sep 2005 CT#29 CP-050440 202 2 Private identities on the Cx 6.8.0 Sep 2005 CT#29 CP-050282 204 1 Charging-Information correction 6.8.0 Sep 2005 CT#29 CP-050296 207 1 Corrections to UAR and LIR for shared public identities 6.8.0 Sep 2005 CT#29 CP-050422 208 1 Behaviour of the Implicit Registration Set for the Unregistered state 6.8.0 Sep 2005 CT#29 CP-050296 210 - Change of stage 2 reference from Release 5 to Release 6 6.8.0 Sep 2005 CT#29 CP-050294 211 - PSI Activation 6.8.0 Sep 2005 CT#29 CP-050271 213 2 Removal of redundant restrictions for one Public User Identity in SAR 6.8.0 Sep 2005 CT#29 CP-050296 216 - Error code clean up 6.8.0 Sep 2005 CT#29 CP-050296 217 1 Clarification of User Profile update 6.8.0 Dec 2005 CT#30 CP-050604 198 5 XML syntax correction 6.9.0 Dec 2005 CT#30 CP-050611 220 1 PSI impacts on the Cx Interface 6.9.0 Dec 2005 CT#30 CP-050611 221 3 Routing for PSIs Matching a Wildcarded PSI 6.9.0 Dec 2005 CT#30 CP-050611 222 2 Removal of overhead in Private Identities handling in RTR 6.9.0 Dec 2005 CT#30 CP-050605 229 2 Use-Data description corrections 6.9.0 Dec 2005 CT#30 CP-050605 232 2 S-CSCF assignment checking for notregistered state 6.9.0 Dec 2005 CT#30 CP-050605 236 4 RTR correction 6.9.0 Dec 2005 CT#30 CP-050605 238 1 PPR correction 6.9.0 Dec 2005 CT#30 CP-050611 239 1 Private User Id in RTR 6.9.0 Dec 2005 CT#30 CP-050611 246 1 Server capabilities associations with features 6.9.0 Dec 2005 CT#30 Rel-7 version was created because of ETSI TISPAN references. 7.0.0 Mar 2006 CT#31 CP-060084 0243 1 SPT for mobile orig unregistered 7.1.0 Mar 2006 CT#31 CP-060159 0247 2 Removal of the terms Mobile Originated and Mobile Terminated 7.1.0 Mar 2006 CT#31 CP-060154 0254 - Alignment of Annex E with .xsd file 7.1.0 Mar 2006 CT#31 CP-060154 0256 - Incorrect implementation of CR 0198 7.1.0 Mar 2006 CT#31 CP-060065 0260 2 Handling of unknown errors 7.1.0 Mar 2006 CT#31 CP-060154 0263 2 Private User ID in PPR and RTR 7.1.0 Mar 2006 CT#31 CP-060065 0269 - Message flow correction 7.1.0 Mar 2006 CT#31 CP-060065 0274 - Default public-id and PPR 7.1.0 Jun 2006 CT#32 CP-060302 0285 - S-CSCF reselection removal 7.2.0 Jun 2006 CT#32 CP-060308 0290 3 Correction of the normative text in the table 6.7 7.2.0 Jun 2006 CT#32 CP-060308 0292 2 Using SiFC feature to define optional S-CSCF capabilities 7.2.0 Sep 2006 CT#33 CP-060308 0296 - S-CSCF assignment correction 7.3.0 Sep 2006 CT#33 CP-060405 0299 - Default Public User ID either SIP URI or tel URI 7.3.0 Sep 2006 CT#33 CP-060399 0304 1 Barring Indication for public user identity 7.3.0 Sep 2006 CT#33 CP-060417 0306 2 Deletion of description about Authentication-Data-Item 7.3.0 Sep 2006 CT#33 CP-060399 0313 1 Registration message flow correction 7.3.0 Sep 2006 CT#33 CP-060417 0314 4 AS originating requests on behalf of a user 7.3.0 Sep 2006 CT#33 CP-060416 0317 2 Allowing a Display Name to be associated with a Public Identity. 7.3.0 Sep 2006 CT#33 CP-060417 0320 - Update of the Table 6.7 ""Guidelines for S-CSCF Capabilities"" 7.3.0 Dec 2006 CT#34 CP-060553 0325 1 SDP reference correction 7.4.0 Dec 2006 CT#34 CP-060566 0326 1 New message flow about AS originating session 7.4.0 Dec 2006 CT#34 CP-060566 0327 1 Correction of Private Identity description in SAR 7.4.0 Dec 2006 CT#34 CP-060566 0330 3 Correction of error code in SAA 7.4.0 Dec 2006 CT#34 CP-060566 0332 1 Clarification on use of Authentication pending flag 7.4.0 Dec 2006 CT#34 CP-060566 0336 3 Optimization of handling of Wildcarded PSIs 7.4.0 Dec 2006 CT#34 CP-060555 0338 1 Wildcarded PSI as key in PPR 7.4.0 Dec 2006 CT#34 CP-060553 0342 1 Correction of the HSS behaviour in UAR/UAA command pair 7.4.0 Dec 2006 CT#34 CP-060735 0343 3 Clarification regarding URI canonicalization Ð 29.228 7.4.0 Mar 2007 CT#35 CP-070020 0346 3 Clarification of the server name in LIA 7.5.0 Mar 2007 CT#35 CP-070020 0350 3 User profile data synchronisation 7.5.0 Mar 2007 CT#35 CP-070020 0352 - SAA result code correction 7.5.0 Mar 2007 CT#35 CP-070019 0353 2 Removal of roaming restrictions for Emergency Registrations 7.5.0 Mar 2007 CT#35 CP-070020 0354 - Definition and use of the Wildcarded PSI information element 7.5.0 Jun 2007 CT#36 CP-070309 0358 1 Removal of editor's note on IMS Recovery Procedures 7.6.0 Jun 2007 CT#36 CP-070479 0359 2 Impacts of the IMS Communication Service Identifier 7.6.0 Jun 2007 CT#36 CP-070309 0361 2 Clarification on LIA 7.6.0 Jun 2007 CT#36 CP-070309 0365 1 Adding User-Authorization-Type is absent condition to UAR Detailed behaviour 7.6.0 Jun 2007 CT#36 CP-070312 0367 - Modification to the tag RegistrationtType to RegistrationType in the Annex E 7.6.0 Sep 2007 CT#37 CP-070520 0374 1 Authentication failure and timeout handling 7.7.0 Sep 2007 CT#37 CP-070522 0378 - Incorrect implemented CR 120r3 7.7.0 Sep 2007 CT#37 CP-070527 0379 - User Data Already Available 7.7.0 Nov 2007 CT#38 CP-070743 0388 1 Handling of USER_UNKNOWN and NOT_SUPPORTED_USER_DATA error in PPA 7.8.0 Nov 2007 CT#38 CP-070744 0392 2 Alias 7.8.0 Nov 2007 CT#38 CP-070755 0376 6 Updates to 29.228 for Digest on the Cx Interface 8.0.0 Mar 2008 CT#39 CP-080019 0393 1 IMS Restoration after an S-CSCF failure 8.1.0 Mar 2008 CT#39 CP-080022 0395 2 Update for Supporting NASS-Bundled-Authentication 8.1.0 Mar 2008 CT#39 CP-080019 0398 - SIP Digest password push 8.1.0 Mar 2008 CT#39 CP-080019 0400 1 Wildcarded Public User Identities 8.1.0 Jun 2008 CT#40 CP-080261 0399 3 Originating services after call forwarding 8.2.0 Jun 2008 CT#40 CP-080261 0406 XML example 8.2.0 Jun 2008 CT#40 CP-080267 0408 Emergency Registration for REGISTRATION_AND_CAPABILITIES 8.2.0 Jun 2008 CT#40 CP-080267 0410 Removal of restriction for barred user at Emergency Registrations 8.2.0 Sep 2008 CT#41 CP-080456 0413 2 Emergency Public User Identity removal 8.3.0 Sep 2008 CT#41 CP-080460 0420 1 Support of ""Loose-Route"" indication from HSS 8.3.0 Sep 2008 CT#41 CP-080463 0421 Cx Impacts of IMS Restoration Procedures 8.3.0 Sep 2008 CT#41 CP-080460 0423 2 Filter Criteria enhancement for 3rd party REGISTER 8.3.0 Sep 2008 CT#41 CP-080463 0425 1 Addition of Registered Private Identities in SAA 8.3.0 Sep 2008 CT#41 CP-080460 0426 1 Add Assigned S-CSCF name to SAA 8.3.0 Dec 2008 CT#42 CP-080698 0427 2 Service Restoration for Registered IMPU 8.4.0 Dec 2008 CT#42 CP-080707 0431 2 Support for IMS Service Level Trace 8.4.0 Dec 2008 CT#42 CP-080708 0432 Removal of Digest Domain 8.4.0 Dec 2008 CT#42 CP-080696 0433 3 Diameter Proxy Agent - an alternative User Identity to HSS resolution mechanism 8.4.0 Dec 2008 CT#42 CP-080708 0434 2 S-CSCF and AS procedures with Enhanced Filter Criteria 8.4.0 Mar 2009 CT#43 CP-090023 0435 1 Priority Service 8.5.0 Mar 2009 CT#43 CP-090026 0436 1 Multiple Registrations in Registration 8.5.0 Mar 2009 CT#43 CP-090036 0440 2 HSS Addresses 8.5.0 Mar 2009 CT#43 CP-090025 0441 1 Loose Route Indication 8.5.0 Mar 2009 CT#43 CP-090028 0442 2 Support for GPRS IMS Bundled Authentication (GIBA) in Cx 8.5.0 Sep 2009 CT#45 CP-090728 0447 1 Incorrect CR implementation 8.6.0 Dec 2009 CT#46 0452 1 Unregistered user clarification 8.7.0 Dec 2009 CT#46 0456 2 Session-Priority AVP 8.7.0 Dec 2009 CT#46 0457 2 HSS behaviour after PPA with unknown user 8.7.0 Dec 2009 CT#46 0458 1 Check of the S-CSCF Name 8.7.0 Dec 2009 CT#46 0460 IMPI must be sent in SAR for UE initiated requests 8.7.0 Dec 2009 CT#46 Upgraded unchanged from Rel-8 9.0.0 Mar 2010 CT#47 CP-100033 0462 Default IMPU 9.1.0 Mar 2010 CT#47 CP-100031 0468 1 Wildcarded Public Identity 9.1.0 Mar 2010 CT#47 CP-100033 0470 1 Priority service attribute 9.1.0 Mar 2010 CT#47 CP-100033 0474 1 User-Auth-Type not checked 9.1.0 Mar 2010 CT#47 CP-100033 0476 1 GIBA is not allowed when auth. Scheme is Unknown 9.1.0 Mar 2010 CT#47 CP-100042 0477 2 Clarification on the use of User-Data-Already-Available 9.1.0 Mar 2010 CT#47 CP-100015 0482 Server Capabilities 9.1.0 Mar 2010 CT#47 CP-100031 0466 RTR for wildcarded public user identity 9.1.0 May 2010 Xml-file corrected 9.1.1 Jun 2010 CT#48 CP-100412 0484 3 Table not aligned with XML schema for wildcarded identities 9.2.0 Jun 2010 CT#48 CP-100412 0487 3 SAR with NO_ASSIGNMENT correction 9.2.0 Jun 2010 CT#48 CP-100412 0489 2 Update of IETF Reference 9.2.0 Sep 2010 CT#49 CP-100447 0493 2 Wildcarded Identities handling 9.3.0 Sep 2010 CT#49 CP-100447 0495 Wrong order in table for XML schema 9.3.0 Sep 2010 CT#49 CP-100447 0497 2 Cx-MAR handling correction in restoration procedures 9.3.0 Sep 2010 CT#49 CP-100447 500 1 Ambiguity of Presence Conditions of IEs and AVP ABNF 9.3.0 Sep 2010 CT#49 CP-100447 507 Correction for de-registration procedure at restoration 9.3.0 Sep 2010 CT#49 CP-100447 504 2 Mandatory and optional capabilities handling 9.3.0 Dec 2010 CT#50 CP-100668 0519 Coding of SIP-Authorization AVP and SIP-Authenticate AVP 9.4.0 Dec 2010 CT#50 CP-100697 0509 1 Clarification on Alias 10.0.0 Mar 2011 CT#51 CP-110044 0521 - Originating_CDIV Session Case including in XML 10.1.0 Mar 2011 CT#51 CP-110060 0515 5 MPS over Cx 10.1.0 Jun 2011 CT#52 CP-110349 0529 2 Handling of RTR for Emergency Registration 10.2.0 Jun 2011 CT#52 CP-110356 0532 1 Emergency Restoration 10.2.0 Jun 2011 CT#52 CP-110356 0535 - Incorrect Use of Result-Code AVP 10.2.0 Jun 2011 CT#52 CP-110356 0538 1 Error in assignment type for backward compatibility scenarios 10.2.0 Jun 2011 CT#52 CP-110383 0520 4 Reference Location over Cx interface 11.0.0 Sep 2011 CT#53 CP-110566 0542 Priviledged sender 11.1.0 Sep 2011 CT#53 CP-110566 0546 1 Public Identity in canonical form 11.1.0 Dec 2011 CT#54 CP-110781 0552 1 Identity in the service profile 11.2.0 Dec 2011 CT#54 CP-110781 0557 2 Providing the IMSI to the S-CSCF 11.2.0 Dec 2011 CT#54 CP-110809 0553 1 Behaviour of HSS not supported IMS Restoration Procedures to LIR 11.2.0 Mar 2012 CT#55 CP-120014 0562 1 Server-Capability AVP in LIA and UAA 11.3.0 Mar 2012 CT#55 CP-120014 0566 1 Update of charging information and authentication data 11.3.0 Jun 2012 CT#56 CP-120245 0558 2 Maximum Number of simultaneous registrations 11.4.0 Sep 2012 CT#57 CP-120439 0576 1 Emergency registrations do not affect registration status 11.5.0 Sep 2012 CT#57 CP-120456 0577 1 Add RequestURI parameter to SPT matching 11.5.0 Nov 2012 The specification version number in the header corrected 11.5.1 Dec 2012 CT#58 CP-120743 0578 - Experimental-Result-Code correction 11.6.0 Dec 2012 CT#58 CP-120743 0582 3 PSI direct routing with restoration procedures 11.6.0 Dec 2012 CT#58 CP-120743 0583 - Negated Session Case 11.6.0 Mar 2013 CT#59 CP-130011 0593 1 Identities with emergency registration in RTR 11.7.0 Mar 2013 CT#59 CP-130020 0599 1 Clarification on Reference Location information 11.7.0 Jun 2013 CT#60 CP-130374 0600 1 Absent User-Name after S-CSCF recovery 11.8.0 Sep 2013 CT#61 CP-130439 0606 2 Cancellation of the old S-CSCF for IMS Subscription and IMS Restoration Procedures 11.9.0 Sep 2013 CT#61 CP-13046clause 0601 - Correction on Emergency Registration 12.0.0 Dec 2013 CT#62 CP-130627 0607 5 Cx Charging Information Download 12.1.0 Jun 2014 CT#64 CP-140237 0609 2 Wildcarded Public Identity in SAA 12.2.0 Jun 2014 CT#64 CP-140243 0611 2 Diameter Overload Control Over Cx 12.2.0 Sep 2014 CT#65 CP-140506 0624 2 P-CSCF Restoration indication 12.3.0 Sep 2014 CT#65 CP-140515 0626 - Clarification on REGISTRATION_AND_CAPABILITIES for De-registration 12.3.0 Sep 2014 CT#65 CP-140515 0627 - Clarification on Unregistered User 12.3.0 Dec 2014 CT#66 CP-140794 0628 2 HSS behaviour when P-CSCF Restoration indication is received 12.4.0 Dec 2014 CT#66 CP-140790 0630 1 Priority Consideration for Diameter Overload Control 12.4.0 Dec 2014 CT#66 CP-140777 0632 1 Addition of IMS-AKA based on HTTP Digest AKAv2 for WebRTC 12.4.0 Mar 2015 CT#67 CP-150023 0639 1 IMSI Encoding over Cx 12.5.0 Jun 2015 CT#68 CP-150251 0633 4 RTR handling when emergency registration 12.6.0 Jun 2015 CT#68 CP-150251 0642 1 ""Digest-AKAv1-MD5"" is used as well for other Digest-AKA versions 12.6.0 Jun 2015 CT#68 CP-150251 0643 Confidentiality-key is mandatory 12.6.0 Jun 2015 CT#68 CP-150261 0640 - ADMINISTRATIVE_DEREGISTRATION with P-CSCF-Restoration-Indication 12.6.0 July 2016 Correction of typo in previous line of history table. 12.6.1 Sep 2015 CT#69 CP-150428 0647 1 Authentication tables and IE clarifications in MAR/MAA 12.7.0 Sep 2015 CT#69 CP-150428 0649 - Wrong CR update 12.7.0 Sep 2015 CT#69 CP-150432 0644 1 S-CSCF Restoration Information deletion with SAT=UNREGISTERED_USER 12.7.0 Sep 2015 CT#69 CP-150436 0645 - P-CSCF Restoration when IMS Restoration is supported 12.7.0 Dec 2015 CT#70 CP-150754 0653 2 Allowed WAF and/or WWSF Identities 12.8.0 Dec 2015 CT#70 CP-150750 0654 1 Authentication Information IE clarification 12.8.0 Dec 2015 CT#70 CP-150749 0655 1 De-registration without IMPI 12.8.0 Dec 2015 CT#70 CP-150749 0656 1 IMSI change 12.8.0 Dec 2015 CT#70 CP-150759 0658 1 Update reference to DOIC new IETF RFC 12.8.0 Dec 2015 CT#70 CP-150775 0652 4 HSS supports IMS subscriptions corresponding to users managed by third parties 13.0.0 Dec 2015 CT#70 CP-150768 0659 4 DRMP AVP Procedures over Cx/Dx 13.0.0 Mar 2016 CT#71 CP-160031 0661 6 Introduction of AAA-1 interface 13.1.0 Mar 2016 CT#71 CP-160046 0662 - De-registration of emergency registration correction 13.1.0 Jun 2016 CT#72 CP-160215 0665 1 Diameter requests for priority traffic during overload control mechanism 13.2.0 07-2016 Correction to spec version number on cover page 13.2.1 09-2016 CT#73 CP-160431 0666 1 S-CSCF Restoration during Registration enhancement 14.0.0 2016-12 CT#74 CP-160646 0673 2 Reference Location 14.1.0 2016-12 CT#74 CP-160672 0674 1 Service Profile and iFC alignment between XML and text/UML 14.1.0 2016-12 CT#74 CP-160681 0675 1 Load Control 14.1.0 2016-12 CT#74 CP-160664 0677 - Correction to change IETF drmp draft version to official RFC 7944 14.1.0 2017-03 CT#75 CP-170045 0678 - Mission Critical Services 14.2.0 2017-03 CT#75 CP-170048 0679 1 Update of reference for the Diameter base protocol 14.2.0 2017-06 CT#76 CP-171034 0680 1 IMS Trace (ISAT) Reference Updates 14.3.0 2017-06 CT#76 CP-171018 0684 1 Support for signaling transport level packet marking 14.3.0 2017-09 CT#77 CP-172012 0686 - Correction of DRMP Procedures 14.4.0 2017-12 CT#78 CP-173011 0687 1 Cx Subscriber Deregistration Reason 14.5.0 2018-06 CT#80 CP-181121 0688 1 Change of Reference Location Information 15.0.0 2018-09 CT#81 CP-182069 0689 - P-CSCF restoration for 5GC 15.1.0 2019-03 CT#83 CP-190035 0690 1 Reference Location Information change 15.2.0 2019-09 CT#85 CP-192094 0693 2 draft-ietf-dime-load published as RFC 8583 15.3.0 2019-09 CT#85 CP-192150 0691 1 Wildcarded Public Identity in SAA 16.0.0 2019-12 CT#86 CP-193047 0694 - RLOS related registrations 16.1.0 2021-12 CT#94e CP-213104 0696 - B Update of SIP Digest Access Authentication 17.0.0 2022-03 CT#95e CP-220052 0699 1 B Support of the hash value for alternate SIP Digest algorithm 17.1.0 2022-03 CT#95e CP-220054 0697 - B Failed P-CSCF 17.1.0 14 Release 17 3GPP 3GPP TS 29.002 V17.2.0 (2022-06) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) specification (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2021, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 28 1 Scope 29 2 References 29 3 Abbreviations 35 4 Void 36 5 Overload and compatibility overview 36 5.1 Overload control 36 5.1.1 Overload control for MSC (outside MAP) 36 5.1.2 Overload control for MAP entities 36 5.1.3 Congestion control for Signalling System No."
"7 40 5.2 Compatibility 40 5.2.1 General 40 5.2.2 Strategy for selecting the Application Context (AC) version 40 5.2.2.1 Proposed method 40 5.2.2.2 Managing the version look-up table 41 5.2.2.3 Optimising the method 42 6 Requirements concerning the use of SCCP and TC 42 6.1 Use of SCCP 42 6.1.1 SCCP Class 42 6.1.2 Sub-System Number (SSN) 42 6.1.3 SCCP addressing 43 6.1.3.1 Introduction 43 6.1.3.2 The Mobile-services Switching Centre (MSC) 45 6.1.3.2.1 MSC interaction during handover or relocation 45 6.1.3.2.2 MSC for short message routing 45 6.1.3.2.3 MSC for location request routing 45 6.1.3.2.4 MSC for LMU Control 45 6.1.3.3 The Home Location Register (HLR) 46 6.1.3.3.1 During call set-up 46 6.1.3.3.2 Before location updating completion 46 6.1.3.3.3 After location updating completion 46 6.1.3.3.4 VLR restoration 47 6.1.3.3.5 During Network-Requested PDP Context Activation 47 6.1.3.3.6 Before GPRS location updating completion 47 6.1.3.3.7 After GPRS location updating completion 48 6.1.3.3.8 Query for a Location Request 48 6.1.3.4 The Visitor Location Register (VLR) 48 6.1.3.4.0 General 48 6.1.3.4.1 Inter-VLR information retrieval 48 6.1.3.4.2 HLR request 48 6.1.3.4.3 CSS request 49 6.1.3.5 The Interworking MSC (IWMSC) for Short Message Service 49 6.1.3.6 The Equipment Identity Register (EIR) 49 6.1.3.7 Void 49 6.1.3.8 The Serving GPRS Support Node (SGSN) 49 6.1.3.8.0 General 49 6.1.3.8.1 HLR request 49 6.1.3.8.2 GMSC request 49 6.1.3.8.3 CSS request 49 6.1.3.9 The Gateway GPRS Support Node (GGSN) 49 6.1.3.10 The Gateway MSC (GMSC) for Short Message Service 50 6.1.3.10A Void 50 6.1.3.10A.1 Void 50 6.1.3.10A.2 Void 50 6.1.3.10B The Gateway Mobile Location Centre (GMLC) 50 6.1.3.10C The CSG Subscriber Server (CSS) 50 6.1.3.11 Summary table 50 6.2 Use of TC 53 7 General on MAP services 53 7.1 Terminology and definitions 53 7.2 Modelling principles 53 7.3 Common MAP services 54 7.3.1 MAP-OPEN service 55 7.3.2 MAP-CLOSE service 58 7.3.3 MAP-DELIMITER service 58 7.3.4 MAP-U-ABORT service 58 7.3.5 MAP-P-ABORT service 59 7.3.6 MAP-NOTICE service 60 7.3.7 Void 61 7.3.8 Void 61 7.3.9 Void 61 7.3.10 Void 61 7.4 Sequencing of services 61 7.5 General rules for mapping of services onto TC 62 7.5.1 Mapping of common services 62 7.5.2 Mapping of user specific services 63 7.6 Definition of parameters 64 7.6.1 Common parameters 64 7.6.1.1 Invoke Id 64 7.6.1.2 Linked Id 64 7.6.1.3 Provider error 64 7.6.1.4 User error 64 7.6.2 Numbering and identification parameters 68 7.6.2.1 IMSI 68 7.6.2.2 TMSI 68 7.6.2.3 IMEI 68 7.6.2.3a IMEISV 68 7.6.2.4 Previous location area Id 68 7.6.2.5 Stored location area Id 68 7.6.2.6 Current location area Id 68 7.6.2.7 Target location area Id 68 7.6.2.8 Target cell Id 68 7.6.2.8A Target RNC Id 68 7.6.2.9 Void 68 7.6.2.10 Originating entity number 69 7.6.2.11 MSC number 69 7.6.2.12 Target MSC number 69 7.6.2.13 HLR number 69 7.6.2.14 VLR number 69 7.6.2.15 HLR Id 69 7.6.2.16 LMSI 69 7.6.2.17 MS ISDN 69 7.6.2.17A Additional MSISDN 69 7.6.2.18 OMC Id 69 7.6.2.19 Roaming number 69 7.6.2.19A Relocation Number List 69 7.6.2.20 Void 69 7.6.2.21 Handover number 69 7.6.2.22 Forwarded-to number 70 7.6.2.22A Long forwarded-to number 70 7.6.2.22B Long FTN Supported 70 7.6.2.23 Forwarded-to subaddress 70 7.6.2.24 Called number 70 7.6.2.25 Calling number 70 7.6.2.26 Originally dialled number 70 7.6.2.27 Service centre address 70 7.6.2.28 Zone Code 70 7.6.2.29 MSIsdn-Alert 70 7.6.2.30 Location Information 70 7.6.2.30a Location Information for GPRS 70 7.6.2.30b Location Information for EPS 70 7.6.2.31 GMSC Address 70 7.6.2.32 VMSC Address 71 7.6.2.33 Group Id 71 7.6.2.34 North American Equal Access preferred Carrier Id 71 7.6.2.35 Void 71 7.6.2.36 Void 71 7.6.2.37 Serving cell Id 71 7.6.2.38 SGSN number 71 7.6.2.39 SGSN address 71 7.6.2.40 GGSN address 71 7.6.2.41 GGSN number 71 7.6.2.42 APN 71 7.6.2.43 Network Node number 72 7.6.2.43A Network Node Diameter Address 72 7.6.2.44 PDP-Type 72 7.6.2.44A Extension PDP-Type 72 7.6.2.45 PDP-Address 72 7.6.2.45A Extension PDP-Address 72 7.6.2.46 Additional number 72 7.6.2.46A Additional Network Node Diameter Address 72 7.6.2.46B Third Number 72 7.6.2.46C Third Network Node Diameter Address 72 7.6.2.47 P-TMSI 72 7.6.2.48 B-subscriber number 73 7.6.2.49 B-subscriber subaddress 73 7.6.2.50 LMU Number 73 7.6.2.51 MLC Number 73 7.6.2.52 Multicall Bearer Information 73 7.6.2.53 Multiple Bearer Requested 73 7.6.2.54 Multiple Bearer Not Supported 73 7.6.2.55 PDP-Charging Characteristics 73 7.6.2.56 Selected RAB ID 73 7.6.2.57 RAB ID 73 7.6.2.58 gsmSCF Address 73 7.6.2.59 V-GMLC Address 73 7.6.2.60 Void 73 7.6.2.61 H-GMLC Address 73 7.6.2.62 PPR Address 74 7.6.2.63 Routeing Number 74 7.6.2.64 Additional V-GMLC Address 74 7.6.2.65 MME Name 74 7.6.2.66 3GPP AAA Server Name 74 7.6.2.67 CSS number 74 7.6.2.68 SGSN Name 74 7.6.2.69 SGSN Realm 74 7.6.3 Subscriber management parameters 74 7.6.3.1 Category 74 7.6.3.2 Equipment status 74 7.6.3.2a BMUEF 74 7.6.3.3 Extensible Bearer service 74 7.6.3.4 Extensible Teleservice 74 7.6.3.5 Extensible Basic Service Group 75 7.6.3.6 GSM bearer capability 75 7.6.3.7 Subscriber Status 75 7.6.3.8 CUG Outgoing Access indicator 75 7.6.3.9 Operator Determined Barring General Data 75 7.6.3.10 ODB HPLMN Specific Data 77 7.6.3.11 Regional Subscription Data 77 7.6.3.12 Regional Subscription Response 77 7.6.3.13 Roaming Restriction Due To Unsupported Feature 78 7.6.3.14 Extensible SS-Info 78 7.6.3.15 Extensible forwarding information 78 7.6.3.16 Extensible forwarding feature 78 7.6.3.17 Extensible SS-Status 78 7.6.3.18 Extensible Forwarding Options 78 7.6.3.19 Extensible No reply condition timer 79 7.6.3.20 Extensible Call barring information 79 7.6.3.21 Extensible Call barring feature 79 7.6.3.22 CUG info 79 7.6.3.23 CUG subscription 79 7.6.3.24 CUG interlock 79 7.6.3.25 CUG index 80 7.6.3.26 CUG feature 80 7.6.3.27 Inter CUG options 80 7.6.3.28 Intra CUG restrictions 80 7.6.3.29 Extensible SS-Data 80 7.6.3.30 Subscriber State 80 7.6.3.31 Requested Info 81 7.6.3.31A Requested Domain 81 7.6.3.32 Suppression of Announcement 81 7.6.3.33 Suppress T-CSI 81 7.6.3.34 GMSC CAMEL Subscription Info 81 7.6.3.35 VLR CAMEL Subscription Info 81 7.6.3.36 Supported CAMEL Phases in the VLR 81 7.6.3.36A Supported CAMEL Phases in the SGSN 81 7.6.3.36B Offered CAMEL4 CSIs in the VLR 81 7.6.3.36C Offered CAMEL4 CSIs in the SGSN 81 7.6.3.36D Offered CAMEL4 CSIs 81 7.6.3.36E Offered CAMEL4 CSIs in interrogating node 81 7.6.3.36F Offered CAMEL4 CSIs in VMSC 81 7.6.3.36G Offered CAMEL4 Functionalities 82 7.6.3.36H Supported CAMEL Phases 82 7.6.3.36I Supported CAMEL Phases in interrogating node 82 7.6.3.37 CUG Subscription Flag 82 7.6.3.38 CAMEL Subscription Info Withdraw 82 7.6.3.39 Voice Group Call Service (VGCS) Data 82 7.6.3.40 Voice Broadcast Service (VBS) Data 82 7.6.3.41 ISDN bearer capability 82 7.6.3.42 Lower layer Compatibility 82 7.6.3.43 High Layer Compatibility 82 7.6.3.44 Alerting Pattern 82 7.6.3.45 GPRS Subscription Data Withdraw 82 7.6.3.45A EPS Subscription Data Withdraw 82 7.6.3.46 GPRS Subscription Data 83 7.6.3.46A EPS Subscription Data 83 7.6.3.47 QoS-Subscribed 83 7.6.3.48 VPLMN address allowed 83 7.6.3.49 Roaming Restricted In SGSN/MME Due To Unsupported Feature 83 7.6.3.50 Network Access Mode 83 7.6.3.51 Mobile Not Reachable Reason 83 7.6.3.52 Cancellation Type 83 7.6.3.53 All GPRS Data 83 7.6.3.54 Complete Data List Included 83 7.6.3.55 PDP Context Identifier 83 7.6.3.56 LSA Information 83 7.6.3.57 SoLSA support indicator 84 7.6.3.58 LSA Information Withdraw 84 7.6.3.59 LMU Indicator 84 7.6.3.60 LCS Information 84 7.6.3.61 GMLC List 84 7.6.3.62 LCS Privacy Exception List 84 7.6.3.62A Additional LCS Privacy Exception List 84 7.6.3.63 LCS Privacy Exception Parameters 84 7.6.3.64 External Client List 85 7.6.3.65 Internal Client List 85 7.6.3.65A MO-LR List 85 7.6.3.65B Privacy Notification to MS User 85 7.6.3.65C GMLC List Withdraw 85 7.6.3.65D Service Type List 85 7.6.3.66 IST Alert Timer 85 7.6.3.67 Call Termination Indicator 85 7.6.3.68 IST Information Withdraw 85 7.6.3.69 IST Support Indicator 85 7.6.3.70 Super-Charger Supported In HLR 86 7.6.3.71 Super-Charger Supported In Serving Network Entity 86 7.6.3.72 Age Indicator 86 7.6.3.73 GPRS enhancements support indicator 86 7.6.3.74 Extension QoS-Subscribed 86 7.6.3.75 SGSN CAMEL Subscription Info 86 7.6.3.75A Extension-2 QoS-Subscribed 86 7.6.3.75B Extension-3 QoS-Subscribed 86 7.6.3.75C Extension-4 QoS-Subscribed 86 7.6.3.76 MO-SMS-CSI 86 7.6.3.76a MT-SMS-CSI 87 7.6.3.77 GPRS-CSI 87 7.6.3.78 CAMEL subscription info 87 7.6.3.83 Call Barring Data 87 7.6.3.84 Call Forwarding Data 87 7.6.3.85 ODB Data 88 7.6.3.86 Requested Subscription Info 88 7.6.3.87 CS Allocation/Retention priority 88 7.6.3.88 ODB Info 88 7.6.3.89 Suppress VT-CSI 88 7.6.3.90 Suppress Incoming Call Barring 88 7.6.3.91 gsmSCF Initiated Call 88 7.6.3.91a SuppressMTSS 88 7.6.3.92 Call barring support indicator 88 7.6.3.93 MNP Info Result 88 7.6.3.94 Allowed Services 88 7.6.3.95 Unavailability Cause 89 7.6.3.96 MNP Requested Info 89 7.6.3.97 Access Restriction Data 89 7.6.3.98 Supported RAT types indicator 89 7.6.3.99 UE SRVCC Capability 89 7.6.3.100 Temporary Empty CSG Subscription data Indicator 89 7.6.3.101 WLAN-offloadability 89 7.6.3.102 IMSI-Group-Id 89 7.6.4 Supplementary services parameters 89 7.6.4.1 SS-Code 89 7.6.4.1A SS-Code 2 90 7.6.4.2 SS-Status 90 7.6.4.3 SS-Data 90 7.6.4.4 Override Category 90 7.6.4.5 CLI Restriction Option 90 7.6.4.6 Forwarding Options 91 7.6.4.7 No reply condition timer 91 7.6.4.8 - 7.6.4.14 Void 91 7.6.4.15 Forwarding information 91 7.6.4.16 Forwarding feature 91 7.6.4.17 Void 91 7.6.4.18 Call barring information 91 7.6.4.19 Call barring feature 92 7.6.4.20 New password 92 7.6.4.21 Current password 92 7.6.4.22 Guidance information 92 7.6.4.23 Void 92 7.6.4.24 SS-Info 92 7.6.4.25 - 7.6.4.35 Void 92 7.6.4.36 USSD Data Coding Scheme 93 7.6.4.37 USSD String 93 7.6.4.38 Bearer service 93 7,6,4.38A Bearer Service 2 93 7.6.4.39 Teleservice 93 7.6.4.39A Teleservice 2 93 7.6.4.40 Basic Service Group 93 7.6.4.41 eMLPP information 93 7.6.4.42 SS-event 93 7.6.4.43 SS-event data 94 7.6.4.44 LCS Privacy Exceptions 94 7.6.4.45 Mobile Originating Location Request (MO-LR) 94 7.6.4.46 NbrUser 94 7.6.4.47 MC Subscription Data 94 7.6.4.48 MC Information 94 7.6.4.49 CCBS Request State 95 7.6.4.50 Basic Service Group 2 95 7.6.5 Call parameters 95 7.6.5.1 Call reference number 95 7.6.5.2 Interrogation type 95 7.6.5.3 OR interrogation 95 7.6.5.4 OR capability 95 7.6.5.5 Forwarding reason 95 7.6.5.6 Forwarding interrogation required 96 7.6.5.7 O-CSI 96 7.6.5.7A D-CSI 96 7.6.5.7B T-CSI 96 7.6.5.7C VT-CSI 96 7.6.5.7D O-IM-CSI 96 7.6.5.7E D-IM-CSI 96 7.6.5.7F VT-IM-CSI 96 7.6.5.8 Void 96 7.6.5.9 Void 96 7.6.5.10 Void 96 7.6.5.11 CCBS Feature 96 7.6.5.12 UU Data 97 7.6.5.14 Number Portability Status 97 7.6.5.15 Pre-paging supported 97 7.6.5.16 MT Roaming Retry Supported 97 7.6.5.17 MT Roaming Retry 97 7.6.5.18 Paging Area 97 7.6.5.19 Call Priority 97 7.6.5.20 MTRF Supported 97 7.6.5.21 LCLS Global Call Reference (LCLS GCR) 97 7.6.5.22 LCLS-Negotiation 97 7.6.5.23 LCLS-Configuration-Preference 97 7.6.6 Radio parameters 97 7.6.6.1 - 7.6.6.3 Void 98 7.6.6.4 GERAN Classmark 98 7.6.6.5 BSSMAP Service Handover 98 7.6.6.5A BSSMAP Service Handover List 98 7.6.6.6 RANAP Service Handover 98 7.6.6.7 HO-Number Not Required 98 7.6.6.8 Integrity Protection Information 98 7.6.6.9 Encryption Information 98 7.6.6.10 Radio Resource Information 98 7.6.6.10A Radio Resource List 98 7.6.6.10B Chosen Radio Resource Information 98 7.6.6.11 Key Status 98 7.6.6.12 Selected UMTS Algorithms 98 7.6.6.13 Allowed GSM Algorithms 98 7.6.6.14 Allowed UMTS Algorithms 99 7.6.6.15 Selected GSM Algorithm 99 7.6.6.16 Iu-Currently Used Codec 99 7.6.6.17 Iu-Supported Codecs List 99 7.6.6.17A Iu-Available Codecs List 99 7.6.6.18 Iu-Selected Codec 99 7.6.6.19 RAB Configuration Indicator 99 7.6.6.20 UESBI-Iu 99 7.6.6.21 Alternative Channel Type 99 7.6.6.22 AoIP-Supported Codecs List Anchor 99 7.6.6.23 AoIP-Available Codecs List Map 99 7.6.6.24 AoIP-Selected Codec Target 99 7.6.7 Authentication parameters 100 7.6.7.1 Authentication set list 100 7.6.7.2 Rand 100 7.6.7.3 Sres 100 7.6.7.4 Kc 100 7.6.7.5 Xres 100 7.6.7.5A Ck 100 7.6.7.5B Ik 100 7.6.7.5C Autn 100 7.6.7.5D KASME 100 7.6.7.6 Cksn 100 7.6.7.6A Ksi 100 7.6.7.6B Auts 100 7.6.7.7 Ciphering mode 101 7.6.7.8 Current Security Context 101 7.6.7.9 Failure cause 101 7.6.7.10 Re-attempt 101 7.6.7.11 Access Type 101 7.6.8 Short message parameters 101 7.6.8.1 SM-RP-DA 101 7.6.8.2 SM-RP-OA 101 7.6.8.3 MWD status 101 7.6.8.4 SM-RP-UI 102 7.6.8.5 SM-RP-PRI 102 7.6.8.6 SM Delivery Outcome 102 7.6.8.7 More Messages To Send 102 7.6.8.8 Alert Reason 102 7.6.8.9 Absent Subscriber Diagnostic SM 102 7.6.8.10 Alert Reason Indicator 102 7.6.8.10A Additional Alert Reason Indicator 102 7.6.8.11 Additional SM Delivery Outcome 102 7.6.8.12 Additional Absent Subscriber Diagnostic SM 102 7.6.8.13 Delivery Outcome Indicator 103 7.6.8.14 GPRS Node Indicator 103 7.6.8.14A IMS Node Indicator 103 7.6.8.15 GPRS Support Indicator 103 7.6.8.16 SM-RP-MTI 103 7.6.8.17 SM-RP-SMEA 103 7.6.8.18 IP-SM-GW SM Delivery Outcome 103 7.6.8.19 IP-SM-GW Absent Subscriber Diagnostic SM 103 7.6.8.20 IP-SM-GW Indicator 103 7.6.8.21 SM Delivery Timer 103 7.6.8.22 SM Delivery Start Time 103 7.6.8.23 Maximum Retransmission Time 103 7.6.8.24 Requested Retransmission Time 103 7.6.8.25 Maximum UE Availability Time 104 7.6.8.26 SMS-GMSC Alert Event 104 7.6.8.27 SMS-GMSC Address 104 7.6.8.28 SMS-GMSC Diameter Address 104 7.6.8.29 New SGSN Number 104 7.6.8.30 New MME Number 104 7.6.8.31 New SGSN Diameter Address 104 7.6.8.32 New MME Diameter Address 104 7.6.8.33 New MSC Number 104 7.6.8.34 SMSF 3GPP Absent Subscriber Diagnostic SM 104 7.6.8.35 SMSF Non 3GPP Absent Subscriber Diagnostic SM 104 7.6.8.36 SMSF 3GPP Delivery Outcome Indicator 104 7.6.8.37 SMSF Non-3GPP Delivery Outcome Indicator 105 7.6.8.38 SMSF 3GPP SM Delivery Outcome 105 7.6.8.39 SMSF Non-3GPP SM Delivery Outcome 105 7.6.8.40 SMSF 3GPP Absent Subscriber Diagnostic SM 105 7.6.8.41 SMSF Non 3GPP Absent Subscriber Diagnostic SM 105 7.6.9 Access and signalling system related parameters 105 7.6.9.1 AN-apdu 105 7.6.9.2 CM service type 105 7.6.9.3 Access connection status 105 7.6.9.4 External Signal Information 106 7.6.9.5 Access signalling information 106 7.6.9.6 Location update type 106 7.6.9.7 Protocol ID 106 7.6.9.8 Network signal information 106 7.6.9.8A Network signal information 2 107 7.6.9.9 Call Info 107 7.6.9.10 Additional signal info 107 7.6.10 System operations parameters 107 7.6.10.1 Network resources 108 7.6.10.2 Trace reference 108 7.6.10.2A Trace reference 2 108 7.6.10.3 Trace type 108 7.6.10.4 Additional network resources 108 7.6.10.5 Trace depth list 108 7.6.10.6 Trace NE type list 108 7.6.10.7 Trace interface list 108 7.6.10.8 Trace event list 108 7.6.10.9 Trace support indicator 109 7.6.10.10 Trace Propagation List 109 7.6.10.11 MDT-Configuration 109 7.6.10.12 MDT User Consent 109 7.6.11 Location Service Parameters 109 7.6.11.1 Age of Location Estimate 109 7.6.11.2 Deferred MT-LR Response Indicator 109 7.6.11.3 Deferred MT-LR Data 109 7.6.11.4 LCS Client ID 109 7.6.11.5 LCS Event 109 7.6.11.7 LCS Priority 109 7.6.11.8 LCS QoS 109 7.6.11.9 CS LCS Not Supported by UE 110 7.6.11.10 PS LCS Not Supported by UE 110 7.6.11.11 Location Estimate 110 7.6.11.11A GERAN Positioning Data 110 7.6.11.11B UTRAN Positioning Data 110 7.6.11.11C GERAN GANSS Positioning Data 111 7.6.11.11D UTRAN GANSS Positioning Data 111 7.6.11.11E UTRAN Additional Positioning Data 111 7.6.11.11F UTRAN Barometric Pressure Measurement 111 7.6.11.11G UTRAN Civic Address 111 7.6.11.12 Location Type 111 7.6.11.13 NA-ESRD 111 7.6.11.14 NA-ESRK 111 7.6.11.15 LCS Service Type Id 111 7.6.11.16 Privacy Override 111 7.6.11.17 Supported LCS Capability Sets 112 7.6.11.18 LCS Codeword 112 7.6.11.19 NA-ESRK Request 112 7.6.11.20 Supported GAD Shapes 112 7.6.11.21 Additional Location Estimate 112 7.6.11.22 Cell Id Or SAI 112 7.6.11.23 LCS-Reference Number 112 7.6.11.24 LCS Privacy Check 112 7.6.11.25 Additional LCS Capability Sets 113 7.6.11.26 Area Event Info 113 7.6.11.27 Velocity Estimate 113 7.6.11.28 Accuracy Fulfilment Indicator 113 7.6.11.29 MO-LR Short Circuit Indicator 113 7.6.11.30 Reporting PLMN List 113 7.6.11.31 Periodic LDR information 113 7.6.11.32 Sequence Number 113 7.6.12 Void 113 7.7 Representation of a list of a basic parameter in service-primitives 114 8 Mobility services 114 8.1 Location management services 114 8.1.1 Void 114 8.1.1.1 Void 114 8.1.1.2 Void 114 8.1.1.3 Void 114 8.1.2 MAP_UPDATE_LOCATION service 114 8.1.2.1 Definition 114 8.1.2.2 Service primitives 114 8.1.2.3 Parameter definitions and use 115 8.1.3 MAP_CANCEL_LOCATION service 118 8.1.3.1 Definition 118 8.1.3.2 Service primitives 118 8.1.3.3 Parameter definitions and use 118 8.1.4 MAP_SEND_IDENTIFICATION service 119 8.1.4.1 Definition 119 8.1.4.2 Service primitives 119 8.1.4.3 Parameter definitions and use 120 8.1.5 Void 121 8.1.5.1 Void 121 8.1.5.2 Void 121 8.1.5.3 Void 121 8.1.6 MAP_PURGE_MS service 121 8.1.6.1 Definition 121 8.1.6.2 Service primitives 122 8.1.6.3 Parameter definitions and use 122 8.1.7 MAP_UPDATE_GPRS_LOCATION service 123 8.1.7.1 Definition 123 8.1.7.2 Service primitives 123 8.1.7.3 Parameter definitions and use 124 8.1.8 MAP-NOTE-MM-EVENT 128 8.1.8.1 Definition 128 8.1.8.2 Service primitives 128 8.1.8.3 Parameter use 129 8.1.9 MAP_UPDATE_VCSG_LOCATION service 130 8.1.9.1 Definition 130 8.1.9.2 Service primitives 130 8.1.9.3 Parameter definitions and use 131 8.1.10 MAP_ CANCEL_VCSG_LOCATION service 131 8.1.10.1 Definition 131 8.1.10.2 Service primitives 131 8.1.10.3 Parameter definitions and use 132 8.2 Paging and search 132 8.2.1 MAP_PAGE service 132 8.2.1.1 Definition 132 8.2.1.2 Service primitives 132 8.2.1.3 Parameter definitions and use 132 8.2.2 MAP_SEARCH_FOR_MS service 133 8.2.2.1 Definition 133 8.2.2.2 Service primitives 133 8.2.2.3 Parameter definitions and use 133 8.3 Access management services 134 8.3.1 MAP_PROCESS_ACCESS_REQUEST service 134 8.3.1.1 Definition 134 8.3.1.2 Service primitives 134 8.3.1.3 Parameter definitions and use 134 8.4 Handover services 136 8.4.1 MAP_PREPARE_HANDOVER service 136 8.4.1.1 Definition 136 8.4.1.2 Service primitives 136 8.4.1.3 Parameter use 137 8.4.2 MAP_SEND_END_SIGNAL service 141 8.4.2.1 Definition 141 8.4.2.2 Service primitives 141 8.4.2.3 Parameter use 141 8.4.3 MAP_PROCESS_ACCESS_SIGNALLING service 141 8.4.3.1 Definition 141 8.4.3.2 Service primitives 141 8.4.3.3 Parameter use 142 8.4.4 MAP_FORWARD_ACCESS_SIGNALLING service 143 8.4.4.1 Definition 143 8.4.4.2 Service primitives 143 8.4.4.3 Parameter use 144 8.4.5 MAP_PREPARE_SUBSEQUENT_HANDOVER service 146 8.4.5.1 Definition 146 8.4.5.2 Service primitives 146 8.4.5.3 Parameter use 146 8.4.6 MAP_ALLOCATE_HANDOVER_NUMBER service 147 8.4.6.1 Definition 147 8.4.6.2 Service primitives 147 8.4.6.3 Parameter use 147 8.4.7 MAP_SEND_HANDOVER_REPORT service 148 8.4.7.1 Definition 148 8.4.7.2 Service primitives 148 8.4.7.3 Parameter use 148 8.5 Authentication management services 148 8.5.1 MAP_AUTHENTICATE service 148 8.5.1.1 Definition 148 8.5.1.2 Service primitives 149 8.5.1.3 Parameter use 149 8.5.2 MAP_SEND_AUTHENTICATION_INFO service 149 8.5.2.1 Definition 149 8.5.2.2 Service primitives 150 8.5.2.3 Parameter use 150 8.5.3 MAP_AUTHENTICATION_FAILURE_REPORT service 152 8.5.3.1 Definition 152 8.5.3.2 Service primitives 152 8.5.3.3 Parameter use 152 8.6 Security management services 153 8.6.1 MAP_SET_CIPHERING_MODE service 153 8.6.1.1 Definitions 153 8.6.1.2 Service primitives 153 8.6.1.3 Parameter use 153 8.7 International mobile equipment identities management services 154 8.7.1 MAP_CHECK_IMEI service 154 8.7.1.1 Definition 154 8.7.1.2 Service primitives 154 8.7.1.3 Parameter use 154 8.7.2 MAP_OBTAIN_IMEI service 155 8.7.2.1 Definition 155 8.7.2.2 Service primitives 155 8.7.2.3 Parameter use 155 8.8 Subscriber management services 156 8.8.1 MAP-INSERT-SUBSCRIBER-DATA service 156 8.8.1.1 Definition 156 8.8.1.2 Service primitives 157 8.8.1.3 Parameter use 158 8.8.1.4 Basic service information related to supplementary services 172 8.8.2 MAP-DELETE-SUBSCRIBER-DATA service 172 8.8.2.1 Definition 172 8.8.2.2 Service primitives 172 8.8.2.3 Parameter use 173 8.9 Identity management services 178 8.9.1 MAP-PROVIDE-IMSI service 178 8.9.1.1 Definition 178 8.9.1.2 Service primitives 178 8.9.1.3 Parameter use 178 8.9.2 MAP-FORWARD-NEW-TMSI service 178 8.9.2.1 Definition 178 8.9.2.2 Service primitives 179 8.9.2.3 Parameter use 179 8.10 Fault recovery services 179 8.10.1 MAP_RESET service 179 8.10.1.1 Definition 179 8.10.1.2 Service primitives 179 8.10.1.3 Parameter definition and use 179 8.10.2 MAP_FORWARD_CHECK_SS_INDICATION service 180 8.10.2.1 Definition 180 8.10.2.2 Service primitives 180 8.10.2.3 Parameter definition and use 180 8.10.3 MAP_RESTORE_DATA service 181 8.10.3.1 Definition 181 8.10.3.2 Service primitives 181 8.10.3.3 Parameter definitions and use 181 8.11 Subscriber Information services 183 8.11.1 MAP-ANY-TIME-INTERROGATION service 183 8.11.1.1 Definition 183 8.11.1.2 Service primitives 183 8.11.1.3 Parameter definition and use 184 8.11.2 MAP-PROVIDE-SUBSCRIBER-INFO service 185 8.11.2.1 Definition 185 8.11.2.2 Service primitives 185 8.11.2.3 Parameter definition and use 185 8.11.3 MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION service 186 8.11.3.1 Definition 186 8.11.3.2 Service primitives 186 8.11.3.3 Parameter definition and use 187 8.11.4 MAP-ANY-TIME-MODIFICATION service 188 8.11.4.1 Definition 188 8.11.4.2 Service primitives 188 8.11.4.3 Parameter definition and use 188 8.11.5 MAP-NOTE-SUBSCRIBER-DATA-MODIFIED service 189 8.11.5.1 Definition 189 8.11.5.2 Service primitives 189 8.11.5.3 Parameter definition and use 190 9 Operation and maintenance services 191 9.1 Subscriber tracing services 191 9.1.1 MAP-ACTIVATE-TRACE-MODE service 191 9.1.1.1 Definition 191 9.1.1.2 Service primitives 192 9.1.1.3 Parameter use 192 9.1.2 MAP-DEACTIVATE-TRACE-MODE service 193 9.1.2.1 Definition 193 9.1.2.2 Service primitives 193 9.1.2.3 Parameter use 193 9.1.3 MAP-TRACE-SUBSCRIBER-ACTIVITY service 194 9.1.3.1 Definition 194 9.1.3.2 Service primitives 194 9.1.3.3 Parameter use 194 9.2 Other operation and maintenance services 195 9.2.1 MAP-SEND-IMSI service 195 9.2.1.1 Definition 195 9.2.1.2 Service primitives 195 9.2.1.3 Parameter use 195 10 Call handling services 195 10.1 MAP_SEND_ROUTING_INFORMATION service 195 10.1.1 Definition 195 10.1.2 Service primitives 195 10.1.3 Parameter use 196 10.2 MAP_PROVIDE_ROAMING_NUMBER service 202 10.2.1 Definition 202 10.2.2 Service primitives 202 10.2.3 Parameter use 203 10.3 MAP_RESUME_CALL_HANDLING service 205 10.3.1 Definition 205 10.3.2 Service primitives 205 10.3.3 Parameter use 206 10.4 MAP_PREPARE_GROUP_CALL service 207 10.4.1 Definition 207 10.4.2 Service primitives 207 10.4.3 Parameter definitions and use 208 10.5 MAP_PROCESS_GROUP CALL_SIGNALLING service 209 10.5.1 Definitions 209 10.5.2 Service primitives 209 10.5.3 Parameter definitions and use 209 10.6 MAP_FORWARD_GROUP_CALL_SIGNALLING service 210 10.6.1 Definitions 210 10.6.2 Service primitives 210 10.6.3 Parameter definitions and use 210 10.7 MAP_SEND_GROUP_CALL_END_SIGNAL service 211 10.7.1 Definitions 211 10.7.2 Service primitives 212 10.7.3 Parameter definitions and use 212 10.7A MAP_SEND_GROUP_CALL_INFO service 212 10.7A.1 Definitions 212 10.7A.2 Service primitives 212 10.7A.3 Parameter definitions and use 213 10.8 Void 214 10.9 Void 214 10.10 MAP_SET_REPORTING_STATE service 214 10.10.1 Definition 214 10.10.2 Service primitives 214 10.10.3 Parameter use 214 10.11 MAP_STATUS_REPORT service 215 10.11.1 Definition 215 10.11.2 Service primitives 215 10.11.3 Parameter use 215 10.12 MAP_REMOTE_USER_FREE service 216 10.12.1 Definition 216 10.12.2 Service primitives 216 10.12.3 Parameter use 216 10.13 MAP_IST_ALERT service 217 10.13.1 Definition 217 10.13.2 Service primitives 217 10.13.3 Parameter use 217 10.14 MAP_IST_COMMAND service 218 10.14.1 Definition 218 10.14.2 Service primitives 218 10.14.3 Parameter use 218 10.15 MAP_RELEASE_RESOURCES service 219 10.15.1 Definition 219 10.15.2 Service primitives 219 10.15.3 Parameter use 219 11 Supplementary services related services 219 11.1 MAP_REGISTER_SS service 219 11.1.1 Definition 219 11.1.2 Service primitives 219 11.1.3 Parameter use 220 11.2 MAP_ERASE_SS service 221 11.2.1 Definition 221 11.2.2 Service primitives 221 11.2.3 Parameter use 221 11.3 MAP_ACTIVATE_SS service 222 11.3.1 Definition 222 11.3.2 Service primitives 222 11.3.3 Parameter use 222 11.4 MAP_DEACTIVATE_SS service 223 11.4.1 Definitions 223 11.4.2 Service primitives 224 11.4.3 Parameter use 224 11.5 MAP_INTERROGATE_SS service 225 11.5.1 Definitions 225 11.5.2 Service primitives 225 11.5.3 Parameter use 225 11.6 Void 227 11.7 MAP_REGISTER_PASSWORD service 227 11.7.1 Definitions 227 11.7.2 Service primitives 227 11.7.3 Parameter use 227 11.8 MAP_GET_PASSWORD service 228 11.8.1 Definitions 228 11.8.2 Service primitives 228 11.8.3 Parameter use 228 11.9 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service 228 11.9.1 Definitions 229 11.9.2 Service primitives 229 11.9.3 Parameter use 229 11.10 MAP_UNSTRUCTURED_SS_REQUEST service 230 11.10.1 Definitions 230 11.10.2 Service primitives 230 11.10.3 Parameter use 230 11.11 MAP_UNSTRUCTURED_SS_NOTIFY service 231 11.11.1 Definitions 231 11.11.2 Service primitives 231 11.11.3 Parameter use 231 11.12 MAP_SS_INVOCATION_NOTIFY 232 11.12.1 Definition 232 11.12.2 Service primitives 232 11.12.3 Parameter use 232 11.13 MAP_REGISTER_CC_ENTRY service 233 11.13.1 Definition 233 11.13.2 Service primitives 233 11.13.3 Parameter use 233 11.14 MAP_ERASE_CC_ENTRY service 234 11.14.1 Definition 234 11.14.2 Service primitives 234 11.14.3 Parameter use 234 12 Short message service management services 235 12.1 MAP-SEND-ROUTING-INFO-FOR-SM service 235 12.1.1 Definition 235 12.1.2 Service primitives 235 12.1.3 Parameter use 236 12.1.4 Identities of MT-SMS Target Nodes 239 12.2 MAP-MO-FORWARD-SHORT-MESSAGE service 240 12.2.1 Definition 240 12.2.2 Service primitives 240 12.2.3 Parameter use 240 12.3 MAP-REPORT-SM-DELIVERY-STATUS service 241 12.3.1 Definition 241 12.3.2 Service primitives 241 12.3.3 Parameter use 242 12.4 MAP-READY-FOR-SM service 244 12.4.1 Definition 244 12.4.2 Service primitives 244 12.4.3 Parameter use 245 12.5 MAP-ALERT-SERVICE-CENTRE service 245 12.5.1 Definition 245 12.5.2 Service primitives 246 12.5.3 Parameter use 246 12.6 MAP-INFORM-SERVICE-CENTRE service 248 12.6.1 Definition 248 12.6.2 Service primitives 249 12.6.3 Parameter use 249 12.7 MAP-SEND-INFO-FOR-MT-SMS service 249 12.7.1 Definition 249 12.7.2 Service primitives 250 12.7.3 Parameter use 250 12.8 MAP-SEND-INFO-FOR-MO-SMS service 250 12.8.1 Definition 251 12.8.2 Service primitives 251 12.8.3 Parameter use 251 12.9 MAP-MT-FORWARD-SHORT-MESSAGE service 251 12.9.1 Definition 251 12.9.2 Service primitives 251 12.9.3 Parameter use 252 12.10 MAP-MT-FORWARD-SM-FOR-VGCS service 254 12.10.1 Definition 254 12.10.2 Service primitives 254 12.10.3 Parameter use 254 13 Network-Requested PDP Context Activation services 255 13.1 MAP_SEND_ROUTING_INFO_FOR_GPRS service 255 13.1.1 Definition 255 13.1.2 Service primitives 255 13.1.3 Parameter definition and use 255 13.2 MAP_FAILURE_REPORT service 256 13.2.1 Definition 256 13.2.2 Service primitives 256 13.2.3 Parameter definition and use 256 13.3 MAP_NOTE_MS_PRESENT_FOR_GPRS service 257 13.3.1 Definition 257 13.3.2 Service primitives 257 13.3.3 Parameter definition and use 257 13A Location Service Management Services 258 13A.1 MAP-SEND-ROUTING-INFO-FOR-LCS Service 258 13A.1.1 Definition 258 13A.1.2 Service Primitives 258 13A.1.3 Parameter Use 259 13A.2 MAP-PROVIDE-SUBSCRIBER-LOCATION Service 260 13A.2.1 Definition 260 13A.2.2 Service Primitives 260 13A.2.3 Parameter Definition and Use 261 13A.3 MAP-SUBSCRIBER-LOCATION-REPORT Service 264 13A.3.1 Definition 264 13A.3.2 Service Primitives 264 13A.3.3 Parameter Definition and Use 265 13A.4 Void 268 13A.4.1 Void 268 13A.4.2 Void 268 13A.4.3 Void 268 13A.5 Void 268 13A.5.1 Void 268 13A.5.2 Void 268 13A.5.3 Void 268 13A.6 Void 268 13A.6.1 Void 269 13A.6.2 Void 269 13A.6.3 Void 269 13A.7 Void 269 13A.7.1 Void 269 13A.7.2 Void 269 13A.7.3 Void 269 13A.8 Void 269 13A.8.1 Void 269 13A.8.2 Void 269 13A.8.3 Void 269 13A.9 Void 269 13A.9.1 Void 269 13A.9.2 Void 269 13A.9.3 Void 269 14 General 269 14.1 Overview 269 14.2 Underlying services 269 14.3 Model 270 14.4 Conventions 270 15 Elements of procedure 270 15.1 Handling of unknown operations 270 15.2 Dialogue establishment 271 15.2.1 Behaviour at the initiating side 271 15.2.2 Behaviour at the responding side 272 15.3 Dialogue continuation 273 15.4 Load control 273 15.5 Procedures for MAP specific services 273 15.5.1 Service invocation 273 15.5.2 Void 274 15.5.3 Service invocation receipt 274 15.5.4 Void 274 15.5.5 Handling of components received from TC 274 15.6 SDL descriptions 274 16 Mapping on to TC services 307 16.1 Dialogue control 307 16.1.1 Directly mapped parameters 307 16.1.2 Use of other parameters of dialogue handling primitives 307 16.1.2.1 Dialogue Id 307 16.1.2.2 Application-context-name 307 16.1.2.3 User information 307 16.1.2.4 Component present 307 16.1.2.5 Termination 307 16.1.2.6 P-Abort-Cause 307 16.1.2.7 Quality of service 307 16.2 Service specific procedures 308 16.2.1 Directly mapped parameters 308 16.2.2 Use of other parameters of component handling primitives 308 16.2.2.1 Dialogue Id 308 16.2.2.2 Class 308 16.2.2.3 Linked Id 308 16.2.2.4 Operation 309 16.2.2.5 Error 310 16.2.2.6 Parameters 310 16.2.2.7 Time out 310 16.2.2.8 Last component 310 16.2.2.9 Problem code 310 16.2.2.9.1 Mapping to MAP User Error 310 16.2.2.9.2 Mapping to MAP Provider Error parameter 311 16.2.2.9.3 Mapping to diagnostic parameter 311 17 Abstract syntax of the MAP protocol 312 17.1 General 312 17.1.1 Encoding rules 312 17.1.2 Use of TC 312 17.1.2.1 Use of Global Operation and Error codes defined outside MAP 313 17.1.3 Use of information elements defined outside MAP 313 17.1.4 Compatibility considerations 313 17.1.5 Structure of the Abstract Syntax of MAP 314 17.1.6 Application Contexts 316 17.2 Operation packages 317 17.2.1 General aspects 317 17.2.2 Packages specifications 318 17.2.2.1 Location updating 318 17.2.2.2 Location cancellation 318 17.2.2.3 Roaming number enquiry 319 17.2.2.4 Information retrieval 319 17.2.2.5 Inter-VLR information retrieval 319 17.2.2.6 IMSI retrieval 319 17.2.2.7 Call control transfer 320 17.2.2.8 Void 320 17.2.2.9 Void 320 17.2.2.10 Interrogation 320 17.2.2.11 Void 320 17.2.2.12 Handover Control 320 17.2.2.13 Subscriber Data management stand alone 321 17.2.2.14 Equipment management 321 17.2.2.15 Subscriber data management 321 17.2.2.16 Location register restart 321 17.2.2.17 Tracing stand-alone 322 17.2.2.18 Functional SS handling 322 17.2.2.19 Tracing 322 17.2.2.20 Binding 322 17.2.2.21 Unstructured SS handling 323 17.2.2.22 MO Short message relay services 323 17.2.2.23 Short message gateway services 323 17.2.2.24 MT Short message relay services 324 17.2.2.25 Void 324 17.2.2.26 Message waiting data management 324 17.2.2.27 Alerting 324 17.2.2.28 Data restoration 324 17.2.2.29 Purging 325 17.2.2.30 Subscriber information enquiry 325 17.2.2.31 Any time information enquiry 325 17.2.2.32 Group Call Control 325 17.2.2.32A Group Call Info Retrieval 325 17.2.2.33 Void 326 17.2.2.34 Void 326 17.2.2.35 Gprs location updating 326 17.2.2.36 Gprs Interrogation 326 17.2.2.37 Failure reporting 326 17.2.2.38 GPRS notifying 326 17.2.2.39 Supplementary Service invocation notification 327 17.2.2.40 Set Reporting State 327 17.2.2.41 Status Report 327 17.2.2.42 Remote User Free 327 17.2.2.43 Call Completion 327 17.2.2.44 Location service gateway services 327 17.2.2.45 Location service enquiry 328 17.2.2.45A Location service reporting 328 17.2.2.46 Void 328 17.2.2.47 Void 328 17.2.2.48 Void 328 17.2.2.49 IST Alerting 328 17.2.2.50 Service Termination 328 17.2.2.51 Mobility Management event notification 329 17.2.2.53 Subscriber Data modification notification 329 17.2.2.54 Authentication Failure Report 329 17.2.2.55 Resource Management 329 17.2.2.56 MT Short message relay VGCS services 330 17.2.2.57 Vcsg location updating 330 17.2.2.58 Vcsg location cancellation 330 17.3 Application contexts 330 17.3.1 General aspects 330 17.3.2 Application context definitions 331 17.3.2.1 Void 331 17.3.2.2 Location Updating 331 17.3.2.3 Location Cancellation 331 17.3.2.4 Roaming number enquiry 332 17.3.2.5 Void 332 17.3.2.6 Location Information Retrieval 332 17.3.2.7 Call control transfer 332 17.3.2.8 Void 333 17.3.2.9 Void 333 17.3.2.10 Void 333 17.3.2.11 Location registers restart 333 17.3.2.12 Handover control 333 17.3.2.13 IMSI Retrieval 333 17.3.2.14 Equipment Management 334 17.3.2.15 Information retrieval 334 17.3.2.16 Inter-VLR information retrieval 334 17.3.2.17 Stand Alone Subscriber Data Management 335 17.3.2.18 Tracing 335 17.3.2.19 Network functional SS handling 335 17.3.2.20 Network unstructured SS handling 336 17.3.2.21 Short Message Gateway 336 17.3.2.22 Mobile originating Short Message Relay 336 17.3.2.23 Void 337 17.3.2.24 Short message alert 337 17.3.2.25 Short message waiting data management 337 17.3.2.26 Mobile terminating Short Message Relay 337 17.3.2.27 MS purging 338 17.3.2.28 Subscriber information enquiry 338 17.3.2.29 Any time information enquiry 338 17.3.2.30 Group Call Control 338 17.3.2.30A Group Call Info Retrieval 338 17.3.2.31 Void 339 17.3.2.32 Gprs Location Updating 339 17.3.2.33 Gprs Location Information Retreival 339 17.3.2.34 Failure Reporting 339 17.3.2.35 GPRS Notifying 339 17.3.2.36 Supplementary Service invocation notification 340 17.3.2.37 Reporting 340 17.3.2.38 Call Completion 340 17.3.2.39 Location Service Gateway 341 17.3.2.40 Location Service Enquiry 341 17.3.2.41 Void 341 17.3.2.42 Void 341 17.3.2.43 Void 341 17.3.2.44 IST Alerting 341 17.3.2.45 Service Termination 341 17.3.2.46 Mobility Management event notification 342 17.3.2.48 Subscriber Data modification notification 342 17.3.2.49 Authentication Failure Report 342 17.3.2.50 Resource Management 342 17.3.2.51 Mobile terminating Short Message Relay VGCS 343 17.3.2.52 Vcsg Location Updating 343 17.3.2.53 Vcsg Location Cancellation 343 17.3.3 ASN.1 Module for application-context-names 343 17.4 MAP Dialogue Information 346 17.5 MAP operation and error codes 348 17.6 MAP operations and errors 350 17.6.1 Mobile Service Operations 350 17.6.2 Operation and Maintenance Operations 357 17.6.3 Call Handling Operations 358 17.6.4 Supplementary service operations 361 17.6.5 Short message service operations 365 17.6.6 Errors 368 17.6.7 Group Call operations 374 17.6.8 Location service operations 376 17.6.9 Void 377 17.7 MAP constants and data types 377 17.7.1 Mobile Service data types 377 17.7.2 Operation and maintenance data types 426 17.7.3 Call handling data types 433 17.7.4 Supplementary service data types 439 17.7.5 Supplementary service codes 443 17.7.6 Short message data types 446 17.7.7 Error data types 452 17.7.8 Common data types 458 17.7.9 Teleservice Codes 467 17.7.10 Bearer Service Codes 468 17.7.11 Extension data types 470 17.7.12 Group Call data types 471 17.7.13 Location service data types 474 17.7.14 Void 484 18 General on MAP user procedures 485 18.1 Introduction 485 18.2 Common aspects of user procedure descriptions 485 18.2.1 General conventions 485 18.2.2 Naming conventions 485 18.2.3 Convention on primitives parameters 486 18.2.3.1 Open service 486 18.2.3.2 Close service 487 18.2.4 Version handling at dialogue establishment 487 18.2.4.1 Behaviour at the initiating side 487 18.2.4.2 Behaviour at the responding side 487 18.2.5 Abort Handling 487 18.2.6 SDL conventions 487 18.3 Interaction between MAP Provider and MAP Users 488 19 Mobility procedures 489 19.1 Location management Procedures 489 19.1.1 Location updating 490 19.1.1.1 General 490 19.1.1.2 Procedures in the VLR 495 19.1.1.3 Procedure in the PVLR 495 19.1.1.4 Procedure in the SGSN 495 19.1.1.5 Procedures in the HLR 496 19.1.1A Location updating for VCSG 516 19.1.1A.1 General 516 19.1.1A.2 Procedures in the VLR 516 19.1.1A.3 Procedures in the SGSN 516 19.1.1A.4 Procedures in the CSS 516 19.1.2 Location Cancellation 524 19.1.2.1 General 524 19.1.2.2 Procedure in the HLR 524 19.1.2.3 Procedure in the VLR 525 19.1.2.4 Procedure in the SGSN 525 19.1.2A Location Cancellation for VCSG 532 19.1.2A.1 General 532 19.1.2A.2 Procedure in the CSS 532 19.1.2A.3 Procedure in the VLR 532 19.1.2A.4 Procedure in the SGSN 532 19.1.3 Void 536 19.1.4 MS Purging 536 19.1.4.1 General 537 19.1.4.2 Procedure in the VLR 537 19.1.4.3 Procedure in the SGSN 537 19.1.4.4 Procedure in the HLR 538 19.2 Handover procedures 543 19.2.1 General 543 19.2.2 Procedure in MSC A 546 19.2.2.1 Basic handover 546 19.2.2.2 Handling of access signalling 547 19.2.2.3 Subsequent handover 547 19.2.3 Procedure in MSC B 547 19.2.3.1 Basic handover 548 19.2.3.2 Handling of access signalling 548 19.2.3.3 Subsequent handover 548 19.2.4 Macro Receive_Error_From_HO_CA 548 19.2.5 Procedure in VLR B 548 19.3 Fault recovery procedures 567 19.3.1 VLR fault recovery procedures 567 19.3.1.1 General 567 19.3.1.2 Procedure in the VLR 568 19.3.1.3 Procedure in the HLR 568 19.3.2 HLR fault recovery procedures 570 19.3.2.1 General 570 19.3.2.2 Procedure in the HLR 571 19.3.2.3 Procedure in the VLR 572 19.3.2.4 Procedure in the SGSN 572 19.3.3 CSS fault recovery procedures 578 19.3.3.1 General 578 19.3.3.2 Procedure in the CSS 579 19.3.3.3 Procedure in the VLR 579 19.3.3.4 Procedure in the SGSN 579 19.4 Mobility Management event notification procedure 584 19.4.1 General 584 19.4.2 Procedure in the VLR or SGSN 585 19.4.3 Procedure in the gsmSCF 585 19.5 HLR Insert Subscriber Data macros 588 19.5.1 Macro Insert_Subs_Data_Framed_HLR 588 19.5.2 Macro Insert_GPRS_Subs_Data_Framed_HLR 588 19.5A CSS Insert Subscriber Data macros 591 19.5A.1 Macro Insert_VCSG_Subs_Data_Framed_CSS 591 20 Operation and maintenance procedures 593 20.1 General 593 20.1.1 Tracing Co-ordinator for the VLR 593 20.1.2 Tracing Co-ordinator for the SGSN 593 20.1.3 Subscriber Data Management Co-ordinator for the VLR 593 20.1.4 Subscriber Data Management Co-ordinator for the SGSN 593 20.2 Tracing procedures 600 20.2.1 Subscriber tracing activation procedure 603 20.2.1.1 Procedures in the HLR 603 20.2.1.2 Procedure in the VLR 603 20.2.1.3 Procedure in the SGSN 603 20.2.2 Subscriber tracing deactivation procedure 603 20.2.2.1 Procedures in the HLR 603 20.2.2.2 Procedure in the VLR 604 20.2.2.3 Procedure in the SGSN 604 20.3 Subscriber data management procedures for HLR 617 20.3.1 Subscriber deletion procedure 618 20.3.1.1 Procedure in the HLR 618 20.3.1.2 Procedure in the VLR 618 20.3.1.3 Procedure in the SGSN 619 20.3.2 Subscriber data modification procedure 619 20.3.2.1 Procedure in the HLR 619 20.3.2.2 Procedures in the VLR 620 20.3.2.3 Procedures in the SGSN 620 20.3A Subscriber Data Management procedures for CSS 632 20.3A.1 Subscriber deletion procedure 633 20.3A.1.1 Procedure in the CSS 633 20.3A.1.2 Procedure in the VLR 633 20.3A.1.3 Procedure in the SGSN 633 20.3A.2 Subscriber data modification procedure 634 20.3A.2.1 Procedure in the CSS 634 20.3A.2.2 Procedures in the VLR 634 20.3A.2.3 Procedures in the SGSN 634 20.4 Subscriber Identity procedure 646 20.4.1 Procedure in the VLR 646 20.4.2 Procedure in the HLR 646 21 Call handling procedures 649 21.1 General 649 21.2 Retrieval of routing information 649 21.2.1 General 649 21.2.2 Procedure in the GMSC 653 21.2.9 Process in the gsmSCF 653 21.2.4 Procedure in the HLR 653 21.2.5 Procedure in the VLR to provide a roaming number 654 21.2.6 Procedure in the VLR to restore subscriber data 654 21.2.7 Procedure in the VLR to provide subscriber information 654 21.2.8 Procedure in the old VLR to request a Roaming Number (MTRF) 654 21.3 Transfer of call handling 664 21.3.1 General 664 21.3.2 Process in the VMSC 664 21.3.3 Process in the GMSC 665 21.4 Inter MSC Group Call Procedures 668 21.4.1 General 668 21.4.2 Process in the Anchor MSC 668 21.4.3 Process in the Relay MSC 669 21.4A Inter MSC Group Call Info Retrieval 674 21.4A.1 General 674 21.4A.2 Process in the MSC 674 21.5 Void 677 21.6 CCBS: monitoring and reporting the status of the subscriber 677 21.6.1 Reporting co-ordinator process in the VLR 677 21.6.2 Setting the reporting state Ð stand-alone 677 21.6.2.1 Process in the HLR 677 21.6.2.2 Process in the VLR 677 21.6.3 Status Reporting 677 21.6.3.1 Process in the VLR 678 21.6.3.2 Process in the HLR 679 21.6.4 CCBS: Remote User Free 679 21.6.4.1 Process in the HLR 680 21.6.3.2 Process in the VLR 680 21.7 Void 693 21.8 Void 693 21.9 Immediate Service Termination (IST) 693 21.9.1 IST Alert 693 21.9.1.1 Procedure in the MSC 693 21.9.1.2 Procedure in the HLR 693 21.9.2 IST Command 693 21.9.2.1 Procedure in the HLR 694 21.9.2.2 Procedure in the MSC 694 21.10 Resource Management 699 21.10.1 General 699 21.3.2 Process in the GMSC 699 21.3.3 Process in the VMSC 699 22 Supplementary services procedures 702 22.1 Supplementary service co-ordinator processes 702 22.1.1 Supplementary service co-ordinator process for the MSC 702 22.1.2 Void 702 22.1.3 Functional supplementary service co-ordinator process for the HLR 702 22.1.4 Call completion supplementary service co-ordinator process for the HLR 702 22.2 Registration procedure 707 22.2.1 General 707 22.2.2 Procedure in the MSC 708 22.2.3 Procedure in the VLR 708 22.2.4 Procedure in the HLR 708 22.3 Erasure procedure 714 22.3.1 General 714 22.3.2 Procedure in the MSC 715 22.3.3 Procedure in the VLR 715 22.3.4 Procedure in the HLR 715 22.4 Activation procedure 715 22.4.1 General 715 22.4.2 Procedure in the MSC 716 22.4.3 Procedure in the VLR 717 22.4.4 Procedure in the HLR 717 22.5 Deactivation procedure 723 22.5.1 General 723 22.5.2 Procedure in the MSC 724 22.5.3 Procedures in the VLR 724 22.5.4 Procedures in the HLR 724 22.6 Interrogation procedure 724 22.6.1 General 724 22.6.2 Procedure in the MSC 725 22.6.3 Procedures in the VLR 725 22.6.4 Procedure in the HLR 726 22.7 Void 730 22.8 Password registration procedure 731 22.8.1 General 731 22.8.2 Procedure in the MSC 733 22.8.3 Procedure in the VLR 733 22.8.4 Procedure in the HLR 733 22.9 Mobile Initiated USSD procedure 736 22.9.1 General 736 22.9.2 Procedure in the MSC 736 22.9.3 Procedure in the VLR 736 22.9.4 Procedure in the HLR 737 22.9.5 Procedures in the gsmSCF/secondary HLR 737 22.10 Network initiated USSD procedure 751 22.10.1 General 751 22.10.2 Procedure in the MSC 751 22.10.3 Procedure in the VLR 751 22.10.4 Procedure in the HLR 752 22.10.5 Procedure in the gsmSCF or secondary HLR 752 22.11 Common macros for clauseÊ22 772 22.11.1 SS Password handling macros 772 22.11.2 Void 772 22.12 Supplementary Service Invocation Notification procedure 776 22.12.1 General 776 22.12.2 Procedure in the MSC 776 22.12.3 Procedure in the gsmSCF 776 22.13 Activation of a CCBS request 779 22.13.1 General 779 22.13.2 Procedure in the VLR 779 22.13.3 Procedure in the HLR 779 22.14 Deactivation of a CCBS"
"request 782 22.14.1 General 782 22.14.2 Procedure in the VLR 782 22.14.3 Procedure in the HLR 782 23 Short message service procedures 785 23.1 General 785 23.1.1 Mobile originated short message service Co-ordinator for the MSC 785 23.1.2 Short message Gateway Co-ordinator for the HLR 785 23.2 The mobile originated short message transfer procedure 790 23.2.1 Procedure in the serving MSC 791 23.2.2 Procedure in the VLR 791 23.2.3 Procedure in the SGSN 791 23.2.4 Procedure in the SMS Interworking MSC (SMS-IWMSC) 792 23.3 The mobile terminated short message transfer procedure 804 23.3.1 Procedure in the SMS-GMSC 811 23.3.2 Procedure in the HLR 813 23.3.3 Procedure in the Serving MSC 813 23.3.4 Procedure in the VLR 814 23.3.5 Procedure in the SGSN 814 23.3.6 Procedure in the SMS Router 815 23.3.7 Procedure in the IP-SM-GW 816 23.4 The Short Message Alert procedure 862 23.4.1 Procedure in the Serving MSC Ð the MS has memory available 864 23.4.2 Procedures in the VLR 864 23.4.2.1 The Mobile Subscriber is present 864 23.4.2.2 The MS has memory available 864 23.4.3 Procedures in the SGSN 865 23.4.3.1 The Mobile Subscriber is present 865 23.4.3.2 The Mobile Equipment has memory available 865 23.4.4 Procedure in the HLR 865 23.4.5 Procedure in the SMS Interworking MSC 865 23.5 The SM delivery status report procedure 874 23.5.1 Procedure in the SMS-GMSC 874 23.5.2 Procedure in the HLR 874 23.5.3 Procedure in the IP-SM-GW 875 23.6 The macro Report_SM_Delivery_Stat_HLR 880 23.7 The mobile terminated short message transfer procedure for VGCS 883 23.7.1 Procedure in the SMS-GMSC 884 23.7.2 Procedure in the Anchor MSC 884 24 GPRS process description 888 24.1 Procedure for retrieval of routeing information for GPRS 889 24.1.1 Process in the GGSN 889 24.1.2 Process in the HLR 889 24.2 Procedure for reporting failure to establish a network requested PDP context 892 24.2.1 Process in the GGSN 892 24.2.2 Process in the HLR 892 24.3 Procedure for reporting that an MS has become reachable for GPRS 895 24.3.1 Process in the HLR 895 24.3.2 Process in the GGSN for Note Ms Present For Gprs 895 24A CSE interrogation and control of subscriber data 898 24A.1 General 898 24A.2 Any Time Subscription Interrogation procedure 900 24A.2.1 General 900 24A.2.2 Process in the gsmSCF 900 24A.2.3 Process in the HLR 900 24A.3 Any Time Modification procedure 903 24A.3.1 General 903 24A.3.2 Process in the gsmSCF 903 24A.3.3 Process in the HLR 903 24A.4 Subscriber Data Modification Notification procedure 906 24A.4.1 General 906 24A.4.2 Process in the HLR 906 24A.4.3 Process in the gsmSCF 906 24A.5 Any Time Interrogation procedure 911 24A.5.1 General 911 24A.5.2 Procedures in the gsmSCF 912 24A.5.3 Procedure in the HLR 912 24A.5.4 Procedure in the GMLC 912 24B Location Services process description 918 24B.1 Routeing information retrieval procedure for LCS 918 24B.1.1 General 918 24B.1.2 Process in the GMLC 918 24B.1.3 Process in the HLR 918 24B.2 Provide Subscriber Location procedure 921 24B.2.1 General 921 24B.2.2 Process in the GMLC 921 24B.2.3 Process in the MSC 921 24B.2.4 Process in the SGSN 921 24B.3 Subscriber Location Report procedure 925 24B.3.1 General 925 24B.3.2 Process in the MSC 925 24B.3.3 Process in the SGSN 925 24B.3.4 Process in the GMLC 925 25 General macro description 929 25.1 MAP_OPEN handling macros 929 25.1.1 Macro Receive_Open_Ind 929 25.1.2 Macro Receive_Open_Cnf 929 25.2 Macros to check the content of indication and confirmation primitives 934 25.2.1 Macro Check_Indication 934 25.2.2 Macro Check_Confirmation 934 25.3 The page and search macros 937 25.3.1 Macro PAGE_MSC 937 25.3.2 Macro Search_For_MS_MSC 937 25.4 Macros for handling an Access Request 940 25.4.1 Macro Process_Access_Request_MSC 940 25.4.2 Macro Process_Access_Request_VLR 940 25.4.3 Macro Obtain_Identity_VLR 940 25.4.4 Process Update_Location_Child_VLR 940 25.5 Authentication macros and processes 950 25.5.1 Macro Authenticate_MSC 950 25.5.2 Macro Authenticate_VLR 950 25.5.3 Macro Obtain_Authent_Params_VLR 950 25.5.4 Process Obtain_Authentication_Sets_VLR 950 25.5.5 Process Obtain_Authent_Sets_SGSN 950 25.5.6 Process Obtain_Authent_Sets_HLR 950 25.5.7 Authentication Failure Reporting 951 25.5.7.1 General 951 25.5.7.2 Process in the VLR 951 25.5.7.3 Process in the SGSN 951 25.5.7.4 Process in the HLR 951 25.6 IMEI Handling Macros 967 25.6.1 Macro Check_IMEI_MSC 967 25.6.2 Macro Check_IMEI_VLR 967 25.6.3 Process Check_IMEI_SGSN 967 25.6.4 Process Check_IMEI_EIR 967 25.6.5 Macro Obtain_IMEI_MSC 967 25.6.6 Macro Obtain_IMEI_VLR 967 25.7 Insert Subscriber Data macros and processes 976 25.7.1 Macro Insert_Subs_Data_VLR 976 25.7.2 Macro Insert_Subs_Data_SGSN 976 25.7.3 Process Insert_Subs_Data_Stand_Alone_HLR 976 25.7.4 Process Insert_GPRS_Subs_Data_Stand_Alone_HLR 976 25.7.5 Macro Wait_for_Insert_Subs_Data_Cnf 977 25.7.6 Macro Wait_for_Insert_GPRS_Subs_Data_Cnf 977 25.7.7 Process Send_Insert_Subs_Data_HLR 977 25.7.8 Process Insert_VCSG_Subs_Data_Stand_Alone_CSS 977 25.7.9 Macro Wait_for_Insert_VCSG_Subs_Data_Cnf 977 25.7.10 Process Send_Insert_VCSG_Subs_Data_CSS 977 25.8 Request IMSI Macros 991 25.8.1 Macro Obtain_IMSI_MSC 991 25.8.2 Macro Obtain_IMSI_VLR 991 25.9 Tracing macros 994 25.9.1 Macro Trace_Subscriber_Activity_MSC 994 25.9.2 Macro Trace_Subscriber_Activity_VLR 994 25.9.3 Macro Trace_Subscriber_Activity_SGSN 994 25.9.4 Macro Activate_Tracing_VLR 994 25.9.5 Macro Activate_Tracing_SGSN 994 25.9.6 Macro Control_Tracing_With_VLR_HLR 994 25.9.7 Macro Control_Tracing_With_SGSN_HLR 994 25.10 Short Message Alert procedures 1002 25.10.1 Process Subscriber_Present_VLR 1002 25.10.2 Process SubscriberPresent_SGSN 1002 25.10.3 Macro Alert_Service_Centre_HLR 1002 25.10.4 Process Alert_SC_HLR 1002 Annex A (informative): ASN.1 Cross-reference listing and fully expanded sources 1006 Annex B (informative): Void 1007 Annex C (informative): Message Segmentation Mechanisms 1008 C.1 SCCP segmentation 1008 C.2 TCAP segmentation 1008 C.2.1 Empty Begin 1008 C.2.2 Empty Continue 1008 C.2.3 TC-Result-NL 1008 C.3 MAP Segmentation 1009 C.3.1 Invoke without explicit indication 1009 C.3.2 Invoke with explicit indication 1009 C.3.3 Result 1009 Annex D (informative): Void 1014 Annex E (informative): Change History 1015 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope It is necessary to transfer between entities of a Public Land Mobile Network (PLMN) information specific to the PLMN in order to deal with the specific behaviour of roaming Mobile Stations (MS)s. The Signalling System No. 7 specified by CCITT is used to transfer this information. The present document describes the requirements for the signalling system and the procedures needed at the application level in order to fulfil these signalling needs. Clauses 1 to 6 are related to general aspects such as terminology, mobile network configuration and other protocols required by MAP. MAP consists of a set of MAP services that are provided to MAP service-users by a MAP service-provider. FigureÊ1.1/1: Modelling principles Clauses 7 to 13A of the present document describe the MAP services. Clauses 14 to 17 define the MAP protocol specification and the behaviour of service provider (protocol elements to be used to provide MAP services, mapping on to TC service primitives, abstract syntaxes, etc.). Clauses 18 to 25 describe the MAP user procedures that make use of MAP services. The present document specifies functions, procedures and information which apply to GERAN Iu mode. However, functionality related to GERAN Iu mode is neither maintained nor enhanced. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TRÊ21.905: ""Vocabulary for 3GPP Specifications"". [2] 3GPP TS 22.001: ""Digital cellular telecommunications system (PhaseÊ2+); Principles of telecommunication services supported by a Public Land Mobile Network (PLMN)"". [3] 3GPP TSÊ22.002: ""Bearer Services Supported by a Public Land Mobile Network (PLMN)"". [4] 3GPP TS 22.003: ""Circuit Teleservices Supported by a Public Land Mobile Network (PLMN)"". [5] 3GPP TSÊ22.004: ""General on Supplementary Services"". [6] 3GPP TS 42.009: ""Digital cellular telecommunications system (PhaseÊ2+); Security aspects"". [7] 3GPP TSÊ22.016: ""International Mobile station Equipment Identities (IMEI)"". [8] 3GPP TSÊ22.041: ""Operator Determined Barring"". [9] 3GPP TSÊ22.081: ""Line identification supplementary services - StageÊ1"". [10] 3GPP TSÊ22.082: ""Call Forwarding (CF) supplementary services - StageÊ1"". [11] 3GPP TSÊ22.083: ""Call Waiting (CW) and Call Hold (HOLD) Supplementary Services - StageÊ1"". [12] 3GPP TSÊ22.084: ""Multi Party (MPTY) Supplementary Services - StageÊ1"". [13] 3GPP TSÊ22.085: ""Closed User Group (CUG) supplementary services - StageÊ1"". [14] 3GPP TSÊ22.086: ""Advice of charge (AoC) Supplementary Services - StageÊ1"". [15] 3GPP TSÊ22.088: ""Call Barring (CB) supplementary services - StageÊ1"". [16] 3GPP TSÊ22.090: ""Unstructured Supplementary Service Data (USSD); - StageÊ1"". [17] 3GPP TSÊ23.003: ""Numbering, addressing and identification"". [18] Void [19] 3GPP TSÊ23.007: ""Restoration procedures"". [20] 3GPP TSÊ23.008: ""Organisation of subscriber data"". [21] 3GPP TSÊ23.009: ""Handover procedures"". [22] 3GPP TSÊ23.011: ""Technical realization of Supplementary Services - General Aspects"". [23] 3GPP TSÊ23.012: ""Location management procedures"". [24] 3GPP TS 43.020: ""Security related network functions"". [25] 3GPP TSÊ23.038: ""Alphabets and language"". [25a] 3GPP TSÊ23.039: ""Interface protocols for the connection of Short Message Service Centres (SMSCs) to Short Message Entities (SMEs)"". [26] 3GPP TSÊ23.040: ""Technical realization of the Short Message Service (SMS) Point to Point (PP)"". [26a] 3GPP TSÊ23.271: ""Functional stage2 description of LCS"". [27] 3GPP TSÊ23.081: ""Line Identification Supplementary Services - StageÊ2"". [28] 3GPP TSÊ23.082: ""Call Forwarding (CF) Supplementary Services - StageÊ2"". [29] 3GPP TSÊ23.083: ""Call WaitingÊ(CW) and Call Hold (HOLD) Supplementary Services - StageÊ2"". [30] 3GPP TSÊ23.084: ""Multi Party (MPTY) Supplementary Services - StageÊ2"". [31] 3GPP TSÊ23.085: ""Closed User Group (CUG) Supplementary Services - StageÊ2"". [32] 3GPP TSÊ23.086: ""Advice of Charge (AoC) Supplementary Services - StageÊ2"". [33] 3GPP TSÊ23.088: ""Call Barring (CB) Supplementary Services - StageÊ2"". [34] 3GPP TSÊ23.090: ""Unstructured Supplementary Services Data (USSD) - StageÊ2"". [34a] 3GPP TS 33.204: ""3G Security; Network domain security; TCAP user security"". [35] 3GPP TSÊ24.008: ""Mobile Radio Interface Layer 3 specification; Core Network Protocols - Stage 3"". [36] 3GPP TSÊ24.010: ""Mobile radio interface layer 3 Supplementary Services specification - General aspects"". [37] 3GPP TSÊ24.011: ""Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface"". [37a] 3GPP TS 44.071: ""Location Services (LCS) Ð stage 3"". [38] 3GPP TSÊ24.080: ""Mobile radio interface layer 3 supplementary services specification - Formats and coding"". [39] 3GPP TSÊ24.081: ""Line identification supplementary services - StageÊ3"". [40] 3GPP TSÊ24.082: ""Call Forwarding (CF) Supplementary Services - StageÊ3"". [41] 3GPP TSÊ24.083: ""Call Waiting (CW) and Call Hold (HOLD) supplementary services - StageÊ3"". [42] 3GPP TSÊ24.084: ""Multi Party (MPTY) Supplementary Services - StageÊ3"". [43] 3GPP TSÊ24.085: ""Closed User Group (CUG) Supplementary Services - StageÊ3"". [44] 3GPP TSÊ24.086: ""Advice of Charge (AoC) Supplementary Services - StageÊ3"". [45] 3GPP TSÊ24.088: ""Call Barring (CB) Supplementary Services - StageÊ3"". [46] 3GPP TSÊ24.090: ""Unstructured Supplementary Services Data - StageÊ3"". [47] 3GPP TS 48.002: "" Base Station System - Mobile-services Switching Centre (BSS - MSC) interface principles"". [48] 3GPP TS 48.006: ""Signalling transport mechanism specification for the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface"". [49] 3GPP TS 48.008: ""Mobile Switching Centre - Base Station System (MSC - BSS) interface; Layer 3 specification"". [49a1] 3GPP TS 48.031: ""Location Services (LCS); Serving Mobile Location Centre (SMLC) Ð Serving Mobile Location Centre (SMLC); SMLC Peer Protocol (SMLCPP)"". [49b] 3GPP TS 48.071: ""Location Services (LCS); Serving Mobile Location Centre - Base Station System (SMLC - BSS) interface Layer 3 specification"". [50] 3GPP TS 49.001: ""General network interworking scenarios"". [51] 3GPP TSÊ29.002: ""Mobile Application Part (MAP) specification"". [52] Void [53] Void [54] Void [55] 3GPP TSÊ29.006: ""Interworking between a Public Land Mobile Network (PLMN) and a Packet Switched Public Data Network/Integrated Services Digital Network (PSPDN/ISDN) for the support of Packet Switched data transmission services"". [56] 3GPP TSÊ29.007: ""General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone NetworkÊ(PSTN)"". [57] 3GPP TS 29.008: ""Application of the Base Station System Application Part (BSSAP) on the E-interface"". [58] 3GPP TSÊ29.010: ""Information element mapping between Mobile Station - Base Station System and BSS Mobile-services Switching Centre (MS - BSS - MSC) Signalling procedures and the Mobile Application Part (MAP)"". [59] 3GPP TSÊ29.011: ""Signalling interworking for Supplementary Services"". [59a] 3GPP TS 49.031: ""Digital cellular telecommunications system (PhaseÊ2+); Location Services (LCS); Base Station System Application Part LCS Extension (BSSAP-LE)"". [60] Void [61] 3GPP TSÊ52.008: ""GSM Subscriber and Equipment Trace"". [62] ETSÊ300Ê102-1Ê(1990): ""Integrated Services Digital Network (ISDN); User-network interface layer 3 specifications for basic call control"". [63] ETSÊ300Ê136Ê(1992): ""Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service description"". [64] ETSÊ300Ê138Ê(1992): ""Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service Digital Subscriber Signalling System No.one (DSS1) protocol"". [65] ETSÊ300Ê287: ""Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2"". [66] ETRÊ060: ""Signalling Protocols and Switching (SPS); Guide-lines for using Abstract Syntax Notation One (ASN.1) in telecommunication application protocols"". [66b] ETR 091: ""ETSI object identifier tree; Common domain Mobile domain"" [67] ITU-TÊRecommendationÊE.164: ""The international public telecommunication numbering plan"". [68] ITU-TÊRecommendationÊE.212: ""The international identification plan for mobile terminals and mobile users"". [69] ITU-TÊRecommendationÊE.213: ""Telephone and ISDN numbering plan for land mobile stations in public land mobile networks (PLMN) "". [70] ITU-TÊRecommendationÊE.214: ""Structure of the land mobile global title for the signalling connection control part (SCCP) "". [71] ITU-TÊRecommendationÊQ.699: ""Interworking between ISDN access and non-ISDN access over ISDN User Part of Signalling System No.Ê7 "". [72] ITU-TÊRecommendationÊQ.711: ""Specifications of Signalling System No.7; Functional description of the Signalling Connection Control Part"". [73] ITU-TÊRecommendationÊQ.712: ""Definition and function of SCCP messages"". [74] ITU-TÊRecommendationÊQ.713: ""Specifications of Signalling System No.7; SCCP formats and codes"". [75] ITU-TÊRecommendationÊQ.714: ""Specifications of Signalling System No.7; Signalling Connection Control Part procedures"". [76] ITU-TÊRecommendationÊQ.716: ""Specifications of Signalling System No.7; Signalling connection control part (SCCP) performances"". [77] ITU-TÊRecommendationÊQ.721Ê(1988): ""Specifications of Signalling System No.7; Functional description of the Signalling System No.7 Telephone user part"". [78] ITU-TÊRecommendationÊQ.722Ê(1988): ""Specifications of Signalling System No.7; General function of Telephone messages and signals"". [79] ITU-TÊRecommendationÊQ.723Ê(1988): ""Specifications of Signalling System No.7; Formats and codes"". [80] ITU-TÊRecommendationÊQ.724Ê(1988): ""Specifications of Signalling System No.7; Signalling procedures"". [81] ITU-TÊRecommendationÊQ.725Ê(1988): ""Specifications of Signalling System No.7; Signalling performance in the telephone application"". [82] ITU-TÊRecommendationÊQ.761Ê(1988): ""Specifications of Signalling System No.7; Functional description of the ISDN user part of Signalling System No.7"". [83] ITU-TÊRecommendationÊQ.762Ê(1988): ""Specifications of Signalling System No.7; General function of messages and signals"". [84] ITU-TÊRecommendationÊQ.763Ê(1988): ""Specifications of Signalling System No.7; Formats and codes"". [85] ITU-TÊRecommendationÊQ.764Ê(1988): ""Specifications of Signalling System No.7; Signalling procedures"". [86] ITU-TÊRecommendationÊQ.767: ""Specifications of Signalling System No.7; Application of the ISDN user part of CCITT signalling System No.7 for international ISDN interconnections"". [87] ITU-TÊRecommendationÊQ.771: ""Specifications of Signalling System No.7; Functional description of transaction capabilities"". [88] ITU-TÊRecommendationÊQ.772: ""Specifications of Signalling System No.7; Transaction capabilities information element definitions"". [89] ITU-TÊRecommendationÊQ.773: ""Specifications of Signalling System No.7; Transaction capabilities formats and encoding"". [90] ITU-TÊRecommendationÊQ.774: ""Specifications of Signalling System No.7; Transaction capabilities procedures"". [91] ITU-TÊRecommendationÊQ.775: ""Specifications of Signalling System No.7; Guide-lines for using transaction capabilities"". [92] ITU-TÊRecommendationÊX.200: ""Reference Model of Open systems interconnection for CCITT Applications"". [93] ITU-TÊRecommendation ÊX.680: ""Information technology Ð Abstract Syntax Notation One (ASN.1): Specification of basic notation"". [93b] ITU-TÊRecommendationÊX.681: ""Information technology Ð Abstract Syntax Notation One (ASN.1): Information object specification"". [94] ITU-TÊRecommendationÊX.690: ""Information technology Ð ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)"". [95] ITU-TÊRecommendationÊX.210: ""Open systems interconnection layer service definition conventions"". [97] 3GPP TSÊ23.018: ""Basic Call Handling"". [98] 3GPP TSÊ23.078: ""Customised Applications for Mobile network Enhanced Logic (CAMEL) PhaseÊ4Ê- Stage 2"". [99] 3GPP TSÊ23.079: ""Support of Optimal Routeing (SOR) - Stage 2"". [100] 3GPP TS 43.068: ""Voice Group Call Service (VGCS) - Stage 2"". [101] 3GPP TS 43.069: ""Voice Broadcast service (VBS) - Stage 2"". [102] ANSI T1.113: ""Signaling System No. 7 (SS7) - ISDN User Part"". [103] Void [104] 3GPP TSÊ23.060: ""General Packet Radio Service (GPRS) Service description; Stage 2"". [105] 3GPP TSÊ29.060: ""General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface"". [106] 3GPP TSÊ29.018: ""General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface layer 3 specification"". [107] 3GPP TSÊ23.093: ""Technical Realization of Completion of Calls to Busy Subscriber (CCBS); StageÊ2"". [108] 3GPP TSÊ23.066: ""Support of Mobile Number Portability (MNP); Technical Realisation Stage 2"". [109] ANSI T1.112 (1996): ""Telecommunication Ð Signalling No. 7 - Signaling Connection Control Part (SCCP)"". [110] 3GPP TS 23.116: ""Super-Charger Technical Realisation; Stage 2."". [111] Void. [112] Void [113] Void [114] Void [115] Void [116] ITU-T Recommendation Q.850 (May 1998): ""Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part"". [117] 3GPP TS 22.135: ""Multicall; Service description; Stage 1"". [118] 3GPP TS 23.135: ""Multicall supplementary service; Stage 2"". [119] 3GPP TS 24.135: ""Multicall supplementary service; Stage 3"". [120] 3GPP TSÊ25.413: ""UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling"". [121] 3GPP TS 29.202: ""SS7 signalling transport in core network"". [122] 3GPP TS 23.032: ""Universal Geographical Area Description (GAD)"". [123] 3GPP TS 22.071: ""Location Services (LCS); Service description, Stage 1"". [124] ITU-T Recommendation X.880: ""Data networks and open system communication - Open System Interconnection - Service definitions - Remote operations: Concepts, model and notation"". [125] 3GPP TS 23.278: ""Customised Applications for Mobile Network Enhanced Logic (CAMEL) Phase 4 Ð Stage 2 IM CN Interworking (Rel-5)"". [126] 3GPP TS 23.172: ""Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification"". [127] 3GPP TS 26.103: ""Speech codec list for GSM and UMTS"". [128] 3GPP TS 23.141: ""Presence Service; Architecture and Functional Description"". [129] 3GPP TS 23.094: ""Follow Me (FM) Ð Stage 2"". [130] Void [131] 3GPP TS 32.421: ""Subscriber and equipment trace: Trace concepts and requirements"". [132] 3GPP TS 32.422: ""Subscriber and equipment trace; Trace control and Configuration Management"". [133] 3GPP TS 23.236: ""Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes"". [134] 3GPP TS 23.204: ""Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access"". [135] 3GPP TS 23.292: ""IP Multimedia Subsystem (IMS) Centralized Services"". [136] 3GPP TS 23.067: ""enhanced Multi-Level Precedence and Pre-emption service (eMLPP) - Stage 2"". [137] 3GPP TS 24.067: ""Enhanced Multi-Level Precedence and Pre-emption service (eMLPP); Stage 3"". [138] 3GPP TS 22.011: ""Service accessibility"". [139] IETF RFC 3588: ""Diameter Base Protocol"". [140] Void [141] 3GPPÊTSÊ29.173: ""Locations Services; Diameter-based SLh interface for Control Plane LCS"". [142] Void [143] 3GPPÊTSÊ23.272: ""Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2"". [144] 3GPP TS 29.272: ""Evolved Packet System (EPS); Mobility Management Entity (MME) and Service GPRS Support Node (SGSN) related interfaces based on Diameter protocol"". [145] 3GPP TS 23.401: ""General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access"". [146] 3GPP TS 29.205: ""Application of Q.1900 series to bearer independent Circuit Switched (CS) core network architecture; Stage 3"". [147] 3GPP TS 36.413: ""Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)"". [148] 3GPP TS 23.682: ""Architecture enhancements to facilitate communications with packet data networks and applications"". [149] 3GPP TS 29.274: ""3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)"". [150] 3GPP TS 23.380: ""IMS Restoration Procedures"". [151] 3GPP TS 29.273: ""Evolved Packet System (EPS); 3GPP EPS AAA interfaces"". [152] 3GPPÊTSÊ29.118: ""Mobility Management Entity (MME) - Visitor Location Register (VLR) SGs interface specification"". [153] 3GPPÊTSÊ38.413: ""NG-RAN; NG Application Protocol (NGAP)"". [154] 3GPPÊTSÊ23.107: ""Quality of Service (QoS) concept and architecture"". 3 Abbreviations ADD Automatic Device Detection GANSS Galileo and Additional Navigation Satellite Systems All other abbreviations used in the present document are listed in 3GPP TSÊ21.905. 4 Void 5 Overload and compatibility overview 5.1 Overload control There is a requirement for an overload/congestion control for all entities of the Public Land Mobile Network and the underlying Signalling System No. 7. 5.1.1 Overload control for MSC (outside MAP) For the entity MSC the following two procedures (outside MAP) may be applied to control the processor load: - ISDN CCITT Recommendation Q.764 (Automatic Congestion Control), applicable to reduce the mobile terminating traffic; - BSSAP 3GPP TS 48.008 [49] (A-interface Flow Control), applicable to reduce the mobile originating traffic. 5.1.2 Overload control for MAP entities For all MAP entities, especially the HLR, the following overload control method is applied. If overload of a MAP entity is detected requests for certain MAP operations (see tables 5.1/1, 5.1/2, 5.1/3 and 5.1/4) may be ignored by the responder. The decision as to which MAP Operations may be ignored is made by the MAP service provider and is based upon the priority of the application context. Since most of the affected MAP operations are supervised in the originating entity by TC timers (medium) an additional delay effect is achieved for the incoming traffic. If overload levels are applicable in the Location Registers the MAP operations should be discarded taking into account the priority of their application context (see tableÊ5.1/1 for HLR, tableÊ5.1/2 for MSC/VLR, table 5.1/3 for the SGSN and table 5.1/4 for the SMLC; the lowest priority is discarded first). The ranking of priorities given in the tables 5.1/1, 5.1/2, 5.1/3 and 5.1/4 is not normative. The tables can only be seen as a proposal that might be changed due to network operator/implementation matters. TableÊ5.1/1: Priorities of Application Contexts for HLR as Responder Responder = HLR Initiating Entity Priority high Mobility Management networkLocUp VLR (updateLocation), (restoreData/v2), (sendParameters/v1) gprsLocationUpdate SGSN (updateGPRSLocation/v3), infoRetrieval VLR/SGSN (sendAuthenticationInfo/v2/v3), (sendParameters/v1) istAlerting MSC (istAlert/v3) msPurging VLR (purgeMS/v2/v3) msPurging SGSN (purgeMS/v3) Short Message Service shortMsgGateway GMSC (sendRoutingInfoforSM), (reportSM-DeliveryStatus) mwdMngt VLR/SGSN (readyForSM/v2/v3), (noteSubscriberPresent/v1) Mobile Terminating Traffic locInfoRetrieval GMSC (sendRoutingInfo) anyTimeEnquiry gsmSCF (anyTimeInterrogation/v3) reporting VLR (statusReport) Location Services locationSvcGateway GMLC (sendRoutingInfoforLCS/v3) Subscriber Controlled Inputs (Supplementary Services) networkFunctionalSs VLR (registerSS), (eraseSS), (activateSS), (deactivateSS), (interrogateSS), (registerPassword), (processUnstructuredSS-Data/v1), (beginSubscriberActivity/v1) callCompletion VLR (registerCCEntry), (eraseCCEntry) networkUnstructuredSs VLR (processUnstructuredSS-Request/v2) imsiRetrieval VLR (sendIMSI/v2) gprsLocationInfoRetrieval GGSN/SGSN (sendRoutingInfoForGprs/v3/v4) failureReport GGSN/SGSN (failureReport/v3) authenticationFailureReport VLR/SGSN (authenticationFailureReport/v3) Priority low NOTE: The application context name is the last component but one of the object identifier. Operation names are given in brackets for information with ""/vn"" appended to vn only operations. TableÊ5.1/3: Priorities of Application Contexts for SGSN as Responder Responder = SGSN Initiating Entity Priority high Mobility and Location Register Management locationCancel HLR (cancelLocation v3) reset HLR (reset) subscriberDataMngt HLR (insertSubscriberData v3), (deleteSubscriberData v3) tracing HLR (activateTraceMode), (deactivateTraceMode) Short Message Service shortMsgMT-Relay MSC (MT-ForwardSM v3), (forwardSM v1/v2) Location Services locationSvcEnquiry GMLC (provideSubscriberLocation v3) Network-Requested PDP context activation gprsNotify HLR (noteMsPresentForGprs v3), (Subscriber Location & State retrieval) subscriberInfoEnquiry HLR (provideSubscriberInformation/v3) Priority low NOTE: The application context name is the last component but one of the object identifier. Operation names are given in brackets for information with ""/vn"" appended to vn. TableÊ5.1/2: Priorities of Application Contexts for MSC/VLR as Responder Responder = MSC/VLR Initiating Entity Priority high Handover handoverControl MSC (prepareHandover/v2/v3), (performHandover/v1) Group call and Broadcast call groupCallControl MSC (prepareGroupCall/v3) groupCallInfoRetrieval MSC (sendGroupCallInfo/v3) Mobility and Location Register Management locationCancel HLR (cancelLocation) reset HLR (reset) immediateTermination HLR (istCommand/v3) interVlrInfoRetrieval VLR (sendIdentification/v2/v3), (sendParameters/v1) subscriberDataMngt HLR (insertSubscriberData), (deleteSubscriberData) tracing HLR (activateTraceMode), (deactivateTraceMode) Short Message Service shortMsgMO-Relay MSC/SGSN (MO-ForwardSM v3), (forwardSM v1/v2) shortMsgMT-Relay MSC (MT-ForwardSM v3), (forwardSM v1/v2) shortMsgAlert HLR (alertServiceCentre/v2), (alertServiceCentreWithoutResult/v1) Mobile Terminating Traffic resourceMngt GMSC (releaseResources) roamingNbEnquiry HLR (provideRoamingNumber) callControlTransfer MSC (resumeCallHandling) subscriberInfoEnquiry HLR (provideSubscriberInformation/v3) reporting HLR (remoteUserFree), (SetReportingState) Location Services locationSvcEnquiry GMLC (provideSubscriberLocation/v3) Network-Initiated USSD networkUnstructuredSs HLR (unstructuredSS-Request/v2), (unstructuredSS-Notify/v2) Priority low NOTE: The application context name is the last component but one of the object identifier. Operation names are given in brackets for information with ""/vn"" appended to vn only operations. 5.1.3 Congestion control for Signalling System No. 7 The requirements of SS7 Congestion control have to be taken into account as far as possible. Means that could be applied to achieve the required traffic reductions are described in clauses 5.1.1 and 5.1.2. 5.2 Compatibility 5.2.1 General The present document of the Mobile Application Part is designed in such a way that an implementation which conforms to it can also conform to the Mobile Application Part operational version 1 specifications, except on the MSC-VLR interface. A version negotiation mechanism based on the use of an application-context-name is used to negotiate the protocol version used between two entities for supporting a MAP-user signalling procedure. When starting a signalling procedure, the MAP-user supplies an application-context-name to the MAP-provider. This name refers to the set of application layer communication capabilities required for this dialogue. This refers to the required TC facilities (e.g. version 1 or 2) and the list of operation packages (i.e. set of operations) from which operations can be invoked during the dialogue. A version one application-context-name may only be transferred to the peer user in a MAP-U-ABORT to an entity of version two or higher (i.e. to trigger a dialogue which involves only communication capabilities defined for MAP operational versionÊ1). If the proposed application-context-name can be supported by the responding entity the dialogue continues on this basis otherwise the dialogue is refused and the initiating user needs to start a new dialogue, which involves another application-context-name which requires less communication capabilities but provides similar functionality (if possible). When a signalling procedure can be supported by several application contexts that differ by their version number, the MAP-User needs to select a name. It can either select the name that corresponds to the highest version it supports or follow a more specific strategy so that the number of protocol fallbacks due to version compatibility problems is minimised. 5.2.2 Strategy for selecting the Application Context (AC) version A method should be used to minimise the number of protocol fall-backs which would occur sometimes if the highest supported AC-Name were always the one selected by GSMÊentities when initiating a dialogue. The following method is an example that can be used mainly at transitory phase stage when the network is one of mixed phase entities. 5.2.2.1 Proposed method A tableÊ(tableÊ1) may be set up by administrative action to define the highest application context (AC) version supported by each destination; a destination may be another node within the same or a different PLMN, or another PLMN considered as a single entity. The destination may be defined by an E.164 number or an E.214 number derived from an IMSI or in North America (World Zone 1) by an E.164 number or an IMSI (E.212 number). The tableÊalso includes the date when each destination is expected to be able to handle at least one AC of the latest version of the MAP protocol. When this date is reached, the application context supported by the node is marked as ""unknown"", which will trigger the use of tableÊ2. A second tableÊ(tableÊ2) contains an entry for each destination that has an entry in tableÊ1. For a given entity, the entry in tableÊ2 may be a single application context version or a vector of different versions applying to different application contexts for that entity. TableÊ2 is managed as described in clauseÊ5.2.2.2. The data for each destination will go through the following states: a) the version shown in tableÊ1 is ""version n-1"", where 'n' is the highest version existing in this specification; tableÊ2 is not used; b) the version shown in tableÊ1 is ""unknown""; tableÊ2 is used, and maintained as described in clauseÊ5.2.2.2; c) when the PLMN operator declares that an entity (single node or entire PLMN) has been upgraded to support all the MAP version n ACs defined for the relevant interface, the version shown in tableÊ1 is set to ""version n"" by administrative action; tableÊ2 is no longer used, and the storage space may be recovered. 5.2.2.2 Managing the version look-up table WHEN it receives a MAP-OPEN ind the MAP-User determines the originating entity number either using the originating address parameter or the originating reference parameter or retrieving it from the subscriber data using the IMSI or the MSISDN. IF the entity number is known: THEN It updates (if required) the associated list of highest supported ACs. ELSE It creates an entry for this entity and includes the received AC-name in the list of highest supported ACs. WHEN starting a procedure, the originating MAP-user looks up its version control table. IF the destination address is known and not timed-out. THEN It retrieves the appropriate AC-name and uses it IF the dialogue is accepted by the peer THEN It does not modify the version control table ELSE (this should never occur) It starts a new dialogue with the common highest version supported (based on information implicitly or explicitly provided by the peer). It replaces the old AC-name by the new one in the list of associated highest AC supported. ELSE It uses the AC-name that corresponds to the highest version it supports. IF the dialogue is accepted by the peer. THEN It adds the destination node in its version control tableÊand includes the AC-Name in the list of associated highest AC supported. ELSE It starts a new dialogue with the common highest version supported (based on information implicitly or explicitly provided by the peer). IF the destination node was not known THEN It adds the destination node in its version control tableÊand includes the new AC-Name in the list of associated highest AC supported. ELSE It replaces the old AC-name by the new one in the list of highest supported AC and reset the timer. 5.2.2.3 Optimising the method A table look-up may be avoided in some cases if both the HLR and the VLR or both the HLR and the SGSN store for each subscriber the version of the AC-name used at location updating. Then: - for procedures which make use of the same application-context, the same AC-name (thus the same version) can be selected (without any tableÊlook-up) when the procedure is triggered; - for procedures which make use of a different application-context but which includes one of the packages used by the location updating AC, the same version can be selected (without any tableÊlook-up) when the procedure is triggered; for HLR: - Subscriber data modification (stand alone); for VLR: - Data Restoration. 6 Requirements concerning the use of SCCP and TC 6.1 Use of SCCP The Mobile Application Part (MAP) makes use of the services offered by the Signalling Connection Control Part (SCCP). MAP supports the following SCCP versions: - Signalling Connection Control Part, Signalling System no. 7 CCITT ('Blue Book SCCP'); - Signalling Connection Control Part, Signalling System no. 7 ITU-T Recommendation (07/96) Q.711 to Q.716 ('White Book SCCP'). Support of White Book SCCP at the receiving side shall be mandated from 00:01hrs, 1st July 2002(UTC). However, for signalling over the MAP E-interface to support inter-MSC handover/relocation, the support of White Book SCCP shall be mandated with immediate effect. A White Book SCCP message will fail if any signalling point used in the transfer of the message does not support White Book SCCP. Therefore it is recommended that the originator of the White Book SCCP message supports a drop back mechanism or route capability determination mechanism to interwork with signalling points that are beyond the control of GSM/UMTS network operators. In North America (World Zone 1) the national version of SCCP is used as specified in ANSI T1.112. Interworking between a PLMN in North America and a PLMN outside North America will involve an STP to translate between ANSI SCCP and ITU-T/CCITT SCCP. The SCCP is identified as an MTP3-user and the transport of SCCP messages between two entities shall be accomplished according to the 3GPP TS 29.202 [121]. 6.1.1 SCCP Class MAP will only make use of the connectionless classes (0 or 1) of the SCCP. 6.1.2 Sub-System Number (SSN) The Application Entities (AEs) defined for MAP consist of several Application Service Elements (ASEs) and are addressed by sub-system numbers (SSNs). The SSNs for MAP are specified in 3GPP TS 23.003 [17]. When the SGSN emulates MSC behaviour for processing messages (MAP-MO-FORWARD-SHORT-MESSAGE, MAP_CHECK_IMEI, MAP_SUBSCRIBER_LOCATION_REPORT) towards entities which do not support interworking to SGSNs, it shall use the MSC SSN in the calling party address instead of the SGSN SSN. When present in the network, the Presence Network Agent emulates the behaviour of the GSM Service Control Function (gsm SCF) for processing of messages (MAP-NOTE-MM-EVENT, MAP-ANY-TIME-INTERROGATION and MAP-ANY-TIME-MODIFICATION). When a FFN (Follow Me Functional Node, see TS 23.094 [129]) is implemented in a network entity different from HLR, this network entity shall emulate HLR behaviour, i.e. it shall accept MAP-PROCESS-UNSTRUCTURED-SS-REQUEST messages addressed with SSN for HLR. In an EPS, an Interworking Function (IWF) may be used to convert Diameter S6a messages to MAP Gr messages and vice versa; also an IWF may be used to convert Diameter S13 messages to MAP Gf messages and vice versa. An SSN value for the IWF does not exist. Instead the IWF shall use the SGSN SSN value when serving an MME and use the HLR SSN when serving an HSS. An IWF is said to serve an MME (or HSS) when Diameter messages are exchanged between the IWF and the MME (or HSS). In a 5GS, a UDM may support a MAP interface towards the SMS-GMSC/SMS-Router by emulating HLR behaviour, i.e. the UDM may have an integrated/collocated HLR component serving the MAP communication to the SMS-GMSC/SMS-Router. An SSN value for UDM does not exist. Instead the UDM (with an integrated/collocated HLR) shall use the HLR SSN value. 6.1.3 SCCP addressing 6.1.3.1 Introduction Within the GSMÊSystem there will be a need to communicate between entities within the same PLMN and in different PLMNs. Using the Mobile Application Part (MAP) for this function implies the use of Transaction Capabilities (TC) and the Signalling Connection Control Part (SCCP) of CCITT Signalling System No. 7. Only the entities that should be addressed are described below. If the CCITT or ITU-T SCCP is used, the format and coding of address parameters carried by the SCCP for that purpose shall comply with CCITT Recommendation Q.713 with the following restrictions: 1) Intra-PLMN addressing For communication between entities within the same PLMN, a MAP SSN shall always be included in the called and calling party addresses. All other aspects of SCCP addressing are network specific. 2) Inter-PLMN addressing a) Called Party Address - SSN indicator = 1 (MAP SSN always included); - Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and nature of address indicator); - the translation type field will be coded ""00000000"" (Not used)."
"For call related messages for non-optimal routed calls (as described in 3GPP TS 23.066 [108]) directed to another PLMN the translation type field may be coded ""10000000"" (CRMNP); - Routing indicator = 0 (Routing on global title); b) Calling Party Address - SSN indicator = 1 (MAP SSNs always included); - Point code indicator = 0; - Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and nature of address indicator); - Numbering Plan = 0001 (ISDN Numbering Plan, E.164; In Case of Inter-PLMN Signalling, the dialogue initiating entity and dialogue responding entity shall always include its own E.164 Global Title as Calling Party Address); - the translation type field will be coded ""00000000"" (Not used); - Routing indicator = 0 (Routing on Global Title). If ANSI T1.112 SCCP is used, the format and coding of address parameters carried by the SCCP for that purpose shall comply with ANSI specification T1.112 with the following restrictions: 1) Intra-PLMN addressing For communication between entities within the same PLMN, a MAP SSN shall always be included in the called and calling party addresses. All other aspects of SCCP addressing are network specific. 2) Inter-PLMN addressing a) Called Party Address - SSN indicator = 1 (MAP SSN always included); - Global title indicator = 0010 (Global title includes translation type); - the Translation Type (TT) field will be coded as follows: TT = 9, if IMSI is included; TT = 14, if MSISDN is included; Or TT = 10, if Network Element is included. (If TT=10, then Number Portability GTT is not invoked, if TT=14, then Number Portability GTT may be invoked). - Routing indicator = 0 (Routing on global title); b) Calling Party Address - SSN indicator = 1 (MAP SSNs always included); - Point code indicator = 0; - Global Title indicator = 0010 (Global title includes translation type); TT = 9, if IMSI is included; TT = 14, if MSISDN is included; Or TT = 10, if Network Element is included. (If TT=10, then Number Portability GTT is not invoked, if TT=14, then Number Portability GTT may be invoked). Routing indicator = 0 (Routing on Global Title). If a Global Title translation is required for obtaining routeing information, one of the numbering plans E.164, E.212 and E.214 is applicable. - E.212 numbering plan. When CCITT or ITU-T SCCP is used, an E.212 number must not be included as Global Title in an SCCP UNITDATA message. The translation of an E.212 number into a Mobile Global Title is applicable in a dialogue initiating VLR, SGSN or GGSN if the routeing information towards the HLR is derived from the subscriber's IMSI. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used as a Global Title to address the HLR. When an MS moves from one VLR service area to another, the new VLR may derive the address of the previous VLR from the Location Area Identification provided by the MS in the location registration request. The PLMN where the previous VLR is located is identified by the E.212 numbering plan elements of the Location Area Identification, i.e. the Mobile Country Code (MCC) and the Mobile Network Code (MNC). - E.214 and E.164 numbering plans. When CCITT or ITU-T SCCP is used, only address information belonging to either E.214 or E.164 numbering plan is allowed to be included as Global Title in the Called and Calling Party Address. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used as a Global Title to address the HLR. If the Calling Party Address associated with the dialogue initiating message contains a Global Title, the sending network entity shall include its E.164 entity number. When receiving an SCCP UNITDATA message, SCCP shall accept either of the valid numbering plans in the Called Party Address and in the Calling Party Address. When CCITT or ITU-T SCCP is used and an N-UNITDATA-REQUEST primitive from TC is received, SCCP shall accept an E.164 number or an E.214 number in the Called Address and in the Calling Address. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used instead of E.214 number. The following clauses describe the method of SCCP addressing appropriate for each entity both for the simple intra PLMN case and where an inter-PLMN communication is required. The following entities are considered: - the Mobile-services Switching Centre (MSC); - the Home location Register (HLR); - the Visitor Location Register (VLR); - the Gateway Mobile-services Switching Centre (GMSC); - the GSM Service Control Function (gsmSCF); - the Interworking Mobile-services Switching Centre (IWMSC); - the Serving GPRS Support Node (SGSN); - the Gateway GPRS Support Node (GGSN); - the Gateway Mobile Location Centre (GMLC); - the CSG Subscriber Server (CSS). 6.1.3.2 The Mobile-services Switching Centre (MSC) There are several cases where it is necessary to address the MSC. 6.1.3.2.1 MSC interaction during handover or relocation The address is derived from the target Cell id or from the target RNC id. 6.1.3.2.2 MSC for short message routing When a short message has to be routed to an MS, the GMSC addresses the VMSC by an MSC identity received from the HLR that complies with E.164 rules. For MS originating short message, the IWMSC address is derived from the Service Centre address. 6.1.3.2.3 MSC for location request routing When a location request for a particular MS needs to be sent to the MS's VMSC, the GMLC addresses the VMSC using an E.164 address received from the MS's HLR. 6.1.3.2.4 MSC for LMU Control When a control message has to be routed to an LMU from an SMLC, the SMLC addresses the serving MSC for the LMU using an E.164 address. 6.1.3.3 The Home Location Register (HLR) There are several cases where the HLR has to be addressed. 6.1.3.3.1 During call set-up When a call is initiated the HLR of the called mobile subscriber will be interrogated to discover the whereabouts of the MS. The addressing required by the SCCP will be derived from the MSISDN dialled by the calling subscriber. The dialled number will be translated into either an SPC, in the case of communications within a PLMN, or a Global Title if other networks are involved (i.e. if the communication is across a PLMN boundary). If the calling subscriber is a fixed network subscriber, the interrogation can be initiated from the Gateway MSC of the home PLMN in the general case. If the topology of the network allows it, the interrogation could be initiated from any Signalling Point that has MAP capabilities, e.g. local exchange, outgoing International Switching Centre (ISC), etc. 6.1.3.3.2 Before location updating completion When an MS registers for the first time in a VLR, the VLR has to initiate the update location dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if the authentication information must be retrieved from the HLR. When initiating either of these dialogues, the only data for addressing the HLR that the VLR has available is contained in the IMSI, and addressing information for SCCP must be derived from it. When continuing the established update location dialogue (as with any other dialogue), the VLR must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. This means that the VLR must be able to address the HLR based on: - an E.214 Mobile Global Title originally derived by the VLR from the IMSI (when CCITT or ITU-T SCCP is used), or an E.212 number originally derived from IMSI (when ANSI SCCP is used, an IMSI); or - an E.164 HLR address; or - in the case of intra-PLMN signalling, an SPC. When answering with Global Title to the VLR, the HLR shall insert its E.164 address in the Calling Party Address of the SCCP message containing the first responding CONTINUE message. If the HLR is in the same PLMN as the VLR, local translation tables may exist to derive an SPC. For authentication information retrieval and location updating via the international PSTN/ISDN signalling network that requires the use of CCITT or ITU-T SCCP, the Global Title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. In World Zone 1 where the ANSI SCCP is used, IMSI (E.212 number) is used as Global Title. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below: - E.212 Mobile Country Code translates to E.164 Country Code; - E.212 Mobile Network Code translates to E.164 National Destination Code; - E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits. This translation will be done either at the application or at SCCP level in the VLR. The Mobile Global Title thus derived will be used to address the HLR. If location updating is triggered by an MS that roams from one MSC Area into a different MSC Area served by the same VLR, the VLR shall address the HLR in the same way as if the MS registers for the first time in the VLR. 6.1.3.3.3 After location updating completion In this case, the subscriber's basic MSISDN has been received from the HLR during the subscriber data retrieval procedure as well as the HLR number constituting a parameter of the MAP message indicating successful completion of the update location dialogue. From either of these E.164 numbers the address information for initiating dialogues with the roaming subscriber's HLR can be derived. Also the subscriber's IMSI may be used for establishing the routeing information towards the HLR. This may apply in particular if the dialogue with the HLR is triggered by subscriber controlled input. Thus the SCCP address of the roaming subscriber's HLR may be an SPC, or it may be a Global title consisting of the E.164 MSISDN or the E.164 number allocated to the HLR or either the E.214 Mobile Global Title derived from the IMSI if CCITT or ITU-T SCCP is used, or the IMSI if ANSI SCCP is used (ANSI SCCP is used in World Zone 1). 6.1.3.3.4 VLR restoration If a roaming number is requested by the HLR for an IMSI that has no data record in the interrogated VLR, the VLR provides the roaming number in the dialogue terminating message. Subsequently the VLR must retrieve the authentication data from the MS's HLR, if required, and must then trigger the restore data procedure. For this purpose, the VLR has to initiate in succession two independent dialogues with the MS's HLR. The MTP and SCCP address information needed for routeing towards the HLR can be derived from the IMSI received as a parameter of the MAP message requesting the roaming number. In this case, the IMSI received from the HLR in the roaming number request shall be processed in the same way as the IMSI that is received from an MS that registers for the first time within a VLR. Alternatively to the IMSI, the Calling Party Address associated with the roaming number request may be used to obtain the routeing information towards the HLR. 6.1.3.3.5 During Network-Requested PDP Context Activation When receiving a PDP PDU the GGSN may interrogate the HLR of the MS for information retrieval. When initiating such a dialogue, the only data for addressing the HLR that the GGSN has available is contained in the IMSI, and addressing information must be derived from it. The IMSI is obtained from the IP address or the X.25 address in the incoming IP message by means of a translation table. This means that the GGSN shall be able to address the HLR based on an E.214, (if CCITT or ITU-T SCCP is used), or E.212 (if ANSI SCCP is used), Mobile Global Title originally derived by the GGSN from the IMSI in the case of inter-PLMN signalling. In the case of intra-PLMN signalling, an SPC may also be used. If the HLR is in the same PLMN as the GGSN, local translation tables may exist to derive an SPC. For information retrieval via the international PSTN/ISDN signalling network, the Global title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below: - E.212 Mobile Country Code translates to E.164 Country Code; - E.212 Mobile Network Code translates to E.164 National Destination Code; - E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits. This translation will be done either at the application or at SCCP level in the GGSN. The Mobile Global Title thus derived will be used to address the HLR. 6.1.3.3.6 Before GPRS location updating completion When an MS registers for the first time in an SGSN, the SGSN has to initiate the update location dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if the authentication information must be retrieved from the HLR. When initiating either of these dialogues, the only data for addressing the HLR that the SGSN has available is contained in the IMSI, and addressing information for SCCP must be derived from it. When continuing the established update location dialogue (as with any other dialogue), the SGSN must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. This means that the SGSN must be able to address the HLR based on: - an E.214 (if CCITT or ITU-T SCCP is used) or E.212 (if ANSI SCCP is used) Mobile Global Title originally derived by the SGSN from the IMSI; or - an E.164 HLR address; or - in the case of intra-PLMN signalling, an SPC. If the HLR is in the same PLMN as the SGSN, local translation tables may exist to derive an SPC. For authentication information retrieval and location updating via the international PSTN/ISDN signalling network, the Global title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below: - E.212 Mobile Country Code translates to E.164 Country Code; - E.212 Mobile Network Code translates to E.164 National Destination Code; - E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits. This translation will be done either at the application or at SCCP level in the SGSN. The Mobile Global Title thus derived will be used to address the HLR. 6.1.3.3.7 After GPRS location updating completion In this case, the subscriber's Basic MSISDN has been received from the HLR during the subscriber data retrieval procedure as well as the HLR number constituting a parameter of the MAP message indicating successful completion of the update location dialogue. From either of these E.164 numbers the address information for initiating dialogues with the roaming subscriber's HLR can be derived. Also the subscriber's IMSI may be used for establishing the routeing information towards the HLR. Thus the SCCP address of the roaming subscriber's HLR may be an SPC, or it may be a Global title consisting of the E.164 MSISDN or the E.164 number allocated to the HLR or the E.214 Mobile Global Title derived from the IMSI. 6.1.3.3.8 Query for a Location Request For a location request from an external client, the GMLC needs to address the home HLR of the target MS to obtain the address of the target MS's serving MSC. The GMLC uses either the international E.164 MSISDN, the international E.214 number (if CCITT or ITU-T SCCP is used) or the international E.212 number (if ANSI SCCP is used) of the MS as means to route a query to the HLR. 6.1.3.4 The Visitor Location Register (VLR) 6.1.3.4.0 General There are several cases when the VLR needs to be addressed. 6.1.3.4.1 Inter-VLR information retrieval When an MS moves from one VLR service area to another, the new VLR may request the IMSI and authentication sets from the previous VLR. The new VLR derives the address of the previous VLR from the Location Area Identification provided by the MS in the location registration request. 6.1.3.4.2 HLR request The HLR will only request information from a VLR if it is aware that one of its subscribers is in the VLR service area. This means that a location updating dialogue initiated by the VLR has been successfully completed, i.e. the HLR has indicated successful completion of the update location procedure to the VLR. When initiating dialogues towards the VLR after successful completion of location updating, the routeing information used by the HLR is derived from the E.164 VLR number received as a parameter of the MAP message initiating the update location dialogue. If the VLR is in the same PLMN as the HLR, the VLR may be addressed directly by an SPC derived from the E.164 VLR number. For dialogues via the international PSTN/ISDN signalling network, presence of the E.164 VLR number in the Called Party Address is required. 6.1.3.4.3 CSS request The CSS will only request information from a VLR if it is aware that one of its subscribers is in the VLR service area. This means that a VCSG location updating dialogue initiated by the VLR has been successfully completed, i.e. the CSS has indicated successful completion of the update VCSG location procedure to the VLR. When initiating dialogues towards the VLR after successful completion of VCSG location updating, the routeing information used by the CSS is derived from the E.164 VLR number received as a parameter of the MAP message initiating the update VCSG location dialogue. The VLR may be addressed either by the E.164 VLR number or directly by an SPC derived from the E.164 VLR number due to the VLR is in the same PLMN as the CSS. 6.1.3.5 The Interworking MSC (IWMSC) for Short Message Service The IWMSC is the interface between the mobile network and the network to access to the Short Message Service Centre. This exchange has an E.164 address known in the SGSN or in the MSC. 6.1.3.6 The Equipment Identity Register (EIR) The EIR address is either unique or could be derived from the IMEI. The type of address is not defined. 6.1.3.7 Void 6.1.3.8 The Serving GPRS Support Node (SGSN) 6.1.3.8.0 General There are several cases when the SGSN needs to be addressed. 6.1.3.8.1 HLR request The HLR will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN serving area. This means that a GPRS location updating has been successfully completed, i.e., the HLR has indicated successful completion of the GPRS location update to the SGSN. The routeing information used by the HLR is derived form the E.164 SGSN number received as parameter of the MAP message initiating the GPRS update location procedure. If the SGSN is in the same PLMN as the HLR, the SGSN may be addressed directly by an SPC derived from the E.164 SGSN number. For dialogues via the international PSTN/ISDN signalling network, the presence of the E.164 SGSN number in the Called Party Address is required. 6.1.3.8.2 GMSC request When the GMSC initiates dialogues towards the SGSN the SGSN (MAP) SSN (See 3GPP TS 23.003 [17]) shall be included in the called party address. The routeing information used by the GMSC is derived from the E.164 SGSN number received as a parameter of the MAP message initiating the forward short message procedure. If the GMSC does not support the GPRS functionality the MSC (MAP) SSN value shall be included in the called party address. NOTE: Every VMSC and SGSN shall have uniquely identifiable application using E.164 numbers, for the purpose of SMS over GPRS when the GMSC does not support the GPRS functionality. 6.1.3.8.3 CSS request The CSS will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN serving area. This means that a VCSG location updating has been successfully completed, i.e., the CSS has indicated successful completion of the VCSG location update to the SGSN. The routeing information used by the CSS is derived from the E.164 SGSN number received as parameter of the MAP message initiating the update VCSG location procedure. The SGSN may be addressed either by the E.164 SGSN number or directly by an SPC derived from the E.164 SGSN number due to the SGSN is in the same PLMN as the CSS. 6.1.3.9 The Gateway GPRS Support Node (GGSN) The GGSN provides interworking with external packet-switched networks, network screens and routing of the Network-Requested PDP Context activation. If a Network-Requested PDP Context activation fails, the HLR will alert the GGSN when the subscriber becomes reachable. The HLR will use the E.164 GGSN number received as parameter of the MAP message reporting the failure. 6.1.3.10 The Gateway MSC (GMSC) for Short Message Service The GMSC provides interworking with the network to access the Short Message Service Centre, the mobile network and routing of Send Routing Info For SM. The GMSC has on E.164 address known in the HLR, SGSN or MSC. 6.1.3.10A Void 6.1.3.10A.1 Void 6.1.3.10A.2 Void 6.1.3.10B The Gateway Mobile Location Centre (GMLC) The GMLC initiates location requests on behalf of external clients. The E.164 address of the GMLC is provided to an HLR when the GMLC requests a serving MSC address or SGSN address from the HLR for a target MS. The E.164 address of the GMLC is also provided to a serving MSC or SGSN when the GMLC requests the location of a target MS served by this MSC or SGSN. 6.1.3.10C The CSG Subscriber Server (CSS) The CSS address is either unique or could be derived from the IMSI. The type of address is not defined. 6.1.3.11 Summary table The following tables summarise the SCCP address used for invoke operations. As a principle, within a PLMN either an SPC or a GT may be used (network operation option), whereas when addressing an entity outside the PLMN the GT must be used. The address type mentioned in the tableÊ(e.g. MSISDN) is used as GT or to derive the SPC. For a response, the originating address passed in the invoke is used as SCCP Called Party Address. For extra-PLMN addressing the own E.164 entity address is used as SCCP Calling Party Address; for intra-PLMN addressing an SPC derived from the entity number may be used instead. When using an SPC, the SPC may be taken directly from MTP. TableÊ6.1/1 to from fixed net work HLR VLR MSC EIR gsmSCF SGSN GGSN CSS fixed network --- E:GT T:MSISDN --- --- --- --- --- --- --- Home Location Register --- --- I:SPC/GT E:GT T:VLR NUMBER --- --- I:SPC/GT E:GT T:gsmSCF NUMBER I:SPC/GT E:GT T:SGSN NUMBER I:SPC/GT E:GT T:GGSN NUMBER --- Visitor Location Register --- I:SPC/GT E:GT T:MGT (outside World Zone 1)/MSISDN (World Zone 1/)HLR NUMBER (note) I:SPC/GT E:GT T:VLR NUMBER --- --- I:SPC/GT E:GT T:gsmSCF NUMBER --- --- I: SPC/GT E:GT T:CSS NUMBER mobile-services switching centre --- I:SPC/GT E:GT T:MSISDN I:SPC/GT E:GT T:VLR NUMBER I:SPC/GT E:GT T:MSC NUMBER I:SPC/GT E:GT T:EIR NUMBER I:SPC/GT E:GT T:gsmSCF NUMBER I:SPC/GT E:GT T:SGSN NUMBER --- --- gsm Service Control Function --- I:SPC/GT E:GT T:MSISDN --- --- --- --- --- --- --- Serving GPRS Support Node --- I:SPC/GT E:GT T:MGT/ MSISDN/HLR NUMBER --- I:SPC/GT E:GT T:MSC NUMBER I:SPC/GT E:GT T:EIR NUMBER I:SPC/GT E:GT T:gsmSCF NUMBER --- --- I:SPC/GT E:GT T:CSS NUMBER Gateway GPRS Support Node --- I:SPC/GT E:GT T:MGT --- --- --- --- --- --- --- Gateway Mobile Location Centre --- I:SPC/GT E:GT T:MSISDN, MGT (outside World Zone 1) or IMSI (World Zone 1) (note) --- I:SPC/GT E:GT T:MSC NUMBER --- --- I:SPC/GT E:GT T:SGSN NUMBER --- --- CSG Subscriber Server --- --- I:SPC/GT E:GT T:VLR NUMBER --- --- --- I:SPC/GT E:GT T:SGSN NUMBER --- --- I: Intra-PLMN. E: Extra (Inter)-PLMN. T: Address Type. GT: Global Title. MGT: E.214 Mobile Global Title. SPC: Signalling Point Code. NOTE: For initiating the location updating procedure and an authentication information retrieval from the HLR preceding it, the VLR has to derive the HLR address from the IMSI of the MS. The result can be an SPC or an E.214 Mobile Global Title if CCITT or ITU-T SCCP is used, or IMSI itself if ANSI SCCP is used (ANSI SCCP is used in World Zone 1). When continuing the established update location dialogue (as with any other dialogue) the VLR must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. For transactions invoked by the VLR after update location completion, the VLR may derive the information for addressing the HLR from addresses received in the course of the update location procedure (MSISDN or HLR number) or from the IMSI. When invoking the Restore Data procedure and an authentication information retrieval from the HLR preceding it, the VLR must derive the information for addressing the HLR from the address information received in association with the roaming number request. This may be either the IMSI received as a parameter of the MAP message requesting the Roaming Number or the Calling Party Address associated with the MAP message requesting the Roaming Number. The gsmSCF shall be addressed using more than one Global Title number. The first Global Title number is used to address a gsmSCF for MAP. The second Global Title number is used to address a gsmSCF for CAP. For querying the HLR to obtain the VMSC address to support location services, the GMLC has to derive the HLR address from either the MSISDN or IMSI of the target MS. When using the IMSI, the result can be an SPC or an E.214 Mobile Global Title if CCITT or ITU-T SCCP is used, or IMSI itself if ANSI SCCP is used (ANSI SCCP is used in World Zone 1). TableÊ6.1/2 to from GMLC fixed network --- Home Location Register --- Visitor Location Register --- Mobile-services Switching Centre I:SPC/GT E:GT T:MLC Number gsm Service Control Function I:SPC/GT E:GT T:MSISDN Serving GPRS Support Node I:SPC/GT E:GT T:MLC Number Gateway GPRS Support Node --- Gateway Mobile Location Centre I: Intra-PLMN. E: Extra (Inter)-PLMN. T: Address Type. GT: Global Title. MGT: E.214 Mobile Global Title. SPC: Signalling Point Code. 6.2 Use of TC The Mobile Application part makes use of the services offered by the Transaction Capabilities (TC) of Signalling System No. 7. ETSÊ300Ê287, which is based on CCITT White Book Recommendations Q.771 to Q.775, should be consulted for the full specification of TC. The MAP uses all the services provided by TC except the ones related to the unstructured dialogue facility. From a modelling perspective, the MAP is viewed as a single Application Service Element. Further structuring of it is for further study. Transaction Capabilities refers to a protocol structure above the network layer interface (i.e., the SCCP service interface) up to the application layer including common application service elements but not the specific application service elements using them. TC is structured as a Component sub-layer above a Transaction sub-layer. The Component sub-layer provides two types of application services: services for the control of end-to-end dialogues and services for Remote Operation handling. These services are accessed using the TC-Dialogue handling primitives and TC-Component handling primitives respectively. Services for dialogue control include the ability to exchange information related to application-context negotiation as well as initialisation data. Services for Remote Operation handling provide for the exchange of protocol data units invoking tasks (operations), and reporting their outcomes (results or errors) plus any non-application-specific protocol errors detected by the component sub-layer. The reporting of application-specific protocol errors by the TC user, as distinct from application process errors, is also provided. The Transaction sub-layer provides a simple end-to-end connection association service over which several related protocol data units (i.e. built by the Component Sub-Layer) can be exchanged. A Transaction termination can be prearranged (no indication provided to the TC user) or basic (indication provided). 7 General on MAP services 7.1 Terminology and definitions The term service is used in clauses 7 to 12 as defined in CCITT Recommendation X.200. The service definition conventions of CCITT Recommendation X.210 are also used. MAP services that are defined for use between HLR and SGSN are also used in an Evolved Packet System (EPS) between two IWFs and between HSS and IWF, where the IWF is an Interworking Function that converts MAP messages to Diameter messages and vice versa. MAP services that are defined for use between SGSN and EIR are also used in an Evolved Packet System (EPS) between IWF and EIR. IWFs may be connected via Diameter to MMEs and HSSs and they may be connected via MAP to HSSs, IWFs, and EIRs. 7.2 Modelling principles MAP provides its users with a specified set of services and can be viewed by its users as a ""black box"" or abstract machine representing the MAP service-provider. The service interface can then be depicted as shown in figureÊ7.2/1. FigureÊ7.2/1: Modelling principles The MAP service-users interact with the MAP service-provider by issuing or receiving MAP service-primitives at the service interface. A MAP service-user may receive services from several instances of the MAP service-provider at the same time. In such cases the overall procedure is synchronised by the service-user. The MAP service-primitives are named using the following notation: MAP-ServicePrimitiveName type where type can be any of: request (req), indication (ind), response (rsp) or confirm (cnf). (In the user arrow diagrams type is not indicated in the case of req/ind and indicated as ""ack"" in the case of rsp/cnf). The services are further classified as unconfirmed-service, confirmed-service and provider-initiated-service where the first two categories refer to whether or not the service is confirmed by the service-provider. The confirmation may or may not correspond to a response provided by the other service-user. MAP services are also classified as common MAP services that are available to all MAP service-users, and MAP service-user specific services, which are services available to one or several, but not all, MAP service-users. A MAP dialogue is defined as an exchange of information between two MAP users in order to perform a common task. A MAP dialogue will consist of one or several MAP services. 7.3 Common MAP services All MAP service-users require access to services for performing basic application layer functions: - for establishing and clearing MAP dialogues between peer MAP service-users; - for accessing functions supported by layers below the applications layer; - for reporting abnormal situations; - for handling of different MAP versions; - for testing whether or not a persistent MAP dialogue is still active at each side. For these purposes the following common services are defined: - MAP-OPEN service; - MAP-CLOSE service; - MAP-DELIMITER service; - MAP-U-ABORT service; - MAP-P-ABORT service; - MAP-NOTICE service. In defining the service-primitives the following convention is used for categorising parameters: M the inclusion of the parameter is mandatory. The M category can be used for any primitive type and specifies that the corresponding parameter must be present in the indicated primitive type; O the inclusion of the parameter is a service-provider option. The O category can be used in indication and confirm type primitives and is used for parameters that may optionally be included by the service-provider; U the inclusion of the parameter is a service-user option. The U category can be used in request and response type primitives. The inclusion of the corresponding parameter is the choice of the service-user; C the inclusion of the parameter is conditional. The C category can be used for the following purposes: - to indicate that if the parameter is received from another entity it must be included for the service being considered; - to indicate that the service user must decide whether to include the parameter, based on the context on which the service is used; - to indicate that one of a number of mutually exclusive parameters must be included (e.g. parameters indicating a positive result versus parameters indicating a negative result); - to indicate that a service user optional parameter (marked ""U"") or a conditional parameter (marked ""C"") presented by the service user in a request or response type primitive is to be presented to the service user in the corresponding indication or confirm type primitive; (=) when appended to one of the above, this symbol means that the parameter takes the same value as the parameter appearing immediately to its left; blank the parameter is not present. A primitive type may also be without parameters, i.e. no parameter is required with the primitive type; in this case the corresponding column of the tableÊis empty. 7.3.1 MAP-OPEN service This service is used for establishing a MAP dialogue between two MAP service-users. The service is a confirmed service with service primitives as shown in tableÊ7.3/1. TableÊ7.3/1: Service-primitives for the MAP-OPEN service Parameters Request Indication Response Confirm Application context name M M(=) U C(=) Destination address M M(=) Destination reference U C(=) Originating address U O Originating reference U C(=) Specific information U C(=) U C(=) Responding address U C(=) Result M M(=) Refuse-reason C C(=) Provider error O Application context name: This parameter identifies the type of application context being established. If the dialogue is accepted the received application context name shall be echoed. In case of refusal of dialogue this parameter shall indicate the highest version supported. Destination address: A valid SCCP address identifying the destination peer entity (see also clauseÊ6). As an implementation option, this parameter may also, in the indication, be implicitly associated with the service access point at which the primitive is issued. Destination-reference: This parameter is a reference that refines the identification of the called process. It may be identical to Destination address but its value is to be carried at MAP level. TableÊ7.3/2 describes the MAP services using this parameter. Only these services are allowed to use it. TableÊ7.3/2: Use of the destination reference MAP service Reference type Use of the parameter MAP-REGISTER-SS IMSI Subscriber identity MAP-ERASE-SS IMSI Subscriber identity MAP-ACTIVATE-SS IMSI Subscriber identity MAP-DEACTIVATE-SS IMSI Subscriber identity MAP-INTERROGATE-SS IMSI Subscriber identity MAP-REGISTER-PASSWORD IMSI Subscriber identity MAP-PROCESS-UNSTRUCTURED- SS-REQUEST IMSI (note 1) Subscriber identity MAP-UNSTRUCTURED- SS-REQUEST IMSI (note 2) Subscriber identity MAP-UNSTRUCTURED-SS-NOTIFY IMSI (note 2) Subscriber identity MAP-FORWARD-SHORT-MESSAGE IMSI (note 3) Subscriber identity MAP-REGISTER-CC-ENTRY IMSI Subscriber identity MAP-ERASE-CC-ENTRY IMSI Subscriber identity NOTE 1: On the HLR - HLR interface and on the HLR - gsmSCF interface the Destination reference shall be either IMSI or MSISDN. NOTE 2: On the gsmSCF - HLR interface and on the HLR - HLR interface the Destination reference shall be either IMSI or MSISDN. NOTE 3: Only when the IMSI and the LMSI are received together from the HLR in the mobile terminated short message transfer. Originating address: A valid SCCP address identifying the requestor of a MAP dialogue (see also clauseÊ6). As an implementation option, this parameter may also, in the request, be implicitly associated with the service access point at which the primitive is issued. Originating-reference: This parameter is a reference that refines the identification of the calling process. It may be identical to the Originating address but its value is to be carried at MAP level. TableÊ7.3/3 describes the MAP services using the parameter. Only these services are allowed to use it. Processing of the Originating-reference shall be performed according to the supplementary service descriptions and other service descriptions, e.g. operator determined barring. Furthermore the receiving entity may be able to use the value of the Originating-reference to screen the service indication. TableÊ7.3/3: Use of the originating reference MAP service Reference type Use of the parameter MAP-REGISTER-SS ISDN-Address-String Originated entity address MAP-ERASE-SS ISDN-Address-String Originated entity address MAP-ACTIVATE-SS ISDN-Address-String Originated entity address MAP-DEACTIVATE-SS ISDN-Address-String Originated entity address MAP-INTERROGATE-SS ISDN-Address-String Originated entity address MAP-REGISTER-PASSWORD ISDN-Address-String Originated entity address MAP-PROCESS-UNSTRUCTURED- SS-REQUEST ISDN-Address-String Originated entity address MAP-UNSTRUCTURED- SS-REQUEST ISDN-Address-String (note) Originated entity address MAP-UNSTRUCTURED- SS-NOTIFY ISDN-Address-String (note) Originated entity address MAP-REGISTER-CC-ENTRY ISDN-Address-String Originated entity address MAP-ERASE-CC-ENTRY ISDN-Address-String Originated entity address NOTE: The Originating reference may be omitted. Specific information: This parameter may be used for passing any user specific information."
"Establishment and processing of the Specific information is not specified by GSM and shall be performed according to operator specific requirements. Responding address: An address identifying the responding entity. The responding address is included if required by the context (e.g. if it is different from the destination address). Result: This parameter indicates whether the peer accepts the dialogue. Refuse reason: This parameter is present only if the Result parameter indicates that the dialogue is refused. It takes one of the following values: - Application-context-not-supported; - Invalid-destination-reference; - Invalid-originating-reference; - No-reason-given; - Remote node not reachable; - Potential version incompatibility. 7.3.2 MAP-CLOSE service This service is used for releasing a previously established MAP dialogue. The service may be invoked by either MAP service-user depending on rules defined within the service-user. The service is an unconfirmed service with parameters as shown in tableÊ7.3/4. TableÊ7.3/4: Service-primitives for the MAP-CLOSE service Parameters Request Indication Release method M Specific Information U C(=) Release method: This parameter can take the following two values: - normal release; in this case the primitive is mapped onto the protocol and sent to the peer; - prearranged end; in this case the primitive is not mapped onto the protocol. Prearranged end is managed independently by the two users, i.e. only the request type primitive is required in this case. Specific information: This parameter may be used for passing any user specific information. Establishment and processing of the Specific information is not specified by GSMÊGSMÊand shall be performed according to operator specific requirements. 7.3.3 MAP-DELIMITER service This service is used to explicitly request the transfer of the MAP protocol data units to the peer entities. See also clauseÊ7.4 and 7.5 for the detailed use of the MAP-DELIMITER service. The service is an unconfirmed service with service-primitives as shown in tableÊ7.3/5. TableÊ7.3/5: Service-primitives for the MAP-DELIMITER service Parameters Request Indication 7.3.4 MAP-U-ABORT service This service enables the service-user to request the MAP dialogue to be aborted. The service is an unconfirmed service with service-primitives as shown in tableÊ7.3/6. TableÊ7.3/6: Service-primitives for the MAP-U-ABORT service Parameters Request Indication User reason M M(=) Diagnostic information U C(=) Specific information U C(=) User reason: This parameter can take the following values: - resource limitation (congestion); the requested user resource is unavailable due to congestion; - resource unavailable; the requested user resource is unavailable for reasons other than congestion; - application procedure cancellation; the procedure is cancelled for reasons detailed in the diagnostic information parameter; - procedure error; processing of the procedure is terminated for procedural reasons. Diagnostic information: This parameter may be used to give additional information for some of the values of the user-reason parameter: TableÊ7.3/7: User reason and diagnostic information User reason Diagnostic information Resource limitation (congestion) - Resource unavailable Short term/long term problem Application procedure cancellation Handover cancellation/ Radio Channel release/ Network path release/ Call release/ Associated procedure failure/ Tandem dialogue released/ Remote operations failure Procedure error - Specific information: This parameter may be used for passing any user specific information. Establishment and processing of the Specific information is not specified by GSMÊand shall be performed according to operator specific requirements. 7.3.5 MAP-P-ABORT service This service enables the MAP service-provider to abort a MAP dialogue. The service is a provider-initiated service with service-primitives as shown in tableÊ7.3/8. TableÊ7.3/8: Service-primitives for the MAP-P-ABORT service Parameters Indication Provider reason M Source M Provider reason: This parameter indicates the reason for aborting the MAP dialogue: - provider malfunction; - supporting dialogue/transaction released; - resource limitation; - maintenance activity; - version incompatibility; - abnormal MAP dialogue. Source: This parameter indicates the source of the abort. For Transaction Capabilities (TC) applications the parameter may take the following values: - MAP problem; - TC problem; - network service problem. TableÊ7.3/9: Values of provider reason and source parameters and examples of corresponding events Provider reason Source Corresponding event Provider MAP Malfunction at MAP level at peer entity malfunction TC ""Unrecognised message type"" or ""Badly formatted transaction portion"" or ""Incorrect transaction portion"" received in TC-P-ABORT ""Abnormal dialogue"" Network service Malfunction at network service level at peer entity Supporting dialogue/ transaction released TC ""Unrecognised transaction ID"" received in TC-ABORT Resource MAP Congestion towards MAP peer service-user limitation TC ""Resource limitation"" received in TC-P-ABORT Maintenance MAP Maintenance at MAP peer service-user activity Network service Maintenance at network peer service level Abnormal MAP dialogue MAP MAP dialogue is not in accordance with specified application context Version incompatibility TC A Provider Abort indicating ""No common dialogue portion"" is received in the dialogue initiated state 7.3.6 MAP-NOTICE service This service is used to notify the MAP service-user about protocol problems related to a MAP dialogue not affecting the state of the protocol machines. The service is a provider-initiated service with service-primitive as shown in tableÊ7.3/10. TableÊ7.3/10: Service-primitive for the MAP-NOTICE service Parameters Indication Problem diagnostic M Problem diagnostic: This parameter can take one of the following values: - abnormal event detected by the peer; - response rejected by the peer; - abnormal event received from the peer; - message cannot be delivered to the peer. 7.3.7 Void 7.3.8 Void 7.3.9 Void 7.3.10 Void 7.4 Sequencing of services The sequencing of services is shown in figureÊ7.4/1 and is as follows: Opening: The MAP-OPEN service is invoked before any user specific service-primitive is accepted. The sequence may contain none, one or several user specific service-primitives. If no user specific service-primitive is contained between the MAP-OPEN and the MAP-DELIMITER primitives, then this will correspond to sending an empty Begin message in TC. If more than one user specific service-primitive is included, all are to be sent in the same Begin message. The sequence ends with a MAP-DELIMITER primitive. Continuing: This sequence may not be present in some MAP dialogues. If it is present, it ends with a MAP-DELIMITER primitive. If more than one user specific service-primitive is included, all are to be included in the same Continue message. Closing: The sequence can only appear after an opening sequence or a continuing sequence. The sequence may contain none, one or several user specific service-primitives if the MAP-CLOSE primitive specifies normal release. If no user specific service-primitive is included, then this will correspond to sending an empty End message in TC. If more than one user specific service-primitive is included, all are to be sent in the same End message. If prearranged end is specified, the sequence cannot contain any user specific service-primitive. The MAP-CLOSE primitive must be sent after all user specific service-primitives have been delivered to the MAP service-provider. Aborting: A MAP service-user can issue a MAP-U-ABORT primitive at any time after the MAP dialogue has been opened or as a response to an attempt to open a MAP dialogue. The MAP service-provider may issue at any time a MAP-P-ABORT primitive towards a MAP service-user for which a MAP dialogue exists. MAP-U-ABORT primitives and MAP-P-ABORT primitives terminate the MAP dialogue. a) Opening b) Continuing c) Closing d) Aborting FigureÊ7.4/1: Sequencing of services If the reason ""resource unavailable (short term problem)"" is indicated in the MAP-U-ABORT indication primitive, the MAP service-user may decide to attempt a new MAP dialogue establishment immediately. Sequencing of user specific service-primitives is done by the MAP service-user and based on rules applicable for each MAP service-user instance. A MAP-NOTICE indication primitive may be received at any time during the active period of a MAP dialogue. 7.5 General rules for mapping of services onto TC 7.5.1 Mapping of common services TableÊ7.5/1 gives an overview of the mapping rules for mapping of common services onto TC-services. TableÊ7.5/2 gives the mapping rules for mapping of TC-services onto common services. Protocol machine description is given in clauses 14 to 17. TableÊ7.5/1: Mapping of common services onto TC services MAP service-primitive TC service-primitive MAP-OPEN request (+ any user specific service primitives) + MAP-DELIMITER request TC-BEGIN request (+ component handling primitives) MAP-OPEN response (+ any user specific service primitives) + MAP-DELIMITER request TC-CONTINUE request (note) (+ component handling primitives) (any user specific service primitives) + MAP-DELIMITER request TC-CONTINUE request (+ component handling primitives) (any user specific service primitives) + MAP-CLOSE request TC-END request (+ component handling primitives) MAP-U-ABORT request TC-U-ABORT request NOTE: Or TC-END if the MAP-CLOSE request has been received before the MAP-DELIMITER request. TableÊ7.5/2: Mapping of TC services onto common service TC service-primitive MAP service-primitive TC-BEGIN indication (+ component handling primitives) MAP-OPEN indication (+ user specific service primitives) + MAP-DELIMITER indication (note 1) TC-CONTINUE indication (+ component handling primitives) First time: MAP-OPEN confirm (+ user specific service primitives) + MAP-DELIMITER indication (note 1) Subsequent times: (user specific service primitives) + MAP-DELIMITER indication (note 1) TC-END indication (+ component handling primitives) MAP-OPEN confirm (note 6) (user specific service primitives) + MAP-CLOSE indication TC-U-ABORT indication MAP-U-ABORT indication or MAP-P-ABORT indication (note 2) MAP-OPEN confirmation (note 3) TC-P-ABORT indication MAP-P-ABORT indication (note 4) MAP-OPEN confirmation (note 5) NOTE 1: It may not be necessary to present this primitive to the user for MAP version 2 applications. NOTE 2: The mapping depends on whether the TC-U-ABORT indication primitive contains a MAP abort PDU from the remote MAP service-provider or a MAP-user-abort-PDU from the remote MAP service-user. NOTE 3: Only if the opening sequence is pending and if the ""Abort Reason"" in the TC-U-ABORT indication is set to ""Application Context Not Supported"". NOTE 4: If the ""Abort Reason"" in the TC-P-ABORT indication is set to a value different from ""Incorrect Transaction Portion"". NOTE 5: Only if the opening sequence is pending and if the ""Abort Reason"" in the TC-P-ABORT indication is set to ""Incorrect Transaction Portion"". NOTE 6: Only if opening sequence is pending. 7.5.2 Mapping of user specific services TableÊ7.5/3 gives the general mapping rules which apply to mapping of MAP user specific services onto TC services and tableÊ7.5/4 gives the similar rules for mapping of TC services onto MAP user specific services. Detailed mapping is given in clauses 14 to 17. TableÊ7.5/3: Mapping of MAP user specific services onto TC services MAP service-primitive TC-service-primitive MAP-xx request TC-INVOKE request MAP-xx response TC-RESULT-L request (note 1) TC-U-ERROR request TC-U-REJECT request TC-INVOKE request (note 2) TableÊ7.5/4: Mapping of TC services onto MAP user specific services TC-service-primitive MAP service-primitive TC-INVOKE indication MAP-xx indication TC-RESULT-L indication (note 4) MAP-xx confirm TC-U-ERROR indication TC-INVOKE indication (note 2) TC-L-CANCEL indication TC-U-REJECT indication MAP-xx confirm or TC-L-REJECT indication MAP-NOTICE indication (note 3) TC-R-REJECT indication Notes to tables 7.5/3 and 7.5/4: NOTE 1: The mapping is determined by parameters contained in the MAP-xx response primitive. NOTE 2: This applies only to TC class 4 operations where the operation is used to pass a result of another class 2 or class 4 operation. NOTE 3: The detailed mapping rules are given in clauseÊ16. NOTE 4: If RESULT-NL components are present they are mapped onto the same MAP-xx confirm. 7.6 Definition of parameters 7.6.1 Common parameters The following set of parameters is used in several MAP service-primitives. 7.6.1.1 Invoke Id This parameter identifies corresponding service primitives. The parameter is supplied by the MAP service-user and must be unique over each service-user/service-provider interface. 7.6.1.2 Linked Id This parameter is used for linked services and it takes the value of the invoke Id of the service linked to. 7.6.1.3 Provider error This parameter is used to indicate a protocol related type of error: - duplicated invoke Id; - not supported service; - mistyped parameter; - resource limitation; - initiating release, i.e. the peer has already initiated release of the dialogue and the service has to be released; - unexpected response from the peer; - service completion failure; - no response from the peer; - invalid response received. 7.6.1.4 User error This parameter can take values as follows: NOTE: The values are grouped in order to improve readability; the grouping has no other significance. a) Generic error: - system failure, i.e. a task cannot be performed because of a problem in the entity reporting the error or in another entity. The type of entity or network resource may be indicated by use of the network resource parameter or additional network resource parameter. If and only if the problem is in the entity reporting the error, a cause of failure (FailureCauseParam) shall be included; - data missing, i.e. an optional parameter required by the context is missing; - unexpected data value, i.e. the data type is formally correct but its value or presence is unexpected in the current context; - resource limitation; - initiating release, i.e. the receiving entity has started the release procedure; - facility not supported, i.e. the requested facility is not supported by the PLMN with detailed reasons as follows: - Shape of location estimate not supported; - Needed LCS capability not supported in serving node; - incompatible terminal, i.e. the requested facility is not supported by the terminal. b) Identification or numbering problem: - unknown subscriber, i.e. no such subscription exists; - number changed, i.e. the subscription does not exist for that number any more; - unknown MSC; - unidentified subscriber, i.e. if the subscriber is not contained in the database and it has not or cannot be established whether or not a subscription exists; - unallocated roaming number; - unknown equipment; - unknown location area. c) Subscription problem: - roaming not allowed, i.e. a location updating attempt is made in an area not covered by the subscription; - illegal subscriber, i.e. illegality of the access has been established by use of authentication procedure; - bearer service not provisioned; - teleservice not provisioned; - illegal equipment, i.e. the IMEI check procedure has shown that the IMEI is prohibited-listed or not permitted-listed. d) Handover problem: - no handover number available, i.e. the VLR cannot allocate a number for handover or cannot allocate the required amount of numbers for relocation; - subsequent handover failure, i.e. handover to a third MSC failed for some reason; - target cell outside group call area. e) Operation and maintenance problem: - tracing buffer full, i.e. tracing cannot be performed because the tracing capacity is exceeded. f) Call set-up problem: - no roaming number available, i.e. a roaming number cannot be allocated because all available numbers are in use; - absent subscriber, i.e. the subscriber has activated the detach service or the system detects the absence condition. This error may be qualified to indicate whether the subscriber was IMSI detached, in a restricted area or did not respond to paging; - busy subscriber. This error may be qualified to indicate that the subscriber was busy due to CCBS and that CCBS is possible; - no subscriber reply; - forwarding violation, i.e. the call has already been forwarded the maximum number of times that is allowed; - CUG reject, i.e. the call does not pass a CUG check; additional information may also be given in order to indicate rejection due to e.g. incoming call barred or non-CUG membership; - call barred. Optionally, additional information may be included for indicating either that the call meets a barring condition set by the subscriber or that the call is barred for operator reasons. In the case of barring of Mobile Terminating Short Message, the additional information may indicate a barring condition due to ""Unauthorised Message Originator""; if the call is rejected due to the application of the ACR supplementary service, the additional information shall indicate a barring condition due to ""Anonymous Call Rejection""; - optimal routeing not allowed, i.e. the entity which sends the error does not support optimal routeing, or the HLR will not accept an optimal routeing interrogation from the GMSC, or the call cannot be optimally routed because it would contravene optimal routeing constraints; - forwarding failed, i.e. the GMSC interrogated the HLR for forwarding information but the HLR returned an error. g) Supplementary services problem: - call barred; - illegal SS operation; - SS error status; - SS not available; - SS subscription violation; - SS incompatibility; - negative password check; - password registration failure; - Number of Password Attempts; - USSD Busy; - Unknown Alphabet; - short term denial; - long term denial. For definition of these errors see 3GPP TS 24.080 [38]. h) Short message problem: - SM delivery failure with detailed reason as follows: - memory capacity exceeded; - MS protocol error; - MS not equipped; - unknown service centre (SC); - SC congestion; - invalid SME address; - subscriber is not an SC subscriber; - and possibly detailed diagnostic information, coded as specified in 3GPP TS 23.040, under SMS-SUBMIT-REPORT and SMS-DELIVERY-REPORT. If the SM entity that returns the SM Delivery Failure error includes detailed diagnostic information, it shall be forwarded in the MAP_MO_FORWARD_SHORT_MESSAGE and in the MAP_MT_FORWARD_SHORT_MESSAGE response. - message waiting list full, i.e. no further SC address can be added to the message waiting list. - Subscriber busy for MT SMS, i.e. the mobile terminated short message transfer cannot be completed because: - another mobile terminated short message transfer is going on and the delivery node does not support message buffering; or - another mobile terminated short message transfer is going on and it is not possible to buffer the message for later delivery; or - the message was buffered but it is not possible to deliver the message before the expiry of the buffering time defined in 3GPP TS 23.040; - Absent Subscriber SM, i.e. the mobile terminated short message transfer cannot be completed because the network cannot contact the subscriber. Diagnostic information regarding the reason for the subscriber's absence may be included with this error. i) Location services problem: - Unauthorised Requesting Network - Unauthorised LCS Client with detailed reasons as follows: - NoAdditional Information - Client not in MS Privacy Exception List - Call to Client not setup - Disallowed by Local Regulatory Requirements - Unauthorised Privacy Class - Unauthorised Call/Session Unrelated External Client - Unauthorised Call/Session Related External Client - Privacy override not applicable - Position method failure with detailed reasons as follows: - Congestion - Insufficient resources - Insufficient Measurement Data - Inconsistent Measurement Data - Location procedure not completed - QoS not attainable - Position Method Not Available in Network - Position Method Not Available in Location Area - Unknown or unreachable LCS Client. 7.6.1.5 All Information Sent This parameter indicates to the receiving entity when the sending entity has sent all necessary information. 7.6.2 Numbering and identification parameters 7.6.2.1 IMSI This parameter is the International Mobile Subscriber Identity defined in 3GPP TS 23.003 [17]. 7.6.2.2 TMSI This parameter is the Temporary Mobile Subscriber Identity defined in 3GPP TS 23.003 [17]. 7.6.2.3 IMEI This parameter is the International Mobile Equipment Identity defined in 3GPP TS 23.003 [17]. 7.6.2.3a IMEISV This parameter is the International Mobile Equipment Identity and Software Version Number defined in 3GPP TS 23.003 [17]. 7.6.2.4 Previous location area Id This parameter refers to the identity of the location area from which the subscriber has roamed. 7.6.2.5 Stored location area Id This parameter refers to the location area where the subscriber is assumed to be located. 7.6.2.6 Current location area Id This parameter is used to indicate the location area in which the subscriber is currently located. 7.6.2.7 Target location area Id This parameter refers to the location area into which the subscriber intends to roam. 7.6.2.8 Target cell Id This parameter refers to the identity of the cell to which a call has to be handed over. 7.6.2.8A Target RNC Id This parameter refers to the identity of the RNC to which a call has to be relocated. 7.6.2.9 Void 7.6.2.10 Originating entity number This parameter refers to an application layer identification of a system component in terms of its associated ISDN number. 7.6.2.11 MSC number This parameter refers to the ISDN number of an MSC. 7.6.2.12 Target MSC number This parameter refers to the ISDN number of an MSC to which a call has to be handed over. 7.6.2.13 HLR number This parameter refers to the ISDN number of an HLR. 7.6.2.14 VLR number This parameter refers to the ISDN number of a VLR. 7.6.2.15 HLR Id This parameter refers to the identity of an HLR derived from the IMSI defined in CCITT Recommendation E.212. 7.6.2.16 LMSI This parameter refers to a local identity allocated by the VLR to a given subscriber for internal management of data in the VLR. LMSI shall not be sent to the SGSN. 7.6.2.17 MS ISDN This parameter refers to one of the ISDN numbers assigned to a mobile subscriber in accordance with CCITT Recommendation E.213. 7.6.2.17A Additional MSISDN This parameter refers to an ISDN number assigned on top of the existing MSISDN, to a user with a connection to the PS domain (see 3GPP TS 23.003 [17]). If the Additional MSISDN is available its value shall be used as C MSISDN on the Sv interface. 7.6.2.18 OMC Id This parameter refers to the identity of an Operation and Maintenance Centre. 7.6.2.19 Roaming number This parameter refers to the roaming number as defined in CCITT Recommendation E.213. 7.6.2.19A Relocation Number List This parameter refers to the number(s) used for routing one call or several calls between MSCs during relocation. 7.6.2.20 Void 7.6.2.21 Handover number This parameter refers to the number used for routing a call between MSCs during handover. 7.6.2.22 Forwarded-to number This parameter refers to the address to which a call is to be forwarded. A subaddress may be appended. For subscribers having an originating CAMEL Phase 2 or higher subscription, this address need not be in E.164 international format. 7.6.2.22A Long forwarded-to number This parameter refers to the address to which a call is to be forwarded. A subaddress may be appended. For subscribers having an originating CAMEL Phase 2 or higher subscription this address need not be in international format. 7.6.2.22B Long FTN Supported This parameter indicates that the sending entity supports Long Forwarded-to Numbers. 7.6.2.23 Forwarded-to subaddress This parameter refers to the sub-address attached to the address to which a call is to be forwarded. 7.6.2.24 Called number This parameter refers to a called party number as defined in CCITT Recommendation Q.767. 7.6.2.25 Calling number This parameter refers to a calling party number as defined in CCITT Recommendation Q.767. 7.6.2.26 Originally dialled number This parameter refers to the number dialled by the calling party in order to reach a mobile subscriber. 7.6.2.27 Service centre address This parameter represents the address of a Short Message Service Centre. 7.6.2.28 Zone Code This parameter is used to define location areas into which the subscriber is allowed or not allowed to roam (regional subscription). With a complete list of Zone Codes the VLR or the SGSN or MME is able to determine for all its location areas, routing areas or tracking areas whether roaming is allowed or not. 7.6.2.29 MSIsdn-Alert This parameter refers to the MSISDN stored in a Message Waiting Data File in the HLR. It is used to alert the Service Centre when the MS is again attainable. 7.6.2.30 Location Information The VLR indicates in this parameter the location of the served subscriber as defined in 3GPP TS 23.018 [97]. 7.6.2.30a Location Information for GPRS The SGSN indicates in this parameter the location of the served subscriber as defined in 3GPP TS 23.078 [98]. 7.6.2.30b Location Information for EPS The MME (via an IWF) indicates in this parameter the location of the served subscriber. 7.6.2.31 GMSC Address This parameter refers to the E.164 address of a GMSC. 7.6.2.32 VMSC Address This parameter refers to the E.164 address of a VMSC. 7.6.2.33 Group Id This parameter is used to describe groups a subscriber can be a member of. A subscriber can partake in all group calls (VBS/VGCS) where he subscribed to the respective groups. 7.6.2.34 North American Equal Access preferred Carrier Id This parameter refers to the carrier identity preferred by the subscriber for calls requiring routing via an inter-exchange carrier. This identity is used at: - outgoing calls: when the subscriber does not specify at call set-up a carrier identity; - forwarded calls: when a call is forwarded by the subscriber; - incoming calls: applicable to the roaming leg of the call. 7.6.2.35 Void 7.6.2.36 Void 7.6.2.37 Serving cell Id This parameter indicates the cell currently being used by the served subscriber. 7.6.2.38 SGSN number This parameter refers to the ISDN number of a SGSN. 7.6.2.39 SGSN address This parameter refers to the IP-address of a SGSN. This parameter is defined in 3GPP TS 23.003 [17]. 7.6.2.40 GGSN address This parameter refers to the IP-address of a GGSN. This parameter is defined in 3GPP TS 23.003 [17]. 7.6.2.41 GGSN number This parameter refers to the ISDN number of a GGSN or the ISDN number of the protocol-converter if a protocol converting GSN is used between the GGSN and the HLR. 7.6.2.42 APN This parameter refers to the DNS name of a GGSN. This parameter is defined in 3GPP TS 23.060 [104]. 7.6.2.43 Network Node number This parameter refers to the ISDN number of an MT-SMS target node (MSC or MME, SGSN, or IP-SM-GW) or of an SMS Router. 7.6.2.43A Network Node Diameter Address This parameter refers to the Diameter Name and Realm of the same MT-SMS target node or SMS Router of which the ISDN number is within the Network Node number parameter. 7.6.2.44 PDP-Type This parameter indicates which type of protocol is used by the MS as defined in 3GPP TS 23.060 [104]. The allowed values are one of IPv4 encoded as HEX (21) or IPv6 encoded as HEX (57), or Non-IP encoded as HEX (02). NOTE: To indicate both IPv4 and IPv6 PDP types are allowed, but not IPv4v6, two PDP contexts need to be present in the subscription for the same APN, one indicating IPv4 PDP type and one indicating IPv6 PDP type. 7.6.2.44A Extension PDP-Type This parameter indicates the support of the dual-stack PDP-type (IPv4v6) encoded as HEX (8D) by a certain PDP, as defined in 3GPP TS 23.060 [104], and it is an extension to PDP-Type. 7.6.2.45 PDP-Address This parameter indicates the address of the data protocol as defined in 3GPP TS 23.060 [104]. 7.6.2.45A Extension PDP-Address This parameter indicates an additional address of the data protocol, and it is included when the PDP supports dual-stack (IPv4v6). It is an extension to PDP-Address and it is encoded in the same way. IPv4 or IPv6 address types can be used in this parameter but, when both parameters are present, each of them shall contain different address types. 7.6.2.46 Additional number This parameter refers to the ISDN number of an additional MT-SMS target node (MSC or MME or SGSN) or of an SMS Router. 7.6.2.46A Additional Network Node Diameter Address This parameter refers to an additional Diameter Name and Realm of the same MT-SMS target node or SMS Router of which the ISDN number is within the Additional number parameter. 7.6.2.46B Third Number This parameter refers to the ISDN number of a third MT-SMS target node (MSC or MME or SGSN). 7.6.2.46C Third Network Node Diameter Address This parameter refers to the third Diameter Name and Realm of the same MT-SMS target node of which the ISDN number is within the Third number parameter. 7.6.2.47 P-TMSI This parameter is the Packet Temporary Mobile Subscriber Identity defined in 3GPP TS 23.003 [17]. 7.6.2.48 B-subscriber number This parameter refers to the number of the destination B dialled by the A user. This may include a subaddress. 7.6.2.49 B-subscriber subaddress This parameter refers to the sub-address attached to the destination B dialled by the A user. 7.6.2.50 LMU Number This parameter refers to a local number assigned to an LMU by an SMLC. 7.6.2.51 MLC Number This parameter refers to the ISDN (E.164) number of an MLC. 7.6.2.52 Multicall Bearer Information This parameter refers to the number of simultaneous bearers supported per user by the serving network. 7.6.2.53 Multiple Bearer Requested This parameter indicates whether multiple bearers are requested for a relocation. 7.6.2.54 Multiple Bearer Not Supported This parameter indicates whether multiple bearers are supported. 7.6.2.55 PDP-Charging Characteristics This parameter indicates the charging characteristics associated with a specific PDP context as defined in 3GPP TSÊ32.215. 7.6.2.56 Selected RAB ID The selected radio access bearer to be kept at subsequent inter-MSC handover from UMTS to GSM. 7.6.2.57 RAB ID This parameter indicates the radio access bearer identifier as defined in 3GPP TS 25.413. This parameter is used to relate the radio resources with the radio access bearers. 7.6.2.58 gsmSCF Address This parameter refers to the ISDN number assigned to the gsmSCF address. In an IP Multimedia Core Network, the gsmSCF-address shall contain the IM-SSF address when the IM-SSF takes the role of the gsmSCF. 7.6.2.59 V-GMLC Address This parameter refers to the IP address of a V-GMLC. 7.6.2.60 Void 7.6.2.61 H-GMLC Address This parameter refers to the IP address of a H-GMLC. 7.6.2.62 PPR Address This parameter refers to the IP address of a Privacy Profile Register. 7.6.2.63 Routeing Number This parameter refers to a number used for routeing purpose and identifying a network operator. See 3GPP TS 23.066 [108]. 7.6.2.64 Additional V-GMLC Address This parameter refers to the IP address of a V-GMLC. 7.6.2.65 MME Name This parameter refers to the Diameter Identity of an MME as defined in 3GPP TS 23.003 [17]. 7.6.2.66 3GPP AAA Server Name This parameter refers to the Diameter Identity of a 3GPP AAA server as defined in 3GPP TS 29.273 [151]. 7.6.2.67 CSS number This parameter refers to the ISDN number of a CSS as defined in 3GPP TS 23.003[17]. 7.6.2.68 SGSN Name This parameter refers to the Diameter Identity of an SGSN as defined in 3GPP TS 23.003 [17]. 7.6.2.69 SGSN Realm This parameter refers to the Diameter Identity of an SGSN as defined in 3GPP TS 23.003 [17]. 7.6.3 Subscriber management parameters 7.6.3.1 Category This parameter refers to the calling party category as defined in CCITT Recommendation Q.767. 7.6.3.2 Equipment status This parameter refers to the status of the mobile equipment as defined in 3GPP TS 22.016 [7]. 7.6.3.2a BMUEF This parameter refers to the Bit Map of UE Faults and corresponds to the UESBI-Iu parameter defined in 3GPP TS 25.413 [120]. 7.6.3.3 Extensible Bearer service This parameter may refer to a single bearer service, a set of bearer services or to all bearer services as defined in 3GPP TS 22.002 [3]. This parameter is used only for subscriber profile management. Extensible Bearer service values include all values defined for a Bearer service parameter (7.6.4.38). 7.6.3.4 Extensible Teleservice This parameter may refer to a single teleservice, a set of teleservices or to all teleservices as defined in 3GPP TS 22.003 [4]. This parameter is used only for subscriber profile management. Extensible Teleservice values include all values defined for a Teleservice parameter (7.6.4.39). 7.6.3.5 Extensible Basic Service Group This parameter refers to the Basic Service Group either as an extensible bearer service (see clause 7.6.3.3) or an extensible teleservice (see clause 7.6.3.4). This parameter is used only for subscriber profile management. The null value (i.e. neither extensible bearer service nor extensible teleservice) is used to denote the group containing all extensible bearer services and all extensible teleservices. 7.6.3.6 GSM bearer capability This parameter refers to the GSM bearer capability information element defined in 3GPP TS 24.008 [35]. 7.6.3.7 Subscriber Status This parameter refers to the barring status of the subscriber: - service granted; - Operator Determined Barring. 7.6.3.8 CUG Outgoing Access indicator This parameter represents the Outgoing Access as defined in ETSÊ300Ê136. 7.6.3.9 Operator Determined Barring General Data This parameter refers to the set of subscriber features that the network operator or the service provider can regulate. This set only includes those limitations that can be a) controlled in the VLR, b) controlled in the SGSN or MME, c) controlled in the SGSN applied for short message transfer only, d) interrogated or modified by the gsmSCF: ODB category Controlled in the VLR Controlled in the SGSN or MME Controlled in the SGSN applied for short message transfer only Interrogatable and modifyable by the gsmSCF All outgoing calls barred X X X International outgoing calls barred X X X International outgoing calls except those to the home PLMN country barred X X X Interzonal outgoing calls barred X X X Interzonal outgoing calls except those to the home PLMN country barred X X X Interzonal outgoing calls AND international outgoing calls except those directed to the home PLMN country barred X X X Premium rate (information) outgoing calls barred X X Premium rate (entertainment) outgoing calls barred X X Supplementary service access barred X X Invocation of call transfer barred X X Invocation of chargeable call transfer barred X X Invocation of internationally chargeable call transfer barred X X Invocation of interzonally chargeable call transfer barred X X Invocation of call transfer where both legs are chargeable barred X X Invocation of call transfer if there is already an ongoing transferred call for the served subscriber in the serving MSC/VLR barred X X All packet Oriented Services barred X X Roamer Access to HPLMN-AP barred X X Roamer Access to VPLMN-AP barred X X Outgoing calls when roaming outside the home PLMN country X All incoming calls X Incoming calls when roaming outside the home PLMN country X Incoming calls when roaming outside the zone of the home PLMN country X Roaming outside the home PLMN X Roaming outside the home PLMN country X Registration of any call forwarded-to number X Registration of any international call forwarded-to number X Registration of any international call forwarded-to number except to a number within the HPLMN country X Registration of any inter-zone call forwarded-to number X Registration of any inter-zone call forwarded-to number except to a number within the HPLMN country X 7.6.3.10 ODB HPLMN Specific Data This parameter refers to the set of subscriber features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. This set only includes those limitations that can be controlled in the VLR or in the SGSN or MME: - Operator Determined Barring Type 1; - Operator Determined Barring Type 2; - Operator Determined Barring Type 3; - Operator Determined Barring Type 4. 7.6.3.11 Regional Subscription Data This parameter defines the regional subscription area in which the subscriber is allowed to roam. It consists of a list of Zone Codes (see clause 7.6.2.28). 7.6.3.12 Regional Subscription Response This parameter indicates either that the regional subscription data cannot be handled or that the current MSC or SGSN or MME area is entirely restricted because of regional subscription. 7.6.3.13 Roaming Restriction Due To Unsupported Feature This parameter defines that a subscriber is not allowed to roam in the current MSC area. It may be used by the HLR if a feature or service is indicated as unsupported by the VLR. 7.6.3.14 Extensible SS-Info This parameter refers to all the information related to a supplementary service and is a choice between: - extensible forwarding information (see clauseÊ7.6.3.15); - extensible call barring information (see clauseÊ7.6.3.20); - CUG info (see clauseÊ7.6.3.22); - extensible SS-Data (see clauseÊ7.6.3.29). 7.6.3.15 Extensible forwarding information This parameter represents the information related to each call forwarding service: - the SS-Code of the relevant call forwarding service (see clause 7.6.4.1); - if required, a list of extensible forwarding feature parameters (see clause 7.6.3.16). The list may contain one item per Basic Service Group. 7.6.3.16 Extensible forwarding feature This parameter applies to each combination of call forwarding service and Basic Service Group and contains the following information, as required: - extensible Basic Service Group (see clause 7.6.3.5); - extensible SS-Status (see clause 7.6.3.17); - forwarded-to number (see clause 7.6.2.22); - forwarded-to subaddress (see clause 7.6.2.23); - extensible forwarding options (see clause 7.6.3.18); - extensible no reply condition timer (see clause 7.6.4.19); - long forwarded-to number (see clause 7.6.2.22A). If a number is required to define the forwarded-to destination then: - If the VLR supports Long Forwarded-to Numbers then the long forwarded-to number shall be present and the forwarded-to number shall be absent; - If the VLR does not support Long Forwarded-to Numbers then the forwarded-to number shall be present and the long forwarded-to number shall be absent. 7.6.3.17 Extensible SS-Status This parameter refers to the state information of individual supplementary services as defined in 3GPP TS 23.011 [22]. 7.6.3.18 Extensible Forwarding Options This parameter refers to a set of forwarding options attached to a supplementary service. It contains the following information: - notification to forwarding party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - redirection notification to the forwarded-to party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - notification to calling party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - redirecting presentation (see 3GPP TS 22.082 [10] for the meaning of this parameter); - forwarding reason (see 3GPP TS 22.082 [10] for the meaning of this parameter). 7.6.3.19 Extensible No reply condition timer This parameter refers to the extensible no reply condition timer for call forwarding on no reply. 7.6.3.20 Extensible Call barring information This parameter contains for each call barring service: - SS-Code (see clauseÊ7.6.4.1); - a list of extensible call barring feature parameters (see clauseÊ7.6.3.21)."
"The list may contain one item per Basic Service Group. 7.6.3.21 Extensible Call barring feature This parameter gives the status of call barring services as applicable to each Basic Service Group. The parameter contains the following information: - Extensible Basic Service Group (see clauseÊ7.6.3.5); - provisioned SS-Status (see clauseÊ7.6.3.17). 7.6.3.22 CUG info This parameter refers to the overall information required for operation for each CUG: - CUG subscriptionList; - CUG featureList. 7.6.3.23 CUG subscription This parameter refers to the set of basic information for each CUG defined in that subscription. The following information is stored: - CUG index; - CUG interlock; - Intra CUG restrictions; - Basic Service Group List. 7.6.3.24 CUG interlock This parameter represents the CUG interlock code defined in ETS 300 138. 7.6.3.25 CUG index This parameter represents the CUG index defined in ETS 300 138. 7.6.3.26 CUG feature This parameter contains two parameters that are associated with the Basic Service Group. If the Basic Service Group Code is not present the feature applies to all Basic Services. The following parameters are included: - Preferential CUG indicator: - indicates which CUG index is to be used at outgoing call set-up using the associated Basic Service Group; - Inter CUG Option: - describes whether it for the associated Basic Service Group is allowed to make calls outside the CUG and whether incoming calls are allowed; - Basic Service Group. See 3GPP TS 22.085 [13] for meaning of this parameter. 7.6.3.27 Inter CUG options This parameter indicates the subscribers' ability to make and receive calls outside a specific closed user group. It takes any of the following values: - CUG only facility (only calls within CUG are allowed); - CUG with outgoing access (calls outside CUG allowed); - CUG with incoming access (calls from outside CUG into CUG allowed); - CUG with both incoming and outgoing access (all calls allowed). 7.6.3.28 Intra CUG restrictions This parameter describes whether or not the subscriber is allowed to originate calls to or to receive calls from within the CUG. It can take any of the following values: - no CUG restrictions; - CUG incoming calls barred; - CUG outgoing calls barred. 7.6.3.29 Extensible SS-Data This parameter refers to the necessary set of information required in order to characterise one supplementary service: - SS-Code (see clause 7.6.4.1); - Extensible SS-Status (if applicable) (see clause 7.6.3.17); - Extensible Override subscription option (if applicable) (see clause 7.6.3.30); - Extensible CLI Restriction (if applicable) (see clause 7.6.3.31); - Extensible Basic Service Group Code (see clause 7.6.3.5). 7.6.3.30 Subscriber State This parameter indicates the state of the MS as defined in 3GPP TS 23.018 [97]. 7.6.3.31 Requested Info This parameter indicates the subscriber information being requested as defined in 3GPP TSÊ23.018Ê[97] and 3GPP TSÊ23.078Ê[98]. 7.6.3.31A Requested Domain This parameter indicates the domain (circuit switched, i.e. from the MSC/VLR, or packet switched, i.e. from the SGSN) from which the requested information should be retrieved. 7.6.3.32 Suppression of Announcement This parameter indicates if the announcement or tones shall be suppressed as defined in 3GPP TS 23.078Ê[98]. 7.6.3.33 Suppress T-CSI This parameter is used to suppress the invocation of terminating CAMEL services. 7.6.3.34 GMSC CAMEL Subscription Info This parameter contains CAMEL subscription information, i.e. O-CSI and/or D-CSI and/or T-CSI, which indicates to the GMSC that originating and/or terminating CAMEL services shall be invoked for the incoming call. 7.6.3.35 VLR CAMEL Subscription Info This parameter identifies the subscriber as having CAMEL services that are invoked in the MSC or VLR. 7.6.3.36 Supported CAMEL Phases in the VLR This parameter indicates which phases of CAMEL are supported in the VLR. 7.6.3.36A Supported CAMEL Phases in the SGSN This parameter indicates which phases of CAMEL are supported in the SGSN. 7.6.3.36B Offered CAMEL4 CSIs in the VLR This parameter indicates which CSIs of CAMEL phase 4 are offered in the VLR as defined in 3GPP TS 23.078. 7.6.3.36C Offered CAMEL4 CSIs in the SGSN This parameter indicates which CSIs of CAMEL phase 4 are offered in the SGSN as defined in 3GPP TS 23.078. 7.6.3.36D Offered CAMEL4 CSIs This parameter indicates which CSIs of CAMEL phase 4 are offered as defined in 3GPP TS 23.078. 7.6.3.36E Offered CAMEL4 CSIs in interrogating node This parameter indicates which CSIs of CAMEL phase 4 are offered in the GMSC or in the gsmSCF as defined in 3GPP TS 23.078. 7.6.3.36F Offered CAMEL4 CSIs in VMSC This parameter indicates which CSIs of CAMEL phase 4 are offered in the VMSC as defined in 3GPP TS 23.078. 7.6.3.36G Offered CAMEL4 Functionalities 7.6.3.36H Supported CAMEL Phases This parameter indicates which phases of CAMEL are supported as defined in 3GPP TS 23.078. 7.6.3.36I Supported CAMEL Phases in interrogating node This parameter indicates which phases of CAMEL are supported as defined in 3GPP TS 23.078. The interrogating node may be a GMSC or a gsmSCF. This parameter indicates which functionalities of CAMEL phase 4 are offered as defined in 3GPP TS 23.078. 7.6.3.37 CUG Subscription Flag This parameter indicates that a subscriber with a T-CSI also has a CUG subscription. It is defined in 3GPP TS 23.078. 7.6.3.38 CAMEL Subscription Info Withdraw This parameter indicates that CAMEL Subscription Info shall be deleted from the VLR or SGSN. 7.6.3.39 Voice Group Call Service (VGCS) Data This parameter refers to one or more groups a subscriber may be a member of for voice group calls. 7.6.3.40 Voice Broadcast Service (VBS) Data This parameter refers to one or more groups a subscriber may be a member of for the voice broadcast service. Per group it is further indicated whether the subscriber is only allowed to listen to respective group calls or whether he is in addition entitled to initiate respective voice broadcast calls. 7.6.3.41 ISDN bearer capability This parameter refers to the ISDN bearer capability information element defined in 3GPP TS 29.007 [56]. 7.6.3.42 Lower layer Compatibility This parameter refers to the lower layer compatibility information element defined in 3GPP TS 24.008 [35]. 7.6.3.43 High Layer Compatibility This parameter refers to the high layer compatibility information element defined in 3GPP TS 24.008 [35]. 7.6.3.44 Alerting Pattern This parameter is an indication that can be used by the MS to alert the user in a specific manner in case of mobile terminating traffic (switched call or USSD). That indication can be an alerting level or an alerting category. 7.6.3.45 GPRS Subscription Data Withdraw This parameter indicates that GPRS Subscription Data shall be deleted from the SGSN. 7.6.3.45A EPS Subscription Data Withdraw This parameter indicates that EPS Subscription Data shall be deleted from the MME. 7.6.3.46 GPRS Subscription Data This parameter refers to the list of PDP-Contexts the subscriber has subscribed to. 7.6.3.46A EPS Subscription Data This parameter refers to the list of APN-Configurations the subscriber has subscribed to. 7.6.3.47 QoS-Subscribed This parameter indicates the quality of service subscribed for a certain service. It is defined in 3GPP TS 23.060 [104]. 7.6.3.48 VPLMN address allowed This parameter specifies whether the MS is allowed to use a dynamic address allocated in the VPLMN. It is defined in 3GPP TS 23.060 [104]. 7.6.3.49 Roaming Restricted In SGSN/MME Due To Unsupported Feature This parameter defines that a subscriber is not allowed to roam in the current SGSN or MME area. It may be used by the HLR if a feature or service is indicated as unsupported by the SGSN or MME. 7.6.3.50 Network Access Mode This parameter is defined in 3GPP TS 23.008 [20]. 7.6.3.51 Mobile Not Reachable Reason This parameter stores the reason for the MS being absent when an attempt to deliver a short message to an MS fails at the MSC, SGSN or both. It is defined in 3GPP TS 23.040. 7.6.3.52 Cancellation Type This parameter indicates the reason of location cancellation. It is defined in 3GPP TS 23.060 [104]. The HLR shall not send Cancel Location with a Cancellation Type of ""initialAttachProcedure"" to the SGSN unless the SGSN has indicated support of this cancellation type within UpdateGprsLocation or the HLR has enough knowledge that the SGSN supports ""initialAttachProcedure"". If the HLR needs to send a cancellation type of ""initialAttachProcedure"" but cannot do so due to non-support by the SGSN, the HLR shall send Cancel Location with a Cancellation Type of ""updateProcedure"" and delete the stored SGSN-Number. 7.6.3.53 All GPRS Data This parameter indicates to the SGSN that all GPRS Subscription Data shall be deleted for the subscriber. 7.6.3.54 Complete Data List Included This parameter indicates to the SGSN or MME that the complete GPRS Subscription Data/EPS Subscription Data stored for the Subscriber shall be replaced with the GPRS Subscription Data/EPS Subscription Data received. 7.6.3.55 PDP Context Identifier This parameter is used to identify a PDP context for the subscriber. 7.6.3.56 LSA Information This parameter refers to one or more localised service areas a subscriber may be a member of, together with the priority, the preferential access indicator, the active mode support indicator and active mode indication of each localised service area. The access right outside these localised service areas is also indicated. 7.6.3.57 SoLSA support indicator This parameter indicates that the VLR or the SGSN supports SoLSA subscription. 7.6.3.58 LSA Information Withdraw This parameter indicates that LSA information shall be deleted from the VLR or the SGSN. 7.6.3.59 LMU Indicator This parameter indicates the presence of an LMU. 7.6.3.60 LCS Information This parameter defines the LCS related information for an MS subscriber and contains the following components: - GMLC List (see clause 7.6.3.61). - LCS Privacy Exception List (see clause 7.6.3.62). - MO-LR List (see clause 7.6.3.65A). - Additional LCS Privacy Exception List (see clause 7.6.3.62A). 7.6.3.61 GMLC List This parameter contains the addresses of all GMLCs that are permitted to issue a call/session unrelated or call/session related MT-LR location request for this MS. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.62 LCS Privacy Exception List This parameter defines the classes of LCS Client that are allowed to locate any target MS. For each class, the following information is provided: - SS-Code (see clauseÊ7.6.4.1); - a list of LCS privacy exception parameters (see clauseÊ7.6.3.63). 7.6.3.62A Additional LCS Privacy Exception List This parameter defines the classes of LCS Client that are allowed to locate any target MS. For each class, the following information is provided: - SS-Code (see clauseÊ7.6.4.1); - a list of LCS privacy exception parameters (see clauseÊ7.6.3.63). The Additional LCS Privacy Exception List shall be present only if the LCS Privacy Exception List is present and contains LCS privacy exception parameters for 4 privacy exception classes. 7.6.3.63 LCS Privacy Exception Parameters This parameter gives the status of each LCS privacy exception class and any additional parameters relevant to this class. The parameter contains the following information: - provisioned SS-Status (see clauseÊ7.6.3.17); - privacy notification to MS user (see clause 7.6.3.65B); - external client List (see clauseÊ7.6.3.64); - internal client List (see clause 7.6.3.65). - service type List (see clauseÊ7.6.3.65D); 7.6.3.64 External Client List This parameter is only applicable to the call/session unrelated privacy class and call/session related privacy class, and gives the identities of the external clients that are allowed to locate a target MS for a MT-LR. Each identity is an international (e.g.E.164) address. For each identified external client, GMLC restrictions may be defined. It may also be indicated if the MS shall be notified of a non-restricted MT-LR from each identified LCS client and, if so, whether notification only or notification with privacy verification shall apply. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.65 Internal Client List This parameter is only applicable to the PLMN operator privacy class and gives the identities of the internal PLMN operator clients that are allowed to locate a target MS for an NI-LR or MT-LR. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.65A MO-LR List This parameter defines the classes of MO-LR for which a subscription exists for a particular MS. For each class, the following information is provided: - SS-Code (see clauseÊ7.6.4.1). 7.6.3.65B Privacy Notification to MS User This parameter is applicable to the call/session unrelated privacy class and call/session related privacy class. For non-call/call related privacy class it indicates whether the MS user shall be notified for that class MT-LR from any value added LCS client when the MT-LR is restricted and be enabled to accept or override the restriction. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.65C GMLC List Withdraw This parameter indicates whether the subscriber's LCS GMLC list shall be deleted from the VLR or SGSN. 7.6.3.65D Service Type List This parameter is only applicable to the Service type privacy class and gives the identities of the service type of the clients that are allowed to locate a target MS for an MT-LR. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.66 IST Alert Timer This parameter indicates the IST Alert Timer value that must be used in the MSC to inform the HLR about the call activities that the subscriber performs. Units are minutes. 7.6.3.67 Call Termination Indicator This parameter indicates whether the MSC shall terminate a specific ongoing call, or all the call activities related to a specified subscriber. 7.6.3.68 IST Information Withdraw This parameter indicates that IST information shall be deleted from the VMSC. 7.6.3.69 IST Support Indicator This parameter indicates the degree of IST functionality supported by the MSC (Visited MSC or Gateway MSC). It can take one of the following values: - Basic IST functionality; - IST command service (in addition to the basic IST functionality and including the ability to terminate all calls being carried for the identified subscriber). 7.6.3.70 Super-Charger Supported In HLR This parameter is used by the HLR to indicate support of the Super-Charger functionality and an indication of the age of the subscription data stored in the HLR. 7.6.3.71 Super-Charger Supported In Serving Network Entity This parameter is used to indicate support of the Super-Charger functionality by the originating entity and to indicate either that subscription data is required or the date and time of the last know subscriber data modification. 7.6.3.72 Age Indicator This parameter is used by the HLR to determine the validity of the subscription data retained by the serving network entity in a Super-Charged network. 7.6.3.73 GPRS enhancements support indicator This parameter indicates to the HLR that the SGSN supports GPRS enhancements. 7.6.3.74 Extension QoS-Subscribed This parameter indicates the enhanced QoS subscribed for a certain service. It is defined in 3GPP TS 23.060. This parameter is an extension to QoS-Subscribed. 7.6.3.75 SGSN CAMEL Subscription Info This parameter identifies the subscriber as having CAMEL services that are invoked in the SGSN. 7.6.3.75A Extension-2 QoS-Subscribed This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used when the maximum bit rate exceeds 8640 kbps. For more details, refer to 3GPP TS 24.008Ê[35]. 7.6.3.75B Extension-3 QoS-Subscribed This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used when the maximum/guaranteed bit rate for uplink exceeds 8640 kbps. For more details, refer to 3GPP TS 24.008Ê[35]. 7.6.3.75C Extension-4 QoS-Subscribed This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used to define the Evolved Allocation/Retention Priority parameter, which includes the Priority Level, the Preemption Capability value and the Preemption vulnerability value, as described in 3GPP TS 29.060 [105]. 7.6.3.76 MO-SMS-CSI This parameter identifies the subscriber as having mobile originating SMS CAMEL services as defined in 3GPP TS 23.078. For the CAMEL phase 3 the MO-SMS-CSI is the same as the SMS-CSI. 7.6.3.76a MT-SMS-CSI This parameter identifies the subscriber as having mobile terminating SMS CAMEL services as defined in 3GPP TS 23.078. 7.6.3.77 GPRS-CSI This parameter identifies the subscriber as having GPRS CAMEL services as defined in 3GPP TS 23.078. 7.6.3.78 CAMEL subscription info This parameter indicates the CSI that can be controlled by CSE. 7.6.3.79 Extensible Call barring information for CSE This parameter contains for each call barring service for CSE: - SS-Code; - a list of extensible call barring feature parameters. The list may contain one item per Basic Service Group. - password; - wrong password attempt counter; - notification-to-CSE flag. 7.6.3.80 Extensible Forwarding information for CSE This parameter represents the information for CSE related to each call forwarding service: - the SS-Code of the relevant call forwarding service; - if required, a list of extensible forwarding feature parameters; - the list may contain one item per Basic Service Group; - notification-to-CSE flag. 7.6.3.81 Modification Request for CSI This parameter indicates the CAMEL subscription information to be modified by CSE. 7.6.3.81a Modification Request for ODB data This parameter indicates the operator determined barring data to be modified by CSE. 7.6.3.82 Modification Request for SS Information This parameter indicates the call forwarding, call barring, call hold, call waiting, explicit call transfer, calling line identification presentation and calling line identification restriction supplementary service data to be modified by CSE. 7.6.3.83 Call Barring Data This parameter contains the extensible call barring feature list (see clauseÊ7.6.3.21) and Notification to CSE flag. 7.6.3.84 Call Forwarding Data This parameter contains the extensible call forwarding feature list (see clause 7.6.3.16) and Notification to CSE flag. 7.6.3.85 ODB Data This parameter contains the ODB general data, ODB HPLMN specific data. 7.6.3.86 Requested Subscription Info This parameter indicates the subscription information being requested. 7.6.3.87 CS Allocation/Retention priority This parameter indicates the allocation/retention priority for Circuit Switched (CS). It corresponds to the allocation/retention priority that is defined in 3GPPÊTSÊ23.107Ê[154]. 7.6.3.88 ODB Info This parameter contains the ODB data and Notification to CSE flag. 7.6.3.89 Suppress VT-CSI This parameter is used to suppress the invocation of terminating CAMEL services at the VMSC. 7.6.3.90 Suppress Incoming Call Barring This parameter is used to suppress the invocation of Incoming Call Barrings. 7.6.3.91 gsmSCF Initiated Call This parameter is used to indicate that the call was initiated by the gsmSCF. 7.6.3.91a SuppressMTSS This parameter is used to suppress the invocation of terminating supplementary services 7.6.3.92 Call barring support indicator This parameter is used to indicate that the SGSN supports the call barring services for SMS. 7.6.3.93 MNP Info Result This parameter refers to the Mobile Number Portability (MNP) information result (see 3GPP TSÊ23.078Ê[98] and 3GPP TS 23.066 [108]). This parameter may contain the following information: - Routeing Number (see clause 7.6.2.63). - IMSI (see 3GPP TS 23.078[98], see also clause 7.6.2.1). - MSISDN (see clause 7.6.2.17). - Number Portability Status (see clause 7.6.5.14). 7.6.3.94 Allowed Services This parameter is used by the HLR to indicate which service is available for a call when two services have been requested, for the SCUDIF feature described in 3GPP TS 23.172 [126]. 7.6.3.95 Unavailability Cause This parameter is used to indicate the reason for the unavailability of one of the services as indicated by the Allowed Services IE (see 7.6.3.94) when two services have been requested, for the SCUDIF feature described in 3GPP TS 23.172 [126]. 7.6.3.96 MNP Requested Info This parameter indicates by its presence that Mobile Number Portability (MNP) information is requested for the subscriber, as defined in 3GPP TSÊ23.078Ê[98]. 7.6.3.97 Access Restriction Data This parameter refers to the radio access technologies that are possibly restricted to a subscriber via subscription data. For the use of the parameter, see 3GPP TS 23.012 [23] for the CS domain and 3GPP TS 23.060[104], 3GPP TS 29.060 [105] clause 7.5.3 and 3GPP TS 29.274 [149] clause 7.3.6 for the PS domain. 7.6.3.98 Supported RAT types indicator This parameter indicates which RAT types are supported/served by the MSC/VLR or SGSN or MME 7.6.3.99 UE SRVCC Capability This parameter indicates, if present, the support of SRVCC capability by the UE. 7.6.3.100 Temporary Empty CSG Subscription data Indicator This parameter indicates that the CSS has currently no CSG subscription data for this roaming user but registers the VLR or SGSN, so to inform them if later changes in CSG subscription data occur. 7.6.3.101 WLAN-offloadability This parameter refers to the WLAN offloadability for E-UTRAN or UTRAN. This parameter is defined in 3GPP TS 29.272 [144]. 7.6.3.102 IMSI-Group-Id This parameter refers to the IMSI-Group identifier. This parameter is defined in 3GPP TS 29.272 [144]. 7.6.4 Supplementary services parameters 7.6.4.1 SS-Code This parameter may refer to one supplementary service or a set of supplementary services as defined in 3GPP TS 22.004. For MAP this includes: - Calling Line Identification Presentation service (CLIP); - Calling Line Identification Restriction service (CLIR); - Connected Line Identification Presentation service (COLP); - Connected Line Identification Restriction service (COLR); - Calling Name Presentation (CNAP); - All Call Forwarding services, including Call Deflection; - Call Waiting (CW); - Call Hold (HOLD); - Multi-Party service (MPTY); - Closed User Group (CUG); - All Charging services; - All Call Restriction services; - Explicit Call Transfer service (ECT); - enhanced Multi-Level Precedence and Pre-emption service (eMLPP); - Completion of Calls to Busy Subscriber, originating side (CCBS-A); - Completion of Calls to Busy Subscriber, destination side (CCBS-B); - All LCS privacy exceptions (see clauseÊ7.6.4.44); - Mobile Originating Location Request (MO-LR) (see clause 7.6.4.45); - Multicall (MC). 7.6.4.1A SS-Code 2 This parameter is used to refer to one or a set of supplementary services (as 7.6.4.1 ""SS-Code"") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]). 7.6.4.2 SS-Status This parameter refers to the state information of individual supplementary services as defined in 3GPP TS 23.011. 7.6.4.3 SS-Data This parameter refers to the necessary set of information required in order to characterise one supplementary service: - SS-Code (see clause 7.6.4.1); - SS-Status (if applicable) (see clause 7.6.4.2); - Override subscription option (see clause 7.6.4.4); - CLI Restriction (see clause 7.6.4.5); - Basic Service Group Code (see clause 7.6.4.40). 7.6.4.4 Override Category This parameter refers to the subscription option Override Category attached to a supplementary service. It can take the following two values: - Enabled; - Disabled. 7.6.4.5 CLI Restriction Option This parameter refers to the subscription option Restriction mode attached to the CLIR supplementary service. It can take the following three values: - Permanent; - Temporary (Default Restricted); - Temporary (Default Allowed). 7.6.4.6 Forwarding Options This parameter refers to a forwarding option attached to a supplementary service. It can take one of the following values: - notification to forwarding party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - notification to calling party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - redirecting presentation (see 3GPP TS 22.082 [10] for the meaning of this parameter); - Forwarding reason (see 3GPP TS 22.082 [10] for the meaning of this parameter). 7.6.4.7 No reply condition timer This parameter refers to the no reply condition timer for call forwarding on no reply. 7.6.4.8 - 7.6.4.14 Void 7.6.4.15 Forwarding information This parameter represents the information related to each call forwarding service: - the SS-Code of the relevant call forwarding service (see clause 7.6.4.1); - if required, a list of forwarding feature parameters (see clause 7.6.4.16). the list may contain one item per Basic Service Group. 7.6.4.16 Forwarding feature This parameter applies to each combination of call forwarding service and Basic Service Group and contains the following information, as required: - Basic Service Group (see clause 7.6.4.40); - SS-Status (see clause 7.6.4.2); - forwarded-to number (see clause 7.6.2.22); - forwarded-to subaddress (see clause 7.6.2.23); - forwarding options (see clause 7.6.4.6); - no reply condition timer (see clause 7.6.4.7); - long forwarded-to number (see clause 7.6.2.22A). If a number is required to define the forwarded-to destination then: - If the VLR supports Long Forwarded-to Numbers then the long forwarded-to number shall be present and the forwarded-to number shall be absent. - If the VLR does not support Long Forwarded-to Numbers then the forwarded-to number shall be present and the long forwarded-to number shall be absent. 7.6.4.17 Void 7.6.4.18 Call barring information This parameter contains for each call barring service: - SS-Code (see clauseÊ7.6.4.1); - a list of call barring feature parameters (see clauseÊ7.6.4.19). The list may contain one item per Basic Service Group. 7.6.4.19 Call barring feature This parameter gives the status of call barring services as applicable to each Basic Service Group. The parameter contains the following information: - Basic Service Group (see clauseÊ7.6.4.40); - SS-Status (see clauseÊ7.6.4.2). 7.6.4.20 New password This parameter refers to the password which the subscriber just registered in the network. This parameter refers to a password used by the subscriber for supplementary service control. 7.6.4.21 Current password This parameter refers to a password used by the subscriber for supplementary service control. 7.6.4.22 Guidance information This parameter refers to guidance information given to a subscriber who is requested to provide a password. One of the following information may be given: - ""enter password""; this information is used for checking of the old password; - ""enter new password""; this information is used during password registration for the request of the first new password; - ""enter new password again""; this information is used during password registration for the request of the new password again for verification. 7.6.4.23 Void 7.6.4.24 SS-Info This parameter refers to all the information related to a supplementary service and is a choice between: - forwarding information (see clauseÊ7.6.4.15); - call barring information (see clauseÊ7.6.4.18); - CUG info (see clauseÊ7.6.4.8); - SS-Data (see clauseÊ7.6.4.3). - eMLPP information (see clause 7.6.4.41). 7.6.4.25 - 7.6.4.35 Void 7.6.4.36 USSD Data Coding Scheme This parameter contains the information of the alphabet and the language used for the unstructured information in an Unstructured Supplementary Service Data operation. The coding of this parameter is according to the Cell Broadcast Data Coding Scheme as specified in 3GPP TS 23.038 [25]. 7.6.4.37 USSD String This parameter contains a string of unstructured information in an Unstructured Supplementary Service Data operation. The string is sent either by the mobile user or the network. The contents of a string sent by the MS are interpreted by the network as specified in 3GPP TS 22.090 [16]. 7.6.4.38 Bearer service This parameter may refer to a single bearer service, a set of bearer services or to all bearer services as defined in 3GPP TS 22.002 [3]. This parameter is used only for supplementary service management. 7,6,4.38A Bearer Service 2 This parameter is used to indicate the bearer service or set of bearer services (as 7.6.4.38 ""Bearer service"") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]). 7.6.4.39 Teleservice This parameter may refer to a single teleservice, a set of teleservices or to all teleservices as defined in 3GPP TS 22.003 [4]. This parameter is used only for supplementary service management. 7.6.4.39A Teleservice 2 This parameter is used to indicate the teleservice or set of teleservices (as 7.6.4.39 ""Teleservice"") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]). 7.6.4.40 Basic Service Group This parameter refers to the Basic Service Group either as a bearer service (see clause 7.6.4.38) or a teleservice (see clause 7.6.4.39). This parameter is used only for supplementary service management. The null value (i.e. neither bearer service nor teleservice) is used to denote the group containing all bearer services and all teleservices. 7.6.4.41 eMLPP information This parameter contains two parameters which are associated with the eMLPP service. The following two parameters are included: - maximum entitled priority: - indicates the highest priority level the subscriber is allowed to apply for an outgoing call set-up; - default priority: - defines the priority level which shall be assigned to a call if no explicit priority is indicated during call set-up. 7.6.4.42 SS-event This parameter indicates the Supplementary Service for which an invocation notification is sent towards the gsmSCF. It can indicate one of the following services: - Explicit Call Transfer (ECT) - Call Deflection (CD) - Multi-Party call (MPTY) - Completion of Calls to Busy Subscriber (CCBS) 7.6.4.43 SS-event data This parameter contains additional information related to Supplementary Service invocation. Depending on the service invoked it can contain the following information: ECT A list with all Called Party Numbers involved. CD The called Party number involved. 7.6.4.44 LCS Privacy Exceptions Distinct SS codes are assigned to the following classes of LCS client in a target MS subscriber's privacy exception list. - Universal Class; - Call/session related value added class; - Call/session unrelated value added class; - PLMN operator class. - Service type class. 7.6.4.45 Mobile Originating Location Request (MO-LR) Distinct SS codes are assigned to the following classes of MO-LR: - Basic Self Location; - Autonomous Self Location; - Transfer to Third Party. 7.6.4.46 NbrUser This parameter indicates the maximum number of parallel bearers that may be used as defined by the user at registration of the MC SS. 7.6.4.47 MC Subscription Data This parameter contains two parameters which are associated with the MC service. The following two parameters are included: - NbrUser: indicates the maximum number of parallel bearers that may be used as defined by the user at registration of the MC SS - NbrSB: indicates the maximum number of parallel bearers that may be used as defined by the user's subscription. 7.6.4.48 MC Information This parameter contains three parameters which are associated with the MC service. The following parameters are included: - NbrSB; - NbrUser; - NbrSN. Definitions of these parameters are provided in 3GPP TS 23.135. 7.6.4.49 CCBS Request State This parameter indicates the current state of the CCBS request. It can take one of seven values: - request; - recall; - active; - completed; - suspended; - frozen; - deleted. 7.6.4.50 Basic Service Group 2 This parameter refers to the Basic Service Group either as a bearer service (see clause 7.6.4.38) or a teleservice (see clause 7.6.4.39). This parameter is used only for supplementary service management. 7.6.5 Call parameters 7.6.5.1 Call reference number This parameter refers to a call reference number allocated by a call control MSC. 7.6.5.2 Interrogation type This parameter refers to the type of interrogation for routing information which is sent from a GMSC to an HLR. It can take either of two values: - basic call (for information to route a call before the call has been extended to the VMSC of the called party); - forwarding (for information to route the call to the forwarded-to destination after the VMSC of the forwarding party has requested the GMSC to resume handling of the call. 7.6.5.3 OR interrogation This parameter indicates that the GMSC which interrogated the HLR for routeing information is not in the same PLMN as the HLR, and therefore that the call will potentially be optimally routed. 7.6.5.4 OR capability This parameter indicates the phase of OR which the GMSC supports. 7.6.5.5 Forwarding reason This parameter indicates the reason for which the call is to be forwarded. It can take one of three values: - busy subscriber; - mobile subscriber not reachable; - no subscriber reply. 7.6.5.6 Forwarding interrogation required This parameter indicates that if the VMSC of the forwarding subscriber requests the GMSC to resume handling of the call the GMSC shall interrogate the HLR for forwarding information. 7.6.5.7 O-CSI This parameter identifies the subscriber as having originating CAMEL services as defined in 3GPP TS 23.078. 7.6.5.7A D-CSI This parameter identifies the subscriber as having originating CAMEL dialled services as defined in 3GPP TS 23.078. 7.6.5.7B T-CSI This parameter identifies the subscriber as having terminating CAMEL services in the GMSC, as defined in 3GPP TSÊ23.078. 7.6.5.7C VT-CSI This parameter identifies the subscriber as having terminating CAMEL services in the VMSC, as defined in 3GPPÊTSÊ23.078. 7.6.5.7D O-IM-CSI This parameter identifies the subscriber as having originating IP Multimedia Core Network CAMEL services as defined in 3GPP TS 23.278. 7.6.5.7E D-IM-CSI This parameter identifies the subscriber as having originating IP Multimedia Core Network CAMEL dialled services as defined in 3GPP TS 23.278. 7.6.5.7F VT-IM-CSI This parameter identifies the subscriber as having terminating IP Multimedia Core Network CAMEL services as defined in 3GPPÊTSÊ23.278. 7.6.5.8 Void 7.6.5.9 Void 7.6.5.10 Void 7.6.5.11 CCBS Feature This parameter corresponds to the 'CCBS Description' parameter in 3GPP TS 23.093. It refers to the necessary set of information required in order to characterise a certain CCBS request. The parameter may contain the following information: - CCBS Index (see 3GPP TS 23.093 for the use of this parameter); - B-subscriber number (see clause 7.6.2.48); - B-subscriber subaddress (see clause 7.6.2.49); - Basic Service Group Code (see clause 7.6.4.40). 7.6.5.12 UU Data This parameter includes User-To-User Data. It is defined in 3GPP TS 23.087. 7.6.5.13 UUS CF Interaction This parameter indicates if the call forwarding or call deflection has been activated after UUS1 request has been accepted . It is defined in 3GPP TS 23.087. 7.6.5.14 Number Portability Status This parameter indicates the number portability status of subscriber. See 3GPP TS 23.066 [108]. 7.6.5.15 Pre-paging supported This parameter indicates that the entity which sent it supports pre-paging. 7.6.5.16 MT Roaming Retry Supported The parameter indicates that the entity which sent it supports MT Roaming Retry. When sent by the HLR, it further indicates that the GMSC also supports MT Roaming Retry. 7.6.5.17 MT Roaming Retry The parameter indicates that the GMSC receiving the IE shall start MT roaming retry (see 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]). 7.6.5.18 Paging Area The parameter indicates the paging area where the MS is currently located (see 3GPP TS 23.012 [23] and 3GPP TS 23.018 [97]). 7.6.5.19 Call Priority The parameter indicates the eMLPP priority of the call (see 3GPP TS 23.067 [136]). 7.6.5.20 MTRF Supported The parameter indicates that the entity which sends it supports MT Roaming Forwarding. 7.6.5.21 LCLS Global Call Reference (LCLS GCR) This parameter refers to a globally unique call identifier for the duration of the call (see 3GPP TS 29.205 [146]). This parameter is used to identify a call and to correlate the call legs of a call to determine if the call is a local call within the BSS. 7.6.5.22 LCLS-Negotiation This parameter is used to request MSC-B to indicate LCLS, see 3GPP TS 29.205 [146] clause B.2.1.4 LCLS Negotiation Request. 7.6.5.23 LCLS-Configuration-Preference This parameter contains information to indicate the negotiated LCLS configuration preference, see 3GPP TS 29.205 [146] clause B.2.1.10 LCLS Configuration Preference. 7.6.6 Radio parameters 7.6.6.1 - 7.6.6.3 Void 7.6.6.4 GERAN Classmark This information element is sent from one MSC to the other MSC in the signalling for inter MSC handover. It is used to convey information related to cell capabilities, as defined in 3GPP TS 48.008. 7.6.6.5 BSSMAP Service Handover This parameter refers to the Service Handover information element defined in 3GPP TS 48.008 7.6.6.5A BSSMAP Service Handover List This parameter refers to the list of Service Handover information elements defined in 3GPP TS 48.008. This parameter shall be used when there are multiple bearers and at least one of the bearers has an associated BSSMAP Service Handover parameter. 7.6.6.6 RANAP Service Handover This parameter refers to the Service Handover information element defined in 3GPP TS 25.413. 7.6.6.7 HO-Number Not Required This parameter indicates that no handover or relocation number allocation is necessary. 7.6.6.8 Integrity Protection Information This parameter refers to the Integrity Protection Information element defined in 3GPP TS 25.413. 7.6.6.9 Encryption Information This parameter refers to the Encryption Information element defined in 3GPP TS 25.413. 7.6.6.10 Radio Resource Information This parameter refers to the Channel Type information element defined in 3GPP TS 48.008 [49]. 7.6.6.10A Radio Resource List This parameter refers to list of RAB-id's and their associated Channel Type information elements defined in 3GPP TS 48.008. This parameter shall be used when there are multiple bearers and at least one of the bearers has an associated Radio Resource Information parameter. 7.6.6.10B Chosen Radio Resource Information This parameter refers to the Chosen Channel and Speech Version information elements defined in 3GPP TS 48.008. 7.6.6.11 Key Status This parameter refers to the Key Status element defined in 3GPP TS 25.413. 7.6.6.12 Selected UMTS Algorithms This parameters identifies the UMTS integrity and optionally encryption algorithms selected by MSC-B. Coding of this parameter is defined in 3GPP TS 25.413. 7.6.6.13 Allowed GSM Algorithms This parameters identifies the allowed GSM algorithms in MSC-B. Coding of this parameter is defined in 3GPP TS 48.008. 7.6.6.14 Allowed UMTS Algorithms This parameters identifies the allowed UMTS algorithms in MSC-B. Coding of this parameter is defined in 3GPP TS 25.413. 7.6.6.15 Selected GSM Algorithm This parameter identifies the GSM algorithm selected by GSM BSC controlled by MSC-B. Coding of this parameter is defined in 3GPP TS 48.008. 7.6.6.16 Iu-Currently Used Codec This parameter indicates the codec used at the Iu interface before handover. 7.6.6.17 Iu-Supported Codecs List This parameter indicates the codecs supported by the UE and by MSC-A and the associated modes in priority order (the first entry being the highest priority codec). MSC-B uses this information to select the associated transcoder resources. 7.6.6.17A Iu-Available Codecs List This parameter indicates the codecs available at the Iu interface in MSC-B and the associated modes."
"MSC-A uses this information to decide whether a change to a different codec at the Iu interface is possible. 7.6.6.18 Iu-Selected Codec When sent by MSC-B, this parameter indicates the codec selected by MSC-B for the Iu interface. When sent by MSC-A, this parameter indicates the codec to be used by MSC-B at the Iu interface. 7.6.6.19 RAB Configuration Indicator This parameter indicates by its presence that MSC-A (or MSC-B in case of subsequent handover) has generated the RAB parameters according to the preferred codec (first entry in the Iu-Supported Codecs List). 7.6.6.20 UESBI-Iu This parameter refers to the UESBI-Iu (UE Specific Behaviour Information over the Iu interface) information element defined in 3GPP TS 25.413. 7.6.6.21 Alternative Channel Type This parameter refers to the Channel Type information element defined in 3GPP TS 48.008 [49] for the alternative radio access bearer. This parameter is used for SCUDIF calls (see 3GPP TS 23.172 [126]). 7.6.6.22 AoIP-Supported Codecs List Anchor This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Supported Codecs List (Anchor) in 3GPP TS 23.009 [21]. 7.6.6.23 AoIP-Available Codecs List Map This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Available Codecs List (Map) in 3GPP TS 23.009 [21]. 7.6.6.24 AoIP-Selected Codec Target This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Selected Codec (Target) in 3GPP TS 23.009 [21]. 7.6.7 Authentication parameters 7.6.7.1 Authentication set list This parameter represents a list of sets of authentication parameters for a given subscriber. The list either contains Authentication Triplets (Rand, Sres, Kc) or Authentication Quintuplets (Rand, Xres, Ck, Ik, Autn). If the list contains Authentication Quintuplets, the order of sequence in this list is chronological, the first quintuplet in the list is the oldest one. 7.6.7.2 Rand This parameter represents a random number used for authentication. 7.6.7.3 Sres This parameter represents the response to an authentication request. 7.6.7.4 Kc This parameter refers to a key used for ciphering purposes. 7.6.7.5 Xres This parameter represents the response to an UMTS authentication request. 7.6.7.5A Ck This parameter refers to a key used for UMTS ciphering purposes. 7.6.7.5B Ik This parameter refers to the Integrity Key. 7.6.7.5C Autn This parameter refers to the Authentication Token. 7.6.7.5D KASME This parameter refers to the Key for the Access Security Management Entity. 7.6.7.6 Cksn This parameter refers to a ciphering key sequence number. 7.6.7.6A Ksi This parameter refers to a key set identifier. 7.6.7.6B Auts This parameter refers to the resynchronisation token. 7.6.7.7 Ciphering mode This parameter refers to the ciphering mode which is associated with a radio channel. It may take values as follows: - no encryption; - identification of specific ciphering algorithm. 7.6.7.8 Current Security Context This parameter represents a list of security context parameters for a given subscriber. The list either contains GSM Security Context data (Kc, Cksn) or UMTS Security Context Data (Ck, Ik, Ksi). 7.6.7.9 Failure cause This parameter refers to an authentication failure which has occurred. It may take values as follows: - wrong user response; - wrong network signature. 7.6.7.10 Re-attempt It indicates whether the failure ocurred in a normal authentication attempt or in an authentication reattempt (there was a previous unsuccessful authentication). 7.6.7.11 Access Type It indicates whether the authentication procedure was initiated due to a call, an emergency call, a location updating, a supplementary service procedure, a short message transfer, a GPRS attach procedure, a routing area updating, a service request, a MS initiated Detach in GPRS, a PDP context activation or a PDP context deactivation procedure. 7.6.8 Short message parameters 7.6.8.1 SM-RP-DA This parameter represents the destination address used by the short message service relay sub-layer protocol. It can be either of the following: - IMSI (see clauseÊ7.6.2.1); - LMSI (see clauseÊ7.6.2.16); - MS-ISDN (see clauseÊ7.6.2.17); - roaming number (see clauseÊ7.6.2.19); - service centre address (see clauseÊ7.6.2.27). 7.6.8.2 SM-RP-OA This parameter refers to the originating address used by the short message service relay sub-layer protocol. It can be either of the following: - MS-ISDN (see clauseÊ7.6.2.17); - service centre address (see clauseÊ7.6.2.27). 7.6.8.3 MWD status This parameter indicates whether or not the address of the originator service centre is already contained in the Message Waiting Data file. In addition, it contains the status of the Memory Capacity Exceeded Flag (MCEF), the status of the Mobile subscriber Not Reachable Flag (MNRF), the status of the Mobile station Not Reachable for GPRS flag (MNRG), the status of the Mobile station Not Reachable for 5G-3GPP access flag (MNR5G) and the status of the Mobile station Not Reachable for 5G-Non-3GPP access flag (MNR5GN3G). 7.6.8.4 SM-RP-UI This parameter represents the user data field carried by the short message service relay sub-layer protocol. 7.6.8.5 SM-RP-PRI This parameter is used to indicate whether or not delivery of the short message shall be attempted when a service centre address is already contained in the Message Waiting Data file. 7.6.8.6 SM Delivery Outcome This parameter indicates the cause for setting the message waiting data. It can take one of the following values: - Absent subscriber; - MS memory capacity exceeded; - Successful transfer. 7.6.8.7 More Messages To Send This parameter is used to indicate whether or not the service centre has more short messages to send. 7.6.8.8 Alert Reason This parameter is used to indicate the reason why the service centre is alerted. It can take one of the following values: - MS present; - Memory Available. 7.6.8.9 Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent. For the values for this parameter see 3GPP TS 23.040. 7.6.8.10 Alert Reason Indicator This parameter indicates that the alert reason is sent to the HLR due to GPRS activity. 7.6.8.10A Additional Alert Reason Indicator This parameter indicates that the alert reason is sent to the HLR due to IMS activity. 7.6.8.11 Additional SM Delivery Outcome This parameter is used to indicate the GPRS delivery outcome in case a combination between delivery outcome for GPRS and non-GPRS are sent to the HLR. 7.6.8.12 Additional Absent Subscriber Diagnostic SM This parameter indicates the reason of the additional SM Delivery Outcome. 7.6.8.13 Delivery Outcome Indicator This parameter indicates that the delivery outcome sent to the HLR is for GPRS. 7.6.8.14 GPRS Node Indicator This parameter indicates by its presence that the Network Node Number sent by the HLR, SMS-Router or IP-SM-GW is to be considered as the SGSN number (although it may actually be an SMS-Router Number or IP-SM-GW Number). 7.6.8.14A IMS Node Indicator This parameter indicates by its presence that the Network Node Number sent by the HLR is an IP-SM-GW number. 7.6.8.15 GPRS Support Indicator This parameter indicates that the SMS-GMSC supports GPRS specific procedure of combine delivery of Short Message via MSC and/or via the SGSN. 7.6.8.16 SM-RP-MTI This parameter represents the RP-Message Type Indicator of the Short Message. It is used to distinguish a SM sent to the mobile station in order to acknowledge an MO-SM initiated by the mobile from a normal MT-SM. This parameter is formatted according to the formatting rules of address fields as described in 3GPP TS 23.040. 7.6.8.17 SM-RP-SMEA This parameter represents the RP-Originating SME-address of the Short Message Entity that has originated the SM. This parameter is used by the short message service relay sub-layer protocol and is formatted according to the formatting rules of address fields as described in 3GPP TS 23.040. 7.6.8.18 IP-SM-GW SM Delivery Outcome This parameter is used to indicate the delivery outcome for the IMS domain. 7.6.8.19 IP-SM-GW Absent Subscriber Diagnostic SM This parameter indicates the reason of the IP-SM-GW SM Delivery Outcome. 7.6.8.20 IP-SM-GW Indicator This parameter indicates by its presence that sm-deliveryOutcome is for delivery via IMS. 7.6.8.21 SM Delivery Timer This parameter indicates the SM Delivery Timer value set in the SMS-GMSC to the IP-SM-GW, SGSN or MSC/VLR. It may be taken into account by the domain selection procedure in the IP-SM-GW. Units are in seconds. 7.6.8.22 SM Delivery Start Time This parameter indicates the timestamp (in UTC) at which the SM Delivery Supervision Timer was started in the SMS-GMSC. 7.6.8.23 Maximum Retransmission Time This parameter indicates the maximum retransmission time (in UTC) until which the SMS-GMSC is capable to retransmit the MT Short Message. 7.6.8.24 Requested Retransmission Time This parameter indicates the retransmission time (in UTC) at which the SMS-GMSC is requested to retransmit the MT Short Message. 7.6.8.25 Maximum UE Availability Time This parameter indicates the timestamp (in UTC) until which a UE using a power saving mechanism (such as extended idle mode DRX) is expected to be reachable for SM Delivery. This information may be used by the SMS Center to prioritize the retransmission of Short Message to UEs using a power saving mechanism. 7.6.8.26 SMS-GMSC Alert Event This parameter indicates the event that causes the MME (via an IWF) or the SGSN to alert the SMS-GMSC for retransmitting an MT Short Message. 7.6.8.27 SMS-GMSC Address This parameter contains the E.164 number of the SMS-GMSC or SMS Router, in international number format as described in ITU-T Recommendation E.164 [67]. 7.6.8.28 SMS-GMSC Diameter Address This parameter contains the Diameter Identity of the SMS-GMSC or SMS Router. 7.6.8.29 New SGSN Number This parameter contains the E.164 number of the new SGSN serving the MS. 7.6.8.30 New MME Number This parameter contains the E.164 number of the new MME serving the MS. 7.6.8.31 New SGSN Diameter Address This parameter contains the Diameter Identity of the new SGSN serving the MS. 7.6.8.32 New MME Diameter Address This parameter contains the Diameter Identity of the new MME serving the MS. 7.6.8.33 New MSC Number This parameter contains the E.164 number of the new MSC serving the MS. 7.6.8.34 SMSF 3GPP Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent for 5G 3GPP access. For the values for this parameter see 3GPP TS 23.040. 7.6.8.35 SMSF Non 3GPP Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent for 5G Non 3GPP access. For the values for this parameter see 3GPP TS 23.040. 7.6.8.36 SMSF 3GPP Delivery Outcome Indicator This parameter indicates that the delivery outcome IE is associated to the SM delivery via the SMSF for 3GPP access. 7.6.8.37 SMSF Non-3GPP Delivery Outcome Indicator This parameter indicates that the delivery outcome IE is associated to the SM delivery via the SMSF for Non-3GPP access. 7.6.8.38 SMSF 3GPP SM Delivery Outcome This parameter is used to indicate the delivery outcome at the SMSF for 3GPP access. 7.6.8.39 SMSF Non-3GPP SM Delivery Outcome This parameter is used to indicate the delivery outcome at the SMSF for non-3GPP access. 7.6.8.40 SMSF 3GPP Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent for 5G 3GPP access. For the values for this parameter see 3GPP TS 23.040. 7.6.8.41 SMSF Non 3GPP Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent for 5G Non 3GPP access. For the values for this parameter see 3GPP TS 23.040. 7.6.9 Access and signalling system related parameters 7.6.9.1 AN-apdu This parameter includes one or two concatenated complete 3GPP TS 25.413 or 3GPP TS 48.006 [48] messages, as described in 3GPP TSÊ23.009 and 3GPP TSÊ29.010. The access network protocol ID indicates that the message or messages are according to either 3GPP TS 48.006 [48] or 3GPP TSÊ25.413. For the coding of the messages see 3GPP TSÊ25.413, 3GPP TS 48.006 [48] and 3GPP TS 48.008 [49]. 7.6.9.2 CM service type This parameter identifies the service category being requested by the subscriber: - mobile originating call; - emergency call establishment; - short message service; - mobile originating call re-establishment; - mobile terminating call; - SS request; - Voice group call set-up; - Voice broadcast set-up. 7.6.9.3 Access connection status This parameter represents the following access connection status information: - RR-connection status (established/not established); - ciphering mode (on/off); - authentication status (authenticated/not authenticated). 7.6.9.4 External Signal Information This parameter contains concatenated information elements (including tag and length) which are defined by a common protocol version, preceded by the associated protocol ID. It is used to transport information of the indicated protocol via MAP interfaces. 7.6.9.5 Access signalling information This parameter refers to any set of information elements imported from 3GPP TS 24.008 [35]. 7.6.9.6 Location update type This parameter refers to the location update type (normal, periodic or IMSI attach) contained in the 3GPP TS 24.008 [35] LOCATION REGISTRATION REQUEST message. 7.6.9.7 Protocol ID This parameter refers to the protocol to which the coding of the content of the associated External Signal Information conforms. The following values are defined: - 04.08; - 08.06; - ETSÊ300Ê102-1. This value indicates the protocol defined by ETSÊ300Ê102-1 (EDSS1). 7.6.9.8 Network signal information This parameter is transported as external signal information. The protocol ID shall be set to ""ETSÊ300Ê102-1"". The network signal information may include the following information elements as defined in 3GPP TS 29.007 [56]: - ISDN BC; the tag and length are defined by ETSÊ300Ê102-1. For the content, see 3GPP TS 29.007 [56]. - HLC; the tag and length are defined by ETSÊ300Ê102-1. For the content, see 3GPP TS 29.007 [56]. - LLC; the tag and length are defined by ETSÊ300Ê102-1. For the content, see 3GPP TS 29.007 [56]. They are contained in the Signal Information parameter according to figureÊ7.6/1 (irrespective of the order): FigureÊ7.6/1: Network signal information parameter 7.6.9.8A Network signal information 2 This parameter is transported as additional external signal information for SCUDIF calls, described in 3GPP TS 23.172 [126]. The protocol ID and possibly included information elements are identical to Network Signal Information, defined in 7.6.9.8, ""Network signal information"". 7.6.9.9 Call Info This parameter is transported as external signal information. The protocol ID shall be set to ""3GPP TS 24.008 [35]"". The Call Info includes the set of information elements from the original SETUP message and is imported from 3GPP TS 24.008 [35]. 7.6.9.10 Additional signal info This parameter is transported as external signal information. The protocol ID shall be set to ""ETSÊ300Ê356"". The additional signal information may include the following information elements: - Calling Party Number as defined by ETSÊ300Ê356. - Generic Number as defined by ETSÊ300Ê356. They are contained in the Signal Information parameter according to figureÊ7.6/2 (irrespective of the order): FigureÊ7.6/2: Additional signal information parameter 7.6.10 System operations parameters 7.6.10.1 Network resources This parameter refers to a class or type of network resource: - PLMN; - HLR; - VLR (current or previous); - MSC (controlling or current); - EIR; - radio sub-system. 7.6.10.2 Trace reference This parameter represents a reference associated with a GSM only tracing request as defined in 3GPP TS 52.008 [61]. The parameter is managed by OMC/EM. 7.6.10.2A Trace reference 2 This parameter represents a reference associated with a tracing request as defined in 3GPP TS 32.421 [131] and 3GPP TS 32.422 [132]. The parameter is managed by EM. 7.6.10.3 Trace type This parameter identifies the type of trace for GSM only tracing request. Trace types are fully defined in 3GPP TSÊ52.008 [61]. If the activation of the tracing is requested only for UMTS, then this parameter shall contain value ""No MSC Trace"" for MSC Record Type and value ""No BSS Trace"" for BSS Record Type. 7.6.10.4 Additional network resources This parameter refers to a class or type of network resource: - SGSN; - GGSN; - GMLC; - gsmSCF; - NPLR; - AuC. 7.6.10.5 Trace depth list This parameter identifies the list of depths of trace per network element. See 3GPP TS 32.422 [132]. 7.6.10.6 Trace NE type list This parameter identifies the list of network elements to be traced. See 3GPP TS 32.422 [132]. 7.6.10.7 Trace interface list This parameter identifies the list of interfaces or protocols per network element to be traced. See 3GPP TS 32.422 [132]. 7.6.10.8 Trace event list This parameter identifies the list of events per network element, which trigger a Trace Recording Session. See 3GPP TS 32.422 [132]. 7.6.10.9 Trace support indicator This parameter indicates that UMTS trace parameters are supported in the VLR or in the SGSN. 7.6.10.10 Trace Propagation List This parameter indicates UMTS trace propagation parameters sent from one MSC to the other MSC in the signalling for inter MSC handover/relocation. See 3GPP TS 32.422 [132]. 7.6.10.11 MDT-Configuration This parameter contains Minimization of Drive Test Configuration Data as defined in 3GPP TS 32.422 [132]. 7.6.10.12 MDT User Consent This parameter contains an indicator whether user consent for MDT activation is available or not as defined in 3GPP TS 32.422 [132]. 7.6.11 Location Service Parameters 7.6.11.1 Age of Location Estimate This parameter indicates how long ago the location estimate was obtained. 7.6.11.2 Deferred MT-LR Response Indicator This parameter shows that this is a response to a deferred mt-lr request. 7.6.11.3 Deferred MT-LR Data This parameter is used to report the deferred location event type, the location information and reason why the serving node aborted monitoring the event to the GMLC. The termination cause mt-lrRestart shall be used to trigger the GMLC to restart the location procedure in all the cases where the sending node detects that the location procedure cannot be successfully performed anymore by the sending node and that it could be successfully performed by another node (as for example when. Cancel Location or Send Identification has been received). The location information shall be included only if the termination cause is mt-lrRestart. The network node number contained in the location information refers to the node where the MS/UE has moved to and shall be included if available, like in case Send Identification has been received. 7.6.11.4 LCS Client ID This parameter provides information related to the identity of an LCS client. 7.6.11.5 LCS Event This parameter identifies an event associated with the triggering of a location estimate. 7.6.11.6 Void 7.6.11.7 LCS Priority This parameter gives the priority of the location request. 7.6.11.8 LCS QoS This parameter defines the Quality of Service (QoS) for any location request. It is composed of the following elements. 1) Response Time Indicates the category of response time Ð ""low delay"" or ""delay tolerant"". 2) Horizontal Accuracy Indicates the required horizontal accuracy of the location estimate. 3) Vertical Coordinate Indicates if a vertical coordinate is required (in addition to horizontal coordinates). 4) Vertical Accuracy Indicates the required vertical accuracy of the location estimate (inclusion is optional). 5) Velocity Request Indicates that velocity should be returned if available (inclusion is optional). 7.6.11.9 CS LCS Not Supported by UE This parameter is used by the VLR to indicate to the HLR that the UE does not support neither UE Based nor UE Assisted positioning metheds for Circuit Switched Location Services. VLR defines the presence of this parameter on the basis of the Classmark 3 information. 7.6.11.10 PS LCS Not Supported by UE This parameter is used by the SGSN to indicate to the HLR that the UE does not support neither UE Based nor UE Assisted positioning metheds for Packet Switched Location Services. SGSN defines the presence of this parameter on the basis of the UE capability information and the access technology supported by the SGSN. 7.6.11.11 Location Estimate This parameter gives an estimate of the location of an MS in universal coordinates and the accuracy of the estimate. The estimate is expressed in terms of the geographical shapes defined by 3GPP TS 23.032. and is composed of the type of shape plus the encoding of the shape itself. Any type of shape defined in 3GPP TS 23.032 can be filled in in the Location Estimate parameter, but only the encoding of the following shapes shall be carried by Location Estimate: - Ellipsoid point with uncertainty circle - Ellipsoid point with uncertainty ellipse - Ellipsoid point with altitude and uncertainty ellipsoid - Ellipsoid arc - Ellipsoid point The encoding for the remaining types of shape, defined in the 3GPP TS 23.032, shall be filled in in the Additional Location Estimate parameter. 7.6.11.11A GERAN Positioning Data This parameter provides positioning data associated with a successful or unsuccessful location attempt for a target MS described in 3GPP TS 49.031 [59a]. 7.6.11.11B UTRAN Positioning Data This parameter provides positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120]. It contains the positioningDataDiscriminator and positioningDataSet parts of the RANAP PositionData element only. 7.6.11.11C GERAN GANSS Positioning Data This parameter provides GANSS positioning data associated with a successful or unsuccessful location attempt for a target MS as described in 3GPP TS 49.031 [59a] if GANSS has been used. 7.6.11.11D UTRAN GANSS Positioning Data This parameter provides GANSS positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120] if GANSS has been used. It contains the GANSS-PositioningDataSet part of the RANAP PositionData element only. 7.6.11.11E UTRAN Additional Positioning Data This parameter provides additional positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120] if Additional Positioning has been used. It contains the Additional-PositioningDataSet part of the RANAP PositionData element only. 7.6.11.11F UTRAN Barometric Pressure Measurement This parameter provides barometric pressure measurement associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120]. 7.6.11.11G UTRAN Civic Address This parameter provides civic address associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120]. 7.6.11.12 Location Type This parameter indicates the type of location estimate required by the LCS client. Possible location estimate types include: - current location; - current or last known location; - initial location for an emergency services call; - deferred location event type; - notification verification only. 7.6.11.13 NA-ESRD This parameter only applies to location for an emergency services call in North America and gives the North American Emergency Services Routing Digits. 7.6.11.14 NA-ESRK This parameter only applies to location for an emergency services call in North America and gives the North American Emergency Services Routing Key. 7.6.11.15 LCS Service Type Id This parameter defines the LCS Service Type of the current positioning request. The possible values are defined in 3GPP TS 22.071 [123] 7.6.11.16 Privacy Override This parameter indicates if MS privacy is overridden by the LCS client when the GMLC and VMSC/SGSN for an MT-LR are in the same country. 7.6.11.17 Supported LCS Capability Sets This parameter indicates which capability sets of LCS are supported in the VLR or SGSN. 7.6.11.18 LCS Codeword This parameter contains the codeword associated to current positioning request as described in 3GPP TS 23.271 [26a]. 7.6.11.19 NA-ESRK Request This parameter allows the MSC to indicate that it requires the GMLC to allocate a NA-ESRK based on the target MS location estimate. This parameter only applies to emergency services calls in North America. 7.6.11.20 Supported GAD Shapes This parameter indicates which of the shapes defined in 3GPP TS 23.032 are supported. If the parameter is not provided then the receiving node shall assume that the sending entity supports the following shapes: - Ellipsoid point with uncertainty circle - Ellipsoid point with uncertainty ellipse - Ellipsoid point with altitude and uncertainty ellipsoid - Ellipsoid arc - Ellipsoid point 7.6.11.21 Additional Location Estimate This parameter gives an estimate of the location of an MS/UE in universal coordinates and the accuracy of the estimate. This parameter allows the location estimate to be expressed in any of the geographical shapes defined in 3GPP TS 23.032 7.6.11.22 Cell Id Or SAI For GERAN access, this parameter contains the Global Cell Identifier for the cell that the subscriber is currently attached to. For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to. 7.6.11.23 LCS-Reference Number This parameter represents a reference between a request and a responce of a deferred mt-lr procedure as deccribed in 3GPP TS 23.271 [26a]. 7.6.11.24 LCS Privacy Check This parameter refers to the requested privacy check related actions (call/session unrelated and/or call/session related) from MSC or SGSN provided by H-GMLC. Possible requested actions are: - positioning allowed without notifying the UE user; - positioning allowed with notification to the UE user; - positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user or if there is no response to the notification; - positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user; - positioning not allowed. 7.6.11.25 Additional LCS Capability Sets This parameter indicates which capability sets of LCS are supported in the VLR or SGSN. 7.6.11.26 Area Event Info This parameter defines the requested deferred MT-LR area event information. The parameter consists of area definition, type of area event, occurrence info and minimum interval time. 7.6.11.27 Velocity Estimate This parameter gives an estimate of the velocity of an MS and the accuracy of the estimate. The estimate is expressed in terms of speed and bearing as defined by 3GPP TS 23.032 [122], and is composed of the velocity terms plus the encoding of the velocity itself. Only the encoding of the following velocity definitions shall be carried by the Velocity Estimate: - Horizontal Velocity - Horizontal with Vertical Velocity - Horizontal Velocity with Uncertainty - Horizontal with Vertical Velocity and Uncertainty 7.6.11.28 Accuracy Fulfilment Indicator This parameter indicates the fulfilled accuracy of the positioning procedure. For details see 3GPP TS 23.271 [26a]. 7.6.11.29 MO-LR Short Circuit Indicator This parameter indicates whether MO-LR short circuit feature is permitted. For details see 3GPP TS 23.271 [26a]. 7.6.11.30 Reporting PLMN List This parameter provides a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made. For details see 3GPP TS 23.271 [26a]. 7.6.11.31 Periodic LDR information This parameter refers to the periodic reporting interval and reporting amount of the deferred periodic location. For details see 3GPP TS 23.271 [26a]. 7.6.11.32 Sequence Number This parameter refers to the number of the periodic location reports completed. The sequence number would be set to 1 in the first location report and increment by 1 for each new report. When the number reaches the reporting amountÊvalue, the H-GMLC (for a periodic MT-LR or a periodic MO-LR transfer to third party) will know the procedure is complete. For details see 3GPP TS 23.271 [26a]. 7.6.12 Void 7.7 Representation of a list of a basic parameter in service-primitives In some service-primitives several instances of a basic parameter of clauseÊ7.6 are required. In the service descriptions such cases will be represented as ParameterNameLIST in the tables where ParameterName refers to one of the parameters defined in clauseÊ7.6. This corresponds to the following construction rule: FigureÊ7.7/1: Construction of Lists 8 Mobility services 8.1 Location management services 8.1.1 Void 8.1.1.1 Void 8.1.1.2 Void 8.1.1.3 Void 8.1.2 MAP_UPDATE_LOCATION service 8.1.2.1 Definition This service is used by the VLR to update the location information stored in the HLR. This service is also used by an IWF that registers an MME as MSC for MT-SMS. The MAP_UPDATE_LOCATION service is a confirmed service using the service primitives given in tableÊ8.1/2. 8.1.2.2 Service primitives TableÊ8.1/2: MAP_UPDATE_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) MSC Address M M(=) VLR number M M(=) LMSI U C(=) Supported CAMEL Phases C C(=) SoLSA Support Indicator C C(=) IST Support Indicator C C(=) Super-Charger Supported in Serving Network Entity C C(=) Long FTN Supported C C(=) Supported LCS Capability Sets C C(=) Offered CAMEL 4 CSIs C C(=) Inform Previous Network Entity C C(=) CS LCS Not Supported by UE C C(=) V-GMLC Address U C(=) IMEISV C C(=) Skip Subscriber Data Update U C(=) Supported RAT Types Indicator U C(=) Paging Area U C(=) Restoration Indicator U C(=) MTRF Supported U C(=) Equivalent PLMN List C C(=) MSISDN-less Operation Supported C C(=) MME-Diameter-Address-For MT-SMS C C(=) Reset-IDs Supported C C(=) ADD Capability U C(=) Paging Area Capability U C(=) HLR number C C(=) User error C C(=) Provider error O 8.1.2.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. MSC Address See definition for MSC number in clauseÊ7.6.2. The MSC address is used for short message delivery only and for each incoming call set-up attempt the MSRN will be requested from the VLR. VLR number See definition in clauseÊ7.6.2. LMSI See definition in clauseÊ7.6.2. It is an operator option to provide the LMSI from the VLR; it is mandatory for the HLR to support the LMSI handling procedures. Supported CAMEL Phases This parameter indicates which phases of CAMEL are supported. Must be present if a CAMEL phase different from phase 1 is supported. Otherwise may be absent. HLR number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory in case of successful HLR updating. SoLSA Support Indicator This parameter is used by the VLR to indicate to the HLR in the Update Location indication that SoLSA is supported. If this parameter is not included in the Update Location indication and the Subscriber is marked as only allowed to roam in Subscribed LSAs, then the HLR shall reject the roaming and indicate to the VLR that roaming is not allowed to that Subscriber in the VLR. This SoLSA Support Indicator shall be stored by the HLR per VLR where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a VLR and no SoLSA Support indicator is stored for that VLR, the location status of that Subscriber shall be set to Restricted. IST Support Indicator This parameter is used to indicate to the HLR that the VMSC supports basic IST functionality, that is, the VMSC is able to terminate the Subscriber Call Activity that originated the IST Alert when it receives the IST alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Update Location indication and the Subscriber is marked as an IST Subscriber, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Roaming, Incoming or Outgoing calls), or allow service assuming the associated risk of not having the basic IST mechanism available. This parameter can also indicate that the VMSC supports the IST Command service, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Update Location indication and the HLR supports the IST Command capability, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Roaming, Incoming or Outgoing calls), or allow service assuming the associated risk of not having the IST Command mechanism available. Long FTN Supported This parameter indicates that the VLR supports Long Forwarded-to Numbers. Super-Charger Supported in Serving Network Entity This parameter is used by the VLR to indicate to the HLR that the VLR supports the Super-Charger functionality and whether subscription data has been retained by the VLR. If subscription data has been retained by the VLR the age indicator shall be included. Otherwise the VLR shall indicate that subscriber data is required. If this parameter is absent then the VLR does not support the Super-Charger functionality. Supported LCS Capability Sets This parameter indicates, if present, the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the VLR does not support LCS at all. If this parameter is absent then the VLR may support at most LCS capability set 1, that is LCS Release98 or Release99 version. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR (see clause 7.6.3.36D). Inform Previous Network Entity This parameter is used by the VLR to ask the HLR to inform the previous network entity about the update by sending the previous network entity a Cancel Location message. It is used if Super-Charger is supported in the network and either the serving network entity has not been able to inform the previous network entity that MS has moved (i.e. if it has not sent Send Identification to the previous serving entity) or the MTRF Supported flag is set in the MAP_UPDATE LOCATION request. CS LCS Not Supported by UE See definition in clauseÊ7.6.11. V-GMLC address See definition in clauseÊ7.6.2. IMEISV For definition of the parameter see clause 7.6.2. For the use of this parameter see 3GPP TS 23.012. IMEISV shall be present if ADD function is supported and a new IMEISV is to be notified to the HLR (The functional requirements for the presence of IMEISV due to ADD are described in 3GPP TS 22.101 clause 7.4). Skip Subscriber Data Update The presence of the parameter is optional and if present it indicates that the service is solely used to inform the HLR about change of IMEISV or Paging Area. The parameter is used to optimise signalling load during Location Update procedure. Supported RAT Types Indicator This parameter indicates, if present, which access technologies (e.g. GERAN and / or UTRAN) are served by the MSC/VLR (see clause 7.6.3) Paging Area This parameter indicates, if present, the paging area where the MS is currently located (see clause 7.6.5.18) Restoration Indicator This parameter indicates, if present, that the HLR shall send in the MAP-INSERT-SUBSCRIBER-DATA the MME Name if the subscriber is registered to EPS, or the SGSN Number if available and if the subscriber is registered to GPRS. The VLR may set this indicator during a CSFB mobile originated call if the VLR performs an implicit location update (see 3GPP TS 23.272 [143]). MTRF Supported See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. Equivalent PLMN List This parameter indicates the equivalent PLMN list of which the VLR requests the corresponding CSG Subscription data. MSISDN-less Operation Supported See clause 3.6.1.5 of 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. MME-Diameter-Address-For-MT-SMS This parameter may be sent by an IWF that registers an MME for MT-SMS. The MME-Diameter-Address-For-MT-SMS may be stored in the HLR and may be sent in SMS interrogation responses to SMS-GMSCs. Reset-IDs Supported This parameter indicates, if present, the support of Reset-IDs by the MSC. ADD Capability This parameter indicates, if present, the support of ADD function by the HLR. Paging Area Capability This parameter indicates, if present, the support of Paging Area function by the HLR. The HLR shall report the same capability for all subscribers. User error In case of unsuccessful updating, an error cause shall be returned by the HLR. The following error causes defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - unknown subscriber; - roaming not allowed; This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the VLR number. The cause is qualified by the roaming restriction reason ""PLMN Not Allowed"", ""Supported RAT Types Not Allowed"" or ""Operator Determined Barring"". If no qualification is received (HLR with MAP Version 1), ""PLMN Not Allowed"" is taken as default. This cause shall be used when the HLR rejects a MAP Update Location request received for an MSISDN-less subscription from a VLR not supporting MSISDN-less operation (see clause 3.6.1.5 of 3GPP TS 23.012 [23]). - system failure; - unexpected data value. Provider error For definition of provider errors see clauseÊ7.6.1. 8.1.3 MAP_CANCEL_LOCATION service 8.1.3.1 Definition This service is used between HLR and VLR to delete a subscriber record from the VLR. It may be invoked automatically when an MS moves from one VLR area to another, to remove the subscriber record from the old VLR, or by the HLR operator to enforce a location updating from the VLR to the HLR, e.g. on withdrawal of a subscription. Also this service is used between HLR and SGSN to delete a subscriber record from the SGSN. It may be invoked automatically when an MS moves from one SGSN area to another, to remove the subscriber record from the old SGSN, or by the HLR operator to enforce a location updating from the SGSN to the HLR. This service is also used to request the SGSN to indicate to the MS to initiate an immediate re-attach procedure. In an EPS this service is used between HSS and IWF and between IWF and IWF to delete the subscriber record from the MME or SGSN or to release bearer resources without deleting the subscriber record. This service is also used to request the MME or SGSN to indicate to the UE to initiate an immediate re-attach procedure. The MAP_CANCEL_LOCATION service is a confirmed service using the primitives defined in tableÊ8.1/3."
"8.1.3.2 Service primitives TableÊ8.1/3: MAP_CANCEL_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) LMSI C C(=) Cancellation Type C C(=) MTRF Supported And Authorized U C(=) MTRF Supported And Not Authorized U C(=) New MSC Number U C(=) New VLR Number U C(=) New LMSI U C(=) Reattach Required U C(=) User error C C(=) Provider error O 8.1.3.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. LMSI See definition in clauseÊ7.6.2. The LMSI shall be included if it has been received from VLR. LMSI is not applicable between SGSN and HLR. Value 0000 0000 can be used to indicate that the LMSI is not in use. Cancellation Type See definition in clauseÊ7.6.3. The presence of this parameter is mandatory when the Cancel Location is sent to the SGSN or IWF. The parameter may also be sent during an inter-VLR location update If the VLR receives this parameter and does not understand it the VLR shall ignore it and should by default assume an Update procedure. If the SGSN receives this parameter indicating initial attach procedure, the SGSN shall do as specified in 3GPP TS 23.060 [104], and shall not delete the subscription data. MTRF Supported And Authorized See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. MTRF Supported And Not Authorized See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. New MSC Number This parameter refers to the E.164 address of the new VMSC. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported And Authorized flag is present. New VLR Number This parameter contains the new VLR Number. See definition in clauseÊ7.6.2. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported And Authorized flag is present. New LMSI See definition in clauseÊ7.6.2 for LMSI. This parameter shall be present if the MTRF Supported And Authorized flag is present and the HLR has received the LMSI in Update Location from the new VLR. Reattach Required When present and when the Cancellation Type indicates a subscription withdraw, this parameter indicates that the MME (informed via the IWF) or the SGSN shall delete the subscription data and request the UE or MS to initiate an immediate re-attach procedure as described in 3GPP TS 23.401 [145] and in 3GPP TS 23.060 [12]. User error If the cancellation fails, an error cause is to be returned by the VLR or by the SGSN or IWF. One of the following error causes defined in clauseÊ7.6.1 shall be used: - unexpected data value; - data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 8.1.4 MAP_SEND_IDENTIFICATION service 8.1.4.1 Definition The MAP_SEND_IDENTIFICATION service is used between a VLR and a previous VLR to retrieve IMSI and authentication data for a subscriber registering afresh in that VLR. It may also be used to send the MSC number from a VLR to a previous VLR. The MAP_SEND_IDENTIFICATION service is a confirmed service using the service primitives defined in tableÊ8.1/4. 8.1.4.2 Service primitives TableÊ8.1/4: MAP_SEND_IDENTIFICATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) TMSI M M(=) Number of requested vectors M M(=) Segmentation prohibited indicator C C(=) MSC Number U C(=) Previous Location Area Id U C(=) Hop Counter U C (=) MTRF Supported U C(=) VLR Number U C(=) New LMSI U C(=) IMSI C C(=) Authentication set U C(=) Current Security Context U C(=) MT call pending flag U C(=) Last used LTE PLMN ID U C(=) User error C C(=) Provider error O 8.1.4.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. TMSI See definition in clauseÊ7.6.2. If multiple service requests are present in a dialogue then this parameter shall be present in every service request. Number of requested vectors A number indicating how many authentication vectors the new VLR is prepared to receive. The previous VLR shall not return more vectors than indicated by this parameter. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one Segmentation prohibited indicator This parameter indicates if the new VLR or SGSN allows segmentation of the response at MAP user level. This parameter may be present only in the first request of the dialogue. IMSI See definition in clauseÊ7.6.2. The IMSI is to be returned if the service succeeds. If multiple service requests are present in a dialogue and the service succeeds then this parameter shall not be present in any service response other than the first one MSC Number This is the ISDN number assigned to the MSC currently serving the MS. This parameter shall be present if the MTRF Supported flag is present. Previous Location Area Id See definition in clauseÊ7.6.2. Together with the TMSI the Previous Location Area Id can be used to derive the IMSI. Authentication set See definition in clauseÊ7.6.7. If the service succeeds a list of up to five authentication sets is returned, if there are any available. Current Security Context See definition in clause 7.6.7. If the service succeeds, a list of either GSM or UMTS Security Context parameters can be returned. This parameter shall not be included if the Key Status associated to the current security context indicates this is a new keyset that has not been used yet. If this parameter is present in the message, the new VLR shall consider that the keyset has already been used (i.e. the key status is ""old""). MT call pending flag This flag indicates by its presence that there is a Mobile Terminating call pending in the old MSC/VLR. See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. Hop Counter For the use of this parameter see 3GPPÊTSÊ23.012Ê[23]. MTRF Supported See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. VLR Number This is the ISDN number assigned to the VLR currently serving the MS. See definition in clauseÊ7.6.2. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported flag is present. New LMSI See definition in clauseÊ7.6.2 for LMSI. This parameter may be present if the MTRF Supported flag is present. Last used LTE PLMN ID See 3GPP TS 23.272 [143] for the use of this parameter and the conditions for its presence. User error This parameter is mandatory if the service fails. The following error cause defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - unidentified subscriber. Provider error For definition of provider errors see clauseÊ7.6.1. 8.1.5 Void 8.1.5.1 Void 8.1.5.2 Void 8.1.5.3 Void 8.1.6 MAP_PURGE_MS service 8.1.6.1 Definition This service is used between the VLR and the HLR to cause the HLR to mark its data for an MS so that any request for routing information for a mobile terminated call or a mobile terminated short message will be treated as if the MS is not reachable. It is invoked when the subscriber record for the MS is to be deleted in the VLR, either by MMI interaction or automatically, e.g. because the MS has been inactive for several days. This service shall not be used if both the VLR and HLR support the Super-Charger functionality. Also this service is used between the SGSN and the HLR to cause the HLR to mark its data for an MS so that any request for routing information for a mobile terminated short message or a network requested PDP-context activation will be treated as if the MS is not reachable. It is invoked when the subscriber record for the MS is to be deleted in the SGSN, either by MMI interaction or automatically, e.g. because the MS has been inactive for several days. This service shall not be used if both the SGSN and HLR support the Super-Charger functionality. In an EPS this service is used between IWF and IWF and between IWF and HSS. The MAP_PURGE_MS service is a confirmed service using the primitives defined in tableÊ8.1/6. 8.1.6.2 Service primitives TableÊ8.1/6: MAP_PURGE_MS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) VLR number C C(=) Freeze TMSI C C(=) Freeze P-TMSI C C(=) Freeze M-TMSI C C(=) SGSN number C C(=) Last known location C C(=) User error C C(=) Provider error O 8.1.6.3 Parameter definitions and use Invoke ID See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. VLR number Shall be present if the sender is VLR. See definition in clauseÊ7.6.2. SGSN number Shall be present if the sender is SGSN. See definition in clause 7.6.2. In an EPS, this parameter may contain the IWF number. Freeze TMSI This parameter is sent to the VLR to indicate that the TMSI has to be frozen. It shall be present if the received VLR number matches the stored VLR number. Freeze P-TMSI This parameter is sent to the SGSN to indicate that the P-TMSI has to be frozen. It shall be present if the received SGSN number matches the stored SGSN number. Freeze M-TMSI This parameter is sent to the IWF to indicate that the M-TMSI has to be frozen. It shall be present if the received node number matches the stored IWF number. Last known location This parameter contains the last known location of the purged UE. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error See definition of provider errors in clauseÊ7.6.1. 8.1.7 MAP_UPDATE_GPRS_LOCATION service 8.1.7.1 Definition This service is used by the SGSN to update the location information stored in the HLR. In an EPS, this service is used between IWF and IWF and between IWF and HSS. The MAP_UPDATE_GPRS_LOCATION service is a confirmed service using the service primitives given in tableÊ8.1/7. 8.1.7.2 Service primitives TableÊ8.1/7: MAP_UPDATE_GPRS_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) SGSN number M M(=) SGSN address M M(=) Supported CAMEL Phases C C(=) SoLSA Support Indicator C C(=) Super-Charger Supported in Serving Network Entity C C(=) GPRS enhancements support indicator C C(=) Supported LCS Capability Sets C C(=) Offered CAMEL 4 CSIs C C(=) Inform Previous Network Entity C C(=) PS LCS Not Supported by UE C C(=) V-GMLC Address U C(=) Call barring support indicator C C(=) IMEISV C C(=) Skip Subscriber Data Update U C(=) Supported RAT Types Indicator U C(=) EPS Info C C(=) Serving Node Type Indicator C C(=) Supported Features U C(=) Used RAT Type U C(=) GPRS Subscription Data not needed Indicator C C(=) EPS Subscription Data Not Needed Indicator C C(=) Node-Type-Indicator U C(=) Area Restricted Indicator C C(=) UE Reachable Indicator C C(=) T-ADS Data Retrieval Support Indicator C C(=) Homogeneous Support Of IMS Voice Over PS Sessions C C(=) Update of Homogeneous Support Of IMS Voice Over PS Sessions C C(=) UE SRVCC Capability C C(=) Equivalent PLMN List C C(=) MME Number for MT SMS C C(=) SMS-Only C C(=) SMS Register Request C C(=) Removal of MME Registration for SMS C C(=) MSISDN-less Operation Supported C C(=) SGSN Name C C(=) SGSN Realm C C(=) Lgd Support Indicator C C(=) Adjacent-PLMNs C C(=) Reset-IDs Supported C C(=) ADD Capability U C(=) SGSN-MME Separation Support Indicator C C(=) HLR number C C(=) MME Registered for SMS C C(=) User error C C(=) Provider error O 8.1.7.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. SGSN number See definition in clauseÊ7.6.2. In an EPS, this parameter is populated with an IWF number if received from an IWF. SGSN address See definition in clauseÊ7.6.2. In an EPS, this parameter is populated with an IWF address if received from an IWF. Supported CAMEL Phases This parameter indicates which phases of CAMEL are supported. The SGSN can only support CAMEL phase 3 or greater. SoLSA Support Indicator This parameter is used by the SGSN to indicate to the HLR in the Update GPRS Location indication that SoLSA is supported. If this parameter is not included in the Update GPRS Location indication and the Subscriber is marked as only allowed to roam in Subscribed LSAs, then the HLR shall reject the roaming and indicate to the SGSN that roaming is not allowed to that Subscriber in the SGSN. This SoLSA Support Indicator shall be stored by the HLR per SGSN where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a SGSN and no SoLSA Support indicator is stored for that SGSN, the location status of that Subscriber has to be set to Restricted. Super-Charger Supported in Serving Network Entity This parameter is used by the SGSN to indicate to the HLR that the SGSN supports the Super-Charger functionality and whether subscription data has been retained by the SGSN. If subscription data has been retained by the SGSN the age indicator shall be included. Otherwise the SGSN shall indicate that subscriber data is required. If this parameter is absent then the SGSN does not support the Super-Charger functionality. GPRS enhancements support indicator This parameter is used by the SGSN to indicate to the HLR in the Update GPRS Location indication that GPRS enhancements are supported. If this parameter is included in the Update GPRS Location indication the HLR may send the extension QoS parameter in the PDP contexts to the SGSN. The HLR may send the extension-2 QoS, the extension-3 QoS and the extension-4 QoS parameters with the extension QoS parameter. HLR number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory in case of successful HLR updating. Supported LCS Capability Sets This parameter indicates, if present, the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the SGSN does not support LCS at all. The SGSN is not allowed to indicate support for LCS capability set 1. If this parameter is absent then the SGSN does not support LCS at all. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the SGSN (see clause 7.6.3.36D). Inform Previous Network Entity This parameter is used by the SGSN to ask the HLR to inform the previous network entity about the update by sending the previous network entity a Cancel Location message. It is used in case Super-Charger is supported in the network and the serving network entity has not been able to inform the previous network entity that MS has moved, that is if it has not sent SGSN Context Request to the previous serving entity. PS LCS Not Supported by UE See definition in clauseÊ7.6.11. V-GMLC address See definition in clauseÊ7.6.2. Call Barring support indicator See definition in clauseÊ7.6.3.92. IMEISV For definition of the parameter see clause 7.6.2. For the use of this parameter see 3GPP TS 23.060. IMEISV shall be present if ADD function is supported and the IMEISV is new in SGSN (The functional requirements for the presence of IMEISV due to ADD are described in 3GPP TS 22.101 clause 7.4). Skip Subscriber Data Update The presence of the parameter is optional and if present it indicates that subscriber data download during the updateGprsLocation procedure may be skipped by the HLR e.g. because the service is solely used to inform the HLR about change of IMEISV. The parameter is used to optimise signalling load during Location Update procedure. Supported RAT Types Indicator This parameter indicates, if present, which access technologies (e.g. GERAN and/or UTRAN and/or E-UTRAN) are served by the SGSN or MME (see clause 7.6.3) EPS Info This parameter may indicate that the MME or SGSN has selected a new PDN GW for an APN. If so, the HSS shall skip subscriber data update (insert subscriber data) and only note the new PDN GW. Otherwise this parameter may indicate the appropriate instruction to be performed by the HSS which is one or more of a) Update Location; i.e. send CancelLocation to the old MME and replace the stored MME id (if Serving Node Type Indicator is present and the stored MME id is different from the received MME id), or send CancelLocation to the old SGSN and replace the stored SGSN id (if Serving Node Type Indicator is absent and the stored SGSN id is different from the received SGSN id); b) Cancel SGSN; i.e. send CancelLocation to the SGSN and delete the stored SGSN id. c) Initial Attach; i.e. send CancelLocation to the MME (if Serving Node Type Indicator is absent) or to the SGSN (if Serving Node Type Indicator is present) with cancellation type set to ""initial attach procedure"" Serving Node Type Indicator This parameter indicates by its presence that the subscriber's serving node is an MME (which is either stand alone or combined with an SGSN) and it indicates by its absence that the subscriber's serving node is an SGSN (which is either stand alone or combined with an MME). Supported Features This parameter shall be used by an IWF to forward feature support indications as received from the MME or SGSN via S6a/S6d. It shall also be used by the SGSN to indicate support of the Dedicated Core Network functionality to the HLR. Used RAT Type This parameter may indicate the RAT type currently used by the serving node. GPRS Subscription Data not needed Indicator This parameter indicates by its presence that the SGSN (or MME/IWF) does not request GPRS Subscription Data in addition to EPS Subscription Data. EPS Subscription Data Not Needed Indicator This parameter indicates by its presence that the SGSN does not request EPS Subscription Data in addition to GPRS Subscription Data. NOTE: The indicator is only applicable to an SGSN which only supports Gn and Gp interfaces and does not support S4 interface. Node-Type Indicator This parameter indicates by its presence that the requesting node is a combined MME/SGSN. Absence of this Indicator indicates that the requesting node is a single MME or SGSN. When Node-Type Indicator is absent and Serving Node Type Indicator is present, the HSS may skip checking SMS/LCS supported features and skip the download of SMS/LCS-related subscription data to a standalone MME. Area Restricted Indicator This parameter indicates by its presence that the network node area is restricted due to regional subscription. This parameter is used by the IWF only. UE-Reachable Indicator This parameter indicates by its presence that the UE is reachable. NOTE: In general any UpdateGPRS-Location request message (with or without UE-Reachable Indicator) implicitly conveys the information that the UE is now reachable. This explicit indicator shall be set only when UpdateGPRS-Location is used for the only and no other purpose than indicating UE reachability. The HLR shall skip subscriber data downloading and any mobility management functionality other than reporting the UE's reachability to relevant core network entities. T-ADS Data Retrieval Support Indicator This parameter indicates by its presence that the SGSN supports retrieval of T-ADS data with the Provide-Subscriber-Info service. Homogeneous Support Of IMS Voice Over PS Sessions This parameter when present indicates that IMS voice over PS sessions is homogeneously supported in the complete SGSN area or that IMS voice over PS sessions is homogeneously not supported in the complete SGSN area. Update of Homogeneous Support Of IMS Voice Over PS Sessions This parameter when present indicates that Homogeneous Support of IMS Voice Over PS Sessions is updated. If the Homogeneous Support of IMS Voice Over PS Session is not present, the value of the Homogeneous Support of IMS Voice Over PS Sessions shall be updated as unknown to the serving node. UE SRVCC Capability See definition in clause 7.6.3.99. Equivalent PLMN List This parameter indicates the equivalent PLMN list of which the MME/SGSN requests the corresponding CSG Subscription data. MME Number for MT SMS This parameter contains the ISDN number of the MME allocated for MT SMS (see 3GPP TS 23.003 [17]). It is present when the MME requests to be registered for SMS. SMS-Only This parameter indicates to the HSS that the UE needs only PS domain services and SMS services. SMS Register Request This parameter indicates to the HSS that if the MME (via IWF) needs to be registered for SMS, prefers not to be registered for SMS or has no preference to be registered for SMS, see 3GPP TS 23.272 [143]. This parameter indicates to the HSS that if the SGSN needs to be registered for SMS, prefers not to be registered for SMS or has no preference to be registered for SMS, see 3GPP TS 23.060 [104]. Removal of MME Registration for SMS This parameter indicates by its presence that the MME requests to remove its registration for SMS. MSISDN-less Operation Supported This parameter indicates by its presence that the SGSN supports MSISDN-less operation (see clause 5.3.17 of 3GPP TS 23.060 [23]). An SGSN which supports MSISDN-less operation shall set this parameter. SGSN Name See definition in clauseÊ7.6.2. This parameter is provided in a request when the serving node is an SGSN and the SGSN supports Lgd interface for LCS and/or Gdd interface for SMS. SGSN Realm See definition in clauseÊ7.6.2. This parameter is provided in a request when the serving node is an SGSN and the SGSN supports Lgd interface for LCS and/or Gdd interface for SMS. Lgd Support Indicator This parameter, by its presence, indicates to the HSS that the SGSN supports Lgd interface for LCS. When absent the SGSN supports only Lg interface for LCS, if LCS is supported. Adjacent PLMNs This parameter indicates the list of PLMNs where an UE served by the SGSN is likely to make a handover from the PLMN where the SGSN is located. This list is statically configured by the operator in the SGSN, according to the geographical disposition of the different PLMNs in that area, the roaming agreements, etc... Reset-IDs Supported This parameter indicates, if present, the support of Reset-IDs by the SGSN. ADD Capability This parameter indicates, if present, the support of ADD function by the HLR. SGSN-MME Separation Support Indicator This parameter indicates by its presence that the HSS separately stores SGSN Id and MME Id. A combined MME/SGSN shall not send Update-GPRS-Location at intra node inter RAT routing area update if a Separation Indicator was not received previously. MME Registered for SMS This parameter indicates by its presence that the HSS has registered the MME for SMS. User error In case of unsuccessful updating, an error cause shall be returned by the HLR. The following error causes defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - unknown subscriber; - roaming not allowed. This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the SGSN number. The cause is qualified by the roaming restriction reason ""PLMN Not Allowed"", ""Supported RAT Types Not Allowed"" or ""Operator Determined Barring"". This cause shall be used when the HLR rejects a MAP Update Gprs Location request received for an MSISDN-less subscription from a SGSN not supporting MSISDN-less operation. - system failure; - unexpected data value. The diagnostic in the Unknown Subscriber may indicate ""Imsi Unknown"" or ""Gprs or EPS Subscription Unknown"". Provider error For definition of provider errors see clauseÊ7.6.1. 8.1.8 MAP-NOTE-MM-EVENT 8.1.8.1 Definition This service is used between the VLR and the gsmSCF or between the SGSN and the gsmSCF when a mobility management event for a subscriber has been processed successfully, that subscriber is provisioned with M-CSI or MG-CSI and the relevant mobility management event is marked for reporting. This service is also used between the VLR and the Presence Network Agent or between the SGSN and the Presence Network Agent to notify the Presence Network Agent when a mobility management event for a subscriber has been processed successfully, that subscriber is provisioned with M-CSI or MG-CSI and the relevant mobility management event is marked for reporting (see 3GPP TS 23.141 [128]). 8.1.8.2 Service primitives The service primitives are shown in tableÊ8.1/8. TableÊ8.1/8: MAP_NOTE_MM_EVENT parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Event Met M M(=) Service Key M M(=) IMSI M M(=) Basic MSISDN M M(=) Location Information for GPRS C C(=) Location Information C C(=) LSA Identity C C(=) Supported CAMEL Phases M M(=) Offered CAMEL 4 Functionalities C C(=) User error C C(=) Provider error O 8.1.8.3 Parameter use Event Met This parameter indicates the mobility management event that has lead to the notification. It shall have one of the following values for a mobility management event reported by the VLR: - Location update in the same VLR service area; - Location update to another VLR service area; - IMSI attach; - MS initiated IMSI detach (explicit detach); - Network initiated IMSI detach (implicit detach). It shall have one of the following values for a mobility management event reported by the SGSN: - Routeing area update in the same SGSN service area; - Routeing area update to another SGSN service area; - GPRS attach; - MS initiated GPRS detach; - Network initiated GPRS detach; - Network initiated transfer to the ""not reachable for paging"" state. Service Key See clause 7.6.x. IMSI See clause 7.6.x. Basic MSISDN See clause 7.6.x. Location Information See clause 7.6.2.30. This information shall be sent when the event is reported by a VLR, if available. If the event is reported as part of an SGs location update procedure, this information shall include the LAI and the Location Information for EPS if available. Location Information for GPRS See clause 7.6.2.30a. This information shall be sent when the event is reported by an SGSN, if available. LSA Identity See clause 7.6.x. This information shall be sent, if available. Supported CAMEL Phases See clause 7.6.x. This information shall always be sent. Offered CAMEL 4 Functionalities This parameter indicates the CAMEL phase 4 functionalities offered by the sending entity, VMSC/VLR or SGSN (see clause 7.6.3.36G). User error This parameter is sent by the receiving entity when an error is detected. It shall have one of the following values: - Data Missing; - Unexpected Data Value; - Unknown Subscriber; - MM-EventNotSupported. Provider error This is defined in clause 7.6.1. 8.1.9 MAP_UPDATE_VCSG_LOCATION service 8.1.9.1 Definition This procedure is used by the VLR or SGSN to register the MS in the CSS when - the VPLMN supports Autonomous CSG Roaming - and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN - and the MS has requested an initial attach or a location area procedure or a routing area procedure to a CSG cell - and the VLR or SGSN has not yet registered the MS in the CSS. The MAP_UPDATE_VCSG_LOCATION service is a confirmed service using the service primitives given in table 8.1/9. 8.1.9.2 Service primitives Table 8.1/9: MAP_UPDATE_VCSG_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) VLR number C C(=) SGSN number C C(=) MSISDN C C(=) Temporary Empty CSG Subscription data Indicator C C(=) User error C C(=) Provider error O 8.1.9.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. VLR number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory when the service is used by the VLR. SGSN number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory when the service is used by the SGSN. MSISDN See definition in clauseÊ7.6.2. Shall be present if this parameter is available. Temporary Empty CSG Subscription data Indicator See definition in clauseÊ7.6.3.100. This parameter shall be present if the CSS accepts the request and there is no CSG Subscription data (empty CSG-ID list) for the roaming MS in the CSS. User error The following error causes defined in clauseÊ7.6.1 may be used: - unknown subscriber; - system failure; - unexpected data value. Provider error For definition of provider errors see clause 7.6.1 8.1.10 MAP_ CANCEL_VCSG_LOCATION service 8.1.10.1 Definition This service is used between CSS and VLR to delete a roaming user record including the CSG subscription data and the CSS number from the VLR. The service is also used between CSS and SGSN to delete a roaming user record including the CSG subscription data and the CSS number from the SGSN. It may be invoked when there is removal of the CSG subscription data in CSS and of the MS registration including the case where a MS was registered in CSS but without CSG data. The MAP_CANCEL_VCSG_LOCATION service is a confirmed service using the primitives defined in tableÊ8.1/10. 8.1.10.2 Service primitives TableÊ8.1/10: MAP_CANCEL_VCSG_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) User error C C(=) Provider error O 8.1.10.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. User error If the cancellation fails, an error cause is to be returned by the VLR or by the SGSN. One of the following error causes defined in clauseÊ7.6.1 shall be used: - unexpected data value; - data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 8.2 Paging and search 8.2.1 MAP_PAGE service 8.2.1.1 Definition This service is used between VLR and MSC to initiate paging of an MS for mobile terminated short message or unstructured SS notification. The MAP_PAGE service is a confirmed service using the primitives from tableÊ8.2/1. 8.2.1.2 Service primitives TableÊ8.2/1: MAP_PAGE Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) Stored location area Id M M(=) TMSI U C(=) User error C C(=) Provider error O 8.2.1.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is used to define the paging subgroup. If the TMSI is not supplied, paging on the radio path uses the IMSI as an identifier. Stored location area Id See definition in clauseÊ7.6.2. TMSI See definition in clauseÊ7.6.2. The TMSI is included if paging on the radio channel is to use the TMSI as an identifier. User error The following error causes defined in clauseÊ7.6.1 may be sent by the user in case of a paging error, depending on the failure reason: - absent subscriber; - unknown location area; - busy subscriber; - system failure; - this corresponds to the case where there is no call associated with the MAP_PAGE service, i.e. if the call has been released but the dialogue to the VLR has not been aborted; - unexpected data value. Provider error See definition in clauseÊ7.6.1. 8.2.2 MAP_SEARCH_FOR_MS service 8.2.2.1 Definition This service is used between VLR and MSC to initiate paging of an MS in all location areas of that VLR. It is used if the VLR does not hold location area information confirmed by radio contact. The MAP_SEARCH_FOR_MS service is a confirmed service using the primitives from tableÊ8.2/2. 8.2.2.2 Service primitives TableÊ8.2/2: MAP_SEARCH_FOR_MS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) Current location area Id C C(=) User error C C(=) Provider error O 8.2.2.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is used to identify the subscriber when paging on the radio path. Current location area Id See definition in clauseÊ7.6.2. In case of successful outcome of the service, i.e. if the MS responds to paging, the Location Area Id of the area in which the MS responded is given in the response. User error The following error causes defined in clauseÊ7.6.1 shall be sent by the user if the search procedure fails, depending on the failure reason: - absent subscriber; this error cause is returned by the MSC if the MS does not respond to the paging request; - system failure; - this corresponds to the case where there is no call associated with the MAP_SEARCH_FOR_MS service, i.e. if the call has been released but the dialogue to the VLR has not been aborted; - busy subscriber; - unexpected data value. Provider error See definition in clauseÊ7.6.1. 8.3 Access management services 8.3.1 MAP_PROCESS_ACCESS_REQUEST service 8.3.1.1 Definition This service is used between MSC and VLR to initiate processing of an MS access to the network, e.g. for mobile originated short message submission or after being paged by the network. The MAP_PROCESS_ACCESS_REQUEST service is a confirmed service using the primitives from tableÊ8.3/1. 8.3.1.2 Service primitives TableÊ8.3/1: MAP_PROCESS_ACCESS_REQUEST Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) CM service type M M(=) Access connection status M M(=) Current Location Area Id M M(=) Serving cell Id M M(=) TMSI C C(=) Cksn C C(=) IMSI C C(=) C C(=) IMEI C C(=) C C(=) MSISDN U C(=) User error C C(=) Provider error O 8.3.1.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. CM service type See definition in clauseÊ7.6.9. Access connection status See definition in clauseÊ7.6.9. Current Location Area Id See definition in clauseÊ7.6.2. This parameter is used to update the VLR in case of previous VLR failure. Serving cell Id See definition in clause 7.6.2. TMSI See definition in clauseÊ7.6.2. Either TMSI or IMSI as received from the MS are included in the Request/Indication, but one shall be present. In case of CM Service Type ""Emergency Call Establishment"", the IMEI may replace IMSI/TMSI. Cksn See definition in clauseÊ7.6.7. In case of access with TMSI, the Cksn shall be present. IMSI See definition in clauseÊ7.6.2. Either TMSI or IMSI as received from the MS are included in the Request/Indication, but one shall be present. In case of CM Service Type ""Emergency Call Establishment"", the IMEI may replace IMSI/TMSI. In the Response/Confirmation, the IMSI is to be sent in case of successful outcome of the service. In case of CM Service Type ""Emergency Call Establishment"", IMEI may replace IMSI. IMEI See definition in clauseÊ7.6.2. The IMEI may replace IMSI/TMSI in the Request/Indication and IMSI in the Response/Confirmation only in case the CM Service Type indicates ""Emergency Call Establishment"". MSISDN See definition in clauseÊ7.6.2. The MSISDN is included in case of successful outcome of the service as an operator option, e.g. if it is needed at the MSC for charging purposes in case of call forwarding. User error One of the following error causes defined in clauseÊ7.6.1 shall be sent by the user if the access request fails, depending on the failure reason: - unidentified subscriber; - illegal subscriber; this error is sent if a correlated authentication procedure has not authenticated the subscriber; - illegal equipment; this error is sent if an IMEI check failed, i.e. the IMEI is prohibited-listed or not permitted-listed; - roaming not allowed; - this cause is used after VLR restart if the subscriber has no subscription for the current location area, e.g. due to regional subscription. The cause will be qualified by ""location area not allowed"" or ""national roaming not allowed"", respectively; - unknown location area; - system failure; - unexpected data value. Provider error For definition of provider errors see clauseÊ7.6.1. 8.4 Handover services It should be noted that the handover services used on the B-interface have not been updated for Release 99. The B-interface is not fully operational specified. It is strongly recommended not to implement the B-interface as an external interface. 8.4.1 MAP_PREPARE_HANDOVER service 8.4.1.1 Definition This service is used between MSC-A and MSC-B (E-interface) when a call is to be handed over or relocated from MSC A to MSC B. The MAP_PREPARE_HANDOVER service is a confirmed service using the primitives from tableÊ8.4/1."
"8.4.1.2 Service primitives TableÊ8.4/1: MAP_PREPARE_HANDOVER Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Target Cell Id C C(=) Target RNC Id C C(=) HO-NumberNotRequired C C(=) IMSI C C(=) Integrity Protection Information C C(=) Encryption Information C C(=) Radio Resource Information C C(=) AN-APDU C C(=) C C(=) Allowed GSM Algorithms C C(=) Allowed UMTS Algorithms C C(=) Radio Resource List C C(=) RAB ID C C(=) GERAN Classmark C C(=) BSSMAP Service Handover C C(=) BSSMAP Service Handover List C C(=) RANAP Service Handover C C(=) Iu-Currently Used Codec C C(=) Iu-Supported Codecs List C C(=) RAB Configuration Indicator C C(=) ASCI Call Reference C C(=) UESBI-Iu C C(=) IMEISV C C(=) Alternative Channel Type C C(=) Trace_Propagation_List C C(=) AoIP-Supported Codecs List Anchor C C(=) Regional Subscription Data U (C=) CSG Subscription Data U (C=) LCLS Global Call Reference C C(=) LCLS-Negotiation C C(=) LCLS-Configuration-Preference C C(=) Multiple Bearer Requested C C(=) Handover Number C C(=) Relocation Number List C C(=) Multicall Bearer Information C C(=) Multiple Bearer Not Supported C C(=) Selected UMTS Algorithms C C(=) Chosen Radio Resource Information C C(=) Iu-Selected Codec C C(=) Iu-Available Codecs List C C(=) AoIP-Selected Codec Target C C(=) AoIP-Available Codecs List Map C C(=) User error C C(=) Provider error O 8.4.1.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. Target Cell Id For definition of this parameter see clauseÊ7.6.2. This parameter is only included if the service is not in an ongoing transaction. This parameter shall also be excluded if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009. Target RNC Id For definition of this parameter see clauseÊ7.6.2. This parameter shall be included if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009. HO-Number Not Required For definition of this parameter see clauseÊ7.6.6. IMSI For definition of this parameter see clauseÊ7.6.2. This UMTS parameter shall be included if: - available and - if the access network protocol is BSSAP and - there is an indication that the MS also supports UMTS. Integrity Protection Information For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the access network protocol is BSSAP. Encryption Information For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the access network protocol is BSSAP. Radio Resource Information For definition of this parameter see clauseÊ7.6.6. This GSM parameter shall be included if the access network protocol is RANAP and there is an indication that the UE also supports GSM. If the parameter Radio Resource List is sent , the parameter Radio Resource Information shall not be sent. AN-APDU For definition of this parameter see clauseÊ7.6.9. Allowed GSM Algorithms For definition of this parameter see clause 7.6.6. This parameters includes allowed GSM algorithms. This GSM parameter shall be included if: - the service is a part of the Inter-MSC SRNS Relocation procedure and - Ciphering or Security Mode Setting procedure has been performed.and - there is an indication that the UE also supports GSM. Allowed UMTS Algorithms For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if all of the following conditions apply: - access network protocol is BSSAP and - Integrity Protection Information and Encryption Information are not available and - Ciphering or Security Mode Setting procedure has been performed. Radio Resource List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if the access network protocol is RANAP and there is an indication that the UE also supports GSM. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B. If the parameter Radio Resource Information is sent , the parameter Radio Resource List shall not be sent. RAB ID For definition of this parameter see clauseÊ7.6.2. This parameter shall be included when MSC-A supports multiple bearers and access network protocol is BSSAP and the RAB ID has a value other than 1. GERAN Classmark For definition of this parameter see clauseÊ7.6.6 This parameter shall be included if available. BSSMAP Service Handover For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is RANAP. If the parameter BSSMAP Service Handover List is sent, the parameter BSSMAP Service Handover shall not be sent. BSSMAP Service Handover List For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is RANAP. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B. If the parameter BSSMAP Service Handover is sent, the parameter BSSMAP Service Handover List shall not be sent. RANAP Service Handover For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is BSSAP. Iu-Currently Used Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if the handover is requested for a speech bearer and the MS is in UMTS or GERAN Iu-mode access. This parameter shall not be included if the Iu-Supported Codecs List is not included. Iu-Supported Codecs List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included by MSC-A, if the handover is requested for a speech bearer. RAB Configuration Indicator For definition of this parameter see clauseÊ7.6.6. This parameter may be included if the handover is requested for a speech bearer and MSC-A knows by means of configuration information that MSC-B supports the use of the Iu-Supported Codecs List parameter. This parameter shall not be included if the Iu-Supported Codecs List is not included. ASCI Call Reference This parameter contains either the broadcast call reference or group call reference. It shall be included if a subscriber is undergoing handover during a VGCS or VBS call, where MSC-B already has a Bearer established, so that MSC-B can determine the Group or Broadcast Call to which it shall attach the subscriber, see 3GPP TS 48.008 [49]. UESBI-Iu For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is BSSAP. IMEISV For definition of the parameter see clause 7.6.2. This parameter shall be present, if available. This is used e.g. for Management based Trace Activation (see 3GPP TS 32.422). Alternative Channel Type For definition of this parameter see clauseÊ7.6.6 It shall be present for a SCUDIF call if the access network protocol is BSSAP. Trace Propagation List See definition in clauseÊ7.6.10. This parameter shall be included when MSC-A requests trace invocation. AoIP-Supported Codecs List Anchor For definition of this parameter see clauseÊ7.6.6. This parameter may be included by MSC-A, if the handover is requested for a speech bearer and mobile terminal supports GSM codec types. Regional Subscription Data The list of subscribed Zone Codes as received from the HLR may be included by MSC-A at intra PLMN inter MSC handover and may be stored at MSC-B for use at subsequent intra MSC handover. CSG Subscription Data The subscribed CSG Subscription Information as received from the HLR may be included by MSC-A at intra PLMN inter MSC handover and at inter PLMN inter MSC handover when the target PLMN is an ePLMN, and may be stored at MSC-B for use at subsequent intra MSC handover. LCLS Global Call Reference For definition of this parameter see clauseÊ7.6.5.21. This parameter shall be included when MSC-A supports LCLS. LCLS-Negotiation For definition of this parameter see clauseÊ7.6.5.22. This parameter shall be included when MSC-A supports LCLS. LCLS-Configurations-Preference For definition of this parameter see clauseÊ7.6.5.23. This parameter shall be included when MSC-A supports LCLS. Multiple Bearer Requested For a definition of this parameter see clause 7.6.2. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B. Handover Number For definition of this parameter see clauseÊ7.6.2. This parameter shall be returned at handover, unless the parameter HO-NumberNotRequired is sent. If the parameter Handover Number is returned, the parameter Relocation Number List shall not be returned. Relocation Number List For definition of this parameter see clauseÊ7.6.2. This parameter shall be returned at relocation, unless the parameter HO-NumberNotRequired is sent. If the parameter Relocation Number List is returned, the parameter Handover Number shall not be returned. Multicall Bearer Information For a definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation in the case that MSC-B supports multiple bearers. Multiple Bearer Not Supported For a definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation when MSC-B receives Multiple Bearer Requested parameter and MSC-B does not support multiple bearers. Selected UMTS Algorithms For definition of this parameter see clauseÊ7.6.6. This parameters includes the UMTS integrity and optionally encryption algorithms selected by RNC under the control of MSC-B. This UMTS parameter shall be included if the service is a part of the inter MSC inter system handover from GSM to UMTS. Chosen Radio Resource Information For definition of this parameter see clauseÊ7.6.6. This parameter shall be returned at relocation if the encapsulated PDU is RANAP RAB Assignment Response and MS is in GSM access. Iu-Selected Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if an Iu-Supported Codecs List was received in the service request and MSC-B supports the selection of codec based on the Iu-Supported Codecs List and the target radio access network is connected to MSC-B via the Iu interface, even if the Iu-Selected Codec is equal to the Iu-Currently Used Codec received in the service request. This parameter shall not be included if the Iu-Supported Codecs List was not received in the service request. Iu-Available Codecs List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included by an MSC-B supporting TrFO, if the Iu-Supported Codecs List was included by MSC-A and the target radio access is UMTS or GERAN Iu-mode. AoIP-Selected Codec Target For definition of this parameter see clauseÊ7.6.6. This parameter may be included by an MSC-B supporting TrFO, if the AoIP-Supported Codecs List Anchor was included by MSC-A and if AoIP is used on the target A interface with transcoder inserted in the MGW. AoIP-Available Codecs List Map For definition of this parameter see clauseÊ7.6.6. This parameter may be included by an MSC-B supporting TrFO, if the AoIP-Supported Codecs List Anchor was included by MSC-A and if AoIP is used on the target A interface with transcoder inserted in the MGW. User error For definition of this parameter see clauseÊ7.6.1. The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - No handover number available. - Target cell outside group call area; - System failure. - Unexpected data value. - Data Missing. Provider error See definition of provider errors in clauseÊ7.6.1. 8.4.2 MAP_SEND_END_SIGNAL service 8.4.2.1 Definition This service is used between MSC-B and MSC-A (E-interface) indicating that the radio path has been established by MSC-B to the MS. MSC-A retains then the main control of the call until it clears. The response is used by MSC-A to inform MSC-B that all resources for the call can be released in MSC-B, either because the call has been released in MSC-A or because the call has been successfully handed over or relocated from MSC-B to another MSC. The MAP_SEND_END_SIGNAL service is a confirmed service using the primitives from tableÊ8.4/2. 8.4.2.2 Service primitives TableÊ8.4/2: MAP_SEND_END_SIGNAL Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) AN-APDU M M(=) Provider error O 8.4.2.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. AN-APDU For definition of this parameter see clauseÊ7.6.9. Provider error For definition of this parameter see clauseÊ7.6.1. 8.4.3 MAP_PROCESS_ACCESS_SIGNALLING service 8.4.3.1 Definition This service is used between MSC-B and MSC-A (E-interface) to pass information received on the A interface or Iu-interface in MSC B to MSC A. The MAP_PROCESS_ACCESS_SIGNALLING service is a non-confirmed service using the primitives from tableÊ8.4/3. 8.4.3.2 Service primitives TableÊ8.4/3: MAP_PROCESS_ACCESS_SIGNALLING Parameter name Request Indication Invoke Id M M(=) AN-APDU M M(=) Selected GSM Algorithm C C(=) Selected UMTS Algorithms C C(=) Chosen Radio Resource Information C C(=) Selected RAB id C C(=) Iu-Selected Codec C C(=) Iu-Available Codecs List C C(=) AoIP-Selected Codec Target C C(=) AoIP-Available Codecs List Map C C(=) 8.4.3.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. AN-APDU For definition of this parameter see clauseÊ7.6.9. Selected GSM algorithm For definition of this parameter see clauseÊ7.6.6. This parameter shall be present if the encapsulated PDU is Security Mode Complete and MS is in GSM access. Selected UMTS Algorithms For definition of this parameter see clauseÊ7.6.6. This parameters includes the UMTS integrity and optionally encryption algorithms selected by RNC under the control of MSC-B. This UMTS parameter shall be included if the encapsulated PDU is BSSMAP Cipher Mode Complete and the MS is in UMTS, or an interystem handover to UMTS is performed in MSC-B, or in the case of intra MSC-B intra UMTS relocation. Chosen Radio Resource Information For definition of this parameter see clauseÊ7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Response and MS is in GSM access. Selected RAB ID The selected radio access bearer that was kept at subsequent intra-MSC handover from UMTS to GSM after multiple bearers were used. Iu-Selected Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included - if MSC-B changes the selected codec and the MS is in UMTS or GERAN Iu-mode access; - if intersystem handover to UMTS or GERAN Iu-mode is performed in MSC-B; or - if MSC-B received a Forward Access Signalling service request including an Iu-Supported Codecs List and the MS is in UMTS or GERAN Iu-mode access. This parameter shall not be included if the Iu-Supported Codecs List was not received either in the Prepare Handover service request or in the Forward Access Signalling service request. Iu-Available Codecs List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included by an MSC-B supporting TrFO - if the Iu-Available Codecs List has changed in MSC-B; - if intersystem handover to UMTS or GERAN Iu-mode is performed in MSC-B; or - if MSC-B received a Forward Access Signalling service request including an Iu-Supported Codecs List and the MS is in UMTS or GERAN Iu-mode access. AoIP-Selected Codec Target For definition of this parameter see clauseÊ7.6.6. This parameter may be included - if A interface codec is changed in MSC-B; or - if intersystem handover to AoIP capable BSC is performed in MSC-B and if AoIP is used on the target A interface with transcoder inserted in the MGW; or - if MSC-B received a Forward Access Signalling service request including an AoIP-Supported Codecs List and the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW. This parameter shall not be included if the AoIP-Supported Codecs List Anchor was not received either in the Prepare Handover service request or in the Forward Access Signalling service request. AoIP-Available Codecs List Map For definition of this parameter see clauseÊ7.6.6. This parameter may be included by an MSC-B supporting TrFO - if the AoIP-Available Codecs List has changed in MSC-B; or - if intersystem handover to AoIP capable BSC is performed in MSC-B where AoIP is used on the target A interface with transcoder inserted in the MGW; or - if MSC-B received a Forward Access Signalling service request including an AoIP-Supported Codecs List Anchor and the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW. 8.4.4 MAP_FORWARD_ACCESS_SIGNALLING service 8.4.4.1 Definition This service is used between MSC-A and MSC-B (E-interface) to pass information to be forwarded to the A-interface or Iu-interface of MSC-B. The MAP_FORWARD_ACCESS_SIGNALLING service is a non-confirmed service using the primitives from tableÊ8.4/4. 8.4.4.2 Service primitives TableÊ8.4/4: MAP_FORWARD_ACCESS_SIGNALLING Parameter name Request Indication Invoke Id M M(=) Integrity Protection Information C C(=) Encryption Information C C(=) Key Status C C(=) AN-APDU M M(=) Allowed GSM Algorithms C C(=) Allowed UMTS Algorithms C C(=) Radio Resource Information C C(=) Radio Resource List C C(=) BSSMAP Service Handover C C(=) BSSMAP Service Handover List C C(=) RANAP Service Handover C C(=) Iu-Currently Used Codec C C(=) Iu-Supported Codecs List C C(=) RAB Configuration Indicator C C(=) Iu-Selected Codec C C(=) Alternative Channel Type C C(=) Trace Propagation List C C(=) AoIP-Supported Codecs List Anchor C C(=) AoIP-Selected Codec Target C C(=) UESBI-Iu C C(=) IMEISV C C(=) 8.4.4.3 Parameter use For the definition and use of all parameters and errors, see clauseÊ7.6.1. Invoke Id For definition of this parameter see clauseÊ7.6.1. Integrity Protection Information For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command. Encryption Information For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command. Key Status For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command. AN-APDU For definition of this parameter see clauseÊ7.6.9. Allowed GSM Algorithms This parameters includes allowed GSM algorithms. This GSM parameter shall be included if the encapsulated PDU is RANAP Security Mode Command and there is an indication that the UE also supports GSM. Allowed UMTS Algorithms For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if Integrity Protection Information and Encryption Information are not available and the encapsulated PDU is BSSMAP Cipher Mode Command. Radio Resource Information For definition of this parameter see clauseÊ7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Request. If the parameter Radio Resource List is sent, the parameter Radio Resource Information shall not be sent. Radio Resource List For definition of this parameter see clauseÊ7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Request and MSC-A requests modification of multiple bearers. If the parameter Radio Resource Information is sent, the parameter Radio Resource List shall not be sent. BSSMAP Service Handover For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the encapsulated PDU is RANAP RAB Assignment Request. If the parameter BSSMAP Service Handover List is sent, the parameter BSSMAP Service Handover shall not be sent. BSSMAP Service Handover List For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the encapsulated PDU is RANAP RAB Assignment Request and MSC-A requests modification of multiple bearers. If the parameter BSSMAP Service Handover is sent, the parameter BSSMAP Service Handover List shall not be sent. RANAP Service Handover For definition of this parameter see clauseÊ7.6.6.. It shall be present if it is available and the encapsulated PDU is BSSMAP Assignment Request. Iu-Currently Used Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request for a speech bearer and the MS is in UMTS or GERAN Iu-mode access. This parameter shall not be included if the Iu-Supported Codecs List is not included. Iu-Supported Codecs List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request and - a new bearer is allocated for speech; - an existing bearer is modified from data to speech; or - for an existing speech bearer the order of priority in the Iu-Supported Codecs List needs to be modified. This parameter shall not be included if the Iu-Selected Codec is included. RAB Configuration Indicator For definition of this parameter see clauseÊ7.6.6. This parameter may be included if the encapsulated PDU is a RANAP RAB Assignment Request for a speech bearer, and MSC-A knows by means of configuration information that MSC-B supports the use of the Iu-Supported Codecs List parameter. This parameter shall not be included if the Iu-Supported Codecs List is not included. Iu-Selected Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if - the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request for an existing speech bearer; and - the MS is in UMTS or GERAN Iu-mode access; and - an Iu-Available Codecs List was received by MSC-A for this speech bearer before, either in the Prepare Handover service response or in the Process Access Signalling service request. This parameter shall not be included if the Iu-Supported Codecs List is included. Alternative Channel Type For definition of this parameter see clauseÊ7.6.6. This parameter shall be present for a SCUDIF call if the encapsulated PDU is BSSMAP Assignment Request. Trace Propagation List See definition in clauseÊ7.6.10. This parameter shall be included when MSC-A requests trace invocation. AoIP-Supported Codecs List Anchor For definition of this parameter see clauseÊ7.6.6. This parameter may be included if the encapsulated PDU is a BSSMAP Assignment Request and - a new bearer is allocated for speech; - an existing bearer is modified from data to speech; or - for an existing speech bearer the order of priority in the AoIP-Supported Codecs List needs to be modified. This parameter shall not be included if the AoIP-Selected Codec Target is included. AoIP-Selected Codec Target For definition of this parameter see clauseÊ7.6.6. This parameter may be included if - the encapsulated PDU is a BSSMAP Assignment Request for an existing speech bearer; and - the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW; and - an AoIP-Available Codecs List was received by MSC-A for this speech bearer before, either in the Prepare Handover service response or in the Process Access Signalling service request. This parameter shall not be included if the AoIP-Supported Codecs List Anchor is included. UESBI-Iu For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is BSSAP and the parameter has not already been sent to the target MSC. IMEISV For definition of the parameter see clause 7.6.2. This parameter shall be present if available and if not already sent to the target MSC. This is used e.g. for Management based Trace Activation (see 3GPP TS 32.422). 8.4.5 MAP_PREPARE_SUBSEQUENT_HANDOVER service 8.4.5.1 Definition This service is used between MSC-B and MSC-A (E-interface) to inform MSC-A that it has been decided that a handover or relocation to either MSC-A or a third MSC (MSC-B') is required. The MAP_PREPARE_SUBSEQUENT_HANDOVER service is a confirmed service using the primitives from tableÊ8.4/5. 8.4.5.2 Service primitives TableÊ8.4/5: MAP_PREPARE_SUBSEQUENT_HANDOVER Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Target Cell Id C C(=) Target RNC Id C C(=) Target MSC Number M M(=) Selected RAB ID C C(=) GERAN Classmark C C(=) RAB Configuration Indicator C C(=) AN-APDU M M(=) C C(=) User error C C(=) Provider error O 8.4.5.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. Target Cell Id For definition of this parameter see clauseÊ7.6.2. This parameter shall be excluded if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009. Target RNC Id For definition of this parameter see clauseÊ7.6.2. This parameter shall be included if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009. Target MSC Number For definition of this parameter see clauseÊ7.6.2. Selected RAB ID For definition of this parameter see clauseÊ7.6.2. GERAN Classmark For definition of this parameter see clauseÊ7.6.6 This parameter shall be included if available. RAB Configuration Indicator For definition of this parameter see clauseÊ7.6.6. This parameter may be included if the call is a speech call and MSC-B knows by means of configuration information that MSC-B' (and MSC-A) supports the use of the Iu-Supported Codecs List parameter. AN-APDU For definition of this parameter see clauseÊ7.6.9. User error For definition of this parameter see clauseÊ7.6.1. The following error causes defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown MSC; - Subsequent handover failure; - Unexpected data value; - Data Missing. Provider error For definition of this parameter see clauseÊ7.6.1. 8.4.6 MAP_ALLOCATE_HANDOVER_NUMBER service 8.4.6.1 Definition This service is used between MSC and VLR (B-interface) to request a handover number. The MAP_ALLOCATE_HANDOVER_NUMBER service is a confirmed service using the primitives from tableÊ8.4/6. 8.4.6.2 Service primitives TableÊ8.4/6: MAP_ALLOCATE_HANDOVER_NUMBER Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) User error C C(=) Provider error O 8.4.6.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. User error For definition of this parameter see clauseÊ7.6.1. The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - No handover number available. Provider error For definition of this parameter see clauseÊ7.6.1. 8.4.7 MAP_SEND_HANDOVER_REPORT service 8.4.7.1 Definition This service is used between VLR and MSC-B (B-interface) to transfer the handover number to be forwarded to and used by MSC-A. The MAP_SEND_HANDOVER_REPORT service is a confirmed service using the primitives from tableÊ8.4/7. 8.4.7.2 Service primitives TableÊ8.4/7: MAP_SEND_HANDOVER_REPORT Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Handover Number M M(=) Linked Id M M(=) Provider error O 8.4.7.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. Handover Number For definition of this parameter see clauseÊ7.6.2. Linked Id For definition of this parameter see clauseÊ7.6.1. This service is linked with MAP_ALLOCATE_HANDOVER_NUMBER. Provider error For definition of this parameter see clauseÊ7.6.1. 8.5 Authentication management services 8.5.1 MAP_AUTHENTICATE service The MAP_AUTHENTICATE service is used on the MAP B interface. This interface is not fully operational specified. It is strongly recommended not to implement the B-interface as an external interface. 8.5.1.1 Definition This service is used between the VLR and the MSC when the VLR receives a MAP service indication from the MSC concerning a location registration, call set-up, operation on a supplementary service or a request from the MSC to initiate authentication. The service is a confirmed service and consists of four service primitives. 8.5.1.2 Service primitives The service primitives are shown in tableÊ8.5/1. TableÊ8.5/1: MAP_AUTHENTICATE parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) RAND M M(=) CKSN M M(=) SRES M M(=) Provider error O 8.5.1.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. RAND See clauseÊ7.6.7 for the use of this parameter. CKSN See clauseÊ7.6.7 for the use of this parameter. SRES See clauseÊ7.6.7 for the use of this parameter. Provider error See clauseÊ7.6.1 for the use of this parameter. 8.5.2 MAP_SEND_AUTHENTICATION_INFO service 8.5.2.1 Definition This service is used between the VLR and the HLR for the VLR to retrieve authentication information from the HLR. The VLR requests up to five authentication vectors. Also this service is used between the SGSN and the HLR for the SGSN to retrieve authentication information and/or UE Usage Type from the HLR. The SGSN requests up to five authentication vectors. Also this service is used between the BSF and the HLR for the BSF to retrieve authentication information from the HLR. The BSF shall only request one authentication vector at a time. In an EPS, this service is used between IWF and IWF and between IWF and HSS. If the requesting node type is different from ""MME"" and the user is a UMTS subscriber, the HLR shall return authentication quintuplets. If the requesting node type is different from MME and the user is a GSM subscriber, the HLR shall return authentication triplets. If the requesting node type is ""MME"", the HSS shall return EPS authentication vectors. If the requesting node type is a combined MME/SGSN, the HSS shall return requested authentication vectors for the actual RAT and may return additional authentication vectors for the other RAT. If the HLR cannot provide the VLR, the SGSN or the BSF with triplets, an empty response is returned. The VLR, the SGSN, or the BSF may then re-use old authentication triplets, except where this is forbidden under the conditions specified in 3GPP TS 43.020Ê[24]. If the HLR cannot provide the VLR, the SGSN or the BSF with quintuplets, an empty response is returned. The VLR, the SGSN or the BSF shall not re-use old authentication quintuplets. If the HSS cannot provide the IWF with EPS authentication vectors, an empty response is returned. If the VLR or SGSN or IWF or BSF receives a MAP_SEND_AUTHENTICATION_INFO response containing a User Error parameter as part of the handling of an authentication procedure, the authentication procedure in the VLR or SGSN or MME or BSF shall fail. Security related network functions are further described in 3GPP TS 43.020 [24] and 3GPP TS 33.200. The service is a confirmed service and consists of four service primitives. 8.5.2.2 Service primitives The service primitives are shown in tableÊ8.5/2. TableÊ8.5/2: MAP_SEND_AUTHENTICATION_INFO parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI C C(=) Number of requested vectors C C(=) Requesting node type C C(=) Re-synchronisation Info C C(=) Segmentation prohibited indicator C C (=) Immediate response preferred indicator U C (=) Requesting PLMN ID C C(=) Number of additional requested vectors C C(=) Additional requested Vectors are for EPS C C(=) UE Usage Type Request Indication C C(=) AuthenticationSetList C C(=) UE Usage Type C C(=) User error C C(=) Provider error O 8.5.2.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. IMSI See clauseÊ7.6.2 for the use of this parameter. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Number of requested vectors A number indicating how many authentication vectors the VLR, the SGSN, the MME or the BSF is prepared to receive. The HLR shall not return more vectors than indicated by this parameter. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Requesting node type The type of the requesting node (SGSN, MME, combined MME/SGSN, VLR, or BSF). This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Re-synchronisation Info For definition and use of this parameter see 3GPP TS 33.200. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.. Segmentation prohibited indicator This parameter indicates if the VLR, the SGSN or the IWF allows segmentation of the response at MAP user level. This parameter may be present only in the first request of the dialogue. Immediate response preferred indicator This parameter indicates that one of the requested authentication vectors is requested for immediate use in the VLR, the SGSN, the MME or the BSF. It may be used by the HLR together with the number of requested vectors and the number of vectors stored in the HLR to determine the number of vectors to be obtained from the AuC. It shall be ignored if the number of available vectors is greater than the number of requested vectors. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Requesting PLMN ID The PLMN-ID of the requesting node. See3GPP TS 23.003. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Number of additional requested vectors A number indicating how many additional authentication vectors the combined MME/SGSN or IWF is prepared to receive. The HLR shall not return more vectors than indicated by this parameter. This parameter shall be present only if the requesting node type is a combined MME/SGSN. A combined MME/SGSN that wants to request only EPS-Vectors (only non-EPS-Vectors) shall set the requesting node type to ""MME"" (""SGSN""). This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Additional vectors are for EPS This parameter shall be absent if Number of additional vectors is absent. The parameter indicates by its presence that additional vectors (i.e. not for immediate use) are for EPS. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. UE Usage Type Request Indication This parameter indicates by its presence that the HLR (if it supports the Dedicated Core Network functionality) shall include the UE Usage Type in the response to the SGSN. This parameter is not applicable for VLRs. AuthenticationSetList A set of one to five authentication vectors are transferred from the HLR to the VLR, from the HLR to the SGSN or IWF or from the HLR to the BSF, if the outcome of the service was successful. UE Usage Type This parameter shall be present if UE Usage Type Request Indication was present in the request and the HLR supports the Dedicated Core Networks functionality (see 3GPP TS 23.060 [104]) and a UE Usage Type is available in the subscription data of the user. In this case, if the Immediate Response Preferred parameter is not set, the HLR may return no authentication vectors in the response. User error One of the following error causes defined in clauseÊ7.6.1 shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason: - unknown subscriber; - unexpected data value; - system failure; - data missing. Provider error See clauseÊ7.6.1 for the use of this parameter. 8.5.3 MAP_AUTHENTICATION_FAILURE_REPORT service 8.5.3.1 Definition This service is used between the VLR and the HLR or between the SGSN or HLR for reporting of authentication failures. 8.5.3.2 Service primitives The service primitives are shown in tableÊ8.5/3. TableÊ8.5/3: MAP_AUTHENTICATION_FAILURE_REPORT parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) Failure cause M M(=) Re-attempt M M(=) Access Type M M(=) Rand M M(=) VLR number C C(=) SGSN number C C(=) User error C C(=) Provider error O 8.5.3.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. IMSI See clauseÊ7.6.2 for the use of this parameter. Failure Cause See clauseÊ7.6.7 for use of this parameter. Re-attempt See clause 7.6.7 for use of this parameter. Access Type See clause 7.6.7 for use of this parameter. Rand This parameter identifies the specific AV that failed authentication. See clause 7.6.7 for use of this parameter. VLR number Shall be present if the sender is VLR. See definition in clauseÊ7.6.2. SGSN number Shall be present if the sender is SGSN. See definition in clause 7.6.2. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - Unknown Subscriber; - System Failure; - Unexpected Data Value. Provider error These are defined in clauseÊ7.6. 8.6 Security management services 8.6.1 MAP_SET_CIPHERING_MODE service 8.6.1.1 Definitions This service is used between the VLR and the MSC to set the ciphering mode and to start ciphering if applicable. It is called when another service requires that information is to be sent on the radio path in encrypted form. The service is a non-confirmed service and consists of two service primitives. 8.6.1.2 Service primitives The service primitives are shown in tableÊ8.6/1. TableÊ8.6/1: MAP_SET_CIPHERING_MODE parameters Parameter name Request Indication Invoke id M M(=) Ciphering mode M M(=) Kc C C(=) 8.6.1.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. Ciphering mode See clauseÊ7.6.7 for the use of this parameter. Kc The Kc parameter should be included when the ciphering mode parameter indicates that ciphering must be performed. 8.7 International mobile equipment identities management services 8.7.1 MAP_CHECK_IMEI service 8.7.1.1 Definition This service is used between the VLR and the MSC, between the MSC and the EIR, between the SGSN and EIR, and between IWF and EIR to request check of IMEI."
"If the IMEI is not available in the MSC or in the SGSN, it is requested from the MS and transferred to the EIR in the service request. This service may also be used to request the BMUEF from the EIR. The service is a confirmed service and consists of four service primitives. 8.7.1.2 Service primitives The service primitives are shown in tableÊ8.7/1. TableÊ8.7/1: MAP_CHECK_IMEI parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMEI C C(=) C C(=) IMEISV C C(=) C(=) C(=) Requested Equipment Info M M(=) Equipment status C C(=) BMUEF C C(=) User error C C(=) Provider error O 8.7.1.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. Requested Equipment Info This parameter indicates whether Equipment Status or BMUEF or both is requested. IMEI See clauseÊ7.6.2 for the use of this parameter. The parameter shall not be included in the service request between the VLR and the MSC, but one of IMEI and IMEISV is mandatory in the service request from the MSC to the EIR, from the SGSN to the EIR and from the IWF to the EIR. It is not included in the service response from the EIR to the MSC, the SGSN or the IWF, but one of IMEI and IMEISV is mandatory in the service response from the MSC to the VLR on successful outcome. IMEISV See clauseÊ7.6.2 for the use of this parameter. IMEISV shall be present if BMUEF is requested. Equipment status See clauseÊ7.6.3 for the use of this parameter. This parameter is sent by the responder in case of successful outcome of the service if Equipment status was requested. BMUEF See clauseÊ7.6.4 for the use of this parameter. This parameter is sent by the responder in case of successful outcome of the service if BMUEF was requested. User error One of the following error causes defined in clauseÊ7.6.1 shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason: - unknown equipment; this error is returned by the responder when the IMEI is not known in the EIR; - system failure; - data missing. Provider error See clauseÊ7.6.1 for the use of this parameter. 8.7.2 MAP_OBTAIN_IMEI service 8.7.2.1 Definition This service is used between the VLR and the MSC to request the IMEI. If the IMEI is not available in the MSC, it is requested from the MS. The service is a confirmed service and consists of four service primitives. 8.7.2.2 Service primitives The service primitives are shown in tableÊ8.7/2. TableÊ8.7/2: MAP_OBTAIN_IMEI parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMEI C C(=) User error C C(=) Provider error O 8.7.2.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. IMEI See clauseÊ7.6.2 for the use of this parameter. The parameter is included in the service response from the MSC to the VLR on successful outcome of the service. User error If the service fails, the VLR sends the user error System Failure (see clauseÊ7.6.1) to the MSC. Provider error See clauseÊ7.6.1 for the use of this parameter. 8.8 Subscriber management services 8.8.1 MAP-INSERT-SUBSCRIBER-DATA service 8.8.1.1 Definition This service is used by an HLR to update a VLR with certain subscriber data in the following occasions: - the operator has changed the subscription of one or more supplementary services, basic services or data of a subscriber. Note that in case of withdrawal of a Basic or Supplementary service this primitive shall not be used; - the operator has applied, changed or removed Operator Determined Barring; - the subscriber has changed data concerning one or more supplementary services by using a subscriber procedure; - the HLR provides the VLR with subscriber parameters at location updating of a subscriber or at restoration. In this case, this service is used to indicate explicitly that a supplementary service is not provisioned, if the supplementary service specification requires it. The only supplementary services which have this requirement are the CLIR and COLR services. Network access mode is provided only in restoration. If the Super-Charger functionality is supported the HLR may not need to provide the VLR with subscriber parameters at location updating of a subscriber. See TS 23.116. Also this service is used by an HLR to update an SGSN with certain subscriber data in the following occasions: - if the GPRS subscription has changed; - if the network access mode is changed; - the operator has applied, changed or removed Operator Determined Barring; - the subscriber has changed data concerning one or more supplementary services by using a subscriber procedure; - the HLR provides the SGSN with subscriber parameters at GPRS location updating of a subscriber. If the Super Charger functionality is supported the HLR may not need to provide the SGSN with subscriber parameters. See 3GPP TS 23.116. Also this service is used by a CSS to update an SGSN or a VLR with VPLMN-CSG-Subscription data in the following occasions: - if the VPLMN-CSG subscription data has changed; - the CSS provides the VLR or SGSN with VPLMN-CSG subscription data at VCSG location updating of a subscriber. In an EPS, this service is used by an HSS to update an MME via IWF with certain subscriber data in the following occasions: - the EPS subscription has changed; - the operator has applied, changed or removed Operator Determined Barring; - the HSS provides the MME via IWF(MME) with subscriber parameters at EPS location updating of a subscriber unless an explicit indication to skip subscriber data update has been received. In an EPS, this service is used by an IWF to indicate to the MME via IWF that the HSS has requested to be notified when the UE has become reachable. It is a confirmed service and consists of the primitives shown in tableÊ8.8/1. 8.8.1.2 Service primitives TableÊ8.8/1: MAP-INSERT-SUBSCRIBER-DATA Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI C C(=) MSISDN C C(=) Additional MSISDN C C(=) Category C C(=) Subscriber Status C C(=) Bearer service List C C(=) C C(=) Teleservice List C C(=) C C(=) Forwarding information List C C(=) Call barring information List C C(=) CUG information List C C(=) SS-Data List C C(=) eMLPP Subscription Data C C(=) MC-Subscription Data C C(=) Operator Determined Barring General data C C(=) C C(=) Operator Determined Barring HPLMN data C C(=) Roaming Restriction Due To Unsupported Feature C C(=) Regional Subscription Data C C(=) VLR CAMEL Subscription Info C C(=) Voice Broadcast Data C C(=) Voice Group Call Data C C(=) Network access mode C C(=) GPRS Subscription Data C C(=) EPS Subscription Data C C(=) VPLMN LIPA Allowed C C(=) Roaming Restricted In SGSN/MME Due To Unsupported Feature C C(=) North American Equal Access preferred Carrier Id List U C(=) SGSN CAMEL Subscription Info C C(=) LSA Information C C(=) IST Alert Timer C C(=) SS-Code List C C(=) LMU Identifier C C(=) LCS Information C C(=) CS Allocation/Retention priority C C(=) Super-Charger Supported In HLR C C(=) Subscribed Charging Characteristics C C(=) Access Restriction Data C C(=) ICS Indicator U C(=) CSG Subscription Data C C(=) VPLMN CSG Subscription Data C C(=) UE Reachability Request Indicator C C(=) SGSN Number C C(=) MME-Name C C(=) Subscribed Periodic RAU-TAU Timer C C(=) Subscribed Periodic LAU Timer C C(=) MDT User Consent C C(=) PS and SMS-Only Service Provision C C(=) SMS in SGSN Allowed C C(=) CS-to-PS-SRVCC-Allowed-Indicator C C(=) P-CSCF Restoration Request C C(=) Adjacent Access Restriction Data C C(=) IMSI-Group-Id List C C(=) UE Usage Type C C(=) User Plane Integrity Protection Indicator C C(=) DL-Buffering Suggested Packet Count C C(=) Reset-IDs C C(=) eDRX-Cycle-Length List C C(=) IAB-Operation-Allowed-Indicator C C(==) Regional Subscription Response C C(=) Supported CAMEL Phases C C (=) Offered CAMEL 4 CSIs C C (=) Supported Features U C (=) User error U C(=) Provider error O 8.8.1.3 Parameter use All parameters are described in clauseÊ7.6. The following clarifications are applicable: Network access mode This parameter defines if the subscriber has access to MSC/VLR and/or to SGSN/MME. This parameter is used by SGSN/MME and MSC/VLR. In VLR, the parameter is used only as part of Restore Data Procedure and the parameter is not stored in the VLR. This parameter shall always be sent to the SGSN and viaIWF to the MME as part of the GPRS subscriber data at GPRS/MME location updating. It shall be sent to the SGSN and via IWF to the MME if it is changed as a result of administrative action. This parameter shall not be used by the CSS. IMSI It is only included if the service is not used in an ongoing transaction (e.g. location updating). This parameter is used by the VLR and the SGSN and IWF. MSISDN For subscriptions with MSISDN: It is included at location updating and when it is changed. The MSISDN sent shall be the basic MSISDN. This parameter is used by the VLR and the SGSN and IWF. For a subscription without MSISDN: The HLR shall not populate this parameter if the VLR or SGSN explicitly indicated support of MSISDN-less operation. NOTE 1: See clauses 8.1.2.3 and 8.1.7.3 for the case where the VLR or SGSN does not support MSISDN-less operation. Additional MSISDN If subscribed, the Additional MSISDN is included at location updating and when it is changed. This parameter is used by the SGSN and IWF. This parameter shall be ignored by the VLR if received. If the SGSN does not indicate support of the feature the HSS shall not send the parameter. Category It is included either at location updating or when it is changed. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. Subscriber Status It is included either at location updating or when it is changed. To apply, remove or update Operator Determined Barring Categories the Subscriber Status is set to Operator Determined Barring. In this case ODB General Data shall also be present. If the Operator Determined Barring applies and the subscriber is registered in the HPLMN and HPLMN specific Operator Determined Barring applies then ODB HPLMN Specific Data shall also be present. To remove all Operator Determined Barring Categories the Subscriber Status shall be set to ""Service Granted"". This parameter is used by the VLR and the SGSN and IWF. This parameter shall not be used by the CSS. Bearer service List A list of Extensible Bearer service parameters (Extensible Bearer service is defined in clauseÊ7.6). An Extensible Bearer service parameter must be the code for an individual Bearer service, except in the cases described below. The codes for the Bearer service groups ""allAlternateSpeech-DataCDA"" and ""allAlternateSpeech-DataCDS"" shall, if applicable, be sent from the HLR to the VLR as a pair. The codes for the Bearer service groups ""allSpeechFollowedByDataCDA"" and ""allSpeechFollowedByDataCDS"" shall, if applicable, be sent from the HLR to the VLR as a pair. If it is included in the Request/Indication, it includes either all Extensible Bearer services subscribed (at location updating or at restoration) or only the ones added (at subscriber data modification). If the VLR receives an Indication containing any Extensible Bearer service parameters which it does not support/allocate it returns them in the response to the HLR and discards the unsupported Extensible Bearer services (no error is sent back), except in the cases described below. If the VLR receives the codes for the Bearer service groups ""allSpeechFollowedByDataCDA"" and ""allSpeechFollowedByDataCDS"" and supports one or more of the circuit-switched synchronous or asynchronous data rates specified for simple data bearer services, it shall accept the bearer service codes, and not return them in the response to the HLR. If the VLR does not support any of the circuit-switched synchronous or asynchronous data rates specified for simple data bearer services, and receives the pair of codes for ""allAlternateSpeech-DataCDA"" and ""allAlternateSpeech-DataCDS"" or the pair of codes for ""allSpeechFollowedByDataCDA"" and ""allSpeechFollowedByDataCDS"", it shall reject the pair of codes by returning them in the response to the HLR. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Teleservice List A list of Extensible Teleservice parameters (Extensible Teleservice is defined in clauseÊ7.6). An Extensible Teleservice parameter must be the code for an individual Teleservice. If it is included in the Request/Indication, it contains either all Extensible Teleservices subscribed (at location updating or at restoration) or the ones added (at subscriber data modification). Only the Extensible Teleservices that are relevant to the node at which the message is received should be included in the Teleservice List. If the VLR or the SGSN or the IWF receives an Indication containing any Extensible Teleservice parameters which it does not support/allocate it returns them in the response to the HLR and discards the unsupported Extensible Teleservices (no error is sent back). This parameter is used by the VLR and the SGSN and the IWF. This parameter shall not be used by the CSS. Forwarding information List A list of Extensible Forwarding information parameters (Extensible Forwarding information is defined in clauseÊ7.6). It includes Call Forwarding services either at location updating or at restoration or when they are changed. Each Extensible Forwarding information parameter shall be treated independently of all other parameters in the primitive. The Extensible Forwarding information shall include the SS-Code for an individual call forwarding supplementary service. The Extensible Forwarding information shall contain one or more Extensible Forwarding Features (Extensible Forwarding Feature is defined in clauseÊ7.6). The Extensible Forwarding Feature may include an Extensible Basic Service Group. This shall be interpreted according to the rules in clauseÊ8.8.1.4. The Extensible Forwarding Feature shall contain an Extensible SS-Status parameter. If the Extensible SS-Status indicates that call forwarding is registered then (except for call forwarding unconditional) the Extensible Forwarding Feature shall contain a number to define the forwarded-to destination and, if available, the forwarded-to subaddress. In other states the forwarded-to number and, if applicable, the forwarded-to subaddress shall not be included. For call forwarding unconditional the forwarded-to number and, if applicable, the forwarded-to subaddress shall not be included. If the VLR does not receive a forwarded-to subaddress then it shall assume that a forwarded-to subaddress has not been registered. The Extensible Forwarding Feature shall contain the extensible forwarding options (except for call forwarding unconditional where the extensible forwarding options shall not be included). Bits 3 and 4 of the extensible forwarding options shall be ignored by the VLR, and may be set to any value by the HLR. For call forwarding on no reply: If the extensible SS-Status indicates that call forwarding is registered then the Extensible Forwarding Feature shall contain an extensible no reply condition timer. In other states the no reply condition timer shall not be included. For call forwarding services other than call forwarding on no reply: The Extensible Forwarding Feature shall not contain a no reply condition timer. If the VLR receives an Indication containing any Call Forwarding service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and discards the unsupported Call Forwarding service codes (noÊerror is sent back). This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Call barring information List A list of Extensible Call barring information parameters (Extensible Call barring information is defined in clauseÊ7.6). It includes Call Barring services either at location updating or at restoration or when they are changed. Each Extensible Call barring information parameter shall be treated independently of all other parameters in the primitive. The Extensible Call barring information shall include the SS-Code for an individual call barring supplementary service. The Extensible Call barring information shall contain one or more Extensible Call Barring Features (Extensible Call Barring Feature is defined in clauseÊ7.6). The Extensible Call Barring Feature may include an Extensible Basic Service Group. This shall be interpreted according to the rules in clauseÊ8.8.1.4. The Extensible Call Barring Feature shall contain an extensible SS-Status parameter. If the VLR or the SGSN or the IWF receives an Indication containing any Extensible Call Barring service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and discards the unsupported Extensible Call Barring service codes (no error is sent back). This parameter shall not be used by the CSS. CUG information List A list of CUG information list parameters (CUG information is defined in clauseÊ7.6). It includes CUG information either at location updating or at restoration or when it is changed. At location updating, restoration or when there is a change in CUG data, the HLR shall include the complete CUG SubscriptionList and, if there are options per basic group, it shall also include the complete CUG-FeatureList. If there are not options per extensible basic service group the CUG-FeatureList shall not be included. In any dialogue, the first insertSubscriberData message which contains CUG information shall include a non-empty CUG-SubscriptionList. When the VLR receives CUG data it shall replace the stored CUG data with the received data set. If CUG-FeatureList is omitted in the Insert Subscriber Data operation VLR shall interpret that no options per extensible basic service group exist, and then it shall apply the default values i.e. no outgoing access, no incoming access, no preferential CUG exists. If CUG-Feature is received without preferential CUG, the VLR shall interpret that no preferential CUG applies. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. Note that data consistency between CUG subscription data and CUG feature data is the responsibility of the HLR. If the VLR does not support the CUG service it returns its code to the HLR in the parameter SS-Code List and discards the received information (no error is sent back). This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. SS-Data List A list of Extensible SS-Data parameters (Extensible SS-Data is defined in clauseÊ7.6). It is sent for any other supplementary service than Call Forwarding, Call Barring, CUG and eMLPP either at location updating or at restoration or when they are changed. Each SS-Data parameter shall be treated independently of all other parameters in the primitive. The Extensible SS-Data shall include the SS-Code for an individual supplementary service. The Extensible SS-Data shall contain an Extensible SS-Status parameter and any subscription options that are applicable to the service defined by the SS-Code. The SS-Data may include a Basic Service Group List. This shall be interpreted according to the rules in clauseÊ8.8.1.4. If the VLR receives an Indication containing any supplementary service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and therefore discards the unsupported service codes received (no error is sent back). This parameter is used by the SGSN only for LCS. If the SGSN receives an Indication containing any LCS related supplementary service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and therefore discards the unsupported service codes received (no error is sent back). SS-codes not related to the supported LCS capability set shall be discarded. If the IWF receives an Indication containing any LCS related supplementary service codes, it returns them to the HSS in the parameter SS-Code List and therefore discards the service codes received (no error is sent back). SS-codes not related to the supported LCS capability set shall be discarded. This parameter shall not be used by the CSS. Operator Determined Barring General data If it is included in a Request/Indication, it includes all the Operator Determined Barring categories that may be applied to a subscriber registered in any PLMN. This parameter is only included in a Request/Indication when the parameter Subscriber Status is set to the value Operator Determined Barring. Note that all General Operator Determined Barring Categories shall be set to their actual status. If the VLR or the SGSN or IWF receives an Indication containing Operator Determined Barring General Data which shows that the subscriber is subject to barring not supported / not allocated by the VLR or by the SGSN, it returns Operator Determined Barring General Data in the response to the HLR to show the barring categories which are not supported / not allocated by the VLR or by the SGSN. This parameter is used by the VLR and the SGSN and IWF. This parameter shall not be used by the CSS. Operator Determined Barring HPLMN data It includes all the Operator Determined Barring categories that may be applied only to a subscriber registered in the HPLMN. Therefore, it shall only be transferred to the VLR or to the SGSN or IWF when the subscriber is roaming into the HPLMN and when the parameter Subscriber Status is set to the value Operator Determined Barring. Note that all HPLMN Operator Determined Barring Categories shall be set to their actual status. If Subscriber Status is set to the value Operator Determined Barring and no Operator Determined Barring HPLMN data is present then the VLR or the SGSN or IWF shall not apply any HPLMN specific ODB services to the subscriber. This parameter is used by the VLR and the SGSN and IWF. This parameter shall not be used by the CSS. eMLPP Subscription Data If included in the Insert Subscriber Data request this parameter defines the priorities the subscriber might apply for a call (as defined in clause 7.6). It contains both subparameters of eMLPP. If the VLR does not support the eMLPP service it returns its code to the HLR in the parameter SS-Code List and therefore discards the received information (no error is sent back). eMLPP subscription data that have been stored previously in a subscriber data record in the VLR are completely replaced by the new eMLPP subscription data received in a MAP_INSERT_SUBSCRIBER_DATA during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. MC Subscription Data If included in the Insert Subscriber Data request, this parameter provides the MC Subscription Data as defined in clauseÊ7.6. If the VLR does not support the MC service, it returns its code to the HLR in the parameter SS-Code List and therefore discards the received information (no error is sent back). MC subscription data that have been stored previously in a subscriber data record in the VLR are completely replaced by the new MC subscription data received in a MAP_INSERT_SUBSCRIBER_DATA during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Roaming Restriction Due To Unsupported Feature The HLR may decide to include this parameter in the request if certain services or features are indicated as not supported by the MSC/VLR (e.g. Advice of Charge Charging Level). If this parameter is sent to the VLR the MSC area is restricted by the HLR and the VLR. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Regional Subscription Data If included in the Insert Subscriber Data request this parameter defines the subscriber's subscription area for the addressed VLR, for the addressed SGSN or for the addressed MME (as defined in clauseÊ7.6). It contains the complete list of up to 10 Zone Codes that apply to a subscriber in the currently visited PLMN. The HLR shall send only those Zone Codes which are stored against the CC and NDC of the VLR, the SGSN or the MME to be updated. NOTE 2: Support of this parameter is a network operator option and it will not be sent to networks which do not support Regional Subscription. Regional subscription data that have been stored previously in a subscriber data record in the VLR, in the SGSN or in the MME are completely replaced by the regional subscription data received in an Insert Subscriber Data indication during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. After the regional subscription data are inserted the VLR or the SGSN shall derive whether its location areas are allowed or not. If the whole MSC or SGSN area is restricted it will be reported to HLR by returning the Regional Subscription Response. The VLR or the SGSN returns a Regional Subscription Response indicating that a problem with the Zone Code has been detected in one of the following cases: - Too Many Zone Codes: more than 10 Zone Codes are to be stored in the VLR or in the SGSN. - Regional Subscription Not Supported by the VLR or the SGSN. - Zone Codes Conflict: the VLR or the SGSN detects that the zone codes indicate conflicting service permission for a location area. Zone codes which have no mapping to location areas shall be ignored. If a sequence of MAP_INSERT_SUBSCRIBER_DATA services is used during a dialogue, Regional Subscription Data shall be accepted only in one service. Regional Subscription Data received in a subsequent service shall be rejected with the error Unexpected Data Value. If Regional Subscription Data are not included in any MAP_INSERT_SUBSCRIBER_DATA service, there is no restriction of roaming due to Regional Subscription. This parameter is used by the VLR, the SGSN and the IWF. This parameter shall not be used by the CSS. Voice Broadcast Data This parameter contains a list of group id's a user might have subscribed to; (VBS-Data is defined in clause 7.6). It includes VBS information either at location updating or at restoration or when it is changed. At location updating, restoration or when there is a change in VBS data, the HLR shall include the complete VBS-Data. When the VLR receives VBS-Data within a dialogue it shall replace the stored VBS-data with the received data set. All subsequent VBS-data received within this dialogue shall be interpreted as add-on data. If VBS-data is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VBS data. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Voice Group Call Data This parameter contains a list of group id's a user might have subscribed to; see clause 7.6. At location updating, restoration or when there is a change in VGCS data, the HLR shall include the complete VGCS Data. When the VLR receives VGCS-Data within a dialogue it shall replace the stored VGCS-Data with the received data set. All VGCS-Data received within this dialogue shall be interpreted as add-on data. If VBCS-Data is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VGCS-Data. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. North American Equal Access preferred Carrier Id List A list of the preferred carrier identity codes that are subscribed to. When the VLR receives this parameter from the HLR, it shall replace the previously stored preferred carrier identity codes with the received ones. It is not possible to delete all the preferred carrier identity codes from the VLR using this service. To delete all the preferred carrier identity codes from the VLR, the HLR shall use the MAP_CANCEL_LOCATION service. This parameter shall not be used by the CSS. LSA Information If included in the ISD request, this parameter contains a list of localised service area identities a user might have subscribed to together with the priority, the preferential access indicator, the active mode support indicator and active mode indication of each localised service area; see clause 7.6. The access right outside these localised service areas is also indicated. In all cases mentioned below, the LSA information shall only include LSA Data applicable to the VPLMN where the Subscriber is located. The VLR number, received in the MAP-UPDATE_LOCATION primitive, or the SGSN number, received in the MAP_UPDATE_GPRS_LOCATION primitive, can be used, alongside data stored in the HLR, to determine the LSA Data applicable to the VPLMN. At restoration, location updating or GPRS location updating the HLR shall include the complete set of applicable LSA Information. When there is a change in LSA data the HLR shall include at least the new and/or modified LSA data. When there is a change in the access right outside the localised service areas the HLR shall include the LSA only access indicator. When the SGSN or the VLR receives LSA information within a dialogue it shall check if the received data has to be considered as the entire LSA information. If so, it shall replace the stored LSA information with the received data set, otherwise it shall replace the data only for the modified LSA data (if any) and/or access right, and add the new LSA data (if any) to the stored LSA Information. If the entire LSA information is received, it shall always include the LSA only access indicator value together with the LSA data applicable for the PLMN (if any). If LSA Information is omitted in the Insert Subscriber Data operation the SGSN or the VLR shall keep the previously stored LSA Information. If the SGSN or the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used by the VLR and the SGSN, and if the IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. IST Alert Timer This parameter contains the IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs. At Location Updating, restoration, or when there is a change in the IST data defined for the Subscriber, the HLR shall include the IST Alert timer. This parameter shall not be used by the CSS. LMU Identifier This parameter indicates the presence of an LMU. This parameter is used only by the VLR and shall be ignored if received by an SGSN or an IWF. This parameter shall not be used by the CSS. LCS Information This parameter provides the following LCS related information for an MS subscriber: - list of GMLCs in the HPLMN; - privacy exception list; - MO-LR list. At restoration and location updating, the HLR shall include the complete LCS data of the subscriber. When there is a change in LCS subscriber data the HLR shall include at least the new and/or modified LCS data. LCS data that is not modified need not be included. The VLR/SGSN shall keep any previously stored LCS Information that is not included in an Insert Subscriber Data operation. If the VLR/SGSN detects that there is overlapping in the LCS information received within a dialogue, it shall send the error Unexpected Data Value. However, if the VLR receives the LCS code in both the LCS Information and the SS Data List, then the VLR shall not interpret this as overlapping data. This parameter is used by the VLR and the SGSN and the IWF. This parameter shall not be used by the CSS. Super-Charger Supported In HLR This parameter is used by the HLR to indicate support for the Super-Charger functionality. If this parameter is present it shall include an indication of the age of the subscription data stored in the HLR. If this parameter is absent then the HLR does not support the Super-Charger functionality. This parameter shall not be used by the CSS. SS-Code List The list of SS-Code parameters for the services that are provided to a subscriber but are not supported/allocated by the VLR/SGSN/IWF (SS-Code is defined in clauseÊ7.6). The list can only include individual SS-Codes that were sent in the service request. For the VLR, this list can also include SS-Codes for the eMLPP and/or CUG services if the above mentioned conditions, as described in eMLPP Subscription Data and/or CUG information List, are met (that is, eMLPP Subscription Data and/or CUG information List are received). This parameter shall not be used by the CSS. ICS-Indicator This optional flag indicates to the MSC Server enhanced for ICS (see 3GPP TS 23.292 [135]) whether the MSC Server shall attempt the IMS registration. This parameter is used by the VLR and the SGSN. This parameter shall not be used by the CSS. CSG-Subscription Data This parameter contains a list of CSG-Ids, the associated expiration dates (see 3GPP TS 22.011 [138]) and a list of corresponding APNs (see 3GPP TS 29.272 [144]. When the VLR or SGSN or MME receives CSG-Subscription Data from the HLR/HSS it shall replace the stored CSG-Subscription Data from the HLR/HSS (if any) with the received data. This parameter is used by the VLR and the SGSN and IWF, except the list of corresponding APNs is not applicable to the VLR, and the VLR shall ignore this list if it is received. This parameter shall not be used by the CSS. VPLMN CSG Subscription Data This parameter contains a list of CSG-Ids, the associated expiration dates (see 3GPP TS 22.011 [138]). When the VLR or SGSN or MME receives VPLMN CSG Subscription Data from the CSS, it shall replace the stored VPLMN-CSG Subscription Data from the CSS (if any) with the received VPLMN CSG Subscription data. This parameter is used by the VLR, the SGSN and MME. This parameter is not applicable for the HLR/HSS, and the VLR or SGSN or IWF shall ignore this parameter if it is received from the HLR/HSS. CSG Subscription Data from the HLR/HSS and VPLMN CSG Subscription Data from the CSS are managed independently in the VLR or SGSN or MME. If the same CSG Id exists in both CSG subscription data from the CSS and CSG subscription data from the HLR/HSS, the CSG subscription data from the HLR/HSS shall take precedence over the CSG subscription data from the CSS in further use. UE Reachability Request Indicator This parameter indicates by its presence that the HSS is awaiting a Notification of UE Reachability. This parameter is used by the IWF only. This parameter shall not be used by the CSS. MME Name This parameter contains the MME identity used over the SGs interface (see 3GPP TS 23.003 [17] clause 19.4.2.4) when stored in the HSS. Otherwise this parameter contains the Diameter Identity of the MME (see 3GPP TS 23.003 [17]). If the subscriber is registered to EPS and the length of the MME Name does not exceed 55 octets, the HLR shall send the MME Name to the VLR during the data restoration procedure if the 'Restoration Indicator' is set in the MAP_RESTORE_DATA request, and during an Update Location procedure if the 'Restoration Indicator' is set in the MAP_UPDATE_LOCATION request. This parameter may be used by the MSC/VLR, e.g. to page the UE via SGs. This parameter shall not be used by the CSS. Subscribed Periodic RAU-TAU Timer This parameter contains the subscribed periodic RAU/TAU timer (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]) and is used by the SGSN and MME (via IWF). The SGSN and MME shall handle the Subscribed Periodic RAU-TAU Timer as specified in clause 5.2.1.1.2 of 3GPP TS 29.272 [144]. If the VLR receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Subscribed Periodic LAU Timer This parameter contains the subscribed periodic LAU timer value (see 3GPP TS 23.012 [23]) and is used by the MSC/VLR. The MSC/VLR shall handle the Subscribed Periodic LAU Timer as specified in clause 3.7.3 of 3GPP TS 23.012 [23]. If the SGSN receives this parameter it shall ignore it. This parameter shall not be used by the CSS. SGSN Number This parameter contains the Identity of the SGSN (see 3GPP TS 23.003 [17])."
"If the subscriber is registered to GPRS, the HLR shall send the SGSN Number if available to the VLR during the data restoration procedure if the 'Restoration Indicator' is set in the MAP_RESTORE_DATA request, and during an Update Location procedure if the 'Restoration Indicator' is set in the MAP_UPDATE_LOCATION request. This parameter may be used by the MSC/VLR, e.g. to page the UE via Gs. This parameter shall not be used by the CSS. MDT User Consent This parameter indicates the user consent availability for MDT activation, see 3GPP TS 32.422 [132]. This parameter is used by the VLR, the SGSN and the IWF. This parameter shall not be used by the CSS. PS and SMS-only Service Provision This parameter indicates whether the subscription is for PS Only and permits CS service access only for SMS. SMS in SGSN Allowed This parameter indicates whether the HSS allows SMS to be provided by SGSN over NAS. User Plane Integrity Protection Indicator This parameter indicates by its presence that the SGSN may decide to activate integrity protection of the user plane when GERAN is used (see 3GPP TS 43.020 [24]). If the VLR receives this parameter it shall ignore it. DL-Buffering Suggested Packet Count This parameter indicates a suggested DL-Buffering Packet Count. The MME (via IWF) and SGSN may take it into account in addition to local policies, to determine whether to invoke extended buffering of downlink packets at the SGW for High Latency Communication. Otherwise, the MME or SGSN shall make this determination based on local policies only (see 3GPP TS 29.272 [144]). If the VLR receives this parameter it shall ignore it. Reset-IDs This parameter contains a list of subscribed Reset-IDs. eDRX-Cycle-Length List This list shall contain the subscribed eDRX cycle length, along with the RAT type to which it is applicable. IAB-Operation-Allowed-Indicator This parameter indicates by its presence that IAB operation is authorized for the UE. See 3GPPÊTSÊ401Ê[145]. Regional Subscription Response If included in the response this parameter indicates one of: - Network Node Area Restricted entirely because of regional subscription; - Too Many Zone Codes to be inserted; - Zone Codes Conflict; - Regional Subscription not Supported by the VLR or by the SGSN or MME. If the VLR determines after insertion of Regional Subscription Data that the entire MSC area is restricted, the VLR shall respond with a Regional Subscription Response indicating MSC Area Restricted. Otherwise MSC Area Restricted is not sent. The HLR shall check whether the current MSC area is no longer restricted. If the SGSN determines after insertion of Regional Subscription Data that the entire SGSN area is restricted, the SGSN shall respond with a Regional Subscription Response indicating SGSN Area Restricted. Otherwise SGSN Area Restricted is not sent. The HLR shall check whether the current SGSN area is no longer restricted. This parameter is used by the VLR, the SGSN and the IWF. This parameter shall not be used by the CSS. VLR CAMEL Subscription Info This parameter is sent for subscribers who have CAMEL services which are invoked in the MSC. - In CAMEL phase 1, this parameter contains only the O-CSI. - In CAMEL Phase 2, this parameter may contain O-CSI, SS-CSI and TIF-CSI. In CAMEL Phase 2 and onwards, TDP-Criteria for O-CSI may be associated with O-CSI. - In CAMEL Phase 3, this parameter may contain O-CSI, D-CSI, SS-CSI, VT-CSI, MO-SMS-CSI, M-CSI and TIF-CSI. In CAMEL Phase 3 and onwards, TDP-Criteria for VT-CSI may be associated with VT-CSI. - In CAMEL Phase 4, this parameter may contain O-CSI, D-CSI, SS-CSI, VT-CSI, MO-SMS-CSI, MT-SMS-CSI, M-CSI and TIF-CSI. In CAMEL Phase 4, TDP-Criteria for MT-SMS-CSI may be associated with MT-SMS-CSI. The VLR CAMEL Subscription Info is sent at location updating or when any information in the applicable CAMEL Subscription Info in the HLR has been changed. At location updating, the complete set of VLR CAMEL Subscription Info is sent in one dialogue. When CAMEL Subscription Information is changed in the HLR and changed data have to be sent to the VLR, then: - for CAMEL Phase 1 and CAMEL Phase 2, the complete set of VLR CAMEL Subscription Info is sent in one dialogue; - for CAMEL Phase 3 or higher, one or more specific elements of VLR CAMEL Subscription Info are sent in one dialogue. When the VLR receives a specific element of VLR CAMEL Subscription Info, it shall overwrite the corresponding specific element of VLR CAMEL Subscription Info (if any) which it has stored for that subscriber. For CAMEL Phase 1 and CAMEL Phase 2 , the VLR CAMEL Subscription Info consists of any one or more of: - O-CSI (irrespective of the value of the ""CAMEL Capability Handling"" inside O-CSI),TDP-Criteria for O-CSI,SS-CSI and TIF-CSI. (The complete set of above shall be sent even if only one CSI has changed in case of stand alone ISD. The omitted elements of above list will be withdrawn in the VLR.) From CAMEL phase 3 onwards, the specific elements of VLR CAMEL Subscription Info which may be sent are: O-CSI (irrespective of the value of the ""CAMEL Capability Handling"" inside O-CSI), TDP criteria for O-CSI, SS-CSI and TIF-CSI; (The complete set of above shall be sent even if only one CSI has changed in case of stand alone ISD. The omitted elements of above list will be withdrawn in the VLR.) - D-CSI; - VT-CSI; - TDP-Criteria for VT-CSI; - MO-SMS-CSI; - MT-SMS-CSI; - TDP-Criteria for MT-SMS-CSI; - M-CSI. If the VLR CAMEL Subscription Info is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VLR CAMEL Subscription Info. Within one dialogue subsequent received data are interpreted as add-on data. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. The VLR CAMEL Subscription Info may contain the TIF-CSI (Translation Information Flag) for CAMEL Phase 2 and higher. See 3GPP TS 23.072 for the use of this parameter and the conditions for its presence. This parameter shall not be used by the CSS. Supported CAMEL Phases The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. This parameter is used by the VLR and SGSN. A VLR or SGSN not supporting any CAMEL Phase may omit this parameter. An IWF shall omit this parameter. This parameter shall not be used by the CSS. GPRS Subscription Data This parameter contains a list of PDP-contexts a user has subscribed to; see clause 7.6. At GPRS location updating the HLR shall include the complete GPRS Subscription Data. When there is a change in GPRS subscriber data the HLR shall include only the new and/or modified PDP contexts. When the SGSN receives GPRS Subscription Data within a dialogue it shall check if the received data has to be considered as the entire GPRS subscription data. If so, it shall replace the stored GPRS Subscription Data with the received data set, otherwise it shall replace the data only for the modified PDP contexts (if any) and add the new PDP contexts (if any) to the stored GPRS Subscription Data. If GPRS Subscription Data is omitted in the Insert Subscriber Data operation the SGSN shall keep the previously stored GPRS Subscription Data. If the SGSN detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it. The SGSN shall handle the SIPTO-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the SIPTO-Local-Network-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the LIPA Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the Restoration-Priority information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. This parameter shall not be used by the CSS. EPS Subscription Data This parameter contains: - the UE level APN-OI Replacement (see 3GPP TS 23.401 [145]), and - the Subscriber Profile ID for RAT/Frequency Priority (RFSP-ID) (see 3GPP TS 23.401 [145], 3GPP TS 36.413 [147] and 3GPP TS 23.060 [104]), and - the AMBR (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]), and - a list of APN Configurations, - a session transfer number for SRVCC (STN-SR) (see 3GPP TS 23.003 [17]). - MPS CS Priority, which by its presence indicates the UE is subscribed to the eMLPP in the CS domain. - MPS EPS Priority, which by its presence indicates the UE is subscribed to the MPS in the EPS domain. - Subscribed vSRVCC (see 3GPP 29.272 [144]). This parameter is used only by the MME via IWF and SGSN. If the VLR receives this parameter it shall ignore it. The MPS CS Priority and MPS EPS Priority inside the parameter are used only by the MME via IWF. If the SGSN receives them it shall ignore them. The SGSN shall handle the SIPTO-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the SIPTO-Local-Network-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the LIPA Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the Restoration-Priority information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the WLAN-offloadability information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. This parameter shall not be used by the CSS. VPLMN LIPA Allowed This parameter by its presence indicates that the UE is allowed to use LIPA in the PLMN where the UE is attached (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]). This parameter is used only by the IWF and SGSN. If the VLR receives this parameter it shall ignore it. This parameter shall not be used by the CSS. SGSN CAMEL Subscription Info The SGSN CAMEL Subscription Info is sent at GPRS location updating or when any information in the applicable SGSN CAMEL Subscription Info in the HLR has been changed. - In CAMEL Phase 3, this parameter may contain one or both of GPRS-CSI and MO-SMS-CSI. - In CAMEL Phase 4, this parameter may contain GPRS-CSI, MO-SMS-CSI and MT-SMS-CSI and TDP-Criteria for MT-SMS-CSI. At GPRS location updating the complete set of SGSN CAMEL Subscription Info is sent. When CAMEL Subscription Information is changed in the HLR and changed data have to be sent to the SGSN, then one or more specific elements of SGSN CAMEL Subscription Info are sent in one dialogue. When the SGSN receives a specific element of SGSN CAMEL Subscription Info, it shall overwrite the corresponding specific element of SGSN CAMEL Subscription Info (if any) which it has stored for that subscriber. The specific elements of SGSN CAMEL Subscription Info which may be sent are: - MO-SMS-CSI; - MT-SMS-CSI; - TDP-Criteria for MT-SMS-CSI; - GPRS-CSI; - MC-CSI. This parameter is used only by the SGSN and if the VLR or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Roaming Restricted In SGSN/MME Due To Unsupported Feature The HSS/HLR may decide to include this parameter in the request if certain services or features are indicated as not supported by the SGSN/IWF. This parameter is used only by the SGSN and IWFand if the VLR receives this parameter it shall ignore it. This parameter shall not be used by the CSS. CS Allocation/Retention priority The CS Allocation/Retention priority is used only for Circuit Switched (CS). This parameter specifies relative importance to compare with other bearers about allocation and retention of bearer. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR or SGSN (see clause 7.6.3.36D). An IWF shall omit this parameter. This parameter shall not be used by the CSS. Subscribed Charging Characteristics This parameter refers to the Subscribed Charging Characteristics as defined in 3GPP TS 32.251. For a detailed description of the use of the parameter, see 3GPP TS 32.251. This parameter is used only by the SGSN and IWF and if the VLR receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Access Restriction Data This parameter indicates the allowed RAT for the PLMN where the UE is attached according to subscription data. (see clause 7.6.3.97) If the VLR/SGSN/MME supports the Access Restriction feature but does not receive the Access Restriction Data parameter from the HSS/HLR at location updating or restoration, the VLR/SGSN/MME shall assume that the subscriber's profile does not have any restrictions enabled. For a detailed description of the use of the parameter, see 3GPP TS 23.012 [23] for the CS domain and 3GPP TS 23.060[104], 3GPP TS 29.060 [105] clause 7.5.3 and 3GPP TS 29.274 [149] clause 7.3.6 for the PS domain. This parameter shall not be used by the CSS. Supported Features This parameter shall be used by an IWF to forward feature support indications as received from the MME or SGSN via S6a/S6d. This parameter shall not be used by the CSS. CS-to-PS-SRVCC-Allowed-Indicator This parameter indicates by its presence to the MSC Server enhanced for ICS (see 3GPP TS 23.292 [135]) that CS to PS SRVCC is subscribed. This parameter is used by the VLR. P-CSCF Restoration Request This parameter indicates by its presence that the HSS requests to the SGSN or the MME (via the IWF) the execution of the HSS-based P-CSCF restoration procedures, as described in 3GPP TS 23.380 [150], clause 5.4. This parameter shall not be used by the CSS. Adjacent Access Restriction Data This parameter indicates the allowed RAT in each one of the indicated PLMN IDs, according to subscription data. This parameter shall not be used by the CSS. IMSI-Group-Id List A list of IMSI-Group-Id parameters each of which identifies an IMSI-Group the subscriber belongs to. UE Usage Type This parameter indicates the usage characteristics of the UE that enables the selection of a specific Dedicated Core Network . It shall not be sent to VLRs and shall not be sent to SGSNs that did not indicate support of the Dedicated Core Network functionality within GPRS-Location Update. When the Insert-Subscriber-Data operation is used within an Update-GPRS-Location Dialogue, the HLR shall include this parameter if the SGSN indicated support of the Dedicated Core Network functionality and a UE Usage Type is available in the subscription data of the user. Outside the Update-Gprs-Location Dialogue the HLR shall include this parameter towards the SGSN that supports the Dedicated Core Network functionality if the value changed. User error Only one of the following values is applicable: - Unidentified subscriber; - Data missing; - Unexpected data value. 8.8.1.4 Basic service information related to supplementary services A number of parameters that relate to supplementary services can be qualified by a Basic Service Group (or a Basic Service Group List). This clauseÊexplains how this information is to be interpreted. Supplementary service parameters to which this clauseÊis applicable only apply to the basic service groups described in this clause, and only those basic service groups shall be overwritten at the VLR or the SGSN. The Basic Service Group (or Basic Service Group List) is optional. If present the Basic Service Group (or each element of the Basic Service Group List) shall be one of: - an Elementary Basic Service Group for which the supplementary service is applicable to at least one basic service in the group and for which the subscriber has a subscription to at least one basic service in the group; - the group ""All Teleservices"" provided that the service is applicable to at least one teleservice and that the subscriber has a subscription to at least one teleservice which is in the same Elementary Basic Service Group as a teleservice to which the service is applicable; - the group ""All Bearer Services"" provided that the service is applicable to at least one bearer service and that the subscriber has a subscription to at least one bearer service which is in the same Elementary Basic Service Group as a basic service to which the service is applicable. If the Basic Service Group (or Basic Service Group List) is not present then the parameter shall apply to all Basic Service Groups. If the basic service information is not a single Elementary Basic Service Group then the parameter shall be taken as applying individually to all the Elementary Basic Service Groups for which: - the supplementary service is applicable to at least one basic service in the Basic Service Group; and - the subscriber has a subscription to at least one basic service in the Basic Service Group. The VLR and the SGSN are not required to store supplementary services data for Basic Service Groups which are not supported at the VLR or the SGSN respectively. 8.8.2 MAP-DELETE-SUBSCRIBER-DATA service 8.8.2.1 Definition This service is used by an HLR to remove certain subscriber data from a VLR or SGSN if the subscription of one or more supplementary services or basic services is withdrawn. Note that this service is not used in case of erasure or deactivation of supplementary services. This service is also used by an HLR to remove GPRS subscription data from an SGSN. This service is also used by an HSS via IWF to remove EPS subscription data from an MME. This service is also used by a CSS to remove the CSG subscription data from an MME via IWF or a VLR/SGSN. It is a confirmed service and consists of the primitives shown in tableÊ8.8/2. 8.8.2.2 Service primitives TableÊ8.8/2: MAP-DELETE-SUBSCRIBER-DATA Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) Basic service List C C(=) SS-Code List C C(=) Roaming Restriction Due To Unsupported Feature C C(=) Camel Subscription Info Withdraw C C(=) Specific CSI Withdraw C C(=) Regional Subscription Data C C(=) VBS Group Indication C C(=) VGCS Group Indication C C(=) GPRS Subscription Data Withdraw C C(=) EPS Subscription Data Withdraw C C(=) Roaming Restricted In SGSN/MME Due To Unsupported Feature C C(=) LSA Information Withdraw C C(=) IST Information Withdraw C C(=) Regional Subscription Response C C(=) GMLC List Withdraw C C(=) Subscribed Charging Characteristics Withdraw C C(=) CSG Information Deleted C C(=) VPLMN CSG Information Deleted C C(=) APN-OI-Replacement Withdraw C C(=) STN-SR Withdraw C C(=) Subscribed vSRVCC Withdraw C C(=) Subscribed Periodic RAU-TAU Timer Withdraw C C(=) Subscribed Periodic LAU Timer Withdraw C C(=) Additional MSISDN Withdraw C C(=) CS-to-PS-SRVCC Withdraw C C(=) User Plane Integrity Protection Withdraw C C(=) DL-Buffering Suggested Packet Count Withdraw C C(=) UE-Usage-Type Withdraw C C(=) Reset-IDs Withdraw C C(=) IAB-Operation-Withdraw C C(=) User error C C(=) Provider error O 8.8.2.3 Parameter use All parameters are described in clauseÊ7.6. The following clarifications are applicable: Basic service List A list of Extensible Basic service parameters (Extensible Basic service is defined in clauseÊ7.6). It is used when one, several or all basic services are to be withdrawn from the subscriber. If the VLR or the SGSN receives a value for an Extensible Basic Service which it does not support, it shall ignore that value. This parameter is used by the VLR and by the SGSN; if the IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. SS-Code List A list of SS-Code parameters (SS-Code is defined in clauseÊ7.6). It is used when several or all supplementary services are to be withdrawn from the subscriber. There are three possible options: - deletion of basic service(s); The parameter Basic service List is only included. - deletion of supplementary service(s); The parameter SS-Code List is only included. - deletion of basic and supplementary services; Both Basic service List and SS-Code List are included. This parameter is used by the VLR and SGSN and IWF for Call Barring and LCS. Otherwise, this parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Roaming Restriction Due To Unsupported Feature This parameter is used if Roaming Restriction Due To Unsupported Feature is deleted from the subscriber data. This may occur if unsupported features or services are removed from the subscriber data in the HLR. If this parameter is sent the VLR shall check if the current Location Area is possibly allowed now. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. CAMEL Subscription Info Withdraw This parameter is used to indicate that CAMEL Subscription Info shall be deleted from the VLR or from the SGSN. All CAMEL Subscription Info for the subscriber shall be deleted. This parameter is used by the VLR and by the SGSN. This parameter should not be sent in the same message as the Specific CSI Withdraw parameter; if the IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Specific CSI Withdraw This parameter is used to indicate that one or more specific elements of CAMEL Subscription Info shall be deleted from the VLR or from the SGSN. The specific elements of CAMEL Subscription Info which may be withdrawn are: - O-CSI with TDP criteria for O-CSI; - SS-CSI; - TIF-CSI; - D-CSI; - VT-CSI with TDP criteria for VT-CSI; - MO-SMS-CSI; - MT-SMS-CSI with TDP-Criteria for MT-SMS-CSI; - M-CSI; - MG-CSI; - GPRS-CSI. This parameter is used by the VLR and by the SGSN; if the IWF receices this parameter it shall ignore it. It shall not be sent to VLRs that do not support CAMEL phase 3 or higher. This parameter should not be sent in the same message as the CAMEL Subscription Info Withdraw parameter. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Regional Subscription Identifier Contains one single Zone Code (as defined in clauseÊ7.6) and is used if all Zone Codes shall be deleted from the subscriber data. When all the Zone Codes are deleted, the VLR, the SGSN or the MME shall check for its location areas whether they are allowed or not. If the whole Network Node area is restricted, the VLR, the SGSN or the MME (via the IWF) will report it to HLR by returning the Regional Subscription Response ""Network Node Area Restricted"". The binary coding of the Zone Code value received in a Delete Subscriber Data request shall not be checked by the VLR, the SGSN or the MME. Note that support of this parameter is a network operator option and it shall not be sent to networks which do not support Regional Subscription. If Regional Subscription is not supported by the VLR, the SGSN or the MME, the request for deletion of Zone Codes is refused by sending the Regional Subscription Response ""Regional Subscription Not Supported"" to the HLR. If no Zone Codes are stored in the respective subscriber data record, the request for deleting all Zone Code information shall be ignored and no Regional Subscription Response shall be returned. This parameter is used by the VLR, the SGSN and the MME. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. VBS Group Indication Contains an indication (flag) which is used if all Group Ids shall be deleted from the subscriber data for the Voice Broadcast teleservice. If VBS is not supported in the VLR or no Group Ids are stored for VBS in the respective subscriber record, the request for deletion of all Group Ids shall be ignored. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. VGCS Group Indication Contains an indication (flag) which is used if all Group Id's shall be deleted from the subscriber data for the Voice Group Call teleservice. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it. If VGCS is not supported in the VLR or no Group Ids are stored for VGCS in the respective subscriber record, the request for deletion of all Group Ids shall be ignored. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. GPRS Subscription Data Withdraw This parameter is used to indicate whether all GPRS Subscription Data for the subscriber shall be deleted or if only a subset of the stored GPRS Subscription Data for the subscriber shall be deleted. In the latter case only those PDP contexts whose identifiers are included in the subsequent identifier list will be deleted. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. EPS Subscription Data Withdraw This parameter is used to indicate whether all EPS Subscription Data for the subscriber shall be deleted or if only a subset of the stored EPS Subscription Data for the subscriber shall be deleted. In the latter case, only those APN Configurations whose identifiers are included in the subsequent identifier list will be deleted. This parameter is used only by the SGSN and the MME and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Roaming Restricted In SGSN/MME Due To Unsupported Feature This parameter is used if Roaming Restricted In SGSN/MME Due To Unsupported Feature is deleted from the GPRS/EPS subscriber data. This may occur if unsupported features or services are removed from the GPRS/EPS subscriber data in the HLR. If this parameter is sent the SGSN shall check if the current Location Area is possibly allowed now. This parameter is used only by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. LSA Information Withdraw This parameter is used to indicate whether all LSA Information for the subscriber shall be deleted or if only a subset of the stored LSA Information for the subscriber shall be deleted. In the latter case only the LSA data whose LSA identities are included in the subsequent LSA data list will be deleted. This parameter is used by the VLR and the SGSN. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. IST Information Withdraw This parameter is used to indicate that the IST condition has been removed for the subscriber. See 3GPP TS 43.035 for the use of this parameter. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Regional Subscription Response If included in the Delete Subscriber Data response this parameter indicates one of: - Network Node Area Restricted; - Regional Subscription Not Supported. This parameter is used by the VLR, the SGSN and the IWF. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. GMLC List Withdraw This parameter indicates that the subscriber's LCS GMLC List shall be deleted from the VLR or SGSN. This parameter is used by the VLR and the SGSN and IWF. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Subscribed Charging Characteristics Withdraw This parameter indicates that the Subscribed Charging Characteristics shall be replaced with a local default value in the SGSN or in the MME (see 3GPP TS 32.251). This parameter is used only by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. CSG Information Deleted This parameter indicates that CSG Subscription Information received from the HLR/HSS shall be deleted from VLR, SGSN, or MME. This parameter is used by the VLR, SGSN and the IWF. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. VPLMN CSG Information Deleted This parameter indicates that CSG Subscription Information received from the CSS shall be deleted from VLR, SGSN. This parameter is used by the VLR and SGSN. This parameter is not applicable for the HLR/HSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the HLR/HSS. APN-OI-Replacement Withdraw This parameter indicates that APN-OI-Replacement shall be deleted from the SGSN or the MME. This parameter is used by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. STN-SR Withdraw This parameter indicates that STN-SR shall be deleted from the SGSN or the MME. This parameter is used by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Subscribed vSRVCC Withdraw This parameter indicates that Subscribed vSRVCC shall be deleted from the MME. This parameter is used by the MME and the IWF and if the SGSN or VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Subscribed Periodic RAU-TAU Timer Withdraw This parameter indicates that Subscribed Periodic RAU-TAU Timer value shall be deleted from the SGSN or the MME. This parameter is used by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Subscribed Periodic LAU Timer Withdraw This parameter indicates that Subscribed Periodic LAU Timer value shall be deleted from the VLR. This parameter is used by the VLR and if the MME or SGSN receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Additional MSISDN Withdraw This parameter indicates that Additional MSISDN shall be deleted from the SGSN or MME. This parameter is used by the SGSN and the IWF. CS-to-PS-SRVCC Withdraw This parameter indicates by its presence that CS to PS SRVCC is no longer subscribed. User Plane Integrity Protection Withdraw This parameter indicates by its presence that User Plane Integrity Protection may no longer be required. DL-Buffering Suggested Packet Count Withdraw This parameter indicates by its presence that a suggested DL-Buffering Packet Count is no longer subscribed. UE-Usage-Type Withdraw This parameter indicates by its presence that a UE-Usage-Type is no longer subscribed. This parameter is not applicable for VLRs. The HLR shall include this parameter towards the SGSN or MME (via IWF) that supports the Dedicated Core Network functionality if the subscription to a UE-Usage-Type is removed. Reset-IDs Withdraw This parameter indicates by its presence that Reset-IDs are no longer subscribed. IAB-Operation-Withdraw This parameter indicates by its presence that IAB operation is no longer authorized for the UE. User error Only one of the following values is applicable: - Unidentified subscriber; - Data missing; - Unexpected data value. 8.9 Identity management services 8.9.1 MAP-PROVIDE-IMSI service 8.9.1.1 Definition This service is used by a VLR in order to get, via the MSC, the IMSI of a subscriber (e.g. when a subscriber has identified itself with a TMSI not allocated to any subscriber in the VLR). It is a confirmed service and consists of the primitives shown in tableÊ8.9/1. 8.9.1.2 Service primitives TableÊ8.9/1: MAP-PROVIDE-IMSI Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI C C(=) User error C C(=) Provider error O 8.9.1.3 Parameter use All parameters are described in clauseÊ7.6. The following clarifications are applicable: IMSI This parameter is received when the request is successfully carried out. It contains the requested IMSI. User error Only one of the following values is applicable: - Absent subscriber. 8.9.2 MAP-FORWARD-NEW-TMSI service 8.9.2.1 Definition This service is used by a VLR to allocate, via MSC, a new TMSI to a subscriber during an ongoing transaction (e.g. call set-up, location updating or supplementary services operation). It is a confirmed service and consists of the primitives shown in tableÊ8.9/2. 8.9.2.2 Service primitives TableÊ8.9/2: MAP-FORWARD-NEW-TMSI Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) TMSI M M(=) Provider error O 8.9.2.3 Parameter use The parameter TMSI is described in clauseÊ7.6. 8.10 Fault recovery services 8.10.1 MAP_RESET service 8.10.1.1 Definition This service is used by the HSS/HLR or CSS, after a restart, to indicate to a list of VLRs, SGSNs or MMEs (via IWF) that a failure occurred. This service may also be used by the HSS/HLR as part of operation and maintenance actions e.g. to allow planned HLR/HSS outage without service interruption, or to update subscription data shared by multiple subscribers. The MAP_RESET service is a non-confirmed service using the service primitives defined in tableÊ8.10/1. 8.10.1.2 Service primitives TableÊ8.10/1: MAP_RESET Parameter name Request Indication Invoke Id M M(=) Sending Node Number M M(=) HLR Id LIST U C(=) Reset-ID LIST C C(=) Subscription Data C C(=) Subscription Data Deletion C C(=) 8.10.1.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. SendingNode Number For a restart of the HLR/HSS, this parameter shall contain the HLR number. See definition in clauseÊ7.6.2. For a restart of the CSS, this parameter shall contain the CSS number. See definition in clause 7.6.2. HLR Id LIST The HLR Id List is a list of HLR Ids. If the parameter is present in the indication, the VLR, the SGSN or the MME may base the retrieval of subscribers to be restored on their IMSI: the subscribers affected by the reset are those whose IMSI leading digits are equal to one of these numbers. If the parameter and the Reset-ID List is absent, subscribers to be restored are those for which the OriginatingEntityNumber received at location updating time matches the equivalent parameter of the Reset Indication. This parameter shall only be applicable for a restart of the HLR/HSS. It shall not be present if Reset-ID LIST is present. Reset-ID LIST The Reset-ID LIST is a list of Reset-IDs. It shall not be present if Reset-IDs are not supported by the HLR/HSS and by theVLR or SGSN or MME (via IWF). If the parameter is present in the indication, the VLR, the SGSN or the MME may base the retrieval of affected subscribers (i.e. those impacted by the restoration or by the shared data update) on their subscribed Reset-IDs: The subscribers affected by the reset are those whose subscription contains at least one of these Reset-IDs."
"Subscription Data If the Reset Procedure is used to add/ modify subscription data shared by multiple subscribers, this Information Element shall contain the part of the subscription profile that either is to be added to the subscription profile stored in the VLR, MME or SGSN or combined MME/SGSN or is replacing a part of the subscription profiles of the impacted subscribers stored in the VLR, MME or SGSN. Shall be absent if Subsciption Data Deletion is present. Shall be absent if Reset-ID LIST is absent Subscription Data Deletion If the Reset Procedure is used to delete subscription data shared by multiple subscribers, this Information Element shall contain the identifications of the part of the subscription profile that is to be deleted from the subscription profiles of the impacted subscribers stored in the VLR, MME or SGSN. Shall be absent if Subsciption Data is present. Shall be absent if Reset-ID LIST is absent 8.10.2 MAP_FORWARD_CHECK_SS_INDICATION service 8.10.2.1 Definition This service may be used by an HLR as an implementation option, to indicate to a mobile subscriber that supplementary services parameters may have been altered, e.g. due to a restart. If received from the HLR, the VLR shall forward this indication to the MSC, which in turn forwards it to the MS. The HLR only sends this indication after successful completion of the subscriber data retrieval from HLR to VLR that ran embedded in a MAP_UPDATE_LOCATION procedure. The MAP_FORWARD_CHECK_SS_INDICATION service is a non-confirmed service using the service primitives defined in tableÊ8.10/2. 8.10.2.2 Service primitives TableÊ8.10/2: MAP_FORWARD_CHECK_SS_INDICATION Parameter name Request Indication Invoke Id M M(=) 8.10.2.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. 8.10.3 MAP_RESTORE_DATA service 8.10.3.1 Definition This service is invoked by the VLR on receipt of a MAP_PROVIDE_ROAMING_NUMBER indication for an unknown IMSI, or for a known IMSI with the indicator "" Subscriber Data Confirmed by HLR"" set to ""Not confirmed"". The service is used to update the LMSI in the HLR, if provided, and to request the HLR to send all data to the VLR that are to be stored in the subscriber's IMSI record. This service may be invoked by the VLR on receipt of a ""MAP-MT-FORWARD-SHORT-MESSAGE"" message for an unknown IMSI, or for a known IMSI with the indicator ""Subscriber Data Confirmed by HLR"" set to ""Not confirmed"". The service is used to update the LMSI in the HLR, if provided, and to request the HLR to send all data to the VLR that are to be stored in the subscriber's IMSI record. The HLR shall return the error ""system failure"" to the VLR if the subscriber is not registered on the VLR. The MAP_RESTORE_DATA service is a confirmed service using the service primitives defined in tableÊ8.10/3. 8.10.3.2 Service primitives TableÊ8.10/3: MAP_RESTORE_DATA Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) LMSI U C(=) Supported CAMEL phases C C(=) SoLSA Support Indicator C C(=) IST Support Indicator C C(=) Super-Charger Supported in Serving Network Entity C C(=) Long FTN Supported C C(=) Supported LCS Capability Sets C C(=) Offered CAMEL 4 CSIs C C(=) Restoration Indicator U C(=) Supported RAT Types Indicator U C(=) MTRF Supported U C(=) MSISDN-less Operation Supported C C(=) HLR number C C(=) MS Not Reachable Flag C C(=) User error C C(=) Provider error O 8.10.3.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. LMSI See definition in clauseÊ7.6.2. It is an operator option to provide the LMSI from the VLR; it is mandatory for the HLR to support the LMSI handling procedures. Supported CAMEL Phases This parameter indicates which phases of CAMEL are supported. Must be present if a CAMEL phase different from phase 1 is supported. Otherwise may be absent. SoLSA Support Indicator This parameter is used by the VLR to indicate to the HLR in the Restore Data indication that SoLSA is supported. If this parameter is not included in the Restore Data indication then the HLR shall not perform any specific error handling. This SoLSA Support Indicator shall be stored by the HLR per VLR where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a VLR and no SoLSA Support indicator is stored for that VLR, the location status of that Subscriber shall be set to Restricted. IST Support Indicator This parameter is used to indicate to the HLR that the VMSC supports basic IST functionality, that is, the VMSC is able to terminate the Subscriber Call Activity that originated the IST Alert when it receives the IST alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Restore Data indication and the Subscriber is marked as an IST Subscriber, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Outgoing calls), or allow service assuming the associated risk of not having the basic IST mechanism available. This parameter can also indicate that the VMSC supports the IST Command service, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Restore Data indication and the HLR supports the IST Command capability, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Outgoing calls), or allow service assuming the associated risk of not having the IST Command mechanism available. Long FTN Supported This parameter indicates that the VLR supports Long Forwarded-to Numbers. Super-Charger Supported in Serving Network Entity This parameter is used by the VLR to indicate to the HLR that the VLR supports the Super-Charger functionality and that subscriber data is required. If this parameter is absent then the VLR does not support the Super-Charger functionality. Supported LCS Capability Sets This parameter indicates, if present, the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the VLR does not support LCS at all. If this parameter is absent then the VLR may support at most LCS capability set 1, that is LCS Release98 or Release99 version. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR (see clause 7.6.3.36D). Restoration Indicator This parameter indicates, if present, that the HLR shall send in the MAP-INSERT-SUBSCRIBER-DATA the MME Name if the subscriber is registered to EPS, or the SGSN Number if available and if the subscriber is registered to GPRS. The VLR may set this indicator if it supports Gs or SGs interfaces. Supported RAT Types Indicator This parameter indicates, if present, which access technologies (e.g. GERAN and / or UTRAN) are served by the MSC/VLR (see clause 7.6.3) MTRF Supported See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. MSISDN-less Operation Supported See clause 3.6.1.5 of 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. HLR number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory in case of successful outcome of the service. MS Not Reachable Flag See definition in clauseÊ7.6.8. This parameter shall be present in case of successful outcome of the service, if the ""MS Not Reachable flag"" was set in the HLR. User error In case of unsuccessful outcome of the service, an error cause shall be returned by the HLR. The following error causes defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - unknown subscriber; - system failure; - unexpected data value; - data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 8.11 Subscriber Information services 8.11.1 MAP-ANY-TIME-INTERROGATION service 8.11.1.1 Definition This service is used by the gsmSCF, to request information (e.g. subscriber state and location) from the HLR or the GMLC at any time. This service may also be used by the gsmSCF to request the Mobile Number Portability (MNP) information from the NPLR. This service is also used by the Presence Network Agent to request information, (e.g. subscriber state and location) about the subscriber (associated with a presentity) from the HLR at any time (see 3GPP TS 23.141 [128]). When this service is used to the HLR, the subscriber state, location, Time Zone, or T-ADS data may be requested. When this service is used to the GMLC, only the location may be requested. When this service is used to the NPLR, only the MNP information may be requested. The MAP-ANY-TIME-INTERROGATION service is a confirmed service using the service primitives defined in tableÊ8.11/1. 8.11.1.2 Service primitives TableÊ8.11/1: Any_Time_Interrogation Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Requested Info M M(=) Requested domain C C(=) MNP Requested Info C C(=) gsmSCF-Address M M(=) IMSI C C(=) MSISDN C C(=) Location Information C C(=) Location Information for GPRS C C(=) Location Information for EPS C C(=) Subscriber State C C(=) PS Subscriber State C C(=) EPS Subscriber State C C(=) IMEI C C(=) MS Classmark 2 C C(=) GPRS MS Class C C(=) MNP info Result C C(=) IMS Voice Over PS Sessions Support Indicator C C(=) Last UE Activity Time C C(=) Last RAT Type C C(=) Time Zone C C(=) Daylight Saving Time C C(=) User error C C(=) Provider error O 8.11.1.3 Parameter definition and use All parameters are described in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.018 [97] and 3GPPÊTSÊ23.078Ê[98]. The HLR or GMLC may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Interrogation indication. The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98]. IMS Voice Over PS Sessions Support Indicator This parameter indicates the most recent IMS-Voice-Over-PS-Sessions support (based on the Last UE Activity Time), as received from the serving nodes. This parameter shall be present if Requested Info indicates that T-ADS Data are requested. Last UE Activity Time This parameter indicates the most recent available point in time of the UE's last radio contact, as received from the serving nodes. This value may not represent the absolute last instant of radio activity of the UE, when any of the serving nodes has not answered to the T-ADS query. This parameter may be present if requested Info indicates that T-ADS Data are requested. This value may not be available when all the serving nodes have indicated an homogeneous support or an homogeneous non support of IMS Voice Over PS Sessions, since in that case, the serving nodes do not need to be explicitly asked for T-ADS Data. Last RAT Type This parameter indicates the most recent available RAT Type of the access (based on the Last UE Activity Time), as received from the serving nodes. This parameter shall be present if requested Info indicates that T-ADS Data are requested and the IMS Voice Over PS Sessions Support Indicator does not take the value ""unknown"". This value may not represent the absolute last RAT Type of the UE, when any of the serving nodes has not answered to the T-ADS query. This parameter may be present if requested Info indicates that T-ADS Data are requested. This value may not be available when all the serving nodes have indicated an homogeneous support or an homogeneous non support of IMS Voice Over PS Sessions, since in that case, the serving nodes do not need to be explicitly asked for T-ADS Data. Time Zone This parameter indicates the Time Zone of the location in the visited network where the UE is attached, including any adjustment for summertime (daylight saving time). Daylight Saving Time This parameter indicates the Daylight Saving Time (in steps of 1 hour) used to adjust for summertime the time zone of the location where the UE is attached in the visited network. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Any Time Interrogation Not Allowed; - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error These are defined in clause 7.6.1. 8.11.2 MAP-PROVIDE-SUBSCRIBER-INFO service 8.11.2.1 Definition This service is used to request information (e.g. subscriber state and location) from the VLR, SGSN or MME (via an IWF) at any time. The MAP-PROVIDE-SUBSCRIBER-INFO service is a confirmed service using the primitives defined in tableÊ8.11/2. 8.11.2.2 Service primitives TableÊ8.11/2: Provide_Subscriber_Information Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Requested Info M M(=) IMSI M M(=) LMSI U O Call Priority U O Location Information C C(=) Location Information for GPRS C C(=) Subscriber State C C(=) PS Subscriber State C C(=) IMEI C C(=) MS Classmark 2 C C(=) GPRS MS Class C C(=) IMS Voice Over PS Sessions Support Indicator C C(=) Last UE Activity Time C C(=) Last RAT Type C C(=) Location Information for EPS C C(=) Time Zone C C(=) Daylight Saving Time C C(=) User error C C(=) Provider error O 8.11.2.3 Parameter definition and use All parameters are defined in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.018 [97] and 3GPPÊTSÊ23.078Ê[98]. Call Priority This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the HLR supports this parameter and if the Call Priority was received in the MAP_SEND_ROUTING_INFORMATION request. IMS Voice Over PS Sessions Support Indicator This parameter indicates whether IMS Voice Over PS Sessions is supported at the UE's current Routing Area. This parameter shall be present if the UE's current Routing Area is known to the SGSN and the Requested Info indicates that T-ADS Data are requested; otherwise it shall be absent. Last UE Activity Time This parameter indicates the point in time of the UE's last radio contact. This parameter shall be present if requested Info indicates that T-ADS Data are request. Last RAT Type This parameter indicates the RAT Type of the access where the UE was present at the time of the last radio contact. This parameter shall be present if requested Info indicates that T-ADS Data are request. Time Zone This parameter indicates the Time Zone of the location in the visited network where the UE is attached, including any adjustment for summertime (daylight saving time). Daylight Saving Time This parameter indicates the Daylight Saving Time (in steps of 1 hour) used to adjust for summertime the time zone of the location where the UE is attached in the visited network. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Data Missing; - Unexpected Data Value. If the subscriber is not found on the VLR, SGSN or MME, this may be indicated to the requester with the ""Unexpected Subscriber"" value inside the Unexpected Data Value error Provider error These are defined in clause 7.6.1. 8.11.3 MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION service 8.11.3.1 Definition This service is used by the gsmSCF, to request subscription information (e.g. call forwarding supplementary service data or CSI) from the HLR at any time. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this service. 8.11.3.2 Service primitives TableÊ8.11/3: Any_Time_Subscription_Interrogation Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Requested Subscription Info M M(=) GsmSCF-Address M M(=) IMSI C C(=) MSISDN C C(=) Long FTN Supported C C(=) Call Forwarding Data C C(=) Call Barring Data C C(=) ODB Info C C(=) CAMEL Subscription Info C C(=) Supported CAMEL phases in VLR C C(=) Supported CAMEL phases in SGSN C C(=) Offered CAMEL 4 CSIs in VLR C C(=) Offered CAMEL 4 CSIs in SGSN C C(=) MSISDN-BS-List C C(=) CSG Subscription Data C C(=) Call Hold Data C C(=) Call Waiting Data C C(=) Explicit Call Transfer Data C C(=) Calling Line Identification Presentation Data C C(=) Calling Line Identification Restriction Data C C(=) User error C C(=) Provider error O 8.11.3.3 Parameter definition and use All parameters are described in clauseÊ7.6. The HLR may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Subscription_Interrogation indication. The gsmSCF-address shall contain the IM-SSF address when the IM-SSF takes the role of the gsmSCF. The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Unexpected Data Value; - Unknown Subscriber; - BearerServiceNotProvisioned; - TeleserviceNotProvisioned; - CallBarred; - IllegalSS-Operation; - SS-NotAvailable; - InformationNotAvailable; - Any Time Subscription Interrogation Not Allowed; - Data Missing. Provider error These are defined in clause 7.6.1. 8.11.4 MAP-ANY-TIME-MODIFICATION service 8.11.4.1 Definition This service is used by the gsmSCF, to modify information of the HLR at any time. This service is also used by the Presence Network Agent to activate or deactivate reporting of mobility management events (associated with a presentity) from the VLR or SGSN (see 3GPP TS 23.141 [128]). This service is also used by a Service Related Entity (e.g. the IP-SM-GW) to activate a one-time subscription of UE-reachability in the MME (see 3GPP TS 23.204 [134]) and SGSN (see 3GPP TS 23.060 [104]). This service is also used by external Short Message Gateway (IP-SM-GW) for updating the IP-SM-GW Number stored in the HLR, and for retrieving SC Address from the HLR. 8.11.4.2 Service primitives TableÊ8.11/4: Any_Time_Modification Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) gsmSCF-Address M M(=) Subscriber Identity M M(=) Modification request for ODB data C C(=) Modification request for SS information C C(=) Modification request for CSI C C(=) Modification request for CSG C C(=) Long FTN Supported C C(=) Modification request for IP-SM-GW data C C(=) Activation request for UE-Reachability C C(=) Ext Forwarding information-for-CSE C C(=) Ext Call barring information-for-CSE C C(=) ODB Info C C(=) CAMEL subscription info C C(=) Service Centre Address C C(=) User error C C(=) Provider error O 8.11.4.3 Parameter definition and use All parameters are described in clauseÊ7.6. The HLR may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Modification indication. The use of parameters other than described below and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. gsmSCF-Address This parameter indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. If the service is used by IP-SM-GW, the parameter contains the address of the IP-SM-GW. See also 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. Modification request for CSG This parameter is used by the gsmSCF to request notification of modification of CSG subscription data. Modification request for IP-SM-GW data This parameter is used by the external IP-SM-GW for updating the IP-SM-GW Number and IP-SM-GW Diameter Address stored in the HLR. If this parameter is present then other modification requests shall not be present. Activation request for UE Reachability This parameter is used by the Service Related Entity (e.g. IP-SM-GW) to activate the one-time subscription for UE-Reachability. If this parameter is present then other modification requests shall not be present. Service Centre Address See definition in clauseÊ7.6.2. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Any Time Modification Not Allowed; - Data Missing; - Unexpected Data Value; - Unknown Subscriber; - Bearer service not provisioned; This error is returned only if not even a subset of the requested bearer service group has been subscribed to; - Teleservice not provisioned; This error is returned only if not even a subset of the requested teleservice group has been subscribed to; - Call Barred; - Illegal SS operation; - SS error status; - SS incompatibility; - SS subscription violation; - Information Not Available. Provider error These are defined in clause 7.6.1. 8.11.5 MAP-NOTE-SUBSCRIBER-DATA-MODIFIED service 8.11.5.1 Definition This service is used by the HLR to inform the gsmSCF that subscriber data have been modified. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this service. This service is also used by the HLR to inform the Service Related Entity (e.g. IP-SM-GW) that the UE has become reachable (see 3GPP TS 23.204 [134]). 8.11.5.2 Service primitives TableÊ8.11/5: Note_Subscriber_Data_Modified Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) MSISDN M M(=) Ext Forwarding information-for-CSE C C(=) Ext Call barring information-for-CSE C C(=) ODB Info C C(=) CAMEL subscription info C C(=) CSG Subscription Data C C CW info C C(=) CH info C C(=) CLIP Info C C(=) CLIR Info C C(=) ECT Info C C(=) All Information Sent C C(=) UE reachable C C(=) User error C C(=) Provider error O 8.11.5.3 Parameter definition and use Invoke id See clause 7.6.1 for the use of this parameter. IMSI See clause 7.6.2 for the use of this parameter. MSISDN See clause 7.6.2 for the use of this parameter. In an IP Multimedia Core Network, if no MSISDN is available, the HLR shall populate this parameter with the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). Ext Forwarding information-for-CSE See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]. Ext Call barring information-for-CSE See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]. ODB Info See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]. CAMEL subscription info See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. CSG Subscription Data This parameter contains a list of CSG-Ids and the associated expiration dates (see 3GPP TS 22.011 [138]). The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]. CW Info This parameter contains the status of the call waiting supplementary service. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] CH Info This parameter contains the status of the call hold supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] ECT Info This parameter contains the status of the explicit call transfer supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] CLIP Info This parameter contains the status of the calling line identification presentation supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] CLIR Info This parameter contains the status of the calling line identification restriction supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] All Information Sent This parameter is set when the HLR has sent all information to gsmSCF. UE Reachable This parameter is used when the HLR indicates to the Service related entity (e.g. IP-SM-GW) that the UE is reachable again. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error These are defined in clause 7.6.1. The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. 9 Operation and maintenance services 9.1 Subscriber tracing services 9.1.1 MAP-ACTIVATE-TRACE-MODE service 9.1.1.1 Definition This service is used between the HLR and the VLR to activate subscriber tracing in the VLR. Also this service is used between the HLR and the SGSN to activate subscriber tracing in the SGSN. The MAP-ACTIVATE-TRACE-MODE service is a confirmed service using the primitives from tableÊ9.1/1. 9.1.1.2 Service primitives TableÊ9.1/1: MAP-ACTIVATE-TRACE-MODE Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI C C(=) Trace reference M M(=) Trace type M M(=) Trace reference 2 C C(=) Trace depth list C C(=) Trace NE type list C C(=) Trace interface list C C(=) Trace event list C C(=) Trace support indicator C C(=) OMC Id U C(=) MDT-Configuration C C(=) User error C C(=) Provider error O 9.1.1.3 Parameter use Invoke id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is a mandatory parameter in a stand-alone operation. Trace reference See definition in clauseÊ7.6.10. This parameter contains trace reference for GSM only tracing request. Trace type See definition in clauseÊ7.6.10. This parameter contains trace type for GSM only tracing request. OMC Id See definition in clauseÊ7.6.2. The use of this parameter is an operator option. Trace reference 2 See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace depth list See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace NE type list See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace interface list See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace event list See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace support indicator See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. MDT-Configuration See definition in clauseÊ7.6.10. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unidentified Subscriber; - Facility Not Supported; - Tracing Buffer Full; - System Failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 9.1.2 MAP-DEACTIVATE-TRACE-MODE service 9.1.2.1 Definition This service is used between the VLR and the HLR for deactivating subscriber tracing in the VLR. Also this service is used between the SGSN and the HLR for deactivating subscriber tracing in the SGSN. The MAP-DEACTIVATE-TRACE-MODE service is a confirmed service using the primitives from tableÊ9.1/2. 9.1.2.2 Service primitives TableÊ9.1/2: MAP-DEACTIVATE-TRACE-MODE Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI C C(=) Trace reference M M(=) Trace reference 2 C C(=) User error C C(=) Provider error O 9.1.2.3 Parameter use Invoke id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is a mandatory parameter in a stand-alone operation. Trace reference See definition in clauseÊ7.6.10. Trace reference 2 See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unidentified Subscriber; - Facility Not Supported; - System Failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 9.1.3 MAP-TRACE-SUBSCRIBER-ACTIVITY service 9.1.3.1 Definition This service is used between the VLR and the MSC to activate the subscriber tracing in the MSC. The MAP-TRACE-SUBSCRIBER-ACTIVITY service is a non-confirmed service using the primitives from tableÊ9.1/3. 9.1.3.2 Service primitives TableÊ9.1/3: MAP-TRACE-SUBSCRIBER-ACTIVITY Parameter name Request Indication Invoke id M M(=) IMSI C C(=) Trace reference M M(=) Trace type M M(=) OMC Id U C(=) 9.1.3.3 Parameter use Invoke id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The controlling MSC shall provide either the IMSI or the IMEI to the servicing MSC. Trace reference See definition in clauseÊ7.6.10. Trace type See definition in clauseÊ7.6.10. OMC Id See definition in clauseÊ7.6.2. The use of this parameter is an operator option. 9.2 Other operation and maintenance services 9.2.1 MAP-SEND-IMSI service 9.2.1.1 Definition This service is used by a VLR in order to fetch the IMSI of a subscriber in case of some Operation & Maintenance procedure where subscriber data are needed in the Visited PLMN and MSISDN is the only subscriber's identity known. It is a confirmed service and consists of the primitives shown in tableÊ9.2/1. 9.2.1.2 Service primitives TableÊ9.2/1: MAP-SEND-IMSI Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSISDN M M(=) IMSI C C(=) User error C C(=) Provider error O 9.2.1.3 Parameter use All parameters are described in clauseÊ7.6. The following clarifications are applicable. User error Only one of the following values is applicable: - Unknown subscriber; - Unexpected data value; - Data missing. 10 Call handling services 10.1 MAP_SEND_ROUTING_INFORMATION service 10.1.1 Definition This service is used between the Gateway MSC and the HLR. The service is invoked by the Gateway MSC to perform the interrogation of the HLR in order to route a call towards the called MS. This is a confirmed service using the primitives listed in tableÊ10.1/1. This service is also used between the GMSC and the NPLR and between the gsmSCF and the HLR. 10.1.2 Service primitives TableÊ10.1/1: MAP_SEND_ROUTING_INFORMATION parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Interrogation Type M M(=) GMSC or gsmSCF Address M M(=) MSISDN M M(=) C C(=) OR Interrogation C C(=) OR Capability C C(=) CUG Interlock C C(=) C C(=) CUG Outgoing Access C C(=) C C(=) Number of Forwarding C C(=) Network Signal Info C C(=) Supported CAMEL Phases C C(=) C C(=) Suppress T-CSI C C(=) Offered CAMEL 4 CSIs C C(=) Suppression of Announcement C C(=) Call Reference Number C C(=) Forwarding Reason C C(=) Basic Service Group C C(=) Basic Service Group 2 C C(=) Alerting Pattern C C(=) CCBS Call C C(=) Supported CCBS Phase C C(=) Additional Signal Info C C(=) IST Support Indicator C C(=) Pre-paging supported C C(=) Call Diversion Treatment Indicator C C(=) Long FTN Supported C C(=) Suppress VT-CSI C C(=) Suppress Incoming Call Barring C C(=) SuppressMTSS C C(=) gsmSCF Initiated Call C C(=) Network Signal Info 2 C C(=) MT Roaming Retry Supported U C(=) Call Priority U C(=) IMSI C C(=) MSRN C C(=) Forwarding Data C C(=) Forwarding Interrogation Required C C(=) VMSC address C C(=) ReleaseResourcesSupported C C(=) GMSC Camel Subscription Info C C(=) Location Information C C(=) Subscriber State C C(=) Basic Service Code C C(=) CUG Subscription Flag C C(=) North American Equal Access preferred Carrier Id U C(=) User error C C(=) SS-List U C(=) CCBS Target C C(=) Keep CCBS Call Indicator C C(=) IST Alert Timer C C(=) Number Portability Status U C(=) Supported CAMEL Phases in VMSC C Offered CAMEL 4 CSIs in VMSC C C(=) MSRN 2 C C(=) Forwarding Data 2 C C(=) SS-List 2 C C(=) Basic Service Code 2 C C(=) Allowed Services C C(=) Unavailability Cause C C(=) Provider error O GSMÊBearer Capability U C(=) 10.1.3 Parameter use See clauseÊ7.6 for a definition of the parameters used in addition to the following. Note that: - a conditional parameter whose use is defined only in 3GPP TS 23.078 shall be absent if the sending entity does not support CAMEL; - a conditional parameter whose use is defined only in 3GPP TS 23.079 [99] shall be absent if the sending entity does not support optimal routeing; - a conditional parameter whose use is defined only in 3GPP TS 23.078 & 3GPP TS 23.079 [99] shall be absent if the sending entity supports neither CAMEL nor optimal routeing. Interrogation Type See 3GPP TS 23.079 [99] for the use of this parameter. GMSC or gsmSCF address The E.164 address of the GMSC or the gsmSCF. This parameter contains the gsmSCF address if the gsmSCF iniated call parameter is present, otherwise it is the GMSC address. MSISDN This is the Mobile Subscriber ISDN number assigned to the called subscriber. In the Request & Indication it is the number received by the GMSC in the ISUP IAM. If the call is to be forwarded and the HLR supports determination of the redirecting number, the HLR inserts the basic MSISDN in the Response. See 3GPP TS 23.066 [108] for the use of this parameter and the conditions for its presence in the response. OR Interrogation See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. OR Capability See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. CUG Interlock See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. CUG Outgoing Access See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. Number of Forwarding See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. Network Signal Info See 3GPP TS 23.018 [97] for the conditions for the presence of the components of this parameter. Supported CAMEL Phases The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. T-CSI Suppression The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the GMSC/VLR (see clause 7.6.3.36D). Suppression Of Announcement The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Call Reference Number The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97]. Forwarding Reason See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. Basic Service Group See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. Basic Service Group 2 See 3GPP TS 23.079[99] for the use of this parameter and the conditions for its presence. Alerting Pattern See 3GPP TS 23.018 [97] and 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence. CCBS Call See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Supported CCBS Phase This parameter indicates by its presence that CCBS is supported and the phase of CCBS which is supported. Additional Signal Info See 3GPP TS 23.081 [27] and 3GPP TS 23.088 [33] for the conditions for the presence of the components of this parameter. IST Support Indicator This parameter is used to indicate to the HLR that the GMSC supports basic IST functionality, that is, the GMSC is able to terminate the subscriber call activity that originated the IST Alert when it receives the IST Alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Send Routing Information indication and the subscriber is marked as an IST subscriber, then the HLR may limit the service for the call (by barring the incoming call if it is not subject to forwarding, or suppressing Call Forwarding from the GMSC), or allow the call assuming the associated risk of not having the basic IST mechanism available. This parameter can also indicate that the GMSC supports the IST Command, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Send Routing Information indication and the subscriber is marked as an IST subscriber, then the HLR may limit the service for the subscriber (by barring the incoming calls if they are not subject to forwarding, or suppressing Call Forwarding from the GMSC), or allow the incoming calls assuming the associated risk of not having the IST Command mechanism available. Pre-paging supported See 3GPP TS 23.018 for the use of this parameter and the conditions for its presence. Call Diversion Treatment Indicator This parameter indicates whether or not call diversion is allowed. Network Signal Info 2 See 3GPP TS 23.172 [126] for the conditions for the presence of the components of this parameter. MT Roaming Retry Supported See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. Call Priority This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the GMSC supports the eMLPP feature and if the call is an eMLPP call. The eMLPP priority levels A and B shall be mapped to the Call Priority level 0. IMSI See 3GPP TS 23.018 [97] and 3GPP TS 23.066 [108] for the use of this parameter and the conditions for its presence. MSRN See 3GPP TS 23.018 [97], 3GPP TS 23.066 [108] and 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence."
"If the NPLR returns only the MSISDN-number without Routeing Number to the GMSC, the MSISDN-number shall be returned as MSRN. Forwarding Data This parameter includes a number to define the forwarded-to destination, the forwarding reason and the forwarding options Notification to calling party and Redirecting presentation, and can include the forwarded-to subaddress. See 3GPP TS 23.018 [97] and 3GPP TS 23.079 [99] for the conditions for the presence of its components. Forwarding Interrogation Required See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. Long FTN Supported This parameter indicates that the GMSC supports Long Forwarded-to Numbers. Suppress VT-CSI The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Suppress Incoming Call Barring The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. gsmSCF Initiated Call The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. SuppressMTSS The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. VMSC address See 3GPP TS 23.079 [99] and 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence. In addition this parameter shall be present if the ReleaseResourcesSupported parameter is present. Release Resources Supported This parameter indicates by its presence that the MAP_RELEASE_RESOURCES service is supported at the VMSC. It shall be present if so indicated by the VMSC with MAP_PROVIDE_ROAMING_NUMBER confirm. GMSC CAMEL Subscription Info The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Location Information The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Subscriber State The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. CUG Subscription Flag The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. North American Equal Access preferred Carrier Id This parameter is returned to indicate the preferred carrier identity to be used to set-up the call (i.e. forwarding the call or establishing the roaming leg). SS-List This parameter includes SS-codes and will be returned as an operator option. The HLR shall not send PLMN-specific SS-codes across PLMN boundaries. However if the GMSC receives PLMN-specific SS-codes from a foreign PLMN's HLR the GMSC may ignore it. If the GMSC attempts to process the PLMN- specific SS- codes, this may lead to unpredictable behaviour but the GMSC shall continue call processing. Basic Service Code The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. If the CAMEL service is not involved, this parameter includes the basic service code and will be returned as an operator option. The HLR shall not send a PLMN-specific Basic Service Code across PLMN boundaries. However if the GMSC receives a PLMN-specific Basic Service Code from a foreign PLMN's HLR the GMSC may ignore it. If the GMSC attempts to process the PLMN specific Basic Service codes, this may lead to unpredictable behaviour but the GMSC shall continue call processing. CCBS Target See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Keep CCBS Call Indicator See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. IST Alert Timer It includes the IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs. This parameter is only sent to the GMSC in response to a Send Routing Information request which indicates the the GMSC supports IST. Number Portability Status This parameter indicates the number portability status of the subscriber. This parameter may be present if the sender of SRIack is NPLR. Supported CAMEL Phases in VMSC The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Offered CAMEL 4 CSIs in VMSC This parameter is defined in clause 7.6.3.36F. MSRN 2 The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. Forwarding Data 2 The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. SS-List 2 The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. Basic Service Code 2 The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. Allowed Services The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. Unavailability Cause The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Unknown Subscriber; The diagnostic for the Unknown Subscriber error may indicate ""NPDB Mismatch"". - Number changed; - Call Barred; This error will indicate that either incoming calls are barred for this MS or that calls are barred due to Operator Determined Barring (see 3GPP TS 22.041 [8] for a definition of this network feature); - CUG Reject; The value of this error cause will indicate the reason for CUG Reject; - Bearer Service Not Provisioned; - Teleservice Not Provisioned; A subscription check has been performed and the call has not passed the check due to incompatibility with regard to the requested service. Depending on the nature of the incompatibility, either of these messages will be returned; - Facility Not Supported; - Absent Subscriber; This indicates that the location of the MS is not known (either the station is not registered and there is no location information available or the Provide Roaming Number procedure fails due to IMSI detached flag being set), or the GMSC requested forwarding information with a forwarding reason of not reachable, and the call forwarding on MS not reachable service is not active; this may also indicate that the MS has moved to a new MSC/VLR and that MT Roaming Retry is requested (see 3GPP TS 23.018 [97]); - Busy Subscriber; This indicates that Call Forwarding on Busy was not active for the specified basic service group when the GMSC requested forwarding information with a forwarding reason of busy; The error may also indicate that the subscriber is busy due to an outstanding CCBS recall. In the error data it may then be specified that CCBS is possible for the busy encountered call; - No Subscriber Reply; This indicates that Call Forwarding on No Reply was not active for the specified basic service group when the GMSC requested forwarding information with a forwarding reason of no reply; - OR Not Allowed; This indicates that the HLR is not prepared to accept an OR interrogation from the GMSC, or that calls to the specified subscriber are not allowed to be optimally routed; - Forwarding Violation; - System Failure; - Data Missing; - Unexpected Data Value. See clauseÊ7.6.1.4 for a definition of these errors. Provider error These are defined in clauseÊ7.6. GSMÊBearer Capability This information is passed according to the rules specified in 3GPP TS 29.007 [56]. There may be two GSMÊBearer Capabilities supplied. 10.2 MAP_PROVIDE_ROAMING_NUMBER service 10.2.1 Definition This service is used between the HLR and VLR. The service is invoked by the HLR to request a VLR to send back a roaming number to enable the HLR to instruct the GMSC to route an incoming call to the called MS. This service is also used between old VLR and new VLR during the MT Roaming Forwarding procedure. The service is invoked by the old VLR to request a roaming number from the new VLR to be able to route an incoming call to the called UE. This is a confirmed service which uses the primitives described in tableÊ10.2/1. 10.2.2 Service primitives TableÊ10.2/1: MAP_PROVIDE_ROAMING_NUMBER parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) MSC Number M M(=) MSISDN U C(=) LMSI C C(=) GSMÊBearer Capability C C(=) Network Signal Info C C(=) Suppression Of Announcement C C(=) Call Reference Number C C(=) GMSC Address C C(=) OR Interrogation C C(=) OR Not Supported in GMSC C C(=) Alerting Pattern C C(=) CCBS Call C C(=) Supported CAMEL Phases in interrogating node C C(=) Additional Signal Info C C(=) Pre-paging supported C C(=) Long FTN Supported C C(=) Suppress VT-CSI C C(=) Offered CAMEL 4 CSIs in interrogating node C C(=) MT Roaming Retry Supported U C(=) Paging Area U C(=) Call Priority U C(=) MTRF Indicator U C(=) Old MSC Number U C (=) Last used LTE PLMN ID U C(=) Roaming Number C C(=) VMSC address U C(=) ReleaseResourcesSupported U C(=) User error C C(=) Provider error O 10.2.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. Note that: - a conditional parameter whose use is defined only in 3GPP TS 23.078 [98] shall be absent if the sending entity does not support CAMEL; - a conditional parameter whose use is defined only in 3GPP TS 23.079 [99] shall be absent if the sending entity does not support optimal routeing; - a conditional parameter whose use is defined only in 3GPP TS 23.078 [98] & 3GPP TS 23.079 [99] shall be absent if the sending entity supports neither CAMEL nor optimal routeing. IMSI This is the IMSI of the called Subscriber. MSC Number This is the ISDN number assigned to the MSC currently serving the MS. When the service is used between HLR and VLR, the MSC number will have been stored in the HLR as provided at location updating. When used between old VLR and new VLR during an MT Roaming Forwarding procedure, the MSC number will have been provided at location cancelling or within Send Identification. MSISDN See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. LMSI See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. In addition, for the mobile terminating roaming forwarding procedure between the old VLR and the new VLR, this parameter shall be present if the MTRF Indicator is present and theÊoldÊVLRÊhas received the new LMSI inÊCancel LocationÊfrom the HLR or in Send Identification from the new VLR. GSMÊBearer Capability See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. This information is passed according to the rules specified in TS 3GPP TS 29.007 [56]. There may be two GSMÊBearer Capabilities supplied. Network Signal Info See 3GPP TS 23.018 [97] for the conditions for the presence of the components of this parameter. Suppression Of Announcement The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078 [98]. Call Reference Number The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97]. GMSC Address The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97]. OR Interrogation See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. OR Not Supported in GMSC See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. Supported CAMEL Phases in interrogating node This parameter is defined in clause 7.6.3.36I.Alerting Pattern See 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence. CCBS Call See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Additional Signal Info See 3GPP TS 23.081 [27] for the conditions for the presence of the components of this parameter. Pre-paging supported See 3GPP TS 23.018 for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present. Long FTN supported See 3GPP TS 23.082 for the use of this parameter and the conditions for its presence. Suppress VT-CSI See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence. Offered CAMEL 4 CSIs in interrogating node This parameter is defined in clause 7.6.3.36E. MT Roaming Retry Supported See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present. Paging Area See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present. Call Priority This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the HLR supports this parameter and if the Call Priority was received in the MAP_SEND_ROUTING_INFORMATION request. MTRF Indicator This indicator indicates by its presence that the service is used between old VLR and new VLR during an MT Roaming Forwarding procedure. See 3GPP TS 23.018 [97]. Old MSC Number This parameter refers to the E.164 address of the old MSC. The use of this parameter is specified in 3GPP TS 23.018 [97]. This information element is applicable only if the MTRF Indicator is set. Last used LTE PLMN ID See 3GPP TS 23.272 [143] for the use of this parameter and the conditions for its presence. This information element is applicable only if the MTRF Indicator is set. Roaming Number See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. VMSC address See 3GPP TS 23.079 [99], 3GPP TS 23.078 [98] and 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. This parameter shall be present during the Mobile Terminating Roaming Forwarding Call during Retrieval of Routeing Information procedure if an MSRN is allocated by the new MSC/VLR. ReleaseResourcesSupported This parameter indicates by its presence that the MAP_RELEASE_RESOURCES service is supported at the VMSC. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Absent Subscriber; This error will be returned if the IMSI detach flag is set. - No Roaming Number Available; - OR Not Allowed; This indicates that the MAP_PROVIDE_ROAMING_NUMBER indication included the OR interrogation indicator, but the VLR does not support optimal routeing. - Facility Not Supported; - System Failure; - Data Missing; - Unexpected Data Value. See clauseÊ7.6 for a definition of these reasons. Provider error These are defined in clauseÊ7.6. 10.3 MAP_RESUME_CALL_HANDLING service 10.3.1 Definition This service is used between the terminating VMSC and the GMSC. The service is invoked by the terminating VMSC to request the GMSC to resume handling the call and forward it to the specified destination. This is a confirmed service which uses the Primitives listed in tableÊ10.3/1. 10.3.2 Service primitives TableÊ10.3/1: MAP_RESUME_CALL_HANDLING parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Call Reference Number C C(=) Basic Service Group C C(=) Basic Service Group 2 C C(=) IMSI C C(=) Forwarding Data C C(=) CUG Interlock C C(=) CUG Outgoing Access C C(=) O-CSI C C(=) D-CSI C C(=) CCBS Target C C(=) UU Data C C(=) UUS CF Interaction C C(=) All Information Sent C C(=) MSISDN C C(=) MT Roaming Retry U C(=) User error C C(=) Provider error O 10.3.3 Parameter use Information received in subsequent segment of a segmented dialogue shall not overwrite information received in an earlier segment. See clauseÊ7.6 for a definition of the parameters used, in addition to the following. Call Reference Number See 3GPP TS 23.079 [99] for the use of this parameter. This parameter shall be present in the first segment of the dialogue. Basic Service Group See 3GPP TS 23.079 [99] for the use of this parameter. This parameter shall be present in the first segment of the dialogue. Basic Service Group 2 See 3GPP TS 23.079[99] for the use of this parameter. If this parameter is present, it shall be in the first segment of the dialogue. IMSI This is the IMSI of the forwarding Subscriber. This parameter shall be present in the first segment of the dialogue. Forwarding Data This parameter includes a number to define the forwarded-to destination, the forwarding reason and the forwarding options Notification to calling party and Redirecting presentation, and can include the forwarded-to subaddress. See 3GPP TS 23.079 [99] for the conditions for the presence of its components. This parameter shall be present in a first segment of the dialogue. CUG Interlock See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. CUG Outgoing Access See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. O-CSI See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence. For CAMEL phases 1 & 2, the O-CSI shall contain only one set of O-BCSM TDP data. D-CSI The Dialled Services-CSI. See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence. CCBS Target See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. UU Data See 3GPP TS 23.087 for the use of this parameter and the conditions for its presence. UUS CF Interaction See 3GPP TS 23.087 for the use of this parameter and the conditions for its presence. All Information Sent This parameter is set when the VMSC has sent all information to GMSC. MT Roaming Retry See 3GPP TS 23.018 [97], 3GPP TS 23.012 [23] and 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. When this parameter is present, only the Call Reference Number and All Information Sent IEs shall be present; the other IEs shall be ignored by the GMSC if received. MSISDN This parameter is the basic MSISDN of the forwarding subscriber. It shall be present if the VMSC supports determination of the redirecting number. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Optimal Routeing not allowed; - Forwarding failed; - Unexpected Data Value; - Data Missing. Provider error These are defined in clauseÊ7.6. 10.4 MAP_PREPARE_GROUP_CALL service 10.4.1 Definition This service is used by the Anchor_MSC to inform the Relay_MSC about a group call set-up. The MAP_PREPARE_GROUP_CALL service is a confirmed service using the service primitives given in table 10.4/1. 10.4.2 Service primitives Table 10.4/1: MAP_PREPARE_GROUP_CALL service Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Teleservice M M(=) ASCI Call Reference M M(=) Ciphering Algorithm M M(=) Group Key Number VK-Id C C(=) VSTK Key C C(=) VSTK-RAND C C(=) Priority C C(=) CODEC-Information M M(=) Uplink Free Indicator M M(=) Talker Channel Parameter C C(=) Uplink Reply Indicator C C(=) Group Call Number M M(=) User Error C C(=) Provider Error O 10.4.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. Teleservice Voice Broadcast Service or Voice Group Call Service. ASCI Call Reference Broadcast call reference or group call reference. This item is used to access the VBS-GCR or VGCS-GCR within the Relay_MSC. Ciphering Algorithm The ciphering algorithm to be used for the group call. Group Key Number VK-Id This Group Key Number has to be broadcast and is used by the mobile station to derive the key for ciphering on the radio interface (see 3GPP TS 43.020 [24]). Values 2 to 15 are reserved for future use. Shall be present if the ciphering applies. VSTK The VGCS/VBS Short Term Key is used to derive the key for ciphering on the radio interface (see 3GPP TS 43.020 [24]). Shall be present if the ciphering applies. VSTK-RAND This random number has to be broadcast and is used by the mobile station to derive the group key for ciphering on the radio interface (see 3GPP TS 43.020 [24]). Shall be present if the ciphering applies. Priority Default priority level related to the call if eMLPP applies. CODEC-Information Information on the codecs allowed for this call. Uplink Free Indicator A flag indicating whether the call is initiated from a dispatcher. Talker Channel Parameter A flag indicating by its presence that a dedicated channel shall be established and maintained for the talking service subscriber. Uplink Reply Indicator A flag indicating by its presence that the uplink reply procedure is applicable for the voice group call or voice broadcast call. Group Call Number This temporary allocated E.164 number is used for routing the call from the Anchor MSC to the Relay MSC. User Error For definition of this parameter see clauseÊ7.6.1 The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - No Group Call Number available; - System Failure; - Unexpected Data Value. Provider Error See definition of provider error in clauseÊ7.6.1. 10.5 MAP_PROCESS_GROUP CALL_SIGNALLING service 10.5.1 Definitions This service is used between Relay MSC and Anchor MSC for transmission of Group Call notifications. The MAP_PROCESS_GROUP_CALL_SIGNALLING service is a non-confirmed service using the service primitives given in table 10.5/1. 10.5.2 Service primitives Table 10.5/1: MAP_PROCESS_GROUP_CALL_SIGNALLING service Parameter name Request Indication Invoke Id M M(=) Uplink Request C C(=) Uplink Release Indication C C(=) AN-APDU C C(=) Release Group Call C C(=) Talker Priority C C(=) Additional Info C C(=) Emergency Mode Reset Command Flag C C(=) 10.5.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1 Uplink Request This information element indicates to the anchor MSC that a service subscriber roaming in the relay MSC area requests access to the uplink. Uplink Release Indication This information element if included by the Relay MSC indicates to the Anchor MSC that the uplink has become free. AN-APDU This parameter contains the Notification Data message as defined in3GPP TS 48.008 [49]. Release Group Call This information element if included by the Relay MSC indicates to the Anchor MSC that the service subscriber who has initiated the call and who currently has access to the uplink terminates the call. Talker Priority For the definition and use of this parameter see 3GPP TS 43.068 [100] Additional Info For the definition and use of this parameter see 3GPP TS 43.068 [100] Emergency Mode Reset Command Flag For the definition and use of this parameter see 3GPP TS 43.068 [100] 10.6 MAP_FORWARD_GROUP_CALL_SIGNALLING service 10.6.1 Definitions This service is used between Anchor MSC and Relay MSC for transmission of Group Call notifications. The MAP_FORWARD_GROUP_CALL_SIGNALLING service is a non-confirmed service using the service primitives given in table 10.6/1. 10.6.2 Service primitives Table 10.6/1: MAP_FORWARD_GROUP_CALL_SIGNALLING service Parameter name Request Indication Invoke Id M M(=) IMSI C C(=) Uplink Request Acknowledgement C C(=) Uplink Release Indication C C(=) Uplink Reject Command C C(=) Uplink Seized Command C C(=) Uplink Release Command C C(=) AN-APDU C C(=) State Attributes C C(=) Talker Priority C C(=) Additional Info C C(=) Emergency Mode Reset Command Flag C C(=) SM RP UI C C(=) 10.6.3 Parameter definitions and use IMSI Identity of the service subscriber who has established the call and who is allowed to terminate the call. Invoke Id See definition in clauseÊ7.6.1. Uplink Request Acknowledgement This information element is used for positive acknowledgement of an uplink request. Uplink Release Indication This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink has become free. Uplink Reject Command This information element is used for negative acknowledgement of an uplink request. Uplink Seized Command This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink is no longer free. Uplink Release Command This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink which is granted to a MS in the relay MSC area shall be released. AN-APDU This parameter contains the Notification Data message as defined in 3GPP TS 48.008 [49] State Attributes This information element is used to allow service logic running in an Anchor MSC to mute a VGCS talker even when the talker is served on a Relay MSC. The IE is used to build a GCC message that provides a mechanism to induce the VGCS talker terminal to mute/unmute the downlink at the Anchor MSC, as defined in 3GPP TS 44.068. Talker Priority For the definition and use of this parameter see 3GPP TS 43.068 [100] Additional Info For the definition and use of this parameter see 3GPP TS 43.068 [100] Emergency Mode Reset Command Flag For the definition and use of this parameter see 3GPP TS 43.068 [100] SM RP UI See definition in clauseÊ7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. 10.7 MAP_SEND_GROUP_CALL_END_SIGNAL service 10.7.1 Definitions This service is used between the Relay MSC and the Anchor MSC. When the VGCS/ VBS calling service subscriber is in the Relay MSC area the MAP_SEND_GROUP_CALL_END_SIGNAL indicates that at least the downlink channel in the originating cell is established. For all other VGCS/ VBS call set-up scenarios (i.e. calling service subscriber in Anchor MSC area, calling service subscriber in other Relay MSC area, dispatcher originated call) the MAP_SEND_GROUP_CALL_END_SIGNAL indicates that at least the downlink channel in any one cell within the VGCS/ VBS call area in the Relay MSC is established. The response is used by the Anchor MSC to inform the Relay MSC that all resources for the call can be released in the Relay MSC because the call has been released in the Anchor MSC. The MAP_SEND_GROUP_CALL_END_SIGNAL service is a confirmed service using the service primitives given in table 10.7/1. 10.7.2 Service primitives Table 10.7/1: MAP_SEND_GROUP_CALL_END_SIGNAL service Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI C C(=) Talker Priority C C(=) Additional Info C C(=) Provider Error O 10.7.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1 IMSI Identity of the service subscriber who has established the call and who is allowed to terminate the call. Shall be present if the call was established by a service subscriber roaming in the relay MSC area. Talker Priority For the definition and use of this parameter see 3GPP TS 43.068 [100] Additional Info For the definition and use of this parameter see 3GPP TS 43.068 [100] Provider Error See definition of provider error in clauseÊ7.6.1. 10.7A MAP_SEND_GROUP_CALL_INFO service 10.7A.1 Definitions This service is used in a RANflex configuration (see 3GPP TS 23.236 [133]) between the subscriber's visited MSC and group call serving MSC of the subscriber's location area. The MAP_SEND_GROUP_CALL_INFO service is a confirmed service using the service primitives given in table 10.7A/1. 10.7A.2 Service primitives Table 10.7A/1: MAP_SEND_GROUP_CALL_INFO service Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Requested Info M M(=) Teleservice M M(=) Cell Id C C(=) Group Id M M(=) IMSI C C(=) C C(=) Talker Priority C C(=) Additional Info C C(=) C C(=) TMSI C C(=) CKSN C C(=) Anchor MSC Address C C(=) ASCI Call Reference C C(=) Additional Subscriptions C C(=) Kc C C(=) User Error C C(=) Provider Error O 10.7A.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1 Requested Info For the definition and use of this parameter see 3GPP TS 43.068 [100] Teleservice Voice Broadcast Service or Voice Group Call Service. Cell Id Identity of the initiating service subscriber's current cell. Group Id For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101]. If prefixes are used together with group IDs, the most significant digit of the Group Id contains the prefix. IMSI If sent in the request: Identity of the service subscriber who has established the call and who is allowed to terminate the call. If sent in the response: Identity of the uplink requesting service subscriber. Talker Priority For the definition and use of this parameter see 3GPP TS 43.068 [100] Additional Info For the definition and use of this parameter see 3GPP TS 43.068 [100] TMSI See definition in clauseÊ7.6.2. CKSN See clauseÊ7.6.7 for the use of this parameter. Anchor MSC Address For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101] ASCI Call Reference For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101] Additional Subscriptions For the definition and use of this parameter see 3GPP TS 43.068 [100] Kc See clauseÊ7.6.7 for the use of this parameter. User Error For definition of this parameter see clauseÊ7.6.1 The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - System Failure; - Unexpected Data Value; - Data Missing - TeleserviceNotProvisioned; - Unknown Subscriber; - Ongoing Call. Provider Error See definition of provider error in clauseÊ7.6.1. 10.8 Void 10.9 Void 10.10 MAP_SET_REPORTING_STATE service 10.10.1 Definition This service is used between the HLR and the VLR to set the reporting state for a requested service. It is a confirmed service using the service primitives shown in table 10.10/1. 10.10.2 Service primitives TableÊ10.10/1: MAP_SET_REPORTING_STATE parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI C C(=) LMSI C C(=) CCBS Monitoring C C(=) CCBS Subscriber Status C C(=) User error C C(=) Provider error O 10.10.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. IMSI The IMSI is a mandatory parameter if the service is used as the only one in a dialogue. CCBS Monitoring This parameter indicates whether monitoring for CCBS shall be started or stopped. If it indicates that monitoring shall be started this service corresponds to the message 'Start Reporting' in 3GPP TS 23.093 [107]; if it indicates that monitoring shall be stopped this service corresponds to the message 'Stop Reporting' in 3GPP TS 23.093 [107]. CCBS Subscriber Status See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System Failure; - Unidentified Subscriber; - Unexpected Data Value; - Data Missing; - Resource Limitation; - Facility Not Supported. NOTE: This error is reserved for future use. Provider error These are defined in clause 7.6. 10.11 MAP_STATUS_REPORT service 10.11.1 Definition This service is used by the VLR to report an event or call outcome to the HLR. It is a confirmed service using the service primitives shown in table 10.11/1. 10.11.2 Service primitives TableÊ10.11/1: MAP_STATUS_REPORT parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) CCBS Subscriber Status C C(=) Monitoring Mode C C(=) Call Outcome C C(=) User error C C(=) Provider error O 10.11.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. CCBS Subscriber Status If this parameter is present without Monitoring Mode and Call Outcome this service corresponds to the message 'Event Report' in 3GPP TS 23.093 [107]. See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Monitoring Mode If this parameter is present with CCBS Call Outcome this service corresponds to the message 'CCBS Call Report' in 3GPP TS 23.093 [107]. See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Call Outcome See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - Unknown Subscriber; - System Failure; - Unexpected Data Value; - Data Missing. Provider error These are defined in clauseÊ7.6. 10.12 MAP_REMOTE_USER_FREE service 10.12.1 Definition This service is used between the HLR and the VLR to report that the B subscriber is now idle and that the A subscriber can be notified. It is a confirmed service using the service primitives shown in table 10.12/1. 10.12.2 Service primitives TableÊ10.12/1: MAP_REMOTE_USER_FREE parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) Call Info M M(=) CCBS Feature M M(=) Translated B Number M M(=) Replace B Number C C(=) Alerting Pattern C C(=) RUF Outcome C C(=) User error C C(=) Provider error O 10.12.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. Call Info See 3GPP TS 23.093 [107] for the use of this parameter. CCBS Feature See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature. Translated B Number See 3GPP TS 23.093 [107] for the use of this parameter. Replace B Number See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Alerting Pattern See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. RUF Outcome See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - Unexpected Data Value; - Data Missing; - Incompatible Terminal; - This error is returned by the responder when the terminal used for CCBS activation is not compatible with the terminal used for the CCBS recall. For details refer to 3GPP TS 24.008 [35]; - Absent Subscriber (IMSI Detach; Restricted Area; No Page Response); - System Failure; - Busy Subscriber (CCBS Busy). Provider error These are defined in clauseÊ7.6. 10.13 MAP_IST_ALERT service 10.13.1 Definition This service is used between the MSC (Visited MSC or Gateway MSC) and the HLR, to report that the IST timer running for a call for the Subscriber has expired. It is a confirmed service using the service primitives shown in tableÊ10.13/1. 10.13.2 Service primitives TableÊ10.13/1: MAP_IST_ALERT parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) IST Alert Timer C C(=) IST Information Withdraw C C(=) Call termination Indicator C C(=) User error C C(=) Provider error O 10.13.3 Parameter use All parameters are described in clause 7.6. The following clarifications are applicable: IST Alert Timer If included in the IST Alert response, it includes the new IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs. IST Information Withdraw If included in the IST Alert response, this parameter is used to indicate that the IST condition has been removed for the subscriber. When the MSC receives this parameter, IST control for that call shall be terminated. Call termination Indicator If included in the IST Alert response, this parameter is used to indicate whether the MSC shall terminate the call activity that had previously triggered the IST Alert procedure, or it shall also release all other call activities for the specified subscriber (outgoing call activities if the IST Alert is initiated by the VMSC, or incoming call activities if the IST Alert is initiated by the GMSC). Release of all other call activities is possible only if the MSC has the capability to link the call activities for the Subscriber by using the IMSI as key. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Unexpected Data Value; - Resource Limitation; - Facility Not Supported; - Unknown Subscriber. 10.14 MAP_IST_COMMAND service 10.14.1 Definition This service is used by the HLR to instruct the MSC (Visited MSC or Gateway MSC) to terminate ongoing call activities for a specific subscriber. It is a confirmed service using the service primitives shown in table 10.14/1. 10.14.2 Service primitives TableÊ10.14/1: MAP_IST_COMMAND parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) User error C C(=) Provider error O 10.14.3 Parameter use All parameters are described in clause 7.6. The following clarifications are applicable: User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Unexpected Data Value; - Resource Limitation; - Facility Not Supported; - Unknown Subscriber. 10.15 MAP_RELEASE_RESOURCES service 10.15.1 Definition This service is used between the GMSC and the terminating VMSC."
"The service is invoked by the GMSC to request the VMSC to release the resources associated with the specified MSRN. This is a confirmed service which uses the Primitives listed in tableÊ10.15/1. 10.15.2 Service primitives TableÊ10.15/1: MAP_RELEASE_RESOURCES parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSRN M M(=) User error C C(=) Provider error O 10.15.3 Parameter use MSRN See 3GPP TS 23.018 [97] for the use of this parameter. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Unexpected Data Value; Provider error These are defined in clauseÊ7.6. 11 Supplementary services related services 11.1 MAP_REGISTER_SS service 11.1.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to register data related to a supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.1./1. 11.1.2 Service primitives TableÊ11.1/1: MAP_REGISTER_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Basic service C C(=) Forwarded-to number with subaddress C C(=) No reply condition time C C(=) EMLPP default priority C C(=) C C(=) Long FTN Supported C C(=) NbrUser C C(=) C C(=) Forwarding information C C(=) User error C C(=) Provider error O 11.1.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates the supplementary service which the mobile subscriber wants to register. Basic service This parameter indicates for which basic service group the supplementary service is to be registered. If it is not included, the registration request applies to all basic services. Forwarded-to number with subaddress This parameter is obligatory if the registration applies to one or more call forwarding supplementary services. It can optionally include a sub-address. No reply condition time This parameter is included if the registration applies to the Call Forwarding on No Reply supplementary service (or a superset of this service) and the mobile subscriber supplies a value for this time. EMLPP default priority This parameter is sent by the initiator to register the eMLPP default priority level and is returned by the responder at successful outcome of the service. Long FTN Supported This parameter indicates that the mobile station supports Long Forwarded-to Numbers. NbrUser This parameter is sent by the initiator to register the MC maximum number of user defined circuit switched bearers to be used. Forwarding information This parameter is returned by the responder at successful outcome of the service, if the registration request concerned one or a group of Call Forwarding supplementary services. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; - Call Barred; - Bearer service not provisioned; - This error is returned only if not even a subset of the requested bearer service group has been subscribed to; - Teleservice not provisioned; This error is returned only if not even a subset of the requested teleservice group has been subscribed to; - Illegal SS operation; - SS error status; - SS incompatibility. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.2 MAP_ERASE_SS service 11.2.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.2/1. 11.2.2 Service primitives TableÊ11.2/1: MAP_ERASE_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Basic service C C(=) Forwarding information C C(=) User error C C(=) Provider error O 11.2.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates the supplementary service which the mobile subscriber wants to erase. Basic service This parameter indicates for which basic service group the supplementary service should be erased. If it is not included, the erasure request applies to all basic services. Forwarding information This parameter is returned by the responder at successful outcome of the service, if the erasure request concerned one or a group of Call Forwarding supplementary services. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Bearer service not provisioned; This error is returned only if not even a subset of the requested bearer service group has been subscribed to; - Teleservice not provisioned; This error is returned only if not even a subset of the requested teleservice group has been subscribed to; - Call Barred; - Illegal SS operation; - SS error status. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.3 MAP_ACTIVATE_SS service 11.3.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to activate a supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.3/1. 11.3.2 Service primitives TableÊ11.3/1: MAP_ACTIVATE_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Long FTN Supported C C(=) Basic service C C(=) Forwarding information C C(=) Call barring information C C(=) SS-Data C C(=) User error C C(=) Provider error O 11.3.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates the supplementary service which the mobile subscriber wants to activate. Basic service This parameter indicates for which basic service groups the requested supplementary service(s) should be activated. If it is not included, the activation request applies to all basic services. Forwarding information This parameter is returned by the responder at successful outcome of the service, if the activation request concerned Call Forwarding. Long FTN Supported This parameter indicates that the mobile station supports Long Forwarded-to Numbers. Call barring information This parameter is returned by the responder at successful outcome of the service, if the activation request concerned Call Barring. SS-Data This parameter is returned by the responder at successful outcome of the service, if the activation request concerned for example Call Waiting. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Bearer service not provisioned; - This error is returned only if not even a subset of the requested bearer service group has been subscribed to. - Teleservice not provisioned; - This error is returned only if not even a subset of the requested teleservice group has been subscribed to. - Call Barred; - Illegal SS operation; - SS error status; - SS subscription violation; - SS incompatibility; - Negative PW check; - Number Of PW Attempts Violation. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.4 MAP_DEACTIVATE_SS service 11.4.1 Definitions This service is used between the MSC and the VLR and between the VLR and the HLR to deactivate a supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.4/1. 11.4.2 Service primitives TableÊ11.4/1: MAP_DEACTIVATE_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Basic service C C(=) Forwarding information C C(=) Call barring information C C(=) SS-Data C C(=) User error C C(=) Provider error O 11.4.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates the supplementary service which the mobile subscriber wants to deactivate. Basic service This parameter indicates for which basic service group the requested supplementary service(s) should be deactivated. If it is not included the deactivation request applies to all basic services. Forwarding information This parameter is returned by the responder at successful outcome of the service, if the deactivation request concerned one or a group of Call Forwarding supplementary services. Call barring information This parameter is returned by the responder at successful outcome of the service, if the activation request concerned one or a group of Call Barring supplementary services. SS-Data This parameter is returned by the responder at successful outcome of the service, for example if the deactivation request concerned the Call Waiting supplementary service. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Bearer service not provisioned; This error is returned only if not even a subset of the requested bearer service group has been subscribed to; - Teleservice not provisioned; This error is returned only if not even a subset of the requested teleservice group has been subscribed to; - Call Barred; - Illegal SS operation; - SS error status; - SS subscription violation; - Negative PW check; - Number Of PW Attempts Violation. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.5 MAP_INTERROGATE_SS service 11.5.1 Definitions This service is used between the MSC and the VLR and between the VLR and the HLR to retrieve information related to a supplementary service. The VLR will relay the message to the HLR if necessary. The service is a confirmed service and consists of four service primitives. 11.5.2 Service primitives The service primitives are shown in tableÊ11.5/1. TableÊ11.5/1: MAP_INTERROGATE_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Basic service C C(=) Long FTN Supported C C(=) SS-Status C C(=) Basic service Group LIST C C(=) Forwarding feature LIST C C(=) CLI restriction Info C C(=) EMLPP Info C C(=) MC Information C C(=) CCBS Feature LIST C C(=) User error C C(=) Provider error O 11.5.3 Parameter use For additional information on parameter use refer to the GSMÊ04.8x and 04.9x-series of technical specifications. Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code The mobile subscriber can only interrogate a single supplementary service per service request. Basic service This parameter indicates for which basic service group the given supplementary service is interrogated. If it is not included, the interrogation request applies to all basic services. SS-Status This parameter is included by the responder if: - the interrogated supplementary service can only be subscribed for all applicable basic services simultaneously; or - the interrogated supplementary service is not active for any of the interrogated basic services, or - the interrogation was for the CCBS supplementary service and no CCBS request is active or the service is not provisioned. Basic service group LIST This parameter LIST is used to include one or a series of basic service groups for which the interrogated supplementary service is active. If the interrogated supplementary service is not active for any of the interrogated (and provisioned) basic service groups, the SS-Status parameter is returned. Long FTN Supported This parameter indicates that the mobile station supports Long Forwarded-to Numbers. Forwarding feature LIST The forwarding feature parameter is described in clauseÊ7.6.4. A list of one or more forwarding features is returned by the responder when the interrogation request applied to Call Forwarding supplementary service. If no basic service code parameter is provided within this sequence, the forwarding feature parameter applies to all provisioned basic services. CLI restriction Info The CLI-RestrictionInfo parameter is returned by the responder when the interrogation request applies to the CLIR supplementary service. EMLPP Info The eMLPP info (maximum entitled priority and default priority) is returned by the responder if the interrogation request applies to the eMLPP supplementary service. MC Information The MC information (NbrSB, NbrUser and NbrSN) is returned by the responder if the interrogation request applies to the MC supplementary service. For a definition of these 3 components, refer to 3GPP TS 23.135 and 3GPP TS 24.135. CCBS Feature LIST The CCBS feature parameter is described in clause 7.6. A list of one or more CCBS features is returned by the responder when the interrogation request applied to the CCBS supplementary service. See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature. User error This error is sent by the responder upon unsuccessful outcome of the interrogation service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Bearer Service not provisioned; This error is returned only if not even a subset of the interrogated bearer services are provided; - Teleservice not provisioned; This error is returned only if not even a subset of the interrogated teleservices are provided; - Call Barred; - Illegal SS operation; - SS not available. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.6 Void 11.7 MAP_REGISTER_PASSWORD service 11.7.1 Definitions This service is used between the MSC and the VLR and between the VLR and the HLR if the mobile subscriber requests to register a new password. The VLR will relay the message to the HLR. The service is a confirmed service and consists of four service primitives. 11.7.2 Service primitives The service primitives are shown in tableÊ11.7/1. TableÊ11.7/1: MAP_REGISTER_PASSWORD parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) New password C C(=) User error C C(=) Provider error O 11.7.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates for which supplementary service(s) the password should be registered. New Password See clauseÊ7.6.4 for the use of this parameter. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Call Barred; - SS subscription violation; - Password registration failure; - Negative PW check; - Number Of PW Attempts Violation. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.8 MAP_GET_PASSWORD service 11.8.1 Definitions This service is used between the HLR and the VLR and between the VLR and the MSC when the HLR receives a request from the mobile subscriber for an operation on a supplementary service which requires a password from the subscriber. The VLR will relay the message to the MSC. The service is a confirmed service and uses the service primitives shown in table 11.8/1. 11.8.2 Service primitives TableÊ11.8/1: MAP_GET_PASSWORD parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Linked id C C(=) Guidance info M M(=) Current password M M(=) Provider error O 11.8.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. Linked Id See clauseÊ7.6.1 for the use of this parameter. If the MAP_GET_PASSWORD service is used in conjunction with the MAP_REGISTER_PASSWORD service, this parameter must be present; otherwise it must be absent. Guidance info See clauseÊ7.6.4 for the use of this parameter. Current password See clauseÊ7.6.4 for the use of this parameter. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.9 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service 11.9.1 Definitions This service is used between the MSC and the VLR, between the VLR and the HLR, between the HLR and gsmSCF and between the HLR and HLR to relay information in order to allow unstructured supplementary service operation. The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service is a confirmed service using the primitives from tableÊ11.9/1. 11.9.2 Service primitives TableÊ11.9/1: MAP_PROCESS_UNSTRUCTURED_SS_REQUEST parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) USSD Data Coding Scheme M M(=) C C(=) USSD String M M(=) C C(=) MSISDN C C(=) User error C C(=) Provider error O 11.9.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. USSD Data Coding Scheme See clauseÊ7.6.4 for the use of this parameter. The presence of the parameter in the response is dependent on the unstructured supplementary service application. If this parameter is present, then the USSD String parameter has to be present. USSD String See clauseÊ7.6.1 for the use of this parameter. The presence of the parameter in the response is dependent on the unstructured supplementary service application. If this parameter is present, then the USSD Data Coding Scheme parameter has to be present. MSISDN The subscriber's basic MSISDN. See definition in clauseÊ7.6.2. For Follow Me when the service request is sent from the HLR of the A subscriber, the parameter shall contain the MSISDN of the A subscriber, see 3GPP TS 23.094 [129]. For other purposes the MSISDN may be included as an operator option, e.g. to allow addressing the subscriber's data in the gsmSCF with the MSISDN. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; This error is returned by the responder if it is not able to deal with the contents of the USSD string. - Call Barred; - Unknown Alphabet. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.10 MAP_UNSTRUCTURED_SS_REQUEST service 11.10.1 Definitions This service is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires information from the mobile user, in connection with unstructured supplementary service handling. The MAP_UNSTRUCTURED_SS_REQUEST service is a confirmed service using the primitives from tableÊ11.10/1. 11.10.2 Service primitives TableÊ11.10/1: MAP_UNSTRUCTURED_SS_REQUEST parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) USSD Data Coding Scheme M M(=) C C(=) USSD String M M(=) C C(=) Alerting Pattern C C(=) User error C C(=) Provider error O 11.10.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. USSD Data Coding Scheme See clauseÊ7.6.4 for the use of this parameter. The presence of the parameter in the response is dependent on the mobile user's MMI input. If this parameter is present, then the USSD String parameter has to be present. USSD String See clauseÊ7.6.1 for the use of this parameter. The presence of the parameter in the response is dependent on the mobile user's MMI input. If this parameter is present, then the USSD Data Coding Scheme parameter has to be present. Alerting Pattern See clause 7.6.3 for the use of this parameter. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; This error is returned by the responder if it is not able to deal with the contents of the USSD string; - Absent Subscriber; - Illegal Subscriber; This error indicates that delivery of the unstructured supplementary service data failed because the MS failed authentication; - Illegal Equipment; - USSD Busy; - Unknown Alphabet. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.11 MAP_UNSTRUCTURED_SS_NOTIFY service 11.11.1 Definitions This service is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires a notification to be sent to the mobile user, in connection with unstructured supplementary services handling. The MAP_UNSTRUCTURED_SS_NOTIFY service is a confirmed service using the primitives from tableÊ11.11/1. 11.11.2 Service primitives TableÊ11.11/1: MAP_UNSTRUCTURED_SS_NOTIFY parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) USSD Data Coding Scheme M M(=) USSD String M M(=) Alerting Pattern C C(=) User error C C(=) Provider error O 11.11.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. USSD Data Coding Scheme: See clauseÊ7.6.4 for the use of this parameter. USSD String: See clauseÊ7.6.1 for the use of this parameter. Alerting Pattern See clause 7.6.3 for the use of this parameter. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; This error is returned by the responder if it is not able to deal with the contents of the USSD string. - Absent Subscriber; - Illegal Subscriber; This error indicates that delivery of the unstructured supplementary service data failed because the MS failed authentication. - Illegal Equipment; - USSD Busy; - Unknown Alphabet. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.12 MAP_SS_INVOCATION_NOTIFY 11.12.1 Definition This service is used between the MSC and the gsmSCF when the subscriber invokes one of the following supplementary services; Call Deflection (CD), Explicit Call Transfer (ECT) or Multi Party (MPTY). This service is used between the HLR and the gsmSCF when the subscriber invokes the CCBS supplementary service. 11.12.2 Service primitives The service primitives are shown in tableÊ11.12/1. TableÊ11.12/1: SS_INVOCATION_NOTIFY parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) MSISDN M M(=) IMSI M M(=) SS- event M M(=) SS- event data C C(=) B-subscriber Number C C(=) CCBS Request State C C(=) User error C C(=) Provider error O 11.12.3 Parameter use All parameters are described in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.078. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error This is defined in clause 7.6.1. 11.13 MAP_REGISTER_CC_ENTRY service 11.13.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to register data for a requested call completion supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.13/1. 11.13.2 Service primitives TableÊ11.13/1: MAP_REGISTER_CC_ENTRY parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS Code M M(=) CCBS Feature C C(=) C C(=) Translated B number C C(=) Service Indicator C C(=) Call Info C C(=) Network Signal Info C C(=) User error C C(=) Provider error O 11.13.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. SS-Code This parameter indicates the call completion supplementary service for which the mobile subscriber wants to register an entry. CCBS Feature See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature. Translated B Number See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Service Indicator This parameter corresponds to the parameters 'Presentation Indicator' and 'CAMEL Invoked' in 3GPP TS 23.093 [107]. It indicates which services have been invoked for the original call (e.g. CLIR, CAMEL). See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Call Info See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Network Signal Info See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; - Call Barred; - Illegal SS operation; - SS error status; - SS incompatibility. - Short Term Denial; - Long Term Denial; - Facility Not Supported; NOTE: This error is reserved for future use. Private Extensions shall not be sent with these user errors for this operation. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.14 MAP_ERASE_CC_ENTRY service 11.14.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a call completion supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in tableÊ11.14/1. 11.14.2 Service primitives TableÊ11.14/1: MAP_ERASE_CC_ENTRY parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) C(=) C(=) CCBS Index C C(=) SS-Status C C(=) User error C C(=) Provider error O 11.14.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. SS-Code This parameter indicates the call completion supplementary service for which the mobile subscriber wants to erase an entry/entries. CCBS Index See 3GPP TS 23.093 [107] for the use of this parameter and the condition for its presence. SS-Status Depending on the outcome of the service request this parameter may indicate either provisioned and active or not provisioned. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Call Barred; - Illegal SS operation; - SS error status. Private Extensions shall not be sent with these user errors for this operation. Provider error See clauseÊ7.6.1 for the use of this parameter. 12 Short message service management services 12.1 MAP-SEND-ROUTING-INFO-FOR-SM service 12.1.1 Definition This service is used between the gateway MSC and the HLR to retrieve the routing information needed for routing the short message to the servicing MSC or MME but not both, or SGSN, or (for T4-device triggering via the IMS) IP-SM-GW, or SMSF. This service is also used between the gateway MSC and SMS Router, and SMS Router and HLR in order to enforce routing of the SM delivery via the HPLMN of the receiving MS. This service is also used between HLR and IP-SM-GW, and between IP-SM-GW and HLR in order to allow MT-SM delivery (other than T4-device triggering) via the IMS. This service is also used with an IWF interfacing the S6c interface. The MAP-SEND-ROUTING-INFO-FOR-SM is a confirmed service using the primitives from tableÊ12.1/1. 12.1.2 Service primitives TableÊ12.1/1: MAP-SEND-ROUTING-INFO-FOR-SM Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSISDN M M(=) SM-RP-PRI M M(=) Service Centre Address M M(=) SM-RP-MTI C C(=) SM-RP-SMEA C C(=) GPRS Support Indicator C C(=) SM-Delivery Not Intended U C(=) IP-SM-GW Guidance Support Indicator U C(=) Single Attempt Delivery C C(=) IMSI C C(=) C C(=) Correlation ID C C(=) T4 Trigger Indicator C C(=) SMSF Support Indicator C C(=) Network Node Number C C(=) Network Node Diameter Address C C(=) LMSI C C(=) GPRS Node Indicator C C(=) Additional Number C C(=) Additional Network Node Diameter Address C C(=) IP-SM-GW Guidance U C(=) Third Number C C(=) Third Network Node Diameter Address C C(=) IMS Node Indicator C C(=) SMSF 3GPP Number C C(=) SMSF 3GPP Diameter Address C C(=) SMSF Non-3GPP Number C C(=) SMSF Non-3GPP Diameter Address C C(=) SMSF 3GPP Address Indicator C C(=) SMSF Non 3GPP Address Indicator C C(=) User error C C(=) Provider error O 12.1.3 Parameter use Invoke id See definition in clauseÊ7.6.1. MSISDN See definition in clauseÊ7.6.2. When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR following an T4 Submit Trigger (see 3GPP TS 23.682 [148]), MSISDN may not be available. In this case the UE shall be identified by the IMSI and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), MSISDN may not be available. In this case the UE shall be identified by a Correlation ID (SIP-URI-B) and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). SM-RP-PRI See definition in clauseÊ7.6.8. Service Centre Address See definition in clauseÊ7.6.2. SM-RP-MTI See definition in clauseÊ7.6.8. This parameter shall be present when the feature ÇÊSM filtering by the HPLMNÊÈ is supported by the SMS-GMSC and when the equivalent parameter is received from the short message service relay sub-layer protocol. SM-RP-SMEA See definition in clauseÊ7.6.8. This parameter shall be present when the feature ÇÊSM filtering by the HPLMNÊÈ is supported by the SMS-GMSC and when the equivalent parameter is received from the short message service relay sub-layer protocol. GPRS Support Indicator See definition in clause 7.6.8. The presence of this parameter is mandatory if the SMS-GMSC supports receiving of the two numbers from the HLR. SM-Delivery Not Intended This parameter indicates by its presence that delivery of a short message is not intended. It further indicates whether only IMSI or only MCC+MNC are requested. This parameter may be set by entities that request the service without intending to deliver a short message (e.g. MMS Relay/Server), and shall be evaluated by the SMS Router and may be evaluated by the HLR. IP-SM-GW Guidance Support Indicator This parameter indicates whether or not the SMS-GMSC is prepared to receive IP-SM-GW Guidance in the response. Single Attempt Delivery This parameter indicates the short message is only valid for delivering once, and the HLR/HSS does not need to add the received SC address into MWD list in the case there is no serving node available to provide SMS to the user. IMSI See definition in clauseÊ7.6.2. In Request and Indication: IMSI shall be present if MSISDN is not available. When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), IMSI may not be available. In this case the IMSI parameter shall be populated with the HLR-ID value. In Response and Confirm: If enforcement of routing an SM via the HPLMN of the receiving MS is deployed, this parameter contains an MT Correlation ID instead of an IMSI when the service is used between SMS-GMSC and SMS Router (see 3GPP TS 23.040 [26] for more information). If the ""SM-Delivery Not Intended"" parameter was present in the Indication with a value of ""only MCC+MNC requested"", then this parameter may contain MCC+MNC+dummy MSIN. The presence of this parameter is mandatory in a successful case. T4 Trigger Indicator This indicator indicates by its presence that the request is sent in the context of T4 device triggering (see 3GPP TS 23.682 [148]). When received, the HLR may return up to three serving node numbers and shall not forward the request to an IP-SM-GW or SMS Router. SMSF Support Indicator It indicates that the requesting node is capable of receiving ISDN numbers and/or Diameter addresses of the SMSF as target of MT-SMS. Correlation ID The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user. SIP-URI-A and HLR-ID shall be absent from this parameter. The Correlation ID indicates by its presence that the request is sent in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [134]). When received, the HLR shall return the IP-SM-GW number and shall not forward the request to an IP-SM-GW. Network Node Number See definition in clauseÊ7.6.2. This parameter is provided in a successful response. If the ""SM-Delivery Not Intended"" parameter was present in the Indication a dummy address (encoded in the same manner as the dummy MSISDN defined in clause 3.3 of 3GPPÊTSÊ23.003Ê[17]) may be provided. See clause 12.1.4. Network Node Diameter Address See definition in clauseÊ7.6.2. See clause 12.1.4. LMSI See definition in clauseÊ7.6.2. It is an operator option to provide this parameter from the VLR; it is mandatory for the HLR to include the LMSI in a successful response, if the VLR has used the LMSI. GPRS Node Indicator See definition in clause 7.6.8. Outside the context of T4 device triggering: The presence of this parameter is mandatory if only the SGSN number is sent in the Network Node Number (i.e. if the value within Network Node Number is to be considered as SGSN-Number and Additional Number is absent). Within the context of T4 device triggering: The presence of this parameter is mandatory if the value within Network Node Number is to be considered as SGSN-Number and Third Number is absent. Additional Number See definition in clauseÊ7.6.2. See clause 12.1.4. Additional Network Node Diameter Address See definition in clauseÊ7.6.2. See clause 12.1.4. IP-SM-GW Guidance This parameter contains the recommended and the minimum timer values for supervision of MT-Forward-Short-Message response. Shall be absent if the IP-SM-GW-Guidance Support Indicator in the request is absent. This parameter is only used by IP-SM-GW and SMS-GMSC. Third Number See definition in clauseÊ7.6.2. See clause 12.1.4. Third Network Node Diameter Address See definition in clauseÊ7.6.2. See clause 12.1.4 IMS Node Indicator See definition in clause 7.6.8. Outside the context of T4 device triggering: The parameter is not applicable and shall be absent. Within the context of T4 device triggering: The presence of this parameter is mandatory if the value within Network Node Number is to be considered as IP-SM-GW-Number and Third Number is absent. SMSF 3GPP Number This parameter contains the ISDN number of the SMSF target node for MT-SMS over 3GPP access. SMSF 3GPP Diameter Address This parameter contains the Diameter Name and Realm of the SMSF target node for MT-SMS over 3GPP access. SMSF Non-3GPP Number This parameter contains the ISDN number of the SMSF target node for MT-SMS over non-3GPP access. SMSF Non-3GPP Diameter Address This parameter contains the Diameter Name and Realm of the SMSF target node for MT-SMS over non-3GPP access. SMSF 3GPP Address Indicator It indicates that the parameter Network Node Number (and Network Node Diameter Address, if present) contains the address of an SMSF for 3GPP access. SMSF Non-3GPP Address Indicator It indicates that the parameter Network Node Number (and Network Node Diameter Address, if present) contains the address of an SMSF for non-3GPP access. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown subscriber; - Call Barred; - Teleservice Not Provisioned; - Absent Subscriber_SM; - Facility Not Supported; - System failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.1.4 Identities of MT-SMS Target Nodes In a successful MAP-Send-Routing-Info-For-SM response at least one MT-SMS Target Node identity or an SMS Router identity shall be present and this shall be an E.164 number within the Network Node Number parameter. In addition, optionally a second Target Node identity or an SMS Router identity may be present as E.164 number within the Additional Number Parameter. In T4 device trigger scenarios in addition to a second Target Node identity, a third Target Node Identity may be present as E.164 number within the Third Number parameter. In addition to the E.164 identity of an MT-SMS Target Node or an SMSRouter, the presence of the Diameter Name/Realm of the corresponding target node or SMS Router follows the hereafter rules: - If Network Node Number contains an MME number for SMS, Network Node Diameter Address shall be present and contain the Diameter address of the MME. - If Network Node Number contains an MSC number, Network Node Diameter Address may be present and shall contain the Diameter address of the MME. - If Network Node Number contains an SGSN number, Network Node Diameter Address shall be present only if the HSS has received the information that SGSN supports the Gdd interface. - If Network Node Number contains an SMS Router number, Network Node Diameter Address may be present and shall contain the SMS Router Diameter address. - If Network Node Number contains an IP-SM-GW number, Network Node Diameter Address may be present and shall contain the IP-SM-GW Diameter address. Similar for Additional Number - Additional Network Node Diameter Address; Similar for Third Number - Third Network Node Diameter Address. In scenarios supporting interworking with 5G System, an E.164 Number and a Diameter Address of the SMSF may be present, for both 3GPP and non-3GPP accesses. In addition: - If Network Node Number contains an SMSF 3GPP number, Network Node Diameter Address may be present and shall contain the SMSF 3GPP Diameter address. - If Network Node Number contains an SMSF Non-3GPP number, Network Node Diameter Address may be present and shall contain the SMSF Non-3GPP Diameter address. 12.2 MAP-MO-FORWARD-SHORT-MESSAGE service 12.2.1 Definition This service is used between the serving MSC or the SGSN or IP-SM-GW and the SMS Interworking MSC to forward mobile originated short messages. The MAP-MO-FORWARD-SHORT-MESSAGE service is a confirmed service using the service primitives given in tableÊ12.2/1. 12.2.2 Service primitives TableÊ12.2/1: MAP-MO-FORWARD-SHORT-MESSAGE Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) SM RP DA M M(=) SM RP OA M M(=) SM RP UI M M(=) C C(=) IMSI C C(=) Correlation ID C C(=) SM Delivery Outcome C C(=) User error C C(=) Provider error O 12.2.3 Parameter use Invoke id See definition in clauseÊ7.6.1."
"SM RP DA See definition in clauseÊ7.6.8. In the mobile originated SM transfer this parameter contains the Service Centre address received from the mobile station. SM RP OA See definition in clauseÊ7.6.8. The MSISDN received from the VLR or from the SGSN is inserted in this parameter in the mobile originated SM transfer. A Dummy MSISDN value is used for MSISDN-less SMS in IMS. In this case the originating user is identified by SIP-URI-A (see Correlation ID). SM RP UI See definition in clauseÊ7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. IMSI See definition in clauseÊ7.6.2.1. The IMSI of the originating subscriber shall be inserted in this parameter in the mobile originated SM transfer. Correlation ID The Correlation ID is composed of an HLR-Id identifying the destination user's HLR, a SIP-URI-B identifying the MSISDN-less destination user, and a SIP-URI-A identifying the originating user. The Correlation ID indicates by its presence that the request is sent in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [134]), and that a Report-SM-Delivery status needs to be sent to the HLR to add the SC address to the MWD. SM Delivery Outcome See definition in clauseÊ7.6.8. This parameter indicates the status of the mobile terminated SM delivery. Shall be present if Correlation ID is present and shall take one of the unsuccessful outcome values. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Facility Not Supported; - System Failure; - SM Delivery Failure; - The reason of the SM Delivery Failure can be one of the following in the mobile originated SM: - unknown Service Centre address; - Service Centre congestion; - invalid Short Message Entity address; - subscriber not Service Centre subscriber; - protocol error. - Unexpected Data Value Provider error For definition of provider errors see clauseÊ7.6.1. 12.3 MAP-REPORT-SM-DELIVERY-STATUS service 12.3.1 Definition This service is used between the gateway MSC and the HLR or the external Short Message Gateway (IP-SM-GW) and the HLR. The MAP-REPORT-SM-DELIVERY-STATUS service is used to set the Message Waiting Data into the HLR or to inform the HLR of successful SM transfer after polling. This service is invoked by the gateway MSC or the external Short Message Gateway (IP-SM-GW). The MAP-REPORT-SM-DELIVERY-STATUS service is a confirmed service using the service primitives given in tableÊ12.3/1. 12.3.2 Service primitives TableÊ12.3/1: MAP-REPORT-SM-DELIVERY-STATUS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSISDN M M(=) IMSI C C(=) Service Centre Address M M(=) SM Delivery Outcome M M(=) Absent Subscriber Diagnostic SM C C(=) GPRS Support Indicator C C(=) Delivery Outcome Indicator C C(=) Additional SM Delivery Outcome C C(=) Additional Absent Subscriber Diagnostic SM C C(=) IP-SM-GW-Indicator C C(=) IP-SM-GW SM Delivery Outcome C C(=) IP-SM-GW Absent Subscriber Diagnostic SM C C(=) Single Attempt Delivery C C(=) Correlation ID C C(=) SMSF 3GPP Delivery Outcome Indicator C C(=) SMSF 3GPP SM Delivery Outcome C C(=) SMSF 3GPP Absent Subscriber Diagnostic SM C C(=) SMSF non-3GPP Delivery Outcome Indicator C C(=) SMSF non-3GPP SM Delivery Outcome C C(=) SMSF non-3GPP Absent Subscriber Diagnostic SM C C(=) MSIsdn-Alert C C(=) User error C C(=) Provider error O 12.3.3 Parameter use Invoke id See definition in clauseÊ7.6.1. MSISDN See definition in clauseÊ7.6.2. When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR following an T4 Submit Trigger (see 3GPP TS 23.682 [148]), MSISDN may not be available. In this case the UE shall be identified by the IMSI and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), MSISDN may not be available. In this case the UE shall be identified by a Correlation ID (SIP-URI-B) and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). IMSI See definition in clauseÊ7.6.2. When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), IMSI may not be available. In this case the IMSI parameter shall be populated with an HLR-ID). Service Centre Address See definition in clauseÊ7.6.2. SM Delivery Outcome See definition in clauseÊ7.6.8. This parameter indicates the status of the mobile terminated SM delivery. Absent Subscriber Diagnostic SM See definition in clauseÊ7.6.8. GPRS Support Indicator See definition in clause 7.6.8. The presence of this parameter is mandatory if the SMS-GMSC supports handling of two delivery outcomes. Delivery Outcome Indicator See definition in clause 7.6.8. Additional SM Delivery Outcome See definition in clause 7.6.8. Additional Absent Subscriber Diagnostic SM See definition in clause 7.6.8. IP-SM-GW Indicator See definition in clause 7.6.8. IP-SM-GW SM Delivery Outcome See definition in clause 7.6.8. IP-SM-GW Absent Subscriber Diagnostic SM See definition in clause 7.6.8. Single Attempt Delivery This parameter indicates the short message is only valid for delivering once, and the HLR/HSS does not need to add the received SC address into MWD list. It may only be present in the case the delivery of the short message failed due to absent subscriber or MS memory capacity exceeded. Editor's Note: Description of the use of this parameter might be needed in 3GPP TS 23.040. Correlation ID The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user. SIP-URI-A and HLR-ID shall be absent from this parameter. SMSF 3GPP Delivery Outcome Indicator See definition in clause 7.6.8. SMSF 3GPP SM Delivery Outcome See definition in clause 7.6.8. SMSF 3GPP Absent Subscriber Diagnostic SM See definition in clause 7.6.8. SMSF Non-3GPP Delivery Outcome Indicator See definition in clause 7.6.8. SMSF Non-3GPP SM Delivery Outcome See definition in clause 7.6.8. SMSF Non-3GPP Absent Subscriber Diagnostic SM See definition in clause 7.6.8. MSIsdn-Alert See definition in clauseÊ7.6.2. This parameter shall be present in case of unsuccessful delivery, when the MSISDN received in the operation is different from the stored MSIsdn-Alert; the stored MSIsdn-Alert is the value that is returned to the gateway MSC. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown Subscriber; - Message Waiting List Full; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.4 MAP-READY-FOR-SM service 12.4.1 Definition This service is used between the MSC and VLR as well as between the VLR and the HLR. The MSC initiates this service if a subscriber indicates memory available situation. The VLR uses the service to indicate this to the HLR. The VLR initiates this service if a subscriber, whose message waiting flag is active in the VLR, has radio contact in the MSC. Also this service is used between the SGSN and the HLR. The SGSN initiates this service if a subscriber indicates memory available situation. The SGSN uses the service to indicate this to the HLR. Also this service is used between the HSS and the MME via an IWF. The MME initiates this service if a subscriber indicates memory available situation. The MME uses the service to indicate this to the HLR. The SGSN initiates this service if a subscriber, whose message waiting flag is active in the SGSN, has radio contact in the GPRS. The MME initiates this service if a subscriber, whose message waiting flag is active in the MME, has radio contact via LTE. Also this service is used between the external Short Message Gateway (IP-SM-GW) and the HLR. The IP-SM-GW initiates this service if a subscriber indicates memory available situation. The IP-SM-GW uses the service to indicate this to the HLR. The IP-SM-GW initiates this service if a subscriber, whose message waiting flag is active in the IP-SM-GW, is reachable in IMS. The MAP-READY-FOR-SM service is a confirmed service using the primitives from tableÊ12.4/1. 12.4.2 Service primitives TableÊ12.4/1: MAP-READY-FOR-SM Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI C C(=) TMSI C C(=) Alert Reason M M(=) Alert Reason Indicator C C(=) Additional Alert Reason Indicator C C(=) Maximum UE Availability Time C C(=) User error C C(=) Provider error O 12.4.3 Parameter use Invoke id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is used always between the VLR and the HLR and between the SGSN and the HLR and between the HSS and the IWF. Between the MSC and the VLR the identification can be either IMSI or TMSI. TMSI See definition in clauseÊ7.6.2. The identification can be either IMSI or TMSI between MSC and VLR. Alert Reason See definition in clauseÊ7.6.8. This parameter indicates if the mobile subscriber is present or the MS has memory available. Alert Reason Indicator See definition in clauseÊ7.6.8. This parameter by its presence indicates the message is sent from SGSN, and by its absence indicates the message is sent from VLR or MME via IWF. Additional Alert Reason Indicator See definition in clauseÊ7.6.8. Maximum UE Availability Time See definition in clauseÊ7.6.8. This information element may be included by the SGSN or MSC when notifying the HLR that the MS is reachable. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown Subscriber; - Facility Not Supported; - System Failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.5 MAP-ALERT-SERVICE-CENTRE service 12.5.1 Definition This service is used between the HLR and the interworking MSC. The HLR initiates this service, if the HLR detects that a subscriber, whose MSISDN is in the Message Waiting Data file, is active or the MS has memory available. This service is also used between an MME (via an IWF), SGSN or an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPPÊTSÊ23.272Ê[143] and 3GPP TS 23.040 [6]) and the SMS-GMSC (possibly via an SMS Router), to indicate that a MS, for which one or more MT SMS have been requested to be retransmitted at a later time, is now available for MT SMS delivery or has moved under the coverage of another MME, SGSN or MSC. This procedure is used according to the call flows described in clause 10.1 of 3GPP TS 23.040 [26]. The MAP-ALERT-SERVICE-CENTRE service is a confirmed service using the primitives from tableÊ12.5/1. 12.5.2 Service primitives TableÊ12.5/1: MAP-ALERT-SERVICE-CENTRE Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSIsdn-Alert M M(=) IMSI C C(=) Correlation ID C C(=) Service Centre Address M M(=) Maximum UE Availability Time C C(=) SMS-GMSC Alert Event C C(=) SMS-GMSC Diameter Address C C(=) New SGSN Number C C(=) New SGSN Diameter Address C C(=) New MME Number C C(=) New MME Diameter Address C C(=) New MSC Number C C(=) User error C C(=) Provider error O 12.5.3 Parameter use Invoke id See definition in clauseÊ7.6.1. MSIsdn-Alert See definition in clauseÊ7.6.2. When the service is used between the HLR and the SMS-IWMSC, the provided MSISDN shall be the one which is stored in the Message Waiting Data file. If no MSISDN is available, the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]) shall be sent and an IMSI or Correlation ID (SIP-URI-B) shall be present. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]) shall be sent and an IMSI shall be present. IMSI When the service is used between the HLR and the SMS-IWMSC, the provided IMSI shall be the identifier which is stored in the Message Waiting Data file if no MSISDN is available in the context of T4 device triggering (see 3GPP TS 23.682 [148]). When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain the IMSI in the request sent from the MME (via an IWF), SGSN or MSC, or the User Identifier Alert previously sent in the MT Forward Short Message response, when the request is sent from the SMS Router to the SMS-GMSC. Correlation ID When the service is used between the HLR and the SMS-IWMSC, the provided SIP-URI-B within the Correlation ID parameter shall be the identifier which is stored in the Message Waiting Data file if no MSISDN is available in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]). HLR-ID and SIP-URI-A shall be absent. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall not be included. Service Centre Address See definition in clauseÊ7.6.2. When the service is used between the HLR and the SMS-IWMSC, this information element shall contain the E.164 number of the Service Center. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain the E.164 number of the SMS-GMSC (or SMS Router) previously received in the SMS-GMSC Address IE in the MT Forward Short Message Request. Maximum UE Availability Time See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall be included, if available. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall not be included. SMS-GMSC Alert Event See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall either indicate that the MS is now available for MT SMS or that the MS has moved under the coverage of another MME, SGSN or MSC. New SGSN Number See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another SGSN. When present, it shall contain the E.164 number of the new SGSN serving the MS. New MME Number See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME. When present, it shall contain the E.164 number of the new MME serving the MS. New SGSN Diameter Address See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element shall be included if available and if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another SGSN. When present, it shall contain the Diameter Identity of the new SGSN serving the MS. New MME Diameter Address See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element shall be included if available and if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME. When present, it shall contain the Diameter Identity of the new MME serving the MS. SMS-GMSC Diameter Address See definition in clauseÊ7.6.2. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain, if available, the Diameter Identity of the SMS-GMSC (or SMS Router) previously received in the SMS-GMSC Diameter Address IE in the MT Forward Short Message Request. New MSC Number See definition in clauseÊ7.6.8.33. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MSC and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MSC. When present, it shall contain the E.164 number of the new MSC serving the MS. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - System Failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.6 MAP-INFORM-SERVICE-CENTRE service 12.6.1 Definition This service is used between the HLR and the gateway MSC (transiting an SMS Router, if present) to inform the Service Centre which MSISDN number is stored in the Message Waiting Data file. If the stored MSISDN number is not the same as the one received from the gateway MSC in the MAP-SEND-ROUTING-INFO-FOR-SM service primitive the stored MSISDN number is included in the message. Additionally the status of MCEF, MNRF, MNRG, MNR5G and MNR5GN3G flags and the inclusion of the particular Service Centre address in the Message Waiting Data list is informed to the gateway MSC when appropriate. If the HLR has stored a single MNRR, the value is included in the Absent Subscriber Diagnostic SM parameter. If the HLR has stored a second MNRR, the value of the MNRR for the MSC is included in the Absent Subscriber Diagnostic SM parameter and the value of the MNRR for the SGSN is included in the Additional Absent Subscriber Diagnostic SM parameter. The MAP-INFORM-SERVICE-CENTRE service is a non-confirmed service using the primitives from tableÊ12.6/1. 12.6.2 Service primitives TableÊ12.6/1: MAP-INFORM-SERVICE-CENTRE Parameter name Request Indication Invoke Id M M(=) MSIsdn-Alert C C(=) MWD Status C C(=) Absent Subscriber Diagnostic SM C C(=) Additional Absent Subscriber Diagnostic SM C C(=) SMSF 3GPP Absent Subscriber Diagnostic SM C C(=) SMSF Non 3GPP Absent Subscriber Diagnostic SM C C(=) 12.6.3 Parameter use Invoke id See definition in clauseÊ7.6.1. MSIsdn-Alert See definition in clauseÊ7.6.2. This parameter refers to the MSISDN stored in a Message Waiting Data file in the HLR. MWD Status See definition in clauseÊ7.6.8. This parameter indicates the status of the MCEF, MNRF, MNRG, MNR5G and MNR5GN3G flags and the status of the particular SC address presence in the Message Waiting Data list. Absent Subscriber Diagnostic SM See definition in clause 7.6.8. Additional Absent Subscriber Diagnostic SM See definition in clause 7.6.8. SMSF 3GPP Absent Subscriber Diagnostic SM See definition in clause 7.6.8. SMSF Non 3GPP Absent Subscriber Diagnostic SM See definition in clause 7.6.8. 12.7 MAP-SEND-INFO-FOR-MT-SMS service 12.7.1 Definition This service is used between the MSC and the VLR. The service is invoked by the MSC receiving a mobile terminated short message to request subscriber related information from the VLR. The MAP-SEND-INFO-FOR-MT-SMS service is a confirmed service using the primitives from tableÊ12.7/1. 12.7.2 Service primitives TableÊ12.7/1: MAP-SEND-INFO-FOR-MT-SMS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) SM RP DA M M(=) IMSI C C(=) MSISDN C C(=) User error C C(=) Provider error O 12.7.3 Parameter use Invoke id See definition in clauseÊ7.6.1. SM RP DA See definition in clauseÊ7.6.8. This parameter shall contain either an IMSI or an LMSI. IMSI See definition in clauseÊ7.6.2. This parameter shall be present if the SM RP DA parameter contains an LMSI; otherwise it shall be absent. MSISDN See definition in clauseÊ7.6.2. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown subscriber; - Unidentified Subscriber; - Absent subscriber; - Unexpected Data Value; - Data Missing; - Illegal subscriber; - Illegal equipment; - Subscriber busy for MT SMS; - System Failure. Provider error For definition of provider errors see clauseÊ7.6.1. 12.8 MAP-SEND-INFO-FOR-MO-SMS service 12.8.1 Definition This service is used between the MSC and the VLR. The service is invoked by the MSC which has to handle a mobile originated short message request to request the subscriber related information from the VLR. The MAP-SEND-INFO-FOR-MO-SMS service is a confirmed service using the primitives from tableÊ12.8/1. 12.8.2 Service primitives TableÊ12.8/1: MAP-SEND-INFO-FOR-MO-SMS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Service Centre Address M M(=) MSISDN C C(=) User error C C(=) Provider error O 12.8.3 Parameter use Invoke id See definition in clauseÊ7.6.1. Service Centre Address See definition in clauseÊ7.6.2. MSISDN See definition in clauseÊ7.6.2. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Teleservice Not Provisioned; - Call Barred; - Unexpected Data Value; - Data Missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.9 MAP-MT-FORWARD-SHORT-MESSAGE service 12.9.1 Definition This service is used between the gateway MSC and the serving MSC or the SGSN (transiting an SMS Router, if present) or the IP-SM-GW to forward mobile terminated short messages. The MAP-MT-FORWARD-SHORT-MESSAGE service is a confirmed service using the service primitives given in tableÊ12.9/1. 12.9.2 Service primitives TableÊ12.9/1: MAP-MT-FORWARD-SHORT-MESSAGE Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) SM RP DA M M(=) SM RP OA M M(=) SM RP UI M M(=) C C(=) More Messages To Send C C(=) SM Delivery Timer C C(=) SM Delivery Start Time C C(=) SMS Over IP Only Indicator C C(=) Correlation ID C C(=) Maximum Retransmission Time C C(=) SMS-GMSC Address C C(=) SMS-GMSC Diameter Address C C(=) Requested Retransmission Time C C(=) User Identifier Alert C C(=) User error C C(=) Provider error O 12.9.3 Parameter use Invoke id See definition in clauseÊ7.6.1. SM RP DA See definition in clauseÊ7.6.8. This parameter can contain either an IMSI or a LMSI. The use of the LMSI is an operator option. The LMSI can be provided if it is received from the HLR. The IMSI is used if the use of the LMSI is not available. This parameter is omitted (i.e. is present and takes the value ""noSM-RP-DA"") in the mobile terminated subsequent SM transfers. When a Correlation ID is present, the IMSI parameter within SM RP DA shall be populated with the HLR-ID and the destination user is identified by the SIP-URI-B within the Correlation ID. SM RP OA See definition in clauseÊ7.6.8. The Service Centre address received from the originating Service Centre is inserted in this parameter. This parameter is omitted in the mobile terminated subsequent SM transfers. SM RP UI See definition in clauseÊ7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. A short message transfer protocol data unit may also be inserted in this parameter in the message delivery acknowledgement from the MSC or from the SGSN to the Service Centre. More Messages To Send See definition in clauseÊ7.6.8. The information from the MMS indication received from the Service Centre is inserted in this parameter. SM Delivery Timer See definition in clauseÊ7.6.8. SM Delivery Start Time See definition in clauseÊ7.6.8. SMS Over IP Only Indicator This indicator indicates by its presence that the IP-SM-GW shall try to deliver the short message via IMS without retrying to other domains. It shall be present in messages sent to the IP-SM-GW following a T4-Submit Trigger message (see 3GPP TS 23.682 [148]) but not in messages sent to MSC or SGSN (possibly transiting an SMS-Router). The indicator also indicates to the IP-SM-GW by its presence that the IMSI within the message is a real IMSI and not a MT-Correlation ID allocated by the IP-SM-GW. Correlation ID The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user and the SIP-URI-A identifying the (MSISDN-less) originating user. HLR-ID shall be absent from this parameter. Maximum Retransmission Time See definition in clauseÊ7.6.8. SMS-GMSC Address See definition in clauseÊ7.6.8. This information element shall be present if the Maximum Retransmission Time IE is present in the message. When present, it shall contain the E.164 number of the SMS-GMSC in the request sent by the SMS-GMSC or the E.164 number of the SMS Router in the request sent by the SMS Router. SMS-GMSC Diameter Address See definition in clauseÊ7.6.8. This information element shall be present if available and if the Maximum Retransmission Time IE is present in the message. When present, it shall contain the Diameter Identity of the SMS-GMSC in the request sent by the SMS-GMSC or the Diameter Identity of the SMS Router in the request sent by the SMS Router. Requested Retransmission Time See definition in clauseÊ7.6.8. This information element may only be present if the MT Forward Short Message Response contains the User error set to Absent Subscriber_SM and if the Maximum Retransmission Time information element is present in the MT Forward Short Message Request. It may be included by an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPPÊTSÊ23.272Ê[143] and 3GPP TS 23.040 [6]) or the SGSN if the UE is using a power saving mechanism (such as extended idle mode DRX) and the UE is currently not reachable. The Requested Retransmission Time shall not exceed the Maximum Retransmission Time received from the SMS-GMSC. User-Identifier-Alert See definition in clauseÊ7.6.8. This information element shall be present in the message from the SMS Router to the SMS-GMSC, if the Requested Retransmission Time IE is present in the message. When present, this information shall contain an MT Correlation ID. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unidentified subscriber; - Absent Subscriber_SM; - Subscriber busy for MT SMS; - Facility Not Supported; - Illegal Subscriber indicates that delivery of the mobile terminated short message failed because the mobile station failed authentication; - Illegal equipment indicates that delivery of the mobile terminated short message failed because an IMEI check failed, i.e. the IMEI was prohibited-listed or not permitted-listed; - System Failure; - SM Delivery Failure: - The reason of the SM Delivery Failure can be one of the following in the mobile terminated SM: - memory capacity exceeded in the mobile equipment; - protocol error; - mobile equipment does not support the mobile terminated short message service. - Unexpected Data Value; - Data Missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.10 MAP-MT-FORWARD-SM-FOR-VGCS service 12.10.1 Definition This service is used between the SMS gateway MSC and the Group Call Anchor MSC to forward mobile terminated short messages into an ongoing voice group call. The MAP-MT-FORWARD-SM-FOR-VGCS service is a confirmed service using the service primitives given in tableÊ12.10/1. 12.10.2 Service primitives TableÊ12.10/1: MAP-MT-FORWARD-SM-VGCS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) ASCI Call Reference M M(=) SM RP OA M M(=) SM RP UI M M(=) C C(=) Dispatcher List C C(=) Ongoing Call Indicator C C(=) User error C C(=) Provider error O 12.10.3 Parameter use Invoke id See definition in clauseÊ7.6.1. ASCI Call Reference Group call reference. This item is used to access the VGCS-GCR within the Anchor_MSC. SM RP OA See definition in clauseÊ7.6.8. The Service Centre address received from the originating Service Centre is inserted in this parameter. SM RP UI See definition in clauseÊ7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. A short message transfer protocol data unit may also be inserted in this parameter in the message delivery acknowledgement from the MSC to the Service Centre. Dispatcher List A list of identities (international E.164 phone numbers) identifying the dispatchers of the VGCS call. It shall be present if received from the GCR; otherwise shall be absent. Ongoing Call Indicator Indicates by its presence that the VGCS call is ongoing. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - System Failure; - Unexpected Data Value. Provider error For definition of provider errors see clauseÊ7.6.1. 13 Network-Requested PDP Context Activation services 13.1 MAP_SEND_ROUTING_INFO_FOR_GPRS service 13.1.1 Definition This service is used by the GGSN to request GPRS routing information from the HLR. 13.1.2 Service primitives TableÊ13.1/1: MAP_SEND_ROUTING_INFO_FOR_GPRS Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) GGSN address C C(=) C C(=) GGSN number M M(=) SGSN address C C(=) Mobile Not Reachable Reason C C(=) User error C C(=) Provider error O 13.1.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. GGSN address This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR. GGSN number See definition in clauseÊ7.6.2. SGSN address This parameter shall be present if the outcome of the Send Routing Info For GPRS request to the GPRS application process in the HLR is positive. Mobile Not Reachable Reason This parameter shall be present if the outcome of the Send Routing Info For GPRS request to the GPRS application process in the HLR is positive and the MNRG flag in the HLR is set. See definition in clause 7.6.3.51. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Absent Subscriber; - System Failure; - Data Missing; - Unexpected Data Value; - Unknown Subscriber. The diagnostic in the Unknown Subscriber may indicate ""Imsi Unknown"" or ""Gprs Subscription Unknown"". - Call Barred; This error will indicate that the received PDP PDUs in the GGSN shall be barred for this MS due to Operator Determined Barring. (The CallBarringCause must be the operatorBarring.) Provider error These are defined in clause 7.6.1. 13.2 MAP_FAILURE_REPORT service 13.2.1 Definition This service is used by the GGSN to inform the HLR that network requested PDP-context activation has failed. 13.2.2 Service primitives TableÊ13.2/1: MAP_FAILURE_REPORT Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) GGSN address C C(=) C C(=) GGSN number M M(=) User error C C(=) Provider error O 13.2.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. GGSN address This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR. GGSN number See definition in clauseÊ7.6.2. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error These are defined in clause 7.6.1. 13.3 MAP_NOTE_MS_PRESENT_FOR_GPRS service 13.3.1 Definition This service is used by the HLR to inform the GGSN that the MS is present for GPRS again. 13.3.2 Service primitives TableÊ13.3/1: MAP_NOTE_MS_PRESENT_FOR_GPRS Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) GGSN address C C(=) SGSN address M M(=) User error C C(=) Provider error O 13.3.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. GGSN address This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR. SGSN address See definition in clauseÊ7.6.2. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error These are defined in clause 7.6.1. 13A Location Service Management Services 13A.1 MAP-SEND-ROUTING-INFO-FOR-LCS Service 13A.1.1 Definition This service is used between the GMLC and the HLR to retrieve the routing information needed for routing a location service request to the servicing VMSC, SGSN, MME or 3GPP AAA server. The MAP-SEND-ROUTING-INFO-FOR-LCS is a confirmed service using the primitives from tableÊ13A.1/1. 13A.1.2 Service Primitives TableÊ13A.1/1: MAP-SEND-ROUTING-INFO-FOR-LCS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MLC Number M M(=) MSISDN C C(=) C C(=) IMSI C C(=) C C(=) LMSI C C(=) Network Node Number C C(=) GPRS Node Indicator C C(=) Additional Number C C(=) Supported LCS Capability Sets C C(=) Additional LCS Capability Sets C C(=) MME Name C C(=) SGSN Name C C(=) SGSN Realm C C(=) AAA Server Name C C(=) V-GMLC Address U C(=) Additional V-GMLC Address U C(=) H-GMLC Address C C(=) PPR Address U C(=) User error C C(=) Provider error O 13A.1.3 Parameter Use Invoke id See definition in clauseÊ7.6.1. MLC Number See definition in clauseÊ7.6.2. MSISDN See definition in clauseÊ7.6.2. The request shall carry either the IMSI or MSISDN. The response shall carry whichever of these was not included in the request (see 3GPP TS 23.271 for details). IMSI See definition in clauseÊ7.6.2. LMSI See definition in clauseÊ7.6.2. It is an operator option to provide this parameter from the VLR; it is mandatory for the HLR to include the LMSI in a successful response, if the VLR has used the LMSI. Network Node Number See definition in clauseÊ7.6.2. This parameter is provided in a successful response. If the Network Node Number and Additional Number are received in the GMLC, the Network Node Number is used in preference to the Additional Number. If the serving node has no ISDN number, the HLR shall populate the Network Node Number parameter with a dummy ISDN number of ""0"". GPRS Node Indicator See definition in clauseÊ7.6.8. The presence of this parameter is mandatory only if the SGSN number is sent in the Network Node Number. Additional Number See definition in clauseÊ7.6.2. This parameter is provided in a successful response. If the Network Node Number and Additional Number are received in the GMLC, the Network Node Number is used in preference to the Additional Number. Supported LCS Capability Sets See definition in clauseÊ7.6.11. This parameter indicates the LCS capability of the serving node that is indicated by the Network Node Number. This parameter is provided only if LCS capability sets are available in HLR and Network Node Number is present in this message. Additional LCS Capability Sets See definition in clauseÊ7.6.11. This parameter indicates the LCS capability of the serving node that is indicated by the Additional Number. This parameter is provided only if LCS capability sets are available in HLR and Additional Number is present in this message. MME Name See definition in clauseÊ7.6.2. This parameter is provided in a successful response when the serving node is an MME. SGSN Name See definition in clauseÊ7.6.2. This parameter is provided in a successful response when the serving node is an SGSN and the SGSN has indicated its support for Lgd interface. SGSN Realm See definition in clauseÊ7.6.2. This parameter is provided in a successful response when the serving node is an SGSN and the SGSN has indicated its support for Lgd interface. AAA Server Name See definition in clauseÊ7.6.2. This parameter is provided in a successful response when the serving node is a 3GPPÊAAA server. V-GMLC address See definition in clauseÊ7.6.2. . This parameter indicates the V-GMLC address of the serving node that is indicated by the Network Node Number. Additional V-GMLC address See definition in clauseÊ7.6.2. This parameter indicates the V-GMLC address of the serving node that is indicated by the Additional Number. This parameter is provided only if additional LCS capability sets are available in HLR and Additional Number is present in this message. H-GMLC address See definition in clauseÊ7.6.2. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. PPR address See definition in clauseÊ7.6.2. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown subscriber; - Absent Subscriber; - Facility Not Supported; - System failure; - Unexpected Data Value; - Data missing; - Unauthorised requesting network. Provider error For definition of provider errors see clauseÊ7.6.1. 13A.2 MAP-PROVIDE-SUBSCRIBER-LOCATION Service 13A.2.1 Definition This service is used by a GMLC to request the location of a target MS from the visited MSC or SGSN at any time. This is a confirmed service using the primitives from tableÊ13A.2/1."
"13A.2.2 Service Primitives TableÊ13A.2/1: Provide_Subscriber_Location Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Location Type M M(=) MLC Number M M(=) LCS Client ID M M(=) Privacy Override U C(=) IMSI C C(=) MSISDN C C(=) LMSI C C(=) LCS Priority C C(=) LCS QoS C C(=) IMEI U C(=) Supported GAD Shapes C C(=) LCS-Reference Number C C(=) LCS Codeword C C(=) LCS Service Type Id C C(=) LCS Privacy Check C C(=) Area Event Info C C(=) H-GMLC Address C C(=) Reporting PLMN List C C(=) PeriodicLDRInfo C C(=) MO-LR Short Circuit Indicator C C(=) C C(=) Location Estimate M M(=) GERAN Positioning Data C C(=) UTRAN Positioning Data C C(=) GERAN GANSS Positioning Data C C(=) UTRAN GANSS Positioning Data C C(=) UTRAN Additional Positioning Data C C(=) UTRAN Barometric Pressure Measurement C C(=) UTRAN Civic Address C C(=) Age of Location Estimate C C(=) Additional Location Estimate C C(=) Deferred MT-LR Response Indicator C C(=) Cell Id Or SAI C C(=) Accuracy Fulfilment Indicator C C(=) Target Serving Node for Handover C C(=) User error C C(=) Provider error O 13A.2.3 Parameter Definition and Use All parameters are defined in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.271 [26a]. Location Type This parameter identifies the type of location information requested. MLC Number This is the E.164 number of the requesting GMLC. LCS Client ID This parameter provides information related to the identity of an LCS client. Privacy Override This parameter indicates if MS privacy is overridden by the LCS client when the GMLC and VMSC or SGSN for an MT-LR are in the same country. IMSI The IMSI is provided to identify the target MS. At least one of the IMSI or MSISDN is mandatory. MSISDN The MSISDN is provided to identify the target MS. At least one of the IMSI or MSISDN is mandatory. LMSI The LMSI shall be provided if previously supplied by the HLR. This parameter is only used in the case of the MT-LR for CS domain. LCS Priority This parameter indicates the priority of the location request. LCS QoS This parameter indicates the required quality of service in terms of response time and accuracy. IMEI The requirements for its presence are specified in 3GPP TS 23.271 [26a]. Supported GAD Shapes This parameter indicates which of the shapes defined in 3GPP TS 23.032 [122] are supported. LCS-Reference Number This parameter shall be included if a deferred MT-LR procedure is performed for a UE available event, an area event or a periodic positioning event. LCS Codeword See definition in clause 7.6.11.18. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. LCS Service Type Id See definition in clause 7.6.11.15. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. LCS Privacy Check See definition in clause 7.6.11. The requirements for its and its components presence are specified in 3GPP TS 23.271 [26a]. Area Event Info See definition in clauseÊ7.6.11. The parameter shall be included if a deferred MT-LR procedure is performed for an area event. H-GMLC address See definition in clauseÊ7.6.2. The parameter shall be included if a deferred MT-LR procedure is performed for a UE available event, an area event or a periodic positioning event. Location Estimate This parameter provides the location estimate if this is encoded in one of the supported geographical shapes. Otherwise this parameter shall consist of one octet, which shall be discarded by the receiving node. GERAN Positioning Data This parameter indicates the usage of each positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If Positioning Data received from the RAN contains no Positioning Methods, Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. UTRAN Positioning Data This parameter indicates the usage of each positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no Positioning Methods, UTRAN Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. GERAN GANSS Positioning Data This parameter indicates the usage of each GANSS positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If GANSS Positioning Data received from the RAN contains no GANSS method, GERAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. UTRAN GANSS Positioning Data This parameter indicates the usage of each GANSS positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no GANSS Positioning Data Set, UTRAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Additional Positioning Data This parameter indicates the usage of each Additional positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no Additional Positioning Data Set, UTRAN Additional Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Barometric Pressure Measurement This parameter indicates the uncompensated barometric pressure measurement at the MS. The absence of this parameter implies that a barometric pressure measurement was not available or could not be successfully obtained. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Civic Address This parameter indicates the civic address of the MS. The absence of this parameter implies that a civic address was not available or could not be successfully obtained. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. Age of Location Estimate This parameter indicates how long ago the location estimate was obtained. Additional Location Estimate This parameter provides the location estimate when not provided by the Location Estimate parameter. It may be sent only if the parameter Supported GAD Shapes has been received in the Provide Subscriber Location indication and the shape to be included is supported by the GMLC. Deferred MT-LR Response Indicator See definition in clauseÊ7.6.11.2. Cell Id Or SAI For GERAN access, this parameter indicates Global Cell Identifier of the cell that the served subscriber is currently attached to. For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to. This parameter is included only for North American Emergency Calls as described in 3GPP TS 23.271 [26a]. Accuracy Fulfilment Indicator See definition in clauseÊ7.6.11.28. MO-LR Short Circuit Indicator This parameter indicates whether MO-LR Short Circuit is permitted for periodic location. Reporting PLMN List This parameter indicates a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made. Periodic LDR information This parameter indicates the reporting amount and reporting interval of deferred periodic location. Target Serving Node for Handover This parameter provides the address of the target side serving node for handover of an IMS Emergency Call. User error This parameter is sent by the responder when the location request has failed or cannot proceed and if present, takes one of the following values defined in clauseÊ7.6.1. - System Failure; - Data Missing; - Unexpected Data Value; - Facility Not Supported; - Unidentified Subscriber; - Illegal Subscriber; - Illegal Equipment; - Absent Subscriber (diagnostic information may also be provided); - Unauthorised requesting network; - Unauthorised LCS Client with detailed reason; - Position method failure with detailed reason. Provider error These are defined in clause 7.6.1. 13A.3 MAP-SUBSCRIBER-LOCATION-REPORT Service 13A.3.1 Definition This service is used by a VMSC or SGSN to provide the location of a target MS to a GMLC when a request for location is either implicitly administered or made at some earlier time. This is a confirmed service using the primitives from tableÊ13A.3/1. 13A.3.2 Service Primitives TableÊ13A.3/1: Subscriber_Location_Report Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) LCS Event M M(=) LCS Client ID M M(=) Network Node Number M M(=) IMSI C C(=) MSISDN C C(=) NA-ESRD C C(=) C C(=) NA-ESRK C C(=) C C(=) IMEI U C(=) Location Estimate C C(=) GERAN Positioning Data C C(=) UTRAN Positioning Data C C(=) GERAN GANSS Positioning Data C C(=) UTRAN GANSS Positioning Data C C(=) UTRAN Additional Positioning Data C C(=) UTRAN Barometric Pressure Measurement C C(=) UTRAN Civic Address C C(=) Age of Location Estimate C C(=) LMSI U C(=) GPRS Node Indicator C C(=) Additional Location Estimate C C(=) Deferred MT-LR Data C C(=) LCS-Reference Number C C(=) C C(=) NA-ESRK Request C C(=) Cell Id Or SAI C C(=) H-GMLC Address C C(=) C C(=) LCS Service Type Id C C(=) Pseudonym Indicator C C(=) Accuracy Fulfilment Indicator C C(=) Sequence Number C C(=) Periodic LDR Info C C(=) MO-LR Short Circuit Indicator C C(=) C C(=) Target Serving Node for Handover C C(=) Reporting PLMN List C C(=) User error C C(=) Provider error O 13A.3.3 Parameter Definition and Use All parameters are defined in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in. 3GPP TS 23.271 [26a]. LCS Event This parameter indicates the event that triggered the Subscriber Location Report. LCS Client ID This parameter provides information related to the identity of the recipient LCS client. Network Node Number See definition in clauseÊ7.6.2. This parameter provides the address of the sending node. IMSI The IMSI shall be provided if available to the VMSC or SGSN. MSISDN The MSISDN shall be provided if available to the VMSC or SGSN. NA-ESRD If the target MS has originated an emergency service call in North America, the NA-ESRD shall be provided by the VMSC if available. If the target MS has originated an emergency service call in North America and NA-ESRK Request is included in Subscriber_Location_Report-Arg, an NA-ESRK or NA-ESRD, but not both, may also be included in the response to the MSC, see 3GPP TS 23.271 [26a]. NA-ESRK If the target MS has originated an emergency service call in North America, the NA-ESRK shall be provided by the VMSC if assigned. If the target MS has originated an emergency service call in North America and NA-ESRK Request is included in Subscriber_Location_Report-Arg, an NA-ESRK or NA-ESRD, but not both, may also be included in the response to the MSC, see 3GPP TS 23.271 [26a]. IMEI The requirements for its presence are specified in 3GPP TS 23.271 [26a]. Location Estimate This parameter provides the location estimate. The absence of this parameter implies that a location estimate was not available or could not be successfully obtained. If the obtained location estimate is not encoded in one of the supported geographical shapes then this parameter shall consist of one octet, which shall be discarded by the receiving node. GERAN Positioning Data This parameter indicates the usage of each positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If Positioning Data received from the RAN contains no Positioning Methods, Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. UTRAN Positioning Data This parameter indicates the usage of each positioning method that was successfullyattempted to determine the location estimate. If Position Data received from the RAN contains no Positioning Methods, UTRAN Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. GERAN GANSS Positioning Data This parameter indicates the usage of each GANSS positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If GANSS Positioning Data received from the RAN contains no GANSS method, GERAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. UTRAN GANSS Positioning Data This parameter indicates the usage of each GANSS positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no GANSS Positioning Data Set, UTRAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Additional Positioning Data This parameter indicates the usage of each Additional positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no Additional Positioning Data Set, UTRAN Additional Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Barometric Pressure Measurement This parameter indicates the uncompensated barometric pressure measurement at the MS. The absence of this parameter implies that a barometric pressure measurement was not available or could not be successfully obtained. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Civic Address This parameter indicates the civic address of the MS. The absence of this parameter implies that a civic address was not available or could not be successfully obtained. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. Age of Location Estimate This parameter indicates how long ago the location estimate was obtained. LMSI The LMSI may be provided if assigned by the VLR. GPRS Node Indicator See definition in clauseÊ7.6.8. This presence of this parameter is mandatory only if the SGSN number is sent in the Network Node Number. Additional Location Estimate This parameter provides the location estimate when not provided by the Location Estimate parameter.. Deferred MT-LR Data See definition in clauseÊ7.6.11.3. LCS-Reference Number This parameter shall be included if the Subscriber Location Report is the response to a deferred MT location request. NA-ESRK Request If the target MS has originated an emergency service call in North America, NA-ESRK Request may be included to indicate that the MSC is able to accept NA-ESRK in the Response message, see clause 7.6.11.19. Cell Id Or SAI For GERAN access, this parameter indicates Global Cell Identifier of the cell that the served subscriber is currently attached to. For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to. This parameter is included only for Emergency Calls as described in 3GPP TS 23.271 [26a]. H-GMLC address See definition in clauseÊ7.6.2. The parameter shall be included if the Subscriber Location Report is the response to a deferred MT location request for a UE available event, an area event or a periodic positioning event. This parameter shall be included in a Subscriber Location Report response if a deferred MO-LR TTTP procedure is initiated for a periodic positioning event. LCS Service Type Id See definition in clause 7.6.11.15. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. Pseudonym Indicator This parameter indicates by its presence that the pseudonym is required. Refer to 3GPP TS 23.271 [26a]. Accuracy Fulfilment Indicator For a mobile terminated periodic LDR, this parameter indicates whether the obtained location estimate satisfies the requested accuracy or not, provided that this indication is obtained from RAN or the UE with the location estimate. Periodic LDR Information This parameter refers to the periodic reporting interval and reporting amount of the deferred periodic location. MO-LR Short Circuit Indicator This parameter indicates whether MO-LR Short Circuit is permitted for periodic location. Reporting PLMN List This parameter indicates a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made. Sequence Number This parameter refers to the number of the periodic location reports completed. The sequence number would be set to 1 in the first location report and increment by 1 for each new report. When the number reaches the reporting amountÊvalue, the H-GMLC (for a periodic MT-LR or a periodic MO-LR transfer to third party) will know the procedure is complete. For details see 3GPP TS 23.271 [26a]. Target Serving Node for Handover This parameter provides the address of the target side serving node for handover of an IMS Emergency Call. User error This parameter is sent by the responder when the received message contains an error, cannot be forwarded or stored for an LCS client or cannot be accepted for some other reason and if present, takes one of the following values defined in clauseÊ7.6.1. - System Failure; - Data Missing; - Unexpected Data Value; - Resource Limitation; - Unknown Subscriber; - Unauthorised requesting network; - Unknown or unreachable LCS Client. Provider error These are defined in clause 7.6.1. 13A.4 Void 13A.4.1 Void 13A.4.2 Void 13A.4.3 Void 13A.5 Void 13A.5.1 Void 13A.5.2 Void 13A.5.3 Void 13A.6 Void 13A.6.1 Void 13A.6.2 Void 13A.6.3 Void 13A.7 Void 13A.7.1 Void 13A.7.2 Void 13A.7.3 Void 13A.8 Void 13A.8.1 Void 13A.8.2 Void 13A.8.3 Void 13A.9 Void 13A.9.1 Void 13A.9.2 Void 13A.9.3 Void 14 General 14.1 Overview Clauses 14 to 17 specify the protocol elements to be used to provide the MAP services described in clauseÊ7. ClauseÊ15 specifies the elements of procedures for the MAP protocol. ClauseÊ16 specifies the mapping onto TC service primitives. ClauseÊ17 specifies the application contexts, operation packages and abstract syntaxes for the MAP protocol as well as the encoding rules to be applied. 14.2 Underlying services The MAP protocol relies on the services provided by the Transaction Capabilities (TC) of Signalling System Number No. 7, as referenced in clauseÊ6. 14.3 Model The MAP Protocol Machine (MAP PM) can be modelled as a collection of service state machines (SSMs) - one per MAP specific service invoked - coordinated by a MAP dialogue control function with its one state machine: MAP dialogue state machine (DSM). There are two types of Service State Machines: Requesting Service State Machines (RSM) and Performing Service State Machines (PSM). A new invocation of a MAP PM is employed on the receipt of a MAP-OPEN request primitive or a TC-BEGIN indication primitive. Each invocation controls exactly one MAP dialogue. For each MAP specific service invoked during a dialogue, a MAP RSM is created at the requestor's side and a MAP PSM is created at the performer's side. This modelling is used only to facilitate understanding and the MAP behaviour descriptions and is not intended to suggest any implementation. SDL descriptions are organised according to this model. How the MAP-service-user and the MAP refer to a MAP dialogue (i.e. a MAP PM invocation) is a local implementation matter. How TC dialogue identifiers are assigned to a MAP PM invocation is also a local implementation matter. 14.4 Conventions The behaviour of the MAP PM depends on the application-context-name associated with the dialogue. One major difference is that the MAP requests the transfer of the application-context-name by TC only for those contexts which do not belong to the so-called ""version one context set"". The ""version one context set"" is a set of application-contexts which model the behaviour of a MAP V1 implementation according to the latest phase 1 version of GSMÊ09.02. This set is defined in clauseÊ15. The procedures described in clauseÊ15 are used when the application-context-name does not refer to a dialogue between an MSC and its VLR. When the application-context-name refers to a dialogue between an MSC and its VLR the MAP PM procedures are a local implementation matter. 15 Elements of procedure 15.1 Handling of unknown operations Unknown operations (i.e. a standard operation introduced in a later version of the MAP specification, or a private operation) can be introduced into MAP in a backwards compatible way. This means that the receiver of an unknown operation shall, if the dialogue state allows it, send a TC-REJECT component to the sender of the operation indicating 'unrecognised operation' and continue with the processing of further components or messages exchanged within the dialogue as if the unknown operation had not been received. The standardised structure of a MAP dialogue shall not be affected by the invocation of unknown operations, i.e. if a dialogue uses only a TC-BEGIN message which is acknowledged by a TC-END message, a TC-CONTINUE message shall not be used to invoke an unknown operation. However the standardised structure of a MAP dialogue may be affected by the rejection of unknown operations, i.e. if a dialogue uses only a TC-BEGIN message which is acknowledged by a TC-END message, a TC-CONTINUE message followed by a TC-END message may be used to carry the rejection of an unknown operation and the response to the standardised operation. The entity which initiated a dialogue whose standardised structure is a TC-BEGIN message which is acknowledged by a TC-END message shall not send any messages in that dialogue after the TC-BEGIN. Note that if the dialogue structure is affected as described in this paragraph the TC-CONTINUE shall include the dialogue portion required to confirm the acceptance of the dialogue. Unknown operations may be invoked in the following types of message (there is no restriction as to how many unknown operations can be invoked in a message): - TC-BEGIN: the component to invoke the unknown operation shall follow the component of the standard operation which is included in this message. - TC-CONTINUE: the component to invoke the unknown operation may be transported as the only component in a stand-alone message or may be grouped with existing operations. In the latter case a specific sequencing of components is not required. - TC-END: if the component to invoke the unknown operation is grouped with an existing operation a specific sequencing of components is not required The TC-REJECT component may be sent in the following messages: - TC-CONTINUE or TC-END: either as the only component of the message or grouped with an existing component. The choice is up to the MAP-Service User. If the received message contains only unknown operations the MAP-Service User shall send the TC-REJECT components in a TC-CONTINUE message to the peer entity, if the dialogue state allows it. If the received message contains unknown operations and standard operations and the standardised structure of the dialogue requires the response to the standard operation to be sent within a TC-END message, then the MAP-Service User may send the response to the standard operations and the TC-REJECT components for the unknown operations in a TC-CONTINUE message followed by a TC-END message. Neither a specific distribution of the components to the TC messages nor a specific sequencing of components is required. Note that the SDL diagrams of clauses 19Ê-Ê25 do not show the report to the MAP-Service User about the reception of the unknown operation. This has been done for simplicity of description; the MAP PM may inform the MAP-Service User. The sender of the unknown operation shall ensure that there is enough room in the used message for the unknown operation. 15.2 Dialogue establishment The establishment of a MAP dialogue involves two MAP-service-users: the dialogue-initiator and the dialogue-responder. This procedure is driven by the following signals: - a MAP-OPEN request primitive from the dialogue-initiator; - a TC-BEGIN indication primitive occurring at the responding side; - a MAP-OPEN response primitive from the dialogue-responder; - the first TC-CONTINUE indication primitive occurring at the initiating side; and under specific conditions: - a TC-END indication primitive occurring at the initiating side; - a TC-U-ABORT indication primitive occurring at the initiating side; - a TC-P-ABORT indication primitive occurring at the initiating side. One instance of the MAP dialogue state machine runs at the initiating side, and one at the responding side. 15.2.1 Behaviour at the initiating side The behaviour of the MAP dialogue state machine at the initiating side is defined in sheets 1ÊÐÊ8 of the process MAP_DSM (figure 15.6/3). Sheet 3: When the MAP dialogue state machine at the initiating side is waiting for a response from the responding side, a TC-END indication which echoes the AC name which was sent in the TC-BEGIN indicates acceptance of the dialogue. Sheet 3: If the dialogue opening is accepted, any components included in the TC-END are processed and passed to the MAP-Service User. The dialogue is closed by sending a MAP-CLOSE to the MAP-Service User. Sheet 3, sheet 4, sheet 5, sheet 6, sheet 7, sheet 8: when a dialogue is terminated, the MAP dialogue state machine terminates all instances of the Requesting_MAP_SSM which are active for this dialogue. Sheet 4: A TC-P-ABORT with an abort parameter Incorrect_Transaction_Portion indicates that the responding side does not support a MAP version higher than 1. This triggers a MAP-OPEN confirm indicating that the dialogue is refused, with a refuse reason potential version incompatibility. The MAP-Service User may then decide to retry the dialogue at MAP version 1. Sheet 8: When the MAP dialogue state machine at the initiating side is waiting for a response from the responding side, a TC-CONTINUE indication which echoes the AC name which was sent in the TC-BEGIN indicates acceptance of the dialogue. Sheet 8: If the dialogue opening is accepted, any components included in the TC-CONTINUE are processed and passed to the MAP-Service User. The dialogue has then reached the established state. 15.2.2 Behaviour at the responding side The behaviour of the MAP dialogue state machine at the responding side is defined in sheets 0ÊÐÊ14 of the process MAP_DSM (figure 15.6/3). Sheet 9: If no application context information is included in the TC-BEGIN indication, this implies a MAP version 1 dialogue. An explicit application context indicating version 1 is treated as abnormal behaviour. Sheet 11: The v1 application context name which corresponds to a v1 operation is derived using the information in table 15.2/1. TableÊ15.2/1: Mapping of V1 operation codes on to application-context-names Operation Application-context-name (note 1) updateLocation networkLocUpContext-v1 cancelLocation locationCancellationContext-v1 provideRoamingNumber roamingNumberEnquiryContext-v1 insertSubscriberData subscriberDataMngtContext-v1 deleteSubscriberData subscriberDataMngtContext-v1 sendParameters infoRetrievalContext-v1 networkLocUpContext-v1 (note 2) beginSubscriberActivity networkFunctionalSsContext-v1 sendRoutingInfo locationInfoRetrievalContext-v1 performHandover handoverControlContext-v1 reset resetContext-v1 activateTraceMode tracingContext-v1 deactivateTraceMode tracingContext-v1 sendRoutingInfoForSM shortMsgGatewayContext-v1 forwardSM shortMsgRelayContext-v1 reportSM-deliveryStatus shortMsgGatewayContext-v1 noteSubscriberPresent mwdMngtContext-v1 alertServiceCentreWithoutResult shortMsgAlertContext-v1 checkIMEI EquipmentMngtContext-v1 NOTE 1: These symbolic names refer to the object identifier value defined in clauseÊ17 and allocated to each application-context used for the MAP. NOTE 2: The choice between the application contexts is based on the parameters received in the operation. Sheet 12: If the dialogue is accepted, each component present in the TC-BEGIN is forwarded to an instance of a Performing_MAP_SSM, by executing the procedure Process_Components. Sheet 13: If the MAP dialogue state machine receives a MAP-OPEN response with a result accepted, it waits for any MAP specific service request or response primitives or a MAP-DELIMITER request. Sheet 13, sheet 14: When a dialogue is terminated, the MAP dialogue state machine terminates all instances of the Requesting_MAP_SSM or Performing_MAP_SSM which are active for this dialogue. Sheet 14: A MAP-DELIMITER request triggers a TC-CONTINUE request to accept the dialogue. The dialogue has then reached the established state. 15.3 Dialogue continuation Once established the dialogue is said to be in a continuation phase. The behaviour of the MAP dialogue state machine in this phase is defined in sheets 15ÊÐÊ17 of the process MAP_DSM (figure 15.6/3). Both MAP users can request the transfer of MAP APDUs until one of them requests the termination of the dialogue. Normal closure of an established dialogue is shown on sheet 16; abnormal termination is shown on sheet 17. 15.4 Load control If an entity which should respond to a MAP dialogue opening request is overloaded, it uses the AC of the request to determine whether to discard the request. The priority level allocated to each application-context is described in clauseÊ5, tables 5.1/1, 5.1/2, and 5.1/3. 15.5 Procedures for MAP specific services This clauseÊdescribes the MAP procedures for MAP specific services. These procedures are driven by the following types of event: - a MAP specific request or a MAP specific response primitive; - a component handling primitive from TC. A Service State Machine is activated when of one of the following signals is received: - a MAP request primitive, which activates a requesting SSM; - a TC-INVOKE indication primitive without a linked identifier, which activates a performing SSM. For component handling primitives there are two types of event: - events which activate a Service State Machine or which can be related to an existing one; - events which cannot be related to a Service State Machine. 15.5.1 Service invocation The behaviour of the requesting SSM which handles a service is defined by the SDL for the process Requesting_MAP_SSM. The requesting SSM receives a MAP service request from the MAP-Service User via the MAP dialogue state machine and sends a TC-INVOKE request to TCAP. When a confirm is received from TCAP via the MAP dialogue state machine, the requesting SSM forwards a MAP service confirm to the MAP-Service User. The response to a MAP service invocation may come in the form of a linked request. If the linked request corresponds to a class 4 operation, this is handled by the requesting SSM. If the linked request corresponds to a class 1, 2 or 3 operation, the MAP dialogue state machine sends a notification to the requesting SSM and creates an instance of a performing SSM to handle the linked request. The test ""Linked_Operation_Allowed"" on sheet 3 of the process Requesting_MAP_SSM takes the (TRUE) exit if the definition of the parent operation includes the received linked operation as a permitted linked operation; otherwise the test takes the (FALSE) exit. The mapping of MAP specific services on to remote operations is given in tableÊ16.2/1. 15.5.2 Void 15.5.3 Service invocation receipt The behaviour of the performing SSM which handles a service is defined by the SDL for the process Performing_MAP_SSM. The performing SSM receives a TC-INVOKE component from TCAP via the MAP dialogue state machine and sends a MAP service indication to the MAP-Service User. When a MAP service response is received from the MAP-Service User via the MAP dialogue state machine, the performing SSM forwards a TC-RESULT or TC-U-ERROR component to TCAP. 15.5.4 Void 15.5.5 Handling of components received from TC The procedure Process_Components shows the handling of components received in a TC-BEGIN, TC-CONTINUE or TC-END message. Sheet 2: If a linked invoke component corresponds to a class 4 operation, the MAP dialogue state machine sends it to the requesting SSM instance identified by the linked invoke ID. If a linked invoke component corresponds to any other class of operation, the MAP dialogue state machine sends a notification to the requesting SSM instance identified by the linked invoke ID, creates an instance of a performing SSM and sends the invoke component to it. 15.6 SDL descriptions The following SDL specification describes a system which includes three blocks: MAP-user, MAP-provider and TC. Such a system resides in each network component supporting MAP and communicates with its peers via the lower layers of the signalling network which are part of the environment. Only the MAP-provider is fully described in this clause. The various types of processes which form the MAP-User block and the TC block are described respectively in clauses 18 to 25 of the present document and in CCITT Recommendation Q.774. The MAP-Provider block communicates with the MAP_USER via two channels U1 and U2. Via U1 the MAP-provider receives the MAP request and response primitives. Via U2 it sends the MAP indication and confirm primitives. The MAP-Provider block communicates with TC via two channels P1 and P2. Via P1 the MAP-Provider sends all the TC request primitives. Via P2 it receives all the TC indication primitives. The MAP-Provider block is composed of the four following types of process: a) MAP_DSM: This type of process handles a dialogue for transport of MAP messages. There exists one process instance per MAP dialogue. b) Load_Ctrl: This type of process is in charge of load control. There is only one instance of this process in each system. c) Requesting_MAP_SSM: This type of process handles a MAP service requested during a dialogue. An instance of this process is created by the instance of the MAP_DSM process for each requested MAP service. d) Performing_MAP_SSM: This type of process handles a MAP service performed during a dialogue. An instance of this process is created by the instance of the MAP_DSM process for each MAP service to be performed. A process MAP_DSM exchanges external signals with other blocks as well as internal signals with the other processes of the MAP-Provider block. The external signals are either MAP service primitives or TC service primitives. The signal routes used by the various processes are organised as follows: a) A process MAP_DSM receives and sends events from/to the MAP_user via signal route User1/User2. These routes use channels U1 and U2 respectively. b) A process MAP_DSM receives and sends events from/to the TCAP via signal route TC1/TC2. These routes use channels P1 and P2 respectively. c) A process MAP_DSM receives and sends events from/to the LOAD_CTRL process via signal route Load1/Load2. These routes are internal. d) A process MAP_DSM sends events to the Performing_MAP_SSM processes via signal route Intern1. This route is internal. e) A process MAP_DSM sends events to the Requesting_MAP_SSM processes via signal route Intern2. This route is internal. f) A process Performing_MAP_SSM sends events to the MAP_USER via signal route User3. This route uses channel U2. g) A process Performing_MAP_SSM sends events to the TCAP via signal route TC3. This route uses channel P1. h) A process Requesting_MAP_SSM sends events to the MAP_USER via signal route User4. This route uses channel U2. i) A process Requesting_MAP_SSM sends events to the TCAP via signal route TC4. This route uses channel P1. Figure 15.6/1: System MAP_Stack Figure 15.6/2: Block MAP_Provider Figure 15.6/3a: Process MAP_DSM (sheet 1) Figure 15.6/3b: Process MAP_DSM (sheet 2) Figure 15.6/3c: Process MAP_DSM (sheet 3) Figure 15.6/3d: Process MAP_DSM (sheet 4) Figure 15.6/3e: Process MAP_DSM (sheet 5) Figure 15.6/3f: Process MAP_DSM (sheet 6) Figure 15.6/3g: Process MAP_DSM (sheet 7) Figure 15.6/3h: Process MAP_DSM (sheet 8) Figure 15.6/3i: Process MAP_DSM (sheet 9) Figure 15.6/3j: Process MAP_DSM (sheet 10) Figure 15.6/3k: Process MAP_DSM (sheet 11) Figure 15.6/3l: Process MAP_DSM (sheet 12) Figure 15.6/3m: Process MAP_DSM (sheet 13) Figure 15.6/3n: Process MAP_DSM (sheet 14) Figure 15.6/30: Process MAP_DSM (sheet 15) Figure 15.6/3p: Process MAP_DSM (sheet 16) Figure 15.6/3q: Process MAP_DSM (sheet 17) Figure 15.6/4a: Procedure Process_Components (sheet 1) Figure 15.6/4b: Procedure Process_Components (sheet 2) Figure 15.6/4c: Procedure Process_Components (sheet 3) Figure 15.6/4d: Procedure Process_Components (sheet 4) Figure 15.6/4e: Procedure Process_Components (sheet 5) Figure 15.6/5: Process Load_Ctrl Figure 15.6/6a: Process Requesting_MAP_SSM (sheet 1) Figure 15.6/6b: Process Requesting_MAP_SSM (sheet 2) Figure 15.6/6c: Process Requesting_MAP_SSM (sheet 3) Figure 15.6/6d: Process Requesting_MAP_SSM (sheet 4) Figure 15.6/8a: Process Performing_MAP_SSM (sheet 1) Figure 15.6/8b: Process Performing_MAP_SSM (sheet 2) 16 Mapping on to TC services 16.1 Dialogue control Dialogue control services are mapped to TC dialogue handling services. The TC-UNI service is not used by the MAP PM. 16.1.1 Directly mapped parameters The following parameters of the MAP-OPEN request and indication primitives are directly mapped on to the corresponding parameters of the TC-BEGIN primitives: - destination address; - originating address. 16.1.2 Use of other parameters of dialogue handling primitives 16.1.2.1 Dialogue Id The value of this parameter is associated with the MAP PM invocation in an implementation dependent manner. 16.1.2.2 Application-context-name The application-context-name parameter of a MAP primitive is mapped to the application-context-name parameter of TC dialogue handling primitives according to the rules described in clauseÊ15.1. 16.1.2.3 User information The user information parameter of TC dialogue primitives is used to carry the MAP dialogue APDUs. 16.1.2.4 Component present This parameter is used by the MAP PM as described in CCITT Recommendation Q.771. It is not visible to the MAP user. 16.1.2.5 Termination The value of this parameter of the TC-END request primitive is set by the MAP PM on the basis of the release method parameter of the MAP-CLOSE request primitive, except when the dialogue state machine is in the state DIALOGUE INITIATED, in which case the Termination parameter shall always indicate ""pre-arranged end"". 16.1.2.6 P-Abort-Cause Values of the P-abort-cause parameter are mapped to the values of the provider-reason parameter of the MAP P ABORT indication primitive according to tableÊ16.1/1, except in the dialogue initiated phase for the ""incorrectTransactionPortion"" and ""noCommonDialoguePortion"" values which are mapped to the ""potential incompatibility problem"" value of the refuse-reason parameter of the MAP-OPEN cnf primitive. The source parameter in the MAP-P-ABORT ind takes the value ""TC problem"". 16.1.2.7 Quality of service The quality of service of TC request primitives is set by the MAP as shown below."
"- Return option: ""Return message on error"" or ""Discard message on error"" as required by the network operator; - Sequence control: ""Sequence guaranteed"" or ""Sequence result not guaranteed"" as required by the network operator; - ""Sequence guaranteed"" shall be used when a segmented result is to be transferred (e.g. subscriber data in response to SendParameters). It may also be appropriate to use Sequence guaranteed when a series of InsertSubscriberData, ProcessAccessSignalling or ForwardAccessSignalling operations is used. It is essential that the TC message which indicates acceptance of a dialogue opening request is received by the dialogue initiator before any subsequent message in that dialogue; otherwise the dialogue opening will fail. The dialogue responder shall ensure that this requirement is met by: - Sending the dialogue acceptance message in a TC END, if the dialogue structure requires it; or - Using ""Sequence guaranteed"", if the dialogue acceptance message is sent in a TC CONTINUE; or - Waiting until the dialogue acceptance message has been acknowledged by the dialogue initiator before sending a subsequent message, if the dialogue acceptance message is sent in a TC CONTINUE. TableÊ16.1/1: Mapping of P-Abort cause in TC-P-ABORT indication on to provider-reason in MAP-P-ABORT indication TC P-Abort cause MAP provider-reason unrecognised message type provider malfunction unrecognised transaction Id supporting dialogue released badlyFormattedTransactionPortion provider malfunction incorrectTransactionPortion provider malfunction (note) resourceLimitation resource limitation abnormalDialogue provider malfunction noCommonDialoguePortion version incompatibility NOTE: Or version incompatibility in the dialogue initiated phase. 16.2 Service specific procedures Specific services are mapped to TC component handling services. 16.2.1 Directly mapped parameters The Invoke Id parameter of the MAP request and indication primitive is directly mapped on to the Invoke Id parameter of the component handling primitives. 16.2.2 Use of other parameters of component handling primitives 16.2.2.1 Dialogue Id The value of this parameter is associated with the MAP PM invocation in an implementation dependent manner. 16.2.2.2 Class The value of this parameter is set by the MAP PM according to the type of the operation to be invoked. 16.2.2.3 Linked Id When a service response is mapped to a class 4 operation, the value of this parameter is set by the MAP PM and corresponds to the value assigned by the user to the initial service request (i.e. the value of the invoke ID parameter of the request primitive). Otherwise if such a parameter is included in MAP request/indication primitives it is directly mapped to the linked ID parameter of the associated TC INVOKE request/indication primitives. 16.2.2.4 Operation When mapping a request primitive on to a Remote Operations PDU (invoke), the MAP PM shall set the operation code according to the mapping described in tableÊ16.2/1. When mapping a response primitive on to a Remote Operations service, the MAP PM shall set the operation code of the TC-RESULT-L/NL primitive (if required) to the same value as the one received at invocation time. TableÊ16.2/1: Mapping of MAP specific services on to MAP operations MAP-SERVICE operation MAP-ACTIVATE-SS activateSS MAP-ACTIVATE-TRACE-MODE activateTraceMode MAP-ALERT-SERVICE-CENTRE alertServiceCentre MAP-ANY-TIME-INTERROGATION anyTimeInterrogaton MAP_AUTHENTICATION_FAILURE_REPORT authenticationFailureReport MAP-ANY-TIME-MODIFICATION anyTimeModification MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION anyTimeSubscriptionInterrogation MAP-CANCEL-LOCATION cancelLocation MAP-CHECK-IMEI checkIMEI MAP-DEACTIVATE-SS deactivateSS MAP-DEACTIVATE-TRACE-MODE deactivateTraceMode MAP-DELETE-SUBSCRIBER-DATA deleteSubscriberData MAP-ERASE-CC-ENTRY eraseCC-Entry MAP-ERASE-SS eraseSS MAP-FAILURE-REPORT failureReport MAP-FORWARD-ACCESS-SIGNALLING forwardAccessSignalling MAP-FORWARD-CHECK-SS-INDICATION forwardCheckSsIndication MAP-FORWARD-GROUP-CALL-SIGNALLING forwardGroupCallSignalling MAP-MT-FORWARD-SHORT-MESSAGE mt-forwardSM MAP-MO-FORWARD-SHORT-MESSAGE mo-forwardSM MAP-GET-PASSWORD getPassword MAP-INFORM-SERVICE-CENTRE informServiceCentre MAP-INSERT-SUBSCRIBER-DATA insertSubscriberData MAP-INTERROGATE-SS interrogateSs MAP-IST-ALERT istAlert MAP-IST-COMMAND istCommand MAP-NOTE-MS-PRESENT-FOR-GPRS noteMsPresentForGprs MAP-NOTE-SUBSCRIBER-DATA-MODIFIED noteSubscriberDataModified MAP-PREPARE-GROUP-CALL prepareGroupCall MAP-PREPARE-HANDOVER prepareHandover MAP-PREPARE-SUBSEQUENT-HANDOVER prepareSubsequentHandover MAP-PROCESS-ACCESS-SIGNALLING processAccessSignalling MAP-PROCESS-GROUP-CALL-SIGNALLING processGroupCallSignalling MAP-PROCESS-UNSTRUCTURED-SS-REQUEST processUnstructuredSS-Request MAP-PROVIDE-ROAMING-NUMBER provideRoamingNumber MAP-PROVIDE-SUBSCRIBER-LOCATION provideSubscriberLocation MAP-PROVIDE-SUBSCRIBER-INFO provideSubscriberInfo MAP-PURGE-MS purgeMS MAP-READY-FOR-SM readyForSM MAP-REGISTER-CC-ENTRY registerCC-Entry MAP-REGISTER-PASSWORD registerPassword MAP-REGISTER-SS registerSS MAP-REMOTE-USER-FREE remoteUserFree MAP-REPORT-SM-DELIVERY-STATUS reportSmDeliveryStatus MAP-RESET reset MAP-RESTORE-DATA restoreData MAP-SEND_GROUP-CALL_END_SIGNAL sendGroupCallEndSignal MAP-SEND-GROUP-CALL-INFO sendGroupCallInfo MAP-SEND-END-SIGNAL sendEndSignal MAP-SEND-AUTHENTICATION-INFO sendAuthenticationInfo MAP-SEND-IMSI sendIMSI MAP-SEND-IDENTIFICATION sendIdentification MAP-SEND-ROUTING-INFO-FOR-SM sendRoutingInfoForSM MAP-SEND-ROUTING-INFO-FOR-GPRS sendRoutingInfoForGprs MAP-SEND-ROUTING-INFO-FOR-LCS sendRoutingInfoForLCS MAP-SEND-ROUTING-INFORMATION sendRoutingInfo MAP-SET-REPORTING-STATE setReportingState MAP-STATUS-REPORT statusReport MAP-SUBSCRIBER-LOCATION-REPORT subscriberLocationReport MAP-SUPPLEMENTARY-SERVICE-INVOCATION-NOTIFICATION ss-Invocation-Notification MAP-UNSTRUCTURED-SS-NOTIFY unstructuredSS-Notify MAP-UNSTRUCTURED-SS-REQUEST unstructuredSS-Request MAP-UPDATE-GPRS-LOCATION updateGprsLocation MAP-UPDATE-LOCATION updateLocation MAP-NOTE-MM-EVENT NoteMM-Event MAP-UPDATE-VCSG-LOCATION updateVcsgLocation MAP-CANCEL-VCSG-LOCATION cancelVcsgLocation 16.2.2.5 Error The error parameter in a TC-U-ERROR indication primitive is mapped to the user error parameter in the MAP confirm primitive of the service associated with the operation to which the error is attached. The user error parameter in MAP response primitives is mapped to the error parameter of the TC U ERROR request primitive, except for ""initiating-release"" and ""resource-limitation"" which are mapped to the problem code parameter of the TC-U-REJECT request primitive. 16.2.2.6 Parameters The parameters of MAP specific request and indication primitives are mapped to the argument parameter of TC-INVOKE primitives. The parameters of MAP specific response and confirm primitives are mapped to the result parameter of TC-RESULT-L primitives, the parameter of TC-U-ERROR primitives or the argument of TC-INVOKE primitives when mapping on linked class 4 operations is used. 16.2.2.7 Time out The value of this parameter is set by the MAP PM according to the type of operation invoked. 16.2.2.8 Last component This parameter is used by the MAP PM as described in CCITT Recommendation Q.711. It is not visible from the MAP user. 16.2.2.9 Problem code 16.2.2.9.1 Mapping to MAP User Error The following values of the user error parameter are mapped as follows to values of the TC problem code parameter. These values are generated by the MAP user. This mapping is valid from the TC-U-REJECT indication primitive to the MAP confirm service primitive and from the MAP response service primitive to the TC-U-REJECT request primitive. TableÊ16.2/2: Mapping of MAP User Error parameter on to TC problem code in TC-U-REJECT primitives MAP User Error TC problem code resource limitation resource limitation initiating release initiating release 16.2.2.9.2 Mapping to MAP Provider Error parameter The following values of the TC problem code parameter of the TC-U-REJECT indication primitive are mapped as follows to values of the MAP Provider Error parameter of the MAP confirm primitive. TableÊ16.2/3: Mapping of TC problem code in TC-U-REJECT on to MAP Provider Error parameter TC problem code MAP Provider Error duplicated invoke Id duplicated invoke id unrecognised operation service not supported mistyped parameter mistyped parameter The following values of the problem code parameters of the TC-L-REJECT primitive are mapped to values of the provider error parameter of the MAP confirm primitive as follows. TableÊ16.2/4: Mapping of TC problem code in TC-L-REJECT on to MAP Provider Error parameter TC problem code MAP Provider Error return result unexpected unexpected response from the peer return error unexpected unexpected response from the peer 16.2.2.9.3 Mapping to diagnostic parameter The following values of the problem code parameter of the TC-R-REJECT and TC-U-REJECT primitive are mapped to values of the diagnostic parameter of the MAP-NOTICE indication primitive as follows: TableÊ16.2/5: Mapping of TC problem code of TC-R-REJECT and TC-U-REJECT on to diagnostic parameter TC problem code MAP diagnostic General problem - abnormal event detected by the peer Invoke problem - unrecognised linked ID - abnormal event detected by the peer - linked response unexpected - response rejected by the peer - unexpected linked operation - response rejected by the peer Return result problem - unrecognised invoke ID - response rejected by the peer - return result unexpected - response rejected by the peer - mistyped parameter - response rejected by the peer Return error problem - unrecognised invoke ID - response rejected by the peer - return error unexpected - response rejected by the peer - unrecognised error - response rejected by the peer - unexpected error - response rejected by the peer - mistyped parameter - response rejected by the peer The following values of the problem code parameter of the TC-L-REJECT primitive are mapped to values of the diagnostic parameter of the MAP-NOTICE indication primitive as follows. TableÊ16.2/6: Mapping of TC problem code of TC-L-REJECT on to diagnostic parameter TC problem code MAP diagnostic General problems - abnormal event received from the peer Invoke problem - unrecognised linked ID - abnormal event received from the peer Return result problem - unrecognised invoke ID - abnormal event received from the peer Return error problem - unrecognised invoke ID - abnormal event received from the peer 17 Abstract syntax of the MAP protocol 17.1 General This clauseÊspecifies the Abstract Syntaxes for the Mobile Application Part as well as the associated set of Operations and Errors, using the Abstract Syntax Notation One (ASN.1), defined in ITU-T Recommendations X.680 and X.681 with additions as defined in clauseÊ17.1.4 on Compatibility Considerations and the OPERATION and ERROR external information object classes, defined in ITU-T Recommendation X.880. The Abstract Syntax is defined for all interfaces specified in clauseÊ4.4 except for the A- and B-interfaces. The Mobile Application Part protocol is defined by two Abstract Syntaxes: - one Abstract Syntax which encompass all Operations and Errors identified by the various MAP subsystem numbers. This Abstract Syntax represents the set of values each of which is a value of the ASN.1 type TCAPMessages. TCMessage as defined in ITU-T Recommendation Q.773 with the component relationconstraint clauses resolved by the operation and error codes included in the ASN.1 modules MAP-*Operations and MAP-Errors. However, only the subset of this abstract syntax which is required by the procedures defined for an entity needs to be supported. - one Abstract Syntax identified by the OBJECT IDENTIFIER value MAP-DialogueInformation.map-DialogueAS. This Abstract Syntax represents the set of values each of which is a value of the ASN.1 type MAP-DialogueInformation.MAP-DialoguePDU. Such a value of the ASN.1 single-ASN.1-type element is contained within the user-information element of the TCAPMessages.DialoguePortion ASN.1 type. This Abstract Syntax name is to be used as a direct reference. 17.1.1 Encoding rules The encoding rules which are applicable to the defined Abstract Syntaxes are the Basic Encoding Rules for Abstract Syntax Notation One, defined in ITU-T Recommendation X.690 with the same exceptions as in ITU-T Recommendation Q.773, clauseÊ4 Message Representation. When the definite form is used for length encoding, a data value of length less than 128 octets must have the length encoded in the short form. When the long form is employed to code a length, the minimum number of octets shall be used to code the length field. OCTET STRING values and BIT STRING values must be encoded in a primitive form. There is no restriction to the use of empty constructors (e.g. an empty SEQUENCE type). That is, the encoding of the content of any data value shall consist of zero, one or more octets. 17.1.2 Use of TC The mapping of OPERATION and ERROR to TC components is defined in ETS 300 287 (version 2) which is based on ITU-T Recommendation Q.773. NOTE 1: The class of an operation is not stated explicitly but is specified as well in the ASN.1 operation definition. Class 1: RESULT and ERROR appear in ASN.1 operation definition. Class 2: only ERROR appears in ASN.1 operation definition. Class 3: only RESULT appears in ASN.1 operation definition. Class 4: both RESULT and ERROR do not appear in ASN.1 operation definition. The field ""ARGUMENT"", ""PARAMETER"" or ""RESULT"" (for information objects of class OPERATION and ERROR) is always optional from a syntactic point of view. However, except when specifically mentioned with the ASN.1 comment ""-- optional"" , the ""parameter"" part of a component has to be considered as mandatory from a semantic point of view. When an optional element is missing in an invoke component or in an inner data structure while it is required by the context, an error component is returned if specified in the information object associated with the operation ; the associated type of error is ""DataMissing"". This holds also when the entire parameter of an invoke component is missing while it is required by the context. NOTE 2: When a mandatory element is missing in the parameter or inner data structure of any component, a reject component is returned (if the dialogue still exists). The problem code to be used is ""Mistyped parameter"". The Timer Values used in the operation definitions are indicated as ASN.1 comments. The Timer Value Ranges are: s = from 3 seconds to 10 seconds; m = from 15 seconds to 30 seconds; ml = from 1 minute to 10 minutes; l = from 28 hours to 38 hours. 17.1.2.1 Use of Global Operation and Error codes defined outside MAP An entity supporting an application context greater than 2 shall be capable of receiving an operation or error code, within an application context defined in GSM 29.002, encoded as either an Object Identifier (as defined in ITU-T Recommendation X.690 ) or an integer value (as defined in clauseÊ17.5). Related restrictions regarding the use of Object Identifiers are as follows: - The length of the Object Identifier shall not exceed 16 octets and the number of components of the Object Identifier shall not exceed 16. - Object Identifiers shall be used only for operations or errors defined outside of GSM 29.002. - Global error codes may be sent only in response to a global operation. If a standard operation is received then a global error code shall not be sent in response. Handling of an unknown operation codes by the receiving entity is defined in clauseÊ15.1.1. 17.1.3 Use of information elements defined outside MAP An information element or a set of information elements (messages) transparently carried in the Mobile Application Part but defined in other recommendations/technical specifications are handled in one of the following ways: i) The contents of each information element (without the octets encoding the identifier and the length in the recommendation/technical specification where it is defined unless explicitly stated otherwise) is carried as the value of an ASN.1 type derived from the OCTET STRING data type. Additionally, the internal structure may be explained by means of comments. In case of misalignment the referred to recommendation/technical specification takes precedence. ii) The complete information element (including the octets encoding the identifier and the length in the recommendation/technical specification where it is defined) or set of information elements and the identity of the associated protocol are carried as the value of the ExternalSignalInfo data type defined in the present document. Where more than one information element is carried, the information elements are sent contiguously with no filler octets between them. 17.1.4 Compatibility considerations The following ASN.1 modules conform to ITU-T Recommendation X.680 and X.681 . An extension marker (""..."") is used wherever future protocol extensions are foreseen. The ""..."" construct applies only to SEQUENCE and ENUMERATED data types. An entity supporting a version greater than 1 shall not reject an unsupported extension following ""..."" of that SEQUENCE or ENUMERATED data type. The Encoding Rules from clauseÊ17.1.1 apply to every element of the whole Transfer Syntax especially to the ASN.1 type EXTERNAL. The extension container ""privateExtensionList"" is defined in this specification in order to carry extensions which are defined outside this specification. Private extensions can be defined by, for example, network operators, manufacturers, and regional standardisation bodies. Private extensions shall: 1) if included in operations of an AC of V2, follow the extension marker and be tagged using PRIVATE tags up to and including 29. NOTE: This type of extension is in most cases used only within a PLMN. 2) if included in operations of an AC of V3 or higher: be included only in the Private Extension Container that is defined in the specification. NOTE: This type of extension can be used between PLMNs. Private extensions shall not be included in v2 supplementary service operations. Private extensions shall not be included within user error for RegisterCCEntry and EraseCCEntry operations. PCS extensions shall be included in the PCS Extension Container that is defined in this specification. In order to improve extensibility, a few error parameters have been defined as a CHOICE between the version 2 description and a SEQUENCE including the version 2 description and an extension container. Operations used in a v2-application-context must consider only the first alternative while operations used in a vn-application-context (n>2) must consider only the second alternative. 17.1.5 Structure of the Abstract Syntax of MAP For each MAP parameter which has to be transferred by a MAP Protocol Data Unit (MAP message), there is a PDU field (an ASN.1 type) which has the same name as the corresponding parameter, except for the differences required by the ASN.1 notation (blanks between words are removed or replaced by hyphen, the first letter of the first word is capital and the first letter of each of the following words ise capitalised, e.g. ""no reply condition time"" is mapped to ""NoReplyConditionTime""). Additionally some words may be abbreviated as follows: bs basic service ch call handling cug closed user group ho handover ic incoming call id identity info information mm mobility management lcs location services ms mobile service oc outgoing call om operation & maintenance pw Password sm short message service ss supplementary service The MAP protocol is composed of several ASN.1 modules dealing with either operations, errors, data types, and, if applicable, split into those dealing with mobile services, call handling services, supplementary services and short message services. For operations and errors the code values are given as parameters, in order to allow use of the defined information objects also by other protocols (e.g. 3GPP TS 24.080 [38]). The ASN.1 source lines are preceded by line-numbers at the left margin in order to enable the usage of the cross-reference in annexÊA. The module containing the definition of the operation packages for MAP is: 1. MAP-OperationPackages. The module containing the definition of the application contexts for MAP is: 2. MAP-ApplicationContexts. The module containing the data types for the Abstract Syntax to be used for TCAPMessages.DialoguePortion for MAP is: 3. MAP-DialogueInformation. The module containing the supported operations is: 4. MAP-Protocol. The modules containing all operation definitions for MAP are: 5. MAP-MobileServiceOperations; 6. MAP-OperationAndMaintenanceOperations; 7. MAP-CallHandlingOperations; 8. MAP-SupplementaryServiceOperations; 9. MAP-ShortMessageServiceOperations; 10. MAP-Group-Call-Operations; 11. MAP-LocationServiceOperations. The module containing all error definitions for MAP is: 12. MAP-Errors. Modules containing all data type definitions for MAP are: 13. MAP-MS-DataTypes; 14. MAP-OM-DataTypes; 15. MAP-CH-DataTypes; 16. MAP-SS-DataTypes; 17. MAP-SS-Code; 18. MAP-SM-DataTypes; 19. MAP-ER-DataTypes; 20. MAP-CommonDataTypes; 21. MAP-TS-Code; 22. MAP-BS-Code; 23. MAP-ExtensionDataTypes; 24. MAP-GR-DataTypes; 25. MAP-LCS-DataTypes. References are made also to modules defined outside of the present document. They are defined in the technical specification Mobile Services Domain, technical specification Transaction Capability and ITU-T Recommendation X.880 respectively: MobileDomainDefinitions; TCAPMessages, DialoguePDUsÊ; Remote-Operations-Information-Objects. 17.1.6 Application Contexts The following informative table lists the latest versions of the Application Contexts used in this specification, with the operations used by them and, where applicable, whether or not the operation description is exactly the same as for previous versions. Information in 17.6 & 17.7 relates only to the ACs in this table. AC Name AC Version Operations Used Comments locationCancellationContext v3 cancelLocation equipmentMngtContext V3 checkIMEI imsiRetrievalContext v2 sendIMSI infoRetrievalContext v3 sendAuthenticationInfo interVlrInfoRetrievalContext v3 sendIdentification handoverControlContext v3 prepareHandover forwardAccessSignalling sendEndSignal processAccessSignalling prepareSubsequentHandover the syntax of this operation has been extended in comparison with release 98 version mwdMngtContext v3 readyForSM msPurgingContext v3 purgeMS shortMsgAlertContext v2 alertServiceCentre resetContext v3 reset networkUnstructuredSsContext v2 processUnstructuredSS-Request unstructuredSS-Request unstructuredSS-Notify tracingContext v3 activateTraceMode deactivateTraceMode networkFunctionalSsContext v2 registerSS eraseSS activateSS deactivateSS registerPassword interrogateSS getPassword shortMsgMO-RelayContext v3 mo-forwardSM shortMsgMT-RelayContext v3 mt-forwardSM shortMsgMT-VGCS-RelayContext v3 mt-forwardSM-VGCS shortMsgGatewayContext v3 sendRoutingInfoForSM reportSM-DeliveryStatus InformServiceCentre the syntax of this operation has been extended in comparison with release 96 version networkLocUpContext v3 updateLocation forwardCheckSs-Indication restoreData insertSubscriberData activateTraceMode the syntax is the same in v1 & v2 gprsLocationUpdateContext v3 updateGprsLocation insertSubscriberData activateTraceMode subscriberDataMngtContext v3 insertSubscriberData deleteSubscriberData roamingNumberEnquiryContext v3 provideRoamingNumber locationInfoRetrievalContext v3 sendRoutingInfo gprsNotifyContext v3 noteMsPresentForGprs gprsLocationInfoRetrievalContext v4 sendRoutingInfoForGprs failureReportContext v3 failureReport callControlTransferContext v4 resumeCallHandling subscriberInfoEnquiryContext v3 provideSubscriberInfo anyTimeEnquiryContext v3 anyTimeInterrogation anyTimeInfoHandlingContext v3 anyTimeSubscriptionInterrogation anyTimeModification ss-InvocationNotificationContext v3 ss-InvocationNotification groupCallControlContext v3 prepareGroupCall processGroupCallSignalling forwardGroupCallSignalling sendGroupCallEndSignal reportingContext v3 setReportingState statusReport remoteUserFree callCompletionContext v3 registerCC-Entry eraseCC-Entry istAlertingContext v3 istAlert ServiceTerminationContext v3 istCommand locationSvcEnquiryContext v3 provideSubscriberLocation subscriberLocationReport locationSvcGatewayContext v3 sendRoutingInfoForLCS mm-EventReportingContext v3 noteMM-Event subscriberDataModificationNotificationContext v3 noteSubscriberDataModified authenticationFailureReportContext v3 authenticationFailureReport resourceManagementContext v3 releaseResources groupCallInfoRetievalContext v3 sendGroupCallInfo vcsgLocationUpdateContext v3 updateVcsgLocation insertSubscriberData vcsgLocationCancelContext v3 cancelVcsgLocation NOTE (*): The syntax of the operations is not the same as in previous versions unless explicitly stated In the word-text of ASN.1 Modules hidden text is used for marking the begin (.$modulename), interrupt (.#), continuation (.$) and end (.#END) of ASN.1 Source. This allows to automatically extract the ASN.1 Sources. These markers should not be deleted! In addition, hidden text is also used to overcome some compiler restrictions In addition no line break should occur when printing a paragraph in ASN.1 source, otherwise the line-numbering of word is inconsistent with the line-numbering in Annex A. For Completeness the module MAP-Frame is included as hidden text. .$MAP-Frame DEFINITIONS ::= BEGIN IMPORTS Component, TCMessage FROM TCAPMessages dialogue-as-id, DialoguePDU FROM DialoguePDUs updateLocation FROM MAP-Protocol map-DialogueAS, MAP-DialoguePDU FROM MAP-DialogueInformation map-ac FROM MAP-ApplicationContexts ; ZZZZ-Dummy ::= NULL .#END 17.2 Operation packages 17.2.1 General aspects This clauseÊdescribes the operation-packages which are used to build the application-contexts defined in clauseÊ17.3. Each operation-package is a specification of the roles of a pair of communicating objects (i.e. a pair of MAP-Providers), in terms of operations which they can invoke of each other. The grouping of operations into one or several packages does not necessarily imply any grouping in terms of Application Service Elements. The following ASN.1 information object class is used to describe operation-packages in this clause: OPERATION-PACKAGE ::= CLASS { &Both OPERATION OPTIONAL, &Consumer OPERATION OPTIONAL, &Supplier OPERATION OPTIONAL, &id OBJECT IDENTIFIER UNIQUE OPTIONAL } WITH SYNTAX { [ OPERATIONS &Both ] [ CONSUMER INVOKES &Supplier ] [ SUPPLIER INVOKES &Consumer ] [ ID &id ] } Since the application-context definitions provided in clauseÊ17.3 use only an informal description technique, only the type notation is used in the following clauses to define operation-packages. The following definitions are used throughout this clause (n>=2): - v1-only operation: An operation which shall be used only in v1 application-contexts; - vn-only operation: An operation which shall be used only in vn application-contexts; - v(n-1)-operation: An operation whose specification has not been modified since the MAP v(n-1) specifications or if the modifications are considered as not affecting v(n-1) implementations; - v(n-1)-equivalent operation: The version of an operation which excludes all the information elements and errors which have been added since the MAP v(n-1) specification; - vn-only package: An operation package which contains only vn-only operations; - v(n-1)-package: An operation package which contains only v(n-1)- operations. The names of vn-packages are suffixed by ""-vn"" where n>=2. For each operation package which is not vn-only (n>=2) and which does not include only v(n-1)-operations, there is a v(n-1)-equivalent package. Except when a definition is explicitly provided in the following clauses, the v(n 1) equivalent package includes the v(n-1)-equivalent operations of the operations which belong to this package. 17.2.2 Packages specifications 17.2.2.1 Location updating This operation package includes the operations required for location management procedures between HLR and VLR. locationUpdatingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { updateLocation} SUPPLIER INVOKES { forwardCheckSs-Indication} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.2 Location cancellation This operation package includes the operations required for location cancellation and MS purging procedures between HLR and VLR and between HLR and SGSN. locationCancellationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR CONSUMER INVOKES { cancelLocation} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.3 Roaming number enquiry This operation package includes the operations required for roaming number enquiry procedures between HLR or old VLR and VLR. roamingNumberEnquiryPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is HLR or old VLR CONSUMER INVOKES { provideRoamingNumber} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.4 Information retrieval This operation package includes the operation required for the authentication information retrieval procedure between HLR and VLR and between HLR and SGSN. infoRetrievalPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { sendAuthenticationInfo} } The v2-equivalent package is defined as follows: infoRetrievalPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { sendAuthenticationInfo} } The v1-equivalent package is defined as follows: infoRetrievalPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR or VLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { sendParameters} } 17.2.2.5 Inter-VLR information retrieval This operation package includes the operations required for inter VLR information retrieval procedures. interVlrInfoRetrievalPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is VLR CONSUMER INVOKES { sendIdentification} } The v2-equivalent package is defined as follows: interVlrInfoRetrievalPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is VLR CONSUMER INVOKES { sendIdentification} } The v1-equivalent package is : infoRetrievalPackage-v1. 17.2.2.6 IMSI retrieval This operation package includes the operation required for the IMSI retrieval procedure between HLR and VLR. imsiRetrievalPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { sendIMSI} } This package is v2 only. 17.2.2.7 Call control transfer This operation package includes the operation required for the call control transfer procedure between VMSC and GMSC. callControlTransferPackage-v4 OPERATION-PACKAGE ::= { -- Supplier is GMSC if Consumer is VMSC CONSUMER INVOKES { resumeCallHandling} } The v3-equivalent package can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.8 Void 17.2.2.9 Void 17.2.2.10 Interrogation This operation package includes the operations required for interrogation procedures between MSC and HLR or NPLR or between HLR and gsmSCF. interrogationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR or NPLR if Consumer is MSC -- Supplier is HLR if Consumer is gsmSCF CONSUMER INVOKES { sendRoutingInfo} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.11 Void 17.2.2.12 Handover Control This operation package includes the operations required for handover procedures between MSCs. handoverControlPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is MSCB if Consumer is MSCA CONSUMER INVOKES { prepareHandover | forwardAccessSignalling} SUPPLIER INVOKES { sendEndSignal | processAccessSignalling | prepareSubsequentHandover} } The v2-equivalent package can be determined according to the rules described in clauseÊ17.2.1. The v1-equivalent package is defined as follows. handoverControlPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is MSCB if Consumer is MSCA CONSUMER INVOKES { performHandover | forwardAccessSignalling | traceSubscriberActivity} SUPPLIER INVOKES { sendEndSignal | noteInternalHandover | processAccessSignalling | performSubsequentHandover} } 17.2.2.13 Subscriber Data management stand alone This operation package includes the operations required for stand alone subscriber data management procedures between HLR and VLR or between HLR and SGSN. Also this operation package includes the operations required for stand alone subscriber data management procedures between CSS and VLR or between CSS and SGSN. For the CSS Ð VLR interface and CSS Ð SGSN interface only version 3 of this operation package is applicable. subscriberDataMngtStandAlonePackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR or CSS CONSUMER INVOKES { insertSubscriberData | deleteSubscriberData} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.14 Equipment management This operation package includes the operations required for equipment management procedures between EIR and MSC or between EIR and SGSN. equipmentMngtPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is EIR if Consumer is MSC -- Supplier is EIR if Consumer is SGSN CONSUMER INVOKES { checkIMEI} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.15 Subscriber data management This operation package includes the operations required for subscriber data management procedures between HLR and VLR or between HLR and SGSN. Also this operation package includes the operations required for subscriber data management procedures between CSS and VLR or between CSS and SGSN. For the CSS Ð VLR interface and CSS Ð SGSN interface only version 3 of this operation package is applicable. subscriberDataMngtPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR or CSS CONSUMER INVOKES { insertSubscriberData} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.16 Location register restart This operation package includes the operations required for location register restart procedures between HLR and VLR or between HLR and SGSN and also between CSS and VLR or between CSS and SGSN. resetPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR or CSS CONSUMER INVOKES { reset} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. For CSS-VLR interface and CSS-SGSN interface, only version 3 of this operation package is applicable. 17.2.2.17 Tracing stand-alone This operation package includes the operations required for stand alone tracing procedures between HLR and VLR or between HLR and SGSN. tracingStandAlonePackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR CONSUMER INVOKES { activateTraceMode | deactivateTraceMode} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.18 Functional SS handling This operation package includes the operations required for functional supplementary services procedures between VLR and HLR. functionalSsPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { registerSS | eraseSS | activateSS | deactivateSS | registerPassword | interrogateSS} SUPPLIER INVOKES { getPassword} } The v1-equivalent package can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.19 Tracing This operation package includes the operations required for tracing procedures between HLR and VLR or between HLR and SGSN. tracingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR CONSUMER INVOKES { activateTraceMode} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.20 Binding This operation package includes the operation required to initialise a supplementary service procedure between VLR and HLR or between gsmSCF and HLR. bindingPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is gsmSCF if Consumer is HLR CONSUMER INVOKES { beginSubscriberActivity} } This package is v1 only. 17.2.2.21 Unstructured SS handling This operation package includes the operations required for unstructured supplementary services procedures between VLR and HLR, between the HLR and the gsmSCF, and between HLR and HLR. unstructuredSsPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is gsmSCF or HLR if Consumer is HLR CONSUMER INVOKES { processUnstructuredSS-Request} SUPPLIER INVOKES { unstructuredSS-Request | unstructuredSS-Notify} } The v1-equivalent package is defined as follows: unstructuredSsPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is gsmSCF if Consumer is HLR CONSUMER INVOKES { processUnstructuredSS-Data} } 17.2.2.22 MO Short message relay services This operation package includes the operations required for short message relay service procedures between IWMSC and VMSC or between GMSC and MSC or between SGSN and IWMSC. mo-ShortMsgRelayPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is IWMSC if Consumer is MSC -- Supplier is IWMSC if Consumer is SGSN CONSUMER INVOKES { mo-forwardSM} } The v2-equivalent package is defined as follows: shortMsgRelayPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is IWMSC if Consumer is MSC -- Supplier is MSC or SGSN if Consumer is GMSC -- Supplier is IWMSC if Consumer is SGSN CONSUMER INVOKES { forwardSM} } The v1-equivalent package can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.23 Short message gateway services This operation package includes the operations required for short message service gateway procedures between MSC and HLR. shortMsgGatewayPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GMSC CONSUMER INVOKES { sendRoutingInfoForSM | reportSM-DeliveryStatus} SUPPLIER INVOKES { informServiceCentre} } The v2-equivalent package can be determined according to the rules described in clause 17.2.1. The v1-equivalent package is defined as follows: shortMsgGatewayPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GMSC CONSUMER INVOKES { sendRoutingInfoForSM | reportSMDeliveryStatus} } 17.2.2.24 MT Short message relay services This operation package includes the operations required for short message relay service procedures between GMSC and MSC or between GMSC and SGSN. mt-ShortMsgRelayPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is MSC or SGSN or SMS-Router or IP-SM-GW if Consumer is GMSC CONSUMER INVOKES { mt-forwardSM} } The v2-equivalent package is: shortMsgRelayPackage-v2 17.2.2.25 Void 17.2.2.26 Message waiting data management This operation package includes the operations required for short message waiting data procedures between HLR and VLR, between HLR and SGSN. mwdMngtPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is SGSN -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { readyForSM} } The v2-equivalent package can be determined according to the rules described in clause 17.2.1. The v1-equivalent package is defined as follows: mwdMngtPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { noteSubscriberPresent} } 17.2.2.27 Alerting This operation package includes the operations required for alerting between HLR and IWMSC. alertingPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is IWMSC if Consumer is HLR CONSUMER INVOKES { alertServiceCentre} } The v1-equivalent package is defined as follows. alertingPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is IWMSC if Consumer is HLR CONSUMER INVOKES { alertServiceCentreWithoutResult} } 17.2.2.28 Data restoration This operation package includes the operations required for VLR data restoration between HLR and VLR. dataRestorationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { restoreData} } The v2-equivalent package can be determined according to the rules described in clause 17.2.1. The v1-equivalent package is: infoRetrievalPackage-v1 17.2.2.29 Purging This operation package includes the operations required for purging between HLR and VLR or between HLR and SGSN. purgingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { purgeMS} } The v2-equivalent package can be determined according to the rules described in clause 17.2.1. 17.2.2.30 Subscriber information enquiry This operation package includes the operations required for subscriber information enquiry procedures between HLR and VLR or between HLR and SGSN. subscriberInformationEnquiryPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR CONSUMER INVOKES { provideSubscriberInfo} } This package is v3 only. 17.2.2.31 Any time information enquiry This operation package includes the operations required for any time information enquiry procedures between gsmSCF and HLR or between gsmSCF and GMLC or between gsmSCF and NPLR. anyTimeInformationEnquiryPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR or GMLC or NPLR if Consumer is gsmSCF CONSUMER INVOKES { anyTimeInterrogation} } This package is v3 only. 17.2.2.32 Group Call Control This operation package includes the operations required for group call and broadcast call procedures between MSCs. groupCallControlPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is relay MSC if Consumer is anchor MSC CONSUMER INVOKES { prepareGroupCall | forwardGroupCallSignalling} SUPPLIER INVOKES { sendGroupCallEndSignal | processGroupCallSignalling} } This package is v3 only. 17.2.2.32A Group Call Info Retrieval This operation package includes the operations required for group call and broadcast call info retrieval between MSCs. groupCallInfoRetrievalPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is group call serving MSC if Consumer is visited MSC -- Supplier is visited MSC if Consumer is group call serving MSC CONSUMER INVOKES { sendGroupCallInfo} } This package is v3 only. 17.2.2.33 Void 17.2.2.34 Void 17.2.2.35 Gprs location updating This operation package includes the operations required for the gprs location management procedures between HLR and SGSN. gprsLocationUpdatingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { updateGprsLocation} } This package is v3 only. 17.2.2.36 Gprs Interrogation This operation package includes the operations required for interrogation procedures between HLR and GGSN. gprsInterrogationPackage-v4 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GGSN CONSUMER INVOKES { sendRoutingInfoForGprs} } The v3-equivalent package is defined as follows. gprsInterrogationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GGSN CONSUMER INVOKES { sendRoutingInfoForGprs} } 17.2.2.37 Failure reporting This operation package includes the operations required for failure reporting between HLR and GGSN. failureReportingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GGSN CONSUMER INVOKES { failureReport} } This package is v3 only. 17.2.2.38 GPRS notifying This operation package includes the operations required for notifying that GPRS subscriber is present between HLR and GGSN. gprsNotifyingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is GGSN if Consumer is HLR CONSUMER INVOKES { noteMsPresentForGprs} } This package is v3 only. 17.2.2.39 Supplementary Service invocation notification This operation package includes the operations required for Supplementary Service invocation notification procedures between the MSC and the gsmSCF and between the HLR and the gsmSCF. ss-InvocationNotificationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is gsmSCF if Consumer is MSC -- Supplier is gsmSCF if Consumer is HLR CONSUMER INVOKES { ss-InvocationNotification} } This package is v3 only. 17.2.2.40 Set Reporting State This operation package includes the operation required for procedures between HLR and VLR to set the reporting state. setReportingStatePackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is HLR CONSUMER INVOKES { setReportingState} } This package is v3 only. 17.2.2.41 Status Report This operation package includes the operation required for procedures between VLR and HLR to report call results and events. statusReportPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { statusReport} } This package is v3 only. 17.2.2.42 Remote User Free This operation package includes the operation required by the HLR to indicate to the VLR that the remote user is free. remoteUserFreePackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is HLR CONSUMER INVOKES { remoteUserFree} } This package is v3 only. 17.2.2.43 Call Completion This operation package includes the operations required for procedures between VLR and HLR for subscriber control of call completion services."
"callCompletionPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { registerCC-Entry | eraseCC-Entry} } This package is v3 only. 17.2.2.44 Location service gateway services This operation package includes the operations required for location service gateway procedures between GMLC and HLR. locationSvcGatewayPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GMLC CONSUMER INVOKES { sendRoutingInfoForLCS} } This package is v3 only. 17.2.2.45 Location service enquiry This operation package includes the operations required for the location service enquiry procedures between GMLC and MSC and between GMLC and SGSN. locationSvcEnquiryPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is MSC or SGSN if Consumer is GMLC CONSUMER INVOKES { provideSubscriberLocation} } This package is v3 only. 17.2.2.45A Location service reporting This operation package includes the operations required for the location service enquiry procedures between MSC and GMLC and between SGSN and GMLC. locationSvcReportingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is GMLC if Consumer is MSC -- Supplier is GMLC if Consumer is SGSN CONSUMER INVOKES { subscriberLocationReport} } 17.2.2.46 Void 17.2.2.47 Void 17.2.2.48 Void 17.2.2.49 IST Alerting This operation package includes the operation required for alerting procedures between the MSC (Visited MSC or Gateway MSC) and HLR. ist-AlertingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VMSC -- Supplier is HLR if Consumer is GMSC CONSUMER INVOKES { istAlert} } This package is v3 only. 17.2.2.50 Service Termination This operation package includes the operation required for immediate service termination procedures between the HLR and the Visited MSC or between the HLR and the Gateway MSC. serviceTerminationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VMSC or GMSC if Consumer is HLR CONSUMER INVOKES { istCommand} } This package is v3 only. 17.2.2.51 Mobility Management event notification This operation package includes the operations required for Mobility Management event notification procedures between VLR and gsmSCF. mm-EventReportingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is gsmSCF if Consumer is VLR CONSUMER INVOKES { noteMM-Event} } This package is v3 only. 17.2.2.52 Any time information handling This operation package includes the operations required for any time information handling procedures between gsmSCF and HLR. anyTimeInformationHandlingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is gsmSCF CONSUMER INVOKES { anyTimeSubscriptionInterrogation | anyTimeModification} } This package is v3 only. 17.2.2.53 Subscriber Data modification notification This operation package includes the operations required for Subscriber Data modification notification procedures between HLR and gsmSCF. subscriberDataModificationNotificationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is gsmSCF if Consumer is HLR CONSUMER INVOKES { noteSubscriberDataModified} } This package is v3 only. 17.2.2.54 Authentication Failure Report This operation package includes the operation required for procedures between VLR and HLR or the SGSN and the HLR for reporting of authentication failures. authenticationFailureReportPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { authenticationFailureReport} } This package is v3 only. 17.2.2.55 Resource Management This operation package includes the operation required for procedures between GMSC and VMSC for resource management purpose. resourceManagementPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VMSC if Consumer is GMSC CONSUMER INVOKES { releaseResources} } This package is v3 only. 17.2.2.56 MT Short message relay VGCS services This operation package includes the operations required for short message relay service procedures between SMS GMSC and MSC. mt-ShortMsgRelay-VGCS-Package-v3 OPERATION-PACKAGE ::= { -- Supplier is MSC if Consumer is GMSC CONSUMER INVOKES { mt-forwardSM-VGCS} } This package is v3 only. 17.2.2.57 Vcsg location updating This operation package includes the operations required for the vcsg location management procedures between CSS and VLR or between CSS and SGSN. vcsgLocationUpdatingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is CSS if Consumer is VLR or SGSN CONSUMER INVOKES { updateVcsgLocation} } This operation package is v3 only. 17.2.2.58 Vcsg location cancellation This operation package includes the operations required for the vcsg location cancellation procedures between CSS and VLR or between CSS and SGSN. vcsgLocationCancellationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is CSS CONSUMER INVOKES { cancelVcsgLocation} } This operation package is v3 only. 17.3 Application contexts 17.3.1 General aspects An application-context is assigned for each dialogue established by a MAP-user. In the present document each application-context is assigned a name which is supplied in the MAP-OPEN Req primitive by the MAP-User and transmitted to the peer under certain circumstances. The following ASN.1 information object class is used to describe the main aspects of application-contexts in the following clauses: APPLICATION-CONTEXT ::= CLASS { &Symmetric OPERATION-PACKAGE OPTIONAL, &InitiatorConsumerOf OPERATION-PACKAGE OPTIONAL, &ResponderConsumerOf OPERATION-PACKAGE OPTIONAL, &code OBJECT IDENTIFIER } WITH SYNTAX { [ OPERATIONS OF &Symmetric ] [ INITIATOR CONSUMER OF &InitiatorConsumerOf RESPONDER CONSUMER OF &ResponderConsumerOf ] ID &code } The following definitions are used throughout this clause: - v1-application-context: An application-context which contains only v1-packages and uses only TC v1 facilities; - v1 context set: the set of v1-application-contexts defined in the present document. - vn-application-context (n>=2): An application-context which contains only vn-packages; The names of v1-application-contexts are suffixed by ""-v1"" while other names are suffixed by ""-vn"" where n>=2. Application-contexts which do not belong to the v1 context set use v2 TC facilities. The last component of each application-context-name (i.e. the last component of the object identifier value) assigned to an application-context which belongs to the v1 context set indicates explicitly ""version1"". For each application-context which does not belong to the ""v1 context set"" there is a v1-equivalent application context. This is a v1-application-context which includes the v1-equivalents of the packages included in the original context. Each application-context uses the abstract-syntax associated with the operation-packages it includes and uses the transfer-syntax derived from it by applying the encoding rules defined in clauseÊ17.1.1. ACs which do not belong to the v1 context set require the support of the abstract-syntax identified by the object identifier value: MAP-DialogueInformation.map-Dialogue-AS defined in clauseÊ17.4. 17.3.2 Application context definitions 17.3.2.1 Void 17.3.2.2 Location Updating This application context is used between HLR and VLR for location updating procedures. networkLocUpContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { locationUpdatingPackage-v3 | dataRestorationPackage-v3} RESPONDER CONSUMER OF { subscriberDataMngtPackage-v3 | tracingPackage-v3} ID {map-ac networkLocUp(1) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac networkLocUp(1) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac networkLocUp(1) version1(1)} 17.3.2.3 Location Cancellation This application context is used between HLR and VLR or between HLR and SGSN for location cancellation procedures. For the HLR - SGSN interface only version 3 of this application context is applicable. locationCancellationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR INITIATOR CONSUMER OF { locationCancellationPackage-v3} ID {map-ac locationCancel(2) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID map-ac locationCancel(2) version2(2) The following application-context-name is assigned to the v1-equivalent application-context: ID map-ac locationCancel(2) version1(1) 17.3.2.4 Roaming number enquiry This application context is used between HLR and VLR for roaming number enquiry procedures. roamingNumberEnquiryContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR if Initiator is HLR INITIATOR CONSUMER OF { roamingNumberEnquiryPackage-v3} ID {map-ac roamingNbEnquiry(3) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac roamingNbEnquiry(3) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac roamingNbEnquiry(3) version1(1)} 17.3.2.5 Void 17.3.2.6 Location Information Retrieval This application-context is used between GMSC and HLR or between GMSC and NPLR or between gsmSCF and HLR when retrieving location information. For the GMSC - NPLR interface version 1, version 2 and version 3 of this application context are applicable. locationInfoRetrievalContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR or NPLR if Initiator is GMSC -- Responder is HLR if Initiator is gsmSCF INITIATOR CONSUMER OF { interrogationPackage-v3} ID {map-ac locInfoRetrieval(5) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac locInfoRetrieval(5) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac locInfoRetrieval(5) version1(1)} 17.3.2.7 Call control transfer This application context is used for the call control transfer procedure between the VMSC and the GMSC. callControlTransferContext-v4 APPLICATION-CONTEXT ::= { -- Responder is GMSC if Initiator is VMSC INITIATOR CONSUMER OF { callControlTransferPackage-v4} ID {map-ac callControlTransfer(6) version4(4)} } The following application-context-name is assigned to the v3-equivalent application-context: ID {map-ac callControlTransfer(6) version3(3)} 17.3.2.8 Void 17.3.2.9 Void 17.3.2.10 Void 17.3.2.11 Location registers restart This application context is used between HLR and VLR or between HLR and SGSN for location register restart procedures or between CSS and VLR or between CSS and SGSN for CSG Subscriber Server restart procedures. For the HLR - VLR interface and for the HLR - SGSN interface version 1, version 2 and version 3 of this application context are applicable For the CSS - VLR interface and the CSS - SGSN interface version 3 of this application context is applicable. resetContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR or CSS INITIATOR CONSUMER OF { resetPackage-v3} ID {map-ac reset(10) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac reset(10) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac reset(10) version1(1)} 17.3.2.12 Handover control This application context is used for handover procedures between MSCs. handoverControlContext-v3 APPLICATION-CONTEXT ::= { -- Responder is MSCB if Initiator is MSCA INITIATOR CONSUMER OF { handoverControlPackage-v3} ID {map-ac handoverControl(11) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac handoverControl(11) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac handoverControl(11) version1(1)} 17.3.2.13 IMSI Retrieval This application context is used for IMSI retrieval between HLR and VLR. imsiRetrievalContext-v2 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { imsi-RetrievalPackage-v2} ID {map-ac imsiRetrieval(26) version2(2)} } This application-context is v2 only. 17.3.2.14 Equipment Management This application context is used for equipment checking between MSC and EIR or between SGSN and EIR. For the SGSN - EIR interface version 1 and version 2 and version 3 of this application context are applicable: equipmentMngtContext-v3 APPLICATION-CONTEXT ::= { -- Responder is EIR if Initiator is MSC -- Responder is EIR if Initiator is SGSN INITIATOR CONSUMER OF { equipmentMngtPackage-v3} ID {map-ac equipmentMngt(13) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: equipmentMngtContext-v2 APPLICATION-CONTEXT ::= { -- Responder is EIR if Initiator is MSC -- Responder is EIR if Initiator is SGSN INITIATOR CONSUMER OF { equipmentMngtPackage-v2} ID {map-ac equipmentMngt(13) version2(2)} } The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac equipmentMngt(13) version1(1)} 17.3.2.15 Information retrieval This application context is used for authentication information retrieval between HLR and VLR or between HLR and SGSN. For the HLR - SGSN interface version 1 and version 2 and version 3 of this application context are applicable. infoRetrievalContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { infoRetrievalPackage-v3} ID {map-ac infoRetrieval(14) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: infoRetrievalContext-v2 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { infoRetrievalPackage-v2} ID {map-ac infoRetrieval(14) version2(2)} } The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac infoRetrieval(14) version1(1)} 17.3.2.16 Inter-VLR information retrieval This application context is used for information retrieval between VLRs. interVlrInfoRetrievalContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR if Initiator is VLR INITIATOR CONSUMER OF { interVlrInfoRetrievalPackage-v3} ID {map-ac interVlrInfoRetrieval(15) version3(3)} } The v2-equivalent application-context is: interVlrInfoRetrievalContext-v2 APPLICATION-CONTEXT ::= { -- Responder is VLR if Initiator is VLR INITIATOR CONSUMER OF { interVlrInfoRetrievalPackage-v2} ID {map-ac interVlrInfoRetrieval(15) version2(2)} } The v1-equivalent application-context is: ID {map-ac infoRetrieval(14) version1(1)} 17.3.2.17 Stand Alone Subscriber Data Management This application context is used for stand alone subscriber data management between HLR and VLR or between HLR and SGSN. For the HLR - SGSN interface only version 3 of this application context is applicable. Also this application context is used for stand alone subscriber data management between CSS and VLR or between CSS and SGSN. For the CSS Ð VLR interface and CSS Ð SGSN interface only version 3 of this application context is applicable: subscriberDataMngtContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR or CSS INITIATOR CONSUMER OF { subscriberDataMngtStandAlonePackage-v3} ID {map-ac subscriberDataMngt(16) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac subscriberDataMngt(16) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac subscriberDataMngt(16) version1(1)} 17.3.2.18 Tracing This application context is used between HLR and VLR or between HLR and SGSN for stand alone tracing control procedures. For the HLR - SGSN interface version 1, version 2 and version 3 of this application context are applicable. tracingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR INITIATOR CONSUMER OF { tracingStandAlonePackage-v3} ID {map-ac tracing(17) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac tracing(17) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac tracing(17) version1(1)} 17.3.2.19 Network functional SS handling This application context is used for functional-like SS handling procedures between VLR and HLR. networkFunctionalSsContext-v2 APPLICATION-CONTEXT ::= { -- Responder is HLR, Initiator is VLR INITIATOR CONSUMER OF { functionalSsPackage-v2} ID {map-ac networkFunctionalSs(18) version2(2)} } The v1-equivalent application-context is defined as follows: networkFunctionalSsContext-v1 APPLICATION-CONTEXT ::= { -- Responder is HLR, Initiator is VLR INITIATOR CONSUMER OF { functionalSsPackage-v1 | unstructuredSsPackage-v1 | bindingPackage-v1} ID {map-ac networkFunctionalSs(18) version1(1)} } 17.3.2.20 Network unstructured SS handling This application context is used for handling stimuli-like procedures between HLR and VLR, between the HLR and gsmSCF, and between HLR and HLR. networkUnstructuredSsContext-v2 APPLICATION-CONTEXT ::= { -- Responder is HLR, Initiator is VLR -- Responder is VLR, Initiator is HLR -- Responder is gsmSCF, Initiator is HLR -- Responder is HLR, Initiator is gsmSCF -- Responder is HLR, Initiator is HLR OPERATIONS OF { unstructuredSsPackage-v2} ID {map-ac networkUnstructuredSs(19) version2(2)} } The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac networkFunctionalSs(18) version1(1)} 17.3.2.21 Short Message Gateway This application context is used for short message gateway procedures. shortMsgGatewayContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GMSC INITIATOR CONSUMER OF { shortMsgGatewayPackage-v3} ID {map-ac shortMsgGateway(20) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac shortMsgGateway(20) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac shortMsgGateway(20) version1(1)} 17.3.2.22 Mobile originating Short Message Relay This application context is used between MSC and IWMSC or between SGSN and IWMSC for mobile originating short message relay procedures. For the SGSN - IWMSC interface version 1, version 2 and version 3 of this application context are applicable. shortMsgMO-RelayContext-v3 APPLICATION-CONTEXT ::= { -- Responder is IWMSC if Initiator is MSC -- Responder is IWMSC if Initiator is SGSN INITIATOR CONSUMER OF { mo-ShortMsgRelayPackage-v3} ID {map-ac shortMsgMO-Relay(21) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac shortMsgMO-Relay(21) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac shortMsg-Relay(21) version1(1)} 17.3.2.23 Void 17.3.2.24 Short message alert This application context is used for short message alerting procedures. shortMsgAlertContext-v2 APPLICATION-CONTEXT ::= { -- Responder is IWMSC if Initiator is HLR INITIATOR CONSUMER OF { alertingPackage-v2} ID {map-ac shortMsgAlert(23) version2(2)} } The following application-context-name is symbolically assigned to the v1-equivalent application-context: ID {map-ac shortMsgAlert(23) version1(1)} 17.3.2.25 Short message waiting data management This application context is used between VLR and HLR or between SGSN and HLR for short message waiting data management procedures. For the SGSN - HLR interface only version 3 of this application context is applicable. mwdMngtContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is SGSN -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { mwdMngtPackage-v3} ID {map-ac mwdMngt(24) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac mwdMngt(24) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac mwdMngt(24) version1(1)} 17.3.2.26 Mobile terminating Short Message Relay This application context is used between GMSC and MSC or between GMSC and SGSN for mobile terminating short message relay procedures. For the GMSC - SGSN interface version 2 and version 3 of this application context and the equivalent version 1 application context are applicable. shortMsgMT-RelayContext-v3 APPLICATION-CONTEXT ::= { -- Responder is MSC or SGSN if Initiator is GMSC INITIATOR CONSUMER OF { mt-ShortMsgRelayPackage-v3} ID {map-ac shortMsgMT-Relay(25) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac shortMsgMT-Relay(25) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac shortMsg-Relay(21) version1(1)} 17.3.2.27 MS purging This application context is used between HLR and VLR or between HLR and SGSN for MS purging procedures. For the SGSN - HLR interface only version 3 of this application context is applicable. msPurgingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { purgingPackage-v3} ID {map-ac msPurging(27) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac msPurging(27) version2(2)} 17.3.2.28 Subscriber information enquiry This application context is used between HLR and VLR or between HLR and SGSN for subscriber information enquiry procedures. subscriberInfoEnquiryContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR INITIATOR CONSUMER OF { subscriberInformationEnquiryPackage-v3} ID {map-ac subscriberInfoEnquiry(28) version3(3)} } This application-context is v3 only. 17.3.2.29 Any time information enquiry This application context is used between gsmSCF and HLR or between gsmSCF and GMLC or between gsmSCF and NPLR for any time information enquiry procedures. anyTimeInfoEnquiryContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR or GMLC or NPLR if Initiator is gsmSCF INITIATOR CONSUMER OF { anyTimeInformationEnquiryPackage-v3} ID {map-ac anyTimeInfoEnquiry(29) version3(3)} } This application-context is v3 only. 17.3.2.30 Group Call Control This application context is used between anchor MSC and relay MSC for group call and broadcast call procedures. groupCallControlContext-v3 APPLICATION-CONTEXT ::= { -- Responder is relay MSC if Initiator is anchor MSC INITIATOR CONSUMER OF { groupCallControlPackage-v3} ID {map-ac groupCallControl(31) version3(3)} } This application-context is v3 only. 17.3.2.30A Group Call Info Retrieval This application context is used between group call serving MSC and visited MSC for group call and broadcast call procedures. groupCallInfoRetControlContext-v3 APPLICATION-CONTEXT ::= { -- Responder is group call serving MSC if Initiator is visited MSC -- Responder is visited MSC if Initiator is group call serving MSC INITIATOR CONSUMER OF { groupCallInfoRetrievalPackage-v3} ID {map-ac groupCallInfoRetrieval(45) version3(3)} } This application-context is v3 only. 17.3.2.31 Void 17.3.2.32 Gprs Location Updating This application context is used between HLR and SGSN for gprs location updating procedures. gprsLocationUpdateContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { gprsLocationUpdatingPackage-v3} RESPONDER CONSUMER OF { subscriberDataMngtPackage-v3 | tracingPackage-v3} ID {map-ac gprsLocationUpdate(32) version3(3)} } This application-context is v3 only. 17.3.2.33 Gprs Location Information Retreival This application context is used between HLR and GGSN when retrieving gprs location information. gprsLocationInfoRetrievalContext-v4 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GGSN INITIATOR CONSUMER OF { gprsInterrogationPackage-v4} ID {map-ac gprsLocationInfoRetrieval(33) version4(4)} } The following application-context-name is assigned to the v3-equivalent application-context: ID {map-ac gprsLocationInfoRetrieval(33) version3(3)} 17.3.2.34 Failure Reporting This application context is used between HLR and GGSN to inform that network requested PDP-context activation has failed. failureReportContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GGSN INITIATOR CONSUMER OF { failureReportingPackage-v3} ID {map-ac failureReport(34) version3(3)} } This application-context is v3 only. 17.3.2.35 GPRS Notifying This application context is used between HLR and GGSN for notifying that GPRS subscriber is present again. gprsNotifyContext-v3 APPLICATION-CONTEXT ::= { -- Responder is GGSN if Initiator is HLR INITIATOR CONSUMER OF { gprsNotifyingPackage-v3} ID {map-ac gprsNotify(35) version3(3)} } This application-context is v3 only. 17.3.2.36 Supplementary Service invocation notification This application context is used between the MSC and the gsmSCF and between the HLR and the gsmSCF for Supplementary Service invocation notification procedures. ss-InvocationNotificationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is gsmSCF, Initiator is MSC -- Responder is gsmSCF, Initiator is HLR INITIATOR CONSUMER OF { ss-InvocationNotificationPackage-v3} ID {map-ac ss-InvocationNotification(36) version3(3)} } This application-context is v3 only. 17.3.2.37 Reporting This application context is used between HLR and VLR for reporting procedures. reportingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR if Initiator is HLR -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { setReportingStatePackage-v3 | statusReportPackage-v3 | remoteUserFreePackage-v3} RESPONDER CONSUMER OF { setReportingStatePackage-v3 | statusReportPackage-v3} ID {map-ac reporting(7) version3(3)} } This application-context is v3 only. 17.3.2.38 Call Completion This application context is used between VLR and the HLR for subscriber control of call completion services. callCompletionContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { callCompletionPackage-v3} ID {map-ac callCompletion(8) version3(3)} } This application-context is v3 only. 17.3.2.39 Location Service Gateway This application context is used for location service gateway procedures. locationSvcGatewayContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GMLC INITIATOR CONSUMER OF { locationSvcGatewayPackage-v3} ID {map-ac locationSvcGateway(37) version3(3)} } 17.3.2.40 Location Service Enquiry This application context is used for location service enquiry procedures. locationSvcEnquiryContext-v3 APPLICATION-CONTEXT ::= { -- Responder is MSC or SGSN if Initiator is GMLC -- Responder is GMLC if Initiator is MSC -- Responder is GMLC if Initiator is SGSN INITIATOR CONSUMER OF { locationSvcEnquiryPackage-v3 | locationSvcReportingPackage-v3} ID {map-ac locationSvcEnquiry(38) version3 (3)} } 17.3.2.41 Void 17.3.2.42 Void 17.3.2.43 Void 17.3.2.44 IST Alerting This application context is used between MSC (Visited MSC or Gateway MSC) and HLR for alerting services within IST procedures. istAlertingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VMSC -- Responder is HLR if Initiator is GMSC INITIATOR CONSUMER OF { ist-AlertingPackage-v3} ID {map-ac alerting(4) version3(3)} } This application-context is v3 only. 17.3.2.45 Service Termination This application context is used between HLR and MSC (Visited MSC or Gateway MSC) for service termination services within IST procedures. serviceTerminationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VMSC or GMSC if Initiator is HLR INITIATOR CONSUMER OF { serviceTerminationPackage-v3} ID {map-ac serviceTermination(9) version3(3)} } This application-context is v3 only. 17.3.2.46 Mobility Management event notification This application context is used between VLR and gsmSCF for Mobility Management event notification procedures. mm-EventReportingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is gsmSCF, Initiator is VLR INITIATOR CONSUMER OF { mm-EventReportingPackage-v3} ID {map-ac mm-EventReporting(42) version3(3)} } This application-context is v3 only. 17.3.2.47 Any time information handling This application context is used between gsmSCF and HLR for any time information handling procedures. anyTimeInfohandlingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is gsmSCF INITIATOR CONSUMER OF { anyTimeInformationHandlingPackage-v3} ID {map-ac anyTimeInfoHandling(43) version3(3)} } This application-context is v3 only. 17.3.2.48 Subscriber Data modification notification This application context is used between HLR and gsmSCF for Subscriber Data modification notification procedures. subscriberDataModificationNotificationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is gsmSCF, Initiator is HLR INITIATOR CONSUMER OF { subscriberDataModificationNotificationPackage-v3} ID {map-ac subscriberDataModificationNotification(22) version3(3)} } This application-context is v3 only. 17.3.2.49 Authentication Failure Report This application context is used between VLR and HLR or SGSN and HLR for reporting of authentication failures. authenticationFailureReportContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { authenticationFailureReportPackage-v3 } ID {map-ac authenticationFailureReport(39) version3(3)} } This application-context is v3 only. 17.3.2.50 Resource Management This application context is used between GMSC and VMSC for resource management purpose. resourceManagementContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VMSC if Initiator is GMSC INITIATOR CONSUMER OF { resourceManagementPackage-v3 } ID {map-ac resourceManagement(44) version3(3)} } This application-context is v3 only. 17.3.2.51 Mobile terminating Short Message Relay VGCS This application context is used between SMS-GMSC and MSC for mobile terminating short message relay procedures for VGCS. shortMsgMT-Relay-VGCS-Context-v3 APPLICATION-CONTEXT ::= { -- Responder is MSC if Initiator is SMS-GMSC INITIATOR CONSUMER OF { mt-ShortMsgRelay-VGCS-Package-v3} ID {map-ac shortMsgMT-Relay-VGCS(41) version3(3)} } This application-context is v3 only. 17.3.2.52 Vcsg Location Updating This application context is used between CSS and VLR or between CSS and SGSN for vcsg location updating procedures. vcsgLocationUpdateContext-v3 APPLICATION-CONTEXT ::= { -- Responder is CSS if Initiator is VLR or SGSN INITIATOR CONSUMER OF { vcsgLocationUpdatingPackage-v3} RESPONDER CONSUMER OF { subscriberDataMngtPackage-v3} ID {map-ac vcsgLocationUpdate(46) version3(3)} } This application-context is v3 only. 17.3.2.53 Vcsg Location Cancellation This application context is used between CSS and VLR or between CSS and SGSN for vcsg location cancellation procedures. vcsgLocationCancellationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is CSS INITIATOR CONSUMER OF { vcsgLocationCancellationPackage-v3} ID {map-ac vcsgLocationCancel(47) version3(3)} } This application-context is v3 only. 17.3.3 ASN.1 Module for application-context-names The following ASN.1 module summarises the application-context-name assigned to MAP application-contexts. .$MAP-ApplicationContexts { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ApplicationContexts (2) version20 (20)} DEFINITIONS ::= BEGIN -- EXPORTS everything IMPORTS gsm-NetworkId, ac-Id FROM MobileDomainDefinitions { itu-t (0) identified-organization (4) etsi (0) mobileDomain (0) mobileDomainDefinitions (0) version1 (1)} ; -- application-context-names map-ac OBJECT IDENTIFIER ::= {gsm-NetworkId ac-Id} networkLocUpContext-v3 OBJECT IDENTIFIER ::= {map-ac networkLocUp(1) version3(3)} locationCancellationContext-v3 OBJECT IDENTIFIER ::= {map-ac locationCancel(2) version3(3)} roamingNumberEnquiryContext-v3 OBJECT IDENTIFIER ::= {map-ac roamingNbEnquiry(3) version3(3)} authenticationFailureReportContext-v3 OBJECT IDENTIFIER ::= {map-ac authenticationFailureReport(39) version3(3)} locationInfoRetrievalContext-v3 OBJECT IDENTIFIER ::= {map-ac locInfoRetrieval(5) version3(3)} resetContext-v3 OBJECT IDENTIFIER ::= {map-ac reset(10) version3(3)} handoverControlContext-v3 OBJECT IDENTIFIER ::= {map-ac handoverControl(11) version3(3)} equipmentMngtContext-v3 OBJECT IDENTIFIER ::= {map-ac equipmentMngt(13) version3(3)} infoRetrievalContext-v3 OBJECT IDENTIFIER ::= {map-ac infoRetrieval(14) version3(3)} interVlrInfoRetrievalContext-v3 OBJECT IDENTIFIER ::= {map-ac interVlrInfoRetrieval(15) version3(3)} subscriberDataMngtContext-v3 OBJECT IDENTIFIER ::= {map-ac subscriberDataMngt(16) version3(3)} tracingContext-v3 OBJECT IDENTIFIER ::= {map-ac tracing(17) version3(3)} networkFunctionalSsContext-v2 OBJECT IDENTIFIER ::= {map-ac networkFunctionalSs(18) version2(2)} networkUnstructuredSsContext-v2 OBJECT IDENTIFIER ::= {map-ac networkUnstructuredSs(19) version2(2)} shortMsgGatewayContext-v3 OBJECT IDENTIFIER ::= {map-ac shortMsgGateway(20) version3(3)} shortMsgMO-RelayContext-v3 OBJECT IDENTIFIER ::= {map-ac shortMsgMO-Relay(21) version3(3)} shortMsgAlertContext-v2 OBJECT IDENTIFIER ::= {map-ac shortMsgAlert(23) version2(2)} mwdMngtContext-v3 OBJECT IDENTIFIER ::= {map-ac mwdMngt(24) version3(3)} shortMsgMT-RelayContext-v3 OBJECT IDENTIFIER ::= {map-ac shortMsgMT-Relay(25) version3(3)} shortMsgMT-Relay-VGCS-Context-v3 OBJECT IDENTIFIER ::= {map-ac shortMsgMT-Relay-VGCS(41) version3(3)} imsiRetrievalContext-v2 OBJECT IDENTIFIER ::= {map-ac imsiRetrieval(26) version2(2)} msPurgingContext-v3 OBJECT IDENTIFIER ::= {map-ac msPurging(27) version3(3)} subscriberInfoEnquiryContext-v3 OBJECT IDENTIFIER ::= {map-ac subscriberInfoEnquiry(28) version3(3)} anyTimeInfoEnquiryContext-v3 OBJECT IDENTIFIER ::= {map-ac anyTimeInfoEnquiry(29) version3(3)} callControlTransferContext-v4 OBJECT IDENTIFIER ::= {map-ac callControlTransfer(6) version4(4)} ss-InvocationNotificationContext-v3 OBJECT IDENTIFIER ::= {map-ac ss-InvocationNotification(36) version3(3)} groupCallControlContext-v3 OBJECT IDENTIFIER ::= {map-ac groupCallControl(31) version3(3)} groupCallInfoRetrievalContext-v3 OBJECT IDENTIFIER ::= {map-ac groupCallInfoRetrieval(45) version3(3)} gprsLocationUpdateContext-v3 OBJECT IDENTIFIER ::= {map-ac gprsLocationUpdate(32) version3(3)} gprsLocationInfoRetrievalContext-v4 OBJECT IDENTIFIER ::= {map-ac gprsLocationInfoRetrieval(33) version4(4)} failureReportContext-v3 OBJECT IDENTIFIER ::= {map-ac failureReport(34) version3(3)} gprsNotifyContext-v3 OBJECT IDENTIFIER ::= {map-ac gprsNotify(35) version3(3)} reportingContext-v3 OBJECT IDENTIFIER ::= {map-ac reporting(7) version3(3)} callCompletionContext-v3 OBJECT IDENTIFIER ::= {map-ac callCompletion(8) version3(3)} istAlertingContext-v3 OBJECT IDENTIFIER ::= {map-ac istAlerting(4) version3(3)} serviceTerminationContext-v3 OBJECT IDENTIFIER ::= {map-ac immediateTermination(9) version3(3)} locationSvcGatewayContext-v3 OBJECT IDENTIFIER ::= {map-ac locationSvcGateway(37) version3(3)} locationSvcEnquiryContext-v3 OBJECT IDENTIFIER ::= {map-ac locationSvcEnquiry(38) version3(3)} mm-EventReportingContext-v3 OBJECT IDENTIFIER ::= {map-ac mm-EventReporting(42) version3(3)} anyTimeInfoHandlingContext-v3 OBJECT IDENTIFIER ::= {map-ac anyTimeInfoHandling(43) version3(3)} subscriberDataModificationNotificationContext-v3 OBJECT IDENTIFIER ::= {map-ac subscriberDataModificationNotification(22) version3(3)} resourceManagementContext-v3 OBJECT IDENTIFIER ::= {map-ac resourceManagement(44) version3(3)} vcsgLocationUpdateContext-v3 OBJECT IDENTIFIER ::= {map-ac vcsgLocationUpdate(46) version3(3)} vcsgLocationCancellationContext-v3 OBJECT IDENTIFIER ::= {map-ac vcsgLocationCancel(47) version3(3)} -- The following Object Identifiers are reserved for application-contexts -- existing in previous versions of the protocol -- AC Name & Version Object Identifier -- -- networkLocUpContext-v1 map-ac networkLocUp (1) version1 (1) -- networkLocUpContext-v2 map-ac networkLocUp (1) version2 (2) -- locationCancellationContext-v1 map-ac locationCancellation (2) version1 (1) -- locationCancellationContext-v2 map-ac locationCancellation (2) version2 (2) -- roamingNumberEnquiryContext-v1 map-ac roamingNumberEnquiry (3) version1 (1) -- roamingNumberEnquiryContext-v2 map-ac roamingNumberEnquiry (3) version2 (2) -- locationInfoRetrievalContext-v1 map-ac locationInfoRetrieval (5) version1 (1) -- locationInfoRetrievalContext-v2 map-ac locationInfoRetrieval (5) version2 (2) -- resetContext-v1 map-ac reset (10) version1 (1) -- resetContext-v2 map-ac reset (10) version2 (2) -- handoverControlContext-v1 map-ac handoverControl (11) version1 (1) -- handoverControlContext-v2 map-ac handoverControl (11) version2 (2) -- sIWFSAllocationContext-v3 map-ac sIWFSAllocation (12) version3 (3) -- equipmentMngtContext-v1 map-ac equipmentMngt (13) version1 (1) -- equipmentMngtContext-v2 map-ac equipmentMngt (13) version2 (2) -- infoRetrievalContext-v1 map-ac infoRetrieval (14) version1 (1) -- infoRetrievalContext-v2 map-ac infoRetrieval (14) version2 (2) -- interVlrInfoRetrievalContext-v2 map-ac interVlrInfoRetrieval (15) version2 (2) -- subscriberDataMngtContext-v1 map-ac subscriberDataMngt (16) version1 (1) -- subscriberDataMngtContext-v2 map-ac subscriberDataMngt (16) version2 (2) -- tracingContext-v1 map-ac tracing (17) version1 (1) -- tracingContext-v2 map-ac tracing (17) version2 (2) -- networkFunctionalSsContext-v1 map-ac networkFunctionalSs (18) version1 (1) -- shortMsgGatewayContext-v1 map-ac shortMsgGateway (20) version1 (1) -- shortMsgGatewayContext-v2 map-ac shortMsgGateway (20) version2 (2) -- shortMsgRelayContext-v1 map-ac shortMsgRelay (21) version1 (1) -- shortMsgAlertContext-v1 map-ac shortMsgAlert (23) version1 (1) -- mwdMngtContext-v1 map-ac mwdMngt (24) version1 (1) -- mwdMngtContext-v2 map-ac mwdMngt (24) version2 (2) -- shortMsgMT-RelayContext-v2 map-ac shortMsgMT-Relay (25) version2 (2) -- msPurgingContext-v2 map-ac msPurging (27) version2 (2) -- callControlTransferContext-v3 map-ac callControlTransferContext (6) version3 (3) -- gprsLocationInfoRetrievalContext-v3 map-ac gprsLocationInfoRetrievalContext (33) version3 (3) .#END 17.4 MAP Dialogue Information .$MAP-DialogueInformation { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-DialogueInformation (3) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS map-DialogueAS, MAP-DialoguePDU ; IMPORTS gsm-NetworkId, as-Id FROM MobileDomainDefinitions { itu-t (0) identified-organization (4) etsi (0) mobileDomain (0) mobileDomainDefinitions (0) version1 (1)} AddressString FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network(1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; -- abstract syntax name for MAP-DialoguePDU map-DialogueAS OBJECT IDENTIFIER ::= {gsm-NetworkId as-Id map-DialoguePDU (1) version1 (1)} MAP-DialoguePDU ::= CHOICE { map-open [0] MAP-OpenInfo, map-accept [1] MAP-AcceptInfo, map-close [2] MAP-CloseInfo, map-refuse [3] MAP-RefuseInfo, map-userAbort [4] MAP-UserAbortInfo, map-providerAbort [5] MAP-ProviderAbortInfo} MAP-OpenInfo ::= SEQUENCE { destinationReference [0] AddressString OPTIONAL, originationReference [1] AddressString OPTIONAL, ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-AcceptInfo ::= SEQUENCE { ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-CloseInfo ::= SEQUENCE { ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-RefuseInfo ::= SEQUENCE { reason Reason, ..., extensionContainer ExtensionContainer OPTIONAL, -- extensionContainer must not be used in version 2 alternativeApplicationContext OBJECT IDENTIFIER OPTIONAL -- alternativeApplicationContext must not be used in version 2 } Reason ::= ENUMERATED { noReasonGiven (0), invalidDestinationReference (1), invalidOriginatingReference (2)} MAP-UserAbortInfo ::= SEQUENCE { map-UserAbortChoice MAP-UserAbortChoice, ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-UserAbortChoice ::= CHOICE { userSpecificReason [0] NULL, userResourceLimitation [1] NULL, resourceUnavailable [2] ResourceUnavailableReason, applicationProcedureCancellation [3] ProcedureCancellationReason} ResourceUnavailableReason ::= ENUMERATED { shortTermResourceLimitation (0), longTermResourceLimitation (1)} ProcedureCancellationReason ::= ENUMERATED { handoverCancellation (0), radioChannelRelease (1), networkPathRelease (2), callRelease (3), associatedProcedureFailure (4), tandemDialogueRelease (5), remoteOperationsFailure (6)} MAP-ProviderAbortInfo ::= SEQUENCE { map-ProviderAbortReason MAP-ProviderAbortReason, ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-ProviderAbortReason ::= ENUMERATED { abnormalDialogue (0), invalidPDU (1)} .#END 17.5 MAP operation and error codes .$MAP-Protocol { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Protocol (4) version20 (20)} DEFINITIONS ::= BEGIN IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} updateLocation, cancelLocation, cancelVcsgLocation, purgeMS, sendIdentification, updateGprsLocation, updateVcsgLocation, prepareHandover, sendEndSignal, processAccessSignalling, forwardAccessSignalling, prepareSubsequentHandover, sendAuthenticationInfo, authenticationFailureReport, checkIMEI, insertSubscriberData, deleteSubscriberData, reset, forwardCheckSS-Indication, restoreData, provideSubscriberInfo, anyTimeInterrogation, anyTimeSubscriptionInterrogation, anyTimeModification, sendRoutingInfoForGprs, failureReport, noteMsPresentForGprs, noteMM-Event, noteSubscriberDataModified FROM MAP-MobileServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MobileServiceOperations (5) version20 (20)} activateTraceMode, deactivateTraceMode, sendIMSI FROM MAP-OperationAndMaintenanceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OperationAndMaintenanceOperations (6) version20 (20)} sendRoutingInfo, provideRoamingNumber, resumeCallHandling, setReportingState, statusReport, remoteUserFree, ist-Alert, ist-Command, releaseResources FROM MAP-CallHandlingOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CallHandlingOperations (7) version20 (20)} registerSS, eraseSS, activateSS, deactivateSS, interrogateSS, processUnstructuredSS-Request, unstructuredSS-Request, unstructuredSS-Notify, registerPassword, getPassword, ss-InvocationNotification, registerCC-Entry, eraseCC-Entry FROM MAP-SupplementaryServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SupplementaryServiceOperations (8) version20 (20)} sendRoutingInfoForSM, mo-ForwardSM, mt-ForwardSM, reportSM-DeliveryStatus, alertServiceCentre, informServiceCentre, readyForSM, mt-ForwardSM-VGCS FROM MAP-ShortMessageServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9) version20 (20)} prepareGroupCall, processGroupCallSignalling, forwardGroupCallSignalling, sendGroupCallEndSignal, sendGroupCallInfo FROM MAP-Group-Call-Operations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Group-Call-Operations (22) version20 (20)} provideSubscriberLocation, sendRoutingInfoForLCS, subscriberLocationReport FROM MAP-LocationServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-LocationServiceOperations (24) version20 (20)} ; Supported-MAP-Operations OPERATION ::= {updateLocation | cancelLocation | cancelVcsgLocation | purgeMS | sendIdentification | updateGprsLocation | updateVcsgLocation | prepareHandover | sendEndSignal | processAccessSignalling | forwardAccessSignalling | prepareSubsequentHandover | sendAuthenticationInfo | authenticationFailureReport | checkIMEI | insertSubscriberData | deleteSubscriberData | reset | forwardCheckSS-Indication | restoreData | provideSubscriberInfo | anyTimeInterrogation | anyTimeSubscriptionInterrogation | anyTimeModification | sendRoutingInfoForGprs | failureReport |noteMsPresentForGprs | noteMM-Event | noteSubscriberDataModified | activateTraceMode | deactivateTraceMode | sendIMSI | sendRoutingInfo | provideRoamingNumber | resumeCallHandling | setReportingState | statusReport | remoteUserFree | ist-Alert | ist-Command | registerSS | eraseSS | activateSS | deactivateSS | interrogateSS | processUnstructuredSS-Request | unstructuredSS-Request | unstructuredSS-Notify | registerPassword | getPassword | ss-InvocationNotification | registerCC-Entry | eraseCC-Entry | sendRoutingInfoForSM | mo-ForwardSM | mt-ForwardSM | reportSM-DeliveryStatus | alertServiceCentre | informServiceCentre | readyForSM | prepareGroupCall | processGroupCallSignalling | forwardGroupCallSignalling | sendGroupCallEndSignal | provideSubscriberLocation | sendRoutingInfoForLCS | subscriberLocationReport | releaseResources | mt-ForwardSM-VGCS | sendGroupCallInfo } -- The following operation codes are reserved for operations -- existing in previous versions of the protocol -- Operation Name AC used Oper. Code -- -- sendParameters map-ac infoRetrieval (14) version1 (1) local:9 -- processUnstructuredSS-Data map-ac networkFunctionalSs (18) version1 (1) local:19 -- performHandover map-ac handoverControl (11) version1 (1) local:28 -- performSubsequentHandover map-ac handoverControl (11) version1 (1) local:30 -- provideSIWFSNumber map-ac sIWFSAllocation (12) version3 (3) local:31 -- siwfs-SignallingModify map-ac sIWFSAllocation (12) version3 (3) local:32 -- noteInternalHandover map-ac handoverControl (11) version1 (1) local:35 -- noteSubscriberPresent map-ac mwdMngt (24) version1 (1) local:48 -- alertServiceCentreWithoutResult map-ac shortMsgAlert (23) version1 (1) local:49 -- traceSubscriberActivity map-ac handoverControl (11) version1 (1) local:52 -- beginSubscriberActivity map-ac networkFunctionalSs (18) version1 (1) local:54 -- The following error codes are reserved for errors -- existing in previous versions of the protocol -- Error Name AC used Error Code -- -- unknownBaseStation map-ac handoverControl (11) version1 (1) local:2 -- invalidTargetBaseStation map-ac handoverControl (11) version1 (1) local:23 -- noRadioResourceAvailable map-ac handoverControl (11) version1 (1) local:24 .#END 17.6 MAP operations and errors 17.6.1 Mobile Service Operations .$MAP-MobileServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MobileServiceOperations (5) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS -- location registration operations updateLocation, cancelLocation, purgeMS, sendIdentification, -- gprs location registration operations updateGprsLocation, -- vcsg location registration operations updateVcsgLocation, cancelVcsgLocation, -- subscriber information enquiry operations provideSubscriberInfo, -- any time information enquiry operations anyTimeInterrogation, -- any time information handling operations anyTimeSubscriptionInterrogation, anyTimeModification, -- subscriber data modification notification operations noteSubscriberDataModified, -- handover operations prepareHandover, sendEndSignal, processAccessSignalling, forwardAccessSignalling, prepareSubsequentHandover, -- authentication management operations sendAuthenticationInfo, authenticationFailureReport, -- IMEI management operations checkIMEI, -- subscriber management operations insertSubscriberData, deleteSubscriberData, -- fault recovery operations reset, forwardCheckSS-Indication, restoreData, -- gprs location information retrieval operations sendRoutingInfoForGprs, -- failure reporting operations failureReport, -- gprs notification operations noteMsPresentForGprs, -- Mobility Management operations noteMM-Event ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, unknownSubscriber, unknownMSC, unidentifiedSubscriber, unknownEquipment, roamingNotAllowed, ati-NotAllowed, noHandoverNumberAvailable, subsequentHandoverFailure, absentSubscriber, mm-EventNotSupported, atsi-NotAllowed, atm-NotAllowed, bearerServiceNotProvisioned, teleserviceNotProvisioned, callBarred, illegalSS-Operation, ss-ErrorStatus, ss-NotAvailable, ss-Incompatibility, ss-SubscriptionViolation, informationNotAvailable, targetCellOutsideGroupCallArea FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} UpdateLocationArg, UpdateLocationRes, CancelLocationArg, CancelLocationRes, PurgeMS-Arg, PurgeMS-Res, SendIdentificationArg, SendIdentificationRes, UpdateGprsLocationArg, UpdateGprsLocationRes, UpdateVcsgLocationArg, UpdateVcsgLocationRes, CancelVcsgLocationArg, CancelVcsgLocationRes, PrepareHO-Arg, PrepareHO-Res, ForwardAccessSignalling-Arg, ProcessAccessSignalling-Arg, SendEndSignal-Arg, SendEndSignal-Res, PrepareSubsequentHO-Res, PrepareSubsequentHO-Arg, SendAuthenticationInfoArg, SendAuthenticationInfoRes, AuthenticationFailureReportArg, AuthenticationFailureReportRes, CheckIMEI-Arg, CheckIMEI-Res, InsertSubscriberDataArg, InsertSubscriberDataRes, DeleteSubscriberDataArg, DeleteSubscriberDataRes, ResetArg, RestoreDataArg, RestoreDataRes, ProvideSubscriberInfoArg, ProvideSubscriberInfoRes, AnyTimeSubscriptionInterrogationArg, AnyTimeSubscriptionInterrogationRes, AnyTimeModificationArg, AnyTimeModificationRes, NoteSubscriberDataModifiedArg, NoteSubscriberDataModifiedRes, AnyTimeInterrogationArg, AnyTimeInterrogationRes, SendRoutingInfoForGprsArg, SendRoutingInfoForGprsRes, FailureReportArg, FailureReportRes, NoteMsPresentForGprsArg, NoteMsPresentForGprsRes, NoteMM-EventArg, NoteMM-EventRes FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} ; -- location registration operations updateLocation OPERATION ::= { --Timer m ARGUMENT UpdateLocationArg RESULT UpdateLocationRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber | roamingNotAllowed} CODE local:2 } cancelLocation OPERATION ::= { --Timer m ARGUMENT CancelLocationArg RESULT CancelLocationRes -- optional ERRORS { dataMissing | unexpectedDataValue} CODE local:3 } purgeMS OPERATION ::= { --Timer m ARGUMENT PurgeMS-Arg RESULT PurgeMS-Res -- optional ERRORS{ dataMissing | unexpectedDataValue| unknownSubscriber} CODE local:67 } sendIdentification OPERATION ::= { --Timer s ARGUMENT SendIdentificationArg RESULT SendIdentificationRes ERRORS { dataMissing | unidentifiedSubscriber} CODE local:55 } -- gprs location registration operations updateGprsLocation OPERATION ::= { --Timer m ARGUMENT UpdateGprsLocationArg RESULT UpdateGprsLocationRes ERRORS { systemFailure | unexpectedDataValue | unknownSubscriber | roamingNotAllowed} CODE local:23 } -- subscriber information enquiry operations provideSubscriberInfo OPERATION ::= { --Timer m ARGUMENT ProvideSubscriberInfoArg RESULT ProvideSubscriberInfoRes ERRORS { dataMissing | unexpectedDataValue} CODE local:70 } -- any time information enquiry operations anyTimeInterrogation OPERATION ::= { --Timer m ARGUMENT AnyTimeInterrogationArg RESULT AnyTimeInterrogationRes ERRORS { systemFailure | ati-NotAllowed | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:71 } -- any time information handling operations anyTimeSubscriptionInterrogation OPERATION ::= { --Timer m ARGUMENT AnyTimeSubscriptionInterrogationArg RESULT AnyTimeSubscriptionInterrogationRes ERRORS { atsi-NotAllowed | dataMissing | unexpectedDataValue | unknownSubscriber | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-NotAvailable | informationNotAvailable} CODE local:62 } anyTimeModification OPERATION ::= { --Timer m ARGUMENT AnyTimeModificationArg RESULT AnyTimeModificationRes ERRORS { atm-NotAllowed | dataMissing | unexpectedDataValue | unknownSubscriber | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-SubscriptionViolation | ss-ErrorStatus | ss-Incompatibility | informationNotAvailable} CODE local:65 } -- subscriber data modification notification operations noteSubscriberDataModified OPERATION ::= { --Timer m ARGUMENT NoteSubscriberDataModifiedArg RESULT NoteSubscriberDataModifiedRes -- optional ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:5 } -- handover operations prepareHandover OPERATION ::= { --Timer m ARGUMENT PrepareHO-Arg RESULT PrepareHO-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | noHandoverNumberAvailable | targetCellOutsideGroupCallArea } CODE local:68 } sendEndSignal OPERATION ::= { --Timer l ARGUMENT SendEndSignal-Arg RESULT SendEndSignal-Res CODE local:29 } processAccessSignalling OPERATION ::= { --Timer s ARGUMENT ProcessAccessSignalling-Arg CODE local:33 } forwardAccessSignalling OPERATION ::= { --Timer s ARGUMENT ForwardAccessSignalling-Arg CODE local:34 } prepareSubsequentHandover OPERATION ::= { --Timer m ARGUMENT PrepareSubsequentHO-Arg RESULT PrepareSubsequentHO-Res ERRORS { unexpectedDataValue | dataMissing | unknownMSC | subsequentHandoverFailure} CODE local:69 } -- authentication management operations sendAuthenticationInfo OPERATION ::= { --Timer m ARGUMENT SendAuthenticationInfoArg -- optional -- within a dialogue sendAuthenticationInfoArg shall not be present in -- subsequent invoke components. If received in a subsequent invoke component -- it shall be discarded."
"RESULT SendAuthenticationInfoRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:56 } authenticationFailureReport OPERATION ::= { --Timer m ARGUMENT AuthenticationFailureReportArg RESULT AuthenticationFailureReportRes -- optional ERRORS { systemFailure | unexpectedDataValue | unknownSubscriber} CODE local:15 } -- IMEI management operations checkIMEI OPERATION ::= { --Timer m ARGUMENT CheckIMEI-Arg RESULT CheckIMEI-Res ERRORS { systemFailure | dataMissing | unknownEquipment} CODE local:43 } -- subscriber management operations insertSubscriberData OPERATION ::= { --Timer m ARGUMENT InsertSubscriberDataArg RESULT InsertSubscriberDataRes -- optional ERRORS { dataMissing | unexpectedDataValue | unidentifiedSubscriber} CODE local:7 } deleteSubscriberData OPERATION ::= { --Timer m ARGUMENT DeleteSubscriberDataArg RESULT DeleteSubscriberDataRes -- optional ERRORS { dataMissing | unexpectedDataValue | unidentifiedSubscriber} CODE local:8 } -- fault recovery operations reset OPERATION ::= { --Timer m ARGUMENT ResetArg CODE local:37 } forwardCheckSS-Indication OPERATION ::= { --Timer s CODE local:38 } restoreData OPERATION ::= { --Timer m ARGUMENT RestoreDataArg RESULT RestoreDataRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:57 } -- gprs location information retrieval operations sendRoutingInfoForGprs OPERATION ::= { --Timer m ARGUMENT SendRoutingInfoForGprsArg RESULT SendRoutingInfoForGprsRes ERRORS { absentSubscriber | systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber | callBarred } CODE local:24 } -- failure reporting operations failureReport OPERATION ::= { --Timer m ARGUMENT FailureReportArg RESULT FailureReportRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:25 } -- gprs notification operations noteMsPresentForGprs OPERATION ::= { --Timer m ARGUMENT NoteMsPresentForGprsArg RESULT NoteMsPresentForGprsRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:26 } noteMM-Event OPERATION ::= { --Timer m ARGUMENT NoteMM-EventArg RESULT NoteMM-EventRes ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber | mm-EventNotSupported} CODE local:89 } -- vcsg location registration operations updateVcsgLocation OPERATION ::= { --Timer m ARGUMENT UpdateVcsgLocationArg RESULT UpdateVcsgLocationRes ERRORS { systemFailure | unexpectedDataValue | unknownSubscriber} CODE local:53 } cancelVcsgLocation OPERATION ::= { --Timer m ARGUMENT CancelVcsgLocationArg RESULT CancelVcsgLocationRes -- optional ERRORS { dataMissing | unexpectedDataValue} CODE local:36 } .#END 17.6.2 Operation and Maintenance Operations .$MAP-OperationAndMaintenanceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OperationAndMaintenanceOperations (6) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS activateTraceMode, deactivateTraceMode, sendIMSI ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, unknownSubscriber, unidentifiedSubscriber, tracingBufferFull FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} ActivateTraceModeArg, ActivateTraceModeRes, DeactivateTraceModeArg, DeactivateTraceModeRes FROM MAP-OM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OM-DataTypes (12) version20 (20)} ISDN-AddressString, IMSI FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ; activateTraceMode OPERATION ::= { --Timer m ARGUMENT ActivateTraceModeArg RESULT ActivateTraceModeRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unidentifiedSubscriber | tracingBufferFull} CODE local:50 } deactivateTraceMode OPERATION ::= { --Timer m ARGUMENT DeactivateTraceModeArg RESULT DeactivateTraceModeRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unidentifiedSubscriber} CODE local:51 } sendIMSI OPERATION ::= { --Timer m ARGUMENT ISDN-AddressString RESULT IMSI ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:58 } .#END 17.6.3 Call Handling Operations .$MAP-CallHandlingOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CallHandlingOperations (7) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS sendRoutingInfo, provideRoamingNumber, resumeCallHandling, setReportingState, statusReport, remoteUserFree, ist-Alert, ist-Command, releaseResources ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, or-NotAllowed, unknownSubscriber, numberChanged, bearerServiceNotProvisioned, teleserviceNotProvisioned, noRoamingNumberAvailable, absentSubscriber, busySubscriber, noSubscriberReply, callBarred, forwardingViolation, forwardingFailed, cug-Reject, resourceLimitation, incompatibleTerminal, unidentifiedSubscriber FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} SendRoutingInfoArg, SendRoutingInfoRes, ProvideRoamingNumberArg, ProvideRoamingNumberRes, ResumeCallHandlingArg, ResumeCallHandlingRes, SetReportingStateArg, SetReportingStateRes, StatusReportArg, StatusReportRes, RemoteUserFreeArg, RemoteUserFreeRes, IST-AlertArg, IST-AlertRes, IST-CommandArg, IST-CommandRes, ReleaseResourcesArg, ReleaseResourcesRes FROM MAP-CH-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CH-DataTypes (13) version20 (20)} ; sendRoutingInfo OPERATION ::= { --Timer m -- The timer is set to the upper limit of the range if the GMSC supports pre-paging. ARGUMENT SendRoutingInfoArg RESULT SendRoutingInfoRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | or-NotAllowed | unknownSubscriber | numberChanged | bearerServiceNotProvisioned | teleserviceNotProvisioned | absentSubscriber | busySubscriber | noSubscriberReply | callBarred | cug-Reject | forwardingViolation} CODE local:22 } provideRoamingNumber OPERATION ::= { --Timer m -- The timer is set to the upper limit of the range if the HLR supports pre-paging. ARGUMENT ProvideRoamingNumberArg RESULT ProvideRoamingNumberRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | or-NotAllowed | absentSubscriber | noRoamingNumberAvailable} CODE local:4 } resumeCallHandling OPERATION ::= { --Timer m ARGUMENT ResumeCallHandlingArg RESULT ResumeCallHandlingRes -- optional ERRORS { forwardingFailed | or-NotAllowed | unexpectedDataValue | dataMissing } CODE local:6 } setReportingState OPERATION ::= { --Timer m ARGUMENT SetReportingStateArg RESULT SetReportingStateRes -- optional ERRORS { systemFailure | unidentifiedSubscriber | unexpectedDataValue | dataMissing | resourceLimitation | facilityNotSupported} CODE local:73 } statusReport OPERATION ::= { --Timer m ARGUMENT StatusReportArg RESULT StatusReportRes -- optional ERRORS { unknownSubscriber | systemFailure | unexpectedDataValue | dataMissing} CODE local:74 } remoteUserFree OPERATION ::= { --Timer ml ARGUMENT RemoteUserFreeArg RESULT RemoteUserFreeRes ERRORS { unexpectedDataValue | dataMissing | incompatibleTerminal | absentSubscriber | systemFailure | busySubscriber} CODE local:75 } ist-Alert OPERATION ::= { --Timer m ARGUMENT IST-AlertArg RESULT IST-AlertRes -- optional ERRORS { unexpectedDataValue | resourceLimitation | unknownSubscriber | systemFailure | facilityNotSupported} CODE local:87 } ist-Command OPERATION::= { --Timer m ARGUMENT IST-CommandArg RESULT IST-CommandRes -- optional ERRORS { unexpectedDataValue | resourceLimitation | unknownSubscriber | systemFailure | facilityNotSupported} CODE local:88 } releaseResources OPERATION::= { --Timer m ARGUMENT ReleaseResourcesArg RESULT ReleaseResourcesRes -- optional ERRORS { unexpectedDataValue | systemFailure } CODE local:20 } .#END 17.6.4 Supplementary service operations .$MAP-SupplementaryServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SupplementaryServiceOperations (8) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS registerSS, eraseSS, activateSS, deactivateSS, interrogateSS, processUnstructuredSS-Request, unstructuredSS-Request, unstructuredSS-Notify, registerPassword, getPassword, ss-InvocationNotification, registerCC-Entry, eraseCC-Entry ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, unknownSubscriber, bearerServiceNotProvisioned, teleserviceNotProvisioned, callBarred, illegalSS-Operation, ss-ErrorStatus, ss-NotAvailable, ss-SubscriptionViolation, ss-Incompatibility, pw-RegistrationFailure, negativePW-Check, numberOfPW-AttemptsViolation, unknownAlphabet, ussd-Busy, absentSubscriber, illegalSubscriber, illegalEquipment, shortTermDenial, longTermDenial, facilityNotSupported FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} RegisterSS-Arg, SS-Info, SS-ForBS-Code, InterrogateSS-Res, USSD-Arg, USSD-Res, Password, GuidanceInfo, SS-InvocationNotificationArg, SS-InvocationNotificationRes, RegisterCC-EntryArg, RegisterCC-EntryRes, EraseCC-EntryArg, EraseCC-EntryRes FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} ; -- supplementary service handling operations registerSS OPERATION ::= { --Timer m ARGUMENT RegisterSS-Arg RESULT SS-Info -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-ErrorStatus | ss-Incompatibility} CODE local:10 } eraseSS OPERATION ::= { --Timer m ARGUMENT SS-ForBS-Code RESULT SS-Info -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-ErrorStatus } CODE local:11 } activateSS OPERATION ::= { --Timer m ARGUMENT SS-ForBS-Code RESULT SS-Info -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-ErrorStatus | ss-SubscriptionViolation | ss-Incompatibility | negativePW-Check | numberOfPW-AttemptsViolation} CODE local:12 } deactivateSS OPERATION ::= { --Timer m ARGUMENT SS-ForBS-Code RESULT SS-Info -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-ErrorStatus | ss-SubscriptionViolation | negativePW-Check | numberOfPW-AttemptsViolation} CODE local:13 } interrogateSS OPERATION ::= { --Timer m ARGUMENT SS-ForBS-Code RESULT InterrogateSS-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-NotAvailable} CODE local:14 } processUnstructuredSS-Request OPERATION ::= { --Timer 10 minutes ARGUMENT USSD-Arg RESULT USSD-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownAlphabet | callBarred} CODE local:59 } unstructuredSS-Request OPERATION ::= { --Timer ml ARGUMENT USSD-Arg RESULT USSD-Res -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | absentSubscriber | illegalSubscriber | illegalEquipment | unknownAlphabet | ussd-Busy} CODE local:60 } unstructuredSS-Notify OPERATION ::= { --Timer ml ARGUMENT USSD-Arg RETURN RESULT TRUE ERRORS { systemFailure | dataMissing | unexpectedDataValue | absentSubscriber | illegalSubscriber | illegalEquipment | unknownAlphabet | ussd-Busy} CODE local:61 } registerPassword OPERATION ::= { --Timer ml ARGUMENT SS-Code RESULT Password ERRORS { systemFailure | dataMissing | unexpectedDataValue | callBarred | ss-SubscriptionViolation | pw-RegistrationFailure | negativePW-Check | numberOfPW-AttemptsViolation} -- LINKED { -- getPassword} CODE local:17 } getPassword OPERATION ::= { --Timer m ARGUMENT GuidanceInfo RESULT Password CODE local:18 } ss-InvocationNotification OPERATION ::= { --Timer m ARGUMENT SS-InvocationNotificationArg RESULT SS-InvocationNotificationRes -- optional ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:72 } registerCC-Entry OPERATION ::= { --Timer m ARGUMENT RegisterCC-EntryArg RESULT RegisterCC-EntryRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | callBarred | illegalSS-Operation | ss-ErrorStatus | ss-Incompatibility | shortTermDenial | longTermDenial | facilityNotSupported} CODE local:76 } eraseCC-Entry OPERATION ::= { --Timer m ARGUMENT EraseCC-EntryArg RESULT EraseCC-EntryRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | callBarred | illegalSS-Operation | ss-ErrorStatus} CODE local:77 } .#END 17.6.5 Short message service operations .$MAP-ShortMessageServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS sendRoutingInfoForSM, mo-ForwardSM, mt-ForwardSM, reportSM-DeliveryStatus, alertServiceCentre, informServiceCentre, readyForSM, mt-ForwardSM-VGCS ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, unknownSubscriber, unidentifiedSubscriber, illegalSubscriber, illegalEquipment, teleserviceNotProvisioned, callBarred, subscriberBusyForMT-SMS, sm-DeliveryFailure, messageWaitingListFull, absentSubscriberSM FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} RoutingInfoForSM-Arg, RoutingInfoForSM-Res, MO-ForwardSM-Arg, MO-ForwardSM-Res, MT-ForwardSM-Arg, MT-ForwardSM-Res, ReportSM-DeliveryStatusArg, ReportSM-DeliveryStatusRes, AlertServiceCentreArg, InformServiceCentreArg, ReadyForSM-Arg, ReadyForSM-Res, MT-ForwardSM-VGCS-Arg, MT-ForwardSM-VGCS-Res FROM MAP-SM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version20 (20)} ; sendRoutingInfoForSM OPERATION ::= { --Timer m ARGUMENT RoutingInfoForSM-Arg RESULT RoutingInfoForSM-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unknownSubscriber | teleserviceNotProvisioned | callBarred | absentSubscriberSM} CODE local:45 } mo-ForwardSM OPERATION ::= { --Timer ml ARGUMENT MO-ForwardSM-Arg RESULT MO-ForwardSM-Res -- optional ERRORS { systemFailure | unexpectedDataValue | facilityNotSupported | sm-DeliveryFailure} CODE local:46 } mt-ForwardSM OPERATION ::= { --Timer ml -- the timer value may be subject to negotiation between GMSC and IP-SM-GW ARGUMENT MT-ForwardSM-Arg RESULT MT-ForwardSM-Res -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unidentifiedSubscriber | illegalSubscriber | illegalEquipment | subscriberBusyForMT-SMS | sm-DeliveryFailure | absentSubscriberSM} CODE local:44 } reportSM-DeliveryStatus OPERATION ::= { --Timer s ARGUMENT ReportSM-DeliveryStatusArg RESULT ReportSM-DeliveryStatusRes -- optional ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber | messageWaitingListFull} CODE local:47 } alertServiceCentre OPERATION ::= { --Timer s ARGUMENT AlertServiceCentreArg RETURN RESULT TRUE ERRORS { systemFailure | dataMissing | unexpectedDataValue} CODE local:64 } informServiceCentre OPERATION ::= { --Timer s ARGUMENT InformServiceCentreArg CODE local:63 } readyForSM OPERATION ::= { --Timer m ARGUMENT ReadyForSM-Arg RESULT ReadyForSM-Res -- optional ERRORS { dataMissing | unexpectedDataValue | facilityNotSupported | unknownSubscriber} CODE local:66 } mt-ForwardSM-VGCS OPERATION ::= { --Timer ml ARGUMENT MT-ForwardSM-VGCS-Arg RESULT MT-ForwardSM-VGCS-Res -- optional ERRORS { systemFailure | unexpectedDataValue } CODE local:21 } .#END 17.6.6 Errors .$MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS -- generic errors systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, incompatibleTerminal, resourceLimitation, -- identification and numbering errors unknownSubscriber, numberChanged, unknownMSC, unidentifiedSubscriber, unknownEquipment, -- subscription errors roamingNotAllowed, illegalSubscriber, illegalEquipment, bearerServiceNotProvisioned, teleserviceNotProvisioned, -- handover errors noHandoverNumberAvailable, subsequentHandoverFailure, targetCellOutsideGroupCallArea, -- operation and maintenance errors tracingBufferFull, -- call handling errors or-NotAllowed, noRoamingNumberAvailable, busySubscriber, noSubscriberReply, absentSubscriber, callBarred, forwardingViolation, forwardingFailed, cug-Reject, -- any time interrogation errors ati-NotAllowed, -- any time information handling errors atsi-NotAllowed, atm-NotAllowed, informationNotAvailable, -- supplementary service errors illegalSS-Operation, ss-ErrorStatus, ss-NotAvailable, ss-SubscriptionViolation, ss-Incompatibility, unknownAlphabet, ussd-Busy, pw-RegistrationFailure, negativePW-Check, numberOfPW-AttemptsViolation, shortTermDenial, longTermDenial, -- short message service errors subscriberBusyForMT-SMS, sm-DeliveryFailure, messageWaitingListFull, absentSubscriberSM, -- Group Call errors noGroupCallNumberAvailable, ongoingGroupCall, -- location service errors unauthorizedRequestingNetwork, unauthorizedLCSClient, positionMethodFailure, unknownOrUnreachableLCSClient, -- Mobility Management errors mm-EventNotSupported ; IMPORTS ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) } SS-Status FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} SS-IncompatibilityCause, PW-RegistrationFailureCause, SM-DeliveryFailureCause, SystemFailureParam, DataMissingParam, UnexpectedDataParam, FacilityNotSupParam, UnknownSubscriberParam, NumberChangedParam, UnidentifiedSubParam, RoamingNotAllowedParam, IllegalSubscriberParam, IllegalEquipmentParam, BearerServNotProvParam, TeleservNotProvParam, TracingBufferFullParam, NoRoamingNbParam, OR-NotAllowedParam, AbsentSubscriberParam, BusySubscriberParam, NoSubscriberReplyParam, CallBarredParam, ForwardingViolationParam, ForwardingFailedParam, CUG-RejectParam, ATI-NotAllowedParam, SubBusyForMT-SMS-Param, MessageWaitListFullParam, AbsentSubscriberSM-Param, ResourceLimitationParam, NoGroupCallNbParam, IncompatibleTerminalParam, ShortTermDenialParam, LongTermDenialParam, UnauthorizedRequestingNetwork-Param, UnauthorizedLCSClient-Param, PositionMethodFailure-Param, UnknownOrUnreachableLCSClient-Param, MM-EventNotSupported-Param, ATSI-NotAllowedParam, ATM-NotAllowedParam, IllegalSS-OperationParam, SS-NotAvailableParam, SS-SubscriptionViolationParam, InformationNotAvailableParam, TargetCellOutsideGCA-Param, OngoingGroupCallParam FROM MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version20 (20)} ; -- generic errors systemFailure ERROR ::= { PARAMETER SystemFailureParam -- optional CODE local:34 } dataMissing ERROR ::= { PARAMETER DataMissingParam -- optional -- DataMissingParam must not be used in version <3 CODE local:35 } unexpectedDataValue ERROR ::= { PARAMETER UnexpectedDataParam -- optional -- UnexpectedDataParam must not be used in version <3 CODE local:36 } facilityNotSupported ERROR ::= { PARAMETER FacilityNotSupParam -- optional -- FacilityNotSupParam must not be used in version <3 CODE local:21 } incompatibleTerminal ERROR ::= { PARAMETER IncompatibleTerminalParam -- optional CODE local:28 } resourceLimitation ERROR ::= { PARAMETER ResourceLimitationParam -- optional CODE local:51 } -- identification and numbering errors unknownSubscriber ERROR ::= { PARAMETER UnknownSubscriberParam -- optional -- UnknownSubscriberParam must not be used in version <3 CODE local:1 } numberChanged ERROR ::= { PARAMETER NumberChangedParam -- optional CODE local:44 } unknownMSC ERROR ::= { CODE local:3 } unidentifiedSubscriber ERROR ::= { PARAMETER UnidentifiedSubParam -- optional -- UunidentifiedSubParam must not be used in version <3 CODE local:5 } unknownEquipment ERROR ::= { CODE local:7 } -- subscription errors roamingNotAllowed ERROR ::= { PARAMETER RoamingNotAllowedParam CODE local:8 } illegalSubscriber ERROR ::= { PARAMETER IllegalSubscriberParam -- optional -- IllegalSubscriberParam must not be used in version <3 CODE local:9 } illegalEquipment ERROR ::= { PARAMETER IllegalEquipmentParam -- optional -- IllegalEquipmentParam must not be used in version <3 CODE local:12 } bearerServiceNotProvisioned ERROR ::= { PARAMETER BearerServNotProvParam -- optional -- BearerServNotProvParam must not be used in version <3 CODE local:10 } teleserviceNotProvisioned ERROR ::= { PARAMETER TeleservNotProvParam -- optional -- TeleservNotProvParam must not be used in version <3 CODE local:11 } -- handover errors noHandoverNumberAvailable ERROR ::= { CODE local:25 } subsequentHandoverFailure ERROR ::= { CODE local:26 } targetCellOutsideGroupCallArea ERROR ::= { PARAMETER TargetCellOutsideGCA-Param -- optional CODE local:42 } -- operation and maintenance errors tracingBufferFull ERROR ::= { PARAMETER TracingBufferFullParam -- optional CODE local: 40 } -- call handling errors noRoamingNumberAvailable ERROR ::= { PARAMETER NoRoamingNbParam -- optional CODE local:39 } absentSubscriber ERROR ::= { PARAMETER AbsentSubscriberParam -- optional -- AbsentSubscriberParam must not be used in version <3 CODE local:27 } busySubscriber ERROR ::= { PARAMETER BusySubscriberParam -- optional CODE local:45 } noSubscriberReply ERROR ::= { PARAMETER NoSubscriberReplyParam -- optional CODE local:46 } callBarred ERROR ::= { PARAMETER CallBarredParam -- optional CODE local:13 } forwardingViolation ERROR ::= { PARAMETER ForwardingViolationParam -- optional CODE local:14 } forwardingFailed ERROR ::= { PARAMETER ForwardingFailedParam -- optional CODE local:47 } cug-Reject ERROR ::= { PARAMETER CUG-RejectParam -- optional CODE local:15 } or-NotAllowed ERROR ::= { PARAMETER OR-NotAllowedParam -- optional CODE local:48 } -- any time interrogation errors ati-NotAllowed ERROR ::= { PARAMETER ATI-NotAllowedParam -- optional CODE local:49 } -- any time information handling errors atsi-NotAllowed ERROR ::= { PARAMETER ATSI-NotAllowedParam -- optional CODE local:60 } atm-NotAllowed ERROR ::= { PARAMETER ATM-NotAllowedParam -- optional CODE local:61 } informationNotAvailable ERROR ::= { PARAMETER InformationNotAvailableParam -- optional CODE local:62 } -- supplementary service errors illegalSS-Operation ERROR ::= { PARAMETER IllegalSS-OperationParam -- optional -- IllegalSS-OperationParam must not be used in version <3 CODE local:16 } ss-ErrorStatus ERROR ::= { PARAMETER SS-Status -- optional CODE local:17 } ss-NotAvailable ERROR ::= { PARAMETER SS-NotAvailableParam -- optional -- SS-NotAvailableParam must not be used in version <3 CODE local:18 } ss-SubscriptionViolation ERROR ::= { PARAMETER SS-SubscriptionViolationParam -- optional -- SS-SubscriptionViolationParam must not be used in version <3 CODE local:19 } ss-Incompatibility ERROR ::= { PARAMETER SS-IncompatibilityCause -- optional CODE local:20 } unknownAlphabet ERROR ::= { CODE local:71 } ussd-Busy ERROR ::= { CODE local:72 } pw-RegistrationFailure ERROR ::= { PARAMETER PW-RegistrationFailureCause CODE local:37 } negativePW-Check ERROR ::= { CODE local:38 } numberOfPW-AttemptsViolation ERROR ::= { CODE local:43 } shortTermDenial ERROR ::= { PARAMETER ShortTermDenialParam -- optional CODE local:29 } longTermDenial ERROR ::= { PARAMETER LongTermDenialParam -- optional CODE local:30 } -- short message service errors subscriberBusyForMT-SMS ERROR ::= { PARAMETER SubBusyForMT-SMS-Param -- optional CODE local:31 } sm-DeliveryFailure ERROR ::= { PARAMETER SM-DeliveryFailureCause CODE local:32 } messageWaitingListFull ERROR ::= { PARAMETER MessageWaitListFullParam -- optional CODE local:33 } absentSubscriberSM ERROR ::= { PARAMETER AbsentSubscriberSM-Param -- optional CODE local:6 } -- Group Call errors noGroupCallNumberAvailable ERROR ::= { PARAMETER NoGroupCallNbParam -- optional CODE local:50 } ongoingGroupCall ERROR ::= { PARAMETER OngoingGroupCallParam -- optional CODE local:22 } -- location service errors unauthorizedRequestingNetwork ERROR ::= { PARAMETER UnauthorizedRequestingNetwork-Param -- optional CODE local:52 } unauthorizedLCSClient ERROR ::= { PARAMETER UnauthorizedLCSClient-Param -- optional CODE local:53 } positionMethodFailure ERROR ::= { PARAMETER PositionMethodFailure-Param -- optional CODE local:54 } unknownOrUnreachableLCSClient ERROR ::= { PARAMETER UnknownOrUnreachableLCSClient-Param -- optional CODE local:58 } mm-EventNotSupported ERROR ::= { PARAMETER MM-EventNotSupported-Param -- optional CODE local:59 } .#END 17.6.7 Group Call operations .$MAP-Group-Call-Operations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Group-Call-Operations (22) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS prepareGroupCall, sendGroupCallEndSignal, forwardGroupCallSignalling, processGroupCallSignalling, sendGroupCallInfo ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, unexpectedDataValue, noGroupCallNumberAvailable, ongoingGroupCall, unknownSubscriber, teleserviceNotProvisioned, dataMissing FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} PrepareGroupCallArg, PrepareGroupCallRes, SendGroupCallEndSignalArg, SendGroupCallEndSignalRes, ForwardGroupCallSignallingArg, ProcessGroupCallSignallingArg, SendGroupCallInfoArg, SendGroupCallInfoRes FROM MAP-GR-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-GR-DataTypes (23) version20 (20)} ; prepareGroupCall OPERATION ::= { --Timer m ARGUMENT PrepareGroupCallArg RESULT PrepareGroupCallRes ERRORS { systemFailure | noGroupCallNumberAvailable | unexpectedDataValue} CODE local:39 } sendGroupCallEndSignal OPERATION ::= { --Timer l ARGUMENT SendGroupCallEndSignalArg RESULT SendGroupCallEndSignalRes CODE local:40 } processGroupCallSignalling OPERATION ::= { --Timer s ARGUMENT ProcessGroupCallSignallingArg CODE local:41 } forwardGroupCallSignalling OPERATION ::= { --Timer s ARGUMENT ForwardGroupCallSignallingArg CODE local:42 } sendGroupCallInfo OPERATION ::= { --Timer m ARGUMENT SendGroupCallInfoArg RESULT SendGroupCallInfoRes ERRORS { systemFailure | ongoingGroupCall | unexpectedDataValue | dataMissing | teleserviceNotProvisioned | unknownSubscriber} CODE local:84 } .#END 17.6.8 Location service operations .$MAP-LocationServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-LocationServiceOperations (24) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS provideSubscriberLocation, sendRoutingInfoForLCS, subscriberLocationReport ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, unknownSubscriber, absentSubscriber, unauthorizedRequestingNetwork, unauthorizedLCSClient, positionMethodFailure, resourceLimitation, unknownOrUnreachableLCSClient, unidentifiedSubscriber, illegalEquipment, illegalSubscriber FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} RoutingInfoForLCS-Arg, RoutingInfoForLCS-Res, ProvideSubscriberLocation-Arg, ProvideSubscriberLocation-Res, SubscriberLocationReport-Arg, SubscriberLocationReport-Res FROM MAP-LCS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-LCS-DataTypes (25) version20 (20)} ; sendRoutingInfoForLCS OPERATION ::= { --Timer m ARGUMENT RoutingInfoForLCS-Arg RESULT RoutingInfoForLCS-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unknownSubscriber | absentSubscriber | unauthorizedRequestingNetwork } CODE local:85 } provideSubscriberLocation OPERATION ::= { --Timer ml ARGUMENT ProvideSubscriberLocation-Arg RESULT ProvideSubscriberLocation-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unidentifiedSubscriber | illegalSubscriber | illegalEquipment | absentSubscriber | unauthorizedRequestingNetwork | unauthorizedLCSClient | positionMethodFailure } CODE local:83 } subscriberLocationReport OPERATION ::= { --Timer m ARGUMENT SubscriberLocationReport-Arg RESULT SubscriberLocationReport-Res ERRORS { systemFailure | dataMissing | resourceLimitation | unexpectedDataValue | unknownSubscriber | unauthorizedRequestingNetwork | unknownOrUnreachableLCSClient} CODE local:86 } .#END 17.6.9 Void 17.7 MAP constants and data types 17.7.1 Mobile Service data types .$MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS -- location registration types UpdateLocationArg, UpdateLocationRes, CancelLocationArg, CancelLocationRes, PurgeMS-Arg, PurgeMS-Res, SendIdentificationArg, SendIdentificationRes, UpdateGprsLocationArg, UpdateGprsLocationRes, IST-SupportIndicator, SupportedLCS-CapabilitySets, UpdateVcsgLocationArg, UpdateVcsgLocationRes, CancelVcsgLocationArg, CancelVcsgLocationRes, -- handover types ForwardAccessSignalling-Arg, PrepareHO-Arg, PrepareHO-Res, PrepareSubsequentHO-Arg, PrepareSubsequentHO-Res, ProcessAccessSignalling-Arg, SendEndSignal-Arg, SendEndSignal-Res, -- authentication management types SendAuthenticationInfoArg, SendAuthenticationInfoRes, AuthenticationFailureReportArg, AuthenticationFailureReportRes, -- security management types Kc, Cksn, -- equipment management types CheckIMEI-Arg, CheckIMEI-Res, -- subscriber management types InsertSubscriberDataArg, InsertSubscriberDataRes, LSAIdentity, DeleteSubscriberDataArg, DeleteSubscriberDataRes, Ext-QoS-Subscribed, Ext2-QoS-Subscribed, Ext3-QoS-Subscribed, Ext4-QoS-Subscribed, SubscriberData, ODB-Data, SubscriberStatus, ZoneCodeList, maxNumOfZoneCodes, O-CSI, D-CSI, O-BcsmCamelTDPCriteriaList, T-BCSM-CAMEL-TDP-CriteriaList, SS-CSI, ServiceKey, DefaultCallHandling, DefaultSMS-Handling, DefaultGPRS-Handling, CamelCapabilityHandling, BasicServiceCriteria, SupportedCamelPhases, OfferedCamel4CSIs, OfferedCamel4Functionalities, maxNumOfCamelTDPData, CUG-Index, CUG-Info, CUG-Interlock, InterCUG-Restrictions, IntraCUG-Options, NotificationToMSUser, QoS-Subscribed, IST-AlertTimerValue, T-CSI, T-BcsmTriggerDetectionPoint, APN, AdditionalInfo, -- fault recovery types ResetArg, RestoreDataArg, RestoreDataRes, -- provide subscriber info types GeographicalInformation, MS-Classmark2, GPRSMSClass, -- subscriber information enquiry types ProvideSubscriberInfoArg, ProvideSubscriberInfoRes, SubscriberInfo, LocationInformation, LocationInformationGPRS, SubscriberState, GPRSChargingID, MNPInfoRes, RouteingNumber, -- any time information enquiry types AnyTimeInterrogationArg, AnyTimeInterrogationRes, -- any time information handling types AnyTimeSubscriptionInterrogationArg, AnyTimeSubscriptionInterrogationRes, AnyTimeModificationArg, AnyTimeModificationRes, -- subscriber data modification notification types NoteSubscriberDataModifiedArg, NoteSubscriberDataModifiedRes, -- gprs location information retrieval types SendRoutingInfoForGprsArg, SendRoutingInfoForGprsRes, -- failure reporting types FailureReportArg, FailureReportRes, -- gprs notification types NoteMsPresentForGprsArg, NoteMsPresentForGprsRes, -- Mobility Management types NoteMM-EventArg, NoteMM-EventRes, NumberPortabilityStatus, PagingArea, -- VGCS / VBS types types GroupId, Long-GroupId, AdditionalSubscriptions ; IMPORTS maxNumOfSS, SS-SubscriptionOption, SS-List, SS-ForBS-Code, Password, OverrideCategory, CliRestrictionOption FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} Ext-BearerServiceCode FROM MAP-BS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-BS-Code (20) version20 (20)} Ext-TeleserviceCode FROM MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-TS-Code (19) version20 (20)} AddressString, ISDN-AddressString, ISDN-SubaddressString, FTN-AddressString, AccessNetworkSignalInfo, IMSI, IMEI, TMSI, HLR-List, LMSI, Identity, GlobalCellId, CellGlobalIdOrServiceAreaIdOrLAI, Ext-BasicServiceCode, NAEA-PreferredCI, EMLPP-Info, MC-SS-Info, SubscriberIdentity, AgeOfLocationInformation, LCSClientExternalID, LCSClientInternalID, Ext-SS-Status, LCSServiceTypeID, ASCI-CallReference, TBCD-STRING, LAIFixedLength, PLMN-Id, EMLPP-Priority, GSN-Address, DiameterIdentity, Time, E-UTRAN-CGI, NR-CGI, TA-Id, NR-TA-Id, RAIdentity, NetworkNodeDiameterAddress FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} AbsentSubscriberDiagnosticSM FROM MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version20 (20)} TracePropagationList FROM MAP-OM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OM-DataTypes (12) version20 (20)} ; -- location registration types UpdateLocationArg ::= SEQUENCE { imsi IMSI, msc-Number [1] ISDN-AddressString, vlr-Number ISDN-AddressString, lmsi [10] LMSI OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , vlr-Capability [6] VLR-Capability OPTIONAL, informPreviousNetworkEntity [11] NULL OPTIONAL, cs-LCS-NotSupportedByUE [12] NULL OPTIONAL, v-gmlc-Address [2] GSN-Address OPTIONAL, add-info [13] ADD-Info OPTIONAL, pagingArea [14] PagingArea OPTIONAL, skipSubscriberDataUpdate [15] NULL OPTIONAL, -- The skipSubscriberDataUpdate parameter in the UpdateLocationArg and the ADD-Info -- structures carry the same semantic. restorationIndicator [16] NULL OPTIONAL, eplmn-List [3] EPLMN-List OPTIONAL, mme-DiameterAddress [4] NetworkNodeDiameterAddress OPTIONAL } VLR-Capability ::= SEQUENCE{ supportedCamelPhases [0] SupportedCamelPhases OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , solsaSupportIndicator [2] NULL OPTIONAL, istSupportIndicator [1] IST-SupportIndicator OPTIONAL, superChargerSupportedInServingNetworkEntity [3] SuperChargerInfo OPTIONAL, longFTN-Supported [4] NULL OPTIONAL, supportedLCS-CapabilitySets [5] SupportedLCS-CapabilitySets OPTIONAL, offeredCamel4CSIs [6] OfferedCamel4CSIs OPTIONAL, supportedRAT-TypesIndicator [7] SupportedRAT-Types OPTIONAL, longGroupID-Supported [8] NULL OPTIONAL, mtRoamingForwardingSupported [9] NULL OPTIONAL, msisdn-lessOperation-Supported [10] NULL OPTIONAL, reset-ids-Supported [11] NULL OPTIONAL } SupportedRAT-Types::= BIT STRING { utran (0), geran (1), gan (2), i-hspa-evolution (3), e-utran (4), nb-iot (5)} (SIZE (2..8)) -- exception handling: bits 6 to 7 shall be ignored if received and not understood SuperChargerInfo ::= CHOICE { sendSubscriberData [0] NULL, subscriberDataStored [1] AgeIndicator } AgeIndicator ::= OCTET STRING (SIZE (1..6)) -- The internal structure of this parameter is implementation specific. IST-SupportIndicator ::= ENUMERATED { basicISTSupported (0), istCommandSupported (1), ...} -- exception handling: -- reception of values > 1 shall be mapped to ' istCommandSupported ' SupportedLCS-CapabilitySets ::= BIT STRING { lcsCapabilitySet1 (0), lcsCapabilitySet2 (1), lcsCapabilitySet3 (2), lcsCapabilitySet4 (3) , lcsCapabilitySet5 (4) } (SIZE (2..16)) -- Core network signalling capability set1 indicates LCS Release98 or Release99 version. -- Core network signalling capability set2 indicates LCS Release4. -- Core network signalling capability set3 indicates LCS Release5. -- Core network signalling capability set4 indicates LCS Release6. -- Core network signalling capability set5 indicates LCS Release7 or later version. -- A node shall mark in the BIT STRING all LCS capability sets it supports. -- If no bit is set then the sending node does not support LCS. -- If the parameter is not sent by an VLR then the VLR may support at most capability set1. -- If the parameter is not sent by an SGSN then no support for LCS is assumed. -- An SGSN is not allowed to indicate support of capability set1. -- Other bits than listed above shall be discarded. UpdateLocationRes ::= SEQUENCE { hlr-Number ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ..., add-Capability NULL OPTIONAL, pagingArea-Capability [0]NULL OPTIONAL } ADD-Info ::= SEQUENCE { imeisv [0] IMEI, skipSubscriberDataUpdate [1] NULL OPTIONAL, -- The skipSubscriberDataUpdate parameter in the UpdateLocationArg and the ADD-Info -- structures carry the same semantic. ...} PagingArea ::= SEQUENCE SIZE (1..5) OF LocationArea LocationArea ::= CHOICE { laiFixedLength [0] LAIFixedLength, lac [1] LAC} LAC ::= OCTET STRING (SIZE (2)) -- Refers to Location Area Code of the Location Area Identification defined in -- 3GPP TS 23.003 [17]. -- Location Area Code according to 3GPP TS 24.008 [35] CancelLocationArg ::= [3] SEQUENCE { identity Identity, cancellationType CancellationType OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., typeOfUpdate [0] TypeOfUpdate OPTIONAL, mtrf-SupportedAndAuthorized [1] NULL OPTIONAL, mtrf-SupportedAndNotAuthorized [2] NULL OPTIONAL, newMSC-Number [3] ISDN-AddressString OPTIONAL, newVLR-Number [4] ISDN-AddressString OPTIONAL, new-lmsi [5] LMSI OPTIONAL, reattach-Required [6] NULL OPTIONAL } --mtrf-SupportedAndAuthorized and mtrf-SupportedAndNotAuthorized shall not -- both be present TypeOfUpdate ::= ENUMERATED { sgsn-change (0), mme-change (1), ...} -- TypeOfUpdate shall be absent if CancellationType is different from updateProcedure -- and initialAttachProcedure CancellationType ::= ENUMERATED { updateProcedure (0), subscriptionWithdraw (1), ..., initialAttachProcedure (2)} -- The HLR shall not send values other than listed above CancelLocationRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} PurgeMS-Arg ::= [3] SEQUENCE { imsi IMSI, vlr-Number [0] ISDN-AddressString OPTIONAL, sgsn-Number [1] ISDN-AddressString OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., locationInformation [2] LocationInformation OPTIONAL, locationInformationGPRS [3] LocationInformationGPRS OPTIONAL, locationInformationEPS [4] LocationInformationEPS OPTIONAL } PurgeMS-Res ::= SEQUENCE { freezeTMSI [0] NULL OPTIONAL, freezeP-TMSI [1] NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., freezeM-TMSI [2] NULL OPTIONAL } SendIdentificationArg ::= SEQUENCE { tmsi TMSI, numberOfRequestedVectors NumberOfRequestedVectors OPTIONAL, -- within a dialogue numberOfRequestedVectors shall be present in -- the first service request and shall not be present in subsequent service requests. -- If received in a subsequent service request it shall be discarded. segmentationProhibited NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., msc-Number ISDN-AddressString OPTIONAL, previous-LAI [0] LAIFixedLength OPTIONAL, hopCounter [1] HopCounter OPTIONAL, mtRoamingForwardingSupported [2] NULL OPTIONAL, newVLR-Number [3] ISDN-AddressString OPTIONAL, new-lmsi [4] LMSI OPTIONAL } HopCounter ::= INTEGER (0..3) SendIdentificationRes ::= [3] SEQUENCE { imsi IMSI OPTIONAL, -- IMSI shall be present in the first (or only) service response of a dialogue. -- If multiple service requests are present in a dialogue then IMSI -- shall not be present in any service response other than the first one. authenticationSetList AuthenticationSetList OPTIONAL, currentSecurityContext [2]CurrentSecurityContext OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ..., lastUsedLtePLMN-Id [4] PLMN-Id OPTIONAL, mtCallPendingFlag [5] NULL OPTIONAL } -- authentication management types AuthenticationSetList ::= CHOICE { tripletList [0] TripletList, quintupletList [1] QuintupletList } TripletList ::= SEQUENCE SIZE (1..5) OF AuthenticationTriplet QuintupletList ::= SEQUENCE SIZE (1..5) OF AuthenticationQuintuplet AuthenticationTriplet ::= SEQUENCE { rand RAND, sres SRES, kc Kc, ...} AuthenticationQuintuplet ::= SEQUENCE { rand RAND, xres XRES, ck CK, ik IK, autn AUTN, ...} CurrentSecurityContext ::= CHOICE { gsm-SecurityContextData [0] GSM-SecurityContextData, umts-SecurityContextData [1] UMTS-SecurityContextData } GSM-SecurityContextData ::= SEQUENCE { kc Kc, cksn Cksn, ... } UMTS-SecurityContextData ::= SEQUENCE { ck CK, ik IK, ksi KSI, ... } RAND ::= OCTET STRING (SIZE (16)) SRES ::= OCTET STRING (SIZE (4)) Kc ::= OCTET STRING (SIZE (8)) XRES ::= OCTET STRING (SIZE (4..16)) CK ::= OCTET STRING (SIZE (16)) IK ::= OCTET STRING (SIZE (16)) AUTN ::= OCTET STRING (SIZE (16)) AUTS ::= OCTET STRING (SIZE (14)) Cksn ::= OCTET STRING (SIZE (1)) -- The internal structure is defined in 3GPP TS 24.008 KSI ::= OCTET STRING (SIZE (1)) -- The internal structure is defined in 3GPP TS 24.008 AuthenticationFailureReportArg ::= SEQUENCE { imsi IMSI, failureCause FailureCause, extensionContainer ExtensionContainer OPTIONAL, ... , re-attempt BOOLEAN OPTIONAL, accessType AccessType OPTIONAL, rand RAND OPTIONAL, vlr-Number [0] ISDN-AddressString OPTIONAL, sgsn-Number [1] ISDN-AddressString OPTIONAL } AccessType ::= ENUMERATED { call (0), emergencyCall (1), locationUpdating (2), supplementaryService (3), shortMessage (4), gprsAttach (5), routingAreaUpdating (6), serviceRequest (7), pdpContextActivation (8), pdpContextDeactivation (9), ..., gprsDetach (10)} -- exception handling: -- received values greater than 10 shall be ignored. AuthenticationFailureReportRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} FailureCause ::= ENUMERATED { wrongUserResponse (0), wrongNetworkSignature (1)} -- gprs location registration types UpdateGprsLocationArg ::= SEQUENCE { imsi IMSI, sgsn-Number ISDN-AddressString, sgsn-Address GSN-Address, extensionContainer ExtensionContainer OPTIONAL, ... , sgsn-Capability [0] SGSN-Capability OPTIONAL, informPreviousNetworkEntity [1] NULL OPTIONAL, ps-LCS-NotSupportedByUE [2] NULL OPTIONAL, v-gmlc-Address [3] GSN-Address OPTIONAL, add-info [4] ADD-Info OPTIONAL, eps-info [5] EPS-Info OPTIONAL, servingNodeTypeIndicator [6] NULL OPTIONAL, skipSubscriberDataUpdate [7] NULL OPTIONAL, usedRAT-Type [8] Used-RAT-Type OPTIONAL, gprsSubscriptionDataNotNeeded [9] NULL OPTIONAL, nodeTypeIndicator [10] NULL OPTIONAL, areaRestricted [11] NULL OPTIONAL, ue-reachableIndicator [12] NULL OPTIONAL, epsSubscriptionDataNotNeeded [13] NULL OPTIONAL, ue-srvcc-Capability [14] UE-SRVCC-Capability OPTIONAL, eplmn-List [15] EPLMN-List OPTIONAL, mmeNumberforMTSMS [16] ISDN-AddressString OPTIONAL, smsRegisterRequest [17] SMSRegisterRequest OPTIONAL, sms-Only [18] NULL OPTIONAL, removalofMMERegistrationforSMS [22] NULL OPTIONAL, sgsn-Name [19] DiameterIdentity OPTIONAL, sgsn-Realm [20] DiameterIdentity OPTIONAL, lgd-supportIndicator [21] NULL OPTIONAL, adjacentPLMN-List [23] AdjacentPLMN-List OPTIONAL } SMSRegisterRequest::= ENUMERATED { sms-registration-required (0), sms-registration-not-preferred (1), no-preference (2), ...} Used-RAT-Type::= ENUMERATED { utran (0), geran (1), gan (2), i-hspa-evolution (3), e-utran (4), ..., nb-iot (5)} -- The value e-utran indicates wide-band e-utran EPS-Info ::= CHOICE{ pdn-gw-update [0] PDN-GW-Update, isr-Information [1] ISR-Information } PDN-GW-Update ::= SEQUENCE{ apn [0] APN OPTIONAL, pdn-gw-Identity [1] PDN-GW-Identity OPTIONAL, contextId [2] ContextId OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ... } -- The pdn-gw-update IE shall include the pdn-gw-Identity, and the apn or/and the contextID. -- The HSS shall ignore the eps-info IE if it includes a pdn-gw-update IE which does not -- include pdn-gw-Identity. -- The pdn-gw-Identity is defined as OPTIONAL for backward compatility reason with -- outdated earlier versions of this specification. ISR-Information::= BIT STRING { updateLocation (0), cancelSGSN (1), initialAttachIndicator (2)} (SIZE (3..8)) -- exception handling: reception of unknown bit assignments in the -- ISR-Information data type shall be discarded by the receiver SGSN-Capability ::= SEQUENCE{ solsaSupportIndicator NULL OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... , superChargerSupportedInServingNetworkEntity [2] SuperChargerInfo OPTIONAL , gprsEnhancementsSupportIndicator [3] NULL OPTIONAL, supportedCamelPhases [4] SupportedCamelPhases OPTIONAL, supportedLCS-CapabilitySets [5] SupportedLCS-CapabilitySets OPTIONAL, offeredCamel4CSIs [6] OfferedCamel4CSIs OPTIONAL, smsCallBarringSupportIndicator [7] NULL OPTIONAL, supportedRAT-TypesIndicator [8] SupportedRAT-Types OPTIONAL, supportedFeatures [9] SupportedFeatures OPTIONAL, t-adsDataRetrieval [10] NULL OPTIONAL, homogeneousSupportOfIMSVoiceOverPSSessions [11] BOOLEAN OPTIONAL, -- ""true"" indicates homogeneous support, ""false"" indicates homogeneous non-support -- in the complete SGSN or MME area cancellationTypeInitialAttach [12] NULL OPTIONAL, msisdn-lessOperation-Supported [14] NULL OPTIONAL, updateofHomogeneousSupportOfIMSVoiceOverPSSessions [15] NULL OPTIONAL, reset-ids-Supported [16] NULL OPTIONAL, ext-SupportedFeatures [17] Ext-SupportedFeatures OPTIONAL } -- the supportedFeatures , t-adsDataRetrieval, -- homogeneousSupportOfIMSVoiceOverPSSessions -- /updateofHomogeneousSupportOfIMSVoiceOverPSSessions and -- ext-SupportedFeatures are also applied to the MME/IWF SupportedFeatures::= BIT STRING { odb-all-apn (0), odb-HPLMN-APN (1), odb-VPLMN-APN (2), odb-all-og (3), odb-all-international-og (4), odb-all-int-og-not-to-HPLMN-country (5), odb-all-interzonal-og (6), odb-all-interzonal-og-not-to-HPLMN-country (7), odb-all-interzonal-og-and-internat-og-not-to-HPLMN-country (8), regSub (9), trace (10), lcs-all-PrivExcep (11), lcs-universal (12), lcs-CallSessionRelated (13), lcs-CallSessionUnrelated (14), lcs-PLMN-operator (15), lcs-ServiceType (16), lcs-all-MOLR-SS (17), lcs-basicSelfLocation (18), lcs-autonomousSelfLocation (19), lcs-transferToThirdParty (20), sm-mo-pp (21), barring-OutgoingCalls (22), baoc (23), boic (24), boicExHC (25), localTimeZoneRetrieval (26), additionalMsisdn (27), smsInMME (28), smsInSGSN (29), ue-Reachability-Notification (30), state-Location-Information-Retrieval (31), partialPurge (32), gddInSGSN (33), sgsnCAMELCapability (34), pcscf-Restoration (35), dedicatedCoreNetworks (36), non-IP-PDN-Type-APNs (37), non-IP-PDP-Type-APNs (38), nrAsSecondaryRAT (39) } (SIZE (26..40)) -- for the definition and usage of the above features see the 3GPP TS 29.272 [144]. -- Additional supported features are encoded in Ext-SupportedFeatures bit string. Ext-SupportedFeatures ::= BIT STRING { unlicensedSpectrumAsSecondaryRAT (0) } (SIZE (1..40)) UE-SRVCC-Capability::= ENUMERATED { ue-srvcc-not-supported (0), ue-srvcc-supported (1), ...} UpdateGprsLocationRes ::= SEQUENCE { hlr-Number ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ..., add-Capability NULL OPTIONAL, sgsn-mmeSeparationSupported [0] NULL OPTIONAL, mmeRegisteredforSMS [1] NULL OPTIONAL } EPLMN-List ::= SEQUENCE SIZE (1..50) OF PLMN-Id AdjacentPLMN-List ::= SEQUENCE SIZE (1..50) OF PLMN-Id -- handover types ForwardAccessSignalling-Arg ::= [3] SEQUENCE { an-APDU AccessNetworkSignalInfo, integrityProtectionInfo [0] IntegrityProtectionInformation OPTIONAL, encryptionInfo [1] EncryptionInformation OPTIONAL, keyStatus [2] KeyStatus OPTIONAL, allowedGSM-Algorithms [4] AllowedGSM-Algorithms OPTIONAL, allowedUMTS-Algorithms [5] AllowedUMTS-Algorithms OPTIONAL, radioResourceInformation [6] RadioResourceInformation OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ..., radioResourceList [7] RadioResourceList OPTIONAL, bssmap-ServiceHandover [9] BSSMAP-ServiceHandover OPTIONAL, ranap-ServiceHandover [8] RANAP-ServiceHandover OPTIONAL, bssmap-ServiceHandoverList [10] BSSMAP-ServiceHandoverList OPTIONAL, currentlyUsedCodec [11] Codec OPTIONAL, iuSupportedCodecsList [12] SupportedCodecsList OPTIONAL, rab-ConfigurationIndicator [13] NULL OPTIONAL, iuSelectedCodec [14] Codec OPTIONAL, alternativeChannelType [15] RadioResourceInformation OPTIONAL, tracePropagationList [17] TracePropagationList OPTIONAL, aoipSupportedCodecsListAnchor [18] AoIPCodecsList OPTIONAL, aoipSelectedCodecTarget [19] AoIPCodec OPTIONAL, uesbi-Iu [20] UESBI-Iu OPTIONAL, imeisv [21] IMEI OPTIONAL } AllowedGSM-Algorithms ::= OCTET STRING (SIZE (1)) -- internal structure is coded as Algorithm identifier octet from -- Permitted Algorithms defined in 3GPP TS 48.008 -- A node shall mark all GSM algorithms that are allowed in MSC-B AllowedUMTS-Algorithms ::= SEQUENCE { integrityProtectionAlgorithms [0] PermittedIntegrityProtectionAlgorithms OPTIONAL, encryptionAlgorithms [1] PermittedEncryptionAlgorithms OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} PermittedIntegrityProtectionAlgorithms ::= OCTET STRING (SIZE (1..maxPermittedIntegrityProtectionAlgorithmsLength)) -- Octets contain a complete PermittedIntegrityProtectionAlgorithms data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413. -- Padding bits are included, if needed, in the least significant bits of the -- last octet of the octet string. maxPermittedIntegrityProtectionAlgorithmsLength INTEGER ::= 9 PermittedEncryptionAlgorithms ::= OCTET STRING (SIZE (1..maxPermittedEncryptionAlgorithmsLength)) -- Octets contain a complete PermittedEncryptionAlgorithms data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included, if needed, in the least significant bits of the -- last octet of the octet string. maxPermittedEncryptionAlgorithmsLength INTEGER ::= 9 KeyStatus ::= ENUMERATED { old (0), new (1), ...} -- exception handling: -- received values in range 2-31 shall be treated as ""old"" -- received values greater than 31 shall be treated as ""new"" PrepareHO-Arg ::= [3] SEQUENCE { targetCellId [0] GlobalCellId OPTIONAL, ho-NumberNotRequired NULL OPTIONAL, targetRNCId [1] RNCId OPTIONAL, an-APDU [2] AccessNetworkSignalInfo OPTIONAL, multipleBearerRequested [3] NULL OPTIONAL, imsi [4] IMSI OPTIONAL, integrityProtectionInfo [5] IntegrityProtectionInformation OPTIONAL, encryptionInfo [6] EncryptionInformation OPTIONAL, radioResourceInformation [7] RadioResourceInformation OPTIONAL, allowedGSM-Algorithms [9] AllowedGSM-Algorithms OPTIONAL, allowedUMTS-Algorithms [10] AllowedUMTS-Algorithms OPTIONAL, radioResourceList [11] RadioResourceList OPTIONAL, extensionContainer [8] ExtensionContainer OPTIONAL, ... , rab-Id [12] RAB-Id OPTIONAL, bssmap-ServiceHandover [13] BSSMAP-ServiceHandover OPTIONAL, ranap-ServiceHandover [14] RANAP-ServiceHandover OPTIONAL, bssmap-ServiceHandoverList [15] BSSMAP-ServiceHandoverList OPTIONAL, asciCallReference [20] ASCI-CallReference OPTIONAL, geran-classmark [16] GERAN-Classmark OPTIONAL, iuCurrentlyUsedCodec [17] Codec OPTIONAL, iuSupportedCodecsList [18] SupportedCodecsList OPTIONAL, rab-ConfigurationIndicator [19] NULL OPTIONAL, uesbi-Iu [21] UESBI-Iu OPTIONAL, imeisv [22] IMEI OPTIONAL, alternativeChannelType [23] RadioResourceInformation OPTIONAL, tracePropagationList [25] TracePropagationList OPTIONAL, aoipSupportedCodecsListAnchor [26] AoIPCodecsList OPTIONAL, regionalSubscriptionData [27] ZoneCodeList OPTIONAL, lclsGlobalCallReference [28] LCLS-GlobalCallReference OPTIONAL, lcls-Negotiation [29] LCLS-Negotiation OPTIONAL, lcls-Configuration-Preference [30] LCLS-ConfigurationPreference OPTIONAL, csg-SubscriptionDataList [31] CSG-SubscriptionDataList OPTIONAL } LCLS-GlobalCallReference ::= OCTET STRING (SIZE (13..15)) -- Octets are coded as specified in 3GPP TS 29.205 [146] LCLS-Negotiation::= BIT STRING { permission-indicator-not-allowed-bit (0), permission-indicator-spare-bit (1)} (SIZE (2..8)) --for definition and allowed combination of bits 0 and 1 see 3GPP TS 29.205 -- exception handling: bits 2 to 7 shall be ignored if received and not understood LCLS-ConfigurationPreference::= BIT STRING { forward-data-sending-indicator (0), backward-data-sending-indicator (1), forward-data-reception-indicator (2), backward-data-reception-indicator (3)} (SIZE (4..8)) -- exception handling: bits 4 to 7 shall be ignored if received and not understood BSSMAP-ServiceHandoverList ::= SEQUENCE SIZE (1.. maxNumOfServiceHandovers) OF BSSMAP-ServiceHandoverInfo BSSMAP-ServiceHandoverInfo ::= SEQUENCE { bssmap-ServiceHandover BSSMAP-ServiceHandover, rab-Id RAB-Id, -- RAB Identity is needed to relate the service handovers with the radio access bearers. ...} maxNumOfServiceHandovers INTEGER ::= 7 BSSMAP-ServiceHandover ::= OCTET STRING (SIZE (1)) -- Octets are coded according the Service Handover information element in -- 3GPP TS 48.008. RANAP-ServiceHandover ::= OCTET STRING (SIZE (1)) -- Octet contains a complete Service-Handover data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included in the least significant bits. RadioResourceList ::= SEQUENCE SIZE (1.. maxNumOfRadioResources) OF RadioResource RadioResource ::= SEQUENCE { radioResourceInformation RadioResourceInformation, rab-Id RAB-Id, -- RAB Identity is needed to relate the radio resources with the radio access bearers. ...} maxNumOfRadioResources INTEGER ::= 7 PrepareHO-Res ::= [3] SEQUENCE { handoverNumber [0] ISDN-AddressString OPTIONAL, relocationNumberList [1] RelocationNumberList OPTIONAL, an-APDU [2] AccessNetworkSignalInfo OPTIONAL, multicallBearerInfo [3] MulticallBearerInfo OPTIONAL, multipleBearerNotSupported NULL OPTIONAL, selectedUMTS-Algorithms [5] SelectedUMTS-Algorithms OPTIONAL, chosenRadioResourceInformation [6] ChosenRadioResourceInformation OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., iuSelectedCodec [7] Codec OPTIONAL, iuAvailableCodecsList [8] CodecList OPTIONAL, aoipSelectedCodecTarget [9] AoIPCodec OPTIONAL, aoipAvailableCodecsListMap [10] AoIPCodecsList OPTIONAL } SelectedUMTS-Algorithms ::= SEQUENCE { integrityProtectionAlgorithm [0] ChosenIntegrityProtectionAlgorithm OPTIONAL, encryptionAlgorithm [1] ChosenEncryptionAlgorithm OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} ChosenIntegrityProtectionAlgorithm ::= OCTET STRING (SIZE (1)) -- Octet contains a complete IntegrityProtectionAlgorithm data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included in the least significant bits. ChosenEncryptionAlgorithm ::= OCTET STRING (SIZE (1)) -- Octet contains a complete EncryptionAlgorithm data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included in the least significant bits."
"ChosenRadioResourceInformation ::= SEQUENCE { chosenChannelInfo [0] ChosenChannelInfo OPTIONAL, chosenSpeechVersion [1] ChosenSpeechVersion OPTIONAL, ...} ChosenChannelInfo ::= OCTET STRING (SIZE (1)) -- Octets are coded according the Chosen Channel information element in 3GPP TS 48.008 ChosenSpeechVersion ::= OCTET STRING (SIZE (1)) -- Octets are coded according the Speech Version (chosen) information element in 3GPP TS -- 48.008 PrepareSubsequentHO-Arg ::= [3] SEQUENCE { targetCellId [0] GlobalCellId OPTIONAL, targetMSC-Number [1] ISDN-AddressString, targetRNCId [2] RNCId OPTIONAL, an-APDU [3] AccessNetworkSignalInfo OPTIONAL, selectedRab-Id [4] RAB-Id OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ..., geran-classmark [6] GERAN-Classmark OPTIONAL, rab-ConfigurationIndicator [7] NULL OPTIONAL } PrepareSubsequentHO-Res ::= [3] SEQUENCE { an-APDU AccessNetworkSignalInfo, extensionContainer [0] ExtensionContainer OPTIONAL, ...} ProcessAccessSignalling-Arg ::= [3] SEQUENCE { an-APDU AccessNetworkSignalInfo, selectedUMTS-Algorithms [1] SelectedUMTS-Algorithms OPTIONAL, selectedGSM-Algorithm [2] SelectedGSM-Algorithm OPTIONAL, chosenRadioResourceInformation [3] ChosenRadioResourceInformation OPTIONAL, selectedRab-Id [4] RAB-Id OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ..., iUSelectedCodec [5] Codec OPTIONAL, iuAvailableCodecsList [6] CodecList OPTIONAL, aoipSelectedCodecTarget [7] AoIPCodec OPTIONAL, aoipAvailableCodecsListMap [8] AoIPCodecsList OPTIONAL } AoIPCodecsList ::= SEQUENCE { codec1 [1] AoIPCodec, codec2 [2] AoIPCodec OPTIONAL, codec3 [3] AoIPCodec OPTIONAL, codec4 [4] AoIPCodec OPTIONAL, codec5 [5] AoIPCodec OPTIONAL, codec6 [6] AoIPCodec OPTIONAL, codec7 [7] AoIPCodec OPTIONAL, codec8 [8] AoIPCodec OPTIONAL, extensionContainer [9] ExtensionContainer OPTIONAL, ...} -- Codecs are sent in priority order where codec1 has highest priority AoIPCodec ::= OCTET STRING (SIZE (1..3)) -- The internal structure is defined as follows: -- octet 1 Coded as Speech Codec Elements in 3GPP TS 48.008 -- with the exception that FI, PI, PT and TF bits shall -- be set to 0 -- octets 2,3 Optional; in case of AMR codec types it defines -- the supported codec configurations as defined in -- 3GPP TS 48.008 SupportedCodecsList ::= SEQUENCE { utranCodecList [0] CodecList OPTIONAL, geranCodecList [1] CodecList OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} CodecList ::= SEQUENCE { codec1 [1] Codec, codec2 [2] Codec OPTIONAL, codec3 [3] Codec OPTIONAL, codec4 [4] Codec OPTIONAL, codec5 [5] Codec OPTIONAL, codec6 [6] Codec OPTIONAL, codec7 [7] Codec OPTIONAL, codec8 [8] Codec OPTIONAL, extensionContainer [9] ExtensionContainer OPTIONAL, ...} -- Codecs are sent in priority order where codec1 has highest priority Codec ::= OCTET STRING (SIZE (1..4)) -- The internal structure is defined as follows: -- octet 1 Coded as Codec Identification code in 3GPP TS 26.103 -- octets 2,3,4 Parameters for the Codec as defined in 3GPP TS -- 26.103, if available, length depending on the codec GERAN-Classmark ::= OCTET STRING (SIZE (2..87)) -- Octets are coded according the GERAN Classmark information element in 3GPP TS 48.008 SelectedGSM-Algorithm ::= OCTET STRING (SIZE (1)) -- internal structure is coded as Algorithm identifier octet from Chosen Encryption -- Algorithm defined in 3GPP TS 48.008 -- A node shall mark only the selected GSM algorithm SendEndSignal-Arg ::= [3] SEQUENCE { an-APDU AccessNetworkSignalInfo, extensionContainer [0] ExtensionContainer OPTIONAL, ...} SendEndSignal-Res ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ...} RNCId ::= OCTET STRING (SIZE (7)) -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code according to 3GPP TS 24.008 -- octets 6 and 7 RNC Id or Extended RNC Id value according to -- 3GPP TS 25.413 RelocationNumberList ::= SEQUENCE SIZE (1..maxNumOfRelocationNumber) OF RelocationNumber MulticallBearerInfo ::= INTEGER (1..maxNumOfRelocationNumber) RelocationNumber ::= SEQUENCE { handoverNumber ISDN-AddressString, rab-Id RAB-Id, -- RAB Identity is needed to relate the calls with the radio access bearers. ...} RAB-Id ::= INTEGER (1..maxNrOfRABs) maxNrOfRABs INTEGER ::= 255 maxNumOfRelocationNumber INTEGER ::= 7 RadioResourceInformation ::= OCTET STRING (SIZE (3..13)) -- Octets are coded according the Channel Type information element in 3GPP TS 48.008 IntegrityProtectionInformation ::= OCTET STRING (SIZE (18..maxNumOfIntegrityInfo)) -- Octets contain a complete IntegrityProtectionInformation data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included, if needed, in the least significant bits of the -- last octet of the octet string. maxNumOfIntegrityInfo INTEGER ::= 100 EncryptionInformation ::= OCTET STRING (SIZE (18..maxNumOfEncryptionInfo)) -- Octets contain a complete EncryptionInformation data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included, if needed, in the least significant bits of the -- last octet of the octet string. maxNumOfEncryptionInfo INTEGER ::= 100 -- authentication management types SendAuthenticationInfoArg ::= SEQUENCE { imsi [0] IMSI, numberOfRequestedVectors NumberOfRequestedVectors, segmentationProhibited NULL OPTIONAL, immediateResponsePreferred [1] NULL OPTIONAL, re-synchronisationInfo Re-synchronisationInfo OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., requestingNodeType [3] RequestingNodeType OPTIONAL, requestingPLMN-Id [4] PLMN-Id OPTIONAL, numberOfRequestedAdditional-Vectors [5] NumberOfRequestedVectors OPTIONAL, additionalVectorsAreForEPS [6] NULL OPTIONAL, ueUsageTypeRequestIndication [7] NULL OPTIONAL } NumberOfRequestedVectors ::= INTEGER (1..5) Re-synchronisationInfo ::= SEQUENCE { rand RAND, auts AUTS, ...} SendAuthenticationInfoRes ::= [3] SEQUENCE { authenticationSetList AuthenticationSetList OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., eps-AuthenticationSetList [2] EPS-AuthenticationSetList OPTIONAL, ueUsageType [3] UE-UsageType OPTIONAL } EPS-AuthenticationSetList ::= SEQUENCE SIZE (1..5) OF EPC-AV UE-UsageType::= OCTET STRING (SIZE (4)) -- octets are coded as defined in 3GPP TS 29.272 [144] EPC-AV ::= SEQUENCE { rand RAND, xres XRES, autn AUTN, kasme KASME, extensionContainer ExtensionContainer OPTIONAL, ...} KASME ::= OCTET STRING (SIZE (32)) RequestingNodeType ::= ENUMERATED { vlr (0), sgsn (1), ..., s-cscf (2), bsf (3), gan-aaa-server (4), wlan-aaa-server (5), mme (16), mme-sgsn (17) } -- the values 2, 3, 4 and 5 shall not be used on the MAP-D or Gr interfaces -- exception handling: -- received values in the range (6-15) shall be treated as ""vlr"" -- received values greater than 17 shall be treated as ""sgsn"" -- equipment management types CheckIMEI-Arg ::= SEQUENCE { imei IMEI, requestedEquipmentInfo RequestedEquipmentInfo, extensionContainer ExtensionContainer OPTIONAL, ...} CheckIMEI-Res ::= SEQUENCE { equipmentStatus EquipmentStatus OPTIONAL, bmuef UESBI-Iu OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ...} RequestedEquipmentInfo::= BIT STRING { equipmentStatus (0), bmuef (1)} (SIZE (2..8)) -- exception handling: reception of unknown bit assignments in the -- RequestedEquipmentInfo data type shall be discarded by the receiver UESBI-Iu ::= SEQUENCE { uesbi-IuA [0] UESBI-IuA OPTIONAL, uesbi-IuB [1] UESBI-IuB OPTIONAL, ...} UESBI-IuA ::= BIT STRING (SIZE(1..128)) -- See 3GPP TS 25.413 UESBI-IuB ::= BIT STRING (SIZE(1..128)) -- See 3GPP TS 25.413 EquipmentStatus ::= ENUMERATED { permittedListed (0), prohibitedListed (1), trackingListed (2)} -- subscriber management types InsertSubscriberDataArg ::= SEQUENCE { imsi [0] IMSI OPTIONAL, COMPONENTS OF SubscriberData, extensionContainer [14] ExtensionContainer OPTIONAL, ... , naea-PreferredCI [15] NAEA-PreferredCI OPTIONAL, -- naea-PreferredCI is included at the discretion of the HLR operator. gprsSubscriptionData [16] GPRSSubscriptionData OPTIONAL, roamingRestrictedInSgsnDueToUnsupportedFeature [23] NULL OPTIONAL, networkAccessMode [24] NetworkAccessMode OPTIONAL, lsaInformation [25] LSAInformation OPTIONAL, lmu-Indicator [21] NULL OPTIONAL, lcsInformation [22] LCSInformation OPTIONAL, istAlertTimer [26] IST-AlertTimerValue OPTIONAL, superChargerSupportedInHLR [27] AgeIndicator OPTIONAL, mc-SS-Info [28] MC-SS-Info OPTIONAL, cs-AllocationRetentionPriority [29] CS-AllocationRetentionPriority OPTIONAL, sgsn-CAMEL-SubscriptionInfo [17] SGSN-CAMEL-SubscriptionInfo OPTIONAL, chargingCharacteristics [18] ChargingCharacteristics OPTIONAL, accessRestrictionData [19] AccessRestrictionData OPTIONAL, ics-Indicator [20] BOOLEAN OPTIONAL, eps-SubscriptionData [31] EPS-SubscriptionData OPTIONAL, csg-SubscriptionDataList [32] CSG-SubscriptionDataList OPTIONAL, ue-ReachabilityRequestIndicator [33] NULL OPTIONAL, sgsn-Number [34] ISDN-AddressString OPTIONAL, mme-Name [35] DiameterIdentity OPTIONAL, subscribedPeriodicRAUTAUtimer [36] SubscribedPeriodicRAUTAUtimer OPTIONAL, vplmnLIPAAllowed [37] NULL OPTIONAL, mdtUserConsent [38] BOOLEAN OPTIONAL, subscribedPeriodicLAUtimer [39] SubscribedPeriodicLAUtimer OPTIONAL, vplmn-Csg-SubscriptionDataList [40] VPLMN-CSG-SubscriptionDataList OPTIONAL, additionalMSISDN [41] ISDN-AddressString OPTIONAL, psAndSMS-OnlyServiceProvision [42] NULL OPTIONAL, smsInSGSNAllowed [43] NULL OPTIONAL, cs-to-ps-SRVCC-Allowed-Indicator [44] NULL OPTIONAL, pcscf-Restoration-Request [45] NULL OPTIONAL, adjacentAccessRestrictionDataList [46] AdjacentAccessRestrictionDataList OPTIONAL, imsi-Group-Id-List [47] IMSI-GroupIdList OPTIONAL, ueUsageType [48] UE-UsageType OPTIONAL, userPlaneIntegrityProtectionIndicator [49] NULL OPTIONAL, dl-Buffering-Suggested-Packet-Count [50] DL-Buffering-Suggested-Packet-Count OPTIONAL, reset-Id-List [51] Reset-Id-List OPTIONAL, eDRX-Cycle-Length-List [52] EDRX-Cycle-Length-List OPTIONAL, ext-AccessRestrictionData [53] Ext-AccessRestrictionData OPTIONAL, iab-Operation-Allowed-Indicator [54] NULL OPTIONAL } -- If the Network Access Mode parameter is sent, it shall be present only in -- the first sequence if seqmentation is used EDRX-Cycle-Length-List ::= SEQUENCE SIZE (1..8) OF EDRX-Cycle-Length EDRX-Cycle-Length ::= SEQUENCE { rat-Type [0] Used-RAT-Type, eDRX-Cycle-Length-Value [1] EDRX-Cycle-Length-Value, ...} -- The eDRX-Cycle-Length contains the subscribed eDRX-Cycle-Length applicable to a -- a specific RAT Type. EDRX-Cycle-Length-Value ::= OCTET STRING (SIZE (1)) -- The EDRX-Cycle-Length-Value shall be encoded as specified in clause 7.3.216 of -- 3GPPÊTSÊ29.272Ê[144]. Reset-Id-List ::= SEQUENCE SIZE (1..50) OF Reset-Id Reset-Id ::= OCTET STRING (SIZE (1..4)) -- Reset-Ids shall be unique within the HPLMN. DL-Buffering-Suggested-Packet-Count ::= INTEGER (-1..2147483647) -- values are defined in 3GPP TS 29.272 [144] Group-Service-ID ::= INTEGER (0..4294967295) -- values are defined in 3GPP TS 29.272 [144] Local-GroupID ::= OCTET STRING (SIZE (1..10)) -- Refers to Local group ID defined by an operator identified by the PLMN-ID. -- for details see 3GPP TS 29.272 [144] IMSI-GroupIdList ::= SEQUENCE SIZE (1..50) OF IMSI-GroupId IMSI-GroupId ::= SEQUENCE { group-Service-Id [0] Group-Service-ID, plmnId [1] PLMN-Id, local-Group-ID [2] Local-GroupID, ...} SubscribedPeriodicRAUTAUtimer ::= INTEGER (0..4294967295) -- This parameter carries the subscribed periodic TAU/RAU timer value in seconds as -- specified in 3GPP TS 24.008 [35]. SubscribedPeriodicLAUtimer ::= INTEGER (0..4294967295) -- This parameter carries the subscribed periodic LAU timer value in seconds as -- specified in 3GPP TS 24.008 [35]. CSG-SubscriptionDataList ::= SEQUENCE SIZE (1..50) OF CSG-SubscriptionData CSG-SubscriptionData ::= SEQUENCE { csg-Id CSG-Id, expirationDate Time OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., lipa-AllowedAPNList [0] LIPA-AllowedAPNList OPTIONAL, plmn-Id [1] PLMN-Id OPTIONAL } VPLMN-CSG-SubscriptionDataList ::= SEQUENCE SIZE (1..50) OF CSG-SubscriptionData CSG-Id ::= BIT STRING (SIZE (27)) -- coded according to 3GPP TS 23.003 [17]. LIPA-AllowedAPNList ::= SEQUENCE SIZE (1..maxNumOfLIPAAllowedAPN) OF APN maxNumOfLIPAAllowedAPN INTEGER ::= 50 EPS-SubscriptionData ::= SEQUENCE { apn-oi-Replacement [0] APN-OI-Replacement OPTIONAL, -- this apn-oi-Replacement refers to the UE level apn-oi-Replacement. rfsp-id [2] RFSP-ID OPTIONAL, ambr [3] AMBR OPTIONAL, apn-ConfigurationProfile [4] APN-ConfigurationProfile OPTIONAL, stn-sr [6] ISDN-AddressString OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ..., mps-CSPriority [7] NULL OPTIONAL, mps-EPSPriority [8] NULL OPTIONAL, subscribed-vsrvcc [9] NULL OPTIONAL } -- mps-CSPriority by its presence indicates that the UE is subscribed to the eMLPP in -- the CS domain, referring to the 3GPP TS 29.272 [144] for details. -- mps-EPSPriority by its presence indicates that the UE is subscribed to the MPS in -- the EPS domain, referring to the 3GPP TS 29.272 [144] for details. -- -- subscribed-vsrvcc by its presence indicates that the UE is subscribed to the vSRVCC in -- the EPS domain, referring to the 3GPP TS 29.272 [144] for details. APN-OI-Replacement ::= OCTET STRING (SIZE (9..100)) -- Octets are coded as APN Operator Identifier according to TS 3GPP TS 23.003 [17] RFSP-ID ::= INTEGER (1..256) APN-ConfigurationProfile ::= SEQUENCE { defaultContext ContextId, completeDataListIncluded NULL OPTIONAL, -- If segmentation is used, completeDataListIncluded may only be present in the -- first segment of APN-ConfigurationProfile. epsDataList [1] EPS-DataList, extensionContainer [2] ExtensionContainer OPTIONAL, ... , additionalDefaultContext [3] ContextId OPTIONAL -- for details see the 3GPP TS 29.272 [144]. } EPS-DataList ::= SEQUENCE SIZE (1..maxNumOfAPN-Configurations) OF APN-Configuration maxNumOfAPN-Configurations INTEGER ::= 50 APN-Configuration ::= SEQUENCE { contextId [0] ContextId, pdn-Type [1] PDN-Type, servedPartyIP-IPv4-Address [2] PDP-Address OPTIONAL, apn [3] APN, eps-qos-Subscribed [4] EPS-QoS-Subscribed, pdn-gw-Identity [5] PDN-GW-Identity OPTIONAL, pdn-gw-AllocationType [6] PDN-GW-AllocationType OPTIONAL, vplmnAddressAllowed [7] NULL OPTIONAL, chargingCharacteristics [8] ChargingCharacteristics OPTIONAL, ambr [9] AMBR OPTIONAL, specificAPNInfoList [10] SpecificAPNInfoList OPTIONAL, extensionContainer [11] ExtensionContainer OPTIONAL, servedPartyIP-IPv6-Address [12] PDP-Address OPTIONAL, ..., apn-oi-Replacement [13] APN-OI-Replacement OPTIONAL, -- this apn-oi-Replacement refers to the APN level apn-oi-Replacement. sipto-Permission [14] SIPTO-Permission OPTIONAL, lipa-Permission [15] LIPA-Permission OPTIONAL, restoration-Priority [16] Restoration-Priority OPTIONAL, sipto-local-network-Permission [17] SIPTO-Local-Network-Permission OPTIONAL, wlan-offloadability [18] WLAN-Offloadability OPTIONAL, non-IP-PDN-Type-Indicator [19] NULL OPTIONAL, nIDD-Mechanism [20] NIDD-Mechanism OPTIONAL, sCEF-ID [21] FQDN OPTIONAL, pdn-ConnectionContinuity [22] PDN-ConnectionContinuity OPTIONAL -- absence of pdn-ConnectionContinuity indicates that the handling is left to -- local VPLMN policy } PDN-ConnectionContinuity ::= ENUMERATED { maintainPDN-Connection (0), disconnectPDN-ConnectionWithReactivationRequest (1), disconnectPDN-ConnectionWithoutReactivationRequest (2) } NIDD-Mechanism ::= ENUMERATED { sGi-based-data-delivery (0), sCEF-based-data-delivery (1) -- The default value, when this information element is not present, is -- sGi-based-data-delivery (0) } PDN-Type ::= OCTET STRING (SIZE (1)) -- Octet is coded as follows: -- Bits -- 3 2 1 -- 0 0 1 IPv4 -- 0 1 0 IPv6 -- 0 1 1 IPv4v6 -- 1 0 0 IPv4_or_IPv6 -- Bits 8-4 shall be coded as zero. -- for details see 3GPP TS 29.272 [144] EPS-QoS-Subscribed ::= SEQUENCE { qos-Class-Identifier [0] QoS-Class-Identifier, allocation-Retention-Priority [1] Allocation-Retention-Priority, extensionContainer [2] ExtensionContainer OPTIONAL, ... } AMBR ::= SEQUENCE { max-RequestedBandwidth-UL [0] Bandwidth, max-RequestedBandwidth-DL [1] Bandwidth, extensionContainer [2] ExtensionContainer OPTIONAL, ..., extended-Max-RequestedBandwidth-UL [3] BandwidthExt OPTIONAL, extended-Max-RequestedBandwidth-DL [4] BandwidthExt OPTIONAL -- extended-Max-RequestedBandwidth-UL/DL shall be populated according to the -- description of the corresponding parameters in 3GPP TS 29.272 [144] } SpecificAPNInfoList ::= SEQUENCE SIZE (1..maxNumOfSpecificAPNInfos) OF SpecificAPNInfo maxNumOfSpecificAPNInfos INTEGER ::= 50 SpecificAPNInfo ::= SEQUENCE { apn [0] APN, pdn-gw-Identity [1] PDN-GW-Identity, extensionContainer [2] ExtensionContainer OPTIONAL, ... } Bandwidth ::= INTEGER -- bits per second BandwidthExt ::= INTEGER -- kilobits per second QoS-Class-Identifier ::= INTEGER (1..9) -- values are defined in 3GPP TS 29.212 Allocation-Retention-Priority ::= SEQUENCE { priority-level [0] INTEGER, pre-emption-capability [1] BOOLEAN OPTIONAL, pre-emption-vulnerability [2] BOOLEAN OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ... } PDN-GW-Identity ::= SEQUENCE { pdn-gw-ipv4-Address [0] PDP-Address OPTIONAL, pdn-gw-ipv6-Address [1] PDP-Address OPTIONAL, pdn-gw-name [2] FQDN OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ... } FQDN ::= OCTET STRING (SIZE (9..255)) PDN-GW-AllocationType ::= ENUMERATED { static (0), dynamic (1)} WLAN-Offloadability ::= SEQUENCE { wlan-offloadability-EUTRAN [0] WLAN-Offloadability-Indication OPTIONAL, wlan-offloadability-UTRAN [1] WLAN-Offloadability-Indication OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ... } WLAN-Offloadability-Indication ::= ENUMERATED { notAllowed (0), allowed (1)} AccessRestrictionData ::= BIT STRING { utranNotAllowed (0), geranNotAllowed (1), ganNotAllowed (2), i-hspa-evolutionNotAllowed (3), wb-e-utranNotAllowed (4), ho-toNon3GPP-AccessNotAllowed (5), nb-iotNotAllowed (6), enhancedCoverageNotAllowed (7) } (SIZE (2..8)) -- exception handling: -- The VLR shall ignore the access restriction data related to an access type not -- supported by the node. -- The handling of the access restriction data by the SGSN is described in clause -- 5.3.19 of TS 23.060, in clause 7.5.3 of TS 29.060 and clause 7.3.6 of TS 29.274. -- Additional access restrictions are encoded in Ext-AccessRestrictionData bit string. Ext-AccessRestrictionData ::= BIT STRING { nrAsSecondaryRATNotAllowed (0), unlicensedSpectrumAsSecondaryRATNotAllowed (1) } (SIZE (1..32)) AdjacentAccessRestrictionDataList ::= SEQUENCE SIZE (1..50) OF AdjacentAccessRestrictionData AdjacentAccessRestrictionData ::= SEQUENCE { plmnId [0] PLMN-Id, accessRestrictionData [1] AccessRestrictionData, ... , ext-AccessRestrictionData [2] Ext-AccessRestrictionData OPTIONAL } CS-AllocationRetentionPriority ::= OCTET STRING (SIZE (1)) -- This data type encodes each priority level defined in 3GPP TS 23.107 [154] as the --binary value of the priority level. IST-AlertTimerValue ::= INTEGER (15..255) LCSInformation ::= SEQUENCE { gmlc-List [0] GMLC-List OPTIONAL, lcs-PrivacyExceptionList [1] LCS-PrivacyExceptionList OPTIONAL, molr-List [2] MOLR-List OPTIONAL, ..., add-lcs-PrivacyExceptionList [3] LCS-PrivacyExceptionList OPTIONAL } -- add-lcs-PrivacyExceptionList may be sent only if lcs-PrivacyExceptionList is -- present and contains four instances of LCS-PrivacyClass. If the mentioned condition -- is not satisfied the receiving node shall discard add-lcs-PrivacyExceptionList. -- If an LCS-PrivacyClass is received both in lcs-PrivacyExceptionList and in -- add-lcs-PrivacyExceptionList with the same SS-Code, then the error unexpected -- data value shall be returned. GMLC-List ::= SEQUENCE SIZE (1..maxNumOfGMLC) OF ISDN-AddressString -- if segmentation is used, the complete GMLC-List shall be sent in one segment maxNumOfGMLC INTEGER ::= 5 NetworkAccessMode ::= ENUMERATED { packetAndCircuit (0), onlyCircuit (1), onlyPacket (2), ...} -- if unknown values are received in NetworkAccessMode -- they shall be discarded. GPRSDataList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF PDP-Context maxNumOfPDP-Contexts INTEGER ::= 50 PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type [16] PDP-Type, pdp-Address [17] PDP-Address OPTIONAL, qos-Subscribed [18] QoS-Subscribed, vplmnAddressAllowed [19] NULL OPTIONAL, apn [20] APN, extensionContainer [21] ExtensionContainer OPTIONAL, ... , ext-QoS-Subscribed [0] Ext-QoS-Subscribed OPTIONAL, pdp-ChargingCharacteristics [1] ChargingCharacteristics OPTIONAL, ext2-QoS-Subscribed [2] Ext2-QoS-Subscribed OPTIONAL, -- ext2-QoS-Subscribed may be present only if ext-QoS-Subscribed is present. ext3-QoS-Subscribed [3] Ext3-QoS-Subscribed OPTIONAL, -- ext3-QoS-Subscribed may be present only if ext2-QoS-Subscribed is present. ext4-QoS-Subscribed [4] Ext4-QoS-Subscribed OPTIONAL, -- ext4-QoS-Subscribed may be present only if ext3-QoS-Subscribed is present. apn-oi-Replacement [5] APN-OI-Replacement OPTIONAL, -- this apn-oi-Replacement refers to the APN level apn-oi-Replacement and has -- higher priority than UE level apn-oi-Replacement. ext-pdp-Type [6] Ext-PDP-Type OPTIONAL, -- contains the value IPv4v6 defined in 3GPP TS 29.060 [105], if the PDP can be -- accessed by dual-stack UEs ext-pdp-Address [7] PDP-Address OPTIONAL, -- contains an additional IP address in case of dual-stack static IP address assignment -- for the UE. -- it may contain an IPv4 or an IPv6 address/prefix, and it may be present -- only if pdp-Address is present; if both are present, each parameter shall -- contain a different type of address (IPv4 or IPv6). ambr [10] AMBR OPTIONAL, -- this ambr contains the AMBR associated to the APN included in the -- PDP-Context (APN-AMBR). sipto-Permission [8] SIPTO-Permission OPTIONAL, lipa-Permission [9] LIPA-Permission OPTIONAL, restoration-Priority [11] Restoration-Priority OPTIONAL, sipto-local-network-Permission [12] SIPTO-Local-Network-Permission OPTIONAL, nIDD-Mechanism [13] NIDD-Mechanism OPTIONAL, sCEF-ID [14] FQDN OPTIONAL } Restoration-Priority ::= OCTET STRING (SIZE (1)) -- Octet 1: -- Restoration Priority. This octet encodes the Restoration Priority, -- as the binary value of the Restoration-Priority described in 3GPP TS 29.272 [144]. SIPTO-Permission ::= ENUMERATED { siptoAboveRanAllowed (0), siptoAboveRanNotAllowed (1) } SIPTO-Local-Network-Permission ::= ENUMERATED { siptoAtLocalNetworkAllowed (0), siptoAtLocalNetworkNotAllowed (1) } LIPA-Permission ::= ENUMERATED { lipaProhibited (0), lipaOnly (1), lipaConditional (2) } ContextId ::= INTEGER (1..maxNumOfPDP-Contexts) GPRSSubscriptionData ::= SEQUENCE { completeDataListIncluded NULL OPTIONAL, -- If segmentation is used, completeDataListIncluded may only be present in the -- first segment of GPRSSubscriptionData. gprsDataList [1] GPRSDataList, extensionContainer [2] ExtensionContainer OPTIONAL, ..., apn-oi-Replacement [3] APN-OI-Replacement OPTIONAL -- this apn-oi-Replacement refers to the UE level apn-oi-Replacement. } SGSN-CAMEL-SubscriptionInfo ::= SEQUENCE { gprs-CSI [0] GPRS-CSI OPTIONAL, mo-sms-CSI [1] SMS-CSI OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., mt-sms-CSI [3] SMS-CSI OPTIONAL, mt-smsCAMELTDP-CriteriaList [4] MT-smsCAMELTDP-CriteriaList OPTIONAL, mg-csi [5] MG-CSI OPTIONAL } GPRS-CSI ::= SEQUENCE { gprs-CamelTDPDataList [0] GPRS-CamelTDPDataList OPTIONAL, camelCapabilityHandling [1] CamelCapabilityHandling OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, notificationToCSE [3] NULL OPTIONAL, csi-Active [4] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present when GPRS-CSI is sent to SGSN. -- They may only be included in ATSI/ATM ack/NSDC message. -- GPRS-CamelTDPData and camelCapabilityHandling shall be present in -- the GPRS-CSI sequence. -- If GPRS-CSI is segmented, gprs-CamelTDPDataList and camelCapabilityHandling shall be -- present in the first segment GPRS-CamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF GPRS-CamelTDPData -- GPRS-CamelTDPDataList shall not contain more than one instance of -- GPRS-CamelTDPData containing the same value for gprs-TriggerDetectionPoint. GPRS-CamelTDPData ::= SEQUENCE { gprs-TriggerDetectionPoint [0] GPRS-TriggerDetectionPoint, serviceKey [1] ServiceKey, gsmSCF-Address [2] ISDN-AddressString, defaultSessionHandling [3] DefaultGPRS-Handling, extensionContainer [4] ExtensionContainer OPTIONAL, ... } DefaultGPRS-Handling ::= ENUMERATED { continueTransaction (0) , releaseTransaction (1) , ...} -- exception handling: -- reception of values in range 2-31 shall be treated as ""continueTransaction"" -- reception of values greater than 31 shall be treated as ""releaseTransaction"" GPRS-TriggerDetectionPoint ::= ENUMERATED { attach (1), attachChangeOfPosition (2), pdp-ContextEstablishment (11), pdp-ContextEstablishmentAcknowledgement (12), pdp-ContextChangeOfPosition (14), ... } -- exception handling: -- For GPRS-CamelTDPData sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- GPRS-CamelTDPDatasequence. APN ::= OCTET STRING (SIZE (2..63)) -- Octets are coded according to TS 3GPP TS 23.003 [17] PDP-Type ::= OCTET STRING (SIZE (2)) -- Octets are coded according to TS 3GPP TS 29.060 [105] -- Only the values PPP, IPv4, IPv6 and Non-IP are allowed for this parameter. Ext-PDP-Type ::= OCTET STRING (SIZE (2)) -- Octets are coded, similarly to PDP-Type, according to TS 3GPP TS 29.060 [105]. -- Only the value IPv4v6 is allowed for this parameter. PDP-Address ::= OCTET STRING (SIZE (1..16)) -- Octets are coded according to TS 3GPP TS 29.060 [105] -- The possible size values are: -- 1-7 octets X.25 address type -- 4 octets IPv4 address type -- 16 octets Ipv6 address type QoS-Subscribed ::= OCTET STRING (SIZE (3)) -- Octets are coded according to TS 3GPP TS 24.008 [35] Quality of Service Octets -- 3-5. Ext-QoS-Subscribed ::= OCTET STRING (SIZE (1..9)) -- OCTET 1: -- Allocation/Retention Priority (This octet encodes each priority level defined in -- 3GPP TS 23.107 [154] as the binary value of the priority level, declaration in -- 3GPP TS 29.060 [105]) -- Octets 2-9 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets -- 6-13. Ext2-QoS-Subscribed ::= OCTET STRING (SIZE (1..3)) -- Octets 1-3 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets 14-16. -- If Quality of Service information is structured with 14 octet length, then -- Octet 1 is coded according to 3GPP TS 24.008 [35] Quality of Service Octet 14. Ext3-QoS-Subscribed ::= OCTET STRING (SIZE (1..2)) -- Octets 1-2 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets 17-18. Ext4-QoS-Subscribed ::= OCTET STRING (SIZE (1)) -- Octet 1: -- Evolved Allocation/Retention Priority. This octet encodes the Priority Level (PL), -- the Preemption Capability (PCI) and Preemption Vulnerability (PVI) values, as -- described in 3GPP TS 29.060 [105]. ChargingCharacteristics ::= OCTET STRING (SIZE (2)) -- Octets are coded according to 3GPP TS 32.215. LSAOnlyAccessIndicator ::= ENUMERATED { accessOutsideLSAsAllowed (0), accessOutsideLSAsRestricted (1)} LSADataList ::= SEQUENCE SIZE (1..maxNumOfLSAs) OF LSAData maxNumOfLSAs INTEGER ::= 20 LSAData ::= SEQUENCE { lsaIdentity [0] LSAIdentity, lsaAttributes [1] LSAAttributes, lsaActiveModeIndicator [2] NULL OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} LSAInformation ::= SEQUENCE { completeDataListIncluded NULL OPTIONAL, -- If segmentation is used, completeDataListIncluded may only be present in the -- first segment. lsaOnlyAccessIndicator [1] LSAOnlyAccessIndicator OPTIONAL, lsaDataList [2] LSADataList OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} LSAIdentity ::= OCTET STRING (SIZE (3)) -- Octets are coded according to TS 3GPP TS 23.003 [17] LSAAttributes ::= OCTET STRING (SIZE (1)) -- Octets are coded according to TS 3GPP TS 48.008 [49] SubscriberData ::= SEQUENCE { msisdn [1] ISDN-AddressString OPTIONAL, category [2] Category OPTIONAL, subscriberStatus [3] SubscriberStatus OPTIONAL, bearerServiceList [4] BearerServiceList OPTIONAL, -- The exception handling for reception of unsupported / not allocated -- bearerServiceCodes is defined in clause 8.8.1 teleserviceList [6] TeleserviceList OPTIONAL, -- The exception handling for reception of unsupported / not allocated -- teleserviceCodes is defined in clause 8.8.1 provisionedSS [7] Ext-SS-InfoList OPTIONAL, odb-Data [8] ODB-Data OPTIONAL, roamingRestrictionDueToUnsupportedFeature [9] NULL OPTIONAL, regionalSubscriptionData [10] ZoneCodeList OPTIONAL, vbsSubscriptionData [11] VBSDataList OPTIONAL, vgcsSubscriptionData [12] VGCSDataList OPTIONAL, vlrCamelSubscriptionInfo [13] VlrCamelSubscriptionInfo OPTIONAL } Category ::= OCTET STRING (SIZE (1)) -- The internal structure is defined in ITU-T Rec Q.763. SubscriberStatus ::= ENUMERATED { serviceGranted (0), operatorDeterminedBarring (1)} BearerServiceList ::= SEQUENCE SIZE (1..maxNumOfBearerServices) OF Ext-BearerServiceCode maxNumOfBearerServices INTEGER ::= 50 TeleserviceList ::= SEQUENCE SIZE (1..maxNumOfTeleservices) OF Ext-TeleserviceCode maxNumOfTeleservices INTEGER ::= 20 ODB-Data ::= SEQUENCE { odb-GeneralData ODB-GeneralData, odb-HPLMN-Data ODB-HPLMN-Data OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} ODB-GeneralData ::= BIT STRING { allOG-CallsBarred (0), internationalOGCallsBarred (1), internationalOGCallsNotToHPLMN-CountryBarred (2), interzonalOGCallsBarred (6), interzonalOGCallsNotToHPLMN-CountryBarred (7), interzonalOGCallsAndInternationalOGCallsNotToHPLMN-CountryBarred (8), premiumRateInformationOGCallsBarred (3), premiumRateEntertainementOGCallsBarred (4), ss-AccessBarred (5), allECT-Barred (9), chargeableECT-Barred (10), internationalECT-Barred (11), interzonalECT-Barred (12), doublyChargeableECT-Barred (13), multipleECT-Barred (14), allPacketOrientedServicesBarred (15), roamerAccessToHPLMN-AP-Barred (16), roamerAccessToVPLMN-AP-Barred (17), roamingOutsidePLMNOG-CallsBarred (18), allIC-CallsBarred (19), roamingOutsidePLMNIC-CallsBarred (20), roamingOutsidePLMNICountryIC-CallsBarred (21), roamingOutsidePLMN-Barred (22), roamingOutsidePLMN-CountryBarred (23), registrationAllCF-Barred (24), registrationCFNotToHPLMN-Barred (25), registrationInterzonalCF-Barred (26), registrationInterzonalCFNotToHPLMN-Barred (27), registrationInternationalCF-Barred (28)} (SIZE (15..32)) -- exception handling: reception of unknown bit assignments in the -- ODB-GeneralData type shall be treated like unsupported ODB-GeneralData -- When the ODB-GeneralData type is removed from the HLR for a given subscriber, -- in NoteSubscriberDataModified operation sent toward the gsmSCF -- all bits shall be set to ""O"". ODB-HPLMN-Data ::= BIT STRING { plmn-SpecificBarringType1 (0), plmn-SpecificBarringType2 (1), plmn-SpecificBarringType3 (2), plmn-SpecificBarringType4 (3)} (SIZE (4..32)) -- exception handling: reception of unknown bit assignments in the -- ODB-HPLMN-Data type shall be treated like unsupported ODB-HPLMN-Data -- When the ODB-HPLMN-Data type is removed from the HLR for a given subscriber, -- in NoteSubscriberDataModified operation sent toward the gsmSCF -- all bits shall be set to ""O"". Ext-SS-InfoList ::= SEQUENCE SIZE (1..maxNumOfSS) OF Ext-SS-Info Ext-SS-Info ::= CHOICE { forwardingInfo [0] Ext-ForwInfo, callBarringInfo [1] Ext-CallBarInfo, cug-Info [2] CUG-Info, ss-Data [3] Ext-SS-Data, emlpp-Info [4] EMLPP-Info} Ext-ForwInfo ::= SEQUENCE { ss-Code SS-Code, forwardingFeatureList Ext-ForwFeatureList, extensionContainer [0] ExtensionContainer OPTIONAL, ...} Ext-ForwFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF Ext-ForwFeature Ext-ForwFeature ::= SEQUENCE { basicService Ext-BasicServiceCode OPTIONAL, ss-Status [4] Ext-SS-Status, forwardedToNumber [5] ISDN-AddressString OPTIONAL, -- When this data type is sent from an HLR which supports CAMEL Phase 2 -- to a VLR that supports CAMEL Phase 2 the VLR shall not check the -- format of the number forwardedToSubaddress [8] ISDN-SubaddressString OPTIONAL, forwardingOptions [6] Ext-ForwOptions OPTIONAL, noReplyConditionTime [7] Ext-NoRepCondTime OPTIONAL, extensionContainer [9] ExtensionContainer OPTIONAL, ..., longForwardedToNumber [10] FTN-AddressString OPTIONAL } Ext-ForwOptions ::= OCTET STRING (SIZE (1..5)) -- OCTET 1: -- bit 8: notification to forwarding party -- 0 no notification -- 1 notification -- bit 7: redirecting presentation -- 0 no presentation -- 1 presentation -- bit 6: notification to calling party -- 0 no notification -- 1 notification -- bit 5: 0 (unused) -- bits 43: forwarding reason -- 00 ms not reachable -- 01 ms busy -- 10 no reply -- 11 unconditional -- bits 21: 00 (unused) -- OCTETS 2-5: reserved for future use. They shall be discarded if -- received and not understood. Ext-NoRepCondTime ::= INTEGER (1..100) -- Only values 5-30 are used. -- Values in the ranges 1-4 and 31-100 are reserved for future use -- If received: -- values 1-4 shall be mapped on to value 5 -- values 31-100 shall be mapped on to value 30 Ext-CallBarInfo ::= SEQUENCE { ss-Code SS-Code, callBarringFeatureList Ext-CallBarFeatureList, extensionContainer ExtensionContainer OPTIONAL, ...} Ext-CallBarFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF Ext-CallBarringFeature Ext-CallBarringFeature ::= SEQUENCE { basicService Ext-BasicServiceCode OPTIONAL, ss-Status [4] Ext-SS-Status, extensionContainer ExtensionContainer OPTIONAL, ...} CUG-Info ::= SEQUENCE { cug-SubscriptionList CUG-SubscriptionList, cug-FeatureList CUG-FeatureList OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ...} CUG-SubscriptionList ::= SEQUENCE SIZE (0..maxNumOfCUG) OF CUG-Subscription CUG-Subscription ::= SEQUENCE { cug-Index CUG-Index, cug-Interlock CUG-Interlock, intraCUG-Options IntraCUG-Options, basicServiceGroupList Ext-BasicServiceGroupList OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ...} CUG-Index ::= INTEGER (0..32767) -- The internal structure is defined in ETS 300 138. CUG-Interlock ::= OCTET STRING (SIZE (4)) IntraCUG-Options ::= ENUMERATED { noCUG-Restrictions (0), cugIC-CallBarred (1), cugOG-CallBarred (2)} maxNumOfCUG INTEGER ::= 10 CUG-FeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF CUG-Feature Ext-BasicServiceGroupList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF Ext-BasicServiceCode maxNumOfExt-BasicServiceGroups INTEGER ::= 32 CUG-Feature ::= SEQUENCE { basicService Ext-BasicServiceCode OPTIONAL, preferentialCUG-Indicator CUG-Index OPTIONAL, interCUG-Restrictions InterCUG-Restrictions, extensionContainer ExtensionContainer OPTIONAL, ...} InterCUG-Restrictions ::= OCTET STRING (SIZE (1)) -- bits 876543: 000000 (unused) -- Exception handling: -- bits 876543 shall be ignored if received and not understood -- bits 21 -- 00 CUG only facilities -- 01 CUG with outgoing access -- 10 CUG with incoming access -- 11 CUG with both outgoing and incoming access Ext-SS-Data ::= SEQUENCE { ss-Code SS-Code, ss-Status [4] Ext-SS-Status, ss-SubscriptionOption SS-SubscriptionOption OPTIONAL, basicServiceGroupList Ext-BasicServiceGroupList OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ...} LCS-PrivacyExceptionList ::= SEQUENCE SIZE (1..maxNumOfPrivacyClass) OF LCS-PrivacyClass maxNumOfPrivacyClass INTEGER ::= 4 LCS-PrivacyClass ::= SEQUENCE { ss-Code SS-Code, ss-Status Ext-SS-Status, notificationToMSUser [0] NotificationToMSUser OPTIONAL, -- notificationToMSUser may be sent only for SS-codes callSessionRelated -- and callSessionUnrelated. If not received for SS-codes callSessionRelated -- and callSessionUnrelated, -- the default values according to 3GPP TS 23.271 shall be assumed. externalClientList [1] ExternalClientList OPTIONAL, -- externalClientList may be sent only for SS-code callSessionUnrelated to a -- visited node that does not support LCS Release 4 or later versions. -- externalClientList may be sent only for SS-codes callSessionUnrelated and -- callSessionRelated to a visited node that supports LCS Release 4 or later versions. plmnClientList [2] PLMNClientList OPTIONAL, -- plmnClientList may be sent only for SS-code plmnoperator. extensionContainer [3] ExtensionContainer OPTIONAL, ..., ext-externalClientList [4] Ext-ExternalClientList OPTIONAL, -- Ext-externalClientList may be sent only if the visited node supports LCS Release 4 or -- later versions, the user did specify more than 5 clients, and White Book SCCP is used. serviceTypeList [5] ServiceTypeList OPTIONAL -- serviceTypeList may be sent only for SS-code serviceType and if the visited node -- supports LCS Release 5 or later versions. -- -- if segmentation is used, the complete LCS-PrivacyClass shall be sent in one segment } ExternalClientList ::= SEQUENCE SIZE (0..maxNumOfExternalClient) OF ExternalClient maxNumOfExternalClient INTEGER ::= 5 PLMNClientList ::= SEQUENCE SIZE (1..maxNumOfPLMNClient) OF LCSClientInternalID maxNumOfPLMNClient INTEGER ::= 5 Ext-ExternalClientList ::= SEQUENCE SIZE (1..maxNumOfExt-ExternalClient) OF ExternalClient maxNumOfExt-ExternalClient INTEGER ::= 35 ExternalClient ::= SEQUENCE { clientIdentity LCSClientExternalID, gmlc-Restriction [0] GMLC-Restriction OPTIONAL, notificationToMSUser [1] NotificationToMSUser OPTIONAL, -- If notificationToMSUser is not received, the default value according to -- 3GPP TS 23.271 shall be assumed. extensionContainer [2] ExtensionContainer OPTIONAL, ... } GMLC-Restriction ::= ENUMERATED { gmlc-List (0), home-Country (1) , ... } -- exception handling: -- At reception of any other value than the ones listed the receiver shall ignore -- GMLC-Restriction. NotificationToMSUser ::= ENUMERATED { notifyLocationAllowed (0), notifyAndVerify-LocationAllowedIfNoResponse (1), notifyAndVerify-LocationNotAllowedIfNoResponse (2), ..., locationNotAllowed (3) } -- exception handling: -- At reception of any other value than the ones listed the receiver shall ignore -- NotificationToMSUser. ServiceTypeList ::= SEQUENCE SIZE (1..maxNumOfServiceType) OF ServiceType maxNumOfServiceType INTEGER ::= 32 ServiceType ::= SEQUENCE { serviceTypeIdentity LCSServiceTypeID, gmlc-Restriction [0] GMLC-Restriction OPTIONAL, notificationToMSUser [1] NotificationToMSUser OPTIONAL, -- If notificationToMSUser is not received, the default value according to -- 3GPP TS 23.271 shall be assumed. extensionContainer [2] ExtensionContainer OPTIONAL, ... } MOLR-List ::= SEQUENCE SIZE (1..maxNumOfMOLR-Class) OF MOLR-Class maxNumOfMOLR-Class INTEGER ::= 3 MOLR-Class ::= SEQUENCE { ss-Code SS-Code, ss-Status Ext-SS-Status, extensionContainer [0] ExtensionContainer OPTIONAL, ...} ZoneCodeList ::= SEQUENCE SIZE (1..maxNumOfZoneCodes) OF ZoneCode ZoneCode ::= OCTET STRING (SIZE (2)) -- internal structure is defined in TS 3GPP TS 23.003 [17] maxNumOfZoneCodes INTEGER ::= 10 InsertSubscriberDataRes ::= SEQUENCE { teleserviceList [1] TeleserviceList OPTIONAL, bearerServiceList [2] BearerServiceList OPTIONAL, ss-List [3] SS-List OPTIONAL, odb-GeneralData [4] ODB-GeneralData OPTIONAL, regionalSubscriptionResponse [5] RegionalSubscriptionResponse OPTIONAL, supportedCamelPhases [6] SupportedCamelPhases OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ... , offeredCamel4CSIs [8] OfferedCamel4CSIs OPTIONAL, supportedFeatures [9] SupportedFeatures OPTIONAL, ext-SupportedFeatures [10] Ext-SupportedFeatures OPTIONAL } RegionalSubscriptionResponse ::= ENUMERATED { networkNode-AreaRestricted (0), tooManyZoneCodes (1), zoneCodesConflict (2), regionalSubscNotSupported (3)} DeleteSubscriberDataArg ::= SEQUENCE { imsi [0] IMSI, basicServiceList [1] BasicServiceList OPTIONAL, -- The exception handling for reception of unsupported/not allocated -- basicServiceCodes is defined in clause 6.8.2 ss-List [2] SS-List OPTIONAL, roamingRestrictionDueToUnsupportedFeature [4] NULL OPTIONAL, regionalSubscriptionIdentifier [5] ZoneCode OPTIONAL, vbsGroupIndication [7] NULL OPTIONAL, vgcsGroupIndication [8] NULL OPTIONAL, camelSubscriptionInfoWithdraw [9] NULL OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ..., gprsSubscriptionDataWithdraw [10] GPRSSubscriptionDataWithdraw OPTIONAL, roamingRestrictedInSgsnDueToUnsuppportedFeature [11] NULL OPTIONAL, lsaInformationWithdraw [12] LSAInformationWithdraw OPTIONAL, gmlc-ListWithdraw [13] NULL OPTIONAL, istInformationWithdraw [14] NULL OPTIONAL, specificCSI-Withdraw [15] SpecificCSI-Withdraw OPTIONAL, chargingCharacteristicsWithdraw [16] NULL OPTIONAL, stn-srWithdraw [17] NULL OPTIONAL, epsSubscriptionDataWithdraw [18] EPS-SubscriptionDataWithdraw OPTIONAL, apn-oi-replacementWithdraw [19] NULL OPTIONAL, csg-SubscriptionDeleted [20] NULL OPTIONAL, subscribedPeriodicTAU-RAU-TimerWithdraw [22] NULL OPTIONAL, subscribedPeriodicLAU-TimerWithdraw [23] NULL OPTIONAL, subscribed-vsrvccWithdraw [21] NULL OPTIONAL, vplmn-Csg-SubscriptionDeleted [24] NULL OPTIONAL, additionalMSISDN-Withdraw [25] NULL OPTIONAL, cs-to-ps-SRVCC-Withdraw [26] NULL OPTIONAL, imsiGroupIdList-Withdraw [27] NULL OPTIONAL, userPlaneIntegrityProtectionWithdraw [28] NULL OPTIONAL, dl-Buffering-Suggested-Packet-Count-Withdraw [29] NULL OPTIONAL, ue-UsageTypeWithdraw [30] NULL OPTIONAL, reset-idsWithdraw [31] NULL OPTIONAL, iab-OperationWithdraw [32] NULL OPTIONAL } SpecificCSI-Withdraw ::= BIT STRING { o-csi (0), ss-csi (1), tif-csi (2), d-csi (3), vt-csi (4), mo-sms-csi (5), m-csi (6), gprs-csi (7), t-csi (8), mt-sms-csi (9), mg-csi (10), o-IM-CSI (11), d-IM-CSI (12), vt-IM-CSI (13) } (SIZE(8..32)) -- exception handling: -- bits 11 to 31 shall be ignored if received by a non-IP Multimedia Core Network entity. -- bits 0-10 and 14-31 shall be ignored if received by an IP Multimedia Core Network entity. -- bits 11-13 are only applicable in an IP Multimedia Core Network. -- Bit 8 and bits 11-13 are only applicable for the NoteSubscriberDataModified operation. GPRSSubscriptionDataWithdraw ::= CHOICE { allGPRSData NULL, contextIdList ContextIdList} EPS-SubscriptionDataWithdraw ::= CHOICE { allEPS-Data NULL, contextIdList ContextIdList} ContextIdList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF ContextId LSAInformationWithdraw ::= CHOICE { allLSAData NULL, lsaIdentityList LSAIdentityList } LSAIdentityList ::= SEQUENCE SIZE (1..maxNumOfLSAs) OF LSAIdentity BasicServiceList ::= SEQUENCE SIZE (1..maxNumOfBasicServices) OF Ext-BasicServiceCode maxNumOfBasicServices INTEGER ::= 70 DeleteSubscriberDataRes ::= SEQUENCE { regionalSubscriptionResponse [0] RegionalSubscriptionResponse OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} VlrCamelSubscriptionInfo ::= SEQUENCE { o-CSI [0] O-CSI OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ..., ss-CSI [2] SS-CSI OPTIONAL, o-BcsmCamelTDP-CriteriaList [4] O-BcsmCamelTDPCriteriaList OPTIONAL, tif-CSI [3] NULL OPTIONAL, m-CSI [5] M-CSI OPTIONAL, mo-sms-CSI [6] SMS-CSI OPTIONAL, vt-CSI [7] T-CSI OPTIONAL, t-BCSM-CAMEL-TDP-CriteriaList [8] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL, d-CSI [9] D-CSI OPTIONAL, mt-sms-CSI [10] SMS-CSI OPTIONAL, mt-smsCAMELTDP-CriteriaList [11] MT-smsCAMELTDP-CriteriaList OPTIONAL } MT-smsCAMELTDP-CriteriaList ::= SEQUENCE SIZE (1.. maxNumOfCamelTDPData) OF MT-smsCAMELTDP-Criteria MT-smsCAMELTDP-Criteria ::= SEQUENCE { sms-TriggerDetectionPoint SMS-TriggerDetectionPoint, tpdu-TypeCriterion [0] TPDU-TypeCriterion OPTIONAL, ... } TPDU-TypeCriterion ::= SEQUENCE SIZE (1..maxNumOfTPDUTypes) OF MT-SMS-TPDU-Type maxNumOfTPDUTypes INTEGER ::= 5 MT-SMS-TPDU-Type ::= ENUMERATED { sms-DELIVER (0), sms-SUBMIT-REPORT (1), sms-STATUS-REPORT (2), ... } -- exception handling: -- For TPDU-TypeCriterion sequences containing this parameter with any -- other value than the ones listed above the receiver shall ignore -- the whole TPDU-TypeCriterion sequence. -- In CAMEL phase 4, sms-SUBMIT-REPORT shall not be used and a received TPDU-TypeCriterion -- sequence containing sms-SUBMIT-REPORT shall be wholly ignored. D-CSI ::= SEQUENCE { dp-AnalysedInfoCriteriaList [0] DP-AnalysedInfoCriteriaList OPTIONAL, camelCapabilityHandling [1] CamelCapabilityHandling OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, notificationToCSE [3] NULL OPTIONAL, csi-Active [4] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present when D-CSI is sent to VLR/GMSC. -- They may only be included in ATSI/ATM ack/NSDC message. -- DP-AnalysedInfoCriteria and camelCapabilityHandling shall be present in -- the D-CSI sequence. -- If D-CSI is segmented, then the first segment shall contain dp-AnalysedInfoCriteriaList -- and camelCapabilityHandling. Subsequent segments shall not contain -- camelCapabilityHandling, but may contain dp-AnalysedInfoCriteriaList. DP-AnalysedInfoCriteriaList ::= SEQUENCE SIZE (1..maxNumOfDP-AnalysedInfoCriteria) OF DP-AnalysedInfoCriterium maxNumOfDP-AnalysedInfoCriteria INTEGER ::= 10 DP-AnalysedInfoCriterium ::= SEQUENCE { dialledNumber ISDN-AddressString, serviceKey ServiceKey, gsmSCF-Address ISDN-AddressString, defaultCallHandling DefaultCallHandling, extensionContainer ExtensionContainer OPTIONAL, ...} SS-CSI ::= SEQUENCE { ss-CamelData SS-CamelData, extensionContainer ExtensionContainer OPTIONAL, ..., notificationToCSE [0] NULL OPTIONAL, csi-Active [1] NULL OPTIONAL -- notificationToCSE and csi-Active shall not be present when SS-CSI is sent to VLR. -- They may only be included in ATSI/ATM ack/NSDC message. } SS-CamelData ::= SEQUENCE { ss-EventList SS-EventList, gsmSCF-Address ISDN-AddressString, extensionContainer [0] ExtensionContainer OPTIONAL, ...} SS-EventList ::= SEQUENCE SIZE (1..maxNumOfCamelSSEvents) OF SS-Code -- Actions for the following SS-Code values are defined in CAMEL Phase 3: -- ect SS-Code ::= '00110001'B -- multiPTY SS-Code ::= '01010001'B -- cd SS-Code ::= '00100100'B -- ccbs SS-Code ::= '01000100'B -- all other SS codes shall be ignored -- When SS-CSI is sent to the VLR, it shall not contain a marking for ccbs. -- If the VLR receives SS-CSI containing a marking for ccbs, the VLR shall discard the -- ccbs marking in SS-CSI. maxNumOfCamelSSEvents INTEGER ::= 10 O-CSI ::= SEQUENCE { o-BcsmCamelTDPDataList O-BcsmCamelTDPDataList, extensionContainer ExtensionContainer OPTIONAL, ..., camelCapabilityHandling [0] CamelCapabilityHandling OPTIONAL, notificationToCSE [1] NULL OPTIONAL, csiActive [2] NULL OPTIONAL} -- notificationtoCSE and csiActive shall not be present when O-CSI is sent to VLR/GMSC. -- They may only be included in ATSI/ATM ack/NSDC message. -- O-CSI shall not be segmented. O-BcsmCamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF O-BcsmCamelTDPData -- O-BcsmCamelTDPDataList shall not contain more than one instance of -- O-BcsmCamelTDPData containing the same value for o-BcsmTriggerDetectionPoint. -- For CAMEL Phase 2, this means that only one instance of O-BcsmCamelTDPData is allowed -- with o-BcsmTriggerDetectionPoint being equal to DP2. maxNumOfCamelTDPData INTEGER ::= 10 O-BcsmCamelTDPData ::= SEQUENCE { o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint, serviceKey ServiceKey, gsmSCF-Address [0] ISDN-AddressString, defaultCallHandling [1] DefaultCallHandling, extensionContainer [2] ExtensionContainer OPTIONAL, ... } ServiceKey ::= INTEGER (0..2147483647) O-BcsmTriggerDetectionPoint ::= ENUMERATED { collectedInfo (2), ..., routeSelectFailure (4) } -- exception handling: -- For O-BcsmCamelTDPData sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- O-BcsmCamelTDPDatasequence. -- For O-BcsmCamelTDP-Criteria sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- O-BcsmCamelTDP-Criteria sequence. O-BcsmCamelTDPCriteriaList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF O-BcsmCamelTDP-Criteria T-BCSM-CAMEL-TDP-CriteriaList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF T-BCSM-CAMEL-TDP-Criteria O-BcsmCamelTDP-Criteria ::= SEQUENCE { o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint, destinationNumberCriteria [0] DestinationNumberCriteria OPTIONAL, basicServiceCriteria [1] BasicServiceCriteria OPTIONAL, callTypeCriteria [2] CallTypeCriteria OPTIONAL, ..., o-CauseValueCriteria [3] O-CauseValueCriteria OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL } T-BCSM-CAMEL-TDP-Criteria ::= SEQUENCE { t-BCSM-TriggerDetectionPoint T-BcsmTriggerDetectionPoint, basicServiceCriteria [0] BasicServiceCriteria OPTIONAL, t-CauseValueCriteria [1] T-CauseValueCriteria OPTIONAL, ... } DestinationNumberCriteria ::= SEQUENCE { matchType [0] MatchType, destinationNumberList [1] DestinationNumberList OPTIONAL, destinationNumberLengthList [2] DestinationNumberLengthList OPTIONAL, -- one or both of destinationNumberList and destinationNumberLengthList -- shall be present ...} DestinationNumberList ::= SEQUENCE SIZE (1..maxNumOfCamelDestinationNumbers) OF ISDN-AddressString -- The receiving entity shall not check the format of a number in -- the dialled number list DestinationNumberLengthList ::= SEQUENCE SIZE (1..maxNumOfCamelDestinationNumberLengths) OF INTEGER(1..maxNumOfISDN-AddressDigits) BasicServiceCriteria ::= SEQUENCE SIZE(1..maxNumOfCamelBasicServiceCriteria) OF Ext-BasicServiceCode maxNumOfISDN-AddressDigits INTEGER ::= 15 maxNumOfCamelDestinationNumbers INTEGER ::= 10 maxNumOfCamelDestinationNumberLengths INTEGER ::= 3 maxNumOfCamelBasicServiceCriteria INTEGER ::= 5 CallTypeCriteria ::= ENUMERATED { forwarded (0), notForwarded (1)} MatchType ::= ENUMERATED { inhibiting (0), enabling (1)} O-CauseValueCriteria ::= SEQUENCE SIZE(1..maxNumOfCAMEL-O-CauseValueCriteria) OF CauseValue T-CauseValueCriteria ::= SEQUENCE SIZE(1..maxNumOfCAMEL-T-CauseValueCriteria) OF CauseValue maxNumOfCAMEL-O-CauseValueCriteria INTEGER ::= 5 maxNumOfCAMEL-T-CauseValueCriteria INTEGER ::= 5 CauseValue ::= OCTET STRING (SIZE(1)) -- Type extracted from Cause parameter in ITU-T Recommendation Q.763. -- For the use of cause value refer to ITU-T Recommendation Q.850. DefaultCallHandling ::= ENUMERATED { continueCall (0) , releaseCall (1) , ...} -- exception handling: -- reception of values in range 2-31 shall be treated as ""continueCall"" -- reception of values greater than 31 shall be treated as ""releaseCall"" CamelCapabilityHandling ::= INTEGER(1..16) -- value 1 = CAMEL phase 1, -- value 2 = CAMEL phase 2, -- value 3 = CAMEL Phase 3, -- value 4 = CAMEL phase 4: -- reception of values greater than 4 shall be treated as CAMEL phase 4. SupportedCamelPhases ::= BIT STRING { phase1 (0), phase2 (1), phase3 (2), phase4 (3)} (SIZE (1..16)) -- A node shall mark in the BIT STRING all CAMEL Phases it supports. -- Other values than listed above shall be discarded. OfferedCamel4CSIs ::= BIT STRING { o-csi (0), d-csi (1), vt-csi (2), t-csi (3), mt-sms-csi (4), mg-csi (5), psi-enhancements (6) } (SIZE (7..16)) -- A node supporting Camel phase 4 shall mark in the BIT STRING all Camel4 CSIs -- it offers. -- Other values than listed above shall be discarded. OfferedCamel4Functionalities ::= BIT STRING { initiateCallAttempt (0), splitLeg (1), moveLeg (2), disconnectLeg (3), entityReleased (4), dfc-WithArgument (5), playTone (6), dtmf-MidCall (7), chargingIndicator (8), alertingDP (9), locationAtAlerting (10), changeOfPositionDP (11), or-Interactions (12), warningToneEnhancements (13), cf-Enhancements (14), subscribedEnhancedDialledServices (15), servingNetworkEnhancedDialledServices (16), criteriaForChangeOfPositionDP (17), serviceChangeDP (18), collectInformation (19) } (SIZE (15..64)) -- A node supporting Camel phase 4 shall mark in the BIT STRING all CAMEL4 -- functionalities it offers. -- Other values than listed above shall be discarded. SMS-CSI ::= SEQUENCE { sms-CAMEL-TDP-DataList [0] SMS-CAMEL-TDP-DataList OPTIONAL, camelCapabilityHandling [1] CamelCapabilityHandling OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, notificationToCSE [3] NULL OPTIONAL, csi-Active [4] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present -- when MO-SMS-CSI or MT-SMS-CSI is sent to VLR or SGSN. -- They may only be included in ATSI/ATM ack/NSDC message."
"-- SMS-CAMEL-TDP-Data and camelCapabilityHandling shall be present in -- the SMS-CSI sequence. -- If SMS-CSI is segmented, sms-CAMEL-TDP-DataList and camelCapabilityHandling shall be -- present in the first segment SMS-CAMEL-TDP-DataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF SMS-CAMEL-TDP-Data -- SMS-CAMEL-TDP-DataList shall not contain more than one instance of -- SMS-CAMEL-TDP-Data containing the same value for sms-TriggerDetectionPoint. SMS-CAMEL-TDP-Data ::= SEQUENCE { sms-TriggerDetectionPoint [0] SMS-TriggerDetectionPoint, serviceKey [1] ServiceKey, gsmSCF-Address [2] ISDN-AddressString, defaultSMS-Handling [3] DefaultSMS-Handling, extensionContainer [4] ExtensionContainer OPTIONAL, ... } SMS-TriggerDetectionPoint ::= ENUMERATED { sms-CollectedInfo (1), ..., sms-DeliveryRequest (2) } -- exception handling: -- For SMS-CAMEL-TDP-Data and MT-smsCAMELTDP-Criteria sequences containing this -- parameter with any other value than the ones listed the receiver shall ignore -- the whole sequence. -- -- If this parameter is received with any other value than sms-CollectedInfo -- in an SMS-CAMEL-TDP-Data sequence contained in mo-sms-CSI, then the receiver shall -- ignore the whole SMS-CAMEL-TDP-Data sequence. -- -- If this parameter is received with any other value than sms-DeliveryRequest -- in an SMS-CAMEL-TDP-Data sequence contained in mt-sms-CSI then the receiver shall -- ignore the whole SMS-CAMEL-TDP-Data sequence. -- -- If this parameter is received with any other value than sms-DeliveryRequest -- in an MT-smsCAMELTDP-Criteria sequence then the receiver shall -- ignore the whole MT-smsCAMELTDP-Criteria sequence. DefaultSMS-Handling ::= ENUMERATED { continueTransaction (0) , releaseTransaction (1) , ...} -- exception handling: -- reception of values in range 2-31 shall be treated as ""continueTransaction"" -- reception of values greater than 31 shall be treated as ""releaseTransaction"" M-CSI ::= SEQUENCE { mobilityTriggers MobilityTriggers, serviceKey ServiceKey, gsmSCF-Address [0] ISDN-AddressString, extensionContainer [1] ExtensionContainer OPTIONAL, notificationToCSE [2] NULL OPTIONAL, csi-Active [3] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present when M-CSI is sent to VLR. -- They may only be included in ATSI/ATM ack/NSDC message. MG-CSI ::= SEQUENCE { mobilityTriggers MobilityTriggers, serviceKey ServiceKey, gsmSCF-Address [0] ISDN-AddressString, extensionContainer [1] ExtensionContainer OPTIONAL, notificationToCSE [2] NULL OPTIONAL, csi-Active [3] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present when MG-CSI is sent to SGSN. -- They may only be included in ATSI/ATM ack/NSDC message. MobilityTriggers ::= SEQUENCE SIZE (1..maxNumOfMobilityTriggers) OF MM-Code maxNumOfMobilityTriggers INTEGER ::= 10 MM-Code ::= OCTET STRING (SIZE (1)) -- This type is used to indicate a Mobility Management event. -- Actions for the following MM-Code values are defined in CAMEL Phase 4: -- -- CS domain MM events: -- Location-update-in-same-VLR MM-Code ::= '00000000'B -- Location-update-to-other-VLR MM-Code ::= '00000001'B -- IMSI-Attach MM-Code ::= '00000010'B -- MS-initiated-IMSI-Detach MM-Code ::= '00000011'B -- Network-initiated-IMSI-Detach MM-Code ::= '00000100'B -- -- PS domain MM events: -- Routeing-Area-update-in-same-SGSN MM-Code ::= '10000000'B -- Routeing-Area-update-to-other-SGSN-update-from-new-SGSN -- MM-Code ::= '10000001'B -- Routeing-Area-update-to-other-SGSN-disconnect-by-detach -- MM-Code ::= '10000010'B -- GPRS-Attach MM-Code ::= '10000011'B -- MS-initiated-GPRS-Detach MM-Code ::= '10000100'B -- Network-initiated-GPRS-Detach MM-Code ::= '10000101'B -- Network-initiated-transfer-to-MS-not-reachable-for-paging -- MM-Code ::= '10000110'B -- -- If the MSC receives any other MM-code than the ones listed above for the -- CS domain, then the MSC shall ignore that MM-code. -- If the SGSN receives any other MM-code than the ones listed above for the -- PS domain, then the SGSN shall ignore that MM-code. T-CSI ::= SEQUENCE { t-BcsmCamelTDPDataList T-BcsmCamelTDPDataList, extensionContainer ExtensionContainer OPTIONAL, ..., camelCapabilityHandling [0] CamelCapabilityHandling OPTIONAL, notificationToCSE [1] NULL OPTIONAL, csi-Active [2] NULL OPTIONAL} -- notificationToCSE and csi-Active shall not be present when VT-CSI/T-CSI is sent -- to VLR/GMSC. -- They may only be included in ATSI/ATM ack/NSDC message. -- T-CSI shall not be segmented. T-BcsmCamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF T-BcsmCamelTDPData --- T-BcsmCamelTDPDataList shall not contain more than one instance of --- T-BcsmCamelTDPData containing the same value for t-BcsmTriggerDetectionPoint. --- For CAMEL Phase 2, this means that only one instance of T-BcsmCamelTDPData is allowed --- with t-BcsmTriggerDetectionPoint being equal to DP12. --- For CAMEL Phase 3, more TDP's are allowed. T-BcsmCamelTDPData ::= SEQUENCE { t-BcsmTriggerDetectionPoint T-BcsmTriggerDetectionPoint, serviceKey ServiceKey, gsmSCF-Address [0] ISDN-AddressString, defaultCallHandling [1] DefaultCallHandling, extensionContainer [2] ExtensionContainer OPTIONAL, ...} T-BcsmTriggerDetectionPoint ::= ENUMERATED { termAttemptAuthorized (12), ... , tBusy (13), tNoAnswer (14)} -- exception handling: -- For T-BcsmCamelTDPData sequences containing this parameter with any other -- value than the ones listed above, the receiver shall ignore the whole -- T-BcsmCamelTDPData sequence. -- gprs location information retrieval types SendRoutingInfoForGprsArg ::= SEQUENCE { imsi [0] IMSI, ggsn-Address [1] GSN-Address OPTIONAL, ggsn-Number [2] ISDN-AddressString, extensionContainer [3] ExtensionContainer OPTIONAL, ...} SendRoutingInfoForGprsRes ::= SEQUENCE { sgsn-Address [0] GSN-Address, ggsn-Address [1] GSN-Address OPTIONAL, mobileNotReachableReason [2] AbsentSubscriberDiagnosticSM OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} -- failure report types FailureReportArg ::= SEQUENCE { imsi [0] IMSI, ggsn-Number [1] ISDN-AddressString , ggsn-Address [2] GSN-Address OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} FailureReportRes ::= SEQUENCE { ggsn-Address [0] GSN-Address OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} -- gprs notification types NoteMsPresentForGprsArg ::= SEQUENCE { imsi [0] IMSI, sgsn-Address [1] GSN-Address, ggsn-Address [2] GSN-Address OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} NoteMsPresentForGprsRes ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ...} -- fault recovery types ResetArg ::= SEQUENCE { sendingNodenumber SendingNode-Number, hlr-List HLR-List OPTIONAL, -- The hlr-List parameter shall only be applicable for a restart of the HSS/HLR. extensionContainer [0] ExtensionContainer OPTIONAL, ..., reset-Id-List [1] Reset-Id-List OPTIONAL, subscriptionData [2] InsertSubscriberDataArg OPTIONAL, subscriptionDataDeletion [3] DeleteSubscriberDataArg OPTIONAL} SendingNode-Number ::= CHOICE { hlr-Number ISDN-AddressString, css-Number [1] ISDN-AddressString} RestoreDataArg ::= SEQUENCE { imsi IMSI, lmsi LMSI OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , vlr-Capability [6] VLR-Capability OPTIONAL, restorationIndicator [7] NULL OPTIONAL } RestoreDataRes ::= SEQUENCE { hlr-Number ISDN-AddressString, msNotReachable NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} -- VBS/VGCS types VBSDataList ::= SEQUENCE SIZE (1..maxNumOfVBSGroupIds) OF VoiceBroadcastData VGCSDataList ::= SEQUENCE SIZE (1..maxNumOfVGCSGroupIds) OF VoiceGroupCallData maxNumOfVBSGroupIds INTEGER ::= 50 maxNumOfVGCSGroupIds INTEGER ::= 50 VoiceGroupCallData ::= SEQUENCE { groupId GroupId, -- groupId shall be filled with six TBCD fillers (1111)if the longGroupId is present extensionContainer ExtensionContainer OPTIONAL, ..., additionalSubscriptions AdditionalSubscriptions OPTIONAL, additionalInfo [0] AdditionalInfo OPTIONAL, longGroupId [1] Long-GroupId OPTIONAL } -- VoiceGroupCallData containing a longGroupId shall not be sent to VLRs that did not -- indicate support of long Group IDs within the Update Location or Restore Data -- request message AdditionalInfo ::= BIT STRING (SIZE (1..136)) -- Refers to Additional Info as specified in 3GPP TS 43.068 AdditionalSubscriptions ::= BIT STRING { privilegedUplinkRequest (0), emergencyUplinkRequest (1), emergencyReset (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. VoiceBroadcastData ::= SEQUENCE { groupid GroupId, -- groupId shall be filled with six TBCD fillers (1111)if the longGroupId is present broadcastInitEntitlement NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., longGroupId [0] Long-GroupId OPTIONAL } -- VoiceBroadcastData containing a longGroupId shall not be sent to VLRs that did not -- indicate support of long Group IDs within the Update Location or Restore Data -- request message GroupId ::= TBCD-STRING (SIZE (3)) -- When Group-Id is less than six characters in length, the TBCD filler (1111) -- is used to fill unused half octets. -- Refers to the Group Identification as specified in 3GPP TS 23.003 -- and 3GPP TS 43.068/ 43.069 Long-GroupId ::= TBCD-STRING (SIZE (4)) -- When Long-Group-Id is less than eight characters in length, the TBCD filler (1111) -- is used to fill unused half octets. -- Refers to the Group Identification as specified in 3GPP TS 23.003 -- and 3GPP TS 43.068/ 43.069 -- provide subscriber info types ProvideSubscriberInfoArg ::= SEQUENCE { imsi [0] IMSI, lmsi [1] LMSI OPTIONAL, requestedInfo [2] RequestedInfo, extensionContainer [3] ExtensionContainer OPTIONAL, ..., callPriority [4] EMLPP-Priority OPTIONAL } ProvideSubscriberInfoRes ::= SEQUENCE { subscriberInfo SubscriberInfo, extensionContainer ExtensionContainer OPTIONAL, ...} SubscriberInfo ::= SEQUENCE { locationInformation [0] LocationInformation OPTIONAL, subscriberState [1] SubscriberState OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ... , locationInformationGPRS [3] LocationInformationGPRS OPTIONAL, ps-SubscriberState [4] PS-SubscriberState OPTIONAL, imei [5] IMEI OPTIONAL, ms-Classmark2 [6] MS-Classmark2 OPTIONAL, gprs-MS-Class [7] GPRSMSClass OPTIONAL, mnpInfoRes [8] MNPInfoRes OPTIONAL, imsVoiceOverPS-SessionsIndication [9] IMS-VoiceOverPS-SessionsInd OPTIONAL, lastUE-ActivityTime [10] Time OPTIONAL, lastRAT-Type [11] Used-RAT-Type OPTIONAL, eps-SubscriberState [12] PS-SubscriberState OPTIONAL, locationInformationEPS [13] LocationInformationEPS OPTIONAL, timeZone [14] TimeZone OPTIONAL, daylightSavingTime [15] DaylightSavingTime OPTIONAL, locationInformation5GS [16] LocationInformation5GS OPTIONAL } -- If the HLR receives locationInformation, subscriberState or ms-Classmark2 from an SGSN or -- MME (via an IWF), it shall discard them. -- If the HLR receives locationInformationGPRS, ps-SubscriberState, gprs-MS-Class or -- locationInformationEPS (outside the locationInformation IE) from a VLR, it shall -- discard them. -- If the HLR receives parameters which it has not requested, it shall discard them. -- The locationInformation5GS IE should be absent if UE did not access via 5GS and IM-SSF. IMS-VoiceOverPS-SessionsInd ::= ENUMERATED { imsVoiceOverPS-SessionsNotSupported (0), imsVoiceOverPS-SessionsSupported (1), unknown (2) } -- ""unknown"" shall not be used within ProvideSubscriberInfoRes TimeZone ::= OCTET STRING (SIZE (2..3)) -- Refer to the 3GPP TS 29.272 [144] for details. DaylightSavingTime ::= ENUMERATED { noAdjustment (0), plusOneHourAdjustment (1), plusTwoHoursAdjustment (2) } -- Refer to the 3GPP TS 29.272 [144] for details. MNPInfoRes ::= SEQUENCE { routeingNumber [0] RouteingNumber OPTIONAL, imsi [1] IMSI OPTIONAL, msisdn [2] ISDN-AddressString OPTIONAL, numberPortabilityStatus [3] NumberPortabilityStatus OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ... } -- The IMSI parameter contains a generic IMSI, i.e. it is not tied necessarily to the -- Subscriber. MCC and MNC values in this IMSI shall point to the Subscription Network of -- the Subscriber. See 3GPP TS 23.066 [108]. RouteingNumber ::= TBCD-STRING (SIZE (1..5)) NumberPortabilityStatus ::= ENUMERATED { notKnownToBePorted (0), ownNumberPortedOut (1), foreignNumberPortedToForeignNetwork (2), ..., ownNumberNotPortedOut (4), foreignNumberPortedIn (5) } -- exception handling: -- reception of other values than the ones listed the receiver shall ignore the -- whole NumberPortabilityStatus; -- ownNumberNotPortedOut or foreignNumberPortedIn may only be included in Any Time -- Interrogation message. MS-Classmark2 ::= OCTET STRING (SIZE (3)) -- This parameter carries the value part of the MS Classmark 2 IE defined in -- 3GPP TS 24.008 [35]. GPRSMSClass ::= SEQUENCE { mSNetworkCapability [0] MSNetworkCapability, mSRadioAccessCapability [1] MSRadioAccessCapability OPTIONAL } MSNetworkCapability ::= OCTET STRING (SIZE (1..8)) -- This parameter carries the value part of the MS Network Capability IE defined in -- 3GPP TS 24.008 [35]. MSRadioAccessCapability ::= OCTET STRING (SIZE (1..50)) -- This parameter carries the value part of the MS Radio Access Capability IE defined in -- 3GPP TS 24.008 [35]. RequestedInfo ::= SEQUENCE { locationInformation [0] NULL OPTIONAL, subscriberState [1] NULL OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., currentLocation [3] NULL OPTIONAL, requestedDomain [4] DomainType OPTIONAL, imei [6] NULL OPTIONAL, ms-classmark [5] NULL OPTIONAL, mnpRequestedInfo [7] NULL OPTIONAL, locationInformationEPS-Supported [11] NULL OPTIONAL, t-adsData [8] NULL OPTIONAL, requestedNodes [9] RequestedNodes OPTIONAL, servingNodeIndication [10] NULL OPTIONAL, localTimeZoneRequest [12] NULL OPTIONAL } -- currentLocation and locationInformationEPS-Supported shall be absent if -- locationInformation is absent -- t-adsData shall be absent in messages sent to the VLR -- requestedNodes shall be absent if requestedDomain is ""cs-Domain"" -- servingNodeIndication shall be absent if locationInformation is absent; -- servingNodeIndication shall be absent if current location is present; -- servingNodeIndication indicates by its presence that only the serving node's -- address (MME-Name or SGSN-Number or VLR-Number) is requested. DomainType ::= ENUMERATED { cs-Domain (0), ps-Domain (1), ...} -- exception handling: -- reception of values > 1 shall be mapped to 'cs-Domain' RequestedNodes ::= BIT STRING { mme (0), sgsn (1)} (SIZE (1..8)) -- Other bits than listed above shall be discarded. LocationInformation ::= SEQUENCE { ageOfLocationInformation AgeOfLocationInformation OPTIONAL, geographicalInformation [0] GeographicalInformation OPTIONAL, vlr-number [1] ISDN-AddressString OPTIONAL, locationNumber [2] LocationNumber OPTIONAL, cellGlobalIdOrServiceAreaIdOrLAI [3] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ... , selectedLSA-Id [5] LSAIdentity OPTIONAL, msc-Number [6] ISDN-AddressString OPTIONAL, geodeticInformation [7] GeodeticInformation OPTIONAL, currentLocationRetrieved [8] NULL OPTIONAL, sai-Present [9] NULL OPTIONAL, locationInformationEPS [10] LocationInformationEPS OPTIONAL, userCSGInformation [11] UserCSGInformation OPTIONAL } -- sai-Present indicates that the cellGlobalIdOrServiceAreaIdOrLAI parameter contains -- a Service Area Identity. -- currentLocationRetrieved shall be present -- if the location information were retrieved after a successfull paging. -- if the locationinformationEPS IE is present then the cellGlobalIdOrServiceAreaIdOrLAI IE, -- theÊageOfLocationInformation IE, the geographicalInformation IE, the geodeticInformation IE -- and the currentLocationRetrieved IE (outside the locationInformationEPS IE) shall be -- absent. As an exception, both the cellGlobalIdOrServiceAreaIdOrLAI IE including an LAI and -- the locationinformationEPS IE may be present in a MAP-NOTE-MM-EVENT. -- UserCSGInformation contains the CSG ID, Access mode, and the CSG Membership Indication in -- the case the Access mode is Hybrid Mode. -- The locationInformationEPS IE should be absent if locationInformationEPS-Supported was not -- received in the RequestedInfo IE. LocationInformationEPS ::= SEQUENCE { e-utranCellGlobalIdentity [0] E-UTRAN-CGI OPTIONAL, trackingAreaIdentity [1] TA-Id OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, geographicalInformation [3] GeographicalInformation OPTIONAL, geodeticInformation [4] GeodeticInformation OPTIONAL, currentLocationRetrieved [5] NULL OPTIONAL, ageOfLocationInformation [6] AgeOfLocationInformation OPTIONAL, ..., mme-Name [7] DiameterIdentity OPTIONAL } -- currentLocationRetrieved shall be present if the location information -- was retrieved after successful paging. LocationInformationGPRS ::= SEQUENCE { cellGlobalIdOrServiceAreaIdOrLAI [0] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL, routeingAreaIdentity [1] RAIdentity OPTIONAL, geographicalInformation [2] GeographicalInformation OPTIONAL, sgsn-Number [3] ISDN-AddressString OPTIONAL, selectedLSAIdentity [4] LSAIdentity OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ..., sai-Present [6] NULL OPTIONAL, geodeticInformation [7] GeodeticInformation OPTIONAL, currentLocationRetrieved [8] NULL OPTIONAL, ageOfLocationInformation [9] AgeOfLocationInformation OPTIONAL, userCSGInformation [10] UserCSGInformation OPTIONAL } -- sai-Present indicates that the cellGlobalIdOrServiceAreaIdOrLAI parameter contains -- a Service Area Identity. -- currentLocationRetrieved shall be present if the location information -- was retrieved after successful paging. -- UserCSGInformation contains the CSG ID, Access mode, and the CSG Membership Indication in -- the case the Access mode is Hybrid Mode. LocationInformation5GS ::= SEQUENCE { nrCellGlobalIdentity [0] NR-CGI OPTIONAL, e-utranCellGlobalIdentity [1] E-UTRAN-CGI OPTIONAL, geographicalInformation [2] GeographicalInformation OPTIONAL, geodeticInformation [3] GeodeticInformation OPTIONAL, amf-address [4] FQDN OPTIONAL, trackingAreaIdentity [5] TA-Id OPTIONAL, currentLocationRetrieved [6] NULL OPTIONAL, ageOfLocationInformation [7] AgeOfLocationInformation OPTIONAL, vplmnId [8] PLMN-Id OPTIONAL, localtimeZone [9] TimeZone OPTIONAL, rat-Type [10] Used-RAT-Type OPTIONAL, extensionContainer [11] ExtensionContainer OPTIONAL, ..., nrTrackingAreaIdentity [12] NR-TA-Id OPTIONAL } -- currentLocationRetrieved shall be present if the location information -- was retrieved after successful paging. UserCSGInformation ::= SEQUENCE { csg-Id [0] CSG-Id, extensionContainer [1] ExtensionContainer OPTIONAL, ..., accessMode [2] OCTET STRING (SIZE(1)) OPTIONAL, cmi [3] OCTET STRING (SIZE(1)) OPTIONAL } -- The encoding of the accessMode and cmi parameters are as defined in 3GPP TS 29.060 [105]. GeographicalInformation ::= OCTET STRING (SIZE (8)) -- Refers to geographical Information defined in 3GPP TS 23.032. -- Only the description of an ellipsoid point with uncertainty circle -- as specified in 3GPP TS 23.032 is allowed to be used -- The internal structure according to 3GPP TS 23.032 is as follows: -- Type of shape (ellipsoid point with uncertainty circle) 1 octet -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Uncertainty code 1 octet GeodeticInformation ::= OCTET STRING (SIZE (10)) -- Refers to Calling Geodetic Location defined in Q.763 (1999). -- Only the description of an ellipsoid point with uncertainty circle -- as specified in Q.763 (1999) is allowed to be used -- The internal structure according to Q.763 (1999) is as follows: -- Screening and presentation indicators 1 octet -- Type of shape (ellipsoid point with uncertainty circle) 1 octet -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Uncertainty code 1 octet -- Confidence 1 octet LocationNumber ::= OCTET STRING (SIZE (2..10)) -- the internal structure is defined in ITU-T Rec Q.763 SubscriberState ::= CHOICE { assumedIdle [0] NULL, camelBusy [1] NULL, netDetNotReachable NotReachableReason, notProvidedFromVLR [2] NULL} PS-SubscriberState ::= CHOICE { notProvidedFromSGSNorMME [0] NULL, ps-Detached [1] NULL, ps-AttachedNotReachableForPaging [2] NULL, ps-AttachedReachableForPaging [3] NULL, ps-PDP-ActiveNotReachableForPaging [4] PDP-ContextInfoList, ps-PDP-ActiveReachableForPaging [5] PDP-ContextInfoList, netDetNotReachable NotReachableReason } PDP-ContextInfoList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF PDP-ContextInfo PDP-ContextInfo ::= SEQUENCE { pdp-ContextIdentifier [0] ContextId, pdp-ContextActive [1] NULL OPTIONAL, pdp-Type [2] PDP-Type, pdp-Address [3] PDP-Address OPTIONAL, apn-Subscribed [4] APN OPTIONAL, apn-InUse [5] APN OPTIONAL, nsapi [6] NSAPI OPTIONAL, transactionId [7] TransactionId OPTIONAL, teid-ForGnAndGp [8] TEID OPTIONAL, teid-ForIu [9] TEID OPTIONAL, ggsn-Address [10] GSN-Address OPTIONAL, qos-Subscribed [11] Ext-QoS-Subscribed OPTIONAL, qos-Requested [12] Ext-QoS-Subscribed OPTIONAL, qos-Negotiated [13] Ext-QoS-Subscribed OPTIONAL, chargingId [14] GPRSChargingID OPTIONAL, chargingCharacteristics [15] ChargingCharacteristics OPTIONAL, rnc-Address [16] GSN-Address OPTIONAL, extensionContainer [17] ExtensionContainer OPTIONAL, ..., qos2-Subscribed [18] Ext2-QoS-Subscribed OPTIONAL, -- qos2-Subscribed may be present only if qos-Subscribed is present. qos2-Requested [19] Ext2-QoS-Subscribed OPTIONAL, -- qos2-Requested may be present only if qos-Requested is present. qos2-Negotiated [20] Ext2-QoS-Subscribed OPTIONAL, -- qos2-Negotiated may be present only if qos-Negotiated is present. qos3-Subscribed [21] Ext3-QoS-Subscribed OPTIONAL, -- qos3-Subscribed may be present only if qos2-Subscribed is present. qos3-Requested [22] Ext3-QoS-Subscribed OPTIONAL, -- qos3-Requested may be present only if qos2-Requested is present. qos3-Negotiated [23] Ext3-QoS-Subscribed OPTIONAL, -- qos3-Negotiated may be present only if qos2-Negotiated is present. qos4-Subscribed [25] Ext4-QoS-Subscribed OPTIONAL, -- qos4-Subscribed may be present only if qos3-Subscribed is present. qos4-Requested [26] Ext4-QoS-Subscribed OPTIONAL, -- qos4-Requested may be present only if qos3-Requested is present. qos4-Negotiated [27] Ext4-QoS-Subscribed OPTIONAL, -- qos4-Negotiated may be present only if qos3-Negotiated is present. ext-pdp-Type [28] Ext-PDP-Type OPTIONAL, -- contains the value IPv4v6 defined in 3GPP TS 29.060 [105], if the PDP can be -- accessed by dual-stack UEs. ext-pdp-Address [29] PDP-Address OPTIONAL -- contains an additional IP address in case of dual-stack static IP address assignment -- for the UE. -- it may contain an IPv4 or an IPv6 address/prefix, and it may be present -- only if pdp-Address is present; if both are present, each parameter shall -- contain a different type of address (IPv4 or IPv6). } NSAPI ::= INTEGER (0..15) -- This type is used to indicate the Network layer Service Access Point TransactionId ::= OCTET STRING (SIZE (1..2)) -- This type carries the value part of the transaction identifier which is used in the -- session management messages on the access interface. The encoding is defined in -- 3GPP TS 24.008 TEID ::= OCTET STRING (SIZE (4)) -- This type carries the value part of the Tunnel Endpoint Identifier which is used to -- distinguish between different tunnels between the same pair of entities which communicate -- using the GPRS Tunnelling Protocol The encoding is defined in 3GPP TS 29.060. GPRSChargingID ::= OCTET STRING (SIZE (4)) -- The Charging ID is a unique four octet value generated by the GGSN when -- a PDP Context is activated. A Charging ID is generated for each activated context. -- The encoding is defined in 3GPP TS 29.060. NotReachableReason ::= ENUMERATED { msPurged (0), imsiDetached (1), restrictedArea (2), notRegistered (3)} -- any time interrogation info types AnyTimeInterrogationArg ::= SEQUENCE { subscriberIdentity [0] SubscriberIdentity, requestedInfo [1] RequestedInfo, gsmSCF-Address [3] ISDN-AddressString, extensionContainer [2] ExtensionContainer OPTIONAL, ...} AnyTimeInterrogationRes ::= SEQUENCE { subscriberInfo SubscriberInfo, extensionContainer ExtensionContainer OPTIONAL, ...} -- any time information handling types AnyTimeSubscriptionInterrogationArg ::= SEQUENCE { subscriberIdentity [0] SubscriberIdentity, requestedSubscriptionInfo [1] RequestedSubscriptionInfo, gsmSCF-Address [2] ISDN-AddressString, extensionContainer [3] ExtensionContainer OPTIONAL, longFTN-Supported [4] NULL OPTIONAL, ...} AnyTimeSubscriptionInterrogationRes ::= SEQUENCE { callForwardingData [1] CallForwardingData OPTIONAL, callBarringData [2] CallBarringData OPTIONAL, odb-Info [3] ODB-Info OPTIONAL, camel-SubscriptionInfo [4] CAMEL-SubscriptionInfo OPTIONAL, supportedVLR-CAMEL-Phases [5] SupportedCamelPhases OPTIONAL, supportedSGSN-CAMEL-Phases [6] SupportedCamelPhases OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ... , offeredCamel4CSIsInVLR [8] OfferedCamel4CSIs OPTIONAL, offeredCamel4CSIsInSGSN [9] OfferedCamel4CSIs OPTIONAL, msisdn-BS-List [10] MSISDN-BS-List OPTIONAL, csg-SubscriptionDataList [11] CSG-SubscriptionDataList OPTIONAL, cw-Data [12] CallWaitingData OPTIONAL, ch-Data [13] CallHoldData OPTIONAL, clip-Data [14] ClipData OPTIONAL, clir-Data [15] ClirData OPTIONAL, ect-data [16] EctData OPTIONAL } CallWaitingData ::= SEQUENCE { cwFeatureList [1] Ext-CwFeatureList, notificationToCSE [2] NULL OPTIONAL, ... } Ext-CwFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF Ext-CwFeature Ext-CwFeature ::= SEQUENCE { basicService [1]ÊExt-BasicServiceCode, ss-Status [2]ÊExt-SS-Status, ... } ClipData ::= SEQUENCE { ss-Status [1] Ext-SS-Status, overrideCategory [2] OverrideCategory, notificationToCSE [3] NULL OPTIONAL, ... } ClirData ::= SEQUENCE { ss-Status [1] Ext-SS-Status, cliRestrictionOption [2] CliRestrictionOption OPTIONAL, notificationToCSE [3] NULL OPTIONAL, ... } CallHoldData ::= SEQUENCE { ss-Status [1] Ext-SS-Status, notificationToCSE [2] NULL OPTIONAL, ... } EctData ::= SEQUENCE { ss-Status [1] Ext-SS-Status, notificationToCSE [2] NULL OPTIONAL, ... } RequestedSubscriptionInfo ::= SEQUENCE { requestedSS-Info [1] SS-ForBS-Code OPTIONAL, odb [2] NULL OPTIONAL, requestedCAMEL-SubscriptionInfo [3] RequestedCAMEL-SubscriptionInfo OPTIONAL, supportedVLR-CAMEL-Phases [4] NULL OPTIONAL, supportedSGSN-CAMEL-Phases [5] NULL OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ..., additionalRequestedCAMEL-SubscriptionInfo [7] AdditionalRequestedCAMEL-SubscriptionInfo OPTIONAL, msisdn-BS-List [8] NULL OPTIONAL, csg-SubscriptionDataRequested [9] NULL OPTIONAL, cw-Info [10] NULL OPTIONAL, clip-Info [11] NULL OPTIONAL, clir-Info [12] NULL OPTIONAL, hold-Info [13] NULL OPTIONAL, ect-Info [14] NULL OPTIONAL } MSISDN-BS-List ::= SEQUENCE SIZE (1..maxNumOfMSISDN) OF MSISDN-BS maxNumOfMSISDN INTEGER ::= 50 MSISDN-BS ::= SEQUENCE { msisdn ISDN-AddressString, basicServiceList [0] BasicServiceList OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} RequestedCAMEL-SubscriptionInfo ::= ENUMERATED { o-CSI (0), t-CSI (1), vt-CSI (2), tif-CSI (3), gprs-CSI (4), mo-sms-CSI (5), ss-CSI (6), m-CSI (7), d-csi (8)} AdditionalRequestedCAMEL-SubscriptionInfo ::= ENUMERATED { mt-sms-CSI (0), mg-csi (1), o-IM-CSI (2), d-IM-CSI (3), vt-IM-CSI (4), ...} -- exception handling: unknown values shall be discarded by the receiver. CallForwardingData ::= SEQUENCE { forwardingFeatureList Ext-ForwFeatureList, notificationToCSE NULL OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ...} CallBarringData ::= SEQUENCE { callBarringFeatureList Ext-CallBarFeatureList, password Password OPTIONAL, wrongPasswordAttemptsCounter WrongPasswordAttemptsCounter OPTIONAL, notificationToCSE NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} WrongPasswordAttemptsCounter ::= INTEGER (0..4) ODB-Info ::= SEQUENCE { odb-Data ODB-Data, notificationToCSE NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} CAMEL-SubscriptionInfo ::= SEQUENCE { o-CSI [0] O-CSI OPTIONAL, o-BcsmCamelTDP-CriteriaList [1] O-BcsmCamelTDPCriteriaList OPTIONAL, d-CSI [2] D-CSI OPTIONAL, t-CSI [3] T-CSI OPTIONAL, t-BCSM-CAMEL-TDP-CriteriaList [4] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL, vt-CSI [5] T-CSI OPTIONAL, vt-BCSM-CAMEL-TDP-CriteriaList [6] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL, tif-CSI [7] NULL OPTIONAL, tif-CSI-NotificationToCSE [8] NULL OPTIONAL, gprs-CSI [9] GPRS-CSI OPTIONAL, mo-sms-CSI [10] SMS-CSI OPTIONAL, ss-CSI [11] SS-CSI OPTIONAL, m-CSI [12] M-CSI OPTIONAL, extensionContainer [13] ExtensionContainer OPTIONAL, ..., specificCSIDeletedList [14] SpecificCSI-Withdraw OPTIONAL, mt-sms-CSI [15] SMS-CSI OPTIONAL, mt-smsCAMELTDP-CriteriaList [16] MT-smsCAMELTDP-CriteriaList OPTIONAL, mg-csi [17] MG-CSI OPTIONAL, o-IM-CSI [18] O-CSI OPTIONAL, o-IM-BcsmCamelTDP-CriteriaList [19] O-BcsmCamelTDPCriteriaList OPTIONAL, d-IM-CSI [20] D-CSI OPTIONAL, vt-IM-CSI [21] T-CSI OPTIONAL, vt-IM-BCSM-CAMEL-TDP-CriteriaList [22] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL } AnyTimeModificationArg ::= SEQUENCE { subscriberIdentity [0] SubscriberIdentity, gsmSCF-Address [1] ISDN-AddressString, modificationRequestFor-CF-Info [2] ModificationRequestFor-CF-Info OPTIONAL, modificationRequestFor-CB-Info [3] ModificationRequestFor-CB-Info OPTIONAL, modificationRequestFor-CSI [4] ModificationRequestFor-CSI OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, longFTN-Supported [6] NULL OPTIONAL, ..., modificationRequestFor-ODB-data [7] ModificationRequestFor-ODB-data OPTIONAL, modificationRequestFor-IP-SM-GW-Data [8] ModificationRequestFor-IP-SM-GW-Data OPTIONAL, activationRequestForUE-reachability [9] RequestedServingNode OPTIONAL, modificationRequestFor-CSG [10] ModificationRequestFor-CSG OPTIONAL, modificationRequestFor-CW-Data [11] ModificationRequestFor-CW-Info OPTIONAL, modificationRequestFor-CLIP-Data [12] ModificationRequestFor-CLIP-Info OPTIONAL, modificationRequestFor-CLIR-Data [13] ModificationRequestFor-CLIR-Info OPTIONAL, modificationRequestFor-HOLD-Data [14] ModificationRequestFor-CH-Info OPTIONAL, modificationRequestFor-ECT-Data [15] ModificationRequestFor-ECT-Info OPTIONAL } ModificationRequestFor-CW-Info ::= SEQUENCE { basicService [0] Ext-BasicServiceCode OPTIONAL, ss-Status [1] Ext-SS-Status OPTIONAL, modifyNotificationToCSE [2] ModificationInstruction OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CH-Info ::= SEQUENCE { ss-Status [0] Ext-SS-Status OPTIONAL, modifyNotificationToCSE [1] ModificationInstruction OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-ECT-Info ::= SEQUENCE { ss-Status [0] Ext-SS-Status OPTIONAL, modifyNotificationToCSE [1] ModificationInstruction OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CLIR-Info ::= SEQUENCE { ss-Status [0] Ext-SS-Status OPTIONAL, cliRestrictionOption [1] CliRestrictionOption OPTIONAL, modifyNotificationToCSE [2] ModificationInstruction OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CLIP-Info ::= SEQUENCE { ss-Status [0] Ext-SS-Status OPTIONAL, overrideCategory [1] OverrideCategory OPTIONAL, modifyNotificationToCSE [2] ModificationInstruction OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CSG ::= SEQUENCE { modifyNotificationToCSE [0] ModificationInstruction OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} RequestedServingNode ::= BIT STRING { mmeAndSgsn (0)} (SIZE (1..8)) ServingNode ::= BIT STRING { mme (0), sgsn (1)} (SIZE (2..8)) -- Other bits than listed above shall be discarded. AnyTimeModificationRes ::= SEQUENCE { ss-InfoFor-CSE [0] Ext-SS-InfoFor-CSE OPTIONAL, camel-SubscriptionInfo [1] CAMEL-SubscriptionInfo OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., odb-Info [3] ODB-Info OPTIONAL, cw-Data [4] CallWaitingData OPTIONAL, ch-Data [5] CallHoldData OPTIONAL, clip-Data [6] ClipData OPTIONAL, clir-Data [7] ClirData OPTIONAL, ect-data [8] EctData OPTIONAL, serviceCentreAddress [9] AddressString OPTIONAL } ModificationRequestFor-CF-Info ::= SEQUENCE { ss-Code [0] SS-Code, basicService [1] Ext-BasicServiceCode OPTIONAL, ss-Status [2] Ext-SS-Status OPTIONAL, forwardedToNumber [3] AddressString OPTIONAL, forwardedToSubaddress [4] ISDN-SubaddressString OPTIONAL, noReplyConditionTime [5] Ext-NoRepCondTime OPTIONAL, modifyNotificationToCSE [6] ModificationInstruction OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CB-Info ::= SEQUENCE { ss-Code [0] SS-Code, basicService [1] Ext-BasicServiceCode OPTIONAL, ss-Status [2] Ext-SS-Status OPTIONAL, password [3] Password OPTIONAL, wrongPasswordAttemptsCounter [4] WrongPasswordAttemptsCounter OPTIONAL, modifyNotificationToCSE [5] ModificationInstruction OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-ODB-data ::= SEQUENCE { odb-data [0] ODB-Data OPTIONAL, modifyNotificationToCSE [1] ModificationInstruction OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CSI ::= SEQUENCE { requestedCamel-SubscriptionInfo [0] RequestedCAMEL-SubscriptionInfo, modifyNotificationToCSE [1] ModificationInstruction OPTIONAL, modifyCSI-State [2] ModificationInstruction OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ..., additionalRequestedCAMEL-SubscriptionInfo [4] AdditionalRequestedCAMEL-SubscriptionInfo OPTIONAL } -- requestedCamel-SubscriptionInfo shall be discarded if -- additionalRequestedCAMEL-SubscriptionInfo is received ModificationRequestFor-IP-SM-GW-Data ::= SEQUENCE { modifyRegistrationStatus [0] ModificationInstruction OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ..., ip-sm-gw-DiameterAddress [2] NetworkNodeDiameterAddress OPTIONAL -- ip-sm-gw-DiameterAddress may be present when ModificationInstruction is ""activate"" } ModificationInstruction ::= ENUMERATED { deactivate (0), activate (1)} -- subscriber data modification notification types NoteSubscriberDataModifiedArg ::= SEQUENCE { imsi IMSI, msisdn ISDN-AddressString, forwardingInfoFor-CSE [0] Ext-ForwardingInfoFor-CSE OPTIONAL, callBarringInfoFor-CSE [1] Ext-CallBarringInfoFor-CSE OPTIONAL, odb-Info [2] ODB-Info OPTIONAL, camel-SubscriptionInfo [3] CAMEL-SubscriptionInfo OPTIONAL, allInformationSent [4] NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., ue-reachable [5] ServingNode OPTIONAL, csg-SubscriptionDataList [6] CSG-SubscriptionDataList OPTIONAL, cw-Data [7] CallWaitingData OPTIONAL, ch-Data [8] CallHoldData OPTIONAL, clip-Data [9] ClipData OPTIONAL, clir-Data [10] ClirData OPTIONAL, ect-data [11] EctData OPTIONAL } NoteSubscriberDataModifiedRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} -- mobility management event notificatioon info types NoteMM-EventArg::= SEQUENCE { serviceKey ServiceKey, eventMet [0] MM-Code, imsi [1] IMSI, msisdn [2] ISDN-AddressString, locationInformation [3] LocationInformation OPTIONAL, supportedCAMELPhases [5] SupportedCamelPhases OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ..., locationInformationGPRS [7] LocationInformationGPRS OPTIONAL, offeredCamel4Functionalities [8] OfferedCamel4Functionalities OPTIONAL } NoteMM-EventRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} Ext-SS-InfoFor-CSE ::= CHOICE { forwardingInfoFor-CSE [0] Ext-ForwardingInfoFor-CSE, callBarringInfoFor-CSE [1] Ext-CallBarringInfoFor-CSE } Ext-ForwardingInfoFor-CSE ::= SEQUENCE { ss-Code [0] SS-Code, forwardingFeatureList [1] Ext-ForwFeatureList, notificationToCSE [2] NULL OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} Ext-CallBarringInfoFor-CSE ::= SEQUENCE { ss-Code [0] SS-Code, callBarringFeatureList [1] Ext-CallBarFeatureList, password [2] Password OPTIONAL, wrongPasswordAttemptsCounter [3] WrongPasswordAttemptsCounter OPTIONAL, notificationToCSE [4] NULL OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ...} -- vcsg location registration types UpdateVcsgLocationArg ::= SEQUENCE { imsi IMSI, msisdn [2] ISDN-AddressString OPTIONAL, vlr-Number [0] ISDN-AddressString OPTIONAL, sgsn-Number [1] ISDN-AddressString OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... } UpdateVcsgLocationRes ::= SEQUENCE { temporaryEmptySubscriptiondataIndicator NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... } CancelVcsgLocationArg ::= SEQUENCE { identity Identity, extensionContainer ExtensionContainer OPTIONAL, ... } CancelVcsgLocationRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ... } .#END 17.7.2 Operation and maintenance data types .$MAP-OM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OM-DataTypes (12) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ActivateTraceModeArg, ActivateTraceModeRes, DeactivateTraceModeArg, DeactivateTraceModeRes, TracePropagationList ; IMPORTS AddressString, IMSI, GSN-Address, GlobalCellId, E-UTRAN-CGI, TA-Id, RAIdentity, LAIFixedLength, PLMN-Id FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; ActivateTraceModeArg ::= SEQUENCE { imsi [0] IMSI OPTIONAL, traceReference [1] TraceReference, traceType [2] TraceType, omc-Id [3] AddressString OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., traceReference2 [5] TraceReference2 OPTIONAL, traceDepthList [6] TraceDepthList OPTIONAL, traceNE-TypeList [7] TraceNE-TypeList OPTIONAL, traceInterfaceList [8] TraceInterfaceList OPTIONAL, traceEventList [9] TraceEventList OPTIONAL, traceCollectionEntity [10] GSN-Address OPTIONAL, mdt-Configuration [11] MDT-Configuration OPTIONAL } MDT-Configuration ::= SEQUENCE { jobType JobType, areaScope AreaScope OPTIONAL, listOfMeasurements ListOfMeasurements OPTIONAL, reportingTrigger [0] ReportingTrigger OPTIONAL, reportInterval ReportInterval OPTIONAL, reportAmount [1] ReportAmount OPTIONAL, eventThresholdRSRP EventThresholdRSRP OPTIONAL, eventThresholdRSRQ [2] EventThresholdRSRQ OPTIONAL, loggingInterval [3] LoggingInterval OPTIONAL, loggingDuration [4] LoggingDuration OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ..., measurementPeriodUMTS [6] PeriodUMTS OPTIONAL, measurementPeriodLTE [7] PeriodLTE OPTIONAL, collectionPeriodRRM-UMTS [8] PeriodUMTS OPTIONAL, collectionPeriodRRM-LTE [9] PeriodLTE OPTIONAL, positioningMethod [10] PositioningMethod OPTIONAL, measurementQuantity [11] MeasurementQuantity OPTIONAL, eventThreshold1F [12] EventThreshold1F OPTIONAL, eventThreshold1I [13] EventThreshold1I OPTIONAL, mdt-Allowed-PLMN-List [14] MDT-Allowed-PLMNId-List OPTIONAL } MDT-Allowed-PLMNId-List ::= SEQUENCE SIZE (1..16) OF PLMN-Id PeriodUMTS ::= ENUMERATED { d250ms (0), d500ms (1), d1000ms (2), d2000ms (3), d3000ms (4), d4000ms (5), d6000ms (6), d8000ms (7), d12000ms (8), d16000ms (9), d20000ms (10), d24000ms (11), d28000ms (12), d32000ms (13), d64000ms (14)} PeriodLTE ::= ENUMERATED { d1024ms (0), d1280ms (1), d2048ms (2), d2560ms (3), d5120ms (4), d10240ms (5), d1min (6)} PositioningMethod ::= OCTET STRING (SIZE (1)) -- Octet is coded as described in 3GPP TS 32.422 [132]. MeasurementQuantity ::= OCTET STRING (SIZE (1)) -- Octet is coded as described in 3GPP TS 32.422 [132]. EventThreshold1F ::= INTEGER (-120..165) EventThreshold1I ::= INTEGER (-120..-25) JobType ::= ENUMERATED { immediate-MDT-only (0), logged-MDT-only (1), trace-only (2), immediate-MDT-and-trace (3)} AreaScope ::= SEQUENCE { cgi-List [0] CGI-List OPTIONAL, e-utran-cgi-List [1] E-UTRAN-CGI-List OPTIONAL, routingAreaId-List [2] RoutingAreaId-List OPTIONAL, locationAreaId-List [3] LocationAreaId-List OPTIONAL, trackingAreaId-List [4] TrackingAreaId-List OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ... } CGI-List ::= SEQUENCE SIZE (1..32) OF GlobalCellId E-UTRAN-CGI-List ::= SEQUENCE SIZE (1..32) OF E-UTRAN-CGI RoutingAreaId-List ::= SEQUENCE SIZE (1..8) OF RAIdentity LocationAreaId-List ::= SEQUENCE SIZE (1..8) OF LAIFixedLength TrackingAreaId-List ::= SEQUENCE SIZE (1..8) OF TA-Id ListOfMeasurements ::= OCTET STRING (SIZE (4)) -- Octets are coded as described in 3GPP TS 32.422. ReportingTrigger ::= OCTET STRING (SIZE (1)) -- Octet is coded as described in 3GPP TS 32.422. ReportInterval ::= ENUMERATED { umts250ms (0), umts500ms (1), umts1000ms (2), umts2000ms (3), umts3000ms (4), umts4000ms (5), umts6000ms (6), umts8000ms (7), umts12000ms (8), umts16000ms (9), umts20000ms (10), umts24000ms (11), umts28000ms (12), umts32000ms (13), umts64000ms (14), lte120ms (15), lte240ms (16), lte480ms (17), lte640ms (18), lte1024ms (19), lte2048ms (20), lte5120ms (21), lte10240ms (22), lte1min (23), lte6min (24), lte12min (25), lte30min (26), lte60min (27)} ReportAmount ::= ENUMERATED { d1 (0), d2 (1), d4 (2), d8 (3), d16 (4), d32 (5), d64 (6), infinity (7)} EventThresholdRSRP ::= INTEGER (0..97) EventThresholdRSRQ ::= INTEGER (0..34) LoggingInterval ::= ENUMERATED { d1dot28 (0), d2dot56 (1), d5dot12 (2), d10dot24 (3), d20dot48 (4), d30dot72 (5), d40dot96 (6), d61dot44 (7)} LoggingDuration ::= ENUMERATED { d600sec (0), d1200sec (1), d2400sec (2), d3600sec (3), d5400sec (4), d7200sec (5)} TraceReference ::= OCTET STRING (SIZE (1..2)) TraceReference2 ::= OCTET STRING (SIZE (3)) TraceRecordingSessionReference ::= OCTET STRING (SIZE (2)) TraceType ::= INTEGER (0..255) -- Trace types are fully defined in 3GPP TS 52.008. [61] TraceDepthList ::= SEQUENCE { msc-s-TraceDepth [0] TraceDepth OPTIONAL, mgw-TraceDepth [1] TraceDepth OPTIONAL, sgsn-TraceDepth [2] TraceDepth OPTIONAL, ggsn-TraceDepth [3] TraceDepth OPTIONAL, rnc-TraceDepth [4] TraceDepth OPTIONAL, bmsc-TraceDepth [5] TraceDepth OPTIONAL, ... , mme-TraceDepth [6] TraceDepth OPTIONAL, sgw-TraceDepth [7] TraceDepth OPTIONAL, pgw-TraceDepth [8] TraceDepth OPTIONAL, eNB-TraceDepth [9] TraceDepth OPTIONAL, msc-s-TraceDepthExtension [10] TraceDepthExtension OPTIONAL, mgw-TraceDepthExtension [11] TraceDepthExtension OPTIONAL, sgsn-TraceDepthExtension [12] TraceDepthExtension OPTIONAL, ggsn-TraceDepthExtension [13] TraceDepthExtension OPTIONAL, rnc-TraceDepthExtension [14] TraceDepthExtension OPTIONAL, bmsc-TraceDepthExtension [15] TraceDepthExtension OPTIONAL, mme-TraceDepthExtension [16] TraceDepthExtension OPTIONAL, sgw-TraceDepthExtension [17] TraceDepthExtension OPTIONAL, pgw-TraceDepthExtension [18] TraceDepthExtension OPTIONAL, eNB-TraceDepthExtension [19] TraceDepthExtension OPTIONAL } -- If one of the TraceDepthExtension types is sent, the corresponding TraceDepth type -- shall also be sent with the same enumeration value to allow the receiver not supporting -- the Extension to fall back to the non extended type. -- If one of the TraceDepthExtension types is received and supported, the corresponding -- TraceDepth type shall be ignored. TraceDepth ::= ENUMERATED { minimum (0), medium (1), maximum (2), ...} -- The value medium is applicable only for RNC. For other network elements, if value medium -- is received, value minimum shall be applied. TraceDepthExtension ::= ENUMERATED { minimumWithoutVendorSpecificExtension (0), mediumWithoutVendorSpecificExtension (1), maximumWithoutVendorSpecificExtension (2), ...} -- The value mediumWithoutVendorSpecificExtension is applicable only for RNC. For other -- network elements, if value mediumWithoutVendorSpecificExtension is received, value -- minimumWithoutVendorSpecificExtension shall be applied. TraceNE-TypeList ::= BIT STRING { msc-s (0), mgw (1), sgsn (2), ggsn (3), rnc (4), bm-sc (5) , mme (6), sgw (7), pgw (8), eNB (9)} (SIZE (6..16)) -- Other bits than listed above shall be discarded. TraceInterfaceList ::= SEQUENCE { msc-s-List [0] MSC-S-InterfaceList OPTIONAL, mgw-List [1] MGW-InterfaceList OPTIONAL, sgsn-List [2] SGSN-InterfaceList OPTIONAL, ggsn-List [3] GGSN-InterfaceList OPTIONAL, rnc-List [4] RNC-InterfaceList OPTIONAL, bmsc-List [5] BMSC-InterfaceList OPTIONAL, ..., mme-List [6] MME-InterfaceList OPTIONAL, sgw-List [7] SGW-InterfaceList OPTIONAL, pgw-List [8] PGW-InterfaceList OPTIONAL, eNB-List [9] ENB-InterfaceList OPTIONAL} MSC-S-InterfaceList ::= BIT STRING { a (0), iu (1), mc (2), map-g (3), map-b (4), map-e (5), map-f (6), cap (7), map-d (8), map-c (9)} (SIZE (10..16)) -- Other bits than listed above shall be discarded. MGW-InterfaceList ::= BIT STRING { mc (0), nb-up (1), iu-up (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. SGSN-InterfaceList ::= BIT STRING { gb (0), iu (1), gn (2), map-gr (3), map-gd (4), map-gf (5), gs (6), ge (7), s3 (8), s4 (9), s6d (10)} (SIZE (8..16)) -- Other bits than listed above shall be discarded. GGSN-InterfaceList ::= BIT STRING { gn (0), gi (1), gmb (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. RNC-InterfaceList ::= BIT STRING { iu (0), iur (1), iub (2), uu (3)} (SIZE (4..8)) -- Other bits than listed above shall be discarded. BMSC-InterfaceList ::= BIT STRING { gmb (0)} (SIZE (1..8)) -- Other bits than listed above shall be discarded. MME-InterfaceList ::= BIT STRING { s1-mme (0), s3 (1), s6a (2), s10 (3), s11 (4)} (SIZE (5..8)) -- Other bits than listed above shall be discarded. SGW-InterfaceList ::= BIT STRING { s4 (0), s5 (1), s8b (2), s11 (3), gxc (4)} (SIZE (5..8)) -- Other bits than listed above shall be discarded. PGW-InterfaceList ::= BIT STRING { s2a (0), s2b (1), s2c (2), s5 (3), s6b (4), gx (5), s8b (6), sgi (7)} (SIZE (8..16)) -- Other bits than listed above shall be discarded. ENB-InterfaceList ::= BIT STRING { s1-mme (0), x2 (1), uu (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. TraceEventList ::= SEQUENCE { msc-s-List [0] MSC-S-EventList OPTIONAL, mgw-List [1] MGW-EventList OPTIONAL, sgsn-List [2] SGSN-EventList OPTIONAL, ggsn-List [3] GGSN-EventList OPTIONAL, bmsc-List [4] BMSC-EventList OPTIONAL, ..., mme-List [5] MME-EventList OPTIONAL, sgw-List [6] SGW-EventList OPTIONAL, pgw-List [7] PGW-EventList OPTIONAL} MSC-S-EventList ::= BIT STRING { mo-mtCall (0), mo-mt-sms (1), lu-imsiAttach-imsiDetach (2), handovers (3), ss (4)} (SIZE (5..16)) -- Other bits than listed above shall be discarded. MGW-EventList ::= BIT STRING { context (0)} (SIZE (1..8)) -- Other bits than listed above shall be discarded. SGSN-EventList ::= BIT STRING { pdpContext (0), mo-mt-sms (1), rau-gprsAttach-gprsDetach (2), mbmsContext (3)} (SIZE (4..16)) -- Other bits than listed above shall be discarded. GGSN-EventList ::= BIT STRING { pdpContext (0), mbmsContext (1)} (SIZE (2..8)) -- Other bits than listed above shall be discarded. BMSC-EventList ::= BIT STRING { mbmsMulticastServiceActivation (0)} (SIZE (1..8)) -- Other bits than listed above shall be discarded. MME-EventList ::= BIT STRING { ue-initiatedPDNconectivityRequest (0), serviceRequestts (1), initialAttachTrackingAreaUpdateDetach (2), ue-initiatedPDNdisconnection (3), bearerActivationModificationDeletion (4), handover (5)} (SIZE (6..8)) -- Other bits than listed above shall be discarded. SGW-EventList ::= BIT STRING { pdn-connectionCreation (0), pdn-connectionTermination (1), bearerActivationModificationDeletion (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. PGW-EventList ::= BIT STRING { pdn-connectionCreation (0), pdn-connectionTermination (1), bearerActivationModificationDeletion (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. TracePropagationList ::= SEQUENCE { traceReference [0] TraceReference OPTIONAL, traceType [1] TraceType OPTIONAL, traceReference2 [2] TraceReference2 OPTIONAL, traceRecordingSessionReference [3] TraceRecordingSessionReference OPTIONAL, rnc-TraceDepth [4] TraceDepth OPTIONAL, rnc-InterfaceList [5] RNC-InterfaceList OPTIONAL, msc-s-TraceDepth [6] TraceDepth OPTIONAL, msc-s-InterfaceList [7] MSC-S-InterfaceList OPTIONAL, msc-s-EventList [8] MSC-S-EventList OPTIONAL, mgw-TraceDepth [9] TraceDepth OPTIONAL, mgw-InterfaceList [10] MGW-InterfaceList OPTIONAL, mgw-EventList [11] MGW-EventList OPTIONAL, ..., rnc-TraceDepthExtension [12] TraceDepthExtension OPTIONAL, msc-s-TraceDepthExtension [13] TraceDepthExtension OPTIONAL, mgw-TraceDepthExtension [14] TraceDepthExtension OPTIONAL } -- If one of the TraceDepthExtension types is sent, the corresponding TraceDepth type -- shall also be sent with the same enumeration value to allow the receiver not supporting -- the Extension to fall back to the non extended type. -- If one of the TraceDepthExtension types is received and supported, the corresponding -- TraceDepth type shall be ignored. ActivateTraceModeRes ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ..., traceSupportIndicator [1] NULL OPTIONAL } DeactivateTraceModeArg ::= SEQUENCE { imsi [0] IMSI OPTIONAL, traceReference [1] TraceReference, extensionContainer [2] ExtensionContainer OPTIONAL, ..., traceReference2 [3] TraceReference2 OPTIONAL } DeactivateTraceModeRes ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ...} .#END 17.7.3 Call handling data types .$MAP-CH-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CH-DataTypes (13) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS SendRoutingInfoArg, SendRoutingInfoRes, ProvideRoamingNumberArg, ProvideRoamingNumberRes, ResumeCallHandlingArg, ResumeCallHandlingRes, NumberOfForwarding, SuppressionOfAnnouncement, CallReferenceNumber, SetReportingStateArg, SetReportingStateRes, StatusReportArg, StatusReportRes, RemoteUserFreeArg, RemoteUserFreeRes, IST-AlertArg, IST-AlertRes, IST-CommandArg, IST-CommandRes, UU-Data, ReleaseResourcesArg, ReleaseResourcesRes ; IMPORTS SubscriberInfo, SupportedCamelPhases, OfferedCamel4CSIs, CUG-Interlock, O-CSI, D-CSI, O-BcsmCamelTDPCriteriaList, T-BCSM-CAMEL-TDP-CriteriaList, IST-SupportIndicator, IST-AlertTimerValue, T-CSI, NumberPortabilityStatus, PagingArea FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} ForwardingOptions, SS-List, CCBS-Feature FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} ISDN-AddressString, ISDN-SubaddressString, FTN-AddressString, ExternalSignalInfo, Ext-ExternalSignalInfo, IMSI, LMSI, Ext-BasicServiceCode, AlertingPattern, NAEA-PreferredCI, EMLPP-Priority, PLMN-Id FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; CUG-CheckInfo ::= SEQUENCE { cug-Interlock CUG-Interlock, cug-OutgoingAccess NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} NumberOfForwarding ::= INTEGER (1..5) SendRoutingInfoArg ::= SEQUENCE { msisdn [0] ISDN-AddressString, cug-CheckInfo [1] CUG-CheckInfo OPTIONAL, numberOfForwarding [2] NumberOfForwarding OPTIONAL, interrogationType [3] InterrogationType, or-Interrogation [4] NULL OPTIONAL, or-Capability [5] OR-Phase OPTIONAL, gmsc-OrGsmSCF-Address [6] ISDN-AddressString, callReferenceNumber [7] CallReferenceNumber OPTIONAL, forwardingReason [8] ForwardingReason OPTIONAL, basicServiceGroup [9] Ext-BasicServiceCode OPTIONAL, networkSignalInfo [10] ExternalSignalInfo OPTIONAL, camelInfo [11] CamelInfo OPTIONAL, suppressionOfAnnouncement [12] SuppressionOfAnnouncement OPTIONAL, extensionContainer [13] ExtensionContainer OPTIONAL, ..., alertingPattern [14] AlertingPattern OPTIONAL, ccbs-Call [15] NULL OPTIONAL, supportedCCBS-Phase [16] SupportedCCBS-Phase OPTIONAL, additionalSignalInfo [17] Ext-ExternalSignalInfo OPTIONAL, istSupportIndicator [18] IST-SupportIndicator OPTIONAL, pre-pagingSupported [19] NULL OPTIONAL, callDiversionTreatmentIndicator [20] CallDiversionTreatmentIndicator OPTIONAL, longFTN-Supported [21] NULL OPTIONAL, suppress-VT-CSI [22] NULL OPTIONAL, suppressIncomingCallBarring [23] NULL OPTIONAL, gsmSCF-InitiatedCall [24] NULL OPTIONAL, basicServiceGroup2 [25] Ext-BasicServiceCode OPTIONAL, networkSignalInfo2 [26] ExternalSignalInfo OPTIONAL, suppressMTSS [27] SuppressMTSS OPTIONAL, mtRoamingRetrySupported [28] NULL OPTIONAL, callPriority [29] EMLPP-Priority OPTIONAL } SuppressionOfAnnouncement ::= NULL SuppressMTSS ::= BIT STRING { suppressCUG (0), suppressCCBS (1) } (SIZE (2..16)) -- Other bits than listed above shall be discarded InterrogationType ::= ENUMERATED { basicCall (0), forwarding (1)} OR-Phase ::= INTEGER (1..127) CallReferenceNumber ::= OCTET STRING (SIZE (1..8)) ForwardingReason ::= ENUMERATED { notReachable (0), busy (1), noReply (2)} SupportedCCBS-Phase ::= INTEGER (1..127) -- exception handling: -- Only value 1 is used. -- Values in the ranges 2-127 are reserved for future use. -- If received values 2-127 shall be mapped on to value 1. CallDiversionTreatmentIndicator ::= OCTET STRING (SIZE(1)) -- callDiversionAllowed (xxxx xx01) -- callDiversionNotAllowed (xxxx xx10) -- network default is call diversion allowed SendRoutingInfoRes ::= [3] SEQUENCE { imsi [9] IMSI OPTIONAL, -- IMSI must be present if SendRoutingInfoRes is not segmented. -- If the TC-Result-NL segmentation option is taken the IMSI must be -- present in one segmented transmission of SendRoutingInfoRes. extendedRoutingInfo ExtendedRoutingInfo OPTIONAL, cug-CheckInfo [3] CUG-CheckInfo OPTIONAL, cugSubscriptionFlag [6] NULL OPTIONAL, subscriberInfo [7] SubscriberInfo OPTIONAL, ss-List [1] SS-List OPTIONAL, basicService [5] Ext-BasicServiceCode OPTIONAL, forwardingInterrogationRequired [4] NULL OPTIONAL, vmsc-Address [2] ISDN-AddressString OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ... , naea-PreferredCI [10] NAEA-PreferredCI OPTIONAL, -- naea-PreferredCI is included at the discretion of the HLR operator."
"ccbs-Indicators [11] CCBS-Indicators OPTIONAL, msisdn [12] ISDN-AddressString OPTIONAL, numberPortabilityStatus [13] NumberPortabilityStatus OPTIONAL, istAlertTimer [14] IST-AlertTimerValue OPTIONAL, supportedCamelPhasesInVMSC [15] SupportedCamelPhases OPTIONAL, offeredCamel4CSIsInVMSC [16] OfferedCamel4CSIs OPTIONAL, routingInfo2 [17] RoutingInfo OPTIONAL, ss-List2 [18] SS-List OPTIONAL, basicService2 [19] Ext-BasicServiceCode OPTIONAL, allowedServices [20] AllowedServices OPTIONAL, unavailabilityCause [21] UnavailabilityCause OPTIONAL, releaseResourcesSupported [22] NULL OPTIONAL, gsm-BearerCapability [23] ExternalSignalInfo OPTIONAL } AllowedServices ::= BIT STRING { firstServiceAllowed (0), secondServiceAllowed (1) } (SIZE (2..8)) -- firstService is the service indicated in the networkSignalInfo -- secondService is the service indicated in the networkSignalInfo2 -- Other bits than listed above shall be discarded UnavailabilityCause ::= ENUMERATED { bearerServiceNotProvisioned (1), teleserviceNotProvisioned (2), absentSubscriber (3), busySubscriber (4), callBarred (5), cug-Reject (6), ...} -- exception handling: -- Reception of other values than the ones listed shall result in the service -- being unavailable for that call. CCBS-Indicators ::= SEQUENCE { ccbs-Possible [0] NULL OPTIONAL, keepCCBS-CallIndicator [1] NULL OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} RoutingInfo ::= CHOICE { roamingNumber ISDN-AddressString, forwardingData ForwardingData} ForwardingData ::= SEQUENCE { forwardedToNumber [5] ISDN-AddressString OPTIONAL, -- When this datatype is sent from an HLR which supports CAMEL Phase 2 -- to a GMSC which supports CAMEL Phase 2 the GMSC shall not check the -- format of the number forwardedToSubaddress [4] ISDN-SubaddressString OPTIONAL, forwardingOptions [6] ForwardingOptions OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ..., longForwardedToNumber [8] FTN-AddressString OPTIONAL} ProvideRoamingNumberArg ::= SEQUENCE { imsi [0] IMSI, msc-Number [1] ISDN-AddressString, msisdn [2] ISDN-AddressString OPTIONAL, lmsi [4] LMSI OPTIONAL, gsm-BearerCapability [5] ExternalSignalInfo OPTIONAL, networkSignalInfo [6] ExternalSignalInfo OPTIONAL, suppressionOfAnnouncement [7] SuppressionOfAnnouncement OPTIONAL, gmsc-Address [8] ISDN-AddressString OPTIONAL, callReferenceNumber [9] CallReferenceNumber OPTIONAL, or-Interrogation [10] NULL OPTIONAL, extensionContainer [11] ExtensionContainer OPTIONAL, ... , alertingPattern [12] AlertingPattern OPTIONAL, ccbs-Call [13] NULL OPTIONAL, supportedCamelPhasesInInterrogatingNode [15] SupportedCamelPhases OPTIONAL, additionalSignalInfo [14] Ext-ExternalSignalInfo OPTIONAL, orNotSupportedInGMSC [16] NULL OPTIONAL, pre-pagingSupported [17] NULL OPTIONAL, longFTN-Supported [18] NULL OPTIONAL, suppress-VT-CSI [19] NULL OPTIONAL, offeredCamel4CSIsInInterrogatingNode [20] OfferedCamel4CSIs OPTIONAL, mtRoamingRetrySupported [21] NULL OPTIONAL, pagingArea [22] PagingArea OPTIONAL, callPriority [23] EMLPP-Priority OPTIONAL, mtrf-Indicator [24] NULL OPTIONAL, oldMSC-Number [25] ISDN-AddressString OPTIONAL, lastUsedLtePLMN-Id [26] PLMN-Id OPTIONAL } ProvideRoamingNumberRes ::= SEQUENCE { roamingNumber ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ..., releaseResourcesSupported NULL OPTIONAL, vmsc-Address ISDN-AddressString OPTIONAL } ResumeCallHandlingArg ::= SEQUENCE { callReferenceNumber [0] CallReferenceNumber OPTIONAL, basicServiceGroup [1] Ext-BasicServiceCode OPTIONAL, forwardingData [2] ForwardingData OPTIONAL, imsi [3] IMSI OPTIONAL, cug-CheckInfo [4] CUG-CheckInfo OPTIONAL, o-CSI [5] O-CSI OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ccbs-Possible [8] NULL OPTIONAL, msisdn [9] ISDN-AddressString OPTIONAL, uu-Data [10] UU-Data OPTIONAL, allInformationSent [11] NULL OPTIONAL, ..., d-csi [12] D-CSI OPTIONAL, o-BcsmCamelTDPCriteriaList [13] O-BcsmCamelTDPCriteriaList OPTIONAL, basicServiceGroup2 [14] Ext-BasicServiceCode OPTIONAL, mtRoamingRetry [15] NULL OPTIONAL } UU-Data ::= SEQUENCE { uuIndicator [0] UUIndicator OPTIONAL, uui [1] UUI OPTIONAL, uusCFInteraction [2] NULL OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} UUIndicator ::= OCTET STRING (SIZE (1)) -- Octets are coded according to ETS 300 356 UUI ::= OCTET STRING (SIZE (1..131)) -- Octets are coded according to ETS 300 356 ResumeCallHandlingRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} CamelInfo ::= SEQUENCE { supportedCamelPhases SupportedCamelPhases, suppress-T-CSI NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , offeredCamel4CSIs [0] OfferedCamel4CSIs OPTIONAL } ExtendedRoutingInfo ::= CHOICE { routingInfo RoutingInfo, camelRoutingInfo [8] CamelRoutingInfo} CamelRoutingInfo ::= SEQUENCE { forwardingData ForwardingData OPTIONAL, gmscCamelSubscriptionInfo [0] GmscCamelSubscriptionInfo, extensionContainer [1] ExtensionContainer OPTIONAL, ...} GmscCamelSubscriptionInfo ::= SEQUENCE { t-CSI [0] T-CSI OPTIONAL, o-CSI [1] O-CSI OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., o-BcsmCamelTDP-CriteriaList [3] O-BcsmCamelTDPCriteriaList OPTIONAL, t-BCSM-CAMEL-TDP-CriteriaList [4] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL, d-csi [5] D-CSI OPTIONAL} SetReportingStateArg ::= SEQUENCE { imsi [0] IMSI OPTIONAL, lmsi [1] LMSI OPTIONAL, ccbs-Monitoring [2] ReportingState OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} ReportingState ::= ENUMERATED { stopMonitoring (0), startMonitoring (1), ...} -- exception handling: -- reception of values 2-10 shall be mapped to 'stopMonitoring' -- reception of values > 10 shall be mapped to 'startMonitoring' SetReportingStateRes ::= SEQUENCE{ ccbs-SubscriberStatus [0] CCBS-SubscriberStatus OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} CCBS-SubscriberStatus ::= ENUMERATED { ccbsNotIdle (0), ccbsIdle (1), ccbsNotReachable (2), ...} -- exception handling: -- reception of values 3-10 shall be mapped to 'ccbsNotIdle' -- reception of values 11-20 shall be mapped to 'ccbsIdle' -- reception of values > 20 shall be mapped to 'ccbsNotReachable' StatusReportArg ::= SEQUENCE{ imsi [0] IMSI, eventReportData [1] EventReportData OPTIONAL, callReportdata [2] CallReportData OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} EventReportData ::= SEQUENCE{ ccbs-SubscriberStatus [0] CCBS-SubscriberStatus OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} CallReportData ::= SEQUENCE{ monitoringMode [0] MonitoringMode OPTIONAL, callOutcome [1] CallOutcome OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} MonitoringMode ::= ENUMERATED { a-side (0), b-side (1), ...} -- exception handling: -- reception of values 2-10 shall be mapped 'a-side' -- reception of values > 10 shall be mapped to 'b-side' CallOutcome ::= ENUMERATED { success (0), failure (1), busy (2), ...} -- exception handling: -- reception of values 3-10 shall be mapped to 'success' -- reception of values 11-20 shall be mapped to 'failure' -- reception of values > 20 shall be mapped to 'busy' StatusReportRes ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ...} RemoteUserFreeArg ::= SEQUENCE{ imsi [0] IMSI, callInfo [1] ExternalSignalInfo, ccbs-Feature [2] CCBS-Feature, translatedB-Number [3] ISDN-AddressString, replaceB-Number [4] NULL OPTIONAL, alertingPattern [5] AlertingPattern OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ...} RemoteUserFreeRes ::= SEQUENCE{ ruf-Outcome [0] RUF-Outcome, extensionContainer [1] ExtensionContainer OPTIONAL, ...} RUF-Outcome ::= ENUMERATED{ accepted (0), rejected (1), noResponseFromFreeMS (2), -- T4 Expiry noResponseFromBusyMS (3), -- T10 Expiry udubFromFreeMS (4), udubFromBusyMS (5), ...} -- exception handling: -- reception of values 6-20 shall be mapped to 'accepted' -- reception of values 21-30 shall be mapped to 'rejected' -- reception of values 31-40 shall be mapped to 'noResponseFromFreeMS' -- reception of values 41-50 shall be mapped to 'noResponseFromBusyMS' -- reception of values 51-60 shall be mapped to 'udubFromFreeMS' -- reception of values > 60 shall be mapped to 'udubFromBusyMS' IST-AlertArg ::= SEQUENCE{ imsi [0] IMSI, extensionContainer [1] ExtensionContainer OPTIONAL, ...} IST-AlertRes ::= SEQUENCE{ istAlertTimer [0] IST-AlertTimerValue OPTIONAL, istInformationWithdraw [1] NULL OPTIONAL, callTerminationIndicator [2] CallTerminationIndicator OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} IST-CommandArg ::= SEQUENCE{ imsi [0] IMSI, extensionContainer [1] ExtensionContainer OPTIONAL, ...} IST-CommandRes ::= SEQUENCE{ extensionContainer ExtensionContainer OPTIONAL, ...} CallTerminationIndicator ::= ENUMERATED { terminateCallActivityReferred (0), terminateAllCallActivities (1), ...} -- exception handling: -- reception of values 2-10 shall be mapped to ' terminateCallActivityReferred ' -- reception of values > 10 shall be mapped to ' terminateAllCallActivities ' -- In MSCs not supporting linkage of all call activities, any value received shall -- be interpreted as ' terminateCallActivityReferred ' ReleaseResourcesArg ::= SEQUENCE{ msrn ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ...} ReleaseResourcesRes ::= SEQUENCE{ extensionContainer ExtensionContainer OPTIONAL, ...} .#END 17.7.4 Supplementary service data types .$MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RegisterSS-Arg, SS-Info, SS-Status, SS-SubscriptionOption, SS-ForBS-Code, InterrogateSS-Res, USSD-Arg, USSD-Res, USSD-DataCodingScheme, USSD-String, Password, GuidanceInfo, SS-List, SS-InfoList, OverrideCategory, CliRestrictionOption, NoReplyConditionTime, ForwardingOptions, maxNumOfSS, SS-Data, SS-InvocationNotificationArg, SS-InvocationNotificationRes, CCBS-Feature, RegisterCC-EntryArg, RegisterCC-EntryRes, EraseCC-EntryArg, EraseCC-EntryRes ; IMPORTS AddressString, ISDN-AddressString, ISDN-SubaddressString, FTN-AddressString, IMSI, BasicServiceCode, AlertingPattern, EMLPP-Priority, MaxMC-Bearers, MC-Bearers, ExternalSignalInfo FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} ; RegisterSS-Arg ::= SEQUENCE { ss-Code SS-Code, basicService BasicServiceCode OPTIONAL, forwardedToNumber [4] AddressString OPTIONAL, forwardedToSubaddress [6] ISDN-SubaddressString OPTIONAL, noReplyConditionTime [5] NoReplyConditionTime OPTIONAL, ..., defaultPriority [7] EMLPP-Priority OPTIONAL, nbrUser [8] MC-Bearers OPTIONAL, longFTN-Supported [9] NULL OPTIONAL } NoReplyConditionTime ::= INTEGER (5..30) SS-Info ::= CHOICE { forwardingInfo [0] ForwardingInfo, callBarringInfo [1] CallBarringInfo, ss-Data [3] SS-Data} ForwardingInfo ::= SEQUENCE { ss-Code SS-Code OPTIONAL, forwardingFeatureList ForwardingFeatureList, ...} ForwardingFeatureList ::= SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF ForwardingFeature ForwardingFeature ::= SEQUENCE { basicService BasicServiceCode OPTIONAL, ss-Status [4] SS-Status OPTIONAL, forwardedToNumber [5] ISDN-AddressString OPTIONAL, forwardedToSubaddress [8] ISDN-SubaddressString OPTIONAL, forwardingOptions [6] ForwardingOptions OPTIONAL, noReplyConditionTime [7] NoReplyConditionTime OPTIONAL, ..., longForwardedToNumber [9] FTN-AddressString OPTIONAL } SS-Status ::= OCTET STRING (SIZE (1)) -- bits 8765: 0000 (unused) -- bits 4321: Used to convey the ""P bit"",""R bit"",""A bit"" and ""Q bit"", -- representing supplementary service state information -- as defined in TS 3GPP TS 23.011 [22] -- bit 4: ""Q bit"" -- bit 3: ""P bit"" -- bit 2: ""R bit"" -- bit 1: ""A bit"" ForwardingOptions ::= OCTET STRING (SIZE (1)) -- bit 8: notification to forwarding party -- 0 no notification -- 1 notification -- bit 7: redirecting presentation -- 0 no presentation -- 1 presentation -- bit 6: notification to calling party -- 0 no notification -- 1 notification -- bit 5: 0 (unused) -- bits 43: forwarding reason -- 00 ms not reachable -- 01 ms busy -- 10 no reply -- 11 unconditional when used in a SRI Result, -- or call deflection when used in a RCH Argument -- bits 21: 00 (unused) CallBarringInfo ::= SEQUENCE { ss-Code SS-Code OPTIONAL, callBarringFeatureList CallBarringFeatureList, ...} CallBarringFeatureList ::= SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF CallBarringFeature CallBarringFeature ::= SEQUENCE { basicService BasicServiceCode OPTIONAL, ss-Status [4] SS-Status OPTIONAL, ...} SS-Data ::= SEQUENCE { ss-Code SS-Code OPTIONAL, ss-Status [4] SS-Status OPTIONAL, ss-SubscriptionOption SS-SubscriptionOption OPTIONAL, basicServiceGroupList BasicServiceGroupList OPTIONAL, ..., defaultPriority EMLPP-Priority OPTIONAL, nbrUser [5] MC-Bearers OPTIONAL } SS-SubscriptionOption ::= CHOICE { cliRestrictionOption [2] CliRestrictionOption, overrideCategory [1] OverrideCategory} CliRestrictionOption ::= ENUMERATED { permanent (0), temporaryDefaultRestricted (1), temporaryDefaultAllowed (2)} OverrideCategory ::= ENUMERATED { overrideEnabled (0), overrideDisabled (1)} SS-ForBS-Code ::= SEQUENCE { ss-Code SS-Code, basicService BasicServiceCode OPTIONAL, ..., longFTN-Supported [4] NULL OPTIONAL } GenericServiceInfo ::= SEQUENCE { ss-Status SS-Status, cliRestrictionOption CliRestrictionOption OPTIONAL, ..., maximumEntitledPriority [0] EMLPP-Priority OPTIONAL, defaultPriority [1] EMLPP-Priority OPTIONAL, ccbs-FeatureList [2] CCBS-FeatureList OPTIONAL, nbrSB [3] MaxMC-Bearers OPTIONAL, nbrUser [4] MC-Bearers OPTIONAL, nbrSN [5] MC-Bearers OPTIONAL } CCBS-FeatureList ::= SEQUENCE SIZE (1..maxNumOfCCBS-Requests) OF CCBS-Feature maxNumOfCCBS-Requests INTEGER ::= 5 CCBS-Feature ::= SEQUENCE { ccbs-Index [0] CCBS-Index OPTIONAL, b-subscriberNumber [1] ISDN-AddressString OPTIONAL, b-subscriberSubaddress [2] ISDN-SubaddressString OPTIONAL, basicServiceGroup [3] BasicServiceCode OPTIONAL, ...} CCBS-Index ::= INTEGER (1..maxNumOfCCBS-Requests) InterrogateSS-Res ::= CHOICE { ss-Status [0] SS-Status, basicServiceGroupList [2] BasicServiceGroupList, forwardingFeatureList [3] ForwardingFeatureList, genericServiceInfo [4] GenericServiceInfo } USSD-Arg ::= SEQUENCE { ussd-DataCodingScheme USSD-DataCodingScheme, ussd-String USSD-String, ... , alertingPattern AlertingPattern OPTIONAL, msisdn [0] ISDN-AddressString OPTIONAL } USSD-Res ::= SEQUENCE { ussd-DataCodingScheme USSD-DataCodingScheme, ussd-String USSD-String, ...} USSD-DataCodingScheme ::= OCTET STRING (SIZE (1)) -- The structure of the USSD-DataCodingScheme is defined by -- the Cell Broadcast Data Coding Scheme as described in -- TS 3GPP TS 23.038 [25] USSD-String ::= OCTET STRING (SIZE (1..maxUSSD-StringLength)) -- The structure of the contents of the USSD-String is dependent -- on the USSD-DataCodingScheme as described in TS 3GPP TS 23.038 [25]. maxUSSD-StringLength INTEGER ::= 160 Password ::= NumericString (FROM (""0""|""1""|""2""|""3""|""4""|""5""|""6""|""7""|""8""|""9"")) (SIZE (4)) GuidanceInfo ::= ENUMERATED { enterPW (0), enterNewPW (1), enterNewPW-Again (2)} -- How this information is really delivered to the subscriber -- (display, announcement, ...) is not part of this -- specification. SS-List ::= SEQUENCE SIZE (1..maxNumOfSS) OF SS-Code maxNumOfSS INTEGER ::= 30 SS-InfoList ::= SEQUENCE SIZE (1..maxNumOfSS) OF SS-Info BasicServiceGroupList ::= SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF BasicServiceCode maxNumOfBasicServiceGroups INTEGER ::= 13 SS-InvocationNotificationArg ::= SEQUENCE { imsi [0] IMSI, msisdn [1] ISDN-AddressString, ss-Event [2] SS-Code, -- The following SS-Code values are allowed : -- ect SS-Code ::= '00110001'B -- multiPTY SS-Code ::= '01010001'B -- cd SS-Code ::= '00100100'B -- ccbs SS-Code ::= '01000100'B ss-EventSpecification [3] SS-EventSpecification OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., b-subscriberNumber [5] ISDN-AddressString OPTIONAL, ccbs-RequestState [6] CCBS-RequestState OPTIONAL } CCBS-RequestState ::= ENUMERATED { request (0), recall (1), active (2), completed (3), suspended (4), frozen (5), deleted (6) } SS-InvocationNotificationRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ... } SS-EventSpecification ::= SEQUENCE SIZE (1..maxEventSpecification) OF AddressString maxEventSpecification INTEGER ::= 2 RegisterCC-EntryArg ::= SEQUENCE { ss-Code [0] SS-Code, ccbs-Data [1] CCBS-Data OPTIONAL, ...} CCBS-Data ::= SEQUENCE { ccbs-Feature [0] CCBS-Feature, translatedB-Number [1] ISDN-AddressString, serviceIndicator [2] ServiceIndicator OPTIONAL, callInfo [3] ExternalSignalInfo, networkSignalInfo [4] ExternalSignalInfo, ...} ServiceIndicator ::= BIT STRING { clir-invoked (0), camel-invoked (1)} (SIZE(2..32)) -- exception handling: -- bits 2 to 31 shall be ignored if received and not understood RegisterCC-EntryRes ::= SEQUENCE { ccbs-Feature [0] CCBS-Feature OPTIONAL, ...} EraseCC-EntryArg ::= SEQUENCE { ss-Code [0] SS-Code, ccbs-Index [1] CCBS-Index OPTIONAL, ...} EraseCC-EntryRes ::= SEQUENCE { ss-Code [0] SS-Code, ss-Status [1] SS-Status OPTIONAL, ...} .#END 17.7.5 Supplementary service codes .$MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} DEFINITIONS ::= BEGIN SS-Code ::= OCTET STRING (SIZE (1)) -- This type is used to represent the code identifying a single -- supplementary service, a group of supplementary services, or -- all supplementary services. The services and abbreviations -- used are defined in TS 3GPP TS 22.004 [5]. The internal structure is -- defined as follows: -- -- bits 87654321: group (bits 8765), and specific service -- (bits 4321) allSS SS-Code ::= '00000000'B -- reserved for possible future use -- all SS allLineIdentificationSS SS-Code ::= '00010000'B -- reserved for possible future use -- all line identification SS clip SS-Code ::= '00010001'B -- calling line identification presentation clir SS-Code ::= '00010010'B -- calling line identification restriction colp SS-Code ::= '00010011'B -- connected line identification presentation colr SS-Code ::= '00010100'B -- connected line identification restriction mci SS-Code ::= '00010101'B -- reserved for possible future use -- malicious call identification allNameIdentificationSS SS-Code ::= '00011000'B -- all name identification SS cnap SS-Code ::= '00011001'B -- calling name presentation -- SS-Codes '00011010'B to '00011111'B are reserved for future -- NameIdentification Supplementary Service use. allForwardingSS SS-Code ::= '00100000'B -- all forwarding SS cfu SS-Code ::= '00100001'B -- call forwarding unconditional allCondForwardingSS SS-Code ::= '00101000'B -- all conditional forwarding SS cfb SS-Code ::= '00101001'B -- call forwarding on mobile subscriber busy cfnry SS-Code ::= '00101010'B -- call forwarding on no reply cfnrc SS-Code ::= '00101011'B -- call forwarding on mobile subscriber not reachable cd SS-Code ::= '00100100'B -- call deflection allCallOfferingSS SS-Code ::= '00110000'B -- reserved for possible future use -- all call offering SS includes also all forwarding SS ect SS-Code ::= '00110001'B -- explicit call transfer mah SS-Code ::= '00110010'B -- reserved for possible future use -- mobile access hunting allCallCompletionSS SS-Code ::= '01000000'B -- reserved for possible future use -- all Call completion SS cw SS-Code ::= '01000001'B -- call waiting hold SS-Code ::= '01000010'B -- call hold ccbs-A SS-Code ::= '01000011'B -- completion of call to busy subscribers, originating side -- this SS-Code is used only in InsertSubscriberData, DeleteSubscriberData -- and InterrogateSS ccbs-B SS-Code ::= '01000100'B -- completion of call to busy subscribers, destination side -- this SS-Code is used only in InsertSubscriberData and DeleteSubscriberData mc SS-Code ::= '01000101'B -- multicall allMultiPartySS SS-Code ::= '01010000'B -- reserved for possible future use -- all multiparty SS multiPTY SS-Code ::= '01010001'B -- multiparty allCommunityOfInterest-SS SS-Code ::= '01100000'B -- reserved for possible future use -- all community of interest SS cug SS-Code ::= '01100001'B -- closed user group allChargingSS SS-Code ::= '01110000'B -- reserved for possible future use -- all charging SS aoci SS-Code ::= '01110001'B -- advice of charge information aocc SS-Code ::= '01110010'B -- advice of charge charging allAdditionalInfoTransferSS SS-Code ::= '10000000'B -- reserved for possible future use -- all additional information transfer SS uus1 SS-Code ::= '10000001'B -- UUS1 user-to-user signalling uus2 SS-Code ::= '10000010'B -- UUS2 user-to-user signalling uus3 SS-Code ::= '10000011'B -- UUS3 user-to-user signalling allBarringSS SS-Code ::= '10010000'B -- all barring SS barringOfOutgoingCalls SS-Code ::= '10010001'B -- barring of outgoing calls baoc SS-Code ::= '10010010'B -- barring of all outgoing calls boic SS-Code ::= '10010011'B -- barring of outgoing international calls boicExHC SS-Code ::= '10010100'B -- barring of outgoing international calls except those directed -- to the home PLMN Country barringOfIncomingCalls SS-Code ::= '10011001'B -- barring of incoming calls baic SS-Code ::= '10011010'B -- barring of all incoming calls bicRoam SS-Code ::= '10011011'B -- barring of incoming calls when roaming outside home PLMN -- Country allPLMN-specificSS SS-Code ::= '11110000'B plmn-specificSS-1 SS-Code ::= '11110001'B plmn-specificSS-2 SS-Code ::= '11110010'B plmn-specificSS-3 SS-Code ::= '11110011'B plmn-specificSS-4 SS-Code ::= '11110100'B plmn-specificSS-5 SS-Code ::= '11110101'B plmn-specificSS-6 SS-Code ::= '11110110'B plmn-specificSS-7 SS-Code ::= '11110111'B plmn-specificSS-8 SS-Code ::= '11111000'B plmn-specificSS-9 SS-Code ::= '11111001'B plmn-specificSS-A SS-Code ::= '11111010'B plmn-specificSS-B SS-Code ::= '11111011'B plmn-specificSS-C SS-Code ::= '11111100'B plmn-specificSS-D SS-Code ::= '11111101'B plmn-specificSS-E SS-Code ::= '11111110'B plmn-specificSS-F SS-Code ::= '11111111'B allCallPrioritySS SS-Code ::= '10100000'B -- reserved for possible future use -- all call priority SS emlpp SS-Code ::= '10100001'B -- enhanced Multilevel Precedence Pre-emption (EMLPP) service allLCSPrivacyException SS-Code ::= '10110000'B -- all LCS Privacy Exception Classes universal SS-Code ::= '10110001'B -- allow location by any LCS client callSessionRelated SS-Code ::= '10110010'B -- allow location by any value added LCS client to which a call/session -- is established from the target MS callSessionUnrelated SS-Code ::= '10110011'B -- allow location by designated external value added LCS clients plmnoperator SS-Code ::= '10110100'B -- allow location by designated PLMN operator LCS clients serviceType SS-Code ::= '10110101'B -- allow location by LCS clients of a designated LCS service type allMOLR-SS SS-Code ::= '11000000'B -- all Mobile Originating Location Request Classes basicSelfLocation SS-Code ::= '11000001'B -- allow an MS to request its own location autonomousSelfLocation SS-Code ::= '11000010'B -- allow an MS to perform self location without interaction -- with the PLMN for a predetermined period of time transferToThirdParty SS-Code ::= '11000011'B -- allow an MS to request transfer of its location to another LCS client .#END 17.7.6 Short message data types .$MAP-SM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RoutingInfoForSM-Arg, RoutingInfoForSM-Res, MO-ForwardSM-Arg, MO-ForwardSM-Res, MT-ForwardSM-Arg, MT-ForwardSM-Res, ReportSM-DeliveryStatusArg, ReportSM-DeliveryStatusRes, AlertServiceCentreArg, InformServiceCentreArg, ReadyForSM-Arg, ReadyForSM-Res, SM-DeliveryOutcome, AlertReason, Additional-Number, MT-ForwardSM-VGCS-Arg, MT-ForwardSM-VGCS-Res ; IMPORTS AddressString, ISDN-AddressString, SignalInfo, IMSI, LMSI, ASCI-CallReference, Time, NetworkNodeDiameterAddress, HLR-Id FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} AbsentSubscriberDiagnosticSM FROM MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; RoutingInfoForSM-Arg ::= SEQUENCE { msisdn [0] ISDN-AddressString, sm-RP-PRI [1] BOOLEAN, serviceCentreAddress [2] AddressString, extensionContainer [6] ExtensionContainer OPTIONAL, ... , gprsSupportIndicator [7] NULL OPTIONAL, -- gprsSupportIndicator is set only if the SMS-GMSC supports -- receiving of two numbers from the HLR sm-RP-MTI [8] SM-RP-MTI OPTIONAL, sm-RP-SMEA [9] SM-RP-SMEA OPTIONAL, sm-deliveryNotIntended [10] SM-DeliveryNotIntended OPTIONAL, ip-sm-gwGuidanceIndicator [11] NULL OPTIONAL, imsi [12] IMSI OPTIONAL, t4-Trigger-Indicator [14] NULL OPTIONAL, singleAttemptDelivery [13] NULL OPTIONAL, correlationID [15] CorrelationID OPTIONAL, smsf-supportIndicator [16] NULL OPTIONAL } SM-DeliveryNotIntended ::= ENUMERATED { onlyIMSI-requested (0), onlyMCC-MNC-requested (1), ...} SM-RP-MTI ::= INTEGER (0..10) -- 0 SMS Deliver -- 1 SMS Status Report -- other values are reserved for future use and shall be discarded if -- received SM-RP-SMEA ::= OCTET STRING (SIZE (1..12)) -- this parameter contains an address field which is encoded -- as defined in 3GPP TS 23.040. An address field contains 3 elementsÊ: -- address-length -- type-of-address -- address-value RoutingInfoForSM-Res ::= SEQUENCE { imsi IMSI, locationInfoWithLMSI [0] LocationInfoWithLMSI, extensionContainer [4] ExtensionContainer OPTIONAL, ..., ip-sm-gwGuidance [5] IP-SM-GW-Guidance OPTIONAL } IP-SM-GW-Guidance ::= SEQUENCE { minimumDeliveryTimeValue SM-DeliveryTimerValue, recommendedDeliveryTimeValue SM-DeliveryTimerValue, extensionContainer ExtensionContainer OPTIONAL, ...} LocationInfoWithLMSI ::= SEQUENCE { networkNode-Number [1] ISDN-AddressString, lmsi LMSI OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., gprsNodeIndicator [5] NULL OPTIONAL, -- gprsNodeIndicator is set only if the SGSN number is sent as the -- Network Node Number additional-Number [6] Additional-Number OPTIONAL, networkNodeDiameterAddress [7] NetworkNodeDiameterAddress OPTIONAL, additionalNetworkNodeDiameterAddress [8] NetworkNodeDiameterAddress OPTIONAL, thirdNumber [9] Additional-Number OPTIONAL, thirdNetworkNodeDiameterAddress [10] NetworkNodeDiameterAddress OPTIONAL, imsNodeIndicator [11] NULL OPTIONAL, -- gprsNodeIndicator and imsNodeIndicator shall not both be present. -- additionalNumber and thirdNumber shall not both contain the same type of number. smsf-3gpp-Number [12] ISDN-AddressString OPTIONAL, smsf-3gpp-DiameterAddress [13] NetworkNodeDiameterAddress OPTIONAL, smsf-non-3gpp-Number [14] ISDN-AddressString OPTIONAL, smsf-non-3gpp-DiameterAddress [15] NetworkNodeDiameterAddress OPTIONAL, smsf-3gpp-address-indicator [16] NULL OPTIONAL, smsf-non-3gpp-address-indicator [17] NULL OPTIONAL -- -- If smsf-supportIndicator was not included in the request, in RoutingInfoForSM-Arg, -- then smsf-3gpp Number/DiameterAddress, smsf-non-3gpp Number/DiameterAddress and -- smsf-address-indicator and smsf-non-3gpp-address-indicator shall be absent. -- -- If smsf-3gpp-address-indicator is present, it indicates that the networkNode-Number -- (and networkNodeDiameterAddress, if present) contains the address of an SMSF for -- 3GPP access. -- -- If smsf-non-3gpp-address-indicator is present, it indicates that the -- networkNode-Number (and networkNodeDiameterAddress, if present) contains the -- address of an SMSF for non 3GPP access. -- -- At most one of gprsNodeIndicator, imsNodeIndicator, smsf-3gpp-address-indicator -- and smsf-non-3gpp-address-indicator shall be present. Absence of all these -- indicators indicate that the networkNode-Number (and networkNodeDiameterAddress, -- if present) contains the address of an MSC/MME. } Additional-Number ::= CHOICE { msc-Number [0] ISDN-AddressString, sgsn-Number [1] ISDN-AddressString} -- msc-number can be the MSC number or -- the SMS Router number or the MME number for MT SMS -- sgsn-number can be the SGSN number or the SMS Router number MO-ForwardSM-Arg ::= SEQUENCE { sm-RP-DA SM-RP-DA, sm-RP-OA SM-RP-OA, sm-RP-UI SignalInfo, extensionContainer ExtensionContainer OPTIONAL, ... , imsi IMSI OPTIONAL, correlationID [0] CorrelationID OPTIONAL, sm-DeliveryOutcome [1] SM-DeliveryOutcome OPTIONAL } MO-ForwardSM-Res ::= SEQUENCE { sm-RP-UI SignalInfo OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} MT-ForwardSM-Arg ::= SEQUENCE { sm-RP-DA SM-RP-DA, sm-RP-OA SM-RP-OA, sm-RP-UI SignalInfo, moreMessagesToSend NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., smDeliveryTimer SM-DeliveryTimerValue OPTIONAL, smDeliveryStartTime Time OPTIONAL, smsOverIP-OnlyIndicator [0] NULL OPTIONAL, correlationID [1] CorrelationID OPTIONAL, maximumRetransmissionTime [2] Time OPTIONAL, smsGmscAddress [3] ISDN-AddressString OPTIONAL, smsGmscDiameterAddress [4] NetworkNodeDiameterAddress OPTIONAL } -- SM-DeliveryTimerValue contains the value used by the SMS-GMSC CorrelationID ::= SEQUENCE { hlr-id [0] HLR-Id OPTIONAL, sip-uri-A [1] SIP-URI OPTIONAL, sip-uri-B [2] SIP-URI} SIP-URI ::= OCTET STRING -- octets are coded as defined in IETF RFCÊ3261Ê MT-ForwardSM-Res ::= SEQUENCE { sm-RP-UI SignalInfo OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... } SM-RP-DA ::= CHOICE { imsi [0] IMSI, lmsi [1] LMSI, serviceCentreAddressDA [4] AddressString, noSM-RP-DA [5] NULL} SM-RP-OA ::= CHOICE { msisdn [2] ISDN-AddressString, serviceCentreAddressOA [4] AddressString, noSM-RP-OA [5] NULL} SM-DeliveryTimerValue ::= INTEGER (30..600) ReportSM-DeliveryStatusArg ::= SEQUENCE { msisdn ISDN-AddressString, serviceCentreAddress AddressString, sm-DeliveryOutcome SM-DeliveryOutcome, absentSubscriberDiagnosticSM [0] AbsentSubscriberDiagnosticSM OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ..., gprsSupportIndicator [2] NULL OPTIONAL, -- gprsSupportIndicator is set only if the SMS-GMSC supports -- handling of two delivery outcomes deliveryOutcomeIndicator [3] NULL OPTIONAL, -- DeliveryOutcomeIndicator is set when the SM-DeliveryOutcome -- is for GPRS additionalSM-DeliveryOutcome [4] SM-DeliveryOutcome OPTIONAL, -- If received, additionalSM-DeliveryOutcome is for GPRS -- If DeliveryOutcomeIndicator is set, then AdditionalSM-DeliveryOutcome shall be absent additionalAbsentSubscriberDiagnosticSM [5] AbsentSubscriberDiagnosticSM OPTIONAL, -- If received additionalAbsentSubscriberDiagnosticSM is for GPRS -- If DeliveryOutcomeIndicator is set, then AdditionalAbsentSubscriberDiagnosticSM -- shall be absent ip-sm-gw-Indicator [6] NULL OPTIONAL, -- the ip-sm-gw indicator indicates by its presence that sm-deliveryOutcome -- is for delivery via IMS -- If present, deliveryOutcomeIndicator shall be absent. ip-sm-gw-sm-deliveryOutcome [7] SM-DeliveryOutcome OPTIONAL, -- If received ip-sm-gw-sm-deliveryOutcome is for delivery via IMS -- If ip-sm-gw-Indicator is set, then ip-sm-gw-sm-deliveryOutcome shall be absent ip-sm-gw-absentSubscriberDiagnosticSM [8] AbsentSubscriberDiagnosticSM OPTIONAL, -- If received ip-sm-gw-sm-absentSubscriberDiagnosticSM is for delivery via IMS -- If ip-sm-gw-Indicator is set, then ip-sm-gw-sm-absentSubscriberDiagnosticSM -- shall be absent imsi [9] IMSI OPTIONAL, singleAttemptDelivery [10] NULL OPTIONAL, correlationID [11] CorrelationID OPTIONAL, smsf-3gpp-deliveryOutcomeIndicator [12] NULL OPTIONAL, -- smsf-3gpp-deliveryOutcome is set when the SM-DeliveryOutcome -- is for 3GPP-SMSF smsf-3gpp-deliveryOutcome [13] SM-DeliveryOutcome OPTIONAL, -- If smsf-3gpp-deliveryOutcomeIndicator is set, then smsf-3gpp-deliveryOutcome -- shall be absent smsf-3gpp-absentSubscriberDiagSM [14] AbsentSubscriberDiagnosticSM OPTIONAL, -- If smsf-3gpp-deliveryOutcomeIndicator is set, then -- smsf-3gpp-absentSubscriberDiagSM shall be absent smsf-non-3gpp-deliveryOutcomeIndicator [15] NULL OPTIONAL, -- smsf-non-3gpp-deliveryOutcomeIndicator is set when the SM-DeliveryOutcome -- is for non-3GPP-SMSF smsf-non-3gpp-deliveryOutcome [16] SM-DeliveryOutcome OPTIONAL, -- If smsf-non-3gpp-deliveryOutcomeIndicator is set, then smsf-non-3gpp-deliveryOutcome -- shall be absent smsf-non-3gpp-absentSubscriberDiagSM [17] AbsentSubscriberDiagnosticSM OPTIONAL -- If smsf-non-3gpp-deliveryOutcomeIndicator is set, then -- smsf-non-3gpp-absentSubscriberDiagSM shall be absent } SM-DeliveryOutcome ::= ENUMERATED { memoryCapacityExceeded (0), absentSubscriber (1), successfulTransfer (2)} ReportSM-DeliveryStatusRes ::= SEQUENCE { storedMSISDN ISDN-AddressString OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} AlertServiceCentreArg ::= SEQUENCE { msisdn ISDN-AddressString, serviceCentreAddress AddressString, ..., imsi IMSI OPTIONAL, correlationID CorrelationID OPTIONAL, maximumUeAvailabilityTime [0] Time OPTIONAL, smsGmscAlertEvent [1] SmsGmsc-Alert-Event OPTIONAL, smsGmscDiameterAddress [2] NetworkNodeDiameterAddress OPTIONAL, newSGSNNumber [3] ISDN-AddressString OPTIONAL, newSGSNDiameterAddress [4] NetworkNodeDiameterAddress OPTIONAL, newMMENumber [5] ISDN-AddressString OPTIONAL, newMMEDiameterAddress [6] NetworkNodeDiameterAddress OPTIONAL, newMSCNumber [7] ISDN-AddressString OPTIONAL } SmsGmsc-Alert-Event ::= ENUMERATED { msAvailableForMtSms (0), msUnderNewServingNode (1) } InformServiceCentreArg ::= SEQUENCE { storedMSISDN ISDN-AddressString OPTIONAL, mw-Status MW-Status OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , absentSubscriberDiagnosticSM AbsentSubscriberDiagnosticSM OPTIONAL, additionalAbsentSubscriberDiagnosticSM [0] AbsentSubscriberDiagnosticSM OPTIONAL, -- additionalAbsentSubscriberDiagnosticSM may be present only if -- absentSubscriberDiagnosticSM is present. -- if included, additionalAbsentSubscriberDiagnosticSM is for GPRS and -- absentSubscriberDiagnosticSM is for non-GPRS smsf3gppAbsentSubscriberDiagnosticSM [1] AbsentSubscriberDiagnosticSM OPTIONAL, smsfNon3gppAbsentSubscriberDiagnosticSM [2] AbsentSubscriberDiagnosticSM OPTIONAL } MW-Status ::= BIT STRING { sc-AddressNotIncluded (0), mnrf-Set (1), mcef-Set (2) , mnrg-Set (3), mnr5g-Set (4), mnr5gn3g-Set (5)} (SIZE (6..16)) -- exception handling: -- bits 6 to 15 shall be ignored if received and not understood ReadyForSM-Arg ::= SEQUENCE { imsi [0] IMSI, alertReason AlertReason, alertReasonIndicator NULL OPTIONAL, -- alertReasonIndicator is set only when the alertReason -- sent to HLR is for GPRS extensionContainer ExtensionContainer OPTIONAL, ..., additionalAlertReasonIndicator [1] NULL OPTIONAL, -- additionalAlertReasonIndicator is set only when the alertReason -- sent to HLR is for IP-SM-GW maximumUeAvailabilityTime Time OPTIONAL } ReadyForSM-Res ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} AlertReason ::= ENUMERATED { ms-Present (0), memoryAvailable (1)} MT-ForwardSM-VGCS-Arg ::= SEQUENCE { asciCallReference ASCI-CallReference, sm-RP-OA SM-RP-OA, sm-RP-UI SignalInfo, extensionContainer ExtensionContainer OPTIONAL, ...} MT-ForwardSM-VGCS-Res ::= SEQUENCE { sm-RP-UI [0] SignalInfo OPTIONAL, dispatcherList [1] DispatcherList OPTIONAL, ongoingCall NULL OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., additionalDispatcherList [3] AdditionalDispatcherList OPTIONAL } -- additionalDispatcherList shall be absent if dispatcherList is absent or -- contains less than 5 ISDN-AddressStrings DispatcherList ::= SEQUENCE SIZE (1..maxNumOfDispatchers) OF ISDN-AddressString maxNumOfDispatchers INTEGER ::= 5 AdditionalDispatcherList ::= SEQUENCE SIZE (1..maxNumOfAdditionalDispatchers) OF ISDN-AddressString maxNumOfAdditionalDispatchers INTEGER ::= 15 .#END 17.7.7 Error data types .$MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RoamingNotAllowedParam, CallBarredParam, CUG-RejectParam, SS-IncompatibilityCause, PW-RegistrationFailureCause, SM-DeliveryFailureCause, SystemFailureParam, DataMissingParam, UnexpectedDataParam, FacilityNotSupParam, OR-NotAllowedParam, UnknownSubscriberParam, NumberChangedParam, UnidentifiedSubParam, IllegalSubscriberParam, IllegalEquipmentParam, BearerServNotProvParam, TeleservNotProvParam, TracingBufferFullParam, NoRoamingNbParam, AbsentSubscriberParam, BusySubscriberParam, NoSubscriberReplyParam, ForwardingViolationParam, ForwardingFailedParam, ATI-NotAllowedParam, SubBusyForMT-SMS-Param, MessageWaitListFullParam, AbsentSubscriberSM-Param, AbsentSubscriberDiagnosticSM, ResourceLimitationParam, NoGroupCallNbParam, IncompatibleTerminalParam, ShortTermDenialParam, LongTermDenialParam, UnauthorizedRequestingNetwork-Param, UnauthorizedLCSClient-Param, PositionMethodFailure-Param, UnknownOrUnreachableLCSClient-Param, MM-EventNotSupported-Param, ATSI-NotAllowedParam, ATM-NotAllowedParam, IllegalSS-OperationParam, SS-NotAvailableParam, SS-SubscriptionViolationParam, InformationNotAvailableParam, TargetCellOutsideGCA-Param, OngoingGroupCallParam, PositionMethodFailure-Diagnostic, UnauthorizedLCSClient-Diagnostic ; IMPORTS SS-Status FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} SignalInfo, BasicServiceCode, NetworkResource, AdditionalNetworkResource, IMSI, Time FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; RoamingNotAllowedParam ::= SEQUENCE { roamingNotAllowedCause RoamingNotAllowedCause, extensionContainer ExtensionContainer OPTIONAL, ..., additionalRoamingNotAllowedCause [0] AdditionalRoamingNotAllowedCause OPTIONAL } -- if the additionalRoamingNotallowedCause is received by the MSC/VLR or SGSN then the -- roamingNotAllowedCause shall be discarded. AdditionalRoamingNotAllowedCause ::= ENUMERATED { supportedRAT-TypesNotAllowed (0), ...} RoamingNotAllowedCause ::= ENUMERATED { plmnRoamingNotAllowed (0), operatorDeterminedBarring (3)} CallBarredParam ::= CHOICE { callBarringCause CallBarringCause, -- call BarringCause must not be used in version 3 and higher extensibleCallBarredParam ExtensibleCallBarredParam -- extensibleCallBarredParam must not be used in version <3 } CallBarringCause ::= ENUMERATED { barringServiceActive (0), operatorBarring (1)} ExtensibleCallBarredParam ::= SEQUENCE { callBarringCause CallBarringCause OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , unauthorisedMessageOriginator [1] NULL OPTIONAL, anonymousCallRejection [2] NULL OPTIONAL } -- unauthorisedMessageOriginator and anonymousCallRejection shall be mutually exclusive. CUG-RejectParam ::= SEQUENCE { cug-RejectCause CUG-RejectCause OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} CUG-RejectCause ::= ENUMERATED { incomingCallsBarredWithinCUG (0), subscriberNotMemberOfCUG (1), requestedBasicServiceViolatesCUG-Constraints (5), calledPartySS-InteractionViolation (7)} SS-IncompatibilityCause ::= SEQUENCE { ss-Code [1] SS-Code OPTIONAL, basicService BasicServiceCode OPTIONAL, ss-Status [4] SS-Status OPTIONAL, ...} PW-RegistrationFailureCause ::= ENUMERATED { undetermined (0), invalidFormat (1), newPasswordsMismatch (2)} SM-EnumeratedDeliveryFailureCause ::= ENUMERATED { memoryCapacityExceeded (0), equipmentProtocolError (1), equipmentNotSM-Equipped (2), unknownServiceCentre (3), sc-Congestion (4), invalidSME-Address (5), subscriberNotSC-Subscriber (6)} SM-DeliveryFailureCause ::= SEQUENCE { sm-EnumeratedDeliveryFailureCause SM-EnumeratedDeliveryFailureCause, diagnosticInfo SignalInfo OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} AbsentSubscriberSM-Param ::= SEQUENCE { absentSubscriberDiagnosticSM AbsentSubscriberDiagnosticSM OPTIONAL, -- AbsentSubscriberDiagnosticSM can be either for non-GPRS -- or for GPRS extensionContainer ExtensionContainer OPTIONAL, ..., additionalAbsentSubscriberDiagnosticSM [0] AbsentSubscriberDiagnosticSM OPTIONAL, -- if received, additionalAbsentSubscriberDiagnosticSM -- is for GPRS and absentSubscriberDiagnosticSM is -- for non-GPRS imsi [1] IMSI OPTIONAL, -- when sent from HLR to IP-SM-GW, IMSI shall be present if UNRI is not set -- to indicate that the absent condition is met for CS and PS but not for IMS. requestedRetransmissionTime [2] Time OPTIONAL, userIdentifierAlert [3] IMSI OPTIONAL } AbsentSubscriberDiagnosticSM ::= INTEGER (0..255) -- AbsentSubscriberDiagnosticSM values are defined in 3GPP TS 23.040 SystemFailureParam ::= CHOICE { networkResource NetworkResource, -- networkResource must not be used in version 3 extensibleSystemFailureParam ExtensibleSystemFailureParam -- extensibleSystemFailureParam must not be used in version <3 } ExtensibleSystemFailureParam ::= SEQUENCE { networkResource NetworkResource OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., additionalNetworkResource [0] AdditionalNetworkResource OPTIONAL, failureCauseParam [1] FailureCauseParam OPTIONAL } FailureCauseParam ::= ENUMERATED { limitReachedOnNumberOfConcurrentLocationRequests (0), ... } -- if unknown value is received in FailureCauseParam it shall be ignored DataMissingParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} UnexpectedDataParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., unexpectedSubscriber [0] NULL OPTIONAL} -- the unexpectedSubscriber indication in the unexpectedDataValue error shall not be used -- for operations that allow the unidentifiedSubscriber error. FacilityNotSupParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., shapeOfLocationEstimateNotSupported [0] NULL OPTIONAL, neededLcsCapabilityNotSupportedInServingNode [1] NULL OPTIONAL } OR-NotAllowedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} UnknownSubscriberParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., unknownSubscriberDiagnostic UnknownSubscriberDiagnostic OPTIONAL} UnknownSubscriberDiagnostic ::= ENUMERATED { imsiUnknown (0), gprs-eps-SubscriptionUnknown (1), ..., npdbMismatch (2)} -- if unknown values are received in -- UnknownSubscriberDiagnostic they shall be discarded NumberChangedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} UnidentifiedSubParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} IllegalSubscriberParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} IllegalEquipmentParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} BearerServNotProvParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} TeleservNotProvParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} TracingBufferFullParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} NoRoamingNbParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} AbsentSubscriberParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., absentSubscriberReason [0] AbsentSubscriberReason OPTIONAL} AbsentSubscriberReason ::= ENUMERATED { imsiDetach (0), restrictedArea (1), noPageResponse (2), ... , purgedMS (3), mtRoamingRetry (4), busySubscriber (5)} -- exception handling: at reception of other values than the ones listed the -- AbsentSubscriberReason shall be ignored. -- The AbsentSubscriberReason: purgedMS is defined for the Super-Charger feature -- (see TS 23.116). If this value is received in a Provide Roaming Number response -- it shall be mapped to the AbsentSubscriberReason: imsiDetach in the Send Routeing -- Information response -- The AbsentSubscriberReason: mtRoamingRetry is used during MT Roaming Retry, -- see 3GPP TS 23.018[97]. -- The AbsentSubscriberReason: busySubscriber is used during MT Roaming Forwarding, -- see 3GPP TS 23.018[97]. BusySubscriberParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., ccbs-Possible [0] NULL OPTIONAL, ccbs-Busy [1] NULL OPTIONAL} NoSubscriberReplyParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ForwardingViolationParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ForwardingFailedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ATI-NotAllowedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ATSI-NotAllowedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ATM-NotAllowedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} IllegalSS-OperationParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} SS-NotAvailableParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} SS-SubscriptionViolationParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} InformationNotAvailableParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} SubBusyForMT-SMS-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ... , gprsConnectionSuspended NULL OPTIONAL } -- If GprsConnectionSuspended is not understood it shall -- be discarded MessageWaitListFullParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ResourceLimitationParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} NoGroupCallNbParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} IncompatibleTerminalParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ShortTermDenialParam ::= SEQUENCE { ...} LongTermDenialParam ::= SEQUENCE { ...} UnauthorizedRequestingNetwork-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} UnauthorizedLCSClient-Param ::= SEQUENCE { unauthorizedLCSClient-Diagnostic [0] UnauthorizedLCSClient-Diagnostic OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... } UnauthorizedLCSClient-Diagnostic ::= ENUMERATED { noAdditionalInformation (0), clientNotInMSPrivacyExceptionList (1), callToClientNotSetup (2), privacyOverrideNotApplicable (3), disallowedByLocalRegulatoryRequirements (4), ..., unauthorizedPrivacyClass (5), unauthorizedCallSessionUnrelatedExternalClient (6), unauthorizedCallSessionRelatedExternalClient (7) } -- exception handling: -- any unrecognized value shall be ignored PositionMethodFailure-Param ::= SEQUENCE { positionMethodFailure-Diagnostic [0] PositionMethodFailure-Diagnostic OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... } PositionMethodFailure-Diagnostic ::= ENUMERATED { congestion (0), insufficientResources (1), insufficientMeasurementData (2), inconsistentMeasurementData (3), locationProcedureNotCompleted (4), locationProcedureNotSupportedByTargetMS (5), qoSNotAttainable (6), positionMethodNotAvailableInNetwork (7), positionMethodNotAvailableInLocationArea (8), ... } -- exception handling: -- any unrecognized value shall be ignored UnknownOrUnreachableLCSClient-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} MM-EventNotSupported-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} TargetCellOutsideGCA-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} OngoingGroupCallParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} .#END 17.7.8 Common data types .$MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS -- general data types and values AddressString, ISDN-AddressString, maxISDN-AddressLength, FTN-AddressString, ISDN-SubaddressString, ExternalSignalInfo, Ext-ExternalSignalInfo, AccessNetworkSignalInfo, SignalInfo, maxSignalInfoLength, AlertingPattern, TBCD-STRING, DiameterIdentity, Time, HLR-Id, -- data types for numbering and identification IMSI, TMSI, Identity, SubscriberId, IMEI, HLR-List, LMSI, GlobalCellId, NetworkResource, AdditionalNetworkResource, NAEA-PreferredCI, NAEA-CIC, ASCI-CallReference, SubscriberIdentity, PLMN-Id, E-UTRAN-CGI, NR-CGI, TA-Id, NR-TA-Id, RAIdentity, NetworkNodeDiameterAddress, -- data types for CAMEL CellGlobalIdOrServiceAreaIdOrLAI, CellGlobalIdOrServiceAreaIdFixedLength, LAIFixedLength, -- data types for subscriber management BasicServiceCode, Ext-BasicServiceCode, EMLPP-Info, EMLPP-Priority, MC-SS-Info, MaxMC-Bearers, MC-Bearers, Ext-SS-Status, -- data types for geographic location AgeOfLocationInformation, LCSClientExternalID, LCSClientInternalID, LCSServiceTypeID, -- gprs location registration types GSN-Address ; IMPORTS TeleserviceCode, Ext-TeleserviceCode FROM MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-TS-Code (19) version20 (20)} BearerServiceCode, Ext-BearerServiceCode FROM MAP-BS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-BS-Code (20) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; -- general data types TBCD-STRING ::= OCTET STRING -- This type (Telephony Binary Coded Decimal String) is used to -- represent several digits from 0 through 9, *, #, a, b, c, two -- digits per octet, each digit encoded 0000 to 1001 (0 to 9), -- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used -- as filler when there is an odd number of digits. -- bits 8765 of octet n encoding digit 2n -- bits 4321 of octet n encoding digit 2(n-1) +1 DiameterIdentity ::= OCTET STRING (SIZE(9..255)) -- content of DiameterIdentity is defined in IETF RFC 3588 [139] AddressString ::= OCTET STRING (SIZE (1..maxAddressLength)) -- This type is used to represent a number for addressing -- purposes. It is composed of -- a) one octet for nature of address, and numbering plan -- indicator. -- b) digits of an address encoded as TBCD-String. -- a) The first octet includes a one bit extension indicator, a -- 3 bits nature of address indicator and a 4 bits numbering -- plan indicator, encoded as follows: -- bit 8: 1 (no extension) -- bits 765: nature of address indicator -- 000 unknown -- 001 international number -- 010 national significant number -- 011 network specific number -- 100 subscriber number -- 101 reserved -- 110 abbreviated number -- 111 reserved for extension -- bits 4321: numbering plan indicator -- 0000 unknown -- 0001 ISDN/Telephony Numbering Plan (Rec ITU-T E.164) -- 0010 spare -- 0011 data numbering plan (ITU-T Rec X.121) -- 0100 telex numbering plan (ITU-T Rec F.69) -- 0101 spare -- 0110 land mobile numbering plan (ITU-T Rec E.212) -- 0111 spare -- 1000 national numbering plan -- 1001 private numbering plan -- 1111 reserved for extension -- all other values are reserved. -- b) The following octets representing digits of an address -- encoded as a TBCD-STRING. maxAddressLength INTEGER ::= 20 ISDN-AddressString ::= AddressString (SIZE (1..maxISDN-AddressLength)) -- This type is used to represent ISDN numbers. maxISDN-AddressLength INTEGER ::= 9 FTN-AddressString ::= AddressString (SIZE (1..maxFTN-AddressLength)) -- This type is used to represent forwarded-to numbers. -- If NAI = international the first digits represent the country code (CC) -- and the network destination code (NDC) as for E.164. maxFTN-AddressLength INTEGER ::= 15 ISDN-SubaddressString ::= OCTET STRING (SIZE (1..maxISDN-SubaddressLength)) -- This type is used to represent ISDN subaddresses. -- It is composed of -- a) one octet for type of subaddress and odd/even indicator. -- b) 20 octets for subaddress information. -- a) The first octet includes a one bit extension indicator, a -- 3 bits type of subaddress and a one bit odd/even indicator, -- encoded as follows: -- bit 8: 1 (no extension) -- bits 765: type of subaddress -- 000 NSAP (X.213/ISO 8348 AD2) -- 010 User Specified -- All other values are reserved -- bit 4: odd/even indicator -- 0 even number of address signals -- 1 odd number of address signals -- The odd/even indicator is used when the type of subaddress -- is ""user specified"" and the coding is BCD. -- bits 321: 000 (unused) -- b) Subaddress information. -- The NSAP X.213/ISO8348AD2 address shall be formatted as specified -- by octet 4 which contains the Authority and Format Identifier -- (AFI). The encoding is made according to the ""preferred binary -- encoding"" as defined in X.213/ISO834AD2. For the definition -- of this type of subaddress, see ITU-T Rec I.334. -- For User-specific subaddress, this field is encoded according -- to the user specification, subject to a maximum length of 20 -- octets. When interworking with X.25 networks BCD coding should -- be applied. maxISDN-SubaddressLength INTEGER ::= 21 ExternalSignalInfo ::= SEQUENCE { protocolId ProtocolId, signalInfo SignalInfo, -- Information about the internal structure is given in -- clauseÊ7.6.9. extensionContainer ExtensionContainer OPTIONAL, -- extensionContainer must not be used in version 2 ...} SignalInfo ::= OCTET STRING (SIZE (1..maxSignalInfoLength)) maxSignalInfoLength INTEGER ::= 200 -- This NamedValue represents the theoretical maximum number of octets which is -- available to carry a single instance of the SignalInfo data type, -- without requiring segmentation to cope with the network layer service. -- However, the actual maximum size available for an instance of the data -- type may be lower, especially when other information elements -- have to be included in the same component."
"ProtocolId ::= ENUMERATED { gsm-0408 (1), gsm-0806 (2), gsm-BSSMAP (3), -- Value 3 is reserved and must not be used ets-300102-1 (4)} Ext-ExternalSignalInfo ::= SEQUENCE { ext-ProtocolId Ext-ProtocolId, signalInfo SignalInfo, -- Information about the internal structure is given in -- clauseÊ7.6.9.10 extensionContainer ExtensionContainer OPTIONAL, ...} Ext-ProtocolId ::= ENUMERATED { ets-300356 (1), ... } -- exception handling: -- For Ext-ExternalSignalInfo sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- Ext-ExternalSignalInfo sequence. AccessNetworkSignalInfo ::= SEQUENCE { accessNetworkProtocolId AccessNetworkProtocolId, signalInfo LongSignalInfo, -- Information about the internal structure is given in clauseÊ7.6.9.1 extensionContainer ExtensionContainer OPTIONAL, ...} LongSignalInfo ::= OCTET STRING (SIZE (1..maxLongSignalInfoLength)) maxLongSignalInfoLength INTEGER ::= 2560 -- This Named Value represents the maximum number of octets which is available -- to carry a single instance of the LongSignalInfo data type using -- White Book SCCP with the maximum number of segments. -- It takes account of the octets used by the lower layers of the protocol, and -- other information elements which may be included in the same component. AccessNetworkProtocolId ::= ENUMERATED { ts3G-48006 (1), ts3G-25413 (2), ...} -- exception handling: -- For AccessNetworkSignalInfo sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- AccessNetworkSignalInfo sequence. AlertingPattern ::= OCTET STRING (SIZE (1) ) -- This type is used to represent Alerting Pattern -- bits 8765Ê: 0000 (unused) -- bits 43Ê: type of Pattern -- 00 level -- 01 category -- 10 category -- all other values are reserved. -- bits 21Ê: type of alerting alertingLevel-0 AlertingPatternÊ::= '00000000'B alertingLevel-1 AlertingPatternÊ::= '00000001'B alertingLevel-2 AlertingPatternÊ::= '00000010'B -- all other values of Alerting level are reserved -- Alerting Levels are defined in GSM 02.07 alertingCategory-1 AlertingPatternÊ::= '00000100'B alertingCategory-2 AlertingPatternÊ::= '00000101'B alertingCategory-3 AlertingPatternÊ::= '00000110'B alertingCategory-4 AlertingPatternÊ::= '00000111'B alertingCategory-5 AlertingPatternÊ::= '00001000'B -- all other values of Alerting Category are reserved -- Alerting categories are defined in GSM 02.07 GSN-Address ::= OCTET STRING (SIZE (5..17)) -- Octets are coded according to TS 3GPP TS 23.003 [17] Time ::= OCTET STRING (SIZE (4)) -- Octets are coded according to IETF RFC 3588 [139] -- data types for numbering and identification IMSI ::= TBCD-STRING (SIZE (3..8)) -- digits of MCC, MNC, MSIN are concatenated in this order. Identity ::= CHOICE { imsi IMSI, imsi-WithLMSI IMSI-WithLMSI} IMSI-WithLMSI ::= SEQUENCE { imsi IMSI, lmsi LMSI, -- a special value 00000000 indicates that the LMSI is not in use ...} ASCI-CallReference ::= TBCD-STRING (SIZE (1..8)) -- digits of VGCS/VBS-area,Group-ID are concatenated in this order if there is a -- VGCS/VBS-area. TMSI ::= OCTET STRING (SIZE (1..4)) SubscriberId ::= CHOICE { imsi [0] IMSI, tmsi [1] TMSI} IMEI ::= TBCD-STRING (SIZE (8)) -- Refers to International Mobile Station Equipment Identity -- and Software Version Number (SVN) defined in TS 3GPP TS 23.003 [17]. -- If the SVN is not present the last octet shall contain the -- digit 0 and a filler. -- If present the SVN shall be included in the last octet. HLR-Id ::= IMSI -- leading digits of IMSI, i.e. (MCC, MNC, leading digits of -- MSIN) forming HLR Id defined in TS 3GPP TS 23.003 [17]. HLR-List ::= SEQUENCE SIZE (1..maxNumOfHLR-Id) OF HLR-Id maxNumOfHLR-Id INTEGER ::= 50 LMSI ::= OCTET STRING (SIZE (4)) GlobalCellId ::= OCTET STRING (SIZE (5..7)) -- Refers to Cell Global Identification defined in TS 3GPP TS 23.003 [17]. -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code according to TS 3GPP TS 24.008 [35] -- octets 6 and 7 Cell Identity (CI) according to TS 3GPP TS 24.008 [35] NetworkResource ::= ENUMERATED { plmn (0), hlr (1), vlr (2), pvlr (3), controllingMSC (4), vmsc (5), eir (6), rss (7)} AdditionalNetworkResource ::= ENUMERATED { sgsn (0), ggsn (1), gmlc (2), gsmSCF (3), nplr (4), auc (5), ... , ue (6), mme (7)} -- if unknown value is received in AdditionalNetworkResource -- it shall be ignored. NAEA-PreferredCI ::= SEQUENCE { naea-PreferredCIC [0] NAEA-CIC, extensionContainer [1] ExtensionContainer OPTIONAL, ...} NAEA-CIC ::= OCTET STRING (SIZE (3)) -- The internal structure is defined by the Carrier Identification -- parameter in ANSI T1.113.3. Carrier codes between ""000"" and ""999"" may -- be encoded as 3 digits using ""000"" to ""999"" or as 4 digits using -- ""0000"" to ""0999"". Carrier codes between ""1000"" and ""9999"" are encoded -- using 4 digits. SubscriberIdentity ::= CHOICE { imsi [0] IMSI, msisdn [1] ISDN-AddressString } LCSClientExternalID ::= SEQUENCE { externalAddress [0] ISDN-AddressString OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... } LCSClientInternalID ::= ENUMERATED { broadcastService (0), o-andM-HPLMN (1), o-andM-VPLMN (2), anonymousLocation (3), targetMSsubscribedService (4), ... } -- for a CAMEL phase 3 PLMN operator client, the value targetMSsubscribedService shall be used LCSServiceTypeID ::= INTEGER (0..127) -- the integer values 0-63 are reserved for Standard LCS service types -- the integer values 64-127 are reserved for Non Standard LCS service types -- Standard LCS Service Types emergencyServices LCSServiceTypeID ::= 0 emergencyAlertServices LCSServiceTypeID ::= 1 personTracking LCSServiceTypeID ::= 2 fleetManagement LCSServiceTypeID ::= 3 assetManagement LCSServiceTypeID ::= 4 trafficCongestionReporting LCSServiceTypeID ::= 5 roadsideAssistance LCSServiceTypeID ::= 6 routingToNearestCommercialEnterprise LCSServiceTypeID ::= 7 navigation LCSServiceTypeID ::= 8 --this service type is reserved for use in previous releases citySightseeing LCSServiceTypeID ::= 9 localizedAdvertising LCSServiceTypeID ::= 10 mobileYellowPages LCSServiceTypeID ::= 11 trafficAndPublicTransportationInfo LCSServiceTypeID ::= 12 weather LCSServiceTypeID ::= 13 assetAndServiceFinding LCSServiceTypeID ::= 14 gaming LCSServiceTypeID ::= 15 findYourFriend LCSServiceTypeID ::= 16 dating LCSServiceTypeID ::= 17 chatting LCSServiceTypeID ::= 18 routeFinding LCSServiceTypeID ::= 19 whereAmI LCSServiceTypeID ::= 20 -- The values of LCSServiceTypeID are defined according to 3GPP TS 22.071. -- Non Standard LCS Service Types serv64 LCSServiceTypeID ::= 64 serv65 LCSServiceTypeID ::= 65 serv66 LCSServiceTypeID ::= 66 serv67 LCSServiceTypeID ::= 67 serv68 LCSServiceTypeID ::= 68 serv69 LCSServiceTypeID ::= 69 serv70 LCSServiceTypeID ::= 70 serv71 LCSServiceTypeID ::= 71 serv72 LCSServiceTypeID ::= 72 serv73 LCSServiceTypeID ::= 73 serv74 LCSServiceTypeID ::= 74 serv75 LCSServiceTypeID ::= 75 serv76 LCSServiceTypeID ::= 76 serv77 LCSServiceTypeID ::= 77 serv78 LCSServiceTypeID ::= 78 serv79 LCSServiceTypeID ::= 79 serv80 LCSServiceTypeID ::= 80 serv81 LCSServiceTypeID ::= 81 serv82 LCSServiceTypeID ::= 82 serv83 LCSServiceTypeID ::= 83 serv84 LCSServiceTypeID ::= 84 serv85 LCSServiceTypeID ::= 85 serv86 LCSServiceTypeID ::= 86 serv87 LCSServiceTypeID ::= 87 serv88 LCSServiceTypeID ::= 88 serv89 LCSServiceTypeID ::= 89 serv90 LCSServiceTypeID ::= 90 serv91 LCSServiceTypeID ::= 91 serv92 LCSServiceTypeID ::= 92 serv93 LCSServiceTypeID ::= 93 serv94 LCSServiceTypeID ::= 94 serv95 LCSServiceTypeID ::= 95 serv96 LCSServiceTypeID ::= 96 serv97 LCSServiceTypeID ::= 97 serv98 LCSServiceTypeID ::= 98 serv99 LCSServiceTypeID ::= 99 serv100 LCSServiceTypeID ::= 100 serv101 LCSServiceTypeID ::= 101 serv102 LCSServiceTypeID ::= 102 serv103 LCSServiceTypeID ::= 103 serv104 LCSServiceTypeID ::= 104 serv105 LCSServiceTypeID ::= 105 serv106 LCSServiceTypeID ::= 106 serv107 LCSServiceTypeID ::= 107 serv108 LCSServiceTypeID ::= 108 serv109 LCSServiceTypeID ::= 109 serv110 LCSServiceTypeID ::= 110 serv111 LCSServiceTypeID ::= 111 serv112 LCSServiceTypeID ::= 112 serv113 LCSServiceTypeID ::= 113 serv114 LCSServiceTypeID ::= 114 serv115 LCSServiceTypeID ::= 115 serv116 LCSServiceTypeID ::= 116 serv117 LCSServiceTypeID ::= 117 serv118 LCSServiceTypeID ::= 118 serv119 LCSServiceTypeID ::= 119 serv120 LCSServiceTypeID ::= 120 serv121 LCSServiceTypeID ::= 121 serv122 LCSServiceTypeID ::= 122 serv123 LCSServiceTypeID ::= 123 serv124 LCSServiceTypeID ::= 124 serv125 LCSServiceTypeID ::= 125 serv126 LCSServiceTypeID ::= 126 serv127 LCSServiceTypeID ::= 127 PLMN-Id ::= OCTET STRING (SIZE (3)) -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit E-UTRAN-CGI ::= OCTET STRING (SIZE (7)) -- Octets are coded as described in 3GPP TS 29.118 [152]. NR-CGI ::= OCTET STRING (SIZE (8)) -- Octets are coded as described in 3GPP TS 38.413 [153]. TA-Id ::= OCTET STRING (SIZE (5)) -- Octets are coded as described in 3GPP TS 29.118 [152]. NR-TA-Id ::= OCTET STRING (SIZE (6)) -- Octets are coded as described in 3GPP TS 38.413 [153]. RAIdentity ::= OCTET STRING (SIZE (6)) -- Routing Area Identity is coded in accordance with 3GPP TS 29.060 [105]. -- It shall contain the value part defined in 3GPP TS 29.060 only. I.e. the 3GPP TS 29.060 -- type identifier octet shall not be included. NetworkNodeDiameterAddress::= SEQUENCE { diameter-Name [0] DiameterIdentity, diameter-Realm [1] DiameterIdentity } -- data types for CAMEL CellGlobalIdOrServiceAreaIdOrLAI ::= CHOICE { cellGlobalIdOrServiceAreaIdFixedLength [0] CellGlobalIdOrServiceAreaIdFixedLength, laiFixedLength [1] LAIFixedLength} CellGlobalIdOrServiceAreaIdFixedLength ::= OCTET STRING (SIZE (7)) -- Refers to Cell Global Identification or Service Are Identification -- defined in 3GPP TS 23.003. -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code according to 3GPP TS 24.008 -- octets 6 and 7 Cell Identity (CI) value or -- Service Area Code (SAC) value -- according to 3GPP TS 23.003 LAIFixedLength ::= OCTET STRING (SIZE (5)) -- Refers to Location Area Identification defined in 3GPP TS 23.003 [17]. -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code according to 3GPP TS 24.008 [35] -- data types for subscriber management BasicServiceCode ::= CHOICE { bearerService [2] BearerServiceCode, teleservice [3] TeleserviceCode} Ext-BasicServiceCode ::= CHOICE { ext-BearerService [2] Ext-BearerServiceCode, ext-Teleservice [3] Ext-TeleserviceCode} EMLPP-Info ::= SEQUENCE { maximumentitledPriority EMLPP-Priority, defaultPriority EMLPP-Priority, extensionContainer ExtensionContainer OPTIONAL, ...} EMLPP-Priority ::= INTEGER (0..15) -- The mapping from the values A,B,0,1,2,3,4 to the integer-value is -- specified as follows where A is the highest and 4 is the lowest -- priority level -- the integer values 7-15 are spare and shall be mapped to value 4 priorityLevelA EMLPP-Priority ::= 6 priorityLevelB EMLPP-Priority ::= 5 priorityLevel0 EMLPP-Priority ::= 0 priorityLevel1 EMLPP-Priority ::= 1 priorityLevel2 EMLPP-Priority ::= 2 priorityLevel3 EMLPP-Priority ::= 3 priorityLevel4 EMLPP-Priority ::= 4 MC-SS-Info ::= SEQUENCE { ss-Code [0] SS-Code, ss-Status [1] Ext-SS-Status, nbrSB [2] MaxMC-Bearers, nbrUser [3] MC-Bearers, extensionContainer [4] ExtensionContainer OPTIONAL, ...} MaxMC-Bearers ::= INTEGER (2..maxNumOfMC-Bearers) MC-Bearers ::= INTEGER (1..maxNumOfMC-Bearers) maxNumOfMC-Bearers INTEGER ::= 7 Ext-SS-Status ::= OCTET STRING (SIZE (1..5)) -- OCTET 1: -- -- bits 8765: 0000 (unused) -- bits 4321: Used to convey the ""P bit"",""R bit"",""A bit"" and ""Q bit"", -- representing supplementary service state information -- as defined in TS 3GPP TS 23.011 [22] -- bit 4: ""Q bit"" -- bit 3: ""P bit"" -- bit 2: ""R bit"" -- bit 1: ""A bit"" -- OCTETS 2-5: reserved for future use. They shall be discarded if -- received and not understood. -- data types for geographic location AgeOfLocationInformation ::= INTEGER (0..32767) -- the value represents the elapsed time in minutes since the last -- network contact of the mobile station (i.e. the actuality of the -- location information). -- value ""0"" indicates that the MS is currently in contact with the -- network -- value ""32767"" indicates that the location information is at least -- 32767 minutes old .#END 17.7.9 Teleservice Codes .$MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-TS-Code (19) version20 (20)} DEFINITIONS ::= BEGIN TeleserviceCode ::= OCTET STRING (SIZE (1)) -- This type is used to represent the code identifying a single -- teleservice, a group of teleservices, or all teleservices. The -- services are defined in TS GSM 22.003 [4]. -- The internal structure is defined as follows: -- bits 87654321: group (bits 8765) and specific service -- (bits 4321) Ext-TeleserviceCode ::= OCTET STRING (SIZE (1..5)) -- This type is used to represent the code identifying a single -- teleservice, a group of teleservices, or all teleservices. The -- services are defined in TS GSM 22.003 [4]. -- The internal structure is defined as follows: -- OCTET 1: -- bits 87654321: group (bits 8765) and specific service -- (bits 4321) -- OCTETS 2-5: reserved for future use. If received the -- Ext-TeleserviceCode shall be -- treated according to the exception handling defined for the -- operation that uses this type. -- Ext-TeleserviceCode includes all values defined for TeleserviceCode. allTeleservices TeleserviceCode ::= '00000000'B allSpeechTransmissionServices TeleserviceCode ::= '00010000'B telephony TeleserviceCode ::= '00010001'B emergencyCalls TeleserviceCode ::= '00010010'B allShortMessageServices TeleserviceCode ::= '00100000'B shortMessageMT-PP TeleserviceCode ::= '00100001'B shortMessageMO-PP TeleserviceCode ::= '00100010'B allFacsimileTransmissionServices TeleserviceCode ::= '01100000'B facsimileGroup3AndAlterSpeech TeleserviceCode ::= '01100001'B automaticFacsimileGroup3 TeleserviceCode ::= '01100010'B facsimileGroup4 TeleserviceCode ::= '01100011'B -- The following non-hierarchical Compound Teleservice Groups -- are defined in TS 3GPP TS 22.030: allDataTeleservices TeleserviceCode ::= '01110000'B -- covers Teleservice Groups 'allFacsimileTransmissionServices' -- and 'allShortMessageServices' allTeleservices-ExeptSMS TeleserviceCode ::= '10000000'B -- covers Teleservice Groups 'allSpeechTransmissionServices' and -- 'allFacsimileTransmissionServices' -- -- Compound Teleservice Group Codes are only used in call -- independent supplementary service operations, i.e. they -- are not used in InsertSubscriberData or in -- DeleteSubscriberData messages. allVoiceGroupCallServices TeleserviceCode ::= '10010000'B voiceGroupCall TeleserviceCode ::= '10010001'B voiceBroadcastCall TeleserviceCode ::= '10010010'B allPLMN-specificTS TeleserviceCode ::= '11010000'B plmn-specificTS-1 TeleserviceCode ::= '11010001'B plmn-specificTS-2 TeleserviceCode ::= '11010010'B plmn-specificTS-3 TeleserviceCode ::= '11010011'B plmn-specificTS-4 TeleserviceCode ::= '11010100'B plmn-specificTS-5 TeleserviceCode ::= '11010101'B plmn-specificTS-6 TeleserviceCode ::= '11010110'B plmn-specificTS-7 TeleserviceCode ::= '11010111'B plmn-specificTS-8 TeleserviceCode ::= '11011000'B plmn-specificTS-9 TeleserviceCode ::= '11011001'B plmn-specificTS-A TeleserviceCode ::= '11011010'B plmn-specificTS-B TeleserviceCode ::= '11011011'B plmn-specificTS-C TeleserviceCode ::= '11011100'B plmn-specificTS-D TeleserviceCode ::= '11011101'B plmn-specificTS-E TeleserviceCode ::= '11011110'B plmn-specificTS-F TeleserviceCode ::= '11011111'B .#END 17.7.10 Bearer Service Codes .$MAP-BS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-BS-Code (20) version20 (20)} DEFINITIONS ::= BEGIN BearerServiceCode ::= OCTET STRING (SIZE (1)) -- This type is used to represent the code identifying a single -- bearer service, a group of bearer services, or all bearer -- services. The services are defined in TS 3GPP TS 22.002 [3]. -- The internal structure is defined as follows: -- -- plmn-specific bearer services: -- bits 87654321: defined by the HPLMN operator -- rest of bearer services: -- bit 8: 0 (unused) -- bits 7654321: group (bits 7654), and rate, if applicable -- (bits 321) Ext-BearerServiceCode ::= OCTET STRING (SIZE (1..5)) -- This type is used to represent the code identifying a single -- bearer service, a group of bearer services, or all bearer -- services. The services are defined in TS 3GPP TS 22.002 [3]. -- The internal structure is defined as follows: -- -- OCTET 1: -- plmn-specific bearer services: -- bits 87654321: defined by the HPLMN operator -- -- rest of bearer services: -- bit 8: 0 (unused) -- bits 7654321: group (bits 7654), and rate, if applicable -- (bits 321) -- OCTETS 2-5: reserved for future use. If received the -- Ext-TeleserviceCode shall be -- treated according to the exception handling defined for the -- operation that uses this type. -- Ext-BearerServiceCode includes all values defined for BearerServiceCode. allBearerServices BearerServiceCode ::= '00000000'B allDataCDA-Services BearerServiceCode ::= '00010000'B dataCDA-300bps BearerServiceCode ::= '00010001'B dataCDA-1200bps BearerServiceCode ::= '00010010'B dataCDA-1200-75bps BearerServiceCode ::= '00010011'B dataCDA-2400bps BearerServiceCode ::= '00010100'B dataCDA-4800bps BearerServiceCode ::= '00010101'B dataCDA-9600bps BearerServiceCode ::= '00010110'B general-dataCDA BearerServiceCode ::= '00010111'B allDataCDS-Services BearerServiceCode ::= '00011000'B dataCDS-1200bps BearerServiceCode ::= '00011010'B dataCDS-2400bps BearerServiceCode ::= '00011100'B dataCDS-4800bps BearerServiceCode ::= '00011101'B dataCDS-9600bps BearerServiceCode ::= '00011110'B general-dataCDS BearerServiceCode ::= '00011111'B allPadAccessCA-Services BearerServiceCode ::= '00100000'B padAccessCA-300bps BearerServiceCode ::= '00100001'B padAccessCA-1200bps BearerServiceCode ::= '00100010'B padAccessCA-1200-75bps BearerServiceCode ::= '00100011'B padAccessCA-2400bps BearerServiceCode ::= '00100100'B padAccessCA-4800bps BearerServiceCode ::= '00100101'B padAccessCA-9600bps BearerServiceCode ::= '00100110'B general-padAccessCA BearerServiceCode ::= '00100111'B allDataPDS-Services BearerServiceCode ::= '00101000'B dataPDS-2400bps BearerServiceCode ::= '00101100'B dataPDS-4800bps BearerServiceCode ::= '00101101'B dataPDS-9600bps BearerServiceCode ::= '00101110'B general-dataPDS BearerServiceCode ::= '00101111'B allAlternateSpeech-DataCDA BearerServiceCode ::= '00110000'B allAlternateSpeech-DataCDS BearerServiceCode ::= '00111000'B allSpeechFollowedByDataCDA BearerServiceCode ::= '01000000'B allSpeechFollowedByDataCDS BearerServiceCode ::= '01001000'B -- The following non-hierarchical Compound Bearer Service -- Groups are defined in TS 3GPP TS 22.030: allDataCircuitAsynchronous BearerServiceCode ::= '01010000'B -- covers ""allDataCDA-Services"", ""allAlternateSpeech-DataCDA"" and -- ""allSpeechFollowedByDataCDA"" allAsynchronousServices BearerServiceCode ::= '01100000'B -- covers ""allDataCDA-Services"", ""allAlternateSpeech-DataCDA"", -- ""allSpeechFollowedByDataCDA"" and ""allPadAccessCDA-Services"" allDataCircuitSynchronous BearerServiceCode ::= '01011000'B -- covers ""allDataCDS-Services"", ""allAlternateSpeech-DataCDS"" and -- ""allSpeechFollowedByDataCDS"" allSynchronousServices BearerServiceCode ::= '01101000'B -- covers ""allDataCDS-Services"", ""allAlternateSpeech-DataCDS"", -- ""allSpeechFollowedByDataCDS"" and ""allDataPDS-Services"" -- -- Compound Bearer Service Group Codes are only used in call -- independent supplementary service operations, i.e. they -- are not used in InsertSubscriberData or in -- DeleteSubscriberData messages. allPLMN-specificBS BearerServiceCode ::= '11010000'B plmn-specificBS-1 BearerServiceCode ::= '11010001'B plmn-specificBS-2 BearerServiceCode ::= '11010010'B plmn-specificBS-3 BearerServiceCode ::= '11010011'B plmn-specificBS-4 BearerServiceCode ::= '11010100'B plmn-specificBS-5 BearerServiceCode ::= '11010101'B plmn-specificBS-6 BearerServiceCode ::= '11010110'B plmn-specificBS-7 BearerServiceCode ::= '11010111'B plmn-specificBS-8 BearerServiceCode ::= '11011000'B plmn-specificBS-9 BearerServiceCode ::= '11011001'B plmn-specificBS-A BearerServiceCode ::= '11011010'B plmn-specificBS-B BearerServiceCode ::= '11011011'B plmn-specificBS-C BearerServiceCode ::= '11011100'B plmn-specificBS-D BearerServiceCode ::= '11011101'B plmn-specificBS-E BearerServiceCode ::= '11011110'B plmn-specificBS-F BearerServiceCode ::= '11011111'B .#END 17.7.11 Extension data types .$MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS PrivateExtension, ExtensionContainer, SLR-ArgExtensionContainer; -- IOC for private MAP extensions MAP-EXTENSION ::= CLASS { &ExtensionType OPTIONAL, &extensionId OBJECT IDENTIFIER } -- The length of the Object Identifier shall not exceed 16 octets and the -- number of components of the Object Identifier shall not exceed 16 -- data types ExtensionContainer ::= SEQUENCE { privateExtensionList [0]PrivateExtensionList OPTIONAL, pcs-Extensions [1]PCS-Extensions OPTIONAL, ...} SLR-ArgExtensionContainer ::= SEQUENCE { privateExtensionList [0]PrivateExtensionList OPTIONAL, slr-Arg-PCS-Extensions [1]SLR-Arg-PCS-Extensions OPTIONAL, ...} PrivateExtensionList ::= SEQUENCE SIZE (1..maxNumOfPrivateExtensions) OF PrivateExtension PrivateExtension ::= SEQUENCE { extId MAP-EXTENSION.&extensionId ({ExtensionSet}), extType MAP-EXTENSION.&ExtensionType ({ExtensionSet}{@extId}) OPTIONAL} maxNumOfPrivateExtensions INTEGER ::= 10 ExtensionSet MAP-EXTENSION ::= {... -- ExtensionSet is the set of all defined private extensions } -- Unsupported private extensions shall be discarded if received. PCS-Extensions ::= SEQUENCE { ...} SLR-Arg-PCS-Extensions ::= SEQUENCE { ..., na-ESRK-Request [0] NULL OPTIONAL } .#END 17.7.12 Group Call data types .$MAP-GR-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-GR-DataTypes (23) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS PrepareGroupCallArg, PrepareGroupCallRes, SendGroupCallEndSignalArg, SendGroupCallEndSignalRes, ForwardGroupCallSignallingArg, ProcessGroupCallSignallingArg, SendGroupCallInfoArg, SendGroupCallInfoRes ; IMPORTS ISDN-AddressString, IMSI, TMSI, EMLPP-Priority, ASCI-CallReference, SignalInfo, GlobalCellId, AccessNetworkSignalInfo FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} Ext-TeleserviceCode FROM MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-TS-Code (19) version20 (20)} Kc, AdditionalInfo, GroupId, Long-GroupId, AdditionalSubscriptions, Cksn FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; PrepareGroupCallArg ::= SEQUENCE { teleservice Ext-TeleserviceCode, asciCallReference ASCI-CallReference, codec-Info CODEC-Info, cipheringAlgorithm CipheringAlgorithm, groupKeyNumber-Vk-Id [0] GroupKeyNumber OPTIONAL, groupKey [1] Kc OPTIONAL, -- this parameter shall not be sent and shall be discarded if received priority [2] EMLPP-Priority OPTIONAL, uplinkFree [3] NULL OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., vstk [5] VSTK OPTIONAL, vstk-rand [6] VSTK-RAND OPTIONAL, talkerChannelParameter [7] NULL OPTIONAL, uplinkReplyIndicator [8] NULL OPTIONAL} VSTK ::= OCTET STRING (SIZE (16)) VSTK-RAND ::= OCTET STRING (SIZE (5)) -- The 36 bit value is carried in bit 7 of octet 1 to bit 4 of octet 5 -- bits 3, 2, 1, and 0 of octet 5 are padded with zeros. PrepareGroupCallRes ::= SEQUENCE { groupCallNumber ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ...} SendGroupCallEndSignalArg ::= SEQUENCE { imsi IMSI OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., talkerPriority [0]TalkerPriority OPTIONAL, additionalInfo [1]AdditionalInfo OPTIONAL } TalkerPriority ::= ENUMERATED { normal (0), privileged (1), emergency (2)} SendGroupCallEndSignalRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ForwardGroupCallSignallingArg ::= SEQUENCE { imsi IMSI OPTIONAL, uplinkRequestAck [0] NULL OPTIONAL, uplinkReleaseIndication [1] NULL OPTIONAL, uplinkRejectCommand [2] NULL OPTIONAL, uplinkSeizedCommand [3] NULL OPTIONAL, uplinkReleaseCommand [4] NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., stateAttributes [5] StateAttributes OPTIONAL, talkerPriority [6] TalkerPriority OPTIONAL, additionalInfo [7] AdditionalInfo OPTIONAL, emergencyModeResetCommandFlag [8] NULL OPTIONAL, sm-RP-UI [9] SignalInfo OPTIONAL, an-APDU [10] AccessNetworkSignalInfo OPTIONAL } ProcessGroupCallSignallingArg ::= SEQUENCE { uplinkRequest [0] NULL OPTIONAL, uplinkReleaseIndication [1] NULL OPTIONAL, releaseGroupCall [2] NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., talkerPriority [3] TalkerPriority OPTIONAL, additionalInfo [4] AdditionalInfo OPTIONAL, emergencyModeResetCommandFlag [5] NULL OPTIONAL, an-APDU [6] AccessNetworkSignalInfo OPTIONAL } GroupKeyNumber ::= INTEGER (0..15) CODEC-Info ::= OCTET STRING (SIZE (5..10)) -- Refers to channel type -- coded according to 3GPP TS 48.008 [49] and including Element identifier and Length CipheringAlgorithm ::= OCTET STRING (SIZE (1)) -- Refers to 'permitted algorithms' in 'encryption information' -- coded according to 3GPP TS 48.008 [49]: -- Bits 8-1 -- 8765 4321 -- 0000 0001 No encryption -- 0000 0010 GSM A5/1 -- 0000 0100 GSM A5/2 -- 0000 1000 GSM A5/3 -- 0001 0000 GSM A5/4 -- 0010 0000 GSM A5/5 -- 0100 0000 GSM A5/6 -- 1000 0000 GSM A5/7 StateAttributes ::= SEQUENCE { downlinkAttached [5] NULL OPTIONAL, uplinkAttached [6] NULL OPTIONAL, dualCommunication [7] NULL OPTIONAL, callOriginator [8] NULL OPTIONAL } -- Refers to 3GPP TS 44.068 for definitions of StateAttributes fields. SendGroupCallInfoArg ::= SEQUENCE { requestedInfo RequestedInfo, groupId Long-GroupId, teleservice Ext-TeleserviceCode, cellId [0] GlobalCellId OPTIONAL, imsi [1] IMSI OPTIONAL, tmsi [2] TMSI OPTIONAL, additionalInfo [3] AdditionalInfo OPTIONAL, talkerPriority [4] TalkerPriority OPTIONAL, cksn [5] Cksn OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ... } RequestedInfo ::= ENUMERATED { anchorMSC-AddressAndASCI-CallReference (0), imsiAndAdditionalInfoAndAdditionalSubscription (1), ... } -- exception handling: -- an unrecognized value shall be rejected by the receiver with a return error cause of -- unexpected data value SendGroupCallInfoRes ::= SEQUENCE { anchorMSC-Address [0] ISDN-AddressString OPTIONAL, asciCallReference [1] ASCI-CallReference OPTIONAL, imsi [2] IMSI OPTIONAL, additionalInfo [3] AdditionalInfo OPTIONAL, additionalSubscriptions [4] AdditionalSubscriptions OPTIONAL, kc [5] Kc OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ... } .#END 17.7.13 Location service data types .$MAP-LCS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-LCS-DataTypes (25) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RoutingInfoForLCS-Arg, RoutingInfoForLCS-Res, ProvideSubscriberLocation-Arg, ProvideSubscriberLocation-Res, SubscriberLocationReport-Arg, SubscriberLocationReport-Res, LocationType, DeferredLocationEventType, LCSClientName, LCS-QoS, Horizontal-Accuracy, ResponseTime, Ext-GeographicalInformation, VelocityEstimate, SupportedGADShapes, Add-GeographicalInformation, LCSRequestorID, LCS-ReferenceNumber, LCSCodeword, AreaEventInfo, ReportingPLMNList, PeriodicLDRInfo, SequenceNumber, LCSClientType, LCS-Priority, OccurrenceInfo, IntervalTime ; IMPORTS AddressString, ISDN-AddressString, IMEI, IMSI, LMSI, SubscriberIdentity, AgeOfLocationInformation, LCSClientExternalID, LCSClientInternalID, LCSServiceTypeID, CellGlobalIdOrServiceAreaIdOrLAI, PLMN-Id, GSN-Address, DiameterIdentity FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer, SLR-ArgExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} USSD-DataCodingScheme, USSD-String FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} APN, SupportedLCS-CapabilitySets FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} Additional-Number FROM MAP-SM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version20 (20)} ; RoutingInfoForLCS-Arg ::= SEQUENCE { mlcNumber [0] ISDN-AddressString, targetMS [1] SubscriberIdentity, extensionContainer [2] ExtensionContainer OPTIONAL, ...} RoutingInfoForLCS-Res ::= SEQUENCE { targetMS [0] SubscriberIdentity, lcsLocationInfo [1] LCSLocationInfo, extensionContainer [2] ExtensionContainer OPTIONAL, ..., v-gmlc-Address [3] GSN-Address OPTIONAL, h-gmlc-Address [4] GSN-Address OPTIONAL, ppr-Address [5] GSN-Address OPTIONAL, additional-v-gmlc-Address [6] GSN-Address OPTIONAL } LCSLocationInfo ::= SEQUENCE { networkNode-Number ISDN-AddressString, -- NetworkNode-number can be msc-number, sgsn-number or a dummy value of ""0"" lmsi [0] LMSI OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... , gprsNodeIndicator [2] NULL OPTIONAL, -- gprsNodeIndicator is set only if the SGSN number is sent as the Network Node Number additional-Number [3] Additional-Number OPTIONAL, supportedLCS-CapabilitySets [4] SupportedLCS-CapabilitySets OPTIONAL, additional-LCS-CapabilitySets [5] SupportedLCS-CapabilitySets OPTIONAL, mme-Name [6] DiameterIdentity OPTIONAL, aaa-Server-Name [8] DiameterIdentity OPTIONAL, sgsn-Name [9] DiameterIdentity OPTIONAL, sgsn-Realm [10] DiameterIdentity OPTIONAL } ProvideSubscriberLocation-Arg ::= SEQUENCE { locationType LocationType, mlc-Number ISDN-AddressString, lcs-ClientID [0] LCS-ClientID OPTIONAL, privacyOverride [1] NULL OPTIONAL, imsi [2] IMSI OPTIONAL, msisdn [3] ISDN-AddressString OPTIONAL, lmsi [4] LMSI OPTIONAL, imei [5] IMEI OPTIONAL, lcs-Priority [6] LCS-Priority OPTIONAL, lcs-QoS [7] LCS-QoS OPTIONAL, extensionContainer [8] ExtensionContainer OPTIONAL, ... , supportedGADShapes [9] SupportedGADShapes OPTIONAL, lcs-ReferenceNumber [10] LCS-ReferenceNumber OPTIONAL, lcsServiceTypeID [11] LCSServiceTypeID OPTIONAL, lcsCodeword [12] LCSCodeword OPTIONAL, lcs-PrivacyCheck [13] LCS-PrivacyCheck OPTIONAL, areaEventInfo [14] AreaEventInfo OPTIONAL, h-gmlc-Address [15] GSN-Address OPTIONAL, mo-lrShortCircuitIndicator [16] NULL OPTIONAL, periodicLDRInfo [17] PeriodicLDRInfo OPTIONAL, reportingPLMNList [18] ReportingPLMNList OPTIONAL } -- one of imsi or msisdn is mandatory -- If a location estimate type indicates activate deferred location or cancel deferred -- location, a lcs-Reference number shall be included. LocationType ::= SEQUENCE { locationEstimateType [0] LocationEstimateType, ..., deferredLocationEventType [1] DeferredLocationEventType OPTIONAL } LocationEstimateType ::= ENUMERATED { currentLocation (0), currentOrLastKnownLocation (1), initialLocation (2), ..., activateDeferredLocation (3), cancelDeferredLocation (4) , notificationVerificationOnly (5) } -- exception handling: -- a ProvideSubscriberLocation-Arg containing an unrecognized LocationEstimateType -- shall be rejected by the receiver with a return error cause of unexpected data value DeferredLocationEventType ::= BIT STRING { msAvailable (0) , enteringIntoArea (1), leavingFromArea (2), beingInsideArea (3) , periodicLDR (4) } (SIZE (1..16)) -- beingInsideArea is always treated as oneTimeEvent regardless of the possible value -- of occurrenceInfo inside areaEventInfo. -- exception handling: -- a ProvideSubscriberLocation-Arg containing other values than listed above in -- DeferredLocationEventType shall be rejected by the receiver with a return error cause of -- unexpected data value. LCS-ClientID ::= SEQUENCE { lcsClientType [0] LCSClientType, lcsClientExternalID [1] LCSClientExternalID OPTIONAL, lcsClientDialedByMS [2] AddressString OPTIONAL, lcsClientInternalID [3] LCSClientInternalID OPTIONAL, lcsClientName [4] LCSClientName OPTIONAL, ..., lcsAPN [5] APN OPTIONAL, lcsRequestorID [6] LCSRequestorID OPTIONAL } LCSClientType ::= ENUMERATED { emergencyServices (0), valueAddedServices (1), plmnOperatorServices (2), lawfulInterceptServices (3), ... } -- exception handling: -- unrecognized values may be ignored if the LCS client uses the privacy override -- otherwise, an unrecognized value shall be treated as unexpected data by a receiver -- a return error shall then be returned if received in a MAP invoke LCSClientName ::= SEQUENCE { dataCodingScheme [0] USSD-DataCodingScheme, nameString [2] NameString, ..., lcs-FormatIndicator [3] LCS-FormatIndicator OPTIONAL } -- The USSD-DataCodingScheme shall indicate use of the default alphabet through the -- following encoding -- bit 7 6 5 4 3 2 1 0 -- 0 0 0 0 1 1 1 1 NameString ::= USSD-String (SIZE (1..maxNameStringLength)) maxNameStringLength INTEGER ::= 63 LCSRequestorID ::= SEQUENCE { dataCodingScheme [0] USSD-DataCodingScheme, requestorIDString [1] RequestorIDString, ..., lcs-FormatIndicator [2] LCS-FormatIndicator OPTIONAL } RequestorIDString ::= USSD-String (SIZE (1..maxRequestorIDStringLength)) maxRequestorIDStringLength INTEGER ::= 63 LCS-FormatIndicator ::= ENUMERATED { logicalName (0), e-mailAddress (1), msisdn (2), url (3), sipUrl (4), ... } LCS-Priority ::= OCTET STRING (SIZE (1)) -- 0 = highest priority -- 1 = normal priority -- all other values treated as 1 LCS-QoS ::= SEQUENCE { horizontal-accuracy [0] Horizontal-Accuracy OPTIONAL, verticalCoordinateRequest [1] NULL OPTIONAL, vertical-accuracy [2] Vertical-Accuracy OPTIONAL, responseTime [3] ResponseTime OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., velocityRequest [5] NULL OPTIONAL } Horizontal-Accuracy ::= OCTET STRING (SIZE (1)) -- bit 8 = 0 -- bits 7-1 = 7 bit Uncertainty Code defined in 3GPP TS 23.032. The horizontal location -- error should be less than the error indicated by the uncertainty code with 67% -- confidence. Vertical-Accuracy ::= OCTET STRING (SIZE (1)) -- bit 8 = 0 -- bits 7-1 = 7 bit Vertical Uncertainty Code defined in 3GPP TS 23.032. -- The vertical location error should be less than the error indicated -- by the uncertainty code with 67% confidence. ResponseTime ::= SEQUENCE { responseTimeCategory ResponseTimeCategory, ...} -- note: an expandable SEQUENCE simplifies later addition of a numeric response time. ResponseTimeCategory ::= ENUMERATED { lowdelay (0), delaytolerant (1), ... } -- exception handling: -- an unrecognized value shall be treated the same as value 1 (delaytolerant) SupportedGADShapes ::= BIT STRING { ellipsoidPoint (0), ellipsoidPointWithUncertaintyCircle (1), ellipsoidPointWithUncertaintyEllipse (2), polygon (3), ellipsoidPointWithAltitude (4), ellipsoidPointWithAltitudeAndUncertaintyElipsoid (5), ellipsoidArc (6) } (SIZE (7..16)) -- A node shall mark in the BIT STRING all Shapes defined in 3GPP TS 23.032 it supports. -- exception handling: bits 7 to 15 shall be ignored if received. LCS-ReferenceNumber::= OCTET STRING (SIZE(1)) LCSCodeword ::= SEQUENCE { dataCodingScheme [0] USSD-DataCodingScheme, lcsCodewordString [1] LCSCodewordString, ...} LCSCodewordString ::= USSD-String (SIZE (1..maxLCSCodewordStringLength)) maxLCSCodewordStringLength INTEGER ::= 20 LCS-PrivacyCheck ::= SEQUENCE { callSessionUnrelated [0] PrivacyCheckRelatedAction, callSessionRelated [1] PrivacyCheckRelatedAction OPTIONAL, ...} PrivacyCheckRelatedAction ::= ENUMERATED { allowedWithoutNotification (0), allowedWithNotification (1), allowedIfNoResponse (2), restrictedIfNoResponse (3), notAllowed (4), ...} -- exception handling: -- a ProvideSubscriberLocation-Arg containing an unrecognized PrivacyCheckRelatedAction -- shall be rejected by the receiver with a return error cause of unexpected data value AreaEventInfo ::= SEQUENCE { areaDefinition [0] AreaDefinition, occurrenceInfo [1] OccurrenceInfo OPTIONAL, intervalTime [2] IntervalTime OPTIONAL, ...} AreaDefinition ::= SEQUENCE { areaList [0] AreaList, ...} AreaList ::= SEQUENCE SIZE (1..maxNumOfAreas) OF Area maxNumOfAreas INTEGER ::= 10 Area ::= SEQUENCE { areaType [0] AreaType, areaIdentification [1] AreaIdentification, ...} AreaType ::= ENUMERATED { countryCode (0), plmnId (1), locationAreaId (2), routingAreaId (3), cellGlobalId (4), ..., utranCellId (5) } AreaIdentification ::= OCTET STRING (SIZE (2..7)) -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit if 3 digit MNC included -- or filler (1111) -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code (LAC) for Local Area Id, -- Routing Area Id and Cell Global Id -- octet 6 Routing Area Code (RAC) for Routing Area Id -- octets 6 and 7 Cell Identity (CI) for Cell Global Id -- octets 4 until 7 Utran Cell Identity (UC-Id) for Utran Cell Id OccurrenceInfo ::= ENUMERATED { oneTimeEvent (0), multipleTimeEvent (1), ...} IntervalTime ::= INTEGER (1..32767) -- minimum interval time between area reports in seconds PeriodicLDRInfoÊ::= SEQUENCE { reportingAmount ReportingAmount, reportingInterval ReportingInterval, ...} -- reportingInterval x reportingAmount shall not exceed 8639999 (99 days, 23 hours, -- 59 minutes and 59 seconds) for compatibility with OMA MLP and RLP ReportingAmountÊ::= INTEGER (1..maxReportingAmount) maxReportingAmount INTEGERÊ::= 8639999 ReportingIntervalÊ::= INTEGER (1..maxReportingInterval) -- ReportingInterval is in seconds maxReportingInterval INTEGERÊ::= 8639999 ReportingPLMNList::= SEQUENCE { plmn-ListPrioritized [0] NULL OPTIONAL, plmn-List [1] PLMNList, ...} PLMNList::= SEQUENCE SIZE (1..maxNumOfReportingPLMN) OF ReportingPLMN maxNumOfReportingPLMN INTEGER ::= 20 ReportingPLMN::= SEQUENCE { plmn-Id [0] PLMN-Id, ran-Technology [1] RAN-Technology OPTIONAL, ran-PeriodicLocationSupport [2] NULL OPTIONAL, ...} RAN-Technology ::= ENUMERATED { gsm (0), umts (1), ...} ProvideSubscriberLocation-Res ::= SEQUENCE { locationEstimate Ext-GeographicalInformation, ageOfLocationEstimate [0] AgeOfLocationInformation OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... , add-LocationEstimate [2] Add-GeographicalInformation OPTIONAL, deferredmt-lrResponseIndicator [3] NULL OPTIONAL, geranPositioningData [4] PositioningDataInformation OPTIONAL, utranPositioningData [5] UtranPositioningDataInfo OPTIONAL, cellIdOrSai [6] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL, sai-Present [7] NULL OPTIONAL, accuracyFulfilmentIndicator [8] AccuracyFulfilmentIndicator OPTIONAL, velocityEstimate [9] VelocityEstimate OPTIONAL, mo-lrShortCircuitIndicator [10] NULL OPTIONAL, geranGANSSpositioningData [11] GeranGANSSpositioningData OPTIONAL, utranGANSSpositioningData [12] UtranGANSSpositioningData OPTIONAL, targetServingNodeForHandover [13] ServingNodeAddress OPTIONAL, utranAdditionalPositioningData [14] UtranAdditionalPositioningData OPTIONAL, utranBaroPressureMeas [15] UtranBaroPressureMeas OPTIONAL, utranCivicAddress [16] UtranCivicAddress OPTIONAL } -- if deferredmt-lrResponseIndicator is set, locationEstimate is ignored. -- the add-LocationEstimate parameter shall not be sent to a node that did not indicate the -- geographic shapes supported in the ProvideSubscriberLocation-Arg -- The locationEstimate and the add-locationEstimate parameters shall not be sent if -- the supportedGADShapes parameter has been received in ProvideSubscriberLocation-Arg -- and the shape encoded in locationEstimate or add-LocationEstimate is not marked -- as supported in supportedGADShapes. In such a case ProvideSubscriberLocation -- shall be rejected with error FacilityNotSupported with additional indication -- shapeOfLocationEstimateNotSupported. -- sai-Present indicates that the cellIdOrSai parameter contains a Service Area Identity. AccuracyFulfilmentIndicator ::= ENUMERATED { requestedAccuracyFulfilled (0), requestedAccuracyNotFulfilled (1), ... } Ext-GeographicalInformation ::= OCTET STRING (SIZE (1..maxExt-GeographicalInformation)) -- Refers to geographical Information defined in 3GPP TS 23.032. -- This is composed of 1 or more octets with an internal structure according to -- 3GPP TS 23.032 -- Octet 1: Type of shape, only the following shapes in 3GPP TS 23.032 are allowed: -- (a) Ellipsoid point with uncertainty circle -- (b) Ellipsoid point with uncertainty ellipse -- (c) Ellipsoid point with altitude and uncertainty ellipsoid -- (d) Ellipsoid Arc -- (e) Ellipsoid Point -- Any other value in octet 1 shall be treated as invalid -- Octets 2 to 8 for case (a) Ð Ellipsoid point with uncertainty circle -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Uncertainty code 1 octet -- Octets 2 to 11 for case (b) Ð Ellipsoid point with uncertainty ellipse: -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Uncertainty semi-major axis 1 octet -- Uncertainty semi-minor axis 1 octet -- Angle of major axis 1 octet -- Confidence 1 octet -- Octets 2 to 14 for case (c) Ð Ellipsoid point with altitude and uncertainty ellipsoid -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Altitude 2 octets -- Uncertainty semi-major axis 1 octet -- Uncertainty semi-minor axis 1 octet -- Angle of major axis 1 octet -- Uncertainty altitude 1 octet -- Confidence 1 octet -- Octets 2 to 13 for case (d) Ð Ellipsoid Arc -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Inner radius 2 octets -- Uncertainty radius 1 octet -- Offset angle 1 octet -- Included angle 1 octet -- Confidence 1 octet -- Octets 2 to 7 for case (e) Ð Ellipsoid Point -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- -- An Ext-GeographicalInformation parameter comprising more than one octet and -- containing any other shape or an incorrect number of octets or coding according -- to 3GPP TS 23.032 shall be treated as invalid data by a receiver. -- -- An Ext-GeographicalInformation parameter comprising one octet shall be discarded -- by the receiver if an Add-GeographicalInformation parameter is received -- in the same message. -- -- An Ext-GeographicalInformation parameter comprising one octet shall be treated as -- invalid data by the receiver if an Add-GeographicalInformation parameter is not -- received in the same message. maxExt-GeographicalInformation INTEGER ::= 20 -- the maximum length allows for further shapes in 3GPP TS 23.032 to be included in later -- versions of 3GPP TS 29.002 VelocityEstimate ::= OCTET STRING (SIZE (4..7)) -- Refers to Velocity description defined in 3GPP TS 23.032. -- This is composed of 4 or more octets with an internal structure according to -- 3GPP TS 23.032 -- Octet 1: Type of velocity, only the following types in 3GPP TS 23.032 are allowed: -- (a) Horizontal Velocity -- (b) Horizontal with Vertical Velocity -- (c) Horizontal Velocity with Uncertainty -- (d) Horizontal with Vertical Velocity and Uncertainty -- For types Horizontal with Vertical Velocity and Horizontal with Vertical Velocity -- and Uncertainty, the direction of the Vertical Speed is also included in Octet 1 -- Any other value in octet 1 shall be treated as invalid -- Octets 2 to 4 for case (a) Horizontal velocity: -- Bearing 1 octet -- Horizontal Speed 2 octets -- Octets 2 to 5 for case (b) Ð Horizontal with Vertical Velocity: -- Bearing 1 octet -- Horizontal Speed 2 octets -- Vertical Speed 1 octet -- Octets 2 to 5 for case (c) Ð Horizontal velocity with Uncertainty: -- Bearing 1 octet -- Horizontal Speed 2 octets -- Uncertainty Speed 1 octet -- Octets 2 to 7 for case (d) Ð Horizontal with Vertical Velocity and Uncertainty: -- Bearing 1 octet -- Horizontal Speed 2 octets -- Vertical Speed 1 octet -- Horizontal Uncertainty Speed 1 octet -- Vertical Uncertainty Speed 1 octet PositioningDataInformation ::= OCTET STRING (SIZE (2..maxPositioningDataInformation)) -- Refers to the Positioning Data defined in 3GPP TS 49.031. -- This is composed of 2 or more octets with an internal structure according to -- 3GPP TS 49.031. maxPositioningDataInformation INTEGER ::= 10 -- UtranPositioningDataInfo ::= OCTET STRING (SIZE (3..maxUtranPositioningDataInfo)) -- Refers to the Position Data defined in 3GPP TS 25.413. -- This is composed of the positioningDataDiscriminator and the positioningDataSet -- included in positionData as defined in 3GPP TS 25.413. maxUtranPositioningDataInfo INTEGER ::= 11 -- GeranGANSSpositioningData ::= OCTET STRING (SIZE (2..maxGeranGANSSpositioningData)) -- Refers to the GANSS Positioning Data defined in 3GPP TS 49.031. -- This is composed of 2 or more octets with an internal structure according to -- 3GPP TS 49.031. maxGeranGANSSpositioningData INTEGER ::= 10 -- UtranGANSSpositioningData ::= OCTET STRING (SIZE (1..maxUtranGANSSpositioningData)) -- Refers to the Position Data defined in 3GPP TS 25.413. -- This is composed of the GANSS-PositioningDataSet only, included in PositionData -- as defined in 3GPP TS 25.413. maxUtranGANSSpositioningData INTEGER ::= 9 -- UtranAdditionalPositioningData ::= OCTET STRING (SIZE (1..maxUtranAdditionalPositioningData)) -- Refers to the Position Data defined in 3GPP TS 25.413. -- This is composed of the Additional-PositioningDataSet only, included in PositionData -- as defined in 3GPP TS 25.413. maxUtranAdditionalPositioningData INTEGER ::= 8 -- UtranBaroPressureMeas ::= INTEGER (30000..115000) -- Refers to the barometric pressure measurement defined in 3GPP TS 25.413. -- This is composed of the BarometricPressureMeasurement only as defined in 3GPP TS -- 25.413. UtranCivicAddress ::= OCTET STRING -- Refers to the civic address defined in 3GPP TS 25.413. -- This is composed of the CivicAddress only as defined in 3GPP TS 25.413. Add-GeographicalInformation ::= OCTET STRING (SIZE (1..maxAdd-GeographicalInformation)) -- Refers to geographical Information defined in 3GPP TS 23.032."
"-- This is composed of 1 or more octets with an internal structure according to -- 3GPP TS 23.032 -- Octet 1: Type of shape, all the shapes defined in 3GPP TS 23.032 are allowed: -- Octets 2 to n (where n is the total number of octets necessary to encode the shape -- according to 3GPP TS 23.032) are used to encode the shape itself in accordance with the -- encoding defined in 3GPP TS 23.032 -- -- An Add-GeographicalInformation parameter, whether valid or invalid, received -- together with a valid Ext-GeographicalInformation parameter in the same message -- shall be discarded. -- -- An Add-GeographicalInformation parameter containing any shape not defined in -- 3GPP TS 23.032 or an incorrect number of octets or coding according to -- 3GPP TS 23.032 shall be treated as invalid data by a receiver if not received -- together with a valid Ext-GeographicalInformation parameter in the same message. maxAdd-GeographicalInformation INTEGER ::= 91 -- the maximum length allows support for all the shapes currently defined in 3GPP TS 23.032 SubscriberLocationReport-Arg ::= SEQUENCE { lcs-Event LCS-Event, lcs-ClientID LCS-ClientID, lcsLocationInfo LCSLocationInfo, msisdn [0] ISDN-AddressString OPTIONAL, imsi [1] IMSI OPTIONAL, imei [2] IMEI OPTIONAL, na-ESRD [3] ISDN-AddressString OPTIONAL, na-ESRK [4] ISDN-AddressString OPTIONAL, locationEstimate [5] Ext-GeographicalInformation OPTIONAL, ageOfLocationEstimate [6] AgeOfLocationInformation OPTIONAL, slr-ArgExtensionContainer [7] SLR-ArgExtensionContainer OPTIONAL, ... , add-LocationEstimate [8] Add-GeographicalInformation OPTIONAL, deferredmt-lrData [9] Deferredmt-lrData OPTIONAL, lcs-ReferenceNumber [10] LCS-ReferenceNumber OPTIONAL, geranPositioningData [11] PositioningDataInformation OPTIONAL, utranPositioningData [12] UtranPositioningDataInfo OPTIONAL, cellIdOrSai [13] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL, h-gmlc-Address [14] GSN-Address OPTIONAL, lcsServiceTypeID [15] LCSServiceTypeID OPTIONAL, sai-Present [17] NULL OPTIONAL, pseudonymIndicator [18] NULL OPTIONAL, accuracyFulfilmentIndicator [19] AccuracyFulfilmentIndicator OPTIONAL, velocityEstimate [20] VelocityEstimate OPTIONAL, sequenceNumber [21] SequenceNumber OPTIONAL, periodicLDRInfo [22] PeriodicLDRInfo OPTIONAL, mo-lrShortCircuitIndicator [23] NULL OPTIONAL, geranGANSSpositioningData [24] GeranGANSSpositioningData OPTIONAL, utranGANSSpositioningData [25] UtranGANSSpositioningData OPTIONAL, targetServingNodeForHandover [26] ServingNodeAddress OPTIONAL, utranAdditionalPositioningData [27] UtranAdditionalPositioningData OPTIONAL, utranBaroPressureMeas [28] UtranBaroPressureMeas OPTIONAL, utranCivicAddress [29] UtranCivicAddress OPTIONAL } -- one of msisdn or imsi is mandatory -- a location estimate that is valid for the locationEstimate parameter should -- be transferred in this parameter in preference to the add-LocationEstimate. -- the deferredmt-lrData parameter shall be included if and only if the lcs-Event -- indicates a deferredmt-lrResponse. -- if the lcs-Event indicates a deferredmt-lrResponse then the locationEstimate -- and the add-locationEstimate parameters shall not be sent if the -- supportedGADShapes parameter had been received in ProvideSubscriberLocation-Arg -- and the shape encoded in locationEstimate or add-LocationEstimate was not marked -- as supported in supportedGADShapes. In such a case terminationCause -- in deferredmt-lrData shall be present with value -- shapeOfLocationEstimateNotSupported. -- If a lcs event indicates deferred mt-lr response, the lcs-Reference number shall be -- included. -- sai-Present indicates that the cellIdOrSai parameter contains a Service Area Identity. Deferredmt-lrData ::= SEQUENCE { deferredLocationEventType DeferredLocationEventType, terminationCause [0] TerminationCause OPTIONAL, lcsLocationInfo [1] LCSLocationInfo OPTIONAL, ...} -- lcsLocationInfo may be included only if a terminationCause is present -- indicating mt-lrRestart. LCS-Event ::= ENUMERATED { emergencyCallOrigination (0), emergencyCallRelease (1), mo-lr (2), ..., deferredmt-lrResponse (3) , deferredmo-lrTTTPInitiation (4), emergencyCallHandover (5) } -- deferredmt-lrResponse is applicable to the delivery of a location estimate -- for an LDR initiated earlier by either the network (via an MT-LR activate deferred -- location) or the UE (via a deferred MO-LR TTTP initiation) -- exception handling: -- a SubscriberLocationReport-Arg containing an unrecognized LCS-Event -- shall be rejected by a receiver with a return error cause of unexpected data value TerminationCause ::= ENUMERATED { normal (0), errorundefined (1), internalTimeout (2), congestion (3), mt-lrRestart (4), privacyViolation (5), ..., shapeOfLocationEstimateNotSupported (6) , subscriberTermination (7), uETermination (8), networkTermination (9) } -- mt-lrRestart shall be used to trigger the GMLC to restart the location procedure, -- either because the sending node knows that the terminal has moved under coverage -- of another MSC or SGSN (e.g. Send Identification received), or because the subscriber -- has been deregistered due to a Cancel Location received from HLR. -- -- exception handling -- an unrecognized value shall be treated the same as value 1 (errorundefined) SequenceNumber ::= INTEGER (1..maxReportingAmount) ServingNodeAddress ::= CHOICE { msc-Number [0] ISDN-AddressString, sgsn-Number [1] ISDN-AddressString, mme-Number [2] DiameterIdentity } SubscriberLocationReport-Res ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., na-ESRK [0] ISDN-AddressString OPTIONAL, na-ESRD [1] ISDN-AddressString OPTIONAL, h-gmlc-Address [2] GSN-Address OPTIONAL, mo-lrShortCircuitIndicator [3] NULL OPTIONAL, reportingPLMNList [4] ReportingPLMNList OPTIONAL, lcs-ReferenceNumber [5] LCS-ReferenceNumber OPTIONAL } -- na-ESRK and na-ESRD are mutually exclusive -- -- exception handling -- receipt of both na-ESRK and na-ESRD shall be treated the same as a return error .#END 17.7.14 Void 18 General on MAP user procedures 18.1 Introduction Clauses 18 to 25 describe the use of MAP services for GSMÊsignalling procedures. GSMÊsignalling procedures may involve one or several interfaces running one or several application protocols. The present document addresses only the signalling procedures which require at least the use of one MAP service. When a signalling procedure takes place in the network, an application process invocation is created in each system component involved. Part of the application process invocation acts as a MAP user and handles one or several MAP dialogues. For each dialogue it employs an instance of the MAP service provider. It may also use other communication services to exchange information on other interfaces, but detailed description of these aspects is outside the scope of the present document. 18.2 Common aspects of user procedure descriptions 18.2.1 General conventions For each signalling procedure the present document provides a brief textual overview accompanied by a flow diagram which represent the functional interactions between system components. Functional interactions are labelled using the MAP service name when the interaction results from a service request or by this service name followed by the symbol ""ack"" when this interaction results from a service response. For each of the system components involved, the present document also provides a detailed textual description of the application process behaviour as well as an SDL diagram. SDL diagrams describe the sequence of events, as seen by the MAP-User, which occurs at MAP service provider boundaries as well as external events which occur at other interfaces and which impact on the previous sequence. External events do not necessarily correspond to the messages of other protocols used in the system component. The MAP-user procedures are described as if a set of interworking functions (IWF) between the MAP-user and the other protocol entities was implemented (see figureÊ18.2/1). Such interworking functions are assumed to perform either an identity mapping or some processing or translation as required to eliminate information irrelevant to the MAP-user. The mapping of service primitives on to protocol elements is described in clauses 14 to 17. GSMÊsignalling procedures are built from one or more sub-procedures (e.g. authentication, ciphering, ...). Sub procedures from which signalling procedures are built are represented using SDL MACRO descriptions. In case of any discrepancy between the textual descriptions and the SDL descriptions, the latter take precedence. 18.2.2 Naming conventions Events related to MAP are represented by MAP service primitives. The signal names used in the SDL diagrams are derived from the service primitive names defined in clauses 7 to 12, with some lexical transformations for readability and parsability purposes (blanks between words are replaced by underscores, the first letter of each word is capitalised). Events received and sent on other interfaces are named by appending the message or signal name to a symbol representing the interface type, with some lexical transformations for readability and parsability purposes (blanks between words are replaced by underscores, the first letter of each word is capitalised). The following symbols are used to represent the interface types: ""I"": For interfaces to the fixed network. ""I"" stands for ISUP interface. ""A"": For interfaces between the MSC and the BSS (i.e. A-interfaces); ""Gb"": For interfaces between the SGSN and the BSS (i.e. Gb-interfaces); ""OM"": For network management interfaces (communication with OMC, MML interface, ...); ""SC"": For interfaces to a Service Centre; ""HO_CA"": For internal interfaces to the Handover Control Application. ""US"": For a local USSD application. These naming conventions can be summarised by the following BNF description: <Event_Name> ::= <MAP_Primitive> | <External_Event> <MAP_Primitive> ::= <MAP_Open> | <MAP_Close> | <MAP_U_Abort> | <MAP_P_Abort> | <MAP_Specific> | <MAP_Notice> <MAP_Open> ::= MAP_Open_Req | MAP_Open_Ind | MAP_Open_Rsp | MAP_Open_Cnf <MAP_Close> ::= MAP_Close_Req | MAP_Close_Ind <MAP_U_Abort> ::= MAP_U_Abort_Req | MAP_U_Abort_Ind <MAP_P_Abort> ::= MAP_P_Abort_Ind <MAP_Notice> ::= MAP_Notice_Ind <MAP_Specific> ::= <MAP_Req> | <MAP_Ind> | <MAP_Rsp> | <MAP_Cnf> <MAP_Req> ::= MAP_<Service_Name>_Req <MAP_Ind> ::= MAP_<Service_Name>_Ind <MAP_Rsp> ::= MAP_<Service_Name>_Rsp <MAP_Cnf> ::= MAP_<Service_Name>_Cnf <External_Event> ::= <Interface_Type>_<External_Signal> <Interface_Type> ::= I | A | Gb | OM | SC | HO AC | US <External_Signal> ::= <Lexical_Unit> <Service_Name> ::= <Lexical_Unit> <Lexical_Unit> ::= <Lexical_Component> | <Lexical_Unit>_ <Lexical_Component> <Lexical_Component> ::= <Upper_Case_Letter><Letter_Or_Digit_List> <Letter_Or_Digit_List> ::= <Letter_Or_Digit> | <Letter_Or_Digit_List><Letter_Or_Digit> <Letter_Or_Digit> ::= <Letter> | <Digit> <Letter> ::= <Lower_Case_Letter> | <Upper_Case_Letter> <Upper_Case_Letter> ::= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z <Lower_Case_Letter> ::= a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z <Digit> ::= 1|2|3|4|5|6|7|8|9|0 FigureÊ18.2/1: Interfaces applicable to the MAP-User 18.2.3 Convention on primitives parameters 18.2.3.1 Open service When the originating and destination reference parameters shall be included in the MAP-OPEN request primitive, their value are indicated as a comment to the signal which represents this primitive. 18.2.3.2 Close service When a pre-arranged released is requested, a comment is attached to the signal which represents the MAP-CLOSE request primitive. In the absence of comment, a normal release is assumed. 18.2.4 Version handling at dialogue establishment Unless explicitly indicated in subsequent clauses, the following principles regarding version handling procedures at dialogue establishment are applied by the MAP-user. 18.2.4.1 Behaviour at the initiating side When a MAP user signalling procedure has to be executed, the MAP-user issues a MAP-OPEN request primitive with an appropriate application-context-name. If several names are supported (i.e. several versions) a suitableÊone is selected using the procedures described in clauseÊ5. If version n is selected (where 1 < n <= highest existing version) and a MAP-OPEN Confirm primitive is received in response to the MAP-OPEN request with a result parameter set to ""refused"" and a diagnostic parameter indicating ""application context not supported"" or ""potential version incompatibility problem"", the MAP-User issues a new MAP-OPEN request primitive with the equivalent version y context (where 1 <= y < n). This is informally represented in the SDL diagrams by task symbols indicating 'Perform Vr procedure"". 18.2.4.2 Behaviour at the responding side On receipt of a MAP-OPEN indication primitive, the MAP-User analyses the application-context-name and executes the procedure associated with the requested version context. For example,if it refers to a version one context, the associated V1 procedure is executed; if it refers to a version two context, the associated V2 procedure is executed;etc. 18.2.5 Abort Handling Unless explicitly indicated in subsequent clauses, the following principles are applied by the MAP-user regarding abort handling procedures: On receipt of a MAP-P-ABORT indication or MAP-U-ABORT Indication primitive from any MAP-provider invocation, the MAP-User issues a MAP-U-ABORT Request primitive to each MAP-provider invocation associated with the same user procedure. If applicable a decision is made to decide if the affected user procedure has to be retried or not. 18.2.6 SDL conventions The MAP SDLs make use of a number of SDL concepts and conventions, where not all of them may be widely known. Therefore, this clauseÊoutlines the use of a few concepts and conventions to improve understanding of the MAP SDLs. The MAP User SDLs make use of SDL Processes, Procedures and Macros. Processes are independent from each other even if one process starts another one: The actions of both of them have no ordering in time. SDL Procedures and Macros are just used to ease writing of the specification: They contain parts of a behaviour used in several places, and the corresponding Procedure/Macro definition has to be expanded at the position of the Procedure/Macro call. All Processes are started at system initialisation and live forever, unless process creation/termination is indicated explicitly (i.e. a process is created by some other process). The direction of Input/Output Signals in the SDL graphs is used to indicate the entity to which/from which communication is directed. If a process A communicates in parallel with processes B and C, all Inputs/Outputs to/from B are directed to one side, whereas communication with C is directed to the other side. However, there has been no formal convention used that communication to a certain entity (e.g. a HLR) will always be directed to a certain side (e.g. right). In each state all those Input Signals are listed, which result in an action and/or state change. If an Input Signal is not listed in a state, receipt of this input should lead to an implicit consumption without any action or state change (according to the SDL rules). This implicit consumption is mainly used for receipt of the MAP DELIMITER indication and for receipt of a MAP CLOSE indication, except for a premature MAP CLOSE. 18.3 Interaction between MAP Provider and MAP Users Each MAP User is defined by at least one SDL process. On the dialogue initiating side, the MAP User will create a new instance of a MAP Provider implicit by issuing a MAP-OPEN request. This instance corresponds to a TC Dialogue and lives as long as the dialogue exists (see also clauseÊ14.3). There is a fixed relation between MAP User and this Provider instance, i.e. all MAP service primitives from the MAP User for this dialogue are sent to this instance and all TC components received by this MAP Provider are mapped onto service primitives sent to this MAP User. On the receiving side a MAP Provider instance is created implicit by receipt of a TC BEGIN indication. The corresponding MAP User is determined by the Application Context name included in this primitive, i.e. each Application Context is associated with one and only one MAP User. An instance of this User will be created implicitly by receiving a MAP-OPEN indication. Note that in some cases there exist several SDL Processes for one MAP User (Application Context), e.g. the processes Register_SS_HLR, Erase_SS_HLR, Activate_SS_HLR, Deactivate_SS_HLR, Interrogate_SS_HLR, and Register_Password for the AC Network_Functional_SS_Handling. In these cases, a coordinator process is introduced acting as a MAP User, which in turn starts a sub-process depending on the first MAP service primitive received. 19 Mobility procedures 19.1 Location management Procedures The signalling procedures in this clause support: - Interworking between the VLR and the HLR and between the VLR and the previous VLR (PVLR) when a non-GPRS subscriber performs a location update to a new VLR service area; - Interworking between the SGSN, the HLR and the VLR when a subscriber with both GPRS and non-GPRS subscriptions performs a routeing area update in an SGSN and the Gs interface is implemented; - Interworking between the SGSN and the VLR when a GPRS subscriber performs a routeing area update to a new SGSN service area; - Interworking between the HLR and the VLR and between the HLR and the SGSN to delete a subscriber record from the VLR or the SGSN; - Interworking between the VLR and the HLR and between the SGSN and the HLR to report to the HLR that a subscriber record has been purged from the VLR or the SGSN. The MAP co-ordinating process in the HLR to handle a dialogue opened with the network location updating context is shown in figure 19.1/1. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ19.1/1: Process Location_Management_Coordinator_HLR 19.1.1 Location updating 19.1.1.1 General The stage 2 specification for GPRS is in 3GPP TS 23.060 [104]. The interworking between the MAP signalling procedures and the GPRS procedures in the SGSN and the HLR is shown by the transfer of signals between these procedures. The message flow for successful inter-VLR location updating when the IMSI can be retrieved from the PVLR is shown in figure 19.1.1/2. The message flow for successful inter-VLR location updating when the IMSI cannot be retrieved from the PVLR is shown in figure 19.1.1/3. The message flow for successful GPRS Attach/RA update procedure (Gs interface not installed) is shown in figure 19.1.1/4. The message flow for successful GPRS Attach/RA update procedure combined with a successful VLR location updating (Gs interface installed) is shown in figure 19.1.1/5. PVLR = Previous VLR 1) A_LU_REQUEST (Note 1) 2) MAP_SEND_IDENTIFICATION_req/ind 3) MAP_SEND_IDENTIFICATION_rsp/cnf 4) MAP_UPDATE_LOCATION_req/ind 5) MAP_CANCEL_LOCATION_req/ind 6) MAP_CANCEL_LOCATION_rsp/cnf 7) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 2) 8) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 2) 9) MAP_INSERT_SUBSCRIBER_DATA_req/ind 10) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 11) MAP_UPDATE_LOCATION_rsp/cnf 12) A_LU_CONFIRM (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TSÊ24.008Ê[35]. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: Services printed in italics are optional. FigureÊ19.1.1/2: Message flow for location updating to a new VLR area, when the IMSI can be retrieved from the previous VLR PVLR = Previous VLR 1) A_LU_REQUEST (Note 1) 2) A_IDENTITY_REQUEST (Note 1) 3) A_IDENTITY_RESPONSE (Note 1) 4) MAP_UPDATE_LOCATION_req/ind 5) MAP_CANCEL_LOCATION_req/ind 6) MAP_CANCEL_LOCATION_rsp/cnf 7) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 2) 8) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 2) 9) MAP_INSERT_SUBSCRIBER_DATA_req/ind 10) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 11) MAP_UPDATE_LOCATION_rsp/cnf 12) A_LU_CONFIRM (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TSÊ24.008Ê[35]. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: Services printed in italics are optional. FigureÊ19.1.1/3: Message flow for location updating to a new VLR area, when the IMSI cannot be retrieved from the previous VLR PSGSN = Previous SGSN 1) Gb_ATTACH_REQUEST or RA_UPDATE_REQUEST (Note 1, note 2) 2) MAP_UPDATE_GPRS_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_req/ind 4) MAP_CANCEL_LOCATION_rsp/cnf 5) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 3) 6) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 3) 7) MAP_INSERT_SUBSCRIBER_DATA_req/ind 8) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 9) MAP_UPDATE_GPRS_LOCATION_rsp/cnf 10) Gb_ATTACH_ACCEPT or RA_UPDATE_ACCEPT (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TSÊ24.008Ê[35]. The services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For security functions (authentication, ciphering, IMEI check) triggering refer to 3GPP TSÊ23.060Ê[104]. The MAP signalling invoked for these functions is described in clauseÊ25 of the present document. NOTE 3: Services printed in italics are optional. NOTE 4: Refer to 3GPP TSÊ23.060Ê[104] for termination of the procedure and triggering of the signalling on the interface between the BSS and the SGSN. FigureÊ19.1.1/4: Message flow for GPRS location updating (Gs interface not installed) 1) Gb_ATTACH_REQUEST or RA_UPDATE_REQUEST (Note 1, note 2) 2) MAP_UPDATE_GPRS_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_req/ind 4) MAP_CANCEL_LOCATION_rsp/cnf 5) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 3) 6) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 3) 7) MAP_INSERT_SUBSCRIBER_DATA_req/ind 8) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 9) MAP_UPDATE_GPRS_LOCATION_rsp/cnf 10) Gs_LOCATION_UPDATE_REQUEST (Note 4) 11) MAP_UPDATE_LOCATION_req/ind (Note 5) 12) MAP_INSERT_SUBSCRIBER_DATA_req/ind 13) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 14) MAP_UPDATE_LOCATION_rsp/cnf 15) Gs_LOCATION_UPDATE_ACCEPT (Note 4) 16) Gb_ATTACH_ACCEPT or RA_UPDATE_ACCEPT (Note 1) 17) Gb_TMSI_REALLOCATION_COMPLETE (Note 1) 18) Gs_TMSI_REALLOCATION_COMPLETE (Note 4) NOTE 1: For details of the procedure on the radio path, see 3GPP TSÊ24.008Ê[35]. The services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For security functions (authentication, ciphering, IMEI check) triggering refer to 3GPP TSÊ23.060Ê[104]. MAP processes invoked for those procedures are described in clauseÊ25.5. NOTE 3: Services printed in italics are optional. NOTE 5: For details of the procedure on the path between the SGSN and the VLR, see 3GPP TSÊ29.018Ê[106]. The services shown in chain lines indicate the trigger provided by the signalling on the path between the SGSN and the VLR, and the signalling triggered on the path between the SGSN and the VLR. NOTE 4: Refer to 3GPP TSÊ23.060Ê[104] for termination of the procedure and triggering of the signalling on the interface between the BSS and the SGSN. NOTE 5: For simplicity, the Location Cancellation procedure towards the previous VLR and optional tracing activation towards the new VLR are not shown in this figure. FigureÊ19.1.1/5: Message flow for GPRS location updating (Gs interface installed) 19.1.1.2 Procedures in the VLR The MAP process in the VLR for location updating for a non-GPRS subscriber is shown in figure 19.1.1/6. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP process in the VLR to retrieve the IMSI of a subscriber from the previous VLR (PVLR) is shown in figure 19.1.1/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The process in the VLR for location updating for a GPRS subscriber when the Gs interface is installed is shown in figure 19.1.1/8. The macro GPRS_Location_Update_Completion_VLR is shown in figure 19.1.1/9. The macro invokes a process not defined in this clause; the definition of this process can be found as follows: Subscriber_Present_VLR see clauseÊ25.10.1. The macro GPRS_Update_HLR_VLR is shown in figure 19.1.1/10. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2; Insert_Subs_Data_VLR see clauseÊ25.7.1; Activate_Tracing_VLR see clauseÊ25.9.4. 19.1.1.3 Procedure in the PVLR The MAP process in the PVLR to handle a request for the IMSI of a subscriber from the new VLR is shown in figure 19.1.1/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 19.1.1.4 Procedure in the SGSN The MAP process in the SGSN for location updating for a GPRS subscriber is shown in figure 19.1.1/12. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2; Insert_Subs_Data_SGSN see clauseÊ25.7.2; Activate_Tracing_SGSN see clauseÊ25.9.5. Sheet 2: The procedure Check_User_Error_In_Serving_Network_Entity is specific to Super-Charger; it is specified in 3GPP TSÊ23.116 [110]. 19.1.1.5 Procedures in the HLR The MAP process in the HLR to handle a location updating request from a VLR is shown in figure 19.1.1/13. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. The MAP process in the HLR to handle a location updating request from an SGSN is shown in figure 19.1.1/14. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2; Control_Tracing_With_SGSN_HLR see clauseÊ25.9.7. Sheet 2: The procedure Super_Charged_Cancel_Location_HLR is specific to Super-Charger; it is specified in 3GPPÊTSÊ23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the ""No"" exit of the test ""Result=Pass?"". Sheet 2: The procedure Super_Charged_Location_Updating_HLR is specific to Super-Charger; it is specified in 3GPPÊTSÊ23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the ""No"" exit of the test ""Result=Pass?"". Sheet 2: If the HLR supports the Administrative Restriction of Subscribers' Access feature and roaming is allowed in the VPLMN then the HLR may check the ""Supported RAT Types"" received from the VLR against the access restriction parameters. If this check fails then the decision box ""Roaming allowed in this PLMN"" shall take the exit ""No"". The MAP process in the HLR to notify Short Message Service Centres that a subscriber is now reachable is shown in figure 19.1.1/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Alert_Service_Centre_HLR see clauseÊ25.10.3. Figure 19.1.1/6 (sheet 1 of 2): Process Update_Location_VLR Figure 19.1.1/6 (sheet 2 of 2): Process Update_Location_VLR Figure 19.1.1/7 (sheet 1 of 2): Process Send_Identification_VLR Figure 19.1.1/7 (sheet 2 of 2): Process Send_Identification_VLR FigureÊ19.1.1/8 (sheet 1 of 2): Process GPRS_Update_Location_Area_VLR FigureÊ19.1.1/8 (sheet 2 of 2): Process GPRS_Update_Location_Area_VLR FigureÊ19.1.1/9: Macro GPRS_Location_Update_Completion_VLR FigureÊ19.1.1/10 (sheet 1 of 2): Macro GPRS_Update_HLR_VLR FigureÊ19.1.1/10 (sheet 2 of 2): Macro GPRS_Update_HLR_VLR Figure 19.1.1/11 (sheet 1 of 2): Process Send_Identification_PVLR Figure 19.1.1/11 (sheet 2 of 2): Process Send_Identification_PVLR FigureÊ19.1.1/12 (sheet 1 of 2): Process Update_GPRS_Location_SGSN FigureÊ19.1.1/12 (sheet 2 of 2): Process Update_GPRS_Location_SGSN FigureÊ19.1.1/13 (sheet 1 of 3): Process Update_Location_HLR FigureÊ19.1.1/13 (sheet 2 of 3): Process Update_Location_HLR FigureÊ19.1.1/13 (sheet 3 of 3): Process Update_Location_HLR FigureÊ19.1.1/14 (sheet 1 of 2): Process Update_GPRS_Location_HLR FigureÊ19.1.1/14 (sheet 2 of 2): Process Update_GPRS_Location_HLR FigureÊ19.1.1/15: Process Subscriber_Present_HLR 19.1.1A Location updating for VCSG 19.1.1A.1 General The message flow for successful VCSG location updating between VLR and CSS or between SGSN and CSS is shown in figure 19.1.1A/1. 1) MAP_UPDATE_VCSG_LOCATION_req/ind 2) MAP_INSERT_SUBSCRIBER_DATA_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 4) MAP_UPDATE_VCSG_LOCATION_rsp/cnf Figure 19.1.1A/1: Message flow for VCSG location updating 19.1.1A.2 Procedures in the VLR The MAP process in the VLR for VCSG location updating for a roaming subscriber is shown in figure 19.1.1A/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Insert_Subs_Data_VLR see clause 25.7.2. 19.1.1A.3 Procedures in the SGSN The MAP process in the SGSN for VCSG location updating for a roaming subscriber is shown in figure 19.1.1A/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Insert_Subs_Data_SGSN see clause 25.7.2. 19.1.1A.4 Procedures in the CSS The MAP process in the CSS to handle a VCSG location updating request from a VLR or SGSN is shown in figure 19.1.1A/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1; Check_Indication see clause 25.2.1; Check_Confirmation see clause 25.2.2; Insert_VCSG_Subs_Data_Framed_CSS see clause 19.5A.1. Figure 19.1.1A/2 (sheet 1 of 2): Process Update_VCSG_Location_VLR Figure 19.1.1A/2 (sheet 2 of 2): Process Update_VCSG_Location_VLR Figure 19.1.1A/3 (sheet 1 of 2): Process Update_VCSG_Location_SGSN Figure 19.1.1A/3 (sheet 2 of 2): Process Update_VCSG_Location_SGSN Figure 19.1.1A/4 (sheet 1 of 2): Process Update_VCSG_Location_CSS Figure 19.1.1A/4 (sheet 2 of 2): Process Update_VCSG_Location_CSS 19.1.2 Location Cancellation 19.1.2.1 General Location cancellation is used to delete a subscriber record from the serving node (VLR or SGSN). The procedure is invoked: - because the subscriber has registered with a new serving node, or - because the HPLMN operator has decided to delete the subscriber record from the serving node, e.g. because the subscription has been withdrawn, or because roaming restrictions have been imposed. Location cancellation can be used to force location updating including updating of subscriber data in the serving node at the next subscriber access. The message flow for location cancellation for a non-GPRS subscriber is shown in figure 19.1.2/1. The message flow for location cancellation for a GPRS subscriber is shown in figure 19.1.2/2. 1) MAP_UPDATE_LOCATION_req/ind 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf NOTE: The service shown in dotted lines indicates the trigger provided by other MAP signalling. FigureÊ19.1.2/1: Message flow for Location Cancellation (non-GPRS) 1) MAP_UPDATE_GPRS_LOCATION_req/ind 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf NOTE: The service shown in dotted lines indicates the trigger provided by other MAP signalling. FigureÊ19.1.2/2: Message flow for Location Cancellation (GPRS) 19.1.2.2 Procedure in the HLR The MAP process in the HLR to cancel the location information in a VLR is shown in figure 19.1.2/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP process in the HLR to cancel the location information in a VLR as an independent process invoked from another process is shown in figure 19.1.2/4. The MAP process in the HLR to cancel the location information in an SGSN is shown in figure 19.1.2/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP process in the HLR to cancel the location information in an SGSN as an independent process invoked from another process is shown in figure 19.1.2/6. 19.1.2.3 Procedure in the VLR The MAP process in the VLR to handle a location cancellation request is shown in figure 19.1.2/7. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 19.1.2.4 Procedure in the SGSN The MAP process in the SGSN to handle a location cancellation request is shown in figure 19.1.2/8. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ19.1.2/3: Process Cancel_Location_HLR FigureÊ19.1.2/4: Process Cancel_Location_Child_HLR FigureÊ19.1.2/5: Process Cancel_GPRS_Location_HLR FigureÊ19.1.2/6: Process Cancel_GPRS_Location_Child_HLR FigureÊ19.1.2/7: Process Cancel_Location_VLR FigureÊ19.1.2/8: Process Cancel_Location_SGSN 19.1.2A Location Cancellation for VCSG 19.1.2A.1 General Location cancellation for VCSG is used to delete a subscriber record from the serving node (VLR or SGSN). The procedure is invoked: - because there is a removal of the CSG subscription data in the CSS and of the MS registration - because the CSS has decided to cancel the registration of the MS which does not have CSG subscription data in the CSS. NOTE: How the CSS determines when to cancel the registration of the MS is implementation dependent. The message flow for VCSG location cancellation for a subscriber is shown in figure 19.1.2A/1. 1) MAP_CANCEL_VCSG_LOCATION_req/ind 2) MAP_CANCEL_VCSG_LOCATION_rsp/cnf FigureÊ19.1.2A/1: Message flow for VCSG Location Cancellation 19.1.2A.2 Procedure in the CSS The MAP process in the CSS to cancel the VCSG location information in a VLR is shown in figure 19.1.2A/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP process in the CSS to cancel the VCSG location information in a SGSN is shown in figure 19.1.2A/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 19.1.2A.3 Procedure in the VLR The MAP process in the VLR to handle a VCSG location cancellation request is shown in figure 19.1.2A/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 19.1.2A.4 Procedure in the SGSN The MAP process in the SGSN to handle a VCSG location cancellation request is shown in figure 19.1.2A/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ19.1.2A/2: Process Cancel_VCSG_Location_CSS FigureÊ19.1.2A/3: Process Cancel_VCSG_Location_VLR FigureÊ19.1.2A/4: Process Cancel_VCSG_Location_SGSN 19.1.3 Void 19.1.4 MS Purging 19.1.4.1 General O&M procedures in the VLR or SGSN can trigger MS purging either because of administrative action or because the MS has been inactive for an extended period. The O&M process in the VLR or in the SGSN should ensure that during the MS purging procedure any other attempt to access the MS record is blocked, to maintain consistency of data. The message flow for a VLR to report MS purging to the HLR is shown in figure 19.1.4/1. The message flow for an SGSN to report MS purging to the HLR is shown in figure 19.1.4/2. 1) MAP_PURGE_MS_req/ind 2) MAP_PURGE_MS_rsp/cnf FigureÊ19.1.4/1: Message flow for MS purging (non-GPRS) 1) MAP_PURGE_MS_req/ind 2) MAP_PURGE_MS_rsp/cnf FigureÊ19.1.4/2: Message flow for MS purging (GPRS) 19.1.4.2 Procedure in the VLR The MAP process in the VLR to report MS purging to the HLR is shown in figure 19.1.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 19.1.4.3 Procedure in the SGSN The MAP process in the SGSN to report MS purging to the HLR is shown in figure 19.1.4/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: The procedure Purge_MS_In_Serving_Network_Entity is specific to Super-Charger; it is specified in 3GPP TSÊ23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the ""No"" exit of the test ""Result=Pass?"". 19.1.4.4 Procedure in the HLR The MAP process in the HLR to handle a notification from a VLR or an SGSN that an MS record has been purged is shown in figure 19.1.4/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. If the notification was received from a VLR, the MAP process communicates with the location management application process specified in 3GPPÊTSÊ23.012Ê[23]; if the notification was received from an SGSN, the MAP process communicates with the GPRS mobility management application process specified in 3GPPÊTSÊ23.060Ê[104]. FigureÊ19.1.4/3: Process Purge_MS_VLR FigureÊ19.1.4/4 (sheet 1 of 2): Process Purge_MS_SGSN FigureÊ19.1.4/4 (sheet 2 of 2): Process Purge_MS_SGSN FigureÊ19.1.4/5: Process Purge_MS_HLR 19.2 Handover procedures 19.2.1 General In this clause, the term ""Inter-MSC handover"" is used to denote handover or relocation between different MSCs. The interfaces involved for Inter-MSC handover are shown in figureÊ19.2/1. There are two Inter-MSC handover procedures: 1) Basic Inter-MSC handover: The call is handed over from the controlling MSC(MSCÑA) to another MSC(MSCÑB) (figureÊ19.2/1a). FigureÊ19.2/2 shows the message flow for a successful handover from MSC A to MSCÑB, including a request for handover number allocation from MSC B to VLR B. 2) Subsequent Inter-MSC handover: After the call has been handed over from MSC A to MSC B, a further handover either to MSC A (figureÊ19.2/1a) or to a third MSC (MSC B') (figureÊ19.2/1b) may be necessary in order to continue the call. FigureÊ19.2/3 shows the message flow for a successful subsequent handover to MSC B'. For a successful subsequent handover to MSC A, the messages to and from MSC B' and VLR B' are omitted.. a) Basic handover procedure MSC A to MSC B and subsequent handover procedure MSC B to MSC A. b) Subsequent handover procedure MSC B to MSC B'. FigureÊ19.2/1: Interface structure for handover 1) MAP_PREPARE_HANDOVER_req/ind 2) MAP_ALLOCATE_HANDOVER_NUMBER_req/ind 3) MAP_SEND_HANDOVER_REPORT_req/ind 4) MAP_PREPARE_HANDOVER_rsp/cnf 5) MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note) 6) MAP_PROCESS_ACCESS_SIGNALLING_req/ind 7) MAP_SEND_END_SIGNAL_req/ind 8) MAP_FORWARD_ACCESS_SIGNALLING_req/ind 9) MAP_PROCESS_ACCESS_SIGNALLING_req/ind 10) MAP_SEND_END_SIGNAL_rsp/cnf NOTE: This can be sent at any time after the connection between MSC A and MSC B is established. FigureÊ19.2/2: Example of a successful basic handover procedure to MSC B 1) MAP_PREPARE_HANDOVER_req/ind 2) MAP_ALLOCATE_HANDOVER_NUMBER_req/ind 3) MAP_SEND_HANDOVER_REPORT_req/ind 4) MAP_PREPARE_HANDOVER_rsp/cnf 5) MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note 1) 6) MAP_PROCESS_ACCESS_SIGNALLING_req/ind 7) MAP_SEND_END_SIGNAL_req/ind 8) MAP_PREPARE_SUBSEQUENT_HANDOVER_req/ind 9) MAP_PREPARE_HANDOVER_req/ind 10) MAP_ALLOCATE_HANDOVER_NUMBER_req/ind 11) MAP_SEND_HANDOVER_REPORT_req/ind 12) MAP_PREPARE_HANDOVER_rsp/cnf 13) MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note 2) 14) MAP_PREPARE_SUBSEQUENT_HANDOVER_rsp/cnf 15) MAP_PROCESS_ACCESS_SIGNALLING_req/ind 16) MAP_SEND_END_SIGNAL_req/ind 17) MAP_SEND_END_SIGNAL_rsp/cnf (Note 3) NOTE 1: This can be sent at any time after the connection between MSC A and MSC B is established. NOTE 2: This can be sent at any time after the connection between MSC A and MSC B' is established. NOTE 3: At this stage, the subsequent handover is complete. Any further interworking between MSC A and MSC B' is the same as the interworking between MSC A and MSC B after basic handover FigureÊ19.2/3: Example of a successful subsequent handover to a third MSC The MAP signalling procedures for inter-MSC handover support the allocation of a handover number or one or more relocation numbers and the transfer of encapsulated BSSAP or RANAP messages. The minimum application context version for the MAP handover application context shall be: - version 3 for inter-MSC UTRAN to UTRAN handover; - version 3 for inter-MSC intersystem handover from GSM BSS to UTRAN; - version 2 for inter-MSC intersystem handover from UTRAN to GSM BSS. NOTE: If the MAP handover application context version 2 is used, subsequent handover to UTRAN is not possible. The minimum application context version for the MAP handover application context should be version 2 for inter-MSC handover from GSM BSS to GSM BSS. NOTE: If the MAP handover application context version 2 or lower is used, subsequent handover to UTRAN is not possible. The BSSAP or RANAP messages encapsulated in MAP messages are processed by the Handover Control Application in each MSC. The information in the encapsulated BSSAP or RANAP messages is passed from the Handover Control Application to the MAP process at the sending end; the notation used in the SDL diagrams for the MAP processes is ""HO_CA_MESSAGE_ind(Message transfer)"". The information in the encapsulated BSSAP or RANAP messages is passed from the MAP process to the Handover Control Application at the sending end; the notation used in the SDL diagrams for the MAP processes is ""HO_CA_MESSAGE_req(Message transfer)"". For details of the interworking between the A-interface and MAP procedures or the Iu-interface and MAP procedures, see 3GPP TSÊ23.009Ê[21] and 3GPP TSÊ29.010Ê[58]. 19.2.2 Procedure in MSC A This clause describes the inter-MSC handover procedure in MSC A; it covers basic inter-MSC handover to another MSC (MSC B) and subsequent inter-MSC handover to a third MSC (MSC B') or back to the controlling MSC (MSC A). The MAP process in MSC A to handle inter-MSC handover is shown in figure 19.2/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1. Check_Confirmation see clauseÊ25.2.2. Communication between the MAP handover process and the Handover Control application is represented by the HO_CA_MESSAGE service. For a detailed description of the interworking between the Handover Control applications in different MSCs for the inter-MSC handover procedure, see 3GPP TSÊ23.009Ê[21]. 19.2.2.1 Basic handover The handling in MSC A for basic inter-MSC handover is shown in sheets 1 to 6 of figure 19.2/4."
"Sheet 1: The MAP_PREPARE_HANDOVER request may contain: - an indication that handover number allocation is not required; - the target Cell ID, for compatibility for handover to GSM; - the target RNC ID, for SRNS relocation or inter-system handover from GSM to UMTS; - the IMSI; - UMTS encryption information and UMTS integrity protection information, which are necessary for inter-system handover from GSM to UMTS; - GSM radio resource information (channel type); - the LCLS Global Call Reference; - the LCLS-Negotiation; - the LCLS-Configuration-Preference. The conditions for the presence of these parameters and the processing in MSC B (3G_MSC B) are described in detail in 3GPPÊTSÊ29.010Ê[58], 3GPPÊTSÊ23.009Ê[21] and 3GPPÊTSÊ29.205Ê[146]. Sheet 2: The MAP_PREPARE_HANDOVER confirmation contains one of: - no handover number, if the MAP_PREPARE_HANDOVER request included an indication that handover number allocation is not required; - a handover number; - one or more relocation numbers. Sheet 2: The MAP_PREPARE_HANDOVER confirmation contains BSSAP or RANAP signalling information, which is passed to the Handover Control application in MSC A. Sheet 2: If the MAP_PREPARE_HANDOVER confirmation contains an indication that MSC B does not support multiple bearers, the Handover Control application in MSC A may request handover of one bearer to the same cell in MSC B. Sheet 5: If the original MAP_PREPARE_HANDOVER request included a parameter indicating that handover number allocation is not required, the Handover Control application in MSC A may request a handover number (or one or more relocation numbers); this triggers a further MAP_PREPARE_HANDOVER request towards MSC B. 19.2.2.2 Handling of access signalling The Handover Control application in MSC A may forward access signalling to any of the MS, RNS B or BSS B using the MAP_FORWARD_ACCESS_SIGNALLING service; any of the MS, RNS B or BSS B may forward access signalling to the Handover Control application in MSC A using the MAP_PROCESS_ACCESS_SIGNALLING service. These are non-confirmed services. 19.2.2.3 Subsequent handover The handling in MSC A for subsequent inter-MSC handover is shown in sheets 7 & 8 of figure 19.2/4. If the Handover Control Application determines that the call is to be handed over to a third MSC (MSC B') it triggers another instance of the MAP process to handle the basic handover to MSC B', and reports the result of the subsequent handover to the instance of the MAP process which handles the dialogue with MSC B. Sheet 8: While the MAP process in MSC A is waiting for the completion of subsequent handover, it relays access signalling between the Handover Control application and the MS, RNS B or BSS B as described in clause 19.2.2.2. 19.2.3 Procedure in MSC B This clause describes the handover or relocation procedure in MSC B; it covers basic handover or relocation from the controlling MSC (MSC A) and subsequent handover or relocation. The MAP process in MSC B to handle handover or relocation is shown in figure 19.2/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1. Check_Confirmation see clauseÊ25.2.2. Communication between the MAP handover process and the Handover Control application is represented by the HO_CA_MESSAGE service. For a detailed description of the interworking between the Handover Control applications in different MSCs for the inter-MSC handover procedure, see 3GPP TSÊ23.009Ê[21]. The ordering of allocation of handover number and radio resources shown in the SDL diagrams is not mandatory. 19.2.3.1 Basic handover The handling in MSC B for basic inter-MSC handover is shown in sheets 1 to 7 of figure 19.2/5. Sheet 2: If the MAP_PREPARE_HANDOVER indication included a parameter requesting multiple bearers but MSC B does not support multiple bearers, MSC B sends a MAP_PREPARE_HANDOVER response indicating that multiple bearers are not supported, and waits for a possible MAP_PREPARE_HANDOVER indication requesting handover of a single bearer. Sheet 6: If the original MAP_PREPARE_HANDOVER indication included a parameter indicating that handover number allocation is not required, MSC A may send a further MAP_PREPARE_HANDOVER request to request the allocation of a handover number (or one or more relocation numbers). 19.2.3.2 Handling of access signalling The Handover Control application in MSC A may forward access signalling to any of the MS, RNS B or BSS B using the MAP_FORWARD_ACCESS_SIGNALLING service; any of the MS, RNS B or BSS B may forward access signalling to the Handover Control application in MSC A using the MAP_PROCESS_ACCESS_SIGNALLING service. These are non-confirmed services. Signals to or from any of the MS, RNS B or BSS B are routed through the Handover Control application in MSC B. 19.2.3.3 Subsequent handover The handling in MSC B for subsequent inter-MSC handover is shown in sheet 8 of figure 19.2/5. While the MAP process in MSC B is waiting for the completion of subsequent handover, it relays access signalling between MSC A and the MS, RNS B or BSS B through the Handover Control application as described in clause 19.2.3.2. 19.2.4 Macro Receive_Error_From_HO_CA This macro is used by the handover processes in MSC A and MSC B to receive errors from the Handover Control Application at any state of a handover process. 19.2.5 Procedure in VLR B The process in VLR-B to handle a request for a handover number is shown in figure 19.2/7. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. FigureÊ19.2/4 (sheet 1 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 2 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 3 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 4 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 5 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 6 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 7 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 8 of 8): Process HO_MSC_A FigureÊ19.2/5 (sheet 1 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 2 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 3 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 4 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 5 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 6 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 7 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 8 of 8): Process HO_MSC_B FigureÊ19.2/6: Macro Receive_error_from_HO_CA FigureÊ19.2/7: Process HO_VLR_B 19.3 Fault recovery procedures When a location register has restarted after a fault, the fault recovery procedures ensure that the subscriber data in the VLR or in the SGSN become consistent with the subscriber data that are stored in the HLR for the MS concerned and that the location information in the HLR , the VLR and the SGSN reflect accurately the current location of the MS. The stage 2 specification of fault recovery procedures in location registers is 3GPP TS 23.007 [19]. 19.3.1 VLR fault recovery procedures 19.3.1.1 General Restoration of an IMSI record in a VLR can be triggered by a location registration request from the MS or by a request from the HLR for a roaming number to route a mobile terminated call to the MS. If the restoration is triggered by a location registration request from the MS, the VLR performs the location updating procedure described in 3GPPÊTSÊ23.012Ê[23] and clause 19.1.1 of the present document. If the restoration is triggered by a request for a roaming number, the VLR provides the roaming number and triggers an independent dialogue to restore the subscriber data as described in 3GPPÊTSÊ23.018Ê[97]. The message flow for data restoration triggered by a request for a roaming number is shown in figure 19.3.1/1. 1) MAP_PROVIDE_ROAMING_NUMBER_req/ind 2) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf 3) MAP_SEND_AUTHENTICATION_INFO_req/ind (Note 1, note 2) 4) MAP_SEND_AUTHENTICATION_INFO_rsp/cnf (Note 1, note 2) 5) MAP_RESTORE_DATA_req/ind 6) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, note 3) 7) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, note 3) 8) MAP_INSERT_SUBSCRIBER_DATA_req/ind 9) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 10) MAP_RESTORE_DATA_rsp/cnf NOTE 1: Services printed in italics are optional. NOTE 2: If authentication is required. NOTE 3: If subscriber tracing is active in the HLR. FigureÊ19.3/1: Message flow for VLR restoration at mobile terminated call set-up 19.3.1.2 Procedure in the VLR The procedure in the VLR to handle a dialogue for subscriber data restoration is defined in clauseÊ21.2.6 of the present document. 19.3.1.3 Procedure in the HLR The MAP process in the HLR to handle a request for data restoration in the VLR is shown in figure 19.3.1/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clauseÊ25.2.1; Control_Tracing_With_VLR_HLR see clauseÊ25.9.6. FigureÊ19.3.1/2: Process Restore_Data_HLR 19.3.2 HLR fault recovery procedures 19.3.2.1 General For the HLR, periodic back-up of data to non-volatile memory is mandatory. Data that have been changed after the last back-up and before the restart of the HLR cannot be recovered by reload from the non-volatile memory. Therefore, a restoration procedure is triggered for each IMSI record that has been affected by the HLR fault at the first authenticated radio contact with the MS concerned. As an implementation option, a notification can be forwarded to the MS to alert the subscriber to check the parameters for supplementary services that allow subscriber controlled input (MAP_FORWARD_CHECK_SS_INDICATION service). If the VLR receives this notification from the HLR it shall forward the notification to the MS. If the Gs-interface is implemented the VLR shall not forward this notification. A restoration procedure may also be triggered for IMSI records that shares subscription data with other IMSI records when the shared subscription data is modified, added or deleted. This option presumes the support of Reset-IDs. The message flow for HLR restoration for a non-GPRS subscriber is shown in figure 19.3.2/1. The message flow for HLR restoration for a GPRS subscriber is shown in figure 19.3.2/2. 1) MAP_RESET_req/ind 2) MAP_PROCESS_ACCESS_REQUEST_req/ind 3) MAP_UPDATE_LOCATION_req/ind 4) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, Note 2) 5) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, Note 2) 6) MAP_INSERT_SUBSCRIBER_DATA_req/ind 7) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 8) MAP_UPDATE_LOCATION_rsp/cnf 9) MAP_FORWARD_CHECK_SS_INDICATION_req/ind (Note 1) 10) MAP_FORWARD_CHECK_SS_INDICATION_req/ind (Note 1) NOTE 1: Services printed in italics are optional. NOTE 2: If subscriber tracing is active in the HLR. Steps 2 to 10 may be skipped if the procedure is used to update shared subscription data. FigureÊ19.3.2/1: Message flow for HLR restoration (non-GPRS) 1) MAP_RESET_req/ind 2) MAP_UPDATE_GPRS_LOCATION_req/ind 3) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, Note 2) 4) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, Note 2) 5) MAP_INSERT_SUBSCRIBER_DATA_req/ind 6) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 7) MAP_UPDATE_GPRS_LOCATION_rsp/cnf NOTE 1: Services printed in italics are optional. NOTE 2: If subscriber tracing is active in the HLR. Steps 2 to 7 may be skipped if the procedure is used to update shared subscription data. FigureÊ19.3.2/2: Message flow for HLR restoration (GPRS) 19.3.2.2 Procedure in the HLR The MAP process in the HLR to notify the relevant serving nodes that the HLR has restarted is shown in figure 19.3.2/3. The SGSN address list includes one instance of the address of each SGSN in which (according to the HLR data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the HLR restart. The VLR address list includes one instance of the address of each VLR in which (according to the HLR data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the HLR restart. The MAP process in the HLR to notify a VLR that the HLR has restarted is shown in figure 19.3.2/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2. The MAP process in the HLR to notify an SGSN that the HLR has restarted is shown in figure 19.3.2/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2. 19.3.2.3 Procedure in the VLR The MAP process in the VLR to handle a notification that an HLR has restarted is shown in figure 19.3.2/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. When Reset-IDs are not supported or not present in the MAP_RESET indication, the VLR uses the HLR number or the HLR identity list included in the MAP_RESET indication to identify the IMSI records which are affected by the HLR restart. When Reset-IDs are supported and present in the MAP_RESET indication, the VLR uses the Reset-IDs included in the MAP_RESET indication to identify the affected IMSI records. The task ""Update Data"" includes any required action to let the update come into effect. If the update of shared subscription data requires only local updates in the VLR (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring). If the update of shared subscription data implies initiating a signalling interaction towards other nodes, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE. NOTE: The rational for the recommendationÊto defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user's activity. To avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the VLR may take a maximum operator configuration-depending time. 19.3.2.4 Procedure in the SGSN The MAP process in the SGSN to handle a notification that an HLR has restarted is shown in figure 19.3.2/7. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. When Reset-IDs are not supported or not present in the MAP_RESET indication, the SGSN uses the HLR number or the HLR identity list included in the MAP_RESET indication to identify the IMSI records which are affected by the HLR restart. When Reset-IDs are supported and present in the MAP_RESET indication, the SGSN uses the Reset-IDs included in the MAP_RESET indication to identify the affected IMSI records. The task ""Update Data"" includes any required action to let the update come into effect. If the update of shared subscription data requires only local updates in the SGSN (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring). If the update of shared subscription data implies initiating a signalling interaction towards other nodes, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE. NOTE: The rational for the recommendationÊto defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user's activity. To avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the SGSN may take a maximum operator configuration-depending time. FigureÊ19.3.2/3: Process Restart_HLR FigureÊ19.3.2/4: Process Send_Reset_To_VLR_HLR FigureÊ19.3.2/5: Process Send_Reset_To_SGSN_HLR FigureÊ19.3.2/6: Process Receive_Reset_VLR FigureÊ19.3.2/7: Process Receive_Reset_SGSN 19.3.3 CSS fault recovery procedures 19.3.3.1 General For the CSS, periodic back-up of data to non-volatile memory is mandatory. Serving node numbers that have been changed after the last back-up and before the restart of the CSS cannot be recovered by reload from the non-volatile memory. Therefore, a restoration procedure is triggered for each IMSI record that has been affected by the CSS fault at the first authenticated radio contact with the MS concerned. The message flow for CSS restoration for a non-GPRS subscriber is shown in figure 19.3.3/1. The message flow for CSS restoration for a GPRS subscriber is shown in figure 19.3.3/2. 1) MAP_RESET_req/ind 2) MAP_UPDATE_VCSG_LOCATION_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_req/ind 4) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 5) MAP_UPDATE_VCSG_LOCATION_rsp/cnf Figure 19.3.3/1: Message flow for CSS restoration (non-GPRS) 1) MAP_RESET_req/ind 2) MAP_UPDATE_VCSG_LOCATION_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_req/ind 4) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 5) MAP_UPDATE_VCSG_LOCATION_rsp/cnf Figure 19.3.3/2: Message flow for CSS restoration (GPRS) 19.3.3.2 Procedure in the CSS The MAP process in the CSS to notify the relevant serving nodes that the CSS has restarted is shown in figure 19.3.3/3. The SGSN address list includes one instance of the address of each SGSN in which (according to the CSS data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the CSS restart. The VLR address list includes one instance of the address of each VLR in which (according to the CSS data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the CSS restart. The MAP process in the CSS to notify a VLR that the CSS has restarted is shown in figure 19.3.3/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clause 25.1.2. The MAP process in the CSS to notify an SGSN that the CSS has restarted is shown in figure 19.3.3/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clause 25.1.2. 19.3.3.3 Procedure in the VLR The MAP process in the VLR to handle a notification that a CSS has restarted is shown in figure 19.3.3/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1. The VLR uses the CSS number (filled in Sending Node number parameter) included in the MAP_RESET indication to identify the user's IMSI records which are affected by the CSS restart. 19.3.3.4 Procedure in the SGSN The MAP process in the SGSN to handle a notification that a CSS has restarted is shown in figure 19.3.3/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1. The SGSN uses the CSS number (filled in Sending Node number parameter) included in the MAP_RESET indication to identify the user's IMSI records which are affected by the CSS restart. Figure 19.3.3/3: Process Restart_CSS Figure 19.3.3/4: Process Send_Reset_To_VLR_CSS Figure 19.3.3/5: Process Send_Reset_To_SGSN_CSS Figure 19.3.3/6: Process Receive_Reset_From_CSS_VLR Figure 19.3.3/7: Process Receive_Reset_From_CSS_SGSN 19.4 Mobility Management event notification procedure 19.4.1 General The Mobility Management event notification procedure is used to notify a gsmSCF about the successful completion of a Mobility Management event. The message flow for Mobility Management event notification is shown in figure 19.4/1. 1) MAP_REPORT_MM_EVENT_req/ind 2) MAP_REPORT_MM_EVENT_rsp/cnf FigureÊ19.5/1: Message flow for Mobility Management event notification 19.4.2 Procedure in the VLR or SGSN The MAP process in the VLR or the SGSN to report a Mobility Management event to the gsmSCF is shown in figure 19.4/2.The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation: see clauseÊ25.2.2. 19.4.3 Procedure in the gsmSCF The MAP process in the gsmSCF to handle the report of a Mobility Management event is shown in figure 19.4/3.The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; FigureÊ19.4/2: Process Notify_MM_Event_VLR_Or_SGSN Figure 19.4/3: Process Notify_MM_Event_gsmSCF 19.5 HLR Insert Subscriber Data macros 19.5.1 Macro Insert_Subs_Data_Framed_HLR This macro is used to transfer subscriber data to the VLR as part of an existing dialogue for location updating or data restoration. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows: Wait_For_Insert_Subs_Data_Cnf see clauseÊ25.7.5; Send_Insert_Subs_Data_HLR: see clauseÊ25.7.7. The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. If the VLR has indicated that it does not support a service or feature (e.g. Closed User Group or Advice Of Charge Charging Level) which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restriction Due To Unsupported Feature flag to roaming restricted and sends Roaming Restriction Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. If subscriber data for CAMEL Phase 2 or later services are sent to a VLR which does not support the appropriate phase of CAMEL, the service behaviour may be unpredictable or incorrect. The HLR should therefore ensure that at the conclusion of a stand alone Insert Subscriber data procedure the data in the VLR do not require a capability that the VLR does not have. Possible mechanisms to ensure this are described in 3GPP TS 23.078Ê[98]. The HLR should send a Forwarded-to number which is not in E.164 international format to the VLR only when the HLR has ascertained that the VLR supports CAMEL Phase 2 or later. Thus, the ISD message containing the Forwarded-to number which is not in E.164 international format shall be sent to the VLR only if the HLR previously received confirmation from the VLR at Location Update that CAMEL Phase 2 or later is supported. 19.5.2 Macro Insert_GPRS_Subs_Data_Framed_HLR This macro is used to transfer subscriber data to the SGSN as part of an existing dialogue for location updating. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows: Wait_For_Insert_GPRS_Subs_Data_Cnf see clauseÊ25.7.5; Send_Insert_Subs_Data_HLR: see clauseÊ25.7.7. The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. If the SGSN has indicated that it does not support a service or feature which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restricted In SGSN Due To Unsupported Feature flag to roaming restricted and sends Roaming Restricted In SGSN Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. FigureÊ19.5/1: Macro Insert_Subs_Data_Framed_HLR FigureÊ19.5/2: Macro Insert_GPRS_Subs_Data_Framed_HLR 19.5A CSS Insert Subscriber Data macros 19.5A.1 Macro Insert_VCSG_Subs_Data_Framed_CSS This macro is used to transfer CSG subscriber data from the CSS to the VLR or the SGSN as part of an existing dialogue for VCSG location updating. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows: Wait_For_Insert_VCSG_Subs_Data_Cnf see clause 25.7.9; Send_Insert_VCSG_Subs_Data_CSS: see clause 25.7.10. The CSS may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. If the VLR or the SGSN has indicated that it does not support a service or feature which the CSS operator regards as essential for the subscriber, the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit. If the CSS operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit, the CSS sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Figure 19.5A/1: Macro Insert_VCSG_Subs_Data_Framed_CSS 20 Operation and maintenance procedures 20.1 General The Operation and Maintenance procedures are used to support operation and maintenance of the network. The following procedures exist for operation and maintenance purposes: i) Tracing procedures; ii) Subscriber Data Management procedures; iii) Subscriber Identity procedure. The following application contexts refer to complex MAP Users consisting of several processes: - subscriberDataManagementContext; - tracingContext. Each of these two application contexts needs a co-ordinating process in the VLR or in the SGSN as described in the following clauses. 20.1.1 Tracing Co-ordinator for the VLR The Tracing Co-ordinator process in the VLR is shown the figureÊ20.1/1. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 20.1.2 Tracing Co-ordinator for the SGSN The Tracing Co-ordinator process in the SGSN is shown in figureÊ20.1/2. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 20.1.3 Subscriber Data Management Co-ordinator for the VLR The Subscriber Data Management Co-ordinator process in the VLR is shown in figureÊ20.1/3 and figure 20.1/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 20.1.4 Subscriber Data Management Co-ordinator for the SGSN The Subscriber Data Management Co-ordinator process in the SGSN is shown in figureÊ20.1/4 and figure 20.1/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ20.1/1: Process Co_Tracing_VLR FigureÊ20.1/2: Process Co_Tracing_SGSN FigureÊ20.1/3: Process Co_SDM_VLR FigureÊ20.1/4: Process Co_SDM_SGSN Figure 20.1/5: Process Co_CSG_SDM_VLR Figure 20.1/6: Process Co_CSG_SDM_SGSN 20.2 Tracing procedures Three types of tracing procedures exist: i) Subscriber tracing management procedures; ii) Subscriber tracing procedures; iii) Event tracing procedures. The subscriber tracing management procedures are used to manage the status and the type of the tracing. The subscriber tracing activation procedure is used at location updating or data restoration when the trace mode of a subscriber is set active in the HLR or, as a stand alone procedure, when the subscriber is already registered and the trace mode becomes active in the HLR. The procedures to activate tracing in the VLR are shown in figures 20.2/1 and 20.2/3. The procedures to activate tracing in the SGSN are shown in figures 20.2/2 and 20.2/4. 1) Subscriber Tracing Activation 2) MAP_ACTIVATE_TRACE_MODE_req/ind 3) MAP_ACTIVATE_TRACE_MODE_rsp/cnf 4) Subscriber Tracing Activation Accepted FigureÊ20.2/1: Stand-alone subscriber tracing activation procedure for non-GPRS 1) Subscriber Tracing Activation 2) MAP_ACTIVATE_TRACE_MODE_req/ind 3) MAP_ACTIVATE_TRACE_MODE_rsp/cnf 4) Subscriber Tracing Activation Accepted FigureÊ20.2/2: Stand-alone subscriber tracing activation procedure for GPRS 1) MAP_UPDATE_LOCATION or MAP_RESTORE_DATA_req/ind 2) MAP_ACTIVATE_TRACE_MODE_req/ind 3) MAP_ACTIVATE_TRACE_MODE_rsp/cnf 4) MAP_UPDATE_LOCATION_rsp/cnf or MAP_RESTORE_DATA_rsp/cnf FigureÊ20.2/3: Subscriber tracing activation procedure at location updating or data restoration 1) MAP_UPDATE_GPRS_LOCATION_req/ind 2) MAP_ACTIVATE_TRACE_MODE_req/ind 3) MAP_ACTIVATE_TRACE_MODE_rsp/cnf 4) MAP_UPDATE_GPRS_LOCATION_rsp/cnf FigureÊ20.2/4: Subscriber tracing activation procedure at GPRS location updating The MAP_ACTIVATE_TRACE_MODE request includes the IMSI, trace reference, trace type and identity of the OMC. The subscriber tracing deactivation procedure is used when tracing of a subscriber in the VLR or in the SGSN is no longer required. The procedures are shown in figuresÊ20.2/5 and 20.2/6. 1) Subscriber Tracing Deactivation 2) MAP_DEACTIVATE_TRACE_MODE_req/ind 3) MAP_DEACTIVATE_TRACE_MODE_rsp/cnf 4) Subscriber Tracing Deactivation Accepted FigureÊ20.2/5: Subscriber tracing deactivation procedure for non-GPRS 1) Subscriber Tracing Deactivation 2) MAP_DEACTIVATE_TRACE_MODE_req/ind 3) MAP_DEACTIVATE_TRACE_MODE_rsp/cnf 4) Subscriber Tracing Deactivation Accepted FigureÊ20.2/6: Subscriber tracing deactivation procedure for GPRS The subscriber tracing procedures are used when the VLR detects any subscriber related activity for which the trace mode is activated, e.g. the VLR receives a MAP_PROCESS_ACCESS_REQUEST indication. The procedure is shown in figureÊ20.2/7. 1) MAP_PROCESS_ACCESS_REQUEST_req/ind 2) MAP_TRACE_SUBSCRIBER_ACTIVITY_req/ind 3) Subscriber tracing information FigureÊ20.2/7: Subscriber tracing procedure in the serving MSC 20.2.1 Subscriber tracing activation procedure 20.2.1.1 Procedures in the HLR A subscriber tracing activation request from the OMC starts the appropriate process in the HLR: ATM_With_VLR_HLR if tracing is required in the MSC/VLR, ATM_With_SGSN_HLR if tracing is required in the SGSN. The process in the HLR to activate tracing in the VLR is shown in figureÊ20.2/8. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the Repeat attempt counter has reached its limit, the test ""Repeat Attempt"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options. The process in the HLR to activate tracing in the SGSN is shown in figureÊ20.2/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the Repeat attempt counter has reached its limit, the test ""Repeat Attempt"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options. 20.2.1.2 Procedure in the VLR The process in the VLR to activate tracing in a stand-alone dialogue is shown in figureÊ20.2/10. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. 20.2.1.3 Procedure in the SGSN The process in the SGSN to activate tracing in a stand-alone dialogue is shown in figureÊ20.2/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. 20.2.2 Subscriber tracing deactivation procedure 20.2.2.1 Procedures in the HLR A subscriber tracing deactivation request from the OMC starts the appropriate process in the HLR: DTM_HLR_With_VLR if tracing is no longer required in the MSC/VLR, DTM_HLR_With_SGSN if tracing is no longer required in the SGSN. The process in the HLR to deactivate tracing in the VLR is shown in figureÊ20.2/12. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the Repeat attempt counter has reached its limit, the test ""Repeat Attempt"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options. The process in the HLR to deactivate tracing in the SGSN is shown in figureÊ20.2/13. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the Repeat attempt counter has reached its limit, the test ""Repeat Attempt"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options. 20.2.2.2 Procedure in the VLR The process in the VLR to deactivate tracing is shown in figureÊ20.2/14. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. 20.2.2.3 Procedure in the SGSN The process in the SGSN to deactivate tracing is shown in figureÊ20.2/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. FigureÊ20.2/8 (sheet 1 of 2): Process ATM_With_VLR_HLR FigureÊ20.2/8 (sheet 2 of 2): Process ATM_With_VLR_HLR FigureÊ20.2/9 (sheet 1 of 2): Process ATM_with_SGSN_HLR FigureÊ20.2/9 (sheet 2 of 2): Process ATM_with_SGSN_HLR FigureÊ20.2/10: Process ATM_Standalone_VLR FigureÊ20.2/11: Process ATM_Standalone_SGSN FigureÊ20.2/12 (sheet 1 of 2): Process DTM_with_VLR_HLR FigureÊ20.2/12 (sheet 2 of 2): Process DTM_with_VLR_HLR FigureÊ20.2/13 (sheet 1 of 2): Process DTM_with_SGSN_HLR FigureÊ20.2/13 (sheet 2 of 2): Process DTM_with_SGSN_HLR FigureÊ20.2/14: Process DTM_Standalone_VLR FigureÊ20.2/15: Process DTM_Standalone_SGSN 20.3 Subscriber data management procedures for HLR Two types of subscriber data management procedures exist: 1) Subscriber Deletion; 2) Subscriber Data Modification. The subscriber deletion and subscriber data modification procedures are initiated by the OMC (see figures 20.3/1 , 20.3/2, 20.3/3 and 20.3/4). 1) Delete Subscriber 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf 4) Subscriber Deleted FigureÊ20.3/1: Subscriber deletion procedure for non-GPRS In the subscriber deletion procedure for a non-GPRS subscriber the subscriber data are removed from the VLR and the HLR. The HLR uses the MAP_CANCEL_LOCATION service. 1) Delete GPRS Subscriber 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf 4) GPRS Subscriber Deleted FigureÊ20.3/2: Subscriber deletion procedure for GPRS In the subscriber deletion procedure for a GPRS subscriber the subscriber data are removed from the SGSN and the HLR. The HLR uses the MAP_CANCEL_LOCATION service. 1) Modify Subscriber Data 2) MAP_CANCEL_LOCATION_req/ind, MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf, MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) Subscriber Data Modified FigureÊ20.3/3: Subscriber data modification procedure for non-GPRS 1) Modify GPRS Subscriber Data 2) MAP_CANCEL_LOCATION_req/ind, MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf, MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) GPRS Subscriber Data Modified FigureÊ20.3/4: Subscriber data modification procedure for GPRS In the subscriber data modification procedure the subscriber data are modified in the HLR and when necessary also in the VLR or in the SGSN. The HLR initiates one of the MAP_INSERT_SUBSCRIBER_DATA, MAP_DELETE_SUBSCRIBER_DATA or MAP_CANCEL_LOCATION services depending on the modified data. 20.3.1 Subscriber deletion procedure 20.3.1.1 Procedure in the HLR The subscriber deletion process in the HLR is shown in figureÊ20.3/5. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows: Cancel_GPRS_Location_Child_HLR see clauseÊ19.1.2.2; Cancel_Location_Child_HLR see clauseÊ19.1.2.2. 20.3.1.2 Procedure in the VLR The subscriber deletion procedure in the VLR is described in clauseÊ19.1.2.3 of the present document. 20.3.1.3 Procedure in the SGSN The subscriber deletion procedure in the SGSN is described in clauseÊ19.1. 2.4 of the present document. 20.3.2 Subscriber data modification procedure 20.3.2.1 Procedure in the HLR The OMC can modify the subscriber data in several different ways. The modifications can be categorised in the following groups: 1) data shall be modified in the HLR; no effect in the VLR; 2) data shall be modified in both the HLR and the VLR; 3) withdrawal of a basic service or a supplementary service requiring change to VLR data; 4) modification affects the roaming permission for the subscriber and the subscriber record shall be removed from the VLR data base; 5) withdrawal of non-GPRS Subscription caused by a change of Network Access Mode; 6) data shall be modified in the HLR; no effect in the SGSN; 7) data shall be modified in both the HLR and the SGSN; 8) withdrawal of GPRS subscription data or a basic service or a supplementary service requiring change to SGSN data; 9) modification affects the roaming permission for the subscriber and the subscriber record shall be removed from the SGSN data base; 10) withdrawal of GPRS Subscription caused by a change of Network Access Mode; 11) authentication algorithm or authentication key of the subscriber is modified. In cases 2 and 7 the HLR uses the MAP_INSERT_SUBSCRIBER_DATA service. In cases 3 and 8 the HLR uses the MAP_DELETE_SUBSCRIBER_DATA service. In cases 4, 5, 9, 10 and 11 the HLR uses the MAP_CANCEL_LOCATION service. If the deletion of subscriber data fails, the HLR may repeat the request; the number of repeat attempts and the time in between are HLR operator options, depending on the error returned by the VLR or the SGSN. The subscriber data modification process in the HLR is shown in figure 20.3/6. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows: Insert_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.3; Cancel_Location_Child_HLR see clauseÊ19.1.2.2; Insert_GPRS_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.4; Cancel_GPRS_Location_Child_HLR see clauseÊ19.1.2.2. The macro Delete_Subscriber_Data_HLR is shown in figure 20.3/7. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The macro Delete_GPRS_Subscriber_Data_HLR is shown in figure 20.3/8. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 20.3.2.2 Procedures in the VLR The process in the VLR to update subscriber data in a stand-alone dialogue is shown in figure 20.3/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clauseÊ25.2.1; Insert_Subs_Data_VLR see clauseÊ25.7.1. The process in the VLR to delete subscriber data is shown in figure 20.3/10. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. 20.3.2.3 Procedures in the SGSN The process in the SGSN to update subscriber data in a stand-alone dialogue is shown in figure 20.3/11. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clauseÊ25.2.1; Insert_Subs_Data_SGSN see clauseÊ25.7.2. The process in the SGSN to delete subscriber data is shown in figure 20.3/12. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. FigureÊ20.3/5: Process Delete_Subscriber_HLR FigureÊ20.3/6 (sheet 1 of 2): Process Modify_Data_HLR FigureÊ20.3/6 (sheet 2 of 2): Process Modify_Data_HLR FigureÊ20.3/7: Macro Delete_Subscriber_Data_HLR FigureÊ20.3/8: Macro Delete_GPRS_Subscriber_Data_HLR FigureÊ20.3/9 (sheet 1 of 2): Process Ins_Subs_Data_Stand_Alone_VLR FigureÊ20.3/9 (sheet 2 of 2): Process Ins_Subs_Data_Stand_Alone_VLR FigureÊ20.3/10: Process Delete_Subs_Data_VLR FigureÊ20.3/11 (sheet 1 of 2): Process Ins_Subs_Data_Stand_Alone_SGSN FigureÊ20.3/11 (sheet 2 of 2): Process Ins_Subs_Data_Stand_Alone_SGSN FigureÊ20.3/12: Process Delete_Subs_Data_SGSN 20.3A Subscriber Data Management procedures for CSS Two types of subscriber data management procedures exist: 1) Subscriber Deletion; 2) Subscriber Data Modification. The subscriber deletion and subscriber data modification procedures are initiated by the OMC (see figures 20.3A/1, 20.3A/2, 20.3A/3 and 20.3A/4). 1) Delete Subscriber 2) MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) Subscriber Deleted Figure 20.3A/1: Subscriber deletion procedure for non-GPRS In the subscriber deletion procedure for a non-GPRS subscriber the CSG subscription data for the subscriber in the VPLMN are removed from the VLR and the CSS. The CSS uses the MAP_DELETE_SUBSCRIBER_DATA service."
"1) Delete GPRS Subscriber 2) MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) GPRS Subscriber Deleted Figure 20.3A/2: Subscriber deletion procedure for GPRS In the subscriber deletion procedure for a GPRS subscriber the CSG subscription data for the GPRS subscriber in the VPLMN are removed from the SGSN and the CSS. The CSS uses the MAP_DELETE_SUBSCRIBER_DATA service. 1) Modify Subscriber Data 2) MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) Subscriber Data Modified Figure 20.3A/3: Subscriber data modification procedure for non-GPRS 1) Modify GPRS Subscriber Data 2) MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) GPRS Subscriber Data Modified Figure 20.3A/4: Subscriber data modification procedure for GPRS In the subscriber data modification procedure the CSG subscription data in the VPLMN for the subscriber data are modified in the CSS and when necessary also in the VLR or in the SGSN. The CSS initiates one of the MAP_INSERT_SUBSCRIBER_DATA or MAP_DELETE_SUBSCRIBER_DATA services depending on the modified data. 20.3A.1 Subscriber deletion procedure 20.3A.1.1 Procedure in the CSS The process in the CSS to delete subscriber is shown in figure 20.3A/5. In this case the CSS uses the MAP_DELETE_SUBSCRIBER_DATA service. 20.3A.1.2 Procedure in the VLR The process in the VLR for the CSG subscriber deletion procedure is shown in figure 20.3A/9. 20.3A.1.3 Procedure in the SGSN The process in the SGSN for the CSG subscriber deletion procedure is shown in figure 20.3A/11. 20.3A.2 Subscriber data modification procedure 20.3A.2.1 Procedure in the CSS The OMC can modify the CSG subscriber data in several different ways. The modifications can be categorised in the following groups: 1) CSG subsctiption data shall be modified in the CSS; no effect in the VLR; 2) CSG subsctiption data shall be modified in both the CSS and the VLR; 3) withdrawal of CSG subscription data requiring change to VLR data. 4) CSG subsctiption data shall be modified in the CSS; no effect in the SGSN; 5) CSG subsctiption data shall be modified in both the CSS and the SGSN; 6) withdrawal of CSG subscription data requiring change to SGSN data. In cases 2 and 5 the CSS uses the MAP_INSERT_SUBSCRIBER_DATA service. In cases 3 and 6 the CSS uses the MAP_DELETE_SUBSCRIBER_DATA service. If the deletion of CSG subscriber data fails, the CSS may repeat the request; the number of repeat attempts and the time in between are CSS operator options, depending on the error returned by the VLR or the SGSN. The CSS removes the routeting information after the completion of CSG subscriber data deletion procedure. The CSG subscriber data modification process in the CSS is shown in figure 20.3A/6. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows: Insert_VCSG_Subs_Data_Stand_Alone_CSS see clause 25.7.8; The macro Delete_VCSG_Subs_Data_CSS is shown in figure 20.3A/7. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. 20.3A.2.2 Procedures in the VLR The process in the VLR to update CSG subscription data in the VPLMN for the subscriber in a stand-alone dialogue is shown in figure 20.3A/8. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clause 25.2.1; Insert_Subs_Data_VLR see clause 25.7.1. The process in the VLR to delete CSG subscriber data is shown in figure 20.3A/9. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. 20.3A.2.3 Procedures in the SGSN The process in the SGSN to update CSG subscription data in the VPLMN for the GPRS subscriber in a stand-alone dialogue is shown in figure 20.3A/10. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clause 25.2.1; Insert_Subs_Data_SGSN see clause 25.7.2. The process in the SGSN to delete subscriber data is shown in figure 20.3A/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. Figure 20.3A/5: Process Delete_Subscriber_CSS Figure 20.3A/6 (sheet 1 of 2): Process Modify_Data_CSS Figure 20.3A/6 (sheet 2 of 2): Process Modify_Data_CSS Figure 20.3A/7: Macro Delete_VCSG_Subs_Data_CSS Figure 20.3A/8 (sheet 1 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_VLR Figure 20.3A/8 (sheet 2 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_VLR Figure 20.3A/9: Process Delete_VCSG_Subs_Data_VLR Figure 20.3A/10 (sheet 1 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_SGSN Figure 20.3A/10 (sheet 2 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_SGSN Figure 20.3A/11: Process Delete_VCSG_Subs_Data_SGSN 20.4 Subscriber Identity procedure In the subscriber identity procedure the IMSI of the subscriber is retrieved from the HLR. The procedure is shown in figureÊ20.4/1. 1) Identity request 2) MAP_SEND_IMSI_req/ind 3) MAP_SEND_IMSI_rsp/cnf 4) Identity confirm FigureÊ20.4/1: The subscriber identity procedure 20.4.1 Procedure in the VLR The subscriber identity process in the VLR is shown in figureÊ20.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 20.4.2 Procedure in the HLR The subscriber identity process in the HLR is shown in figureÊ20.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. FigureÊ20.4/2: Process Send_IMSI_VLR FigureÊ20.4/3: Process Send_IMSI_HLR 21 Call handling procedures 21.1 General The MAP call handling procedures are used: - to retrieve routeing information to handle a mobile terminating call; - to transfer control of a call back to the GMSC if the call is to be forwarded; - to retrieve and transfer information between anchor MSC and relay MSC for inter MSC group calls / broadcast calls; - to handle the reporting of MS status for call completion services; - to handle the notification of remote user free for CCBS; - to handle the alerting and termination of ongoing call activities for a specific subscriber; - to handle early release of no longer needed resources; - to relay a mobile terminating call from the old to the new MSC during the Mobile Terminating Roaming Forwarding procedure. The procedures to handle a mobile originating call and a mobile terminating call after the call has arrived at the destination MSC do not require any signalling over a MAP interface. These procedures are specified in 3GPP TS 23.018Ê[97]. The stage 2 specification for the retrieval of routeing information to handle a mobile terminating call is in 3GPP TS 23.018Ê[97]; modifications to this procedure for CAMEL are specified in 3GPP TS 23.078 [98], for optimal routeing of a basic mobile-to-mobile call in 3GPP TS 23.079 [99] and for CCBS in 3GPP TS 23.093 [107]. The interworking between the MAP signalling procedures and the call handling procedures for each entity (GMSC, HLR and VLR) is shown by the transfer of signals between these procedures. The stage 2 specification for the transfer of control of a call back to the GMSC if the call is to be forwarded is in 3GPP TS 23.079 [99]. The interworking between the MAP signalling procedures and the call handling procedures for each entity (VMSC and GMSC) is shown by the transfer of signals between these procedures. The stage 2 specifications for inter MSC group calls / broadcast calls are in 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101]. The interworking between the MAP signalling procedures and the group call /broadcast call procedures for each entity (Anchor MSC and Relay MSC) is shown by the transfer of signals between these procedures. The interworking between the call handling procedures and signalling protocols other than MAP are shown in 3GPP TS 23.018, 3GPP TS 23.078 and 3GPP TS 23.079 [99]. The stage 2 specification for the handling of reporting of MS status for call completion services and notification of remote user free for CCBS is in 3GPP TS 23.093 [107]. The stage 2 specification for the Mobile Terminating Roaming Forwarding procedure is in 3GPP TS 23.018Ê[97] and 3GPP TS 23.012 [23]. 21.2 Retrieval of routing information 21.2.1 General The message flows for successful retrieval of routeing information for a mobile terminating call are shown in figureÊ21.2/1 (mobile terminating call which has not been optimally routed) and 21.2/2 (mobile-to-mobile call which has been optimally routed). The message flow for successful retrieval of routeing information for a gsmSCF initiated call is shown in figure 21.2/3. The message flow for a successful Mobile Terminating Roaming Forwarding procedure is shown in figure 21.2/4. 1) I_IAM (Note 1) 2) MAP_SEND_ROUTING_INFORMATION_req/ind (Note 2) 3) MAP_PROVIDE_SUBSCRIBER_INFO_req/ind (Note 3, Note 4) 4) MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf (Note 4) 5) MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 4) 6) MAP_SEND_ROUTING_INFORMATION_req/ind (Note 4) 7) MAP_PROVIDE_ROAMING_NUMBER_req/ind 8) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf 9) MAP_SEND_ROUTING_INFORMATION_rsp/cnf 10) I_IAM (Note 1) 11) MAP_RESTORE_DATA_req/ind (Note 4) 12) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 4) 13) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 4) 12) MAP_RESTORE_DATA_rsp/cnf (Note 4) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations and ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: This service may also be used by an ISDN exchange for obtaining routing information from the HLR. NOTE 3: As a network operator option, the HLR sends MAP_PROVIDE_SUBSCRIBER_INFORMATION to the VLR. For further details on the CAMEL procedures refer to 3GPP TS 23.078 [98]. NOTE 4: Services printed in italics are optional. FigureÊ21.2/1: Message flow for retrieval of routeing information (non-optimally routed call) 1) I_IAM (Note 1) 2) MAP_SEND_ROUTING_INFORMATION_req/ind 3) MAP_PROVIDE_SUBSCRIBER_INFO_req/ind (Note 2) 4) MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf (Note 2) 5) MAP_PROVIDE_ROAMING_NUMBER_req/ind (Note 2) 6) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf (Note 2) 7) MAP_SEND_ROUTING_INFORMATION_rsp/cnf 8) I_IAM (Note 1) 9) MAP_RESTORE_DATA_req/ind (Note 3) 10) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 11) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) 12) MAP_RESTORE_DATA_rsp/cnf (Note 3) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: For Optimal Routeing phase 1, only one of the information flows for Provide Subscriber Info and Provide Roaming Number is used. NOTE 3: Services printed in italics are optional. FigureÊ21.2/2: Message flow for retrieval of routeing information (optimally routed call) 1) MAP_SEND_ROUTING_INFORMATION_req/ind 2) MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 1) 3) MAP_SEND_ROUTING_INFORMATION_req/ind (Note 1) 4) MAP_PROVIDE_ROAMING_NUMBER_req/ind 5) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf 6) MAP_SEND_ROUTING_INFORMATION_rsp/cnf 7) MAP_RESTORE_DATA_req/ind (Note 1) 8) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 1) 9) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 1) 10) MAP_RESTORE_DATA_rsp/cnf (Note 1) NOTE 1: Services printed in italics are optional. FigureÊ21.2/3: Message flow for retrieval of routeing information for a gsmSCF initiated call The following MAP services are used to retrieve routing information: MAP_SEND_ROUTING_INFORMATION see clauseÊ10.1; MAP_PROVIDE_ROAMING_NUMBER see clauseÊ10.2; MAP_PROVIDE_SUBSCRIBER_INFO see clauseÊ8.11.2; MAP_RESTORE_DATA see clauseÊ8.10.3. 1) I_IAM 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_PROVIDE_ROAMING_NUMBER_req/ind 4) MAP_ PROVIDE_ROAMING_NUMBER_rsp/cnf 5) I_IAM FigureÊ21.2/4: Message flow for Mobile Terminating Roaming Forwarding The following MAP services are used for the Mobile Terminating Roaming Forwarding procedure: MAP_PROVIDE_ ROAMING_NUMBER see clauseÊ10.2; 21.2.2 Procedure in the GMSC The MAP process in the GMSC to retrieve routeing information for a mobile terminating call is shown in figure 21.2/6. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: if the MAP_SEND_ROUTING_INFORMATION request included the OR Interrogation parameter, the test ""OR interrogation?"" takes the ""Yes"" exit; otherwise the test takes the ""No"" exit. 21.2.9 Process in the gsmSCF For the purposes of retrieving routeing information from the HLR, the gsmSCF takes the role of the GMSC and follows the process specified in clause 21.2.2. 21.2.4 Procedure in the HLR The MAP process in the HLR to retrieve routeing information for a mobile terminating call is shown in figure 21.2/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 3: if the MAP_PROVIDE_ROAMING_NUMBER request included the OR Interrogation parameter, the test ""OR interrogation?"" takes the ""Yes"" exit; otherwise the test takes the ""No"" exit. 21.2.5 Procedure in the VLR to provide a roaming number The MAP process in the VLR to provide a roaming number for a mobile terminating call is shown in figure 21.2/8. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; 21.2.6 Procedure in the VLR to restore subscriber data The MAP process in the HLR to restore subscriber data is shown in figure 21.2/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2; Insert_Subs_Data_VLR see clauseÊ25.7.1; Activate_Tracing_VLR see clauseÊ25.9.4. 21.2.7 Procedure in the VLR to provide subscriber information The MAP process in the VLR to provide subscriber information for a mobile terminating call subject to CAMEL invocation is shown in figure 21.2/9. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; 21.2.8 Procedure in the old VLR to request a Roaming Number (MTRF) The MAP process in the old VLR for Mobile Terminating Roaming Forwarding is shown in figure 21.2/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2 Check_Confirmation see clause 25.2.2 FigureÊ21.2/6 (sheet 1 of 2): Process SRI_GMSC FigureÊ21.2/6 (sheet 2 of 2): Process SRI_GMSC FigureÊ21.2/7 (sheet 1 of 3): Process SRI_HLR FigureÊ21.2/7 (sheet 2 of 3): Process SRI_HLR FigureÊ21.2/7 (sheet 3 of 3): Process SRI_HLR FigureÊ21.2/8: Process PRN_VLR FigureÊ21.2/9: Process Restore_Data_VLR FigureÊ21.2/10: Process PSI_VLR FigureÊ21.2/11: Process PRN_Old_VLR 21.3 Transfer of call handling 21.3.1 General The message flow for successful transfer of call handling to forward a call is shown in figure 21.3/1. 1) MAP_RESUME_CALL_HANDLING_req/ind 2) MAP_SEND_ROUTING_INFORMATION_req/ind (Note 2) 3) MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 2) 4) MAP_RESUME_CALL_HANDLING_rsp/cnf 5) I_REL (Note 1) 6) I_IAM (Note 1) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: Services printed in italics are optional. FigureÊ21.3/1: Message flow for transfer of call handling If the HLR indicated in the response to the original request for routeing information that forwarding interrogation is required, the GMSC executes the Send Routeing Information procedure with the HLR to obtain forwarding information; otherwise the GMSC uses the forwarding data which were sent in the MAP_RESUME_CALL_HANDLING req/ind. 21.3.2 Process in the VMSC The MAP process in the VMSC to retrieve routeing information for a mobile terminating call is shown in figure 21.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. If the capacity of a message signal unit in the lower layers of the protocol is enough to carry all the information which has to be sent to the GMSC, the test ""Segmentation needed?"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. 21.3.3 Process in the GMSC The MAP process in the GMSC to handle a request for the GMSC to resume call handling is shown in figure 21.3/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; If the parameter All Information Sent was present in the MAP_RESUME_CALL_HANDLING indication, the test ""All Information Sent"" takes the ""Yes"" exit; otherwise the test takes the ""No"" exit. FigureÊ21.3/2: Process RCH_VMSC FigureÊ21.3/3: Process RCH_GMSC 21.4 Inter MSC Group Call Procedures 21.4.1 General The message flow for successful inter MSC group call / broadcast call set-up is shown in figure 21.4/1. 1) I_IAM (Note 1) 2) MAP_PREPARE_GROUP_CALL_req/ind 3) MAP_PREPARE_GROUP_CALL_rsp/cnf 4) I_IAM (Note 1) 5) MAP_SEND_GROUP_CALL_END_SIGNAL_req/ind 6) I_ACM (Note 1) 7) I_ACM (Note 1) 8) MAP_FORWARD_GROUP_CALL_SIGNALLING_req/ind (Note 2) 9) MAP_PROCESS_GROUP_CALL_SIGNALLING_req/ind (Note 2) 10) MAP_SEND_GROUP_CALL_END_SIGNAL_rsp/cnf 11) I_REL (Note 3) 12) I_REL (Note 3) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations and ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: The MAP_FORWARD_GROUP_CALL_SIGNALLING and MAP_PROCESS_GROUP_CALL_SIGNALLING services are not applicable for voice broadcast calls. NOTE 3: The call can be released from the PSTN/ISDN or the Relay MSC FigureÊ21.4/1: Message flow for inter MSC group call / broadcast call 21.4.2 Process in the Anchor MSC The MAP process in the Anchor MSC to retrieve and transfer information from / to the Relay MSC for VBS and VGCS calls is shown in figure 21.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2. 21.4.3 Process in the Relay MSC The MAP process in the Relay MSC to receive and transfer information from / to the Anchor MSC for VBS and VGCS calls is shown in figure 21.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1. FigureÊ21.4/2 (sheet 1 of 2): Process ASCI_Anchor_MSC FigureÊ21.4/2 (sheet 2 of 2): Process ASCI_Anchor_MSC FigureÊ21.4/3 (sheet 1 of 2): Process ASCI_Relay_MSC FigureÊ21.4/3 (sheet 2 of 2): Process ASCI_Relay_MSC 21.4A Inter MSC Group Call Info Retrieval 21.4A.1 General The message flow for successful inter MSC group call info retrieval is shown in figure 21.4A/1. FigureÊ21.4A/1: Message flow for inter MSC group call info retrieval 21.4A.2 Process in the MSC The MAP process in the MSC to retrieve and group call information is shown in figure 21.4A/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Receive_Open_Ind see clauseÊ25.1.2; FigureÊ21.4A/2 (sheet 1 of 2): Process Group_Call_Info_Retrieval_MSC FigureÊ21.4A/2 (sheet 2 of 2): Process Group_Call_Info_Retrieval_MSC 21.5 Void 21.6 CCBS: monitoring and reporting the status of the subscriber 21.6.1 Reporting co-ordinator process in the VLR The MAP co-ordinating process in the VLR to handle a dialogue opened with the reporting application context is shown in figure 21.6/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 21.6.2 Setting the reporting state Ð stand-alone The message flow for setting the reporting state in a stand-alone dialogue is shown in figure 21.6/1. 1) MAP_SET_REPORTING_STATE_req/ind 2) MAP_SET_REPORTING_STATE_rsp/cnf Figure 21.6/1: Message flow for setting the reporting state Ð stand-alone dialogue 21.6.2.1 Process in the HLR The MAP process in the HLR to set the reporting state in the VLR in a stand-alone dialogue is shown in figureÊ21.6/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The result of a request to stop reporting is not reported to the CCBS application in the HLR. 21.6.2.2 Process in the VLR The MAP process in the VLR to set the reporting state is shown in figure 21.6/8. The macro Set_Reporting_State_VLR is shown in figure 21.6/9. 21.6.3 Status Reporting The message flows for reporting the status of a subscriber are shown in figures 21.6/2 and 21.6/3. 1) MAP_STATUS_REPORT_req/ind 2) MAP_STATUS_REPORT_rsp/cnf Figure 21.6/2: Message flow for status reporting, when monitoring continues in the VLR 1) MAP_STATUS_REPORT_req/ind 2) MAP_STATUS_REPORT_rsp/cnf 3) MAP_SET_REPORTING_STATE_req/ind 4) MAP_SET_REPORTING_STATE_rsp/cnf Figure 21.6/3: Message flow for status reporting, when monitoring stops The MAP_SET_REPORTING_STATE request is used to stop monitoring in the VLR. If the HLR requires the VLR to continue monitoring, it closes the dialogue without sending a MAP_SET_REPORTING_STATE request. 21.6.3.1 Process in the VLR The MAP process in the VLR to send a status report to the HLR is shown in figure 21.6/10. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. This process can be used to report: - an event, such as the user becoming free, or - the result of a CCBS call attempt to the HLR 21.6.3.2 Process in the HLR The MAP process in the HLR to handle a status report is shown in figure 21.6/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; It is an implementation option whether to send the MAP_DELIMITER request before invoking the macro Set_Reporting_State_HLR. The macro Receive_Status_Report_HLR is shown in figure 21.6/12. The macro Set_Reporting_State_HLR is shown in figure 21.6/13. The macro invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. 21.6.4 CCBS: Remote User Free The message flows for handling remote user free are shown in figures 21.6/4 and 21.6/5. 1) MAP_REMOTE_USER_FREE_req/ind 2) MAP_REMOTE_USER_FREE_rsp/cnf Figure 21.6/4: Remote User Free: recall not accepted 1) MAP_REMOTE_USER_FREE_req/ind 2) MAP_REMOTE_USER_FREE_rsp/cnf 3) MAP_STATUS_REPORT_req/ind 4) MAP_STATUS_REPORT_rsp/cnf Figure 21.6/5: Remote User Free: recall accepted 21.6.4.1 Process in the HLR The MAP process in the HLR to handle Remote User Free is shown in figure 21.6/14. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 21.6.3.2 Process in the VLR The MAP process in the VLR to handle Remote User Free is shown in figure 21.6/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. FigureÊ21.6/6: Process Reporting_Coord_VLR FigureÊ21.6/7: Process Set_Reporting_State_Stand_Alone_HLR FigureÊ21.6/8: Process Set_Reporting_State_VLR FigureÊ21.6/9: Macro Receive_Set_Reporting_State_VLR FigureÊ21.6/10 (sheet 1 of 2): Process Send_Status_Report_VLR FigureÊ21.6/10 (sheet 2 of 2): Process Send_Status_Report_VLR FigureÊ21.6/11: Process Status Report_HLR FigureÊ21.6/12: Macro Receive_Status_Report_HLR FigureÊ21.6/13: Macro Set_Reporting_State_HLR Figure 21.6/14: Process Remote_User_Free_HLR Figure 21.6/15 (sheet 1 of 2): Process Remote_User_Free_VLR Figure 21.6/15 (sheet 2 of 2): Process Remote_User_Free_VLR 21.7 Void 21.8 Void 21.9 Immediate Service Termination (IST) 21.9.1 IST Alert The Immediate Service Termination Alert procedure is used to keep track of the call activities performed by subscribers who are marked as being subject to IST monitoring and, possibly, to terminate the call activities for which the alert was sent, or all the call activities related to the subscriber for whom the alert was sent. The message flow for alerting is shown in figure 21.9/1; the MSC may be a Visited MSC or a Gateway MSC. 1) MAP_IST_ALERT_req/ind 2) MAP_IST_ALERT_rsp/cnf FigureÊ21.9/1: Message flow for IST Alert 21.9.1.1 Procedure in the MSC The MAP process in the MSC (Visited MSC or Gateway MSC) is shown in figure 21.9/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. 21.9.1.2 Procedure in the HLR The MAP process in the HLR is shown in figure 21.9/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1; 21.9.2 IST Command The Immediate Service Termination Command procedure is used to terminate the call activities related to a subscriber. The message flow for the IST Command procedure is shown in figure 21.9/2; the MSC may be a Visited MSC or a Gateway MSC. 1) MAP_IST_COMMAND_req/ind 2) MAP_IST_COMMAND_rsp/cnf FigureÊ21.9/2: Message flow for IST Command 21.9.2.1 Procedure in the HLR The MAP process in the HLR is shown in figure 21.9/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. 21.9.2.2 Procedure in the MSC The MAP process in the MSC is shown in figure 21.9.6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1. Figure 21.9/3: Process IST_Alert_MSC Figure 21.9/4: Process IST_Alert_HLR Figure 21.9/5: Process IST_Command_HLR Figure 21.9/6: Process IST_Command_MSC 21.10 Resource Management 21.10.1 General The message flow for successful release of resources is shown in figure 21.10/1. 1) I_IAM (Note 1) 2) MAP_SEND_ROUTING_INFORMATION_req/ind 3) MAP_PROVIDE_ROAMING_NUMBER_req/ind 4) I_REL (Note 1) 5) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf 6) MAP_SEND_ROUTING_INFORMATION_rsp/cnf 7) MAP_RELEASE_RESOURCES (Note 2) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: Services printed in italics are optional. FigureÊ21.10/1: Message flow for early release of resources 21.3.2 Process in the GMSC The MAP process in the GMSC to release resources is shown in figure 21.10/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 21.3.3 Process in the VMSC The MAP process in the VMSC to handle a request for the GMSC to release resources is shown in figure 21.10/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; FigureÊ21.10/2: Process Release Resources_GMSC FigureÊ21.10/3: Process Release Resources_VMSC 22 Supplementary services procedures 22.1 Supplementary service co-ordinator processes 22.1.1 Supplementary service co-ordinator process for the MSC The co-ordinator process in the MSC to handle a CM connection request with CM service type Supplementary service activation is shown in figure 22.1/1. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Process_Access_Request_MSC see clauseÊ25.4.1. 22.1.2 Void 22.1.3 Functional supplementary service co-ordinator process for the HLR The MAP co-ordinator process in the HLR to handle a dialogue opened with the networkFunctionalSS application context is shown in figure 22.1/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 22.1.4 Call completion supplementary service co-ordinator process for the HLR The MAP co-ordinator process in the HLR to handle a dialogue opened with the callCompletion application context is shown in figure 22.1/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ22.1/1 (sheet 1 of 2): Process SS_Coordinator_MSC FigureÊ22.1/1 (sheet 2 of 2): Process SS_Coordinator_MSC FigureÊ22.1/2 void FigureÊ22.1/3: Process SS_Coordinator_HLR FigureÊ22.1/4: Process CC_Coordinator_HLR 22.2 Registration procedure 22.2.1 General The registration procedure is used to register data related to a supplementary service in the HLR. The registration procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below. The registration procedure is shown in figureÊ22.2.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_INSERT_SUBSCRIBER_DATA (see clauses 8 and 25); The following service is certainly used: MAP_REGISTER_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_REGISTER_SS (Note 1) 4) MAP_REGISTER_SS_req/ind 5) MAP_REGISTER_SS_req/ind 6) MAP_REGISTER_SS_rsp/cnf 7) MAP_REGISTER_SS_rsp/cnf 8) A_REGISTER_SS ack (Note 1) 9) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 10) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: Services printed in italics are optional. FigureÊ22.2.1/1: Message flow for supplementary service registration 22.2.2 Procedure in the MSC The A_REGISTER_SS service indication received by the MAP process in the MSC contains the SS-Code and any parameters that are related to the supplementary service. The MAP user transfers the received information to the VLR in the MAP_REGISTER_SS request without checking the contents of the service indication. Rules for the mapping are described in 3GPP TS 29.011 [59]. The information in the MAP_REGISTER_SS confirm from the VLR is relayed to the MS in the A_REGISTER_SS response message as described in 3GPP TSÊ24.08x, 3GPP TSÊ24.08x and 3GPP TSÊ29.011. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The registration process in the MSC is shown in figureÊ22.2.2/1. 22.2.3 Procedure in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The MAP process in the VLR transfers the information received in the MAP_REGISTER_SS indication to the HLR in the MAP_REGISTER_SS request without checking the contents. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference. If the MAP_REGISTER_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_REGISTER_SS response. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The registration process in the VLR is shown in figureÊ22.2.3/1. 22.2.4 Procedure in the HLR The MAP process invokes a macro and a process not defined in this clause; the definitions of the macro and process can be found as follows: Check_Indication see clause 25.2.1; Insert_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.3. The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]): The registration process in the HLR is shown in figureÊ22.2.4/1. FigureÊ22.2.2/1: Process Register_SS_MSC FigureÊ22.2.3/1 (sheet 1 of 2): Process Register_SS_VLR FigureÊ22.2.3/1 (sheet 2 of 2): Process Register_SS_VLR FigureÊ22.2.4/1: Process Register_SS_HLR 22.3 Erasure procedure 22.3.1 General The erasure procedure is used to erase data related to a supplementary service in the HLR. The erasure procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below. The erasure procedure is shown in figureÊ22.3.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_INSERT_SUBSCRIBER_DATA (see clauses 8 and 25); The following service is certainly used: MAP_ERASE_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_ERASE_SS (Note 1) 4) MAP_ERASE_SS_req/ind 5) MAP_ERASE_SS_req/ind 6) MAP_ERASE_SS_rsp/cnf 7) MAP_ERASE_SS_rsp/cnf 8) A_ERASE_SS ack (Note 1) 9) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 10) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: Services printed in italics are optional. FigureÊ22.3.1/1: Message flow for supplementary service erasure 22.3.2 Procedure in the MSC The MSC procedure for erasure is identical to that specified for registration in clauseÊ22.2.2. The text and diagrams in clauseÊ22.2.2 apply with all references to registration changed to erasure. 22.3.3 Procedure in the VLR The VLR procedure for erasure is identical to that specified for registration in clauseÊ22.2.3. The text and diagrams in clauseÊ22.2.3 apply with all references to registration changed to erasure. 22.3.4 Procedure in the HLR The HLR procedure for erasure is identical to that specified for registration in clauseÊ22.2.4. The text and diagrams in clauseÊ22.2.4 apply with all references to registration changed to erasure. 22.4 Activation procedure 22.4.1 General The activation procedure is used to activate a supplementary service in the HLR. The activation procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below. The activation procedure is shown in figureÊ22.4.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_GET_PASSWORD (defined in clauseÊ11); MAP_INSERT_SUBSCRIBER_DATA (see clauses 8 and 25); The following service is certainly used: MAP_ACTIVATE_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_ACTIVATE_SS (Note 1) 4) MAP_ACTIVATE_SS_req/ind 5) MAP_ACTIVATE_SS_req/ind 6) MAP_GET_PASSWORD_req/ind (Note 3) 7) MAP_GET_PASSWORD_req/ind (Note 3) 8) A_GET_PASSWORD (Note 1, Note 3) 9) A_GET_PASSWORD ack (Note 1, Note 3) 10) MAP_GET_PASSWORD_rsp/cnf (Note 3) 11) MAP_GET_PASSWORD_rsp/cnf (Note 3) 12) MAP_ACTIVATE_SS_rsp/cnf 13) MAP_ACTIVATE_SS_rsp/cnf 14) A_ACTIVATE_SS ack (Note 1) 15) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 16) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 of this document. NOTE 3: Services printed in italics are optional. FigureÊ22.4.1/1: Message flow for supplementary service activation 22.4.2 Procedure in the MSC The A_ACTIVATE_SS service indication received by the MAP user in the MSC contains the SS-Code and any parameters related to the supplementary service. The MSC transfers the received information to the VLR in the MAP_ACTIVATE_SS request without checking the contents of the service indication. Rules for the mapping are described in 3GPP TS 29.011 [59]. The information in the MAP_ACTIVATE_SS confirm from the VLR is relayed to the MS in the A_ACTIVATE_SS response message, as described in TSÊ24.08x, 3GPP TSÊ24.08x and 3GPP TSÊ29.011. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The activation process in the MSC is shown in figureÊ22.4.2/1. 22.4.3 Procedure in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The MAP process in the VLR transfers the information received in the MAP_ACTIVATE_SS indication to the HLR in the MAP_ACTIVATE_SS request without checking the contents. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference. If the MAP_REGISTER_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_ACTIVATE_SS response. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The activation process in the VLR is shown in figureÊ22.4.3/1."
"22.4.4 Procedure in the HLR The MAP process invokes a macro and a process not defined in this clause; the definitions of the macro and process can be found as follows: Check_Indication see clause 25.2.1; Insert_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.3. The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]): The activation process in the HLR is shown in figureÊ22.4.4/1. FigureÊ22.4.2/1: Process Activate_SS_MSC FigureÊ22.4.3/1 (sheet 1 of 2): Process Activate_SS_VLR FigureÊ22.4.3/1 (sheet 2 of 2): Process Activate_SS_VLR FigureÊ22.4.4/1 (sheet 1 of 2): Process Activate_SS_HLR FigureÊ22.4.4/1 (sheet 2 of 2): Process Activate_SS_HLR 22.5 Deactivation procedure 22.5.1 General The deactivation procedure is used to deactivate a supplementary service in the HLR. The deactivation procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below. The deactivation procedure is shown in figureÊ22.5.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_GET_PASSWORD (defined in clauseÊ11); MAP_INSERT_SUBSCRIBER_DATA (see clauses 8 and 25); The following service is certainly used: MAP_DEACTIVATE_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_DEACTIVATE_SS (Note 1) 4) MAP_DEACTIVATE_SS_req/ind 5) MAP_DEACTIVATE_SS_req/ind 6) MAP_GET_PASSWORD_req/ind (Note 3) 7) MAP_GET_PASSWORD_req/ind (Note 3) 8) A_GET_PASSWORD (Note 1, Note 3) 9) A_GET_PASSWORD ack (Note 1, Note 3) 10) MAP_GET_PASSWORD_rsp/cnf (Note 3) 11) MAP_GET_PASSWORD_rsp/cnf (Note 3) 12) MAP_DEACTIVATE_SS_rsp/cnf 13) MAP_DEACTIVATE_SS_rsp/cnf 14) A_DEACTIVATE_SS ack (Note 1) 15) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 16) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: Services printed in italics are optional. FigureÊ22.5.1/1: Message flow for supplementary service deactivation 22.5.2 Procedure in the MSC The MSC procedure for deactivation is identical to that specified for activation in clauseÊ22.4.2. The text and diagrams in clauseÊ22.4.2 apply with all references to activation changed to deactivation. 22.5.3 Procedures in the VLR The VLR procedure for deactivation is identical to that specified for activation in clauseÊ22.4.3. The text and diagrams in clauseÊ22.4.3 apply with all references to activation changed to deactivation. 22.5.4 Procedures in the HLR The HLR procedure for deactivation is identical to that specified for activation in clauseÊ22.4.4. The text and diagrams in clauseÊ22.4.4 apply with all references to activation changed to deactivation. 22.6 Interrogation procedure 22.6.1 General The interrogation procedure is used to retrieve information related to a supplementary service from the VLR or the HLR. It is the VLR which decides whether an interrogation request should be forwarded to the HLR or not. Some non-supplementary service related services may be invoked as a result of the procedure, as described in the clauses below. The interrogation procedure is shown in figureÊ22.6.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); The following service is certainly used: MAP_INTERROGATE_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_INTERROGATE_SS (Note 1) 4) MAP_INTERROGATE_SS_req/ind 5) MAP_INTERROGATE_SS_req/ind 6) MAP_INTERROGATE_SS_rsp/cnf 7) MAP_INTERROGATE_SS_rsp/cnf 8) A_INTERROGATE_SS ack (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: Services printed in italics are optional. FigureÊ22.6.1/1: Message flow for supplementary service interrogation 22.6.2 Procedure in the MSC The MSC procedures for interrogation are identical to those specified for registration in clauseÊ22.2.2. The text and diagrams in clauseÊ22.2.2 apply with all references to registration changed to interrogation. 22.6.3 Procedures in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The interrogation is answered either by the VLR or by the HLR, depending on the service interrogated. 1) Interrogation to be handled by the VLR The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). 2) Interrogation to be handled by the HLR If the interrogation is to be handled by the HLR, the MAP process in the VLR transfers the information received in the MAP_INTERROGATE_SS indication to the HLR in the MAP_INTERROGATE_SS request without checking the contents of the service indication. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference. If the MAP_INTERROGATE_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_INTERROGATE_SS response. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The Interrogation process in the VLR is shown in figureÊ22.6.3/1. 22.6.4 Procedure in the HLR The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. The HLR acts as follows: The interrogation is answered either by the VLR or by the HLR, depending on the service interrogated. 1) Interrogation to be handled by the VLR If the interrogation procedure should have been answered by the VLR, then the HLR assumes that the VLR does not support the interrogated supplementary service, and returns the SS Not Available error to the VLR. 2) Interrogation to be handled by HLR The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to either a successful result or an error being returned. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The Interrogation process in the HLR is shown in figureÊ22.6.4/1. FigureÊ22.6.3/1 (sheet 1 of 2): Process Interrogate_SS_VLR FigureÊ22.6.3/1 (sheet 2 of 2): Process Interrogate_SS_VLR FigureÊ22.6.4/1: Process Interrogate_SS_HLR 22.7 Void FigureÊ22.7.2/1 void FigureÊ22.7.3/1 void 22.8 Password registration procedure 22.8.1 General The password registration procedure is used to register a password in the HLR. The password registration procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described below. The password registration procedure is shown in figureÊ22.8.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); The following services are certainly used: MAP_REGISTER_PASSWORD (defined in clauseÊ11); MAP_GET_PASSWORD (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_REGISTER_PASSWORD (Note 1) 4) MAP_REGISTER_PASSWORD_req/ind 5) MAP_REGISTER_PASSWORD_req/ind 6) MAP_GET_PASSWORD_req/ind (Note 3) 7) MAP_GET_PASSWORD_req/ind (Note 3) 8) A_GET_PASSWORD (Note 1, Note 3) 9) A_GET_PASSWORD ack (Note 1, Note 3) 10) MAP_GET_PASSWORD_rsp/cnf (Note 3) 11) MAP_GET_PASSWORD_rsp/cnf (Note 3) 12) MAP_GET_PASSWORD_req/ind (Note 3) 13) MAP_GET_PASSWORD_req/ind (Note 3) 14) A_GET_PASSWORD (Note 1, Note 3) 15) A_GET_PASSWORD ack (Note 1, Note 3) 16) MAP_GET_PASSWORD_rsp/cnf (Note 3) 17) MAP_GET_PASSWORD_rsp/cnf (Note 3) 18) MAP_GET_PASSWORD_req/ind (Note 3) 19) MAP_GET_PASSWORD_req/ind (Note 3) 20) A_GET_PASSWORD (Note 1, Note 3) 21) A_GET_PASSWORD ack (Note 1, Note 3) 22) MAP_GET_PASSWORD_rsp/cnf (Note 3) 23) MAP_GET_PASSWORD_rsp/cnf (Note 3) 24) MAP_REGISTER_PASSWORD_rsp/cnf 25) MAP_REGISTER_PASSWORD_rsp/cnf 26) A_REGISTER_PASSWORD (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines are triggers/ triggered signalling on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: The use of each of the three MAP_GET_PASSWORD operations is described in clauseÊ22.8.4. FigureÊ22.8.1/1: Message flow for supplementary service password registration 22.8.2 Procedure in the MSC The password registration procedure in the MSC is identical to that for activation specified in clauseÊ22.4.2. All the text and diagrams in clauseÊ22.4.2 apply with all references to activation changed to password registration. 22.8.3 Procedure in the VLR The password registration procedure in the VLR is identical to that for activation specified in clauseÊ22.4.3. All the text and diagrams in clauseÊ22.4.3 apply with all references to activation changed to password registration. 22.8.4 Procedure in the HLR The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. The HLR shall process the MAP_REGISTER_PASSWORD indication as specified in 3GPP TS 23.011 [22]. During the handling of password registration, the password procedure is initiated (as specified in 3GPP TS 23.011 [22]) This involves the sending of MAP_GET_PASSWORD requests to the VLR. The password registration process in the HLR is shown in figureÊ22.8.4/1. FigureÊ22.8.4/1 (sheet 1 of 2): Process Register_PW_HLR FigureÊ22.8.4/1 (sheet 2 of 2): Process Register_PW_HLR 22.9 Mobile Initiated USSD procedure 22.9.1 General The procedure supports supplementary service signalling procedures which allow PLMN specific services to be introduced. The message flow for the procedure can be found in 3GPP TS 23.090 [34]. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_UNSTRUCTURED_SS_REQUEST (defined in clauseÊ11); MAP_UNSTRUCTURED_SS_NOTIFY (defined in clauseÊ11). The following service is certainly used: MAP_PROCESS_UNSTRUCTURED_SS_REQUEST (defined in clauseÊ11). 22.9.2 Procedure in the MSC The process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. The A_PROCESS_UNSTRUCTURED_SS_REQUEST from the MS contains information input by the user; the message may be fed to an application contained locally in the MSC or to the VLR. The rules for determining this are specified in 3GPP TS 23.090 [34]. 1) Message Destined for the VLR If the message is destined for the VLR then the MSC shall transfer the message to the VLR using the mapping specified in detail in 3GPP TS 29.011 [59]. 2) Message Destined for the Local Application If the message is destined for the local USSD application then the MSC shall transfer the information contained in the message to the application. The process in the MSC is shown in figureÊ22.9.2/1. 22.9.3 Procedure in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST from the MSC contains information input by the user; the message may be fed to an application contained locally in the VLR or to the HLR. The rules for determining this are specified in 3GPP TS 23.090 [34]. 1) Message Destined for the HLR If the message is destined for the HLR then the VLR shall transfer the message transparently to the HLR. 2) Message Destined for the Local Application If the message is destined for the local USSD application then the VLR shall transfer the information contained in the message to the application. The process in the VLR is shown in figure 22.9.3/1. 22.9.4 Procedure in the HLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST from the VLR contains information input by the user. If the alphabet used for the message is understood then the message shall be fed to an application contained locally in the HLR or to the gsmSCF or to a secondary HLR where the USSD application is located. 1) Message Destined for the Local Application If the message is destined for the local USSD application then the HLR shall transfer the information contained in the message to the local application. 2) Message Destined for the gsmSCF or the secondary HLR If the message is destined for the gsmSCF or the secondary HLR then the primary HLR shall transfer the message transparently to the next node. The process in the primary HLR is shown in figureÊ22.9.4/1. 22.9.5 Procedures in the gsmSCF/secondary HLR The MAP process invokes a macro not defined in this clause; the definition of this macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. The process in the gsmSCF or secondary HLR is shown in figureÊ22.9.5/1. FigureÊ22.9.2/1 (sheet 1 of 3): Process MS_Init_USSD_MSC FigureÊ22.9.2/1 (sheet 2 of 3): Process MS_Init_USSD_MSC FigureÊ22.9.2/1 (sheet 3 of 3): Process MS_Init_USSD_MSC FigureÊ22.9.3/1 (sheet 1 of 4): Process MS_Init_USSD_VLR FigureÊ22.9.3/1 (sheet 2 of 4): Process MS_Init_USSD_VLR FigureÊ22.9.3/1 (sheet 3 of 4): Process_MS_Init_USSD_VLR FigureÊ22.9.3/1 (sheet 4 of 4): Process_MS_Init_USSD_VLR FigureÊ22.9.3/2 void FigureÊ22.9.4/1 (sheet 1 of 4): Process MS_Init_USSD_HLR FigureÊ22.9.4/1 (sheet 2 of 4): Process MS_Init_USSD_HLR FigureÊ22.9.4/1 (sheet 3 of 4): Process MS_Init_USSD_HLR FigureÊ22.9.4/1 (sheet 4 of 4): Process MS_Init_USSD_HLR Figure 22.9.5/1 (sheet 1 of 2): Process MS_Init_USSD_gsmSCF_Secondary_HLR Figure 22.9.5/1 (sheet 2 of 2): Process MS_Init_USSD_gsmSCF_Secondary_HLR 22.10 Network initiated USSD procedure 22.10.1 General The procedure supports supplementary service signalling procedures which allow PLMN specific services to be introduced. The message flow for the procedure can be found in 3GPP TS 23.090 [34]. The following services may be used: MAP_PAGE (see clauses 8 and 25); MAP_SEARCH_FOR_MOBILE_SUBSCRIBER (see clauses 8 and 25); MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25). At least one of the following services will certainly be used, and both may be used: MAP_UNSTRUCTURED_SS_REQUEST (defined in clauseÊ11); MAP_UNSTRUCTURED_SS_NOTIFY (defined in clauseÊ11). 22.10.2 Procedure in the MSC The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Page_MSC see clause 25.3.1; Search_For_MS_MSC see clause 25.3.2; Process_Access_Request_MSC see clause 25.4.1. The process in the MSC is shown in figureÊ22.10.2/1. 22.10.3 Procedure in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Indication see clause 25.2.1; Check_Confirmation see clause 25.2.2. The process in the VLR is shown in figureÊ22.10.3/1. MSC Initiated USSD If a USSD application in the MSC wishes to use the network initiated USSD procedure, and a connection to the MS does not exist then the MSC opens a dialogue with the VLR. This dialogue leads to the VLR performing page or search using the macro Start_USSD_VLR. Macro Start_USSD_VLR The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Confirmation see clause 25.2.1; Process_Access_Request_VLR see clause 25.4.2. The macro is shown in figureÊ22.10.3/2. 22.10.4 Procedure in the HLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Indication see clause 25.2.1; Check_Confirmation see clause 25.2.2. The process in the primary HLR is shown in figuresÊ22.10.4/1 and 22.10.4/2. 22.10.5 Procedure in the gsmSCF or secondary HLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. The procedure in the gsmSCF or secondary HLR is shown in figureÊ22.10.5/1. FigureÊ22.10.2/1 (sheet 1 of 4): Process NW_Init_USSD_MSC FigureÊ22.10.2/1 (sheet 2 of 4): Process NW_Init_USSD_MSC FigureÊ22.10.2/1 (sheet 3 of 4): Process NW_Init_USSD_MSC FigureÊ22.10.2/1 (sheet 4 of 4): Process NW_Init_USSD_MSC FigureÊ22.10.3/1 (sheet 1 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/1 (sheet 2 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/1 (sheet 3 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/1 (sheet 4 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/1 (sheet 5 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/2 (sheet 1 of 2): Macro Start_USSD_VLR FigureÊ22.10.3/2 (sheet 2 of 2): Macro Start_USSD_VLR FigureÊ22.10.4/1 (sheet 1 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/1 (sheet 2 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/1 (sheet 3 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/1 (sheet 4 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/1 (sheet 5 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/2: Macro Start_USSD_HLR FigureÊ22.10.5/1 (sheet 1 of 2): Process NW_Init_USSD_gsmSCF_secondary_HLR FigureÊ22.10.5/1 (sheet 2 of 2): Process NW_Init_USSD_gsmSCF_Secondary_HLR 22.11 Common macros for clauseÊ22 The following macros are used for the description of more than one of the supplementary service processes described in clauseÊ22. 22.11.1 SS Password handling macros Macro Get_Password_MSC This macro is used by the MSC to relay a request for password from the VLR to the MS, and to relay a response from the MS back to the VLR. The macro is shown in figureÊ22.11.1/1. Macro Get_Password_VLR This macro is used by the VLR to relay a request for password from the HLR to the MSC, and to relay a response from the MSC back to the HLR. The macro invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. The macro is shown in figureÊ22.11.1/2. 22.11.2 Void FigureÊ22.11.1/1: Macro Get_Password_MSC FigureÊ22.11.1/2: Macro Get_Password_VLR FigureÊ22.11.2/1 void FigureÊ22.11.2/2 void FigureÊ22.11.2/3 void FigureÊ22.11.2/4 void FigureÊ22.11.2/5 void 22.12 Supplementary Service Invocation Notification procedure 22.12.1 General The Supplementary Service Invocation Notification procedure is used to notify a gsmSCF about the invocation of a GSM Supplementary Service. The supplementary service invocation notification procedure is shown in figureÊ22.12.1/1. The following service is certainly used: MAP_SS_INVOCATION_NOTIFY (defined in clause 11). 1) MAP_SS_INVOCATION_NOTIFY_req/ind 2) MAP_SS_INVOCATION_NOTIFY_rsp/cnf FigureÊ22.12.1/1: Message flow for supplementary service invocation notification 22.12.2 Procedure in the MSC The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. The supplementary service invocation notification process in the MSC is shown in figure 22.12.2/1. 22.12.3 Procedure in the gsmSCF The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1. The supplementary service invocation notification process in thegsmSCF is shown in figureÊ22.12.3/1. Figure 22.12.2/1: Process Notify_SS_Invocation_MSC Figure 22.12.3/1: Process Note_SS_Invocation_gsmSCF 22.13 Activation of a CCBS request 22.13.1 General The message flow to activate a CCBS request is shown in figure 22.13.1/1. The following service is certainly used: MAP_REGISTER_CC_ENTRY (defined in clause 11). 1) MAP_REGISTER_CC_ENTRY_req/ind 2) MAP_REGISTER_CC_ENTRY_rsp/cnf Figure 22.13.1/1: Message flow to activate a CCBS request 22.13.2 Procedure in the VLR The MAP process in the VLR to activate a CCBS request is shown in figure 22.13.2/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 22.13.3 Procedure in the HLR The MAP process in the HLR to activate a CCBS request is shown in figure 22.13.2/1. FigureÊ22.13.2/1: Process Register_CC_Entry_VLR FigureÊ22.13.3/1: Process Register_CC_Entry_HLR 22.14 Deactivation of a CCBS request 22.14.1 General The message flow to deactivate a CCBS request is shown in figure 22.14.1/1. The following service is certainly used: MAP_ERASE_CC_ENTRY (defined in clause 11). 1) MAP_ERASE_CC_ENTRY_req/ind 2) MAP_ERASE_CC_ENTRY_rsp/cnf Figure 22.14.1/1: Message flow to deactivate a CCBS request 22.14.2 Procedure in the VLR The MAP process in the VLR to deactivate a CCBS request is shown in figure 22.14.2/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 22.14.3 Procedure in the HLR The MAP process in the HLR to deactivate a CCBS request is shown in figure 22.14.2/1. FigureÊ22.14.2/1: Process Erase_CC_Entry_VLR FigureÊ22.14.3/1: Process Erase_CC_Entry_HLR 23 Short message service procedures 23.1 General The short message service procedures are used to control both mobile originated and mobile terminated short message transfer. Four procedures exist for short message services: - mobile originated short message service transfer; - mobile terminated short message service transfer; - short message alert procedure; - short message delivery status report procedure. The following application context refers to a complex MAP user consisting of several processes: - shortMessageGatewayContext. This application context needs a co-ordinating process in the HLR. Additionally a co-ordinating process needed for the mobile originated situation in the MSC, because the A_CM_SERV_REQ message does not distinguish between mobile originated short message transfer and the short message alert procedures. NOTE: the A_CM_SERV_REQ message is not used for SMS over GPRS. The modelling is based on the assumption that the SGSN will trigger the appropriate process, according to whether an RP_MO_DATA or an RP_SM_MEMORY_AVAILABLE is received over the LLC layer. When the ""SMS in MME"" architecture option is supported, the clause 23 and its associated figures applies where HSS replaces HLR and where MME is handled as a MSC, except the procedures between the serving MSC and the VLR which, here, are not applicable to the MME. NOTE: MSC and MME cannot be both registered as serving nodes for MT SMS at a given time (cf 3GPP TS 23.272 [2]) 23.1.1 Mobile originated short message service Co-ordinator for the MSC The process starts when the MSC receives an A_CM_SERV_REQ message (see 3GPP TS 24.008 [35]), with a CM service type indicating short message service, from the A-interface. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Process_Access_Request_MSC see clauseÊ25.4.1. If the macro Process_Access_Request_MSC takes the ""OK"" exit (which means that the MSC has sent an A_CM_SERVICE_ACCEPT to the MS), , the MS initiates mobile originated short message transfer or sends an indication that it has memory available for more short messages. The SMS Co-ordinator process in the MSC is shown in figureÊ23.1/1. 23.1.2 Short message Gateway Co-ordinator for the HLR The process starts when the HLR receives a MAP_OPEN indication using when the application context shortMessageGatewayContext. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. The SM Gateway Co-ordinator process in the HLR is shown in figureÊ23.1/2. If the Receive_Open_Ind macro takes the Vr exit then HLR shall perform the MAP dialogue as specified for the appropriate application context version. Depending on the subscriber data, handling at the MAP user application level may be performed as specified in clauses 23.3.2 and 23.5.2 of the present document: FigureÊ23.1/1 (sheet 1 of 2): Process Co_SMS_MSC FigureÊ23.1/1 (sheet 2 of 2): Process Co_SMS_MSC FigureÊ23.1/2: Process Co_SM_Gateway_HLR 23.2 The mobile originated short message transfer procedure The mobile originated short message service procedure is used to forward a short message from a mobile subscriber to a Service Centre. The message flow for the mobile originated short message service procedure is shown in figureÊ23.2/1. 1) Short Message (3GPP TS 24.011 [37]). 2) MAP_SEND_INFO_FOR_MO_SMS (*). 3) MAP_SEND_INFO_FOR_MO_SMS_ACK (*). 4) TCAP BEGIN (**) 4a) TCAP CONTINUE (**) 4b) MAP_MO_FORWARD_SHORT_MESSAGE. 5) Short message (3GPP TS 23.040). 6) Short message Acknowledgement (3GPP TS 23.040). 7) MAP_MO_FORWARD_SHORT_MESSAGE_ACK. 8) Short Message Acknowledgement (3GPP TS 24.011 [37]). (*) Messages 2) and 3) are not used by the SGSN. (**) If a) the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message and b) the Interworking MSC operator and the serving node (MSC or SGSN) operator agreed not to use the TCAP handshake countermeasure against SMS fraud for messages exchanged between their networks (see 3GPP TS 33.204 [34a]) then the TCAP handshake may be omitted. FigureÊ23.2/1: Mobile originated short message transfer In addition the following MAP services are used: MAP_PROCESS_ACCESS_REQUEST (see clauseÊ8.3); (*) MAP_AUTHENTICATE (see clauseÊ8.5); (*) MAP_SET_CIPHERING_MODE (see clauseÊ8.6); (*) MAP_PROVIDE_IMSI (see clauseÊ8.9); (*) MAP_CHECK_IMEI (see clauseÊ8.7); MAP_FORWARD_NEW_TMSI (see clauseÊ8.9); (*) MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauseÊ9.1); (*) MAP_READY_FOR_SM (see clauseÊ12.4). (*) These services are not used by the SGSN. 23.2.1 Procedure in the serving MSC Any CAMEL-specific handling defined in this clause is omitted if the MSC does not support CAMEL control of MO SMS, or if the subscriber does not have a subscription for CAMEL control of MO SMS. The process starts when the MSC receives a short message from the MS. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the MSC is integrated with the SMS-IWMSC, it communicates directly with the Short Message Service Centre (SMSC) using one of the protocols described in 3GPP TS 23.039 [25a]; otherwise it communicates with the SMS-IWMSC using MAP. Sheet 3: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message, the test ""Message segmentation needed"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. Sheet 3:The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the serving MSC's operator and the SMS-IWMSC's operator (see 3GPP TS 33.204 [34a]). The mobile originated short message service process in the MSC is shown in figureÊ23.2/2. 23.2.2 Procedure in the VLR Any CAMEL-specific handling defined in this clause is omitted if the VLR does not support CAMEL control of MO SMS. The process starts when the VLR receives a dialogue opening request followed by a MAP_PROCESS_ACCESS_REQUEST including a CM service type Short Message Service. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1; Process_Access_Request_VLR see clauseÊ25.4.2. The mobile originated short message transfer process in the VLR is shown in figureÊ23.2/3. 23.2.3 Procedure in the SGSN Any CAMEL-specific handling defined in this clause is omitted if the SGSN does not support CAMEL control of MO SMS, or if the subscriber does not have a subscription for CAMEL control of MO SMS. The process starts when the SGSN receives a short message received from the MS over the Gb interface. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 2: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message, the test ""Message segmentation needed"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. Sheet 2:The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the serving SGSN's operator and the SMS-IWMSC's operator (see 3GPP TS 33.204 [34a]). The mobile originated short message service process in the SGSN is shown in figure 23.2/4. 23.2.4 Procedure in the SMS Interworking MSC (SMS-IWMSC) This procedure applies only when the SMS-IWMSC is not integrated with the serving MSC or SGSN. The process starts when the SMS-IWMSC receives a dialogue opening request with the application context shortMsgMO-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. Sheet 1:The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the SMS-IWMSC's operator and the serving node's operator (see 3GPP TS 33.204 [34a]). The mobile originated short message service transfer process in the SMS-IWMSC is shown in figureÊ23.2/5. FigureÊ23.2/2 (sheet 1 of 4): Process MO_SM_MSC FigureÊ23.2/2 (sheet 2 of 4): Process MO_SM_MSC FigureÊ23.2/2 (sheet 3 of 4): Process MO_SM_MSC FigureÊ23.2/2 (sheet 4 of 4): Process MO_SM_MSC FigureÊ23.2/3 (sheet 1 of 2): Process MOSM_VLR FigureÊ23.2/3 (sheet 2 of 2): Process MO_SM_VLR Figure 23.2/4 (sheet 1 of 3): Process MO_SM_SGSN Figure 23.2/4 (sheet 2 of 3): Process MO_SM_SGSN Figure 23.2/4 (sheet 3 of 3): Process MO_SM_SGSN FigureÊ23.2/5 (sheet 1 of 2): Process MO_SM_IWMSC FigureÊ23.2/5 (sheet 2 of 2): Process MO_SM_IWMSC 23.3 The mobile terminated short message transfer procedure The mobile terminated short message transfer procedure is used for forwarding a short message or several short messages from a Service Centre to a mobile subscriber. The message flow for the mobile terminated short message procedure for a single short message transfer is shown in figureÊ23.3/1. FigureÊ23.3/1: Mobile terminated short message service procedures 1) Short Message (3GPP TS 23.040). 2) MAP_SEND_ROUTING_INFO_FOR_SM. 3) MAP_SEND_ROUTING_INFO_FOR_SM_ACK. 4) TCAP BEGIN (***) 4a) TCAP CONTINUE (***) 4b) MAP_MT_FORWARD_SHORT_MESSAGE. The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 5) MAP_SEND_INFO_FOR_MT_SMS (*). 5a) MAP_CONTINUE_CAMEL_SMS_HANDLING (*)(**) 5b) MAP_SEND_INFO_FOR_MT_SMS (*)(**) 6) MAP_PAGE/MAP_SEARCH_FOR_MOBILE_SUBSCRIBER (*). 7) Page (3GPP TS 24.008 [35]). 8) Page response (3GPP TS 24.008 [35]). 9) MAP_PROCESS_ACCESS_REQUEST_ACK and MAP_SEARCH_FOR_MOBILE_SUBSCRIBER_ACK (*). 10) MAP_SEND_INFO_FOR_MT_SMS_ACK (*). 11) Short Message (3GPP TS 24.011 [37]). 12) Short Message Acknowledgement (3GPP TS 24.011 [37]). 13) MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 14) Short Message Acknowledgement (3GPP TS 23.040). (*) Messages 5), 5a), 5b), 6), 9), and 10) are not used by the SGSN. (**) These messages are used only for a subscriber provisioned with MT-SMS-CSI in the VLR. (***) If a) - the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, and b) the SMS Gateway MSC operator and the serving node (MSC or SGSN) operator agreed not to use the TCAP handshake countermeasure against SMS fraud for messages exchanged between their networks (see 3GPP TS 33.204 [34a]) then the TCAP handshake may be omitted. The message flow for the mobile terminated short message procedure for multiple short message transfer is shown in figureÊ23.3/2. FigureÊ23.3/2: Mobile terminated short message procedure for multiple short message transfer 1) Short Message (3GPP TS 23.040 [26]). 2) MAP_SEND_ROUTING_INFO_FOR_SM. 3) MAP_SEND_ROUTING_INFO_FOR_SM_ACK. 4) TCAP BEGIN (***) 4a TCAP CONTINUE (***) 4b) MAP_MT_FORWARD_SHORT_MESSAGE (note 1). The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 5) MAP_SEND_INFO_FOR_MT_SMS (*). 5a) MAP_CONTINUE_CAMEL_SMS_HANDLING (*)(**) 5b) MAP_SEND_INFO_FOR_MT_SMS (*)(**) 6) MAP_PAGE/MAP_SEARCH_FOR_MOBILE_SUBSCRIBER (*). 7) Page (3GPP TS 48.008 [49]). 8) Page response (3GPP TS 24.008 [35]). 9) MAP_PROCESS_ACCESS_REQUEST_ACK and MAP_SEARCH_FOR_MOBILE_SUBSCRIBER_ACK (*). 10) MAP_SEND_INFO_FOR_MT_SMS_ACK (*). 11) Short Message (3GPP TS 24.011 [37]). 12) Short Message Acknowledgement (3GPP TS 24.011 [37]). 13) MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 14) Short Message Acknowledgement (3GPP TS 23.040 [26]). 15) Short Message (3GPP TS 23.040 [26]). 16) MAP_MT_FORWARD_SHORT_MESSAGE (note 2). The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 17) Short Message (3GPP TS 24.011 [37]). 18) Short Message Acknowledgement (3GPP TS 24.011 [37]). 19) MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 20) Short Message Acknowledgement (3GPP TS 23.040 [26]). (*) Messages 5), 5a), 5b) 6), 9), and 10) are not used by the SGSN. (**) These messages are used only for a subscriber provisioned with MT-SMS-CSI in the VLR. (***) If a) the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, and b) the SMS Gateway MSC operator and the serving node (MSC or SGSN) operator agreed not to use the TCAP handshake countermeasure against SMS fraud for messages exchanged between their networks (see 3GPP TS 33.204 [34a]) then the TCAP handshake may be omitted. NOTE 1: The ""More Messages To Send"" flag is TRUE. NOTE 2: The ""More Messages To Send"" flag is FALSE. In the multiple short message transfer the service MAP_MT_FORWARD_SHORT_MESSAGE can be used several times. However, the short message transfer is always acknowledged to the Service Centre before the next short message is sent. In addition the following MAP services are used: MAP_PROCESS_ACCESS_REQUEST (see clauseÊ8.3); (*) MAP_PAGE (see clauseÊ8.2); (*) MAP_SEARCH_FOR_MS (see clauseÊ8.2); (*) MAP_AUTHENTICATE (see clauseÊ8.5); (*) MAP_SET_CIPHERING_MODE (see clauseÊ8.6); (*) MAP_CHECK_IMEI (see clauseÊ8.7); MAP_FORWARD_NEW_TMSI (see clauseÊ8.9); (*) MAP_REPORT_SM_DELIVERY_STATUS (see clauseÊ12.3); MAP_INFORM_SERVICE_CENTRE (see clauseÊ12.6); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauseÊ9.1); (*) MAP_READY_FOR_SM (see clauseÊ12.4). (*) These services are not used by the SGSN. A message flow example for the mobile terminated short message procedure for a single short message transfer in an environment that makes use of an SMS Router for MT-short-message-transfer is shown in figureÊ23.3/2a. NOTE: This message flow can be applied only if no IP-SM-GW deployed in the same network. FigureÊ23.3/2a Mobile terminated short message procedure with SMS Router 1) Short Message (3GPP TS 23.040 [26]) 2) & 3) MAP_SEND_ROUTING_INFO_FOR_SM NOTE: The HLR relays the message MAP_SEND_ROUTING_INFO_FOR_SM received from the SMS-GMSC to the SMS Router on SCCP level. How this is done is implementation specific. 4) MAP_SEND_ROUTING_INFO_FOR_SM 5) MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE 6) MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE 7) Conditionally: Inform Service Centre (3GPP TS 23.040 [26]) 8) MAP_MT_FORWARD_SHORT_MESSAGE The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. NOTE: In this example the SMS-GMSC decides to attempt delivery via MSC. Therefore the SCCP called party SSN shall be set to SSN for MSC. 9) MAP_MT_FORWARD_SHORT_MESSAGE The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 10) MAP_MT_FORWARD_SHORT_MESSAGE_ERROR NOTE: In this example delivery via the MSC is unsuccessful e.g. due to IMSI detached 11) MAP_MT_FORWARD_SHORT_MESSAGE_ERROR 12) MAP_MT_FORWARD_SHORT_MESSAGE NOTE: In this example the SMS-GMSC decides to retry delivery via the SGSN. Therefore the SCCP called party SSN shall be set to the SSN for SGSN. 13) MAP_MT_FORWARD_SHORT_MESSAGE The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 14) MAP_MT_FORWARD_SHORT_MESSAGE_ACK NOTE: In this example delivery via SGSN is successful 15) MAP_MT_FORWARD_SHORT_MESSAGE_ACK 16) Conditionally: MAP_REPORT_SM_DELIVERY_STATUS NOTE: In this example unsuccessful delivery via MSC and successful delivery via SGSN is reported 17) MAP_REPORT_SM_DELIVERY_STATUS_Ack 18) Short Message Acknowledgement (3GPP TS 23.040 [26]). A message flow example for the mobile terminated short message procedure for a single short message transfer in an environment that makes use of an IP-SM-GW (see 3GPP TS 23.204 [134]) for MT-short-message-transfer is shown in figureÊ23.3/2b. NOTE: SMS Routers can apply this message flow as well. FigureÊ23.3/2b Mobile terminated short message procedure with IP-SM-GW 1) Short Message (3GPP TS 23.040 [26]) 2) MAP_SEND_ROUTING_INFO_FOR_SM the message is forwarded to the IP-SM-GW assigned to the recipient of the SM the message may contain IP-SM-GW Guidance support indication 3) MAP_SEND_ROUTING_INFO_FOR_SM 4) MAP_SEND_ROUTING_INFO_FOR_SM since the message is received from an IP-SM-GW, it is not forwarded to an IP-SM-GW 5) MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE 6) MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE The IP-SM-GW returns its own address within the network node number parameter The message may include IP-SM-GW Guidance 7) Conditionally: Inform Service Centre (3GPP TS 23.040 [26]) 8) MAP_MT_FORWARD_SHORT_MESSAGE If the IP-SM-GW-Guidance support indicator was present in message 2 and IP-SM-GW-Guidance was present in message 6, message 8 shall contain the used timer value for supervision of MAP_MT_FORWARD_SHORT_MESSAGE_ACK; the used timer should be identical to the recommended value received in message 6 to ensure that the IP-SM-GW can attempt delivery to multiple domains if necessary and shall not be lower than the minimum value received in message 6 to ensure that an IP-SM-GW can attempt delivery to at least one domain. Otherwise, The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK."
"9) MAP_MT_FORWARD_SHORT_MESSAGE_ACK 10) Conditionally: MAP_REPORT_SM_DELIVERY_STATUS NOTE: As an IP-SM-GW is deployed the message is acknowledged ignoring its content 11) MAP_REPORT_SM_DELIVERY_STATUS_Ack 12) Conditionally: MAP_REPORT_SM_DELIVERY_STATUS since the message is received from an IP-SM-GW, it is processed 13) MAP_REPORT_SM_DELIVERY_STATUS_Ack NOTE: Step 12 and 13 is independent of steps 10, 11, and 14. They can run in parallel. 14) Short Message Acknowledgement (3GPP TS 23.040 [26]). 23.3.1 Procedure in the SMS-GMSC Any CAMEL-specific handling described in this clause is omitted if the SMS-GMSC does not support CAMEL. CAMEL-specific handling is invoked only if the SMS-GMSC is integrated with the VMSC. The process starts when the SMS-GMSC receives an SC_RP_MT_DATA indication from a Service Centre. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Process MT_SM_GMSC sheet 1: If the MAP_SEND_ROUTING_INFO_FOR_SM confirmation included an LMSI, it shall be included in the sm-RP-DA information field of the first MAP_MT_FORWARD_SHORT_MESSAGE request sent to the serving MSC. In this case, the IMSI shall be included in the Destination Reference of the MAP_OPEN request. The SMS-GMSC shall not send an LMSI to an SGSN. If the SMS-GMSC does not send an LMSI to the serving node, the sm-RP-DA information field in the first MAP_MT_FORWARD_SHORT_MESSAGE request sent to the serving MSC or SGSN shall contain the IMSI, and the Destination Reference in the MAP_OPEN request shall not be present. The parameter SM_RP_OA shall contain the Service Centre address. Process MT_SM_GMSC sheet 1: The indication of which number belongs to the SGSN and which to the MSC, received from the HLR in the MAP_SEND_ROUTING_INFO_FOR_SM confirm (see clause 23.3.2) will enable the SMS-GMSC to map the causes received from one or both serving nodes into the appropriate causes for non GPRS, GPRS or both, and send them to the SC and the HLR. Process MT_SM_GMSC sheet 2: The SMS-GMSC maps ""Unexpected data value"" and ""System failure"" MAP errors from the serving node to a ""System failure"" RP_ERROR error cause. The mapping between other MAP error causes and the RP_ERROR error cause is given in 3GPP TSÊ23.040Ê[26] and 3GPP TSÊ24.011Ê[37]. Process MT_SM_GMSC sheet 2: If the SMS-GMSC receives both MSC and SGSN numbers from the HLR as routeing information, it may choose which serving node to use for the first delivery attempt. Process MT_SM_GMSC sheet 2: If the SMS-GMSC makes two delivery attempts, it may report the result of each delivery attempt to the HLR according to the conditions described below. Procedure MT_SM_Delivery_Attempt_GMSC sheet 1: if the macro MT_SM_Transfer_MSC takes the Error exit, the SMS-GMSC maps the MAP User Error to the corresponding SC_RP error, as defined in 3GPP TSÊ23.040Ê[26]. Procedure MT_SM_Delivery_Attempt_GMSC sheet 3: The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the GMSC's operator and the serving node's operator (see 3GPP TS 33.204 [34a]). Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 2, sheet 4, sheet 5: The SMS-GMSC invokes the macro Report_SM_Delivery_Stat_GMSC if: - the reason received from the serving node for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause ""MS memory capacity exceeded"", and the SC address is not yet included in the MWD set, or - the reason received from the serving node for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause MS memory capacity exceeded, and the corresponding flag in the HLR (as indicated in the information received in the MAP_INFORM_ SERVICE_CENTRE) is not set, or - the reason received from the serving node (MSC or SGSN) for failure to deliver the message is absent subscriber_SM and the absent subscriber diagnostic is different from the absent subscriber diagnostic received in the MAP_INFORM_ SERVICE_CENTRE. Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 2, sheet 4, sheet 5: If absent subscriber diagnostic information (see 3GPP TSÊ23.040Ê[26]) is included with the absent subscriber_SM error indication then the SMS-GMSC relays this information to the HLR using the MAP_REPORT_SM_DELIVERY_STATUS service. Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 4: The More Messages To Send flag is set to TRUE or FALSE according to the information received from the Service Centre. Procedure MT_SM_Delivery_Attempt_GMSC sheet 3: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, the test ""Message segmentation needed"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The mobile terminated short message transfer process in the SMS-GMSC is shown in figureÊ23.3/3. The procedure MT_SM_Delivery_Attempt_GMSC is shown in figureÊ23.3/4. The macro MT_SM_Transfer_MSC is shown in figureÊ23.3/7. The SMS-GMSC may include the Maximum Retransmission Time IE in the MT Forward Short Message Request to indicate that it is capable to retransmit the Short Message until the indicated maximum retransmission time, if the following conditions are fulfilled: - the destination user pertains to the PLMN of the SMS-GMSC; and - if an SMS Router is used for MT SMS sent to destination users pertaining to the PLMN of the SMS-GMSC, the SMS Router is known to support the Alert Service Centre procedure specified in clause 12.5. The SMS-GMSC shall include its E.164 number in the SMS-GMSC address and, if available its Diameter Identity in the SMS-GMSC Diameter Address in the request if it also includes the Maximum-Retransmission-Time IE. If subsequently, the SMS-GMSC receives an Alert Service Centre request from an MME (via an IWF), SGSN or MSC, the SMS-GMSC shall retransmit pending MT SMS(s) for the destination user identified by the User Identifier Alert, to the same serving node if the SMS-GMSC Alert Event indicates that the MS is available for MT SMS, or to the new serving node if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME, SGSN or MSC. In the latter case, if neither New MSC Number, nor New SGSN Number, nor New SGSN Diameter Address, nor New MME Number, nor New MME Diameter Address are received in the Alert Service Centre request, the SMS-GMSC shall initiate a Send Routing Info for SM procedure to retrieve the new serving node 's address from the HLR. 23.3.2 Procedure in the HLR The process starts when the HLR receives a MAP_SEND_ROUTING_INFO_FOR_SM indication from the SMS-GMSC. If an SMS Router is deployed, the HLR receives MAP_SEND_ROUTING_INFO_FOR_SM from the SMSÊRouter (step 4 in figure 23.3/2a); relaying a message received from the SMS-GMSC to the SMS Router on SCCP level (steps 2 and 3 in figure 23.3/2a) is done by implementation specific means and is not shown in figure 23.3/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. Sheet 1: The decision box ""Relay to IP-SM-GW"" takes the ""yes"" exit if an IP-SM-GW is deployed and the message was not received from an IP-SM-GW. Sheet 3: If the SMS-GMSC does not support GPRS functionality, it uses the protocol defined in the Release 96 version of this specification. The parameter ""msc-Number"" in ""RoutingInfoForSM-Res"" in the Release 96 version of the protocol definition corresponds to the parameter ""networkNode-Number"" in ""RoutingInfoForSM-Res"" in the Release 97 (and later) version of the protocol definition; therefore if the HLR populates the parameter ""networkNode-Number"" with the SGSN number, the Release 96 SMS-GMSC will interpret the SGSN number as an MSC number. If the HLR populates the ""gprsNodeIndicator"" parameter in the MAP_SEND_ROUTING_INFO_FOR_SM response, a Release 96 SMS-GMSC will silently discard the parameter. Sheet 5: If the HLR received a LMSI from the VLR at location updating, it shall include the LMSI in the MAP_SEND_ROUTING_INFO_FOR_SM response only if the MAP_SEND_ROUTING_INFO_FOR_SM response also includes the MSC number. The mobile terminated short message transfer process in the HLR is shown in figureÊ23.3/5. 23.3.3 Procedure in the Serving MSC Any CAMEL-specific handling defined in this clause is omitted if the MSC does not support CAMEL control of MT SMS, or if the subscriber does not have a subscription for CAMEL control of MT SMS. The process starts when the MSC receives a dialogue opening request with the application context shortMsgMT-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. The mobile terminated short message transfer process in the serving MSC is shown in figure 23.3/6 Procedure MT_SM_VMSC sheet 1: The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the Serving MSC's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]). The macro MT_SM_Transfer_MSC may be invoked either in a stand-alone serving MSC or in a serving MSC which is integrated with the SMS-GMSC. It is used to transfer the first MT short message of a possible sequence of messages. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Confirmation see clauseÊ25.2.2. Page_MSC see clauseÊ25.3.1; Search_for_MS_MSC see clauseÊ25.3.2; Process_Access_Request_MSC see clauseÊ25.4.1; Trace_Subscriber_Activity_MSC see clauseÊ25.9.1. The macro MT_SM_Transfer_MSC is shown in figure 23.3/7. The macro Check_Subscr_Identity_For_MT_SMS is shown in figure 23.3/8. 3GPP TS 29.118 [152] specifies the extensions applicable to the MT SMS procedure over SGs for a UE using extended idle mode DRX (as defined in 3GPP TSÊ23.682 [148]). If the MS is using a power saving mechanism such as extended idle mode DRX (see 3GPP TSÊ23.682 [148]), and if the MT Forward Short Message Request includes the Maximum Retransmission Time IE, an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPPÊTSÊ23.272Ê[143] and 3GPP TS 23.040 [6]) may return an MT Forward Short Message Response with the User Error set to Absent Subscriber_SM and with the Requested-Retransmission-Time IE requesting the SMS-GMSC to retransmit the Short Message at a later time prior to the Maximum Retransmission Time. In that case, the MSC shall store (if not already done) the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and shall not set the MNRF flag. NOTE: This mechanism does not cause additional signalling at the HSS to retransmit the Short Message. An MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPPÊTSÊ23.272Ê[143] and 3GPP TS 23.040 [6]) shall initiate the MAP Service Center Alert procedure to alert the SMS-GMSC when the UE, for which one or more MT SMS have been requested to be retransmitted at a later time, becomes available for MT SMS delivery or moves under the coverage of another MSC prior to the requested SM retransmission time. The MSC shall then delete the stored SMS-GMSC address after the Alert Service Centre procedure is completed. 23.3.4 Procedure in the VLR Any CAMEL-specific handling defined in this clause is omitted if the VLR does not support CAMEL control of MT SMS. The process starts when the VLR receives a dialogue opening request from the MSC. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The mobile terminated short message transfer process in the VLR is shown in figureÊ23.3/9. If the VLR has no IMSI record, or if the record is marked ""Subscriber Data Not Confirmed by HLR"", the VLR may perform the data restoration procedure as specified in clause 4.2.2 in 3GPP TS 23.007 [19]. 23.3.5 Procedure in the SGSN Any CAMEL-specific handling defined in this clause is omitted if the SGSN does not support CAMEL control of MT SMS, or if the subscriber does not have a subscription for CAMEL control of MT SMS. The process starts when the SGSN receives a dialogue opening request with the application context shortMsgMT-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. The mobile terminated short message transfer process in the SGSN is shown in figure 23.3/10. Procedure MT_SM_SGSN sheet 1: The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the Serving SGSN's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]). The macro MT_SM_Transfer_SGSN is used to transfer the first MT short message of a possible sequence of messages. It is shown in figure 23.3/11. If the MS is using extended idle mode DRX (as defined in 3GPP TSÊ23.682 [148]) and the MS is expected to respond to paging shortly or within the time frame indicated by the SM-Delivery-Timer and SM-Delivery-Start-Time IEs, the SGSN should page the MS and attempt to deliver the short message to the MS. If the MS is using extended idle mode DRX (as defined in 3GPP TSÊ23.682 [148]) and the MS is expected to not respond to paging shortly or within the time frame indicated by the SM-Delivery-Timer and SM-Delivery-Start-Time IEs, the SGSN may behave as specified in figure 23.3/11 for an MS that is not reachachable, i.e. set the MNRG flag and return an Absent Subscriber Error to the SMS-GMSC, while still paging the MS. NOTE 1: This mechanism is not intended for MSs which are known to wake up shortly (e.g. within the next 10 seconds) as enough time needs to elapse, between the sending of the MT Forward Short Message Response and the subsequent Ready For SM procedure towards the HLR when the MS becomes reachable, for the Report SM Delivery Status procedure to take place beforehand from the SMS-GMSC to the HLR. If the MS is using a power saving mechanism such as extended idle mode DRX (see 3GPP TSÊ23.682 [148]), and if the MT Forward Short Message Request includes the Maximum Retransmission Time IE, the SGSN may return an MT Forward Short Message Response with the User Error set to Absent Subscriber_SM and with the Requested-Retransmission-Time IE requesting the SMS-GMSC to retransmit the Short Message at a later time prior to the Maximum Retransmission Time. In that case, the SGSN shall store (if not already done) the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and shall not set the MNRG flag. NOTE 2: This mechanism does not cause additional signalling at the HSS to retransmit the Short Message. The SGSN shall initiate the MAP Service Center Alert procedure to alert the SMS-GMSC when the UE, for which one or more MT SMS have been requested to be retransmitted at a later time, becomes available for MT SMS delivery or moves under the coverage of another MME or SGSN prior to the requested SM retransmission time. The SGSN shall then delete the stored SMS-GMSC address after the Alert Service Centre procedure is completed. The macro Check_Subscr_Identity_For_MT_SMS is shown in figure 23.3/8. The page and search procedures are shown in figuresÊ23.3/12 and 23.3/13. 23.3.6 Procedure in the SMS Router If SMS Router is deployed together with IP-SM-GW, then mobile terminated short message transfer process for IP-SM-GW applies as described in clauseÊ23.3.7. The mobile terminated short message transfer process in the SMS Router is shown in figureÊ23.3/14. Procedure MT_SM_SMS_ROUTER sheet 2: Allocated MT Correlation IDs have a limited lifetime, managed by Timer T1. The value of Timer T1 shall be operator configurable (its value being dependant on such factors as subscriber base, network size, number of roaming/SMS interworking partners, average and peak SMS traffic load, etc.). The value of the timer T1 shall cover at least the time indicated by the SM Delivery Start Time and SM Delivery Timer and, if the SMS Router support the Alert Service Centre procedure specified in clause 12.5, the Maximum Retransmission Time signalled in the MAP-MT-FORWARD-SHORT-MESSAGE. Procedure MT_SM_SMS_ROUTER sheet 2: MAP parameters to be stored against the MT Correlation ID are IMSI, networkNode-Number, gprsNodeIndicator, and additional-Number (if and as received within MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_cnf), and optionally MSISDN as received within MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_ind from the SMS-GMSC (and relayed by the HLR)). The SMS Router may also store the GT, or just the CC and NDC parts of the GT, of the SMS-GMSC from which the MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_ind was received. Procedure MT_SM_SMS_ROUTER sheet 3: The SCCP called party SSN received with Open_ind is used to decide whether the new dialogue is opend with the MSC or with the SGSN. The detail of replacing RP-OA is described in TS23.040 [26]. Procedure MT_SM_SMS_ROUTER sheet 4: The decision box ""Retry expected"" takes the ""Yes"" exit if two addresses were received from the HLR, the first delivery attempt was unsuccessful, and the second attempt has not yet been made. Procedure MT_SM_SMS_ROUTER sheet 4: The task ""Release MT Correlation ID"" includes deleting of data stored against the MT Correlation ID. If the MT Forward Short Message Request includes the Maximum-Retransmission-Time IE, the SMS Router shall store the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and replace it by its SMS Router address (E.164 number) and, if available, its SMS Router Diameter Identity when forwarding the request to the MME (via an IFW), SGSN or MSC. If the MT Forward Short Message Response includes the Requested-Retransmission-Time IE, the SMS Router shall include the User Identifier Alert IE when forwarding the response to the SMS-GMSC. NOTE: The User Identifier Alert is further used in the Alert Service Centre procedure specified in clause 12.5 to enable the SMS-GMSC to identify and retransmit all pending MT SMS messages towards the destination user. When receiving an Alert Service Centre request from an MME (via an IWF), SGSN or MSC, the SMS-Router shall replace the IMSI received in the IMSI IE by the User Identifier Alert previously sent in the MT Forward Short Message Response, and forward that request to the SMS-GMSC. 23.3.7 Procedure in the IP-SM-GW Process MT_SM_IPSMGW sheet 3: After unsuccessful delivery via the S-CSCF the IP-SM-GW may retry delivery via MSC and/or SGSN if MSC address and/or SGSN address are available (unless the reported error was ""memory capacity exceeded"" in which case a retry shall not be done). If the retry is successful, a positive response is returned to the SMS-GMSC. If the retry is unsuccessful, an error indication is returned to the SMS-GMSC as follows: If one of the error indications received from S-CSCF, MSC, or SGSN is AbsentsSubscriberSM or UnidentifiedSubscriber, this error shall be returned to the SMS-GMSC. Process MT_SM_IPSMGW sheet 3: The IP-SM-GW invokes the macro Report_SM_Delivery_Stat_IPSMGW if: - the reason for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause ""MS memory capacity exceeded"", and the SC address is not yet included in the MWD set, or - the reason for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause MS memory capacity exceeded, and the corresponding flag in the HLR (as indicated in the information received in the MAP_INFORM_SERVICE_CENTRE) is not set, or - the reason for failure to deliver the message is absent subscriber_SM and the absent subscriber diagnostic is different from the absent subscriber diagnostic received in the MAP_INFORM_SERVICE_CENTRE. The mobile terminated short message transfer process in the IP-SM-GW is shown in figureÊ23.3/15. FigureÊ23.3/3 (sheet 1 of 2): Process MT_SM_GMSC Figure 23.3/3 (sheet 2 of 2): Process MT_SM_GMSC FigureÊ23.3/4 (sheet 1 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 2 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 3 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 4 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 5 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 6 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 7 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 8 of 8): Procedure MT_SM_Delivery_Attempt_GMSC Figure 23.3/5 (sheet 1 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 2 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 3 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 4 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 5 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 6 of 6): Process MT_SM_HLR Figure 23.3/5a (sheet 1 of 1): Procedure Perform_Relaying FigureÊ23.3/6 (sheet 1 of 4): Procedure MT_SM_VMSC FigureÊ23.3/6 (sheet 2 of 4): Procedure MT_SM_VMSC FigureÊ23.3/6 (sheet 3 of 4): Procedure MT_SM_VMSC FigureÊ23.3/6 (sheet 4 of 4): Procedure MT_SM_VMSC FigureÊ23.3/7 (sheet 1 of 4): Macro MT_SM_Transfer_MSC FigureÊ23.3/7 (sheet 2 of 4): Macro MT_SM_Transfer_MSC FigureÊ23.3/7 (sheet 3 of 4): Macro MT_SM_Transfer_MSC FigureÊ23.3/7 (sheet 4 of 4): Macro MT_SM_Transfer_MSC FigureÊ23.3/8: Macro Check_Subscr_Identity_For_MT_SMS FigureÊ23.3/9 (sheet 1 of 3): Process MT_SM_VLR FigureÊ23.3/9 (sheet 2 of 3): Process MT_SM_VLR Figure 23.3/9 (sheet 3 of 3): Process MT_SM_VLR Figure 23.3/10 (sheet 1 of 4): Process MT_SM_SGSN Figure 23.3/10 (sheet 2 of 4): Process MT_SM_ SGSN Figure 23.3/10 (sheet 3 of 4): Process MT_SM_ SGSN Figure 23.3/10 (sheet 4 of 4): Process MT_SM_ SGSN Figure 23.3/11 (sheet 1 of 3): Macro MT_SM_TRANSFER_SGSN Figure 23.3/11 (sheet 2 of 3): Macro MT_SM_TRANSFER_SGSN Figure 23.3/11 (sheet 3 of 3): Macro MT_SM_TRANSFER_SGSN Figure 23.3/12 (sheet 1 of 1): Procedure Page_SMS_SGSN Figure 23.3/13 (sheet 1 of 1): Procedure Search_SMS_SGSN Figure 23.3/14 (sheet 1 of 4): Process MT_SM_ SMS_ROUTER Figure 23.3/14 (sheet 2 of 4): Process MT_SM_ SMS_ROUTER Figure 23.3/14 (sheet 3 of 4): Process MT_SM_ SMS_ROUTER Figure 23.3/14 (sheet 4 of 4): Process MT_SM_ SMS_ROUTER Figure 23.3/15 (sheet 1 of 3): Process MT_SM_ IPSMGW Figure 23.3/15 (sheet 2 of 3): Process MT_SM_ IPSMGW Figure 23.3/15 (sheet 3 of 3): Process MT_SM_ IPSMGW 23.4 The Short Message Alert procedure The Short Message Alert procedure is used to alert the Service Centre when the mobile subscriber is active after a short message transfer has failed because the mobile subscriber is not reachable, or when the MS has indicated that it has memory capacity to accept a short message. The message flow for the Short Message Alert procedure for the case when the mobile subscriber was not reachable is shown in figureÊ23.4/1. 1) CM Service Request (**), Page response or Location Updating (3GPP TS 24.008 [35]). 2) MAP_PROCESS_ACCESS_REQUEST / MAP_UPDATE_LOCATION_AREA (**). 3) MAP_READY_FOR_SM (Mobile Present) / MAP_UPDATE_LOCATION / Supplementary Service Control Request (*). 4) MAP_READY_FOR_SM_ACK (*). 5) MAP_ALERT_SERVICE_CENTRE (notes 1 and 2). 6) Alert Service Centre (3GPP TS 23.040). 7) MAP_ALERT_SERVICE_CENTRE_ACK. NOTE 1: To all Service Centres in the Message Waiting List. NOTE 2: The HLR initiates the MAP_ALERT_SERVICE_CENTRE service only if the MS Memory Capacity Exceeded flag is clear. (*) For GPRS, messages 3) and 4) are sent/received by the SGSN. (**) These messages are not used by the SGSN. FigureÊ23.4/1: Short message alert procedure (Mobile is present) The message flow for the Short Message Alert procedure for the case where the MS indicates that it has memory capacity to accept one or more short messages is shown in figureÊ23.4/2. 1) SM memory capacity available ( 3GPP TS 24.011 [37]). 2) MAP_READY_FOR_SM (Memory Available) (*). 3) MAP_READY_FOR_SM (Memory Available) (**). 4) MAP_READY_FOR_SM_ACK (**). 5) MAP_READY_FOR_SM_ACK (*). 6) SM memory capacity available (Acknowledge) (3GPP TS 24.011 [37]). 7) MAP_ALERT_SERVICE_CENTRE (note). 8) Alert Service Centre (3GPP TS 23.040). 9) MAP_ALERT_SERVICE_CENTRE_ACK. NOTE: To all Service Centres in the Message Waiting List. (*) Messages 2) and 5) are not used by the SGSN. (**) For GPRS, messages 3) and 4) are sent/received by the SGSN. FigureÊ23.4/2: Short message alert procedure (MS memory capacity available) In addition the following MAP services are used in the MS memory available case: MAP_PROCESS_ACCESS_REQUEST (see clauseÊ8.3); (*) MAP_AUTHENTICATE (see clauseÊ8.5); (*) MAP_SET_CIPHERING_MODE (see clauseÊ8.6); (*) MAP_PROVIDE_IMSI (see clauseÊ8.9); (*) MAP_CHECK_IMEI (see clauseÊ8.7); MAP_FORWARD_NEW_TMSI (see clauseÊ8.9); (*) MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauseÊ9.1). (*) (*) These services are not used by the SGSN. The Short Message Alert procedure when the MS indicates successful transfer after polling is shown in figureÊ23.4/3. 1) MAP_REPORT_SM_DELIVERY_STATUS (Successful Transfer). 2) MAP_REPORT_SM_DELIVERY_STATUS_ACK. 3) MAP_ALERT_SERVICE_CENTRE (note). 4) Alert Service Centre (3GPP TS 23.040). 5) MAP_ALERT_SERVICE_CENTRE_ACK. NOTE: To all Service Centres in the Message Waiting List. FigureÊ23.4/3: Short message alert procedure (Successful transfer after polling) 23.4.1 Procedure in the Serving MSC Ð the MS has memory available The process starts when the MSC receives a notification from the MS that it has memory available. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. The short message alert process in the MSC for the MS memory capacity available case is shown in figureÊ23.4/4. 23.4.2 Procedures in the VLR 23.4.2.1 The Mobile Subscriber is present If the VLR successfully handles a MAP_PROCESS_ACCESS_REQUEST indication or a MAP_UPDATE_LOCATION_AREA indication while the MS Not Reachable Flag (MNRF) is set, the VLR sends a MAP_READY_FOR_SM request to the HLR. The Alert Reason is set to indicate that the mobile subscriber is present for non GPRS. If authentication fails during the handling of a MAP_PROCESS_ACCESS_REQUEST indication or a MAP_UPDATE_LOCATION_AREA indication, the VLR shall not send a MAP_READY_FOR_SM request to the HLR. The process in the VLR is described in detail in clauseÊ25.10.1. 23.4.2.2 The MS has memory available The process starts when the VLR receives dialogue opening request followed by a MAP_PROCESS_ACCESS_REQUEST indication including a CM service type Short Message Service. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2. The short message alert process in the VLR for the MS memory capacity available case is shown in figure 23.4/5. 23.4.3 Procedures in the SGSN 23.4.3.1 The Mobile Subscriber is present If the SGSN successfully handles a Page response, Attach request or Routing Area Update request message (3GPP TS 24.008 [35]), while the MS Not Reachable for GPRS (MNRG) flag is set, the SGSN sends a MAP_READY_FOR_SM request to the HLR. The Alert Reason is set to indicate that the mobile subscriber is present for GPRS. If authentication fails during the handling of a Page response, Attach request or Routing Area Update request, the SGSN shall not send a MAP_READY_FOR_SM request to the HLR The process in the SGSN is described in detail in clauseÊ25.10.23. 23.4.3.2 The Mobile Equipment has memory available The process starts when the SGSN receives an RP_SM_MEMORY_AVAILABLE indication from the MS. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The short message alert procedure in the SGSN for the MS memory capacity available case is shown in figureÊ23.4/6. 23.4.4 Procedure in the HLR The process starts when the HLR receives a dialogue opening request using the application context mwdMngtContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1; Alert_Service_Centre_HLR see clauseÊ25.10.3. Sheet 1: If the dialogue opening request is from an SGSN, version 2 and version 1 of the application context are not applicable. The short message alert process in the HLR is shown in figure 23.4/7. 23.4.5 Procedure in the SMS Interworking MSC The process starts when the SMS-IWMSC receives a dialogue opening request using the application context shortMsgAlertContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. The short message alert process in the SMS-IWMSC is shown in figureÊ23.4/8. FigureÊ23.4/4: Procedure SM_Alert_MSC FigureÊ23.4/5 (sheet 1 of 2): Procedure SM_Alert_VLR FigureÊ23.4/5 (sheet 2 of 2): Procedure SM_Alert_VLR Figure 23.4/6 (sheet 1 of 2): Process SM_Alert_SGSN Figure 23.4/6 (sheet 2 of 2): Process SM_Alert_SGSN Figure 23.4/7 (sheet 1 of 2): Process SM_Alert_HLR Figure 23.4/7 (sheet 2 of 2): Process SM_Alert_HLR FigureÊ23.4/8: Process Alert_SC_IWMSC 23.5 The SM delivery status report procedure The SM delivery status report procedure is used: - to set the Service Centre address into the message waiting list in the HLR after short message delivery has failed because the subscriber is absent or unidentified or the memory capacity is exceeded. The procedure sets: - the Memory Capacity Exceeded Flag (MCEF) in the HLR if the MS memory does not have room for more messages; - and/or the MS Not Reachable Flag for non-GPRS if there is no record for the subscriber in the VLR or the subscriber does not respond to paging for delivery via the MSC; - and/or the MS Not Reachable for GPRS (MNRG) flag if there is no record for the subscriber in the SGSN or the subscriber does not respond to paging for delivery via the SGSN; - and/or the UE Not Reachable for IP (UNRI) flag if delivery via the IMS was not successful. - to report to the HLRthat delivery has succeeded. The conditions for report of a successful delivery are described in clauseÊ23.3.1. The message flow for the SM delivery status report procedure is shown in figureÊ23.5/1. 1) MAP_MT_FORWARD_SHORT_MESSAGE_ACK/_NACK (Absent subscriber_SM, unidentified subscriber or memory capacity exceeded). 2) MAP_REPORT_SM_DELIVERY_STATUS. (The HLR ignores the content of this message when an IP-SM-GW is deployed) 2a) MAP_REPORT_SM_DELIVERY_STATUS (sent only by IP-SM-GW) 2b) MAP-REPORT_SM_DELIVERY_STATUS_ACK. 3) MAP_REPORT_SM_DELIVERY_STATUS_ACK. 4) Short Message Negative Acknowledgement (3GPP TS 23.040). FigureÊ23.5/1: Short message delivery status report procedure 23.5.1 Procedure in the SMS-GMSC The conditions for the GMSC to invoke the short message delivery status report procedure are specified in clause 23.3.1. The short message delivery status report macro in the SMS-GMSC is shown in figureÊ23.5/2. 23.5.2 Procedure in the HLR When the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indication while an IP-SM-GW is deployed in the network and the message is not received from an IP-SM-GW, it ignores the information received in the message; otherwise it acts as described in clauseÊ23.6, macro Report_SM_Delivery_Stat_HLR. The short message delivery status report process in the HLR is shown in figureÊ23.5/3. 23.5.3 Procedure in the IP-SM-GW The conditions for the IP-SM-GW and for SMS Router, if deployed with IP-SM-GW, to invoke the short message delivery status report procedure are specified in clause 23.3.7. The short message delivery status report macro in the IP-SM-GW is shown in figureÊ23.5/4. Figure 23.5/2: Macro Report_SM_Delivery_Stat_GMSC FigureÊ23.5/3: Process SM_Delivery_Status_Report_HLR FigureÊ23.5/4: Macro Report_SM_Delivery_Stat_IPSMGW 23.6 The macro Report_SM_Delivery_Stat_HLR This macro is invoked when the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indication from the SMS-GMSC. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clauseÊ25.2.1; Alert_Service_Centre_HLR see clauseÊ25.10.3. Sheet 1: If the MAP_REPORT_SM_DELIVERY_STATUS indication did not include the GPRS support indicator, the HLR deduces the domain for which the delivery report applies as follows: - if the subscriber is a GPRS-only subscriber, the report applies for GPRS; - if the subscriber is a non-GPRS-only subscriber, the report applies for non-GPRS; - if the subscriber is a GPRS and non-GPRS subscriber and the subscription option for MT SMS delivery when the SMS-GMSC does not support GPRS is set to ""Delivery via the SGSN"", the report applies for GPRS; - if the subscriber is a GPRS and non-GPRS subscriber and the subscription option for MT SMS delivery when the SMS-GMSC does not support GPRS is set to ""Delivery via the MSC"", the report applies for non-GPRS; The short message delivery status report macro in the HLR is shown in figureÊ23.6/1. FigureÊ23.6/1 (sheet 1 of 2): Macro Report_SM_Delivery_Stat_HLR FigureÊ23.6/1 (sheet 2 of 2): Macro Report_SM_Delivery_Stat_HLR 23.7 The mobile terminated short message transfer procedure for VGCS The mobile terminated short message transfer for VGCS procedure is used for forwarding a short message from a Service Centre to the group call anchor MSC. The message flow for the mobile terminated short message transfer procedure for VGCS is shown in figureÊ23.7/1. FigureÊ23.7/1: Mobile terminated short message for VGCS service procedures 1) Short Message (3GPP TS 23.040). 2) TCAP BEGIN (*) 3) TCAP CONTINUE (*) 4) MAP_MT_FORWARD_SM_FOR_VGCS. 5) GCR_SMS_INTERROGATION (3GPP TS 43.068). 6) GCR_SMS_INTERROGATION_ACK (3GPP TS 43.068). 7) MAP_MT_FORWARD_SM_FOR_VGCS_ACK. 8) Short Message Acknowledgement (3GPP TS 23.040). (*) If a) - the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SM_FOR_VGCS request in a single TC message, and b) the SMS Gateway MSC operator and the serving node (Anchor-MSC) operator agreed not to use the TCAP handshake countermeasure against SMS fraud for messages exchanged between their networks (see 3GPP TS 33.204 [34a]) then the TCAP handshake may be omitted. 23.7.1 Procedure in the SMS-GMSC The process starts when the SMS-GMSC receives an SC_RP_MT_DATA indication from a Service Centre. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The mobile terminated short message transfer for VGCS process in the SMS-GMSC is shown in figureÊ23.7/2. 23.7.2 Procedure in the Anchor MSC The process starts when the MSC receives a dialogue opening request with the application context shortMsgMT-Relay-VGCS-Context. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; The mobile terminated short message transfer for VGCS process in the Anchor MSC is shown in figure 23.7/3 Procedure MT_SM_VGCS_GMSC sheet 1: The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the Serving MSC's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]). FigureÊ23.7/2 (sheet 1 of 2): Process MT_SM_VGCS_GMSC FigureÊ23.7/2 (sheet 2 of 2): Process MT_SM_VGCS_GMSC FigureÊ23.7/3 (sheet 1 of 2): Process MT_SM_VGCS_Anchor MSC FigureÊ23.7/3 (sheet 2 of 2): Process MT_SM_VGCS_Anchor MSC 24 GPRS process description The MAP GPRS procedures are used for the Network Requested PDP-Context Activation procedures. The stage 2 specification for General Packet Radio Service (GPRS) is in 3GPP TS 23.060 [104]. 24.1 Procedure for retrieval of routeing information for GPRS 24.1.1 Process in the GGSN The MAP process in the GGSN to request routeing information for a network requested PDP context activation is shown in figure 24.1/2. The MAP process invokes macros not defined in this clause; the definition of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24.1.2 Process in the HLR The MAP process in the HLR to provide routing information for a network-requested PDP context activation is shown in figure 24.1/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. FigureÊ24.1/1: Process SRI_GPRS_GGSN FigureÊ24.1/2: Process SRI_GPRS_HLR 24.2 Procedure for reporting failure to establish a network requested PDP context 24.2.1 Process in the GGSN The MAP process in the GGSN to report the failure to establish a network requested PDP context is shown in figure 24.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24.2.2 Process in the HLR The MAP process in the HLR to handle a notification from the GGSN that a network requested PDP context could not be established is shown in figure 24.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check Indication see clause 25.2.1. FigureÊ24.2/1: Process Failure_Report_GGSN FigureÊ24.2/2: Process Failure_Report_HLR 24.3 Procedure for reporting that an MS has become reachable for GPRS 24.3.1 Process in the HLR The MAP process in the HLR to report that an MS is reachable for GPRS is shown in figure 24.3/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24.3.2 Process in the GGSN for Note Ms Present For Gprs The MAP process in the GGSN to handle a notification that the subscriber is present for GPRS again is shown in figure 24.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. FigureÊ24.3/1: Process Note_MS_Present_For_GPRS_HLR FigureÊ24.3/2: Process Note_MS_Present_For_GPRS_GGSN 24A CSE interrogation and control of subscriber data 24A.1 General The MAP procedures for interrogation and control of subscriber data are used to allow the CSE: - to retrieve subscriber data from the HLR; - to modify subscriber data in the HLR; - to receive notification from the HLR when there is a change in subscriber data; - to request information about the location of a subscriber from the HLR or the GMLC; - to request information about the state of a subscriber from the HLR. The following application context refers to a complex MAP user consisting of several processes: - anyTimeInfoHandlingContext This application context needs a co-ordinating process in the HLR. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; The Any Time Info Handling Co-ordinator process in the HLR is shown in figureÊ24A.1/1. FigureÊ24A.1/1: Process Co_ATIH_HLR 24A.2 Any Time Subscription Interrogation procedure 24A.2.1 General The message flow for successful retrieval of subscription information related to an any time subscription interrogation from the CAMEL server are shown in figure 24A.1/1. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this procedure (see 3GPP TS 23.278Ê[125]). FigureÊ24A.2/1: Message flow for any time subscription interrogation The following MAP service is used to retrieve requested information: MAP_ANY_TIME_SUBSCRIPTION_INTERROGATION see clauseÊ8.11.3."
"24A.2.2 Process in the gsmSCF The MAP process in the gsmSCF to obtain subscription information in response to a request from the application process in the gsmSCF is shown in figure 24A.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2 24A.2.3 Process in the HLR The MAP process in the HLR to provide subscription information in response to an interrogation from the CAMEL server is shown in figure 24A.2/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.2 If the MAP_ANY_TIME_SUBSCRIPTION_INTERROGATION service response cannot be carried in a single TC-Result component, it is carried in one or more TC-Result-NL components (each sent in a TC-CONTINUE), followed by a TC-Result-L component in a TC-END message. FigureÊ24A.2/2: Process ATSI_gsmSCF FigureÊ24A.2/3: Process ATSI_HLR 24A.3 Any Time Modification procedure 24A.3.1 General The message flow for successful modification of subscription information related to an any time modification request from the CAMEL server is shown in figure 24A.3/1 FigureÊ24A.3/1: Message flow for any time modification The following MAP service is used to modify subscription information: MAP_ANY_TIME_MODIFICATION see clauseÊ8.11.4. 24A.3.2 Process in the gsmSCF The MAP process in the gsmSCF to modify subscription information in response to a request from the application process in the gsmSCF is shown in figure 24A.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2 24A.3.3 Process in the HLR The MAP process in the HLR to modify subscriber information in response to a modification request from the CAMEL server is shown in figure 24A.3/3. The MAP process invokes a macro and a process not defined in this clause; the definitions of these can be found as follows: Check_Indication see clauseÊ25.2.2; Insert_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.3; If the macro takes the OK exit, the MAP process waits for a service indication. If the MAP_ANY_TIME_MODIFICATION service response cannot be carried in a single TC-Result component, it is carried in one or more TC-Result-NL components (each sent in a TC-CONTINUE), followed by a TC-Result-L component in a TC-END message. If the serving node (VLR or SGSN) is to be updated after the modification, the MAP process creates an instance of the appropriate process (Insert_Subs_Data_Stand_Alone_HLR for VLR update, Insert_GPRS_Subs_Data_Stand_Alone_HLR for SGSN update). FigureÊ24A.3/2: Process ATM_gsmSCF FigureÊ24A.3/3: Process ATM_HLR 24A.4 Subscriber Data Modification Notification procedure 24A.4.1 General The Subscriber Data Modification Notification procedure is used to notify a gsmSCF about the modification of subscriber data. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this procedure. The stage 2 specification for Subscriber Data Modification Notification is in 3GPP TS 23.078Ê[98] and 3GPP TS 23.278Ê[125]. The interworking between the MAP signalling procedures and the Subscriber Data Modification Notification procedures for each entity (HLR, gsmSCF) is shown by the transfer of signals between these processes. The following services are used: FigureÊ24A.4/1: Message flow for subscriber data modification notification The following MAP service is used to send the notification to the gsmSCF: MAP_NOTE_SUBSCRIBER_DATA_MODIFIED see clauseÊ8.11.5. 24A.4.2 Process in the HLR The MAP process in the HLR to send modified data to the gsmSCF is shown in figure 24A.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. If the required information cannot be carried in a single MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service request, the HLR segments the information into two or more requests. The ""All Information Sent"" parameter is omitted from each request except the last. Sheet 2: If the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service request contained the ""All Information Sent"" parameter, the test ""All information sent"" takes the ""Yes"" exit. 24A.4.3 Process in the gsmSCF The MAP process in the gsmSCF to handle a notification to the gsmSCF of change of subscriber data is shown in figure 24A.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1 If the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indication contained the ""All Information Sent"" parameter, the test ""All information sent"" takes the ""Yes"" exit. If the test ""All information sent"" takes the ""No"" exit, the MAP process stores the data received in the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indication. If the test ""All information sent"" takes the ""Yes"" exit, the MAP process assembles the data received in all the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indications received in the dialogue and sends the assembled data to the application process in the gsmSCF. Figure 24A.4/2 (sheet 1 of 2): Process NSDC_HLR Figure 24A.4/2 (sheet 2 of 2): Process NSDC_HLR Figure 24A.4/3: Process NSDC_gsmSCF 24A.5 Any Time Interrogation procedure 24A.5.1 General The message flows for successful retrieval of subscriber information related to an any time interrogation from the CAMEL server are shown in figure 24A.5/1 for interrogation directed to an HLR and figure 24A.5/2 for interrogation directed to a GMLC. 1) MAP_ANY_TIME_INTERROGATION_req/ind 2) MAP_PROVIDE_SUBSCRIBER_INFO_req/ind 3) MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf 4) MAP_ANY_TIME_INTERROGATION_rsp/cnf FigureÊ24A.5/1: Message flow for any time interrogation (gsmSCF to HLR) The following MAP services are used to retrieve information about the status and/or location of a subscriber: MAP_ANY_TIME_INTERROGATION see clauseÊ8.11.1; MAP_PROVIDE_SUBSCRIBER_INFO see clauseÊ8.11.2. The HLR sends the MAP_PROVIDE_SUBSCRIBER_INFO request to the SGSN or the VLR, according to the domain for which the gsmSCF requested the information. 1) MAP_ANY_TIME_INTERROGATION_req/ind 2) MAP_ANY_TIME_INTERROGATION_rsp/cnf Figure 24A.5/2: Message flow for any time interrogation (gsmSCF to GMLC) The following MAP service is used to retrieve location information from a GMLC: MAP_ANY_TIME_INTERROGATION see clauseÊ8.11.1; In addition, the GMLC may use MAP Services specific to Location Services. 24A.5.2 Procedures in the gsmSCF The process in the gsmSCF to request information about the location and/or state of a subscriber from the HLR is shown in figure 24A.5/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The process in the gsmSCF to request location information from the GMLC is shown in figure 24A.5/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 24A.5.3 Procedure in the HLR The MAP process in the HLR to provide subscriber information in response to an interrogation from the CAMEL server is shown in figure 24A.5/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 24A.5.4 Procedure in the GMLC The MAP process in the GMLC to provide location information in response to a request from the gsmSCF is shown in figure 24A.5/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ24A.5/3: Process ATI_To_HLR_gsmSCF FigureÊ24A.5/4: Process ATI_To_GMLC_gsmSCF FigureÊ24A.5/5 (sheet 1 of 2): Process ATI_HLR FigureÊ24A.5/5 (sheet 2 of 2): Process ATI_HLR FigureÊ24A.5/6: Process ATI_GMLC 24B Location Services process description 24B.1 Routeing information retrieval procedure for LCS 24B.1.1 General The message flow for successful retrieval of routeing information related to location services is shown in figure 24B.1/1. FigureÊ24B.1/1: Message flow for retrieval of routeing information for LCS The following MAP service is used to retrieve routeing information: MAP_SEND_ROUTING_INFO_FOR_LCS see clauseÊ13A.1. 24B.1.2 Process in the GMLC The MAP process in the GMLC to request routeing information for LCS is shown in figure 24B.1/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24B.1.3 Process in the HLR The MAP process in the HLR to handle a request for routeing information for LCS is shown in figure 24B.1/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. FigureÊ24B.1/2: Process SRI_LCS_GMLC FigureÊ24B.1/3: Process SRI_LCS_HLR 24B.2 Provide Subscriber Location procedure 24B.2.1 General The message flow for successful retrieval of the location information of a target MS related to location services is shown in figure 24B.1/1. FigureÊ24B.2/1: Message flow for retrieval of location information The following MAP service is used to retrieve location information: MAP_PROVIDE_SUBSCRIBER_LOCATION see clauseÊ13A.2. 24B.2.2 Process in the GMLC The MAP process in the GMLC to request location information from an MSC or an SGSN is shown in figure 24B.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24B.2.3 Process in the MSC The MAP process in the MSC to handle a request for location information from a GMLC is shown in figure 24B.2/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. 24B.2.4 Process in the SGSN The MAP process in the SGSN to handle a request for location information from a GMLC is shown in figure 24B.2/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. FigureÊ24B.2/2: Process PSL_GMLC FigureÊ24B.2/3: Process PSL_MSC FigureÊ24B.2/4: Process PSL_SGSN 24B.3 Subscriber Location Report procedure 24B.3.1 General The message flow for successful report of the location information of a target MS related to location services is shown in figure 24B.3/1. FigureÊ24B.3/1: Message flow for report of the location information The following MAP services are used to report location information: MAP_SUBSCRIBER_LOCATION_REPORT see clauseÊ13A.3. 24B.3.2 Process in the MSC The MAP process in the MSC to send a subscriber location report to the GMLC is shown in figure 24B.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24B.3.3 Process in the SGSN The MAP process in the SGSN to send a subscriber location report to the GMLC is shown in figure 24B.3/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24B.3.4 Process in the GMLC The MAP process in the GMLC to handle a subscriber location report is shown in figure 24B.3/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. Figure 24B.3/2: Process SLR_MSC Figure 24B.3/3: Process SLR_SGSN Figure 24B.3/4: Process SLR_GMLC 25 General macro description 25.1 MAP_OPEN handling macros 25.1.1 Macro Receive_Open_Ind This macro is used by a MAP service-user procedure when a peer entity requests opening of a dialogue. 25.1.2 Macro Receive_Open_Cnf This macro is used by a user procedure after it has requested opening of a dialogue towards a peer entity. Figure 25.1/1 (sheet 1 of 2): Macro Receive_Open_Ind Figure 25.1/1 (sheet 2 of 2): Macro Receive_Open_Ind FigureÊ25.1/2: Macro Receive_Open_Cnf FigureÊ25.1/3: Macro Check_Reference 25.2 Macros to check the content of indication and confirmation primitives 25.2.1 Macro Check_Indication This macro checks that an indication includes all the parameters required by the application, no more and no less, and that the parameters are all within the correct range. It does not handle syntax checking; that is part of the function of the MAP protocol machine. 25.2.2 Macro Check_Confirmation This macro checks whether a confirmation contains an error or a result, and if it contains a result whether the result is correctly formed. FigureÊ25.2/1: Macro Check_Indication FigureÊ25.2/2: Macro Check_Confirmation 25.3 The page and search macros 25.3.1 Macro PAGE_MSC This macro is called if an unstructured SS notification, a network-initiated unstructured SS request or a mobile terminating short message is to be delivered to the MS and the current location area identity of the MS is known in the VLR. If an MM-connection over the radio link already exists for the given IMSI, the MSC sets the access connection status according to the characteristics of the existing connection (i.e. RR-connection established, ciphering mode on/off, MM-connection existing and authenticated or not). If the MSC pages the MS and the VLR provided the TMSI, the MSC uses it to identify the MS at the radio interface; otherwise the MSC uses the IMSI. The MSC also uses the IMSI to determine the page group (see 3GPP TS 24.008 [35]). If the MS responds with a channel request containing an establishment cause which is not ""answer to paging"" the MSC sends a MAP_PAGE response primitive with user error Busy Subscriber. This gives priority to the mobile originating request. Alternatively, as an implementation option, the MSC may treat this as a response to paging, which gives priority to the mobile terminating request. If the paging is for MT SMS delivery and the VLR aborts the transaction before the MSC receives a response from the MS, the MSC aborts the transaction with the SMS-GMSC. 25.3.2 Macro Search_For_MS_MSC This macro is called if an unstructured SS notification, a network-initiated unstructured SS request or a mobile terminating short message is to be delivered to the MS and the current location area identity of the MS is not known in VLR. If an MM-connection over the radio link already exists for the given IMSI, the MSC returns a MAP_SEARCH_FOR_MS response containing the IMSI and current location area identification of the called MS to the VLR and sets the access connection status according to the characteristics of the existing connection (i.e. RR-connection established, ciphering mode on/off, MM-connection existing and authenticated or not). If the MSC pages the MS, the MSC uses the IMSI to identify the subscriber and the page group (see 3GPP TS 24.008 [35]). If the MS responds with a channel request containing an establishment cause which is not ""answer to paging"" the MSC sends a MAP_SEARCH_FOR_MS response with user error Busy Subscriber. This gives priority to the mobile originating request. Alternatively, as an implementation option, the MSC may treat this as a response to paging, which gives priority to the mobile terminating request. If the paging is for MT SMS delivery and the VLR aborts the transaction before the MSC receives a response from the MS, the MSC aborts the transaction with the SMS-GMSC. FigureÊ25.3/1: Macro Page_MSC FigureÊ25.3/2: Macro Search_for_MS_MSC 25.4 Macros for handling an Access Request These macros are invoked when a MS accesses the network, e.g. to submit an MO short message or when responding to paging. The macros handle identification and authentication of the mobile subscriber as well as invocation of security related features (see 3GPP TS 42.009 [6]). 25.4.1 Macro Process_Access_Request_MSC Sheet 1: The MAP_PROCESS_ACCESS_REQUEST request includes the following parameters: - the received subscriber identification (IMSI, TMSI); - the CM service type, indicating the type of request; - the status of the access connection, i.e. whether a connection to this MS already exists and if so, whether it is already authenticated and ciphered; - the current location area id of the MS; and - the CKSN received from the MS. Sheet 2, sheet 3: If the MSC receives an A_SETUP indication while it is waiting for further instructions from the VLR or for the acknowledgment of TMSI reallocation from the MS, the MSC saves the setup request for processing after control has returned from the macro Process_Access_Request_MSC to the calling process. Sheet 3: When the MSC is waiting for a possible instruction to allocate a new TMSI, a MAP_DELIMITER indication indicates that TMSI reallocation is not required. Sheet 3: If the MS sends a TMSI reallocation failure in response to the TMSI reallocation command, the MSC takes the OK exit; the VLR treats the lack of response as a provider error (see macro Process_Access_Request_VLR). 25.4.2 Macro Process_Access_Request_VLR Sheet 3: If the MSC does not send a positive response to the MAP_FORWARD_NEW_TMSI request, this is treated as a MAP_FORWARD_NEW_TMSI confirmation containing a provider error. The Macro takes the Error exit. If TMSI reallocation does not succeed, the old TMSI is frozen, to prevent it from being reallocated. In this case, both old and new TMSIs are regarded as valid. 25.4.3 Macro Obtain_Identity_VLR This macro is invoked by the macro Process_Access_Request_VLR if the subscriber's identity is not known in the VLR. It is an operator option to allow or prevent retrieval of the IMSI without encryption. 25.4.4 Process Update_Location_Child_VLR This process is started when the subscriber successfully accesses the network, e.g. for mobile originated short message submission, response to paging or supplementary services handling. The procedure Notify_gsmSCF is specified in 3GPP TS 23.078. FigureÊ25.4/1 (sheet 1 of 3): Macro Process_Access_Request_MSC FigureÊ25.4/1 (sheet 2 of 3): Macro Process_Access_Request_MSC FigureÊ25.4/1 (sheet 3 of 3): Macro Process_Access_Request_MSC FigureÊ25.4/2 (sheet 1 of 3): Macro Process_Access_Request_VLR FigureÊ25.4/2 (sheet 2 of 3): Macro Process_Access_Request_VLR FigureÊ25.4/2 (sheet 3 of 3): Macro Process_Access_Request_VLR FigureÊ25.4/3: Macro Obtain_Identity_VLR FigureÊ25.4/4 (sheet 1 of 2): Process Update_Location_Child_VLR FigureÊ25.4/4 (sheet 2 of 2): Process Update_Location_Child_VLR 25.5 Authentication macros and processes The following macros are used in the network in order to enable authentication of a mobile subscriber. 25.5.1 Macro Authenticate_MSC This macro is used by the MSC to relay a request for authentication transparently from the VLR to the MS, wait for a response from the MS and relay the response from the MS back to the VLR. 25.5.2 Macro Authenticate_VLR This macro is used by the VLR to control the authentication of a subscriber. Sheet 1: The test ""Received SRES=Expected SRES"" indicates: - a comparison of the Signed RESult received from the MS with the Signed RESult received from the HLR, if GSM authentication is used (see 3GPP TS 43.020 [24]), or - a comparison of the RESult received from the MS with the expected RESult received from the HLR, if UMTS authentication is used (see 3GPP TS 33.102). 25.5.3 Macro Obtain_Authent_Params_VLR This macro is used by the VLR to request authentication vectors from the HLR. Sheet 1, sheet 2, sheet 3: It is an operator option whether to allow the re-use of old authentication triplets. Sheet 2, sheet 3: Old UMTS quintuplets shall not be re-used. Sheet 2: if the VLR requests more authentication vectors in the same dialogue, the subsequent MAP_SEND_AUTHENTIFICATION_INFO request has no parameters. 25.5.4 Process Obtain_Authentication_Sets_VLR This process is initiated by the VLR to fetch authentication vectors from a subscriber's HLR independently of any other processing. 25.5.5 Process Obtain_Authent_Sets_SGSN The procedure for authentication when the serving node is an SGSN is described in 3GPP TS 23.060 [104] and 3GPP TS 24.008 [35]. This Process is used by the SGSN to request authentication vectors from the HLR. Sheet 1, sheet 2: It is an operator option whether to allow the re-use of old authentication triplets. Sheet 2: Old UMTS quintuplets shall not be re-used. 25.5.6 Process Obtain_Authent_Sets_HLR This process is used to provide authentication vectors (triplets or quintuplets) in response to a request from a VLR or an SGSN. Upon receipt of an authentication information request for a UMTS subscriber, the HLR shall return authentication quintuplets. If the user is a GSM subscriber, the HLR shall return authentication triplets. 25.5.7 Authentication Failure Reporting 25.5.7.1 General The Authentication Failure Report procedure is used to notify an HLR about the occurrence of an authentication failure in the SGSN or VLR. The message flows for this procedure are shown in figuresÊ25.5/7& 25.5/8. FigureÊ25.5/7: Message Flow for Authentication Failure Report Ð VLR to HLR FigureÊ25.5/8: Message Flow for Authentication Failure Report Ð SGSN to HLR 25.5.7.2 Process in the VLR 25.5.7.3 Process in the SGSN 25.5.7.4 Process in the HLR FigureÊ25.5/1: Macro Authenticate_MSC FigureÊ25.5/2 (sheet 1 of 2): Macro Authenticate_VLR FigureÊ25.5/2 (sheet 2 of 2): Macro Authenticate_VLR FigureÊ25.5/3 (sheet 1 of 3): Macro Obtain_Authent_Params_VLR FigureÊ25.5/3 (sheet 2 of 3): Macro Obtain_Authent_Params_VLR FigureÊ25.5/3 (sheet 3 of 3): Macro Obtain_Authent_Params_VLR FigureÊ25.5/4: Process Obtain_Authent_Sets_VLR FigureÊ25.5/5 (sheet 1 of 2): Process Obtain_Authent_Sets_SGSN FigureÊ25.5/5 (sheet 2 of 2): Process Obtain_Authent_Sets_SGSN FigureÊ25.5/6 (sheet 1 of 2): Process Obtain_Authent_Sets_HLR FigureÊ25.5/6 (sheet 2 of 2): Process Obtain_Authent_Sets_HLR FigureÊ25.5/7: Procedure Check_Available_Vectors FigureÊ25.5/9: Process Report_Authentication_Failure_VLR FigureÊ25.5/10: Process Report_Authentication_Failure_SGSN FigureÊ25.5/11: Process Note_Authentication_Failure_HLR 25.6 IMEI Handling Macros The following macros are used in the network in order to enable handling and checking of the mobile equipment identity. 25.6.1 Macro Check_IMEI_MSC This macro is used by the MSC to receive a request from the VLR, relay it to the EIR, and pass the result from the EIR back to the VLR. Sheet 1: If the dialogue with the EIR drops back to a previous protocol version and the EIR returned an error, the MSC relays the error to the VLR in the MAP_CHECK_IMEI response. If the dialogue with the EIR failed, or the EIR returned a badly formed result, the MSC sends a System Failure error to the VLR in the MAP_CHECK_IMEI response. 25.6.2 Macro Check_IMEI_VLR This macro is used by the VLR to control the check of a mobile equipment's IMEI. It may also be used to request the BMUEF from the EIR. 25.6.3 Process Check_IMEI_SGSN This process is used by the SGSN to control the check of a mobile equipment's IMEI. It may also be used to request the BMUEF from the EIR. 25.6.4 Process Check_IMEI_EIR This process is used by the EIR to obtain the status of a mobile equipment, upon request from the MSC or from the SGSN. It may also be used to obtain the BMUEF. 25.6.5 Macro Obtain_IMEI_MSC This macro is used by the MSC to respond to a request from the VLR to provide the IMEI. 25.6.6 Macro Obtain_IMEI_VLR This macro is used by the VLR to obtain the IMEI from the MSC. FigureÊ25.6/1 (sheet 1 of 2): Macro Check_IMEI_MSC FigureÊ25.6/1 (sheet 2 of 2): Macro Check_IMEI_MSC FigureÊ25.6/2: Macro Check_IMEI_VLR FigureÊ25.6/3 (sheet 1 of 2): Process Check_IMEI_SGSN FigureÊ25.6/3 (sheet 2 of 2): Process Check_IMEI_SGSN FigureÊ25.6/4: Process Check_IMEI_EIR FigureÊ25.6/5: Macro Obtain_IMEI_MSC FigureÊ25.6/6: Macro Obtain_IMEI_VLR 25.7 Insert Subscriber Data macros and processes 25.7.1 Macro Insert_Subs_Data_VLR This macro is used by any procedure in the VLR that triggers the reception of subscriber data (e.g. Update Location, Update VCSG Location or Restore Data). 25.7.2 Macro Insert_Subs_Data_SGSN This macro is used by any procedure that triggers the reception of subscriber data (e.g. Update GPRS Location or Update VCSG Location ). 25.7.3 Process Insert_Subs_Data_Stand_Alone_HLR This process is used by HLR to transfer subscriber data to the VLR in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of subscriber data is performed either by the operator or by the subscriber and this change has to be reported to the VLR. Sheet 1: The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. Sheet 1, sheet 2: If the VLR has indicated that it does not support a service or feature (e.g. Closed User Group or Advice Of Charge Charging Level) which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restriction Due To Unsupported Feature flag to roaming restricted and sends Roaming Restriction Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 1, sheet 2: If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 2: It is an operator option whether to repeat the download of subscriber data if the VLR returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the VLR. If subscriber data for CAMEL Phase 2 or later services are sent to a VLR which does not support the appropriate phase of CAMEL, the service behaviour may be unpredictable or incorrect. The HLR should therefore ensure that at the conclusion of a stand alone Insert Subscriber data procedure the data in the VLR do not require a capability that the VLR does not have. Possible mechanisms to ensure this are described in 3GPP TS 23.078Ê[98]. The HLR should send a Forwarded-to number which is not in E.164 international format to the VLR only when the HLR has ascertained that the VLR supports CAMEL Phase 2 or later. Thus, the ISD message containing the Forwarded-to number which is not in E.164 international format shall be sent to the VLR only if the HLR previously received confirmation from the VLR at Location Update that CAMEL Phase 2 or later is supported. 25.7.4 Process Insert_GPRS_Subs_Data_Stand_Alone_HLR This process is used by the HLR to transfer subscriber data from the HLR to the SGSN in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of subscriber data is performed either by the operator or by the subscriber and this change has to be reported to the SGSN. Sheet 1: The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. Sheet 1, sheet 2: If the SGSN has indicated that it does not support a service or feature which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restricted In SGSN Due To Unsupported Feature flag to roaming restricted and sends Roaming Restricted In SGSN Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 1, sheet 2: If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 2: It is an operator option whether to repeat the download of subscriber data if the SGSN returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the SGSN. 25.7.5 Macro Wait_for_Insert_Subs_Data_Cnf This macro is used by any process or macro that describes the handling in the HLR of the transfer of subscriber data to the VLR (e.g. Update Location or Restore Data). 25.7.6 Macro Wait_for_Insert_GPRS_Subs_Data_Cnf This macro is used by any process or macro that describes the handling in the HLR of the transfer of subscriber data to the SGSN (e.g. Update GPRS Location). 25.7.7 Process Send_Insert_Subs_Data_HLR This process is used by any process or macro in the HLR where a MAP_INSERT_SUBSCRIBER_DATA request is sent to the VLR or to the SGSN. 25.7.8 Process Insert_VCSG_Subs_Data_Stand_Alone_CSS This process is used by the CSS to transfer CSG subscriber data from the CSS to the VLR or the SGSN in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of CSG subscriber data in the CSS is performed either by the operator or by the subscriber and this change has to be reported to the VLR or the SGSN. Sheet 1: The CSS may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. Sheet 1, sheet 2: If the VLR or the SGSN has indicated that it does not support a service or feature which the CSS operator regards as essential for the subscriber, the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit. Sheet 1, sheet 2: If the CSS operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit, the CSS sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 2: It is an operator option whether to repeat the download of CSG subscriber data if the VLR or theSGSN returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the VLR or the SGSN. 25.7.9 Macro Wait_for_Insert_VCSG_Subs_Data_Cnf This macro is used by any process or macro that describes the handling in the CSS of the transfer of CSG subscriber data to the VLR or to the SGSN (e.g. Update VCSG Location). 25.7.10 Process Send_Insert_VCSG_Subs_Data_CSS This process is used by any process or macro in the CSS where a MAP_INSERT_SUBSCRIBER_DATA request is sent to the VLR or to the SGSN. FigureÊ25.7/1: Macro Insert_Subs_Data_VLR FigureÊ25.7/2: Macro Insert_Subs_Data_SGSN FigureÊ25.7/3 (sheet 1 of 2): Process Insert_Subs_Data_Stand_Alone_HLR FigureÊ25.7/3 (sheet 2 of 2): Process Insert_Subs_Data_Stand_Alone_HLR FigureÊ25.7/4 (sheet 1 of 2): Process Insert_GPRS_Subs_Data_Stand_Alone_HLR FigureÊ25.7/4 (sheet 2 of 2): Process Insert_GPRS_Subs_Data_Stand_Alone_HLR FigureÊ25.7/5: Macro Wait_for_Insert_Subs_Data_Cnf FigureÊ25.7/6: Macro Wait_for_Insert_GPRS_Subs_Data_Cnf FigureÊ25.7/7: Process Send_Insert_Subs_Data_HLR Figure 25.7/8 (sheet 1 of 2): Process Insert_VCSG_Subs_Data_Stand_Alone_CSS Figure 25.7/8 (sheet 2 of 2): Process Insert_VCSG_Subs_Data_Stand_Alone_CSS Figure 25.7/9: Macro Wait_for_Insert_VCSG_Subs_Data_Cnf Figure 25.7/10: Process Send_Insert_VCSG_Subs_Data_CSS 25.8 Request IMSI Macros 25.8.1 Macro Obtain_IMSI_MSC This macro describes the handling of the request received from the VLR to provide the IMSI of a subscriber (e.g. at Location Updating). 25.8.2 Macro Obtain_IMSI_VLR This macro describes the way VLR requests the MSC the IMSI of a subscriber (e.g. at Location Updating). FigureÊ25.8/1: Macro Obtain_IMSI_MSC FigureÊ25.8/2: Macro Obtain_IMSI_VLR 25.9 Tracing macros 25.9.1 Macro Trace_Subscriber_Activity_MSC This macro shows the handling in the MSC for a request from the VLR to trace the activity of a subscriber. 25.9.2 Macro Trace_Subscriber_Activity_VLR This macro is called during the handling of subscriber activity in the VLR to activate tracing if necessary. 25.9.3 Macro Trace_Subscriber_Activity_SGSN This macro is called during the handling of subscriber activity in the SGSN to activate tracing if necessary. 25.9.4 Macro Activate_Tracing_VLR This macro shows the handling in the VLR for a request from the HLR to activate tracing for a subscriber. 25.9.5 Macro Activate_Tracing_SGSN This macro shows the handling in the SGSN for a request from the HLR to activate tracing for a subscriber. 25.9.6 Macro Control_Tracing_With_VLR_HLR This macro shows the handling in the HLR to activate tracing in the VLR if it is required during a dialogue between the VLR and the HLR 25.9.7 Macro Control_Tracing_With_SGSN_HLR This macro shows the handling in the HLR to activate tracing in the SGSN if it is required during a dialogue between the SGSN and the HLR FigureÊ25.9/1: Macro Trace_Subscriber_Activity_MSC FigureÊ25.9/2: Macro Trace_Subscriber_Activity_VLR FigureÊ25.9/3: Macro Trace_Subscriber_Activity_SGSN FigureÊ25.9/4: Macro Activate_Tracing_VLR FigureÊ25.9/5: Macro Activate_Tracing_SGSN FigureÊ25.9/6: Macro Control_Tracing_With_VLR_HLR FigureÊ25.9/7: Macro Control_Tracing_With_SGSN_HLR 25.10 Short Message Alert procedures 25.10.1 Process Subscriber_Present_VLR The VLR invokes the process Subscriber_Present_VLR when the mobile subscriber becomes active. The general description of the short message alert procedures is in clauseÊ23.4 of the present document. 25.10.2 Process SubscriberPresent_SGSN The SGSN invokes the process Subscriber_Present_SGSN when it receives a Page response, a GPRS Attach request or a Routing area update request message (3GPP TS 24.008 [35]). The general description of the short message alert procedures is in clauseÊ23.4 of the present document. 25.10.3 Macro Alert_Service_Centre_HLR The HLR invokes the macro Alert_Service_Centre_HLR when Service Centre(s) are to be alerted. 25.10.4 Process Alert_SC_HLR It is an operator option to resend the MAP_ALERT_SERVICE_CENTRE request to the SMS-IWMSC if the alert is unsuccessful. The number of repeat attempts and the interval between them is also an operator option. The service centre address should be purged from the MWD list if the alert is consistently unsuccessful. FigureÊ25.10/1: Process Subscriber_Present_VLR FigureÊ25.10/2: Process Subscriber_Present_SGSN FigureÊ25.10/3: Macro Alert_Service_Centre_HLR FigureÊ25.10/4: Process Alert_SC_HLR Annex A (informative): ASN.1 Cross-reference listing and fully expanded sources The ASN.1 Cross-reference listing and the fully expanded ASN.1 sources of the MAP protocol are provided for information at http://www.3gpp.org/ftp/Specs/archive/29_series/29.002/ASN.1/ Annex B (informative): Void Annex C (informative): Message Segmentation Mechanisms Various segmentation mechanisms are in use to overcome the problem where a MAP parameter carried in an Invoke, Result (or Error) component is too long to fit into a single SCCP UDT message. These mechanisms are: C.1 SCCP segmentation Instead of one UDT message several XUDT messages are used according to Signalling Connection Control Part, Signalling System no. 7 ITU-T recommendation (07/96) Q.711 to Q.716 ('White Book SCCP'). This mechanism may be used for all MAP messages. If no segmentation mechanism at the TCAP or MAP level is available, this is the only remaining possibility. This mechanism has no impact on the MAP provider level and above; the MAP provider sees the parameter as being sent in a single segment. It should be noted that not all SCCP transit nodes (world wide) currently support the transfer of XUDT messages. Therefore XUDT messages may be lost without notice, depending on the route the message takes. The routes which successive messages take between two end points can differ because of load balancing. It is therefore recommended that this mechanism is used only for: a) messages which do not cross PLMN boundaries (when the PLMN operator ensures that all SCCP transit nodes within his PLMN support White Book SCCP) b) messages with low priority i.e. loss of the message does not result in serious misoperation. It should be noted that the decision whether or not a message crosses PLMN boundaries needs to be taken at the MAP application level; it is therefore based on the message's operation code rather than on the SCCP called party address, i.e. only messages which never cross PLMN boundaries due to the type of message (SendIdentification, SendRoutingInfo without OR, AnyTimeInterrogation, ...) can be regarded as not crossing PLMN boundaries. C.2 TCAP segmentation At the TCAP level the following segmentation mechanisms are available: C.2.1 Empty Begin In a dialogue with AC version >1 the first forward message (Begin) must contain a Dialogue Portion. Instead of sending the Dialogue Portion and the Component Portion in the first forward message, an empty Begin (i.e. without a Component Portion) is sent, followed (after successful dialogue establishment) by a Continue message which can carry a longer Component Portion since no Dialogue Portion is present in the second forward message. C.2.2 Empty Continue In a dialogue with AC version >1 the first backward message (Continue / End) must contain a Dialogue Portion. Instead of sending the Dialogue Portion and the Component Portion in the first backward message, an empty Continue (i.e. without a Component Portion) is sent, followed by a Continue/End message which can carry a longer Component Portion since no Dialogue Portion is present in the second backward message. C.2.3 TC-Result-NL A Result component may be segmented into one or several Result-Not-Last components followed by a Result-Last component. As specified in clause 15.6.3, the MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the result of the associated operation. Note that this segmentation mechanism runs the risk that the message carrying the Result-Last component arrives before the message carrying a Result-Not-Last component which results in failure. The use of SCCP class 1 ""Sequence guaranteed"", which raises the chance of in sequence delivery, is recommended. C.3 MAP Segmentation At the MAP level the following segmentation mechanisms are available: C.3.1 Invoke without explicit indication An Invoke component may be segmented into several Invoke components. These may be sent in burst mode (in which case SCCP class 1 is recommended) or in acknowledged mode. The receiving node does not get an indication of whether or not more segments will be received, so it must not close the dialogue. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the invoke of the associated operation. C.3.2 Invoke with explicit indication An Invoke component may be segmented into several Invoke components sent in acknowledged mode. Each component contains at the MAP level an indication of whether or not subsequent components will follow. The receiving node terminates the dialogue when the last component is received. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the invoke of the associated operation. C.3.3 Result A Result (last) component may be segmented into several Result (last) components sent in acknowledged mode where a new (empty) Invoke component serves as an acknowledgment. The last segment is not acknowledged. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the result of the associated operation. The following tables show the applicability of the mechanisms described above: AC Version 4: Parameter SCCP-segmentation Empty Begin Empty Continue TC-Result-NL Invoke without indication Invoke with indication Result ResumeCallHandlingArg allowed not allowed n.a. n.a. not allowed recommended n.a. AC Version 3: Parameter SCCP-segmentation Empty Begin Empty Continue TC-Result-NL Invoke without indication Invoke with indication Result InsertSubscriberDataArg risky not allowed n.a. n.a. recommended n.a. n.a. SendIdentificationRes allowed n.a. not allowed not allowed n.a. n.a. recommended PrepareHO-Arg allowed not allowed n.a. n.a. not allowed n.a. n.a. PrepareHO-Res allowed n.a. recommended not recommended n.a. n.a. not allowed ProcessAccessSignalling-Arg allowed n.a. n.a. n.a. not allowed n.a. n.a. ForwardAccessSignalling-Arg allowed n.a. n.a. n.a. not allowed n.a. n.a. PrepareSubsequentHO-Arg allowed n.a. n.a. n.a. not allowed n.a. n.a. PrepareSubsequentHO-Res allowed n.a."
"n.a not recommended n.a. n.a. not allowed SendAuthenticationInfoRes risky n.a. not allowed not allowed n.a. n.a. recommended ProvideSubscriberInfoRes allowed n.a. not allowed not recommended n.a. n.a. not allowed AnyTimeInterrogationRes allowed n.a. not allowed not recommended n.a. n.a. not allowed AnyTimeModificationRes allowed n.a. not allowed recommended n.a. n.a. not allowed AnyTimeSubscriptionInterrogationRes allowed n.a. not allowed recommended n.a. n.a. not allowed noteSubscriberDataModifiedArg allowed not allowed n.a. n.a. not allowed recommended n.a. SendRoutingInfoRes allowed n.a. not allowed recommended n.a. n.a. not allowed MO-ForwardSM-Arg risky recommended n.a. n.a. not allowed n.a. n.a. MT-ForwardSM-Arg risky recommended n.a. n.a. not allowed n.a. n.a. AC Version 2: Parameter SCCP-segmentation Empty Begin Empty Continue TC-Result-NL Invoke without indication Invoke with indication Result InsertSubscriberDataArg risky not allowed not allowed n.a. recommended n.a. n.a. SendIdentificationRes allowed n.a. not allowed not recommended n.a. n.a. not allowed SendAuthenticationInfoRes risky n.a. not allowed not recommended n.a. n.a. not allowed ForwardSM-Arg risky recommended n.a. n.a. not allowed n.a. n.a. PrepareHO-Res allowed n.a. recommended not recommended n.a. n.a. not allowed AC Version 1: Parameter SCCP-segmentation Empty Begin Empty Continue TC-Result-NL Invoke without indication Invoke with indication Result InsertSubscriberDataArg risky n.a. n.a. n.a. recommended n.a. n.a. SentParameterList risky n.a. n.a. recommended n.a. n.a. not allowed In the tables above the keywords ""recommended"", ""allowed"", ""risky"", ""not recommended"", ""not allowed"" and ""n.a."" are used as follows: ""recommended"" indicates that the normative part of this specification explicitly specifies the use of this mechanism for the parameter in question; ""allowed"" indicates that the normative part of this specification allows the use of this mechanism for the sending node and mandates support of this mechanism for the receiving node; ""risky"" indicates that the mechanism is ""allowed"".However, the use of this mechanism for the parameter in question may result in serious misoperation because SCCP transit nodes are not guaranteed to support XUDT messages. ""not recommended"" indicates that the normative part of this specification does not explicitly specify the use of this mechanism for the parameter in question. ""not allowed"" indicates that the normative part of this specification implicitly prohibits the use of this mechanism for the parameter in question. ""n.a."" indicates that the mechanism is not applicable for the parameter in question. Annex D (informative): Void Annex E (informative): Change History Date TSGÊ# TSG Doc. CR Rev Subject/Comment New 04 N2-99227 A002 3 Use of E interface 3.1.0 04 N2-99578 A003 Introduction of TIF-CSI for Call Deflection 3.1.0 04 N2-99233 A004 Clarification in ASN.1 encoding of O-CSI and T-CSI 3.1.0 04 N2-99269 A005 Introduction of MSISDN in USSD operation 3.1.0 04 N2-99650 A006 Modification of the O-CSI ASN.1 structure 3.1.0 04 N2-99250 A007 Adding of MAP_DELIMITER_req to the Status report operation 3.1.0 04 N2-99628 A008 Correction to the Purge MS ""Detailed procedure in the HLR"" 3.1.0 04 N2-99677 A009 Adding of MNP-indicator to the SRI ack 3.1.0 04 N2-99228 A010 New subscription options for call forwarding 3.1.0 04 N2-99585 A011 Adding the support of ANSI SCCP which is required in North America (World Zone 1) 3.1.0 04 N2-99515 A012 Introduction of 3-digit MNCs correction 3.1.0 04 N2-99520 A013 Export of NAEA-CIC 3.1.0 04 N2-99548 A014 Clarification to text to identify how the LSA data relevant in the current VPLMN can be determined 3.1.0 04 3C99-468 A015 Alignment with 04.80 3.1.0 04 N2-99519 A016 VBS data 3.1.0 04 N2-99461 A017 Introduction of Data Missing error to the Resume Call Handling 3.1.0 04 N2-99583 A018 Removal of 3-digit MNCs 3.1.0 04 N2-99676 A019 Corrections of mapping from MAP service to TC service 3.1.0 04 3C99-206 A020 Introduction of UUS service to Resume Call Handling 3.1.0 05 N2-99906 021 Clarification on VLR CAMEL Subscription Info 3.2.0 05 N2-99908 022 Clarification on DestinationNumberCriteria 3.2.0 05 N2-99910 023 Removal of TDP-Criteria from RCH 3.2.0 05 N2-99934 025 Various corrections related to GGSN-HLR Interface. 3.2.0 05 N2-99936 034 Update Location handling for GPRS-only subscription 3.2.0 05 N2-99938 035 Correction of OP & AC definitions for NoteMS-PresentForGPRS 3.2.0 05 N2-99952 036 Removal of redundant information from RCH 3.2.0 05 N2-99956 026 OR capability IE in PRN 3.2.0 05 N2-99964 024 1 GMSC-CAMEL phase 2 support IE in PRN 3.2.0 05 N2-99A19 028 Alignment of 29.002 with 02.67 3.2.0 05 N2-99A45 029 1 Non-CAMEL IST implementation 3.2.0 05 N2-99B57 027 2 Addition of the information elements and the ASN.1 definitions for Pre-paging 3.2.0 05 N2-99C27 042 Clarification on 'Supported CAMEL Phases' in ISD ack 3.2.0 05 N2-99C78 044 Editing error correction on VLR capabilities 3.2.0 05 N2-99D06 043 1 Addition of exception handling to the CancellationType 3.2.0 05 N2-99D33 046 Clarification of LR-REJECT cause corresponding to RoamingRestrictionDueTo UnsupportedFeature 3.2.0 05 N2-99D35 047 Clarification of returning the MSISDN in SRIack 3.2.0 06 N2-99G06 033 3 Introduction of the Super-Charger Concept in TS 29.002 3.3.0 06 N2-99G18 032 2 Introduction of White Book SCCP in MAP 3.3.0 06 N2-99G50 070 Addition of GGSN number for the SRIforGPRS 3.3.0 06 N2-99J88 075 1 Introduction of Follow Me 3.3.0 06 N2-99K12 077 Use of SSN for GPRS 3.3.0 06 N2-99K24 069 Correction of the USSD procedure in the HLR. 3.3.0 06 N2-99K52 060 1 MAP Impacts for Location Services (LCS) 3.3.0 06 N2-99K58 045 4 Authentication Enhancements 3.3.0 06 N2-99K60 050 5 QoS-Subscribed field modification 3.3.0 06 N2-99L20 073 1 Introduction of CAMEL Phase 3 in 3GPP TS 29.002 3.3.0 06 N2-99J52 074 Restructuring of MAP Location Management Procedures for the Circuit Switched Domain 3.3.0 06 N2-99J92 068 Update of SDLs to support Super-Charger 3.3.0 New version created to fix a CR implementation error 3.3.1 07 N2B000436 048 5 Introduction of Multicall 3.4.0 07 N2B000319 059 1 Alternative solution for ALR 3.4.0 07 N2B000461 063 4 MNP Database Mismatch 3.4.0 07 N2B000375 066 5 Addition of the FTN-AddressString 3.4.0 07 N2B000456 079 4 Correction of SS Invocation Notification for CCBS 3.4.0 07 N2A000023 080 Corrections to ATSI, ATM, NCSD 3.4.0 07 N2B000046 083 Privacy notification/verification for call related privacy class 3.4.0 07 N2B000142 084 2 Addition of CS Allocation/retention priority 3.4.0 07 N2B000144 086 1 Editorial cleanup of 29.002 3.4.0 07 N2B000100 087 Correction of LSA information 3.4.0 07 N2B000067 089 Security interworking between release 99 and pre-99 MSC/VLRs 3.4.0 07 N2B000113 090 1 Improving GPRS charging efficiency 3.4.0 07 N2B000120 094 2 QoS-Subscribed field enhancements 3.4.0 07 N2B000322 095 1 RANAP support on the E-interface 3.4.0 07 N2B000191 099 UMTS Authentication 3.4.0 07 N2B000466 100 5 Support of 3G Handover, including Multicall 3.4.0 07 N2B000372 101 1 Introduction of Service Area Identification 3.4.0 07 N2B000380 102 2 Clarification on Authentication Info Retrieval 3.4.0 07 N2B000330 103 1 Addition of UMTS security to MAP B interface 3.4.0 07 N2B000244 104 Re-Synchronisation Info 3.4.0 07 N2B000324 105 1 Introduction of additional service parameters for inter-system handover 3.4.0 07 N2B000281 107 Removal of architectural information from clause 4 3.4.0 07 N2-000454 110 1 Introduction of Authentication Failure Report 3.4.0 07 N2B000357 111 Use of MAP private extensions to implement region-specific requirements 3.4.0 07 N2B000470 112 Prioritisation of MAP application context related to VGCS/VBS 3.4.0 07 N2B000472 113 Correction of SS-Codes for LCS 3.4.0 08 N4-000098 115 1 Minor corrections to CAMEL3 NSDC/ATM/ATSI information flows 3.5.0 08 N4-000094 117 1 Using DSD to delete CCBS-B from the subscriber 3.5.0 08 N4-000089 118 1 Indication in PRN of support of Long FTNs 3.5.0 08 N4-000073 120 1 QoS-Subscribed field enhancements 3.5.0 08 N4-000050 121 Correction of introduction of additional service parameters for inter-system handover 3.5.0 08 N4-000100 122 2 Proposed information flow on NSDC 3.5.0 08 N4-000321 124 3 CAMEL Subscription Info 3.5.0 08 N4-000068 125 Clarification to GMLC List definition 3.5.0 08 N4-000320 127 1 Optionality of parameters in d-csi and in sms-csi 3.5.0 08 N4-000209 130 Version 3 tags for handover messages 3.5.0 08 N4-000211 132 Correction of version handling at dialogue establishment 3.5.0 08 N4-000357 133 1 Various corrections and/or cleanup to 29.002 3.5.0 08 N4-000217 134 Correction of errors in Figure 25.1/1: Macro Receive_Open_Ind 3.5.0 08 N4-000326 135 1 Addition of charging characteristics per PDP context 3.5.0 08 N4-000264 138 Clarification of SAI-ack segmentation procedure 3.5.0 08 N4-000392 139 1 Indication of unsupported position method 3.5.0 08 N4-000276 141 Clarification for ReportSM-DeliveryStatus operation 3.5.0 08 N4-000349 142 1 Addition of a parameter in the subsequent Handover from UMTS to GSM with Multicall 3.5.0 08 N4-000278 143 Editorial correction to MSC-A handover SDLs 3.5.0 08 N4-000378 144 1 Use of NAM parameter with MAP-INSERT-SUBSCRIBER-DATA service between HLR and SGSN 3.5.0 08 N4-000293 145 Addition of state attributes in Forward group call signalling 3.5.0 08 N4-000294 146 New user error 'target cell outside group call area' in MAP Prepare Handover message 3.5.0 08 N4-000374 149 Correction to the description of MAP-MO-Forward-Short-Message service 3.5.0 08 N4-000407 148 4 Changes to MAP for secure transport of MAP messages 4.0.0 08 Version 4.0.1 created to allow inclusion of automatic update of Annexes A and B and of clause 17 4.0.1 09 N4-000543 152 1 Clarifications for secure MAP transport 4.1.0 09 N4-000539 153 1 Generalization of version handling text in clause 18.2.4 4.1.0 09 N4-000491 158 Deletion of informative Annexe C 4.1.0 09 N4-000540 159 Aligning 29.002 with 25.413 (UTRAN Iu Interface RANAP Signalling) 4.1.0 09 N4-000541 160 AUTS and AUTN parameter length 4.1.0 09 N4-000744 161 2 Clarification on Authentication Failure Report ack 4.1.0 09 N4-000666 163 1 Correction on Location Information 4.1.0 09 N4-000777 174 2 Optionality of parameters in GPRS-CSI 4.1.0 09 N4-000788 176 1 Correction to QoS indication 4.1.0 09 N4-000747 178 1 Clarification of use of Radio Resource Information 4.1.0 09 N4-000750 180 2 Correction to MSC-A handover SDLs 4.1.0 09 N4-000736 182 Removal of LSAIdentity from NoteMM-EventArg 4.1.0 09 N4-000772 184 LCS Support for CAMEL Phase 3 4.1.0 09 N4-000751 186 1 Correction to MSC-A handover SDLs 4.1.0 09 N4-000779 188 Clarification for segmentation of D-CSI and SMS-CSI 4.1.0 10 N4-000912 166 3 Corrections and clarifications for USSD procedures on the HLR - gsmSCF interface 4.2.0 10 N4-000908 191 1 Corrections of ISD data structure for CAMEL phase 3 4.2.0 10 N4-001069 193 2 USSD Corrections for Follow Me 4.2.0 10 N4-001071 196 1 GSM to 3G Handover: MAP parameter Target Cell ID 4.2.0 10 N4-000921 198 ASN.1 description of targetCellId 4.2.0 10 N4-001073 200 1 IMSI in MAP_PREPARE_HANDOVER 4.2.0 10 N4-001076 208 1 Alignment of the Target RNC-ID 4.2.0 10 N4-001089 211 1 Export of GSN-Address data type 4.2.0 10 N4-001095 212 Transport of long RANAP messages on MAP-E interface 4.2.0 - - - - Automatic update of annexes A and B 4.2.1 11 N4-010036 206 1 Correction to LCS application context 4.3.0 11 N4-010276 215 2 Add parameters to ISD and SRI for GPRS to handle ODB for PS 4.3.0 11 N4-010033 217 Correction to maximum number of RAB's 4.3.0 11 N4-010198 222 2 PS domain support for LCS Release 4 4.3.0 11 N4-010058 224 Failure of Update GPRS Location when HLR is not reachable 4.3.0 11 N4-010287 231 1 Extension of call related privacy class for LCS Release 4 4.3.0 11 N4-010375 232 2 Maximum number of LCS Clients 4.3.0 11 N4-010261 234 MAP over IP according to SIGTRAN 4.3.0 11 N4-010465 236 1 Requesting node type in authentication set request 4.3.0 11 N4-010360 246 Adding EXPORT definition for LSAIdentity 4.3.0 11 N4-010361 247 Removing duplicate parameters from ss-CSI 4.3.0 11 N4-010362 248 Correction to description of SS-CSI in HLR to VLR information flow 4.3.0 11 N4-010365 250 GSM to UMTS handover: addition of MAP parameter RNC ID 4.3.0 11 N4-010393 252 Clarification of the use of multicall bearer information 4.3.0 11 N4-010428 258 Adding EXPORT definition for GeographicalInformation 4.3.0 11 N4-010446 260 Failure of Authentication Parameter GPRS when HLR is not reachable 4.3.0 11 N4-010484 262 1 Correction to D-CSI 4.3.0 12 N4-010728 239 4 Addition of selected UMTS algorithm indication to the handover procedures 4.4.0 12 N4-010730 241 4 Addition of allowed GSM algorithms indication to the handover procedures 4.4.0 12 N4-010733 244 4 Addition of allowed UMTS algorithm indication to the handover procedures 4.4.0 12 N4-010735 245 4 Addition of selected GSM algorithm indication to the handover procedures 4.4.0 12 N4-010739 254 2 Addition of radio resource list to the handover procedures 4.4.0 12 NP-010247 256 3 Addition of GSM channel type and GSM chosen channel indications to handover procedures 4.4.0 12 N4-010787 264 3 Add support in MAP for all shapes defined in 23.032 4.4.0 12 N4-010633 270 1 Correction to description of RNCId parameter 4.4.0 12 N4-010635 272 1 Correction to Encryption Information and Integrity Protection parameters 4.4.0 12 N4-010767 279 3 Essential drawbacks on services due to introduction of Super-Charger function 4.4.0 12 N4-010741 283 1 Introduction of selected Rab-id to the Process Access Signalling operation 4.4.0 12 N4-010673 285 Mistake in the definition of Authentication Failure Report Application Context 4.4.0 12 N4-010551 266 Add support in MAP for Ellipsoid Point 4.4.0 12 N4-010778 168 5 Security Header modification 4.4.0 12 N4-010785 267 3 Additional Parameters in Authentication Failure Report 4.4.0 12 N4-010783 268 3 MS presence notification procedure for LCS 4.4.0 12 N4-010790 289 2 Component level granularity of protection 4.4.0 Corrupted headers fixed 4.4.1 13 N4-010840 290 Clarifications on long forwarded-to numbers 4.5.0 13 N4-010929 291 1 Corrections for Deferred MT-LR 4.5.0 13 N4-010930 292 2 Clarifications on SupportedLCS-CapabilitySets 4.5.0 13 N4-010958 295 2 Corrections on the introduction of LCS for PS domain 4.5.0 13 N4-010970 302 2 Additional SGSN related values to Access Type 4.5.0 13 N4-010976 306 Addition of data type definitions to EXPORT statements for the usage in CAP 4.5.0 13 N4-011017 307 2 Minimum MAP application context for intersystem MSC handover from GSM to UMTS 4.5.0 13 N4-011019 309 2 Minimum MAP application context for intersystem MSC handover from UMTS to GSM 4.5.0 13 N4-010845 277 1 Correction on the SDL of NW initiated USSD operations 4.5.0 13 Editorial Clean up 4.5.0 14 N4-011031 313 Clarification on LCS parameters in MAP 4.6.0 14 N4-011043 314 Handling of linked operations in the MAP protocol machine 4.6.0 14 N4-011285 316 Corrections on the SDL diagrams for LCS 4.6.0 14 N4-011198 318 1 Indication of deletion of CSI in Notify Subscriber Data Change 4.6.0 14 N4-011074 320 Correct length of Add-GeographicalInformation 4.6.0 14 N4-011091 322 Clarify encoding of RNC Id 4.6.0 14 N4-011094 324 Clarify encoding of RANAP parameters in MAP 4.6.0 14 N4-011097 325 Clarifications on long forwarded-to numbers 4.6.0 14 N4-011227 331 1 Clarification of methodology for maintaining data consistency in Supercharger 4.6.0 14 N4-011173 334 Addition of RAB ID to Prepare Handover procedure 4.6.0 14 N4-011175 336 Correction to the Allowed GSM Algorithms parameter 4.6.0 14 N4-011177 337 1 Correction of references 4.6.0 14 N4-011190 339 CUG-Info is not exported from 29.002 4.6.0 14 N4-011209 341 Clarification on NSCD when data is withdrawn 4.6.0 14 N4-011211 343 Clarification of sending CAMEL information in stand alone ISD case 4.6.0 14 N4-011262 344 Correction of the priority for ""SRI for LCS"" 4.6.0 14 N4-011273 347 ASN.1 correction 4.6.0 14 N4-011437 349 2 Handling of MNRR in the HLR & SMS-GMSC 4.6.0 14 N4-011433 354 1 Minimum MAP application context for G2G inter-MSC handover 4.6.0 14 N4-011439 359 2 Alignment of parameter lengths with those prescribed in 08.08 4.6.0 14 N4-011423 360 1 Aligning the security header elements with TS33.200 4.6.0 14 N4-011394 364 Syntax error in the ATM result and ATSI result 4.6.0 14 N4-011381 355 1 LCS Capability Handling for UE's 5.0.0 15 N4-020300 368 4 Collective CAMEL Phase 4 CR 5.1.0 15 N4-020013 373 Inclusion of complete ODB data in ATSI and NSDC 5.1.0 15 N4-020266 381 2 Introduction of the ""Requestor ID"" 5.1.0 15 N4-020068 386 Correction to AC version of gprsLocationInfoRetrievalContext 5.1.0 15 N4-020248 390 1 Incomplete description of Restore Data parameters 5.1.0 15 N4-020183 403 Clarification on CODEC-Info 5.1.0 15 N4-020250 407 1 ODB alignment 5.1.0 16 N4-020530 428 2 LCS: error handling if shape not supported by GMLC 5.2.0 16 N4-020622 453 Addition of Radio Resource List to the Forward Access Signalling operation 5.2.0 16 N4-020641 460 Clarification on Resume Call Handling 5.2.0 16 N4-020746 440 2 Clarification on SendAuthenticationInfo 5.2.0 16 N4-020750 446 1 Addition of Service Handover parameters to MAP Handover messages 5.2.0 16 N4-020318 398 Check of NAM and Requesting Node Type on receipt of SendAuthenticationInfo 5.2.0 16 N4-020333 410 Handling the MNRR flag in the HLR & SMS-GMSC 5.2.0 16 N4-020499 420 1 Clarfication of introducing Session related and unrelated class 5.2.0 16 N4-020511 430 1 Corrections on the introduction of LCS for PS domain 5.2.0 16 N4-020743 448 1 Corrections in SS-code chapter 5.2.0 16 N4-020408 423 Clarification of handling of MT-SMS-TPDU-Type and SMS-TDP 5.2.0 16 N4-020410 425 Clarify conditions to trigger restart of MTLR-Deferred procedure 5.2.0 16 N4-020468 414 1 Corrections to the handling of Any Time Interrogation and Provide Subscriber Info 5.2.0 16 N4-020476 435 1 Change PS-connected in PS-PDPactive 5.2.0 16 N4-020483 422 1 Triggering of gsmSCF for MT-SMS-CSI 5.2.0 16 N4-020485 408 2 Transferring the MS classmark & IMEI to the gsmSCF 5.2.0 16 N4-020543 441 Correction of Object Identifiers for ASN.1 modules 5.2.0 16 N4-020608 450 Enhancement to LCS in the PS domain 5.2.0 16 N4-020623 454 Addition of Location Information GPRS to Note MM Event operation 5.2.0 16 N4-020703 421 4 LCS: Codeword and Service Type 5.2.0 16 N4-020756 436 2 Splitting of CAMEL phase 4 5.2.0 17 N4-021001 437 3 Compatible upgrade to ASN.1:1997 of 29.002 5.3.0 17 NP-020399 462 2 Introduction of GERAN classmark 5.3.0 17 N4-020841 465 Clarification on Call Deflection 5.3.0 17 N4-021040 470 1 Correction to the usage of ""Roaming not allowed"" error 5.3.0 17 N4-021041 471 1 Clarifications on Send Identification 5.3.0 17 N4-021094 479 2 Handling of partial implementations of CAMEL phase 4 5.3.0 17 N4-021047 480 Removal of ChargingNotification feature 5.3.0 17 N4-020810 481 CR29.002-443 (rel5) on extensions to ATM for CAMEL control of IMS 5.3.0 17 N4-020809 482 CR to 29.002 for the support of the MAP Si interface 5.3.0 18 N4-021290 499 Correction to segmentation of O-CSI and T-CSI 5.4.0 18 N4-021418 508 ODB correction 5.4.0 18 N4-021563 511 1 Addtion of reference number to deferred location request procedure 5.4.0 18 N4-021573 516 2 Correction to the Service Handover parameters 5.4.0 18 N4-021299 442 3 Description of MT SM delivery via two serving nodes 5.4.0 18 N4-021294 474 2 Correction of handling of MT-SMS in the SGSN 5.4.0 18 N4-021124 475 ODB and CB for SMS 5.4.0 18 N4-021153 486 Correction of IMEI check for SGSN 5.4.0 18 N4-021467 489 5 Available codecs list and selected codec indication 5.4.0 18 N4-021194 490 Clarification of the use of Requested CAMEL Subscription Info parameters 5.4.0 18 N4-021252 495 Correction to RCH Ð adding O-CSI trigger criteria 5.4.0 18 N4-021264 496 Additional MM-Code for MG-CSI 5.4.0 18 N4-021296 497 1 Additional handling of partial implementations of CAMEL phase 4 5.4.0 18 N4-021383 512 Correcion of Codeword Handling 5.4.0 18 N4-021443 513 Reference to TS 23.078 in TS 29.002 regarding handling of VMSC address is missing 5.4.0 18 N4-021524 521 1 Editorial clean up 5.4.0 18 N4-021531 522 Introduction of the CHOICE element ""netDetNotReachable"" for PS-SubscriberState 5.4.0 18 N4-021260 491 1 Addition of LCS Format Indicator to LCS Client ID 6.0.0 18 N4-021504 517 2 Addition of V-GMLC Address to the Update Location and Update GPRS Location requests 6.0.0 18 N4-021567 518 3 Addition of V-GMLC and H-GMLC Addresses to the Send Routing Info for LCS response 6.0.0 18- N4-021506 519 2 Addition of PPR Address to the Send Routing Info for LCS response 6.0.0 19 N4-030234 509 3 Introduction of Call Barring for SMS in PS domain 6.1.0 19 N4-030325 524 3 Clean-up of SMS procedures chapter 6.1.0 19 NP-030068 545 2 Correction to interactions between CAMEL control of MO SMS and barring 6.1.0 19 N4-030061 526 Incrementing ASN.1 module versions 6.1.0 19 N4-030063 528 LCS diagnostic alignment 6.1.0 19 N4-030054 529 Addition of LCS Capability Set 4 6.1.0 19 N4-030301 533 1 Correction to the definitions of Radio Resource List and BSSMAP Service Handover List 6.1.0 19 N4-030305 541 2 Handover of Group Calls where MSC-B has bearer established 6.1.0 19 N4-030287 551 1 Change of SS-Code List description for Insert Subscriber Data 6.1.0 19 N4-030289 559 1 Missing of ""Continue Monitoring message"" in SDL 21.7_3.2 6.1.0 19 N4-030297 563 1 Alignment of TS 29.002 with TS 23.107 regarding QoS subscribed data 6.1.0 19 N4-030222 566 1 Introduction of MSC Number as a new parameter in MAP-SEND-IDENTIFICATION operation 6.1.0 20 N4-030692 536 2 Additional SGSN Related Access Type Ð Detach 6.2.0 20 N4-030658 568 4 Addition of Positioning Data IE to Provide Subscriber Location and Send Location Report 6.2.0 20 N4-030638 574 1 Provision of SDL diagrams and removal of redundant text in chapter 25 6.2.0 20 N4-030713 595 2 Removal of redundant text from 29.002 Chapter 23 6.2.0 20 N4-030439 599 LCS Client external ID 6.2.0 20 N4-030682 607 1 Provision of SDL diagrams and removal of redundant text in chapter 22 6.2.0 20 N4-030608 608 1 Addition of LCS capability sets to MAP_SRI_for_LCS response 6.2.0 20 N4-030647 612 1 Enhancement of the CheckIMEI operation to retrieve the BMUEF 6.2.0 20 N4-030678 619 1 Correction to naming of PRN parameter 6.2.0 20 N4-030609 624 1 Addition of Privacy Check Related Action to Provide Subscriber Location request 6.2.0 20 N4-030642 610 1 Transfer of UE-specific behaviour bitmap at handover 6.2.0 20 N4-030601 633 Missing SMSs over MSC even if the MS is capable of such sending 6.2.0 21 N4-031043 584 2 Correction to MAP Process Secure_MAP_DSM SDLsÊ 6.3.0 21 N4-031053 664 1 Correction of encoding description of Group-Id 6.3.0 21 N4-030828 657 Reduce maximum length of ""LCS Requestor ID"" and ""LCS Codeword"". 6.3.0 21 N4-030922 647 1 UESBI -IU format 6.3.0 21 N4-031069 616 3 Incorrect Charging with MNP 6.3.0 21 N4-031057 660 2 Notification of the 2nd BSG in case of Late CF with OR 6.3.0 21 N4-031059 614 3 HLR Interrogation for SCUDIF calls 6.3.0 21 N4-030785 644 Removal of tables in clause 7.6 6.3.0 21 N4-030806 649 Correction of References 6.3.0 21 N4-030815 648 Correction of wrong AC name in the table in 17.1.6 6.3.0 21 N4-030824 654 New LCS Service Types 6.3.0 21 N4-030951 671 SS-Barring Category 6.3.0 21 N4-031006 650 1 Add SGSN, GGSN, GMLC, gsmSCF, NPLR and AuC to network resource parameter 6.3.0 21 N4-0301038 645 1 Introduction of North American Interim Location Based Routing of Emergency Call 6.3.0 21 N4-031065 674 Positioning Data for UTRAN LCS 6.3.0 21 N4-030953 637 1 Provision of SDL diagrams and removal of redundant text in chapter 19 6.3.0 21 N4-030745 639 Provision of SDL diagrams and removal of redundant text in chapter 20 6.3.0 21 N4-030747 641 Provision of SDL diagrams and removal of redundant text in chapter 21 6.3.0 21 N4-030748 642 Removal of SIWF description 6.3.0 21 N4-030749 643 Deletion of redundant Annex D 6.3.0 22 N4-031098 677 Enhancements for the Partial Implementation for ""Change of position procedure armed with criteria"" 6.4.0 22 N4-031135 687 Collective CR for Rel-6 Enhanced Dialled Services 6.4.0 22 N4-031274 648 2 Message Segmentation Mechanisms 6.4.0 22 N4-031315 703 Addition of requestingPLMN-ID to Send Authentication Info Request 6.4.0 22 N4-031372 680 2 Addition of CGI to LCS procedures 6.4.0 22 N4-031373 696 2 Include v-gmlc parameter in RESTORE DATA MAP message 6.4.0 22 N4-031365 702 2 Deferred MT-LR Area Event 6.4.0 22 N4-031132 686 More spare bits for CAMEL4 enhancements 6.4.0 22 N4-031163 692 Clarification on D-CSI segmentation 6.4.0 22 N4-031342 676 2 MNP correction for prepaid charging 6.4.0 22 N4-031338 695 1 Remove reduntant option for retrieval of routeing information in figure 21.2.3 6.4.0 22 N4-031108 679 Modification of description for conditions on inclusion of Positioning Data 6.4.0 22 N4-031317 689 2 HSDPA impacts to MAP 6.4.0 22 NP-030533 704 EXPORT data types to CAP (Change of position armed with criteria) 6.4.0 23 N4-040310 668 3 Codec Modification/ Mid-Call Codec Negotiation after Inter-MSC Relocation 6.5.0 23 N4-040193 670 2 Correction of Inter-MSC SRSN Relocation procedure 6.5.0 23 N4-040249 701 3 Introduction of Presence Stage 3 (Ph, Pc and Pg) to the MAP interface 6.5.0 23 N4-040333 708 2 Correction to Insert Subscriber Data message for LCS SS 6.5.0 23 N4-040328 709 1 SCCP segmentation for Inter PLMN MAP message 6.5.0 23 N4-040327 711 2 Inclusion of UTRAN Positioning Data parameter 6.5.0 23 N4-040284 717 1 Include administrative restriction subscription parameter 6.5.0 23 N4-040340 720 2 Add new Unavailability cause for SCUDIF 6.5.0 23 N4-040171 721 CR implemented by fault 6.5.0 23 N4-040182 724 Removal of R-GMLC Address 6.5.0 23 N4-040322 725 1 MO-LR Service Identity support 6.5.0 23 N4-040267 726 1 CAMEL4 SCUDIF notification during active call for prepay 6.5.0 24 N4-040520 731 Introduction of North American Interim Location Based Routing of Emergency Call 6.6.0 24 N4-040585 735 Modify IMEI parameter usage definition in MAP-PSL and MAP-SLR 6.6.0 24 N4-040600 736 Addition of SAI-Present indication to the LCS procedures 6.6.0 24 N4-040601 737 Clarification on the use of MSISDN parameter for Follow Me functionality 6.6.0 24 N4-04732 734 1 Add Additional V-GMLC parameter in MAP-SRI-INFO-FOR-LCS 6.6.0 24 N4-040736 718 6 Addition of IMEISV to Update Location Procedure for ADD function 6.6.0 25 N4-040929 739 Export of UU-Data data type 6.7.0 25 N4-041021 743 Wrong SDL flow page implemented 6.7.0 25 N4-041128 732 2 Pre-Paging Resource Optimization 6.7.0 26 N4-041272 747 Incorrect Implementation of CR 731 6.8.0 26 N4-041477 752 Correction to the service response parameters of ATI 6.8.0 26 N4-041662 746 1 Introducing VGCS/VBS ciphering 6.8.0 26 N4-041683 757 2 Clarification about returning authentication data for a subscriber (GSM or UMTS) 6.8.0 26 N4-041684 748 1 LCS Capability Handling for UE's 6.8.0 26 N4-041685 753 1 Enable NA-ESRD Provision from a GMLC for E911 Location in North America 6.8.0 26 N4-041641 740 2 SMS Fraud countermeasures 6.8.0 27 N4-050212 749 1 Management Based Activation Impacts 6.9.0 27 N4-050369 761 1 Addition of LAI to SendIdentification Request 6.9.0 27 N4-050430 760 1 Subscribed Charging Characteristics 6.9.0 27 N4-050444 759 1 Addition of TCAP-Handshake for MO-ForwardSM 6.9.0 27 N4-050446 745 2 Introduction of Hop Counter for Send Identification 6.9.0 27 N4-050463 738 8 Rel-6 trace management additions to trace activation and deactivation procedures 6.9.0 27 N4-050467 763 2 Pseudonym indicator support in MO-LR 6.9.0 28 C4-050737 769 1 Correction to Trace parameters to allow trace at the BM-SC 6.10.0 28 C4-050832 770 6 Full RANAP support of network initiated SCUDIF 6.10.0 28 C4-050895 766 2 Clarification on the use of Access Restriction Data parameter 6.10.0 28 C4-050784 765 1 Addition of CollectInformation procedure to OfferedCAMEL4Functionalities 7.0.0 29 C4-051013 771 ASN.1 module version update 7.1.0 29 C4-051295 776 2 Enabling the Providing of Velocity 7.1.0 29 C4-051333 772 1 Support of talker priorities and talker identity presentation 7.1.0 29 C4-051334 773 1 Delivery of SMS to voice group call 7.1.0 29 C4-051368 777 2 CS data Mobile Terminating calls from PSTN 7.1.0 29 C4-051336 780 2 Correction on misalignment with stage 2 for Location Services 7.1.0 30 C4-051775 783 2 Addition of UMTS Trace parameters to handover procedure 7.2.0 31 C4-060320 794 1 Addition of UMTS Trace parameters to handover procedure 7.3.0 31 C4-060295 790 1 Removal of MAPsec material 7.3.0 31 C4-060315 787 1 addition of ""supported RAT types indicator"" during location/routing area update 7.3.0 31 C4-060378 792 1 Addition of Periodic Location Feature Support 7.3.0 31 C4-060434 781 3 New LocationType for the notification based on current location of target UE 7.3.0 31 C4-060318 788 1 SMS Relay Application Context Names for Version 1 7.3.0 31 C4-060041 789 Precision on segmentation of MAP GPRSSubscriptionData parameter 7.3.0 31 C4-060250 801 Improvements to VGCS Call Establishment 7.3.0 31 C4-060011 786 Addition of Authentication Domains in MAP Send Authentication Info 7.3.0 32 C4-060813 0808 2 List of MSISDNs and Basic Service Code for MAP Any Time Subscription Interrogation."
"7.4.0 32 C4-060499 0803 Correction of LCS parameter for emergency call usage 7.4.0 32 C4-060680 0814 SSN for FFN 7.4.0 32 C4-060706 0817 Removal of MAPsec material 7.4.0 33 CP-060522 0818 1 Removal of ASN.1 Expanded Source 7.5.0 33 C4-061047 0805 1 Interoperability between VBS/VGCS and RANflex 7.5.0 34 CP-060741 0795 1 Support of SMS over IP networks 7.6.0 34 C4-061800 0828 1 Extension of Group ID 7.6.0 34 C4-061633 0829 Addition of Teleservice Code to SendGroupCallInfo 7.6.0 34 C4-061775 0834 Accuracy Fulfillment Indicator parameter to MAP SLR for deferred MT-LR 7.6.0 34 C4-060693 0832 2 Optional Suppress Terminating Services Bit String in SRI 7.6.0 34 C4-061632 0807 2 Introduction of sending application-specific data to group call members 8.0.0 35 C4-070140 0843 ASN.1 module version update 8.1.0 35 C4-070097 0837 Corrections to RAB Configuration Indicator and Iu-Selected codec 8.1.0 35 C4-070229 0840 Addition of capability to route MT-SMs via the HPLMN of the receiving MS 8.1.0 36 C4-070388 0849 Mobile Termination whilst the MS is moving to another MSC 8.2.0 36 C4-070394 0842 2 Addition of SMS over IP functionality 8.2.0 36 CP-070476 0859 Detailed procedure in the IP-SM-GW 8.2.0 37 C4-071055 0862 QoS Extension 8.3.0 37 C4-071072 0863 Talker Channel Parameter 8.3.0 37 C4-071266 0869 LMSI For MT-SMS 8.3.0 37 C4-071281 0873 1 NPI for the call forwarding to number 8.3.0 37 C4-071285 0864 1 Limit on number of concurrent MT-LR location requests 8.3.0 37 C4-071383 0868 2 Corrections to SMS over IP handling 8.3.0 38 C4-071724 0876 TCRT: Clarification on coding of Notification Data 8.4.0 38 C4-071815 0879 Removal of CCBS_Call_Report_Ack and Event_Report_Ack 8.4.0 38 C4-071855 0881 Restriction on the use of ccbs-A SS indication 8.4.0 38 C4-071891 0877 3 SMS Router Optimization 8.4.0 38 C4-071997 0875 1 Behaviour of the IP-SM-GW for SM Delivery Status Report 8.4.0 39 C4-080267 0885 Updating of RAT Types 8.5.0 39 C4-080148 0883 SDL correction for procedure Check_Available_Vectors 8.5.0 39 C4-080532 0886 2 HLR involvement in SMS Router Optimization 8.5.0 40 C4-081277 0888 1 Extension of Group ID 8.6.0 40 C4-080647 0882 1 Paging optimization with A/Iu flex 8.6.0 41 C4-081730 0890 Addition of IMS Centralized Service subscription information 8.7.0 41 C4-082447 0891 1 eMLPP Priority in MAP SRI, PRN and PSI request 8.7.0 41 C4-082335 0892 1 Gr+ enhancements for EPS 8.7.0 42 C4-082721 0894 Gr alignment 8.8.0 42 C4-082758 0896 RAT Frequency Selection Priority 8.8.0 42 C4-083029 0899 Change in AMBR placement 8.8.0 42 C4-083221 0901 PDN-GW-Identity 8.8.0 42 C4-083223 0902 APN-OIReplacement 8.8.0 42 C4-083247 0903 Access Restriction 8.8.0 42 CP-080706 0906 1 Access Restriction Data Handling 8.8.0 42 Cp-080771 0895 4 Closed Subscriber Group 8.8.0 42 SDL files added in Zip-file 8.8.1 43 C4-090140 0908 Context Identifier for Update or Removal of PDN GW 8.9.0 43 C4-090269 0911 Handling LCS Subscription Data 8.9.0 43 C4-090507 0914 PDN GW Update for Wildcard APN 8.9.0 43 C4-090701 0909 1 Ready for SM 8.9.0 43 C4-090855 0915 Handling SMS Subscription Data 8.9.0 43 C4-090889 0916 Allocation Retention Priority Definition 8.9.0 44 C4-091071 0919 SMS over IP 8.10.0 44 C4-091028 0917 MAP RESTORE DATA service 8.10.0 44 C4-091377 0921 1 Subscription Data Clarification for MAP Interface 8.10.0 44 C4-091429 0920 1 Trace 8.10.0 44 C4-091435 0922 1 Supported Features 8.10.0 44 CP-090379 0923 1 User Data Download 8.10.0 45 C4-091713 0924 Notification of SMS over IP Non-Delivery for E-UTRAN and UE Reachability 8.11.0 45 C4-092244 0927 SGSN interface list for trace 8.11.0 45 C4-092254 0925 2 Cancel Location for Initial Attach 8.11.0 45 C4-092291 0929 Fix APN-Configuration to support dual IP addresses 8.11.0 46 C4-094140 0941 1 Alignment of specifications on Usage of MAP_SEND_AUTHENTICATION_INFO 8.12.0 46 C4-093972 0942 1 SMS over SGs charging 8.12.0 46 C4-094136 0936 1 Subscription to Notification of UE Reachability 8.12.0 46 C4-093588 0935 1 Evolved ARP 9.0.0 46 C4-093294 0932 2 APN level APN-OI-Replacement 9.0.0 46 C4-093221 0933 1 ICS-Flag 9.0.0 47 C4-100386 0949 Correction to the location information EPS IE 9.1.0 47 C4-101003 0951 1 User CSG Information for CAMEL 9.1.0 47 C4-100946 0945 2 Support of Location Continuity on the Lg Interface 9.1.0 47 C4-100947 0958 2 Enhancement of MAP-SEND-ROUTING-INFO-FOR-LCS Service for EPS 9.1.0 47 C4-100264 0943 Evolved ARP Corrections 9.1.0 47 C4-100920 0928 4 AoIP Ð MAP level codec negotiation for GSM codecs 9.1.0 47 C4-100265 0944 Dual Stack support in GPRS 9.1.0 47 C4-100353 0939 2 Support MT Roaming Retry on Pre-paging 9.1.0 47 C4-100892 0954 1 TCRT: Uplink reply procedure 9.1.0 47 C4-100881 0956 1 TADS support in MAP 9.1.0 47 C4-101010 0950 1 UE-AMBR in GPRS Subscription 9.1.0 47 CP-100234 0960 Incorrect KASME length 9.1.0 47 CP-100203 0952 5 EPS Subcsriber State and Location Information Request 9.1.0 48 C4-101236 0971 CR implementation CR 642 9.2.0 48 C4-101403 0963 1 Correction to missing GANSS position data in Provide Subscriber Location and Provide Subscriber Location Report services 9.2.0 48 C4-101400 0967 1 Tracking Area Identity Length 9.2.0 48 C4-101131 0961 ASN.1 Module Version Update 9.2.0 48 C4-101135 0962 EPS state and location retrieval 9.2.0 49 C4-101802 0975 1 Sending of MME name or SGSN Number to the VLR during the data restoration procedure 9.3.0 49 C4-101805 0977 1 Data Restoration for SMS 9.3.0 49 C4-102251 0966 3 MAP SRI Return Error message 9.3.0 49 C4-102269 0985 1 EPS Subscription Data over Gr 9.3.0 49 C4-102376 0980 3 RP-OA modification in SMS Router 9.3.0 49 C4-101809 0976 1 Addition of SIPTO permissions in PS subscription data 10.0.0 49 C4-102250 0957 4 Prevention of Timeout in IP-SM-GW 10.0.0 49 CP-100608 0979 2 Addition of SS codes to the ATSI and ATM procedures 10.0.0 50 C4-103099 0990 2 locationInformationEPS in Subscriber Info response 10.1.0 50 C4-102699 0988 1 Removal of MAP Update GPRS Location message during detach or last PDN connection deactivation via 3GPP access 10.1.0 50 C4-102737 0993 1 URRP for SGSN 10.1.0 50 C4-103156 1005 Location data including only serving node address 10.1.0 50 C4-103157 0997 2 Correction to ATM for call waiting 10.1.0 50 C4-103314 1002 2 Periodic TAU/RAU timer in HSS subscription 10.1.0 50 C4-102614 0991 ASN.1 module version upgrade 10.1.0 50 C4-102687 0987 1 Addition of MPS Priority in Subscription Data 10.1.0 50 C4-102809 0986 1 Addition of LIPA permission in Subscription Data 10.1.0 51 C4-110389 1006 2 UE SRVCC Capability Support in MAP Message 10.2.0 51 C4-110292 1008 1 Use of recovered MME Name / SGSN Name in MSC/VLR 10.2.0 51 C4-110133 1009 Zone Code Propagation at Handover 10.2.0 51 C4-110665 1016 Retrieval of T-ADS data via MAP ATI 10.2.0 51 C4-110759 1018 1 Mobile Terminating Roaming Forwarding 10.2.0 51 C4-110778 1007 2 Minimization of Drive Tests (MDT) 10.2.0 51 C4-110793 1015 1 Introduction of LCLS functionality in TS 29.002 10.2.0 51 C4-110958 1017 2 Enhancements of T-ADS data retrieval via MAP ATI 10.2.0 52 C4-111112 1024 Correction on Subscriber Data Withdrawal 10.3.0 52 C4-111611 1030 2 Missing MME Name in EPS Location Information 10.3.0 52 C4-111534 1020 1 MDT user consent 10.3.0 52 C4-111567 1021 1 SC Address in IP-SM-GW Register Response 10.3.0 52 C4-111402 1025 1 Periodic LAU timer in HSS subscription 10.3.0 52 C4-111414 1026 1 New LMSI handling for MTRF 10.3.0 52 C4-111416 1029 1 Addition of VMSC Address in PRN Ack 10.3.0 53 C4-112067 1047 Use of UE-Reachability by SGSN 10.4.0 53 C4-112081 1042 1 APN-AMBR for GPRS 10.4.0 53 C4-112096 1033 1 MTRF and Super Charger interactions 10.4.0 53 C4-111986 1043 ASN.1 exports for 32.298 11.0.0 53 C4-112033 1032 1 Addition of Anonymous Call Rejection in the CS domain 11.0.0 53 C4-112209 1037 2 Add vSRVCC updates to the Gr interface 11.0.0 53 C4-112222 1040 2 MAP-READY-FOR-SM for IP-SM-GW 11.0.0 54 C4-112930 1053 1 Provide Subscriber Information handling for UE under LTE 11.1.0 54 C4-112988 1063 PDN-Type 11.1.0 54 C4-112990 1056 1 Equivalent PLMN CSG Subscription Request 11.1.0 54 C4-113037 1055 2 LCLS negotiation MAP update 11.1.0 54 C4-112464 1039 4 Cancellation type initial attach 11.1.0 55 C4-120406 1064 1 Initial Attach Indication in MAP_CANCEL_LOCATION 11.2.0 55 C4-120420 1073 1 Removal of Subscribed Periodic TAU/RAU timer in HSS subscription 11.2.0 55 C4-120528 1072 2 User Unknown Error in Provide Subscriber Info MAP operation 11.2.0 55 C4-120224 1066 UE reachability 11.2.0 55 C4-120322 1070 TC-RT: Introduction of group IDs with prefix 11.2.0 55 C4-120416 1067 1 CSG subscription data propagation 11.2.0 55 C4-120423 1069 1 Trace Depth 11.2.0 56 C4-120707 1078 Editorial corrections to TS 29.002 11.3.0 56 C4-120713 1079 Equivalent PLMN CSG Subscription Request for CS 11.3.0 56 C4-120732 1080 EPS location in MAP Note MM Event 11.3.0 56 C4-120959 1065 3 CSG ID and Local Time for NPLI 11.3.0 56 C4-121086 1082 Clarification on HLR procedure for SMS delivery via IP-SM-GW 11.3.0 56 C4-121222 1059 4 Procedures for Update VCSG Location service 11.3.0 56 C4-121223 1049 9 Retrieving CSG subscription data from the CSS to the VLR/SGSN 11.3.0 56 C4-121227 1060 5 CSG Data Management in the VPLMN 11.3.0 57 C4-121465 1089 - TC RT: Number of Dispatcher extension 11.4.0 57 C4-121635 1088 1 Check IMEI Error 11.4.0 57 C4-121805 1092 2 Local Time Zone 11.4.0 57 C4-121534 1084 1 IMSI in MAP-MO-FORWARD-SHORT-MESSAGE 11.4.0 57 C4-121817 1068 5 PS additional number 11.4.0 57 C4-121813 1090 2 SRI for SM and MME Diameter address 11.4.0 57 C4-121802 1091 2 MSISDN-less MT-SMS 11.4.0 57 C4-121625 1083 1 PS only subscription w/o MSISDN 11.4.0 57 C4-121809 1077 4 SMS in MME/SGSN 11.4.0 57 C4-121648 1085 1 CSS Reset Procedures 11.4.0 57 C4-121650 1086 2 Temporary empty CSG suscription data 11.4.0 58 C4-122660 1106 4 Clarification on EPS Info 11.5.0 58 C4-122497 1108 1 Pdp Type 11.5.0 58 C4-122164 1093 1 Trace Depth extension 11.5.0 58 C4-121847 1094 AC version for Reset 11.5.0 58 C4-122469 1095 4 MSISDN-less UEs 11.5.0 58 C4-122476 1096 3 T4 Device Trigger via IMS 11.5.0 58 C4-122187 1097 2 T4 Trigger indication to IP-SM-GW 11.5.0 58 C4-122190 1098 2 Add Diameter Addresses to MT-SMS target node registrations 11.5.0 58 C4-121870 1099 IMSI in AbsentSubscriberSM-param 11.5.0 58 C4-122165 1101 1 Handling of current security context during inter-VLR location update 11.5.0 59 C4-130330 1118 1 SGSN acting on access restriction e-utranNotAllowed 11.6.0 59 C4-130293 1119 1 Registration for SMS Request for SMS in SGSN 11.6.0 59 C4-130305 1120 1 MDT parameters 11.6.0 59 C4-130335 1121 1 Providing Diameter identity of the SGSN to the GMLC over Lh interface 12.0.0 59 C4-130340 1122 1 SGSN indicating support of Lgd interface and providing its Diameter identity to HLR over Gr interface 12.0.0 59 C4-130423 1123 2 Validity Time of Short Message 12.0.0 59 C4-130256 1114 Mobile Terminating call pending flag in MAP Send Identification response 12.0.0 60 C4-131046 1147 2 Subscribed RFSP index for Gn SGSNs 12.1.0 60 C4-131061 1142 3 MME identity for restoration procedures 12.1.0 60 C4-130603 1128 Expicit T4-Trigger Indicator in SRI-SM 12.1.0 60 C4-130929 1126 1 Restoration Priority during SGW and PGW restoration procedures 12.1.0 60 CP-130379 1132 3 SIPTO permission for Local Network enhancements 12.1.0 60 C4-130859 1131 1 Clarification on RNC ID value 12.1.0 60 C4-130979 1129 1 Storing Last known Location Information of purged UE in HSS 12.1.0 60 C4-131040 1135 2 Maximum value for subscribed periodic timers 12.1.0 61 C4-131488 1158 2 Addition of Missing Supported Features 12.2.0 61 C4-131261 1160 ASN.1 module version update 12.2.0 61 C4-131540 1149 1 Returning to former LTE PLMN after CSFB 12.2.0 61 C4-131398 1152 2 Complements for Gdd support 12.2.0 61 C4-131445 1153 1 GERAN Iu Mode 12.2.0 61 C4-131478 1150 2 CancelLocation requesting reattach 12.2.0 61 C4-131529 1161 Enforcing access restriction during I-RAT RAU/TAU procedures 12.2.0 61 C4-131370 1130 2 SMS for IMS UE to IMS UE without MSISDN 12.2.0 62 C4-131758 1162 1 Addition of a reference to TS 23.018 for MTRF optimal routing 12.3.0 62 C4-131759 1163 1 Removal of Editor's Notes for Single-shot SM 12.3.0 62 C4-131764 1165 1 Clarification on Serving Node for SMS 12.3.0 62 C4-132011 1167 MME Initiated Removal of MME Registration for SMS 12.3.0 62 C4-132125 1169 1 Update of Homogeneous Support of IMS Voice Over PS Sessions 12.3.0 62 C4-132202 1171 1 Time Zone retrieval from a Gn/Gp-SGSN 12.3.0 63 C4-140243 1174 1 Addition of SGSN CAMEL Capability to SupportedFeatures 12.4.0 64 C4-140515 1177 CS to PS SRVCC 12.5.0 64 C4-140897 1179 Indication of IMEISV during Inter-MSC Handover 12.5.0 65 C4-141526 1181 1 P-CSCF Restoration Indication 12.6.0 65 C4-141653 1182 1 Closing TS 29.234 and reused AVP in TS 29.273 12.6.0 66 C4-141778 1183 1 MDT PLMN List 12.7.0 66 C4-142039 1187 1 WLAN offloadability for MAP 12.7.0 68 C4-150647 1188 1 Access restriction per VPLMN 13.0.0 68 C4-150880 1190 Access Restriction Data per PLMN 13.0.0 69 C4-151177 1191 ASN.1 module version update 13.1.0 70 C4-151631 1194 Reference Correction 13.2.0 70 C4-151813 1192 1 Introducing IMSI-Group ID Lists to the insert subscriber data 13.2.0 70 C4-151801 1195 1 Retrieval of ""UE Usage Type"" over MAP-Gr 13.2.0 70 C4-152198 1196 1 Positioning enhancement impacts on MAP protocol 13.2.0 70 CP-150868 1198 2 Mobile Terminating SMS handling for extended Idle mode DRX Ð Additional Option 13.2.0 70 CP-150869 1197 2 Mobile Terminating SMS handling for extended Idle mode DRX 13.2.0 71 C4-161271 1202 1 Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX 13.3.0 71 C4-161062 1200 Requested Retransmission Time in MT-Forward-SM response 13.3.0 71 C4-161527 1205 2 New PDN-Type for Cellular IoT 13.3.0 71 C4-161492 1204 2 Addition of NB-IoT radio access type to the Access-Restriction-Data feature 13.3.0 71 C4-161161 1203 Time Zone in MAP-Any-Time-Interrogation 13.3.0 71 C4-161317 1201 1 User Plane Integrity Protection Indicator 13.3.0 72 C4-162090 1213 Clause Numbering 13.4.0 72 C4-163271 1215 3 Group-Service-Id 13.4.0 2016-06 CT#72 CP-160217 1216 1 Use of recovered MME Name / SGSN Name in MSC/VLR 14.0.0 2016-06 CT#72 CP-160217 1214 1 Zone Code Propagation at Handover 14.0.0 2016-09 CT#73 CP-160430 1219 Retrieval of T-ADS data via MAP ATI 14.1.0 2016-09 CT#73 CP-160583 1218 2 Mobile Terminating Roaming Forwarding 14.1.0 2016-09 CT#73 CP-160423 1221 1 Minimization of Drive Tests (MDT) 14.1.0 2016-12 CT#74 CP-160667 1225 1 Introduction of LCLS functionality in TS 29.002 14.2.0 2016-12 CT#74 CP-160665 1229 1 Enhancements of T-ADS data retrieval via MAP ATI 14.2.0 2016-12 CT#74 CP-160659 1227 Correction on Subscriber Data Withdrawal 14.2.0 2016-12 CT#74 CP-160683 1230 3 Missing MME Name in EPS Location Information 14.2.0 2016-12 CT#74 CP-160657 1233 MDT user consent 14.2.0 2016-12 CT#74 CP-160683 1231 1 SC Address in IP-SM-GW Register Response 14.2.0 2017-03 CT#75 CP-170034 1236 T4 Triggering 14.3.0 2017-03 CT#75 CP-170039 1234 1 Enhanced Coverage 14.3.0 2017-03 CT#75 CP-170039 1235 1 Inter-RAT PDN-Continuity 14.3.0 2017-03 CT#76 CP-171039 1237 - T-ADS info retrieval 15.0.0 2017-09 CT#77 CP-172021 1239 - ASN.1 module version update 15.1.0 2017-12 CT#78 CP-173016 1243 2 Correction on subscribed eDRX parameter value 15.2.0 2017-12 CT#78 CP-173036 1240 - Access Restrictions to NR as Secondary RAT 15.2.0 2017-12 CT#78 CP-173036 1241 - Extended Qos 15.2.0 2018-03 CT#79 CP-180027 1244 2 Access restriction to unlicensed spectrum as secondary RAT 15.3.0 2018-10 Cover page version number was corrected 15.3.1 2018-12 CT#82 C4-187638 1245 2 Location Information used by IM-SSF in 5G 15.4.0 2019-06 CT#84 CP-191020 1249 ASN.1 corrections 15.5.0 2019-06 CT#84 CP-191058 1250 1 SMSF Address 15.5.0 2020-03 CT#87 CP-200049 1253 Correction on Location Information used by IM-SSF in 5G 15.6.0 2020-03 CT#87 CP-200027 1251 3 Addition of IAB operation permission to subscriber data 16.0.0 2020-12 CT#90e CP-203027 1255 Inform SC 16.1.0 2020-12 CT#90e CP-203027 1257 SMSF parameter description 16.1.0 2021-03 CT#91e CP-210053 1260 Correction on length of 5GS TAI 16.2.0 2021-03 CT#91e CP-210036 1261 Clarification for dummy Network Node Number 17.0.0 2021-03 CT#91e CP-210036 1259 1 Support of MAP messages at the UDM for SMS in 5GS 17.0.0 2021-06 CT#92e CP-211075 1263 ASN.1 module version update 17.1.0 2021-06 CT#92e CP-211319 1265 Misimplemented CR on Inclusive language review: EIR lists 17.1.0 2022-06 CT#96 CP-221045 1266 - 3GPPÊTSÊ23.107 missing in clause 2 17.2.0 Page 1 CR page 1006 3GPP 3GPP TS 29.002 V17.1.0 (2021-06) 14 Release 17 3GPP 3GPP TS 29.272 V18.2.0 (2023-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 18) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2023, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 10 1 Scope 11 2 References 11 3 Definitions and abbreviations 14 3.1 Definitions 14 3.2 Abbreviations 14 4 General Description 15 5 MME Ð HSS (S6a) and SGSN Ð HSS (S6d) 15 5.1 Introduction 15 5.2 Mobility Services 15 5.2.1 Location Management Procedures 15 5.2.1.1 Update Location 15 5.2.1.1.1 General 15 5.2.1.1.2 Detailed behaviour of the MME and the SGSN 18 5.2.1.1.3 Detailed behaviour of the HSS 23 5.2.1.2 Cancel Location 27 5.2.1.2.1 General 27 5.2.1.2.2 Detailed behaviour of the MME and the SGSN 27 5.2.1.2.3 Detailed behaviour of the HSS 28 5.2.1.3 Purge UE 28 5.2.1.3.1 General 28 5.2.1.3.2 Detailed behaviour of the MME and the SGSN 29 5.2.1.3.3 Detailed behaviour of HSS 30 5.2.2 Subscriber Data Handling Procedures 30 5.2.2.1 Insert Subscriber Data 30 5.2.2.1.1 General 30 5.2.2.1.2 Detailed behaviour of the MME and the SGSN 33 5.2.2.1.3 Detailed behaviour of HSS 36 5.2.2.2 Delete Subscriber Data 38 5.2.2.2.1 General 38 5.2.2.2.2 Detailed behaviour of the MME and the SGSN 41 5.2.2.2.3 Detailed behaviour of the HSS 42 5.2.3 Authentication Procedures 42 5.2.3.1 Authentication Information Retrieval 42 5.2.3.1.1 General 42 5.2.3.1.2 Detailed behaviour of the MME and the SGSN 44 5.2.3.1.3 Detailed behaviour of the HSS 44 5.2.4 Fault Recovery Procedures 46 5.2.4.1 Reset 46 5.2.4.1.1 General 46 5.2.4.1.2 Detailed behaviour of the MME and the SGSN 47 5.2.4.1.3 Detailed behaviour of the HSS 48 5.2.5 Notification Procedures 49 5.2.5.1 Notification 49 5.2.5.1.1 General 49 5.2.5.1.2 Detailed behaviour of the MME and the SGSN 52 5.2.5.1.3 Detailed behaviour of the HSS 53 5A MME Ð CSS (S7a) and SGSN Ð CSS (S7d) 54 5A.1 Introduction 54 5A.2 Mobility Services 54 5A.2.1 Location Management Procedures 54 5A.2.1.1 Update VCSG Location 54 5A.2.1.1.1 General 54 5A.2.1.1.2 Detailed behaviour of the MME and the SGSN 55 5A.2.1.1.3 Detailed behaviour of the CSS 56 5A.2.1.2 Cancel VCSG Location 56 5A.2.1.2.1 General 56 5A.2.1.2.2 Detailed behaviour of the MME and the SGSN 57 5A.2.1.2.3 Detailed behaviour of the CSS 57 5A.2.2 Subscriber Data Handling Procedures 57 5A.2.2.1 Insert VCSG Subscriber Data 57 5A.2.2.1.1 General 57 5A.2.2.1.2 Detailed behaviour of the MME and the SGSN 58 5A.2.2.1.3 Detailed behaviour of CSS 59 5A.2.2.2 Delete VCSG Subscriber Data 59 5A.2.2.2.1 General 59 5A.2.2.2.2 Detailed behaviour of the MME and the SGSN 60 5A.2.2.2.3 Detailed behaviour of the CSS 60 5A.2.3 Fault Recovery Procedures 60 5A.2.3.1 VCSG Reset 60 5A.2.3.1.1 General 60 5A.2.3.1.2 Detailed behaviour of the MME and the SGSN 61 5A.2.3.1.3 Detailed behaviour of the CSS 61 6 MME Ð EIR (S13) and SGSN Ð EIR (S13') 62 6.1 Introduction 62 6.2 ME Identity Check Procedures 62 6.2.1 ME Identity Check 62 6.2.1.1 General 62 6.2.1.2 Detailed behaviour of the MME and the SGSN 63 6.2.1.3 Detailed behaviour of the EIR 63 7 Protocol Specification and Implementation 64 7.1 Introduction 64 7.1.1 Use of Diameter base protocol 64 7.1.2 Securing Diameter Messages 64 7.1.3 Accounting functionality 64 7.1.4 Use of sessions 64 7.1.5 Transport protocol 64 7.1.6 Routing considerations 65 7.1.7 Advertising Application Support 65 7.1.8 Diameter Application Identifier 65 7.1.9 Use of the Supported-Features AVP 66 7.2 Commands 67 7.2.1 Introduction 67 7.2.2 Command-Code values 67 7.2.3 Update-Location-Request (ULR) Command 68 7.2.4 Update-Location-Answer (ULA) Command 69 7.2.5 Authentication-Information-Request (AIR) Command 69 7.2.6 Authentication-Information-Answer (AIA) Command 70 7.2.7 Cancel-Location-Request (CLR) Command 70 7.2.8 Cancel-Location-Answer (CLA) Command 70 7.2.9 Insert-Subscriber-Data-Request (IDR) Command 71 7.2.10 Insert-Subscriber-Data-Answer (IDA) Command 71 7.2.11 Delete-Subscriber-Data-Request (DSR) Command 72 7.2.12 Delete-Subscriber-Data-Answer (DSA) Command 73 7.2.13 Purge-UE-Request (PUR) Command 74 7.2.14 Purge-UE-Answer (PUA) Command 74 7.2.15 Reset-Request (RSR) Command 75 7.2.16 Reset-Answer (RSA) Command 75 7.2.17 Notify-Request (NOR) Command 76 7.2.18 Notify-Answer (NOA) Command 76 7.2.19 ME-Identity-Check-Request (ECR) Command 77 7.2.20 ME-Identity-Check-Answer (ECA) Command 77 7.2.21 Update-VCSG-Location-Request (UVR) Command 78 7.2.22 Update-VCSG-Location-Answer (UVA) Command 78 7.2.23 Cancel-VCSG-Location-Request (CVR) Command 78 7.2.24 Cancel-VCSG-Location-Answer (CVA) Command 79 7.3 Information Elements 80 7.3.1 General 80 7.3.2 Subscription-Data 89 7.3.3 Terminal-Information 90 7.3.4 IMEI 91 7.3.5 Software-Version 91 7.3.6 3GPP2-MEID 91 7.3.7 ULR-Flags 91 7.3.8 ULA-Flags 93 7.3.9 Visited-PLMN-Id 93 7.3.10 Feature-List AVP 93 7.3.10.1 Feature-List AVP for the S6a/S6d application 93 7.3.10.2 Feature-List AVP for the S7a/S7d application 106 7.3.11 Requested-EUTRAN-Authentication-Info 106 7.3.12 Requested-UTRAN- GERAN-Authentication-Info 106 7.3.13 RAT-Type 106 7.3.14 Number-Of-Requested-Vectors 106 7.3.15 Re-Synchronization-Info 107 7.3.16 Immediate-Response-Preferred 107 7.3.17 Authentication-Info 107 7.3.18 E-UTRAN-Vector 107 7.3.19 UTRAN-Vector 107 7.3.20 GERAN-Vector 108 7.3.21 Network-Access-Mode 108 7.3.22 HPLMN-ODB 108 7.3.23 Item-Number 108 7.3.24 Cancellation-Type 108 7.3.25 DSR-Flags 109 7.3.26 DSA-Flags 111 7.3.27 Context-Identifier 111 7.3.28 Void 112 7.3.29 Subscriber-Status 112 7.3.30 Operator-Determined-Barring 112 7.3.31 Access-Restriction-Data 112 7.3.32 APN-OI-Replacement 113 7.3.33 All-APN-Configurations-Included-Indicator 113 7.3.34 APN-Configuration-Profile 114 7.3.35 APN-Configuration 114 7.3.36 Service-Selection 116 7.3.37 EPS-Subscribed-QoS-Profile 116 7.3.38 VPLMN-Dynamic-Address-Allowed 116 7.3.39 STN-SR 116 7.3.40 Allocation-Retention-Priority 117 7.3.41 AMBR 117 7.3.42 MIP-Home-Agent-Address 117 7.3.43 MIP-Home-Agent-Host 118 7.3.44 PDN-GW-Allocation-Type 118 7.3.45 MIP6-Agent-Info 118 7.3.46 RAT-Frequency-Selection-Priority-ID 118 7.3.47 IDA-Flags 118 7.3.48 PUA-Flags 119 7.3.49 NOR-Flags 119 7.3.50 User-Id 120 7.3.51 Equipment-Status 120 7.3.52 Regional-Subscription-Zone-Code 121 7.3.53 RAND 121 7.3.54 XRES 121 7.3.55 AUTN 121 7.3.56 KASME 121 7.3.57 Confidentiality-Key AVP 121 7.3.58 Integrity-Key AVP 121 7.3.59 Kc AVP 121 7.3.60 SRES 121 7.3.61 Void 121 7.3.62 PDN-Type 121 7.3.63 Trace-Data AVP 122 7.3.64 Trace-Reference AVP 122 7.3.65 Void 123 7.3.66 Void 123 7.3.67 Trace-Depth AVP 123 7.3.68 Trace-NE-Type-List AVP 123 7.3.69 Trace-Interface-List AVP 123 7.3.70 Trace-Event-List AVP 123 7.3.71 OMC-Id AVP 123 7.3.72 GPRS-Subscription-Data 123 7.3.73 Complete-Data-List-Included-Indicator 124 7.3.74 PDP-Context 124 7.3.75 PDP-Type 125 7.3.75A Ext-PDP-Type 125 7.3.76 Void 125 7.3.77 QoS-Subscribed 125 7.3.78 CSG-Subscription-Data 125 7.3.79 CSG-Id 125 7.3.80 Expiration-Date 125 7.3.81 Roaming-Restricted-Due-To-Unsupported-Feature 126 7.3.82 Specific-APN-Info AVP 126 7.3.83 Alert-Reason AVP 126 7.3.84 LCS-Info 126 7.3.85 GMLC-Number 126 7.3.86 LCS-PrivacyException 127 7.3.87 SS-Code 127 7.3.88 SS-Status 127 7.3.89 Notification-To-UE-User 127 7.3.90 External-Client 127 7.3.91 Client-Identity 128 7.3.92 GMLC-Restriction 128 7.3.93 PLMN-Client 128 7.3.94 Service-Type 128 7.3.95 ServiceTypeIdentity 128 7.3.96 MO-LR 128 7.3.97 Void 129 7.3.98 Trace-Collection-Entity AVP 129 7.3.99 Teleservice-List 129 7.3.100 TS-Code 129 7.3.101 Call-Barring-Info 129 7.3.102 SGSN-Number 129 7.3.103 IDR-Flags 129 7.3.104 ICS-Indicator 130 7.3.105 Visited-Network-Identifier 130 7.3.106 IMS-Voice-Over-PS-Sessions-Supported 131 7.3.107 Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions 131 7.3.108 Last-UE-Activity-Time 131 7.3.109 GMLC-Address 131 7.3.110 EPS-User-State 131 7.3.111 EPS-Location-Information 132 7.3.112 MME-User-State 132 7.3.113 SGSN-User-State 132 7.3.114 User-State 132 7.3.115 MME-Location-Information 133 7.3.116 SGSN-Location-Information 133 7.3.117 E-UTRAN-Cell-Global-Identity 134 7.3.118 Tracking-Area-Identity 134 7.3.119 Cell-Global-Identity 134 7.3.120 Routing-Area-Identity 134 7.3.121 Location-Area-Identity 134 7.3.122 Service-Area-Identity 134 7.3.123 Geographical-Information 134 7.3.124 Geodetic-Information 134 7.3.125 Current-Location-Retrieved 134 7.3.126 Age-Of-Location-Information 135 7.3.127 Active-APN 135 7.3.128 Error-Diagnostic 135 7.3.129 Ext-PDP-Address AVP 136 7.3.130 UE-SRVCC-Capability 136 7.3.131 MPS-Priority 136 7.3.132 VPLMN-LIPA-Allowed 136 7.3.133 LIPA-Permission 136 7.3.134 Subscribed-Periodic-RAU-TAU-Timer 137 7.3.135 SIPTO-Permission 137 7.3.136 MDT-Configuration 137 7.3.137 Job-Type 138 7.3.138 Area-Scope 138 7.3.139 List-Of-Measurements 138 7.3.140 Reporting-Trigger 138 7.3.141 Report-Interval 138 7.3.142 Report-Amount 138 7.3.143 Event-Threshold-RSRP 138 7.3.144 Event-Threshold-RSRQ 138 7.3.145 Logging-Interval 138 7.3.146 Logging-Duration 139 7.3.147 Relay-Node-Indicator 139 7.3.148 MDT-User-Consent 139 7.3.149 PUR-Flags 139 7.3.150 Subscribed-VSRVCC 139 7.3.151 Equivalent-PLMN-List 140 7.3.152 CLR-Flags 140 7.3.153 UVR-Flags 140 7.3.154 UVA-Flags 140 7.3.155 VPLMN-CSG-Subscription-Data 141 7.3.156 Local-Time-Zone 141 7.3.157 A-MSISDN 141 7.3.158 Void 141 7.3.159 MME-Number-for-MT-SMS 141 7.3.160 Void 142 7.3.161 Void 142 7.3.162 SMS-Register-Request 142 7.3.163 Time-Zone 142 7.3.164 Daylight-Saving-Time 142 7.3.165 Subscription-Data-Flags 142 7.3.166 Measurement-Period-LTE 143 7.3.167 Measurement-Period-UMTS 143 7.3.168 Collection-Period-RRM-LTE 143 7.3.169 Collection-Period-RRM-UMTS 143 7.3.170 Positioning-Method 143 7.3.171 Measurement-Quantity 143 7.3.172 Event-Threshold-Event-1F 144 7.3.173 Event-Threshold-Event-1I 144 7.3.174 Restoration-Priority 144 7.3.175 SGs-MME-Identity 144 7.3.176 SIPTO-Local-Network-Permission 144 7.3.177 Coupled-Node-Diameter-ID 144 7.3.178 OC-Supported-Features 144 7.3.179 OC-OLR 144 7.3.180 ProSe-Subscription-Data 144 7.3.181 WLAN-offloadability 145 7.3.182 WLAN-offloadability-EUTRAN 145 7.3.183 WLAN-offloadability-UTRAN 145 7.3.184 Reset-ID 145 7.3.185 MDT-Allowed-PLMN-Id 146 7.3.186 Adjacent-PLMNs 146 7.3.187 Adjacent-Access-Restriction-Data 146 7.3.188 DL-Buffering-Suggested-Packet-Count 146 7.3.189 IMSI-Group-Id 147 7.3.190 Group-Service-Id 147 7.3.191 Group-PLMN-Id 147 7.3.192 Local-Group-Id 148 7.3.193 AESE-Communication-Pattern 148 7.3.194 Communication-Pattern-Set 148 7.3.195 Monitoring-Event-Configuration 149 7.3.196 Monitoring-Event-Report 150 7.3.197 UE-Reachability-Configuration 150 7.3.198 eNodeB-ID 151 7.3.199 Supported-Services 151 7.3.200 Supported-Monitoring-Events 151 7.3.201 AIR-Flags 151 7.3.202 UE-Usage-Type 152 7.3.203 DRMP 152 7.3.204 Non-IP-PDN-Type-Indicator 152 7.3.205 Non-IP-Data-Delivery-Mechanism 152 7.3.206 Additional-Context-Identifier 153 7.3.207 SCEF-Realm 153 7.3.208 Subscription-Data-Deletion 153 7.3.209 Preferred-Data-Mode 153 7.3.210 Emergency-Info 153 7.3.211 Load 154 7.3.212 V2X-Subscription-Data 154 7.3.213 V2X-Permission 154 7.3.214 PDN-Connection-Continuity 154 7.3.215 eDRX-Cycle-Length 155 7.3.216 eDRX-Cycle-Length-Value 155 7.3.217 UE-PC5-AMBR 155 7.3.218 Extended eNodeB-ID 155 7.3.219 MBSFN-Area 155 7.3.220 MBSFN-Area-ID 155 7.3.221 Carrier-Frequency 156 7.3.222 RDS-Indicator 156 7.3.223 Service-Gap-Time 156 7.3.224 Aerial-UE-Subscription-Information 156 7.3.225 Broadcast-Location-Assistance-Data-Types 156 7.3.226 Paging-Time-Window 158 7.3.227 Operation-Mode 158 7.3.228 Paging-Time-Window-Length 158 7.3.229 eDRX-Related-RAT 158 7.3.230 Core-Network-Restrictions 159 7.3.231 Interworking-5GS-Indicator 159 7.3.232 Ethernet-PDN-Type-Indicator 159 7.3.233 Subscribed-ARPI 159 7.3.234 IAB-Operation-Permission 159 7.3.235 V2X-Subscription-Data-Nr 160 7.3.236 UE-PC5-QoS 160 7.3.237 PC5-QoS-Flow 160 7.3.238 5QI 160 7.3.239 PC5-Flow-Bitrates 160 7.3.240 Guaranteed-Flow-Bitrates 161 7.3.241 Maximum-Flow-Bitrates 161 7.3.242 PC5-Range 161 7.3.243 PC5-Link-AMBR 161 7.3.244 Third-Context-Identifier 161 7.4 Result-Code and Experimental-Result Values 161 7.4.1 General 161 7.4.2 Success 161 7.4.3 Permanent Failures 161 7.4.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001) 161 7.4.3.2 DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) 162 7.4.3.3 DIAMETER_ERROR_RAT_NOT_ALLOWED (5421) 162 7.4.3.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) 162 7.4.3.5 DIAMETER_ERROR_EQUIPMENT_UNKNOWN (5422) 162 7.4.3.6 DIAMETER_ERROR_UNKNOWN_SERVING_NODE (5423) 162 7.4.4 Transient Failures 162 7.4.4.1 DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181) 162 7.4.4.2 DIAMETER_ERROR_CAMEL_SUBSCRIPTION_PRESENT (4182) 162 8 User identity to HSS resolution 162 Annex A (normative): MME mapping table for S6a and NAS Cause Code values 163 Annex B(normative): SGSN mapping table for S6d and NAS Cause Code values 166 Annex C (normative): Diameter overload control mechanism 168 C.1 General 168 C.2 S6a/S6d interfaces 168 C.2.1 General 168 C.2.2 HSS behaviour 168 C.2.3 MME/SGSN behaviour 168 Annex D (Informative): Diameter overload control node behaviour 169 D.1 Message prioritisation over S6a/d 169 Annex E (normative): Diameter message priority mechanism 169 E.1 General 169 E.2 S6a/S6d interfaces 169 E.2.1 General 169 E.2.2 HSS, CSS, EIR behaviour 169 E.2.3 MME/SGSN behaviour 170 Annex F (normative): Diameter load control mechanism 171 F.1 General 171 F.2 S6a/S6d interfaces 171 F.2.1 General 171 F.2.2 HSS behaviour 171 F.2.3 MME/SGSN behaviour 171 Annex G (informative): Change history 172 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope The present document describes the Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related diameter-based interfaces towards the Home Subscriber Server (HSS) or the CSG Subscriber Server (CSS), and the MME and the SGSN related diameter-based interface towards the Equipment Identity Register (EIR). This specification defines the Diameter application for the MME-HSS, S6a reference point, for the MME-CSS, S7a reference point, for the SGSN-HSS, S6d reference point, and for the SGSN-CSS, S7d reference point. The interactions between the HSS/CSS and the MME/SGSN are specified, including the signalling flows. This specification defines the Diameter application for the MME-EIR, S13 reference point, and for the SGSN-EIR, S13' reference point. The interactions between the MME/SGSN and the EIR are specified, including the signalling flows. In this specification, if there is no specific indication, the following principles apply: - ""SGSN"" refers to an SGSN which at least supports the S4 interface and may support Gn and Gp interfaces. - ""S4-SGSN"" refers to an SGSN which supports the S4 interface and does not support Gn and Gp interfaces. - Gn/Gp-SGSN refers to an SGSN which supports the Gn and Gp interfaces and does not support S4 interface. - ""GPRS subscription data"" refers to the parameters in the HLR column in Table 5.2. in 3GPPÊTSÊ23.008Ê[30]. - ""EPS subscription data"" refers to the parameters in the HSS column in Table 5.2A-1 in 3GPPÊTSÊ23.008Ê[30]. The Evolved Packet System stage 2 description (architecture and functional solutions) is specified in 3GPPÊTSÊ23.401Ê[2] and in 3GPPÊTSÊ23.060Ê[12]. SGSN CAMEL Subscription Data are not supported over S6d interface. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPPÊTRÊ21.905: ""Vocabulary for 3GPP Specifications"". [2] 3GPPÊTSÊ23.401: ""GPRS enhancements for E-UTRAN access "". [3] 3GPPÊTSÊ23.003: ""Numbering, addressing and identification"". [4] Void. [5] 3GPPÊTSÊ33.401: ""3GPP System Architecture Evolution: Security Architecture"". [6] Void"". [7] IETFÊRFCÊ2234: ""Augmented BNF for syntax specifications"". [8] 3GPPÊTSÊ32.299: ""Charging management; Diameter charging applications"". [9] 3GPPÊTSÊ29.229: ""Cx and Dx interfaces based on the Diameter protocol"". [10] 3GPPÊTSÊ29.212: ""Policy and Charging Control (PCC); Reference points"". [11] 3GPPÊTSÊ29.214: ""Policy and Charging Control over Rx reference point"". [12] 3GPPÊTSÊ23.060: ""General Packet Radio Service (GPRS); Service description; StageÊ2"". [13] 3GPPÊTSÊ22.016: ""International Mobile station Equipment Identities (IMEI)"". [14] IETFÊRFCÊ4960: ""Stream Control Transmission Protocol"". [15] Void [16] 3GPPÊTSÊ33.210: ""3G Security; Network Domain Security; IP Network Layer Security"".. [17] 3GPPÊTSÊ29.228: ""IP multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and Message Elements"". [18] 3GPPÊTSÊ33.102: ""3G Security; Security Architecture"". [19] 3GPPÊTSÊ36.413: ""Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)"". [20] IETFÊRFCÊ5778: ""Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction"". [21] 3GPPÊTSÊ29.061: ""Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)"". [22] 3GPPÊTSÊ32.298: ""Charging Management; CDR parameter description"". [23] 3GPPÊTSÊ32.422: ""Telecommunication management; Subscriber and equipment trace; Trace control and configuration management"". [24] 3GPPÊTSÊ29.002: ""Mobile Application Part (MAP) specification"". [25] 3GPPÊTSÊ29.329: ""Sh Interface based on the Diameter protocol"". [26] IETFÊRFCÊ5447: ""Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction"". [27] IETFÊRFCÊ4004: ""Diameter Mobile IPv4 Application"". [28] 3GPP2 A.S0022: ""Interoperability Specification (IOS) for Evolved High Rate Packet Data (eHRPD) Radio Access Network Interfaces and Interworking with Enhanced Universal Terrestrial Radio Access Network (E-UTRAN)"". [29] 3GPPÊTSÊ23.011: ""Technical realization of Supplementary Services - General Aspects"". [30] 3GPPÊTSÊ23.008: ""Organization of subscriber data"". [31] 3GPPÊTSÊ24.008: ""Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"". [32] IETFÊRFCÊ5516: ""Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)"". [33] 3GPPÊTSÊ32.251: ""Telecommunication management; Charging management; Packet Switched (PS) domain charging"". [34] 3GPPÊTSÊ23.292: ""IP Multimedia Subsystem (IMS) centralized services "". [35] 3GPPÊTSÊ23.216: ""Single Radio Voice Call Continuity (SRVCC)"". [36] 3GPPÊTSÊ23.015:""Technical realization of Operator Determined Barring (ODB)"". [37] 3GPPÊTSÊ29.173: ""Diameter-based SLh interface for Control Plane LCS"". [38] 3GPPÊTSÊ29.303: ""Domain Name System Procedures; Stage 3"". [39] 3GPPÊTSÊ29.060: ""General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface"". [40] 3GPPÊTSÊ36.300: ""Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2"". [41] ITU-TÊRecommendationÊE.164: ""The international public telecommunication numbering plan"". [42] 3GPPÊTSÊ22.042: ""Network Identity and TimeZone (NITZ); Service description; Stage 1"". [43] 3GPPÊTSÊ23.007: ""Restoration procedures"". [44] 3GPPÊTSÊ23.272: ""Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2"". [45] 3GPPÊTSÊ29.010: ""Information element mapping between Mobile Station - Base Station System (MS - BSS) and Base Station System - Mobile-services Switching Centre (BSS - MSC)"". [46] 3GPPÊTSÊ29.118: ""Mobility Management Entity (MME) ÐVisitor Location Register (VLR)SGs interface specification "". [47] 3GPPÊTSÊ29.172: ""Evolved Packet Core (EPC) LCS Protocol (ELP) between the Gateway Mobile Location Centre (GMLC) and the Mobile Management Entity (MME)"". [48] 3GPPÊTSÊ29.338: ""Diameter based protocols to support Short Message Service (SMS) capable Mobile Management Entities (MMEs)"". [49] 3GPPÊTSÊ29.344: ""Proximity-services (ProSe) Function to Home Subscriber Server (HSS) aspects; Stage 3"". [50] IETFÊRFCÊ7683: ""Diameter Overload Indication Conveyance"". [51] 3GPPÊTSÊ23.380: ""IMS Restoration Procedures"". [52] 3GPPÊTSÊ22.153: ""Multimedia Priority Service"". [53] 3GPPÊTSÊ23.221: ""Architectural requirements"". [54] 3GPPÊTSÊ29.336: ""Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications"". [55] 3GPPÊTSÊ23.682: ""Architecture enhancements to facilitate communications with packet data networks and applications "". [56] 3GPPÊTSÊ29.217: ""Congestion reporting over Np reference point"". [57] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [58] 3GPPÊTSÊ43.020: ""Security related network functions"". [59] 3GPPÊTSÊ29.273: ""Evolved Packet System (EPS); 3GPP EPS AAA interfaces"". [60] IETFÊRFCÊ8583: ""Diameter Load Information Conveyance"". [61] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [62] 3GPPÊTSÊ36.331: ""Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification"". [63] 3GPPÊTSÊ29.128: ""Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) interfaces for interworking with packet data networks and applications"". [64] 3GPPÊTSÊ24.301: ""Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3"". [65] 3GPPÊTSÊ36.423: ""Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP)"". [66] 3GPPÊTSÊ29.503: ""Unified Data Management Services"". [67] 3GPPÊTSÊ23.502: ""Procedures for the 5G System; Stage 2"". [68] 3GPP TSÊ23.287: ""Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services"". [69] 3GPPÊTSÊ23.501: ""System Architecture for the 5G System; Stage 2"". [70] 3GPPÊTSÊ29.563: ""5G System; Home Subscriber Server (HSS) services for interworking with Unified Data Management (UDM); Stage 3"". [71] GSMAÊPRDÊIR.73: ""Steering of Roaming Implementation Guidelines"". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in 3GPPÊTRÊ21.905Ê[1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPPÊTRÊ21.905Ê[1]. CSG subscription data from CSS: It identifies the CSG subscription data that a MME or a SGSN has received from a CSS for a subscriber identified by its IMSI."
"CSG subscription data from HSS: It identifies the CSG subscription data that a MME or a SGSN has received from a HSS for a subscriber identified by its IMSI. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TRÊ21.905Ê[1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TRÊ21.905Ê[1]. AVP Attribute Value Pair C Conditional CSS CSG Subscriber Server DCN Dedicated Core Network DRMP Diameter Routing Message Priority DSCP Differentiated Services Code Point EIR Equipment Identity Register ESM EPS Session Management HSS Home Subscriber Server IAB Integrated Access and Backhaul IE Information Element LAA Licensed Assisted Access LWA LTE/WLAN Aggregation LWIP LTE/WLAN Radio Level Integration with IPsec Tunnel M Mandatory MME Mobility Management Entity NR New Radio O Optional ODB Operator Determined Barring SCEF Service Capability Exposure Function URRP-MME User Reachability Request Parameter for MME URPP-SGSN User Reachability Request Parameter for SGSN 4 General Description This document describes the S6a/S6d and S13/S13' interfaces related procedures, message parameters and protocol specifications. The procedures, message parameters and protocol are similar between S6a and S6d. S6a is used for location changes of the MME, while S6d is for location changes of the SGSN. Refer to clauseÊ5 for the differences, especially clauseÊ5.2.1. The procedures, message parameters and protocol are identical as for the S13 and S13'. See clauseÊ6 for details. In the tables that describe the Information Elements transported by each Diameter command, each Information Element is marked as (M) Mandatory, (C) Conditional or (O) Optional in the ""Cat."" column. For the correct handling of the Information Element according to the category type, see the description detailed in clauseÊ6 of the 3GPPÊTSÊ29.228Ê[17]. 5 MME Ð HSS (S6a) and SGSN Ð HSS (S6d) 5.1 Introduction The S6a interface enables the transfer of subscriber related data between the MME and the HSS as described in the 3GPPÊTSÊ23.401Ê[2]. The S6d interface enables the transfer of subscriber related data between the SGSN and the HSS as described in 3GPPÊTSÊ23.060Ê[12]. 5.2 Mobility Services 5.2.1 Location Management Procedures 5.2.1.1 Update Location 5.2.1.1.1 General The Update Location Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to update location information in the HSS. The procedure shall be invoked by the MME or SGSN and is used: - to inform the HSS about the identity of the MME or SGSN currently serving the user, and optionally in addition; - to update MME or SGSN with user subscription data; subscription data that are applicable to MMEs but not to SGSNs should not be sent to the SGSN unless the SGSN is known to be a combined MME/SGSN; similarly subscription data that are applicable to SGSNs but not to MMEs should not be sent to the MME unless the MME is known to be a combined MME/SGSN. - to provide the HSS with other user data, such as Terminal Information or UE SRVCC Capability. This procedure is mapped to the commands Update-Location-Request/Answer (ULR/ULA) in the Diameter application specified in clause 7. Table 5.2.1.1.1/1 specifies the involved information elements for the request. Table 5.2.1.1.1/2 specifies the involved information elements for the answer. Table 5.2.1.1.1/1: Update Location Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Terminal Information (See 7.3.3) Terminal-Information O This information element shall contain information about the user's mobile equipment. Within this Information Element, only the IMEI and the Software-Version AVPs shall be used on the S6a/S6d interface. ULR Flags (See 7.3.7) ULR-Flags M This Information Element contains a bit mask. See 7.3.7 for the meaning of the bits. Visited PLMN Id (See 7.3.9) Visited-PLMN-Id M This IE shall contain the MCC and the MNC, see 3GPPÊTSÊ23.003Ê[3]. It may be used to apply roaming based features. Equivalent PLMN List (See 7.3.151) Equivalent-PLMN-List O This Information Element shall contain the equivalent PLMN list of which the MME/SGSN requests the corresponding CSG Subscription data. RAT Type (See 7.3.13) RAT-Type M This Information Element contains the radio access type the UE is using. See clauseÊ7.3.13 for details. SGSN number (See 7.3.102) SGSN-Number C This Information Element contains the ISDN number of the SGSN, see 3GPPÊTSÊ23.003Ê[3]. It shall be present when the message is sent on the S6d interface and the SGSN supports LCS (using MAP based Lg interface) or SMS functionalities or the Gs interface. It may be present when the message is sent on the S6a interface and the requesting node is a combined MME/SGSN. Homogeneous Support of IMS Voice Over PS Sessions Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions O This Information Element, if present, indicates whether or not ""IMS Voice over PS Sessions"" is supported homogeneously in all TAs or RAs in the serving node (MME or SGSN or combined MME/SGSN). The value ""SUPPORTED"" indicates that there is support for ""IMS Voice over PS Sessions"" in all TAs or RAs. The value ""NOT_SUPPORTED"" indicates that theres is not support for ""IMS Voice over PS Sessions"" in any of the TAs or RAs. V-GMLC address GMLC-Address C This Information Element shall contain, if available, the IPv4 or IPv6 address of the V-GMLC associated with the serving node. Active APN Active-APN O This Information Element, if present, contains the list of active APNs stored by the MME or SGSN, including the identity of the PDN GW assigned to each APN. For the case of explicitly subscribed APNs, the following information shall be present: - Context-Identifier: context id of subscribed APN in use - Service-Selection: name of subscribed APN in use - MIP6-Agent-Info: including PDN GW identity in use for subscribed APN - Visited-Network-Identifier: identifies the PLMN where the PDN GW was allocated For the case of the Wildcard APN, the following information shall be present: - Context-Identifier: context id of the Wildcard APN - Specific-APN-Info: list of APN-in use and related PDN GW identity when the subscribed APN is the wildcard APN It may be present when MME or SGSN needs to restore PDN GW data in HSS due to a Reset procedure. UE SRVCC Capability UE-SRVCC-Capability C This information element shall indicate if the UE supports or does not support the SRVCC capability and shall be present if the MME or the SGSN supports SRVCC and this information is available to the MME or the SGSN. MME Number for MT SMS MME-Number-for-MT-SMS C This Information Element contains the ISDN number of the MME to route SMS to the UE through the MME, see 3GPPÊTSÊ23.003Ê[3]. It shall be present when the MME supports SMS in MME and wishes to provide SMS in MME. SMS Register Request SMS-Register-Request C This information element is used to inform the HSS if the MME or the SGSN needs to be registered for SMS, prefers not to be registered for SMS or has no preference. It shall be present when the MME supports SMS in MME and requests to be registered for SMS. It shall be present when the SGSN supports ""SMS in SGSN"" as defined in clauseÊ5.3.18 in 23.060Ê[12], and requests to be registered for SMS. SGs MME identity SGs-MME-Identity O This information element is used to inform the HSS of the MME identity that the MME will use over the SGs interface. This information element shall be present, if the MME supports this information element and if the MME identity used over SGs is different from the MME Diameter identity used over S6a. Coupled node's Diameter identity Coupled-Node-Diameter-ID O This information element contains the Diameter identity of the coupled node (i.e. MME's Diameter identity for the SGSN and SGSN's Diameter identity for the MME) when the message is sent by the combined MME/SGSN. This information element may be present when the message is sent on the S6a/S6d interface and the requesting node is a combined MME/SGSN. Adjacent PLMNs Adjacent-PLMNs O This information element, if present, shall contain the list of PLMNs where an UE served by the MME/SGSN is likely to make a handover from the PLMN where the MME/SGSN is located. This list is statically configured by the operator in the MME/SGSN, according to the geographical disposition of the different PLMNs in that area, the roaming agreements, etc... Supported Services (3GPPÊTSÊ29.336Ê[54]) Supported-Services O If present, this Information Element shall contain AVPs indicating details of the services supported by the MME/SGSN. Table 5.2.1.1.1/2: Update Location Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable: - User Unknown - Unknown EPS Subscription - RAT Not Allowed - Roaming Not Allowed Error-Diagnostic Error-Diagnostic O If the Experimental Result indicates ""Unknown EPS Subscription"", Error Diagnostic may be present to indicate whether or not GPRS subscription data are subscribed (i.e. whether or not Network Access Mode stored in the HSS indicates that only circuit service is allowed). If the Experimental Result indicates ""Roaming Not Allowed"", and the Update Location is rejected due to ODB, Error Diagnostic may be present to indicate the specific type of ODB. ULA-Flags (See 7.3.8) ULA-Flags C This Information Element contains a bit mask. See 7.3.8 for the meaning of the bits. It shall be present only when the Result-Code AVP is DIAMETER_SUCCESS. Subscription Data (See 7.3.2) Subscription-Data C This Information Element shall contain the complete subscription profile of the user. It shall be present if success is reported, unless an explicit ""skip subscriber data"" indication was present in the request. Reset-IDs (See 7.3.184) Reset-ID O The Reset-ID uniquely identifies a fallible resource in the HSS on which the user (IMSI) depends. In the event of a restart of the fallible resource a Reset message containing the Reset-ID will exactly identify the impacted subscribers. 5.2.1.1.2 Detailed behaviour of the MME and the SGSN The MME shall make use of this procedure to update the MME identity stored in the HSS (e.g. at initial attach, inter MME tracking area update or radio contact after HSS reset). The SGSN shall make use of this procedure to update the SGSN identity stored in the HSS (e.g. at initial attach, inter SGSN routing area update or radio contact after HSS reset). The MME shall make use of this procedure to request SMS data and to become registered for SMS. The SGSN shall make use of this procedure to request to become registered for SMS. A combined MME/SGSN which uses different Diameter Identities for the MME and SGSN parts shall not send a second ULR when in a first ULA the ULA-Flag ""Separation Indication"" was not set. For UEs receiving emergency services, in which the UE was not successfully authenticated, the MME or SGSN shall not make use of the Update Location procedure. If the Update Location request is to be sent due to an inter node (SGSN to MME) update and the previous SGSN is a Gn/Gp SGSN, the MME shall set the ""Single-Registration-Indication"" flag in the ULR-Flags information element in the request. If the Update Location request is to be sent due to an initial attach, the MME or SGSN shall set the ""Initial-Attach-Indicator"" flag in the ULR-Flags information element in the request. If the Update Location request is sent due to a Tracking Area Update following intra-PLMN inter-MME or AMF to MME handover, then the MME may set the Intra-PLMN-inter-MME handover flag in the ULR-Flags information element in the request. If the Update Location request is sent due to a Tracking Area Update following inter-PLMN inter-MME or AMF to MME handover, then the MME may set the Inter-PLMN-inter-MME handover flag in the ULR-Flags information element in the request. In order to avoid handovers failing (including the cases of emergency and non-emergency EPS fallback voice handovers), the Intra-PLMN-inter-MME handover flag and Inter-PLMN-inter-MME handover flags are required if the HPLMN deploys Steering of Roaming functionality that interferes with the Diameter signalling procedures e.g. as described in the sectionÊ6.1 of GSMAÊPRDÊIR.73Ê[71]. Otherwise, these flags are left to be configured based on operator policy. NOTE 0: It is useful if the HPLMN discloses how they do Steering of Roaming to the VPLMN. The VPLMN can be configured to comply if they support this feature in the MME. When receiving and supporting Reset-ID AVPs in the response, the MME or SGSN shall delete all the stored Reset-IDs, if there are any, and then store all the received Reset-IDs. A combined MME/SGSN shall set the ""Skip Subscriber Data"" flag in the ULR-Flags if subscriber data are already available due to a previous identical location update. Otherwise the MME/SGSN shall not set the ""Skip Subscriber Data"" flag in the ULR-Flags. A combined MME/SGSN that has advertised its support for the combined MME/SGSN capability, by either including the SGSN Number within ULR sent over S6a or including the Coupled-Node-Diameter-ID within ULR sent over S6a/S6d or by using same Diameter identity over S6a and S6d interfaces, shall be prepared to receive a single subscription data update message (IDR or DSR) from the HSS when the subscription data is modified. If the MME or SGSN knows about the homogeneity of the support of IMS Voice over PS Sessions in all TAs or RAs associated to that serving node (i.e., it is supported in all the TA/RAs or it is not supported in any of the TA/RAs) and for the serving subscriber taking into account roaming relationship for IMS Voice over PS Sessions, it shall include this indication to the HSS in the ""Homogeneous Support of IMS Voice over PS Sessions"" IE. The MME or SGSN may include dynamic APN and PGW ID data in the list of Active-APN AVPs, in order to restore this information in the HSS after a Reset procedure. The MME/SGSN may include an equivalent PLMN list to request the CSG Subscription data of the equivalent PLMNs. A standalone MME shall not indicate its support for any SGSN specific features, and it shall not request explicitly the download of GPRS data (via the GPRS-Subscription-Data-Indicator flag; see clauseÊ7.3.7). A standalone MME that does not support the ""SMS in MME"" feature shall not provide its MME Number for MT SMS, ""SMS only"" indication or SMS Registration Request and therefore not indicate its support for any SMS related features (such as ODB or barring services). For an SGSN, if a DIAMETER_ERROR_CAMEL_SUBSCRIPTION_PRESENT is received, the SGSN shall initiate the update location procedure with MAP over Gr interface and use Gr for the subsequent mobility procedures. For a standalone MME or SGSN, if EPS or GPRS subscription data is received, the standalone MME or SGSN shall replace all of the EPS or GPRS subscription data of the user in the MME or SGSN. Any optional EPS or GPRS data not received, but stored in the standalone MME or SGSN, shall be deleted. For a combined MME/SGSN, if EPS subscription data of the user is received, it shall replace all of the EPS subscription data of the user. Any optional EPS data not received by the combined MME/SGSN, but stored in the MME/SGSN, shall be deleted. For a combined MME/SGSN, if GPRS subscription data of the user is received, it shall replace all of the GPRS subscription data of the user. Any optional GPRS data not received by the combined MME/ SGSN, but stored in the MME/SGSN, shall be deleted. When receiving an Update Location response from the HSS, the MME or SGSN shall check the result code. If it indicates success the MME or SGSN shall store the received subscription profile (if any), and it shall store the HSS identity as received in the Origin-Host AVP. If an Additional MSISDN (A-MSISDN) is available in the subscription data and downloaded in the A-MSISDN AVP to the MME/SGSN in an Update Location and if the MME or SGSN supports the additional MSISDN feature, the MME or SGSN shall use the Additional MSISDN as C-MSISDN. For UEs receiving emergency services (i.e. emergency attached UEs or normal attached UEs with a UE Requested PDN Connection for emergency services), and if the MME or SGSN supports emergency services for users in limited service state, the MME or SGSN shall proceed even if the Update Location procedure fails (e.g. authenticated users with roaming restrictions or RAT-Type restrictions in HSS). When receiving GPRS-Subscription-Data AVP in the response, the SGSN or combined MME/SGSN shall delete all the stored PDP-Contexts, if there are any, and then store all the received PDP-Contexts. When receiving the APN-Configuration-Profile AVP in a ULA, the MME or SGSN shall delete all the stored APN-Configurations, if there are any, and then store all the received APN-Configurations. For each of the received APN-Configurations in the APN-Configuration-Profile, if both the MIP6-Agent-Info and the PDN-GW-Allocation-Type AVPs are absent in the APN-Configuration AVP and the MME or SGSN does not have any associated PGW information, the MME or SGSN shall perform the PGW selection (static or dynamic) according to the local configuration. If MIP6-Agent-Info is present, and PDN-GW-Allocation-Type is not present, this means that the PDN GW address included in MIP6-Agent-Info has been statically allocated. If the MIP6-Agent-Info contains an FQDN of the PDN GW, the MME shall retrieve the PGW PLMN ID from the MIP-Home-Agent-Host AVP within the MIP6-Agent-Info AVP. When receiving an Update Location response from the HSS in the TAU or RAU procedure, for each of the received APN-Configurations in the APN-Configuration-Profile, if both the MIP6-Agent-Info and the PDN-GW-Allocation-Type AVPs are absent in the APN-Configuration AVP and the MME or SGSN has associated PGW information and the UE-level access restriction ""HO-To-Non-3GPP-Access Not Allowed"" is not set, the MME or SGSN should send a Notify Request if HO to the WLAN is supported in the network, including the APN and PDN GW identity to the HSS in order to restore this information in the HSS e.g. after a Reset procedure. If the MME/SGSN supports interworking with Gn/Gp-SGSNs, it shall ensure that the Context -Identifier sent over GTPv1 for each of the received APN-Configurations is within the range of 1 and 255. NOTE 1: If the MME/SGSN receives from HSS a Context-Identifier value higher than 255, how this value is mapped to a value between 1 and 255 is implementation specific. If the subscriber is not roaming and the SIPTO-Permission information for an APN is present, the MME or SGSN shallÊallow SIPTO above RAN for that APNÊonly if the SIPTO-Permission information indicates so. If the subscriber is not roaming and the SIPTO-Permission information for an APN is not present, the MME or SGSNÊmay allow SIPTO above RAN for that APN. If the subscriber is roaming and the SIPTO-Permission information for an APN is present, the MME or SGSN shall allow SIPTO above RAN for that APN only if the SIPTO-Permission information indicates so and the VPLMN Dynamic Address is allowed and the MME or SGSN selects a PDN GW in the VPLMN. If the subscriber is roaming and the SIPTO-Permission information for an APN is not present, the MME or SGSN shall not allow SIPTO above RAN for that APN. NOTE 2: Based on local configuration, the MME or SGSN can determine not to allow SIPTO above RAN for an APN,Êregardless if the SIPTO-Permission information is present. If the subscriber is not roaming and the SIPTO-Local-Network-Permission information for an APN is present, the MME or SGSN shall allow SIPTO at the local network for that APNÊonly if the SIPTO-Local-Network-Permission information indicates so. If the subscriber is not roaming and the SIPTO-Local-Network-Permission information for an APN is not present, the MME or SGSN may allow SIPTO at the local network for that APN. If the subscriber is roaming and the SIPTO-Local-Network-Permission information for an APN is present, the MME or SGSN shall allow SIPTO at the local network for that APN only if the SIPTO-Local-Network-Permission information indicates so and the VPLMN Dynamic Address is allowed and the MME or SGSN selects a L-GW in the VPLMN. If the subscriber is roaming and the SIPTO-Local-Network-Permission information for an APN is not present, the MME or SGSN shall not allow SIPTO at the local network for that APN. NOTE 3: Based on local configuration, the MME or SGSN can determine not to allow SIPTO at the local network for an APN,Êregardless if the SIPTO-Local-Network-Permission information is present. If MPS-Priority AVP is present and the UE is subscribed to the eMLPP or 1x RTT priority service in the CS domain as indicated by the MPS-CS-Priority bit of the AVP, the MME shall allow the UE to initiate the RRC connection with higher priority than other normal UEs during CS Fallback procedure. If the MPS-Priority AVP is present and the UE is subscribed to MPS in the EPS domain as indicated by the MPS-EPS-Priority bit of the AVP, the MME shall allow the UE to initiate the RRC connection with higher priority than other normal UEs. If the subscriber is not roaming, the MME or SGSN may allow or prohibit the UE to use LIPA as indicated by LIPA-Permission for a specific APN. If the subscriber is roaming and the VPLMN-LIPA-Allowed AVP indicates that the UE is not allowed to use LIPA in the VPLMN where the UE is attached, the MME or SGSN shall not provide LIPA for the UE and shall not consider the LIPA-Permission AVP. If the VPLMN-LIPA-Allowed AVP indicates that the UE is allowed to use LIPA in the VPLMN, the MME or SGSN may allow or prohibit the UE to use LIPA as indicated by LIPA-Permission for a specific APN. The VPLMN-Dynamic-Address-Allowed AVP shall not be considered if it is received when the MME or SGSN establishes a PDN connection with LIPA. If the LIPA-Permission information for an APN indicates LIPA only, the MME or SGSN shall only allow LIPA for that APN via the authorized CSGs according to the CSG Subscription Data. If the LIPA-Permission information for an APN indicates LIPA prohibited, the MME or SGSN shall not allow LIPA for that APN. If the LIPA-Permission information for an APN indicates LIPA conditional, the MME or SGSN shall allow non LIPA, and LIPA for that APN via the authorized CSGs according to the CSG Subscription Data. If the LIPA-Permission AVP is not present for a specific APN, the APN shall not be allowed to use LIPA. The LIPA-Permission information for the Wildcard APN shall apply to any APN that is not explicitly present in the subscription data. The SIPTO-Permission information for the Wildcard APN shall apply to any APN that is not explicitly present in the subscription data. The SIPTO-Local-Network-Permission information for the Wildcard APN shall apply to any APN that is not explicitly present in the subscription data. If the subscription data received for a certain APN indicates that the APN was authorized as a consequence of having the Wildcard APN in the user subscription in HSS, then the MME shall not store this APN data beyond the lifetime of the UE session and the MME shall delete them upon disconnection of the UE. If the MME supports the Relay Node functionality (see 3GPPÊTSÊ36.300Ê[40]) and the subscription data indicates that the subscriber is not a relay, the MME shall reject the attach request from a device attempting to attach to EPS as a Relay Node. If a device requests to be attached to EPS as an UE, the MME shall proceed with the attach procedure regardless of the content of the Relay Node Indicator. If trace data are received in the subscriber data, the MME or SGSN shall start a Trace Session. For details, see 3GPPÊTSÊ32.422Ê[23]. If the Ext-PDP-Type AVP is present in the PDP-Context AVP, the SGSN or combined MME/SGSN shall ignore the value of the PDP-Type AVP. If the subscriber is not roaming and the Subscribed-Periodic-RAU-TAU-Timer information is present, the MME or SGSN shall allocate the subscribed value to the UE as periodic RAU or TAU timer. If the subscriber is roaming and the Subscribed-Periodic-RAU-TAU-Timer information is present, the MME or SGSN may use the subscribed periodic RAU/TAU timer value as an indication to decide for allocating a locally configured periodic RAU/TAU timer value to the UE. For a combined MME/SGSN, the node may include the Coupled-Node-Diameter-ID AVP to allow the HSS to determine if the UE is served by the MME and SGSN parts of the same combined MME/SGSN. When the message is sent over S6a interface and if this AVP is included, the MME shall include the Diameter identity of the coupled SGSN which is used by the SGSN over S6d interface. When the message is sent over S6d interface and if this AVP is included, the SGSN shall include the Diameter identity of the coupled MME which is used by the MME over S6a interface. NOTE 4: The Coupled-Node-Diameter-ID AVP allows the HSS to determine if the UE is served by the MME and SGSN parts of the same combined MME/SGSN, when the SGSN number is not available and when Diameter identity of S6a and S6d interfaces of the combined MME/SGSN are not the same. If the MME supports the ""SMS in MME"" feature and the UE has requested a combined EPS/IMSI attach or Combined TA/LA Update (see 3GPPÊTSÊ23.272Ê[44]) and the MME is not currently registered for SMS, the MME requests to be registered for SMS by indicating its MME Number for MT SMS in the request, including the SMS-Register-Request AVP and the SMS-Only-Indication flag set in the ULR-Flags AVP if UE indicates ""SMS only"". If the MME supports the ""SMS in MME"" feature, when receving an EPS attach or a TAU from a UE accessing NB-IoT which requests SMS by indicating ""SMS transfer without Combined Attach"" (see 3GPPÊTSÊ23.401Ê[2]), and if the MME is not currently registered for SMS, the MME requests to be registered for SMS by indicating its MME Number for MT SMS in the request, including the SMS-Register-Request AVP. If the HSS provides the MME with SMS data in the ULA and the ULA-Flags is received with ""MME Registered for SMS"" flag set, the MME shall store this data for providing SMS in MME service and consider itself registered for SMS. If the SGSN supports the ""SMS in SGSN"" feature as specified in 3GPPÊTSÊ23.060Ê[12], clauseÊ5.3.18, and wishes to provide SMS via SGSN it shall set the ""SMS in SGSN"" flag in the Feature-List AVP, and include SMS-Register-Request AVP. If the SGSN supports the Diameter based Gdd interface for SMS in SGSN, it shall set the ""Gdd-in-SGSN"" flag in the Feature-List AVP. If the UE has indicated ""SMS-Only"" this shall be indicated to the HSS setting the SMS-OnlyÐIndication flag in the ULR-Flags AVP. NOTE 5: the setting of the ""SMS in SGSN"" feature bit reflects the ""SMS in SGSN Offered"" as described in stage 2 above. If the SMS-In-SGSN-Allowed-Indication flag is set in the received Subscription-Data-Flags AVP, the SGSN shall store the subscription data for providing SMS in SGSN service. If the subscriber is not roaming and the Restoration-Priority information for a certain APN is present, the MME or SGSN shall consider the subscribed value as the relative priority of the user's PDN connection among PDN connections to the same APN when restoring PDN connections affected by an SGW or PGW failure/restart (see 3GPPÊTSÊ23.007Ê[43]). If the subscriber is roaming and the Restoration-Priority information for a certain APN is present, the MME or SGSN may use the subscribed value as an indication of the relative priority of the user's PDN connection among PDN connections to the same APN based on service level agreements. The MME/SGSN may use a locally configured value as default restoration priority if the Restoration-Priority AVP for a certain APN is not present, or if it is not permitted by service level agreements for an in-bound roamer. If the subscription data received for a certain APN includes WLAN-offloadability AVP, then the MME or SGSN shall determine the offloadability of the UE's PDN Connection(s) to that APN based on subscription data and locally configured policy (e.g. for roaming users or when the subscription data does not include any offloadability indication). NOTE 6: As indicated in clauseÊ7.3.31, if the UE-level access restriction ""HO-To-Non-3GPP-Access Not Allowed"" is set, the offload of PDN Connections to WLAN is not allowed for any APN. If the subscription data received for the user includes the DL-Buffering-Suggested-Packet-Count AVP, then the MME or SGSN should take into account the subscription data, in addition to local policies, to determine whether to invoke extended buffering of downlink packets at the SGW for High Latency Communication. Otherwise, the MME or SGSN shall make this determination based on local policies only. When receiving IMSI-Group-Id AVP(s) within the Subscription-Data AVP, the MME or SGSN shall replace stored IMSI-Group Ids (if any) with the received information rather than add the received information to the stored information. When receiving one or more Monitoring-Event-Configuration AVP(s) in the ULA, the MME or SGSN shall start the detection of the Monitoring events indicated in those AVP(s), if not already started, and shall stop the detection and delete the previous monitoring events (if any) which are not indicated in those AVP(s). If there is a failure when starting the detection (e.g. maximum resources exceeded), the MME or SGSN shall not store the failed configuration(s) and shall send a notification of those events whose configuration have failed, as described in clauseÊ5.2.5.1.2 (NOR/NOA commands). If the Subscription-Data AVP is received in the ULA but it does not contain any Monitoring-Event-Configuration AVP(s), the MME or SGSN shall stop the detection and delete all stored monitoring event configurations (if any). If the MME/SGSN supports Monitoring, the MME/SGSN shall include the Supported-Services AVP with Supported-Monitoring-Events included in the ULR command. If the MME and the UE support Attach without PDN connection (i.e. EMM-REGISTERED without PDN connection) and the PDN-Connection-Restricted flag is set in the received Subscription-Data-Flags AVP, the MME shall not establish any non-emergency PDN connectionand shall tear down any existing non-emergency PDN connection for this user. If the subscription data received for the user includes the Preferred-Data-Mode AVP, for an IP APN configuration or for a non-IP APN configuration with SGi based delivery, then the MME should (if the subscriber is not roaming) or may (if the subscriber is roaming) take into account the subscription data, in addition to local policies and the UE's Preferred Network Behaviour, to determine whether to transmit the traffic associated with this APN over the User Plane and/or over the Control Plane.Otherwise, the MME shall make this determination based on local policies and the UE's Preferred Network Behaviour only. If the MME receives from the HSS an Update Location response containing the Emergency-Info AVP in the Subscription-Data, the MME shall use the PDN-GW identity included in Emergency-Info as the PDN-GW used to establish emergency PDN connections with the emergency APN, for non-roaming authenticated UEs requesting the handover of an emergency PDN connection if the MME is configured to use a dynamic PDN-GW for emergency services for such user. When receiving V2X-Subscription-Data in the ULA, the MME shall determine whether the UE is authorized to use V2X communication over PC5 according to V2X subscription data and UE provided network capability. If the UE is authorized to use V2X communication over PC5, the MME shall store the ""V2X service authorized"" indication together with the UE AMBR used for PC5 interface (i.e. UE-PC5-AMBR), and provide such information to the eNodeB when needed. If the MME/SGSN receives from the HSS an Update Location response without the bit set for ""NR as Secondary RAT"" in the Feature-List AVP, the MME/SGSN, based on local policy, may restrict access for NR as secondary RAT when all relevant entities except HSS supports it. If the MME receives from the HSS an Update Location response containing in the subscription data the Core-Network-Restrictions AVP with the bit ""5GC not allowed"" set, the MME shall restrict mobility towards 5GC. 5.2.1.1.3 Detailed behaviour of the HSS When receiving an Update Location request the HSS shall check whether subscription data exists for the IMSI. If the HSS determines that there is not any type of subscription for the IMSI (including EPS, GPRS and CS subscription data), a Result Code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If the Update Location Request is received over the S6a interface, and the subscriber has not any APN configuration, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. If the Update Location Request is received over S6a, from an MME that does not support the ""Non-IP PDN Type APNs"" feature, and the user's subscripton profile contains only APN configurations of type ""Non-IP"", the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. If the Update Location Request is received over the S6d interface, and the subscriber has neither an APN configuration profile nor GPRS subscription data, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. When sending DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION, an Error Diagnostic information may be added to indicate whether or not GPRS subscription data are subscribed (i.e. whether or not Network Access Mode stored in the HSS indicates that only CS service is allowed). The HSS shall check whether the RAT type the UE is using is allowed for the subscriber in the serving PLMN. If it is not, a Result Code of DIAMETER_ERROR_RAT_NOT_ALLOWED shall be returned. The HSS shall check whether access to EPC is allowed, based on the active Core Network Restrictions of the subscriber. If access to EPC is restricted, a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION shall be returned. The HSS shall check whether roaming is not allowed in the VPLMN due to ODB. If so a Result Code of DIAMETER_ERROR_ROAMING_NOT_ALLOWED shall be returned. When this error is sent due to the MME or SGSN not supporting a certain ODB category, an Error Diagnostic information element may be added to indicate the type of ODB; if this error is sent due to the ODB indicating ""Barring of Roaming"", Error Diagnostic shall not be included. If the Update Location Request is received over the S6d interface and the HSS supports the ""SGSN CAMEL Capability"" feature, and the SGSN indicates support of SGSN CAMEL capability, the HSS shall check if the subscriber has SGSN CAMEL Subscription data. If the subscriber has SGSN CAMEL Subscription data, the HSS shall return a Result Code of DIAMETER_ERROR_CAMEL_SUBSCRIPTION_PRESENT. If the Update Location Request is received over the S6a interface, the HSS shall send a Cancel Location Request with a Cancellation-Type of MME_UPDATE_PROCEDURE (CLR; see clause 7.2.7) to the previous MME (if any) and replace the stored MME-Identity with the received value (the MME-Identity is received within the Origin-Host AVP). The HSS shall reset the ""UE purged in MME"" flag and delete any stored last known MME location information of the (no longer) purged UE. If the ""Single-Registration-Indication"" flag was set in the received request, the HSS shall send a Cancel Location Request with a Cancellation-Type of SGSN_UPDATE_PROCEDURE to the SGSN (MAP Cancel Location), and delete the stored SGSN address and SGSN number. If the ""Initial-Attach-Indicator"" flag was set in the received request, and the ""Single-Registration-Indication"" flag was not set, the HSS shall send a Cancel Location Request with a Cancellation-Type of INITIAL_ATTACH_PROCEDURE (CLR; see clause 7.2.7, or MAP Cancel Location) to the SGSN if there is an SGSN registration. If the Update Location Request is received over the S6d interface, the HSS shall send a Cancel Location Request with a Cancellation-Type of SGSN_UPDATE_PROCEDURE (CLR; see clause 7.2.7, or MAP Cancel Location) to the previous SGSN (if any) and replace the stored SGSN-Identity with the received value (the SGSN-Identity is received within the Origin-Host AVP). The HSS shall reset the ""UE purged in SGSN"" flag and delete any stored last known SGSN location information of the (no longer) purged UE. If the ""Initial-Attach-Indicator"" flag was set in the received request, the HSS shall send a Cancel Location Request with a Cancellation-Type of INITIAL_ATTACH_PROCEDURE (CLR; see clause 7.2.7) to the MME if there is an MME registration. When the HSS receives the Update Location Request, if a 15th digit of the IMEI AVP is received, the HSS may discard the digit. If the Update Location Request includes either the ULR-flag Inter-PLMN-inter-MME or the ULR-flag intra-PLMN-inter-MME, then the HSS may ignore this information. NOTEÊ1: These flags are intended for use by Steering of Roaming functions that are not standardised by 3GPP and which operate by interfering with the Diameter procedures."
"If the Update Location Request includes the list of active APNs, the HSS shall delete all the stored dynamic PDN GW information, if there are any, and then replace them by the PDN GW information received in the list of Active-APN AVPs. If the Update Location Request includes an equivalent PLMN list, the HSS shall return the CSG list (if any) for each equivalent PLMN to the MME with the subscription data, and Visited-PLMN-Id AVP shall be present in the CSG-Subscription-Data AVP to indicate the corresponding PLMN. If there is no equivalent PLMN list received, the HSS may not include Visited-PLMN-Id AVP in the CSG-Subscription-Data AVP, and the CSG-Subscription-Data AVP shall contain the CSG subscription data of the registered PLMN of the MME or the SGSN. If the Update Location Request is received over the S6a interface for a user for which the URRP-MME parameter is set in the HSS, the HSS shall clear the URRP-MME parameter and send an indication to the corresponding Service Related Entities. If the Update Location Request is received over the S6d interface for a user for which the URRP-SGSN parameter is set in the HSS, the HSS shall clear the URRP-SGSN parameter and send an indication to the corresponding Service Related Entities. If no result code has been sent to the MME or SGSN so far, the HSS shall include the subscription data in the ULA command according to the ULR-Flags and the supported/unsupported features of the MME or SGSN, unless an explicit ""skip subscriber data"" indication has been received in the request, and shall return a Result Code of DIAMETER_SUCCESS. When the APN-Configuration-Profile AVP is present in the Subscription-Data AVP sent within a ULA, the AVP shall contain at least the default APN Configuration and a Context-Identifier AVP that identifies the per subscriber's default APN configuration. The default APN Configuration shall not contain the Wildcard APN (see 3GPPÊTSÊ23.003Ê[3], clauseÊ9.2); the default APN shall always contain an explicit APN. The GPRS Subscription data (if available in the HSS) shall only be present in the ULA command if it was indicated by the serving node in the ULR-Flags AVP (see clauseÊ7.3.7), or when the subscription data is returned by a Pre-Rel-8 HSS (via an IWF) or when the Update Location Request is received over the S6d interface and there is no APN configuration profile stored for the subscriber. The HSS shall use the indication received in the GPRS-Subscription-Data-Indicator for future use in the subscriber data update procedures. The HSS shall store the new terminal information and/or the new UE SRVCC capability, if they are present in the request. If the UE SRVCC capability is not present, the HSS shall store that it has no knowledge of the UE SRVCC capability. If the MME/SGSN indicates support of the Additional-MSISDN feature and an additional MSISDN (A-MSISDN) is available in the subscription data, the HSS shall send the provisioned additional MSISDN together with the MSISDN. If the MME/SGSN does not support the Additional-MSISDN feature, the HSS shall populate the MSISDN AVP either with the subscribed MSISDN or the subscribed additional MSISDN based on operator policy and availability. NOTEÊ2: When the MME/SGSN does not support the Additional-MSISDN feature, the MME/SGSN will use the MSISDN from the MSISDN AVP as C-MSISDN. LCS-Info, Teleservice-List and Call-Barring-Info data shall be included according to the list of supported features indicated by the serving node (see clauseÊ7.3.10). If the HSS supports the ""SMS in MME"" feature and receives the indication that the MME supports the ""SMS in MME"" feature and requests to be registered for SMS by including the MME Number for MT SMS, SMS-Register-Request AVP and/or setting the SMS-Only-Indication flag in the ULR-Flags AVP if indicated from the UE, the HSS shall determine if SMS can be provided via the MME as described in 3GPPÊTSÊ23.272Ê[44]. If SMS in MME is accepted the HSS shall register the MME for SMS, store the ""MME number for MT SMS"" as the corresponding MSC number to be used for MT SMS and return an indication of MME registered for SMS in ULA-Flags AVP. If the MME is successfully registered for SMS the HSS shall download the available SMS related subscription data that may comprise SMS teleservice, MSISDN, ODB and barring services for SMS according to supported features. Also, if the user is considered as not reachable (i.e., MNRF flag is set in HSS for that user), and the UE is considered to have free available memory (i.e., MCEF flag is not set in HSS for that user), the HSS shall send a MAP-Alert-Service-Centre message or S6c-Alert-Service-Centre-Request to the SMS-IWMSC (see 3GPPÊTSÊ29.338Ê[48]). If the HSS supports the ""SMS in SGSN"" feature as described in 3GPPÊTSÊ23.060Ê[12], clauseÊ5.3.18 and receives the indication from the SGSN that it supports ""SMS in SGSN"" feature, and SMS-Register-Request AVP and/or the SMS-Only-Indication flag in the ULR-Flags AVP if indicated from the UE, and the PS subscriber data allow for SMS services (e.g. the subscription information indicates ""PS and SMS-Only""), the HSS shall determine if SMS can be provided via the SGSN as described in 3GPPÊTSÊ23.060Ê[12]. If ""SMS in SGSN"" is accepted the HSS shall indicate in the ULA that ""SMS in SGSN"" is allowed to the SGSN and shall handle MT SMS as described in 3GPPÊTSÊ23.060Ê[12], clauseÊ5.3.18. If the HSS supports the ""Gdd-in-SGSN"" feature and receives the indication from the SGSN that it supports the ""Gdd-in-SGSN"" feature, the HSS shall store the information that the SGSN supports the Gdd interface. Also, if the user is considered as not reachable (i.e., MNRG flag is set in HSS for that user), and the UE is considered to have free available memory (i.e., MCEF flag is not set in HSS for that user), the HSS shall send a MAP-Alert-Service-Centre message or S6c-Alert-Service-Centre-Request to the SMS-IWMSC (see 3GPPÊTSÊ29.338Ê[48]). The HSS may use the indication received in the Node-Type-Indicator for future use in the subscriber data update procedures. Subscriber-Status AVP shall be present in the Subscription-Data AVP when sent within a ULA. If the value ""OPERATOR_DETERMINED_BARRING"" is sent, the Operator-Determined-Barring AVP or HPLMN-ODB AVP shall also be present in the Subscription-Data AVP, or vice versa. Access-Restriction-Data AVP shall be present within the Subscription-Data AVP sent within a ULA if at least one of the defined restrictions applies. The AMBR AVP shall be present in the Subscription-Data AVP when the APN-Configuration-Profile AVP is sent within a ULA (as part of the Subscription-Data AVP) and may be present in the Subscription-Data AVP when the GPRS-Subscription-Data AVP is present. The EPS-Subscribed-QoS-Profile AVP and the AMBR AVP shall be present in the APN-Configuration AVP when the APN-Configuration AVP is sent in the APN-Configuration-Profile AVP and when the APN-Configuration-Profile AVP is sent within a ULA (as part of the Subscription-Data AVP). For those APNs that have been authorized as a consequence of having the Wildcard APN in the user subscription, the HSS shall include the specific APN name and associated PDN-GW identity inside the APN context of the Wildcard APN. This indicates to the MME that the particular APN shall not be cached in the MME and it shall be deleted when the UE session is terminated. If a Result Code of DIAMETER_SUCCESS is returned, the HSS shall set the Separation Indication in the response. If the HSS receives an indication in the ULR command about the homogeneous support of IMS Voice over PS Sessions in all TA/RAs associated to a serving node, it may use this information in the future in order to skip the T-ADS data retrieval, as described in clauseÊ5.2.2.1 (IDR/IDA commands). Subscribed-VSRVCC AVP shall be present within the Subscription-Data AVP sent within a ULA only if the user is subscribed to the SRVCC and vSRVCC. If the UE is allowed to use Proximity-based Services in the visited PLMN, the HSS shall include ProSe-Subscription-Data AVP within the Subscription-Data AVP sent within a ULA. If the HSS receives the SGs MME identity and if the HSS supports this information element, the HSS shall store it for use with VLR restoration. If the HSS receives Update Location Request over both the S6a and S6d interfaces then based on the following conditions the HSS concludes if the UE is served by the MME and SGSN parts of the same combined MME/SGSN: - if both the messages contain the same SGSN number; or - if the Diameter identity received over S6a matches with the Diameter identity received over S6d; or - if the Coupled-Node-Diameter-ID AVP received over S6a interface matches with the Diameter identity received within Origin-Host AVP over S6d interface OR if the Coupled-Node-Diameter-ID AVP received over S6d interface matches with the Diameter identity received within Origin-Host AVP over S6a interface. If the HSS supports the handling of access restrictions for adjacent PLMNs, and it receives a list of adjacent PLMNs from the MME/SGSN, the HSS may send the associated Access Restriction Data, according to local operator policies, in the Adjacent-Access-Restriction-Data AVP, so the MME/SGSN can use this information to allow, or prevent, inter-RAT inter-PLMN handovers towards any of the PLMNs indicated by the HSS. The HSS shall not include in the list of Adjacent-Access-Restriction-Data the PLMN-ID, and its access restrictions, of the current PLMN where the MME/SGSN is located, since this information is already conveyed in the Access-Restriction-Data AVP inside the Subscription-Data AVP. If the HSS supports Monitoring events and receives a Supported-Services AVP it shall only trigger those services which are supported by the MME/SGSN. If the HSS has previously received over SWx (see 3GPPÊTSÊ29.273Ê[59]) the identity of the PDN-GW to be used for the establishment of emergency PDN connections, it shall include it as part of the Subscription-Data AVP (in the Emergeny-Info AVP), in the Update Location response to the MME. If the UE is allowed to use V2X service in the visited PLMN and the MME supports V2X service, the HSS shall include V2X-Subscription-Data AVP into Subscription-Data AVP within the ULA command. If the MME/SGSN supports the ""External-Identifier"" feature, the HSS shall include the External-Identifier associated with Monitoring Event Configuration in the External-Identifier AVP if populated in the subscription. When multiple External Identifiers are defined for a same subscription, the HSS shall send a default External Identifier in the External-Identifier AVP of the Subscription-Data AVP, and shall include a specific External Identifier (if different from the default External Identifier) associated to each Monitoring Event Configuration in the External-Identifier AVP of each Monitoring-Event-Configuration AVP occurrence inside the Subscription-Data AVP. The Aerial-UE-Subscription-Information AVP shall be present within the Subscription-Data AVP sent within a ULA only if the user has Aerial UE subscription information. 5.2.1.2 Cancel Location 5.2.1.2.1 General The Cancel Location Procedure shall be used between the HSS and the MME and between the HSS and the SGSN to delete a subscriber record from the MME or SGSN. The procedure shall be invoked by the HSS and is used: - to inform the MME or SGSN about a subscription withdrawal, or a change in the subscriber profile that does not allow PS services anymore (e.g., the Network Access Mode does not allow PS services), or a change in the subscriber profile that does not allow access to EPC anymore, or - to inform the MME or SGSN about an ongoing update procedure i.e. MME or SGSN change or - to inform the MME or SGSN about an initial attach procedure. This procedure is mapped to the commands Cancel-Location-Request/Answer (CLR/CLA) in the Diameter application specified in clause 7. Table 5.2.1.2.1/1 specifies the involved information elements for the request. Table 5.2.1.2.1/2 specifies the involved information elements for the answer. Table 5.2.1.2.1/1: Cancel Location Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Cancellation Type (See 7.3.24) Cancellation-Type M Defined values that can be used are: - MME-Update Procedure, - SGSN-Update Procedure, - Subscription Withdrawal, - Update Procedure_IWF, - Initial Attach Procedure. CLR Flags (See 7.3.152) CLR-Flags O This Information Element contains a bit mask. See 7.3.152 for the meaning of the bits and the condition for each bit to be set or not. Table 5.2.1.2.1/2: Cancel Location Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M The result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). 5.2.1.2.2 Detailed behaviour of the MME and the SGSN When receiving a Cancel Location request the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_SUCCESS is returned. If it is known, the MME or SGSN shall check the Cancellation Type and act accordingly. If the Cancellation Type is ""Subscription Withdrawal"", the MME or SGSN shall delete the subscription data and detach the UE; in addition, if the Reattach-Required flag is set, the MME or SGSN shall indicate to the UE to initiate an immediate re-attach procedure, as described in 3GPPÊTSÊ23.401Ê[2] and 3GPPÊTSÊ23.060Ê[12]. A result code of DIAMETER_SUCCESS shall be returned. If a cancellation type of ""Initial Attach Procedure"" is received, the MME or SGSN shall not delete the subscription data. For details see 3GPPÊTSÊ23.401Ê[2] and 3GPPÊTSÊ23.060Ê[12]. If the MME receives this cancelation type, and it is registered for SMS, it shall consider itself as unregistered for SMS. Also in this case a result code of DIAMETER_SUCCESS shall be returned. When a UE is served by a single combined MME/SGSN for both E-UTRAN and non-E-UTRAN access, the combined MME/SGSN shall check the Cancellation-Type. If it indicates Subscription Withdrawal or Update Procedure_IWF, the CLR is processed both in the MME part and in the SGSN part of the combined node. If it indicates Initial Attach Procedure, and if the CLR-Flags AVP is received and supported by the combined MME/SGSN, the CLR is processed only in the affected part of the combined node as indicated by the ""S6a/S6d-Indicator"" flag in the CLR-Flags AVP. Otherwise, the CLR is processed only in the affected part of the combined node and subscription data are kept for the not affected part. 5.2.1.2.3 Detailed behaviour of the HSS The HSS shall make use of this procedure when the subscription is withdrawn by the HSS operator, and when the HSS detects that the UE has moved to a new MME or SGSN area, and when EPC access is not allowed due to Core Network Restrictions. The HSS+UDM shall also make use of this procedure when the HSS+UDM detects that the UE has moved to a new AMF area, if the AMF indicates to the HSS+UDM to cancel MME and/or SGSN. The HSS+UDM shall include a cancellation type as specified in clauseÊ5.4.2.2 of 3GPP TSÊ29.563Ê[70]. The HSS shall include a cancellation type of ""Subscription Withdrawal"" if the subscription is withdrawn by the operator, or if the subscriber profile does not allow PS services anymore, or if the Core Network Restrictions do not allow access to EPC anymore; the HSS may set the Reattach-Required flag in order to request the MME or the SGSN to trigger an immediate reattachment of the UE. The HSS shall include a cancellation type of ""MME Update Procedure"" if the UE moved to a new MME area. The HSS shall include a cancellation type of ""SGSN Update Procedure"" if the UE moved to a new SGSN area. The HSS shall include a cancellation type of ""Initial Attach Procedure"" if the cancel location is initiated due to an Initial Attach from the UE. The HSS shall include the CLR-Flags with the ""S6a/S6d-Indicator"" flag indicating the affected part of the combined node if the cancel location is to be sent to a combined MME/SGSN during initial attach procedure. 5.2.1.3 Purge UE 5.2.1.3.1 General The Purge UE Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to indicate that the subscriber's profile has been deleted from the MME or SGSN either by an MMI interaction or automatically, e.g. because the UE has been inactive for several days. This procedure is mapped to the commands Purge-UE-Request/Answer (PUR/PUA) in the Diameter application specified in clause 7. Table 5.2.1.3.1/1 specifies the involved information elements for the request. Table 5.2.1.3.1/2 specifies the involved information elements for the answer. Table 5.2.1.3.1/1: Purge UE Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. PUR-Flags (See 7.3.149) PUR-Flags O If present, this Information Element shall contain a bitmask. See clauseÊ7.3.149 for the meaning of the bits. EPS-Location-Information (See 7.3.111) EPS-Location-Information C This Information Element shall contain the last known EPS-Location Information of the purged UE. Shall be present if available. Table 5.2.1.3.1/2: Purge UE Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indication success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable: - User Unknown PUA-Flags (See 7.3.48) PUA-Flags C This Information Element shall contain a bit mask. See clauseÊ7.3.48 for the meaning of the bits. It shall be present only when the Result-Code AVP is DIAMETER_SUCCESS. 5.2.1.3.2 Detailed behaviour of the MME and the SGSN The MME shall make use of this procedure to set the ""UE Purged in the MME"" flag in the HSS when the subscription profile is deleted from the MME database due to MMI interaction or after long UE inactivity. The SGSN shall make use of this procedure to set the ""UE Purged in SGSN"" flag in the HSS when the subscription profile is deleted from the SGSN database due to MMI interaction or after long UE inactivity. The combined MME/SGSN when using a single Origin-Host identity shall make use of this procedure to set the ""UE Purged in MME"" and ""UE Purged in SGSN"" flags in the HSS when the subscription profile is deleted from the common MME/SGSN database due to MMI interaction or after long UE inactivity on all registered accesses. If the HSS has indicated support for the Partial Purge feature (see clauseÊ7.3.10), the combined MME/SGSN may also indicate to the HSS a Purge of the UE in only one of the serving nodes in the combined node (either in the MME or in the SGSN). The combined MME/SGSN when using different Origin-Host identities for MME and SGSN shall send two Purge UE Requests as if it was not combined. When receiving a Purge UE response from the HSS the MME shall check the Result Code. If it indicates success, the MME shall check the PUA flag ""freeze M-TMSI"", and if set freeze the M-TMSI i.e. block it for immediate re-use. When receiving a Purge UE response from the HSS the SGSN shall check the Result Code. If it indicates success, the SGSN shall check the PUA flag ""freeze P-TMSI"", and if set freeze the P-TMSI i.e. block it for immediate re-use. When receiving a Purge UE response from the HSS the combined MME/SGSN shall check the Result Code. If it indicates success, the combined MME/SGSN shall check the PUA flag ""freeze M-TMSI"" and ""freeze P-TMSI"", and if set freeze the M-TMSI and/or the P-TMSI i.e. block it for immediate re-use. 5.2.1.3.3 Detailed behaviour of HSS When receiving a Purge UE request the HSS shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If it is known, the HSS shall set the result code to DIAMETER_SUCCESS and compare the received identity in the Origin-Host with the stored MME-Identity and with the stored SGSN-Identity. If the received identity matches the stored MME-identity and the stored SGSN-Identity (no matter whether the node type indicator bit in ULR-Flags was set or clear), then: - if the HSS supports the Partial Purge feature (see clauseÊ7.3.10), and the combined MME/SGSN indicated that the UE was purged in only one of the serving nodes, the HSS shall set the PUA flags according to the serving node where the purge was done (i.e., either ""freeze M-TMSI"" if the purge was done in the MME, or ""freeze P-TMSI"" if the purge was done in the SGSN); similarly, the HSS shall either set the ""UE purged in MME"" flag and store the received last known MME Location information of the purged UE, or set the ""UE purged in SGSN"" flag and store the received last known SGSN-Location Information of the purged UE, accordingly; - if the HSS does not support the Partial Purge feature, or the combined MME/SGSN did not indicate that the UE was purged in only one of the serving nodes, the HSS shall set the PUA flags ""freeze M-TMSI"" and ""freeze P-TMSI"" in the answer message and set the flag ""UE purged in MME"" and ""UE purged in SGSN"" and store the received last known EPS Location Information of the purged UE; If the received identity matches the stored MME-identity but not the stored SGSN-identity, the HSS shall set the PUA flag ""freeze M-TMSI"" and clear the PUA flag ""freeze P-TMSI"" in the answer message, set the flag ""UE purged in MME"" and store the received last known MME location information of the purged UE; If the received identity matches the stored SGSN-identity but not the stored MME-identity, the HSS shall set the PUA flag ""freeze P-TMSI"" and clear the PUA flag ""freeze M-TMSI"" in the answer message and set the flag ""UE purged in SGSN"" and store the received last known SGSN location information of the purged UE; If the received identity does not match the stored MME-identity and does not match the stored SGSN-identity, the HSS shall clear the PUA flags ""freeze M-TMSI"" and ""freeze P-TMSI in the answer message. 5.2.2 Subscriber Data Handling Procedures 5.2.2.1 Insert Subscriber Data 5.2.2.1.1 General The Insert Subscriber Data Procedure shall be used between the HSS and the MME and between the HSS and the SGSN for updating and/or requesting certain user data in the MME or SGSN in the following situations: - due to administrative changes of the user data in the HSS and the user is now located in an MME or SGSN, i.e. if the user was given a subscription and the subscription has changed; subscription data that are applicable to MMEs but not to SGSNs should not be sent to the SGSN unless the SGSN is known to be a combined MME/SGSN; similarly subscription data that are applicable to SGSNs but not to MMEs should not be sent to the MME unless the MME is known to be a combined MME/SGSN. - the operator has applied, changed or removed Operator Determined Barring for this user; - activate subscriber tracing in the MME or the SGSN; - to indicate to the MME or SGSN that the HSS has requested to be notified when the UE has become reachable; - to request from the MME or SGSN the necessary data to support the T-ADS functionality; - to retrieve location information and/or state information from the MME or the SGSN; - to retrieve from the MME or the SGSN the Local Time Zone of the location in the visited network where the UE is attached; - to update the STN-SR (e.g., as a result of an Sh interaction with an SCC-AS). - to update the MME/SGSN with the identity of a dynamically allocated PDN GW as a result of the first PDN connection establishment associated with an APN over non 3GPP access or 5GS.. - to update the MME with the identity of a PDN GW for Emergency Services as a result of the PDN connection establishment for Emergency Services over non 3GPP access. - to indicate to the MME that the HSS has deregistered the MME for SMS. - to indicate to the MME/SGSN that the HSS-based P-CSCF restoration procedure, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4, shall be executed. - to request the MME or the SGSN to configure and report the detection of Monitoring events, or delete stored Monitoring events configuration. - to update the MME with the O&M configured desired Active Time for power saving mode (PSM), or with the value received from the SCEF if Active Time is provided as part of the Suggested-Network-Configuration AVP. - to update the MME with the O&M configured desired Core Network Restrictions to restrict/allow mobility to 5GC. If the HSS knows that the UE has attached to the MME and SGSN parts of the same combined MME/SGSN via both the E-UTRAN and UTRAN/GERAN (refer to clauseÊ5.2.1.1.2, 5.2.1.1.3 for further details), the HSS should invoke this procedure for a single time to update and/or request certain user data in the combined MME/SGSN, i.e. the HSS should not invoke this procedure for each of the MME and the SGSN registered respectively. If the Node-Type-Indicator information has been previously received as cleared in the ULR-Flags and if the MME has not been registered for SMS during update location procedure for the MME, the HSS may skip any change of the SMS related subscription data and consequently does not have to make use of the Insert Subscriber Data procedure to update the SMS subscription data in the MME. This procedure is mapped to the commands Insert Subscriber Data-Request/Answer (IDR/IDA) in the Diameter application specified in clauseÊ7. Table 5.2.2.1.1/1 specifies the involved information elements for the request. Table 5.2.2.1.1/2 specifies the involved information elements for the answer. Table 5.2.2.1.1/1: Insert Subscriber Data Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Subscription Data (See 7.3.2) Subscription-Data M This Information Element shall contain the part of the subscription profile that either is to be added to the subscription profile stored in the MME or SGSN or is replacing a part of the subscription profile stored in the MME or SGSN. IDR Flags (See 7.3.103) IDR-Flags C This Information Element shall contain a bit mask. See 7.3.103 for the meaning of the bits. Reset-IDs (See 7.3.184) Reset-ID O The Reset-ID uniquely identifies a fallible resource in the HSS on which the user (IMSI) depends. In the event of a restart of the fallible resource a Reset message containing the Reset-ID will exactly identify the impacted subscribers. Table 5.2.2.1.1/2: Insert Subscriber Data Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. A combined MME/SGSN that makes use of separate origin host values in Update Location Request messages sent on S6a and Update Location Request messages sent on S6d can detect whether the IDR from HSS was sent to the MME or to the SGSN. IDA sent from such combined MME/SGSN corresponds to the MME's or the SGSN's supported features respectively. A combined MME/SGSN that makes use of a common origin host value in Update Location Request messages sent on S6a and Update Location Request messages sent on S6d cannot detect whether the IDR from HSS was sent to the MME or to the SGSN. IDA sent from such combined MME/SGSN uses the union of the MME's and the SGSN's supported features. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. Result-Code AVP shall be used to indicate success / errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown IMS Voice over PS Sessions Supported (See 7.3.106) IMS-Voice-Over-PS-Sessions-Supported C If available to the serving node, this information element shall indicate whether or not ""IMS Voice over PS Sessions"" is supported by the UE's most recently used TA or RA in the serving node (MME or SGSN or combined MME/SGSN). If the UE is in detached state, this information element shall not be included in the response. Last UE Activity Time (See 7.3.108) Last-UE-Activity-Time C If available to the serving node, this information element shall contain the time of the last radio contact with the UE. If the UE is in detached state, this information element shall not be included in the response. RAT Type (See 7.3.13) RAT-Type C If available to the serving node, this information element shall indicate the RAT Type of the access where the UE was present at the time of the last radio contact. If the UE is in detached state, this information element shall not be included in the response. IDA-Flags (See 7.3.47) IDA-Flags C This Information Element shall contain a bit mask. See 7.3.47 for the meaning of the bits. EPS-User-State (See 7.3.110) EPS-User-State C This Information Element shall contain the EPS-User State. It shall be present if EPS user state was requested within IDR. EPS-Location-Information (See 7.3.111) EPS-Location-Information C This Information Element shall contain the EPS-Location Information. It shall be present if EPS location information was requested within IDR. Local Time Zone (See 7.3.156) Local-Time-Zone C This Information Element shall contain information on the Local Time Zone of the location in the visited network where the UE is attached. It shall be present if the Local Time Zone was requested within IDR. Monitoring Event Report Monitoring-Event-Report C This Information Element shall contain the report of Monitoring event. It shall be present if Monitoring event configuration is included within IDR and any of the requested Monitoring events are available to be reported. (see NOTE 1) Monitoring Event Config Status Monitoring-Event-Config-Status C This Information Element shall be present if Monitoring event configuration is included in IDR. It shall contain all the configuration status for each Monitoring event that was requested. Supported Services (3GPPÊTSÊ29.336Ê[54]) Supported-Services O If present, this Information Element shall contain AVPs indicating details of the services supported by the MME/SGSN. NOTE 1: In IWK-SCEF scenarios, an event is available to be reported by the visited MME only if the event is considered as authorized by the visited MME after checking with the IWK-SCEF. Otherwise, the immediate report shall be not be sent in this command (S6a/IDA), and it shall be sent over T6a using RIR command (see 3GPPÊTSÊ29.128Ê[63]. 5.2.2.1.2 Detailed behaviour of the MME and the SGSN When receiving an Insert Subscriber Data request the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If it is known, the MME or SGSN shall replace the specific part of the stored subscription data with the received data, or shall add the received data to the stored data. When receiving the APN-Configuration-Profile AVP within the Subscription-Data AVP, the MME or SGSN shall check the All-APN-Configurations-Included-Indicator value. If it indicates ""All_APN_CONFIGURATIONS_INCLUDED"", the MME or SGSN shall delete all stored APN-Configurations and then store all received APN-Configurations. Otherwise, the MME or SGSN shall check the Context-Identifier value of each received APN-Configuration. If the Context-Identifier of a received APN-Configuration matches a Context-Identifier of a stored APN-Configuration, the MME or SGSN shall replace the stored APN-Configuration with the received APN-Configuration. If the Context-Identifier of a received APN-Configuration does not match a Context-Identifier of a stored APN-Configuration, the MME or SGSN shall add the received APN-Configuration to the stored APN-Configurations. If the addition or update of the subscription data succeeds in the MME or SGSN, the Result-Code shall be set to DIAMETER_SUCCESS. The MME or SGSN shall then acknowledge the Insert Subscriber Data message by returning an Insert Subscriber Data Answer. For each of the received APN-Configurations in the APN-Configuration-Profile, if both the MIP6-Agent-Info and the PDN-GW-Allocation-Type AVPs are absent in the APN-Configuration AVP, the MME or SGSN shall perform the PGW selection (static or dynamic) according to the local configuration. If MIP6-Agent-Info is present, and PDN-GW-Allocation-Type is not present, this means that the PDN GW address included in MIP6-Agent-Info has been statically allocated. If the MME/SGSN supports interworking with Gn/Gp-SGSNs, it shall ensure that the context identifier sent over GTPv1 for each of the received APN-Configurations is within the range of 1 and 255. NOTE 1: If the MME/SGSN receives from HSS a Contex-Identifier value higher than 255, how this value is mapped to a value between 1 and 255 is implementation specific. If the MME is requested to notify the HSS when the UE becomes reachable, the MME shall set the URRP-MME parameter to indicate the need to inform the HSS about UE reachability, e.g. when the next NAS activity from the UE is detected. If the SGSN is requested to notify the HSS when the UE becomes reachable, the SGSN shall set the URRP-SGSN parameter to indicate the need to inform the HSS about UE reachability, e.g. when the next NAS activity from the UE is detected. When receiving GPRS-Subscription-Data AVP within the Subscription-Data AVP, the SGSN or combined MME/SGSN shall check the Complete-Data-List-Included-Indicator value. If it indicates ""All_PDP_CONTEXTS_INCLUDED"", the SGSN or combined MME/SGSN shall delete all stored PDP-Contexts and then store all received PDP-Contexts. Otherwise, the SGSN or combined MME/SGSN shall check the Context-Identifier value of each received PDP-Context. If the Context-Identifier of a received PDP-Context matches a Context-Identifier of a stored PDP-Context, the SGSN or combined MME/SGSN shall replace the stored PDP-Context with the received PDP-Context. If the Context-Identifier of a received PDP-Context does not match a Context-Identifier of a stored PDP-Context, the SGSN or combined MME/SGSN shall add the received PDP-Context to the stored PDP-Contexts. If the MME or SGSN receives an empty Subscription-Data AVP, it shall take no action with regard to the stored subscription data. When receiving HPLMN-ODB AVP within the Subscription-Data AVP, the MME or SGSN shall replace stored HPLMN-ODB data (if any) with the received information rather than add the received information to the stored information. Unsupported Barring categories need not be stored. When receiving Operator-Determined-Barring AVP within the Subscription-Data AVP, the MME or SGSN shall replace stored ODB subscription information (if any) with the received information rather than add the received information to the stored information. Unsupported Barring categories need not be stored. When receiving Access-Restriction-Data or Adjacent-Access-Restriction-Data AVPs within the Subscription-Data AVP, the MME or SGSN shall replace the corresponding stored information (if any) with the new received information, rather than adding received information to stored information. The handling of access restrictions per-PLMN is defined in 3GPPÊTSÊ23.221Ê[53], clauseÊ6.3.5a and in 3GPPÊTSÊ23.401Ê[2] clauseÊ4.3.28. When receiving APN-OI-Replacement AVP within the Subscription-Data AVP, the MME or SGSN shall replace the stored information (if any) with the received information. When receiving Regional-Subscription-Zone-Code AVP within the Subscription-Data AVP, the MME or SGSN shall replace stored Zone Codes (if any) with the received information rather than add the received information to the stored information. MMEs and SGSNs that do not support regional subscription need not store zone codes. If due to regional subscription restrictions or access restrictions the entire SGSN area is restricted, SGSN shall report it to the HSS by returning the ""SGSN Area Restricted"" indication within the IDA flags. When receiving CSG-Subscription-Data AVPs within the Subscription-Data AVP the MME or SGSN shall replace all stored information from previously received CSG-Subscription-Data AVPs (if any) with the received information rather than add the received information to the stored information. When receiving Teleservice-List AVP, Call-Barring-Info, or LCS-Info AVP, the MME or SGSN shall replace stored information (if any) with the received information rather than add the received information to the stored information. When receiving ProSe-Subscription-Data AVP, the MME or combined MME/SGSN shall replace stored information (if any) with the received information rather than add the received information to the stored information. When receiving and supporting Reset-ID AVPs within the request, the MME or SGSN shall replace stored information (if any) with received information rather than add received information to stored information."
"When receiving the IDR-Flags with the ""T-ADS Data Request"" bit set, and the UE is in attached state, the MME or SGSN or combined MME/SGSN shall return in the IDA message the time stamp of the UE's most recent radio contact and the associated RAT Type, and an indication of whether or not IMS Voice over PS is supported in the current (and most recently used) TA or RA. If the UE is in detached state, the MME or SGSN or combined MME/SGSN shall answer successfully to the T-ADS request from HSS, but it shall not include any of the T-ADS IEs in the response (IMS Voice over PS Sessions Supported, RAT Type and Last UE Activity Time). When receiving the IDR-Flags with the ""EPS User State Request"" bit and/or ""EPS Location Information Request"" bits set the MME or SGSN shall return the corresponding user information to the HSS. If the serving node is a combined MME/SGSN, and the UE is attached via both E-UTRAN and UTRAN/GERAN on the same node, the combined MME/SGSN shall provide the corresponding user information relevant for both MME and SGSN. If the Current Location Request bit was also set and the UE is in idle mode and is expected to be reachable even when it uses a power saving feature (e.g. extended idle mode DRX or PSM as defined in 3GPPÊTSÊ23.685Ê[55]), then the MME or SGSN or combined MME/SGSN shall page the UE in order to return the most up-to-date corresponding user information. If the Current Location Request bit was also set and either paging is unsuccessful or the UE is not expected to be reachable, then the last known location of the UE shall be returned to the HSS. If the Current Location Request bit was also set and the UE (attached via E-UTRAN) is in connected mode, then the MME or combined MME/SGSN shall use S1AP Location Reporting Control procedure towards the eNB prior to reporting the E-UTRAN Cell Global Identification in order to return the UE's most up-to-date cell information. When the location is returned to the HSS, the MME or the combined MME/SGSN shall provide the age of location information if stored in the MME or the combined MME/SGSN or received from eNB. When receiving the IDR-Flags with only the ""Current Location Request"" bit set (i.e. the ""EPS Location Information Request"" bit is not set), the MME or SGSN or combined MME/SGSN shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. If the ""Local Time Zone Request"" bit was set the MME or SGSN if supported shall provide the Local Time Zone corresponding to the location (e.g. TAI or RAI) of the UE to the HSS. If the MME or SGSN cannot fulfil the received request, e.g. due to a database error or any of the required actions cannot be performed, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. If subscription data are received, the MME or SGSN shall mark the subscription record ""Subscriber to be restored in HSS"". If trace data are received in the subscriber data, the MME or SGSN shall start a Trace Session. For details, see 3GPPÊTSÊ32.422Ê[23]. If the Ext-PDP-Type AVP is present in the PDP-Context AVP, the SGSN or combined MME/SGSN shall ignore the value of the PDP-Type AVP. When receiving the IDR-Flags with the bit ""Remove SMS Registration"" set, the MME shall consider itself unregistered for SMS. If the subscription data received for a certain APN includes WLAN-offloadability AVP, then the MME or SGSN shall determine the offloadability of the UE's PDN Connection(s) to that APN based on subscription data and locally configured policy (e.g. for roaming users or when the subscription data does not include any offloadability indication). NOTE 2: As indicated in clauseÊ7.3.31, if the UE-level access restriction ""HO-To-Non-3GPP-Access Not Allowed"" is set, the offload of PDN Connections to WLAN is not allowed for any APN. When receiving the IDR-Flags with the ""P-CSCF Restoration Request"" bit set, the MME or SGSN or combined MME/SGSN shall execute the procedures for HSS-based P-CSCF Restoration, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4. If the subscription data received for the user includes the DL-Buffering-Suggested-Packet-Count AVP, then the MME or SGSN should take into account the subscription data, in addition to local policies, to determine whether to invoke extended buffering of downlink packets at the SGW for High Latency Communication. Otherwise, the MME or SGSN shall make this determination based on local policies only. When receiving IMSI-Group-Id AVP(s) within the Subscription-Data AVP, the MME or SGSN shall replace stored IMSI-Group Ids (if any) with the received information rather than add the received information to the stored information. In the present clause, if the feature ""Extended Reference IDs"" (see clauseÊ7.3.10) is supported by the HSS and the MME/SGSN, the term ""SCEF Reference ID"" shall refer to the content of the 64-bit long ""SCEF-Reference-ID-Ext"" AVP, and the term ""SCEF Reference ID for Deletion"" shall refer to the content of the 64-bit long ""SCEF-Reference-ID-for-Deletion-Ext"" AVP. When receiving a Monitoring-Event-Configuration in the IDR: - if the SCEF Reference ID for Deletion is present in the IDR, the MME or SGSN shall stop the detection of the Monitoring event related to the SCEF Reference ID for Deletion and SCEF-ID pair, and shall delete the corresponding Monitoring event configuration data; - if the SCEF Reference ID is present in the IDR but not stored in the MME or SGSN, the MME or SGSN shall store the received Monitoring event configuration data related to the SCEF Reference ID and SCEF-ID pair, and shall start the detection for the specified Monitoring event(s). - if the SCEF Reference ID is present in the IDR and stored in the MME or SGSN, the MME or SGSN shall replace the stored Monitoring event configuration data related to the SCEF Reference ID and SCEF-ID pair with the received information. NOTE 3: In roaming scenarios the MME/SGSN can reply immediately to the HSS without waiting for the outcome of the interaction with the IWK-SCEF. For the monitoring event configurations for which the configuration status have changed since the last status informed to the HSS, the MME/SGSN shall notify the HSS about the outcome of the interaction with the IWK-SCEF as specified in clauseÊ5.2.5.1.2. If the HSS indicates the support of Monitoring event feature to the MME/SGSN and the MME/SGSN supports Monitoring, the MME/SGSN shall include the Supported-Services AVP with Supported-Monitoring-Event included in the IDA command. When receiving the Maximum-Response-Time in Monitoring-Event-Configuration in IDR, the MME shall use the Maximum-Response-Time as the Active Time for the usage of PSM in UE. If not, when the MME receives the Active-Time in subscription data, the MME shall use the Active-Time as the Active Time for the usage of PSM in UE. When receiving AESE-Communication-Pattern AVP(s) within the Subscription-Data AVP with an SCEF Reference ID for which the MME has already stored data, it shall delete the stored data (CP set(s)) and store the received ones. When receiving AESE-Communication-Pattern AVP(s) within the Subscription-Data AVP with one or more SCEF Reference ID for deletion the MME shall delete the data related to the indicated SCEF Reference ID. If the MME and the UE support an Attach without PDN connection (i.e. EMM-REGISTERED without PDN connection) and the PDN-Connection-Restricted flag is set in the received Subscription-Data-Flags AVP, the MME shall not establish any non-emergency PDN connection and shall tear down any existing non-emergency PDN connection for this user. If the subscription data received for the user includes the Preferred-Data-Mode AVP, for an IP APN configuration or for a non-IP APN configuration with SGi based delivery, then the MME should (if the subscriber is not roaming) or may (if the subscriber is roaming) take into account the subscription data, in addition to local policies and the UE's Preferred Network Behaviour, to determine whether to transmit the traffic associated with this APN over the User Plane and/or over the Control Plane. Otherwise, the MME shall make this determination based on local policies and the UE's Preferred Network Behaviour only. If the MME subscription data received for the user includes the Emergency-Info AVP, the MME shall use the PDN-GW identity contained in such AVP as the PDN-GW used to establish emergency PDN connections with the emergency APN, for non-roaming authenticated UEs requesting the handover of an emergency PDN connection if the MME is configured to use a dynamic PDN-GW for emergency services for such user. When receiving V2X-Subscription-Data in the IDR, the MME shall determine whether the UE is authorized to use V2X communication over PC5 according to V2X subscription data and UE provided network capability. If the UE is authorized to use V2X communication over PC5, the MME shall store the ""V2X service authorized"" indication together with the UE AMBR used for PC5 interface (i.e. UE-PC5-AMBR), and provide such information to the eNodeB when needed. If the MME/SGSN receives from the HSS an Insert Subscriber Data request without the bit set for ""NR as Secondary RAT"" in the Feature-List AVP, the MME/SGSN, based on local policy, may restrict access for NR as secondary RAT when all relevant entities except HSS supports it. If the MME receives from the HSS Insert Subscriber Data request containing in the subscription data the Core-Network-Restrictions AVP with the bit ""5GC not allowed"" set, the MME shall restrict mobility towards 5GC. When receiving Paging-Time-Window AVPs within the Subscription-Data AVP, the MME or SGSN shall replace stored information (if any) with the received information rather than add the received information to the stored information. 5.2.2.1.3 Detailed behaviour of HSS The HSS shall make use of this procedure to replace a specific part of the user data stored in the MME or SGSN with the data sent, or to add a specific part of user data to the data stored in the MME or SGSN. The HSS shall also make use of this procedure to indicate to the MME that it is no longer registered for SMS. NOTE: When a Cancel Location message is required for other reasons, the use of IDR to indicate that the MME is no longer registered for SMS is not needed (see clauseÊ5.2.1.2). Subscriber-Status AVP shall be present in the Subscription-Data AVP, sent within IDR, if the current value in the MME or SGSN needs to be changed. To remove all Operator Determined Barring Categories the Subscriber-Status shall be set to ""SERVICE_GRANTED"". If Subscriber-Status AVP is present and set to OPERATOR_DETERMINED_BARRING, the Operator-Determined-Barring AVP or HPLMN-ODB AVP shall also be present in the Subscription-Data AVP. Access-Restriction-Data AVP shall be present within the Subscription-Data AVP send within an IDR if the information stored in the MME or SGSN needs to be modified. APN-OI-Replacement AVP shall be present in the Subscription-Data AVP sent within an IDR, if the UE level APN-OI-Replacement has been added or modified in the HSS. The APN-Configuration-Profile AVP shall be present in the Subscription-Data AVP sent within an IDR if the Context-Identifier associated with the default APN configuration is changed or at least one APN-Configuration is added or modified by the HSS. If the default APN is changed in the HSS, the APN-Configuration-Profile AVP shall contain the Context-Identifier associated with the default APN and the APN-Configuration AVP for the default APN. The default APN Configuration shall not contain the Wildcard APN (see 3GPPÊTSÊ23.003Ê[3], clauseÊ9.2); the default APN shall always contain an explicit APN. The EPS-Subscribed-QoS-Profile AVP and the AMBR AVP shall be present in the APN-Configuration AVP when the APN-Configuration AVP is sent in the APN-Configuration-Profile AVP and when the APN-Configuration-Profile AVP is sent within a IDR (as part of the Subscription-Data AVP). If the GPRS-Subscription-Data-Indicator information has been previously received as set in the ULR-Flags during update location procedure for the SGSN or combined MME/SGSN, the HSS shall make use of this procedure to replace the GPRS Subscription Data stored in the SGSN or combined MME/SGSN with the data sent or to add a PDP-Context to the data stored in the SGSN or combined MME/SGSN. ProSe-Subscription-Data AVP shall be present in the Subscription-Data AVP sent within an IDR, if the ProSe Subscription data has been added or modified in the HSS. If the HSS receives a message (e.g. via MAP ATM or Sh Sh-Subs-Notif) from a Service Related Entity (e.g. IP-SM-GW) indicating that the UE is unreachable, - the HSS shall associate the subscription to UE reachability of the service-related entity to the URRP-MME and the URRP-SGSN parameters (if not already done) - and if the URRP-MME and/or the URRP-SGSN parameters were not already set (i.e. at least one service-related entity already listed as subscribed), the HSS shall - set the URRP-MME and/or URRP-SGSN parameters and - send an IDR command to the registered MME and/or to the registered SGSN including the ""UE Reachability Request flag"" in the IDR Request Flags in order to request the MME and/or SGSN to notify the HSS when the UE becomes reachable again, unless the HSS knows from the previous ULR command that the registered MME and/or the registerd SGSN do not support UE reachability notifications. If the IDR is sent for the only purpose to request the MME and/or SGSN about the UE reachability status notification, the Subscription-Data AVP shall be included empty. If the HSS has received a message from a service related entity requesting EPS User State and/or EPS Location Information without the Serving Node Indication IE, the HSS shall set the ""EPS User State Request"" bit and/or ""EPS Location Information Request"" bit respectively in the IDR-Flags. The HSS may optionally also set the ""Current Location Request"" bit along with the ""EPS Location Information Request"" bit in the IDR-Flags, if the most up-to-date set of information is needed, unless the HSS knows from the previous ULR command that the registered MME and/or the registered SGSN do not support State/Location Information retrieval. If the IDR is sent only for the purpose of requesting the MME or the SGSN User State or Location Information, the Subscription-Data AVP included shall be empty. If the HSS cannot request EPS Location Information from the MME/SGSN e.g. because the UE is purged from the MME/SGSN, the HSS may make use of stored EPS Location information received in a previous IDA or PUR message. If the HSS has received a message from an AS requesting the current access network's support status of ""IMS Voice over PS Sessions"", and there is no indication about homogeneous support of IMS Voice over PS Sessions in all the serving nodes currently registered in HSS for the UE, the HSS shall set the ""T-ADS Data Request flag"" in the IDR Request Flags, unless the HSS knows from the previous ULR command that the registered MME and/or the registered SGSN do not support T-ADS data retrieval. If the IDR is sent for the only purpose to retrieve the ""IMS Voice over PS Sessions Supported"" indication from the MME or SGSN, the Subscription-Data AVP included shall be empty. If the HSS has received a message from an AS requesting the Local Time Zone, the HSS shall set the "" Local Time Zone Request"" bit in the IDR-Flags, unless the HSS knows from the previous ULR command that the registered MME and/or the registered SGSN do not support Local Time Zone retrieval. If the IDR is sent only for the purpose of requesting the Local Time Zone, the Subscription-Data AVP included shall be empty. If the HSS received an indication in a former ULR command from the MME or SGSN about homogeneous support of IMS Voice over PS Sessions in all TA/RAs associated to that serving node, it may use this information to skip the retrieval of T-ADS data. This can only be done if all the registered serving nodes in HSS for the UE indicated in ULR the same type of homogeneous support (i.e. both serving nodes indicated ""SUPPORTED"", or both serving nodes indicated ""NOT_SUPPORTED""); otherwise, the retrieval of T-ADS data shall be done, to receive the time of the last radio contact with the UE. All APN and PGW-ID pairs stored in the HSS not associated with an explicit APN subscription, (i.e. the access to that APN has been authorized as a consequence of having the Wildcard APN in the user subscription), shall be included by the HSS inside the APN context of the Wildcard APN, as multiple instances of the Specific-APN-Info AVP. When receiving an Insert Subscriber Data answer with ""SGSN Area Restricted"" the HSS shall set the SGSN area restricted flag as ""SGSN area restricted"". Subscribed-VSRVCC AVP may be present within the Subscription-Data AVP sent within an ISR only if the user is subscribed to the SRVCC and vSRVCC. If the HSS determines that the MME shall be unregistered for SMS it shall set the ""Remove SMS Registration"" bit in the IDR-Flags. If the IDR is sent for the only purpose to indicate that the MME is no longer registered for SMS, the Subscription-Data AVP shall be included empty. If the HSS needs to request to the MME/SGSN the execution of the HSS-based P-CSCF restoration procedure, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4, the HSS shall set the ""P-CSCF Restoration Request"" bit in the IDR-Flags, if supported by the MME/SGSN. If the IDR is sent only for the purpose of requesting the execution of the HSS-based P-CSCF restoration procedures, the Subscription-Data AVP included shall be empty. If the HSS receives a SCEF request to configure Monitoring events for the UE to be handled by the MME/SGSN or receives a SCEF request for deleting Monitoring events for the UE in the MME/SGSN, the HSS shall include Monitoring-Event-Configuration AVP(s) in the Subscription-Data AVP sent within the IDR. If the HSS has registered both an MME and an SGSN as serving nodes for a given user, and both nodes are not part of a same combined MME/SGSN node, the HSS shall send the Monitoring-Event-Configuration AVP(s) to each one of the serving nodes that supports the Monitoring event service. If the HSS receives the IDA with Monitoring-Event-Report AVP(s), the HSS shall forward the Monitoring-Event-Report AVP(s) to the SCEF associated to those Monitoring events. If the HSS does not receive a SCEF request to configure Monitoring events for the UE to be handled by the MME/SGSN and does not receive an Active Time with the Suggested-Network-Configuration AVP , the HSS may send an O&M configured desired Active Time value within the Active-Time AVP. If the HSS receives a Supported-Services AVP it shall only trigger those services which are supported by the MME/SGSN. If the HSS has previously received over SWx (see 3GPPÊTSÊ29.273Ê[59]) the identity of the PDN-GW to be used for the establishment of emergency PDN connections, it shall send it to the registered MME (if any) in the IDR command as part of the Subscription-Data AVP (in the Emergeny-Info AVP). If V2X subscription data has been added or modified in the HSS, the HSS shall include the V2X-Subscription-Data AVP in the Subscription-Data AVP sent within an IDR. If the External-Identifier associated with Monitoring Event Configuration for the UE has been added or modified in the HSS and the MME/SGSN supports the ""External-Identifier"" feature, the HSS shall include the External-Identifier AVP in the Subscription-Data AVP. When multiple External Identifiers are defined for a same subscription, the HSS shall send a default External Identifier in the External-Identifier AVP of the Subscription-Data AVP, and shall include a specific External Identifier (if different from the default External Identifier) associated to each Monitoring Event Configuration in the External-Identifier AVP of each Monitoring-Event-Configuration AVP occurrence inside the Subscription-Data AVP. The Aerial-UE-Subscription-Information AVP may be present within the Subscription-Data AVP sent within an IDR only if the user has Aerial UE subscription information. If Core Network Restrictions in subscription data (5GC allowed/not allowed) has been added or modified in the HSS, the HSS shall include the Core-Network-Restrictions AVP in the Subscription-Data AVP sent within an IDR. 5.2.2.2 Delete Subscriber Data 5.2.2.2.1 General This procedure shall be used between the MME and the HSS and between the SGSN and the HSS, to remove some data of the HSS user profile stored in the MME or SGSN. The procedure shall be invoked by the HSS and it corresponds to the functional level operation Delete Subscriber Data (see 3GPPÊTSÊ23.401Ê[2]). It shall be used to remove: - a subset (wich may or may not be the complete set of APN configurations) of the APN Configuration Profile for the subscriber from the SGSN or combined MME/SGSN; - a proper subset (i.e. a subset that is not equal to the complete set of APN configurations and does not contain the default APN configuration) of the APN Configuration Profile for the subscriber from the MME; - the regional subscription; - the subscribed charging characteristics; - Session Transfer Number for SRVCC; - trace data; - ProSe subscription data; - Reset-IDs; - MSISDN; - UE Usage Type; - V2X subscription data. - External Identifier(s). If the HSS knows that the UE has attached to the MME and SGSN parts of the same combined MME/SGSN via both E-UTRAN and UTRAN/GERAN(refer to clauseÊ5.2.1.1.2, 5.2.1.1.3 for further details), the HSS should invoke this procedure for a single time to remove some or all data of the HSS user profile stored in the combined MME/SGSN, i.e. not invoke this procedure for each of the MME and the SGSN registered respectively. If the Node-Type-Indicator information has been previously received as cleared in the ULR-Flags and if the MME has not been registered for SMS during update location procedure for the MME, the HSS may skip any removal of the SMS related subscription data and consequently does not have to make use of the Delete Subscriber Data procedure to update the SMS subscription data in the MME. This procedure is mapped to the commands Delete-Subscriber-Data-Request/Answer (DSR/DSA) in the Diameter application specified in clause 7. Table 5.2.2.2.1/1 specifies the involved information elements for the request. Table 5.2.2.2.1/2 specifies the involved information elements for the answer. Table 5.2.2.2.1/1: Delete Subscriber Data Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. DSR Flags (See 7.3.25) DSR-Flags M This Information Element shall contain a bit mask. See 7.3.25 for the meaning of the bits. Trace Reference (See 7.3.64) Trace- Reference C This parameter shall contain the same value as used for the activation of the Trace Session. This element shall be present only if the ""Trace Data Withdrawal"" bit is set in the DSR-Flags. Context Identifier (See 7.3.27) Context-Identifier C This parameter shall identify the PDN subscription context or GPRS-PDP context that shall be deleted. This element shall be present only if the ""PDN subscription contexts Withdrawal"" bit or the ""PDP context withdrawal"" bit is set in the DSR-Flags. In the ""PDN subscription contexts Withdrawal"" case, the Context-Identifier shall not be associated with the default APN configuration. For the compatibility with the MAP protocol as defined in the 3GPPÊTSÊ29.002Ê[24], this parameter shall not have a value of zero. TS Code List (See 7.3.100) TS-Code C This parameter shall contain the teleservice codes that are to be deleted from the subscription. This element shall be present only if the ""SMS Withdrawal"" bit is set in the DSR-Flags and the SMS related teleservice codes are to be deleted. SS Code List (See 7.3.87) SS-Code C This parameter shall contain the supplementary service codes that are to be deleted from the subscription. This element shall be present only if the ""SMS Withdrawal"" bit is set or the ""LCS Withdrawal"" bit is set in the DSR-Flags. SCEF-Id (See 3GPPÊTSÊ29.336Ê[54]) SCEF-ID C This parameter shall contain the identity of the SCEF to which monitoring events that are to be deleted are associated. This element shall be present if the ""Delete monitoring events"" bit is set in the DSR-Flags. eDRX Related RAT List eDRX-Related-RAT C This parameter shall contain the RAT types for which the eDRX Cycle Lengths is to be deleted from the subscription. This element shall be present only if the ""eDRX-Cycle-Length-Withdrawal"" bit is set in the DSR-Flags and the corresponding eDRX Cycle Lengths are to be deleted. If the ""eDRX-Cycle-Length-Withdrawal"" bit is set in DSR-Flags, but the eDRX-Related-RAT AVP is absent in this command, the MME/SGSN shall delete the stored eDRX cycle lengths for all RATs. External Identifiers External-Identifiers O If present, this parameter shall contain the External Identifier(s) to be deleted from the subscriber data; the MME/SGSN shall also delete those monitoring events that include an External-Identifier AVP in their event configuration matching any of the External-Identifiers in this IE. This IE shall be absent if the ""External-Identifier-Withdrawal"" bit is not set in the DSR-Flags. If this IE is absent, and ""External-Identifier-Withdrawal"" bit is set in DSR-Flags, the MME/SGSN shall delete the default External-Identifier in the Subscription-Data AVP and it shall also delete all monitoring events that include an External-Identifier AVP in their event configuration. Table 5.2.2.2.1/2: Delete Subscriber Data Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown DSA Flags (See 7.3.26) DSA-Flags C This Information Element shall contain a bit mask. See 7.3.26 for the meaning of the bits. 5.2.2.2.2 Detailed behaviour of the MME and the SGSN When receiving a Delete Subscriber Data request, the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If it is known, but the Context-Identifier is associated with the default APN configuration, the MME shall not delete the PDN subscription context, and return an error with a Result-Code set to DIAMETER_UNABLE_TO_COMPLY. Otherwise, the MME or SGSN shall delete the corresponding data according to the indication as sent in the request, and acknowledge the Delete Subscriber Data message by returning a Delete Subscriber Data Answer. If an MME receives a Delete Subscriber Data Request with the ""Complete APN Configuration Profile Withdrawal"" bit set in the DSR-Flags AVP, it shall return an error with a Result-Code set to DIAMETER_UNABLE_TO_COMPLY. If the deletion of the subscription data succeeds in the MME or SGSN, the Result-Code shall be set to DIAMETER_SUCCESS. If the Regional Subscription is deleted from the subscription data, the SGSN shall check for its routing areas whether they are allowed or not. If the entire SGSN area is restricted, SGSN shall report it to the HSS by returning the ""SGSN Area Restricted"" indication within the DSA flags. If the EPS Subscription Data is deleted from the subscription data, the MME or SGSN shall check whether all EPS Subscription Data for the subscriber is deleted or if only a subset of the stored EPS Subscription Data for the subscriber is deleted, the MME or SGSN may then deactivate the associated affected active EPS bearers. If the Subscribed Charging Characteristics are deleted from the subscription data, the Gn/Gp-SGSN shall maintain the existing Subscribed Charging Characteristics throughout the lifetime of the existing MM and PDP contexts, see 3GPPÊTSÊ32.251Ê[33]. If the Subscribed Charging Characteristics are deleted from the subscription data, the MME or S4-SGSN shall maintain the existing Subscribed Charging Characteristics throughout the lifetime of the existing IP CAN bearer, see 3GPPÊTSÊ32.251Ê[33]. If the MSISDN is deleted from the subscription data, the MME or SGSN shall maintain the existing MSISDN throughout the lifetime of the existing PDN connections that were established prior to the deletion of the MSISDN (i.e., other network nodes, such as PDN-GW, are not informed of such deletion for the existing PDN connections). The MME/SGSN shall also delete those monitoring events related to the deleted MSISDN. If the MME or SGSN cannot fulfil the received request for other reasons, e.g. due to a database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. In this case, the MME or SGSN shall mark the subscription record ""Subscriber to be restored in HSS"". If trace data are deleted from the subscription data, the MME or SGSN shall deactivate the Trace Session identified by the trace reference. For details, see 3GPPÊTSÊ32.422Ê[23]. If External Identifiers are requested to be deleted from the subscription data, the MME/SGSN shall check whether any of the identifiers to be deleted match the default External-Identifier provided by HSS in the Subscrition-Data AVP (unless all External Identifiers are requested to be deleted from the subscription); in such case, the MME/SGSN shall reject the request and return an error with a Result-Code set to DIAMETER_UNABLE_TO_COMPLY (if default External Identifier is wanted to be deleted, no External Identifier must be provided in the request). The MME/SGSN shall also delete those monitoring events related to the deleted External Identifiers, or all monitoring events associated to any External Identifier if default External Identifier is deleted. 5.2.2.2.3 Detailed behaviour of the HSS The HSS shall make use of this procedure to remove deleted subscription data from the MME or SGSN. The HSS shall make use of this procedure to remove deleted GPRS Subscription Data from the SGSN or combined MME/SGSN if the GPRS-Subscription-Data-Indicator information has been previously received as set in the ULR-Flags during update location procedure for the MME. The HSS shall not set the ""Complete APN Configuration Profile Withdrawal"" bit in the DSR-Flags AVP when sending a Delete Subscriber Data Request to an MME, since the default APN shall always be present in an MME. When receiving a Delete Subscriber Data Answer with ""SGSN Area Restricted"" the HSS shall set the SGSN area restricted flag as ""SGSN area restricted"". 5.2.3 Authentication Procedures 5.2.3.1 Authentication Information Retrieval 5.2.3.1.1 General The Authentication Information Retrieval Procedure shall be used by the MME and by the SGSN to request Authentication Information from the HSS. This procedure is mapped to the commands Authentication-Information-Request/Answer (AIR/AIA) in the Diameter application specified in clause 7. Table 5.2.3.1.1/1 specifies the involved information elements for the request. Table 5.2.3.1.1/2 specifies the involved information elements for the answer. Table 5.2.3.1.1/1: Authentication Information Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Requested E-UTRAN Authentication Info (See 7.3.11) Requested-EUTRAN-Authentication-Info C This information element shall contain the information related to authentication requests for E-UTRAN. Requested UTRAN/GERAN Authentication Info (See 7.3.12) Requested-UTRAN-GERAN Authentication-Info C This information element shall contain the information related to authentication requests for UTRAN or GERAN. Visited PLMN ID (See 7.3.9) Visited-PLMN-ID M This IE shall contain the MCC and the MNC of the visited PLMN, see 3GPPÊTSÊ23.003Ê[3]. AIR Flags (See 7.3.201) AIR-Flags O This IE, if present, contains a bit mask. See clauseÊ7.3.201 for the meaning of the different bits. Table 5.2.3.1.1/2: Authentication Information Answer Information element name Mapping to Diameter AVP Cat. Description Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. This IE shall contain the Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown - Unknown EPS Subscription - Authentication Data Unavailable Error-Diagnostic Error-Diagnostic O If the Experimental Result indicated ""Unknown EPS Subscription"", Error Diagnostic may be present to indicate whether or not GPRS subscription data are subscribed (i.e. whether or not Network Access Mode stored in the HSS indicates that only CS service is allowed). Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Authentication Info (See 7.3.17) Authentication-Info C This IE shall contain the Authentication Vectors. UE Usage Type (See 7.3.202) UE-Usage-Type C This IE shall be present if the HSS supports the Dedicated Core Networks feature, and the ""Send UE Usage Type"" flag was set in the AIR-Flags AVP in the AIR command, and this information is available in the user subscription. If present, this IE shall contain the UE Usage Type of the subscriber (see clauseÊ7.3.202). 5.2.3.1.2 Detailed behaviour of the MME and the SGSN The MME or SGSN shall make use of this procedure in order to retrieve the Authentication Vectors from the HSS. If the MME or SGSN supports Emergency services for users in limited service state, and the user's IMSI is not available from the UE, or the user's IMSI is marked as unauthenticated, the MME or SGSN shall not make use of the Authentication Information Retrieval procedure. If the request is triggered by a synchronization failure during E-UTRAN authentication, the MME or combined MME/SGSN shall include the Re-Synchronization Information in the Requested-EUTRAN-Authentication-Info AVP in the request. If the request is triggered by a synchronization failure during UTRAN or GERAN authentication, the SGSN or combined MME/SGSN shall include the Re-Synchronization Information in the Requested-UTRAN-GERAN-Authentication-Info AVP in the request. Re-Synchronization Information shall not be present in both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP. A stand alone MME shall include the Requested-EUTRAN-Authentication-Info AVP and shall not include the Requested-UTRAN-GERAN-Authentication-Info AVP in the request. The Immediate-Response-Preferred AVP should be present if a EUTRAN-Vector is needed for immediate use. A stand alone SGSN shall not include the Requested-EUTRAN-Authentication-Info AVP and shall include the Requested-UTRAN-GERAN-Authentication-Info AVP in the request. The Immediate-Response-Preferred AVP should be present if a UTRAN/GERAN-Vector is needed for immediate use. A combined MME/SGSN may include both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP in the request. If both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP are present in the request, the Immediate-Response-Preferred AVP shall be present if the requested authentication vectors are needed for immediate use. The content of the Immediate-Response-Preferred AVP shall correspond to the access type which the UE is currently to be authenticated. The Immediate-Response-Preferred AVP shall not be present in both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP. The presence of an Immediate-Response-Preferred AVP shall indicate that a vector is needed for immediate use. When EUTRAN-AVs and UTRAN-AVs or GERAN-AVs are requested, presence of Immediate-Response-Preferred AVP within the Requested-EUTRAN-Authentication-Info AVP shall indicate that EUTRAN-AVs are requested for immediate use in the MME/SGSN; presence of Immediate-Response-Preferred AVP within the Requested-UTRAN-GERAN-Authentication-Info AVP shall indicate that UTRAN-AVs or GERAN-AVs are requested for immediate use in the MME/SGSN. It may be used by the HSS to determine the number of vectors to be obtained from the AuC and the number of vectors downloaded to the MME or SGSN. If the MME or SGSN supports the Dedicated Core Networks functionality, and the MME or SGSN needs to retrieve the UE Usage Type from the HSS, it shall set the ""Send UE Usage Type"" flag in the AIR-Flags AVP in the AIR command. When receiving an Authentication Information response from the HSS, the MME or SGSN shall check the Result Code. If it indicates success and Authentication Information is present in the result, the MME or SGSN shall use the received vectors. For details see 3GPPÊTSÊ33.401Ê[5]. If the MME or SGSN supports Emergency services for users in limited service state, the MME or SGSN shall proceed even if the Authentication Information Retrieval procedure has failed. In this case, the MME or SGSN shall mark the user's IMSI as unauthenticated. Vectors with lower Item Number should be used before Vectors with higher Item Number are used in the MME or SGSN. For Vectors received within different requests those received by the earlier request should be used before those received by the later request. 5.2.3.1.3 Detailed behaviour of the HSS When receiving an Authentication Information request the HSS shall check whether subscription data exists for the IMSI. If the HSS determines that there is not any type of subscription for the IMSI (including EPS, GPRS and CS subscription data), a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If the Authentication Information Request contains a Requested-EUTRAN-Authentication-Info AVP but no Requested-UTRAN-GERAN-Authentication-Info AVP, and the subscriber has not any APN configuration, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. If the Authentication Information Request contains a Requested-UTRAN-GERAN-Authentication-Info AVP but no Requested-EUTRAN-Authentication-Info AVP, and the subscriber has neither an APN configuration profile nor GPRS subscription data, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION."
"If the Authentication Information Request contains both Requested-EUTRAN-Authentication-Info AVP and Requested-UTRAN-GERAN-Authentication-Info AVP, and the Requested-EUTRAN-Authentication-Info AVP does not contain an Immediate-Response-Preferred AVP, and the subscriber has not any APN configuration, the HSS shall not return E-UTRAN vectors. If the Authentication Information Request contains both Requested-EUTRAN-Authentication-Info AVP and Requested-UTRAN-GERAN-Authentication-Info AVP, and the Requested-EUTRAN-Authentication-Info AVP contains an Immediate-Response-Preferred AVP, and the subscriber does not have any APN configuration, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. When sending DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION, an Error Diagnostic information may be added to indicate whether or not GPRS subscription data are subscribed (i.e. whether or not Network Access Mode stored in the HSS indicates that only circuit service is allowed). If EUTRAN-Authentication-Info is requested, the HSS shall check if serving nodes within the realm identified by the received Origin-Realm AVP are allowed to request authentication information for use in the serving network identified by the received Visited-PLMN-Id AVP. The HSS shall then request the AuC to generate the corresponding requested Authentication Vectors (AVs). Subject to load considerations and/or other implementation specific considerations which may be based on the presence of an Immediate-Response-Preferred AVP, less AVs than the requested number of AVs may be generated. If EUTRAN-Authentication-Info is requested, when receiving AVs from the AuC, the HSS shall generate the KASME before sending the response to the MME or combined MME-SGSN. If the AuC is unable to calculate any corresponding AVs due to unallowed attachment for the UE, e.g. the UE is attaching via E-UTRAN with a SIM card equipped, the HSS shall return an error DIAMETER_AUTHORIZATION_REJECTED, the HSS shall not return any AV to the requesting node in the response. Otherwise, if no corresponding pre-computed AV is available, and the AuC is unable to calculate any corresponding AVs due to unknown failures, such as the internal database error, the result code shall be set to DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE. The MME or the SGSN may request authentication vectors again. For details see 3GPPÊTSÊ33.401Ê[5]. KASME generation is not performed before sending the response to the SGSN. If the Requested-EUTRAN-Authentication-Info AVP is present in the request, the HSS shall download E-UTRAN authentication vectors to the MME. If the Requested-UTRAN-GERAN-Authentication-Info AVP is present in the request, the HSS shall download UTRAN or GERAN authentication vectors to the SGSN. If the Immediate Response Preferred parameter has been received, the HSS may use it together with the number of requested vectors and the number of vectors stored in the HSS that are pre-computed to determine the number of vectors to be obtained from the AuC. The HSS may return less number of vectors than requested to the MME or SGSN. If both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP are in the request, and one of them includes the Immediate Response Preferred parameter, the HSS may omit the vectors request that are not for immediate use. If both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP are in the request, and both of them includes the Immediate Response Preferred parameter, the HSS may return E-UTRAN authentication vectors and UTRAN or GERAN authentication vectors. KASME is always computed for each E-UTRAN vector due to the PLMN-binding before sending the response to the MME independent of the presence of the Immediate Response Preferred parameter. If the Re-Synchronization-Info AVP has been received, the HSS shall check the AUTS parameter before sending new authentication vectors to the MME or the SGSN. For details see 3GPPÊTSÊ33.102Ê[18]. If both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP are in the request, and both of them include the Re-Synchronization-Info AVP, the HSS shall not check the AUTS parameter and return the result code of DIAMETER_UNABLE_TO_COMPLY. Any authentication vectors shall not be sent by the HSS to the requesting node in the response. If more than one EPS or UTRAN or GERAN Vector is to be included within one Authentication-Info AVP, the Item-Number AVP shall be present within each Vector. If the HSS supports the Dedicated Core Networks functionality, and the MME or SGSN has set the ""Send UE Usage Type"" flag in the AIR-Flags AVP in the AIR command: - if the UE Usage Type value is available in the subscription data of the user: - if the Immediate Response Preferred parameter is not present in the Requested-EUTRAN-Authentication-Info nor in the Requested-UTRAN-GERAN-Authentication-Info, the HSS may return no authentication vectors in the response; the HSS shall then return the result code DIAMETER_SUCCESS and may return the generated AVs (if any) to the MME or SGSN; - the HSS shall include the UE-Usage-Type AVP in the AIA response command if the result code is DIAMETER_SUCCESS or DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE. - if the UE Usage Type value is not available in the subscription data of the user, the HSS shall answer as if the MME/SGSN had not requested the UE Usage Type parameter. 5.2.4 Fault Recovery Procedures 5.2.4.1 Reset 5.2.4.1.1 General The Reset Procedure shall be used by the HSS, after a restart, to indicate to the MME and to the SGSN that a failure has occurred. The Reset Procedure may also be used by the HSS as part of operation and maintenance actions e.g. to allow planned HSS outage without service interruption, or to update subscription data shared by multiple subscribers. This procedure is mapped to the commands Reset-Request/Answer (RSR/RSA) in the Diameter application specified in clause 7. Table 5.2.4.1.1/1 specifies the involved information elements for the request. Table 5.2.4.1.1/2 specifies the involved information elements for the answer. Table 5.2.4.1.1/1: Reset Request Information element name Mapping to Diameter AVP Cat. Description User Id List (See 7.3.50) User-Id O This IE shall contain a list of User-Ids where a User-Id comprises the leading digits of an IMSI (i.e. MCC, MNC, leading digits of MSIN) and it shall identify the set of subscribers whose IMSIs begin with the User-Id. The HSS may include this information element if the occurred failure is limited to subscribers identified by one or more User-Ids. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Reset-IDs (See 7.3.184) Reset-ID O If present, this information element identifies the set of impacted subscribers. Subscription Data (See 7.3.2) Subscription-Data O If the Reset Procedure is used to add/ modify subscription data shared by multiple subscribers, this Information Element shall contain the part of the subscription profile that either is to be added to the subscription profile stored in the MME or SGSN or combined MME/SGSN or is replacing a part of the subscription profiles of the impacted subscribers stored in the MME or SGSN. Shall be absent if Subscription-Data-Deletion AVP is present. Shall be absent if Reset-ID AVP is absent Subscription Data Deletion (See 7.3.208) Subscription-Data-Deletion O If the Reset Procedure is used to delete subscription data shared by multiple subscribers, this Information Element shall contain identifications of the part of the subscription profile that is to be deleted from the subscription profiles of the impacted subscribers stored in the MME or SGSN or combined MME/SGSN. Shall be absent if Subscription-Data AVP is present. Shall be absent if Reset-ID AVP is absent Table 5.2.4.1.1/2: Reset Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. There are no Experimental-Result codes applicable for this command. 5.2.4.1.2 Detailed behaviour of the MME and the SGSN When receiving a Reset message neither containing Subscription-Data nor Subscription-Data-Deletion the MME or SGSN or combined MME/SGSN shall mark all impacted subscriber records ""Location Information Confirmed in HSS "" as ""Not Confirmed"". When receiving a Reset message containing Subscription-Data or Subscription-Data-Deletion the MME or SGSN or combined MME/SGSN shall update all impacted subscriber records accordingly, i.e. each impacted subscriber record is updated as if an individual IDR or DSR for that subscriber was received; for details see clauses 5.2.2.1.2 and 5.2.2.2.2. The MME or SGSN or combined MME/SGSN shall not mark successfully updated subscriber records ""Location Information Confirmed in HSS "" as ""Not Confirmed"". If an impacted subscriber record cannot be updated for any reason (e.g. the updated data is considered not shareable by the MME or SGSN or combined MME/SGSN, or the update requires an individual acknowledgement to be sent to the HSS), the MME or SGSN or combined MME/SGSN shall mark that record ""Location Information Confirmed in HSS "" as ""Not Confirmed"". NOTE: Which subscription data are considered by the MME or SGSN or combined MME/SGSN not shareable by multiple subscribers is implementation specific. If the update of shared subscription data requires only local updates in the MME or SGSN or combined MME/SGSN (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring). If the update of shared subscription data implies initiating a signalling interaction towards other nodes (e.g. towards the PGW/PCRF for the change of an APN configuration parameter, such as APN-AMBR), depending on the UE's state the following shall apply: - If the UE is in CONNECTED state, the updates shall be performed immediately including signalling towards other nodes. - If the UE is in IDLE state, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE. NOTE: The rational for the recommendationÊto defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user's activity. In both cases, to avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the MME or SGSN or combined MME/SGSN may take a maximum operator configuration-depending time. If the Reset-IDs IE is supported and received, the MME or SGSN or combined MME/SGSN shall make use of the Reset-IDs (together with the HSS's realm) in order to determine which subscriber records are impacted (i.e. check whether at least one received Reset-ID is associated with the subscriber); otherwise the MME or SGSN or combined MME/SGSN shall make use of the HSS Identity received in the Origin-Host AVP (by comparing it with the value stored after successful ULA) and may make use of the received User-Id-List (if any) in order to determine which subscriber records are impacted. At the next authenticated radio contact with the UE concerned, if the subscriber record ""Location Information Confirmed in HSS"" is marked as ""Not Confirmed"", the restoration procedure shall be triggered. See also 3GPPÊTSÊ29.118Ê[46] clauseÊ5.9.2. 5.2.4.1.3 Detailed behaviour of the HSS The HSS shall make use of this procedure in order to indicate to all relevant MMEs, SGSN, and combined MME/SGSNs that the HSS has restarted and may have lost the current MME-Identity and SGSN-Identity of some of its subscribers who may be currently roaming in the MME area and/or SGSN area, and that the HSS, therefore, cannot send a Cancel Location messages or Insert Subscriber Data messages when needed. The HSS may make use of this procedure in order to indicate to all relevant MMEs, SGSN, and combined MME/SGSNs that the HSS has updated subscription data shared by some of its subscribers who may be currently roaming in the MME area and/or SGSN area. If the Reset-ID feature is not supported by the MME/SGSN and HSS, the HSS optionally may include a list of Ids identifying a subset of subscribers served by the HSS, if the occurred failure is limited to those subscribers. If the Reset-ID feature is supported by the MME or SGSN, the HSS optionally may include one (or several) Reset-ID AVPs identifying e.g. failed hardware components if the occured failure is limited to those subscribers associated with e.g. the identified failed hardware components. The HSS should invoke this procedure towards a combined MME/SGSN only for a single time even if some of the impacted subscribers are attached to the combined MME/SGSN via UTRAN/GERAN and some of the impacted subscribers are attached to the combined MME/SGSN via E-UTRAN. 5.2.5 Notification Procedures 5.2.5.1 Notification 5.2.5.1.1 General The Notification Procedure shall be used between the MME and the HSS and between the SGSN and the HSS when an inter MME or SGSN location update does not occur but the HSS needs to be notified about - an update of terminal information; - an update of the UE SRVCC capability (only if the MME/SGSN supports SRVCC). The Notification Procedure shall also be used between the MME and the HSS and between the SGSN and the HSS if the HSS needs to be notified about: - an assignment/change of a dynamically allocated PDN GW for an APN, if such a notification is needed taking into account the access restrictions and the type of PDN; NOTE: If the PDN is of type ""non-IP"", the APN is not accessible via non-3GPP access and therefore the PDN-GW ID does not need to be conveyed across accesses. - an assignment/change of a dynamically allocated PDN GW for the establishment of emergency PDN connections, if such notification is needed for a non roaming authenticated user, based on operator policy (e.g. on whether the operator uses static PDN GW or not for emergency services) taking into account the access restrictions and feature support; - the failed monitoring event configurations at the MME or SGSN (if received in ULA) or the status of the monitoring event configurations at the IWK-SCEF; - the deletion of a monitoring event configuration in SCEF for a UE (i.e. due to an SCEF restart, see 3GPPÊTSÊ23.007Ê[43]). The Notification Procedure shall be used between the MME and the HSS when an inter MME location update does not occur but the HSS needs to be notified about - the need to send a Cancel Location to the current SGSN. The Notification Procedure shall be used between the MME and the HSS when the ""SMS in MME"" feature is applied and between the SGSN and the HSS when an earlier short message delivery failed and the HSS needs to be notified about: - the UE is reachable or the UE has memory capacity available to receive one or more short messages. The Notification Procedure shall be used between the MME and the HSS and between the SGSN and the HSS when the HSS has requested to be notified about: - the UE is reachable. The Notification Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to notify the HSS about: - an update of the Homogeneous Support of IMS Voice Over PS Sessions. The Notification Procedure shall be used between the MME and the HSS to notify the HSS about: - removal of MME registration for SMS. This procedure is mapped to the commands Notify-Request/Answer (NOR/NOA) in the Diameter application specified in clause 7. Table 5.2.5.1.1/1 specifies the involved information elements for the request. Table 5.2.5.1.1/2 specifies the involved information elements for the answer. Table 5.2.5.1.1/1: Notify Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Terminal Information (See 7.3.3) Terminal-Information C This information element shall contain information about the user's mobile equipment. When notifying the HSS about any change of Terminal Information, the MME or SGSN shall include the new Terminal Information in the request. Within this Information Element, only the IMEI and the Software-Version AVPs shall be used on the S6a/S6d interface. PDN GW Identity (See 7.3.45) MIP6-Agent-Info C This IE shall contain the identity of the selected and dynamically allocated PDN GW for an APN. It shall be present if a new PDN-GW has been selected and the subscriber is allowed handover to non 3GPP access or 5GS interworking without N26 interface enabled. When notifying the HSS about a newly selected PDN GW, the MME or SGSN shall include the PDN-GW-Identity in the request. For establishment of emergency PDN connections, this IE shall contain the identity of the PDN-GW used to establish those PDN connections. PGW PLMN ID Visited-Network-Identifier C This IE identifies the PLMN in which the PDN GW is located. It shall be present when the PDN GW Identity is present and does not contain an FQDN. Context Identifier (See 7.3.27) Context-Identifier O This parameter shall identify the APN Configuration with which the selected PDN GW shall be correlated. It may be present if it is available and the PDN-GW is present and is particular for one specific APN and not common to all the APNs. For the compatibility with the MAP protocol as defined in the 3GPPÊTSÊ29.002Ê[24], this parameter shall not have a value of zero. APN (See TSÊ23.008Ê[30]) Service-Selection (See IETFÊRFCÊ5778Ê[20]) C This IE shall contain the APN for the selected and dynamically allocated PDN GW. For establishment of non-emergency PDN connections, it shall be present if the selected PDN-GW is present and is particular for one specific APN and not common to all the APNs. For establishment of emergency PDN connections (i.e., the Emergency-Services AVP is present, with the Emergency-Indication flag set), this AVP shall be left absent. Alert Reason (See 7.3.83) Alert-Reason C This parameter shall indicate if the mobile subscriber is present or the MS has memory available. It shall be present when notifying the HSS about the presence of the UE or the UE has memory capacity available to receive one or more short messages. UE SRVCC Capability UE-SRVCC-Capability C This information element shall indicate if the UE supports or does not support the SRVCC capability. If the MME/SGSN supports SRVCC and the UE SRVCC Capability has changed, the MME or SGSN shall include the new UE SRVCC Capability in the request. NOR Flags (See 7.3.49) NOR-Flags C This Information Element shall contain a bit mask. See 7.3.49 for the meaning of the bits. Absence of this information element shall be interpreted as all bits set to 0. When notifying the HSS about the need to send cancel location to the current SGSN, the MME shall set the ""Single-Registration-Indication"" flag in the NOR-Flags. When notifying the HSS about the ""restricted"" status of the current SGSN area, the SGSN shall set the ""SGSN area restricted"" flag in the NOR-Flags. When notifying the HSS about the reachability of the UE or the UE has memory capacity available to receive one or more short messages, the MME, if the ""SMS in MME"" feature is applied, or SGSN shall set the ""Ready for SM"" flag correspondingly in the NOR-Flags. When notifying the HSS that the UE is reachable, the MME or SGSN shall set the ""UE Reachable"" flag correspondingly in the NOR-Flags. When notifying the HSS about update of the Homogeneous Support of IMS Voice Over PS Sessions, the MME or the SGSN shall set the ""Homogeneous Support of IMS Voice Over PS Sessions"" flag and S6a/S6d-Indicator flag for a combined MME/SGSN correspondingly in the NOR-Flags. When notifying the HSS about removal of MME registration for SMS, the MME shall set the ""Removal of MME Registration for SMS"" flag correspondingly in the NOR-Flags. Homogeneous Support of IMS Voice Over PS Sessions (See 7.3.107) Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions C This Information Element shall be present if Homogeneous Support of IMS Voice Over PS Sessions is modified to one of the values ""SUPPORTED"" or ""NOT_SUPPORTED"". The value ""SUPPORTED"" indicates that there is support for ""IMS Voice over PS Sessions"" in all TAs or RAs. The value ""NOT_SUPPORTED"" indicates that there is not support for ""IMS Voice over PS Sessions"" in any of the TAs or RAs. Maximum UE Availability Time Maximum-UE-Availability-Time O This information element may be included when notifying the HSS that the UE is reachable. When present, it shall indicate the timestamp (in UTC) until which a UE using a power saving mechanism (such as extended idle mode DRX) is expected to be reachable for SM Delivery. This information may be used by the SMS Center to prioritize the retransmission of Short Message to UEs using a power saving mechanism. Monitoring Event Config Status Monitoring-Event-Config-Status C This information element shall be present if the MME/SGSN sends the Notify Request after receiving the Configuration-Information-Answer from the IWK-SCEF. This information element shall only contain the monitoring event configuration status of those events whose configuration status has changed since the last status informed to the HSS. This information element shall also be present if any of the monitoring events configurations received in ULA failed and shall only contain the monitoring event configuration status of those events whose detection could not be started at the MME/SGSN. This information element shall also be present if the MME or SGSN determines that a Monitoring Event Configuration for a UE is to be deleted in the HSS (i.e. SCEF responds to a Monitoring Event Report with DIAMETER_ERROR_SCEF_REFERENCE_ID_UNKNOWN). Emergency Services (See 3GPPÊTSÊ29.273Ê[59]) Emergency-Services C The MME shall include this information element, and set the Emergency-Indication flag, to notify the HSS that a new PDN-GW has been selected for the establishment of an emergency PDN connection, whose identify is conveyed in the ""PDN GW Identity"" IE. Table 5.2.5.1.1/2: Notify Answer Information element name Mapping to Diameter AVP Cat. Description Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. 5.2.5.1.2 Detailed behaviour of the MME and the SGSN If the MME or SGSN supports Emergency services, the MME or SGSN shall not make use of the Notification procedure for emergency attached unauthenticated UEs; for authenticated UEs, the MME shall make use of the Notification procedure to inform the HSS about the PDN-GW selected to establish emergency PDN connections, if the MME is configured to use a dynamic PGW for emergency services for such UEs. The MME or SGSN shall not make use of the Notification procedure to inform the HSS about the identity of the dynamically selected PDN-GW, if the access restrictions indicate that the user is not allowed to get service via non-3GPP access, or the PDN type of the APN is of type ""non-IP"". The MME or SGSN shall include conditional AVPs in NOR according to the description given in table 5.2.5.1.1/1. If the MME sends a Notify Request to inform the HSS that the UE has become reachable again, the MME shall clear the corresponding URRP-MME for the UE. If the SGSN sends a Notify Request to inform the HSS that the UE has become reachable again, the SGSN shall clear the corresponding URRP-SGSN for the UE. If the MME sends a Notify Request to inform the HSS about the presence of the UE to receive one or more short messages, the MME shall clear the corresponding MNRF for the UE. If the SGSN sends a Notify Request to inform the HSS about the presence of the UE to receive one or more short messages, the SGSN shall clear the corresponding MNRG for the UE. If the MME or SGSN determines that it needs to update the Homogeneous Support of IMS Voice Over PS Sessions in the HSS, the MME or SGSN shall send a Notify Request with the ""Homogeneous Support of IMS Voice Over PS Sessions"" bit set in the NOR-Flags AVP; if there is homogeneous support, or homogeneous non-support, of IMS Voice Over PS Sessions, the MME or SGSN shall report it by including the updated Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP; if the support is not homogeneous, the MME or SGSN shall report it by leaving such AVP absent in the Notify Request to the HSS. MME or SGSN shall ensure the status of Homogeneous Support of IMS Voice Sessions in HSS does not contradict with the value of ""IMS voice over PS session indicator"" provided to UE over NAS as specified in 3GPPÊTSÊ24.008Ê[31] and 3GPPÊTSÊ24.301Ê[64]; if ""IMS voice over PS session indicator"" sent to UE has changed from ""not supported"" to ""supported"" when status Homogenous Support of IMS Voice in HSS is ""not supported"", MME or SGSN shall immediately send Notify Request indicating as either homogenous support or not homogeneous; if ""IMS voice over PS session indicator"" sent to UE has changed from ""supported"" to ""not supported"" when status Homogenous Support of IMS Voice in HSS is ""supported"", MME or SGSN shall immediately send Notify Request indicating as either homogenous non-support or not homogeneous. If the MME needs to indicate to the HSS that it is no longer registered for SMS in the HSS, the MME shall send a Notify Request with ""Removal of MME Registration for SMS"" flag set in the NOR-Flags AVP. When receiving a Notify response from the HSS, if the result code indicates DIAMETER_ERROR_UNKNOWN_SERVING_NODE, the MME or SGSN shall consider the Notification procedure as failed, and it shall mark the subscriber record as ""Subscriber to be restored in HSS"". When receiving a Notify response from the HSS, if the result code indicates DIAMETER_ERROR_USER_UNKNOWN, the MME or SGSN shall detach the subscriber and remove the subscriber from its database. If the MME/SGSN has received the monitoring event configurations in an ULA command and one, several or all event detections fail to be started (e.g due to maximum resources exceeded), the MME/SGSN shall send the Notify Request command with the Monitoring-Event-Config-Status AVP for the failed monitoring event configurations. If the MME or SGSN receives a failure response, e.g. DIAMETER_UNABLE_TO_COMPLY, corresponding to a Notify Request to notify the HSS about the selected PDN-GW, the MME or SGSN shall not trigger a detach for the subscriber based only on this failure. NOTE 1: A failure to indicate the selected PDN-GW to the HSS does not impact connectivity provided via 3GPP access. When the MME/SGSN has received the Configuration-Information-Answer from the IWK-SCEF during the monitoring event configuration procedure, the MME/SGSN shall send the Notify Request command with the Monitoring-Event-Config-Status AVP as received from the IWK-SCEF in the Configuration-Information-Answer, for the monitoring event configurations whose status have changed (due to authorization performed by the IWK-SCEF) since last informed to the HSS. NOTE 2: If the Monitoring-Event-Configuration was received at the MME/SGSN in the ULA command, then the HSS is not yet informed of any status of the monitoring event configuration. In this case, the entire Monitoring-Event-Config-Status as received from IWK-SCEF has to be transferred to the HSS through a Notify Request Command. If the MME or SGSN determines that a Monitoring Event Configuration for a UE is to be deleted in the HSS (i.e. SCEF responds to a Monitoring Event Report with DIAMETER_ERROR_SCEF_REFERENCE_ID_UNKNOWN), the MME or SGSN shall send a Notify Request with the Monitoring-Event-Config-Status AVP. The Monitoring-Event-Config-Status AVP shall include the error as received from SCEF. 5.2.5.1.3 Detailed behaviour of the HSS When receiving a Notify request the HSS shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If the IMSI is known, and the source MME or SGSN originating the Notify message is not currently registered in HSS for that UE, a result code of DIAMETER_ ERROR_ UNKNOWN_SERVING_NODE shall be returned. If the IMSI is known, and the source MME or SGSN is currently registered in HSS, the HSS shall set the result code to DIAMETER_SUCCESS, unless otherwise stated, and - store the new terminal information if present in the request; - store the new UE SRVCC capability if present in the request; - store the new PDN GW and PLMN ID for an APN if present in the request and the APN is present in the subscription and if PDN GW is dynamically allocated; otherwise the HSS shall not store the new PDN GW data and shall set the result code to DIAMETER_ UNABLE_TO_COMPLY; - store the new PDN GW and PLMN ID, and the APN itself, if both are present in the request, and the APN is not present in the subscription but a wild card APN is present in the subscription; - if the Emergency Services IE is present, with the Emergency-Indication flag set, store the new PDN GW, as the PDN GW used to establish emergency PDN connections; the HSS shall store this information not bound to any specific APN; - mark the location area as ""restricted"" if so indicated in the request; - send Cancel Location to the current SGSN if so indicated in the request; - if the UE has become reachable again, and NOR is received on S6a from an MME or on S6d from an SGSN, the HSS shall respectively clear the URRP-MME or the URPP-SGSN parameter for the UE and send an indication t of UE reachability from MME or SGSN o the Service Related Entities if there is any; - when NOR is received on S6d from an SGSN (with the Alert Reason present), the HSS shall reset the MNRG flag and send a MAP-Alert-Service-Centre message or S6c-Alert-Service-Centre-Request (see 3GPPÊTSÊ29.338Ê[48], i.e. the behaviour in the HSS should be the same as when a MAP-Ready for SM is received from an SGSN; - when NOR is received on S6a from an MME (with the Alert Reason present), the HSS shall reset the MNRF flag and send a MAP-Alert-Service-Centre message or S6c-Alert-Service-Centre-Request (see 3GPPÊTSÊ29.338Ê[48], i.e. the behaviour in the HSS should be the same as when a MAP-Ready for SM is received from a VLR/MSC; - when NOR is received on S6a from an MME or on S6d from an SGSN to update the Homogeneous Support of IMS Voice Over PS Sessions, the HSS shall store the updated Homogeneous Support of IMS Voice Over PS Sessions and may use this information in the future in order to skip the T-ADS data retrieval, as described in clauseÊ5.2.2.1 (IDR/IDA commands). If the ""Homogeneous Support of IMS Voice Over PS Sessions"" bit is set in the NOR-Flags AVP received but without Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP present in the NOR message, the HSS shall take the Homogeneous Support of IMS Voice Over PS Sessions as unknown to the serving node. If the ""Homogeneous Support of IMS Voice Over PS Sessions"" bit is not set in the NOR-Flags AVP, the HSS shall ignore (if present) the Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP; - when NOR is received on S6a from an MME for removal of MME registration for SMS, the HSS shall remove the MME registration for SMS and the ""MME number for SMS"" as the corresponding MSC number to be used for MT SMS. - when NOR is received on S6a from an MME or on S6d from an SGSN with the Monitoring-Event-Config-Status AVP, the HSS shall either trigger a Monitoring event cancelation procedure for the monitoring events that were not successfully authorized at the MME/SGSN by the IWK-SCEF or a Monitoring event suspension procedure for the monitoring events that were not successfully configured at the MME/SGSN, as specified in clauseÊ7.2.2.2 of 3GPPÊTSÊ29.336Ê[54]. The HSS shall trigger a Monitoring event cancelation or suspension procedure based on the result code as indicated by MME/SGSN (e.g. DIAMETER_ERROR_UNAUTHORIZED_REQUESTING_ENTITY (5510) returned by IWK-SCEF triggers a Monitoring event cancelation procedure in HSS). - when NOR is received on S6a from an MME or on S6d from an SGSN with an indication of the deletion of a monitoring event configuration in SCEF (DIAMETER_ERROR_SCEF_REFERENCE_ID_UNKNOWN in the Monitoring-Event-Config-Status AVP), the HSS shall locally delete the corresponding Monitoring Event Configuration and shall not trigger a Monitoring event cancelation procedure. and then send the response to the MME or SGSN. 5A MME Ð CSS (S7a) and SGSN Ð CSS (S7d) 5A.1 Introduction The S7a interface enables the transfer of subscriber related CSG data in the VPLMN between the MME and the CSS as described in 3GPPÊTSÊ23.401Ê[2]. The S7d interface enables the transfer of subscriber related CSG data in the VPLMN between the SGSN and the CSS as described in 3GPPÊTSÊ23.060Ê[12]. 5A.2 Mobility Services 5A.2.1 Location Management Procedures 5A.2.1.1 Update VCSG Location 5A.2.1.1.1 General The Update VCSG Location Procedure shall be used between the MME and the CSS or between the SGSN and the CSS to update location information in the CSS or retrieve the CSG subscription data of the UE from the CSS. The procedure allows: - to inform the CSS about the identity of the MME or SGSN currently serving the user, - to update MME or SGSN with user CSG subscription data received from the CSS. This procedure is mapped to the commands Update-VCSG-Location-Request/Answer (UVR/UVA) in the Diameter application specified in clause 7. Table 5A.2.1.1.1/1 specifies the involved information elements for the request. Table 5A.2.1.1.1/2 specifies the involved information elements for the answer. Table 5A.2.1.1.1/1: Update VCSG Location Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. MSISDN MSISDN C This information element shall contain the user MSISDN, formatted according to 3GPPÊTSÊ29.329Ê[25]. It shall be present if available. UVR Flags (See 7.3.153) UVR-Flags M This Information Element contains a bit mask. See 7.3.153 for the meaning of the bits. SGSN number (See 7.3.102) SGSN-Number C This Information Element contains the ISDN number of the SGSN, see 3GPPÊTSÊ23.003Ê[3]. It shall be present when the message is sent on the S7d interface. It may be present when the message on the S7a interface and the requesting node is a combined MME/SGSN. Table 5A.2.1.1.1/2: Update VCSG Location Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S7a/S7d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable: - User Unknown VPLMN CSG Subscription Data (See 7.3.155) VPLMN-CSG-Subscription-Data C This Information Element shall contain the list of CSG Ids and the associated expiry dates stored in the CSS. It shall be present if success is reported, unless an explicit ""skip subscriber data"" indication was present in the request or the Temporary Empty VPLMN CSG Subscription Data flag is set. UVA Flags (See 7.3.154) UVA-Flags C This Information Element contains a bit mask. See 7.3.154 for the meaning of the bits. 5A.2.1.1.2 Detailed behaviour of the MME and the SGSN The MME or SGSN shall make use of this procedure to register the UE in the CSS and to retrieve the ""CSG subscription data from CSS"" when: - the VPLMN supports Autonomous CSG Roaming - and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN - and the UE has requested an initial attach or a tracking area procedure or a routing area procedure to a CSG cell - and the MME or SGSN have not yet registered the UE in the CSS. If the Autonomous CSG Roaming in the VPLMN is not supported or is not allowed by the HPLMN of the subscriber, the MME or SGSN shall not make use of the Update CSG Location procedure. For UEs receiving emergency services, in which the UE was not successfully authenticated, the MME or SGSN shall not make use of the Update VCSG Location procedure. A combined MME/SGSN shall set the ""Skip Subscriber Data"" flag in the UVR-Flags if the ""CSG subscription data from CSS"" are already available due to a previously VCSG Location updating. A combined MME/SGSN that has chosen the option to include the SGSN Number within an Update VCSG Request sent over S7a shall be prepared to receive a single CSG subscription data update message from the CSS when the CSG subscription data is modified in the CSS. When receiving an Update VCSG Location Answer from the CSS, the MME or SGSN shall check the result code."
"If it indicates success the MME or SGSN shall delete all the stored ""CSG subscription data from CSS"" (if any) and then store the received ""CSG subscription data from the CSS"" (if any), and it shall store the CSS identity as received in the Origin-Host AVP. If the same CSG Id exists in both ""CSG subscription data from CSS"" and ""CSG subscription data from HSS"", the ""CSG subscription data from HSS"" shall take precedence over the ""CSG subscription data from CSS"" in further use. If an error response is received from the CSS, the MME or SGSN shall not reject the UE and shall end the procedure when the UE is attaching to a normal cell. If the UE is attaching to a CSG cell, in this case the MME or SGSN shall check if there is such CSG Id from the HSS. If there is no such CSG Id, the MME or SGSN shall reject the UE. 5A.2.1.1.3 Detailed behaviour of the CSS When receiving an Update VCSG Location request the CSS shall check whether the user is known. If the user is not known, and if the Update VCSG Location Request is received over the S7a/S7d interface, the CSS may: - store the MME or SGSN identity received within the Origin-Host AVP, and include the UVA-Flags AVP with ""Temporary Empty VPLMN CSG Subscription Data"" flag set, and return a Result Code of DIAMETER_ SUCCESS, or - return a Result Code of DIAMETER_ERROR_USER_UNKNOWN. NOTE: A mechanism is needed in the CSS to associate the CSG subscription data of the user with the received IMSI. If the Update VCSG Location Request is received over the S7a/S7d interface, the CSS shall replace the stored MME or SGSN identity with the received value (the identity is received within the Origin-Host AVP). If no result code indicating an error is sent to the MME or SGSN, the CSS shall include the VPLMN CSG subscription data in the Update VCSG Location Answer unless an explicit ""skip subscriber data"" indication has been received in the request, and shall return a Result Code of DIAMETER_SUCCESS. 5A.2.1.2 Cancel VCSG Location 5A.2.1.2.1 General The Cancel VCSG Location Procedure shall be used between the CSS and the MME and between the CSS and the SGSN. The procedure shall be invoked by the CSS and is used: - to inform the MME or SGSN about the subscriber's VCSG subscription withdrawal by the CSS operator and the removal of their registration in the CSS. This procedure is mapped to the commands Cancel-VCSG-Location-Request/Answer (CVR/CVA) in the Diameter application specified in clause 7. Table 5A.2.1.2.1/1 specifies the involved information elements for the request. Table 5A.2.1.2.1/2 specifies the involved information elements for the answer. Table 5A.2.1.2.1/1: Cancel VCSG Location Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Cancellation Type (See 7.3.24) Cancellation-Type M Defined values that can be used are: - Subscription Withdrawal, applied to the VPLMN CSG subscription. Table 5A.2.1.2.1/2: Cancel VCSG Location Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M The result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). 5A.2.1.2.2 Detailed behaviour of the MME and the SGSN When receiving a Cancel VCSG Location request the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_SUCCESS is returned. If it is known, the MME or SGSN shall check if the Cancellation Type is Subscription Withdrawal. In this case, the MME or SGSN shall remove the information of their registration in the CSS and the stored VPLMN CSG subscription if any. Also in this case a result code of DIAMETER_SUCCESS is returned. When a UE is served by a single combined MME/SGSN for both E-UTRAN and non-E-UTRAN access, the combined MME/SGSN shall check if the Cancellation Type is Subscription Withdrawal. In this case, the Cancel VCSG Location request is processed both in the MME part and in the SGSN part of the combined node. 5A.2.1.2.3 Detailed behaviour of the CSS The CSS shall make use of this procedure when the user's VPLMN CSG subscription is withdrawn by the CSS operator and shall include a cancellation type of ""Subscription Withdrawal. 5A.2.2 Subscriber Data Handling Procedures 5A.2.2.1 Insert VCSG Subscriber Data 5A.2.2.1.1 General The Insert VCSG Subscriber Data Procedure shall be used between the CSS and the MME and between the CSS and the SGSN for updating CSG subscription data in the MME or SGSN in the following situations: - due to administrative changes of the user data in the CSS and the user is now located in an MME or SGSN, i.e. if the user was given a CSG subscription and the CSG subscription has changed; If the CSS knows that the UE has attached to the same combined MME/SGSN via both the E-UTRAN and UTRAN/GERAN, i.e. the CSS has received the Update VCSG Location Request over both the S7a interface and S7d interface respectively with the same SGSN number, the CSS should invoke this procedure for a single time to update CSG subscription data in the combined MME/SGSN, i.e. the CSS should not invoke this procedure for each of the MME and the SGSN registered respectively. This procedure is mapped to the commands Insert-Subscriber Data-Request/Answer (IDR/IDA) in the Diameter application specified in clauseÊ7. Table 5A.2.2.1.1/1 specifies the involved information elements for the request. Table 5A.2.2.1.1/2 specifies the involved information elements for the answer. Table 5A.2.2.1.1/1: Insert VCSG Subscriber Data Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. VPLMN CSG Subscription Data (See 7.3.2) VPLMN-CSG-Subscription-Data M This Information Element shall contain the list of CSG Ids and the associated expiry dates stored in the VPLMN CSS. Table 5A.2.2.1.1/2: Insert VCSG Subscriber Data Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. Result-Code AVP shall be used to indicate success / errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]).The Experimental-Result AVP shall be used for S7a/S7d errors. This is a grouped AVP which shall contain the 3GPP Vendor Id in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown. 5A.2.2.1.2 Detailed behaviour of the MME and the SGSN When receiving an Insert VCSG Subscriber Data request, the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If the request does not contain any CSG-Subscription-Data AVP, Experimental-Result shall be set to DIAMETER_ERROR_SUBS_DATA_ABSENT. If the request contains at least one CSG-Subscription-Data AVPs, the MME or SGSN shall delete all the stored ""CSG subscription data from CSS"" (if any), and then store the received ""CSG subscription data from CSS"". If the MME or SGSN cannot fulfil the received request, e.g. due to a database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. If the same CSG Id exists in both ""CSG subscription data from CSS"" and ""CSG subscription data from HSS"", the ""CSG subscription data from HSS"" shall take precedence over the ""CSG subscription data from CSS"" in further use. 5A.2.2.1.3 Detailed behaviour of CSS The CSS shall make use of this procedure to delete the ""CSG subscription data from CSS"" stored in the MME or SGSN and replace them with the CSG subscription data sent. If the CSS receives a Insert VCSG Subscriber Data answer with the Result Code DIAMETER_ERROR_USER_UNKNOWN, the CSS shall clear the stored MME or SGSN identity. 5A.2.2.2 Delete VCSG Subscriber Data 5A.2.2.2.1 General This procedure shall be used between the CSS and the MME or between the CSS and the SGSN, to remove all the ""CSG subscription data from CSS"" stored in the MME or SGSN. The procedure shall be invoked by the CSS. If the CSS knows that the UE has attached to the same combined MME/SGSN via both E-UTRAN and UTRAN/GERAN, i.e. the CSS has received the Update VCSG Location Request over both the S7a interface and S7d interface respectively with the same SGSN number, the CSS should invoke this procedure for a single time to remove all the ""CSG subscription data from CSS"" stored in the combined MME/SGSN, i.e. not invoke this procedure for each of the MME and the SGSN registered respectively. This procedure is mapped to the commands Delete-Subscriber-Data-Request/Answer (DSR/DSA) in the S7a/S7d Diameter application specified in clauseÊ7. Table 5A.2.2.2.1/1 specifies the involved information elements for the request. Table 5A.2.2.2.1/2 specifies the involved information elements for the answer. Table 5A.2.2.2.1/1: Delete VCSG Subscriber Data Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. DSR Flags (See 7.3.25) DSR-Flags M This Information Element shall contain a bit mask. See 7.3.25 for the meaning of the bits. Table 5A.2.2.2.1/2: Delete VCSG Subscriber Data Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S7a/S7d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown 5A.2.2.2.2 Detailed behaviour of the MME and the SGSN When receiving a Delete VCSG Subscriber Data request, the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If it is known, the MME or SGSN shall delete all the stored ""CSG subscription data from CSS"". If the deletion of the subscription data succeeds in the MME or SGSN, the Result-Code shall be set to DIAMETER_SUCCESS. If the MME or SGSN cannot fulfil the received request for other reasons, e.g. due to a database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. 5A.2.2.2.3 Detailed behaviour of the CSS The CSS shall make use of this procedure to remove all the CSG subscription data associated to CSS from the MME or SGSN. NOTE: When a Delete VCSG Subscriber Data procedure occurs, the MME or SGSN remains registered in the CSS If the CSS receives a Delete VCSG Subscriber Data answer with the Result Code DIAMETER_ERROR_USER_UNKNOWN from the MME or SGSN, the CSS shall clear the stored MME or SGSN identity. 5A.2.3 Fault Recovery Procedures 5A.2.3.1 VCSG Reset 5A.2.3.1.1 General The VCSG Reset Procedure shall be used by the CSS, after a restart, to indicate to the MME and to the SGSN that a failure has occurred. This procedure is mapped to the commands Reset-Request/Answer (RSR/RSA) in the S7a/S7d Diameter application specified in clause 7. Table 5A.2.3.1.1/1 specifies the involved information elements for the request. Table 5A.2.3.1.1/2 specifies the involved information elements for the answer. Table 5A.2.3.1.1/1: VCSG Reset Request Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Table 5A.2.3.1.1/2: VCSG Reset Answer Information element name Mapping to Diameter AVP Cat. Description Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S7a/S7d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. There are no Experimental-Result codes applicable for this command. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. 5A.2.3.1.2 Detailed behaviour of the MME and the SGSN When receiving a VCSG Reset message, the MME or SGSN or combined MME/SGSN, for all roaming users for which they have a registration in CSS, shall mark ""Location Information Confirmed in CSS"" record as ""Not Confirmed"". The MME or SGSN or combined MME/SGSN shall make use of the CSS Identity received in the Origin-Host AVP (by comparing it with the value stored after successful ULA) in order to determine which user records are impacted. When, as described in 3GPPÊTSÊ23.007Ê[43], an event requiring the MME or SGSN to check the ""CSG subscription data from CSS"" occurs, and if the user record ""Location Information Confirmed in CSS"" is marked as ""Not Confirmed"", the restoration procedure shall be triggered. 5A.2.3.1.3 Detailed behaviour of the CSS The CSS shall make use of this procedure in order to indicate to all relevant MMEs, SGSNs, and combined MME/SGSNs that the CSS has restarted and may have lost the current MME-Identity and SGSN-Identity of some of its users who may be currently roaming in the MME area and/or SGSN area, and to which the CSS, therefore, cannot send e.g. Insert VCSG Subscriber Data messages when needed. The CSS should invoke this procedure towards a combined MME/SGSN only for a single time even if some of the impacted subscribers are attached to the combined MME/SGSN via UTRAN/GERAN and some of the impacted subscribers are attached to the combined MME/SGSN via E-UTRAN. 6 MME Ð EIR (S13) and SGSN Ð EIR (S13') 6.1 Introduction The S13 interface shall enable the ME Identity check procedure between the MME and the EIR as described in the 3GPPÊTSÊ23.401Ê[2]. The S13' interface shall enable the ME Identity check procedure between the SGSN and the EIR as described in the 3GPPÊTSÊ23.060Ê[12]. 6.2 ME Identity Check Procedures 6.2.1 ME Identity Check 6.2.1.1 General This Mobile Equipment Identity Check Procedure shall be used between the MME and the EIR and between the SGSN and the EIR to check the Mobile Equipment's identity status (e.g. to check that it has not been stolen, or, to verify that it does not have faults). This procedure is mapped to the commands ME-Identity-Check-Request/Answer (ECR/ECA) in the Diameter application specified in clause 6. Table 6.2.1.1/1 specifies the involved information elements for the request. Table 6.2.1.1/2 specifies the involved information elements for the answer. Table 6.2.1.1/1: ME Identity Check Request Information element name Mapping to Diameter AVP Cat. Description Terminal Information (See 7.3.3) Terminal-Information M This information element shall contain the information about the used mobile equipment i.e. the IMEI. Within this Information Element, only the IMEI and the Software-Version AVPs shall be used on the S13/S13' interface. IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) O This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Table 6.2.1.1/2: ME Identity Check Answer Information element name Mapping to Diameter AVP Cat. Description Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S13/S13' errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - Unknown equipment Equipment Status (See 7.3.51) Equipment-Status C This information element shall contain the status of the requested mobile equipment as defined in 3GPPÊTSÊ22.016Ê[13]. It shall be present if the result of the ME Identity Check is DIAMETER_SUCCESS. 6.2.1.2 Detailed behaviour of the MME and the SGSN The MME or the SGSN shall make use of this procedure to check the ME identity, if the MME or the SGSN is configured to check the IMEI with the EIR. Terminal-Information, when sent by the MME/SGSN to the EIR, shall contain the IMEI AVP, and it may contain also the Software-Version AVP. IMSI may be sent together with Terminal Information to the EIR for operator-determined purposes. When receiving the ME Identity Check answer from the EIR, the MME or the SGSN shall check the result code and the equipment status. Dependent upon the result, the MME or the SGSN will decide its subsequent actions (e.g. sending an Attach Reject if the EIR indicates that the Mobile Equipment is unknown or prohibited listed). 6.2.1.3 Detailed behaviour of the EIR When receiving an ME Identity Check request, the EIR shall check whether the mobile equipment is known. The EIR shall identify the mobile equipment based on the first 14 digits of the IMEI AVP; if a 15th digit is received in the IMEI AVP, this digit shall be ignored by the EIR. Based on operator policies, the EIR may also use the Software-Version AVP, in addition to the first 14 digits of the IMEI AVP, to check the equipment identity against prohibited and tracking lists (see 3GPPÊTSÊ22.016Ê[13]). If the mobile equipment identity is not known, a result code of DIAMETER_ERROR_ EQUIPMENT_UNKNOWN is returned. If it is known, the EIR shall return DIAMETER_SUCCESS with the equipment status. 7 Protocol Specification and Implementation 7.1 Introduction 7.1.1 Use of Diameter base protocol The Diameter base protocol as specified in IETFÊRFCÊ6733Ê[61] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and error codes as specified in this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) shall be used unmodified. 7.1.2 Securing Diameter Messages For secure transport of Diameter messages, see 3GPPÊTSÊ33.210Ê[16]. If there are no intermediate Diameter Agent networks located between the visited PLMN and the home PLMN, the HSS or the first Diameter Agent located in the home PLMN which has direct connection with the serving network is required to check that the realm contained in the Origin-Realm AVP in the request from the serving network corresponds to the right serving network. If there are intermediate Diameter Agent networks located between the visited PLMN and home PLMN, the first Diameter Agent which has direct connection with the serving network is required to check that the realm contained in the Origin-Realm AVP in the request from the serving network corresponds to the right serving network. NOTE 1: How to do the above check is implementation specific, e.g. it may be done by checking if the IP addresses of the serving network nodes match with the realm received in the Origin-Realm AVP in the request. NOTE 2: Network configurations where a (potential) visited PLMN acts as intermediate Diameter Agent network are not allowed. NOTE 3: In the case there are intermediate Diameter Agent networks, the home network has to trust these intermediate Diameter agent networks to do the check and other hop by hop security check. This trust is usually substantiated by contracts since there are no remote technical means to verify if the checks were actually performed. 7.1.3 Accounting functionality Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the S6a, S6d, S13 and S13' interfaces. 7.1.4 Use of sessions Between the MME and the HSS and between the SGSN and the HSS and between the MME and the EIR, Diameter sessions shall be implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client shall not send any re-authorization or session termination requests to the server. The Diameter base protocol specified in IETFÊRFCÊ6733Ê[61] includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions. The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETFÊRFCÊ6733Ê[61]. As a consequence, the server shall not maintain any state information about this session and the client shall not send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 7.1.5 Transport protocol Diameter messages over the S6a, S6d, S13, S13', S7a and S7d interfaces shall make use of SCTP IETFÊRFCÊ4960Ê[14]. 7.1.6 Routing considerations This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host. If an MME or SGSN knows the address/name of the HSS for a certain user, and the associated home network domain name, both the Destination-Realm and Destination-Host AVPs shall be present in the request. NOTE: When sending a ULR command for a certain user due to HSS restoration procedure (i.e, after the MME/SGSN have received a Reset command from the HSS), the MME or the SGSN might consider the stored address/name of the HSS for the user to be invalid and hence not known. If an MME or SGSN knows only the home network domain name for a certain user, the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node. If an MME or SGSN knows only the identity of the user, the home network domain name shall be derived from the user's IMSI (MNC and MCC values) to construct the EPC Home Network Realm/Domain, as indicated in 3GPPÊTSÊ23.003Ê[3], clauseÊ19.2, and use it as Destination-Realm. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an MME or SGSN. The address/name of the EIR shall be locally configured in the MME. Requests initiated by the HSS towards an MME or SGSN shall include both Destination-Host and Destination-Realm AVPs. The HSS obtains the Destination-Host AVP to use in requests towards an MME or SGSN, from the Origin-Host AVP received in previous requests from the MME or SGSN. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the HSS. The Origin-Host AVP received in requests from the MME may contain a Diameter identity of the MME encoded as specified in clauseÊ19.4.2.4 of 3GPPÊTSÊ23.003Ê[3]. The Origin-Host AVP received in requests from the SGSN may contain a Diameter identity of the SGSN encoded as specified in clauseÊ19.4.2.6 of 3GPPÊTSÊ23.003Ê[3]. The HSS obtains the Destination-Realm AVP to use in requests towards an MME or SGSN, from the Origin-Realm AVP received in previous requests from the MME or SGSN. The Origin-Realm AVP in the requests received by the HSS in roaming cases, should contain the domain name of the network to which the MME or the SGSN belongs, encoded as specified in clauseÊ19.2 of 3GPPÊTSÊ23.003Ê[3]. The Destination-Realm AVP is declared as mandatory in the ABNF for all requests. If the Vendor-Specific-Application-ID AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node, and it shall not be used for routing purposes. 7.1.7 Advertising Application Support The HSS, MME, SGSN and EIR shall advertise support of the Diameter S6a/S6d and/or S13/S13' Application by including the value of the application identifier in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The vendor identifier value of 3GPP (10415) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETFÊRFCÊ6733Ê[61]. 7.1.8 Diameter Application Identifier This clause specifies three Diameter applications: The S6a/S6d interface application, the S13/S13' interface application, and the S7a/S7d interface application. The S6a/S6d interface application allows a Diameter server and a Diameter client: - to exchange location information; - to authorize a user to access the EPS; - to exchange authentication information; - to download and handle changes in the subscriber data stored in the server. The S6a/S6d interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the S6a/S6d interface application is 16777251 (allocated by IANA). The S13/S13' interface application allows a Diameter server and a Diameter client: - to check the validity of the ME Identity. The S13/S13' interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the S13/S13' interface application is 16777252 (allocated by IANA). The S7a/S7d interface application allows a Diameter server and a Diameter client: - to authorize a user to access CSGs identified in the CSS while roaming; - to download and handle changes in CSG subscriber data stored in the CSS. The S7a/S7d interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the S7a/S7d interface application is 16777308 (allocated by IANA). 7.1.9 Use of the Supported-Features AVP When new functionality is introduced on the S6a/S6d interfaces, it should be defined as optional. If backwards incompatible changes can not be avoided, the new functionality shall be introduced as a new feature and support advertised with the Supported-Features AVP. The usage of the Supported-Features AVP on the S6a/S6d interfaces is consistent with the procedures for the dynamic discovery of supported features as defined in clauseÊ7.2 of 3GPPÊTSÊ29.229Ê[9]. When extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF. As defined in 3GPPÊTSÊ29.229Ê[9], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the all reference points as specified in this specificaion, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another. The Table 7.3.10/1 defines the features applicable to the S6a/S6d interfaces for the feature list with a Feature-List-ID of 1. The Table 7.3.10/2 defines the features applicable to the S6a/S6d interfaces for the feature list with a Feature-List-ID of 2. NOTE 1: If the support of a feature by the receiver is required in order for the receiver to be able to correctly process the request command, then the feature is included in the Supported-Features AVP and the M-bit of the Supported-Features AVP has to be set in the request command, according to 3GPPÊTSÊ29.229Ê[9] clauseÊ7.2.1. NOTE 2: Currently none of the features that can be included in the Supported-Features AVP of the ULR command requires that the HSS supports them to successfully process the ULR command. For this reason the MME or SGSN does not need to set the M-bit of the Supported-Features AVP in the ULR command. This corresponds to the exception to the general rule requiring the setting of the M-bit of the Supported-Features AVP in a request described in 3GPPÊTSÊ29.229Ê[9] clauseÊ7.2.1. Setting the M-bit of the Supported-Features AVP in the ULR command will mean that, if any of the features is not supported, the HSS will reject the ULR command as according to 3GPPÊTSÊ29.229Ê[9] clauseÊ7.2.1. 7.2 Commands 7.2.1 Introduction This clause defines the Command code values and related ABNF for each command described in this specification. 7.2.2 Command-Code values This clause defines Command-Code values for the S6a/S6d interface application and S13/S13' interface application as allocated by IANA in the IETFÊRFCÊ5516Ê[32]. Every command is defined by means of the ABNF syntax IETFÊRFCÊ2234Ê[7], according to the Command Code Format (CCF) specification defined in IETFÊRFCÊ6733Ê[61]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETFÊRFCÊ6733Ê[61] shall apply. The Vendor-Specific-Application-Id AVP shall not be included in any command sent by Diameter nodes supporting applications defined in this specification. If the Vendor-Specific-Application-Id AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node. NOTE: The Vendor-Specific-Application-Id is included as an optional AVP in all Command Code Format specifications defined in this specification in order to overcome potential interoperability issues with intermediate Diameter agents non-compliant with the IETFÊRFCÊ6733Ê[61]. The following Command Codes are defined in this specification: Table 7.2.2/1: Command-Code values for S6a/S6d Command-Name Abbreviation Code Clause Update-Location-Request ULR 316 7.2.3 Update-Location-Answer ULA 316 7.2.4 Cancel-Location-Request CLR 317 7.2.7 Cancel-Location-Answer CLA 317 7.2.8 Authentication-Information-Request AIR 318 7.2.5 Authentication-Information-Answer AIA 318 7.2.6 Insert-Subscriber-Data-Request IDR 319 7.2.9 Insert-Subscriber-Data-Answer IDA 319 7.2.10 Delete-Subscriber-Data-Request DSR 320 7.2.11 Delete-Subscriber-Data-Answer DSA 320 7.2.12 Purge-UE-Request PUR 321 7.2.13 Purge-UE-Answer PUA 321 7.2.14 Reset-Request RSR 322 7.2.15 Reset-Answer RSA 322 7.2.16 Notify-Request NOR 323 7.2.17 Notify-Answer NOA 323 7.2.18 For these commands, the Application-ID field shall be set to 16777251 (application identifier of the S6a/S6d interface application, allocated by IANA). Table 7.2.2/2: Command-Code values for S13/S13' Command-Name Abbreviation Code Clause ME-Identity-Check-Request ECR 324 7.2.19 ME-Identity-Check-Answer ECA 324 7.2.20 For these commands, the Application-ID field shall be set to 16777252 (application identifier of the S13/S13' interface application, allocated by IANA). Table 7.2.2/3: Command-Code values for S7a/S7d Command-Name Abbreviation Code Clause Update-VCSG-Location-Request UVR 8388638 7.2.21 Update-VCSG-Location-Answer UVA 8388638 7.2.22 Insert-Subscription-Data-Request IDR 319 7.2.9 Insert-Subscription-Data-Answer IDA 319 7.2.10 Delete-Subscriber-Data-Request DSR 320 7.2.11 Delete-Subscriber-Data-Answer DSA 320 7.2.12 Reset-Request RSR 322 7.2.15 Reset-Answer RSA 322 7.2.16 Cancel-VCSG-Location-Request CVR 8388642 7.2.23 Cancel-VCSG-Location-Answer CVA 8388642 7.2.24 For these commands, the Application-ID field shall be set to 16777308 (application identifier of the S7a/S7d interface application, allocated by IANA). 7.2.3 Update-Location-Request (ULR) Command The Update-Location-Request (ULR) command, indicated by the Command-Code field set to 316 and the ""R"" bit set in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Update-Location-Request> ::= < Diameter Header: 316, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] [ Terminal-Information ] { RAT-Type } { ULR-Flags } [UE-SRVCC-Capability ] { Visited-PLMN-Id } [ SGSN-Number ] [ Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions ] [ GMLC-Address ] *[ Active-APN ] [ Equivalent-PLMN-List ] [ MME-Number-for-MT-SMS ] [ SMS-Register-Request ] [ SGs-MME-Identity ] [ Coupled-Node-Diameter-ID ] [ Adjacent-PLMNs ] [ Supported-Services ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.4 Update-Location-Answer (ULA) Command The Update-Location-Answer (ULA) command, indicated by the Command-Code field set to 316 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Update-Location-Answer> ::= < Diameter Header: 316, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] [ Error-Diagnostic ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ ULA-Flags ] [ Subscription-Data ] *[ Reset-ID ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.5 Authentication-Information-Request (AIR) Command The Authentication-Information-Request (AIR) command, indicated by the Command-Code field set to 318 and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Authentication-Information-Request> ::= < Diameter Header: 318, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[Supported-Features] [ Requested-EUTRAN-Authentication-Info ] [ Requested-UTRAN-GERAN-Authentication-Info ] { Visited-PLMN-Id } [ AIR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.6 Authentication-Information-Answer (AIA) Command The Authentication-Information-Answer (AIA) command, indicated by the Command-Code field set to318 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Authentication-Information-Answer> ::= < Diameter Header: 318, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] [ Error-Diagnostic ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[Supported-Features] [ Authentication-Info ] [ UE-Usage-Type ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.7 Cancel-Location-Request (CLR) Command The Cancel-Location-Request (CLR) command, indicated by the Command-Code field set to 317 and the 'R' bit set in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Cancel-Location-Request> ::= < Diameter Header: 317, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[Supported-Features ] { Cancellation-Type } [ CLR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.8 Cancel-Location-Answer (CLA) Command The Cancel-Location-Answer (CLA) command, indicated by the Command-Code field set to 317 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Cancel-Location-Answer> ::= < Diameter Header: 317, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.9 Insert-Subscriber-Data-Request (IDR) Command The Insert-Subscriber-Data-Request (IDR) command, indicated by the Command-Code field set to 319 and the 'R' bit set in the Command Flags field, is sent from HSS or CSS to MME or SGSN. Message Format when used over the S6a or S6d application: < Insert-Subscriber-Data-Request> ::= < Diameter Header: 319, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features] { Subscription-Data} [ IDR- Flags ] *[ Reset-ID ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a or S7d application: < Insert-Subscriber-Data-Request> ::= < Diameter Header: 319, REQ, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] *{ VPLMN-CSG-Subscription-Data } *[ Reset-ID ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.10 Insert-Subscriber-Data-Answer (IDA) Command The Insert-Subscriber-Data-Answer (IDA) command, indicated by the Command-Code field set to 319 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS or CSS. Message Format when used over the S6a or S6d application: < Insert-Subscriber-Data-Answer> ::= < Diameter Header: 319, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ IMS-Voice-Over-PS-Sessions-Supported ] [ Last-UE-Activity-Time ] [ RAT-Type ] [ IDA-Flags ] [ EPS-User-State ] [ EPS-Location-Information ] [Local-Time-Zone ] [ Supported-Services ] *[ Monitoring-Event-Report ] *[ Monitoring-Event-Config-Status ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a or S7d application: < Insert-Subscriber-Data-Answer> ::= < Diameter Header: 319, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.11 Delete-Subscriber-Data-Request (DSR) Command The Delete-Subscriber Data-Request (DSR) command, indicated by the Command-Code field set to 320 and the 'R' bit set in the Command Flags field, is sent from HSS or CSS to MME or SGSN."
"Message Format when used over the S6a/S6d application: < Delete-Subscriber-Data-Request > ::= < Diameter Header: 320, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] { DSR-Flags } [ SCEF-ID ] *[ Context-Identifier ] [ Trace-Reference ] *[ TS-Code ] *[ SS-Code ] [ eDRX-Related-RAT ] *[ External-Identifier ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] The SCEF-ID shall be present when the flag ""Delete monitoring events"" in DSR-Flags AVP is set. Message Format when used over the S7a/S7d application: < Delete-Subscriber-Data-Request > ::= < Diameter Header: 320, REQ, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] { DSR-Flags } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.12 Delete-Subscriber-Data-Answer (DSA) Command The Delete-Subscriber Data-Answer (DSA) command, indicated by the Command-Code field set to 320 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS or CSS. Message Format when used over the S6a/S6d application: < Delete-Subscriber-Data-Answer> ::= < Diameter Header: 320, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ DSA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a /S7d application: < Delete-Subscriber-Data-Answer> ::= < Diameter Header: 320, PXY, 16777308> < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.13 Purge-UE-Request (PUR) Command The Purge-UE-Request (PUR) command, indicated by the Command-Code field set to 321 and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Purge-UE-Request> ::= < Diameter Header: 321, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] [ PUR-Flags ] *[ Supported-Features ] [ EPS-Location-Information ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.14 Purge-UE-Answer (PUA) Command The Purge-UE-Answer (PUA) command, indicated by the Command-Code field set to 321 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Purge-UE-Answer> ::= < Diameter Header: 321, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] [ PUA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.15 Reset-Request (RSR) Command The Reset-Request (RSR) command, indicated by the Command-Code field set to 322 and the 'R' bit set in the Command Flags field, is sent from HSS or CSS to MME or SGSN. Message Format when used over the S6a/S6d application: < Reset-Request> ::= < Diameter Header: 322, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } *[ Supported-Features ] *[ User-Id ] *[ Reset-ID ] [ Subscription-Data ] [ Subscription-Data-Deletion ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a /S7d application: < Reset-Request> ::= < Diameter Header: 322, REQ, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } *[ Supported-Features ] *[ Reset-ID ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.16 Reset-Answer (RSA) Command The Reset-Answer (RSA) command, indicated by the Command-Code field set to 322 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS or CSS. Message Format when used over the S6a/S6d application: < Reset-Answer> ::= < Diameter Header: 322, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a /S7d application: < Reset-Answer> ::= < Diameter Header: 322, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.17 Notify-Request (NOR) Command The Notify-Request (NOR) command, indicated by the Command-Code field set to 323 and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Notify-Request> ::= < Diameter Header: 323, REQ, PXY, 16777251 > < Session-Id > [ Vendor-Specific-Application-Id ] [ DRMP ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] [ Terminal-Information ] [ MIP6-Agent-Info ] [ Visited-Network-Identifier ] [ Context-Identifier ] [Service-Selection] [ Alert-Reason ] [ UE-SRVCC-Capability ] [ NOR-Flags ] [ Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions ] [ Maximum-UE-Availability-Time ] *[ Monitoring-Event-Config-Status ] [ Emergency-Services ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.18 Notify-Answer (NOA) Command The Notify-Answer (NOA) command, indicated by the Command-Code field set to 323 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Notify-Answer> ::= < Diameter Header: 323, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.19 ME-Identity-Check-Request (ECR) Command The ME-Identity-Check-Request (ECR) command, indicated by the Command-Code field set to 324 and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to EIR. Message Format < ME-Identity-Check-Request > ::= < Diameter Header: 324, REQ, PXY, 16777252 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { Terminal-Information } [ User-Name ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.20 ME-Identity-Check-Answer (ECA) Command The ME-Identity-Check-Answer (ECA) command, indicated by the Command-Code field set to 324 and the 'R' bit cleared in the Command Flags field, is sent from EIR to MME or SGSN. Message Format < ME-Identity-Check-Answer> ::= < Diameter Header: 324, PXY, 16777252 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Equipment-Status ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.21 Update-VCSG-Location-Request (UVR) Command The Update-VCSG-Location-Request (UVR) command, indicated by the Command-Code field set to 8388638 and the ""R"" bit set in the Command Flags field, is sent from MME or SGSN to CSS. Message Format < Update-VCSG-Location-Request> ::= < Diameter Header: 8388638, REQ, PXY, > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ MSISDN ] [ SGSN-Number ] *[ Supported-Features ] { UVR-Flags } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.22 Update-VCSG-Location-Answer (UVA) Command The Update-VCSG-Location-Answer (UVA) command, indicated by the Command-Code field set to 8388638 and the 'R' bit cleared in the Command Flags field, is sent from CSS to MME or SGSN. Message Format < Update-VCSG-Location-Answer> ::= < Diameter Header: 8388638, PXY, > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] [ Error-Diagnostic ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] *[ VPLMN-CSG-Subscription-Data ] [ UVA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.23 Cancel-VCSG-Location-Request (CVR) Command The Cancel-VCSG-Location-Request (CVR) command, indicated by the Command-Code field set to 8388642 and the 'R' bit set in the Command Flags field, is sent from CSS to MME or SGSN. Message Format < Cancel-VCSG-Location-Request> ::= < Diameter Header: 8388642, REQ, PXY, > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[Supported-Features ] { Cancellation-Type } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.24 Cancel-VCSG-Location-Answer (CVA) Command The Cancel-VCSG-Location-Answer (CVA) command, indicated by the Command-Code field set to 8388642 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to CSS. Message Format < Cancel-VCSG-Location-Answer> ::= < Diameter Header: 8388642, PXY, > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.3 Information Elements 7.3.1 General The following table specifies the Diameter AVPs defined for the S6a/S6d interface protocol, the S7a/S7d interface protocol and the S13/S13' interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415). For all AVPs which contain bit masks and are of the type Unsigned32, e.g., ULR-Flags, DSR-Flags, PUA-Flags, etc., bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 should be used. Table 7.3.1/1: S6a/S6d, S7a/S7d and S13/S13' specific DiameterAVPs AVP Flag rules Attribute Name AVP Code Clause defined Value Type Must May Should not Must not May Encr. Subscription-Data 1400 7.3.2 Grouped M, V No Terminal-Information 1401 7.3.3 Grouped M, V No IMEI 1402 7.3.4 UTF8String M, V No Software-Version 1403 7.3.5 UTF8String M, V No QoS-Subscribed 1404 7.3.77 OctetString M, V No ULR-Flags 1405 7.3.7 Unsigned32 M, V No ULA-Flags 1406 7.3.8 Unsigned32 M, V No Visited-PLMN-Id 1407 7.3.9 OctetString M, V No Requested-EUTRAN-Authentication-Info 1408 7.3.11 Grouped M, V No Requested-UTRAN-GERAN-Authentication-Info 1409 7.3.12 Grouped M, V No Number-Of-Requested-Vectors 1410 7.3.14 Unsigned32 M, V No Re-Synchronization-Info 1411 7.3.15 OctetString M, V No Immediate-Response-Preferred 1412 7.3.16 Unsigned32 M, V No Authentication-Info 1413 7.3.17 Grouped M, V No E-UTRAN-Vector 1414 7.3.18 Grouped M, V No UTRAN-Vector 1415 7.3.19 Grouped M, V No GERAN-Vector 1416 7.3.20 Grouped M, V No Network-Access-Mode 1417 7.3.21 Enumerated M, V No HPLMN-ODB 1418 7.3.22 Unsigned32 M, V No Item-Number 1419 7.3.23 Unsigned32 M, V No Cancellation-Type 1420 7.3.24 Enumerated M, V No DSR-Flags 1421 7.3.25 Unsigned32 M, V No DSA-Flags 1422 7.3.26 Unsigned32 M, V No Context-Identifier 1423 7.3.27 Unsigned32 M, V No Subscriber-Status 1424 7.3.29 Enumerated M, V No Operator-Determined-Barring 1425 7.3.30 Unsigned32 M, V No Access-Restriction-Data 1426 7.3.31 Unsigned32 M, V No APN-OI-Replacement 1427 7.3.32 UTF8String M, V No All-APN-Configurations-Included-Indicator 1428 7.3.33 Enumerated M, V No APN-Configuration-Profile 1429 7.3.34 Grouped M, V No APN-Configuration 1430 7.3.35 Grouped M, V No EPS-Subscribed-QoS-Profile 1431 7.3.37 Grouped M, V No VPLMN-Dynamic-Address-Allowed 1432 7.3.38 Enumerated M, V No STN-SR 1433 7.3.39 OctetString M, V No Alert-Reason 1434 7.3.83 Enumerate M, V No AMBR 1435 7.3.41 Grouped M, V No CSG-Subscription-Data 1436 7.3.78 Grouped M. V No CSG-Id 1437 7.3.79 Unsigned32 M, V No PDN-GW-Allocation-Type 1438 7.3.44 Enumerated M, V No Expiration-Date 1439 7.3.80 Time M, V No RAT-Frequency-Selection-Priority-ID 1440 7.3.46 Unsigned32 M, V No IDA-Flags 1441 7.3.47 Unsigned32 M, V No PUA-Flags 1442 7.3.48 Unsigned32 M, V No NOR-Flags 1443 7.3.49 Unsigned32 M, V No User-Id 1444 7.3.50 UTF8String V M No Equipment-Status 1445 7.3.51 Enumerated M, V No Regional-Subscription-Zone-Code 1446 7.3.52 OctetString M, V No RAND 1447 7.3.53 OctetString M, V No XRES 1448 7.3.54 OctetString M, V No AUTN 1449 7.3.55 OctetString M, V No KASME 1450 7.3.56 OctetString M, V No Trace-Collection-Entity 1452 7.3.98 Address M, V No Kc 1453 7.3.59 OctetString M, V No SRES 1454 7.3.60 OctetString M, V No PDN-Type 1456 7.3.62 Enumerated M, V No Roaming-Restricted-Due-To-Unsupported-Feature 1457 7.3.81 Enumerated M, V No Trace-Data 1458 7.3.63 Grouped M, V No Trace-Reference 1459 7.3.64 OctetString M, V No Trace-Depth 1462 7.3.67 Enumerated M, V No Trace-NE-Type-List 1463 7.3.68 OctetString M, V No Trace-Interface-List 1464 7.3.69 OctetString M, V No Trace-Event-List 1465 7.3.70 OctetString M, V No OMC-Id 1466 7.3.71 OctetString M, V No GPRS-Subscription-Data 1467 7.3.72 Grouped M, V No Complete-Data-List-Included-Indicator 1468 7.3.73 Enumerated M, V No PDP-Context 1469 7.3.74 Grouped M, V No PDP-Type 1470 7.3.75 OctetString M, V No 3GPP2-MEID 1471 7.3.6 OctetString M, V No Specific-APN-Info 1472 7.3.82 Grouped M, V No LCS-Info 1473 7.3.84 Grouped M, V No GMLC-Number 1474 7.3.85 OctetString M, V No LCS-PrivacyException 1475 7.3.86 Grouped M, V No SS-Code 1476 7.3.87 OctetString M, V No SS-Status 1477 7.3.88 OctetString M, V No Notification-To-UE-User 1478 7.3.89 Enumerated M, V No External-Client 1479 7.3.90 Grouped M, V No Client-Identity 1480 7.3.91 OctetString M, V No GMLC-Restriction 1481 7.3.92 Enumerated M, V No PLMN-Client 1482 7.3.93 Enumerated M, V No Service-Type 1483 7.3.94 Grouped M, V No ServiceTypeIdentity 1484 7.3.95 Unsigned32 M, V No MO-LR 1485 7.3.96 Grouped M, V No Teleservice-List 1486 7.3.99 Grouped M, V No TS-Code 1487 7.3.100 OctetString M, V No Call-Barring-Info 1488 7.3.101 Grouped M, V No SGSN-Number 1489 7.3.102 OctetString M, V No IDR-Flags 1490 7.3.103 Unsigned32 M, V No ICS-Indicator 1491 7.3.104 Enumerated V M No IMS-Voice-Over-PS-Sessions-Supported 1492 7.3.106 Enumerated V M No Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions 1493 7.3.107 Enumerated V M No Last-UE-Activity-Time 1494 7.3.108 Time V M No EPS-User-State 1495 7.3.110 Grouped V M No EPS-Location-Information 1496 7.3.111 Grouped V M No MME-User-State 1497 7.3.112 Grouped V M No SGSN-User-State 1498 7.3.113 Grouped V M No User-State 1499 7.3.114 Enumerated V M No MME-Location Information 1600 7.3.115 Grouped V M No SGSN-Location-Information 1601 7.3.116 Grouped V M No E-UTRAN-Cell-Global-Identity 1602 7.3.117 OctetString V M No Tracking-Area-Identity 1603 7.3.118 OctetString V M No Cell-Global-Identity 1604 7.3.119 OctetString V M No Routing-Area-Identity 1605 7.3.120 OctetString V M No Location-Area-Identity 1606 7.3.121 OctetString V M No Service-Area-Identity 1607 7.3.122 OctetString V M No Geographical-Information 1608 7.3.123 OctetString V M No Geodetic-Information 1609 7.3.124 OctetString V M No Current-Location-Retrieved 1610 7.3.125 Enumerated V M No Age-Of-Location-Information 1611 7.3.126 Unsigned32 V M No Active-APN 1612 7.3.127 Grouped V M No Error-Diagnostic 1614 7.3.128 Enumerated V M No Ext-PDP-Address 1621 7.3.129 Address V M No UE-SRVCC-Capability 1615 7.3.130 Enumerated V M No MPS-Priority 1616 7.3.131 Unsigned32 V M No VPLMN-LIPA-Allowed 1617 7.3.132 Enumerated V M No LIPA-Permission 1618 7.3.133 Enumerated V M No Subscribed-Periodic-RAU-TAU-Timer 1619 7.3.134 Unsigned32 V M No Ext-PDP-Type 1620 7.3.75A OctetString V M No SIPTO-Permission 1613 7.3.135 Enumerated V M No MDT-Configuration 1622 7.3.136 Grouped V M No Job-Type 1623 7.3.137 Enumerated V M No Area-Scope 1624 7.3.138 Grouped V M No List-Of-Measurements 1625 7.3.139 Unsigned32 V M No Reporting-Trigger 1626 7.3.140 Unsigned32 V M No Report-Interval 1627 7.3.141 Enumerated V M No Report-Amount 1628 7.3.142 Enumerated V M No Event-Threshold-RSRP 1629 7.3.143 Unsigned32 V M No Event-Threshold-RSRQ 1630 7.3.144 Unsigned32 v M No Logging-Interval 1631 7.3.145 Enumerated V M No Logging-Duration 1632 7.3.146 Enumerated V M No Relay-Node-Indicator 1633 7.3.147 Enumerated V M No MDT-User-Consent 1634 7.3.148 Enumerated V M No PUR-Flags 1635 7.3.149 Unsigned32 V M No Subscribed-VSRVCC 1636 7.3.150 Enumerated V M No Equivalent-PLMN-List 1637 7.3.151 Grouped V M No CLR-Flags 1638 7.3.152 Unsigned32 V M No UVR-Flags 1639 7.3.153 Unsigned32 M, V No UVA-Flags 1640 7.3.154 Unsigned32 M, V No VPLMN-CSG-Subscription-Data 1641 7.3.155 Grouped M, V No Time-Zone 1642 7.3.163 UTF8String V M No A-MSISDN 1643 7.3.157 OctetString V M No MME-Number-for-MT-SMS 1645 7.3.159 OctetString V M No SMS-Register-Request 1648 7.3.162 Enumerated V M No Local-Time-Zone 1649 7.3.156 Grouped V M No Daylight-Saving-Time 1650 7.3.164 Enumerated V M No Subscription-Data-Flags 1654 7.3.165 Unsigned32 V M No Measurement-Period-LTE 1655 7.3.166 Enumerated V M No Measurement-Period-UMTS 1656 7.3.167 Enumerated V M No Collection-Period-RRM-LTE 1657 7.3.168 Enumerated V M No Collection-Period-RRM-UMTS 1658 7.3.169 Enumerated V M No Positioning-Method 1659 7.3.170 OctetString V M No Measurement-Quantity 1660 7.3.171 OctetString V M No Event-Threshold-Event-1F 1661 7.3.172 Integer32 V M No Event-Threshold-Event-1I 1662 7.3.173 Integer32 V M No Restoration-Priority 1663 7.3.174 Unsigned32 V M No SGs-MME-Identity 1664 7.3.175 UTF8String V M No SIPTO-Local-Network-Permission 1665 7.3.176 Unsigned32 V M No Coupled-Node-Diameter-ID 1666 7.3.177 DiameterIdentity V M No WLAN-offloadability 1667 7.3.181 Grouped V M No WLAN-offloadability-EUTRAN 1668 7.3.182 Unsigned32 V M No WLAN-offloadability-UTRAN 1669 7.3.183 Unsigned32 V M No Reset-ID 1670 7.3.184 OctetString V M No MDT-Allowed-PLMN-Id 1671 7.3.185 OctetString V M No Adjacent-PLMNs 1672 7.3.186 Grouped V M No Adjacent-Access-Restriction-Data 1673 7.3.187 Grouped V M No DL-Buffering-Suggested-Packet-Count 1674 7.3.188 Integer32 V M No IMSI-Group-Id 1675 7.3.189 Grouped V M No Group-Service-Id 1676 7.3.190 Unsigned32 V M No Group-PLMN-Id 1677 7.3.191 OctetString V M No Local-Group-Id 1678 7.3.192 OctetString V M No AIR-Flags 1679 7.3.201 Unsigned32 V M No UE-Usage-Type 1680 7.3.202 Unsigned32 V M No Non-IP-PDN-Type-Indicator 1681 7.3.204 Enumerated V M No Non-IP-Data-Delivery-Mechanism 1682 7.3.205 Unsigned32 V M No Additional-Context-ID 1683 7.3.206 Unsigned32 V M No SCEF-Realm 1684 7.3.207 DiameterIdentity V M No Subscription-Data-Deletion 1685 7.3.208 Grouped V M No Preferred-Data-Mode 1686 7.3.209 Unsigned32 V M No Emergency-Info 1687 7.3.210 Grouped V M No V2X-Subscription-Data 1688 7.3.212 Grouped V M No V2X-Permission 1689 7.3.213 Unsigned32 V M No PDN-Connection-Continuity 1690 7.3.214 Unsigned32 V M No eDRX-Cycle-Length 1691 7.3.215 Grouped V M No eDRX-Cycle-Length-Value 1692 7.3.216 OctetString V M No UE-PC5-AMBR 1693 7.3.217 Unsigned32 V M No MBSFN-Area 1694 7.3.219 Grouped V M No MBSFN-Area-ID 1695 7.3.220 Unsigned32 V M No Carrier-Frequency 1696 7.3.221 Unsigned32 V M No RDS-Indicator 1697 7.3.222 Enumerated V M No Service-Gap-Time 1698 7.3.223 Unsigned32 V M No Aerial-UE-Subscription-Information 1699 7.3.224 Unsigned32 V M No Broadcast-Location-Assistance-Data-Types 1700 7.3.225 Unsigned64 V M No Paging-Time-Window 1701 7.3.226 Grouped V M No Operation-Mode 1702 7.3.227 Unsigned32 V M No Paging-Time-Window-Length 1703 7.3.228 OctetString V M No Core-Network-Restrictions 1704 7.3.230 Unsigned32 V M No eDRX-Related-RAT 1705 7.3.229 Grouped V M No Interworking-5GS-Indicator 1706 7.3.231 Enumerated V M No Ethernet-PDN-Type-Indicator 1707 7.3.232 Enumerated V M No Subscribed-ARPI 1708 7.3.233 Unsigned32 V M No IAB-Operation-Permission 1709 7.3.234 Enumerated V M No V2X-Subscription-Data-Nr 1710 7.3.235 Grouped V M No UE-PC5-QoS 1711 7.3.236 Grouped V M No PC5-QoS-Flow 1712 7.3.237 Grouped V M No 5QI 1713 7.3.238 Integer32 V M No PC5-Flow-Bitrates 1714 7.3.239 Grouped V M No Guaranteed-Flow-Bitrates 1715 7.3.240 Integer32 V M No Maximum-Flow-Bitrates 1716 7.3.241 Integer32 V M No PC5-Range 1717 7.3.242 Integer32 V M No PC5-Link-AMBR 1718 7.3.243 Integer32 V M No Third-Context-Identifier 1719 7.3.244 Unsigned32 V M No NOTE 1: The AVP header bit denoted as ""M"", indicates whether support of the AVP is required. The AVP header bit denoted as ""V"", indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETFÊRFCÊ6733Ê[61]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. The following table specifies the Diameter AVPs re-used by the S6a/S6d interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within S6a and S6d. Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol specified in IETFÊRFCÊ6733Ê[61], do not need to be supported. The AVPs from the Diameter base protocol specified in IETFÊRFCÊ6733Ê[61] are not included in table 7.3.1/2, but they may be re-used for the S6a/S6d protocol, the S7a/S7protocol and the S13/S13' protocol. Table 7.3.1/2: S6a/S6d, S7a/S7d and S13/S13' re-used Diameter AVPs Attribute Name Reference Comments M-bit Service-Selection IETFÊRFCÊ5778Ê[20] See clauseÊ7.3.36 3GPP-Charging-Characteristics 3GPPÊTSÊ29.061Ê[21] See 3GPPÊTSÊ32.251Ê[33] Annex A and 3GPPÊTSÊ32.298Ê[22] clauseÊ5.1.2.2.7 This attribute holds the EPS PDN Connection Charging Characteristics data for an EPS APN Configuration, or the PDP context Charging Characteristics for GPRS PDP context, or the Subscribed Charging Characteristics data for the subscriber level 3GPP Charging Characteristics; refer to 3GPPÊTSÊ23.008Ê[30]. Supported-Features 3GPPÊTSÊ29.229Ê[9] Feature-List-ID 3GPPÊTSÊ29.229Ê[9] Feature-List 3GPPÊTSÊ29.229Ê[9] See clauseÊ7.3.10 Served-Party-IP-Address 3GPPÊTSÊ32.299Ê[8] holds the PDN IP Address of the user QoS-Class-Identifier 3GPPÊTSÊ29.212Ê[10] Allocation-Retention-Priority 3GPPÊTSÊ29.212Ê[10] See clauseÊ7.3.40 Priority-Level 3GPPÊTSÊ29.212Ê[10] Pre-emption-Capability 3GPPÊTSÊ29.212Ê[10] Pre-emption-Vulnerability 3GPPÊTSÊ29.212Ê[10] Max-Requested-Bandwidth-DL 3GPPÊTSÊ29.214Ê[11] Max-Requested-Bandwidth-UL 3GPPÊTSÊ29.214Ê[11] Extended-Max-Requested-BW-DL 3GPPÊTSÊ29.214Ê[11] Extended-Max-Requested-BW-UL 3GPPÊTSÊ29.214Ê[11] RAT-Type 3GPPÊTSÊ29.212Ê[10] See clauseÊ7.3.13 Must set MSISDN 3GPPÊTSÊ29.329Ê[25] MIP6-Agent-Info IETFÊRFCÊ5447Ê[26] MIP-Home-Agent-Address IETFÊRFCÊ4004Ê[27] MIP-Home-Agent-Host IETFÊRFCÊ4004Ê[27] PDP-Address 3GPPÊTSÊ32.299Ê[8] Confidentiality-Key 3GPPÊTSÊ29.229Ê[9] See clauseÊ7.3.57 Integrity-Key 3GPPÊTSÊ29.229Ê[9] See clauseÊ7.3.58 Visited-Network-Identifier 3GPPÊTSÊ29.229Ê[9] See clauseÊ7.3.105 Must not set GMLC-Address 3GPPÊTSÊ29.173Ê[37] See clauseÊ7.3.109 Must not set User-CSG-Information 3GPPÊTSÊ32.299Ê[8] Must not set ProSe-Subscription-Data 3GPPÊTSÊ29.344Ê[49] See clauseÊ7.3.180 Must not set OC-Supported-Features IETFÊRFCÊ7683Ê[50] See clauseÊ7.3.178 Must not set OC-OLR IETFÊRFCÊ7683Ê[50] See clauseÊ7.3.179 Must not set SCEF-Reference-ID 3GPPÊTSÊ29.336Ê[54] Must not set SCEF-ID 3GPPÊTSÊ29.336Ê[54] Must not set AESE-Communication-Pattern 3GPPÊTSÊ29.336Ê[54] see clauseÊ7.3.193 Must not set Communication-Pattern-set 3GPPÊTSÊ29.336Ê[54] see clauseÊ7.3.194 Must not set Monitoring-Event-Configuration 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.195 Must not set Monitoring-Event-Report 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.196 Must not set UE-Reachability-Configuration 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.197 Must not set eNodeB-ID 3GPPÊTSÊ29.217Ê[56] See clauseÊ7.3.198 Must not set SCEF-Reference-ID-for-Deletion 3GPPÊTSÊ29.336Ê[54] Must not set Monitoring-Type 3GPPÊTSÊ29.336Ê[54] Must not set Maximum-Number-of-Reports 3GPPÊTSÊ29.336Ê[54] Must not set Monitoring-Duration 3GPPÊTSÊ29.336Ê[54] Must not set Charged-Party 3GPPÊTSÊ29.336Ê[54] Must not set Location-Information-Configuration 3GPPÊTSÊ29.336Ê[54] Must not set Reachability-Type 3GPPÊTSÊ29.336Ê[54] Must not set Maximum-Response-Time 3GPPÊTSÊ29.336Ê[54] Must not set Reachability-Information 3GPPÊTSÊ29.336Ê[54] Must not set Reachability-Cause 3GPPÊTSÊ29.128Ê[63] Must not set Monitoring-Event-Config-Status 3GPPÊTSÊ29.336Ê[54] Must not set Supported-Services 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.199 Must not set Supported-Monitoring-Events 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.200 Must not set DRMP IETFÊRFCÊ7944Ê[57] See clauseÊ7.3.203 Must not set Reference-ID-Validity-Time 3GPPÊTSÊ29.336Ê[54] Must not set Maximum-UE-Availability-Time 3GPPÊTSÊ29.338Ê[48] See clauseÊ5.3.3.22 Must not set Emergency-Services 3GPPÊTSÊ29.273Ê[59] Load IETFÊRFCÊ8583Ê[60] See clauseÊ7.3.211 Must not set Extended-eNodeB-ID 3GPPÊTSÊ29.217Ê[56] See clauseÊ7.3.218 Must not set External-Identifier 3GPPÊTSÊ29.336Ê[54] Must not set Loss-Of-Connectivity-Reason 3GPPÊTSÊ29.336Ê[54] Must not set Active-Time 3GPPÊTSÊ29.128Ê[63] Must not set Idle-Status-Indication 3GPPÊTSÊ29.128Ê[63] Must not set MTC-Provider-Info 3GPPÊTSÊ29.336Ê[54] Must not set Traffic-Profile 3GPPÊTSÊ29.336Ê[54] Must not set PDN-Connectivity-Status-Configuration 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.195 Must not set PDN-Connectivity-Status-Report 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.196 Must not set Battery-Indicator 3GPPÊTSÊ29.336Ê[54] Battery-Indicator SCEF-Reference-ID-Ext 3GPPÊTSÊ29.336Ê[54] Must not set SCEF-Reference-ID-for-Deletion-Ext 3GPPÊTSÊ29.336Ê[54] Must not set NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: ""Must set"", ""Must not set"". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. 7.3.2 Subscription-Data The Subscription-Data AVP is of type Grouped. It shall contain the information related to the user profile relevant for EPS and GERAN/UTRAN. AVP format: Subscription-Data ::= <AVP header: 1400 10415> [ Subscriber-Status ] [ MSISDN ] [ A-MSISDN ] [ STN-SR ] [ ICS-Indicator ] [ Network-Access-Mode ] [ Operator-Determined-Barring ] [ HPLMN-ODB ] *10[ Regional-Subscription-Zone-Code ] [ Access-Restriction-Data ] [ APN-OI-Replacement ] [ LCS-Info ] [ Teleservice-List ] *[ Call-Barring-Info ] [ 3GPP-Charging-Characteristics ] [ AMBR ] [ APN-Configuration-Profile ] [ RAT-Frequency-Selection-Priority-ID ] [ Trace-Data] [ GPRS-Subscription-Data ] *[ CSG-Subscription-Data ] [ Roaming-Restricted-Due-To-Unsupported-Feature ] [ Subscribed-Periodic-RAU-TAU-Timer ] [ MPS-Priority ] [ VPLMN-LIPA-Allowed ] [ Relay-Node-Indicator ] [ MDT-User-Consent ] [ Subscribed-VSRVCC ] [ ProSe-Subscription-Data ] [ Subscription-Data-Flags ] *[ Adjacent-Access-Restriction-Data ] [ DL-Buffering-Suggested-Packet-Count ] *[ IMSI-Group-Id ] [ UE-Usage-Type ] *[ AESE-Communication-Pattern ] *[ Monitoring-Event-Configuration ] [ Emergency-Info ] [ V2X-Subscription-Data ] [ V2X-Subscription-Data-Nr ] *[ eDRX-Cycle-Length ] [ External-Identifier ] [ Active-Time ] [ Service-Gap-Time ] [ Broadcast-Location-Assistance-Data-Types ] [ Aerial-UE-Subscription-Information ] [ Core-Network-Restrictions ] *[ Paging-Time-Window ] [ Subscribed-ARPI ] [ IAB-Operation-Permission ] *[ AVP ] The AMBR included in this grouped AVP shall include the AMBR associated to the user's subscription (UE-AMBR); Max-Requested-Bandwidth-UL and Max-Requested-Bandwidth-DL within this AVP shall not both be set to ""0"". The APN-OI-Replacement included in this grouped AVP shall include the UE level APN-OI-Replacement associated to the user's subscription. When multiple External Identifiers are defined for the same subscription, the External-Identifier in this grouped AVP shall contain a default External Identifier determined by the HSS. 7.3.3 Terminal-Information The Terminal-Information AVP is of type Grouped. This AVP shall contain the information about the user's terminal. AVP format Terminal-Information ::= <AVP header: 1401 10415> [ IMEI ] [ 3GPP2-MEID ] [ Software-Version ] *[ AVP ] 7.3.4 IMEI The IMEI AVP is of type UTF8String. This AVP shall contain the International Mobile Equipment Identity, as specified in 3GPPÊTSÊ23.003Ê[3]. It should consist of 14 digits, including the 8-digit Type Allocation Code (TAC) and the 6-digit Serial Number (SNR). It may also include a 15th digit. 7.3.5 Software-Version The Software-Version AVP is of type UTF8String. This AVP shall contain the 2-digit Software Version Number (SVN) of the International Mobile Equipment Identity, as specified in 3GPPÊTSÊ23.003Ê[3]. 7.3.6 3GPP2-MEID This AVP is of type OctetString. This AVP contains the Mobile Equipment Identifier of the user's terminal. For further details on the encoding of the AVP data, refer to the encoding of the Mobile Identity (MEID) octets 3 to 10 in 3GPP2 A.S0022Ê[28] Annex A. 7.3.7 ULR-Flags The ULR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.7/1: Table 7.3.7/1: ULR-Flags Bit Name Description 0 Single-Registration-Indication This bit, when set, indicates that the HSS shall send Cancel Location to the SGSN. An SGSN shall not set this bit when sending ULR. 1 S6a/S6d-Indicator This bit, when set, indicates that the ULR message is sent on the S6a interface, i.e. the source node is an MME (or a combined MME/SGSN to which the UE is attached via E-UTRAN). This bit, when cleared, indicates that the ULR message is sent on the S6d interface, i.e. the source node is an SGSN (or a combined MME/SGSN to which the UE is attached via UTRAN or GERAN). 2 Skip Subscriber Data This bit, when set, indicates that the HSS may skip subscription data in ULA. If the subscription data has changed in the HSS after the last successful update of the MME/SGSN, the HSS shall ignore this bit and send the updated subscription data. If the HSS effectively skips the sending of subscription data, the GPRS-Subscription-Data-Indicator flag can be ignored. 3 GPRS-Subscription-Data-Indicator This bit, when set, indicates that the HSS shall include in the ULA command the GPRS subscription data, if available in the HSS; it shall be included in the GPRS-Subscription-Data AVP inside the Subscription-Data AVP (see 7.3.2). Otherwise, the HSS shall not include the GPRS-Subscription-Data AVP in the response, unless the Update Location Request is received over the S6d interface and there is no APN configuration profile stored for the subscriber, or when the subscription data is returned by a Pre-Rel-8 HSS (via an IWF). A standalone MME shall not set this bit when sending a ULR. 4 Node-Type-Indicator This bit, when set, indicates that the requesting node is a combined MME/SGSN. This bit, when cleared, indicates that the requesting node is a single MME or SGSN; in this case, if the S6a/S6d-Indicator is set, the HSS may skip the check of those supported features only applicable to the SGSN, and if, in addition the MME does not request to be registered for SMS, the HSS may consequently skip the download of the SMS related subscription data to a standalone MME. NOTE2 5 Initial-Attach-Indicator This bit, when set, indicates that the HSS shall send Cancel Location to the MME or SGSN if there is the MME or SGSN registration. 6 PS-LCS-Not-Supported-By-UE This bit, when set, indicates to the HSS that the UE does not support neither UE Based nor UE Assisted positioning methods for Packet Switched Location Services. The MME shall set this bit on the basis of the UE capability information. The SGSN shall set this bit on the basis of the UE capability information and the access technology supported by the SGSN. 7 SMS-Only-Indication This bit, when set, indicates that the UE indicated ""SMS only"" when requesting a combined IMSI attach or combined RA/LU. 8 Dual-Registration-5G-Indicator This bit, when set by an MME over S6a interface, indicates that the HSS+UDM shall not send Nudm_UECM_DeregistrationNotification to the registered AMF (if any); when not set by an MME over S6a interface, it indicates that the HSS+UDM shall send Nudm_UECM_DeregistrationNotification to the registered AMF (if any). See 3GPPÊTSÊ29.503Ê[66]. An SGSN shall not set this bit when sending ULR over S6d interface. 9 Inter-PLMN-inter-MME handover This bit, when set by an MME over S6a interface, indicates that an inter PLMN inter MME (or AMF to MME) handover is ongoing. 10 Intra-PLMN-inter-MME handover This bit, when set by an MME over S6a interface, indicates that an intra PLMN inter MME (or AMF to MME) handover is ongoing. NOTE1: Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving HSS. NOTE2: If the MME is registered for SMS then the HSS will download the SMS related data also for the standalone MME. 7.3.8 ULA-Flags The ULA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.8/1: Table 7.3.8/1: ULA-Flags Bit Name Description 0 Separation Indication This bit, when set, indicates that the HSS stores SGSN number and MME number in separate memory. A Rel-8 HSS shall set the bit. An IWF interworking with a pre Rel-8 HSS/HLR shall clear the bit. 1 MME Registered for SMS This bit, when set, indicates that the HSS has registered the MME for SMS. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.9 Visited-PLMN-Id The Visited-PLMN-Id AVP is of type OctetString. This AVP shall contain the concatenation of MCC and MNC. See 3GPPÊTSÊ23.003Ê[3]. The content of this AVP shall be encoded as an octet string according to table 7.3.9-1. See 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.1.13, PLMN list, for the coding of MCC and MNC. If MNC is 2 digits long, bits 5 to 8 of octet 2 are coded as ""1111"". Table 7.3.9/1: Encoding format for Visited-PLMN-Id AVP 8 7 6 5 4 3 2 1 MCC digit 2 MCC digit 1 octet 1 MNC digit 3 MCC digit 3 octet 2 MNC digit 2 MNC digit 1 octet 3 7.3.10 Feature-List AVP 7.3.10.1 Feature-List AVP for the S6a/S6d application The syntax of this AVP is defined in 3GPPÊTSÊ29.229Ê[9]. For the S6a/S6d application, the meaning of the bits shall be as defined in table 7.3.10/1 for the Feature-List-ID 1 and in table 7.3.10/2 for the Feature-List-ID 2. Table 7.3.10/1: Features of Feature-List-ID 1 used in S6a/S6d Feature bit Feature M/O Description 0 ODB-all-APN O Operator Determined Barring of all Packet Oriented Services This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update by sending DIAMETER_ERROR_ROAMING_NOT_ALLOWED and, optionally, including the type of ODB in the Error-Diagnostic AVP. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 1 ODB-HPLMN-APN O Operator Determined Barring of Packet Oriented Services from access points that are within the HPLMN whilst the subscriber is roaming in a VPLMN This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update by sending DIAMETER_ERROR_ROAMING_NOT_ALLOWED and, optionally, including the type of ODB in the Error-Diagnostic AVP. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 2 ODB-VPLMN-APN O Operator Determined Barring of Packet Oriented Services from access points that are within the roamed to VPLMN This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update by sending DIAMETER_ERROR_ROAMING_NOT_ALLOWED and, optionally, including the type of ODB in the Error-Diagnostic AVP. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 3 ODB-all-OG O Operator Determined Barring of all outgoing calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 4 ODB-all- InternationalOG O Operator Determined Barring of all outgoing international calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs.If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 5 ODB-all-InternationalOGNotToHPLMN-Country O Operator Determined Barring of all outgoing international calls except those directed to the home PLMN country This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 6 ODB-all-InterzonalOG O Operator Determined Barring of all outgoing inter-zonal calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 7 ODB-all-InterzonalOGNotToHPLMN-Country O Operator Determined Barring of all outgoing inter-zonal calls except those directed to the home PLMN country This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 8 ODB-all-InterzonalOGAndInternationalOGNotToHPLMN-Country O Operator Determined Barring of all outgoing international calls except those directed to the home PLMN country and Barring of all outgoing inter-zonal calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 9 RegSub O Regional Subscription This feature is applicable for the ULR/ULA, IDR/IDA and DSR/DSA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send Regional Subscription Zone Codes to the MME or SGSN within ULA."
"Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent Regional Subscription Zone Codes within IDR, the HSS may apply barring of roaming and send CLR. 10 Trace O Trace Function This feature is applicable for the ULR/ULA, IDR/IDA and DSR/DSA command pairs. If the MME or SGSN does not indicate support of this feature in ULR, the HSS shall not send Trace Data to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent Trace Data withinÊIDR, the HSS may store this indication, and not send any further Trace Data to that MME or SGSN. If the MME or SGSN does not indicate support of this feature in DSA, and the HSS has sent Trace Data withinÊDSR, the HSS may store this indication, and not send any further Trace Data to that MME or SGSN 11 LCS-all-PrivExcep (NOTE 1) O All LCS Privacy Exception Classes This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 12 LCS-Universal (NOTE 1) O Allow location by any LCS client This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 13 LCS-CallSessionRelated (NOTE 1) O Allow location by any value added LCS client to which a call/session is established from the target UE This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 14 LCS-CallSessionUnrelated (NOTE 1) O Allow location by designated external value added LCS clients This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 15 LCS-PLMNOperator (NOTE 1) O Allow location by designated PLMN operator LCS clients This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 16 LCS-ServiceType (NOTE 1) O Allow location by LCS clients of a designated LCS service type This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 17 LCS-all-MOLR-SS (NOTE 1) O All Mobile Originating Location Request Classes This feature is applicable for the ULR/ULA and IDR/IDA command pairs. Over S6d interface, this feature is applicable when the SGSN supports MAP based Lg interface. If the MME or SGSN does not support this feature, the HSS shall not send the related LCS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that MME or SGSN. 18 LCS- BasicSelfLocation (NOTE 1) O Allow an MS to request its own location This feature is applicable for the ULR/ULA and IDR/IDA command pairs. Over S6d interface, this feature is applicable when the SGSN supports MAP based Lg interface. If the MME or SGSN does not support this feature, the HSS shall not send the related LCS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that MME or SGSN. 19 LCS- AutonomousSelfLocation (NOTE 1) O Allow an MS to perform self location without interaction with the PLMN This feature is applicable for the ULR/ULA and IDR/IDA command pairs. Over S6d interface, this feature is applicable when the SGSN supports MAP based Lg interface. If the MME or SGSN does not support this feature, the HSS shall not send the related LCS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that MME or SGSN. 20 LCS- TransferToThirdParty O Allow an MS to request transfer of its location to another LCS client This feature is applicable for the ULR/ULA and IDR/IDA command pairs. Over S6d interface, this feature is applicable when the SGSN supports MAP based Lg interface. If the MME or SGSN does not support this feature, the HSS shall not send the related LCS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that MME or SGSN. 21 SM-MO-PP (NOTE 1) O Short Message MO-PP This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 22 Barring-OutgoingCalls O Barring of Outgoing Calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 23 BAOC O Barring of all outgoing calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 24 BOIC O Barring of outgoing international calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 25 BOICExHC O Barring of outgoing international calls except those directed to the home PLMN Country This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 26 UE-Reachability-Notification O UE Reachability Notifcation This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support the UE-Reachability-Notifications, the HSS shall not set the ""UE-Reachability-Request"" bit in IDR-Flags in subsequent IDR commands towards that MME or SGSN. 27 T-ADS Data Retrieval O Terminating Access Domain Selection Data Retrieval This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support the retrieval of T-ADS data via IDR/IDA commands, the HSS shall not set the ""T-ADS Data Request"" bit in IDR-Flags in subsequent IDR commands towards that MME or SGSN. 28 State/Location-Information-Retrieval O State/Location Information Retrieval This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support State/Location Information Retrieval, the HSS shall not set the ""EPS User State Request"", ""EPS Location Information Request"" or ""Current Location Request"" bits in IDR-Flags in subsequent IDR commands towards that MME or SGSN. 29 Partial Purge O Partial Purge from a Combined MME/SGSN This feature is applicable for the ULR/ULA and PUR/PUA command pairs, over S6a and S6d. If the HSS indicates in the ULA command that it does not support Partial Purge, the combined MME/SGSN shall not include in the PUR command the indication of the specific serving node where the Purge has been done. 30 Local Time Zone Retrieval O UE Time Zone Retrieval This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support the retrieval of Local Time Zone via IDR/IDA commands, the HSS shall not set the ""Local Time Zone Request"" bit in IDR-Flags in subsequent IDR commands towards that MME or SGSN. 31 Additional MSISDN O Additional MSISDN This feature is applicable for the ULR/ULA, IDR/IDA and DSR/DSA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support A-MSISDN, the HSS shall populate the MSISDN AVP either with the subscribed MSISDN or the subscribed additional MSISDN based on operator policy and availability and the HSS shall not send IDR with the A-MSISDN AVP or DSR with the ""A-MSISDN Withdrawal"" bit to the serving nodes when the subscription data is changed. If the MME or SGSN indicates in the IDA command that it does not support this feature and the HSS has already sent an A-MSISDN value withinÊIDR, the HSS may store this indication and not send any further A-MSISDN updates to that MME or SGSN. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""ODB-HPLMN-APN"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. NOTE 1: If both bits, corresponding to the feature defined for Lg interface and Lgd interface respectively, are not set, and the HSS supports the feature, the HSS shall not send the related LCS information to the SGSN within ULA and IDR. Table 7.3.10/2: Features of Feature-List-ID 2 used in S6a/S6d Feature bit Feature M/O Description 0 SMS in MME O SMS in MME This feature is applicable for the ULR/ULA, IDR/IDA, DSR/DSA, NOR/NOA command pairs, over S6a. It is used by the MME to notify the HSS it is capable of SMS transfer without the need of establishing an SGs association with an MSC. If the MME does not support this feature, the HSS shall not send the related SMS information to the MME within ULA. If the MME does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME. If the HSS does not support this feature, the HSS shall ignore any request for a registration for SMS; the MME may store this feature indication, and not send any further request for a registration for SMS to the HSS. 1 SMS in SGSN O SMS in SGSN This feature is applicable for the ULR/ULA command pair, over S6d. If the SGSN indicates in the ULR command that it does not support this feature, the HSS shall not indicate ""SMS in SGSN Allowed"" to the SGSN. 2 Dia-LCS-all-PrivExcep (NOTE 1) O All LCS Privacy Exception Classes This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 3 Dia-LCS-Universal (NOTE 1) O Allow location by any LCS client This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 4 Dia-LCS-CallSessionRelated (NOTE 1) O Allow location by any value added LCS client to which a call/session is established from the target UE This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 5 Dia-LCS-CallSessionUnrelated (NOTE 1) O Allow location by designated external value added LCS clients This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 6 Dia-LCS-PLMNOperator (NOTE 1) O Allow location by designated PLMN operator LCS clients This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 7 Dia-LCS-ServiceType (NOTE 1) O Allow location by LCS clients of a designated LCS service type This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 8 Dia-LCS-all-MOLR-SS (NOTE 1) O All Mobile Originating Location Request Classes This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 9 Dia-LCS- BasicSelfLocation (NOTE 1) O Allow an MS to request its own location This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 10 Dia-LCS- AutonomousSelfLocation (NOTE 1) O Allow an MS to perform self location without interaction with the PLMN This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 11 Dia-LCS- TransferToThirdParty (NOTE 1) O Allow an MS to request transfer of its location to another LCS client This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 12 Gdd-in-SGSN O Support of Diameter based Gdd interface for SMS in SGSN This feature is applicable for the ULR/ULA command pair over S6d, when the SGSN supports the Diameter based Gdd interface for SMS in SGSN. 13 Optimized-LCS-Proc-Support O Support for the optimized LCS procedure This feature is applicable for the ULR/ULA command pair over S6a/S6d, when the network supports ISR and when the node is combined MME/SGSN and supports optimized LCS procedure as described in 3GPPÊTSÊ29.172Ê[47] clauseÊ6.2.2. 14 SGSN CAMEL Capability O Support of SGSN CAMEL Capability This feature is applicable for the ULR/ULA command pair over S6d, when the SGSN supports the CAMEL capability. 15 ProSe Capability O Support of ProSe Capability This feature is applicable for the ULR/ULA and IDR/IDA command pairs over S6a (and S6d), when the MME (or combined MME/SGSN) supports the ProSe capability. If the MME or combined MME/SGSN does not support this feature, the HSS shall not send the related ProSe subscription data to the MME or combined MME/SGSN within ULA. If the MME or combined MME/SGSN does not indicate support of this feature in IDA, and the HSS has sent the related ProSe subscription data withinÊIDR, the HSS may store this indication, and not send any further ProSe subscription data to that MME. 16 P-CSCF Restoration O Support of P-CSCF Restoration This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a or S6d interfaces, when the MME or SGSN supports the execution of the P-CSCF restoration procedures. If the MME or the SGSN does not indicate support of this feature in ULR, the HSS shall not send subsequent IDR commands requesting the execution of HSS-based P-CSCF restoration procedures, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4. 17 Reset-IDs O Support of Reset-IDs This feature is applicable to the ULR/ULA and IDR/IDA and DSR/DSA and RSR/RSA command pairs over the S6a and S6d interfaces. If the MME or SGSN indicates in the ULR command that it does not support Reset-IDs, the HSS shall not include Reset-ID AVPs in RSR commands sent to that MME or SGSN. If the MME or SGSN indicates that it does not support this feature in IDA, and the HSS has already sent a Reset-ID value within IDR, the HSS may store this indication and not send any further Reset-ID updates to that MME or SGSN. 18 Communication-Pattern O Support of AESE communication patterns This feature is applicable to the ULR/ULA and IDR/IDA command pairs over S6a (and S6d), when the MME (or combined MME/SGSN) supports the AESE communication patterns. If the MME or combined MME/SGSN does not indicate the support for this feature, the HSS shall not send CP parameter sets to the MME or combined MME/SGSN within IDR/ULA command. If the MME or combined MME/SGSN indicates that it does not support this feature in IDA, and the HSS has already sent CP parameter sets within IDR, the HSS may store this indication and not send any further updates related to CP parameter sets to that MME or combined MME/SGSN. 19 Monitoring-Event O Support of Monitoring Event This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a or S6d interfaces, when the MME or SGSN supports the Monitoring event feature. If the MME or SGSN does not indicate support of this feature in ULR, the HSS shall not send Monitoring event configuration data to the MME or SGSN within ULA and shall not send subsequent IDR commands requesting the configuration of Monitoring events in the MME or SGSN. If the MME or SGSN indicates that it does not support this feature in IDA, and the HSS has already sent Monitoring event configuration data within IDR, the HSS may store this indication and not send any further updates related to Monitoring events to that MME or SGSN. 20 Dedicated Core Networks O Support of Dedicated Core Networks This feature is applicable to the ULR/ULA, IDR/IDA and DSR/DSA command pairs over the S6a and S6d interfaces. If the MME/SGSN does not indicate support of this feature in the ULR command, the HSS shall not send DCN-related subscription data (e.g., UE Usage Type) in ULA, and shall not send subsequent IDR or DSR commands when such subscription data are updated. If the MME/SGSN does not indicate support of this feature in the IDA command and the HSS has already sent DCN-related subscription data in IDR, the HSS may store this indication and not send further updates related to DCN subscription data. 21 Non-IP PDN Type APNs O Support of Non-IP PDN Type APNs This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a and S6d interfaces. If the MME/SGSN does not indicate support of this feature in the ULR command, the HSS shall not send APN configurations with a Non-IP PDN type in the subscription data sent in ULA or in IDR, and shall not send IDR commands with the only purpose to update such subscription data. If the MME or SGSN indicates in the IDA command that it does not support this feature, and the HSS has already sent Non-IP PDN Type APNs withinÊIDR, the HSS may store this indication, and not send any further updates related to Non-IP PDN Type APNs to that MME or SGSN. 22 Non-IP PDP Type APNs O Support of Non-IP PDP Type APNs This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a/S6d interface. If the MME/SGSN does not indicate support of this feature in the ULR command, the HSS shall not send PDP contexts (as part of the GPRS-Subscription-Data) with a Non-IP PDP type in the subscription data sent in ULA or in IDR, and shall not send IDR commands with the only purpose to update such subscription data. If the MME or SGSN indicates in the IDA command that it does not support this feature, and the HSS has already sent Non-IP PDP Type APNs withinÊIDR, the HSS may store this indication, and not send any further updates related to Non-IP PDP Type APNs to that MME or SGSN. 23 Removal of MSISDN O Support of Removal of MSISDN This feature is applicable to the ULR/ULA and DSR/DSA command pairs over the S6a/S6d interface. If the MME/SGSN does not indicate support of this feature in the ULR command, the HSS shall not send DSR with the ""MSISDN Withdrawal"" bit set, to remove an existing MSISDN value from the subscription profile stored in the MME/SGSN. 24 Emergency Service Continuity O Support of Emergency Services Continuity This feature is applicable to the ULR/ULA, NOR/NOA and IDR/IDA command pairs over the S6a interface, when the HSS and the MME support the continuity of emergency services upon mobility between 3GPP and WLAN accesses, as specified in 3GPPÊTSÊ23.401Ê[2], or continuity of emergency services upon mobility between EPS and 5GS without N26 interface, as specified in 3GPPÊTSÊ23.502Ê[67]. If the MME does not indicate support of this feature in a former ULR command, the HSS shall not include the Emergency Info in an ULA command and shall not send an IDR command to update the PGW in use for emergency services. If the HSS does not indicate support of this feature in a former ULA command, the MME shall not send a NOR command to update the PGW in use for emergency services. If the HSS supports this feature on S6a, it shall also support the Emergency Service Continuity feature on SWx, see 3GPPÊTSÊ29.273Ê[59]. 25 V2X Capability O Support of V2X Service This feature is applicable for the ULR/ULA and IDR/IDA command pairs over S6a (and S6d), when the MME (or combined MME/SGSN) supports the V2X service. If the MME or combined MME/SGSN does not support this feature, the HSS shall not send the related V2X subscription data to the MME or combined MME/SGSN within ULA. If the MME or combined MME/SGSN does not indicate support of this feature in IDA, and the HSS has sent the related V2X subscription data withinÊIDR, the HSS may store this indication, and not send any further V2X subscription data to that MME or that combined MME/SGSN. 26 External-Identifier O Support of External-Identifier This feature is applicable for the ULR/ULA, DSR/DSA and IDR/IDA command pairs over S6a (and S6d), when the MME (or combined MME/SGSN) supports the External-Identifier. If the MME or combined MME/SGSN does not support this feature: -The HSS shall not send the External-Identifier subscription data to the MME or combined MME/SGSN within ULA. -The HSS shall not send Monitoring Event configuration for UEs that are part of a group and have no MSISDN as part of its subscription data to the MME/SGSN. -The HSS shall not indicate External-Identifier-Withdrawal in the DSR-Flags AVP of the DSR. 27 NR as Secondary RAT O Support of NR as Secondary RAT This feature is applicable to the ULR/ULA and IDR/IDA command pairs over S6a (and S6d) when the MME (or combined MME/SGSN) supports NR as Secondary RAT, and over S6d when the SGSN supports the indication related to NR as Secondary RAT (such as, e.g., the related Access Restriction Data, or extended QoS parameters). If the MME, SGSN, or combined MME/SGSN does not support this feature, the HSS shall not send (in ULA) or update (in IDR) subscription data related to NR as Secondary RAT. If the HSS does not support this feature, the MME shall ignore the bit ""NR as Secondary RAT Not Allowed"" in Access-Restriction-Data. 28 Unlicensed Spectrum as Secondary RAT O Support of Unlicensed Spectrum as Secondary RAT This feature is applicable to the ULR/ULA and IDR/IDA command pairs over S6a (and S6d) when the MME (or combined MME/SGSN) supports the use of unlicensed spectrum in the form of LAA or LWA/LWIP as Secondary RAT. If the MME (or combined MME/SGSN) does not support this feature, the HSS shall not send (in ULA) or update (in IDR) subscription data related to the use of unlicensed spectrum in the form of LAA, LWA/LWIP or NR in unlicensed bands as Secondary RAT (such as, e.g., the related Access Restriction Data). If the HSS does not support this feature, the MME shall ignore the bit ""Unlicensed Spectrum as Secondary RAT Not Allowed"" in Access-Restriction-Data. 29 Ethernet PDN Type APNs O Support of Ethernet PDN Type APNs This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a and S6d interfaces. If the MME (or combined MME/SGSN) does not indicate support of this feature in the ULR command, the HSS shall not send APN configurations with an Ethernet PDN type in the subscription data sent in ULA or in IDR, and shall not send IDR commands with the only purpose to update such subscription data. If the MME (or combined MME/SGSN) indicates in the IDA command that it does not support this feature, and the HSS has already sent Ethernet PDN Type APNs withinÊIDR, the HSS may store this indication, and not send any further updates related to Ethernet PDN Type APNs to that MME (or combined MME/SGSN). 30 Extended Reference IDs O Extended Reference IDs This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a or S6d interfaces, when the HSS and MME/SGSN support handling 64-bit long Reference IDs. If the MME or SGSN does not indicate support of this feature in ULR, the HSS shall not send ULA or IDR commands containing 64-bit long SCEF Reference IDs or SCEF Reference IDs for Deletion. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""SMS in MME"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. NOTE 1: If both bits, corresponding to the same feature defined for Lg interface and Lgd interface, are not set, and the HSS supports the feature, the HSS shall not send the related LCS information to the SGSN within ULA and IDR. Features that are not indicated in the Supported-Features AVPs within a given application message shall not be used to construct that message. 7.3.10.2 Feature-List AVP for the S7a/S7d application For the S7a/S7d application, the feature list does not contain any feature in this release. 7.3.11 Requested-EUTRAN-Authentication-Info The Requested-EUTRAN-Authentication-Info is of type Grouped. It shall contain the information related to the authentication requests for E-UTRAN. AVP format Requested-EUTRAN-Authentication-Info ::= <AVP header: 1408 10415> [ Number-Of-Requested-Vectors ] [ Immediate-Response-Preferred ] [ Re-synchronization-Info ] *[AVP] 7.3.12 Requested-UTRAN- GERAN-Authentication-Info The Requested-UTRAN-GERAN-Authentication-Info is of type Grouped. It shall contain the information related to the to authentication requests for UTRAN or GERAN. AVP format Requested-UTRAN-GERAN-Authentication-Info ::= <AVP header: 1409 10415> [ Number-Of-Requested-Vectors] [ Immediate-Response-Preferred ] [ Re-synchronization-Info ] *[AVP] 7.3.13 RAT-Type The RAT-Type AVP is of type Enumerated and is used to identify the radio access technology that is serving the UE. See 3GPPÊTSÊ29.212Ê[10] for the defined values. 3GPPÊTSÊ29.212Ê[10] defines distinct RAT-Type values for EUTRAN (WB-EUTRAN), EUTRAN-NB-IoT, LTE-M, WB-EUTRAN over satellite access, EUTRAN-NB-IoT over satellite access, LTE-M over satellite access; these values shall be used in the signaling between the serving nodes (MME/SGSN) and the HSS, e.g. to determine the corresponding access restrictions for the UE. 7.3.14 Number-Of-Requested-Vectors The Number-Of-Requested-Vectors AVP is of type Unsigned32. This AVP shall contain the number of AVs the MME or SGSN is prepared to receive. 7.3.15 Re-Synchronization-Info The Re-Synchronization-Info AVP is of type OctetString. It shall contain the concatenation of RAND and AUTS. 7.3.16 Immediate-Response-Preferred The Immediate-Response-Preferred AVP is of type Unsigned32. This optional AVP indicates by its presence that immediate response is preferred, and by its absence that immediate response is not preferred. If present, the value of this AVP is not significant. When EUTRAN-AVs and UTRAN-AVs or GERAN-AVs are requested, presence of this AVP within the Requested-EUTRAN-Authentication-Info AVP shall indicate that EUTRAN-AVs are requested for immediate use in the MME/SGSN; presence of this AVP within the Requested-UTRAN-GERAN-Authentication-Info AVP shall indicate that UTRAN-AVs or GERAN-AVs are requested for immediate use in the MME/SGSN. It may be used by the HSS to determine the number of vectors to be obtained from the AuC and the number of vectors downloaded to the MME or SGSN. 7.3.17 Authentication-Info The Authentication-Info AVP is of type Grouped. This AVP contains Authentication Vectors. AVP format: Authentication-Info ::= <AVP header: 1413 10415> *[ E-UTRAN-Vector ] *[UTRAN-Vector] *[GERAN-Vector] *[AVP] 7.3.18 E-UTRAN-Vector The E-UTRAN-Vector AVP is of type Grouped. This AVP shall contain an E-UTRAN Vector. AVP format: E-UTRAN-Vector ::= <AVP header: 1414 10415> [ Item-Number ] { RAND } { XRES } { AUTN } { KASME } *[AVP] 7.3.19 UTRAN-Vector The UTRAN-Vector AVP is of type Grouped. This AVP shall contain an UTRAN Vector. AVP format: UTRAN-Vector ::= <AVP header: 1415 10415> [ Item-Number ] { RAND } { XRES } { AUTN } { Confidentiality-Key } { Integrity-Key } *[AVP] 7.3.20 GERAN-Vector The GERAN-Vector AVP is of type Grouped. This AVP shall contain a GERAN Vector. AVP format: GERAN-Vector ::= <AVP header: 1416 10415> [ Item-Number ] { RAND } { SRES } { Kc } *[AVP] 7.3.21 Network-Access-Mode The Network-Access-Mode AVP is of type Enumerated. The following values are defined: PACKET_AND_CIRCUIT (0) Reserved (1) ONLY_PACKET (2) 7.3.22 HPLMN-ODB The HPLMN-ODB AVP is of type Unsigned32 and it shall contain a bit mask indicating the HPLMN specific services of a subscriber that are barred by the operator. The meaning of the bits is HPLMN specific: Table 7.3.22/1: HPLMN-ODB Bit Description 0 HPLMN specific barring type 1 1 HPLMN specific barring type 2 2 HPLMN specific barring type 3 3 HPLMN specific barring type 4 HPLMN-ODB may apply to mobile originated short messages; See 3GPPÊTSÊ23.015Ê[36]. 7.3.23 Item-Number The Item-Number AVP is of type Unsigned32. The Item Number is used to order Vectors received within one request. 7.3.24 Cancellation-Type The Cancellation-Type AVP is of type Enumerated and indicates the type of cancellation. The following values are defined: MME_UPDATE_PROCEDURE (0) This value is used when the Cancel Location is sent to the previous MME due to a received Update Location message from a new MME or due to the HSS+UDM receiving an Nudm_UEContextManagement service request from the AMF or due to the HSS receiving Nhss_UECM_SNDeregistration service operation from UDM (see clauseÊ5.4.2.2 of 3GPPÊTSÊ29.563Ê[70]). SGSN_UPDATE_PROCEDURE (1) This value is used when the Cancel Location is sent to the previous SGSN due to a received Update Location message from a new SGSN or due to the HSS+UDM receiving an Nudm_UEContextManagement service request from the AMF or due to the HSS receiving Nhss_UECM_SNDeregistration service operation from UDM (see clauseÊ5.4.2.2 of 3GPPÊTSÊ29.563Ê[70])."
"SUBSCRIPTION_WITHDRAWAL (2) This value is used: - when the Cancel Location is sent by the HSS to the current MME or SGSN due to withdrawal of the user's subscription by the HSS operator; - when the Cancel VCSG Location is sent by the CSS to the current MME or SGSN due to withdrawal of the user's VPLMN CSG subscription by the CSS operator. UPDATE_PROCEDURE_IWF (3) This value is used by an IWF when interworking with a pre-Rel-8 HSS. INITIAL_ATTACH_PROCEDURE (4) This value is used when the Cancel Location is sent to the MME or SGSN due to a received Update Location message during initial attach procedure from an SGSN or MME respectively. 7.3.25 DSR-Flags The DSR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits is defined in table 7.3.25/1: Table 7.3.25/1: DSR-Flags Bit Name Description 0 Regional Subscription Withdrawal This bit, when set, indicates that Regional Subscription shall be deleted from the subscriber data. 1 Complete APN Configuration Profile Withdrawal This bit, when set, indicates that all EPS APN configuration data for the subscriber shall be deleted from the subscriber data. This flag only applies to the S6d interface. 2 Subscribed Charging Characteristics Withdrawal This bit, when set, indicates that the Subscribed Charging Characteristics have been deleted from the subscription data. 3 PDN subscription contexts Withdrawal This bit, when set, indicates that the PDN subscription contexts whose identifier is included in the Context-Identifier AVP shall be deleted. (Note 1) 4 STN-SR This bit, when set, indicates that the Session Transfer Number for SRVCC shall be deleted from the subscriber data. 5 Complete PDP context list Withdrawal This bit, when set, indicates that all PDP contexts for the subscriber shall be deleted from the subscriber data. 6 PDP contexts Withdrawal This bit, when set, indicates that the PDP contexts whose identifier is included in the Context-Identifier AVP shall be deleted. (Note 2) 7 Roaming Restricted due to unsupported feature This bit, when set, indicates that the roaming restriction shall be deleted from the subscriber data in the MME or SGSN. 8 Trace Data Withdrawal This bit, when set, indicates that the Trace Data shall be deleted from the subscriber data. 9 CSG Deleted This bit, when set, indicates that - the ""CSG-Subscription-Data from HSS"" shall be deleted in the MME or SGSN when received over the S6a or S6d interface - the ""CSG-Subscription-Data from CSS"" shall be deleted in the MME or SGSN when received over the S7a or S7d interface. 10 APN-OI-Replacement This bit, when set, indicates that the UE level APN-OI-Replacement shall be deleted from the subscriber data. 11 GMLC List Withdrawal This bit, when set, indicates that the subscriber's LCS GMLC List shall be deleted from the MME or SGSN. 12 LCS Withdrawal This bit, when set, indicates that the LCS service whose code is included in the SS-Code AVP shall be deleted from the MME or SGSN. 13 SMS Withdrawal This bit, when set, indicates that the SMS service whose code is included in the SS-Code AVP or TS-Code AVP shall be deleted from the MME or SGSN. 14 Subscribed periodic RAU-TAU Timer Withdrawal This bit, when set, indicates that the subscribed periodic RAU TAU Timer value shall be deleted from the subscriber data. 15 Subscribed VSRVCC Withdrawal This bit, when set, indicates that the Subscribed VSRVCC shall be deleted from the subscriber data. 16 A-MSISDN Withdrawal This bit, when set, indicates that the additional MSISDN, if present, shall be deleted from the subscriber data. 17 ProSe Withdrawal This bit, when set, indicates that the ProSe subscription data shall be deleted from the MME or combined MME/SGSN. 18 Reset-IDs This bit, when set, indicates that the set of Reset-IDs shall be deleted from the MME or SGSN. 19 DL-Buffering-Suggested-Packet-Count Withdrawal This bit, when set, indicates that the DL-Buffering-Suggested-Packet-Count shall be deleted in the MME or SGSN. 20 Subscribed IMSI-Group-Id Withdrawal This bit, when set, indicates that all subscribed IMSI-Group-Id(s) shall be deleted in the MME or SGSN. 21 Delete monitoring events This bit when set indicates to the MME or SGSN to delete all the Monitoring events for the subscriber which are associated with the provided SCEF-ID. 22 User Plane Integrity Protection Withdrawal This bit, when set, indicates to the SGSN that User Plane Integrity Protection may no longer be required when GERAN is used. The MME shall ignore it. 23 MSISDN Withdrawal This bit, when set, indicates that the MSISDN shall be deleted from the subscriber data. It is also used by the MME/SGSN to delete those monitoring events created using the MSISDN. 24 UE Usage Type Withdrawal This bit, when set, indicates to the MME or SGSN that the UE Usage Type shall be deleted from the subscription data. 25 V2X Withdrawal This bit, when set, indicates that the V2X subscription data shall be deleted from the MME or combined MME/SGSN. 26 External-Identifier-Withdrawal This bit, when set, indicates that the External-Identifier shall be deleted from the subscriber data. It is also used by the MME/SGSN to delete those monitoring events created using the removed External Identifier or all monitoring events created for any External Identifier in case of removing the default External Identifier. 27 Aerial-UE-Subscription Withdrawal This bit, when set, indicates that the Aerial UE subscription shall be deleted from the subscriber data. 28 Paging Time Window Subscription Withdrawal This bit, when set, indicates that the Paging Time Window subscription shall be deleted from the subscriber data. 29 Active-Time-Withdrawal This bit, when set, indicates that the Active Time used for PSM shall be deleted from the subscriber data. 30 eDRX-Cycle-Length -Withdrawal This bit, when set, indicates that the eDRX-Cycle-Length shall be deleted from the subscriber data. . If the eDRX-Related-RAT is present in the DSR command, only the eDRX Cycle Length for indicated RAT types shall be deleted. Otherwise, the entire eDRX Cycle Length subscription for all RAT types shall be deleted. 31 Service-Gap-Time-Withdrawal This bit, when set, indicates that the Service Gap Time shall be deleted from the subscriber data. Note 1: If the Complete APN Configuration Profile Withdrawal bit is set, this bit should not be set. Note 2: If the Complete PDP context list Withdrawal bit is set, this bit should not be set. Note 3: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. Note 4: Bits 3 and 6 are excluding alternatives and shall not both be set. Note 5: When this AVP is transferred over the S7a/S7d interface, only the bit 9 (CSG Deleted) is meaningful, other bits shall be cleared. 7.3.26 DSA-Flags The DSA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits is defined in table 7.3.26/1: Table 7.3.26/1: DSA-Flags Bit Name Description 0 Network Node area restricted This bit, when set, shall indicate that the complete Network Node area (SGSN area) is restricted due to regional subscription. Note: Bits not defined in this table shall be cleared by the sending SGSN and discarded by the receiving HSS. 7.3.27 Context-Identifier The Context-Identifier AVP is of type Unsigned32. 7.3.28 Void 7.3.29 Subscriber-Status The 3GPP Subscriber Status AVP is of type Enumerated. It shall indicate if the service is barred or granted. The following values are defined: SERVICE_GRANTED (0) OPERATOR_DETERMINED_BARRING (1) 7.3.30 Operator-Determined-Barring The Operator-Determined-Barring AVP is of type Unsigned32 and it shall contain a bit mask indicating the services of a subscriber that are barred by the operator. The meaning of the bits is the following: Table 7.3.30/1: Operator-Determined-Barring Bit Description 0 All Packet Oriented Services Barred 1 Roamer Access HPLMN-AP Barred 2 Roamer Access to VPLMN-AP Barred 3 Barring of all outgoing calls 4 Barring of all outgoing international calls 5 Barring of all outgoing international calls except those directed to the home PLMN country 6 Barring of all outgoing inter-zonal calls 7 Barring of all outgoing inter-zonal calls except those directed to the home PLMN country 8 Barring of all outgoing international calls except those directed to the home PLMN country and Barring of all outgoing inter-zonal calls 7.3.31 Access-Restriction-Data The Access-Restriction-Data AVP is of type Unsigned32 and it shall contain a bit mask where each bit when set to 1 indicates a restriction. The meaning of the bits is the following: Table 7.3.31/1: Access-Restriction-Data Bit Description 0 UTRAN Not Allowed 1 GERAN Not Allowed 2 GAN Not Allowed 3 I-HSPA-Evolution Not Allowed 4 WB-E-UTRAN Not Allowed 5 HO-To-Non-3GPP-Access Not Allowed 6 NB-IoT Not Allowed 7 Enhanced Coverage Not Allowed 8 NR as Secondary RAT in E-UTRAN Not Allowed 9 Unlicensed Spectrum as Secondary RAT Not Allowed 10 NR in 5GS Not Allowed 11 LTE-M Not Allowed 12 WB-E-UTRAN Except LTE-M Not Allowed 13 WB-E-UTRAN(LEO) Not Allowed 14 WB-E-UTRAN(MEO) Not Allowed 15 WB-E-UTRAN(GEO) Not Allowed 16 WB-E-UTRAN(OTHERSAT) Not Allowed 17 NB-IoT(LEO) Not Allowed 18 NB-IoT(MEO) Not Allowed 19 NB-IoT(GEO) Not Allowed 20 NB-IoT(OTHERSAT) Not Allowed 21 LTE-M(LEO) Not Allowed 22 LTE-M(MEO) Not Allowed 23 LTE-M(GEO) Not Allowed 24 LTE-M(OTHERSAT) Not Allowed 25 NR (LEO) Not Allowed 26 NR (MEO) Not Allowed 27 NR (GEO) Not Allowed 28 NR (OTHERSAT) Not Allowed NOTEÊ1: Bits not defined in this table shall be cleared by the HSS and discarded by the receiving MME/SGSN. NOTEÊ2: Bits 11 and 12 are only used when bit 4 is not set. The restriction ""HO-To-Non-3GPP-Access Not Allowed"" shall take a higher precedence than the APN-level parameter ""WLAN-Offloadability"" (see clauseÊ7.3.181). 7.3.32 APN-OI-Replacement The APN-OI-Replacement AVP is of type UTF8String. This AVP shall indicate the domain name to replace the APN OI for the non-roaming case and the home routed roaming case when constructing the APN, and the APN-FQDN upon which to perform a DNS resolution. See 3GPPÊTSÊ23.003Ê[3] and 3GPPÊTSÊ29.303Ê[38]. The contents of the APN-OI-Replacement AVP shall be formatted as a character string composed of one or more labels separated by dots ("".""). 7.3.33 All-APN-Configurations-Included-Indicator The All-APN-Configurations-Included-Indicator AVP is of type Enumerated. The following values are defined: All_APN_CONFIGURATIONS_INCLUDED (0) MODIFIED_ADDED_APN_CONFIGURATIONS_INCLUDED (1) 7.3.34 APN-Configuration-Profile The APN-Configuration-Profile AVP is of type Grouped. It shall contain the information related to the user's subscribed APN configurations for EPS. The AVP format shall conform to: APN-Configuration-Profile ::= <AVP header: 1429 10415> { Context-Identifier } [ Additional-Context-Identifier ] [ Third-Context-Identifier ] { All-APN-Configurations-Included-Indicator } 1*{APN-Configuration} *[AVP] The Subscription-Data AVP associated with an IMSI contains one APN-Configuration-Profile AVP. Each APN-Configuration-Profile AVP contains one or more APN-Configuration AVPs. Each APN-Configuration AVP describes the configuration for a single APN. Therefore, the cardinality of the relationship between IMSI and APN is one-to-many. The Context-Identifier AVP shall identify the per subscriber's default APN configuration. If present, the Additional-Context-Identifier AVP shall identify another default APN configuration, only for those subscriptions containing more than one types of APNs i.e. among APNs with an IP-based PDN type, APNs with a Non-IP PDN type, and APNs with an Ethernet PDN type; in this case, each of those two default APN configurations shall have a different PDN type category (e.g. one default APN with an IP-based PDN type, and another default APN with a Non-IP PDN type). If present, the Third-Context-Identifier AVP shall identify another default APN configuration, only for those subscriptions containing more than two types of APNs i.e. among APNs with an IP-based PDN type, APNs with a Non-IP PDN type, and APNs with an Ethernet PDN type; in this case, each of those three default APN configurations shall have a different PDN type category (i.e. one default APN with an IP-based PDN type, and another default APN with a Non-IP PDN type and one default APN with an Ethernet PDN type). 7.3.35 APN-Configuration The APN-Configuration AVP is of type Grouped. It shall contain the information related to the user's subscribed APN configurations. The Context-Identifier in the APN-Configuration AVP shall identify that APN configuration, and it shall not have a value of zero. Furthermore, the Context-Identifier in the APN-Configuration AVP shall uniquely identify the EPS APN configuration per subscription. For a particular EPS user having multiple APN configurations, the Service-Selection AVP values shall be unique across APN-Configuration AVPs. The AVP format shall conform to: APN-Configuration ::= <AVP header: 1430 10415> { Context-Identifier } * 2Ê[ Served-Party-IP-Address ] { PDN-Type } { Service-Selection} [ EPS-Subscribed-QoS-Profile ] [ VPLMN-Dynamic-Address-Allowed ] [MIP6-Agent-Info ] [ Visited-Network-Identifier ] [ PDN-GW-Allocation-Type ] [ 3GPP-Charging-Characteristics ] [ AMBR ] *[ Specific-APN-Info ] [ APN-OI-Replacement ] [ SIPTO-Permission ] [ LIPA-Permission ] [ Restoration-Priority ] [ SIPTO-Local-Network-Permission ] [ WLAN-offloadability ] [ Non-IP-PDN-Type-Indicator ] [ Non-IP-Data-Delivery-Mechanism ] [ SCEF-ID ] [ SCEF-Realm ] [ Preferred-Data-Mode ] [ PDN-Connection-Continuity ] [ RDS-Indicator ] [ Interworking-5GS-Indicator ] [ Ethernet-PDN-Type-Indicator ] *[ AVP ] The AMBR included in this grouped AVP shall include the AMBR associated to this specific APN configuration (APN-AMBR). The Served-Party-IP-Address AVP may be present 0, 1 or 2 times. These AVPs shall be present if static IP address allocation is used for the UE, and they shall contain either of: - an IPv4 address, or - an IPv6 address/prefix, or - both, an IPv4 address and an IPv6 address/prefix. For the IPv6 prefix, the lower 64 bits of the address shall be set to zero. The PDN-GW-Allocation-Type AVP applies to the MIP6-Agent-Info AVP. Therefore, it shall not be present if MIP6-Agent-Info is not present. The APN-OI-Replacement included in this grouped AVP shall include the APN-OI-Replacement associated with this APN configuration. This APN-OI-Replacement has higher priority than UE level APN-OI-Replacement. The Visited-Network-Identifier AVP indicates the PLMN where the PGW was allocated, in case of dynamic PGW assignment. NOTE: If interworking with MAP is needed, the Context-Identifier will be in the range of 1 and 50. The Non-IP-Data-Delivery-Mechanism shall only be present when Non-IP-PDN-Type-Indicator is set to TRUE (1). The SCEF-ID AVP and the SCEF-Realm AVP shall only be present when Non-IP-PDN-Type-Indicator is set to TRUE (1), and Non-IP-Data-Delivery-Mechanism is set to SCEF-BASED-DATA-DELIVERY (1). The RDS-Indicator may be present when Non-IP-PDN-Type-Indicator is set to TRUE (1), and Non-IP-Data-Delivery-Mechanism is set to SCEF-BASED-DATA-DELIVERY (1). Absence of PDN-Connection-Continuity AVP indicates that the handling is left to local VPLMN policy. 7.3.36 Service-Selection The Service-Selection AVP is of type of UTF8String. This AVP shall contain either the APN Network Identifier (i.e. an APN without the Operator Identifier) per 3GPPÊTSÊ23.003Ê[3], clauses 9.1 & 9.1.1, or this AVP shall contain the wild card value per 3GPPÊTSÊ23.003Ê[3], clauseÊ9.2.1, and 3GPPÊTSÊ23.008Ê[30], clauseÊ2.13.6). The contents of the Service-Selection AVP shall be formatted as a character string composed of one or more labels separated by dots ("".""), or as the wild card APN, i.e., consisting of only one ASCII label, ""*"". This AVP is defined in IETFÊRFCÊ5778[20]. 7.3.37 EPS-Subscribed-QoS-Profile The EPS-Subscribed-QoS-Profile AVP is of type Grouped. It shall contain the bearer-level QoS parameters (QoS Class Identifier and Allocation Retention Priority) associated to the default bearer for an APN (see 3GPPÊTSÊ23.401Ê[2], clauseÊ4.7.3). AVP format EPS-Subscribed-QoS-Profile ::= <AVP header: 1431 10415> { QoS-Class-Identifier } { Allocation-Retention-Priority } *[AVP] NOTE: QoS-Class-Identifier is defined in 3GPPÊTSÊ29.212Ê[10] as an Enumerated AVP. The values allowed for this AVP over the S6a/S6d interface are only those associated to non-GBR bearers, as indicated in 3GPPÊTSÊ23.008Ê[30]; e.g., values QCI_1, QCI_2, QCI_3 and QCI_4, which are associated to GBR bearers, cannot be sent over S6a/S6d. 7.3.38 VPLMN-Dynamic-Address-Allowed The VPLMN-Dynamic-Address-Allowed AVP is of type Enumerated. It shall indicate whether for this APN, the UE is allowed to use the PDN GW in the domain of the HPLMN only, or additionally, the PDN GW in the domain of the VPLMN.. If this AVP is not present, this means that the UE is not allowed to use PDN GWs in the domain of the VPLMN. The following values are defined: NOTALLOWED (0) ALLOWED (1) 7.3.39 STN-SR The STN-SR AVP is of type OctetString and shall contain the Session Transfer Number for SRVCC. See 3GPPÊTSÊ23.003Ê[3] for the definition of STN-SR. This AVP contains an STN-SR, in international number format as described in ITU-T Rec E.164Ê[41], encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.40 Allocation-Retention-Priority The Allocation-Retention-Priorit AVP is of typeGrouped and is defined in 3GPPÊTSÊ29.212Ê[10]. It shall indicate the Priority of Allocation and Retention for the corresponding APN configuration. AVP format Allocation-Retention-Priority ::= <AVP header: 1034 10415> { Priority-Level } [ Pre-emption-Capability ] [ Pre-emption-Vulnerability ] If the Pre-emption-Capability AVP is not present in the Allocation-Retention-Priority AVP, the default value shall be PRE-EMPTION_CAPABILITY_DISABLED (1). If the Pre-emption-Vulnerability AVP is not present in the Allocation-Retention-Priority AVP, the default value shall be PRE-EMPTION_VULNERABILITY_ENABLED (0). 7.3.41 AMBR The AMBR AVP is of type Grouped. It shall contain the maximum requested bandwidth for Uplink and Downlink traffic. The Max-Requested-Bandwidth-(UL/DL) AVPs shall encode the bandwidth value in bits per second, having an upper limit of 4294967295 bits per second. The Extended-Max-Requested-BW-(UL/DL) AVPs shall encode the bandwidth value in kilobits (1000 bits) per second, having an upper limit of 4294967295 kilobits per second. When the maximum bandwidth value to be set for UL (or DL, respectively) traffic is lower than 4294967296 bits per second, the Max-Requested-Bandwidth-UL (or -DL, respectively) AVP shall be present, and set to the requested bandwidth value in bits per second, and the Extended-Max-Requested-BW-UL (or -DL, respectively) AVP shall be absent. When the maximum bandwidth value to be set for UL (or DL, respectively) traffic is higher than 4294967295 bits per second, the Max-Requested-Bandwidth-UL (or DL, respectively) AVP shall be present, and set to its upper limit 4294967295, and the Extended-Max-Requested-BW-UL (or -DL, respectively) shall be present, and set to the requested bandwidth value in kilobits (1000 bits) per second. NOTE: The value applicable for Max-Requested-Bandwidth-UL (or DL, respectively) is between 1 and 4294967295 bits per second, and the value applicable for Extended-Max-Requested-BW-UL (or -DL, respectively) is between 4294968 and 4294967295 kilobits per second. The AMBR AVP cannot indicate the requested bandwidth between 4294967296 and 4294967999 bits per second, and any larger value that cannot be represented in the granularity of kilobits per second. AVP format AMBR ::= <AVP header: 1435 10415> { Max-Requested-Bandwidth-UL } { Max-Requested-Bandwidth-DL } [ Extended-Max-Requested-BW-UL ] [ Extended-Max-Requested-BW-DL ] *[AVP] 7.3.42 MIP-Home-Agent-Address The MIP-Home-Agent-Address AVP is of type Address and is defined in IETFÊRFCÊ4004Ê[27]. This AVP shall contain either IPv4 or IPv6 address of the PDN-GW and this IP address shall be used as the PDN-GW IP address. 7.3.43 MIP-Home-Agent-Host The MIP-Home-Agent-Host is of type Grouped and is defined in IETFÊRFCÊ4004Ê[27]. This AVP shall contain a FQDN of the PDN-GW which shall be used to resolve the PDN-GW IP address using the Domain Name Service function. MIP-Home-Agent-Host grouped AVP is composed by Destination-Host and Destination-Realm AVPs. Destination-Host shall contain the hostname of the PDN-GW, formatted as described in 3GPPÊTSÊ29.303Ê[38], clauseÊ4.3.2. Destination-Realm shall be formatted as: epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org where MNC and MCC values indicate the PLMN where the PDN-GW is located. 7.3.44 PDN-GW-Allocation-Type The PDN-GW-Allocation-Type AVP is of type Enumerated. It shall indicate whether the PDN GW address included in MIP6-Agent-Info has been statically allocated (i.e. provisioned in the HSS by the operator), or dynamically selected by other nodes. The following values are defined: STATIC (0) DYNAMIC (1) 7.3.45 MIP6-Agent-Info The MIP6-Agent-InfoAVP is of type Grouped and is defined in IETFÊRFCÊ5447Ê[26]. This AVP shall contain the identity of the PDN-GW. This AVP is used to convey the identity of the PDN-GW between the MME/SGSN and the HSS regardless of the specific mobility protocol used (GTP or PMIPv6). The identity of PDN-GW is either an IP address transported in MIP-Home-Agent-Address or an FQDN transported in MIP-Home-Agent-Host. FQDN shall be used if known to the MME/SGSN/HSS. AVP format MIP6-Agent-Info ::= < AVP Header: 486 > *2[ MIP-Home-Agent-Address ] [ MIP-Home-Agent-Host ] [ MIP6-Home-Link-Prefix ] *[ AVP ] Within the MIP6-Agent-Info AVP, if static address allocation is used, there may be either: - an IPv4 address or an IPv6 address of the PGW contained in one MIP-Home-Agent-Address AVP; - both IPv4 address and IPv6 address of the PGW contained in two MIP-Home-Agent-Address AVPs. The AVP MIP6-Home-Link-Prefix is not used in S6a/S6d, but it is included here to reflect the complete IETF definition of the grouped AVP. 7.3.46 RAT-Frequency-Selection-Priority-ID The RAT-Frequency-Selection-Priority-ID AVP is of type Unsigned32 and shall contain the subscribed value of Subscriber Profile ID for RAT/Frequency Priority. For details, see 3GPPÊTSÊ23.401Ê[2] and 3GPPÊTSÊ23.060Ê[12] . The coding is defined in 3GPPÊTSÊ36.413Ê[19]. Values shall be in the range of 1 to 256. 7.3.47 IDA-Flags The IDA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meanings of the bits are defined in table 7.3.47/1: Table 7.3.47/1: IDA-Flags Bit Name Description 0 Network Node area restricted This bit, when set, shall indicate that the complete Network Node area (SGSN area) is restricted due to regional subscription. Note: Bits not defined in this table shall be cleared by the sending SGSN and discarded by the receiving HSS. 7.3.48 PUA-Flags The PUA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meanings of the bits are defined in table 7.3.48/1: Table 7.3.48/1: PUA-Flags bit name Description 0 Freeze M-TMSI This bit, when set, shall indicate to the MME that the M-TMSI needs to be frozen, i.e. shall not be immediately re-used. 1 Freeze P-TMSI This bit, when set, shall indicate to the SGSN that the P-TMSI needs to be frozen, i.e. shall not be immediately re-used. Note: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.49 NOR-Flags The NOR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in table 7.3.49/1: Table 7.3.49/1: NOR-Flags bit name Description 0 Single-Registration-Indication This bit, when set, indicates that the HSS shall send Cancel Location to the SGSN. An SGSN shall not set this bit when sending NOR. 1 SGSN area restricted This bit, when set, shall indicate that the complete SGSN area is restricted due to regional subscription. 2 Ready for SM from SGSN This bit, when set, shall indicate that the UE is present or the UE has memory capacity available to receive one or more short messages via SGSN. 3 UE Reachable from MME This bit, when set, shall indicate that the UE has become reachable again from MME. 4 Reserved The use of this bit is deprecated. This bit shall be discarded by the receiving HSS. 5 UE Reachable from SGSN This bit, when set, shall indicate that the UE has become reachable again from SGSN. 6 Ready for SM from MME This bit, when set, shall indicate that the UE is present or the UE has memory capacity available to receive one or more short messages via MME. 7 Homogeneous Support of IMS Voice Over PS Sessions This bit, when set, shall indicate that the Homogeneous Support of IMS Voice Over PS Sessions is updated. 8 S6a/S6d-Indicator This bit, when set, shall indicate that the NOR message is sent on the S6a interface, i.e. the message is from the MME or the MME part on the combined MME/SGSN. This bit, when cleared, indicates that the NOR message is sent on the S6d interface, i.e. the message is from the SGSN or the SGSN part on the combined MME/SGSN. 9 Removal of MME Registration for SMS This bit, when set, shall indicate that the MME requests to remove its registration for SMS. NOTE 1: The S6a/S6d-Indicator flag shall be used together with Homogeneous Support of IMS Voice Over PS Sessions flag, i.e. if the Homogeneous Support of IMS Voice Over PS Sessions bit is set, the S6a/S6d-Indicator bit shall be set if the message is sent from the MME or the MME part on the combined MME/SGSN, and shall be cleared if the message is sent from the SGSN or the SGSN part on the combined MME/SGSN. This S6a/S6d-Indicator bit shall be discarded by the receiving HSS if the Homogeneous Support of IMS Voice Over PS Sessions bit is not set. NOTE 2: Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving HSS. 7.3.50 User-Id The User-Id AVP shall be of type UTF8String. It shall contain the leading digits of an IMSI (i.e. MCC, MNC, leading digits of MSIN, see 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2) formatted as a character string. Within a HSS, a User-Id identifies a set of subscribers, each with identical leading IMSI digits. 7.3.51 Equipment-Status The Equipment-Status AVP is of type Enumerated, and shall contain the status of the mobile equipment. The following values are defined: PERMITTEDLISTED (0) PROHIBITEDLISTED (1) TRACKINGLISTED (2) 7.3.52 Regional-Subscription-Zone-Code The Regional-Subscription-Zone-Code AVP is of type OctetString. It shall contain a Zone Code (ZC) as defined in 3GPPÊTSÊ23.003Ê[3], clauseÊ4.4. Up to 10 Zone Codes per VPLMN can be defined as part of the users's subscription data. NOTE 1: Each zone code represents a collection of tracking area or routing areas (defined by the operator of the VPLMN) where the user is allowed, or disallowed, to roam. The determination of which areas are actually allowed, and which ones are not allowed, is done by the serving node (MME/SGSN) in an implementation-dependent manner. NOTE 2: The description of RSZI in 3GPPÊTSÊ23.003Ê[3] is applicable, in the context of this specification, not only to location areas, but also to routing and tracking areas. 7.3.53 RAND The RAND AVP is of type OctetString. This AVP shall contain the RAND. See 3GPPÊTSÊ33.401Ê[5]. 7.3.54 XRES The XRES AVP is of type OctetString. This AVP shall contain the XRES. See 3GPPÊTSÊ33.401Ê[5]. 7.3.55 AUTN The AUTN AVP is of type OctetString. This AVP shall contain the AUTN. See 3GPPÊTSÊ33.401Ê[5]. 7.3.56 KASME The KASME AVP is of type OctetString. This AVP shall contain the K_ASME. See 3GPPÊTSÊ33.401Ê[5]. 7.3.57 Confidentiality-Key AVP The Confidentiality-Key is of type OctetString, and shall contain the Confidentiality Key (CK). 7.3.58 Integrity-Key AVP The Integrity-Key is of type OctetString, and shall contain the Integrity Key (IK). 7.3.59 Kc AVP The Kc AVP is of type OctetString, and shall contain the Ciphering Key (Kc). 7.3.60 SRES The SRES AVP is of type OctetString. This AVP shall contain the SRES. See 3GPPÊTSÊ33.102Ê[18]. 7.3.61 Void 7.3.62 PDN-Type The PDN-Type AVP is of type Enumerated and indicates the address type of the PDN, when it is IP-based. NOTE: There are certain PDNs that can be accessed without using IP. These are identified by a specific PDN type indicator in their APN configuration settings (e.g. see clauses 7.3.204 and 7.3.232). The following values are defined: IPv4 (0) This value shall be used to indicate that the PDN can be accessed only in IPv4 mode. IPv6 (1) This value shall be used to indicate that the PDN can be accessed only in IPv6 mode. IPv4v6 (2) This value shall be used to indicate that the PDN can be accessed both in IPv4 mode, in IPv6 mode, and also from UEs supporting dualstack IPv4v6. IPv4_OR_IPv6 (3) This value shall be used to indicate that the PDN can be accessed either in IPv4 mode, or in IPv6 mode, but not from UEs supporting dualstack IPv4v6. It should be noted that this value will never be used as a requested PDN Type from the UE, since UEs will only use one of their supported PDN Types, i.e., IPv4 only, IPv6 only or IPv4v6 (dualstack). This value is only used as part of the APN subscription context, as an authorization mechanism between HSS and MME. 7.3.63 Trace-Data AVP The Trace-Data AVP is of type Grouped. This AVP shall contain the information related to trace function. AVP format Trace-Data ::= <AVP header: 1458 10415> {Trace-Reference} {Trace-Depth} {Trace-NE-Type-List} [Trace-Interface-List] {Trace-Event-List} [OMC-Id] {Trace-Collection-Entity} [MDT-Configuration] *[AVP] 7.3.64 Trace-Reference AVP The Trace-Reference AVP is of type OctetString. This AVP shall contain the concatenation of MCC, MNC and Trace ID, where the Trace ID is a 3 byte Octet String. See 3GPPÊTSÊ32.422Ê[23]. The content of this AVP shall be encoded as octet strings according to table 7.3.64/1. See 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.1.13, PLMN list, for the coding of MCC and MNC. If MNC is 2 digits long, bits 5 to 8 of octet 2 are coded as ""1111"". Table 7.3.64/1: Encoding format for Trace-Reference AVP 8 7 6 5 4 3 2 1 MCC digit 2 MCC digit 1 octet 1 MNC digit 3 MCC digit 3 octet 2 MNC digit 2 MNC digit 1 octet 3 Trace ID octet 4 octet 5 octet 6 7.3.65 Void 7.3.66 Void 7.3.67 Trace-Depth AVP The Trace-Depth AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Trace Depth. 7.3.68 Trace-NE-Type-List AVP The Trace-NE-Type-List AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ32.422Ê[23]. 7.3.69 Trace-Interface-List AVP The Trace-Interface-List AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ32.422Ê[23]. 7.3.70 Trace-Event-List AVP The Trace-Event-List AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ32.422Ê[23]. 7.3.71 OMC-Id AVP The OMC-Id AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. 7.3.72 GPRS-Subscription-Data The GPRS-Subscription-Data AVP is of type Grouped. It shall contain the information related to the user profile relevant for GPRS. AVP format: GPRS-Subscription-Data ::= <AVP header: 1467 10415> { Complete-Data-List-Included-Indicator } 1*50{PDP-Context} *[AVP] NOTE: The max number of PDP-Context AVP aligns with the value of maxNumOfPDP-Contexts as defined in 3GPPÊTSÊ29.002Ê[24]. 7.3.73 Complete-Data-List-Included-Indicator The Complete-Data-List-Included-Indicator AVP is of type Enumerated. The following values are defined: All_PDP_CONTEXTS_INCLUDED (0) MODIFIED_ADDED_PDP CONTEXTS_INCLUDED (1) 7.3.74 PDP-Context The PDP-Context AVP is of type Grouped. For a particular GPRS user having multiple PDP Context configurations, the Service-Selection AVP values may be the same for different PDP-Context AVPs. AVP format PDP-Context ::= <AVP header: 1469 10415> { Context-Identifier } { PDP-Type } [ PDP-Address ] { QoS-Subscribed } [ VPLMN-Dynamic-Address-Allowed ] { Service-Selection } [3GPP-Charging-Characteristics] [ Ext-PDP-Type ] [ Ext-PDP-Address ] [ AMBR ] [ APN-OI-Replacement ] [ SIPTO-Permission ] [ LIPA-Permission ] [ Restoration-Priority ] [ SIPTO-Local-Network-Permission ] [ Non-IP-Data-Delivery-Mechanism ] [ SCEF-ID ] *[AVP] The Ext-PDP-Address AVP may be present only if the PDP-Address AVP is present. If the Ext-PDP-Address AVP is present, then it shall not contain the same address type (IPv4 or IPv6) as the PDP-Address AVP. When PDP-Type takes the value Non-IP (HEX 02), the Ext-PDP-Type AVP shall be absent. The AMBR included in this grouped AVP shall include the AMBR associated to the APN included in the PDP-Context AVP (APN-AMBR). The APN-OI-Replacement included in this grouped AVP shall include the APN-OI-Replacement associated to the APN included in the PDP-Context. This APN-OI-Replacement has higher priority than UE level APN-OI-Replacement. The Non-IP-Data-Delivery-Mechanism shall only be present when PDP-Type takes the value Non-IP (HEX 02). The SCEF-ID shall only be present when Non-IP-Data-Delivery-Mechanism takes the value SCEF-BASED-DATA-DELIVERY (1). 7.3.75 PDP-Type The PDP-Type AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. The allowed values are one of IPv4 encoded as HEX (21) or IPv6 encoded as HEX (57) or Non-IP encoded as HEX (02). 7.3.75A Ext-PDP-Type The Ext-PDP-Type AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24] and 3GPPÊTSÊ29.060Ê[39] and shall contain the value of IPv4v6. 7.3.76 Void 7.3.77 QoS-Subscribed The QoS-Subscribed AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24] (octets of QoS-Subscribed, Ext-QoS-Subscribed, Ext2-QoS-Subscribed, Ext3-QoS-Subscribed and Ext4-QoS-Subscribed values are concatenated). 7.3.78 CSG-Subscription-Data The CSG-Subscription-Data AVP is of type Grouped. This AVP shall contain the CSG-Id, and may contain the associated Visited-PLMN-Id, an associated expiration date and the APNs which are allowed to be accessed via Local IP Access from the CSG. If the Visited-PLMN-Id is not present, the CSG-Subscription-Data corresponds to the registered PLMN (i.e. the visited PLMN) of the MME or the SGSN. AVP format CSG-Subscription-Data ::= <AVP header: 1436 10415> { CSG-Id } [ Expiration-Date ] *[ Service-Selection ] [ Visited-PLMN-Id ] *[AVP] 7.3.79 CSG-Id The CSG-Id AVP is of type Unsigned32. Values are coded according to 3GPPÊTSÊ23.003Ê[3]. Unused bits (least significant) shall be padded with zeros. 7.3.80 Expiration-Date The Expiration-Date AVP is of type Time (see IETFÊRFCÊ6733Ê[61]) and contains the point in time when subscription to the CSG-Id expires. 7.3.81 Roaming-Restricted-Due-To-Unsupported-Feature The Roaming-Restricted-Due-To-Unsupported-Feature AVP is of type Enumerated and indicates that roaming is restricted due to unsupported feature. The following value is defined: Roaming-Restricted-Due-To-Unsupported-Feature (0) 7.3.82 Specific-APN-Info AVP The Specific-APN-Info AVP is of type Grouped. It shall only be present in the APN configuration when the APN is a wild card APN. It shall contain the APN which is not present in the subscription context but the UE is authorized to connect to and the identity of the registered PDN-GW. The AVP format shall conform to: Specific-APN-Info ::= <AVP header: 1472 10415> { Service-Selection } { MIP6-Agent-Info } [ Visited-Network-Identifier ] *[ AVP ] 7.3.83 Alert-Reason AVP The Alert-Reason AVP is of type Enumerated. The following values are defined: UE_PRESENT (0) UE_MEMORY_AVAILABLE (1) 7.3.84 LCS-Info The LCS-Info AVP is of type Grouped. This AVP shall contain the following LCS related information for a subscriber: - list of GMLCs in the HPLMN that are permitted to issue a call/session unrelated or call/session related MT-LR location request for this UE; - privacy exception list that is applicable only over the S6d interface; - MO-LR list. AVP format LCS-Info ::= <AVP header: 1473 10415> *[ GMLC-Number] *[ LCS-PrivacyException ] *[ MO-LR ] *[AVP] 7.3.85 GMLC-Number The GMLC-Number AVP is of type OctetString. This AVP shall contain the ISDN number of the GMLC in international number format as described in ITU-T Rec E.164Ê[41] and shall be encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.86 LCS-PrivacyException The LCS-PrivacyException AVP is of type Grouped. This AVP shall contain the classes of LCS Client that are allowed to locate any target UE. AVP format LCS-PrivacyException ::= <AVP header: 1475 10415> { SS-Code } { SS-Status } [ Notification-To-UE-User ] *[ External-Client ] *[ PLMN-Client ] *[ Service-Type ] *[AVP] 7.3.87 SS-Code The SS-Code AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. 7.3.88 SS-Status The SS-Status AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. For details, see 3GPPÊTSÊ23.011Ê[29]. 7.3.89 Notification-To-UE-User The Notification- To-UE-User AVP is of type Enumerated. The following values are defined: NOTIFY_LOCATION_ALLOWED (0) NOTIFYANDVERIFY_LOCATION_ALLOWED_IF_NO_RESPONSE (1) NOTIFYANDVERIFY_LOCATION_NOT_ALLOWED_IF_NO_RESPONSE (2) LOCATION_NOT_ALLOWED (3) 7.3.90 External-Client The External-Client AVP is of type Grouped. This AVP shall contain the identities of the external clients that are allowed to locate a target UE for a MT-LR. AVP format External-Client ::= <AVP header: 1479 10415> { Client-Identity } [ GMLC-Restriction ] [ Notification-To-UE-User ] *[AVP] 7.3.91 Client-Identity The Client-Identity AVP is of type OctetString and it shall contain the ISDN number of the external client in international number format as described in ITU-T Rec E.164Ê[41] and shall be encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.92 GMLC-Restriction The GMLC-Restriction AVP is of type Enumerated. The following values are defined: GMLC_LIST (0) HOME_COUNTRY (1) 7.3.93 PLMN-Client The PLMN-Client AVP is of type Enumerated. The following values are defined: BROADCAST_SERVICE (0) O_AND_M_HPLMN (1) O_AND_M_VPLMN (2) ANONYMOUS_LOCATION (3) TARGET_UE_SUBSCRIBED_SERVICE (4) 7.3.94 Service-Type The Service-Type AVP is of type Grouped. This AVP shall contain the identities of the service type of the clients that are allowed to locate a target UE for an MT-LR. AVP format Service-Type ::= <AVP header: 1483 10415> { ServiceTypeIdentity } [ GMLC-Restriction ] [ Notification-To-UE-User ] *[AVP] 7.3.95 ServiceTypeIdentity The ServiceTypeIdentity AVP is of type Unsigned32. For details on the values of this AVP, see 3GPPÊTSÊ29.002Ê[24]. 7.3.96 MO-LR The MO-LR AVP is of type Grouped. This AVP shall contain the classes of MO-LR for which a subscription exists for a particular UE. AVP format MO-LR ::= <AVP header: 1485 10415> { SS-Code } { SS-Status } *[AVP] 7.3.97 Void 7.3.98 Trace-Collection-Entity AVP The Trace-Collection-Entity AVP is of type Address and contains the IPv4 or IPv6 address of the Trace Collection Entity, as defined in 3GPPÊTSÊ32.422Ê[23], clauseÊ5.9. 7.3.99 Teleservice-List The Teleservice-List AVP is of type Grouped. This AVP shall contain the service codes for the short message related teleservice for a subscriber: AVP format Teleservice-List ::= <AVP header: 1486 10415> 1 * { TS-Code }*Ê[ AVP ] 7.3.100 TS-Code The TS-Code AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. 7.3.101 Call-Barring-Info The Call-Barring-Info AVP is of type Grouped. This AVP shall contain the service codes for the short message related call barring services for a subscriber: AVP format Call-Barring-Info ::= <AVP header: 1488 10415> { SS-Code } { SS-Status } *[ AVP ] 7.3.102 SGSN-Number The SGSN-Number AVP is of type OctetString and it shall contain the ISDN number of the SGSN. For further details on the definition of this AVP, see 3GPPÊTSÊ23.003Ê[3]. This AVP contains an SGSN-Number in international number format as described in ITU-T Rec E.164Ê[41] and shall be encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings."
"This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.103 IDR-Flags The IDR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.103/1: Table 7.3.103/1: IDR-Flags bit name Description 0 UE Reachability Request This bit when set shall indicate to the MME or the SGSN that the HSS is awaiting a Notification of UE Reachability. 1 T-ADS Data Request This bit, when set, shall indicate to the MME or SGSN that the HSS requests the support status of ""IMS Voice over PS Sessions"", and the RAT Type and timestamp of the last radio contact with the UE. 2 EPS User State Request This bit, when set, shall indicate to the MME or the SGSN that the HSS requests the MME or the SGSN for the current user state. 3 EPS Location Information Request This bit, when set, shall indicate to the MME or the SGSN that the HSS requests the MME or SGSN for location information 4 Current Location Request This bit when set shall indicate to the MME or the SGSN that the HSS requests the MME or SGSN to provide the most current location information by paging the UE if the UE is in idle mode. This bit is used only in combination with the""EPS Location Information Request"" bit. 5 Local Time Zone Request This bit when set shall indicate to the MME or the SGSN that the HSS requests the MME or SGSN to provide information on the time zone of the location in the visited network where the UE is attached. 6 Remove SMS Registration This bit when set shall indicate to the MME that it shall consider itself unregistered for SMS. 7 RAT-Type Requested This bit when set shall indicate to the MME or the SGSN that the HSS requests the MME or SGSN to provide the RAT Type that corresponds to the requested EPS Location Information. This bit is used only in combination with the""EPS Location Information Request"" bit. 8 P-CSCF Restoration Request This bit, when set, shall indicate to the MME or SGSN that the HSS requests the execution of the HSS-based P-CSCF restoration procedures, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.104 ICS-Indicator The ICS-Indicator AVP is of type Enumerated. The meaning of the values is defined in 3GPPÊTSÊ23.292Ê[34] and 3GPPÊTSÊ23.216Ê[35]. The following values are defined: FALSE (0) TRUE (1) 7.3.105 Visited-Network-Identifier The Visited-Network-Identifier AVP contains the identity of the network where the PDN-GW was allocated, in the case of dynamic PDN-GW assignment. The AVP shall be encoded as: mnc<MNC>.mcc<MCC>.3gppnetwork.org 7.3.106 IMS-Voice-Over-PS-Sessions-Supported The IMS-Voice-Over-PS-Sessions-Supported AVP is of type Enumerated. The following values are defined: NOT_SUPPORTED (0) This value indicates that ""IMS Voice over PS Sessions"" is not supported by the UE's most recently used TA or RA in the serving node. SUPPORTED (1) This value indicates that ""IMS Voice over PS Sessions"" is supported by the UE's most recently used TA or RA in the serving node. 7.3.107 Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions The Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP is of type Enumerated. The following values are defined: NOT_SUPPORTED (0) This value indicates that ""IMS Voice over PS Sessions"" is not supported, homogeneously, in any of the TAs or RAs associated to the serving node for the served subscribers including consideration on roaming relationship for IMS Voice over PS. SUPPORTED (1) This value indicates that ""IMS Voice over PS Sessions"" is supported, homogeneously, in all of the TAs or RAs associated to the serving node for the served subscriber including consideration on roaming relationship for IMS Voice over PS. If this AVP is not present in the command, it indicates that there is no homogeneous support of IMS Voice Over PS Sessions on all the TA/RAs of the serving node, or that the homogeneity of this support is unknown to the serving node. NOTE: In order to ensure the T-ADS by HPLMN, MME or SGSN is expected to either set ""Homogenous Support of IMS Voice over PS Sessions"" AVP to ""NOT_SUPPORTED (0)"", or not to set this AVP for inbound roaming subscribers if there is no IMS Voice over PS roaming relationship with the HPLMN. 7.3.108 Last-UE-Activity-Time The Last-UE-Activity-Time AVP is of type Time (see IETFÊRFCÊ6733Ê[61]), and contains the point of time of the last radio contact of the serving node (MME or SGSN) with the UE. 7.3.109 GMLC-Address The GMLC-Address AVP is of type Address and shall contain the IPv4 or IPv6 address of the V-GMLC associated with the serving node. 7.3.110 EPS-User-State The EPS-User-State AVP is of type Grouped. It shall contain the information related to the user state in the MME and/or the SGSN. AVP format EPS-User-State ::= <AVP header:1495 10415> [MME-User-State] [SGSN-User-State] *[AVP] 7.3.111 EPS-Location-Information The EPS-Location Information AVP is of type Grouped. It shall contain the information related to the user location relevant for EPS. AVP format EPS-Location-Information ::= <AVP header: 1496 10415> [MME-Location-Information] [SGSN-Location-Information] *[AVP] 7.3.112 MME-User-State The MME-User-State AVP is of type Grouped. It shall contain the information related to the user state in the MME. AVP format MME-User-State ::= <AVP header: 1497 10415> [User-State] *[AVP] 7.3.113 SGSN-User-State The SGSN-User-State AVP is of type Grouped. It shall contain the information related to the user state in the SGSN. AVP format SGSN-User-State ::= <AVP header: 1498 10415> [User-State] *[AVP] 7.3.114 User-State The User-State AVP is of type Enumerated and indicates the user state in EPS. The following values are defined: DETACHED (0) The UE is in EMM_DEREGISTERED state. ATTACHED_NOT_REACHABLE_FOR_PAGING (1) The SGSN has determined from its internal data that the UE is attached to the network, but there is no EPS bearer active, and the UE is not reachable for paging. This value is only applicable to S4-SGSN. ATTACHED_REACHABLE_FOR_PAGING (2) The SGSN has determined from its internal data that the UE is attached to the network, but there is no EPS bearer active; the SGSN has not determined from its internal data that the UE is not reachable for paging. This value is only applicable to S4-SGSN. CONNECTED_NOT_REACHABLE_FOR_PAGING (3) The SGSN or MME has determined from its internal data that the UE is attached to the network, there is at least one EPS bearer active, and the UE is not reachable for paging. CONNECTED_REACHABLE_FOR_PAGING (4) The SGSN or MME has determined from its internal data that the UE is attached to the network, there is at least one EPS bearer active, and the SGSN or MME has not determined from its internal data that the UE is not reachable for paging. RESERVED (5) This value should not be used by MME or SGSN over S6a/S6d. If this value is received by the HSS from pre-rel-12 MME/SGSNs, the HSS shall consider that the UE is not reachable and use the ""Network determined not reachable"" state when reporting the User State to other network entities, e.g. over Sh. NOTE: The state associated to a ""Network determined not reachable"" condition should also be used by HSS when reporting to the requesting entity, e.g. over Sh, that the user was found to be not reachable (for instance, if the HSS receives no answer from the MME/SGSN to the user state query). 7.3.115 MME-Location-Information The MME-Location-Information AVP is of type Grouped. It shall contain the information related to the user location relevant for the MME. AVP format MME-Location-Information ::= <AVP header: 1600 10415> [E-UTRAN-Cell-Global-Identity] [Tracking-Area-Identity] [Geographical-Information] [Geodetic-Information] [Current-Location-Retrieved] [Age-Of-Location-Information] [User-CSG-Information] [ eNodeB-ID ] [ Extended-eNodeB-ID ] *[AVP] An eNodeB-ID AVP may be present for Monitoring event reporting. 7.3.116 SGSN-Location-Information The SGSN-Location-Information AVP is of type Grouped. It shall contain the information related to the user location relevant for the SGSN. AVP format SGSN-Location-Information ::= <AVP header: 1601 10415> [Cell-Global-Identity] [Location-Area-Identity] [Service-Area-Identity] [Routing-Area-Identity] [Geographical-Information] [Geodetic-Information] [Current-Location-Retrieved] [Age-Of-Location-Information] [ User-CSG-Information] *[AVP] 7.3.117 E-UTRAN-Cell-Global-Identity The E-UTRAN-Cell-Global-Identity AVP is of type OctetString and shall contain the E-UTRAN Cell Global Identification of the user which identifies the cell the user equipment is registered, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.118 Tracking-Area-Identity The Tracking-Area-Identity AVP is of type OctetString and shall contain the Tracking Area Identity of the user which identifies the tracking area where the user is located, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.119 Cell-Global-Identity The Cell-Global-Identity AVP is of type OctetString and shall contain the Cell Global Identification of the user which identifies the cell the user equipment is registered, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.120 Routing-Area-Identity The Routing-Area-Identity AVP is of type OctetString and shall contain the Routing Area Identity of the user which identifies the routing area where the user is located, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.121 Location-Area-Identity The Location-Area-Identity AVP is of type OctetString and shall contain the Location Area Identification of the user which identifies the Location area where the user is located, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.122 Service-Area-Identity The Service-Area-Identity AVP is of type OctetString and shall contain the Service Area Identifier of the user where the user is located, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.123 Geographical-Information The Geographical-Information AVP is of type OctetString and shall contain the geographical Information of the user. For details and octet encoding, see 3GPPÊTSÊ29.002Ê[24]. 7.3.124 Geodetic-Information The Geodetic-Information AVP is of type OctetString and shall contain the Geodetic Location of the user. For details and octet encoding, see 3GPPÊTSÊ29.002Ê[24]. 7.3.125 Current-Location-Retrieved The Current-Location-Retrieved AVP is of type Enumerated. The following values are defined: ACTIVE-LOCATION-RETRIEVAL (0) This value is used when location information was obtained after a successful paging procedure for Active Location Retrieval when the UE is in idle mode or after retrieving the most up-to-date location information from the eNB when the UE is in connected mode. 7.3.126 Age-Of-Location-Information The Age-Of-Location-Information AVP is of type Unsigned32 and shall contain the the elapsed time in minutes since the last network contact of the user equipment. For details, see 3GPPÊTSÊ29.002Ê[24]. 7.3.127 Active-APN The Active-APNs AVP is of type Grouped. It shall contain information about a dynamically established APN on a serving node, so the HSS can restore it, if it is eventually lost after a node restart. The AVP format shall conform to: Active-APN ::= <AVP header: 1612 10415> { Context-Identifier } [ Service-Selection ] [ MIP6-Agent-Info ] [ Visited-Network-Identifier ] *[ Specific-APN-Info ] *[ AVP ] 7.3.128 Error-Diagnostic The Error-Diagnostic AVP is of type Enumerated. The following values are defined: - GPRS_DATA_SUBSCRIBED (0) This value shall be used when Experimental-Error is DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION and there is GPRS Subscription Data for the user. - NO_GPRS_DATA_SUBSCRIBED (1) This value shall be used when Experimental-Error is DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION and there is not GPRS Subscription Data for the user. - ODB_ALL_APN (2) This value shall be used when Experimental-Error is DIAMETER_ERROR_ROAMING_NOT_ALLOWED and the Operator Determined Barring indicates ""All Packet Oriented Services Barred"" (see clauseÊ7.3.30). - ODB_HPLMN_APN (3) This value shall be used when Experimental-Error is DIAMETER_ERROR_ROAMING_NOT_ALLOWED and the Operator Determined Barring indicates ""Roamer Access HPLMN-AP Barred"" (see clauseÊ7.3.30). - ODB_VPLMN_APN (4) This value shall be used when Experimental-Error is DIAMETER_ERROR_ROAMING_NOT_ALLOWED and the Operator Determined Barring indicates ""Roamer Access to VPLMN-AP Barred"" (see clauseÊ7.3.30). 7.3.129 Ext-PDP-Address AVP The Ext-PDP-Address AVP is of type Address and indicates an additional address of the data protocol, and it may be included when the PDP supports dual-stack (IPv4v6). 7.3.130 UE-SRVCC-Capability The UE-SRVCC-Capability AVP is of type Enumerated. It shall indicate if the UE supports or does not support the SRVCC capability. The following values are defined: UE-SRVCC-NOT-SUPPORTED (0) UE-SRVCC-SUPPORTED (1) 7.3.131 MPS-Priority The MPS-Priority AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.131/1: Table 7.3.131/1: MPS-Priority Bit Name Description 0 MPS-CS-Priority This bit, when set, indicates that the UE is subscribed to the eMLPP or 1x RTT priority service in the CS domain. 1 MPS-EPS-Priority This bit, when set, indicates that the UE is subscribed to the MPS in the EPS domain. Note: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. NOTE: The HSS derives the information for MPS-CS-Priority from the eMLPP Subscription Data as defined in the 3GPPÊTSÊ29.002Ê[24] or 1x RTT priority service which is out of the scope of 3GPP. 7.3.132 VPLMN-LIPA-Allowed The VPLMN-LIPA-Allowed AVP is of type Enumerated. It shall indicate whether the UE is allowed to use LIPA in the VPLMN where the UE is roaming. The following values are defined: LIPA_NOTALLOWED (0) This value indicates that the UE is not allowed to use LIPA in the VPLMN where the UE is roaming. LIPA_ALLOWED (1) This value indicates that the UE is allowed to use LIPA in the VPLMN where the UE is roaming. 7.3.133 LIPA-Permission The LIPA-Permission AVP is of type Enumerated. It shall indicate whether the APN can be accessed via Local IP Access. The following values are defined: LIPA_PROHIBITED (0) This value indicates that this APN is prohibited to be accessed via LIPA. LIPA_ONLY (1) This value indicates that this APN can be accessed only via LIPA. LIPA_CONDITIONAL (2) This value indicates that this APN can be accessed via both non LIPA and LIPA. 7.3.134 Subscribed-Periodic-RAU-TAU-Timer The Subscribed-Periodic-RAU-TAU-Timer AVP is of type Unsigned32 and it shall contain the subscribed periodic RAU/TAU timer value in seconds as specified in 3GPPÊTSÊ24.008Ê[31]. 7.3.135 SIPTO-Permission The SIPTO-Permission AVP is of type Enumerated. It shall indicate whether the traffic associated with this particular APN is allowed or not for SIPTO above RAN. The following values are defined: SIPTO_above_RAN _ALLOWED (0) SIPTO_above_RAN _NOTALLOWED (1) 7.3.136 MDT-Configuration The MDT-Configuration AVP is of type Grouped. It shall contain MDT related information as specified in 3GPPÊTSÊ32.422Ê[23]. The AVP format shall conform to: MDT-Configuration ::= <AVP header: 1622 10415> { Job-Type } [ Area-Scope ] [ List-Of-Measurements ] [ Reporting-Trigger ] [ Report-Interval ] [ Report-Amount ] [ Event-Threshold-RSRP ] [ Event-Threshold-RSRQ ] [ Logging-Interval ] [ Logging-Duration ] [ Measurement-Period-LTE ] [ Measurement-Period-UMTS ] [ Collection-Period- RRM-LTE ] [ Collection-Period-RRM-UMTS ] [ Positioning-Method ] [ Measurement-Quantity] [ Event-Threshold-Event-1F ] [ Event-Threshold-Event-1I ] *[ MDT-Allowed-PLMN-Id ] *[ MBSFN-Area ] *[ AVP ] 7.3.137 Job-Type The Job-Type AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Job-Type. 7.3.138 Area-Scope The Area-Scope AVP is of type Grouped. See 3GPPÊTSÊ32.422Ê[23]. The AVP format shall conform to: Area-Scope ::= <AVP header: 1623 10415> *[ Cell-Global-Identity ] *[ E-UTRAN-Cell-Global-Identity ] *[ Routing-Area-Identity ] *[ Location-Area-Identity ] *[ Tracking-Area-Identity ] *[ AVP ] 7.3.139 List-Of-Measurements The List-Of-Measurements AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits is defined in 3GPPÊTSÊ32.422Ê[23]. The most significant bit is bit 8 of the first octet. 7.3.140 Reporting-Trigger The Reporting-Trigger AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits is defined in 3GPPÊTSÊ32.422Ê[23]. The most significant bit is bit 8 of the first octet. 7.3.141 Report-Interval The Report-Interval AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Report Interval 7.3.142 Report-Amount The Report-Amount AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Report Amount. 7.3.143 Event-Threshold-RSRP The Event-Threshold-RSRP AVP is of type Unsigned32. See 3GPPÊTSÊ32.422Ê[23] for allowed values 7.3.144 Event-Threshold-RSRQ The Event-Threshold-RSRQ AVP is of type Unsigned32. See 3GPPÊTSÊ32.422Ê[23] for allowed values 7.3.145 Logging-Interval The Logging-Interval AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Logging Interval 7.3.146 Logging-Duration The Logging-Duration AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Logging Duration 7.3.147 Relay-Node-Indicator The Relay-Node-Indicator AVP is of type Enumerated. It shall indicate whether the subscription data belongs to a Relay Node or not (see 3GPPÊTSÊ36.300Ê[40]). The following values are defined: NOT_RELAY_NODE (0) This value indicates that the subscription data does not belong to a Relay Node. RELAY_NODE (1) This value indicates that the subscription data belongs to a Relay Node. The default value when this AVP is not present is NOT_RELAY_NODE (0). 7.3.148 MDT-User-Consent The MDT-User-Consent AVP is of type Enumerated. It shall indicate whether the user has given his consent for MDT activation or not (see 3GPPÊTSÊ32.422Ê[23]). The following values are defined: CONSENT_NOT_GIVEN (0) CONSENT_GIVEN (1) The default value when this AVP is not present in ULA is CONSENT_NOT_GIVEN (0). Absence of this AVP in IDR shall be interpreted as the MDT-User-Consent has not been modified. The presence of this subscription parameter in ULA or IDR shall be independent of the support of the Trace Function by the MME/SGSN (see clauseÊ7.3.10). 7.3.149 PUR-Flags The PUR-Flags AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.149/1: Table 7.3.149/1: PUR-Flags bit name Description 0 UE Purged in MME This bit, when set, indicates that the combined MME/SGSN has purged the UE in the MME part of the node. This bit shall not be set by a standalone SGSN. 1 UE Purged in SGSN This bit, when set, shall indicate that the combined MME/SGSN has purged the UE in the SGSN part of the node. This bit shall not be set by a standalone MME. NOTE: Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving HSS. 7.3.150 Subscribed-VSRVCC The Subscribed-VSRVCC AVP is of type Enumerated. It shall indicate that the user is subscribed to the vSRVCC. The following value is defined: VSRVCC_SUBSCRIBED (0) Absence of this AVP in IDR shall be interpreted as the Subscribed-VSRVCC has not been modified. Absence of this AVP in ULA shall be interpreted as the user is not subscribed to the vSRVCC. 7.3.151 Equivalent-PLMN-List The Equivalent-PLMN-List AVP is of type Grouped. This AVP shall contain the equivalent PLMN IDs of the registered PLMN (i.e. the visited PLMN) of the MME or the SGSN. AVP format Equivalent-PLMN-List ::= <AVP header: 1637 10415> 1*{ Visited-PLMN-Id } *[AVP] 7.3.152 CLR-Flags The CLR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.152/1: Table 7.3.152/1: CLR-Flags Bit Name Description 0 S6a/S6d-Indicator (Note 1) This bit, when set, indicates that the CLR message is sent on the S6a interface, i.e. the message is to the MME or the MME part on the combined MME/SGSN. This bit, when cleared, indicates that the CLR message is sent on the S6d interface, i.e. the message is to the SGSN or the SGSN part on the combined MME/SGSN. 1 Reattach-Required This bit, when set, indicates that the MME or SGSN shall request the UE to initiate an immediate re-attach procedure as described in 3GPPÊTSÊ23.401Ê[2] and in 3GPPÊTSÊ23.060Ê[12]. NOTE 1: The S6a/S6d-Indicator flag shall be used during initial attach procedure for a combined MME/SGSN. The S6a/S6d-Indicator flag may also be sent to a standalone node. NOTE 2: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. NOTE 3: For the purpose of withdrawing ""Aerial UE Subscription"", HSS may send CLR with CLR-Flag set to Reattach-Required. 7.3.153 UVR-Flags The UVR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.154/1: Table 7.3.154/1: UVR-Flags Bit Name Description 0 Skip Subscriber Data This bit, when set, indicates that the CSS may skip subscription data in UVA. If the CSG subscription data has changed in the CSS after the last successful update of the MME/SGSN, the CSS shall ignore this bit and send the updated CSG subscription data. Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving CSS. 7.3.154 UVA-Flags The UVA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.156/1: Table 7.3.156/1: UVA-Flags Bit Name Description 0 Temporary Empty VPLMN CSG Subscription Data This bit, when set, indicates that the CSS has currently no VPLMN CSG subscription data for this user but has registered the MME or SGSN, so to inform them if later changes in VPLMN CSG subscription data occur. Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving CSS. 7.3.155 VPLMN-CSG-Subscription-Data The VPLMN-CSG-Subscription-Data AVP is of type Grouped. This AVP shall contain the CSG-Id, and optionally an associated expiration date. AVP format VPLMN-CSG-Subscription-Data ::= <AVP header: 1641 10415> { CSG-Id } [ Expiration-Date ] *[AVP] 7.3.156 Local-Time-Zone The Local-Time-Zone AVP is of type Grouped and shall contain the Time Zone and the Daylight Saving Time (DST) adjustment of the location in the visited network where the UE is attached. The AVP format shall conform to: Local-Time-Zone ::= <AVP header: 1649 10415> { Time-Zone } { Daylight-Saving-Time } *Ê[ AVP ] 7.3.157 A-MSISDN The A-MSISDN AVP is of type OctetString. See 3GPPÊTSÊ23.003Ê[3] for the definition of the Additional MSISDN. This AVP contains an A-MSISDN, in international number format as described in ITU-T Rec E.164Ê[41], encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. This AVP may be present in the Subscription-Data AVP when sent within ULA. It may also be present in the Subscription-Data AVP, sent within an IDR, if the current value in the MME or SGSN needs to be changed. 7.3.158 Void 7.3.159 MME-Number-for-MT-SMS The MME-Number-for-MT-SMS AVP is of type OctetString and it shall contain the ISDN number corresponding to the MME for MT SMS. For further details on the definition of this AVP, see 3GPPÊTSÊ23.003Ê[3]. This AVP contains an international number with the format as described in ITU-T Rec E.164Ê[41] and shall be encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.160 Void 7.3.161 Void 7.3.162 SMS-Register-Request The SMS-Register-Request AVP is of type Enumerated and it shall indicate whether the MME or the SGSN requires to be registered for SMS (e.g. SGs interface not supported) or if the MME or the SGSN prefers not to be registered for SMS or if the MME or the SGSN has no preference. The following values are defined: SMS_REGISTRATION_REQUIRED (0) SMS_REGISTRATION_NOT_PREFERRED (1) NO_PREFERENCE (2) The criteria for setting these values are defined in 3GPPÊTSÊ23.272Ê[44] and 3GPPÊTSÊ23.060Ê[12]. When the MME/SGSN includes the SMS-Register-Request AVP in ULR in order to modify its registration status for SMS, the MME/SGSN shall not set the ""Skip Subscriber Data"" flag within the ULR-Flags AVP. 7.3.163 Time-Zone The Time-Zone AVP is of type UTF8String and shall contain the time zone of the location in the visited network where the UE is attached. It contains the offset from UTC (Coordinated Universal Time) in units of 15 minutes, as defined in 3GPPÊTSÊ22.042Ê[42]. It shall be expressed as positive (i.e. with the leading plus signÊ[+]) if the local time is ahead of or equal to UTC of day and as negative (i.e. with the leading minus signÊ[-]) if it is behind UTC of day. The value contained in the Time-Zone AVP shall take into account daylight saving time, such that when the sending entity changes from regular (winter) time to daylight saving (summer) time, there is a change to the value in the Time-Zone AVP. The contents of the Time-Zone AVP shall be formatted as a character string with the following format: Basic format: ±n, with ""n"" being the number of units of 15 minutes from UTC. For example, if the offset is +2h=+8x15mn, the value of the Time-Zone AVP will be: ""+8"". 7.3.164 Daylight-Saving-Time The Daylight-Saving-Time AVP is of type Enumerated and shall contain the Daylight Saving Time (in steps of 1 hour) used to adjust for summertime the time zone of the location where the UE is attached in the visited network. The following values are defined: NO_ADJUSTMENT (0) PLUS_ONE_HOUR_ADJUSTMENT (1) PLUS_TWO_HOURS_ADJUSTMENT (2) 7.3.165 Subscription-Data-Flags The Subscription-Data-Flags is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.165/1: Table 7.3.165/1: Subscription-Data-Flags Bit Name Description 0 PS-And-SMS-Only-Service-Provision-Indication This bit, when set, indicates that the subscription is for PS Only and permits CS service access only for SMS. 1 SMS-In-SGSN-Allowed-Indication This bit, when set, indicates that SMS in SGSN for the user is allowed. 2 User Plane Integrity Protection This bit, when set, indicates that the SGSN may decide to activate integrity protection of the user plane when GERAN is used (see 3GPPÊTSÊ43.020Ê[58]). The MME shall ignore it. 3 PDN-Connection-Restricted This bit, when set, indicates to the MME that it shall not establish any non-emergency PDN connection for this user if the MME and the UE supports Attach without PDN connection. The SGSN shall ignore it. 4 Acknowledgement-Of-Downlink-NAS-Data PDUs disabled This bit, when set, indicates to the MME that acknowledgement of downlink NAS data PDUs for Control Plane CIoT Optimization is disabled for this UE (even for APN configurations with RDS Indicator set to ENABLED (1)). When not set it indicated to the MME that acknowledgement of downlink NAS data PDUs for Control Plane CIoT Optimization is enabled (for APN configurations with RDS Indicator set to ENABLED (1)) for this UE, which is the default (see 3GPPÊTSÊ23.401Ê[2]). The SGSN shall ignore it. NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. 7.3.166 Measurement-Period-LTE The Measurement-Period-LTE AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Measurement period LTE. 7.3.167 Measurement-Period-UMTS The Measurement-Period-UMTS AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Measurement period UMTS. 7.3.168 Collection-Period-RRM-LTE The Collection-Period-RRM-LTE AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Collection period for RRM measurements LTE. 7.3.169 Collection-Period-RRM-UMTS The Collection-Period-RRM-UMTS AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Collection period for RRM measurements UMTS. 7.3.170 Positioning-Method The Positioning-Method AVP is of type OctetString. It contains one octet carrying a bit map of 8 bits. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Positioning Method. 7.3.171 Measurement-Quantity The Measurement-Quantity AVP is of type OctetString. It contains one octet carrying a bit map of 8 bits. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Measurement quantity. 7.3.172 Event-Threshold-Event-1F The Event-Threshold-Event-1F AVP is of type Integer32. See 3GPPÊTSÊ32.422Ê[23] for allowed values. 7.3.173 Event-Threshold-Event-1I The Event-Threshold-Event-1I AVP is of type Integer32. See 3GPPÊTSÊ32.422Ê[23] for allowed values 7.3.174 Restoration-Priority The Restoration-Priority AVP is of type Unsigned32. It shall indicate the relative priority of a user's PDN connection among PDN connections to the same APN when restoring PDN connections affected by an SGW or PGW failure/restart (see 3GPPÊTSÊ23.007Ê[43]). Values 1 to 16 are defined, with value 1 as the highest level of priority. 7.3.175 SGs-MME-Identity The SGs-MME-Identity AVP is of type UTF8String. This AVP shall contain the MME identity used over the SGs interface and specified in 3GPPÊTSÊ23.003Ê[3] clauseÊ19.4.2.4. 7.3.176 SIPTO-Local-Network-Permission The SIPTO-Local-Network-Permission AVP is of type Unsigned32. It shall indicate whether the traffic associated with this particular APN is allowed or not for SIPTO at the local network. The following values are defined: ""SIPTO at Local Network ALLOWED"" 0 ""SIPTO at Local Network NOTALLOWED"" 1 7.3.177 Coupled-Node-Diameter-ID The Coupled-Node-Diameter-ID AVP is of type DiameterIdentity. This AVP shall contain the S6a or S6d Diameter identity of the coupled node as specified in 3GPPÊTSÊ23.003Ê[3] clauseÊ19.4.2.4 and clauseÊ19.4.2.6. 7.3.178 OC-Supported-Features The OC-Supported-Features AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[50]. This AVP is used to support Diameter overload control mechanism, see Annex C for more information. 7.3.179 OC-OLR The OC-OLR AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[50]. This AVP is used to support Diameter overload control mechanism, see Annex C for more information. 7.3.180 ProSe-Subscription-Data The ProSe-Subscription-Data AVP is of type Grouped. It shall contain the ProSe related subscription data. It was originally defined in 3GPPÊTSÊ29.344Ê[49]. AVP format ProSe-Subscription-Data ::= <AVP header: 3701 10415> { ProSe-Permission } *[AVP] 7.3.181 WLAN-offloadability The WLAN-offloadability AVP is of type Grouped. This AVP contains WLAN offloadability for E-UTRAN or UTRAN. AVP format: WLAN-offloadability ::= <AVP header: 1667> [ WLAN-offloadability-EUTRAN ] [ WLAN-offloadability-UTRAN ] *[ AVP ] 7.3.182 WLAN-offloadability-EUTRAN The WLAN-offloadability-EUTRAN AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.182/1: Table 7.3.182/1: WLAN-offloadability-EUTRAN bit name Description 0 WLAN offloadability for E-UTRAN This bit, when set, shall indicate that the traffic associated with the APN is allowed to be offloaded to WLAN from E-UTRAN using the WLAN/3GPP Radio Interworking feature. If not set, it means the traffic associated with the APN is not allowed to be offloaded to WLAN from E-UTRAN. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.183 WLAN-offloadability-UTRAN The WLAN-offloadability-UTRAN AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.183/1: Table 7.3.183/1: WLAN-offloadability-UTRAN bit name Description 0 WLAN offloadability for UTRAN This bit, when set, shall indicate that the traffic associated with the APN is allowed to be offloaded to WLAN from UTRAN using the WLAN/3GPP Radio Interworking feature. If not set, it means the traffic associated with the APN is not allowed to be offloaded to WLAN from UTRAN. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN.. 7.3.184 Reset-ID The Reset-ID is of type OctetString. The value shall uniquely (within the HSS's realm) identify a resource in the HSS that may fail or has restarted. In the Reset procedure, when used to add/modify/delete subscription data shared by multiple subscribers, the Reset-ID is used to identify the set of affected subscribers. 7.3.185 MDT-Allowed-PLMN-Id The MDT-Allowed-PLMN-Id AVP is of type OctetString. This AVP shall contain the concatenation of MCC and MNC. See 3GPPÊTSÊ23.003Ê[3]. The content of this AVP shall be encoded as an octet string according to table 7.3.185/1. This AVP identifies the PLMN in which the MDT data collection shall take place. See 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.1.13, PLMN list, for the coding of MCC and MNC. If MNC is 2 digits long, bits 5 to 8 of octet 2 are coded as ""1111"". Table 7.3.185/1: Encoding format for MDT-Allowed-PLMN-Id AVP 8 7 6 5 4 3 2 1 MCC digit 2 MCC digit 1 octet 1 MNC digit 3 MCC digit 3 octet 2 MNC digit 2 MNC digit 1 octet 3 7.3.186 Adjacent-PLMNs The Adjacent-PLMNs AVP is of type Grouped. This AVP shall contain a list of PLMN IDs where an UE served by the MME/SGSN is likely to make a handover from the PLMN where the MME/SGSN is located. AVP format: Adjacent-PLMNs ::= <AVP header: 1672 10415> 1*{ Visited-PLMN-Id } *[AVP] 7.3.187 Adjacent-Access-Restriction-Data The Adjacent-Access-Restriction-Data AVP is of type Grouped. This AVP shall contain a pair of PLMN ID and the associated Access Restriction Data for that PLMN. AVP format: Adjacent-Access-Restriction-Data ::= <AVP header: 1673 10415> { Visited-PLMN-Id } { Access-Restriction-Data } *[AVP] 7.3.188 DL-Buffering-Suggested-Packet-Count The DL-Buffering-Suggested-Packet-Count AVP is of type Integer32. It shall indicate whether extended buffering of downlink packets at the SGW, for High Latency Communication, is requested or not. When requested, it may also suggest the number of downlink packets to buffer at the SGW for this user. The following values are defined: ""Extended DL Data Buffering NOT REQUESTED"" 0 ""Extended DL Data Buffering REQUESTED, without a suggested number of packets"" -1 ""Extended DL Data Buffering REQUESTED, with a suggested number of packets"" > 0 ""Extended DL Data Buffering REQUESTED"", with or without a suggested number of packets to be buffered for this user, indicates that extended buffering of downlink packets at the SGW is applicable to this user. ""Extended DL Data Buffering NOT REQUESTED"" indicates that extended buffering of downlink packets at the SGW is not applicable to this user. 7.3.189 IMSI-Group-Id The IMSI-Group-Id AVP shall be of type Grouped. This AVP shall contain the information about the IMSI-Group-Id. AVP format IMSI-Group-Id ::= <AVP header: 1675 10415> { Group-Service-Id } { Group-PLMN-Id } { Local-Group-Id } *[AVP] For details see 3GPPÊTSÊ23.003Ê[3], clauseÊ19.9). 7.3.190 Group-Service-Id The Group-Service-Id AVP is of type Unsigned32 and it shall identify the specific service for which the IMSI-Group-Id is used. The following values are defined: Table 7.3.190-1: Group-Service-Id Value Description 1 Group specific NAS level congestion control 2 Group specific Monitoring of Number of UEs present in a geographical area Values greater than 1000 are reserved for home operator specific use. IMSI-Group-IDs with a Group-Service-Id in this range shall not be sent outside the HPLMN unless roaming agreements allow so. 7.3.191 Group-PLMN-Id The Group-PLMN-Id AVP is of type OctetString. This AVP shall contain the concatenation of MCC and MNC. See 3GPPÊTSÊ23.003Ê[3]. The content of this AVP shall be encoded as an octet string according to table 7.3.191-1. See 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.1.13, PLMN list, for the coding of MCC and MNC. If MNC is 2 digits long, bits 5 to 8 of octet 2 are coded as ""1111"". Table 7.3.191-1: Encoding format for Group-PLMN-Id AVP 8 7 6 5 4 3 2 1 MCC digit 2 MCC digit 1 octet 1 MNC digit 3 MCC digit 3 octet 2 MNC digit 2 MNC digit 1 octet 3 7.3.192 Local-Group-Id The Local-Group-Id AVP is of type OctetString. It shall contain an operator defined value, representing a group. 7.3.193 AESE-Communication-Pattern AESE-Communication-Pattern AVP is of type Grouped and is defined in 3GPPÊTSÊ29.336Ê[54]. AVP format AESE-Communication-Pattern ::= <AVP header: 3113 10415> [ SCEF-Reference-ID ] [ SCEF-Reference-ID-Ext ] { SCEF-ID } *[ SCEF-Reference-ID-for-Deletion ] *[ SCEF-Reference-ID-for-Deletion-Ext ] *[ Communication-Pattern-Set ] [ MTC-Provider-Info ] *[AVP] At least one reference ID (either in SCEF-Reference-ID or in SCEF-Reference-ID-Ext) or a reference ID for deletion (either in SCEF-Reference-ID-for-Deletion or in SCEF-Reference-ID-for-Deletion-Ext) shall be present. When the ""Extended Reference IDs"" feature is supported by the HSS and MME/SGSN, the SCEF-Reference-ID-Ext and SCEF-Reference-ID-for-Deletion-Ext AVPs shall be used insted of SCEF-Reference-ID and SCEF-Reference-ID-for-Deletion respectively. 7.3.194 Communication-Pattern-Set Communication-Pattern-Set AVP is of type Grouped and is defined in 3GPPÊTSÊ29.336Ê[54]. AVP format Communication-Pattern-Set ::= <AVP header: 3114 10415> [ Periodic-Communication-Indicator ] [ Communication-Duration-Time ] [ Periodic-Time ] *[ Scheduled-Communication-Time ] [ Stationary-Indication ] [ Reference-ID-Validity-Time ] [ Traffic-Profile ] [ Battery-Indicator ] *[AVP] If the Reference-ID-Validity-Time AVP is absent, it indicates that there is no expiration time defined for the Communication-Pattern-Set. 7.3.195 Monitoring-Event-Configuration The Monitoring-Event-Configuration AVP is of type Grouped. It shall contain the Monitoring event configuration related subscription data. It is originally defined in 3GPPÊTSÊ29.336Ê[54]. For S6a/S6d interface, the Monitoring-Event-Configuration AVP format is specified as following: AVP format: Monitoring-Event-Configuration ::= <AVP header: 3122 10415> [ SCEF-Reference-ID ] [ SCEF-Reference-ID-Ext ] { SCEF-ID } { Monitoring-Type } *[ SCEF-Reference-ID-for-Deletion ] *[ SCEF-Reference-ID-for-Deletion-Ext ] [ Maximum-Number-of-Reports ] [ Monitoring-Duration ] [ Charged-Party ] [ UE-Reachability-Configuration ] [ Location-Information-Configuration ] [ SCEF-Realm ] [ External-Identifier ] [ MTC-Provider-Info ] [ PDN-Connectivity-Status-Configuration ] *[ AVP ] When the Monitoring-Event-Configuration AVP is used over the S6a/S6d interfaces, the SCEF-Realm AVP shall be present and its value shall be obtained by the HSS from the Origin-Realm AVP of the Configuration-Information-Request command conveying the corresponding monitoring event configuration over the S6t interface from the SCEF to the HSS. The Monitoring-Type AVP shall only be taken into account in combination with SCEF-Reference-ID/SCEF-Reference-ID-Ext AVP; Monitoring-Type AVP shall be ignored for deletion of an event (i.e. when SCEF-Reference-ID-for-Deletion/SCEF-Reference-ID-for-Deletion-Ext AVP is present). Maximum-Number-of-Reports shall not be present over S6a/S6d interfaces if Monitoring-Type is AVAILABILITY_AFTER_DDN_FAILURE (6). Maximum-Number-of-Reports shall not be greater than one over S6a/S6d interfaces if Monitoring-Type is LOCATION_REPORTING (2) and MONTE-Location-Type is LAST_KNOWN_LOCATION (1). When multiple External Identifiers are defined for the same subscription, the External-Identifier in this grouped AVP, if present, shall contain the specific External Identifier to be associated with this monitoring event; if it is not present, the External Identifier associated with this monitoring event shall be the default External Identifier defined in the subscription (see clauseÊ7.3.2). When the ""Extended Reference IDs"" feature is supported by the HSS and MME/SGSN, the SCEF-Reference-ID-Ext and SCEF-Reference-ID-for-Deletion-Ext AVPs shall be used insted of SCEF-Reference-ID and SCEF-Reference-ID-for-Deletion respectively. 7.3.196 Monitoring-Event-Report The Monitoring-Event-Report AVP is of type Grouped. It shall contain the Monitoring event report data. It is originally defined in 3GPPÊTSÊ29.336Ê[54]."
"For S6a/S6d interface, the Monitoring-Event-Report AVP format is specified as following: AVP format: Monitoring Event Report::= <AVP header: 3123 10415> { SCEF-Reference-ID } [ SCEF-Reference-ID-Ext ] [ SCEF-ID ] [ Reachability-Information ] [ Reachability-Cause ] [ EPS-Location-Information ] [ Monitoring-Type ] [ Loss-Of-Connectivity-Reason ] [ Idle-Status-Indication ] [ Maximum-UE-Availability-Time ] *[ PDN-Connectivity-Status-Report ] *[ AVP ] For S6a/S6d interface, when the Monitoring-Type AVP takes the value UE_REACHABILITY (1), the Reachability-Information AVP shall take the value REACHABLE_FOR_DATA (1), and the Reachability-Cause AVP may be present. For S6a/S6d interface, when the Monitoring-Type AVP takes the value PDN_CONNECTIVITY_STATUS (10), the PDN-Connectivity-Status-Report AVP(s) shall contain the list of active PDNs, for the given APN provided in the monitoring event configuration, or for all APNs if no APN was provided; each PDN-Connectivity-Status-Report shall have the PDN-Connectivity-Status-Type set to value ""CREATED (0)"". When the ""Extended Reference IDs"" feature is supported by the HSS and MME/SGSN, the SCEF-Reference-ID-Ext AVP shall be used insted of SCEF-Reference-ID; in such case, the required AVP ""SCEF-Reference-ID"" shall be included in the grouped AVP by the sender, but its content shall be discarded by the receiver. 7.3.197 UE-Reachability-Configuration The UE-Reachability-Configuration AVP is of type Grouped, and it shall contain the details for configuration for UE reachability. It is originally defined in 3GPPÊTSÊ29.336Ê[54]. For S6a/S6d interface, the UE-Reachability-Configuration AVP format is specified as following: AVP format: UE-Reachability-Configuration::= <AVP header: 3129 10415> [ Reachability-Type ] [ Maximum-Response-Time ] *[ AVP ] NOTE: When a Maximum-Response-Time value is not received from the SCEF, the HSS can send an O&M configured desired active time value within the Maximum-Response-Time AVP. For S6a/S6d interface, the Reachability-Type AVP shall have bit 0 (""Reachability for SMS"") cleared, and it shall have bit 1 (""Reachability for Data"") set. 7.3.198 eNodeB-ID The eNodeB-ID AVP is of type OctetString, and indicates the eNodeB in which the UE is currently located. It is originally defined in 3GPPÊTSÊ29.217Ê[56]. 7.3.199 Supported-Services The Supported-Services AVP is of type Grouped and it shall contain the different bit masks representing the services supported by the MME/SGSN: AVP format Supported-Services::= <AVP header: 3143 10415> [ Supported-Monitoring-Events ] *[AVP] 7.3.200 Supported-Monitoring-Events The Supported-Monitoring-Events AVP is of type Unsigned64 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.200-1: Table 7.3.200 -1: Supported-Monitoring-Events Bit Name Description 0 UE and UICC and/or new IMSI-IMEI-SV association only used on S6t interface 1 UE-reachability This bit shall be set if UE reachability Monitoring event is supported in the MME/SGSN 2 Location-of-the-UE This bit shall be set if Location of the UE and change in location of the UE Monitoring event is supported in the MME/SGSN 3 Loss-of-connectivity This bit shall be set if Loss of connectivity Monitoring event is supported in the MME/SGSN 4 Communication-failure This bit shall be set if Communication failure Monitoring event is supported in the MME/SGSN 5 Roaming-status only used on S6t interface 6 Availability after DDN failure This bit shall be set if Availability after DDN failure Monitoring event is supported in the MME/SGSN 7 Idle Status Indication This bit shall be set if Idle Status Indication reporting is supported in the MME/SGSN 8 PDN Connectivity Status This bit shall be set if PDN Connectivity Status monitoring event is supported in the MME/SGSN NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. 7.3.201 AIR-Flags The AIR-Flags AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.201/1: Table 7.3.201/1: AIR-Flags bit name Description 0 Send UE Usage Type This bit, when set, indicates that the MME or SGSN requests the HSS to send the subscription parameter ""UE Usage Type"". NOTE: Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving HSS. 7.3.202 UE-Usage-Type The UE-Usage-Type AVP is of type Unsigned32. This value shall indicate the usage characteristics of the UE that enables the selection of a specific Dedicated Core Network (DCN). See clauseÊ4.3.25 of 3GPPÊTSÊ23.401Ê[2]. The allowed values of UE-Usage-Type shall be in the range of 0 to 255. Values in the range of 0 to 127 are standardized and defined as follows: 0: Spare, for future use É 127: Spare, for future use Values in the range of 128 to 255 are operator-specific. 7.3.203 DRMP The DRMP AVP is of type Enumerated and it is defined in IETFÊRFCÊ7944Ê[57]. This AVP allows the HSS, the CSS, the EIR and the MME/SGSN to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message. 7.3.204 Non-IP-PDN-Type-Indicator The Non-IP-PDN-Type-Indicator AVP is of type Enumerated and indicates whether the APN has a Non-IP PDN type. The following values are defined: FALSE (0) This value indicates that the APN does not have a Non-IP PDN type. TRUE (1) This value indicates that the APN has a Non-IP PDN type and, in this case, the value indicated by the PDN-Type AVP inside APN-Configuration AVP shall be ignored. The default value when this AVP is not present is FALSE (0). 7.3.205 Non-IP-Data-Delivery-Mechanism The Non-IP-Data-Delivery-Mechanism AVP is of type Unsigned32 and indicates the mechanism to be used for Non-IP data delivery for a given APN. The following values are defined: SGi-BASED-DATA-DELIVERY (0) This value indicates that the Non-IP data is delivered via Point-To-Point tunnelling over the SGi interface. SCEF-BASED-DATA-DELIVERY (1) This value indicates that the Non-IP data is delivered via the SCEF. The default value when this AVP is not present is SGi-BASED-DATA-DELIVERY (0). 7.3.206 Additional-Context-Identifier The Additional-Context-Identifier AVP is of type Unsigned32 and indicates the identity of another default APN to be used when the subscription profile of the user contains APNs with more than one PDN type among IP-based PDN types, non-IP PDN types and Ethernet PDN types. 7.3.207 SCEF-Realm The SCEF-Realm AVP is of type DiameterIdentity and it shall contain the Diameter realm of the SCEF. For further details on the encoding of this AVP, see IETFÊRFCÊ6733Ê[61]. 7.3.208 Subscription-Data-Deletion The Subscription-Data-Deletion AVP is of type Grouped and indicates the shared subscription data that need to be deleted from the subscription profiles of the impacted subscribers. AVP format Subscription-Data-Deletion ::= <AVP header: 1685 10415> { DSR-Flags } [ SCEF-ID ] *[ Context-Identifier ] [ Trace-Reference ] *[ TS-Code ] *[ SS-Code ] *[ AVP ] 7.3.209 Preferred-Data-Mode The Preferred-Data-Mode AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.209/1: Table 7.3.209/1: Preferred-Data-Mode bit name Description 0 Data over User Plane Preferred This bit, when set, shall indicate that the User Plane is preferred for transmitting the traffic associated with the APN. If not set, it means that the User Plane is not preferred for transmitting the traffic associated with the APN. 1 Data over Control Plane Preferred This bit, when set, shall indicate that the Control Plane is preferred for transmitting the traffic associated with the APN. If not set, it means that the Control Plane is not preferred for transmitting the traffic associated with the APN. NOTE 1: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME. NOTE 2: At least one of the bits 0 and 1 shall be set to 1. Both bits 0 and 1 may be set to 1 to indicate that both User Plane and Control Plane are preferred for transmitting the traffic associated with the APN. NOTE 3: This parameter only applies to E-UTRAN and SGi PDN connections. Data over User Plane refers to PDN data transported over S1-U and Data Radio Bearer. Data over Control Plane refers to PDN data transported over NAS and Signalling Radio Bearer. 7.3.210 Emergency-Info The Emergency-Info AVP is of type Grouped. It shall contain the identity of the PDN-GW used for the establishment of emergency PDN connections. The AVP format shall conform to: Emergency-Info ::= <AVP header: 1687 10415> [ MIP6-Agent-Info ] *[ AVP ] 7.3.211 Load The Load AVP is of type Grouped and it is defined in IETFÊRFCÊ8583Ê[60]. This AVP is used to support Diameter load control mechanism, see Annex F for more information. 7.3.212 V2X-Subscription-Data The V2X-Subscription-Data AVP is of type Grouped. It shall contain the V2X related subscription data for the network scheduled LTE sidelink communication.. AVP format: V2X-Subscription-Data ::= <AVP header: 1688 10415> [ V2X-Permission ] [ UE-PC5-AMBR ] *[AVP] The UE-PC5-AMBR AVP within the V2X-Subscription-Data AVP indicates the UE AMBR used for LTE PC5 interface. 7.3.213 V2X-Permission The V2X-Permission AVP is of type Unsigned32 and it shall contain a bit mask that indicates the permissions for V2X service subscribed by the user. The meaning of the bits shall be as defined in table 7.3.x2-1: Table 7.3.x2-1: V2X-Permission Bit Name Description 0 Allow V2X communication over PC5 as Vehicle UE This bit, when set, indicates that the user is allowed to use V2X communication over PC5 as Vehicle UE in the serving PLMN. 1 Allow V2X communication over PC5 as Pedestrian UE This bit, when set, indicates that the user is allowed to use V2X communication over PC5 as Pedestrian UE in the serving PLMN. NOTE: Bits not defined in this table shall be cleared by the HSS and discarded by the MME. 7.3.214 PDN-Connection-Continuity The PDN-Connection-Continuity AVP is of type Unsigned32 and indicates how to handle the PDN connection when the UE moves between ""broadband"" (WB-E-UTRAN, UTRAN) and ""narrowband"" (NB-IoT, GPRS, EC-GSM-IoT). The following values are defined: MAINTAIN-PDN-CONNECTION (0) DISCONNECT-PDN-CONNECTION-WITH-REACTIVATION-REQUEST (1) DISCONNECT-PDN-CONNECTION-WITHOUT-REACTIVATION-REQUEST (2) This AVP corresponds to the ""PDN continuity at inter RAT mobility"" field as defined in 3GPPÊTSÊ23.401Ê[2] table 5.7.1-1. 7.3.215 eDRX-Cycle-Length The eDRX-Cycle-Length AVP is of type Grouped. This AVP shall contain an eDRX cycle length, along with the RAT type for which this cycle length is applicable to (e.g. E-UTRAN and NB-IOT). AVP format: eDRX-Cycle-Length ::= <AVP header: 1691 10415> { RAT-Type } { eDRX-Cycle-Length-Value } *[ AVP ] 7.3.216 eDRX-Cycle-Length-Value The eDRX-Cycle-Length-Value AVP is of type OctetString. This AVP shall contain the extended DRX cycle value subscribed for this user for a given RAT type. The contents of eDRX-Cycle-Length-Value shall consist of 1 octet. The encoding shall be as defined in 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.5.32, and it shall only contain the value of the field ""eDRX value"" for a given RAT type, i.e., the 4 least significant bits of the octet in this AVP shall contain bits 1-4 of octet 3 in the ""Extended DRX parameter"" IE (see Figure 10.5.5.32 of 3GPPÊTSÊ24.008Ê[31]), and the 4 most significant bits of the octet in this AVP shall be set to 0. 7.3.217 UE-PC5-AMBR The UE-PC5-AMBR AVP is of type Unsigned32. It indicates the maximum bits delivered by UE over the PC5 interface within a period of time. The unit of UE-PC5-AMBR is bits/s. 7.3.218 Extended eNodeB-ID The Extended eNodeB-ID AVP is of type OctetString, and indicates the eNodeB in which the UE is currently located. It is originally defined in 3GPPÊTSÊ29.217Ê[56]. 7.3.219 MBSFN-Area The MBSFN-Area AVP is of type Grouped. It contains a MBSFN Area ID and a Carrier Frequency (see 3GPPÊTSÊ32.422Ê[23]). The AVP format shall conform to: MBSFN-Area ::= <AVP header: 1694 10415> [ MBSFN-Area-ID ] [ Carrier-Frequency ] *[ AVP ] If both MBSFN-Area-ID and Carrier-Frequency values are present, a specific MBSFN area is indicated. If Carrier-Frequency value is present, but MBSFN-Area-ID is absent, all MBSFN areas on that carrier frequency are indicated. If both MBSFN-Area-ID and Carrier-Frequency are absent, any MBSFN area is indicated. 7.3.220 MBSFN-Area-ID The MBSFN-Area-ID AVP is of type Unsigned32 and it shall contain the MBSFN Area ID value, in the range of 0..255 (see 3GPPÊTSÊ36.331Ê[62]). 7.3.221 Carrier-Frequency The Carrier-Frequency AVP is of type Unsigned32 and it shall contain the Carrier Frequency value, in the range of 0..262143 (see 3GPPÊTSÊ36.331Ê[62]). 7.3.222 RDS-Indicator The RDS-Indicator AVP is of type Enumerated and indicates whether the Reliable Data Service (RDS) is enabled or disabled for the APN. See 3GPPÊTSÊ23.682Ê[55]. The following values are defined: DISABLED (0) ENABLED (1) The default value when this AVP is not present is DISABLED (0). 7.3.223 Service-Gap-Time The Service-Gap-Time AVP is of type Unsigned32 and indicates the minimum number of seconds during which the UE shall stay in ECM-IDLE mode, after leaving the ECM-CONNECTED mode, before being allowed to send a subsequent connection request to enter ECM-CONNECTED mode again. See description of the Service Gap Control feature in 3GPPÊTSÊ23.401Ê[2]. 7.3.224 Aerial-UE-Subscription-Information The Aerial-UE-Subscription-Information AVP is of type Unsigned32 and indicates the subscription of Aerial UE function. The following values are defined: AERIAL_UE_ALLOWED (0) AERIAL_UE_NOT_ALLOWED (1) This AVP corresponds to the ""Aerial UE subscription information"" information element as defined in 3GPPÊTSÊ36.413[19] and TSÊ36.423Ê[65]. 7.3.225 Broadcast-Location-Assistance-Data-Types The Broadcast-Location-Assistance-Data-Types AVP is of type Unsigned64. The content of this AVP is a bit mask which indicates the broadcast location assistance data types for which the UE is subscribed to receive ciphering keys used to decipher broadcast assistance data. The meaning of the bits is defined in table 7.3.225-1: Table 7.3.225-1: Broadcast-Location-Assistance-Data-Types bit name Description 0 Positioning SIB Type 1-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-1. 1 Positioning SIB Type 1-2 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-2. 2 Positioning SIB Type 1-3 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-3. 3 Positioning SIB Type 1-4 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-4. 4 Positioning SIB Type 1-5 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-5. 5 Positioning SIB Type 1-6 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-6. 6 Positioning SIB Type 1-7 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-7. 7 Positioning SIB Type 2-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-1. 8 Positioning SIB Type 2-2 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-2. 9 Positioning SIB Type 2-3 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-3. 10 Positioning SIB Type 2-4 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-4. 11 Positioning SIB Type 2-5 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-5. 12 Positioning SIB Type 2-6 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-6. 13 Positioning SIB Type 2-7 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-7. 14 Positioning SIB Type 2-8 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-8. 15 Positioning SIB Type 2-9 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-9. 16 Positioning SIB Type 2-10 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-10. 17 Positioning SIB Type 2-11 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-11. 18 Positioning SIB Type 2-12 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-12. 19 Positioning SIB Type 2-13 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-13. 20 Positioning SIB Type 2-14 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-14. 21 Positioning SIB Type 2-15 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-15. 22 Positioning SIB Type 2-16 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-16. 23 Positioning SIB Type 2-17 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-17. 24 Positioning SIB Type 2-18 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-18. 25 Positioning SIB Type 2-19 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-19. 26 Positioning SIB Type 3-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 3-1. 27 Positioning SIB Type 1-8 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-8. 28 Positioning SIB Type 2-20 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-20. 29 Positioning SIB Type 2-21 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-21. 30 Positioning SIB Type 2-22 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-22. 31 Positioning SIB Type 2-23 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-23. 32 Positioning SIB Type 2-24 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-24. 33 Positioning SIB Type 2-25 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-25. 34 Positioning SIB Type 4-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 4-1. 35 Positioning SIB Type 5-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 5-1. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.226 Paging-Time-Window The Paging-Time-Window AVP is of type Grouped. This AVP shall contain the Paging Time Window length, along with the Operation Mode (see clauseÊ7.3.227) for which this time window length is applicable to. AVP format: Paging-Time-Window ::= <AVP header: 1701 10415> { Operation-Mode } { Paging-Time-Window-Length } *[ AVP ] 7.3.227 Operation-Mode The Operation-Mode AVP is of type Unsigned32. This value shall indicate the operation mode for which the Paging-Time-Window-Length applies. See clauseÊ3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.5.32. The allowed values of Operation-Mode shall be in the range of 0 to 255. Values are defined as follows: 0: Spare, for future use 1: Iu mode 2: WB-S1 mode 3: NB-S1 mode 4 to 255: Spare, for future use 7.3.228 Paging-Time-Window-Length The Paging-Time-Window-Length AVP is of type OctetString. This AVP shall contain the Paging time window length subscribed for this user for a given operation mode. The contents of Paging-Time-Window-Length shall consist of 1 octet. The encoding shall be as defined in 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.5.32, and it shall only contain the value of the field ""Paging Time Window length"" for a given RAT type, i.e., the 4 most significant bits of the octet in this AVP shall contain bits 5-8 of octet 3 in the ""Extended DRX parameter"" IE (see Figure 10.5.5.32 of 3GPPÊTSÊ24.008Ê[31]), and the 4 least significant bits of the octet in this AVP shall be set to 0. 7.3.229 eDRX-Related-RAT The eDRX-Related-RAT AVP is of type Grouped. This AVP shall contain the RAT type to which the eDRX Cycle Length is related: AVP format eDRX-Related-RAT ::= <AVP header: 1705 10415> 1 * { RAT-Type } *[AVP] 7.3.230 Core-Network-Restrictions The Core-Network-Restrictions AVP is of type Unsigned32 and shall contain a bitmask indicating the types of Core Network that are disallowed for a given user. The meaning of the bits shall be as defined in table 7.3.230-1: Table 7.3.230-1: Core-Network-Restrictions Bit Name Description 0 Reserved The use of this bit is deprecated. This bit shall be discarded by the receiving MME. 1 5GC not allowed Access to 5GC not allowed. NOTE: Bits not defined in this table shall be cleared by the HSS and discarded by the MME. 7.3.231 Interworking-5GS-Indicator The Interworking-5GS-Indicator AVP is of type Enumerated and indicates whether the interworking between 5GS and EPS is subscribed or not subscribed for the APN. See 3GPPÊTSÊ23.502Ê[67]. The following values are defined: NOT-SUBSCRIBED (0) SUBSCRIBED (1) The default value when this AVP is not present is NOT-SUBSCRIBED (0). 7.3.232 Ethernet-PDN-Type-Indicator The Ethernet-PDN-Type-Indicator AVP is of type Enumerated and indicates whether the APN has an Ethernet PDN type. The following values are defined: FALSE (0) This value indicates that the APN does not have an Ethernet PDN type. TRUE (1) This value indicates that the APN has an Ethernet PDN type and in this case the value indicated by the PDN-Type AVP inside APN-Configuration AVP shall be ignored. The default value when this AVP is not present is FALSE (0). 7.3.233 Subscribed-ARPI The Subscribed-ARPI AVP is of type Unsigned32 and shall contain the subscribed value of the Additional RRM Policy Index. For details, see 3GPPÊTSÊ23.401Ê[2]. 7.3.234 IAB-Operation-Permission The IAB-Operation-Permission AVP is of type Enumerated. It shall indicate to the MME or SGSN whether the UE is allowed for IAB operation. See 3GPPÊTSÊ23.401Ê[2]. The following values are defined: IAB_OPERATION_ALLOWED (0) IAB_OPERATION_NOTALLOWED (1) 7.3.235 V2X-Subscription-Data-Nr The V2X-Subscription-Data-Nr AVP is of type Grouped. It shall contain the V2X related subscription data for the network scheduled NR sidelink communication. AVP format: V2X-Subscription-Data-Nr ::= <AVP header: 1710 10415> [ V2X-Permission ] [ UE-PC5-AMBR ] [ UE-PC5-QoS ] *[AVP] The UE-PC5-AMBR AVP within the V2X-Subscription-Data AVP indicates the UE AMBR used for NR PC5 interface. 7.3.236 UE-PC5-QoS The UE-PC5-QoS AVP is of type Grouped. It shall contain the PC5 QoS parameters for V2X communication over NR PC5 reference point. AVP format: UE-PC5-QoS ::= <AVP header: 1711 10415> 1*{ PC5-QoS-Flow } [ PC5-Link-AMBR ] *[AVP] 7.3.237 PC5-QoS-Flow The PC5-QoS-Flow AVP is of type Grouped. It shall contain the QoS parameters for a PC5 flow. AVP format: PC5-QoS-Flow ::= <AVP header: 1712 10415> { 5QI } [ PC5-Flow-Bitrates ] [ PC5-Range ] *[AVP] 7.3.238 5QI The 5QI AVP is of type Integer32. It shall contain the 5QI. See 3GPPÊTSÊ23.501Ê[69] for allowed values.If the 5QI is used in PC5 QoS parameter, it shall contain PQI, PQI is a special 5QI (see clauseÊ5.4.2.1 of 3GPPÊTSÊ23.287Ê[68]). 7.3.239 PC5-Flow-Bitrates The PC5-Flow-Bitrates AVP is of type Grouped. It shall contain the PC5 Flow Bit Rates, it's for GBR QoS Flows only. AVP format: PC5-Flow-Bitrates ::= <AVP header: 1714 10415> [ Guaranteed-Flow-Bitrates ] [ Maximum-Flow-Bitrates ] 7.3.240 Guaranteed-Flow-Bitrates The Guaranteed-Flow-Bitrates AVP is of type Integer32. It indicates the guaranteed bits delivered for the PC5 QoS flow by UE over the PC5 interface within a period of time. The unit of Guaranteed-Flow-Bitrates is bits/s. 7.3.241 Maximum-Flow-Bitrates The Maximum-Flow-Bitrates AVP is of type Integer32. It indicates the maximum bits delivered for the PC5 QoS flow by UE over the PC5 interface within a period of time. The unit of Maximum-Flow-Bitrates is bits/s. 7.3.242 PC5-Range The PC5-Range AVP is of type Integer32. It indicates the Range in the unit of meters. See clauseÊ5.4.2.4 of 3GPPÊTSÊ23.287Ê[68]. 7.3.243 PC5-Link-AMBR The PC5-Link-AMBR AVP is of type Integer32. It indicates t the PC5 Link Aggregated Bit Rates for all the Non-GBR QoS Flows. The unit of PC5-Link-AMBR is bits/s. 7.3.244 Third-Context-Identifier The Third-Context-Identifier AVP is of type Unsigned32 and indicates the identity of another default APN to be used when the subscription profile of the user contains APNs with three PDN types, i.e. IP-based PDN types, non-IP PDN types and Ethernet PDN types. 7.4 Result-Code and Experimental-Result Values 7.4.1 General This clause defines result code values that shall be supported by all Diameter implementations that conform to this specification. 7.4.2 Success Result codes that fall within the Success category shall be used to inform a peer that a request has been successfully completed. The Result-Code AVP values defined in the Diameter base protocol IETFÊRFCÊ6733Ê[61] shall be applied. 7.4.3 Permanent Failures Errors that fall within the Permanent Failures category shall be used to inform the peer that the request has failed, and should not be attempted again. The Result-Code AVP values defined in the Diameter base protocol IETFÊRFCÊ6733Ê[61] shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and the Result-Code AVP shall be absent. 7.4.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001) This result code shall be sent by the HSS to indicate that the user identified by the IMSI is unknown 7.4.3.2 DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) This result code shall be sent by the HSS to indicate that no EPS subscription is associated with the IMSI. 7.4.3.3 DIAMETER_ERROR_RAT_NOT_ALLOWED (5421) This result code shall be sent by the HSS to indicate the RAT type the UE is using is not allowed for the IMSI. 7.4.3.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) This result code shall be sent by the HSS to indicate that the subscriber is not allowed to roam within the MME or SGSN area. 7.4.3.5 DIAMETER_ERROR_EQUIPMENT_UNKNOWN (5422) This result code shall be sent by the EIR to indicate that the mobile equipment is not known in the EIR. 7.4.3.6 DIAMETER_ERROR_UNKNOWN_SERVING_NODE (5423) This result code shall be sent by the HSS to indicate that a Notify command has been received from a serving node which is not registered in HSS as the node currently serving the user. 7.4.4 Transient Failures Result codes that fall within the transient failures category shall be used to inform a peer that the request could not be satisfied at the time it was received, but may be able to satisfy the request in the future. The Result-Code AVP values defined in the Diameter base protocol IETFÊRFCÊ6733Ê[61]shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and the Result-Code AVP shall be absent. 7.4.4.1 DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181) This result code shall be sent by the HSS to indicate that an unexpectedly transient failure occurs. The requesting node can try the request again in the future. 7.4.4.2 DIAMETER_ERROR_CAMEL_SUBSCRIPTION_PRESENT (4182) This result code shall be sent by the HSS to indicate that the subscriber to be registered has SGSN CAMEL Subscription data. 8 User identity to HSS resolution The User identity to HSS resolution mechanism enables the MME, SGSN (for non-roaming case) or Diameter Relay/proxy agents in the home network (for roaming case) to find the identity of the HSS that holds the subscriber data for a given user identity when multiple and separately addressable HSSs have been deployed in the home network. The resolution mechanism is not required in networks that utilise a single HSS. This User identity to HSS resolution mechanism may rely on routing capabilitites provided by Diameter and be implemented in the home operator network within dedicated Diameter Agents (Redirect Agents or Proxy Agents) responsible for determining the HSS identity based on the provided user identity. If this Diameter based implementation is selected by the Home network operator, the principles described below shall apply. In non-roaming case, in networks where more than one independently addressable HSS are deployed in the home network, each MME and SGSN shall be configured with the address/identity of a Diameter Agent (Redirect Agent or Proxy Agent) implementing this resolution mechanism. For support of roaming case, Diameter Relay agents and/or Diameter Proxy agents in the home network receiving the Diameter signalling from visited networks shall be configured with the address/identity of a Diameter Agent (Redirect Agent or Proxy Agent) implementing this resolution mechanism. To get the HSS identity that holds the subscriber data for a given user identity in the home network, the Diameter request normally destined to the HSS shall be sent to a pre-configured address/identity of a Diameter agent supporting the User identity to HSS resolution mechanism. - If this Diameter request is received by a Diameter Redirect Agent, the Diameter Redirect Agent shall determine the HSS identity based on the provided user identity and shall return a notification of redirection towards the HSS identity, in response to the Diameter request. Multiple HSS identities may be included in the response, as specified in IETFÊRFCÊ6733Ê[61]. In such a case, the requesting Diameter entity shall send the Diameter request to the first HSS identity in the ordered list received in the Diameter response from the Diameter Redirect Agent. If no successful response to the Diameter request is received, the requesting Diameter entity shall send a Diameter request to the next HSS identity in the ordered list. This procedure shall be repeated until a successful response from an HSS is received. After the user identity to HSS resolution, the MME or the SGSN shall store the determined HSS identity/name/Realm and shall use it in further Diameter requests to the same user identity. - If this Diameter request is received by a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the HSS identity based on the provided user identity and - if the Diameter load control mechanism is supported (see IETFÊRFCÊ8583Ê[60]) - optionally also based on previously received load values from Load AVPs of type HOST. The Diameter Proxy Agent shall then forward the Diameter request directly to the determined HSS. In this case, the user identity to HSS resolution decision is communicated to the MME/SGSN in the Origin-Host/Origin-Realm AVPs of the response. The MME or the SGSN may store the determined HSS identity/name/Realm and may use it in further Diameter requests to the same user identity. In roaming case, whereas a Diameter Relay Agent is stateless, a stateful Diameter Proxy Agent in the home network may store the determined HSS identity/name/Realm and use it in further Diameter requests associated to the same user identity. NOTE: Alternatives to the user identity to HSS resolution Diameter based implementation are outside the scope of this specification. Annex A (normative): MME mapping table for S6a and NAS Cause Code values When the UE initiates Attach, Tracking Area Update or Service Request, there may be the need for the MME to communicate with the HSS via S6a to retrieve authentication data and/or subscription data. If this retrieval is rejected by the HSS, the received Diameter-Result-Code values or Experimental-Result values need to be mapped to appropriate cause codes over NAS to the UE. This mapping shall be as shown in Table A.1. If the retrieval is successful, not needed (e.g. because data are already available) or not possible (e.g. because HSS is unavailable or overloaded), detected error conditions need to be mapped to appropriate cause codes over NAS to the UE. This mapping shall be as shown in Table A.2. Table A.1: Mapping from S6a error code to NAS Cause Code values Reject indication received at MME over S6a NAS Cause Code sent to UE DIAMETER_ERROR_USER_UNKNOWN (5001) #8 ""EPS services and non-EPS services not allowed"" DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) without Error Diagnostic, or with Error Diagnostic of GPRS_DATA_SUBSCRIBED #15 ""No suitable cells in tracking area"" DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) with Error Diagnostic of NO_GPRS_DATA_SUBSCRIBED #7 ""EPS services not allowed"" DIAMETER_ERROR_RAT_NOT_ALLOWED (5421) #15 ""No suitable cells in tracking area"", or #13 ""Roaming not allowed in this tracking area"", or #12 ""Tracking area not allowed"" (NOTE 1) DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) , without Error Diagnostic #11 ""PLMN not allowed"" DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), with Error Diagnostic of ODB_HPLMN_APN or ODB_VPLMN_APN #14 ""EPS services not allowed in this PLMN"" DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), with Error Diagnostic of ODB_ALL_APN #15 ""No suitable cells in tracking area"" DIAMETER_AUTHORIZATION_REJECTED (5003) DIAMETER_UNABLE_TO_DELIVER (3002) DIAMETER_REALM_NOT_SERVED (3003) #15 ""No suitable cells in tracking area"", or #17 ""Network failure"", or #42 ""Severe network failure"" (NOTE 1) DIAMETER_UNABLE_TO_COMPLY (5012), DIAMETER_INVALID_AVP_VALUE (5004) DIAMETER_AVP_UNSUPPORTED (5001) DIAMETER_MISSING_AVP (5005) DIAMETER_RESOURCES_EXCEEDED (5006) DIAMETER_AVP_OCCURS_TOO_MANY_TIMES (5009) DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181) (NOTE 2) #17 ""Network failure"" or #42 ""Severe network failure"" (NOTE 1) NOTE 1: Any of those NAS Cause Code values may be sent to the UE, depending on operator's choice. NOTE 2: Any other permanent errors from the Diameter base protocol as defined in IETFÊRFCÊ6733Ê[61], not listed here, should be mapped to NAS Cause Code #17 ""Network failure"". Table A.2: Mapping from detected error condition to NAS Cause Code values Condition NAS cause code sent to UE The MME receives a SGsAP-LOCATION-UPDATE-REJECT message from the VLR indicating in the reject cause ""IMSI unknown in HLR"" or if the UE has packet only subscription. Only used in the Combined Tracking and Location Area Update procedure. #2 ""IMSI Unknown in HSS"" The MME receives in Update-Location-Answer message an indication of Roaming restricted in MME due to unsupported feature #14 ""EPS services not allowed in this PLMN"" The MME cannot service an UE generated request because CS domain is not available and SMS in MME is not supported. #18 ""CS domain not available"" The value OPERATOR_DETERMINED_BARRING is received in the Subscriber-Status AVP #15 ""No suitable cells in tracking area"" The HSS indicates that due to subscription to a ""regionally restricted service"" the UE is not allowed to operate in the tracking area. #12 ""Tracking area not allowed"" The CSG ID of the cell from where the UE has sent the TRACKING AREA UPDATE REQUEST message is not contained in the Allowed CSG list. #25 ""Not authorized for this CSG"" The MME detects that it cannot communicate with the HSS in the HPLMN of the subscriber. How the MME detect this is implementation specific. #15 ""No suitable cells in tracking area"" #14 ""EPS services not allowed in this PLMN"" #111 ""Protocol error, unspecified"" NOTE: Any of those NAS Cause Code values may be sent to the UE, depending on operator's choice / configuration, e.g. NAS Cause Code #14 is to be sent to the UE if the network is an LTE only network. The MME detects by internal configuration that roaming is not allowed. #11 ""PLMN not allowed"" The MME detects that it cannot send a request to the HSS due to HSS overload (see Annex C). #22 ""Congestion"" #42 ""Severe network failure"" NOTE 1: Cause #22 should be used. In addition, the MME may ask the UE not to retry before a backoff timer expires, based on an operator policy. The eventual timer value may take into account the value received in the corresponding active overload report and operator policy. NOTE 2: Cause #42 may be used, for attach requests, in case of severe overload, according to operator policy. Annex B(normative): SGSN mapping table for S6d and NAS Cause Code values When the UE initiates Attach, Routing Area Update or Service Request, there may be the need for the SGSN to communicate with the HSS via S6d to retrieve authentication data and/or subscription data. If this retrieval is rejected by the HSS, the received Diameter-Result-Code values or Experimental-Result valuesneed to be mapped to appropriate cause codes over NAS to the UE. NOTE: Mapping from MAP Gr error codes to NAS Cause Code values is described in the 3GPPÊTSÊ29.010Ê[45]. This mapping shall be as shown in Table B.1. If the retrieval is successful, not needed (e.g. because data are already available) or not possible (e.g. because HSS is unavailable or overloaded), detected error conditions need to be mapped to appropriate cause codes over NAS to the UE. This mapping shall be as shown in Table and B.2. Table B.1: Mapping from S6d error code to NAS Cause Code values Reject indication received at SGSN over S6d NAS Cause Code sent to UE DIAMETER_ERROR_USER_UNKNOWN (5001) #8 ""GPRS services and non-GPRS services not allowed"" DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) #7 ""GPRS services not allowed"" DIAMETER_ERROR_RAT_NOT_ALLOWED (5421) #15 ""No suitable cells in location area"", or #13 ""Roaming not allowed in this location area"", or #12 ""Location area not allowed"" (NOTE 1) DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) , without Error Diagnostic #11 ""PLMN not allowed"" DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), with Error Diagnostic of ODB_HPLMN_APN or ODB_VPLMN_APN #14 ""GPRS services not allowed in this PLMN"" DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), with Error Diagnostic of ODB_ALL_APN #15 ""No suitable cells in location area"" DIAMETER_AUTHORIZATION_REJECTED (5003) DIAMETER_UNABLE_TO_DELIVER (3002) #15 ""No suitable cells in location area"" DIAMETER_UNABLE_TO_COMPLY (5012), DIAMETER_INVALID_AVP_VALUE (5004) DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181) and no retry takes place (NOTE 2) #17 ""Network failure"" NOTE 1: Any of those NAS Cause Code values may be sent to the UE, depending on operator's choice. NOTE 2: Any other permanent errors from the Diameter base protocol as defined in IETFÊRFCÊ6733Ê[61], not listed here, should be also mapped to NAS Cause Code #17 ""Network failure""."
"Table B.2: Mapping from detected error condition to NAS Cause Code values Condition NAS cause code to UE The SGSN receives a BSSAP+-LOCATION-UPDATE-REJECT message from the VLR indicating in the reject cause ""IMSI unknown in HLR"" or if the UE has packet only subscription. Only used in the Combined Routing and Location Area Update procedure. #2 ""IMSI Unknown in HLR"" The SGSN receives in Update-Location-Answer message an indication of Roaming restricted in SGSN due to unsupported feature #14 ""GPRS services not allowed in this PLMN"" The value OPERATOR_DETERMINED_BARRING is received in the Subscriber-Status AVP #15 ""No suitable cells in routing area"" The HLR indicates that due to subscription to a ""regionally restricted service"" the MS is not allowed to operate in the location area. #12 ""Location area not allowed"" The CSG ID of the cell from where the UE has sent the ROUTING AREA UPDATE REQUEST message is not contained in the Allowed CSG list. #25 ""Not authorized for this CSG"" The SGSN indicates that the MS has requested ""SMS-only services"" and the SMS services are provided by the SGSN in the PS domain. #28 ""SMS provided via GPRS in this routing area"" The SGSN detects that it cannot communicate with the HLR in the HPLMN of the subscriber. How the SGSN detect this is implementation specific. #15 ""No suitable cells in routing area"" #14 ""GPRS services not allowed in this PLMN"" NOTE: Any of those NAS Cause Code values may be sent to the UE, depending on operator's choice / configuration, e.g. NAS Cause Code #14 is to be sent to the UE if the network is an LTE only network. The SGSN detects by internal configuration that roaming is not allowed. #11 ""PLMN not allowed"" The SGSN detects that it cannot send a request to the HSS due to HSS overload (see Annex C). #22 ""Congestion"". In addition, the MME may ask the UE not to retry before a backoff timer expires, based on an operator policy. The eventual timer value may take into account the value received in the corresponding active overload report and operator policy. Annex C (normative): Diameter overload control mechanism C.1 General IETFÊRFCÊ7683Ê[50] specifies a Diameter overload control mechanism which includes the definition and the transfer of related AVPs between Diameter nodes. Depending on regional/national requirements and network operator policy, priority traffic (e.g. MPS as described in 3GPPÊTSÊ22.153Ê[52]) shall be exempted from throttling due to Diameter overload control up to the point where requested traffic reduction cannot be achieved without throttling the priority traffic. C.2 S6a/S6d interfaces C.2.1 General Diameter overload control mechanism is an optional feature. It is recommended to make use of IETFÊRFCÊ7683Ê[50] on the S6a/S6d interfaces where, when applied, the MME or the SGSN shall behave as reacting nodes and the HSS as a reporting node. C.2.2 HSS behaviour The HSS requests traffic reduction from its clients when the HSS is in an overload situation, including OC-OLR AVP in answer commands as described in IETFÊRFCÊ7683Ê[50]. The HSS identifies that it is in an overload situation by implementation specific means. For example, the HSS may take into account the traffic over the S6a/d interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources, etc. The HSS determines the specific contents of OC-OLR AVP in overload reports and the HSS decides when to send OC-OLR AVPs by implementation specific means. C.2.3 MME/SGSN behaviour The MME/SGSN applies required traffic reduction received in answer commands to subsequent applicable requests, as per RFC 7683Ê[50]. Requested traffic reduction is achieved by the MME/SGSN by implementation specific means. For example, it may implement message throttling with prioritization or a message retaining mechanism for operations that can be postponed. Diameter requests related to priority traffic (e.g. MPS as identified by the MME/SGSN through access procedures) and emergency have the highest priority. Depending on regional/national regulatory and operator policies, these Diameter requests shall be the last to be throttled, when the MME/SGSN has to apply traffic reduction. Relative priority amongst various priority traffic (e.g. MPS) and emergency traffic is subject to regional/national regulatory and operator policies. As a result of the need to throttle traffic, the MME or SGSN may reject Attach, Tracking Area Update or Service Requests initiated by UEs. The possible NAS causes are described in the Annex A and B. Annex D (Informative): Diameter overload control node behaviour D.1 Message prioritisation over S6a/d This clause describes possible behaviours of the MME/SGSN regarding message prioritisation as guidance and for an informative purpose when Diameter overload control is applied over S6a/d. When the HSS is overloaded, the MME/SGSN will receive overload reports from the HSS requesting a reduction of the requests sent by the MME/SGSN. The following and not exhaustive considerations may be taken into account for the MME/SGSN throttling decisions: - Prioritisation of requests related to priority traffic (e.g. MPS as identified by the MME/SGSN through access procedures, emergency) - Identification of the procedures that can be deferred (e.g. UE reachable notification, purge after a long inactivity time), so to avoid to drop non deferrable procedures; - Prioritisation of certain types of requests (i.e. between AIR, ULR, PUR, NOR) according to the context of their use, in particular: - Higher prioritisation of ULR commands when used in relation with mobility management (e.g. handover) for an attached user, so to avoid the interruption of the service for the user; - Lower prioritisation of AIR and ULR commands when related to an initial attach, so to avoid the attachment of new users; - Skipping of optional authentication (e.g. in TAU procedures). Annex E (normative): Diameter message priority mechanism E.1 General IETFÊRFCÊ7944Ê[57] specifies a Diameter routing message priority mechanism that allows Diameter nodes to indicate the relative priority of Diameter messages. With this information, other Diameter nodes may leverage the relative priority of Diameter messages into routing, resource allocation, set the DSCP marking for transport of the associated Diameter message, and also abatement decisions when overload control is applied. E.2 S6a/S6d interfaces E.2.1 General The Diameter message priority mechanism is an optional feature. It is recommended to make use of IETF ÊRFC 7944Ê[57] over the S6a/S6d interfaces of an operator network when the overload control defined in Annex C is applied on these S6a/d interfaces. E.2.2 HSS, CSS, EIR behaviour When the HSS, the CSS or the EIR supports the Diameter message priority mechanism, the HSS, the CSS, or the EIR shall comply with IETFÊRFCÊ7944Ê[57]. The HSS or the CSS sending a request shall determine the required priority according to its policies. When priority is required, the HSS or the CSS shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level. When the HSS or the CSS receives the corresponding response, the HSS or the CSS shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request. When the HSS, the CSS, or the EIR receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, the HSS, the CSS, or the EIR may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, the HSS, the CSS, or the EIR shall include the DRMP AVP in the response.If: - the HSS, the CSS or the EIR supports using the Diameter message priority mechanism for DSCP marking purposes, - the transport network utilizes DSCP marking, and - message-dependant DSCP marking is possible for the protocol stack transporting Diameter, then the HSS, the CSS or the EIR shall set the DSCP marking for transport of the request or response according to the required priority level. When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific. E.2.3 MME/SGSN behaviour When the MME/SGSN supports the Diameter message priority mechanism, the MME/SGSN shall comply with IETFÊRFCÊ7944Ê[57]. The MME/SGSN sending a request shall determine the required priority according to its policies. When priority is required, the MME/SGSN shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the requests according to the required priority level. When the MME/SGSN receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request. When the MME/SGSN receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, it may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response. If: - the MME/SGSN supports using the Diameter message priority mechanism for DSCP marking purposes, - the transport network utilizes DSCP marking, and - message-dependant DSCP marking is possible for the protocol stack transporting Diameter, then the MME/SGSN shall set the DSCP marking for transport of the request or response according to the required priority level. Diameter requests related to high priority traffic (e.g. MPS as identified by the MME/SGSN via the RRC Establishment Cause IE set to the highPriorityAccess value as per 3GPPÊTSÊ36.413Ê[19] or through subscription information in the MPS-Priority AVP, emergency) shall contain a DRMP AVP with a high priority of which the level value is operator dependent. When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific. Annex F (normative): Diameter load control mechanism F.1 General IETFÊRFCÊ8583Ê[60] specifies a mechanism for sharing of Diameter load information. It includes the definition and the transfer of related AVPs between Diameter nodes. F.2 S6a/S6d interfaces F.2.1 General Diameter load control mechanism is an optional feature. It is recommended to make use of IETFÊRFCÊ8583Ê[60] on the S6a/S6d interfaces where, when applied, the MME or the SGSN shall behave as receiving nodes and the HSS as a reporting node. F.2.2 HSS behaviour The HSS may report its current load by including a Load AVP of type HOST in answer commands as described in IETFÊRFCÊ8583Ê[60]. The HSS calculates its current load by implementation specific means. For example, the HSS may take into account the traffic over the S6a/d interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources, etc. The HSS determines when to send Load AVPs of type HOST by implementation specific means. F.2.3 MME/SGSN behaviour When performing next hop Diameter Agent selection for requests that are routed based on realm, the MME/SGSN may take into account load values from Load AVPs of type PEER received from candidate next hop Diameter nodes, as per IETFÊRFCÊ8583Ê[60]. Annex G (informative): Change history Date TSGÊ# TSG Doc."
"CR Rev Cat Subject/Comment New 2008-09 CT#41 CP-080475 V2.0.0 approved in CT#41 8.0.0 2008-12 CT#42 CP-080691 0001 1 S6a Vendor-Specific-Application-Id AVP 8.1.0 CP-080691 0002 1 RegSub feature CP-080691 0005 - Clarification on Immediate-Response-Preferred CP-080691 0006 1 Correction of the Reference of Supported Features CP-080691 0007 - Definition of RAT-Frequency-Selection-Priority CP-080691 0008 2 ME Identity Check CP-080703 0009 2 Gr alignment CP-080971 0010 3 Closed Subscriber Group CP-080691 0011 - AVP codes CP-080691 0012 1 MSISDN AVP CP-080691 0013 - Result codes CP-080691 0014 - Removal of Editor's note in ULA Flag CP-080691 0015 2 Duplicated AMBR AVP and Use of Called-Station-Id CP-080691 0017 - Change of AVP to carry the APN information CP-080691 0018 1 Reference to 3GPP-Charging-Characteristics CP-080691 0019 - Access Restriction Data Definition CP-080691 0020 - AMBR Definition CP-080691 0021 1 AVPs Encoding CP-080691 0022 1 PDN-GW Delete CP-080691 0023 1 Requesting Node Type Clarification CP-080691 0024 - Authn Session State AVP CP-080691 0026 2 Trace Session Activation and Deactivation CP-080691 0027 1 Context-Identifier in APN-Configuration-Profile CP-080691 0029 - APN-OIReplacement CP-080703 0032 - Access Restriction CP-080691 0033 1 Context Identifier clarification CP-080691 0034 1 APN-Configuration correction CP-080691 0037 - Removal of Supported RAT Types CP-080691 0039 1 Extension of the Terminal-Information AVP for non-3GPP accesses CP-080691 0040 - Conditionality of ULA-Flags and PUA-Flags AVPs CP-080691 0042 - Wrong Description for Complete APN Configuration Profile Withdrawal CP-080691 0043 - Purge UE Detailed Behaviour CP-080691 0044 1 MME/SGSN area restricted flag cleanup - TS number in cover page corrected 8.1.1 2009-03 CT#43 CP-090056 0048 2 Context Identifier for Update or Removal of PDN GW 8.2.0 CP-090046 0049 - Clarification of the relationship between Subscriber-Status and ODB CP-090046 0051 2 Context-Identifier in APN-Configuration-Profile CP-090024 0052 - Update of the AVP Codes CP-090236 0053 2 PDN GW update for Wildcard APN CP-090044 0054 1 Ready for SM CP-090046 0055 - ODB for SM CP-090044 0056 2 Handling LCS Subscription Data CP-090046 0057 2 Charging Characteristics CP-090046 0058 2 Regional-Subscription-Zone-Code AVP Correction CP-090046 0059 2 Trace Depth corrections CP-090046 0060 2 Delete Subscriber Data Request procedure CP-090046 0063 1 Coding definition for STN-SR CP-090046 0064 - Trace Reference in DSR CP-090046 0065 1 DSR-Flags CP-090046 0066 2 Clarification on All-APN-Configurations-Included-Indicator CP-090046 0069 - User-Name AVP contains only the IMSI CP-090046 0070 1 MIP6-Agent-Info Definition and Usage CP-090046 0075 1 Allocation Retention Priority CP-090046 0076 1 APN includes only the Network Identifier CP-090046 0077 - Error Codes and ABNF Corrections CP-090039 0078 4 User to HSS resolution CP-090046 0079 1 Introducing the Trace-Collection-Entity AVP CP-090046 0081 4 Usage of Immediate-Response-Preferred AVP CP-090044 0082 3 Handling SMS Subscription Data CP-090046 0083 - SCTP version CP-090046 0084 - RFC 5447 References 2009-06 CT#44 CP-090287 0086 1 Notification of SMS over IP Non-Delivery for E-UTRAN and UE Reachability 8.3.0 CP-090287 0087 1 Coding of Immediate Response Preferred AVP CP-090287 0088 - Trace Event List CP-090287 0089 - Removal of Requesting Node Type from AIR CP-090287 0091 - Regional-Subscription-Zone-Code clarification CP-090287 0092 - Clarification of PLMN encoding CP-090287 0093 - Diameter Command Codes for S6a/S6d/S13/S13' CP-090287 0094 - Update of Diameter Codes CP-090287 0095 1 Formatting of APN in Service-Selection AVP CP-090378 0096 3 User Data Download Indication CP-090315 0097 - Usage of Single-Registration-Indication CP-090495 0098 3 ULR processing enhancement 2009-09 CT#45 CP-090531 0100 2 Correction on APN-OI-Replacement 8.4.0 Cp-090726 0101 3 GPRS subscription data over S6d CP-090531 0102 1 Usage of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION CP-090531 0103 6 Cancel Location for Initial Attach CP-090531 0104 4 Subscriber Data Update CP-090531 0105 1 Usage of Single Registration Indication CP-090531 0106 2 Charging Characteristics Reference CP-090531 0107 1 Alerting Reason Behaviour CP-090531 0108 1 Wildcard APN CP-090531 0109 - Subscriber's NAM CP-090531 0111 - Trace ID length correction CP-090531 0112 1 Subscription-Data AVP in Update Location Answer CP-090531 0113 1 Default values for Allocation Retention Priority AVP CP-090531 0114 - Default APN and Wildcard APN CP-090531 0115 2 Correction in behavior of DSR-Flags CP-090531 0116 1 PDN Type CP-090531 0118 1 Clarification on the process of skip subscriber data flag in the HSS CP-090532 0119 1 Corrections on IDR ABNF and Service Type AVP CP-090532 0120 1 TS-Code AVP is missing in DSR command CP-090532 0123 1 Cleanup of the TS CP-090532 0124 1 Format of User-Id CP-090532 0125 1 GPRS Subscription Data Update CP-090532 0126 2 APN-Configuration-Profile CP-090532 0128 1 3GPP2-MEID AVP CP-090532 0129 1 MIP6-Agent-Info AVP CP-090532 0130 - Alignment of Supported Feature concept with 29.229 CP-090532 0133 1 EPS Subscribed QoS CP-090532 0137 1 Restruction of the TSÊ29.272 CP-090532 0138 1 Trace Depth per session CP-090532 0140 - Clarification of Unsigned32 bit flag AVPs CP-090532 0141 1 Extra Regional-Subscription-Zone-Codes CP-090532 0142 1 Clarification of Service-Selection AVP encoding CP-090532 0143 1 User to HSS identity resolution for Diameter Proxy Agents CP-090532 0144 - RFSP coding 2009-09 CT#45 CP-090556 0122 3 Optimization of Subscriber Data Update 9.0.0 CP-090562 0131 Emergency Support in S6a 2009-12 CT#46 CP-091030 0148 4 Clarification on Some Subscription Data List Handling in MME/SGSN 9.1.0 CP-090793 0149 1 APN level APN-OI-Replacement CP-090800 0150 2 ICS-Flag CP-090767 0152 2 RFSP alignment in 29.272 CP-090801 0153 1 Notify Request for Emergency Attached UEs CP-090767 0155 2 Wildcard APN CP-090767 0157 1 Lifetime of Charging Characteristics after Change CP-091030 0159 2 Correction on the UE initiated detach procedure CP-090767 0163 2 FQDN for S6a NOR CP-090767 0165 - HPLMN-ODB AVP correction CP-091032 0167 From GMLC-Address to GMLC-Number CP-091030 0171 1 Static PDN GW CP-091030 0177 1 Clarification on Usage of Re-Synchronization-Info AVP CP-091030 0179 1 Clarification on the Number of PDP-Contexts in the GPRS-Subscription-Data AVP CP-090767 0185 - APN-Configuration-Profile usage in IDR CP-091030 0187 2 IMEI encoding CP-091030 0189 1 APN-Configuration Service-Selection values CP-091030 0191 1 QoS attributes CP-090789 0196 1 Subscription-Data clarification for UE Reachability CP-091030 0198 2 Vendor Specific Application ID CP-090776 0200 1 Destination Realm CP-090767 0202 - Correction to fault recovery procedure and ME identity check procedure CP-090767 0204 - Reference of 3GPP-Charging-Characteristics CP-090767 0206 - Reset procedure MME/SGSN behavior 2010-03 CT#47 CP-100020 0181 2 Correction to Purge UE Detailed Behaviour 9.2.0 CP-100020 0210 HPLMN ODB CP-100048 0211 2 TADS support in S6a/S6d CP-100020 0217 Cancellation-Type clarifications CP-100020 0219 1 IETF References update CP-100020 0221 Static PDN GW CP-100046 0222 1 Addition of V-GMLC address for S6a CP-100020 0223 1 Handling of UE Reachability MME Parameter CP-100020 0227 Indication of PLMN ID of the selected PGW CP-100040 0228 Context-Identifier in NOR CP-100235 0230 5 EPS Subscriber State and Location Information Request CP-100040 0233 1 Reset to Combined MME/SGSN CP-100040 0234 1 NOR-Flags correction CP-100040 0236 2 Indication of LCS Capabilities support over S6a/S6d CP-100040 0238 1 Fix ambiguity on context id AVP 2010-06 CT#48 CP-100264 0241 1 Service-Selection values 9.3.0 0243 1 MIP6-Agent-Info 0245 2 Fix ambiguity on usage of the Supported-Features AVP 0260 1 Correction of Context-Identifier CP-100277 0247 1 Dynamic information update after a Reset procedure 0248 1 Notify command from unknown MME CP-100416 0249 4 S6a Error Codes CP-100279 0258 3 URRP for SGSN CP-100265 0262 3 MME mapping between Diameter error codes and NAS Cause Code values 2010-09 CT#49 CP-100456 0268 1 Restoration of the SGSN Number in the VLR 9.4.0 CP-100457 0272 QoS-Subscribed CP-100457 0273 Trace-Reference AVP encoding CP-100457 0284 Usage of MIP-Home-Agent-Host AVP CP-100457 0285 Correction on HSS behaviour about IMEI CP-100577 0275 2 NAS Cause Code values CP-100463 0276 LCS Privacy Features for MME CP-100443 0281 2 Correction to Delete Subscriber Data for SGSN CP-100443 0283 1 Unclear Cancel-Type Setting for Single Registration and Initial Attach 2010-09 CT#49 CP-100465 0267 1 Addition of SIPTO permissions in PS subscription data 10.0.0 2010-10 CT#50 CP-100689 0324 1 HSS Error Returned due to ODB 10.1.0 CP-100689 0316 1 Clarification on Access Restriction Data CP-100698 0297 1 Removal of Notify Messages during detach or last PDN connection deactivation via 3GPP access CP-100679 0303 1 Usage of Served Party IP Address AVP inside the APN Configuration CP-100679 0305 1 Usage of APN-OI-Replacement AVP CP-100679 0307 AMBR clarification CP-100679 0308 Store HSS Identity in MME/SGSN after successful ULA CP-100679 0315 3 Fix ambiguity in the LCS related indication CP-100679 0327 2 Unknown EPS Subscription CP-100688 0325 1 Periodic TAU/RAU timer in HSS subscription CP-100707 0313 1 Correction of Restoration flag CP-100707 0319 Default APN and Wildcard APN CP-100707 0322 1 Usage of PGW Allocation Type AVP CP-100699 0323 Usage of STN-SR AVP CP-100699 0291 3 Enhanced SRVCC CP-100687 0290 4 Addition of MPS Priority in Subscription Data CP-100683 0289 1 Addition of LIPA permission in Subscription Data CP-100684 0288 1 SIPTO Permission for Wildcard APN 2011-03 CT#51 CP-110087 0329 2 Minimization of Drive Tests (MDT) 10.2.0 CP-110042 0330 2 Feature Flags for UE Reachability Notification and State/Location Info Retrieval CP-110042 0337 3 Correction of error cause handling CP-110042 0339 2 Setting of M bit AVP flag CP-110042 0343 1 AMBR Correction CP-110073 0332 2 Correction on PGW PLMN ID CP-110088 0334 2 Relay Node Indicator CP-110051 0346 1 PDP Address correction CP-110051 0351 2 Ambiguity in IDR flags CP-110051 0353 Homogeneous Support for IMS Voice over PS AVP missing 2011-06 CT#52 CP-110351 0362 SGSN-Number AVP correction 10.3.0 CP-110380 0357 2 MDT user consent CP-110375 0363 1 Purge from Combined MME/SGSN 2011-09 CT#53 CP-110562 0372 1 Active-APN AVP definition 10.4.0 CP-110562 0374 Context-Identifier when interworking with GTPv1 CP-110562 0380 1 APN-AMBR for GPRS CP-110565 0377 Correction on DIAMETER_AUTHORIZATION_REJECTED CP-110699 0381 Correction of implementation error in TSÊ29.272, CR 324 2011-09 CT#53 CP-110581 0369 2 Behaviour of HSS in abnormal case of Immediate-Response-Preferred AVP 11.0.0 CP-110584 0370 3 Add vSRVCC updates to the S6a interface 2011-12 CT#54 CP-110787 0390 1 Unknown EPS Subscription over S6d/S6a 11.1.0 CP-110811 0387 2 Equivalent PLMN CSG Subscription Request CP-110787 0397 1 M-bit Handling 2012-03 CT#55 CP-120023 0409 1 GMLC-Number format 11.2.0 CP-120025 0399 3 Initial Attach Indication in CLR CP-120029 0406 T-ADS data request for detached UE CP-120029 0410 1 Removal of Subscribed Periodic TAU/RAU timer in HSS subscription CP-120037 0400 Clarification on UE-SRVCC-Capability AVP in ULR CP-120037 0402 ODB clarification CP-120037 0403 2 S6a location reporting 2012-06 CT#56 CP-120240 0401 3 CSG ID and Local Time for NPLI 11.3.0 CP-120413 0415 4 Ready for SM in MME CP-120249 0418 1 ULR handling for combined MME/SGSN CP-120249 0419 Clarification on Update of PGW ID 2012-09 CT#57 CP-120476 0382 10 VCSG procedures over S7a/S7d 11.4.0 CP-120476 0394 5 Delete CSG subscription Data over S7a /S7d CP-120476 0416 4 VCSG Reset procedure over S7a/S7d CP-120481 0404 5 PS additional number over S6a/S6d CP-120462 0421 - Single Registration Indication CP-120462 0422 - Zone Codes CP-120462 0423 - Clarification on Notification of UE Reachability CP-120462 0428 - CSG-Subscription-Data replacement CP-120462 0430 1 Update of Homogeneous Support of IMS Over PS Sessions CP-120462 0434 2 Mapping S6a and NAS cause code CP-120473 0429 4 SMS in MME CP-120473 0432 1 SMS in SGSN CP-120480 0433 2 Local Time Zone 2012-12 CT#58 CP-120722 0441 1 User-CSG-Information 11.5.0 CP-120713 0457 1 SGSN-Number AVP CP-120740 0436 1 Application ID for S7a/S7d CP-120740 0443 2 Empty VCSG Subscription Data CP-120742 0438 1 Notification Procedure clarification for UE with Emergency Bearer Services CP-120742 0445 - Inclusion of APN-OI Replacement in PDP Context CP-120742 0450 - Correction in the chapter of Reset-Answer (RSA) command CP-120742 0452 1 UE Time Zone CP-120742 0453 1 Corrections to Local Time Zone CP-120742 0454 2 Clarification on IDR-Flags CP-120742 0455 - Correction of General Description of Delete Subscriber Data CP-120742 0458 - DSR-Flags CP-120742 0461 1 Wrong implementation of the Daylight-Saving-Time AVP CP-120736 0446 1 A-MSISDN Correction CP-120732 0447 1 MME network condition to NAS cause code mapping CP-120732 0448 2 SGSN network condition to NAS cause code mapping CP-120732 0449 3 MME de-registration for ""SMS in MME"" CP-120732 0451 1 Correction on Update Location Request CP-120732 0459 1 Alignment of stage 3 SMS in MME with stage 2 CP-120741 0460 1 Use of Flag instead of Enumerated AVPs 2013-03 CT#59 CP-130022 0466 - Corrections to wrong references and command/AVP name 11.6.0 CP-130022 0467 1 Update to Subscription-Data-Flags CP-130022 0471 1 Values not allowed for QCI over S6a/S6d CP-130022 0472 1 Cause Code Mapping CP-130022 0470 1 Registration for SMS Request for SMS in SGSN CP-130025 0474 - MDT parameters 2013-03 CT#59 CP-130031 0442 3 Check of Serving Node for S6a Security 12.0.0 CP-130031 0468 1 MME name encoding over S6a CP-130156 0475 1 SGSN indicating support of Lgd interface to HSS 2013-06 CT#60 CP-130380 0490 1 Removal of SMS-Only AVP and Typo Corrections on Some AVP Definitions 12.1.0 CP-130380 0501 2 MME identity for restoration procedures CP-130380 0492 1 Definition of A New Feature-List CP-130380 0488 1 UE-SRVCC-Capability Update Clarification CP-130380 0483 - Reset clarification CP-130380 0481 2 AIR rejection CP-130380 0479 1 Storing Last known Location Information of purged UE in HSS CP-130380 0512 1 Maximum value for the subscribed periodic RAU TAU timer CP-130279 0497 1 Definition of SS Status for Call Barring CP-130378 0489 2 SIPTO permission for Local Network enhancements CP-130288 0487 - PS Location Info request with RAT-type CP-130309 0482 - CSS clarification CP-130295 0478 - Restoration Priority during SGW and PGW restoration procedures CP-130410 0508 1 HSS handling of T-ADS for detached subscriber 2013-09 CT#61 CP-130444 0515 - Correction to the restoration priority levels during SGW and PGW restoration procedures 12.2.0 CP-130450 0517 - HPLMN-ODB Correction CP-130463 0518 2 CancelLocation requesting reattach CP-130456 0519 1 Indication of Gdd support over S6d CP-130461 0520 2 Homogeneous Support Of Voice over IP CP-130461 0521 1 Definition of User-State values CP-130461 0522 1 Context Identifier Range Inconsistency 2013-12 CT#62 CP-130611 0528 1 Addtion of S6aS6d-Indicator in NOR 12.3.0 CP-130617 0533 1 MME Initiated Removal of MME Registration for SMS CP-130624 0523 1 Combined MME/SGSN indicating the support for optimized LCS procedure CP-130624 0526 1 Clarification on Description of Features for LCS CP-130644 0525 1 SMS in MME CP-130623 0529 1 Alert Service Center sent over S6c CP-130632 0530 1 Purge Clarification CP-130639 0531 1 SGSN CAMEL Subscription Indication 2014-03 CT#63 CP-140035 0534 2 Clarification on Current-Location-Retrieved and Age-of-Location-Information 12.4.0 CP-140035 0536 3 Mechanism to determine if the UE is served by the MME and SGSN parts of the same combined MME/SGSN CP-140035 0537 - Call-Barring-Info AVP CP-140035 0538 - Missing SGs-MME-Identity AVP in the ULR 2014-06 CT#64 CP-140257 0544 1 SS-Status AVP Definition 12.5.0 CP-140264 0555 3 Cause Mapping for ODB CP-140264 0556 2 NOR Error User Unknown CP-140254 0557 1 Enhancement for ProSe CP-140413 0558 - Correction on SGSN CAMEL Capability in Supported-Features CP-140243 0540 5 Diameter overload control mechanism CP-140243 0559 1 Diameter overload over S6a/d 2014-09 CT#65 CP-140523 0564 2 Clarification on ProSe Subscription Data 12.6.0 CP-140514 0565 2 WLAN offloadability defined in HSS CP-140506 0567 2 P-CSCF Restoration Indication 2014-12 CT#66 CP-140772 0569 2 Reset-ID 12.7.0 CP-140772 0581 3 M-bit setting of Supported-Features AVP CP-140764 0571 - MDT PLMN List CP-140764 0580 1 S6a/S6d-Indicator in NOR CP-140790 0575 1 Priority Consideration for Diameter Overload Control 2014-12 CT#66 CP-140765 0574 2 Roaming Subscription Corresponding to Specific RAT 13.0.0 CP-140759 0578 2 Stored HSS Identity for HSS Restoration Procedure 2015-03 CT#67 CP-150035 0582 1 Clarification on the usage of SV in IMEI check procedure 13.1.0 2015-06 CT#68 CP-150265 0583 1 Cleanup and small error corrections 13.2.0 CP-150263 0584 2 Access Restriction Data per PLMN CP-150279 0585 1 Alignment of using ProSe and ProSe services 2015-09 CT#69 CP-150427 0597 - Wrong Application-ID for S7a Diameter Application 13.3.0 CP-150454 0586 3 Subscription data for extended buffering at the SGW CP-150453 0587 2 Introducing IMSI-Group ID Lists to the subscription Info CP-150449 0588 3 Addition of CP parameters to subscription data 2015-12 CT#70 CP-150778 0590 9 Add MTC Monitoring support 13.4.0 CP-150778 0606 1 Roaming and interaction with the IWK-SCEF CP-150778 0607 4 Introducing a Bitmask to inform the HSS of the Monitoring capabilities of the MME/SGSN CP-150778 0609 2 Deletion of all Monitoring events assigned to a subscriber (UE) CP-150785 0598 1 DL-Buffering-Suggested-Packet-Count AVP CP-150781 0600 1 Retrieval of ""UE Usage Type"" over S6a/S6d CP-150762 0601 1 Clarification of precedence between UE-level ""HO to non-3GPP access"" access restriction, and APN-level ""WLAN-Offloadability"" CP-150768 0602 4 Diameter message priority over S6a/d CP-150771 0604 2 Introduction of validity time delete and replace procedure for CP sets CP-150755 0611 1 ProSe in combined MME/SGSN CP-150744 0614 Erroneous AVP code for some MDT parameters CP-150759 0614 1 Update reference to DOIC new IETF RFC CP-150776 0615 1 Mobile Terminating SMS handling for extended Idle mode DRX 2016-03 CT#71 CP-160029 0618 2 Notifying the status of MONTE event configuration at the IWK-SCEF to the HSS 13.5.0 CP-160043 0619 1 Fix the issue on HSS restart procedure CP-160039 0620 1 User Plane Integrity Protection Indicator CP-160029 0621 3 Configure Monitoring Event to Multiple Serving Nodes CP-160033 0623 1 Allow SMS for NB-IoT UE without Combined Attach CP-160045 0625 - Adjacent PLMNs CP-160045 0626 1 Invocation of Alert procedure by HSS after ULR CP-160023 0629 1 Diameter message priority over S7a/d, S13, S13' CP-160033 0630 2 Addition of NB-IoT radio access type to the Access-Restriction-Data feature CP-160033 0631 3 New PDN-Type for Cellular IoT 2016-03 Table 7.3.1/1 formatted 13.5.1 2016-06 CT#72 CP-160215 0643 1 Diameter requests for priority traffic during overload control mechanism 13.6.0 2016-06 CT#72 CP-160238 0628 3 Subscription Data for combined MME/SGSN 13.6.0 2016-06 CT#72 CP-160238 0632 1 Cause Mapping 13.6.0 2016-06 CT#72 CP-160238 0633 - Correction on Service-Selection 13.6.0 2016-06 CT#72 CP-160238 0639 2 Group-Service-Id 13.6.0 2016-06 CT#72 CP-160233 0635 - Renaming of Validity-Time AVP 13.6.0 2016-06 CT#72 CP-160228 0636 - Update SMS Support for NB-IoT 13.6.0 2016-06 CT#72 CP-160225 0637 2 SCEF realm 13.6.0 2016-06 CT#72 CP-160222 0638 2 Shared Subscription data update 14.0.0 2016-06 CT#72 CP-160217 0640 1 Support for Non-IP PDP types 14.0.0 2016-06 CT#72 CP-160221 0641 1 MSISDN Removal from Subscription Profile 14.0.0 2016-09 CT#73 CP-160423 0645 - PDN-Connection-Restricted flag 14.1.0 2016-09 CT#73 CP-160423 0647 1 Preferred Data Mode for an SGi PDN connection 14.1.0 2016-09 CT#73 CP-160428 0652 - CR implementation error on ECR and ECA commands 14.1.0 2016-09 CT#73 CP-160426 0658 2 Current Location Retrieval 14.1.0 2016-09 CT#73 CP-160437 0649 1 Removal of Editor's Note on non shareable subscription data 14.1.0 2016-09 CT#73 CP-160437 0650 - Removal of Editor's Note on detailed checks for shared subscription data update 14.1.0 2016-09 CT#73 CP-160437 0656 2 Solution to avoid high load resulting from shared subscription data update 14.1.0 2016-09 CT#73 CP-160433 0653 - Change of Network Access Mode 14.1.0 2016-09 CT#73 CP-160432 0654 - Usage of Supported Features 14.1.0 2016-09 CT#73 CP-160432 0655 - Handling of MSISDN removal from subscription profile 14.1.0 2016-12 CT#74 CP-160679 0659 4 Handover of Emergency PDN Connections 14.2.0 2016-12 CT#74 CP-160673 0660 1 Reset-ID AVP description for shared subscription data update 14.2.0 2016-12 CT#74 CP-160673 0671 1 Update of ""Homogeneous Support"" Status 14.2.0 2016-12 CT#74 CP-160673 0684 1 Missing S7a/S7d application identifier 14.2.0 2016-12 CT#74 CP-160654 0662 1 Communication-Pattern Feature 14.2.0 2016-12 CT#74 CP-160681 0666 1 Load Control 14.2.0 2016-12 CT#74 CP-160681 0677 1 Host Load 14.2.0 2016-12 CT#74 CP-160665 0668 1 Dynamic Removal of UE Usage Type 14.2.0 2016-12 CT#74 CP-160665 0674 1 Presence of UE Usage Type in Error Responses 14.2.0 2016-12 CT#74 CP-160657 0670 1 Undefined Bits in Access Restriction Data 14.2.0 2016-12 CT#74 CP-160678 0672 1 Add V2X Subscription Data to S6a Interface 14.2.0 2016-12 CT#74 CP-160664 0682 - Correction to change IETF drmp draft version to official RFC 7944 14.2.0 2016-12 CT#74 CP-160660 0683 1 Deletion of all monitoring events 14.2.0 2017-03 CT#75 CP-170028 0692 1 Maximum Response Time 14.3.0 2017-03 CT#75 CP-170039 0687 1 Enhanced Coverage 14.3.0 2017-03 CT#75 CP-170039 0688 1 Inter-RAT PDN-Continuity 14.3.0 2017-03 CT#75 CP-170044 0693 1 Emergency-Info AVP in ULA 14.3.0 2017-03 CT#75 CP-170043 0696 1 Correct UE-PC5-AMBR Format 14.3.0 2017-03 CT#75 CP-170036 0697 2 Removal of complete APN Configuration Profile 14.3.0 2017-03 CT#75 CP-170036 0698 1 Clarification of MDT User Consent 14.3.0 2017-03 CT#75 CP-170036 0699 1 Missing M/O values in several feature flags 14.3.0 2017-03 CT#75 CP-170036 0700 2 Subscription parameters for eDRX 14.3.0 2017-03 CT#75 CP-170036 0701 2 Support of long and short Macro eNodeB IDs 14.3.0 2017-03 CT#75 CP-170048 0704 - Update of reference for the Diameter base protocol 14.3.0 2017-03 CT#75 CP-170048 0705 - Handling of the Vendor-Specific-Application-Id AVP 14.3.0 2017-03 CT#75 CP-170048 0706 - Cardinality of the Failed-AVP AVP in answer 14.3.0 2017-06 CT#76 CP-171029 0707 1 External Identifier in Subscription-Data 14.4.0 2017-06 CT#76 CP-171021 0709 - Alignment of PDN-Connection-Restricted Flag handling on NAS specification 14.4.0 2017-06 CT#76 CP-171017 0713 1 Add MBSFN Area List to MDT Configuration parameters 14.4.0 2017-06 CT#76 CP-171184 0715 2 Communication Patterns without Expiry Time 14.4.0 2017-06 CT#76 CP-171029 0717 1 Loss Of Connectivity Reason in S6a/d IDA 14.4.0 2017-06 CT#76 CP-171018 0720 1 Support for signaling transport level packet marking 14.4.0 2017-06 CT#76 CP-171043 0718 1 Clarification of S6a/Notification-Request command for non-IP APNs 15.0.0 2017-06 CT#76 CP-171041 0721 - Removal of UE-Usage-Type 15.0.0 2017-09 CT#77 CP-172027 0727 1 Access Restriction to NR as Secondary RAT 15.1.0 2017-09 CT#77 CP-172027 0728 1 Extended QoS for 5G NR 15.1.0 2017-09 CT#77 CP-172018 0729 1 Acknowledgements of downlink NAS data PDUs 15.1.0 2017-09 CT#77 CP-172018 0730 1 Reliable Data Service 15.1.0 2017-09 CT#77 CP-172026 0731 1 Enhancements for NAPS on Idle Status Indication 15.1.0 2017-09 CT#77 CP-172013 0736 - Correction of DRMP Procedures 15.1.0 2017-12 CT#78 CP-173016 0743 1 Correction on subscribed eDRX parameter value 15.2.0 2017-12 CT#78 CP-173028 0740 1 Clarification of UE Reachability monitoring event over S6a/S6d 15.2.0 2017-12 CT#78 CP-173025 0741 - Error in the DIAMETER_ERROR_EQUIPMENT_UNKNOWN name 15.2.0 2017-12 CT#78 CP-173025 0744 3 Active Time in Insert Subscriber Data 15.2.0 2017-12 CT#78 CP-173035 0746 1 Access restriction to unlicensed spectrum as secondary RAT 15.2.0 2017-12 CT#78 CP-173036 0747 1 Access Restrictions to NR as Secondary RAT on MM Context 15.2.0 2018-03 CT#79 CP-180013 0755 2 Handling of Homogenous-Support-of-IMS-Voice-Over-PS-Sessions AVP 15.3.0 2018-03 CT#79 CP-180021 0756 - Service Gap Time 15.3.0 2018-03 CT#79 CP-180025 0757 1 Filtering the Report for Number of UEs in a Geographic Area 15.3.0 2018-06 CT#80 CP-181122 0758 - Bandwidth Clarification 15.4.0 2018-06 CT#80 CP-181122 0759 1 Supported-Services AVP code 15.4.0 2018-06 CT#80 CP-181122 0762 1 Subscription for Aerial UE in 3GPP system 15.4.0 2018-06 CT#80 CP-181124 0765 1 Subscription data for ciphering keys 15.4.0 2018-06 CT#80 CP-181133 0763 1 Access Restrictions 15.4.0 2018-09 CT#81 CP-182077 0766 - Update of Broadcast-Location-Assistance-Data-Types AVP 15.5.0 2018-09 CT#81 CP-182067 0767 2 Access Restriction Data for NR as Secondary RAT not supported by HSS 15.5.0 2018-09 CT#81 CP-182067 0774 - Applicable values for AMBR 15.5.0 2018-09 CT#81 CP-182075 0768 1 Handling of monitoring events in ULA 15.5.0 2018-09 CT#81 CP-182072 0769 1 Subscribed PTW length 15.5.0 2018-09 CT#81 CP-182072 0770 1 DSR-Flag for Active-Time 15.5.0 2018-09 CT#81 CP-182071 0771 2 DSR-Flag for eDRX-Cycle-Length 15.5.0 2018-09 CT#81 CP-182084 0773 - Access Restrictions 15.5.0 2018-12 CT#82 CP-183092 0775 4 Single Registration 15.6.0 2018-12 CT#82 CP-183092 0776 1 Interworking with 5GS indicator in APN Subscription 15.6.0 2018-12 CT#82 CP-183092 0789 2 MME_UPDATE_PROCEDURE 15.6.0 2018-12 CT#82 CP-183098 0785 1 Deletion of monitoring events when unknown in SCEF 15.6.0 2018-12 CT#82 CP-183098 0786 - Event configuration failure in ULA 15.6.0 2018-12 CT#82 CP-183098 0787 1 Idle-Status-Indication is missing in monitoring event report 15.6.0 2018-12 CT#82 CP-183098 0788 1 Applicability of Maximum Number of Reports 15.6.0 2018-12 CT#82 CP-183100 0784 3 Behavior of MME/SGSN upon reception of DIAMETER_UNABLE_TO_COMPLY for NOR 15.6.0 2018-12 CT#82 CP-183100 0790 1 Paging Time Window 15.6.0 2019-03 CT#83 CP-190034 0791 1 eDRX AVPs 15.7.0 2019-03 CT#83 CP-190038 0792 - Missing Maximum-UE-Availability-Time AVP 15.7.0 2019-03 CT#83 CP-190034 0794 1 Access Restriction to NR as Secondary RAT for SGSN 15.7.0 2019-03 CT#83 CP-190034 0795 - Paging-Time-Window AVP name 15.7.0 2019-03 CT#83 CP-190037 0796 1 Handling of multiple external IDs for the same UE 15.7.0 2019-06 CT#84 CP-191023 0797 - Service Gap Time Deletion 15.8.0 2019-09 CT#85 CP-192094 0804 2 draft-ietf-dime-load published as RFC 8583 15.9.0 2019-09 CT#85 CP-192121 0801 1 Communication pattern enhancement 16.0.0 2019-09 CT#85 CP-192122 0800 1 Event type PDN Connectivity Status 16.0.0 2019-09 CT#85 CP-192122 0802 - Ethernet PDN Type 16.0.0 2019-12 CT#86 CP-193024 0808 - Applicability of Core Network Restrictions 16.1.0 2019-12 CT#86 CP-193038 0809 1 Subscribed ARPI 16.1.0 2019-12 CT#86 CP-193038 0810 - LTE-M Access Restriction 16.1.0 2019-12 CT#86 CP-193038 0812 - Missing protocol code-point values 16.1.0 2019-12 CT#86 CP-193052 0807 1 Battery Indication for Communication pattern enhancement 16.1.0 2020-03 CT#87e CP-200027 0813 1 Addition of IAB-Operation-Permission to subscriber data 16.2.0 2020-03 CT#87e CP-200036 0814 1 Subscription data for NR V2X 16.2.0 2020-06 CT#88e CP-201053 0815 - Alignments on definitions 16.3.0 2020-06 CT#88e CP-201053 0816 - Supported Monitoring Events 16.3.0 2020-06 CT#88e CP-201053 0818 - Error cause handling 16.3.0 2020-06 CT#88e CP-201053 0819 1 Update of RAT restrictions 16.3.0 2020-06 CT#88e CP-201053 0821 1 Supported Features for combined MME/SGSN 16.3.0 2020-06 CT#88e CP-201049 0817 1 Subscribed PC5 QoS Parameters for NR V2X 16.3.0 2020-06 CT#88e CP-201033 0820 1 SGSN Interworking with 5G 16.3.0 2020-09 CT#89e CP-202109 0822 2 Monitoring Configurations in ULA 16.4.0 2020-09 CT#89e CP-202094 0823 - Immediate Event Report in IDA 16.4.0 2020-09 CT#89e CP-202094 0824 1 Corrections on Broadcast-Location-Assistance-Data-Types 16.4.0 2020-12 CT#90e CP-203032 0826 - Extended Reference ID 16.5.0 2020-12 CT#90e CP-203032 0825 1 Correction for implementation error 16.5.0 2021-03 CT#91e CP-210057 0828 - Default APN for Ethernet PDN types 16.6.0 2021-03 CT#91e CP-210053 0829 2 Cancellation Type for UDICOM 16.6.0 2021-03 CT#91e CP-210027 0827 1 Use of inclusive terminology 17.0.0 2021-09 CT#93e CP-212053 0830 - F Superfluous AVPs in re-used Diameter AVPs table 17.1.0 2022-03 CT#93e CP-220063 0832 - F Removal of Monitoring Events when External ID or MSISDN is deleted 17.1.0 2022-03 CT#93e CP-220093 0831 1 B Access Restriction for IoT Satellite Access 17.2.0 2022-06 CT#96 CP-221060 0834 - F Clarification on Withdrawal of eDRX Cycle Length 17.3.0 2022-06 CT#96 CP-221060 0836 1 F Withdrawal of Paging Time Window Subscription 17.3.0 2022-06 CT#96 CP-221060 0837 1 F Emergency service session continuity 17.3.0 2022-06 CT#96 CP-221066 0840 - A CR 0828 has not been correctly implemented 17.3.0 2022-09 CT#97e CP-222073 0842 2 F Update ULR flags in support of handover 17.4.0 2023-03 CT#99 CP-230054 0843 - F Skip Subscriber Data in ULR-Flags 18.0.0 2023-06 CT#100 CP-231063 0844 - F Reachability Cause in immediate reports 18.1.0 2023-12 CT#102 0847 1 A Preventing LTE to NR NTN handover for users without NR NTN subscription 18.2.0 3GPP TS 29.272 V18.2.0 (2023-12) 168 Release 18 3GPP 3GPP TS 29.272 V18.2.0 (2023-12) 14 Release 18 3GPP 3GPP TS 29.228 V17.1.0 (2022-03) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP Multimedia (IM) Subsystem Cx and Dx interfaces; Signalling flows and message contents (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2022, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 7 1 Scope 8 2 References 8 3 Definitions, symbols and abbreviations 9 3.1 Definitions 9 3.2 Abbreviations 10 4 Main Concept 11 5 General Architecture 11 5.1 Functional requirements of network entities 11 5.1.1 Functional requirements of P-CSCF 11 5.1.2 Functional requirements of I-CSCF 11 5.1.3 Functional requirements of S-CSCF 11 5.1.4 Functional requirements of HSS 11 5.1.5 Functional classification of Cx interface procedures 11 5.1.6 Functional Requirements of the Presentity Presence Proxy 12 6 Procedure Descriptions 12 6.1 Location management procedures 13 6.1.1 User registration status query 13 6.1.1.1 Detailed behaviour 14 6.1.2 S-CSCF registration/deregistration notification 16 6.1.2.1 Detailed behaviour 20 6.1.3 Network initiated de-registration by the HSS, administrative 25 6.1.3.1 Detailed behaviour 26 6.1.4 User location query 28 6.1.4.1 Detailed behaviour 29 6.2 User data handling procedures 30 6.2.1 User Profile download 30 6.2.2 HSS initiated update of User Information 30 6.2.2.1 Detailed behaviour 32 6.3 Authentication procedures 33 6.3.1 Detailed behaviour 36 6.4 User identity to HSS resolution 37 6.5 Implicit registration 38 6.5.1 S-CSCF initiated procedures 38 6.5.1.1 Registration 38 6.5.1.2 De-registration 38 6.5.1.3 Authentication 38 6.5.1.4 Downloading the user profile 38 6.5.1.5 Initiation of a session to a non-registered user 39 6.5.2 HSS initiated procedures 39 6.5.2.1 Update of User Profile 39 6.5.2.2 De-registration 39 6.5.2.3 Update of the Charging information 39 6.5.2.4 Update of the SIP Digest Authentication Data 39 6.5.2.5 Update of the Allowed WAF and/or WWSF Identities 40 6.6 Download of the Relevant User Profile and Charging Information and Allowed WAF and/or WWSF Identities 40 6.6.1 HSS initiated update of User Profile 40 6.6.2 S-CSCF operation 40 6.7 S-CSCF Assignment 40 7 Information element contents 43 7.1 Visited Network Identifier 43 7.2 Public User Identity 43 7.2a Public Service Identity 43 7.2b Wildcarded Public Identity 43 7.2c Void 43 7.3 Private User Identity 43 7.3a Private Service Identity 43 7.4 S-CSCF Name 43 7.4a AS Name 43 7.5 S-CSCF Capabilities 44 7.6 Result 44 7.7 User Profile 44 7.8 Server Assignment Type 44 7.9 Authentication Data 44 7.9.1 Item Number 44 7.9.2 Authentication Scheme 44 7.9.3 Authentication Information 44 7.9.4 Authorization Information 44 7.9.5 Confidentiality Key 44 7.9.6 Integrity Key 45 7.9.7 Authentication Context 45 7.9.8 Digest Authenticate 45 7.9.8.1 Digest Realm 45 7.9.8.2 Void 45 7.9.8.3 Digest Algorithm 45 7.9.8.4 Digest QoP 45 7.9.8.5 Digest HA1 45 7.9.8.6 Alternate Digest Algorithm 45 7.9.8.7 Alternate Digest HA1 45 7.9.9 Line Identifier 45 7.9.10 Framed IP Address 46 7.9.11 Framed IPv6 Prefix 46 7.9.12 Framed Interface Id 46 7.10 Number Authentication Items 46 7.11 Reason for de-registration 46 7.12 Charging information 46 7.13 Routing information 46 7.14 Type of authorization 46 7.15 Void 46 7.16 User Data Already Available 46 7.17 Associated Private Identities 46 7.18 Originating-Request 46 7.19 User Authorization Request Flags 47 7.20 Loose-Route Indication 47 7.21 S-CSCF Restoration Information 47 7.22 Associated Registered Private Identities 47 7.23 Multiple Registration Indication 47 7.24 Session-Priority 47 7.25 Identities with Emergency Registration 47 7.26 Priviledged-Sender Indication 47 7.27 LIA Flags 47 7.28 Server Assignment Request Flags 47 7.29 Allowed WAF and/or WWSF Identities 48 7.30 RTR Flags 48 7.31 Failed-PCSCF 48 8 Error handling procedures 48 8.1 Registration error cases 48 8.1.1 Cancellation of the old S-CSCF 48 8.1.2 Error in S-CSCF name 49 8.1.3 Error in S-CSCF assignment type 49 9 Protocol version identification 49 10 Operational Aspects 49 Annex A (normative): Mapping of Cx operations and terminology to Diameter 50 A.1 Introduction 50 A.2 Cx message to Diameter command mapping 50 A.3 Cx message parameters to Diameter AVP mapping 50 A.4 Message flows 51 A.4.1 RegistrationÐ user not registered 52 A.4.2 Registration Ð user currently registered 53 A.4.3 UE initiated de-registration 53 A.4.4 Network initiated de-registration 54 A.4.4.1 Registration timeout 54 A.4.4.2 Administrative de-registration 54 A.4.4.3 De-registration initiated by service platform 55 A.4.5 UE Terminating SIP session set-up 55 A.4.6 Initiation of a session to a non-registered user 56 A.4.6a AS originating session on behalf of a non-registered user 56 A.4.7 User Profile update 57 Annex B (informative): User profile UML model 58 B.1 General description 58 B.2 Service profile 58 B.2.1 Public Identification 59 B.2.1A Core Network Service Authorization 61 B.2.2 Initial Filter Criteria 62 B.2.3 Service Point Trigger 63 Annex C (informative): Conjunctive and Disjunctive Normal Form 65 Annex D (informative): High-level format for the User Profile 68 Annex E (normative): XML schema for the Cx interface user profile 69 Annex F (normative): Definition of parameters for service point trigger matching 74 Annex G (normative): Emergency registrations 74 Annex H (normative): Diameter overload control mechanism 75 H.1 General 75 H.2 HSS behaviour 75 H.3 I/S-CSCF behaviour 75 Annex I (Informative): Diameter overload node behaviour 76 I.1 Message prioritization 76 Annex J (normative): Diameter message priority mechanism 76 J.1 General 76 J.2 Cx/Dx interfaces 76 J.2.1 General 76 J.2.2 S-CSCF/I-CSCF behaviour 76 J.2.3 HSS/SLF behaviour 77 J.2.4 Interactions 77 Annex K (normative): Diameter load control mechanism 78 K.1 General 78 K.2 HSS behaviour 78 K.3 I-CSCF/S-CSCF behaviour 78 Annex L (informative): Change history 79 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope This 3GPP Technical Specification (TS) specifies: 1. The interactions between the HSS (Home Subscriber Server) and the CSCF (Call Session Control Functions), referred to as the Cx interface. 2. The interactions between the CSCF and the SLF (Server Locator Function), referred to as the Dx interface. 3. The interactions between the SIP Core and the SIP database, referred to as the Cx interface, for the Mission Critical Services, where this interface is named as AAA-1, as described in 3GPPÊTSÊ23.280Ê[30]. NOTE: In the 3GPPÊTSÊ23.280Ê[30] the term SIP database is used for the HSS and the term SIP Core is used for the P-CSCF, the I-CSCF and the S-CSCF when compared to this specification. The IP Multimedia (IM) Subsystem stage 2 is specified in 3GPPÊTSÊ23.228Ê[1] and the signalling flows for the IP multimedia call control based on SIP and SDP are specified in 3GPPÊTSÊ24.228Ê[2]. This document addresses the signalling flows for Cx and Dx interfaces. This document also addresses how the functionality of Px interface is accomplished. The Presence Service Stage 2 description (architecture and functional solution) is specified in 3GPPÊTSÊ23.141Ê[10]."
"2 References [1] 3GPPÊTSÊ23.228: ""IP Multimedia (IM) Subsystem Ð Stage 2"". [2] 3GPPÊTSÊ24.228: ""Signalling flows for the IP multimedia call control based on SIP and SDP"". [3] 3GPPÊTSÊ33.203: ""Access security for IP-based services"". [4] 3GPPÊTSÊ23.002: ""Network architecture"". [5] 3GPPÊTSÊ29.229: ""Cx Interface based on Diameter Ð Protocol details"". [6] 3GPPÊTSÊ23.218: ""IP Multimedia (IM) Session Handling; IP Multimedia (IM) call model"". [7] IETFÊRFCÊ2045 ""Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies"". [8] 3GPPÊTSÊ24.229: ""IP Multimedia Call Control Protocol based on SIP and SDP"" Ð stage 3. [9] Void. [10] 3GPPÊTSÊ23.141: ""Presence Service; Architecture and Functional Description"". [11] IETFÊRFCÊ3261 ""SIP: Session Initiation Protocol"". [12] IETFÊRFCÊ4566 ""SDP: Session Description Protocol"". [13] IEEE 1003.1-2004, Part 1: Base Definitions. [14] IETFÊRFCÊ2486: ""The Network Access Identifier"". [15] IETFÊRFCÊ3966: ""The tel URI for Telephone Numbers"". [16] Void. [17] 3GPPÊTSÊ23.003: ""Numbering, addressing and identification"". [18] 3GPPÊTSÊ23.008: ""Organization of subscriber data"". [19] 3GPPÊTSÊ23.380: ""IMS Restoration Procedures"". [20] Void [21] IETFÊRFCÊ4005: ""Diameter Network Access Server Application"". [22] IETFÊRFCÊ4412: ""Communications Resource Priority for the Session Initiation Protocol (SIP)"". [23] 3GPPÊTSÊ23.167: ""IP Multimedia Subsystem (IMS) emergency sessions"". [24] IETFÊRFCÊ7683: ""Diameter Overload Indication Conveyance"". [25] 3GPPÊTSÊ22.153: ""Multimedia Priority Service"". [26] ANSI X3.4: ""Coded Character Set - 7-bit American Standard Code for Information Interchange"". [27] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [28] Void [29] IETFÊIETFÊRFCÊ8583: ""Diameter Load Information Conveyance"". [30] 3GPPÊTSÊ23.280: ""Common functional architecture to support mission critical services"". [31] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [32] 3GPPÊTSÊ24.323: ""3GPP IP Multimedia Subsystem (IMS) service level tracing management object (MO)"". [33] IETFÊRFCÊ7616: ""HTTP Digest Access Authentication"". 3 Definitions, symbols and abbreviations 3.1 Definitions For the purposes of the present document, the following terms and definitions given in TSÊ23.003Ê[17] apply: Distinct Public Service Identity Distinct Public User Identity Public Service Identity Public User Identity Wildcarded Public Service Identity Wildcarded Public User Identity For the purposes of the present document, the following terms and definitions apply. Common Part (of a user profile): Contains Initial Filter Criteria instances that should be evaluated both for registered and unregistered Public User Identities, or for unregistered Public Service Identities in the S-CSCF. Complete user profile: Contains the Initial Filter Criteria instances of all three different user profile parts; registered part, unregistered part and common part. IP Multimedia session: IP Multimedia session and IP Multimedia call are treated as equivalent in this specification. Authentication pending flag: A flag that indicates that the authentication of a Public User Identity - Private User Identity pair is pending and waiting for confirmation. Charging information: Data that is sent in the Charging-Information AVP. Allowed WAF and/or WWSF identities: A list of network addresses identifying WebRTC Authentication Functions (WAFs) and/or WebRTC Web Server Functions (WWSFs) allowed for a subscription. Implicitly registered Public User Identity set: A set of Public User Identities, which are registered and de-registered simultaneously when any of the Public User Identities belonging to that set is registered or de-registered. Not Registered State: Public Identity is not Registered and has no S-CSCF assigned. Private Identity: Either a Private User Identity or a Private Service Identity. Public Identity: Either a Public User Identity or a Public Service Identity. Registered Part (of a user profile): Contains Initial Filter Criteria instances that should be evaluated only for registered Public User Identities in the S-CSCF. iFCs from the registered part need not be evaluated when the Public Identity is unregistered. Registered State: Public User Identity is Registered at the request of the user and has an S-CSCF assigned. S-CSCF reassignment pending flag: A flag that is handled only when IMS Restoration Procedures are supported.and that indicates that the subscription may be reassigned to a new S-CSCF (i.e. the current S-CSCF is not responding) Unregistered part (of a user profile): Contains Initial Filter Criteria instances that should be evaluated only for unregistered Public Identities in the S-CSCF. iFCs from the unregistered part need not be evaluated when the Public User Identity is registered. Unregistered State: Public Identity is not Registered but has a serving S-CSCF assigned to execute Unregistered state services as a consequence of a terminating request, or an originating request from an AS on behalf of a user, or there is an S-CSCF keeping the user profile stored. User information: The user related data that the S-CSCF requests from the HSS or HSS pushes to the S-CSCF, e.g. user profile,charging information, allowed WAF and/or WWSF identities and authentication information. User profile: Data that is sent in the User-Data AVP. 3.2 Abbreviations For the purposes of the present document, the following abbreviations apply: AVP Attribute Value Pair C Conditional CSCF Call Session Control Function DRMP Diameter Routing Message Priority DSCP Differentiated Services Code Point GIBA GPRS-IMS-Bundled-Authentication HSS Home Subscriber Server IE Information Element IP Internet Protocol I-CSCF Interrogating CSCF IM IP Multimedia IMS IP Multimedia Subsystem M Mandatory MPS Multimedia Priority Service NASS Network Attachment SubSystem O Optional P-CSCF Proxy CSCF SIP Session Initiation Protocol SLF Server Locator Function S-CSCF Serving CSCF WAF WebRTC Authentication Function WWSF WebRTC Web Server Function 4 Main Concept This document presents the Cx interface related functional requirements of the communicating entities. It gives a functional classification of the procedures and describes the procedures and message parameters. Error handling flows, protocol version identification, etc. procedures are also included. 5 General Architecture This clause further specifies the architectural assumptions associated with the Cx reference point, building on TSÊ23.228Ê[1] and also the Px reference point building upon TSÊ23.141Ê[10]. 5.1 Functional requirements of network entities 5.1.1 Functional requirements of P-CSCF There is no requirement for the interaction between the P-CSCF and the HSS. 5.1.2 Functional requirements of I-CSCF The I-CSCF communicates with the HSS over the Cx interface. For functionality of the I-CSCF refer to TSÊ23.002Ê[4]. 5.1.3 Functional requirements of S-CSCF The S-CSCF communicates with the HSS over the Cx interface. For functionality of the S-CSCF refer to TSÊ23.002Ê[4]. 5.1.4 Functional requirements of HSS The HSS communicates with the I-CSCF and the S-CSCF over the Cx interface. For functionality of the HSS refer to TSÊ23.002Ê[4]. 5.1.5 Functional classification of Cx interface procedures Operations on the Cx interface are classified in functional groups: 1. Location management procedures - The operations regarding registration and de-registration. - Location retrieval operation. 2. User data handling procedures - The download of user information during registration and to support recovery mechanisms. - Operations to support the updating of user data and recovery mechanisms. 3. User authentication procedures 4. IMS Restoration Procedures (see TSÊ23.380Ê[19]) to support S-CSCF service interruption 5.1.6 Functional Requirements of the Presentity Presence Proxy The interaction between the Presentity Presence Proxy and the HSS, referred to as the Px interface, is handled using the mechanisms defined for the Cx interface. 6 Procedure Descriptions In the tables that describe the Information Elements transported by each command, each Information Element is marked as (M) Mandatory, (C) Conditional or (O) Optional in the Category ""Cat."" column. The application level specification overrides the ABNF defining the presence of the AVPs to be included in the Diameter commands. The category defined by the Information Element table shall always be the same, i.e. Optional; or more restrictive, i.e. Mandatory or Conditional, than the presence requirements defined by the ABNF syntax, e.g. a required AVP in the ABNF shall not be overridden by an Optional IE but an Optional AVP in the ABNF may be overridden by the Mandatory or Conditional IE Category. - A mandatory Information Element shall always be present in the command. If this Information Element is absent, an application error occurs at the receiver and an answer message shall be sent back to the originator of the request with the Result-Code set to DIAMETER_MISSING_AVP. This message shall also include a Failed-AVP AVP containing the missing Information Element i.e. the corresponding Diameter AVP defined by the AVP Code and the other fields set as expected for this Information Element. - A conditional Information Element (marked as (C) in the table) shall be present in the command if certain conditions are fulfilled. - If the receiver detects that those conditions are fulfilled and the Information Element is absent, an application error occurs and an answer message shall be sent back to the originator of the request with the Result-Code set to DIAMETER_MISSING_AVP. This message shall also include a Failed-AVP AVP containing the missing Information Element i.e. the corresponding Diameter AVP defined by the AVP Code and the other fields set as expected for this Information Element. - If those conditions are not fulfilled, the Information Element shall be absent. If however this Information Element appears in the message, it shall not cause an application error and it may be ignored by the receiver if this is not explicitly defined as an error case. Otherwise, an application error occurs at the receiver and an answer message with the Result-Code set to DIAMETER_AVP_NOT_ALLOWED shall be sent back to the originator of the request. A Failed-AVP AVP containing a copy of the corresponding Diameter AVP shall be included in this message. - An optional Information Element (marked as (O) in the table) may be present or absent in the command, at the discretion of the application at the sending entity. Absence or presence of this Information Element shall not cause an application error and may be ignored by the receiver. When a procedure is required to determine whether two S-CSCF names are equal, the rules for SIP URI comparison specified in RFC 3261 clauseÊ19.1.4 shall apply. When a procedure is required to determine the Public Identity used for an identity lookup in HSS and SLF, the HSS and SLF shall use the Public Identity from the SIP URI or Tel URI as contained in the Public-Identity AVP that is in canonical form as described by TSÊ23.003Ê[17]. Unknown permanent failure error codes shall be treated in the same way as DIAMETER_UNABLE_TO_COMPLY. For unknown transient failure error codes the request may be repeated, or handled in the same way as DIAMETER_UNABLE_TO_COMPLY. 6.1 Location management procedures 6.1.1 User registration status query This procedure is used between the I-CSCF and the HSS during SIP registrations. The procedure is invoked by the I-CSCF, corresponds to the combination of the functional level operations Cx-Query and Cx-Select-Pull (see TSÊ23.228Ê[1]) and is used: - To authorize the registration of the distinct Public User Identity, checking multimedia subsystem access permissions and roaming agreements. - To perform a first security check, determining whether the distinct Public User Identity in the message is associated with the Private User Identity sent in the message. - To obtain either the S-CSCF where the distinct Public User Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored), or the list of capabilities that the S-CSCF has to support. This procedure is mapped to the commands User-Authorization-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.1.1.1 and 6.1.1.2 detail the involved information elements. Table 6.1.1.1: User registration status query Information element name Mapping to Diameter AVP Cat. Description Public User Identity (See 7.2) Public-Identity M Public User Identity to be registered Visited Network Identifier (See 7.1) Visited-Network-Identifier M Identifier that allows the home network to identify the visited network Type of Authorization (See 7.14) User-Authorization-Type C Type of authorization requested by the I-CSCF. If the request corresponds to a de-registration, i.e. Expires field or expires parameter in Contact field in the REGISTER method is equal to zero, this AVP shall be present in the command and the value shall be set to DE-REGISTRATION. If the request corresponds to an initial registration or a re-registration, i.e. Expires field or expires parameter in Contact field in the REGISTER method is not equal to zero then this AVP may be absent from the command. If present its value shall be set to REGISTRATION. If the request corresponds to an initial registration or a re-registration or a de-registration and the I-CSCF explicitly queries the S-CSCF capabilities, then this AVP shall be present in the command and the value shall be set to REGISTRATION_AND_CAPABILITIES. The I-CSCF shall use this value when the S-CSCF currently assigned to the Public User Identity in the HSS, cannot be contacted and a new S-CSCF needs to be selected. The I-CSCF shall also use this value for RLOS related registrations when the S-CSCF currently assigned to the Public User Identity in the HSS does not support RLOS (see 3GPPÊTSÊ23.228Ê[1] annex Z) and a new S-CSCF (supporting RLOS) needs to be selected. RLOS support of the different S-CSCFs shall be locally configured in the I-CSCF, and this capability is independent on the subscribed capabilities received from HSS. Private User Identity (See 7.3) User-Name M Private User Identity Routing Information (See 7.13) Destination-Host, Destination-Realm C If the I-CSCF knows HSS name Destination-Host AVP shall be present in the command. Otherwise, only Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the I-CSCF. UAR Flags (See 7.19) UAR-Flags O This Information Element contains a set of indications. See 7.19 for the content of the information element. Table 6.1.1.2: User registration status response Information element name Mapping to Diameter AVP Cat. Description Result (See 7.6) Result-Code / Experimental-Result M Result of the operation. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. S-CSCF capabilities (See 7.5) Server-Capabilities O Required capabilities of the S-CSCF to be assigned to the IMS Subscription. S-CSCF Name (See 7.4) Server-Name C Name of the assigned S CSCF. 6.1.1.1 Detailed behaviour The HSS shall, in the following order (if there is an error in any of the following steps the HSS shall stop processing and return the corresponding error code, see TSÊ29.229Ê[5]): 0. If the HSS supports WebRTC as described in TSÊ23.228Ê[1] clause U.2.1.4, it shall check if the Private User Identity and the Public User Identity are managed by a third party, if so the HSS continues in step 4. NOTEÊ: How the HSS identifies that the Private User Identity and the Public User Identity are managed by a third party for WebRTC and how the HSS identifies the corresponding user profile are implementation specific. 1. Check that the Private User Identity and the Public User Identity exists in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 2. Check that the Public User Identity matches a distinct Public User Identity in the HSS. If it doesn't, the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 3. Check that the Public User Identity received in the request is associated with the Private User Identity received in the request. If not Experimental-Result-Code shall be set to DIAMETER_ERROR _IDENTITIES_DONT_MATCH. 4. Check whether the Public User Identity received in the request is barred from the establishment of multimedia sessions. - If it is an IMS Emergency Registration (by checking the UAR Flags) or the Public User Identity received in the request is not barred, continue to step 5. - Otherwise, the HSS shall check whether there are other non-barred Public User Identities to be implicitly registered with that one. - If so, continue to step 5. - If not, Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED. 5. Check the User-Authorization-Type received in the request: - If it is REGISTRATION or if User-Authorization-Type is absent from the request, the HSS shall check whether the UAR Flags indicate that this is an IMS Emergency Registration: - If it is not, and the Public User Identity is allowed to roam in the visited network (if not Experimental-Result-Code shall be set to DIAMETER_ERROR _ROAMING_NOT_ALLOWED) and authorized to register (if not Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED) then continue to step 6. - If it is an IMS Emergency Registration, authorization shall be granted and the HSS shall not perform any check regarding roaming. Continue to step 6. - If it is DE_REGISTRATION, the HSS may not perform any check regarding roaming. Continue to step 6. - If it is REGISTRATION_AND_CAPABILITIES, the HSS shall check whether the UAR Flags indicate that this is an IMS Emergency Registration: - If it is not, and the Public User Identity is allowed to roam in the visited network (if not Experimental-Result-Code shall be set to DIAMETER_ERROR _ROAMING_NOT_ALLOWED) and authorized to register (if not Result-Code shall be set to DIAMETER_AUTHORIZATION_REJECTED). The HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. If Server-Capabilities AVP is absent, it indicates to the I-CSCF that it can select any available S-CSCF. If an S-CSCF is already assigned in the HSS and IMS Restoration Procedures are supported in the HSS, the HSS shall set the S-CSCF reassignment pending flag and shall allow overwriting of the S-CSCF name in the next SAR request. Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing. - If it is an IMS Emergency Registration, authorization shall be granted and the HSS shall not perform any check regarding roaming. The HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. The Server-Capabilities AVP may be absent, to indicate to the I-CSCF that it can select any available S-CSCF. Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing. 6. Check the state of the Public User Identity received in the request: - If it is registered, the HSS shall return the stored S-CSCF name. No S-CSCF capabilities shall be present in the response. If User-Authorization-Type is equal to REGISTRATION or is absent, Experimental-Result-Code shall be set to DIAMETER_SUBSEQUENT_REGISTRATION. If User-Authorization-Type is equal to DE-REGISTRATION, Result-Code shall be set to DIAMETER_SUCCESS. - If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored) and User-Authorization-Type is equal to DE-REGISTRATION, the HSS shall return the stored S-CSCF name and the Result-Code shall be set to DIAMETER_SUCCESS. If the User-Authorization-Type is equal to REGISTRATION or is absent, then the HSS shall return the stored S-CSCF name and the Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities. - If it is not registered yet, the HSS shall check the value of User-Authorization-Type received in the request: - If the value of User-Authorization-Type is DE_REGISTRATION and the Authentication pending flag is set, the HSS shall return the stored S-CSCF name and Experimental-Result-Code set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF capabilities. Otherwise, if Authentication pending flag is not set, the HSS shall not return any S-CSCF name or S-CSCF capabilities. The HSS shall set the Experimental-Result-Code to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED in the response. - If the value of User-Authorization-Type is REGISTRATION or is absent, then the HSS shall check if there is at least one Public User Identity within the IMS Subscription with an S-CSCF name assigned. - If there is at least one Public User Identity within the IMS Subscription that is registered, the HSS shall return the S-CSCF name assigned for that Public User Identity and Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities. - If there is at least one Public User Identity within the IMS Subscription that is unregistered (i.e registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored), then the HSS shall return the stored S-CSCF name and the Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities. - If there is no identity of the user within the same IMS Subscription that is registered or unregistered, the HSS shall check if there is an S-CSCF name stored for the user (e.g. the user is being authenticated by the S-CSCF as indicated by the Authentication pending flag). If it is, the HSS shall return the stored S-CSCF name and Experimental-Result-Code set to DIAMETER_SUBSEQUENT_REGISTRATION. The HSS shall not return any S-CSCF capabilities. - If there is not any Public User Identity within the IMS Subscription with an S-CSCF name assigned, then the HSS may return the Server-Capabilities AVP, which enables the I-CSCF to select an S-CSCF. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. The Server-Capabilities AVP may be absent, to indicate to the I-CSCF that it may select any available S-CSCF. Experimental-Result-Code shall be set to DIAMETER_FIRST_REGISTRATION. The HSS shall not return any S-CSCF name. If the HSS cannot fulfil received request, e.g. due to database error, it shall set Result-Code to DIAMETER_UNABLE_TO_COMPLY. No S-CSCF name or S-CSCF capabilities shall be present in the response. 6.1.2 S-CSCF registration/deregistration notification This procedure is used between the S-CSCF and the HSS. The procedure is invoked by the S-CSCF, corresponds to the combination of the operations Cx-Put and Cx-Pull (see TSÊ23.228Ê[1]) and is used: - To assign an S-CSCF to a Public Identity, or to clear the name of the S-CSCF assigned to one or more Public Identities. - To download from HSS the relevant user information for the S-CSCF. - To backup and retrieve the S-CSCF Restoration Information (see TSÊ23.380Ê[19]) in the HSS. - To provide a P-CSCF Restoration Indication, and optionally, the address of the failed P-CSCF, to the HSS and trigger P-CSCF Restoration mechanism. This procedure is mapped to the commands Server-Assignment-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.1.2.1 and 6.1.2.2 describe the involved information elements. Table 6.1.2.1: S-CSCF registration/deregistration notification request Information element name Mapping to Diameter AVP Cat. Description Public User Identity / Public Service Identity (See 7.2 and 7.2a) Public-Identity C Public Identity or list of Public Identities. One and only one Public Identity shall be present if the Server-Assignment-Type is any value other than TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, USER_DEREGISTRATION_STORE_SERVER_NAME or ADMINISTRATIVE_DEREGISTRATION. If Server-Assignment-Type indicates deregistration of some type and Private Identity is not present in the request, at least one Public Identity shall be present. S-CSCF Name (See 7.4) Server-Name M Name of the S-CSCF. Private User Identity / Private Service Identity (See 7.3 and 7.3a) User-Name C Private Identity. It shall be present if it is available when the S-CSCF issues the request. It may be absent during the initiation of a session to an unregistered Public Identity (Server-Assignment-Type shall contain the value UNREGISTERED_USER) or after S-CSCF recovery upon originating request different than REGISTER (Server-Assignment-Type shall contain the value NO_ASSIGNMENT). In case of de-registration, Server-Assignment-Type equal to TIMEOUT_DEREGISTRATION, ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME if no Public-Identity AVPs are present then User-Name AVP shall be present. Server Assignment Type (See 7.8) Server-Assignment-Type M Type of update, request or notification that the S-CSCF requests in the HSS (e.g: de-registration). See 3GPPÊTSÊ29.229Ê[5] for all the possible values. User Data Already Available (See 7.16) User-Data-Already-Available M This indicates if the user profile and charging information and, if supported and present in the subscription, allowed WAF and/or WWSF identities are already available in the S-CSCF. In the case where Server-Assignment-Type is not equal to NO_ASSIGNMENT, REGISTRATION, RE_REGISTRATION or UNREGISTERED_USER, the HSS shall not use User Data Already Available when processing the request. Routing Information (See 7.13) Destination-Host C If the S-CSCF knows the HSS name, the Destination-Host AVP shall be present in the command. This information is available if the request belongs to an already existing registration, e.g. in case of the re-registration, where the HSS name is stored in the S-CSCF. The HSS name is obtained from the Origin-Host AVP, which is received from the HSS, e.g. included in the MAA command. This information may not be available if the command is sent as a consequence of a session termination for an unregistered Public Identity. In this case the Destination-Host AVP is not present and the command is routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the S-CSCF. Wildcarded Public Identity (See 7.2b) Wildcarded-Public-Identity O If the request refers to a Wildcarded PSI or Wildcarded Public User Identity, and the Server-Asignment-Type is set to UNREGISTERED_USER, NO_ASSIGNMENT, TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME, ADMINISTRATIVE_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or TIMEOUT_DEREGISTRATION, the S-CSCF may include the corresponding Wildcarded PSI or Wildcarded Public User Identity in this information element. If this element is present, it shall be used by the HSS to identify the identity affected by the request. The terms Public Identity or Public Service Identity in the detailed behaviour refer then to the Wildcarded Public Identity. S-CSCF Restoration Information (See 7.21) SCSCF-Restoration-Info C When the S-CSCF supports IMS Restoration Procedures, if Server-Assignment-Type is REGISTRATION or RE_REGISTRATION, and any of the related restoration information changed compared to the previous one, the S-CSCF shall send this information element to the HSS. This information allows a later retrieval in case of an S-CSCF service interruption. Multiple-Registration-Indication (See 7.23) Multiple-Registration-Indication C When the S-CSCF supports IMS Restoration Procedures, if Server-Assignment-Type is REGISTRATION and the registration is a multiple registration and the Public User Identity is not stored as registered with the Private User Identity as in the request in the S-CSCF, the S-CSCF shall send this information element to the HSS. Session-Priority (See 7.24) Session-Priority O This information element, if present, shall indicate the session's priority to the HSS. SAR Flags (See 7.28) SAR-Flags O This Information Element contains a set of indications. See 7.28 for the content of the information element. Failed P-CSCF Failed-PCSCF O If present, this Information Element shall contain the address (FQDN and/or IP addresses) of a failed P-CSCF; it shall only be included if the SAR Flags IE contains the ""P-CSCF Restoration Indication"" (see clauseÊ7.28). Table 6.1.2.2: S-CSCF registration/deregistration notification response Information element name Mapping to Diameter AVP Cat. Description Private User Identity / Private Service Identity (See 7.3 and 7.3a) User-Name C Private Identity. It shall be present if it is available when the HSS sends the response. It may be absent in the following error case: when the Server-Assignment-Type of the request is UNREGISTERED_USER and the received Public Identity is not known by the HSS. Registration result (See 7.6) Result-Code / Experimental-Result M Result of registration. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. User Profile (See 7.7) User-Data C Relevant user profile. It shall be present when Server-Assignment-Type in the request is equal to NO_ASSIGNMENT, REGISTRATION, RE_REGISTRATION or UNREGISTERED_USER according to the rules defined in clauseÊ6.6. If the S-CSCF receives more data than it is prepared to accept, it shall perform the de-registration of the Private Identity with Server-Assignment-Type set to DEREGISTRATION_TOO_MUCH_DATA and send back a SIP 3xx or 480 (Temporarily Unavailable) response, which shall trigger the selection of a new S-CSCF by the I-CSCF, as specified in 3GPPÊTSÊ24.229Ê[8]. Charging Information (See 7.12) Charging-Information C Addresses of the charging functions. It shall be present when the User-Data AVP is sent to the S-CSCF according to the rules defined in clauseÊ6.6. When this parameter is included, either the Primary-Charging-Collection-Function-Name AVP or the Primary-Event-Charging-Function-Name AVP shall be included. All other elements shall be included if they are available. Associated Private Identities Associated-Identities O This AVP contains all Private Identities, which belong to the same IMS subscription as the Private Identity or Public Identity received in the SAR command. If the IMS subscription contains only single Private Identity this AVP shall not be present. Loose-Route Indication Loose-Route-Indication C This AVP indicates to the S-CSCF that loose-route mechanism shall be applied to the public identities contained in the user profile received from the HSS. If the loose-route mechanism is required, this AVP shall be present and set to LOOSE_ROUTE_REQUIRED. If the Loose-Route mechanism is not required, this AVP may be either absent or present. If present, it shall be set to LOOSE_ROUTE_NOT_REQUIRED. S-CSCF Restoration Information (See 7.21) SCSCF-Restoration-Info C This information shall be present if it was stored by the S-CSCF in the HSS and Server-Assignment-Type is either UNREGISTERED_USER or NO_ASSIGNMENT. This information shall also be present if it was stored by the S-CSCF in the HSS and the SAR indicates it is related to a multiple registration and Server-Assignment-Type is REGISTRATION. This information may be present if it was stored by the S-CSCF in the HSS and Server-Assignment-Type is either REGISTRATION or RE-REGISTRATION and there are other Private Identities different from the Private Identity received in the SAR command being registered with the Public Identity received in the SAR command. Associated Registered Private Identities (See 7.22) Associated-Registered-Identities C This AVP contains all Private Identities that were registered with the Public Identity received in the SAR command. The HSS shall send this information element if the IMS Restoration Procedures are supported and the value of Server-Assignment-Type in the request is REGISTRATION or RE_REGISTRATION and there are other Private Identities different from the Private Identity received in the SAR command being registered with the Public Identity received in the SAR command. Otherwise, this AVP shall not be present. S-CSCF Name (See 7.4) Server-Name C Name of the assigned S-CSCF. This AVP shall be present, if the requesting S-CSCF name is different from the previously assigned S-CSCF name stored in the HSS. Wildcarded Public Identity (See 7.2b) Wildcarded-Public-Identity C This AVP shall be present if: - the value of Server-Assignment-Type in the request was UNREGISTERED_USER or NO_ASSIGNMENT and - the Wildcarded-Public-Identity AVP in the request was not present and - the Public Identity in the request fell within the range of a Wildcarded Public User Identity in the HSS whose state is registered/unregistered. If this element is present, it shall be used by the S-CSCF to identify the identity affected by the request. Priviledged-Sender Indication (See 7.26) Priviledged-Sender-Indication O This AVP indicates if the Private User Identity shall be considered as a priviledged sender. If not present, it means that the Private User Identity is not considered a priviledged sender. Allowed WAF and/or WWSF Identities (See 7.29) Allowed-WAF-WWSF-Identities C Addresses of the WAFs and/or WWSFs the subscription is allowing to use. This AVP shall be present if both a) it is applicable for the subscription and b) the User-Data AVP is present. 6.1.2.1 Detailed behaviour On registering/deregistering a Public Identity the S-CSCF shall inform the HSS. The same procedure is used by the S-CSCF: - to get the user information which contains the user profile, the charging information and the allowed WAF and/or WWSF Identities. The relevant user profile downloaded is described in more detailed in clauses 6.5.1 and 6.6. - to provide a P-CSCF Restoration Indication to the HSS when the S-CSCF, supporting the HSS based P-CSCF restoration mechanism described in TSÊ23.380Ê[19], has identified a P-CSCF failure for a given UE and then triggers the P-CSCF Restoration mechanism execution for this UE. The Public-Identity AVP and User-Data AVPs in this command pair shall contain only one type of identities i.e. either only Public User Identities, or only Public Service Identities. User initiated registration/deregistration procedures (i.e. server-assignment-type is set to RE_REGISTRATION, USER_DEREGISTRATION, etc.) shall only be allowed for distinct Public User Identities. The HSS holds information about the state of registration of all the identities related to an IMS Subscription. The S-CSCF uses this procedure to update such states. For Shared Public User Identities, the S-CSCF shall initiate this procedure towards the HSS for each Private User Identity undergoing a Registration or Deregistration related to the Shared Public User Identity. For implicitly registered identities, the rules defined in ClauseÊ6.5.1 shall apply. When the request message was received because of a terminating session request, the HSS may prioritise the received request message according to priority level received within the Session-Priority AVP. NOTE 1: Refer to Annex J for HSS procedures associated with the handling of both the Session-Priority AVP and DRMP AVP received in the request message. The HSS shall, in the following order (in case of an error in any of the steps the HSS shall stop processing and return the corresponding error code, see TSÊ29.229Ê[5]): 1. Check that the Public Identity and Private Identity exist in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 2. The HSS may check whether the Private and Public Identities received in the request are associated in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH. 3. If more than one Public-Identity AVP is present and the Server-Assignment-Type is one of the values defined in Table 6.1.2.1 as applying for only one identity, then the Result Code shall be set to DIAMETER_AVP_OCCURS_TOO_MANY_TIMES and no user information shall be returned. 4. The HSS shall check the Public Identity type received in the request. - If the identity in the request is a distinct Public User Identity, continue in step 5, otherwise the HSS shall check the server-assignment-type: If it indicates REGISTRATION, RE_REGISTRATION, USER_DEREGISTRATION, USER_DEREGISTRATION_STORE_SERVER_NAME, AUTHENTICATION_FAILURE or AUTHENTICATION_TIMEOUT, Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. - If the identity in the request is a Public Service Identity, then check if the PSI Activation State for that identity is active. If not, then the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN. 5. Check the Server Assignment Type value received in the request: - If it indicates REGISTRATION or RE_REGISTRATION, the HSS shall check whether the Public Identity is assigned for the S-CSCF requesting the data. If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF, and IMS restoration procedures are not supported or the S-CSCF reassignment pending flag is not set, the HSS shall include the name of the previously assigned S-CSCF in the response message andÊthe Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED. If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF and IMS restoration procedures are supported, and the S-CSCF reassignment pending flag is set, the HSS shall overwrite the S-CSCF name and shall reset the S-CSCF reassignment pending flag. If there is no S-CSCF assigned to the user or the requesting S-CSCF is the same as the previously assigned S-CSCF stored in the HSS,Êthe HSS shall download the relevant user information taking into consideration the value set in the User-Data-Already-Available AVP (see clauseÊ6.6). The Result-Code shall be set to DIAMETER_SUCCESS and the HSS shall set the registration state of the Public User Identity as registered (if not already registered). If the S-CSCF Restoration Information is included in the request and the HSS implements IMS Restoration procedures, and if it is RE_REGISTRATION, the HSS shall store this information. If the Public User Identity's authentication pending flag which is specific for the Private User Identity is set, the HSS shall clear it. If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription. If the loose-route mechanism is required for the registered Public User Identities, the Loose-Route-Indication AVP shall be added to the answer message. If there are multiple Private User Identities being registered with the Public Identity received in the request message, and the IMS Restoration Procedures are supported in the HSS, the Associated-Registered-Identities AVP shall be added to the answer message and it shall contain all Private User Identities being registered with the Public Identity, and subject to the operator policy, the HSS may include all stored S-CSCF Restoration Information groups associated to the Private User Identities in the response. NOTE 2: If the HSS returns all the S-CSCF Restoration Information groups in the response, the S-CSCF can ignore the Associated-Registered-Identities AVP and skip additional Server-Assignment-Request since the information is already made available. If it is REGISTRATION and the HSS implements IMS Restoration procedures, if multiple registration indication is included in the request and the Public User Identity is stored as registered in the HSS, and there is restoration information related to the Private User Identity, the HSS shall not overwrite the stored S-CSCF Restoration Information, instead, it shall send the stored S-CSCF restoration information together with the user profile in the SAA. Subject to the operator policy, if there is S-CSCF Restoration Information associated with several Private User Identities, the HSS may include all the S-CSCF Restoration Information groups in the response. The Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. Otherwise, the HSS shall store the received S-CSCF restoration information. The Result-Code shall be set to DIAMETER_SUCCESS. - If it indicates UNREGISTERED_USER, the following applies. If the P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS supporting the P-CSCF-Restoration-mechanism feature shall check whether at least one of the serving node(s) for corresponding user support this feature."
"If none of the serving nodes support the feature, the HSS shall stop processing this request and the Result-Code shall be set to DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED. The HSS shall check whether the Public Identity is assigned for the S-CSCF requesting the data: - If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF, and IMS restoration procedures are not supported or the S-CSCF reassignment pending flag is not set and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall include the name of the previously assigned S-CSCF in the response message andÊthe Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED. - If there is already an S-CSCF assigned to the user and the requesting S-CSCF is not the same as the previously assigned S-CSCF and IMS restoration procedures are supported, and the S-CSCF reassignment pending flag is set, the HSS shall overwrite the S-CSCF name and shall reset the S-CSCF reassignment pending flag. - If there is no S-CSCF assigned to the user or the requesting S-CSCF is the same as the previously assigned S-CSCF stored in the HSS, the HSS shall store the S-CSCF name. The HSS shall check the Public Identity registration state: - If the registration state of the Public Identity is not registered or unregistered, the HSS shall set or keep the registration state of the Public Identity as unregistered, i.e. registered as a consequence of an originating or terminating request and if a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP download the relevant user information. The Result-Code shall be set to DIAMETER_SUCCESS. If there are multiple Private User Identities associated to the Public User Identity in the HSS, the HSS shall arbitrarily select one of the Private User Identities and put it into the response message. - If the registration state of the Public Identity is registered and IMS restoration procedures are not supported, the HSS shall set the registration state of the Public identity as unregistered, clear any S-CSCF Restoration Information associated with the Public User Identity (if any) and if a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP download the relevant user information. The Result-Code shall be set to DIAMETER_SUCCESS. If there are multiple Private User Identities associated to the Public User Identity in the HSS, the HSS shall arbitrarily select one of the Private User Identities and put it into the response message. NOTE 3: The case where S-CSCF Restoration Information is stored in the HSS even though IMS Restoration Procedures are not supported corresponds to the situation where the HSS supports IMS Restoration Procedures but a new assigned S-CSCF does not, while the former S-CSCF supported this feature. - If the registration state of the Public Identity is registered and IMS restoration procedures are supported and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall include in the response all S-CSCF Restoration Information related with the Public User Identity. If there is S-CSCF Restoration Information associated with several Private User Identities, the HSS shall include all the S-CSCF Restoration Information groups in the response. The Experimental-Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. - If the registration state of the Public Identity is Registered and IMS Restoration Procedures are supported and a P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS shall set the registration state of the Public identity as Unregistered and clear any S-CSCF Restoration Information associated with the Public User Identity (if any). The Result-Code shall be set to DIAMETER_SUCCESS. If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription. If the S-CSCF receives a wildcarded public identity from the I-CSCF, the S-CSCF shall use this wildcarded public identity to fetch the user profile (i.e.Êby sending a Cx-SAR including Wildcarded-Public-Identity AVP if the profile is not available) and registration information locally stored. If the S-CSCF does not receive a wildcarded public identity, the S-CSCF shall not perform wildcarded public identity matching and shall use the public identity received instead to fetch the user profile (i.e.Êby sending a Cx-SAR without including Wildcarded-Public-Identity AVP if the profile is not available) and registration information. NOTE 4: There may be SIP requests in which the S-CSCF does not receive information of a wildcarded public identity, e.g. originating call from an AS on behalf of a user. NOTE 5: Since a distinct public identity falling into the range of a wildcarded public identity can have a different service profile, the S-CSCF does not perform the wildcarded public identity matching against the public identity received to avoid using the wrong service profile. If the Wildcarded-Public-Identity AVP is not received and if the Public Identity falls within the range of a wildcarded public identity whose registration state is registered and a P-CSCF-Restoration-Indication is not included in SAR-Flags AVP, the HSS shall not overwrite the registration state. The Result-Code shall be set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE and the HSS shall include the Wildcarded-Public-Identity AVP in the response. Upon reception of this error, the S-CSCF should behave as if it has received a wildcarded public identity in the first place. If SAR-Flags AVP includes a P-CSCF-Restoration-Indication, the HSS supporting the P-CSCF-RestorationÐmechanism feature shall send a P-CSCF restoration indication to the serving nodes where the IMSI associated to the received Private Identity is registered, i.e. SGSN and/or MME, using S6a/S6d IDR/IDA or Gr ISD request/answer as described in TSÊ23.380Ê[19] clauseÊ5.4. The Result-Code shall be set to DIAMETER_SUCCESS. - If it indicates TIMEOUT_DEREGISTRATION, USER_DEREGISTRATION, DEREGISTRATION_TOO_MUCH_DATA or ADMINISTRATIVE_DEREGISTRATION, the following applies. If it indicates ADMINISTRATIVE_DEREGISTRATION and if the P-CSCF-Restoration-Indication is included in SAR-Flags AVP, the HSS supporting the P-CSCF-Restoration-mechanism feature shall check whether at least one of the serving node(s) for corresponding user support this feature. If none of the serving nodes support the feature, the HSS shall stop processing this request and the Result-Code shall be set to DIAMETER_ERROR_SERVING_NODE_FEATURE_UNSUPPORTED. The HSS shall check the registration state for all the Public Identities in the request. - If a Private User Identity is present in the request, if the request did not contain Public Identities the HSS shall check the registration state of the Public Identities associated with the Private Identity identified in the request. For each Public Identity: - If the registration state of the Public User Identity is Registered, the HSS shall check if the Public User Identity is currently registered with one or more Private User Identities. - If the Public User Identity is currently registered with only one Private User Identity, the HSS shall set the registration state of the Public User Identity to Not Registered and clear the S-CSCF name and any S-CSCF Restoration Information associated with the Public User Identity. - If the Public User Identity is currently registered with more than one Private User Identity, the HSS shall keep the registration state of the Public User Identity as Registered and retain the S-CSCF name associated with the Public User Identity. The HSS shall remove any S-CSCF Restoration Information associated to the registration of this Public User Identity with this Private User Identity. - If a Private User Identity is absent in the request, if the Public User Identity is currently registered with more than one Private User Identity, the HSS shall stop processing this request and shall set the Result-Code to DIAMETER_MISSING_AVP. - if the registration state of the Public Identity is Unregistered, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity. In case of ADMINISTRATIVE_DEREGISTRATION, if SAR-Flags AVP includes a P-CSCF-Restoration-Indication, the HSS or combined HSS-UDM supporting the P-CSCF-Restoration-mechanism feature shall send a P-CSCF restoration indication to the serving nodes where the IMSI associated to the received Private Identity is registered, i.e. SGSN and/or MME, using S6a/S6d IDR/IDA or Gr ISD request/answer as described in TSÊ23.380Ê[19] clauseÊ5.4, and SMF and/or AMF, using the Nudm_UECM_P-CSCF-RestorationNotification service operation as described in TSÊ23.380Ê[19] clauseÊ5.8.4. The Result-Code shall be set to DIAMETER_SUCCESS - If it indicates TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME or USER_DEREGISTRATION_STORE_SERVER_NAME the HSS decides whether to keep the S-CSCF name associated to the Private User Identity stored or not for all the Public User Identities that the S-CSCF indicated in the request. If no Public User Identity is present in the request, the Private User Identity shall be present. - If the HSS decides to keep the S-CSCF name stored the HSS shall keep the S-CSCF name stored for all the Public User Identities associated to the Private User Identity. The Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall check if each Public User Identity in the request is currently registered with one or more Private User Identities. If the request did not contain Public User Identities the HSS shall check if each Public User Identity associated with the Private User Identity in the request is currently registered with one or more Private User Identities. For each Public User Identity;- - If only one Private User Identity associated with the Public User Identity is currently registered with the Public User Identity, the HSS shall set the registration state of the Public User Identity to Unregistered and clear any S-CSCF Restoration Information associated with the Public User Identity - If more than one Private User Identity that shares that Public User Identity is currently registered with the Public User Identity the HSS shall keep the registration state of the Public User Identity as Registered. The HSS shall remove any S-CSCF Restoration Information associated to the registration of this Public User Identity with the Private User Identity in the request. - If the HSS decides not to keep the S-CSCF name the Experimental-Result shall be set to DIAMETER_SUCCESS_SERVER_NAME_NOT_STORED. The HSS shall check if each Public User Identity in the request is currently registered with one or more Private User Identities. If the request did not contain Public User Identities the HSS shall check if each Public User Identity associated with the Private User Identity in the request is currently registered with one or more Private User Identities. For each Public User Identity;- - If only one Private User Identity associated with the Public User Identity is currently registered with the Public User Identity, the HSS shall set the registration state of the Public User Identity to Not Registered and clear the S-CSCF name associated with Public User Identity. - If more than one Private User Identity that shares that Public User Identity is currently registered with the Public User Identity the HSS shall keep the registration state of the Public User Identity as Registered. - If it indicates NO_ASSIGNMENT, the HSS checks whether the Public Identity is assigned for the S-CSCF requesting the data. If the requesting S-CSCF is not the same as the assigned S-CSCF and the S-CSCF reassignment pending flag is not set, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY, otherwise the HSS shall download the relevant user information and the Result-Code shall be set to DIAMETER_SUCCESS. If relevant S-CSCF Restoration Information is stored in the HSS and IMS Restoration Procedures are supported, it shall be added to the answer message. If there is S-CSCF Restoration Information associated with several Private User Identities, the HSS shall include all the S-CSCF Restoration Information groups in the response. If there are multiple Private User Identities, which belong to the served IMS subscription the Associated-Identities AVP should be added to the answer message and it shall contain all Private User Identities associated to the IMS subscription. NOTE 6: the check of the S-CSCF reassignment pending flag is needed since an S-CSCF supporting restoration procedures can receive a user initiated de-registration for a Public Identity for which it does not have any registration data (see TSÊ23.380Ê[19]). In such case, the S-CSCF indicates NO_ASSIGNMENT in Server-Assignment-Type to retrieve any possible restoration information from the HSS. - If it indicates AUTHENTICATION_FAILURE (e.g. there is a mismatch in IP-address secure binding information) or AUTHENTICATION_TIMEOUT (e.g. no response to Digest challenge), the HSS shall keep the registration state of the Public User Identity. The HSS shall check the registration state for the Public User Identity in the request and only if the registration state of the Public User Identity is Not Registered, the HSS shall clear the S-CSCF name associated with the Public User Identity. If the Public User Identity's authentication pending flag which is specific for the Private User Identity is set, the HSS shall clear it. The Result-Code shall be set to DIAMETER_SUCCESS. If the HSS cannot fulfil the received request, e.g. due to database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. The HSS shall not modify any registration state nor download any Public Identity information to the S-CSCF. See clauseÊ8.1.2 and 8.1.3 for the description of the handling of the error situations: reception of an S-CSCF name different from the one stored in the HSS and reception of a Server-Assignment-Type value not compatible with the registration state of the Public Identity. 6.1.3 Network initiated de-registration by the HSS, administrative In case of network initiated de-registration of by the HSS, the HSS change the state of the Public Identities to Not Registered and send a notification to the S-CSCF indicating the identities that shall be de-registered. The procedure is invoked by the HSS, corresponds to the functional level operation Cx-Deregister (see TSÊ23.228Ê[1]). This procedure is mapped to the commands Registration-Termination-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.1.3.1 and 6.1.3.2 describe the involved information elements. Table 6.1.3.1: Network Initiated Deregistration by HSS request Information element name Mapping to Diameter AVP Cat. Description Public User Identity / Public Service Identity (See 7.2 and 7.2a) Public-Identity C It contains the list of Public Identities that are de-registered, in the form of SIP URL or TEL URL. Public-Identity AVP shall be present if the de-registration reason code is NEW_SERVER_ASSIGNED. It may be present with the other reason codes. Private User Identity / Private Service Identity (See 7.3 and 7.3a) User-Name M It contains the Private Identity in the form of a NAI. The HSS shall always send a Private Identity that is known to the S-CSCF based on an earlier SAR/SAA procedure. Reason for de-registration (See 7.11) Deregistration-Reason M The HSS shall send to the S-CSCF a reason for the de-registration. The de-registration reason is composed of two parts: one textual message (if available) that is intended to be forwarded to the user that is de-registered, and one reason code (see 3GPPÊTSÊ29.229Ê[5]) that determines the behaviour of the S-CSCFÊ Routing Information (See 7.13) Destination-Host M It contains the name of the S-CSCF which originated the last update of the name of the multimedia server stored in the HSS for a given IMS Subscription. The address of the S-CSCF is the same as the Origin-Host AVP in the message sent from the S-CSCF. Associated Private Identities Associated-Identities O This AVP contains Private Identities, which belong to the same IMS subscription as the Private Identity in the User-Name AVP and should be de-registered together with that one. If the IMS subscription contains only a single Private Identity, this AVP shall not be present. RTR Flags (See 7.30) RTR-Flags O This information element contains a bit mask. See 7.30 for the meaning of the bits. Table 6.1.3.2: Network Initiated Deregistration by HSS response Information element name Mapping to Diameter AVP Cat. Description Result (See 7.6) Result-Code / Experimental-Result M This information element indicates the result of de-registration. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. Associated Private Identities Associated-Identities C This AVP shall be present if the S-CSCF de-registered more than one Private Identity with the request. It contains all Private Identities that have been deregistered together with the one in the User-Name AVP of the request. Identities with Emergency Registration (See 7.25) Identity-with-Emergency-Registration C This information element indicates a list of pairs of private and public user identities which have not been de-registered due to emergency registration. 6.1.3.1 Detailed behaviour The HSS shall de-register the affected identities and invoke this procedure to inform the S-CSCF. The S-CSCF shall remove all the information stored in the S-CSCF for the affected identities. The HSS may de-register: - One Public Identity or a list of Public Identities. HSS may include all Public User Identities associated with the User-Name AVP to the request. This option is applicable with all reason codes. - One or more Private Identities of the IMS Subscription with all associated Public Identities. No Public-Identity AVPs shall be present in this case. This option is applicable with reason codes PERMANENT_TERMINATION, SERVER_CHANGE, and REMOVE_S-CSCF. - All Public Service Identities that match a Wildcarded Public Service Identity. In this case the HSS may send one of the Public Service Identities that was received in the Server Assignment Request for that Wildcarded Public Service Identity and the associated Private Service Identity. - A Wildcarded Public User Identity. In this case the HSS shall send a distinct Public User Identity that belongs to the same implicit registration set as the Wildcarded Public User Identity and the associated Private User Identity. The HSS shall send in the Deregistration-Reason AVP the reason for the de-registration, composed by a textual message (if available) aimed for the user and a reason code that determines the action the S-CSCF has to perform. The possible reason codes are: - PERMANENT_TERMINATION: The HSS indicates to the S-CSCF that the S-CSCF will no longer be assigned to the Public Identity and associated implicitly registered/unregistered Public Identities (if any) for the Private Identity(ies) indicated in the request (e.g. due to an IMS subscription cancellation, or modification, or a removal of IP-address secure binding information when GIBA is used). This reason also indicates that no other S-CSCF can be assigned. The HSS shall check the registration state of the Public Identities. If no Public Identities are involved, the HSS shall check the registration state of the Public Identities associated with the Private User Identity identified. For each Public Identity: - If the registration state of the Public Identity is Registered, the HSS shall check if the Public User Identity is currently registered with one or more Private User Identities. - If the Public User Identity is currently registered with only one Private User Identity, the HSS shall check whether the Public User Identity is included in the information element Identities with Emergency Registrations returned by S-CSCF in the response. - If included, the HSS shall keep the S-CSCF name associated with the Public User Identity and set the registration state of the Public User Identity to Unregistered. - If not included, the HSS shall clear the S-CSCF name associated with the Public User Identity, and set the registration state of the Public User Identity to Not Registered The S-CSCF initiates the de-registration of the Public User Identity unless it is emergency registered. - If the Public User Identity is currently registered with more than one Private User Identity, the HSS shall keep the registration state of the Public User Identity as Registered and retain the S-CSCF name associated with the Public User Identity. The S-CSCF initiates the de-registration of the Public User Identity unless it is emergency registered. - If the registration state of the Public Identity is Unregistered, the HSS shall check whether this Public User Identity is included in the information element Identities with Emergency Registrations returned by S-CSCF in the response. - If included, the HSS shall keep the S-CSCF name associated with the Public User Identity. - If not included, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity. - NEW_SERVER_ASSIGNED: The HSS indicates to the S-CSCF that a new S-CSCF has been allocated to the IMS Subscription e.g. because the previous assigned S-CSCF was unavailable during a registration procedure. The S-CSCF shall remove all information for all of the Public Identities indicated in the request. - SERVER_CHANGE: The HSS indicates to the S-CSCF that the de-registration is requested to force the selection of new S-CSCF to assign to the IMS Subscription (e.g. when the S-CSCF capabilities are changed in the HSS or when the S-CSCF indicates that it has not enough memory for the updated User Profile). The HSS shall set the registration state to ""Not Registered"" and clear the S-CSCF name for all of the Public Identities affected by the request. If the S-CSCF does not indicate in the response all the Private Identities that were in the request, the HSS shall repeat this request for each of the remaining Private Identities in the IMS Subscription that are known to the S-CSCF. The S-CSCF should start the network initiated de-registration towards the user, i.e. all registrations within the IMS Subscription are de-registered and the user is asked to re-register to all existing registrations. - REMOVE_S-CSCF: The HSS indicates to the S-CSCF that the S-CSCF will no longer be assigned to an unregistered Public Identity(ies) (i.e registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) for a given IMS Subscription. The HSS shall check if an emergency registration exists in the S-CSCF, checking for each Public Identity contained in the request whether it is present in the information element Identities with Emergency Registrations returned by S-CSCF. - If an emergency registration does not exist in S-CSCF, for each Public Identity contained within the request, the HSS shall set the registration state of the Public Identity to Not Registered and clear the S-CSCF name associated with the Public Identity. The S-CSCF shall remove all information related to the Public User Identity contained within the request. - If an emergency registration exists in S-CSCF for one or more Public User Identities contained in the request, the S-CSCF should include the corresponding Private Identity /Public User Identity pairs in the information element Identities with Emergency Registrations in the answer. The HSS, when receiving such an answer, shall not change the registration state of the Public User Identities present in the information element Identities with Emergency Registrations and shall keep unchanged the S-CSCF name associated with these Public User Identities. Public Identities which are emergency registered in the S-CSCF shall not be de-registered when a Cx-Deregistration request with a -reason code of PERMANENT_TERMINATION or REMOVE_S-CSCF is received from the HSS. In this case - if all to be de-registered identities are emergency registered, a Result-Code set to DIAMETER_UNABLE_TO_COMPLY and a list of Private / Public Identity pairs which are emergency registered shall be returned to the HSS - if a proper subset of the to be de-registered identities are emergency registered, a Result-Code of DIAMETER_LIMITED_SUCCESS and a list of Private Identity / Public Identity pairs which are emergency registered shall be returned to the HSS. NOTE 1: If the Public Identity that is emergency registered has normal registration as well, then for the normal registration the S-CSCF will perform the detailed de-registration procedures towards the UE for each reason code as described in TSÊ24.229Ê[8]. NOTE 2: It is assumed that Public Identities which are implicitly registered along with an emergency registration are also emergency registered. The detailed de-registration procedures performed by the S-CSCF are described in TSÊ24.229Ê[8]. 6.1.4 User location query This procedure is used between the I-CSCF and the HSS to obtain the name of the S-CSCF assigned to a Public Identity, or the name of the AS hosting a PSI for direct routing. The procedure is invoked by the I-CSCF, is performed per Public Identity, and corresponds to the functional level operation Cx-Location-Query (see TSÊ23.228Ê[1]). This procedure is mapped to the commands Location Info Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.1.4.1 and 6.1.4.2 detail the involved information elements. Table 6.1.4.1: User Location query Information element name Mapping to Diameter AVP Cat. Description Public User Identity / Public Service Identity (See 7.2 and 7.2a) Public-Identity M Public Identity Routing information (See 7.13) Destination-Host, Destination-Realm C If the I-CSCF knows HSS name Destination-Host AVP shall be present in the command. Otherwise, only Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the I-CSCF. Originating Request (See 7.18) Originating-Request O It indicates that the request is related to an originating SIP message. Type of Authorization (See 7.14) User-Authorization-Type C This information element shall be present and set to REGISTRATION_AND_CAPABILITIES by the I-CSCF if IMS Restoration Procedures are supported and the S-CSCF currently assigned to the Public User Identity in the HSS cannot be contacted. Session Priority (See 7.24) Session-Priority O This information element, if present, shall indicate the session's priority to the HSS. Table 6.1.4.2: User Location response Information element name Mapping to Diameter AVP Cat. Description Result (See 7.6) Result-Code / Experimental-Result M Result of the operation. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. S-CSCF Name / AS name (See 7.4 and 7.4a) Server-Name C Name of the assigned S-CSCF for basic IMS routing or the name of the AS for direct routing. S-CSCF capabilities (See 7.5) Server-Capabilities O It contains the information to help the I-CSCF in the selection of the S-CSCF. Wildcarded Public Identity (See 7.2b) Wildcarded-Public-Identity O If the requests refers to a Wildcarded PSI or Wildcarded Public User Identity (the Public Identity in the request matches a Wildcarded PSI or Wildcarded Public User Identity in the HSS), the HSS shall include the corresponding Wildcarded Public Identity in this information element. The matching of distinct Public Identies takes precedence over the matching of wildcarded public identities. LIA Flags (See 7.27) LIA-Flags O This information element contains a bit mask. See 7.27 for the meaning of the bits. 6.1.4.1 Detailed behaviour The HSS may prioritise the received request message according to priority level received within the Session-Priority AVP. NOTE 1: Refer to Annex J for HSS procedures associated with the handling of both the Session-Priority AVP and DRMP AVP received in the request message. The HSS shall, in the following order (if an error occurs in any of the ste The HSS shall, in the following order (if an error occurs in any of the steps the HSS shall stop processing and return the corresponding error code, see TSÊ29.229Ê[5]): 1. Check that the Public Identity is known. If not the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 2. Check the type of the Public Identity contained in the request: - If this is a Public User Identity, continue to step 2a. - If this is a Public Service Identity: - Check if the PSI Activation State for that identity is active. If not, then the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_USER_UNKNOWN. - Check if the name of the AS hosting the Public Service Identity is stored in the HSS and that the request does not contain the Originating-Request AVP. - If this is the case, if IMS Restoration Procedures are supported, the HSS shall check if User-Authorization-Type was received in the request, and if the value is REGISTRATION_AND_CAPABILITIES: - If it is, the HSS shall reject the request with Result-Code set to DIAMETER_UNABLE_TO_COMPLY. - Otherwise, the HSS shall return the AS name and the Result-Code AVP shall be set to DIAMETER_SUCCESS. HSS may set PSI Direct Routing Indication bit in LIA-Flags AVP, then I-CSCF shall not perform IMS Restoration Procedures (see clauseÊ4.3.3 in TSÊ23.380Ê[19]). - Otherwise, continue to step 2a. 2a. If IMS Restoration procedures are supported, the HSS shall check if User-Authorization-Type was received in the request, and if the value is REGISTRATION_AND_CAPABILITIES: - If it is, then the HSS may return the Server-Capabilities AVP. The returned capabilities, if any, shall satisfy all the requirements of all the service profiles associated with the IMS Subscription. If Server-Capabilities AVP is absent, it indicates to the I-CSCF that it can select any available S-CSCF. Also the HSS shall set the S-CSCF reassignment pending flag and allow overwriting of the S-CSCF name in the next SAR request, which enables the I-CSCF to select an S-CSCF. The Result-Code shall be set to DIAMETER_SUCCESS. The HSS shall not return any S-CSCF name. Stop processing. - Otherwise, continue to step 3. 3. Check the state of the Public Identity received in the request, and where necessary, check if the Public Identity has terminating services related to the unregistered state. - If it is registered, the HSS shall return the stored S-CSCF name. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code AVP shall be set to DIAMETER_SUCCESS. - If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) the HSS shall return the S-CSCF name assigned for that Public Identity. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code shall be set to DIAMETER_SUCCESS. - If it is not registered, but either it has terminating services related to unregistered state or the request contains the Originating-Request AVP, the HSS shall check if there is at least one Public Identity within the IMS Subscription with an S-CSCF name assigned: - If this is the case the HSS shall return the S-CSCF name assigned for that Public Identity. The Server-Name AVP shall contain the SIP URI of the server. The Server-Capabilities AVP shall not be present. The Result-Code shall be set to DIAMETER_SUCCESS. - If there is not any S-CSCF name assigned to a Public Identity within the IMS Subscription, the HSS may return information about the required S-CSCF capabilities, which enables the I-CSCF to select an S-CSCF. The Server-Capabilities AVP may be present. The HSS shall send the same server capability set that is sent in the user registration status response during the registration. If Server-Capabilities AVP is not present, the I-CSCF shall understand that any S-CSCF is suitable for the IMS Subscription. The Server-Name AVP shall not be present. The Experimental-Result-Code shall be set to DIAMETER_UNREGISTERED_SERVICE. - If it is not registered or unregistered, and the Public Identity has no terminating services related to the unregistered state and the request does not contain the Originating-Request AVP, the response shall contain Experimental-Result-Code set to DIAMETER_ERROR_IDENTITY_NOT_REGISTERED. If the HSS cannot fulfil the received request, e.g. due to database error, it shall set Result-Code to DIAMETER_UNABLE_TO_COMPLY. No S-CSCF name or S-CSCF capabilities shall be present in the response. 6.2 User data handling procedures 6.2.1 User Profile download As part of the registration procedure ( TSÊ23.228Ê[1]) S-CSCF obtains user data and service related information by means of the Cx-Put Resp operation (see 6.1.2). 6.2.2 HSS initiated update of User Information This procedure is initiated by the HSS to update at least one of the following user information in S-CSCF: - User profile information and/or - Charging information and/or - Allowed WAF and/or WWSF Identities and/or - SIP Digest authentication information in the S-CSCF. This procedure shall not be used by the HSS to add, delete, or update the value of the IMSI. This procedure corresponds to the functional level operation Cx-Update_Subscr_Data (see TSÊ23.228Ê[1]). This procedure is mapped to the commands Push-Profile-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.2.2.1 and 6.2.2.2 describe the involved information elements. Table 6.2.2.1: User Profile Update request Information element name Mapping to Diameter AVP Cat. Description Private User Identity / Private Service Identity (See 7.3 and 7.3a) User-Name M Private Identity. The HSS shall always send a Private Identity that is known to the S-CSCF based on an earlier SAR/SAA procedure. User profile (See 7.7) User-Data C Updated user profile (see clauses 6.5.2.1 and 6.6.1), with the format defined in clauseÊ7.7. It shall be present if the user profile is changed in the HSS. If the User-Data AVP is not present, the SIP-Auth-Data-Item or Charging-Information AVP or Allowed-WAF-WWSF-Identities AVP shall be present. Authentication Data (See 7.9) SIP-Auth-Data-Item C SIP Digest authentication information. It shall be present if the used authentication scheme is SIP Digest and when password change has occurred in the HSS. If the SIP-Auth-Data-Item AVP is not present, the Charging-Information or User-Data AVP or Allowed-WAF-WWSF-Identities AVP shall be present. See Table 6.3.6 for the contents of this information element. Charging Information (See 7.12) Charging-Information C Addresses of the charging functions. It shall be present if the charging addresses are changed in the HSS. If the Charging-Information AVP is not present, the SIP-Auth-Data-Item or User-Data AVP or Allowed-WAF-WWSF-Identities AVP shall be present. When this parameter is included, either the Primary-Charging-Collection-Function-Name AVP or the Primary-Event-Charging-Function-Name AVP shall be included. All other charging information shall be included if it is available. Routing Information (See 7.13) Destination-Host M It contains the name of the S-CSCF which originated the last update of the name of the multimedia server stored in the HSS for a given IMS Subscription. The address of the S-CSCF is the same as the Origin-Host AVP in the message sent from the S-CSCF. Allowed WAF and/or WWSF Identities (See 7.29) Allowed-WAF-WWSF-Identities C Addresses of the WAFs and/or WWSFs the subscription is allowing to use. It shall be present if the allowed WAF and/or WWSF identities are changed in the HSS. Table 6.2.2.2: User Profile Update response Information element name Mapping to Diameter AVP Cat. Description Result (See 7.6) Result-Code / Experimental-Result M This information element indicates the result of the update of User Profile in the S-CSCF. Result-Code AVP shall be used for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). Experimental-Result AVP shall be used for Cx/Dx errors. This is a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. 6.2.2.1 Detailed behaviour The HSS shall make use of this procedure to update the relevant user information to the S-CSCF. See clauses 6.5.2.1 and 6.6.1 for the rules of user profile updating. See clauseÊ6.5.2.3 for the rules of Charging Information update. See clauseÊ6.5.2.4 for the rules of SIP Digest Authentication Data update. See clauseÊ6.5.2.5 for the rules of Allowed WAF and/or WWSF Identities update. If there are multiple registered Private User Identities associated to the Public User Identity in the HSS, the HSS shall send only single request and select arbitrarily one of the Private User Identities and put it into the request. For updates of the profile of a Wildcarded Public Identity, the HSS shall send only one single request. That request shall contain the Wildcarded Public Identity. The SIP-Auth-Data-Item AVP and/or Charging-Information AVP and/or the User-Data AVP shall be present in the request. If the User-Data AVP is present in the request, the S-CSCF shall overwrite, for the Public Identities indicated in the User profile included in the request, current information with the information received from the HSS, except in the error situations detailed in table 6.2.2.1.1. If the Charging-Information AVP is present in the request, the S-CSCF shall replace the existing charging information with the information received from the HSS. The SIP-Auth-Data-Item AVP shall be present if the command is sent in order to update SIP Digest authentication information due to a password change. If the S-CSCF receives data that it can not recognise, unsupported user data in a part of the request where it may not be ignored or more data than it can accept, it shall return the corresponding error code to the HSS as indicated in table 6.2.2.1.1. The S-CSCF shall not overwrite the data that it already has to give service to the IMS Subscription. The HSS shall initiate a network-initiated de-registration procedure towards the S-CSCF with Deregistration-Reason set to SERVER_CHANGE, which will trigger the assignment of a new S-CSCF. If the HSS receives DIAMETER_ERROR_USER_UNKNOWN from the S-CSCF in the Push-Profile-Answer, then the HSS shall re-send the request using another arbitrarily selected registered Private Identity (if any). If restoration procedures are not supported, the HSS shall set the unknown Private User Identity's registration status to ""not registered""; this will allow the synchronization of the registration status in HSS and S-CSCF. NOTE: If restoration procedures are supported, restoration procedures will ensure synchronization of the registration status in HSS and S-CSCF, i.e. the S-CSCFÊcan either immediately retrieve the S-CSCF restoration information for the registered Public User Identity (sending SAR with Server Assignment Type set to NO_ASSIGNMENT), or wait for reception of a SIP request. Table 6.2.2.1.1 details the valid result codes that the S-CSCF can return in the response."
"Table 6.2.2.1.1: User information update response valid result codes Result-Code AVP value Condition DIAMETER_SUCCESS The request succeeded. DIAMETER_ERROR_NOT_SUPPORTED_USER_DATA The request failed. The S-CSCF informs the HSS that the received user information contained information, which was not recognised or supported by the S-CSCF due to unsupported S-CSCF capabilities. DIAMETER_ERROR_USER_UNKNOWN The request failed because the Private Identity is not found in S-CSCF. DIAMETER_ERROR_TOO_MUCH_DATA The request failed. The S-CSCF informs to the HSS that it tried to push too much data into the S-CSCF. DIAMETER_UNABLE_TO_COMPLY The request failed. 6.3 Authentication procedures This procedure is used between the S-CSCF and the HSS to exchange information to support the authentication between the end user and the home IMS network. The procedure is invoked by the S-CSCF, corresponds to the combination of the operations Cx-AV-Req and Cx-AV-Req-Resp (see TSÊ33.203Ê[3]) and is used: - To retrieve authentication vectors from the HSS. - To resolve synchronization failures between the sequence numbers in the UE and the HSS for authentication schemes that support this capability (e.g. IMS-AKA). - To promote the result of the NASS-level authentication to the IMS level. - To retrieve the IP-address secure binding information for GPRS-IMS-Bundled Authentication (GIBA) from the HSS. This procedure is mapped to the commands Multimedia-Auth-Request/Answer in the Diameter application specified in TSÊ29.229Ê[5]. Tables 6.3.1 through 6.3.7 detail the involved information elements. Table 6.3.1: Authentication Request Information element name Mapping to Diameter AVP Cat. Description Public User Identity (See 7.2) Public-Identity M This information element contains the Distinct Public User Identity of the user Private User Identity (See 7.3) User-Name M This information element contains the Private User Identity Number Authentication Items (See 7.10) SIP-Number-Auth-Items M This information element indicates the number of authentication vectors requested. Certain authentication schemes do not support more than one set of authentication vectors (e.g. SIP Digest, GIBA). Authentication Data (See 7.9) SIP-Auth-Data-Item M See Table 6.3.2 for the contents of this information element. S-CSCF Name (See 7.4) Server-Name M This information element contains the name (SIP URL) of the S-CSCF. Routing Information (See 7.13) Destination-Host C If the S-CSCF knows the HSS name this AVP shall be present. This information is available if the MAR belongs to an already existing registration, e.g. in case of the re-registration, where the HSS name is stored in the S-CSCF. The HSS name is obtained from the Origin-Host AVP, which is received from the HSS, e.g. included in the MAA command. This information may not be available if the command is sent in case of the initial registration. In this case the Destination-Host AVP is not present and the command is routed to the next Diameter node, e.g. SLF, based on the Diameter routing table in the client. Table 6.3.2: Authentication Data content in Authentication Request Information element name Mapping to Diameter AVP Cat. Description Authentication Scheme (See 7.9.2) SIP-Authentication-Scheme M This information element indicates the authentication scheme. See 3GPPÊTSÊ29.229Ê[5] for a list of values Authentication Context (See 7.9.7) SIP-Authentication-Context C This information element shall contain authentication-related information relevant for performing the authentication. It shall be absent for IMS-AKA authentication schemes. Authorization Information (See 7.9.4) SIP-Authorization C This information element shall only be present for a request due to an IMS-AKA synchronization failure. If present, only IMS-AKA authentication schemes are allowed. Table 6.3.3: Void Table 6.3.4: Authentication Request Response Information element name Mapping to Diameter AVP Cat. Description User Identity (See 7.2) Public-Identity C Public User Identity. It shall be present when the result is DIAMETER_SUCCESS. Private User Identity (See 7.3) User-Name C Private User Identity. It shall be present when the result is DIAMETER_SUCCESS. Number Authentication Items (See 7.10) SIP-Number-Auth-Items C This information element indicates the number of authentication vectors delivered in the Authentication Data information element. It shall be present when the result is DIAMETER_SUCCESS. For SIP Digest, NASS Bundled authentication and GIBA this AVP shall be set to a value of 1. Authentication Data (See 7.9) SIP-Auth-Data-Item C If the SIP-Number-Auth-Items AVP is equal to zero or it is not present, then this information element shall not be present. See Table 6.3.5 for the contents of this information element. Result (See 7.6) Result-Code / Experimental-Result M This information element indicates the result of the operation. It shall be mapped to Result-Code AVP for errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[31]). It shall be mapped to Experimental-Result AVP for Cx/Dx errors. This information element is mapped to a grouped AVP which contains the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. Table 6.3.5: Authentication Data information element content in Authentication Request Response Information element name Mapping to Diameter AVP Cat. Description Item Number (See 7.9.1) SIP-Item-Number C This information element shall only be present for IMS-AKA authentication schemes. This information element shall be present when there are multiple occurrences of the Authentication Data information element in the Authentication Request Response, and the order in which they should be processed is significant. In this scenario, Authentication Data information elements with a low Item Number information element value should be processed before Authentication Data information elements with a high Item Number information element value. Authentication Scheme (See 7.9.2) SIP-Authentication-Scheme M This information element indicates the authentication scheme. Authentication Information (See 7.9.3) SIP-Authenticate C This information element shall only be present for IMS-AKA authentication schemes. Authorization Information (See 7.9.4) SIP-Authorization C This information element shall only be present for IMS-AKA authentication schemes. Confidentiality Key (See 7.9.5) Confidentiality-Key C This information element shall be present for IMS AKA authentication schemes. It shall contain the confidentiality key. Integrity Key (See 7.9.6) Integrity-Key C This information element shall only be present for IMS-AKA authentication schemes. This information element shall contain the integrity key. Digest Authenticate (See 7.9.8) SIP-Digest-Authenticate C This information element shall only be present for SIP Digest authentication scheme. See Table 6.3.7 for contents of this grouped AVP. Line Identifier (See 7.9.9) Line-Identifier C This information element shall only be present for NASS Bundled authentication scheme. This information element contains fixed broadband access line identifier associated to the user. This information element can be repeated. Framed IP Address (See 7.9.10) Framed-IP-Address C This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If the IP Address of the User is an IPv4 address, this AVP shall be included. Framed IPv6 Prefix (See 7.9.11) Framed-IPv6-Prefix C This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If the IP Address of the User is an IPv6 address, this AVP shall be included. Framed Interface Id (See 7.9.12) Framed-Interface-Id C This information element shall only be present for GPRS-IMS-Bundled authentication scheme. If and only if the IP Address of the User is an IPv6 address and the Framed-IPv6-Prefix AVP alone is not unique for the user this AVP shall be included. Table 6.3.6: Void Table 6.3.7: Digest Authenticate information element content Ð Response for SIP Digest Information element name Mapping to Diameter AVP Cat. Description Digest Realm (See 7.9.8.1) Digest-Realm M This information element corresponds to the Realm parameter as defined in IETFÊRFCÊ7616Ê[33]. Digest Algorithm (See 7.9.8.3) Digest-Algorithm O This information element contains the algorithm as defined in IETFÊRFCÊ7616Ê[33]. If this information element is present, it shall contain ""MD5"". If neither the Digest Algorithm information element nor the Alternate Digest Algorithm information element are present, then the value ""MD5"" is assumed. (NOTEÊ1) Digest QoP (See 7.9.8.4) Digest-QoP M This information element contains the QoP as defined in IETFÊRFCÊ7616Ê[33]. This information element shall be set to a value of ""auth"" by the HSS. Digest HA1 (See 7.9.8.5) Digest-HA1 M This information element contains the H(A1) for algorithm ""MD5"" as defined in IETFÊRFCÊ7616Ê[33]. (NOTEÊ1) Alternate Digest Algorithm (See 7.9.8.6) Alternate-Digest-Algorithm O This information element contains the algorithm as defined in IETFÊRFCÊ7616Ê[33]. (NOTEÊ2) Alternate Digest HA1 (See 7.9.8.6) Alternate-Digest-HA1 O This information element contains the H(A1), as defined in IETFÊRFCÊ7616Ê[33]. (NOTEÊ2) NOTEÊ1: The MD5 algorithm is only supported for backward compatibility and may only be provided within the Digest Algorithm information element. NOTEÊ2: If the Alternate Digest HA1 information element is present, the Digest HA1 information element shall also be present and the Digest HA1 information element shall contain the MD5 hash. The algorithm of the Alternate Digest HA1 information element shall be determined by the Alternate Digest Algorithm information element. Table 6.3.8: Void Table 6.3.9: Void 6.3.1 Detailed behaviour The HSS shall, in the following order (in case of an error in any of the steps the HSS shall stop processing and return the corresponding error code, see TSÊ29.229Ê[5]): 1. Check that the Private User Identity and the Public User Identity exist in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 2. Check that the Public User Identity matches a distinct Public User Identity in the HSS. If it doesn't, the Experimental-Result-Code shall be set to DIAMETER_ERROR_USER_UNKNOWN. 3. Check whether the Private and Public User Identities in the request are associated in the HSS. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_IDENTITIES_DONT_MATCH. 4. Check the authentication scheme indicated in the request, and - if it is ""Unknown"", check the authentication scheme stored in HSS. If it is neither NASS-Bundled authentication nor SIP Digest authentication, Experimental-Result-Code shall be set to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED. - if not, check that the authentication scheme indicated in the request is supported. If not Experimental-Result-Code shall be set to DIAMETER_ERROR_AUTH_SCHEME_NOT_SUPPORTED. This step is only applicable for IMS-AKA authentication. If the request indicates there is a synchronization failure, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS: - If they are identical the HSS shall process AUTS as described in TSÊ33.203Ê[3] and return the requested authentication information. The Result-Code shall be set to DIAMETER_SUCCESS. 5. Check the registration status of the Public User Identity received in the request: - If it is registered, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS: - If they are different, the HSS shall overwrite the S-CSCF name. If IMS restoration procedures are supported and the S-CSCF reassignment pending flag is set, the HSS shall reset the flag and keep the S-CSCF restoration information associated with the Public User Identity. The HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity's authentication pending flag which is specific to the Private User Identity received in the request. The Result-Code shall be set to DIAMETER_SUCCESS. - If they are identical, the HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. The Result-Code shall be set to DIAMETER_SUCCESS. - If it is unregistered (i.e. registered as a consequence of an originating or terminating request or there is an S-CSCF keeping the user profile stored) or not registered, the HSS shall compare the S-CSCF name received in the request to the S-CSCF name stored in the HSS: - If they are different or if there is no S-CSCF name stored in the HSS for any Public User Identity of the IMS subscription, the HSS shall store the S-CSCF name. The HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity's authentication pending flag which is specific to the Private User Identity which was received in the request. The Result-Code shall be set to DIAMETER_SUCCESS. - If they are identical, the HSS shall download SIP-Auth-Data-Item stored up to a maximum specified in SIP-Number-Auth-Items received in the command Multimedia-Auth-Request. If authentication scheme is neither NASS-Bundled nor GIBA, the HSS shall set the Public User Identity's authentication pending flag which is specific to the Private User Identity that was received in the request. The Result-Code shall be set to DIAMETER_SUCCESS. Exceptions to the cases specified here shall be treated by HSS as error situations, the Result-Code shall be set to DIAMETER_UNABLE_TO_COMPLY. No authentication information shall be returned. 6.4 User identity to HSS resolution The User identity to HSS resolution mechanism enables the I-CSCF and the S-CSCF to find the identity of the HSS, that holds the subscriber data for a given Public Identity when multiple and separately addressable HSSs have been deployed by the network operator. The resolution mechanism is not required in networks that utilise a single HSS. An example for a single HSS solution is server farm architecture. The resolution mechanism described in TSÊ23.228Ê[1] shall use a Subscription Locator Function (SLF) or a Diameter Proxy Agent. The I-CSCF and the S-CSCF accesses the SLF via the Dx interface. The Dx interface shall always be used in conjunction with the Cx interface. The Dx interface shall be based on the Diameter base protocol as specified in IETFÊRFCÊ6733Ê[31]. The SLF functionality shall use the routing mechanism provided by an enhanced Diameter redirect agent. The SLF or the Diameter Proxy Agent shall be able to determine the HSS identity. To get the HSS identity the I-CSCF and the S-CSCF shall send the Cx request normally destined to the HSS to a pre-configured Diameter address/name. - If this Cx Request is received by an SLF (acting as a Diameter redirect agent), the SLF shall determine the HSS identity and sends to the I-CSCF or S-CSCF a notification of redirection towards the HSS identity, in response to the Cx request. Multiple HSS identities may be included in the response, as specified in IETFÊRFCÊ6733Ê[31]. In such a case, the I-CSCF or the S-CSCF shall send the Cx Request to the first HSS identity in the ordered list received in the Cx Response from the SLF. If the I-CSCF or S-CSCF does not receive a successful response to the Cx Request, the I-CSCF or S-CSCF shall send a Cx Request to the next HSS identity in the ordered list. This procedure shall be repeated until a successful response from an HSS is received. - If this Cx Request is received by the Diameter Proxy Agent, the Diameter Proxy Agent shall determine the HSS identity based on the provided user identity and - if the Diameter load control mechanism is supported (see IETFÊIETFÊRFCÊ8583Ê[29]) - optionally also based on previously received load values from Load AVPs of type HOST. The Diameter Proxy Agent shall then forward the Cx request directly to the determined HSS. The I-CSCF and S-CSCF shall determine the HSS identity from the response to the Cx request received from the HSS. While the I-CSCF is stateless, the S-CSCF shall store the HSS identity/name/Realm, as specified in TSÊ23.228Ê[1] and shall use it in further Cx requests associated to the same IMS Public Identity. In networks where the use of the user identity to HSS resolution mechanism is required, each I-CSCF and S-CSCF shall be configured with the address/name of the SLF or the Diameter Proxy Agent to enable use of these resolution mechanisms. 6.5 Implicit registration Implicit registration is the mechanism by which a user is allowed to register simultaneously more than one of his/her Public User Identities. The HSS knows the identities that are to be implicitly registered when it receives the indication of the registration of an individual identity. What follows is an extension of the affected basic procedures. 6.5.1 S-CSCF initiated procedures The result of the S-CSCF initiated procedures affects all the Public User Identities that are configured in the HSS to be in the same implicitly registered Public User Identity set with the targeted individual Public User Identity. Where the S-CSCF initiated procedure affects the Registration state of the targeted Public User Identity, the Registration states of the Public User Identities in the associated implicitly registered Public User Identity set are affected in the same way. 6.5.1.1 Registration The notification of a registration of a Public User Identity implies the registration of the corresponding implicitly registered Public User Identity set. The user information downloaded in the response contains the Public User Identities of the implicitly registered Public User Identity set with the associated service profiles. This allows the S-CSCF to know which Public User Identities belong to the implicitly registered Public User Identity set. The S-CSCF shall take from the set of implicitly registered Public User Identities the first identity which is not barred, and use this as the default Public User Identity. The default Public User Identity shall be a distinct Public User Identity. 6.5.1.2 De-registration The de-registration of a Public User Identity implies the de-registration of the corresponding implicitly registered Public User Identity set, both in the HSS and in the S-CSCF. The S-CSCF shall include in the request a single Public User Identity to deregister all the Public User Identities that belong to the corresponding implicitly registered Public User Identity set. The de-registration of a Private User Identity implies the de-registration of all the corresponding Public User Identities, both in the HSS and in the S-CSCF. 6.5.1.3 Authentication Setting the authentication pending flag for a Public User Identity implies setting the authentication pending flag for each corresponding implicitly registered Public User Identity in the HSS. 6.5.1.4 Downloading the user profile If the S-CSCF requests to download a user profile from HSS, the user profile in the response shall contain the Public User Identities of the corresponding implicitly registered Public User Identity set with the associated service profiles. 6.5.1.5 Initiation of a session to a non-registered user The change of a Public User Identity to the Unregistered state due to the initiation of a session from/to a Public Identity that was in Not Registered state and the opposite change from Unregistered state to Not Registered state implies the same change for all the Public User Identities in the same Implicit Registration Set. 6.5.2 HSS initiated procedures 6.5.2.1 Update of User Profile A request sent by the HSS to update the user profile shall include only the Public User Identities of the implicitly registered Public User Identity set, with the associated service profiles (even if not updated). If other Public User Identities not associated with the implicitly registered Public User Identity set are affected, they shall be downloaded in separate commands. This procedure shall be used by the HSS to add a newly provisioned or Not Registered Public User Identity or Identities to an existing implicitly registered Public User Identity set that is in the state Registered or Unregistered. The added Public User Identity gets the registration state of the set it is added to. The HSS shall use this procedure if a Public User Identity or Identities are removed from the implicitly registered Public User Identity set that is in a state Registered or Unregistered. In practise, this is done by sending a PPR for the set without the removed identities. The S-CSCF shall remove all information stored in the S-CSCF for the removed identities. The HSS shall not use this procedure if there is no Public User Identities left in the implicitly registered Public User Identity set after the removal. In that case HSS shall use the RTR command instead. The HSS shall not use this procedure to change the default Public User Identity of the implicitly registered Public User Identity set that is in a state Registered. In that case the HSS shall use the RTR command to de-register the Public User Identity set. When a change of the Reference Location Information occurs (e.g.. a change of authorization), the HSS may use a network initiated de-registration instead of this procedure, and may indicate to the S-CSCF that the de-registration is sent due to change of Reference Location Information. Moving of a Public User Identity or Identities from one implicitly registered Public User Identity set to another set shall be done in two steps: First the identity or identities are removed from the ""old"" set as described above, then the identity or identities are added to the ""new"" set as described above. 6.5.2.2 De-registration A request sent by the HSS to de-register any of the identities included in an implicitly registered Public User Identity set shall affect all the Public User Identities of the deregistered set. The de-registration of a Private User Identity implies the de-registration of all the corresponding Public User Identities, both in the HSS and in the S-CSCF. 6.5.2.3 Update of the Charging information A request sent by the HSS to update the charging information shall include the Private User Identity for whom the charging information changed. If corresponding Public Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) and charging information is changed, the HSS should immediately push this information to the S-CSCF. 6.5.2.4 Update of the SIP Digest Authentication Data A request sent by the HSS to update the authentication data shall include the Private User Identity for whom the authentication data changed. If corresponding Public Identity is registered and authentication data is changed, the HSS should immediately push this information to the S-CSCF. If corresponding Public Identity is either not registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored), authentication pending flag is set and authentication data is changed, the HSS should immediately push this information to the S-CSCF. 6.5.2.5 Update of the Allowed WAF and/or WWSF Identities A request sent by the HSS to update the WAF and/or WWSF identities allowed for the subscription shall include the Private User Identity for whom this information changed. If corresponding Public Identity is registered and allowed WAF and/or WWSF identities are changed, the HSS should immediately push this information to the S-CSCF. 6.6 Download of the Relevant User Profile and Charging Information and Allowed WAF and/or WWSF Identities The download of the relevant user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities from the HSS to the S-CSCF depends on whether the user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities are already stored in the S-CSCF. If the SiFC feature is supported by the HSS and S-CSCF, the HSS shall download the identifiers of the shared iFC sets. If either the HSS or the S-CSCF does not support the SiFC feature, the HSS shall download the complete iFCs, and SiFC identifiers shall not be downloaded by the HSS. The SiFC feature is defined in TSÊ29.229Ê[5]. If User-Data-Already-Available is set to USER_DATA_NOT_AVAILABLE the HSS shall download the requested user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities. If the Public User Identity in the request is included in an implicitly registered Public User Identity set, the HSS shall include in the response the service profiles associated with all Public User Identities within the implicitly registered Public User Identity set to which the received Public User Identity belongs. If User-Data-Already-Available is set to USER_DATA_ALREADY_AVAILABLE, the HSS should not return any user profile or charging information data or allowed WAF and/or WWSF identities. The HSS may override User-Data-Already-Available set to USER_DATA_ALREADY_AVAILABLE and download the user profile, charging information and, if supported and part of subscription, allowed WAF and/or WWSF identities. 6.6.1 HSS initiated update of User Profile The request to update the user profile in the S-CSCF includes only the Public User Identities of the implicitly registered Public User Identity set with the associated service profiles. See 6.5.2.1. If the Public Identity is registered or unregistered (i.e. registered as a consequence of an originating or terminating request or there is a S-CSCF keeping the user profile stored) and there are changes in the user profile, the HSS should immediately push the complete user profile to the S-CSCF. 6.6.2 S-CSCF operation At deregistration of a Public User Identity, the S-CSCF shall store the user information if it sends Server-Assignment-Request command including Server-Assignment-Type AVP set to value USER_DEREGISTRATION_STORE_SERVER_NAME or TIMEOUT_DEREGISTRATION_STORE_SERVER_NAME and the HSS responds with DIAMETER_SUCCESS. Otherwise the S-CSCF shall not keep user information. 6.7 S-CSCF Assignment The list of mandatory and optional capabilities received by an I-CSCF from the HSS allows operators to distribute users between S-CSCFs, depending on the different capabilities (e.g. features, role, geographical location) that each S-CSCF may have. Alternatively, an operator has the possibility to steer users to certain S-CSCFs. The operator shall define (possibly based on the functionality offered by each S-CSCF installed in the network) the exact meaning of the S-CSCF mandatory and optional capabilities available in his network. It is an operator task to allocate a unique value toÊrepresent a singleÊcapability (e.g. support of ""wildcarded PSI"") orÊa set of capabilities (e.g. support of ""alias"" and ""Shared IFC sets"" and ""wildcarded PSI"") and to use these values to identify capabilities that are mandatory and/or optional to support for a given subscription. It is a configuration task for the operator to ensure that the I-CSCF has a correct record of the capabily values received from the HSS for each S-CSCF available in his network. The I-CSCF and the HSS do not need to know the semantic of these values. This semantic is exclusively an operator issue. As a first choice, the I-CSCF shall select an S-CSCF that has all the mandatory and optional capabilities for the user. Only if that is not possible shall the I-CSCF apply a 'best-fit' algorithm. If more than one S-CSCF is identified that supports all mandatory capabilities the I-CSCF may then consider optional capabilities in selecting a specific S-CSCF. The 'best-fit' algorithm is implementation dependent and out of the scope of this specification. It is the responsibility of the operator to ensure that there are S-CSCFs which have mandatory capabilities indicated by the HSS for any given user. However, configuration errors may occur. If such errors occur and they prevent the I-CSCF from selecting an S-CSCF which meets the mandatory capabilities indicated by the HSS, the I-CSCF shall inform the operator via the O&M subsystem. As an alternative to selecting an S-CSCF based on the list of capabilities received from the HSS, it is possible to steer users to certain S-CSCFs. To do this, the operator may include one or more S-CSCF names as part of the capabilities of the user profile. The reason for the selection (e.g. all the users belonging to the same company/group could be in the same S-CSCF to implement a VPN service) and the method of selection are operator issues and out of the scope of this specification. If this alternative is chosen, the HSS shall include Server-Name AVPs in the Server-Capabilities AVP and should not include Mandatory-Capability AVPs or Optional-Capability AVPs in the Server-Capabilities AVP, and the I-CSCF when receiving Server-Name AVPs within the Server-Capabilities AVP shall discard any Mandatory-Capability AVP and any Optional-Capability AVP received within the Server-Capabilities AVP. The following table is a guideline for operators that records S-CSCF capabilities that need to be supported by an S-CSCF in order to serve a user or a service (identified by a Public User Identity or Public Service Identity), that cannot be served by an S-CSCF which is only compliant to a previous 3GPP release. Table 6.7: Guidelines for S-CSCF Capabilities Capability Mandatory or Optional (NOTE 1) Description Support of ""Wildcarded PSI"" M This capability indicates that the assigned S-CSCF shall support the handling of Wildcarded PSIs. Support of ""OrigUnreg SPT"" M This capability indicates that the assigned S-CSCF shall be able to process iFCs with a Session Case ""Originating_Unregistered"" received from the HSS in the user profile. Support of ""OrigCDIV SPT"" M This capability indicates that the assigned S-CSCF shall be able to process iFCs with a Session Case ""Originating_CDIV"" received from the HSS in the user profile. Support of ""Shared iFC sets"" O This capability indicates that the assigned S-CSCF may support the ""SiFC"" feature defined in the 3GPPÊTSÊ29.229Ê[5]. Support of ""Display Name"" O This capability indicates that the assigned S-CSCF may support the handling of ""Display Name"". The behaviour of the S-CSCF related to this missing data is the same as if the HSS did not send the Display Name. Support of ""Alias"" O This capability indicates that the assigned S-CSCF may support the ""AliasInd"" feature defined in 3GPPÊTSÊ29.229Ê[5]. Support of ""SIP Digest Authentication"" M This capability indicates that the assigned S-CSCF shall support the handling of SIP Digest Authentication. Support of ""NASS Bundled Authentication"" M This capability indicates that the assigned S-CSCF shall support the handling of NASS Bundled Authentication. Support of ""Wildcarded IMPUs"" M This capability indicates that the assigned S-CSCF shall support the handling of Wildcarded Public User Identities. Support of ""Loose-Route "" M This capability indicates that the assigned S-CSCF shall support the loose-route mechanism. Support of ""Service Level Trace"" M This capability indicates that the assigned S-CSCF shall support the Service Level Trace mechanism. Support of ""Priority Service"" M This capability indicates that the S-CSCF shall support a network default pre-configured namespace (e.g. ""wps"") and the associated Service Priority Level. See IETFÊRFCÊ4412Ê[22] and 3GPP TSÊ24.229Ê[8]. Support of ""Extended Priority "" (NOTE 2) M This capability indicates that the S-CSCF shall support the Priority Namespaces and their associated Priority Levels. See IETF RFC 4412Ê[22] and 3GPP TSÊ24.229Ê[8]. Support of ""Early IMS Security"" M This capability indicates that the assigned S-CSCF shall support GIBA. Support of ""Reference Location"" M This capability indicates that the assigned S-CSCF shall support the handling of reference location as defined in 3GPP TSÊ23.167Ê[23]. Support of ""Priviledged-Sender"" M This capability indicates that the S-CSCF shall support priviledged sender. See 3GPP TSÊ24.229Ê[8]. Support of ""IMSI"" M This capability indicates that the assigned S-CSCF shall support the handling of the IMSI. Support of ""Maximum Number of allowed simultaneous registrations"" M This capability indicates that the assigned S-CSCF shall support the handling of maximum number of allowed simultaneous registrations per user as received from the HSS. NOTE 1: Mandatory (M) corresponds to a Mandatory Capability that shall be supported by the assigned S-CSCF for a given user. The I-CSCF shall not select an S-CSCF that does not meet a mandatory capability. The selection of a S-CSCF not supporting this capability would lead to an unspecified network behaviour. Optional (O) corresponds to an Optional Capability that may be supported by the assigned S-CSCF for a given user. The selection of a S-CSCF that would not support this capability will not significantly affect the network behaviour. NOTE 2: Support of ""Extended Priority "" is backward compatible with continued support of the ""Priority Service"". 7 Information element contents 7.1 Visited Network Identifier This information element contains the domain name of the visited network. 7.2 Public User Identity This information element contains the Public User Identity. For definition of a Public User Identity, see TSÊ23.003Ê[17]. When GPRS-IMS-Bundled Authentication (GIBA) is used, a Temporary Public User Identity is derived from the IMSI used for bearer network access according to the rules in TSÊ23.003Ê[17]. 7.2a Public Service Identity This information element contains a Public Service Identity (PSI) that is hosted by an application server. For definition of a PSI, see TSÊ23.003Ê[17]. 7.2b Wildcarded Public Identity This information element contains a Wildcarded PSI that is hosted by an application server or a Wildcarded Public User Identity. For definition of a Wildcarded PSI and a Wildcarded Public User Identity, see TSÊ23.003Ê[17]. 7.2c Void 7.3 Private User Identity This information element contains the Private User Identity. For definition of a Private User Identity, see TSÊ23.003Ê[17]. When GPRS-IMS-Bundled Authentication (GIBA) is used, the Private User Identity is derived from the IMSI as specified in TSÊ33.203Ê[3]. 7.3a Private Service Identity This information element contains the Private Service Identity. For definition of a Private Service Identity, see TSÊ23.003Ê[17]. 7.4 S-CSCF Name This information element contains the S-CSCF Name of the S-CSCF assigned to an IMS Subscription. For definition of a S-CSCF Name, see TSÊ23.008Ê[18]. 7.4a AS Name This information element contains the AS Name of the AS hosting a Public Service Identity. For definition of AS Name, see TSÊ23.008Ê[18]. 7.5 S-CSCF Capabilities This information element carries information to assist the I-CSCF during the process of selecting an S-CSCF for a certain IMS Subscription. 7.6 Result This information element contains result of an operation. See TSÊ29.229Ê[5] for the possible values. 7.7 User Profile This information element contains the user profile in XML format. The user profile XML shall be valid against the user profile XML schema defined in Annex E. Annex B specifies the UML logical model of the user profile downloaded via the Cx interface. Annex D contains and informative, high level representation, of the wire representation of user profile data. 7.8 Server Assignment Type Indicates the type of server assignment. See TSÊ29.229Ê[5] for the list of existing values. 7.9 Authentication Data This information element is composed of the following sub-elements. 7.9.1 Item Number This information element indicates the order in which the authentication vectors are to be consumed. See TSÊ29.229Ê[5] for coding details. 7.9.2 Authentication Scheme This information element contains the authentication scheme, which is used to encode the authentication parameters. See TSÊ29.229Ê[5] for a list of values. 7.9.3 Authentication Information This information element is used to convey the challenge and authentication token used during the authentication procedure, see TSÊ33.203Ê[3] for more information. See TSÊ29.229Ê[5] for coding details. 7.9.4 Authorization Information This information element is used, in an authentication request, to indicate a failure of synchronization. In a response, it is used to convey the expected response to the challenge used to authenticate the user, see TSÊ33.203Ê[3] for more information. See TSÊ29.229Ê[5] for coding details. 7.9.5 Confidentiality Key This information element contains the confidentiality key, see TSÊ33.203Ê[3] for more information. See TSÊ29.229Ê[5] for coding details. 7.9.6 Integrity Key This information element contains the integrity key, see TSÊ33.203Ê[3] for more information. See TSÊ29.229Ê[5] for coding details. 7.9.7 Authentication Context his information element contains authentication-related information relevant for performing the authentication but that is not part of the SIP authentication headers. Some mechanisms (e.g. PGP, digest with quality of protection set to ""auth-int"" defined in IETFÊRFCÊ7616Ê[33], digest with predictive nonces or sip access digest) request that part or the whole SIP request (e.g. the SIP method) is passed to the entity performing the authentication. In such cases the SIPAuthentication-Context AVP shall be carrying such information. See TSÊ29.229Ê[5] for coding details. 7.9.8 Digest Authenticate This information element is composed of the following sub-elements. 7.9.8.1 Digest Realm This information element is part of the Digest authentication challenge, and corresponds to the Realm parameter as defined in IETFÊRFCÊ3261Ê[11]. This information element is used to convey the Realm to the S-CSCF during the SIP Digest authentication procedure. See TSÊ29.229Ê[5] for coding details. 7.9.8.2 Void 7.9.8.3 Digest Algorithm This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. See TSÊ29.229Ê[5] for coding details. 7.9.8.4 Digest QoP This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. It provides the Quality of Protection indication and has an effect on the digest computation. See TSÊ29.229Ê[5] for coding details. 7.9.8.5 Digest HA1 This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. See TSÊ29.229Ê[5] for coding details. 7.9.8.6 Alternate Digest Algorithm This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. See TSÊ29.229Ê[5] for coding details. 7.9.8.7 Alternate Digest HA1 This information element is part of the Digest authentication challenge, defined in IETFÊRFCÊ7616Ê[33]. See TSÊ29.229Ê[5] for coding details. 7.9.9 Line Identifier This information element contains the line identifier of the user's network termination. See TSÊ29.229Ê[5] for coding details. 7.9.10 Framed IP Address See TSÊ29.229Ê[5] for more information. 7.9.11 Framed IPv6 Prefix See TSÊ29.229Ê[5] for more information. 7.9.12 Framed Interface Id See TSÊ29.229Ê[5] for more information. 7.10 Number Authentication Items This information element contains the number of authentication vectors requested or delivered. 7.11 Reason for de-registration This information element contains the reason for a de-registration procedure. 7.12 Charging information Addresses of the charging functions. See TSÊ29.229Ê[5]. 7.13 Routing information Information to route requests. 7.14 Type of authorization Type of authorization requested by the I-CSCF. See TSÊ29.229Ê[5] for a list of values. 7.15 Void Void 7.16 User Data Already Available This information element indicates to the HSS if the user profile is already available in the S-CSCF. See TSÊ29.229Ê[5] for a list of values. 7.17 Associated Private Identities This information element indicates to the S-CSCF the Private Identities, which belong to the same IMS Subscription as the Private Identity received in the request command. See TSÊ29.229Ê[5]. 7.18 Originating-Request This information element indicates to the HSS that the request is related to an originating SIP message. See 3GPP 29.229Ê[5]. 7.19 User Authorization Request Flags This information element carries the following indication (see 3GPP 29.229Ê[5] for coding details): - IMS Emergency Registration. 7.20 Loose-Route Indication This information element indicates to the S-CSCF that the loose-route mechanism shall be applied to the public identities contained in the user profile received from the HSS. See TSÊ29.229Ê[5]. This information is static data for the duration of the subscription or the validity of the IMS identity."
"Modification of this data result in Network Initiated Deregistration (SERVER_CHANGE); see clauseÊ6.1.3.1. 7.21 S-CSCF Restoration Information This information element contains information for the S-CSCF to handle traffic for a registered user. It is associated with the Private User Identity and the Implicit Registration Set that is affected by the SAR request. See TSÊ29.229Ê[5] for the contents of this information element. 7.22 Associated Registered Private Identities This information element indicates to the S-CSCF the Registered Private Identities, which were registered with the Public Identity received in the request command. See TSÊ29.229Ê[5]. 7.23 Multiple Registration Indication This information element indicates to the HSS that this is related to a multiple registration. See TSÊ29.229Ê[5]. 7.24 Session-Priority This information element indicates the session's priority level to the HSS. See TSÊ29.229Ê[5]. 7.25 Identities with Emergency Registration This information element indicates to the HSS a list of pairs of Private / Public Identities that are emergency registered. See TSÊ29.229Ê[5]. 7.26 Priviledged-Sender Indication This information element indicates to the S-CSCF that the Private User Identity shall be considered as a priviledged sender, as described in TSÊ24.229Ê[8]. 7.27 LIA Flags This information element carries the following indications. See TSÊ29.229Ê[5] for coding details. - PSI Direct Routing Indication 7.28 Server Assignment Request Flags This information element carries the following indication (see 3GPP 29.229Ê[5] for coding details): - P-CSCF Restoration Indication 7.29 Allowed WAF and/or WWSF Identities Addresses of the WebRTC Authentication Functions and/or WebRTC Web Server Functions allowed for a subscription. See TSÊ33.203Ê[3]. 7.30 RTR Flags This information element carries the following indications. See TSÊ29.229Ê[5] for coding details. - Reference Location Information change 7.31 Failed-PCSCF This information element indicates to the HSS the address of a failed P-CSCF, as detected by the S-CSCF. 8 Error handling procedures 8.1 Registration error cases This clause describes the handling of error cases, which can occur during the registration process. If the new and previously assigned S-CSCF names sent in the Multimedia-Auth-Request command are different and the Multimedia-Auth-Request is not indicating synchronisation failure (i.e. the request does not contain auts parameter), then the HSS shall overwrite the S-CSCF name. If the new and previously assigned S-CSCF names sent in a command other than the Multimedia-Auth-Request command are different and the S-CSCF reassignment pending flag is not set, then the HSS shall not overwrite the S-CSCF name; instead it shall send a response to the S-CSCF indicating an error. 8.1.1 Cancellation of the old S-CSCF It is possible that in certain situations the HSS receives a Multimedia-Auth-Request (MAR) command including a S-CSCF name, which is not the same as the previously assigned S-CSCF for the user. This can happen e.g. in case the new S-CSCF is selected due to a failure in the re-registration if the previously assigned S-CSCF does not respond to REGISTER message sent from the I-CSCF after a timeout. In this case, the new S-CSCF is assigned for the user and if registrations in the previously assigned S-CSCF exist for the user, these registrations in the old S-CSCF are handled locally in the old S-CSCF, e.g. re-registration timers in the old S-CSCF shall cancel the registrations. Additionally, the HSS should de-register the registrations in the old S-CSCF by using the Registration-Termination-Request command. In this case, the HSS shall first check whether the deregistration is really required by comparing the Diameter client address of the newly assigned S-CSCF received in the MAR command to the Diameter client address stored in the HSS. If the Diameter client addresses match, the deregistration shall not be initiated. Otherwise the deregistration should be initiated for all the registered Public User Identities for the corresponding IMS Subscription. HSS shall check whether IMS Restoration Procedures are supported to perform deregistration: - If supported, Registration-Termination-Request shall be sent for all Public User Identities (with their associated Private User Identities), with Deregistration-Reason AVP value set to NEW_SERVER_ASSIGNED. - Otherwise, Registration-Termination-Request shall be sent with different Deregistration-Reason AVP values, in the following order: 1. Deregistration-Reason AVP value set to NEW_SERVER_ASSIGNED, for the Public User Identity (with its associated Private User Identity), which is registered in the new S-CSCF. 2. Deregistration-Reason AVP value set to SERVER_CHANGE, for the user Public User Identities (with their associated Private User Identities), which are not yet registered in the new S-CSCF. 8.1.2 Error in S-CSCF name If the S-CSCF name sent in the Server-Assignment-Request command and the previously assigned S-CSCF name stored in the HSS are different and the S-CSCF reassignment pending flag is not set, then the HSS shall not overwrite the S-CSCF name. If the Server Assignment Type indicates NO_ASSIGNMENT, the HSS shall send a response to the S-CSCF with Result-Code value set to DIAMETER_UNABLE_TO_COMPLY. For all other Server Assignment Types, the HSS shall send a response to the S-CSCF with Experimental-Result-Code value set to DIAMETER_ERROR_IDENTITY_ALREADY_REGISTERED. If the S-CSCF name sent in the Server-Assignment-Request command and the previously assigned S-CSCF name stored in the HSS are different and IMS Restoration Procedures are supported and the S-CSCF reassignment pending flag is set, then the HSS shall allow overwriting of the S-CSCF name and proceed with the processing of the SAR command as defined in clauseÊ6.1.2. 8.1.3 Error in S-CSCF assignment type If the Server-Assignment-Type in the Server-Assignment-Request command sent by the S-CSCF to the HSS is not allowed (i.e if the Server-Assignment-Type is not applicable based on the user state or it is not applicable based on the user identity type), the HSS shall send a response to the S-CSCF with the Experimental-Result-Code value set to DIAMETER_ERROR_IN_ASSIGNMENT_TYPE. 9 Protocol version identification See TSÊ29.229Ê[5]. 10 Operational Aspects See TSÊ29.229Ê[5]. Annex A (normative): Mapping of Cx operations and terminology to Diameter A.1 Introduction This appendix gives mappings from Cx to Diameter protocol elements. Diameter protocol elements are defined in TSÊ29.229Ê[5]. A.2 Cx message to Diameter command mapping The following table defines the mapping between stage 2 operations and Diameter commands: Table A.2.1: Cx message to Diameter command mapping Cx message Source Destination Command-Name Abbreviation Cx-Query + Cx-Select-Pull I-CSCF HSS User-Authorization-Request UAR Cx-Query Resp + Cx-Select-Pull Resp HSS I-CSCF User-Authorization-Answer UAA Cx-Put + Cx-Pull S-CSCF HSS Server-Assignment-Request SAR Cx-Put Resp + Cx-Pull Resp HSS S-CSCF Server-Assignment-Answer SAA Cx-Location-Query I-CSCF HSS Location-Info-Request LIR Cx-Location-Query Resp HSS I-CSCF Location-Info-Answer LIA Cx-AuthDataReq S-CSCF HSS Multimedia-Authentication-Request MAR Cx-AuthDataResp HSS S-CSCF Multimedia-Authentication-Answer MAA Cx-Deregister HSS S-CSCF Registration-Termination-Request RTR Cx-Deregister Resp S-CSCF HSS Registration-Termination-Answer RTA Cx-Update_Subscr_Data HSS S-CSCF Push-Profile-Request PPR Cx-Update_Subscr_Data Resp S-CSCF HSS Push-Profile-Answer PPA A.3 Cx message parameters to Diameter AVP mapping The following table gives an overview about the mapping: Table A.3.1: Cx message parameters to Diameter AVP mapping Cx parameter AVP Name Visited Network Identifier Visited-Network-Identifier Public Identity Public-Identity Private Identity User-Name S-CSCF Name Server-Name AS Name S-CSCF capabilities Server-Capabilities Result Result-Code Experimental-Result-Code User profile User-Data Server Assignment Type Server-Assignment-Type Authentication data SIP-Auth-Data-Item Item Number SIP-Item-Number Authentication Scheme SIP-Authentication-Scheme Authentication Information SIP-Authenticate Authorization Information SIP-Authorization Confidentiality Key Confidentiality-Key Integrity Key Integrity-Key Number Authentication Items SIP-Number-Auth-Items Reason for de-registration Deregistration-Reason Charging Information Charging-Information Routing Information Destination-Host Type of Authorization Authorization-Type Associated Private Identities Associated-Identities Digest Authenticate SIP-Digest-Authenticate Digest Realm Digest-Realm Digest Algorithm Digest-Algorithm Digest QoP Digest-QoP Digest HA1 Digest-HA1 Alternate Digest Algorithm Alternate-Digest-Algorithm Alternate Digest HA1 Alternate-Digest-HA1 Line Identifier Line-Identifier Wildcarded Public Identity Wildcarded-Public Identity Loose-Route Indication Loose-Route-Indication S-CSCF Restoration Information SCSCF-Restoration-Info Multiple Registration Indication Multiple-Registration-Indication Priviledged-Sender Indication Priviledged-Sender-Indication LIA Flags LIA-Flags Allowed WAF and/or WWSF Identities Allowed-WAF-WWSF-Identities A.4 Message flows The following message flows give examples regarding which Diameter messages shall be sent in scenarios described in TSÊ23.228Ê[1]. A.4.1 RegistrationÐ user not registered Figure A.4.1.1: Registration Ð user not registered A.4.2 Registration Ð user currently registered Figure A.4.2.1: Re-registration A.4.3 UE initiated de-registration Figure A.4.3.1: UE initiated de-registration A.4.4 Network initiated de-registration A.4.4.1 Registration timeout Figure A.4.4.1.1: Network initiated de-registration Ð registration timeout A.4.4.2 Administrative de-registration Figure A.4.4.2.1: Network initiated de-registration Ð administrative de-registration A.4.4.3 De-registration initiated by service platform Figure A.4.4.3.1: Network initiated de-registration Ð initiated by service platform A.4.5 UE Terminating SIP session set-up Figure A.4.5.1: UE Terminating SIP session set-up A.4.6 Initiation of a session to a non-registered user Figure A.4.6.1: Initiation of a session to a non-registered user A.4.6a AS originating session on behalf of a non-registered user Figure A.4.6a.1: AS originating session on behalf of a non-registered user A.4.7 User Profile update Figure A.4.7.1: User profile update Annex B (informative): User profile UML model The purpose of this UML model is to define in an abstract level the structure of the user profile downloaded over the Cx interface and describe the purpose of the different information classes included in the user profile. B.1 General description The following picture gives an outline of the UML model of the user profile, which is downloaded from HSS to S-CSCF: Figure B.1.1: User Profile IMS Subscription class contains as a parameter the private user identity of the user in NAI format and the IMSI of the user, if available, as defined in TSÊ23.003Ê[17]. Each instance of the IMS Subscription class contains zero or one instance of the class Reference Location Information. The class Reference Location Information contains zero or one attribute AccessType, zero or one attribute AccessInfo, and zero or one attribute AccessValue. The attribute AccessType indicates the type of access for which the reference location of the user is defined (e.g. ADSL). The attribute AccessInfo indicates the type of the access information defined for the reference location of the user (e.g. dsl-location). The attribute AccessValue contains the location information (e.g. line identifier in fixed access networks) as configured by the operator. Each instance of the IMS Subscription class contains one or several instances of the class Service Profile. B.2 Service profile The following picture gives an outline of the UML model of the Service Profile class: Figure B.2.1: Service Profile Each instance of the Service Profile class consists of the following classes: - One or several instances of the Public-Identity class. PublicIdentity class contains the Public Identities associated with that service profile. The information in the CoreNetworkServicesAuthorization and InitialFilterCriteria classes apply to all PublicIdentification class instances, which are included in one ServiceProfile class. - An optional instance of the CoreNetworkServicesAuthorization class. If no instance of the CoreNetworkServicesAuthorization class is present, no filtering related to subscribed media or restriction on IMS Communication Service Identifiers applies in the S-CSCF. - Zero or several instances of the InitialFilterCriteria class. Each instance of the Service Profile class contains the following attributes: - Zero or more instances of the attribute SharedIFCSetID. A SharedIFCSetID attribute points to a set of Initial Filter Criteria locally administered and stored at the S-CSCF. Shared iFC Sets may be shared by several Service Profiles. B.2.1 Public Identification The following picture gives an outline of the UML model of Public Identification class: Figure B.2.1.1: Public Identification The attribute BarringIndication is of type Boolean. If it is absent, or if it is present and set to FALSE, the S-CSCF shall not restrict the use of that public user identity in any IMS communications. If it is present and set to TRUE, the S-CSCF shall prevent that public identity from being used in any IMS communication except registrations and re-registrations, as specified in TSÊ24.229Ê[8]. Public Identification class can contain an Identity attribute. The attribute IdentityType indicates the type of identity contained in each case. It could be either: - A distinct Public User Identity - A distinct Public Service Identity - A Wildcarded Public Service Identity - A non distinct Public User Identity, i.e. not explicitly provisioned in HSS. - A Wildcarded Public User Identity If the identity type is not present, it is assumed to be a distinct Public User Identity. The attribute WildcardedPSI may be present (when IdentityType is WildcardedPSI) and contains the Wildcarded Public Service Identity that matched the Public Service Identity. This Wildcarded Public Service identity shall be sent as stored in the HSS, that is, including the delimiter described in TSÊ23.003Ê[17]. The attribute DisplayName allows a name to be associated with a Public Identity. The attribute AliasIdentityGroupID indicates the Alias Public User Identity Set to which the Public User Identity belongs. If the ""AliasInd"" feature is supported, all Public User Identities shall have an AliasIdentityGroupID allocated. Within an IMS subscription Public User Identities that have the same AliasIdentityGroupID allocated shall be in the same implicit registration sets, and shall share their service profile and the same service data for each and every service, and shall be regarded as aliases of each other, as defined in the TSÊ23.008Ê[18]. If the ""AliasInd"" feature is not supported, all Public User Identities within an IMS subscription that are within the same implicit registration set and share their service profile shall be regarded aliases of each other. The attribute WildcardedIMPU shall be present when IdentityType is a non distinct IMPU or it may be optionally present when IdentityType is a Wildcarded IMPU. It contains the Wildcarded Public User Identity that matched the Public User Identity. This Wildcarded Public User identity shall be sent as stored in the HSS, that is, including the delimiter described in TSÊ23.003Ê[17]. The attribute ServiceLevelTraceInfo provides the Service Level Tracing Information that is related to the Public User Identity. If the ServiceLevelTraceInfo is present, service level tracing shall be enabled in the S-CSCF for the related Public User Identity according to the configuration data received. If the ServiceLevelTraceInfo is not present, service level tracing is disabled in the S-CSCF for the related Public User Identity. The attribute ServicePriorityLevel provides the Priority Level allowed for the Public User Identity, which can be used by the S-CSCF and other network elements for Priority Service. The attribute PriorityNamespace provides the Namespace as specified in IETFÊRFCÊ4412Ê[22] and to which the Extended Priority refers. The attribute PriorityLevel provides the Priority Level allowed for the Public User Identity, for the Extended Priority. Its value depends on the PriorityNamespace. The attribute MaxNumOfAllowedSimultRegs provides the maximum number of allowed simultaneous registrations for the Public User Identity. B.2.1A Core Network Service Authorization The following picture gives an outline of the UML model of Core Network Service Authorization class: Figure B.2.1A.1: Core Network Service Authorization Each instance of the Core Network Service Authorization class contains zero or one instance of the class Subscribed Media Profile Id. If no instance of the class Subscribed Media Profile Id is present, no filtering related to subscribed media applies in S-CSCF. The Subscribed Media Profile Id is of type Integer and identifies a media profile in the S-CSCF for the authorization of media parameters. Each instance of the Core Network Service Authorization class contains zero or one instance of the class List of Service Ids. If no instance of the class List of Service Ids is present, no restriction on IMS Communication Service Identifiers related applies in S-CSCF. Each instance of the class List of Service Ids contains zero or more instances of the class Service Id. The Service Id is of type String and identifies an IMS Communication Service Identifier that the subscriber is authorized to use. B.2.2 Initial Filter Criteria The following picture gives an outline of the UML model of Initial Filter Criteria class: Figure B.2.2.1.1: Initial Filter Criteria Each instance of the InitialFilterCriteria class includes the following attributes: - One instance of Priority attribute that indicates the priority of the Filter Criteria. The higher the Priority Number the lower the priority of the Filter Criteria is; i.e., a Filter Criteria with a higher value of Priority Number shall be assessed after the Filter Criteria with a smaller Priority Number have been assessed. The same priority shall not be assigned to more than one initial Filter Criterion. - An optional instance of ProfilePartIndicator attribute that is an enumerated type, with possible values ""REGISTERED and UNREGISTERED, indicating if the iFC is a part of the registered or unregistered user profile. If ProfilePartIndicator is missing from the iFC, the iFC is considered to be relevant to both the registered and unregistered parts of the user profile, i.e. belongs to the common part of the user profile. Each instance of the InitialFilterCriteria class consists of the following classes: - An optional instance of TriggerPoint class that describes the trigger points that should be checked in order to find out if the indicated Application Server should be contacted or not. Each TriggerPoint is a boolean expression in Conjunctive or Disjunctive Normal form (CNF of DNF). The absence of Trigger Point instance will indicate an unconditional triggering to Application Server. The attribute ConditionTypeCNF attribute defines how the set of SPTs are expressed, i.e. either an Ored set of ANDed sets of SPT statements or an ANDed set of Ored sets of statements. Individual SPT statements can also be negated. These combinations are termed, respectively, Disjunctive Normal Form (DNF) and Conjunctive Normal Form (CNF) for the SPT (see Annex C). Both DNF and CNF forms can be used. ConditionTypeCNF is a boolean that is TRUE when the Trigger Point associated with the FilterCriteria is a boolean expression in Conjunctive Normal Form (CNF) and FALSE if the Trigger Point is expressed in Disjunctive Normal Form (DNF) (see Annex C). Each TriggerPoint class is composed by 1 to n instances of the SPT (ServicePointTrigger) class. - One instance of ApplicationServer class that defines the application server, which is contacted, if the trigger points are met. Each instance of the ApplicationServer class includes following attributes: - One instance of ServerName attribute that is the SIP URL of the application server to contact. - An optional instance of DefaultHandling attribute that determines whether the dialog should be released if the Application Server could not be reached or not; it is of type enumerated and can take the values: SESSION_CONTINUED or SESSION_TERMINATED. - One optional instance of the ServiceInfo attribute. The ServiceInfo attribute allows to download to S-CSCF information that is to be transferred transparently to an Application Server when the trigger points of a filter criterion are satisfied. ServiceInfo is a string conveying that information. See TSÊ23.218Ê[6] for a description of the use of this information element. Each instance of the ApplicationServer class includes following classes: - One optional instance of the IncludeRegisterRequest class that indicates to the S-CSCF that the incoming SIP REGISTER request is to be transferred to an Application Server when the trigger points of a filter criterion are satisfied. See TSÊ23.218Ê[6] for a description of the use of this information element. - One optional instance of the IncludeRegisterResponse class that indicates to the S-CSCF that the final SIP response to the incoming SIP REGISTER request is to be transferred to an Application Server when the trigger points of a filter criterion are satisfied. See TSÊ23.218Ê[6] for a description of the use of this information element. B.2.3 Service Point Trigger The following picture gives an outline of the UML model of Service Point Trigger class: Figure B.2.3.1: Service Point Trigger The attribute Group of the class Service Point Trigger allows the grouping of SPTs that will configure the sub-expressions inside a CNF or DNF expression. For instance, in the following CNF expression (A+B).(C+D), A+B and C+D would correspond to different groups. In CNF, the attribute Group identifies the ORed sets of SPT instances. If the SPT belongs to different ORed sets, SPT can have more than one Group values assigned. At least one Group must be assigned for each SPT. In DNF, the attribute Group identifies the ANDed sets of SPT instances. If the SPT belongs to different ANDed sets, SPT can have more than one Group values assigned. At least one Group must be assigned for each SPI. The attribute ConditionNegated of the class Service Point Trigger defines whether the individual SPT instance is negated (i.e. NOT logical expression). NOTE: The operator should be aware that a negated Session Case implies that all other available session cases are set. The list of session cases depends on the release and can even be increased in the future, then a negated Session Case may end up triggering ASs unexpectedly (e.g. NOT ORIGINATED_REGISTERED may trigger only TERMINATING_UNREGISTERED and TERMINATING_REGISTERED, or as well ORIGINATING_UNREGISTERED and ORIGINATING_CDIV). The attribute RegistrationType of the class Service Point Trigger is relevant only to the SIP Method SPT with a value of ""REGISTER"" and its' support is optional in the HSS and in the S-CSCF. The RegistrationType may contain a list of values that define whether the SPT matches to REGISTER messages that are related to initial registrations, re-registrations, and/or de-registrations. If RegistrationTypes are given, the SIP Method SPT with a value of ""REGISTER"" shall match if any of the RegistrationTypes match and the S-CSCF supports the RegistrationType attribute. If the SIP Method SPT contains value ""REGISTER"", and no RegistrationType is given, or if the S-CSCF does not support the RegistrationType attribute, the SIP Method SPT matches to all REGISTER messages. The attribute RegistrationType may be discarded if it is present in an SPT other than SIP Method with value ""REGISTER"". Request-URI class defines SPT for the Request-URI. Request-URI contains attribute RequestURI. SIP Method class defines SPT for the SIP method. SIP Method contains attribute Method which holds the name of any SIP method. SIP Header class defines SPT for the presence or absence of any SIP header or for the content of any SIP header. SIP Header contains attribute Header which identifies the SIP Header, which is the SPT, and the Content attribute defines the value of the SIP Header if required. The absence of the Content attribute and ConditionNegated = TRUE indicates that the SPT is the absence of a determined SIP header. Session Case class represents an enumerated type, with possible values ""Originating"", ""Terminating_Registered"", ""Terminating_Unregistered"", ""Originating_Unregistered"", ""Originating_CDIV"" indicating whether the filter should be used by the S-CSCF handling the Originating, Terminating for a registered end user, Terminating for an unregistered end user, Originating for an unregistered end user, or Originating after Call Diversion services. Session Description Information class defines SPT for the content of any SDP field within the body of a SIP Method. The Line attribute identifies the line inside the session description. Content is a string defining the content of the line identified by Line. Annex C (informative): Conjunctive and Disjunctive Normal Form A Trigger Point expression is constructed out of atomic expressions (i.e. Service Point Trigger) linked by Boolean operators AND, OR and NOT. Any logical expression constructed in that way can be transformed to forms called Conjunctive Normal Form (CNF) and Disjunctive Normal Form (DNF). A Boolean expression is said to be in Conjunctive Normal Form if it is expressed as a conjunction of disjunctions of literals (positive or negative atoms), i.e. as an AND of clauses, each of which is the OR of one of more atomic expressions. Taking as an example the following trigger: Method = ""INVITE"" OR Method = ""MESSAGE"" OR (Method=""SUBSCRIBE"" AND NOT Header = ""from"" Content = ""joe"") The trigger can be split into the following atomic expressions: Method=""INVITE"" Method=""MESSAGE"" Method=""SUBSCRIBE"" NOT header=""from"" Content =""joe"" Grouping the atomic expressions, the CNF expression equivalent to the previous example looks like: (Method=""INVITE"" OR Method = ""MESSAGE"" OR Method=""SUBSCRIBE"") AND (Method=""INVITE"" OR Method = ""MESSAGE"" OR (NOT Header = ""from"" Content = ""joe"")) This result in two ""OR"" groups linked by ""AND"" (CNF): (Method=""INVITE"" OR Method = ""MESSAGE"" OR Method=""SUBSCRIBE"") (Method=""INVITE"" OR Method = ""MESSAGE"" OR (NOT Header = ""from"" Content = ""joe"")) The XML representation of the trigger is: <?xml version=""1.0"" encoding=""UTF-8""?> <IMSSubscription xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xsi:noNamespaceSchemaLocation=""CxDataType.xsd""> <PrivateID>IMPI1@homedomain.com</PrivateID> <ServiceProfile> <PublicIdentity> <BarringIndication>1</BarringIndication> <Identity> sip:IMPU1@homedomain.com </Identity> </PublicIdentity> <PublicIdentity> <Identity> sip:IMPU2@homedomain.com </Identity> </PublicIdentity> <InitialFilterCriteria> <Priority>0</Priority> <TriggerPoint> <ConditionTypeCNF>1</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>MESSAGE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>SUBSCRIBE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>1</Group> <Method>INVITE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>1</Group> <Method>MESSAGE</Method> </SPT> <SPT> <ConditionNegated>1</ConditionNegated> <Group>1</Group> <SIPHeader> <Header>From</Header> <Content>""joe""</Content> </SIPHeader> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:AS1@homedomain.com</ServerName> <DefaultHandling>0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </ServiceProfile> </IMSSubscription> A Boolean expression is said to be in Disjunctive Normal Form if it is expressed as a disjunction of conjunctions of literals (positive or negative atoms), i.e. as an OR of clauses, each of which is the AND of one of more atomic expressions. The previous example is already in DNF, composed by the following groups: Method=""INVITE"" Method=""MESSAGE"" Method=""SUBSCRIBE"" AND (NOT header=""from"" Content =""joe"") The XML representation of the trigger is: <?xml version=""1.0"" encoding=""UTF-8""?> <IMSSubscription xmlns:xsi=""http://www.w3.org/2001/XMLSchema-instance"" xsi:noNamespaceSchemaLocation=""CxDataType.xsd""> <PrivateID>IMPI1@homedomain.com</PrivateID> <ServiceProfile> <PublicIdentity> <BarringIndication>1</BarringIndication> <Identity> sip:IMPU1@homedomain.com </Identity> </PublicIdentity> <PublicIdentity> <Identity> sip:IMPU2@homedomain.com </Identity> </PublicIdentity> <InitialFilterCriteria> <Priority>0</Priority> <TriggerPoint> <ConditionTypeCNF>0</ConditionTypeCNF> <SPT> <ConditionNegated>0</ConditionNegated> <Group>0</Group> <Method>INVITE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>1</Group> <Method>MESSAGE</Method> </SPT> <SPT> <ConditionNegated>0</ConditionNegated> <Group>2</Group> <Method>SUBSCRIBE</Method> </SPT> <SPT> <ConditionNegated>1</ConditionNegated> <Group>2</Group> <SIPHeader> <Header>From</Header> <Content>""joe""</Content> </SIPHeader> </SPT> </TriggerPoint> <ApplicationServer> <ServerName>sip:AS1@homedomain.com</ServerName> <DefaultHandling index=""0"">0</DefaultHandling> </ApplicationServer> </InitialFilterCriteria> </ServiceProfile> </IMSSubscription> Annex D (informative): High-level format for the User Profile The way the information shall be transferred through the Cx interface can be seen from a high-level point of view in the following picture: Figure D.1: Example of in-line format of user profile If more than one service profile is created, for example to assign a different set of filters to public identifiers 1 and 2 and public identity 3, the information shall be packaged in the following way: Figure D.2: Example of in-line format of user profile Annex E (normative): XML schema for the Cx interface user profile The file CxDataType_Rel11.xsd, attached to this specification, contains the XML schema for the user profile that is sent over the Cx interface. The user profile XML schema defines that are used in the user profile XML. The data that is allowed to be sent in the user profile may vary depending on the features supported by the Diameter end points, see TSÊ29.229Ê[5]. The user profile XML schema file is intended to be used by an XML parser. The version of the Cx application sending the user profile XML shall be the same as the version of the sent user profile XML and thus it implies the version of the user profile XML schema to be used to validate it. Table E.1 describes the data types and the dependencies among them that configure the user profile XML schema. Table E.1: XML schema for the Cx interface user profile: simple data types Data type Tag Base type Comments tPriority Priority integer >= 0 tProfilePartIndicator ProfilePartIndicator enumerated Possible values: 0 (REGISTERED) 1 (UNREGISTERED) tSharedIFCSetID SharedIFCSetID integer >= 0 tGroupID Group integer >= 0 tRegistrationType RegistrationType enumerated Possible values: 0 (INITIAL_REGISTRATION) 1 (RE-REGISTRATION) 2 (DE-REGISTRATION) tDefaultHandling DefaultHandling enumerated Possible values: 0 (SESSION_CONTINUED) 1 (SESSION_TERMINATED) tDirectionOfRequest SessionCase enumerated Possible values: 0 (ORIGINATING_REGISTERED) 1 TERMINATING_REGISTERED 2 (TERMINATING_UNREGISTERED) 3 (ORIGINATING_UNREGISTERED) 4 (ORIGINATING_CDIV) tPrivateID PrivateID anyURI Syntax described in IETF RFC 2486Ê[14] tSIP_URL Identity anyURI Syntax described in IETF RFC 3261Ê[11] or 3GPP TSÊ23003 (See Note 1) tTEL_URL Identity anyURI Syntax described in IETF RFC 3966Ê[15] or 3GPP TSÊ23003 (See Note 1) tIdentity Identity (union) Union of tSIP_URL, and tTEL_URL tIdentityType IdentityType enumerated Possible values: 0 (DISTINCT PUBLIC_USER_IDENTITY) 1 (DISTINCT_PSI) 2 (WILDCARDED_PSI) (See Note 2) 3 (NON_DISTINCT_IMPU) (See Note 3) 4 (WILDCARDED_IMPU) (See Note 4) tServiceInfo ServiceInfo string tString RequestURI, Method, Header, Content, Line, AccessType, AccessInfo, AccessValue string tBool ConditionTypeCNF, ConditionNegated, BarringIndication boolean Possible values: 0 (false) 1 (true) tSubscribedMediaProfileId SubscribedMediaProfileId integer >=0 tDisplayName DisplayName string tAliasIdentityGroupID AliasIdentityGroupID string tServiceLevelTraceInfo ServiceLevelTraceInfo string Syntax described in 3GPPÊTSÊ24.323Ê[32] tServicePriorityLevel ServicePriorityLevel enumerated Possible values: 0 (Highest priority) 1 2 3 4 (Lowest priority) tPriorityNamespace PriorityNamespace string Possible values are those of the namespaces that are defined in IETF RFC 4412Ê[22] or defined according to the IANA registration procedure described in IETF RFC 4412Ê[22] for Resource-Priority Namespaces. tPriorityLevel PriorityLevel string Possible values depend on the PriorityNamespace and are specified with the associated namespace that is defined in IETF RFC 4412Ê[22] or defined according to the IANA registration procedure described in IETF RFC 4412Ê[22] for Resource-Priority Namespaces tIMSI IMSI string Syntax described in 3GPP TSÊ23.003Ê[17]. ASCII encoded according to ANSI X3.4Ê[26]. tMaxNumOfAllowedSimultRegistrations MaxNumOfAllowedSimultRegistrations integer >= 1 NOTE 1: Only when the ""Identity"" tag is a Wildcarded Identity the syntax is described in 1Ê23.003Ê[17]. It applies to both WILDCARDED_IMPU and WILDCARDED_PSI. NOTE 2: Wildcarded PSI could optionally be included as well in tPublicIdentityExtension. NOTE 3: The IMPU is not explicitly provisioned in HSS. In this case, corresponding Wildcarded IMPU is included in tPublicIdentityExtension3. NOTE 4: WILDCARDED_IMPU indicates that the content of the identity in the ""Identity"" tag is a Wildcarded Public User Identity. In this case, Wildcarded IMPU could optionally be included as well in tPublicIdentityExtension3. Table E.2: XML schema for the Cx interface user profile: complex data types Data type Tag Compound of Tag Type Cardinality tIMSSubscription IMSSubscription PrivateID tPrivateID 1 ServiceProfile tServiceProfile (1 to n) Extension tIMSSubscriptionExtension (0 to 1) tIMSSubscriptionExtension Extension IMSI tIMSI (0 to 1) Extension tIMSSubscriptionExtension2 (0 to 1) tIMSSubscriptionExtension2 Extension ReferenceLocationInformation tReferenceLocationInformation (0 to n) (NOTEÊ5) tReferenceLocationInformation ReferenceLocationInformation AccessType tString (NOTEÊ4) (0 to 1) AccessInfo tString (NOTEÊ4) (0 to 1) AccessValue tString (NOTEÊ4) (0 to 1) tServiceProfile ServiceProfile PublicIdentity tPublicIdentity (1 to n? CoreNetworkServicesAuthorization CoreNetworkServicesAuthorization (0 to 1? InitialFilterCriteria tInitialFilterCriteria (0 to n) Extension tServiceProfileExtension (0 to 1) tServiceProfileExtension Extension SharedIFCSetID tSharedIFCSetID (0 to n) tCoreNetworkServicesAuthorization CoreNetworkServicesAuthorization SubscribedMediaProfileId tSubscribedMediaProfileId (0 to 1) Extension tCNServicesAuthorizationExtension (0 to 1) tPublicIdentity PublicIdentity BarringIndication tBool (0 to 1) Identity tIdentity 1 Extension tPublicIdentityExtension (0 to 1) tInitialFilterCriteria InitialFilterCriteria Priority tPriority 1 TriggerPoint tTrigger (0 to 1) ApplicationServer tApplicationServer 1 ProfilePartIndicator tProfilePartIndicator (0 to 1) tTrigger TriggerPoint ConditionTypeCNF tBool 1 SPT tSePoTri (1 to n) tSePoTri SPT ConditionNegated tBool (0 to 1) Group tGroupID (1 to n( Choice of RequestURI tString 1 Method tString 1 SIPHeader tHeader 1 SessionCase tDirectionOfRequest 1 SessionDescription tSessionDescription 1 Extension tSePoTriExtension (0 to 1) tSePoTriExtension Extension RegistrationType tRegistrationType (0 to 2) tHeader SIPHeader Header tString 1 Content tString (0 to 1) tSessionDescription SessionDescription Line tString 1 Content tString (0 to 1) tApplicationServer ApplicationServer ServerName tSIP_URL 1 DefaultHandling tDefaultHandling (0 to 1) ServiceInfo tServiceInfo (0 to 1) Extension tApplicationServerExtension (0 to 1) tApplicationServerExtension Extension IncludeRegisterRequest tIncludeRegisterRequest (0 to 1) IncludeRegisterResponse tIncludeRegisterResponse (0 to 1) tIncludeRegisterRequest IncludeRegisterRequest (NOTEÊ2) (NOTEÊ2) (0 to 1) tIncludeRegisterResponse tIncludeRegisterResponse (NOTEÊ2) (NOTEÊ2) (0 to 1) tPublicIdentityExtension Extension IdentityType tIdentityType (0 to 1) WildcardedPSI anyURI (NOTE 3) (0 to 1) Extension tPublicIdentityExtension2 (0 to 1) tPublicIdentityExtension2 Extension DisplayName tDisplayName (0 to 1) AliasIdentityGroupID tAliasIdentityGroupID (0 to 1) Extension tPublicIdentityExtension3 (0 to 1) tPublicIdentityExtension3 Extension WildcardedIMPU anyURI (NOTE 3) (0 to 1) ServiceLevelTraceInfo tServiceLevelTraceInfo (0 to 1) ServicePriorityLevel ServicePriorityLevel (0 to 1) Extension tPublicIdentityExtension4 (0 to 1) tPublicIdentityExtension4 Extension ExtendedPriority tExtendedPriority (0 to n) Extension tPublicIdentityExtension5 (0 to 1) tPublicIdentityExtension5 Extension MaxNumOfAllowedSimultRegistrations tMaxNumOfAllowedSimultRegistrations (0 to 1) tExtendedPriority ExtendedPriority PriorityNamespace tPriorityNamespace 1 PriorityLevel tPriorityLevel 1 tCNServicesAuthorizationExtension Extension ListOfServiceIds tListOfServiceIds (0 to 1) tListOfServiceIds ListOfServiceIds ServiceId tString (0 to n) NOTE 1: ""n"" shall be interpreted as non-bounded. NOTEÊ2: empty cells shall be interpreted as complex XML elements without defined content. NOTE 3: the syntax of Wildcarded Public User Identity and Wildcarded Service Identity shall be as described in 3GPP TSÊ23.003Ê[17]. NOTE 4: the syntax of AccessType, AccessInfo and AccessValue is as described in 3GPP TSÊ24.229Ê[8] for P-Access-Network-Info header fields: AccessType corresponds to the ""access-type"" field whereas AccessInfo and AccessValue correspond to the type and associated value defined for the ""access-info"" field. NOTE 5: the HSS shall not send more than one instance of ReferenceLocationInformation and if the S-CSCF receives more than one instance of ReferenceLocationInformation it may arbitrarily pick one for further processing. Annex F (normative): Definition of parameters for service point trigger matching Table F.1 defines the parameters that are transported in the user profile XML. Table F.1: Definition of parameters in the user profile XML Tag Description RequestURI RequestURI tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. For SIP URI, the regular expression shall be matched against the hostport of the SIP-URI. For definition of SIP-URI and hostport, see IETF RFC 3261Ê[11]. For Tel URI, the regular expression shall be matched against the telephone-subscriber of the telephone-uri. For definition of telephone-subscriber and telephone-uri, see IETF RFC 3966Ê[15]. SIPHeader A SIP Header SPT shall be evaluated separately against each header instance within the SIP message. The SIP Header SPT matches if at least one header occurrence matches the SPT. Header (of SIPHeader) Header tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. The regular expression shall be matched against the header-name of the SIP header. For definition of header and header-name, see IETF RFC 3261Ê[11]. Before matching the header-name to the pattern, all SWSs shall be removed from the header-name and all LWSs in the header-name shall be reduced to a single white space character (SP). For definition of SWS and LWS, see IETF RFC 3261Ê[11]. Content (of SIPHeader) Content tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. The regular expression shall be matched against the header-value of the SIP header. For definition of header and header-value, see IETF RFC 3261Ê[11]. If the SIP header contains several header-values in a comma-separated list, each of the header-value shall be matched against the pattern for the Content separately. Before matching the header-value to the pattern, all SWSs shall be removed from the header-value and all LWSs in the header-value shall be reduced to a single white space character (SP). For definition of SWS and LWS, see IETF RFC 3261Ê[11]. SessionDescription A Session Description SPT shall be evaluated separately against each SDP field instance within the SIP message. The Session Description SPT matches if at least one field occurrence matches the SPT. Line (of SessionDescription) Line tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. The regular expression shall be matched against the type of the field inside the session description. For definition of type, see clauseÊ6 in IETF RFC 4566Ê[12]. Content (of SessionDescription) Content tag shall include a regular expression in a form of Extended Regular Expressions (ERE) as defined in clauseÊ9 in IEEE 1003.1-2004 Part 1Ê[13]. The regular expression shall be matched against the value of the field inside the session description. For definition of value, see clauseÊ6 in IETF RFC 4566Ê[12]. Annex G (normative): Emergency registrations S-CSCF and HSS shall handle emergency registrations as normal registrations with the following considerations: - Upon emergency registration, following cases apply: - If a normal registration for the same user does not exist, the S-CSCF shall download corresponding user profile from HSS, ensure that the HSS allocates S-CSCF name to this subscriber and the registration status is set to UNREGISTERED. - Otherwise, the S-CSCF shall ensure that the registration status of the user is not changed in the HSS. - Upon deregistration or expiration of the last normal session, if an emergency registration is still active for this subscriber, the S-CSCF shall ensure that the HSS keeps S-CSCF name allocated to this subscriber and the registration status is set to UNREGISTERED. - Upon expiration of an emergency registration, the S-CSCF shall ensure the registration status of the user is not changed in the HSS if there are other normal registrations of the user. Otherwise, the S-CSCF may send SAR to the HSS to remove its name and set the registration status of the user to NOT REGISTERED. - IMS Restoration procedures do not apply for IMS emergency sessions. Annex H (normative): Diameter overload control mechanism H.1 General Diameter overload control mechanism is an optional feature. IETFÊRFCÊ7683Ê[24] specifies a Diameter overload control mechanism which includes the definition and the transfer of related AVPs between Diameter nodes. It is recommended to make use of IETFÊRFCÊ7683Ê[24] on the Cx interface where, when applied, the I/S-CSCF shall behave as reacting nodes and the HSS as a reporting node. Depending on regional/national requirements and network operator policy, priority traffic (e.g. MPS as described in TSÊ22.153Ê[25]) shall be exempted from throttling due to Diameter overload control up to the point where requested traffic reduction cannot be achieved without throttling the priority traffic. H.2 HSS behaviour The HSS requests traffic reduction from the I/S-CSCF when the HSS is in an overload situation, including OC-OLR AVP in answer commands as described in IETFÊRFCÊ7683Ê[24]. The HSS identifies that it is in an overload situation by implementation specific means. For example, the HSS may take into account the traffic over the Cx interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources, etc. The HSS determines the specific contents of OC-OLR AVP in overload reports and the HSS decides when to send OC-OLR AVPs by implementation specific means. H.3 I/S-CSCF behaviour The I/S-CSCF applies required traffic reduction received in answer commands to subsequent applicable requests, as per IETFÊRFCÊ7683Ê[24]. The I/S-CSCF achieves requested traffic reduction by implementation specific means. For example, the I/S-CSCF may implement message throttling with prioritization or a message retaining mechanism for operations that can be postponed. Diameter requests related to priority traffic (e.g. MPS) and emergency, detected via the presence of priority information (e.g., Resource-Priority header field for MPS) in SIP messages as described in TSÊ24.229Ê[8], have the highest priority. Depending on regional/national regulatory and operator policies, these Diameter requests shall be the last to be throttled, when the I/S-CSCF has to apply traffic reduction."
"Relative priority amongst various priority traffic (e.g. MPS) and emergency traffic is subject to regional/national regulatory and operator policies. Annex I (Informative): Diameter overload node behaviour I.1 Message prioritization This clause describes possible behaviours of the I/S-CSCF regarding message prioritisation in an informative purpose. The I/S-CSCF may take the following into account when making throttling decisions: - Identification of the procedures that can be deferred (e.g. Deregistration Request), so to avoid to drop non deferrable procedures; - Prioritisation of certain types of request (e.g. between MAR and SAR for S-CSCF, and between LIR and UAR for I-CSCF) according to the context of their use, in particular: - Higher prioritisation of SAR commands for S-CSCF that are related to a registered user for a service, so to avoid the interruption of the registered service for the user; - Higher prioritisation of LIR commands for I-CSCF that are related to a requested service different from registration or deregistration, so to get more originating or terminating services provided to the user; - Skipping of optional authentication. - Priority level of a priority user (e.g., MPS user). Annex J (normative): Diameter message priority mechanism J.1 General IETFÊRFCÊ7944Ê[27] specifies a Diameter message priority mechanism that allows Diameter nodes to indicate the relative priority of Diameter messages. With this information, other Diameter nodes may leverage the relative priority of Diameter messages into routing, resource allocation, set the DSCP marking for transport of the associated Diameter message, and also abatement decisions when overload control is applied. J.2 Cx/Dx interfaces J.2.1 General The Diameter message priority mechanism is an optional feature. It is recommended to make use of IETFÊRFCÊ7944Ê[27] over the Cx/Dx interfaces of an operator network when the overload control defined in Annex H is applied on these Cx/Dx interfaces. J.2.2 S-CSCF/I-CSCF behaviour When the S-CSCF/I-CSCF supports the Diameter message priority mechanism, the S-CSCF/I-CSCF shall comply with IETFÊRFCÊ7944Ê[27]. The S-CSCF/I-CSCF sending a request shall determine the required priority according to its policies. When priority is required, the S-CSCF/I-CSCF shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level. When the S-CSCF/I-CSCF receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request. When the S-CSCF/I-CSCF receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, it may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response. If: - the S-CSCF/I-CSCF supports using the Diameter message priority mechanism for DSCP marking purposes, - the transport network utilizes DSCP marking, and - message-dependant DSCP marking is possible for the protocol stack transporting Diameter, then the S-CSCF/I-CSCF shall set the DSCP marking for transport of the request or response according to the required priority level. Diameter requests related to priority traffic (e.g. MPS as identified by the S-CSCF/I-CSCF through SIP procedures, emergency) shall contain a DRMP AVP with a high priority of which the level value is operator dependent. When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific. J.2.3 HSS/SLF behaviour When the HSS/SLF supports the Diameter message priority mechanism, the HSS/SLF shall comply with IETFÊRFCÊ7944Ê[27]. The HSS/SLF sending a request shall determine the required priority according to its policies. When priority is required, the HSS/SLF shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level. When the HSS/SLF receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request. When the HSS/SLF receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, it may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response. If: - the HSS/SLF supports using the Diameter message priority mechanism for DSCP marking purposes, - the transport network utilizes DSCP marking, and - message-dependant DSCP marking is possible for the protocol stack transporting Diameter, then the HSS/SLF shall set the DSCP marking for transport of the request or response according to the required priority level. When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific. J.2.4 Interactions If the HSS supporting the Diameter message priority mechanism receives the request message containing both the Session-Priority AVP and DRMP AVP, the HSS shall prioritize the request according to priority level received within the DRMP AVP. Annex K (normative): Diameter load control mechanism K.1 General The Diameter load control mechanism is an optional feature. It is recommended to make use of IETFÊIETFÊRFCÊ8583Ê[29] on the Cx interface where, when applied, the I-CSCF and the S-CSCF shall behave as reacting nodes and the HSS as a reporting node. K.2 HSS behaviour The HSS may report its current load by including a Load AVP of type HOST in answer commands as described in IETFÊIETFÊRFCÊ8583Ê[29]. The HSS calculates its current load by implementation specific means. For example, the HSS may take into account the traffic over the Cx interface or other interfaces, the level of usage of internal resources (e.g. CPU, memory), the access to external resources, etc. The HSS determines when to send Load AVPs of type HOST by implementation specific means. K.3 I-CSCF/S-CSCF behaviour When performing next hop Diameter Agent selection for requests that are routed based on realm, the I-CSCF/S-CSCF may take into account load values from Load AVPs of type PEER received from candidate next hop Diameter nodes, as per IETFÊIETFÊRFCÊ8583Ê[29]. Annex L (informative): Change history Date TSGÊ# TSG Doc. CR Rev Cat Subject/Comment New Jun 2002 CN#16 NP-020264 Version 2.0.0 approved at CN#16 5.0.0 Sep 2002 CN#17 NP-020449 001 2 Clarification of implicit registration 5.1.0 Sep 2002 CN#17 NP-020449 002 1 Clarification of user registration status query 5.1.0 Sep 2002 CN#17 NP-020449 003 1 Clarification of HSS initiated update of user profile 5.1.0 Sep 2002 CN#17 NP-020449 004 2 Clarification of MAR command 5.1.0 Sep 2002 CN#17 NP-020449 005 1 Conditionality of the SIP-Auth-Data-Item in MAA command 5.1.0 Dec 2002 CN#18 NP-020587 008 2 Rejection of registration of a Temporary Public Identity without active implicit registration 5.2.0 Dec 2002 CN#18 NP-020587 010 - Removal of upper bounds in Cx i/f user profile 5.2.0 Dec 2002 CN#18 NP-020587 011 - S-CSCF Assignment 5.2.0 Dec 2002 CN#18 NP-020587 012 - NAS-Session-Key AVPs in MAA command 5.2.0 Dec 2002 CN#18 NP-020587 013 1 Correction to detailed behaviour of user registration status query 5.2.0 Dec 2002 CN#18 NP-020587 014 1 Removing the DDF dependencies from Cx interface 5.2.0 Dec 2002 CN#18 NP-020587 015 1 Clarification of SERVER_CHANGE de-registration reason code 5.2.0 Dec 2002 CN#18 NP-020589 016 1 Clarification of User-Authorization-Type AVP usage within the UAR 5.2.0 Dec 2002 CN#18 NP-020587 017 1 Correction to HSS initiated update of user profile 5.2.0 Dec 2002 CN#18 NP-020588 019 - Correction in charging information 5.2.0 Dec 2002 CN#18 NP-020590 020 1 Error handling in S-CSCF when receiving too much data 5.2.0 Dec 2002 CN#18 NP-020587 021 1 Re-allocation of S-CSCF 5.2.0 Dec 2002 CN#18 NP-020591 022 - Correction of the SPI 5.2.0 Mar 2003 CN#19 NP-030101 025 1 Clarification of service profile download at service profile modification 5.3.0 Mar 2003 CN#19 NP-030101 028 - Filter ID field removal in InitialFilterCriteria class 5.3.0 Mar 2003 CN#19 NP-030101 030 1 Clarification of IMPU barring handling 5.3.0 Mar 2003 CN#19 NP-030101 032 1 The default public user identity in the Server-Assignment-Answer 5.3.0 Mar 2003 CN#19 NP-030101 034 2 Corrections to service profile 5.3.0 Mar 2003 CN#19 NP-030101 037 3 Handling of non supported data in the S-CSCF when the profile is being updated 5.3.0 Mar 2003 CN#19 NP-030101 024 1 Clarification of the HSS behaviour in REGISTRATION and DE_REGISTRATION procedures at IMPU checking time. 5.3.0 Mar 2003 CN#19 NP-030101 027 - Deletion of Annex F 5.3.0 Mar 2003 CN#19 NP-030101 029 - Clarification of User-Authorization-Type AVP usage within UAR 5.3.0 Mar 2003 CN#19 NP-030101 031 1 Update TS 29.228 after Diameter has become RFC 5.3.0 Mar 2003 CN#19 NP-030101 033 1 Replacement of the NAS-Session-Key AVP 5.3.0 Mar 2003 CN#19 NP-030101 035 2 Clarification on Re-allocation of S-CSCF 5.3.0 Mar 2003 CN#19 NP-030101 038 1 Change of SPI to SPT 5.3.0 Mar 2003 CN#19 NP-030101 040 1 Definition of the Subscribed Media Profile Identifier 5.3.0 Mar 2003 CN#19 NP-030101 026 - Error in definition of Service Point of Interest class 5.3.0 Jun 2003 CN#20 NP-030215 043 - Correct use of the Result-Code AVP 5.4.0 Jun 2003 CN#20 NP-030215 044 1 Conditionality of User-Name AVP in Server-Assignment-Answer 5.4.0 Jun 2003 CN#20 NP-030215 045 2 Corrections to the base 64 encoding examples 5.4.0 Jun 2003 CN#20 NP-030215 046 1 Deregistration of implicitly registered public user identities 5.4.0 Jun 2003 CN#20 NP-030215 047 - Clarification on the Server-Assignment-Type NO_ASSIGNMENT 5.4.0 Jun 2003 CN#20 NP-030215 048 1 Incorrect use of result-code 5.4.0 Jun 2003 CN#20 NP-030215 049 1 Misalignment in the Public-User-Identity IE 5.4.0 Jun 2003 CN#20 NP-030215 050 1 Duplicated Destination-Host AVP within MAR command code 5.4.0 Sep 2003 CN#21 NP-030383 042 3 Error in S-CSCF Assignment Type 5.5.0 Sep 2003 CN#21 NP-030383 051 2 Mistakes in the XML schema of 29.228-540 5.5.0 Sep 2003 CN#21 NP-030383 055 1 Extensibility of the public identity structure in the XML schema 5.5.0 Sep 2003 CN#21 NP-030394 041 2 Introduction of Presence Stage 3 (Px) to the Cx interface 6.0.0 Sep 2003 CN#21 NP-030394 052 - Sharing public identities across multiple UEs 6.0.0 Dec 2003 CN#22 NP-030585 057 3 Conditions for inclusion of Charging Information 6.1.0 Dec 2003 CN#22 NP-030500 060 1 MAR in synchronisation failure case 6.1.0 Dec 2003 CN#22 NP-030500 061 1 The S-CSCF name needs to be checked always in MAR 6.1.0 Dec 2003 CN#22 NP-030500 063 - Conditional AVPs in answer commands 6.1.0 Dec 2003 CN#22 NP-030500 065 1 Server-Assignment-Request 6.1.0 Dec 2003 CN#22 NP-030500 067 - Determination of User-Authorization-Type AVP based on registration expiration 6.1.0 Dec 2003 CN#22 NP-030500 069 2 Not registered state after deregistration with S-CSCF deleted at the HSS 6.1.0 Dec 2003 CN#22 NP-030500 071 - The extensibility of the XML schema 6.1.0 Dec 2003 CN#22 - Reference [9] updated 6.1.0 Mar 2004 CN#23 NP-040046 077 1 Clarification on S-CSCF-Name comparison 6.2.0 Mar 2004 CN#23 NP-040055 081 - Error for missing identification in SAR command 6.2.0 Mar 2004 CN#23 NP-040046 085 1 Conditions for inclusion of Public Identity in SAR 6.2.0 Mar 2004 CN#23 NP-040046 087 1 Correction to sending the Charging-Information AVP 6.2.0 Mar 2004 CN#23 NP-040046 089 - Correction to User-Authorization-Answer 6.2.0 Mar 2004 CN#23 NP-040046 091 - Default handling of error cases during IMS registration 6.2.0 Jun 2004 CN#24 NP-040215 097 2 Update of the charging addresses from HSS 6.3.0 Jun 2004 CN#24 NP-040215 095 1 Content of the User Profile 6.3.0 Jun 2004 CN#24 NP-040215 099 - Correction of SessionCase attribute ambiguity 6.3.0 Sep 2004 CN#25 NP-040416 109 1 LIR and services related to unregistered state 6.4.0 Sep 2004 CN#25 NP-040401 121 2 Triggering initial REGISTER messages 6.4.0 Sep 2004 CN#25 NP-040401 118 1 XML versioning 6.4.0 Sep 2004 CN#25 NP-040401 122 1 Optimization of User Profile Download 6.4.0 Sep 2004 CN#25 NP-040396 124 2 Simplification of the User Profile Split concept 6.4.0 Sep 2004 CN#25 NP-040416 120 3 Use of regular expressions 6.4.0 Dec 2004 CN#26 NP-040523 138 1 HSS initiated deregistration with ""not registered"" registration state 6.5.0 Dec 2004 CN#26 NP-040530 140 1 HSS initiated deregistration with user profile removal for permanent termination 6.5.0 Dec 2004 CN#26 NP-040523 142 2 HSS initiated deregistration using the network initiated de-registration procedure 6.5.0 Dec 2004 CN#26 NP-040530 146 1 Clarification of R6 authentication scheme 6.5.0 Dec 2004 CN#26 NP-040523 150 - Regular Expressions 6.5.0 Dec 2004 CN#26 NP-040530 155 - Correction to XML Root Element 6.5.0 Dec 2004 CN#26 NP-040530 156 1 Modification of User-Data-Already-Available in SAR command. 6.5.0 Dec 2004 CN#26 NP-040523 159 2 Handling of Information Element marked as (M), (C) or (O) 6.5.0 Mar 2005 CN#27 NP-050030 166 - Avoiding undesired deregistration 6.6.0 Mar 2005 CN#27 NP-050030 168 1 Correction to authentication procedures in not registered case 6.6.0 Mar 2005 CN#27 NP-050037 170 3 Clarification of behaviour for Shared Public User Identities 6.6.0 Mar 2005 CN#27 NP-050037 172 - Distribution of Cipher Key and Integrity Key 6.6.0 Apr 2005 Editorial correction on figure figure A.4.1.1 and on clauses: 6.1.4.1, 6.2.2, B.2.1 and 6.2.1.1 6.6.1 Jun 2005 CT#28 CP-050086 181 - TEL-URI reference correction 6.7.0 Jun 2005 CT#28 CP-050086 183 - Clarification on Server Capabilities 6.7.0 Jun 2005 CT#28 CP-050086 185 - Incorrect Implementation of CR172 6.7.0 Jun 2005 CT#28 CP-050081 188 1 Clarification of the content of SIP-Authentication-Context 6.7.0 Jun 2005 CT#28 CP-050086 192 - Syntax correction for XML 6.7.0 Sep 2005 CT#29 CP-050422 196 - Authentication Registration with synchronization failure, Data requested from HSS 6.8.0 Sep 2005 CT#29 CP-050296 200 Correction to XML Schema for SharedIFCSet 6.8.0 Sep 2005 CT#29 CP-050440 202 2 Private identities on the Cx 6.8.0 Sep 2005 CT#29 CP-050282 204 1 Charging-Information correction 6.8.0 Sep 2005 CT#29 CP-050296 207 1 Corrections to UAR and LIR for shared public identities 6.8.0 Sep 2005 CT#29 CP-050422 208 1 Behaviour of the Implicit Registration Set for the Unregistered state 6.8.0 Sep 2005 CT#29 CP-050296 210 - Change of stage 2 reference from Release 5 to Release 6 6.8.0 Sep 2005 CT#29 CP-050294 211 - PSI Activation 6.8.0 Sep 2005 CT#29 CP-050271 213 2 Removal of redundant restrictions for one Public User Identity in SAR 6.8.0 Sep 2005 CT#29 CP-050296 216 - Error code clean up 6.8.0 Sep 2005 CT#29 CP-050296 217 1 Clarification of User Profile update 6.8.0 Dec 2005 CT#30 CP-050604 198 5 XML syntax correction 6.9.0 Dec 2005 CT#30 CP-050611 220 1 PSI impacts on the Cx Interface 6.9.0 Dec 2005 CT#30 CP-050611 221 3 Routing for PSIs Matching a Wildcarded PSI 6.9.0 Dec 2005 CT#30 CP-050611 222 2 Removal of overhead in Private Identities handling in RTR 6.9.0 Dec 2005 CT#30 CP-050605 229 2 Use-Data description corrections 6.9.0 Dec 2005 CT#30 CP-050605 232 2 S-CSCF assignment checking for notregistered state 6.9.0 Dec 2005 CT#30 CP-050605 236 4 RTR correction 6.9.0 Dec 2005 CT#30 CP-050605 238 1 PPR correction 6.9.0 Dec 2005 CT#30 CP-050611 239 1 Private User Id in RTR 6.9.0 Dec 2005 CT#30 CP-050611 246 1 Server capabilities associations with features 6.9.0 Dec 2005 CT#30 Rel-7 version was created because of ETSI TISPAN references. 7.0.0 Mar 2006 CT#31 CP-060084 0243 1 SPT for mobile orig unregistered 7.1.0 Mar 2006 CT#31 CP-060159 0247 2 Removal of the terms Mobile Originated and Mobile Terminated 7.1.0 Mar 2006 CT#31 CP-060154 0254 - Alignment of Annex E with .xsd file 7.1.0 Mar 2006 CT#31 CP-060154 0256 - Incorrect implementation of CR 0198 7.1.0 Mar 2006 CT#31 CP-060065 0260 2 Handling of unknown errors 7.1.0 Mar 2006 CT#31 CP-060154 0263 2 Private User ID in PPR and RTR 7.1.0 Mar 2006 CT#31 CP-060065 0269 - Message flow correction 7.1.0 Mar 2006 CT#31 CP-060065 0274 - Default public-id and PPR 7.1.0 Jun 2006 CT#32 CP-060302 0285 - S-CSCF reselection removal 7.2.0 Jun 2006 CT#32 CP-060308 0290 3 Correction of the normative text in the table 6.7 7.2.0 Jun 2006 CT#32 CP-060308 0292 2 Using SiFC feature to define optional S-CSCF capabilities 7.2.0 Sep 2006 CT#33 CP-060308 0296 - S-CSCF assignment correction 7.3.0 Sep 2006 CT#33 CP-060405 0299 - Default Public User ID either SIP URI or tel URI 7.3.0 Sep 2006 CT#33 CP-060399 0304 1 Barring Indication for public user identity 7.3.0 Sep 2006 CT#33 CP-060417 0306 2 Deletion of description about Authentication-Data-Item 7.3.0 Sep 2006 CT#33 CP-060399 0313 1 Registration message flow correction 7.3.0 Sep 2006 CT#33 CP-060417 0314 4 AS originating requests on behalf of a user 7.3.0 Sep 2006 CT#33 CP-060416 0317 2 Allowing a Display Name to be associated with a Public Identity. 7.3.0 Sep 2006 CT#33 CP-060417 0320 - Update of the Table 6.7 ""Guidelines for S-CSCF Capabilities"" 7.3.0 Dec 2006 CT#34 CP-060553 0325 1 SDP reference correction 7.4.0 Dec 2006 CT#34 CP-060566 0326 1 New message flow about AS originating session 7.4.0 Dec 2006 CT#34 CP-060566 0327 1 Correction of Private Identity description in SAR 7.4.0 Dec 2006 CT#34 CP-060566 0330 3 Correction of error code in SAA 7.4.0 Dec 2006 CT#34 CP-060566 0332 1 Clarification on use of Authentication pending flag 7.4.0 Dec 2006 CT#34 CP-060566 0336 3 Optimization of handling of Wildcarded PSIs 7.4.0 Dec 2006 CT#34 CP-060555 0338 1 Wildcarded PSI as key in PPR 7.4.0 Dec 2006 CT#34 CP-060553 0342 1 Correction of the HSS behaviour in UAR/UAA command pair 7.4.0 Dec 2006 CT#34 CP-060735 0343 3 Clarification regarding URI canonicalization Ð 29.228 7.4.0 Mar 2007 CT#35 CP-070020 0346 3 Clarification of the server name in LIA 7.5.0 Mar 2007 CT#35 CP-070020 0350 3 User profile data synchronisation 7.5.0 Mar 2007 CT#35 CP-070020 0352 - SAA result code correction 7.5.0 Mar 2007 CT#35 CP-070019 0353 2 Removal of roaming restrictions for Emergency Registrations 7.5.0 Mar 2007 CT#35 CP-070020 0354 - Definition and use of the Wildcarded PSI information element 7.5.0 Jun 2007 CT#36 CP-070309 0358 1 Removal of editor's note on IMS Recovery Procedures 7.6.0 Jun 2007 CT#36 CP-070479 0359 2 Impacts of the IMS Communication Service Identifier 7.6.0 Jun 2007 CT#36 CP-070309 0361 2 Clarification on LIA 7.6.0 Jun 2007 CT#36 CP-070309 0365 1 Adding User-Authorization-Type is absent condition to UAR Detailed behaviour 7.6.0 Jun 2007 CT#36 CP-070312 0367 - Modification to the tag RegistrationtType to RegistrationType in the Annex E 7.6.0 Sep 2007 CT#37 CP-070520 0374 1 Authentication failure and timeout handling 7.7.0 Sep 2007 CT#37 CP-070522 0378 - Incorrect implemented CR 120r3 7.7.0 Sep 2007 CT#37 CP-070527 0379 - User Data Already Available 7.7.0 Nov 2007 CT#38 CP-070743 0388 1 Handling of USER_UNKNOWN and NOT_SUPPORTED_USER_DATA error in PPA 7.8.0 Nov 2007 CT#38 CP-070744 0392 2 Alias 7.8.0 Nov 2007 CT#38 CP-070755 0376 6 Updates to 29.228 for Digest on the Cx Interface 8.0.0 Mar 2008 CT#39 CP-080019 0393 1 IMS Restoration after an S-CSCF failure 8.1.0 Mar 2008 CT#39 CP-080022 0395 2 Update for Supporting NASS-Bundled-Authentication 8.1.0 Mar 2008 CT#39 CP-080019 0398 - SIP Digest password push 8.1.0 Mar 2008 CT#39 CP-080019 0400 1 Wildcarded Public User Identities 8.1.0 Jun 2008 CT#40 CP-080261 0399 3 Originating services after call forwarding 8.2.0 Jun 2008 CT#40 CP-080261 0406 XML example 8.2.0 Jun 2008 CT#40 CP-080267 0408 Emergency Registration for REGISTRATION_AND_CAPABILITIES 8.2.0 Jun 2008 CT#40 CP-080267 0410 Removal of restriction for barred user at Emergency Registrations 8.2.0 Sep 2008 CT#41 CP-080456 0413 2 Emergency Public User Identity removal 8.3.0 Sep 2008 CT#41 CP-080460 0420 1 Support of ""Loose-Route"" indication from HSS 8.3.0 Sep 2008 CT#41 CP-080463 0421 Cx Impacts of IMS Restoration Procedures 8.3.0 Sep 2008 CT#41 CP-080460 0423 2 Filter Criteria enhancement for 3rd party REGISTER 8.3.0 Sep 2008 CT#41 CP-080463 0425 1 Addition of Registered Private Identities in SAA 8.3.0 Sep 2008 CT#41 CP-080460 0426 1 Add Assigned S-CSCF name to SAA 8.3.0 Dec 2008 CT#42 CP-080698 0427 2 Service Restoration for Registered IMPU 8.4.0 Dec 2008 CT#42 CP-080707 0431 2 Support for IMS Service Level Trace 8.4.0 Dec 2008 CT#42 CP-080708 0432 Removal of Digest Domain 8.4.0 Dec 2008 CT#42 CP-080696 0433 3 Diameter Proxy Agent - an alternative User Identity to HSS resolution mechanism 8.4.0 Dec 2008 CT#42 CP-080708 0434 2 S-CSCF and AS procedures with Enhanced Filter Criteria 8.4.0 Mar 2009 CT#43 CP-090023 0435 1 Priority Service 8.5.0 Mar 2009 CT#43 CP-090026 0436 1 Multiple Registrations in Registration 8.5.0 Mar 2009 CT#43 CP-090036 0440 2 HSS Addresses 8.5.0 Mar 2009 CT#43 CP-090025 0441 1 Loose Route Indication 8.5.0 Mar 2009 CT#43 CP-090028 0442 2 Support for GPRS IMS Bundled Authentication (GIBA) in Cx 8.5.0 Sep 2009 CT#45 CP-090728 0447 1 Incorrect CR implementation 8.6.0 Dec 2009 CT#46 0452 1 Unregistered user clarification 8.7.0 Dec 2009 CT#46 0456 2 Session-Priority AVP 8.7.0 Dec 2009 CT#46 0457 2 HSS behaviour after PPA with unknown user 8.7.0 Dec 2009 CT#46 0458 1 Check of the S-CSCF Name 8.7.0 Dec 2009 CT#46 0460 IMPI must be sent in SAR for UE initiated requests 8.7.0 Dec 2009 CT#46 Upgraded unchanged from Rel-8 9.0.0 Mar 2010 CT#47 CP-100033 0462 Default IMPU 9.1.0 Mar 2010 CT#47 CP-100031 0468 1 Wildcarded Public Identity 9.1.0 Mar 2010 CT#47 CP-100033 0470 1 Priority service attribute 9.1.0 Mar 2010 CT#47 CP-100033 0474 1 User-Auth-Type not checked 9.1.0 Mar 2010 CT#47 CP-100033 0476 1 GIBA is not allowed when auth. Scheme is Unknown 9.1.0 Mar 2010 CT#47 CP-100042 0477 2 Clarification on the use of User-Data-Already-Available 9.1.0 Mar 2010 CT#47 CP-100015 0482 Server Capabilities 9.1.0 Mar 2010 CT#47 CP-100031 0466 RTR for wildcarded public user identity 9.1.0 May 2010 Xml-file corrected 9.1.1 Jun 2010 CT#48 CP-100412 0484 3 Table not aligned with XML schema for wildcarded identities 9.2.0 Jun 2010 CT#48 CP-100412 0487 3 SAR with NO_ASSIGNMENT correction 9.2.0 Jun 2010 CT#48 CP-100412 0489 2 Update of IETF Reference 9.2.0 Sep 2010 CT#49 CP-100447 0493 2 Wildcarded Identities handling 9.3.0 Sep 2010 CT#49 CP-100447 0495 Wrong order in table for XML schema 9.3.0 Sep 2010 CT#49 CP-100447 0497 2 Cx-MAR handling correction in restoration procedures 9.3.0 Sep 2010 CT#49 CP-100447 500 1 Ambiguity of Presence Conditions of IEs and AVP ABNF 9.3.0 Sep 2010 CT#49 CP-100447 507 Correction for de-registration procedure at restoration 9.3.0 Sep 2010 CT#49 CP-100447 504 2 Mandatory and optional capabilities handling 9.3.0 Dec 2010 CT#50 CP-100668 0519 Coding of SIP-Authorization AVP and SIP-Authenticate AVP 9.4.0 Dec 2010 CT#50 CP-100697 0509 1 Clarification on Alias 10.0.0 Mar 2011 CT#51 CP-110044 0521 - Originating_CDIV Session Case including in XML 10.1.0 Mar 2011 CT#51 CP-110060 0515 5 MPS over Cx 10.1.0 Jun 2011 CT#52 CP-110349 0529 2 Handling of RTR for Emergency Registration 10.2.0 Jun 2011 CT#52 CP-110356 0532 1 Emergency Restoration 10.2.0 Jun 2011 CT#52 CP-110356 0535 - Incorrect Use of Result-Code AVP 10.2.0 Jun 2011 CT#52 CP-110356 0538 1 Error in assignment type for backward compatibility scenarios 10.2.0 Jun 2011 CT#52 CP-110383 0520 4 Reference Location over Cx interface 11.0.0 Sep 2011 CT#53 CP-110566 0542 Priviledged sender 11.1.0 Sep 2011 CT#53 CP-110566 0546 1 Public Identity in canonical form 11.1.0 Dec 2011 CT#54 CP-110781 0552 1 Identity in the service profile 11.2.0 Dec 2011 CT#54 CP-110781 0557 2 Providing the IMSI to the S-CSCF 11.2.0 Dec 2011 CT#54 CP-110809 0553 1 Behaviour of HSS not supported IMS Restoration Procedures to LIR 11.2.0 Mar 2012 CT#55 CP-120014 0562 1 Server-Capability AVP in LIA and UAA 11.3.0 Mar 2012 CT#55 CP-120014 0566 1 Update of charging information and authentication data 11.3.0 Jun 2012 CT#56 CP-120245 0558 2 Maximum Number of simultaneous registrations 11.4.0 Sep 2012 CT#57 CP-120439 0576 1 Emergency registrations do not affect registration status 11.5.0 Sep 2012 CT#57 CP-120456 0577 1 Add RequestURI parameter to SPT matching 11.5.0 Nov 2012 The specification version number in the header corrected 11.5.1 Dec 2012 CT#58 CP-120743 0578 - Experimental-Result-Code correction 11.6.0 Dec 2012 CT#58 CP-120743 0582 3 PSI direct routing with restoration procedures 11.6.0 Dec 2012 CT#58 CP-120743 0583 - Negated Session Case 11.6.0 Mar 2013 CT#59 CP-130011 0593 1 Identities with emergency registration in RTR 11.7.0 Mar 2013 CT#59 CP-130020 0599 1 Clarification on Reference Location information 11.7.0 Jun 2013 CT#60 CP-130374 0600 1 Absent User-Name after S-CSCF recovery 11.8.0 Sep 2013 CT#61 CP-130439 0606 2 Cancellation of the old S-CSCF for IMS Subscription and IMS Restoration Procedures 11.9.0 Sep 2013 CT#61 CP-13046clause 0601 - Correction on Emergency Registration 12.0.0 Dec 2013 CT#62 CP-130627 0607 5 Cx Charging Information Download 12.1.0 Jun 2014 CT#64 CP-140237 0609 2 Wildcarded Public Identity in SAA 12.2.0 Jun 2014 CT#64 CP-140243 0611 2 Diameter Overload Control Over Cx 12.2.0 Sep 2014 CT#65 CP-140506 0624 2 P-CSCF Restoration indication 12.3.0 Sep 2014 CT#65 CP-140515 0626 - Clarification on REGISTRATION_AND_CAPABILITIES for De-registration 12.3.0 Sep 2014 CT#65 CP-140515 0627 - Clarification on Unregistered User 12.3.0 Dec 2014 CT#66 CP-140794 0628 2 HSS behaviour when P-CSCF Restoration indication is received 12.4.0 Dec 2014 CT#66 CP-140790 0630 1 Priority Consideration for Diameter Overload Control 12.4.0 Dec 2014 CT#66 CP-140777 0632 1 Addition of IMS-AKA based on HTTP Digest AKAv2 for WebRTC 12.4.0 Mar 2015 CT#67 CP-150023 0639 1 IMSI Encoding over Cx 12.5.0 Jun 2015 CT#68 CP-150251 0633 4 RTR handling when emergency registration 12.6.0 Jun 2015 CT#68 CP-150251 0642 1 ""Digest-AKAv1-MD5"" is used as well for other Digest-AKA versions 12.6.0 Jun 2015 CT#68 CP-150251 0643 Confidentiality-key is mandatory 12.6.0 Jun 2015 CT#68 CP-150261 0640 - ADMINISTRATIVE_DEREGISTRATION with P-CSCF-Restoration-Indication 12.6.0 July 2016 Correction of typo in previous line of history table. 12.6.1 Sep 2015 CT#69 CP-150428 0647 1 Authentication tables and IE clarifications in MAR/MAA 12.7.0 Sep 2015 CT#69 CP-150428 0649 - Wrong CR update 12.7.0 Sep 2015 CT#69 CP-150432 0644 1 S-CSCF Restoration Information deletion with SAT=UNREGISTERED_USER 12.7.0 Sep 2015 CT#69 CP-150436 0645 - P-CSCF Restoration when IMS Restoration is supported 12.7.0 Dec 2015 CT#70 CP-150754 0653 2 Allowed WAF and/or WWSF Identities 12.8.0 Dec 2015 CT#70 CP-150750 0654 1 Authentication Information IE clarification 12.8.0 Dec 2015 CT#70 CP-150749 0655 1 De-registration without IMPI 12.8.0 Dec 2015 CT#70 CP-150749 0656 1 IMSI change 12.8.0 Dec 2015 CT#70 CP-150759 0658 1 Update reference to DOIC new IETF RFC 12.8.0 Dec 2015 CT#70 CP-150775 0652 4 HSS supports IMS subscriptions corresponding to users managed by third parties 13.0.0 Dec 2015 CT#70 CP-150768 0659 4 DRMP AVP Procedures over Cx/Dx 13.0.0 Mar 2016 CT#71 CP-160031 0661 6 Introduction of AAA-1 interface 13.1.0 Mar 2016 CT#71 CP-160046 0662 - De-registration of emergency registration correction 13.1.0 Jun 2016 CT#72 CP-160215 0665 1 Diameter requests for priority traffic during overload control mechanism 13.2.0 07-2016 Correction to spec version number on cover page 13.2.1 09-2016 CT#73 CP-160431 0666 1 S-CSCF Restoration during Registration enhancement 14.0.0 2016-12 CT#74 CP-160646 0673 2 Reference Location 14.1.0 2016-12 CT#74 CP-160672 0674 1 Service Profile and iFC alignment between XML and text/UML 14.1.0 2016-12 CT#74 CP-160681 0675 1 Load Control 14.1.0 2016-12 CT#74 CP-160664 0677 - Correction to change IETF drmp draft version to official RFC 7944 14.1.0 2017-03 CT#75 CP-170045 0678 - Mission Critical Services 14.2.0 2017-03 CT#75 CP-170048 0679 1 Update of reference for the Diameter base protocol 14.2.0 2017-06 CT#76 CP-171034 0680 1 IMS Trace (ISAT) Reference Updates 14.3.0 2017-06 CT#76 CP-171018 0684 1 Support for signaling transport level packet marking 14.3.0 2017-09 CT#77 CP-172012 0686 - Correction of DRMP Procedures 14.4.0 2017-12 CT#78 CP-173011 0687 1 Cx Subscriber Deregistration Reason 14.5.0 2018-06 CT#80 CP-181121 0688 1 Change of Reference Location Information 15.0.0 2018-09 CT#81 CP-182069 0689 - P-CSCF restoration for 5GC 15.1.0 2019-03 CT#83 CP-190035 0690 1 Reference Location Information change 15.2.0 2019-09 CT#85 CP-192094 0693 2 draft-ietf-dime-load published as RFC 8583 15.3.0 2019-09 CT#85 CP-192150 0691 1 Wildcarded Public Identity in SAA 16.0.0 2019-12 CT#86 CP-193047 0694 - RLOS related registrations 16.1.0 2021-12 CT#94e CP-213104 0696 - B Update of SIP Digest Access Authentication 17.0.0 2022-03 CT#95e CP-220052 0699 1 B Support of the hash value for alternate SIP Digest algorithm 17.1.0 2022-03 CT#95e CP-220054 0697 - B Failed P-CSCF 17.1.0 14 Release 17 3GPP 3GPP TS 29.002 V17.2.0 (2022-06) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Mobile Application Part (MAP) specification (Release 17) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2021, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 28 1 Scope 29 2 References 29 3 Abbreviations 35 4 Void 36 5 Overload and compatibility overview 36 5.1 Overload control 36 5.1.1 Overload control for MSC (outside MAP) 36 5.1.2 Overload control for MAP entities 36 5.1.3 Congestion control for Signalling System No."
"7 40 5.2 Compatibility 40 5.2.1 General 40 5.2.2 Strategy for selecting the Application Context (AC) version 40 5.2.2.1 Proposed method 40 5.2.2.2 Managing the version look-up table 41 5.2.2.3 Optimising the method 42 6 Requirements concerning the use of SCCP and TC 42 6.1 Use of SCCP 42 6.1.1 SCCP Class 42 6.1.2 Sub-System Number (SSN) 42 6.1.3 SCCP addressing 43 6.1.3.1 Introduction 43 6.1.3.2 The Mobile-services Switching Centre (MSC) 45 6.1.3.2.1 MSC interaction during handover or relocation 45 6.1.3.2.2 MSC for short message routing 45 6.1.3.2.3 MSC for location request routing 45 6.1.3.2.4 MSC for LMU Control 45 6.1.3.3 The Home Location Register (HLR) 46 6.1.3.3.1 During call set-up 46 6.1.3.3.2 Before location updating completion 46 6.1.3.3.3 After location updating completion 46 6.1.3.3.4 VLR restoration 47 6.1.3.3.5 During Network-Requested PDP Context Activation 47 6.1.3.3.6 Before GPRS location updating completion 47 6.1.3.3.7 After GPRS location updating completion 48 6.1.3.3.8 Query for a Location Request 48 6.1.3.4 The Visitor Location Register (VLR) 48 6.1.3.4.0 General 48 6.1.3.4.1 Inter-VLR information retrieval 48 6.1.3.4.2 HLR request 48 6.1.3.4.3 CSS request 49 6.1.3.5 The Interworking MSC (IWMSC) for Short Message Service 49 6.1.3.6 The Equipment Identity Register (EIR) 49 6.1.3.7 Void 49 6.1.3.8 The Serving GPRS Support Node (SGSN) 49 6.1.3.8.0 General 49 6.1.3.8.1 HLR request 49 6.1.3.8.2 GMSC request 49 6.1.3.8.3 CSS request 49 6.1.3.9 The Gateway GPRS Support Node (GGSN) 49 6.1.3.10 The Gateway MSC (GMSC) for Short Message Service 50 6.1.3.10A Void 50 6.1.3.10A.1 Void 50 6.1.3.10A.2 Void 50 6.1.3.10B The Gateway Mobile Location Centre (GMLC) 50 6.1.3.10C The CSG Subscriber Server (CSS) 50 6.1.3.11 Summary table 50 6.2 Use of TC 53 7 General on MAP services 53 7.1 Terminology and definitions 53 7.2 Modelling principles 53 7.3 Common MAP services 54 7.3.1 MAP-OPEN service 55 7.3.2 MAP-CLOSE service 58 7.3.3 MAP-DELIMITER service 58 7.3.4 MAP-U-ABORT service 58 7.3.5 MAP-P-ABORT service 59 7.3.6 MAP-NOTICE service 60 7.3.7 Void 61 7.3.8 Void 61 7.3.9 Void 61 7.3.10 Void 61 7.4 Sequencing of services 61 7.5 General rules for mapping of services onto TC 62 7.5.1 Mapping of common services 62 7.5.2 Mapping of user specific services 63 7.6 Definition of parameters 64 7.6.1 Common parameters 64 7.6.1.1 Invoke Id 64 7.6.1.2 Linked Id 64 7.6.1.3 Provider error 64 7.6.1.4 User error 64 7.6.2 Numbering and identification parameters 68 7.6.2.1 IMSI 68 7.6.2.2 TMSI 68 7.6.2.3 IMEI 68 7.6.2.3a IMEISV 68 7.6.2.4 Previous location area Id 68 7.6.2.5 Stored location area Id 68 7.6.2.6 Current location area Id 68 7.6.2.7 Target location area Id 68 7.6.2.8 Target cell Id 68 7.6.2.8A Target RNC Id 68 7.6.2.9 Void 68 7.6.2.10 Originating entity number 69 7.6.2.11 MSC number 69 7.6.2.12 Target MSC number 69 7.6.2.13 HLR number 69 7.6.2.14 VLR number 69 7.6.2.15 HLR Id 69 7.6.2.16 LMSI 69 7.6.2.17 MS ISDN 69 7.6.2.17A Additional MSISDN 69 7.6.2.18 OMC Id 69 7.6.2.19 Roaming number 69 7.6.2.19A Relocation Number List 69 7.6.2.20 Void 69 7.6.2.21 Handover number 69 7.6.2.22 Forwarded-to number 70 7.6.2.22A Long forwarded-to number 70 7.6.2.22B Long FTN Supported 70 7.6.2.23 Forwarded-to subaddress 70 7.6.2.24 Called number 70 7.6.2.25 Calling number 70 7.6.2.26 Originally dialled number 70 7.6.2.27 Service centre address 70 7.6.2.28 Zone Code 70 7.6.2.29 MSIsdn-Alert 70 7.6.2.30 Location Information 70 7.6.2.30a Location Information for GPRS 70 7.6.2.30b Location Information for EPS 70 7.6.2.31 GMSC Address 70 7.6.2.32 VMSC Address 71 7.6.2.33 Group Id 71 7.6.2.34 North American Equal Access preferred Carrier Id 71 7.6.2.35 Void 71 7.6.2.36 Void 71 7.6.2.37 Serving cell Id 71 7.6.2.38 SGSN number 71 7.6.2.39 SGSN address 71 7.6.2.40 GGSN address 71 7.6.2.41 GGSN number 71 7.6.2.42 APN 71 7.6.2.43 Network Node number 72 7.6.2.43A Network Node Diameter Address 72 7.6.2.44 PDP-Type 72 7.6.2.44A Extension PDP-Type 72 7.6.2.45 PDP-Address 72 7.6.2.45A Extension PDP-Address 72 7.6.2.46 Additional number 72 7.6.2.46A Additional Network Node Diameter Address 72 7.6.2.46B Third Number 72 7.6.2.46C Third Network Node Diameter Address 72 7.6.2.47 P-TMSI 72 7.6.2.48 B-subscriber number 73 7.6.2.49 B-subscriber subaddress 73 7.6.2.50 LMU Number 73 7.6.2.51 MLC Number 73 7.6.2.52 Multicall Bearer Information 73 7.6.2.53 Multiple Bearer Requested 73 7.6.2.54 Multiple Bearer Not Supported 73 7.6.2.55 PDP-Charging Characteristics 73 7.6.2.56 Selected RAB ID 73 7.6.2.57 RAB ID 73 7.6.2.58 gsmSCF Address 73 7.6.2.59 V-GMLC Address 73 7.6.2.60 Void 73 7.6.2.61 H-GMLC Address 73 7.6.2.62 PPR Address 74 7.6.2.63 Routeing Number 74 7.6.2.64 Additional V-GMLC Address 74 7.6.2.65 MME Name 74 7.6.2.66 3GPP AAA Server Name 74 7.6.2.67 CSS number 74 7.6.2.68 SGSN Name 74 7.6.2.69 SGSN Realm 74 7.6.3 Subscriber management parameters 74 7.6.3.1 Category 74 7.6.3.2 Equipment status 74 7.6.3.2a BMUEF 74 7.6.3.3 Extensible Bearer service 74 7.6.3.4 Extensible Teleservice 74 7.6.3.5 Extensible Basic Service Group 75 7.6.3.6 GSM bearer capability 75 7.6.3.7 Subscriber Status 75 7.6.3.8 CUG Outgoing Access indicator 75 7.6.3.9 Operator Determined Barring General Data 75 7.6.3.10 ODB HPLMN Specific Data 77 7.6.3.11 Regional Subscription Data 77 7.6.3.12 Regional Subscription Response 77 7.6.3.13 Roaming Restriction Due To Unsupported Feature 78 7.6.3.14 Extensible SS-Info 78 7.6.3.15 Extensible forwarding information 78 7.6.3.16 Extensible forwarding feature 78 7.6.3.17 Extensible SS-Status 78 7.6.3.18 Extensible Forwarding Options 78 7.6.3.19 Extensible No reply condition timer 79 7.6.3.20 Extensible Call barring information 79 7.6.3.21 Extensible Call barring feature 79 7.6.3.22 CUG info 79 7.6.3.23 CUG subscription 79 7.6.3.24 CUG interlock 79 7.6.3.25 CUG index 80 7.6.3.26 CUG feature 80 7.6.3.27 Inter CUG options 80 7.6.3.28 Intra CUG restrictions 80 7.6.3.29 Extensible SS-Data 80 7.6.3.30 Subscriber State 80 7.6.3.31 Requested Info 81 7.6.3.31A Requested Domain 81 7.6.3.32 Suppression of Announcement 81 7.6.3.33 Suppress T-CSI 81 7.6.3.34 GMSC CAMEL Subscription Info 81 7.6.3.35 VLR CAMEL Subscription Info 81 7.6.3.36 Supported CAMEL Phases in the VLR 81 7.6.3.36A Supported CAMEL Phases in the SGSN 81 7.6.3.36B Offered CAMEL4 CSIs in the VLR 81 7.6.3.36C Offered CAMEL4 CSIs in the SGSN 81 7.6.3.36D Offered CAMEL4 CSIs 81 7.6.3.36E Offered CAMEL4 CSIs in interrogating node 81 7.6.3.36F Offered CAMEL4 CSIs in VMSC 81 7.6.3.36G Offered CAMEL4 Functionalities 82 7.6.3.36H Supported CAMEL Phases 82 7.6.3.36I Supported CAMEL Phases in interrogating node 82 7.6.3.37 CUG Subscription Flag 82 7.6.3.38 CAMEL Subscription Info Withdraw 82 7.6.3.39 Voice Group Call Service (VGCS) Data 82 7.6.3.40 Voice Broadcast Service (VBS) Data 82 7.6.3.41 ISDN bearer capability 82 7.6.3.42 Lower layer Compatibility 82 7.6.3.43 High Layer Compatibility 82 7.6.3.44 Alerting Pattern 82 7.6.3.45 GPRS Subscription Data Withdraw 82 7.6.3.45A EPS Subscription Data Withdraw 82 7.6.3.46 GPRS Subscription Data 83 7.6.3.46A EPS Subscription Data 83 7.6.3.47 QoS-Subscribed 83 7.6.3.48 VPLMN address allowed 83 7.6.3.49 Roaming Restricted In SGSN/MME Due To Unsupported Feature 83 7.6.3.50 Network Access Mode 83 7.6.3.51 Mobile Not Reachable Reason 83 7.6.3.52 Cancellation Type 83 7.6.3.53 All GPRS Data 83 7.6.3.54 Complete Data List Included 83 7.6.3.55 PDP Context Identifier 83 7.6.3.56 LSA Information 83 7.6.3.57 SoLSA support indicator 84 7.6.3.58 LSA Information Withdraw 84 7.6.3.59 LMU Indicator 84 7.6.3.60 LCS Information 84 7.6.3.61 GMLC List 84 7.6.3.62 LCS Privacy Exception List 84 7.6.3.62A Additional LCS Privacy Exception List 84 7.6.3.63 LCS Privacy Exception Parameters 84 7.6.3.64 External Client List 85 7.6.3.65 Internal Client List 85 7.6.3.65A MO-LR List 85 7.6.3.65B Privacy Notification to MS User 85 7.6.3.65C GMLC List Withdraw 85 7.6.3.65D Service Type List 85 7.6.3.66 IST Alert Timer 85 7.6.3.67 Call Termination Indicator 85 7.6.3.68 IST Information Withdraw 85 7.6.3.69 IST Support Indicator 85 7.6.3.70 Super-Charger Supported In HLR 86 7.6.3.71 Super-Charger Supported In Serving Network Entity 86 7.6.3.72 Age Indicator 86 7.6.3.73 GPRS enhancements support indicator 86 7.6.3.74 Extension QoS-Subscribed 86 7.6.3.75 SGSN CAMEL Subscription Info 86 7.6.3.75A Extension-2 QoS-Subscribed 86 7.6.3.75B Extension-3 QoS-Subscribed 86 7.6.3.75C Extension-4 QoS-Subscribed 86 7.6.3.76 MO-SMS-CSI 86 7.6.3.76a MT-SMS-CSI 87 7.6.3.77 GPRS-CSI 87 7.6.3.78 CAMEL subscription info 87 7.6.3.83 Call Barring Data 87 7.6.3.84 Call Forwarding Data 87 7.6.3.85 ODB Data 88 7.6.3.86 Requested Subscription Info 88 7.6.3.87 CS Allocation/Retention priority 88 7.6.3.88 ODB Info 88 7.6.3.89 Suppress VT-CSI 88 7.6.3.90 Suppress Incoming Call Barring 88 7.6.3.91 gsmSCF Initiated Call 88 7.6.3.91a SuppressMTSS 88 7.6.3.92 Call barring support indicator 88 7.6.3.93 MNP Info Result 88 7.6.3.94 Allowed Services 88 7.6.3.95 Unavailability Cause 89 7.6.3.96 MNP Requested Info 89 7.6.3.97 Access Restriction Data 89 7.6.3.98 Supported RAT types indicator 89 7.6.3.99 UE SRVCC Capability 89 7.6.3.100 Temporary Empty CSG Subscription data Indicator 89 7.6.3.101 WLAN-offloadability 89 7.6.3.102 IMSI-Group-Id 89 7.6.4 Supplementary services parameters 89 7.6.4.1 SS-Code 89 7.6.4.1A SS-Code 2 90 7.6.4.2 SS-Status 90 7.6.4.3 SS-Data 90 7.6.4.4 Override Category 90 7.6.4.5 CLI Restriction Option 90 7.6.4.6 Forwarding Options 91 7.6.4.7 No reply condition timer 91 7.6.4.8 - 7.6.4.14 Void 91 7.6.4.15 Forwarding information 91 7.6.4.16 Forwarding feature 91 7.6.4.17 Void 91 7.6.4.18 Call barring information 91 7.6.4.19 Call barring feature 92 7.6.4.20 New password 92 7.6.4.21 Current password 92 7.6.4.22 Guidance information 92 7.6.4.23 Void 92 7.6.4.24 SS-Info 92 7.6.4.25 - 7.6.4.35 Void 92 7.6.4.36 USSD Data Coding Scheme 93 7.6.4.37 USSD String 93 7.6.4.38 Bearer service 93 7,6,4.38A Bearer Service 2 93 7.6.4.39 Teleservice 93 7.6.4.39A Teleservice 2 93 7.6.4.40 Basic Service Group 93 7.6.4.41 eMLPP information 93 7.6.4.42 SS-event 93 7.6.4.43 SS-event data 94 7.6.4.44 LCS Privacy Exceptions 94 7.6.4.45 Mobile Originating Location Request (MO-LR) 94 7.6.4.46 NbrUser 94 7.6.4.47 MC Subscription Data 94 7.6.4.48 MC Information 94 7.6.4.49 CCBS Request State 95 7.6.4.50 Basic Service Group 2 95 7.6.5 Call parameters 95 7.6.5.1 Call reference number 95 7.6.5.2 Interrogation type 95 7.6.5.3 OR interrogation 95 7.6.5.4 OR capability 95 7.6.5.5 Forwarding reason 95 7.6.5.6 Forwarding interrogation required 96 7.6.5.7 O-CSI 96 7.6.5.7A D-CSI 96 7.6.5.7B T-CSI 96 7.6.5.7C VT-CSI 96 7.6.5.7D O-IM-CSI 96 7.6.5.7E D-IM-CSI 96 7.6.5.7F VT-IM-CSI 96 7.6.5.8 Void 96 7.6.5.9 Void 96 7.6.5.10 Void 96 7.6.5.11 CCBS Feature 96 7.6.5.12 UU Data 97 7.6.5.14 Number Portability Status 97 7.6.5.15 Pre-paging supported 97 7.6.5.16 MT Roaming Retry Supported 97 7.6.5.17 MT Roaming Retry 97 7.6.5.18 Paging Area 97 7.6.5.19 Call Priority 97 7.6.5.20 MTRF Supported 97 7.6.5.21 LCLS Global Call Reference (LCLS GCR) 97 7.6.5.22 LCLS-Negotiation 97 7.6.5.23 LCLS-Configuration-Preference 97 7.6.6 Radio parameters 97 7.6.6.1 - 7.6.6.3 Void 98 7.6.6.4 GERAN Classmark 98 7.6.6.5 BSSMAP Service Handover 98 7.6.6.5A BSSMAP Service Handover List 98 7.6.6.6 RANAP Service Handover 98 7.6.6.7 HO-Number Not Required 98 7.6.6.8 Integrity Protection Information 98 7.6.6.9 Encryption Information 98 7.6.6.10 Radio Resource Information 98 7.6.6.10A Radio Resource List 98 7.6.6.10B Chosen Radio Resource Information 98 7.6.6.11 Key Status 98 7.6.6.12 Selected UMTS Algorithms 98 7.6.6.13 Allowed GSM Algorithms 98 7.6.6.14 Allowed UMTS Algorithms 99 7.6.6.15 Selected GSM Algorithm 99 7.6.6.16 Iu-Currently Used Codec 99 7.6.6.17 Iu-Supported Codecs List 99 7.6.6.17A Iu-Available Codecs List 99 7.6.6.18 Iu-Selected Codec 99 7.6.6.19 RAB Configuration Indicator 99 7.6.6.20 UESBI-Iu 99 7.6.6.21 Alternative Channel Type 99 7.6.6.22 AoIP-Supported Codecs List Anchor 99 7.6.6.23 AoIP-Available Codecs List Map 99 7.6.6.24 AoIP-Selected Codec Target 99 7.6.7 Authentication parameters 100 7.6.7.1 Authentication set list 100 7.6.7.2 Rand 100 7.6.7.3 Sres 100 7.6.7.4 Kc 100 7.6.7.5 Xres 100 7.6.7.5A Ck 100 7.6.7.5B Ik 100 7.6.7.5C Autn 100 7.6.7.5D KASME 100 7.6.7.6 Cksn 100 7.6.7.6A Ksi 100 7.6.7.6B Auts 100 7.6.7.7 Ciphering mode 101 7.6.7.8 Current Security Context 101 7.6.7.9 Failure cause 101 7.6.7.10 Re-attempt 101 7.6.7.11 Access Type 101 7.6.8 Short message parameters 101 7.6.8.1 SM-RP-DA 101 7.6.8.2 SM-RP-OA 101 7.6.8.3 MWD status 101 7.6.8.4 SM-RP-UI 102 7.6.8.5 SM-RP-PRI 102 7.6.8.6 SM Delivery Outcome 102 7.6.8.7 More Messages To Send 102 7.6.8.8 Alert Reason 102 7.6.8.9 Absent Subscriber Diagnostic SM 102 7.6.8.10 Alert Reason Indicator 102 7.6.8.10A Additional Alert Reason Indicator 102 7.6.8.11 Additional SM Delivery Outcome 102 7.6.8.12 Additional Absent Subscriber Diagnostic SM 102 7.6.8.13 Delivery Outcome Indicator 103 7.6.8.14 GPRS Node Indicator 103 7.6.8.14A IMS Node Indicator 103 7.6.8.15 GPRS Support Indicator 103 7.6.8.16 SM-RP-MTI 103 7.6.8.17 SM-RP-SMEA 103 7.6.8.18 IP-SM-GW SM Delivery Outcome 103 7.6.8.19 IP-SM-GW Absent Subscriber Diagnostic SM 103 7.6.8.20 IP-SM-GW Indicator 103 7.6.8.21 SM Delivery Timer 103 7.6.8.22 SM Delivery Start Time 103 7.6.8.23 Maximum Retransmission Time 103 7.6.8.24 Requested Retransmission Time 103 7.6.8.25 Maximum UE Availability Time 104 7.6.8.26 SMS-GMSC Alert Event 104 7.6.8.27 SMS-GMSC Address 104 7.6.8.28 SMS-GMSC Diameter Address 104 7.6.8.29 New SGSN Number 104 7.6.8.30 New MME Number 104 7.6.8.31 New SGSN Diameter Address 104 7.6.8.32 New MME Diameter Address 104 7.6.8.33 New MSC Number 104 7.6.8.34 SMSF 3GPP Absent Subscriber Diagnostic SM 104 7.6.8.35 SMSF Non 3GPP Absent Subscriber Diagnostic SM 104 7.6.8.36 SMSF 3GPP Delivery Outcome Indicator 104 7.6.8.37 SMSF Non-3GPP Delivery Outcome Indicator 105 7.6.8.38 SMSF 3GPP SM Delivery Outcome 105 7.6.8.39 SMSF Non-3GPP SM Delivery Outcome 105 7.6.8.40 SMSF 3GPP Absent Subscriber Diagnostic SM 105 7.6.8.41 SMSF Non 3GPP Absent Subscriber Diagnostic SM 105 7.6.9 Access and signalling system related parameters 105 7.6.9.1 AN-apdu 105 7.6.9.2 CM service type 105 7.6.9.3 Access connection status 105 7.6.9.4 External Signal Information 106 7.6.9.5 Access signalling information 106 7.6.9.6 Location update type 106 7.6.9.7 Protocol ID 106 7.6.9.8 Network signal information 106 7.6.9.8A Network signal information 2 107 7.6.9.9 Call Info 107 7.6.9.10 Additional signal info 107 7.6.10 System operations parameters 107 7.6.10.1 Network resources 108 7.6.10.2 Trace reference 108 7.6.10.2A Trace reference 2 108 7.6.10.3 Trace type 108 7.6.10.4 Additional network resources 108 7.6.10.5 Trace depth list 108 7.6.10.6 Trace NE type list 108 7.6.10.7 Trace interface list 108 7.6.10.8 Trace event list 108 7.6.10.9 Trace support indicator 109 7.6.10.10 Trace Propagation List 109 7.6.10.11 MDT-Configuration 109 7.6.10.12 MDT User Consent 109 7.6.11 Location Service Parameters 109 7.6.11.1 Age of Location Estimate 109 7.6.11.2 Deferred MT-LR Response Indicator 109 7.6.11.3 Deferred MT-LR Data 109 7.6.11.4 LCS Client ID 109 7.6.11.5 LCS Event 109 7.6.11.7 LCS Priority 109 7.6.11.8 LCS QoS 109 7.6.11.9 CS LCS Not Supported by UE 110 7.6.11.10 PS LCS Not Supported by UE 110 7.6.11.11 Location Estimate 110 7.6.11.11A GERAN Positioning Data 110 7.6.11.11B UTRAN Positioning Data 110 7.6.11.11C GERAN GANSS Positioning Data 111 7.6.11.11D UTRAN GANSS Positioning Data 111 7.6.11.11E UTRAN Additional Positioning Data 111 7.6.11.11F UTRAN Barometric Pressure Measurement 111 7.6.11.11G UTRAN Civic Address 111 7.6.11.12 Location Type 111 7.6.11.13 NA-ESRD 111 7.6.11.14 NA-ESRK 111 7.6.11.15 LCS Service Type Id 111 7.6.11.16 Privacy Override 111 7.6.11.17 Supported LCS Capability Sets 112 7.6.11.18 LCS Codeword 112 7.6.11.19 NA-ESRK Request 112 7.6.11.20 Supported GAD Shapes 112 7.6.11.21 Additional Location Estimate 112 7.6.11.22 Cell Id Or SAI 112 7.6.11.23 LCS-Reference Number 112 7.6.11.24 LCS Privacy Check 112 7.6.11.25 Additional LCS Capability Sets 113 7.6.11.26 Area Event Info 113 7.6.11.27 Velocity Estimate 113 7.6.11.28 Accuracy Fulfilment Indicator 113 7.6.11.29 MO-LR Short Circuit Indicator 113 7.6.11.30 Reporting PLMN List 113 7.6.11.31 Periodic LDR information 113 7.6.11.32 Sequence Number 113 7.6.12 Void 113 7.7 Representation of a list of a basic parameter in service-primitives 114 8 Mobility services 114 8.1 Location management services 114 8.1.1 Void 114 8.1.1.1 Void 114 8.1.1.2 Void 114 8.1.1.3 Void 114 8.1.2 MAP_UPDATE_LOCATION service 114 8.1.2.1 Definition 114 8.1.2.2 Service primitives 114 8.1.2.3 Parameter definitions and use 115 8.1.3 MAP_CANCEL_LOCATION service 118 8.1.3.1 Definition 118 8.1.3.2 Service primitives 118 8.1.3.3 Parameter definitions and use 118 8.1.4 MAP_SEND_IDENTIFICATION service 119 8.1.4.1 Definition 119 8.1.4.2 Service primitives 119 8.1.4.3 Parameter definitions and use 120 8.1.5 Void 121 8.1.5.1 Void 121 8.1.5.2 Void 121 8.1.5.3 Void 121 8.1.6 MAP_PURGE_MS service 121 8.1.6.1 Definition 121 8.1.6.2 Service primitives 122 8.1.6.3 Parameter definitions and use 122 8.1.7 MAP_UPDATE_GPRS_LOCATION service 123 8.1.7.1 Definition 123 8.1.7.2 Service primitives 123 8.1.7.3 Parameter definitions and use 124 8.1.8 MAP-NOTE-MM-EVENT 128 8.1.8.1 Definition 128 8.1.8.2 Service primitives 128 8.1.8.3 Parameter use 129 8.1.9 MAP_UPDATE_VCSG_LOCATION service 130 8.1.9.1 Definition 130 8.1.9.2 Service primitives 130 8.1.9.3 Parameter definitions and use 131 8.1.10 MAP_ CANCEL_VCSG_LOCATION service 131 8.1.10.1 Definition 131 8.1.10.2 Service primitives 131 8.1.10.3 Parameter definitions and use 132 8.2 Paging and search 132 8.2.1 MAP_PAGE service 132 8.2.1.1 Definition 132 8.2.1.2 Service primitives 132 8.2.1.3 Parameter definitions and use 132 8.2.2 MAP_SEARCH_FOR_MS service 133 8.2.2.1 Definition 133 8.2.2.2 Service primitives 133 8.2.2.3 Parameter definitions and use 133 8.3 Access management services 134 8.3.1 MAP_PROCESS_ACCESS_REQUEST service 134 8.3.1.1 Definition 134 8.3.1.2 Service primitives 134 8.3.1.3 Parameter definitions and use 134 8.4 Handover services 136 8.4.1 MAP_PREPARE_HANDOVER service 136 8.4.1.1 Definition 136 8.4.1.2 Service primitives 136 8.4.1.3 Parameter use 137 8.4.2 MAP_SEND_END_SIGNAL service 141 8.4.2.1 Definition 141 8.4.2.2 Service primitives 141 8.4.2.3 Parameter use 141 8.4.3 MAP_PROCESS_ACCESS_SIGNALLING service 141 8.4.3.1 Definition 141 8.4.3.2 Service primitives 141 8.4.3.3 Parameter use 142 8.4.4 MAP_FORWARD_ACCESS_SIGNALLING service 143 8.4.4.1 Definition 143 8.4.4.2 Service primitives 143 8.4.4.3 Parameter use 144 8.4.5 MAP_PREPARE_SUBSEQUENT_HANDOVER service 146 8.4.5.1 Definition 146 8.4.5.2 Service primitives 146 8.4.5.3 Parameter use 146 8.4.6 MAP_ALLOCATE_HANDOVER_NUMBER service 147 8.4.6.1 Definition 147 8.4.6.2 Service primitives 147 8.4.6.3 Parameter use 147 8.4.7 MAP_SEND_HANDOVER_REPORT service 148 8.4.7.1 Definition 148 8.4.7.2 Service primitives 148 8.4.7.3 Parameter use 148 8.5 Authentication management services 148 8.5.1 MAP_AUTHENTICATE service 148 8.5.1.1 Definition 148 8.5.1.2 Service primitives 149 8.5.1.3 Parameter use 149 8.5.2 MAP_SEND_AUTHENTICATION_INFO service 149 8.5.2.1 Definition 149 8.5.2.2 Service primitives 150 8.5.2.3 Parameter use 150 8.5.3 MAP_AUTHENTICATION_FAILURE_REPORT service 152 8.5.3.1 Definition 152 8.5.3.2 Service primitives 152 8.5.3.3 Parameter use 152 8.6 Security management services 153 8.6.1 MAP_SET_CIPHERING_MODE service 153 8.6.1.1 Definitions 153 8.6.1.2 Service primitives 153 8.6.1.3 Parameter use 153 8.7 International mobile equipment identities management services 154 8.7.1 MAP_CHECK_IMEI service 154 8.7.1.1 Definition 154 8.7.1.2 Service primitives 154 8.7.1.3 Parameter use 154 8.7.2 MAP_OBTAIN_IMEI service 155 8.7.2.1 Definition 155 8.7.2.2 Service primitives 155 8.7.2.3 Parameter use 155 8.8 Subscriber management services 156 8.8.1 MAP-INSERT-SUBSCRIBER-DATA service 156 8.8.1.1 Definition 156 8.8.1.2 Service primitives 157 8.8.1.3 Parameter use 158 8.8.1.4 Basic service information related to supplementary services 172 8.8.2 MAP-DELETE-SUBSCRIBER-DATA service 172 8.8.2.1 Definition 172 8.8.2.2 Service primitives 172 8.8.2.3 Parameter use 173 8.9 Identity management services 178 8.9.1 MAP-PROVIDE-IMSI service 178 8.9.1.1 Definition 178 8.9.1.2 Service primitives 178 8.9.1.3 Parameter use 178 8.9.2 MAP-FORWARD-NEW-TMSI service 178 8.9.2.1 Definition 178 8.9.2.2 Service primitives 179 8.9.2.3 Parameter use 179 8.10 Fault recovery services 179 8.10.1 MAP_RESET service 179 8.10.1.1 Definition 179 8.10.1.2 Service primitives 179 8.10.1.3 Parameter definition and use 179 8.10.2 MAP_FORWARD_CHECK_SS_INDICATION service 180 8.10.2.1 Definition 180 8.10.2.2 Service primitives 180 8.10.2.3 Parameter definition and use 180 8.10.3 MAP_RESTORE_DATA service 181 8.10.3.1 Definition 181 8.10.3.2 Service primitives 181 8.10.3.3 Parameter definitions and use 181 8.11 Subscriber Information services 183 8.11.1 MAP-ANY-TIME-INTERROGATION service 183 8.11.1.1 Definition 183 8.11.1.2 Service primitives 183 8.11.1.3 Parameter definition and use 184 8.11.2 MAP-PROVIDE-SUBSCRIBER-INFO service 185 8.11.2.1 Definition 185 8.11.2.2 Service primitives 185 8.11.2.3 Parameter definition and use 185 8.11.3 MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION service 186 8.11.3.1 Definition 186 8.11.3.2 Service primitives 186 8.11.3.3 Parameter definition and use 187 8.11.4 MAP-ANY-TIME-MODIFICATION service 188 8.11.4.1 Definition 188 8.11.4.2 Service primitives 188 8.11.4.3 Parameter definition and use 188 8.11.5 MAP-NOTE-SUBSCRIBER-DATA-MODIFIED service 189 8.11.5.1 Definition 189 8.11.5.2 Service primitives 189 8.11.5.3 Parameter definition and use 190 9 Operation and maintenance services 191 9.1 Subscriber tracing services 191 9.1.1 MAP-ACTIVATE-TRACE-MODE service 191 9.1.1.1 Definition 191 9.1.1.2 Service primitives 192 9.1.1.3 Parameter use 192 9.1.2 MAP-DEACTIVATE-TRACE-MODE service 193 9.1.2.1 Definition 193 9.1.2.2 Service primitives 193 9.1.2.3 Parameter use 193 9.1.3 MAP-TRACE-SUBSCRIBER-ACTIVITY service 194 9.1.3.1 Definition 194 9.1.3.2 Service primitives 194 9.1.3.3 Parameter use 194 9.2 Other operation and maintenance services 195 9.2.1 MAP-SEND-IMSI service 195 9.2.1.1 Definition 195 9.2.1.2 Service primitives 195 9.2.1.3 Parameter use 195 10 Call handling services 195 10.1 MAP_SEND_ROUTING_INFORMATION service 195 10.1.1 Definition 195 10.1.2 Service primitives 195 10.1.3 Parameter use 196 10.2 MAP_PROVIDE_ROAMING_NUMBER service 202 10.2.1 Definition 202 10.2.2 Service primitives 202 10.2.3 Parameter use 203 10.3 MAP_RESUME_CALL_HANDLING service 205 10.3.1 Definition 205 10.3.2 Service primitives 205 10.3.3 Parameter use 206 10.4 MAP_PREPARE_GROUP_CALL service 207 10.4.1 Definition 207 10.4.2 Service primitives 207 10.4.3 Parameter definitions and use 208 10.5 MAP_PROCESS_GROUP CALL_SIGNALLING service 209 10.5.1 Definitions 209 10.5.2 Service primitives 209 10.5.3 Parameter definitions and use 209 10.6 MAP_FORWARD_GROUP_CALL_SIGNALLING service 210 10.6.1 Definitions 210 10.6.2 Service primitives 210 10.6.3 Parameter definitions and use 210 10.7 MAP_SEND_GROUP_CALL_END_SIGNAL service 211 10.7.1 Definitions 211 10.7.2 Service primitives 212 10.7.3 Parameter definitions and use 212 10.7A MAP_SEND_GROUP_CALL_INFO service 212 10.7A.1 Definitions 212 10.7A.2 Service primitives 212 10.7A.3 Parameter definitions and use 213 10.8 Void 214 10.9 Void 214 10.10 MAP_SET_REPORTING_STATE service 214 10.10.1 Definition 214 10.10.2 Service primitives 214 10.10.3 Parameter use 214 10.11 MAP_STATUS_REPORT service 215 10.11.1 Definition 215 10.11.2 Service primitives 215 10.11.3 Parameter use 215 10.12 MAP_REMOTE_USER_FREE service 216 10.12.1 Definition 216 10.12.2 Service primitives 216 10.12.3 Parameter use 216 10.13 MAP_IST_ALERT service 217 10.13.1 Definition 217 10.13.2 Service primitives 217 10.13.3 Parameter use 217 10.14 MAP_IST_COMMAND service 218 10.14.1 Definition 218 10.14.2 Service primitives 218 10.14.3 Parameter use 218 10.15 MAP_RELEASE_RESOURCES service 219 10.15.1 Definition 219 10.15.2 Service primitives 219 10.15.3 Parameter use 219 11 Supplementary services related services 219 11.1 MAP_REGISTER_SS service 219 11.1.1 Definition 219 11.1.2 Service primitives 219 11.1.3 Parameter use 220 11.2 MAP_ERASE_SS service 221 11.2.1 Definition 221 11.2.2 Service primitives 221 11.2.3 Parameter use 221 11.3 MAP_ACTIVATE_SS service 222 11.3.1 Definition 222 11.3.2 Service primitives 222 11.3.3 Parameter use 222 11.4 MAP_DEACTIVATE_SS service 223 11.4.1 Definitions 223 11.4.2 Service primitives 224 11.4.3 Parameter use 224 11.5 MAP_INTERROGATE_SS service 225 11.5.1 Definitions 225 11.5.2 Service primitives 225 11.5.3 Parameter use 225 11.6 Void 227 11.7 MAP_REGISTER_PASSWORD service 227 11.7.1 Definitions 227 11.7.2 Service primitives 227 11.7.3 Parameter use 227 11.8 MAP_GET_PASSWORD service 228 11.8.1 Definitions 228 11.8.2 Service primitives 228 11.8.3 Parameter use 228 11.9 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service 228 11.9.1 Definitions 229 11.9.2 Service primitives 229 11.9.3 Parameter use 229 11.10 MAP_UNSTRUCTURED_SS_REQUEST service 230 11.10.1 Definitions 230 11.10.2 Service primitives 230 11.10.3 Parameter use 230 11.11 MAP_UNSTRUCTURED_SS_NOTIFY service 231 11.11.1 Definitions 231 11.11.2 Service primitives 231 11.11.3 Parameter use 231 11.12 MAP_SS_INVOCATION_NOTIFY 232 11.12.1 Definition 232 11.12.2 Service primitives 232 11.12.3 Parameter use 232 11.13 MAP_REGISTER_CC_ENTRY service 233 11.13.1 Definition 233 11.13.2 Service primitives 233 11.13.3 Parameter use 233 11.14 MAP_ERASE_CC_ENTRY service 234 11.14.1 Definition 234 11.14.2 Service primitives 234 11.14.3 Parameter use 234 12 Short message service management services 235 12.1 MAP-SEND-ROUTING-INFO-FOR-SM service 235 12.1.1 Definition 235 12.1.2 Service primitives 235 12.1.3 Parameter use 236 12.1.4 Identities of MT-SMS Target Nodes 239 12.2 MAP-MO-FORWARD-SHORT-MESSAGE service 240 12.2.1 Definition 240 12.2.2 Service primitives 240 12.2.3 Parameter use 240 12.3 MAP-REPORT-SM-DELIVERY-STATUS service 241 12.3.1 Definition 241 12.3.2 Service primitives 241 12.3.3 Parameter use 242 12.4 MAP-READY-FOR-SM service 244 12.4.1 Definition 244 12.4.2 Service primitives 244 12.4.3 Parameter use 245 12.5 MAP-ALERT-SERVICE-CENTRE service 245 12.5.1 Definition 245 12.5.2 Service primitives 246 12.5.3 Parameter use 246 12.6 MAP-INFORM-SERVICE-CENTRE service 248 12.6.1 Definition 248 12.6.2 Service primitives 249 12.6.3 Parameter use 249 12.7 MAP-SEND-INFO-FOR-MT-SMS service 249 12.7.1 Definition 249 12.7.2 Service primitives 250 12.7.3 Parameter use 250 12.8 MAP-SEND-INFO-FOR-MO-SMS service 250 12.8.1 Definition 251 12.8.2 Service primitives 251 12.8.3 Parameter use 251 12.9 MAP-MT-FORWARD-SHORT-MESSAGE service 251 12.9.1 Definition 251 12.9.2 Service primitives 251 12.9.3 Parameter use 252 12.10 MAP-MT-FORWARD-SM-FOR-VGCS service 254 12.10.1 Definition 254 12.10.2 Service primitives 254 12.10.3 Parameter use 254 13 Network-Requested PDP Context Activation services 255 13.1 MAP_SEND_ROUTING_INFO_FOR_GPRS service 255 13.1.1 Definition 255 13.1.2 Service primitives 255 13.1.3 Parameter definition and use 255 13.2 MAP_FAILURE_REPORT service 256 13.2.1 Definition 256 13.2.2 Service primitives 256 13.2.3 Parameter definition and use 256 13.3 MAP_NOTE_MS_PRESENT_FOR_GPRS service 257 13.3.1 Definition 257 13.3.2 Service primitives 257 13.3.3 Parameter definition and use 257 13A Location Service Management Services 258 13A.1 MAP-SEND-ROUTING-INFO-FOR-LCS Service 258 13A.1.1 Definition 258 13A.1.2 Service Primitives 258 13A.1.3 Parameter Use 259 13A.2 MAP-PROVIDE-SUBSCRIBER-LOCATION Service 260 13A.2.1 Definition 260 13A.2.2 Service Primitives 260 13A.2.3 Parameter Definition and Use 261 13A.3 MAP-SUBSCRIBER-LOCATION-REPORT Service 264 13A.3.1 Definition 264 13A.3.2 Service Primitives 264 13A.3.3 Parameter Definition and Use 265 13A.4 Void 268 13A.4.1 Void 268 13A.4.2 Void 268 13A.4.3 Void 268 13A.5 Void 268 13A.5.1 Void 268 13A.5.2 Void 268 13A.5.3 Void 268 13A.6 Void 268 13A.6.1 Void 269 13A.6.2 Void 269 13A.6.3 Void 269 13A.7 Void 269 13A.7.1 Void 269 13A.7.2 Void 269 13A.7.3 Void 269 13A.8 Void 269 13A.8.1 Void 269 13A.8.2 Void 269 13A.8.3 Void 269 13A.9 Void 269 13A.9.1 Void 269 13A.9.2 Void 269 13A.9.3 Void 269 14 General 269 14.1 Overview 269 14.2 Underlying services 269 14.3 Model 270 14.4 Conventions 270 15 Elements of procedure 270 15.1 Handling of unknown operations 270 15.2 Dialogue establishment 271 15.2.1 Behaviour at the initiating side 271 15.2.2 Behaviour at the responding side 272 15.3 Dialogue continuation 273 15.4 Load control 273 15.5 Procedures for MAP specific services 273 15.5.1 Service invocation 273 15.5.2 Void 274 15.5.3 Service invocation receipt 274 15.5.4 Void 274 15.5.5 Handling of components received from TC 274 15.6 SDL descriptions 274 16 Mapping on to TC services 307 16.1 Dialogue control 307 16.1.1 Directly mapped parameters 307 16.1.2 Use of other parameters of dialogue handling primitives 307 16.1.2.1 Dialogue Id 307 16.1.2.2 Application-context-name 307 16.1.2.3 User information 307 16.1.2.4 Component present 307 16.1.2.5 Termination 307 16.1.2.6 P-Abort-Cause 307 16.1.2.7 Quality of service 307 16.2 Service specific procedures 308 16.2.1 Directly mapped parameters 308 16.2.2 Use of other parameters of component handling primitives 308 16.2.2.1 Dialogue Id 308 16.2.2.2 Class 308 16.2.2.3 Linked Id 308 16.2.2.4 Operation 309 16.2.2.5 Error 310 16.2.2.6 Parameters 310 16.2.2.7 Time out 310 16.2.2.8 Last component 310 16.2.2.9 Problem code 310 16.2.2.9.1 Mapping to MAP User Error 310 16.2.2.9.2 Mapping to MAP Provider Error parameter 311 16.2.2.9.3 Mapping to diagnostic parameter 311 17 Abstract syntax of the MAP protocol 312 17.1 General 312 17.1.1 Encoding rules 312 17.1.2 Use of TC 312 17.1.2.1 Use of Global Operation and Error codes defined outside MAP 313 17.1.3 Use of information elements defined outside MAP 313 17.1.4 Compatibility considerations 313 17.1.5 Structure of the Abstract Syntax of MAP 314 17.1.6 Application Contexts 316 17.2 Operation packages 317 17.2.1 General aspects 317 17.2.2 Packages specifications 318 17.2.2.1 Location updating 318 17.2.2.2 Location cancellation 318 17.2.2.3 Roaming number enquiry 319 17.2.2.4 Information retrieval 319 17.2.2.5 Inter-VLR information retrieval 319 17.2.2.6 IMSI retrieval 319 17.2.2.7 Call control transfer 320 17.2.2.8 Void 320 17.2.2.9 Void 320 17.2.2.10 Interrogation 320 17.2.2.11 Void 320 17.2.2.12 Handover Control 320 17.2.2.13 Subscriber Data management stand alone 321 17.2.2.14 Equipment management 321 17.2.2.15 Subscriber data management 321 17.2.2.16 Location register restart 321 17.2.2.17 Tracing stand-alone 322 17.2.2.18 Functional SS handling 322 17.2.2.19 Tracing 322 17.2.2.20 Binding 322 17.2.2.21 Unstructured SS handling 323 17.2.2.22 MO Short message relay services 323 17.2.2.23 Short message gateway services 323 17.2.2.24 MT Short message relay services 324 17.2.2.25 Void 324 17.2.2.26 Message waiting data management 324 17.2.2.27 Alerting 324 17.2.2.28 Data restoration 324 17.2.2.29 Purging 325 17.2.2.30 Subscriber information enquiry 325 17.2.2.31 Any time information enquiry 325 17.2.2.32 Group Call Control 325 17.2.2.32A Group Call Info Retrieval 325 17.2.2.33 Void 326 17.2.2.34 Void 326 17.2.2.35 Gprs location updating 326 17.2.2.36 Gprs Interrogation 326 17.2.2.37 Failure reporting 326 17.2.2.38 GPRS notifying 326 17.2.2.39 Supplementary Service invocation notification 327 17.2.2.40 Set Reporting State 327 17.2.2.41 Status Report 327 17.2.2.42 Remote User Free 327 17.2.2.43 Call Completion 327 17.2.2.44 Location service gateway services 327 17.2.2.45 Location service enquiry 328 17.2.2.45A Location service reporting 328 17.2.2.46 Void 328 17.2.2.47 Void 328 17.2.2.48 Void 328 17.2.2.49 IST Alerting 328 17.2.2.50 Service Termination 328 17.2.2.51 Mobility Management event notification 329 17.2.2.53 Subscriber Data modification notification 329 17.2.2.54 Authentication Failure Report 329 17.2.2.55 Resource Management 329 17.2.2.56 MT Short message relay VGCS services 330 17.2.2.57 Vcsg location updating 330 17.2.2.58 Vcsg location cancellation 330 17.3 Application contexts 330 17.3.1 General aspects 330 17.3.2 Application context definitions 331 17.3.2.1 Void 331 17.3.2.2 Location Updating 331 17.3.2.3 Location Cancellation 331 17.3.2.4 Roaming number enquiry 332 17.3.2.5 Void 332 17.3.2.6 Location Information Retrieval 332 17.3.2.7 Call control transfer 332 17.3.2.8 Void 333 17.3.2.9 Void 333 17.3.2.10 Void 333 17.3.2.11 Location registers restart 333 17.3.2.12 Handover control 333 17.3.2.13 IMSI Retrieval 333 17.3.2.14 Equipment Management 334 17.3.2.15 Information retrieval 334 17.3.2.16 Inter-VLR information retrieval 334 17.3.2.17 Stand Alone Subscriber Data Management 335 17.3.2.18 Tracing 335 17.3.2.19 Network functional SS handling 335 17.3.2.20 Network unstructured SS handling 336 17.3.2.21 Short Message Gateway 336 17.3.2.22 Mobile originating Short Message Relay 336 17.3.2.23 Void 337 17.3.2.24 Short message alert 337 17.3.2.25 Short message waiting data management 337 17.3.2.26 Mobile terminating Short Message Relay 337 17.3.2.27 MS purging 338 17.3.2.28 Subscriber information enquiry 338 17.3.2.29 Any time information enquiry 338 17.3.2.30 Group Call Control 338 17.3.2.30A Group Call Info Retrieval 338 17.3.2.31 Void 339 17.3.2.32 Gprs Location Updating 339 17.3.2.33 Gprs Location Information Retreival 339 17.3.2.34 Failure Reporting 339 17.3.2.35 GPRS Notifying 339 17.3.2.36 Supplementary Service invocation notification 340 17.3.2.37 Reporting 340 17.3.2.38 Call Completion 340 17.3.2.39 Location Service Gateway 341 17.3.2.40 Location Service Enquiry 341 17.3.2.41 Void 341 17.3.2.42 Void 341 17.3.2.43 Void 341 17.3.2.44 IST Alerting 341 17.3.2.45 Service Termination 341 17.3.2.46 Mobility Management event notification 342 17.3.2.48 Subscriber Data modification notification 342 17.3.2.49 Authentication Failure Report 342 17.3.2.50 Resource Management 342 17.3.2.51 Mobile terminating Short Message Relay VGCS 343 17.3.2.52 Vcsg Location Updating 343 17.3.2.53 Vcsg Location Cancellation 343 17.3.3 ASN.1 Module for application-context-names 343 17.4 MAP Dialogue Information 346 17.5 MAP operation and error codes 348 17.6 MAP operations and errors 350 17.6.1 Mobile Service Operations 350 17.6.2 Operation and Maintenance Operations 357 17.6.3 Call Handling Operations 358 17.6.4 Supplementary service operations 361 17.6.5 Short message service operations 365 17.6.6 Errors 368 17.6.7 Group Call operations 374 17.6.8 Location service operations 376 17.6.9 Void 377 17.7 MAP constants and data types 377 17.7.1 Mobile Service data types 377 17.7.2 Operation and maintenance data types 426 17.7.3 Call handling data types 433 17.7.4 Supplementary service data types 439 17.7.5 Supplementary service codes 443 17.7.6 Short message data types 446 17.7.7 Error data types 452 17.7.8 Common data types 458 17.7.9 Teleservice Codes 467 17.7.10 Bearer Service Codes 468 17.7.11 Extension data types 470 17.7.12 Group Call data types 471 17.7.13 Location service data types 474 17.7.14 Void 484 18 General on MAP user procedures 485 18.1 Introduction 485 18.2 Common aspects of user procedure descriptions 485 18.2.1 General conventions 485 18.2.2 Naming conventions 485 18.2.3 Convention on primitives parameters 486 18.2.3.1 Open service 486 18.2.3.2 Close service 487 18.2.4 Version handling at dialogue establishment 487 18.2.4.1 Behaviour at the initiating side 487 18.2.4.2 Behaviour at the responding side 487 18.2.5 Abort Handling 487 18.2.6 SDL conventions 487 18.3 Interaction between MAP Provider and MAP Users 488 19 Mobility procedures 489 19.1 Location management Procedures 489 19.1.1 Location updating 490 19.1.1.1 General 490 19.1.1.2 Procedures in the VLR 495 19.1.1.3 Procedure in the PVLR 495 19.1.1.4 Procedure in the SGSN 495 19.1.1.5 Procedures in the HLR 496 19.1.1A Location updating for VCSG 516 19.1.1A.1 General 516 19.1.1A.2 Procedures in the VLR 516 19.1.1A.3 Procedures in the SGSN 516 19.1.1A.4 Procedures in the CSS 516 19.1.2 Location Cancellation 524 19.1.2.1 General 524 19.1.2.2 Procedure in the HLR 524 19.1.2.3 Procedure in the VLR 525 19.1.2.4 Procedure in the SGSN 525 19.1.2A Location Cancellation for VCSG 532 19.1.2A.1 General 532 19.1.2A.2 Procedure in the CSS 532 19.1.2A.3 Procedure in the VLR 532 19.1.2A.4 Procedure in the SGSN 532 19.1.3 Void 536 19.1.4 MS Purging 536 19.1.4.1 General 537 19.1.4.2 Procedure in the VLR 537 19.1.4.3 Procedure in the SGSN 537 19.1.4.4 Procedure in the HLR 538 19.2 Handover procedures 543 19.2.1 General 543 19.2.2 Procedure in MSC A 546 19.2.2.1 Basic handover 546 19.2.2.2 Handling of access signalling 547 19.2.2.3 Subsequent handover 547 19.2.3 Procedure in MSC B 547 19.2.3.1 Basic handover 548 19.2.3.2 Handling of access signalling 548 19.2.3.3 Subsequent handover 548 19.2.4 Macro Receive_Error_From_HO_CA 548 19.2.5 Procedure in VLR B 548 19.3 Fault recovery procedures 567 19.3.1 VLR fault recovery procedures 567 19.3.1.1 General 567 19.3.1.2 Procedure in the VLR 568 19.3.1.3 Procedure in the HLR 568 19.3.2 HLR fault recovery procedures 570 19.3.2.1 General 570 19.3.2.2 Procedure in the HLR 571 19.3.2.3 Procedure in the VLR 572 19.3.2.4 Procedure in the SGSN 572 19.3.3 CSS fault recovery procedures 578 19.3.3.1 General 578 19.3.3.2 Procedure in the CSS 579 19.3.3.3 Procedure in the VLR 579 19.3.3.4 Procedure in the SGSN 579 19.4 Mobility Management event notification procedure 584 19.4.1 General 584 19.4.2 Procedure in the VLR or SGSN 585 19.4.3 Procedure in the gsmSCF 585 19.5 HLR Insert Subscriber Data macros 588 19.5.1 Macro Insert_Subs_Data_Framed_HLR 588 19.5.2 Macro Insert_GPRS_Subs_Data_Framed_HLR 588 19.5A CSS Insert Subscriber Data macros 591 19.5A.1 Macro Insert_VCSG_Subs_Data_Framed_CSS 591 20 Operation and maintenance procedures 593 20.1 General 593 20.1.1 Tracing Co-ordinator for the VLR 593 20.1.2 Tracing Co-ordinator for the SGSN 593 20.1.3 Subscriber Data Management Co-ordinator for the VLR 593 20.1.4 Subscriber Data Management Co-ordinator for the SGSN 593 20.2 Tracing procedures 600 20.2.1 Subscriber tracing activation procedure 603 20.2.1.1 Procedures in the HLR 603 20.2.1.2 Procedure in the VLR 603 20.2.1.3 Procedure in the SGSN 603 20.2.2 Subscriber tracing deactivation procedure 603 20.2.2.1 Procedures in the HLR 603 20.2.2.2 Procedure in the VLR 604 20.2.2.3 Procedure in the SGSN 604 20.3 Subscriber data management procedures for HLR 617 20.3.1 Subscriber deletion procedure 618 20.3.1.1 Procedure in the HLR 618 20.3.1.2 Procedure in the VLR 618 20.3.1.3 Procedure in the SGSN 619 20.3.2 Subscriber data modification procedure 619 20.3.2.1 Procedure in the HLR 619 20.3.2.2 Procedures in the VLR 620 20.3.2.3 Procedures in the SGSN 620 20.3A Subscriber Data Management procedures for CSS 632 20.3A.1 Subscriber deletion procedure 633 20.3A.1.1 Procedure in the CSS 633 20.3A.1.2 Procedure in the VLR 633 20.3A.1.3 Procedure in the SGSN 633 20.3A.2 Subscriber data modification procedure 634 20.3A.2.1 Procedure in the CSS 634 20.3A.2.2 Procedures in the VLR 634 20.3A.2.3 Procedures in the SGSN 634 20.4 Subscriber Identity procedure 646 20.4.1 Procedure in the VLR 646 20.4.2 Procedure in the HLR 646 21 Call handling procedures 649 21.1 General 649 21.2 Retrieval of routing information 649 21.2.1 General 649 21.2.2 Procedure in the GMSC 653 21.2.9 Process in the gsmSCF 653 21.2.4 Procedure in the HLR 653 21.2.5 Procedure in the VLR to provide a roaming number 654 21.2.6 Procedure in the VLR to restore subscriber data 654 21.2.7 Procedure in the VLR to provide subscriber information 654 21.2.8 Procedure in the old VLR to request a Roaming Number (MTRF) 654 21.3 Transfer of call handling 664 21.3.1 General 664 21.3.2 Process in the VMSC 664 21.3.3 Process in the GMSC 665 21.4 Inter MSC Group Call Procedures 668 21.4.1 General 668 21.4.2 Process in the Anchor MSC 668 21.4.3 Process in the Relay MSC 669 21.4A Inter MSC Group Call Info Retrieval 674 21.4A.1 General 674 21.4A.2 Process in the MSC 674 21.5 Void 677 21.6 CCBS: monitoring and reporting the status of the subscriber 677 21.6.1 Reporting co-ordinator process in the VLR 677 21.6.2 Setting the reporting state Ð stand-alone 677 21.6.2.1 Process in the HLR 677 21.6.2.2 Process in the VLR 677 21.6.3 Status Reporting 677 21.6.3.1 Process in the VLR 678 21.6.3.2 Process in the HLR 679 21.6.4 CCBS: Remote User Free 679 21.6.4.1 Process in the HLR 680 21.6.3.2 Process in the VLR 680 21.7 Void 693 21.8 Void 693 21.9 Immediate Service Termination (IST) 693 21.9.1 IST Alert 693 21.9.1.1 Procedure in the MSC 693 21.9.1.2 Procedure in the HLR 693 21.9.2 IST Command 693 21.9.2.1 Procedure in the HLR 694 21.9.2.2 Procedure in the MSC 694 21.10 Resource Management 699 21.10.1 General 699 21.3.2 Process in the GMSC 699 21.3.3 Process in the VMSC 699 22 Supplementary services procedures 702 22.1 Supplementary service co-ordinator processes 702 22.1.1 Supplementary service co-ordinator process for the MSC 702 22.1.2 Void 702 22.1.3 Functional supplementary service co-ordinator process for the HLR 702 22.1.4 Call completion supplementary service co-ordinator process for the HLR 702 22.2 Registration procedure 707 22.2.1 General 707 22.2.2 Procedure in the MSC 708 22.2.3 Procedure in the VLR 708 22.2.4 Procedure in the HLR 708 22.3 Erasure procedure 714 22.3.1 General 714 22.3.2 Procedure in the MSC 715 22.3.3 Procedure in the VLR 715 22.3.4 Procedure in the HLR 715 22.4 Activation procedure 715 22.4.1 General 715 22.4.2 Procedure in the MSC 716 22.4.3 Procedure in the VLR 717 22.4.4 Procedure in the HLR 717 22.5 Deactivation procedure 723 22.5.1 General 723 22.5.2 Procedure in the MSC 724 22.5.3 Procedures in the VLR 724 22.5.4 Procedures in the HLR 724 22.6 Interrogation procedure 724 22.6.1 General 724 22.6.2 Procedure in the MSC 725 22.6.3 Procedures in the VLR 725 22.6.4 Procedure in the HLR 726 22.7 Void 730 22.8 Password registration procedure 731 22.8.1 General 731 22.8.2 Procedure in the MSC 733 22.8.3 Procedure in the VLR 733 22.8.4 Procedure in the HLR 733 22.9 Mobile Initiated USSD procedure 736 22.9.1 General 736 22.9.2 Procedure in the MSC 736 22.9.3 Procedure in the VLR 736 22.9.4 Procedure in the HLR 737 22.9.5 Procedures in the gsmSCF/secondary HLR 737 22.10 Network initiated USSD procedure 751 22.10.1 General 751 22.10.2 Procedure in the MSC 751 22.10.3 Procedure in the VLR 751 22.10.4 Procedure in the HLR 752 22.10.5 Procedure in the gsmSCF or secondary HLR 752 22.11 Common macros for clauseÊ22 772 22.11.1 SS Password handling macros 772 22.11.2 Void 772 22.12 Supplementary Service Invocation Notification procedure 776 22.12.1 General 776 22.12.2 Procedure in the MSC 776 22.12.3 Procedure in the gsmSCF 776 22.13 Activation of a CCBS request 779 22.13.1 General 779 22.13.2 Procedure in the VLR 779 22.13.3 Procedure in the HLR 779 22.14 Deactivation of a CCBS"
"request 782 22.14.1 General 782 22.14.2 Procedure in the VLR 782 22.14.3 Procedure in the HLR 782 23 Short message service procedures 785 23.1 General 785 23.1.1 Mobile originated short message service Co-ordinator for the MSC 785 23.1.2 Short message Gateway Co-ordinator for the HLR 785 23.2 The mobile originated short message transfer procedure 790 23.2.1 Procedure in the serving MSC 791 23.2.2 Procedure in the VLR 791 23.2.3 Procedure in the SGSN 791 23.2.4 Procedure in the SMS Interworking MSC (SMS-IWMSC) 792 23.3 The mobile terminated short message transfer procedure 804 23.3.1 Procedure in the SMS-GMSC 811 23.3.2 Procedure in the HLR 813 23.3.3 Procedure in the Serving MSC 813 23.3.4 Procedure in the VLR 814 23.3.5 Procedure in the SGSN 814 23.3.6 Procedure in the SMS Router 815 23.3.7 Procedure in the IP-SM-GW 816 23.4 The Short Message Alert procedure 862 23.4.1 Procedure in the Serving MSC Ð the MS has memory available 864 23.4.2 Procedures in the VLR 864 23.4.2.1 The Mobile Subscriber is present 864 23.4.2.2 The MS has memory available 864 23.4.3 Procedures in the SGSN 865 23.4.3.1 The Mobile Subscriber is present 865 23.4.3.2 The Mobile Equipment has memory available 865 23.4.4 Procedure in the HLR 865 23.4.5 Procedure in the SMS Interworking MSC 865 23.5 The SM delivery status report procedure 874 23.5.1 Procedure in the SMS-GMSC 874 23.5.2 Procedure in the HLR 874 23.5.3 Procedure in the IP-SM-GW 875 23.6 The macro Report_SM_Delivery_Stat_HLR 880 23.7 The mobile terminated short message transfer procedure for VGCS 883 23.7.1 Procedure in the SMS-GMSC 884 23.7.2 Procedure in the Anchor MSC 884 24 GPRS process description 888 24.1 Procedure for retrieval of routeing information for GPRS 889 24.1.1 Process in the GGSN 889 24.1.2 Process in the HLR 889 24.2 Procedure for reporting failure to establish a network requested PDP context 892 24.2.1 Process in the GGSN 892 24.2.2 Process in the HLR 892 24.3 Procedure for reporting that an MS has become reachable for GPRS 895 24.3.1 Process in the HLR 895 24.3.2 Process in the GGSN for Note Ms Present For Gprs 895 24A CSE interrogation and control of subscriber data 898 24A.1 General 898 24A.2 Any Time Subscription Interrogation procedure 900 24A.2.1 General 900 24A.2.2 Process in the gsmSCF 900 24A.2.3 Process in the HLR 900 24A.3 Any Time Modification procedure 903 24A.3.1 General 903 24A.3.2 Process in the gsmSCF 903 24A.3.3 Process in the HLR 903 24A.4 Subscriber Data Modification Notification procedure 906 24A.4.1 General 906 24A.4.2 Process in the HLR 906 24A.4.3 Process in the gsmSCF 906 24A.5 Any Time Interrogation procedure 911 24A.5.1 General 911 24A.5.2 Procedures in the gsmSCF 912 24A.5.3 Procedure in the HLR 912 24A.5.4 Procedure in the GMLC 912 24B Location Services process description 918 24B.1 Routeing information retrieval procedure for LCS 918 24B.1.1 General 918 24B.1.2 Process in the GMLC 918 24B.1.3 Process in the HLR 918 24B.2 Provide Subscriber Location procedure 921 24B.2.1 General 921 24B.2.2 Process in the GMLC 921 24B.2.3 Process in the MSC 921 24B.2.4 Process in the SGSN 921 24B.3 Subscriber Location Report procedure 925 24B.3.1 General 925 24B.3.2 Process in the MSC 925 24B.3.3 Process in the SGSN 925 24B.3.4 Process in the GMLC 925 25 General macro description 929 25.1 MAP_OPEN handling macros 929 25.1.1 Macro Receive_Open_Ind 929 25.1.2 Macro Receive_Open_Cnf 929 25.2 Macros to check the content of indication and confirmation primitives 934 25.2.1 Macro Check_Indication 934 25.2.2 Macro Check_Confirmation 934 25.3 The page and search macros 937 25.3.1 Macro PAGE_MSC 937 25.3.2 Macro Search_For_MS_MSC 937 25.4 Macros for handling an Access Request 940 25.4.1 Macro Process_Access_Request_MSC 940 25.4.2 Macro Process_Access_Request_VLR 940 25.4.3 Macro Obtain_Identity_VLR 940 25.4.4 Process Update_Location_Child_VLR 940 25.5 Authentication macros and processes 950 25.5.1 Macro Authenticate_MSC 950 25.5.2 Macro Authenticate_VLR 950 25.5.3 Macro Obtain_Authent_Params_VLR 950 25.5.4 Process Obtain_Authentication_Sets_VLR 950 25.5.5 Process Obtain_Authent_Sets_SGSN 950 25.5.6 Process Obtain_Authent_Sets_HLR 950 25.5.7 Authentication Failure Reporting 951 25.5.7.1 General 951 25.5.7.2 Process in the VLR 951 25.5.7.3 Process in the SGSN 951 25.5.7.4 Process in the HLR 951 25.6 IMEI Handling Macros 967 25.6.1 Macro Check_IMEI_MSC 967 25.6.2 Macro Check_IMEI_VLR 967 25.6.3 Process Check_IMEI_SGSN 967 25.6.4 Process Check_IMEI_EIR 967 25.6.5 Macro Obtain_IMEI_MSC 967 25.6.6 Macro Obtain_IMEI_VLR 967 25.7 Insert Subscriber Data macros and processes 976 25.7.1 Macro Insert_Subs_Data_VLR 976 25.7.2 Macro Insert_Subs_Data_SGSN 976 25.7.3 Process Insert_Subs_Data_Stand_Alone_HLR 976 25.7.4 Process Insert_GPRS_Subs_Data_Stand_Alone_HLR 976 25.7.5 Macro Wait_for_Insert_Subs_Data_Cnf 977 25.7.6 Macro Wait_for_Insert_GPRS_Subs_Data_Cnf 977 25.7.7 Process Send_Insert_Subs_Data_HLR 977 25.7.8 Process Insert_VCSG_Subs_Data_Stand_Alone_CSS 977 25.7.9 Macro Wait_for_Insert_VCSG_Subs_Data_Cnf 977 25.7.10 Process Send_Insert_VCSG_Subs_Data_CSS 977 25.8 Request IMSI Macros 991 25.8.1 Macro Obtain_IMSI_MSC 991 25.8.2 Macro Obtain_IMSI_VLR 991 25.9 Tracing macros 994 25.9.1 Macro Trace_Subscriber_Activity_MSC 994 25.9.2 Macro Trace_Subscriber_Activity_VLR 994 25.9.3 Macro Trace_Subscriber_Activity_SGSN 994 25.9.4 Macro Activate_Tracing_VLR 994 25.9.5 Macro Activate_Tracing_SGSN 994 25.9.6 Macro Control_Tracing_With_VLR_HLR 994 25.9.7 Macro Control_Tracing_With_SGSN_HLR 994 25.10 Short Message Alert procedures 1002 25.10.1 Process Subscriber_Present_VLR 1002 25.10.2 Process SubscriberPresent_SGSN 1002 25.10.3 Macro Alert_Service_Centre_HLR 1002 25.10.4 Process Alert_SC_HLR 1002 Annex A (informative): ASN.1 Cross-reference listing and fully expanded sources 1006 Annex B (informative): Void 1007 Annex C (informative): Message Segmentation Mechanisms 1008 C.1 SCCP segmentation 1008 C.2 TCAP segmentation 1008 C.2.1 Empty Begin 1008 C.2.2 Empty Continue 1008 C.2.3 TC-Result-NL 1008 C.3 MAP Segmentation 1009 C.3.1 Invoke without explicit indication 1009 C.3.2 Invoke with explicit indication 1009 C.3.3 Result 1009 Annex D (informative): Void 1014 Annex E (informative): Change History 1015 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope It is necessary to transfer between entities of a Public Land Mobile Network (PLMN) information specific to the PLMN in order to deal with the specific behaviour of roaming Mobile Stations (MS)s. The Signalling System No. 7 specified by CCITT is used to transfer this information. The present document describes the requirements for the signalling system and the procedures needed at the application level in order to fulfil these signalling needs. Clauses 1 to 6 are related to general aspects such as terminology, mobile network configuration and other protocols required by MAP. MAP consists of a set of MAP services that are provided to MAP service-users by a MAP service-provider. FigureÊ1.1/1: Modelling principles Clauses 7 to 13A of the present document describe the MAP services. Clauses 14 to 17 define the MAP protocol specification and the behaviour of service provider (protocol elements to be used to provide MAP services, mapping on to TC service primitives, abstract syntaxes, etc.). Clauses 18 to 25 describe the MAP user procedures that make use of MAP services. The present document specifies functions, procedures and information which apply to GERAN Iu mode. However, functionality related to GERAN Iu mode is neither maintained nor enhanced. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPP TRÊ21.905: ""Vocabulary for 3GPP Specifications"". [2] 3GPP TS 22.001: ""Digital cellular telecommunications system (PhaseÊ2+); Principles of telecommunication services supported by a Public Land Mobile Network (PLMN)"". [3] 3GPP TSÊ22.002: ""Bearer Services Supported by a Public Land Mobile Network (PLMN)"". [4] 3GPP TS 22.003: ""Circuit Teleservices Supported by a Public Land Mobile Network (PLMN)"". [5] 3GPP TSÊ22.004: ""General on Supplementary Services"". [6] 3GPP TS 42.009: ""Digital cellular telecommunications system (PhaseÊ2+); Security aspects"". [7] 3GPP TSÊ22.016: ""International Mobile station Equipment Identities (IMEI)"". [8] 3GPP TSÊ22.041: ""Operator Determined Barring"". [9] 3GPP TSÊ22.081: ""Line identification supplementary services - StageÊ1"". [10] 3GPP TSÊ22.082: ""Call Forwarding (CF) supplementary services - StageÊ1"". [11] 3GPP TSÊ22.083: ""Call Waiting (CW) and Call Hold (HOLD) Supplementary Services - StageÊ1"". [12] 3GPP TSÊ22.084: ""Multi Party (MPTY) Supplementary Services - StageÊ1"". [13] 3GPP TSÊ22.085: ""Closed User Group (CUG) supplementary services - StageÊ1"". [14] 3GPP TSÊ22.086: ""Advice of charge (AoC) Supplementary Services - StageÊ1"". [15] 3GPP TSÊ22.088: ""Call Barring (CB) supplementary services - StageÊ1"". [16] 3GPP TSÊ22.090: ""Unstructured Supplementary Service Data (USSD); - StageÊ1"". [17] 3GPP TSÊ23.003: ""Numbering, addressing and identification"". [18] Void [19] 3GPP TSÊ23.007: ""Restoration procedures"". [20] 3GPP TSÊ23.008: ""Organisation of subscriber data"". [21] 3GPP TSÊ23.009: ""Handover procedures"". [22] 3GPP TSÊ23.011: ""Technical realization of Supplementary Services - General Aspects"". [23] 3GPP TSÊ23.012: ""Location management procedures"". [24] 3GPP TS 43.020: ""Security related network functions"". [25] 3GPP TSÊ23.038: ""Alphabets and language"". [25a] 3GPP TSÊ23.039: ""Interface protocols for the connection of Short Message Service Centres (SMSCs) to Short Message Entities (SMEs)"". [26] 3GPP TSÊ23.040: ""Technical realization of the Short Message Service (SMS) Point to Point (PP)"". [26a] 3GPP TSÊ23.271: ""Functional stage2 description of LCS"". [27] 3GPP TSÊ23.081: ""Line Identification Supplementary Services - StageÊ2"". [28] 3GPP TSÊ23.082: ""Call Forwarding (CF) Supplementary Services - StageÊ2"". [29] 3GPP TSÊ23.083: ""Call WaitingÊ(CW) and Call Hold (HOLD) Supplementary Services - StageÊ2"". [30] 3GPP TSÊ23.084: ""Multi Party (MPTY) Supplementary Services - StageÊ2"". [31] 3GPP TSÊ23.085: ""Closed User Group (CUG) Supplementary Services - StageÊ2"". [32] 3GPP TSÊ23.086: ""Advice of Charge (AoC) Supplementary Services - StageÊ2"". [33] 3GPP TSÊ23.088: ""Call Barring (CB) Supplementary Services - StageÊ2"". [34] 3GPP TSÊ23.090: ""Unstructured Supplementary Services Data (USSD) - StageÊ2"". [34a] 3GPP TS 33.204: ""3G Security; Network domain security; TCAP user security"". [35] 3GPP TSÊ24.008: ""Mobile Radio Interface Layer 3 specification; Core Network Protocols - Stage 3"". [36] 3GPP TSÊ24.010: ""Mobile radio interface layer 3 Supplementary Services specification - General aspects"". [37] 3GPP TSÊ24.011: ""Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface"". [37a] 3GPP TS 44.071: ""Location Services (LCS) Ð stage 3"". [38] 3GPP TSÊ24.080: ""Mobile radio interface layer 3 supplementary services specification - Formats and coding"". [39] 3GPP TSÊ24.081: ""Line identification supplementary services - StageÊ3"". [40] 3GPP TSÊ24.082: ""Call Forwarding (CF) Supplementary Services - StageÊ3"". [41] 3GPP TSÊ24.083: ""Call Waiting (CW) and Call Hold (HOLD) supplementary services - StageÊ3"". [42] 3GPP TSÊ24.084: ""Multi Party (MPTY) Supplementary Services - StageÊ3"". [43] 3GPP TSÊ24.085: ""Closed User Group (CUG) Supplementary Services - StageÊ3"". [44] 3GPP TSÊ24.086: ""Advice of Charge (AoC) Supplementary Services - StageÊ3"". [45] 3GPP TSÊ24.088: ""Call Barring (CB) Supplementary Services - StageÊ3"". [46] 3GPP TSÊ24.090: ""Unstructured Supplementary Services Data - StageÊ3"". [47] 3GPP TS 48.002: "" Base Station System - Mobile-services Switching Centre (BSS - MSC) interface principles"". [48] 3GPP TS 48.006: ""Signalling transport mechanism specification for the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface"". [49] 3GPP TS 48.008: ""Mobile Switching Centre - Base Station System (MSC - BSS) interface; Layer 3 specification"". [49a1] 3GPP TS 48.031: ""Location Services (LCS); Serving Mobile Location Centre (SMLC) Ð Serving Mobile Location Centre (SMLC); SMLC Peer Protocol (SMLCPP)"". [49b] 3GPP TS 48.071: ""Location Services (LCS); Serving Mobile Location Centre - Base Station System (SMLC - BSS) interface Layer 3 specification"". [50] 3GPP TS 49.001: ""General network interworking scenarios"". [51] 3GPP TSÊ29.002: ""Mobile Application Part (MAP) specification"". [52] Void [53] Void [54] Void [55] 3GPP TSÊ29.006: ""Interworking between a Public Land Mobile Network (PLMN) and a Packet Switched Public Data Network/Integrated Services Digital Network (PSPDN/ISDN) for the support of Packet Switched data transmission services"". [56] 3GPP TSÊ29.007: ""General requirements on interworking between the Public Land Mobile Network (PLMN) and the Integrated Services Digital Network (ISDN) or Public Switched Telephone NetworkÊ(PSTN)"". [57] 3GPP TS 29.008: ""Application of the Base Station System Application Part (BSSAP) on the E-interface"". [58] 3GPP TSÊ29.010: ""Information element mapping between Mobile Station - Base Station System and BSS Mobile-services Switching Centre (MS - BSS - MSC) Signalling procedures and the Mobile Application Part (MAP)"". [59] 3GPP TSÊ29.011: ""Signalling interworking for Supplementary Services"". [59a] 3GPP TS 49.031: ""Digital cellular telecommunications system (PhaseÊ2+); Location Services (LCS); Base Station System Application Part LCS Extension (BSSAP-LE)"". [60] Void [61] 3GPP TSÊ52.008: ""GSM Subscriber and Equipment Trace"". [62] ETSÊ300Ê102-1Ê(1990): ""Integrated Services Digital Network (ISDN); User-network interface layer 3 specifications for basic call control"". [63] ETSÊ300Ê136Ê(1992): ""Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service description"". [64] ETSÊ300Ê138Ê(1992): ""Integrated Services Digital Network (ISDN); Closed User Group (CUG) supplementary service Digital Subscriber Signalling System No.one (DSS1) protocol"". [65] ETSÊ300Ê287: ""Integrated Services Digital Network (ISDN); Signalling System No.7; Transaction Capabilities (TC) version 2"". [66] ETRÊ060: ""Signalling Protocols and Switching (SPS); Guide-lines for using Abstract Syntax Notation One (ASN.1) in telecommunication application protocols"". [66b] ETR 091: ""ETSI object identifier tree; Common domain Mobile domain"" [67] ITU-TÊRecommendationÊE.164: ""The international public telecommunication numbering plan"". [68] ITU-TÊRecommendationÊE.212: ""The international identification plan for mobile terminals and mobile users"". [69] ITU-TÊRecommendationÊE.213: ""Telephone and ISDN numbering plan for land mobile stations in public land mobile networks (PLMN) "". [70] ITU-TÊRecommendationÊE.214: ""Structure of the land mobile global title for the signalling connection control part (SCCP) "". [71] ITU-TÊRecommendationÊQ.699: ""Interworking between ISDN access and non-ISDN access over ISDN User Part of Signalling System No.Ê7 "". [72] ITU-TÊRecommendationÊQ.711: ""Specifications of Signalling System No.7; Functional description of the Signalling Connection Control Part"". [73] ITU-TÊRecommendationÊQ.712: ""Definition and function of SCCP messages"". [74] ITU-TÊRecommendationÊQ.713: ""Specifications of Signalling System No.7; SCCP formats and codes"". [75] ITU-TÊRecommendationÊQ.714: ""Specifications of Signalling System No.7; Signalling Connection Control Part procedures"". [76] ITU-TÊRecommendationÊQ.716: ""Specifications of Signalling System No.7; Signalling connection control part (SCCP) performances"". [77] ITU-TÊRecommendationÊQ.721Ê(1988): ""Specifications of Signalling System No.7; Functional description of the Signalling System No.7 Telephone user part"". [78] ITU-TÊRecommendationÊQ.722Ê(1988): ""Specifications of Signalling System No.7; General function of Telephone messages and signals"". [79] ITU-TÊRecommendationÊQ.723Ê(1988): ""Specifications of Signalling System No.7; Formats and codes"". [80] ITU-TÊRecommendationÊQ.724Ê(1988): ""Specifications of Signalling System No.7; Signalling procedures"". [81] ITU-TÊRecommendationÊQ.725Ê(1988): ""Specifications of Signalling System No.7; Signalling performance in the telephone application"". [82] ITU-TÊRecommendationÊQ.761Ê(1988): ""Specifications of Signalling System No.7; Functional description of the ISDN user part of Signalling System No.7"". [83] ITU-TÊRecommendationÊQ.762Ê(1988): ""Specifications of Signalling System No.7; General function of messages and signals"". [84] ITU-TÊRecommendationÊQ.763Ê(1988): ""Specifications of Signalling System No.7; Formats and codes"". [85] ITU-TÊRecommendationÊQ.764Ê(1988): ""Specifications of Signalling System No.7; Signalling procedures"". [86] ITU-TÊRecommendationÊQ.767: ""Specifications of Signalling System No.7; Application of the ISDN user part of CCITT signalling System No.7 for international ISDN interconnections"". [87] ITU-TÊRecommendationÊQ.771: ""Specifications of Signalling System No.7; Functional description of transaction capabilities"". [88] ITU-TÊRecommendationÊQ.772: ""Specifications of Signalling System No.7; Transaction capabilities information element definitions"". [89] ITU-TÊRecommendationÊQ.773: ""Specifications of Signalling System No.7; Transaction capabilities formats and encoding"". [90] ITU-TÊRecommendationÊQ.774: ""Specifications of Signalling System No.7; Transaction capabilities procedures"". [91] ITU-TÊRecommendationÊQ.775: ""Specifications of Signalling System No.7; Guide-lines for using transaction capabilities"". [92] ITU-TÊRecommendationÊX.200: ""Reference Model of Open systems interconnection for CCITT Applications"". [93] ITU-TÊRecommendation ÊX.680: ""Information technology Ð Abstract Syntax Notation One (ASN.1): Specification of basic notation"". [93b] ITU-TÊRecommendationÊX.681: ""Information technology Ð Abstract Syntax Notation One (ASN.1): Information object specification"". [94] ITU-TÊRecommendationÊX.690: ""Information technology Ð ASN.1 encoding rules: Specification of Basic Encoding Rules (BER), Canonical Encoding Rules (CER) and Distinguished Encoding Rules (DER)"". [95] ITU-TÊRecommendationÊX.210: ""Open systems interconnection layer service definition conventions"". [97] 3GPP TSÊ23.018: ""Basic Call Handling"". [98] 3GPP TSÊ23.078: ""Customised Applications for Mobile network Enhanced Logic (CAMEL) PhaseÊ4Ê- Stage 2"". [99] 3GPP TSÊ23.079: ""Support of Optimal Routeing (SOR) - Stage 2"". [100] 3GPP TS 43.068: ""Voice Group Call Service (VGCS) - Stage 2"". [101] 3GPP TS 43.069: ""Voice Broadcast service (VBS) - Stage 2"". [102] ANSI T1.113: ""Signaling System No. 7 (SS7) - ISDN User Part"". [103] Void [104] 3GPP TSÊ23.060: ""General Packet Radio Service (GPRS) Service description; Stage 2"". [105] 3GPP TSÊ29.060: ""General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface"". [106] 3GPP TSÊ29.018: ""General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface layer 3 specification"". [107] 3GPP TSÊ23.093: ""Technical Realization of Completion of Calls to Busy Subscriber (CCBS); StageÊ2"". [108] 3GPP TSÊ23.066: ""Support of Mobile Number Portability (MNP); Technical Realisation Stage 2"". [109] ANSI T1.112 (1996): ""Telecommunication Ð Signalling No. 7 - Signaling Connection Control Part (SCCP)"". [110] 3GPP TS 23.116: ""Super-Charger Technical Realisation; Stage 2."". [111] Void. [112] Void [113] Void [114] Void [115] Void [116] ITU-T Recommendation Q.850 (May 1998): ""Usage of cause and location in the Digital Subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part"". [117] 3GPP TS 22.135: ""Multicall; Service description; Stage 1"". [118] 3GPP TS 23.135: ""Multicall supplementary service; Stage 2"". [119] 3GPP TS 24.135: ""Multicall supplementary service; Stage 3"". [120] 3GPP TSÊ25.413: ""UTRAN Iu interface Radio Access Network Application Part (RANAP) signalling"". [121] 3GPP TS 29.202: ""SS7 signalling transport in core network"". [122] 3GPP TS 23.032: ""Universal Geographical Area Description (GAD)"". [123] 3GPP TS 22.071: ""Location Services (LCS); Service description, Stage 1"". [124] ITU-T Recommendation X.880: ""Data networks and open system communication - Open System Interconnection - Service definitions - Remote operations: Concepts, model and notation"". [125] 3GPP TS 23.278: ""Customised Applications for Mobile Network Enhanced Logic (CAMEL) Phase 4 Ð Stage 2 IM CN Interworking (Rel-5)"". [126] 3GPP TS 23.172: ""Technical realization of Circuit Switched (CS) multimedia service; UDI/RDI fallback and service modification"". [127] 3GPP TS 26.103: ""Speech codec list for GSM and UMTS"". [128] 3GPP TS 23.141: ""Presence Service; Architecture and Functional Description"". [129] 3GPP TS 23.094: ""Follow Me (FM) Ð Stage 2"". [130] Void [131] 3GPP TS 32.421: ""Subscriber and equipment trace: Trace concepts and requirements"". [132] 3GPP TS 32.422: ""Subscriber and equipment trace; Trace control and Configuration Management"". [133] 3GPP TS 23.236: ""Intra-domain connection of Radio Access Network (RAN) nodes to multiple Core Network (CN) nodes"". [134] 3GPP TS 23.204: ""Support of Short Message Service (SMS) over generic 3GPP Internet Protocol (IP) access"". [135] 3GPP TS 23.292: ""IP Multimedia Subsystem (IMS) Centralized Services"". [136] 3GPP TS 23.067: ""enhanced Multi-Level Precedence and Pre-emption service (eMLPP) - Stage 2"". [137] 3GPP TS 24.067: ""Enhanced Multi-Level Precedence and Pre-emption service (eMLPP); Stage 3"". [138] 3GPP TS 22.011: ""Service accessibility"". [139] IETF RFC 3588: ""Diameter Base Protocol"". [140] Void [141] 3GPPÊTSÊ29.173: ""Locations Services; Diameter-based SLh interface for Control Plane LCS"". [142] Void [143] 3GPPÊTSÊ23.272: ""Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2"". [144] 3GPP TS 29.272: ""Evolved Packet System (EPS); Mobility Management Entity (MME) and Service GPRS Support Node (SGSN) related interfaces based on Diameter protocol"". [145] 3GPP TS 23.401: ""General Packet Radio Service (GPRS) enhancements for Evolved Universal Terrestrial Radio Access Network (E-UTRAN) access"". [146] 3GPP TS 29.205: ""Application of Q.1900 series to bearer independent Circuit Switched (CS) core network architecture; Stage 3"". [147] 3GPP TS 36.413: ""Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)"". [148] 3GPP TS 23.682: ""Architecture enhancements to facilitate communications with packet data networks and applications"". [149] 3GPP TS 29.274: ""3GPP Evolved Packet System (EPS); Evolved General Packet Radio Service (GPRS) Tunnelling Protocol for Control plane (GTPv2-C)"". [150] 3GPP TS 23.380: ""IMS Restoration Procedures"". [151] 3GPP TS 29.273: ""Evolved Packet System (EPS); 3GPP EPS AAA interfaces"". [152] 3GPPÊTSÊ29.118: ""Mobility Management Entity (MME) - Visitor Location Register (VLR) SGs interface specification"". [153] 3GPPÊTSÊ38.413: ""NG-RAN; NG Application Protocol (NGAP)"". [154] 3GPPÊTSÊ23.107: ""Quality of Service (QoS) concept and architecture"". 3 Abbreviations ADD Automatic Device Detection GANSS Galileo and Additional Navigation Satellite Systems All other abbreviations used in the present document are listed in 3GPP TSÊ21.905. 4 Void 5 Overload and compatibility overview 5.1 Overload control There is a requirement for an overload/congestion control for all entities of the Public Land Mobile Network and the underlying Signalling System No. 7. 5.1.1 Overload control for MSC (outside MAP) For the entity MSC the following two procedures (outside MAP) may be applied to control the processor load: - ISDN CCITT Recommendation Q.764 (Automatic Congestion Control), applicable to reduce the mobile terminating traffic; - BSSAP 3GPP TS 48.008 [49] (A-interface Flow Control), applicable to reduce the mobile originating traffic. 5.1.2 Overload control for MAP entities For all MAP entities, especially the HLR, the following overload control method is applied. If overload of a MAP entity is detected requests for certain MAP operations (see tables 5.1/1, 5.1/2, 5.1/3 and 5.1/4) may be ignored by the responder. The decision as to which MAP Operations may be ignored is made by the MAP service provider and is based upon the priority of the application context. Since most of the affected MAP operations are supervised in the originating entity by TC timers (medium) an additional delay effect is achieved for the incoming traffic. If overload levels are applicable in the Location Registers the MAP operations should be discarded taking into account the priority of their application context (see tableÊ5.1/1 for HLR, tableÊ5.1/2 for MSC/VLR, table 5.1/3 for the SGSN and table 5.1/4 for the SMLC; the lowest priority is discarded first). The ranking of priorities given in the tables 5.1/1, 5.1/2, 5.1/3 and 5.1/4 is not normative. The tables can only be seen as a proposal that might be changed due to network operator/implementation matters. TableÊ5.1/1: Priorities of Application Contexts for HLR as Responder Responder = HLR Initiating Entity Priority high Mobility Management networkLocUp VLR (updateLocation), (restoreData/v2), (sendParameters/v1) gprsLocationUpdate SGSN (updateGPRSLocation/v3), infoRetrieval VLR/SGSN (sendAuthenticationInfo/v2/v3), (sendParameters/v1) istAlerting MSC (istAlert/v3) msPurging VLR (purgeMS/v2/v3) msPurging SGSN (purgeMS/v3) Short Message Service shortMsgGateway GMSC (sendRoutingInfoforSM), (reportSM-DeliveryStatus) mwdMngt VLR/SGSN (readyForSM/v2/v3), (noteSubscriberPresent/v1) Mobile Terminating Traffic locInfoRetrieval GMSC (sendRoutingInfo) anyTimeEnquiry gsmSCF (anyTimeInterrogation/v3) reporting VLR (statusReport) Location Services locationSvcGateway GMLC (sendRoutingInfoforLCS/v3) Subscriber Controlled Inputs (Supplementary Services) networkFunctionalSs VLR (registerSS), (eraseSS), (activateSS), (deactivateSS), (interrogateSS), (registerPassword), (processUnstructuredSS-Data/v1), (beginSubscriberActivity/v1) callCompletion VLR (registerCCEntry), (eraseCCEntry) networkUnstructuredSs VLR (processUnstructuredSS-Request/v2) imsiRetrieval VLR (sendIMSI/v2) gprsLocationInfoRetrieval GGSN/SGSN (sendRoutingInfoForGprs/v3/v4) failureReport GGSN/SGSN (failureReport/v3) authenticationFailureReport VLR/SGSN (authenticationFailureReport/v3) Priority low NOTE: The application context name is the last component but one of the object identifier. Operation names are given in brackets for information with ""/vn"" appended to vn only operations. TableÊ5.1/3: Priorities of Application Contexts for SGSN as Responder Responder = SGSN Initiating Entity Priority high Mobility and Location Register Management locationCancel HLR (cancelLocation v3) reset HLR (reset) subscriberDataMngt HLR (insertSubscriberData v3), (deleteSubscriberData v3) tracing HLR (activateTraceMode), (deactivateTraceMode) Short Message Service shortMsgMT-Relay MSC (MT-ForwardSM v3), (forwardSM v1/v2) Location Services locationSvcEnquiry GMLC (provideSubscriberLocation v3) Network-Requested PDP context activation gprsNotify HLR (noteMsPresentForGprs v3), (Subscriber Location & State retrieval) subscriberInfoEnquiry HLR (provideSubscriberInformation/v3) Priority low NOTE: The application context name is the last component but one of the object identifier. Operation names are given in brackets for information with ""/vn"" appended to vn. TableÊ5.1/2: Priorities of Application Contexts for MSC/VLR as Responder Responder = MSC/VLR Initiating Entity Priority high Handover handoverControl MSC (prepareHandover/v2/v3), (performHandover/v1) Group call and Broadcast call groupCallControl MSC (prepareGroupCall/v3) groupCallInfoRetrieval MSC (sendGroupCallInfo/v3) Mobility and Location Register Management locationCancel HLR (cancelLocation) reset HLR (reset) immediateTermination HLR (istCommand/v3) interVlrInfoRetrieval VLR (sendIdentification/v2/v3), (sendParameters/v1) subscriberDataMngt HLR (insertSubscriberData), (deleteSubscriberData) tracing HLR (activateTraceMode), (deactivateTraceMode) Short Message Service shortMsgMO-Relay MSC/SGSN (MO-ForwardSM v3), (forwardSM v1/v2) shortMsgMT-Relay MSC (MT-ForwardSM v3), (forwardSM v1/v2) shortMsgAlert HLR (alertServiceCentre/v2), (alertServiceCentreWithoutResult/v1) Mobile Terminating Traffic resourceMngt GMSC (releaseResources) roamingNbEnquiry HLR (provideRoamingNumber) callControlTransfer MSC (resumeCallHandling) subscriberInfoEnquiry HLR (provideSubscriberInformation/v3) reporting HLR (remoteUserFree), (SetReportingState) Location Services locationSvcEnquiry GMLC (provideSubscriberLocation/v3) Network-Initiated USSD networkUnstructuredSs HLR (unstructuredSS-Request/v2), (unstructuredSS-Notify/v2) Priority low NOTE: The application context name is the last component but one of the object identifier. Operation names are given in brackets for information with ""/vn"" appended to vn only operations. 5.1.3 Congestion control for Signalling System No. 7 The requirements of SS7 Congestion control have to be taken into account as far as possible. Means that could be applied to achieve the required traffic reductions are described in clauses 5.1.1 and 5.1.2. 5.2 Compatibility 5.2.1 General The present document of the Mobile Application Part is designed in such a way that an implementation which conforms to it can also conform to the Mobile Application Part operational version 1 specifications, except on the MSC-VLR interface. A version negotiation mechanism based on the use of an application-context-name is used to negotiate the protocol version used between two entities for supporting a MAP-user signalling procedure. When starting a signalling procedure, the MAP-user supplies an application-context-name to the MAP-provider. This name refers to the set of application layer communication capabilities required for this dialogue. This refers to the required TC facilities (e.g. version 1 or 2) and the list of operation packages (i.e. set of operations) from which operations can be invoked during the dialogue. A version one application-context-name may only be transferred to the peer user in a MAP-U-ABORT to an entity of version two or higher (i.e. to trigger a dialogue which involves only communication capabilities defined for MAP operational versionÊ1). If the proposed application-context-name can be supported by the responding entity the dialogue continues on this basis otherwise the dialogue is refused and the initiating user needs to start a new dialogue, which involves another application-context-name which requires less communication capabilities but provides similar functionality (if possible). When a signalling procedure can be supported by several application contexts that differ by their version number, the MAP-User needs to select a name. It can either select the name that corresponds to the highest version it supports or follow a more specific strategy so that the number of protocol fallbacks due to version compatibility problems is minimised. 5.2.2 Strategy for selecting the Application Context (AC) version A method should be used to minimise the number of protocol fall-backs which would occur sometimes if the highest supported AC-Name were always the one selected by GSMÊentities when initiating a dialogue. The following method is an example that can be used mainly at transitory phase stage when the network is one of mixed phase entities. 5.2.2.1 Proposed method A tableÊ(tableÊ1) may be set up by administrative action to define the highest application context (AC) version supported by each destination; a destination may be another node within the same or a different PLMN, or another PLMN considered as a single entity. The destination may be defined by an E.164 number or an E.214 number derived from an IMSI or in North America (World Zone 1) by an E.164 number or an IMSI (E.212 number). The tableÊalso includes the date when each destination is expected to be able to handle at least one AC of the latest version of the MAP protocol. When this date is reached, the application context supported by the node is marked as ""unknown"", which will trigger the use of tableÊ2. A second tableÊ(tableÊ2) contains an entry for each destination that has an entry in tableÊ1. For a given entity, the entry in tableÊ2 may be a single application context version or a vector of different versions applying to different application contexts for that entity. TableÊ2 is managed as described in clauseÊ5.2.2.2. The data for each destination will go through the following states: a) the version shown in tableÊ1 is ""version n-1"", where 'n' is the highest version existing in this specification; tableÊ2 is not used; b) the version shown in tableÊ1 is ""unknown""; tableÊ2 is used, and maintained as described in clauseÊ5.2.2.2; c) when the PLMN operator declares that an entity (single node or entire PLMN) has been upgraded to support all the MAP version n ACs defined for the relevant interface, the version shown in tableÊ1 is set to ""version n"" by administrative action; tableÊ2 is no longer used, and the storage space may be recovered. 5.2.2.2 Managing the version look-up table WHEN it receives a MAP-OPEN ind the MAP-User determines the originating entity number either using the originating address parameter or the originating reference parameter or retrieving it from the subscriber data using the IMSI or the MSISDN. IF the entity number is known: THEN It updates (if required) the associated list of highest supported ACs. ELSE It creates an entry for this entity and includes the received AC-name in the list of highest supported ACs. WHEN starting a procedure, the originating MAP-user looks up its version control table. IF the destination address is known and not timed-out. THEN It retrieves the appropriate AC-name and uses it IF the dialogue is accepted by the peer THEN It does not modify the version control table ELSE (this should never occur) It starts a new dialogue with the common highest version supported (based on information implicitly or explicitly provided by the peer). It replaces the old AC-name by the new one in the list of associated highest AC supported. ELSE It uses the AC-name that corresponds to the highest version it supports. IF the dialogue is accepted by the peer. THEN It adds the destination node in its version control tableÊand includes the AC-Name in the list of associated highest AC supported. ELSE It starts a new dialogue with the common highest version supported (based on information implicitly or explicitly provided by the peer). IF the destination node was not known THEN It adds the destination node in its version control tableÊand includes the new AC-Name in the list of associated highest AC supported. ELSE It replaces the old AC-name by the new one in the list of highest supported AC and reset the timer. 5.2.2.3 Optimising the method A table look-up may be avoided in some cases if both the HLR and the VLR or both the HLR and the SGSN store for each subscriber the version of the AC-name used at location updating. Then: - for procedures which make use of the same application-context, the same AC-name (thus the same version) can be selected (without any tableÊlook-up) when the procedure is triggered; - for procedures which make use of a different application-context but which includes one of the packages used by the location updating AC, the same version can be selected (without any tableÊlook-up) when the procedure is triggered; for HLR: - Subscriber data modification (stand alone); for VLR: - Data Restoration. 6 Requirements concerning the use of SCCP and TC 6.1 Use of SCCP The Mobile Application Part (MAP) makes use of the services offered by the Signalling Connection Control Part (SCCP). MAP supports the following SCCP versions: - Signalling Connection Control Part, Signalling System no. 7 CCITT ('Blue Book SCCP'); - Signalling Connection Control Part, Signalling System no. 7 ITU-T Recommendation (07/96) Q.711 to Q.716 ('White Book SCCP'). Support of White Book SCCP at the receiving side shall be mandated from 00:01hrs, 1st July 2002(UTC). However, for signalling over the MAP E-interface to support inter-MSC handover/relocation, the support of White Book SCCP shall be mandated with immediate effect. A White Book SCCP message will fail if any signalling point used in the transfer of the message does not support White Book SCCP. Therefore it is recommended that the originator of the White Book SCCP message supports a drop back mechanism or route capability determination mechanism to interwork with signalling points that are beyond the control of GSM/UMTS network operators. In North America (World Zone 1) the national version of SCCP is used as specified in ANSI T1.112. Interworking between a PLMN in North America and a PLMN outside North America will involve an STP to translate between ANSI SCCP and ITU-T/CCITT SCCP. The SCCP is identified as an MTP3-user and the transport of SCCP messages between two entities shall be accomplished according to the 3GPP TS 29.202 [121]. 6.1.1 SCCP Class MAP will only make use of the connectionless classes (0 or 1) of the SCCP. 6.1.2 Sub-System Number (SSN) The Application Entities (AEs) defined for MAP consist of several Application Service Elements (ASEs) and are addressed by sub-system numbers (SSNs). The SSNs for MAP are specified in 3GPP TS 23.003 [17]. When the SGSN emulates MSC behaviour for processing messages (MAP-MO-FORWARD-SHORT-MESSAGE, MAP_CHECK_IMEI, MAP_SUBSCRIBER_LOCATION_REPORT) towards entities which do not support interworking to SGSNs, it shall use the MSC SSN in the calling party address instead of the SGSN SSN. When present in the network, the Presence Network Agent emulates the behaviour of the GSM Service Control Function (gsm SCF) for processing of messages (MAP-NOTE-MM-EVENT, MAP-ANY-TIME-INTERROGATION and MAP-ANY-TIME-MODIFICATION). When a FFN (Follow Me Functional Node, see TS 23.094 [129]) is implemented in a network entity different from HLR, this network entity shall emulate HLR behaviour, i.e. it shall accept MAP-PROCESS-UNSTRUCTURED-SS-REQUEST messages addressed with SSN for HLR. In an EPS, an Interworking Function (IWF) may be used to convert Diameter S6a messages to MAP Gr messages and vice versa; also an IWF may be used to convert Diameter S13 messages to MAP Gf messages and vice versa. An SSN value for the IWF does not exist. Instead the IWF shall use the SGSN SSN value when serving an MME and use the HLR SSN when serving an HSS. An IWF is said to serve an MME (or HSS) when Diameter messages are exchanged between the IWF and the MME (or HSS). In a 5GS, a UDM may support a MAP interface towards the SMS-GMSC/SMS-Router by emulating HLR behaviour, i.e. the UDM may have an integrated/collocated HLR component serving the MAP communication to the SMS-GMSC/SMS-Router. An SSN value for UDM does not exist. Instead the UDM (with an integrated/collocated HLR) shall use the HLR SSN value. 6.1.3 SCCP addressing 6.1.3.1 Introduction Within the GSMÊSystem there will be a need to communicate between entities within the same PLMN and in different PLMNs. Using the Mobile Application Part (MAP) for this function implies the use of Transaction Capabilities (TC) and the Signalling Connection Control Part (SCCP) of CCITT Signalling System No. 7. Only the entities that should be addressed are described below. If the CCITT or ITU-T SCCP is used, the format and coding of address parameters carried by the SCCP for that purpose shall comply with CCITT Recommendation Q.713 with the following restrictions: 1) Intra-PLMN addressing For communication between entities within the same PLMN, a MAP SSN shall always be included in the called and calling party addresses. All other aspects of SCCP addressing are network specific. 2) Inter-PLMN addressing a) Called Party Address - SSN indicator = 1 (MAP SSN always included); - Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and nature of address indicator); - the translation type field will be coded ""00000000"" (Not used)."
"For call related messages for non-optimal routed calls (as described in 3GPP TS 23.066 [108]) directed to another PLMN the translation type field may be coded ""10000000"" (CRMNP); - Routing indicator = 0 (Routing on global title); b) Calling Party Address - SSN indicator = 1 (MAP SSNs always included); - Point code indicator = 0; - Global title indicator = 0100 (Global title includes translation type, numbering plan, encoding scheme and nature of address indicator); - Numbering Plan = 0001 (ISDN Numbering Plan, E.164; In Case of Inter-PLMN Signalling, the dialogue initiating entity and dialogue responding entity shall always include its own E.164 Global Title as Calling Party Address); - the translation type field will be coded ""00000000"" (Not used); - Routing indicator = 0 (Routing on Global Title). If ANSI T1.112 SCCP is used, the format and coding of address parameters carried by the SCCP for that purpose shall comply with ANSI specification T1.112 with the following restrictions: 1) Intra-PLMN addressing For communication between entities within the same PLMN, a MAP SSN shall always be included in the called and calling party addresses. All other aspects of SCCP addressing are network specific. 2) Inter-PLMN addressing a) Called Party Address - SSN indicator = 1 (MAP SSN always included); - Global title indicator = 0010 (Global title includes translation type); - the Translation Type (TT) field will be coded as follows: TT = 9, if IMSI is included; TT = 14, if MSISDN is included; Or TT = 10, if Network Element is included. (If TT=10, then Number Portability GTT is not invoked, if TT=14, then Number Portability GTT may be invoked). - Routing indicator = 0 (Routing on global title); b) Calling Party Address - SSN indicator = 1 (MAP SSNs always included); - Point code indicator = 0; - Global Title indicator = 0010 (Global title includes translation type); TT = 9, if IMSI is included; TT = 14, if MSISDN is included; Or TT = 10, if Network Element is included. (If TT=10, then Number Portability GTT is not invoked, if TT=14, then Number Portability GTT may be invoked). Routing indicator = 0 (Routing on Global Title). If a Global Title translation is required for obtaining routeing information, one of the numbering plans E.164, E.212 and E.214 is applicable. - E.212 numbering plan. When CCITT or ITU-T SCCP is used, an E.212 number must not be included as Global Title in an SCCP UNITDATA message. The translation of an E.212 number into a Mobile Global Title is applicable in a dialogue initiating VLR, SGSN or GGSN if the routeing information towards the HLR is derived from the subscriber's IMSI. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used as a Global Title to address the HLR. When an MS moves from one VLR service area to another, the new VLR may derive the address of the previous VLR from the Location Area Identification provided by the MS in the location registration request. The PLMN where the previous VLR is located is identified by the E.212 numbering plan elements of the Location Area Identification, i.e. the Mobile Country Code (MCC) and the Mobile Network Code (MNC). - E.214 and E.164 numbering plans. When CCITT or ITU-T SCCP is used, only address information belonging to either E.214 or E.164 numbering plan is allowed to be included as Global Title in the Called and Calling Party Address. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used as a Global Title to address the HLR. If the Calling Party Address associated with the dialogue initiating message contains a Global Title, the sending network entity shall include its E.164 entity number. When receiving an SCCP UNITDATA message, SCCP shall accept either of the valid numbering plans in the Called Party Address and in the Calling Party Address. When CCITT or ITU-T SCCP is used and an N-UNITDATA-REQUEST primitive from TC is received, SCCP shall accept an E.164 number or an E.214 number in the Called Address and in the Calling Address. In World Zone 1 when ANSI SCCP is used, the IMSI (E.212 number) is used instead of E.214 number. The following clauses describe the method of SCCP addressing appropriate for each entity both for the simple intra PLMN case and where an inter-PLMN communication is required. The following entities are considered: - the Mobile-services Switching Centre (MSC); - the Home location Register (HLR); - the Visitor Location Register (VLR); - the Gateway Mobile-services Switching Centre (GMSC); - the GSM Service Control Function (gsmSCF); - the Interworking Mobile-services Switching Centre (IWMSC); - the Serving GPRS Support Node (SGSN); - the Gateway GPRS Support Node (GGSN); - the Gateway Mobile Location Centre (GMLC); - the CSG Subscriber Server (CSS). 6.1.3.2 The Mobile-services Switching Centre (MSC) There are several cases where it is necessary to address the MSC. 6.1.3.2.1 MSC interaction during handover or relocation The address is derived from the target Cell id or from the target RNC id. 6.1.3.2.2 MSC for short message routing When a short message has to be routed to an MS, the GMSC addresses the VMSC by an MSC identity received from the HLR that complies with E.164 rules. For MS originating short message, the IWMSC address is derived from the Service Centre address. 6.1.3.2.3 MSC for location request routing When a location request for a particular MS needs to be sent to the MS's VMSC, the GMLC addresses the VMSC using an E.164 address received from the MS's HLR. 6.1.3.2.4 MSC for LMU Control When a control message has to be routed to an LMU from an SMLC, the SMLC addresses the serving MSC for the LMU using an E.164 address. 6.1.3.3 The Home Location Register (HLR) There are several cases where the HLR has to be addressed. 6.1.3.3.1 During call set-up When a call is initiated the HLR of the called mobile subscriber will be interrogated to discover the whereabouts of the MS. The addressing required by the SCCP will be derived from the MSISDN dialled by the calling subscriber. The dialled number will be translated into either an SPC, in the case of communications within a PLMN, or a Global Title if other networks are involved (i.e. if the communication is across a PLMN boundary). If the calling subscriber is a fixed network subscriber, the interrogation can be initiated from the Gateway MSC of the home PLMN in the general case. If the topology of the network allows it, the interrogation could be initiated from any Signalling Point that has MAP capabilities, e.g. local exchange, outgoing International Switching Centre (ISC), etc. 6.1.3.3.2 Before location updating completion When an MS registers for the first time in a VLR, the VLR has to initiate the update location dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if the authentication information must be retrieved from the HLR. When initiating either of these dialogues, the only data for addressing the HLR that the VLR has available is contained in the IMSI, and addressing information for SCCP must be derived from it. When continuing the established update location dialogue (as with any other dialogue), the VLR must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. This means that the VLR must be able to address the HLR based on: - an E.214 Mobile Global Title originally derived by the VLR from the IMSI (when CCITT or ITU-T SCCP is used), or an E.212 number originally derived from IMSI (when ANSI SCCP is used, an IMSI); or - an E.164 HLR address; or - in the case of intra-PLMN signalling, an SPC. When answering with Global Title to the VLR, the HLR shall insert its E.164 address in the Calling Party Address of the SCCP message containing the first responding CONTINUE message. If the HLR is in the same PLMN as the VLR, local translation tables may exist to derive an SPC. For authentication information retrieval and location updating via the international PSTN/ISDN signalling network that requires the use of CCITT or ITU-T SCCP, the Global Title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. In World Zone 1 where the ANSI SCCP is used, IMSI (E.212 number) is used as Global Title. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below: - E.212 Mobile Country Code translates to E.164 Country Code; - E.212 Mobile Network Code translates to E.164 National Destination Code; - E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits. This translation will be done either at the application or at SCCP level in the VLR. The Mobile Global Title thus derived will be used to address the HLR. If location updating is triggered by an MS that roams from one MSC Area into a different MSC Area served by the same VLR, the VLR shall address the HLR in the same way as if the MS registers for the first time in the VLR. 6.1.3.3.3 After location updating completion In this case, the subscriber's basic MSISDN has been received from the HLR during the subscriber data retrieval procedure as well as the HLR number constituting a parameter of the MAP message indicating successful completion of the update location dialogue. From either of these E.164 numbers the address information for initiating dialogues with the roaming subscriber's HLR can be derived. Also the subscriber's IMSI may be used for establishing the routeing information towards the HLR. This may apply in particular if the dialogue with the HLR is triggered by subscriber controlled input. Thus the SCCP address of the roaming subscriber's HLR may be an SPC, or it may be a Global title consisting of the E.164 MSISDN or the E.164 number allocated to the HLR or either the E.214 Mobile Global Title derived from the IMSI if CCITT or ITU-T SCCP is used, or the IMSI if ANSI SCCP is used (ANSI SCCP is used in World Zone 1). 6.1.3.3.4 VLR restoration If a roaming number is requested by the HLR for an IMSI that has no data record in the interrogated VLR, the VLR provides the roaming number in the dialogue terminating message. Subsequently the VLR must retrieve the authentication data from the MS's HLR, if required, and must then trigger the restore data procedure. For this purpose, the VLR has to initiate in succession two independent dialogues with the MS's HLR. The MTP and SCCP address information needed for routeing towards the HLR can be derived from the IMSI received as a parameter of the MAP message requesting the roaming number. In this case, the IMSI received from the HLR in the roaming number request shall be processed in the same way as the IMSI that is received from an MS that registers for the first time within a VLR. Alternatively to the IMSI, the Calling Party Address associated with the roaming number request may be used to obtain the routeing information towards the HLR. 6.1.3.3.5 During Network-Requested PDP Context Activation When receiving a PDP PDU the GGSN may interrogate the HLR of the MS for information retrieval. When initiating such a dialogue, the only data for addressing the HLR that the GGSN has available is contained in the IMSI, and addressing information must be derived from it. The IMSI is obtained from the IP address or the X.25 address in the incoming IP message by means of a translation table. This means that the GGSN shall be able to address the HLR based on an E.214, (if CCITT or ITU-T SCCP is used), or E.212 (if ANSI SCCP is used), Mobile Global Title originally derived by the GGSN from the IMSI in the case of inter-PLMN signalling. In the case of intra-PLMN signalling, an SPC may also be used. If the HLR is in the same PLMN as the GGSN, local translation tables may exist to derive an SPC. For information retrieval via the international PSTN/ISDN signalling network, the Global title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below: - E.212 Mobile Country Code translates to E.164 Country Code; - E.212 Mobile Network Code translates to E.164 National Destination Code; - E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits. This translation will be done either at the application or at SCCP level in the GGSN. The Mobile Global Title thus derived will be used to address the HLR. 6.1.3.3.6 Before GPRS location updating completion When an MS registers for the first time in an SGSN, the SGSN has to initiate the update location dialogue with the MS's HLR and a preceding dialogue for authentication information retrieval if the authentication information must be retrieved from the HLR. When initiating either of these dialogues, the only data for addressing the HLR that the SGSN has available is contained in the IMSI, and addressing information for SCCP must be derived from it. When continuing the established update location dialogue (as with any other dialogue), the SGSN must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. This means that the SGSN must be able to address the HLR based on: - an E.214 (if CCITT or ITU-T SCCP is used) or E.212 (if ANSI SCCP is used) Mobile Global Title originally derived by the SGSN from the IMSI; or - an E.164 HLR address; or - in the case of intra-PLMN signalling, an SPC. If the HLR is in the same PLMN as the SGSN, local translation tables may exist to derive an SPC. For authentication information retrieval and location updating via the international PSTN/ISDN signalling network, the Global title must be derived from the IMSI, using the principles contained in CCITT Recommendation E.214 and the Numbering Plan Indicator (NPI) value referenced by the SCCP Specifications. A summary of the translation from the IMSI (CCITT Recommendation E.212) to Mobile Global Title (described in CCITT Recommendation E.214) is shown below: - E.212 Mobile Country Code translates to E.164 Country Code; - E.212 Mobile Network Code translates to E.164 National Destination Code; - E.212 Mobile Subscriber Identification Number (MSIN) is carried unchanged if within the E.164 number maximum length (15 digits). If the Mobile Global Title is more than 15 digits the number is truncated to 15 by deleting the least significant digits. This translation will be done either at the application or at SCCP level in the SGSN. The Mobile Global Title thus derived will be used to address the HLR. 6.1.3.3.7 After GPRS location updating completion In this case, the subscriber's Basic MSISDN has been received from the HLR during the subscriber data retrieval procedure as well as the HLR number constituting a parameter of the MAP message indicating successful completion of the update location dialogue. From either of these E.164 numbers the address information for initiating dialogues with the roaming subscriber's HLR can be derived. Also the subscriber's IMSI may be used for establishing the routeing information towards the HLR. Thus the SCCP address of the roaming subscriber's HLR may be an SPC, or it may be a Global title consisting of the E.164 MSISDN or the E.164 number allocated to the HLR or the E.214 Mobile Global Title derived from the IMSI. 6.1.3.3.8 Query for a Location Request For a location request from an external client, the GMLC needs to address the home HLR of the target MS to obtain the address of the target MS's serving MSC. The GMLC uses either the international E.164 MSISDN, the international E.214 number (if CCITT or ITU-T SCCP is used) or the international E.212 number (if ANSI SCCP is used) of the MS as means to route a query to the HLR. 6.1.3.4 The Visitor Location Register (VLR) 6.1.3.4.0 General There are several cases when the VLR needs to be addressed. 6.1.3.4.1 Inter-VLR information retrieval When an MS moves from one VLR service area to another, the new VLR may request the IMSI and authentication sets from the previous VLR. The new VLR derives the address of the previous VLR from the Location Area Identification provided by the MS in the location registration request. 6.1.3.4.2 HLR request The HLR will only request information from a VLR if it is aware that one of its subscribers is in the VLR service area. This means that a location updating dialogue initiated by the VLR has been successfully completed, i.e. the HLR has indicated successful completion of the update location procedure to the VLR. When initiating dialogues towards the VLR after successful completion of location updating, the routeing information used by the HLR is derived from the E.164 VLR number received as a parameter of the MAP message initiating the update location dialogue. If the VLR is in the same PLMN as the HLR, the VLR may be addressed directly by an SPC derived from the E.164 VLR number. For dialogues via the international PSTN/ISDN signalling network, presence of the E.164 VLR number in the Called Party Address is required. 6.1.3.4.3 CSS request The CSS will only request information from a VLR if it is aware that one of its subscribers is in the VLR service area. This means that a VCSG location updating dialogue initiated by the VLR has been successfully completed, i.e. the CSS has indicated successful completion of the update VCSG location procedure to the VLR. When initiating dialogues towards the VLR after successful completion of VCSG location updating, the routeing information used by the CSS is derived from the E.164 VLR number received as a parameter of the MAP message initiating the update VCSG location dialogue. The VLR may be addressed either by the E.164 VLR number or directly by an SPC derived from the E.164 VLR number due to the VLR is in the same PLMN as the CSS. 6.1.3.5 The Interworking MSC (IWMSC) for Short Message Service The IWMSC is the interface between the mobile network and the network to access to the Short Message Service Centre. This exchange has an E.164 address known in the SGSN or in the MSC. 6.1.3.6 The Equipment Identity Register (EIR) The EIR address is either unique or could be derived from the IMEI. The type of address is not defined. 6.1.3.7 Void 6.1.3.8 The Serving GPRS Support Node (SGSN) 6.1.3.8.0 General There are several cases when the SGSN needs to be addressed. 6.1.3.8.1 HLR request The HLR will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN serving area. This means that a GPRS location updating has been successfully completed, i.e., the HLR has indicated successful completion of the GPRS location update to the SGSN. The routeing information used by the HLR is derived form the E.164 SGSN number received as parameter of the MAP message initiating the GPRS update location procedure. If the SGSN is in the same PLMN as the HLR, the SGSN may be addressed directly by an SPC derived from the E.164 SGSN number. For dialogues via the international PSTN/ISDN signalling network, the presence of the E.164 SGSN number in the Called Party Address is required. 6.1.3.8.2 GMSC request When the GMSC initiates dialogues towards the SGSN the SGSN (MAP) SSN (See 3GPP TS 23.003 [17]) shall be included in the called party address. The routeing information used by the GMSC is derived from the E.164 SGSN number received as a parameter of the MAP message initiating the forward short message procedure. If the GMSC does not support the GPRS functionality the MSC (MAP) SSN value shall be included in the called party address. NOTE: Every VMSC and SGSN shall have uniquely identifiable application using E.164 numbers, for the purpose of SMS over GPRS when the GMSC does not support the GPRS functionality. 6.1.3.8.3 CSS request The CSS will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN serving area. This means that a VCSG location updating has been successfully completed, i.e., the CSS has indicated successful completion of the VCSG location update to the SGSN. The routeing information used by the CSS is derived from the E.164 SGSN number received as parameter of the MAP message initiating the update VCSG location procedure. The SGSN may be addressed either by the E.164 SGSN number or directly by an SPC derived from the E.164 SGSN number due to the SGSN is in the same PLMN as the CSS. 6.1.3.9 The Gateway GPRS Support Node (GGSN) The GGSN provides interworking with external packet-switched networks, network screens and routing of the Network-Requested PDP Context activation. If a Network-Requested PDP Context activation fails, the HLR will alert the GGSN when the subscriber becomes reachable. The HLR will use the E.164 GGSN number received as parameter of the MAP message reporting the failure. 6.1.3.10 The Gateway MSC (GMSC) for Short Message Service The GMSC provides interworking with the network to access the Short Message Service Centre, the mobile network and routing of Send Routing Info For SM. The GMSC has on E.164 address known in the HLR, SGSN or MSC. 6.1.3.10A Void 6.1.3.10A.1 Void 6.1.3.10A.2 Void 6.1.3.10B The Gateway Mobile Location Centre (GMLC) The GMLC initiates location requests on behalf of external clients. The E.164 address of the GMLC is provided to an HLR when the GMLC requests a serving MSC address or SGSN address from the HLR for a target MS. The E.164 address of the GMLC is also provided to a serving MSC or SGSN when the GMLC requests the location of a target MS served by this MSC or SGSN. 6.1.3.10C The CSG Subscriber Server (CSS) The CSS address is either unique or could be derived from the IMSI. The type of address is not defined. 6.1.3.11 Summary table The following tables summarise the SCCP address used for invoke operations. As a principle, within a PLMN either an SPC or a GT may be used (network operation option), whereas when addressing an entity outside the PLMN the GT must be used. The address type mentioned in the tableÊ(e.g. MSISDN) is used as GT or to derive the SPC. For a response, the originating address passed in the invoke is used as SCCP Called Party Address. For extra-PLMN addressing the own E.164 entity address is used as SCCP Calling Party Address; for intra-PLMN addressing an SPC derived from the entity number may be used instead. When using an SPC, the SPC may be taken directly from MTP. TableÊ6.1/1 to from fixed net work HLR VLR MSC EIR gsmSCF SGSN GGSN CSS fixed network --- E:GT T:MSISDN --- --- --- --- --- --- --- Home Location Register --- --- I:SPC/GT E:GT T:VLR NUMBER --- --- I:SPC/GT E:GT T:gsmSCF NUMBER I:SPC/GT E:GT T:SGSN NUMBER I:SPC/GT E:GT T:GGSN NUMBER --- Visitor Location Register --- I:SPC/GT E:GT T:MGT (outside World Zone 1)/MSISDN (World Zone 1/)HLR NUMBER (note) I:SPC/GT E:GT T:VLR NUMBER --- --- I:SPC/GT E:GT T:gsmSCF NUMBER --- --- I: SPC/GT E:GT T:CSS NUMBER mobile-services switching centre --- I:SPC/GT E:GT T:MSISDN I:SPC/GT E:GT T:VLR NUMBER I:SPC/GT E:GT T:MSC NUMBER I:SPC/GT E:GT T:EIR NUMBER I:SPC/GT E:GT T:gsmSCF NUMBER I:SPC/GT E:GT T:SGSN NUMBER --- --- gsm Service Control Function --- I:SPC/GT E:GT T:MSISDN --- --- --- --- --- --- --- Serving GPRS Support Node --- I:SPC/GT E:GT T:MGT/ MSISDN/HLR NUMBER --- I:SPC/GT E:GT T:MSC NUMBER I:SPC/GT E:GT T:EIR NUMBER I:SPC/GT E:GT T:gsmSCF NUMBER --- --- I:SPC/GT E:GT T:CSS NUMBER Gateway GPRS Support Node --- I:SPC/GT E:GT T:MGT --- --- --- --- --- --- --- Gateway Mobile Location Centre --- I:SPC/GT E:GT T:MSISDN, MGT (outside World Zone 1) or IMSI (World Zone 1) (note) --- I:SPC/GT E:GT T:MSC NUMBER --- --- I:SPC/GT E:GT T:SGSN NUMBER --- --- CSG Subscriber Server --- --- I:SPC/GT E:GT T:VLR NUMBER --- --- --- I:SPC/GT E:GT T:SGSN NUMBER --- --- I: Intra-PLMN. E: Extra (Inter)-PLMN. T: Address Type. GT: Global Title. MGT: E.214 Mobile Global Title. SPC: Signalling Point Code. NOTE: For initiating the location updating procedure and an authentication information retrieval from the HLR preceding it, the VLR has to derive the HLR address from the IMSI of the MS. The result can be an SPC or an E.214 Mobile Global Title if CCITT or ITU-T SCCP is used, or IMSI itself if ANSI SCCP is used (ANSI SCCP is used in World Zone 1). When continuing the established update location dialogue (as with any other dialogue) the VLR must derive the routeing information towards the HLR from the Calling Party Address received with the first responding CONTINUE message until the dialogue terminating message is received. For transactions invoked by the VLR after update location completion, the VLR may derive the information for addressing the HLR from addresses received in the course of the update location procedure (MSISDN or HLR number) or from the IMSI. When invoking the Restore Data procedure and an authentication information retrieval from the HLR preceding it, the VLR must derive the information for addressing the HLR from the address information received in association with the roaming number request. This may be either the IMSI received as a parameter of the MAP message requesting the Roaming Number or the Calling Party Address associated with the MAP message requesting the Roaming Number. The gsmSCF shall be addressed using more than one Global Title number. The first Global Title number is used to address a gsmSCF for MAP. The second Global Title number is used to address a gsmSCF for CAP. For querying the HLR to obtain the VMSC address to support location services, the GMLC has to derive the HLR address from either the MSISDN or IMSI of the target MS. When using the IMSI, the result can be an SPC or an E.214 Mobile Global Title if CCITT or ITU-T SCCP is used, or IMSI itself if ANSI SCCP is used (ANSI SCCP is used in World Zone 1). TableÊ6.1/2 to from GMLC fixed network --- Home Location Register --- Visitor Location Register --- Mobile-services Switching Centre I:SPC/GT E:GT T:MLC Number gsm Service Control Function I:SPC/GT E:GT T:MSISDN Serving GPRS Support Node I:SPC/GT E:GT T:MLC Number Gateway GPRS Support Node --- Gateway Mobile Location Centre I: Intra-PLMN. E: Extra (Inter)-PLMN. T: Address Type. GT: Global Title. MGT: E.214 Mobile Global Title. SPC: Signalling Point Code. 6.2 Use of TC The Mobile Application part makes use of the services offered by the Transaction Capabilities (TC) of Signalling System No. 7. ETSÊ300Ê287, which is based on CCITT White Book Recommendations Q.771 to Q.775, should be consulted for the full specification of TC. The MAP uses all the services provided by TC except the ones related to the unstructured dialogue facility. From a modelling perspective, the MAP is viewed as a single Application Service Element. Further structuring of it is for further study. Transaction Capabilities refers to a protocol structure above the network layer interface (i.e., the SCCP service interface) up to the application layer including common application service elements but not the specific application service elements using them. TC is structured as a Component sub-layer above a Transaction sub-layer. The Component sub-layer provides two types of application services: services for the control of end-to-end dialogues and services for Remote Operation handling. These services are accessed using the TC-Dialogue handling primitives and TC-Component handling primitives respectively. Services for dialogue control include the ability to exchange information related to application-context negotiation as well as initialisation data. Services for Remote Operation handling provide for the exchange of protocol data units invoking tasks (operations), and reporting their outcomes (results or errors) plus any non-application-specific protocol errors detected by the component sub-layer. The reporting of application-specific protocol errors by the TC user, as distinct from application process errors, is also provided. The Transaction sub-layer provides a simple end-to-end connection association service over which several related protocol data units (i.e. built by the Component Sub-Layer) can be exchanged. A Transaction termination can be prearranged (no indication provided to the TC user) or basic (indication provided). 7 General on MAP services 7.1 Terminology and definitions The term service is used in clauses 7 to 12 as defined in CCITT Recommendation X.200. The service definition conventions of CCITT Recommendation X.210 are also used. MAP services that are defined for use between HLR and SGSN are also used in an Evolved Packet System (EPS) between two IWFs and between HSS and IWF, where the IWF is an Interworking Function that converts MAP messages to Diameter messages and vice versa. MAP services that are defined for use between SGSN and EIR are also used in an Evolved Packet System (EPS) between IWF and EIR. IWFs may be connected via Diameter to MMEs and HSSs and they may be connected via MAP to HSSs, IWFs, and EIRs. 7.2 Modelling principles MAP provides its users with a specified set of services and can be viewed by its users as a ""black box"" or abstract machine representing the MAP service-provider. The service interface can then be depicted as shown in figureÊ7.2/1. FigureÊ7.2/1: Modelling principles The MAP service-users interact with the MAP service-provider by issuing or receiving MAP service-primitives at the service interface. A MAP service-user may receive services from several instances of the MAP service-provider at the same time. In such cases the overall procedure is synchronised by the service-user. The MAP service-primitives are named using the following notation: MAP-ServicePrimitiveName type where type can be any of: request (req), indication (ind), response (rsp) or confirm (cnf). (In the user arrow diagrams type is not indicated in the case of req/ind and indicated as ""ack"" in the case of rsp/cnf). The services are further classified as unconfirmed-service, confirmed-service and provider-initiated-service where the first two categories refer to whether or not the service is confirmed by the service-provider. The confirmation may or may not correspond to a response provided by the other service-user. MAP services are also classified as common MAP services that are available to all MAP service-users, and MAP service-user specific services, which are services available to one or several, but not all, MAP service-users. A MAP dialogue is defined as an exchange of information between two MAP users in order to perform a common task. A MAP dialogue will consist of one or several MAP services. 7.3 Common MAP services All MAP service-users require access to services for performing basic application layer functions: - for establishing and clearing MAP dialogues between peer MAP service-users; - for accessing functions supported by layers below the applications layer; - for reporting abnormal situations; - for handling of different MAP versions; - for testing whether or not a persistent MAP dialogue is still active at each side. For these purposes the following common services are defined: - MAP-OPEN service; - MAP-CLOSE service; - MAP-DELIMITER service; - MAP-U-ABORT service; - MAP-P-ABORT service; - MAP-NOTICE service. In defining the service-primitives the following convention is used for categorising parameters: M the inclusion of the parameter is mandatory. The M category can be used for any primitive type and specifies that the corresponding parameter must be present in the indicated primitive type; O the inclusion of the parameter is a service-provider option. The O category can be used in indication and confirm type primitives and is used for parameters that may optionally be included by the service-provider; U the inclusion of the parameter is a service-user option. The U category can be used in request and response type primitives. The inclusion of the corresponding parameter is the choice of the service-user; C the inclusion of the parameter is conditional. The C category can be used for the following purposes: - to indicate that if the parameter is received from another entity it must be included for the service being considered; - to indicate that the service user must decide whether to include the parameter, based on the context on which the service is used; - to indicate that one of a number of mutually exclusive parameters must be included (e.g. parameters indicating a positive result versus parameters indicating a negative result); - to indicate that a service user optional parameter (marked ""U"") or a conditional parameter (marked ""C"") presented by the service user in a request or response type primitive is to be presented to the service user in the corresponding indication or confirm type primitive; (=) when appended to one of the above, this symbol means that the parameter takes the same value as the parameter appearing immediately to its left; blank the parameter is not present. A primitive type may also be without parameters, i.e. no parameter is required with the primitive type; in this case the corresponding column of the tableÊis empty. 7.3.1 MAP-OPEN service This service is used for establishing a MAP dialogue between two MAP service-users. The service is a confirmed service with service primitives as shown in tableÊ7.3/1. TableÊ7.3/1: Service-primitives for the MAP-OPEN service Parameters Request Indication Response Confirm Application context name M M(=) U C(=) Destination address M M(=) Destination reference U C(=) Originating address U O Originating reference U C(=) Specific information U C(=) U C(=) Responding address U C(=) Result M M(=) Refuse-reason C C(=) Provider error O Application context name: This parameter identifies the type of application context being established. If the dialogue is accepted the received application context name shall be echoed. In case of refusal of dialogue this parameter shall indicate the highest version supported. Destination address: A valid SCCP address identifying the destination peer entity (see also clauseÊ6). As an implementation option, this parameter may also, in the indication, be implicitly associated with the service access point at which the primitive is issued. Destination-reference: This parameter is a reference that refines the identification of the called process. It may be identical to Destination address but its value is to be carried at MAP level. TableÊ7.3/2 describes the MAP services using this parameter. Only these services are allowed to use it. TableÊ7.3/2: Use of the destination reference MAP service Reference type Use of the parameter MAP-REGISTER-SS IMSI Subscriber identity MAP-ERASE-SS IMSI Subscriber identity MAP-ACTIVATE-SS IMSI Subscriber identity MAP-DEACTIVATE-SS IMSI Subscriber identity MAP-INTERROGATE-SS IMSI Subscriber identity MAP-REGISTER-PASSWORD IMSI Subscriber identity MAP-PROCESS-UNSTRUCTURED- SS-REQUEST IMSI (note 1) Subscriber identity MAP-UNSTRUCTURED- SS-REQUEST IMSI (note 2) Subscriber identity MAP-UNSTRUCTURED-SS-NOTIFY IMSI (note 2) Subscriber identity MAP-FORWARD-SHORT-MESSAGE IMSI (note 3) Subscriber identity MAP-REGISTER-CC-ENTRY IMSI Subscriber identity MAP-ERASE-CC-ENTRY IMSI Subscriber identity NOTE 1: On the HLR - HLR interface and on the HLR - gsmSCF interface the Destination reference shall be either IMSI or MSISDN. NOTE 2: On the gsmSCF - HLR interface and on the HLR - HLR interface the Destination reference shall be either IMSI or MSISDN. NOTE 3: Only when the IMSI and the LMSI are received together from the HLR in the mobile terminated short message transfer. Originating address: A valid SCCP address identifying the requestor of a MAP dialogue (see also clauseÊ6). As an implementation option, this parameter may also, in the request, be implicitly associated with the service access point at which the primitive is issued. Originating-reference: This parameter is a reference that refines the identification of the calling process. It may be identical to the Originating address but its value is to be carried at MAP level. TableÊ7.3/3 describes the MAP services using the parameter. Only these services are allowed to use it. Processing of the Originating-reference shall be performed according to the supplementary service descriptions and other service descriptions, e.g. operator determined barring. Furthermore the receiving entity may be able to use the value of the Originating-reference to screen the service indication. TableÊ7.3/3: Use of the originating reference MAP service Reference type Use of the parameter MAP-REGISTER-SS ISDN-Address-String Originated entity address MAP-ERASE-SS ISDN-Address-String Originated entity address MAP-ACTIVATE-SS ISDN-Address-String Originated entity address MAP-DEACTIVATE-SS ISDN-Address-String Originated entity address MAP-INTERROGATE-SS ISDN-Address-String Originated entity address MAP-REGISTER-PASSWORD ISDN-Address-String Originated entity address MAP-PROCESS-UNSTRUCTURED- SS-REQUEST ISDN-Address-String Originated entity address MAP-UNSTRUCTURED- SS-REQUEST ISDN-Address-String (note) Originated entity address MAP-UNSTRUCTURED- SS-NOTIFY ISDN-Address-String (note) Originated entity address MAP-REGISTER-CC-ENTRY ISDN-Address-String Originated entity address MAP-ERASE-CC-ENTRY ISDN-Address-String Originated entity address NOTE: The Originating reference may be omitted. Specific information: This parameter may be used for passing any user specific information."
"Establishment and processing of the Specific information is not specified by GSM and shall be performed according to operator specific requirements. Responding address: An address identifying the responding entity. The responding address is included if required by the context (e.g. if it is different from the destination address). Result: This parameter indicates whether the peer accepts the dialogue. Refuse reason: This parameter is present only if the Result parameter indicates that the dialogue is refused. It takes one of the following values: - Application-context-not-supported; - Invalid-destination-reference; - Invalid-originating-reference; - No-reason-given; - Remote node not reachable; - Potential version incompatibility. 7.3.2 MAP-CLOSE service This service is used for releasing a previously established MAP dialogue. The service may be invoked by either MAP service-user depending on rules defined within the service-user. The service is an unconfirmed service with parameters as shown in tableÊ7.3/4. TableÊ7.3/4: Service-primitives for the MAP-CLOSE service Parameters Request Indication Release method M Specific Information U C(=) Release method: This parameter can take the following two values: - normal release; in this case the primitive is mapped onto the protocol and sent to the peer; - prearranged end; in this case the primitive is not mapped onto the protocol. Prearranged end is managed independently by the two users, i.e. only the request type primitive is required in this case. Specific information: This parameter may be used for passing any user specific information. Establishment and processing of the Specific information is not specified by GSMÊGSMÊand shall be performed according to operator specific requirements. 7.3.3 MAP-DELIMITER service This service is used to explicitly request the transfer of the MAP protocol data units to the peer entities. See also clauseÊ7.4 and 7.5 for the detailed use of the MAP-DELIMITER service. The service is an unconfirmed service with service-primitives as shown in tableÊ7.3/5. TableÊ7.3/5: Service-primitives for the MAP-DELIMITER service Parameters Request Indication 7.3.4 MAP-U-ABORT service This service enables the service-user to request the MAP dialogue to be aborted. The service is an unconfirmed service with service-primitives as shown in tableÊ7.3/6. TableÊ7.3/6: Service-primitives for the MAP-U-ABORT service Parameters Request Indication User reason M M(=) Diagnostic information U C(=) Specific information U C(=) User reason: This parameter can take the following values: - resource limitation (congestion); the requested user resource is unavailable due to congestion; - resource unavailable; the requested user resource is unavailable for reasons other than congestion; - application procedure cancellation; the procedure is cancelled for reasons detailed in the diagnostic information parameter; - procedure error; processing of the procedure is terminated for procedural reasons. Diagnostic information: This parameter may be used to give additional information for some of the values of the user-reason parameter: TableÊ7.3/7: User reason and diagnostic information User reason Diagnostic information Resource limitation (congestion) - Resource unavailable Short term/long term problem Application procedure cancellation Handover cancellation/ Radio Channel release/ Network path release/ Call release/ Associated procedure failure/ Tandem dialogue released/ Remote operations failure Procedure error - Specific information: This parameter may be used for passing any user specific information. Establishment and processing of the Specific information is not specified by GSMÊand shall be performed according to operator specific requirements. 7.3.5 MAP-P-ABORT service This service enables the MAP service-provider to abort a MAP dialogue. The service is a provider-initiated service with service-primitives as shown in tableÊ7.3/8. TableÊ7.3/8: Service-primitives for the MAP-P-ABORT service Parameters Indication Provider reason M Source M Provider reason: This parameter indicates the reason for aborting the MAP dialogue: - provider malfunction; - supporting dialogue/transaction released; - resource limitation; - maintenance activity; - version incompatibility; - abnormal MAP dialogue. Source: This parameter indicates the source of the abort. For Transaction Capabilities (TC) applications the parameter may take the following values: - MAP problem; - TC problem; - network service problem. TableÊ7.3/9: Values of provider reason and source parameters and examples of corresponding events Provider reason Source Corresponding event Provider MAP Malfunction at MAP level at peer entity malfunction TC ""Unrecognised message type"" or ""Badly formatted transaction portion"" or ""Incorrect transaction portion"" received in TC-P-ABORT ""Abnormal dialogue"" Network service Malfunction at network service level at peer entity Supporting dialogue/ transaction released TC ""Unrecognised transaction ID"" received in TC-ABORT Resource MAP Congestion towards MAP peer service-user limitation TC ""Resource limitation"" received in TC-P-ABORT Maintenance MAP Maintenance at MAP peer service-user activity Network service Maintenance at network peer service level Abnormal MAP dialogue MAP MAP dialogue is not in accordance with specified application context Version incompatibility TC A Provider Abort indicating ""No common dialogue portion"" is received in the dialogue initiated state 7.3.6 MAP-NOTICE service This service is used to notify the MAP service-user about protocol problems related to a MAP dialogue not affecting the state of the protocol machines. The service is a provider-initiated service with service-primitive as shown in tableÊ7.3/10. TableÊ7.3/10: Service-primitive for the MAP-NOTICE service Parameters Indication Problem diagnostic M Problem diagnostic: This parameter can take one of the following values: - abnormal event detected by the peer; - response rejected by the peer; - abnormal event received from the peer; - message cannot be delivered to the peer. 7.3.7 Void 7.3.8 Void 7.3.9 Void 7.3.10 Void 7.4 Sequencing of services The sequencing of services is shown in figureÊ7.4/1 and is as follows: Opening: The MAP-OPEN service is invoked before any user specific service-primitive is accepted. The sequence may contain none, one or several user specific service-primitives. If no user specific service-primitive is contained between the MAP-OPEN and the MAP-DELIMITER primitives, then this will correspond to sending an empty Begin message in TC. If more than one user specific service-primitive is included, all are to be sent in the same Begin message. The sequence ends with a MAP-DELIMITER primitive. Continuing: This sequence may not be present in some MAP dialogues. If it is present, it ends with a MAP-DELIMITER primitive. If more than one user specific service-primitive is included, all are to be included in the same Continue message. Closing: The sequence can only appear after an opening sequence or a continuing sequence. The sequence may contain none, one or several user specific service-primitives if the MAP-CLOSE primitive specifies normal release. If no user specific service-primitive is included, then this will correspond to sending an empty End message in TC. If more than one user specific service-primitive is included, all are to be sent in the same End message. If prearranged end is specified, the sequence cannot contain any user specific service-primitive. The MAP-CLOSE primitive must be sent after all user specific service-primitives have been delivered to the MAP service-provider. Aborting: A MAP service-user can issue a MAP-U-ABORT primitive at any time after the MAP dialogue has been opened or as a response to an attempt to open a MAP dialogue. The MAP service-provider may issue at any time a MAP-P-ABORT primitive towards a MAP service-user for which a MAP dialogue exists. MAP-U-ABORT primitives and MAP-P-ABORT primitives terminate the MAP dialogue. a) Opening b) Continuing c) Closing d) Aborting FigureÊ7.4/1: Sequencing of services If the reason ""resource unavailable (short term problem)"" is indicated in the MAP-U-ABORT indication primitive, the MAP service-user may decide to attempt a new MAP dialogue establishment immediately. Sequencing of user specific service-primitives is done by the MAP service-user and based on rules applicable for each MAP service-user instance. A MAP-NOTICE indication primitive may be received at any time during the active period of a MAP dialogue. 7.5 General rules for mapping of services onto TC 7.5.1 Mapping of common services TableÊ7.5/1 gives an overview of the mapping rules for mapping of common services onto TC-services. TableÊ7.5/2 gives the mapping rules for mapping of TC-services onto common services. Protocol machine description is given in clauses 14 to 17. TableÊ7.5/1: Mapping of common services onto TC services MAP service-primitive TC service-primitive MAP-OPEN request (+ any user specific service primitives) + MAP-DELIMITER request TC-BEGIN request (+ component handling primitives) MAP-OPEN response (+ any user specific service primitives) + MAP-DELIMITER request TC-CONTINUE request (note) (+ component handling primitives) (any user specific service primitives) + MAP-DELIMITER request TC-CONTINUE request (+ component handling primitives) (any user specific service primitives) + MAP-CLOSE request TC-END request (+ component handling primitives) MAP-U-ABORT request TC-U-ABORT request NOTE: Or TC-END if the MAP-CLOSE request has been received before the MAP-DELIMITER request. TableÊ7.5/2: Mapping of TC services onto common service TC service-primitive MAP service-primitive TC-BEGIN indication (+ component handling primitives) MAP-OPEN indication (+ user specific service primitives) + MAP-DELIMITER indication (note 1) TC-CONTINUE indication (+ component handling primitives) First time: MAP-OPEN confirm (+ user specific service primitives) + MAP-DELIMITER indication (note 1) Subsequent times: (user specific service primitives) + MAP-DELIMITER indication (note 1) TC-END indication (+ component handling primitives) MAP-OPEN confirm (note 6) (user specific service primitives) + MAP-CLOSE indication TC-U-ABORT indication MAP-U-ABORT indication or MAP-P-ABORT indication (note 2) MAP-OPEN confirmation (note 3) TC-P-ABORT indication MAP-P-ABORT indication (note 4) MAP-OPEN confirmation (note 5) NOTE 1: It may not be necessary to present this primitive to the user for MAP version 2 applications. NOTE 2: The mapping depends on whether the TC-U-ABORT indication primitive contains a MAP abort PDU from the remote MAP service-provider or a MAP-user-abort-PDU from the remote MAP service-user. NOTE 3: Only if the opening sequence is pending and if the ""Abort Reason"" in the TC-U-ABORT indication is set to ""Application Context Not Supported"". NOTE 4: If the ""Abort Reason"" in the TC-P-ABORT indication is set to a value different from ""Incorrect Transaction Portion"". NOTE 5: Only if the opening sequence is pending and if the ""Abort Reason"" in the TC-P-ABORT indication is set to ""Incorrect Transaction Portion"". NOTE 6: Only if opening sequence is pending. 7.5.2 Mapping of user specific services TableÊ7.5/3 gives the general mapping rules which apply to mapping of MAP user specific services onto TC services and tableÊ7.5/4 gives the similar rules for mapping of TC services onto MAP user specific services. Detailed mapping is given in clauses 14 to 17. TableÊ7.5/3: Mapping of MAP user specific services onto TC services MAP service-primitive TC-service-primitive MAP-xx request TC-INVOKE request MAP-xx response TC-RESULT-L request (note 1) TC-U-ERROR request TC-U-REJECT request TC-INVOKE request (note 2) TableÊ7.5/4: Mapping of TC services onto MAP user specific services TC-service-primitive MAP service-primitive TC-INVOKE indication MAP-xx indication TC-RESULT-L indication (note 4) MAP-xx confirm TC-U-ERROR indication TC-INVOKE indication (note 2) TC-L-CANCEL indication TC-U-REJECT indication MAP-xx confirm or TC-L-REJECT indication MAP-NOTICE indication (note 3) TC-R-REJECT indication Notes to tables 7.5/3 and 7.5/4: NOTE 1: The mapping is determined by parameters contained in the MAP-xx response primitive. NOTE 2: This applies only to TC class 4 operations where the operation is used to pass a result of another class 2 or class 4 operation. NOTE 3: The detailed mapping rules are given in clauseÊ16. NOTE 4: If RESULT-NL components are present they are mapped onto the same MAP-xx confirm. 7.6 Definition of parameters 7.6.1 Common parameters The following set of parameters is used in several MAP service-primitives. 7.6.1.1 Invoke Id This parameter identifies corresponding service primitives. The parameter is supplied by the MAP service-user and must be unique over each service-user/service-provider interface. 7.6.1.2 Linked Id This parameter is used for linked services and it takes the value of the invoke Id of the service linked to. 7.6.1.3 Provider error This parameter is used to indicate a protocol related type of error: - duplicated invoke Id; - not supported service; - mistyped parameter; - resource limitation; - initiating release, i.e. the peer has already initiated release of the dialogue and the service has to be released; - unexpected response from the peer; - service completion failure; - no response from the peer; - invalid response received. 7.6.1.4 User error This parameter can take values as follows: NOTE: The values are grouped in order to improve readability; the grouping has no other significance. a) Generic error: - system failure, i.e. a task cannot be performed because of a problem in the entity reporting the error or in another entity. The type of entity or network resource may be indicated by use of the network resource parameter or additional network resource parameter. If and only if the problem is in the entity reporting the error, a cause of failure (FailureCauseParam) shall be included; - data missing, i.e. an optional parameter required by the context is missing; - unexpected data value, i.e. the data type is formally correct but its value or presence is unexpected in the current context; - resource limitation; - initiating release, i.e. the receiving entity has started the release procedure; - facility not supported, i.e. the requested facility is not supported by the PLMN with detailed reasons as follows: - Shape of location estimate not supported; - Needed LCS capability not supported in serving node; - incompatible terminal, i.e. the requested facility is not supported by the terminal. b) Identification or numbering problem: - unknown subscriber, i.e. no such subscription exists; - number changed, i.e. the subscription does not exist for that number any more; - unknown MSC; - unidentified subscriber, i.e. if the subscriber is not contained in the database and it has not or cannot be established whether or not a subscription exists; - unallocated roaming number; - unknown equipment; - unknown location area. c) Subscription problem: - roaming not allowed, i.e. a location updating attempt is made in an area not covered by the subscription; - illegal subscriber, i.e. illegality of the access has been established by use of authentication procedure; - bearer service not provisioned; - teleservice not provisioned; - illegal equipment, i.e. the IMEI check procedure has shown that the IMEI is prohibited-listed or not permitted-listed. d) Handover problem: - no handover number available, i.e. the VLR cannot allocate a number for handover or cannot allocate the required amount of numbers for relocation; - subsequent handover failure, i.e. handover to a third MSC failed for some reason; - target cell outside group call area. e) Operation and maintenance problem: - tracing buffer full, i.e. tracing cannot be performed because the tracing capacity is exceeded. f) Call set-up problem: - no roaming number available, i.e. a roaming number cannot be allocated because all available numbers are in use; - absent subscriber, i.e. the subscriber has activated the detach service or the system detects the absence condition. This error may be qualified to indicate whether the subscriber was IMSI detached, in a restricted area or did not respond to paging; - busy subscriber. This error may be qualified to indicate that the subscriber was busy due to CCBS and that CCBS is possible; - no subscriber reply; - forwarding violation, i.e. the call has already been forwarded the maximum number of times that is allowed; - CUG reject, i.e. the call does not pass a CUG check; additional information may also be given in order to indicate rejection due to e.g. incoming call barred or non-CUG membership; - call barred. Optionally, additional information may be included for indicating either that the call meets a barring condition set by the subscriber or that the call is barred for operator reasons. In the case of barring of Mobile Terminating Short Message, the additional information may indicate a barring condition due to ""Unauthorised Message Originator""; if the call is rejected due to the application of the ACR supplementary service, the additional information shall indicate a barring condition due to ""Anonymous Call Rejection""; - optimal routeing not allowed, i.e. the entity which sends the error does not support optimal routeing, or the HLR will not accept an optimal routeing interrogation from the GMSC, or the call cannot be optimally routed because it would contravene optimal routeing constraints; - forwarding failed, i.e. the GMSC interrogated the HLR for forwarding information but the HLR returned an error. g) Supplementary services problem: - call barred; - illegal SS operation; - SS error status; - SS not available; - SS subscription violation; - SS incompatibility; - negative password check; - password registration failure; - Number of Password Attempts; - USSD Busy; - Unknown Alphabet; - short term denial; - long term denial. For definition of these errors see 3GPP TS 24.080 [38]. h) Short message problem: - SM delivery failure with detailed reason as follows: - memory capacity exceeded; - MS protocol error; - MS not equipped; - unknown service centre (SC); - SC congestion; - invalid SME address; - subscriber is not an SC subscriber; - and possibly detailed diagnostic information, coded as specified in 3GPP TS 23.040, under SMS-SUBMIT-REPORT and SMS-DELIVERY-REPORT. If the SM entity that returns the SM Delivery Failure error includes detailed diagnostic information, it shall be forwarded in the MAP_MO_FORWARD_SHORT_MESSAGE and in the MAP_MT_FORWARD_SHORT_MESSAGE response. - message waiting list full, i.e. no further SC address can be added to the message waiting list. - Subscriber busy for MT SMS, i.e. the mobile terminated short message transfer cannot be completed because: - another mobile terminated short message transfer is going on and the delivery node does not support message buffering; or - another mobile terminated short message transfer is going on and it is not possible to buffer the message for later delivery; or - the message was buffered but it is not possible to deliver the message before the expiry of the buffering time defined in 3GPP TS 23.040; - Absent Subscriber SM, i.e. the mobile terminated short message transfer cannot be completed because the network cannot contact the subscriber. Diagnostic information regarding the reason for the subscriber's absence may be included with this error. i) Location services problem: - Unauthorised Requesting Network - Unauthorised LCS Client with detailed reasons as follows: - NoAdditional Information - Client not in MS Privacy Exception List - Call to Client not setup - Disallowed by Local Regulatory Requirements - Unauthorised Privacy Class - Unauthorised Call/Session Unrelated External Client - Unauthorised Call/Session Related External Client - Privacy override not applicable - Position method failure with detailed reasons as follows: - Congestion - Insufficient resources - Insufficient Measurement Data - Inconsistent Measurement Data - Location procedure not completed - QoS not attainable - Position Method Not Available in Network - Position Method Not Available in Location Area - Unknown or unreachable LCS Client. 7.6.1.5 All Information Sent This parameter indicates to the receiving entity when the sending entity has sent all necessary information. 7.6.2 Numbering and identification parameters 7.6.2.1 IMSI This parameter is the International Mobile Subscriber Identity defined in 3GPP TS 23.003 [17]. 7.6.2.2 TMSI This parameter is the Temporary Mobile Subscriber Identity defined in 3GPP TS 23.003 [17]. 7.6.2.3 IMEI This parameter is the International Mobile Equipment Identity defined in 3GPP TS 23.003 [17]. 7.6.2.3a IMEISV This parameter is the International Mobile Equipment Identity and Software Version Number defined in 3GPP TS 23.003 [17]. 7.6.2.4 Previous location area Id This parameter refers to the identity of the location area from which the subscriber has roamed. 7.6.2.5 Stored location area Id This parameter refers to the location area where the subscriber is assumed to be located. 7.6.2.6 Current location area Id This parameter is used to indicate the location area in which the subscriber is currently located. 7.6.2.7 Target location area Id This parameter refers to the location area into which the subscriber intends to roam. 7.6.2.8 Target cell Id This parameter refers to the identity of the cell to which a call has to be handed over. 7.6.2.8A Target RNC Id This parameter refers to the identity of the RNC to which a call has to be relocated. 7.6.2.9 Void 7.6.2.10 Originating entity number This parameter refers to an application layer identification of a system component in terms of its associated ISDN number. 7.6.2.11 MSC number This parameter refers to the ISDN number of an MSC. 7.6.2.12 Target MSC number This parameter refers to the ISDN number of an MSC to which a call has to be handed over. 7.6.2.13 HLR number This parameter refers to the ISDN number of an HLR. 7.6.2.14 VLR number This parameter refers to the ISDN number of a VLR. 7.6.2.15 HLR Id This parameter refers to the identity of an HLR derived from the IMSI defined in CCITT Recommendation E.212. 7.6.2.16 LMSI This parameter refers to a local identity allocated by the VLR to a given subscriber for internal management of data in the VLR. LMSI shall not be sent to the SGSN. 7.6.2.17 MS ISDN This parameter refers to one of the ISDN numbers assigned to a mobile subscriber in accordance with CCITT Recommendation E.213. 7.6.2.17A Additional MSISDN This parameter refers to an ISDN number assigned on top of the existing MSISDN, to a user with a connection to the PS domain (see 3GPP TS 23.003 [17]). If the Additional MSISDN is available its value shall be used as C MSISDN on the Sv interface. 7.6.2.18 OMC Id This parameter refers to the identity of an Operation and Maintenance Centre. 7.6.2.19 Roaming number This parameter refers to the roaming number as defined in CCITT Recommendation E.213. 7.6.2.19A Relocation Number List This parameter refers to the number(s) used for routing one call or several calls between MSCs during relocation. 7.6.2.20 Void 7.6.2.21 Handover number This parameter refers to the number used for routing a call between MSCs during handover. 7.6.2.22 Forwarded-to number This parameter refers to the address to which a call is to be forwarded. A subaddress may be appended. For subscribers having an originating CAMEL Phase 2 or higher subscription, this address need not be in E.164 international format. 7.6.2.22A Long forwarded-to number This parameter refers to the address to which a call is to be forwarded. A subaddress may be appended. For subscribers having an originating CAMEL Phase 2 or higher subscription this address need not be in international format. 7.6.2.22B Long FTN Supported This parameter indicates that the sending entity supports Long Forwarded-to Numbers. 7.6.2.23 Forwarded-to subaddress This parameter refers to the sub-address attached to the address to which a call is to be forwarded. 7.6.2.24 Called number This parameter refers to a called party number as defined in CCITT Recommendation Q.767. 7.6.2.25 Calling number This parameter refers to a calling party number as defined in CCITT Recommendation Q.767. 7.6.2.26 Originally dialled number This parameter refers to the number dialled by the calling party in order to reach a mobile subscriber. 7.6.2.27 Service centre address This parameter represents the address of a Short Message Service Centre. 7.6.2.28 Zone Code This parameter is used to define location areas into which the subscriber is allowed or not allowed to roam (regional subscription). With a complete list of Zone Codes the VLR or the SGSN or MME is able to determine for all its location areas, routing areas or tracking areas whether roaming is allowed or not. 7.6.2.29 MSIsdn-Alert This parameter refers to the MSISDN stored in a Message Waiting Data File in the HLR. It is used to alert the Service Centre when the MS is again attainable. 7.6.2.30 Location Information The VLR indicates in this parameter the location of the served subscriber as defined in 3GPP TS 23.018 [97]. 7.6.2.30a Location Information for GPRS The SGSN indicates in this parameter the location of the served subscriber as defined in 3GPP TS 23.078 [98]. 7.6.2.30b Location Information for EPS The MME (via an IWF) indicates in this parameter the location of the served subscriber. 7.6.2.31 GMSC Address This parameter refers to the E.164 address of a GMSC. 7.6.2.32 VMSC Address This parameter refers to the E.164 address of a VMSC. 7.6.2.33 Group Id This parameter is used to describe groups a subscriber can be a member of. A subscriber can partake in all group calls (VBS/VGCS) where he subscribed to the respective groups. 7.6.2.34 North American Equal Access preferred Carrier Id This parameter refers to the carrier identity preferred by the subscriber for calls requiring routing via an inter-exchange carrier. This identity is used at: - outgoing calls: when the subscriber does not specify at call set-up a carrier identity; - forwarded calls: when a call is forwarded by the subscriber; - incoming calls: applicable to the roaming leg of the call. 7.6.2.35 Void 7.6.2.36 Void 7.6.2.37 Serving cell Id This parameter indicates the cell currently being used by the served subscriber. 7.6.2.38 SGSN number This parameter refers to the ISDN number of a SGSN. 7.6.2.39 SGSN address This parameter refers to the IP-address of a SGSN. This parameter is defined in 3GPP TS 23.003 [17]. 7.6.2.40 GGSN address This parameter refers to the IP-address of a GGSN. This parameter is defined in 3GPP TS 23.003 [17]. 7.6.2.41 GGSN number This parameter refers to the ISDN number of a GGSN or the ISDN number of the protocol-converter if a protocol converting GSN is used between the GGSN and the HLR. 7.6.2.42 APN This parameter refers to the DNS name of a GGSN. This parameter is defined in 3GPP TS 23.060 [104]. 7.6.2.43 Network Node number This parameter refers to the ISDN number of an MT-SMS target node (MSC or MME, SGSN, or IP-SM-GW) or of an SMS Router. 7.6.2.43A Network Node Diameter Address This parameter refers to the Diameter Name and Realm of the same MT-SMS target node or SMS Router of which the ISDN number is within the Network Node number parameter. 7.6.2.44 PDP-Type This parameter indicates which type of protocol is used by the MS as defined in 3GPP TS 23.060 [104]. The allowed values are one of IPv4 encoded as HEX (21) or IPv6 encoded as HEX (57), or Non-IP encoded as HEX (02). NOTE: To indicate both IPv4 and IPv6 PDP types are allowed, but not IPv4v6, two PDP contexts need to be present in the subscription for the same APN, one indicating IPv4 PDP type and one indicating IPv6 PDP type. 7.6.2.44A Extension PDP-Type This parameter indicates the support of the dual-stack PDP-type (IPv4v6) encoded as HEX (8D) by a certain PDP, as defined in 3GPP TS 23.060 [104], and it is an extension to PDP-Type. 7.6.2.45 PDP-Address This parameter indicates the address of the data protocol as defined in 3GPP TS 23.060 [104]. 7.6.2.45A Extension PDP-Address This parameter indicates an additional address of the data protocol, and it is included when the PDP supports dual-stack (IPv4v6). It is an extension to PDP-Address and it is encoded in the same way. IPv4 or IPv6 address types can be used in this parameter but, when both parameters are present, each of them shall contain different address types. 7.6.2.46 Additional number This parameter refers to the ISDN number of an additional MT-SMS target node (MSC or MME or SGSN) or of an SMS Router. 7.6.2.46A Additional Network Node Diameter Address This parameter refers to an additional Diameter Name and Realm of the same MT-SMS target node or SMS Router of which the ISDN number is within the Additional number parameter. 7.6.2.46B Third Number This parameter refers to the ISDN number of a third MT-SMS target node (MSC or MME or SGSN). 7.6.2.46C Third Network Node Diameter Address This parameter refers to the third Diameter Name and Realm of the same MT-SMS target node of which the ISDN number is within the Third number parameter. 7.6.2.47 P-TMSI This parameter is the Packet Temporary Mobile Subscriber Identity defined in 3GPP TS 23.003 [17]. 7.6.2.48 B-subscriber number This parameter refers to the number of the destination B dialled by the A user. This may include a subaddress. 7.6.2.49 B-subscriber subaddress This parameter refers to the sub-address attached to the destination B dialled by the A user. 7.6.2.50 LMU Number This parameter refers to a local number assigned to an LMU by an SMLC. 7.6.2.51 MLC Number This parameter refers to the ISDN (E.164) number of an MLC. 7.6.2.52 Multicall Bearer Information This parameter refers to the number of simultaneous bearers supported per user by the serving network. 7.6.2.53 Multiple Bearer Requested This parameter indicates whether multiple bearers are requested for a relocation. 7.6.2.54 Multiple Bearer Not Supported This parameter indicates whether multiple bearers are supported. 7.6.2.55 PDP-Charging Characteristics This parameter indicates the charging characteristics associated with a specific PDP context as defined in 3GPP TSÊ32.215. 7.6.2.56 Selected RAB ID The selected radio access bearer to be kept at subsequent inter-MSC handover from UMTS to GSM. 7.6.2.57 RAB ID This parameter indicates the radio access bearer identifier as defined in 3GPP TS 25.413. This parameter is used to relate the radio resources with the radio access bearers. 7.6.2.58 gsmSCF Address This parameter refers to the ISDN number assigned to the gsmSCF address. In an IP Multimedia Core Network, the gsmSCF-address shall contain the IM-SSF address when the IM-SSF takes the role of the gsmSCF. 7.6.2.59 V-GMLC Address This parameter refers to the IP address of a V-GMLC. 7.6.2.60 Void 7.6.2.61 H-GMLC Address This parameter refers to the IP address of a H-GMLC. 7.6.2.62 PPR Address This parameter refers to the IP address of a Privacy Profile Register. 7.6.2.63 Routeing Number This parameter refers to a number used for routeing purpose and identifying a network operator. See 3GPP TS 23.066 [108]. 7.6.2.64 Additional V-GMLC Address This parameter refers to the IP address of a V-GMLC. 7.6.2.65 MME Name This parameter refers to the Diameter Identity of an MME as defined in 3GPP TS 23.003 [17]. 7.6.2.66 3GPP AAA Server Name This parameter refers to the Diameter Identity of a 3GPP AAA server as defined in 3GPP TS 29.273 [151]. 7.6.2.67 CSS number This parameter refers to the ISDN number of a CSS as defined in 3GPP TS 23.003[17]. 7.6.2.68 SGSN Name This parameter refers to the Diameter Identity of an SGSN as defined in 3GPP TS 23.003 [17]. 7.6.2.69 SGSN Realm This parameter refers to the Diameter Identity of an SGSN as defined in 3GPP TS 23.003 [17]. 7.6.3 Subscriber management parameters 7.6.3.1 Category This parameter refers to the calling party category as defined in CCITT Recommendation Q.767. 7.6.3.2 Equipment status This parameter refers to the status of the mobile equipment as defined in 3GPP TS 22.016 [7]. 7.6.3.2a BMUEF This parameter refers to the Bit Map of UE Faults and corresponds to the UESBI-Iu parameter defined in 3GPP TS 25.413 [120]. 7.6.3.3 Extensible Bearer service This parameter may refer to a single bearer service, a set of bearer services or to all bearer services as defined in 3GPP TS 22.002 [3]. This parameter is used only for subscriber profile management. Extensible Bearer service values include all values defined for a Bearer service parameter (7.6.4.38). 7.6.3.4 Extensible Teleservice This parameter may refer to a single teleservice, a set of teleservices or to all teleservices as defined in 3GPP TS 22.003 [4]. This parameter is used only for subscriber profile management. Extensible Teleservice values include all values defined for a Teleservice parameter (7.6.4.39). 7.6.3.5 Extensible Basic Service Group This parameter refers to the Basic Service Group either as an extensible bearer service (see clause 7.6.3.3) or an extensible teleservice (see clause 7.6.3.4). This parameter is used only for subscriber profile management. The null value (i.e. neither extensible bearer service nor extensible teleservice) is used to denote the group containing all extensible bearer services and all extensible teleservices. 7.6.3.6 GSM bearer capability This parameter refers to the GSM bearer capability information element defined in 3GPP TS 24.008 [35]. 7.6.3.7 Subscriber Status This parameter refers to the barring status of the subscriber: - service granted; - Operator Determined Barring. 7.6.3.8 CUG Outgoing Access indicator This parameter represents the Outgoing Access as defined in ETSÊ300Ê136. 7.6.3.9 Operator Determined Barring General Data This parameter refers to the set of subscriber features that the network operator or the service provider can regulate. This set only includes those limitations that can be a) controlled in the VLR, b) controlled in the SGSN or MME, c) controlled in the SGSN applied for short message transfer only, d) interrogated or modified by the gsmSCF: ODB category Controlled in the VLR Controlled in the SGSN or MME Controlled in the SGSN applied for short message transfer only Interrogatable and modifyable by the gsmSCF All outgoing calls barred X X X International outgoing calls barred X X X International outgoing calls except those to the home PLMN country barred X X X Interzonal outgoing calls barred X X X Interzonal outgoing calls except those to the home PLMN country barred X X X Interzonal outgoing calls AND international outgoing calls except those directed to the home PLMN country barred X X X Premium rate (information) outgoing calls barred X X Premium rate (entertainment) outgoing calls barred X X Supplementary service access barred X X Invocation of call transfer barred X X Invocation of chargeable call transfer barred X X Invocation of internationally chargeable call transfer barred X X Invocation of interzonally chargeable call transfer barred X X Invocation of call transfer where both legs are chargeable barred X X Invocation of call transfer if there is already an ongoing transferred call for the served subscriber in the serving MSC/VLR barred X X All packet Oriented Services barred X X Roamer Access to HPLMN-AP barred X X Roamer Access to VPLMN-AP barred X X Outgoing calls when roaming outside the home PLMN country X All incoming calls X Incoming calls when roaming outside the home PLMN country X Incoming calls when roaming outside the zone of the home PLMN country X Roaming outside the home PLMN X Roaming outside the home PLMN country X Registration of any call forwarded-to number X Registration of any international call forwarded-to number X Registration of any international call forwarded-to number except to a number within the HPLMN country X Registration of any inter-zone call forwarded-to number X Registration of any inter-zone call forwarded-to number except to a number within the HPLMN country X 7.6.3.10 ODB HPLMN Specific Data This parameter refers to the set of subscriber features that the network operator or the service provider can regulate only when the subscriber is registered in the HPLMN. This set only includes those limitations that can be controlled in the VLR or in the SGSN or MME: - Operator Determined Barring Type 1; - Operator Determined Barring Type 2; - Operator Determined Barring Type 3; - Operator Determined Barring Type 4. 7.6.3.11 Regional Subscription Data This parameter defines the regional subscription area in which the subscriber is allowed to roam. It consists of a list of Zone Codes (see clause 7.6.2.28). 7.6.3.12 Regional Subscription Response This parameter indicates either that the regional subscription data cannot be handled or that the current MSC or SGSN or MME area is entirely restricted because of regional subscription. 7.6.3.13 Roaming Restriction Due To Unsupported Feature This parameter defines that a subscriber is not allowed to roam in the current MSC area. It may be used by the HLR if a feature or service is indicated as unsupported by the VLR. 7.6.3.14 Extensible SS-Info This parameter refers to all the information related to a supplementary service and is a choice between: - extensible forwarding information (see clauseÊ7.6.3.15); - extensible call barring information (see clauseÊ7.6.3.20); - CUG info (see clauseÊ7.6.3.22); - extensible SS-Data (see clauseÊ7.6.3.29). 7.6.3.15 Extensible forwarding information This parameter represents the information related to each call forwarding service: - the SS-Code of the relevant call forwarding service (see clause 7.6.4.1); - if required, a list of extensible forwarding feature parameters (see clause 7.6.3.16). The list may contain one item per Basic Service Group. 7.6.3.16 Extensible forwarding feature This parameter applies to each combination of call forwarding service and Basic Service Group and contains the following information, as required: - extensible Basic Service Group (see clause 7.6.3.5); - extensible SS-Status (see clause 7.6.3.17); - forwarded-to number (see clause 7.6.2.22); - forwarded-to subaddress (see clause 7.6.2.23); - extensible forwarding options (see clause 7.6.3.18); - extensible no reply condition timer (see clause 7.6.4.19); - long forwarded-to number (see clause 7.6.2.22A). If a number is required to define the forwarded-to destination then: - If the VLR supports Long Forwarded-to Numbers then the long forwarded-to number shall be present and the forwarded-to number shall be absent; - If the VLR does not support Long Forwarded-to Numbers then the forwarded-to number shall be present and the long forwarded-to number shall be absent. 7.6.3.17 Extensible SS-Status This parameter refers to the state information of individual supplementary services as defined in 3GPP TS 23.011 [22]. 7.6.3.18 Extensible Forwarding Options This parameter refers to a set of forwarding options attached to a supplementary service. It contains the following information: - notification to forwarding party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - redirection notification to the forwarded-to party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - notification to calling party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - redirecting presentation (see 3GPP TS 22.082 [10] for the meaning of this parameter); - forwarding reason (see 3GPP TS 22.082 [10] for the meaning of this parameter). 7.6.3.19 Extensible No reply condition timer This parameter refers to the extensible no reply condition timer for call forwarding on no reply. 7.6.3.20 Extensible Call barring information This parameter contains for each call barring service: - SS-Code (see clauseÊ7.6.4.1); - a list of extensible call barring feature parameters (see clauseÊ7.6.3.21)."
"The list may contain one item per Basic Service Group. 7.6.3.21 Extensible Call barring feature This parameter gives the status of call barring services as applicable to each Basic Service Group. The parameter contains the following information: - Extensible Basic Service Group (see clauseÊ7.6.3.5); - provisioned SS-Status (see clauseÊ7.6.3.17). 7.6.3.22 CUG info This parameter refers to the overall information required for operation for each CUG: - CUG subscriptionList; - CUG featureList. 7.6.3.23 CUG subscription This parameter refers to the set of basic information for each CUG defined in that subscription. The following information is stored: - CUG index; - CUG interlock; - Intra CUG restrictions; - Basic Service Group List. 7.6.3.24 CUG interlock This parameter represents the CUG interlock code defined in ETS 300 138. 7.6.3.25 CUG index This parameter represents the CUG index defined in ETS 300 138. 7.6.3.26 CUG feature This parameter contains two parameters that are associated with the Basic Service Group. If the Basic Service Group Code is not present the feature applies to all Basic Services. The following parameters are included: - Preferential CUG indicator: - indicates which CUG index is to be used at outgoing call set-up using the associated Basic Service Group; - Inter CUG Option: - describes whether it for the associated Basic Service Group is allowed to make calls outside the CUG and whether incoming calls are allowed; - Basic Service Group. See 3GPP TS 22.085 [13] for meaning of this parameter. 7.6.3.27 Inter CUG options This parameter indicates the subscribers' ability to make and receive calls outside a specific closed user group. It takes any of the following values: - CUG only facility (only calls within CUG are allowed); - CUG with outgoing access (calls outside CUG allowed); - CUG with incoming access (calls from outside CUG into CUG allowed); - CUG with both incoming and outgoing access (all calls allowed). 7.6.3.28 Intra CUG restrictions This parameter describes whether or not the subscriber is allowed to originate calls to or to receive calls from within the CUG. It can take any of the following values: - no CUG restrictions; - CUG incoming calls barred; - CUG outgoing calls barred. 7.6.3.29 Extensible SS-Data This parameter refers to the necessary set of information required in order to characterise one supplementary service: - SS-Code (see clause 7.6.4.1); - Extensible SS-Status (if applicable) (see clause 7.6.3.17); - Extensible Override subscription option (if applicable) (see clause 7.6.3.30); - Extensible CLI Restriction (if applicable) (see clause 7.6.3.31); - Extensible Basic Service Group Code (see clause 7.6.3.5). 7.6.3.30 Subscriber State This parameter indicates the state of the MS as defined in 3GPP TS 23.018 [97]. 7.6.3.31 Requested Info This parameter indicates the subscriber information being requested as defined in 3GPP TSÊ23.018Ê[97] and 3GPP TSÊ23.078Ê[98]. 7.6.3.31A Requested Domain This parameter indicates the domain (circuit switched, i.e. from the MSC/VLR, or packet switched, i.e. from the SGSN) from which the requested information should be retrieved. 7.6.3.32 Suppression of Announcement This parameter indicates if the announcement or tones shall be suppressed as defined in 3GPP TS 23.078Ê[98]. 7.6.3.33 Suppress T-CSI This parameter is used to suppress the invocation of terminating CAMEL services. 7.6.3.34 GMSC CAMEL Subscription Info This parameter contains CAMEL subscription information, i.e. O-CSI and/or D-CSI and/or T-CSI, which indicates to the GMSC that originating and/or terminating CAMEL services shall be invoked for the incoming call. 7.6.3.35 VLR CAMEL Subscription Info This parameter identifies the subscriber as having CAMEL services that are invoked in the MSC or VLR. 7.6.3.36 Supported CAMEL Phases in the VLR This parameter indicates which phases of CAMEL are supported in the VLR. 7.6.3.36A Supported CAMEL Phases in the SGSN This parameter indicates which phases of CAMEL are supported in the SGSN. 7.6.3.36B Offered CAMEL4 CSIs in the VLR This parameter indicates which CSIs of CAMEL phase 4 are offered in the VLR as defined in 3GPP TS 23.078. 7.6.3.36C Offered CAMEL4 CSIs in the SGSN This parameter indicates which CSIs of CAMEL phase 4 are offered in the SGSN as defined in 3GPP TS 23.078. 7.6.3.36D Offered CAMEL4 CSIs This parameter indicates which CSIs of CAMEL phase 4 are offered as defined in 3GPP TS 23.078. 7.6.3.36E Offered CAMEL4 CSIs in interrogating node This parameter indicates which CSIs of CAMEL phase 4 are offered in the GMSC or in the gsmSCF as defined in 3GPP TS 23.078. 7.6.3.36F Offered CAMEL4 CSIs in VMSC This parameter indicates which CSIs of CAMEL phase 4 are offered in the VMSC as defined in 3GPP TS 23.078. 7.6.3.36G Offered CAMEL4 Functionalities 7.6.3.36H Supported CAMEL Phases This parameter indicates which phases of CAMEL are supported as defined in 3GPP TS 23.078. 7.6.3.36I Supported CAMEL Phases in interrogating node This parameter indicates which phases of CAMEL are supported as defined in 3GPP TS 23.078. The interrogating node may be a GMSC or a gsmSCF. This parameter indicates which functionalities of CAMEL phase 4 are offered as defined in 3GPP TS 23.078. 7.6.3.37 CUG Subscription Flag This parameter indicates that a subscriber with a T-CSI also has a CUG subscription. It is defined in 3GPP TS 23.078. 7.6.3.38 CAMEL Subscription Info Withdraw This parameter indicates that CAMEL Subscription Info shall be deleted from the VLR or SGSN. 7.6.3.39 Voice Group Call Service (VGCS) Data This parameter refers to one or more groups a subscriber may be a member of for voice group calls. 7.6.3.40 Voice Broadcast Service (VBS) Data This parameter refers to one or more groups a subscriber may be a member of for the voice broadcast service. Per group it is further indicated whether the subscriber is only allowed to listen to respective group calls or whether he is in addition entitled to initiate respective voice broadcast calls. 7.6.3.41 ISDN bearer capability This parameter refers to the ISDN bearer capability information element defined in 3GPP TS 29.007 [56]. 7.6.3.42 Lower layer Compatibility This parameter refers to the lower layer compatibility information element defined in 3GPP TS 24.008 [35]. 7.6.3.43 High Layer Compatibility This parameter refers to the high layer compatibility information element defined in 3GPP TS 24.008 [35]. 7.6.3.44 Alerting Pattern This parameter is an indication that can be used by the MS to alert the user in a specific manner in case of mobile terminating traffic (switched call or USSD). That indication can be an alerting level or an alerting category. 7.6.3.45 GPRS Subscription Data Withdraw This parameter indicates that GPRS Subscription Data shall be deleted from the SGSN. 7.6.3.45A EPS Subscription Data Withdraw This parameter indicates that EPS Subscription Data shall be deleted from the MME. 7.6.3.46 GPRS Subscription Data This parameter refers to the list of PDP-Contexts the subscriber has subscribed to. 7.6.3.46A EPS Subscription Data This parameter refers to the list of APN-Configurations the subscriber has subscribed to. 7.6.3.47 QoS-Subscribed This parameter indicates the quality of service subscribed for a certain service. It is defined in 3GPP TS 23.060 [104]. 7.6.3.48 VPLMN address allowed This parameter specifies whether the MS is allowed to use a dynamic address allocated in the VPLMN. It is defined in 3GPP TS 23.060 [104]. 7.6.3.49 Roaming Restricted In SGSN/MME Due To Unsupported Feature This parameter defines that a subscriber is not allowed to roam in the current SGSN or MME area. It may be used by the HLR if a feature or service is indicated as unsupported by the SGSN or MME. 7.6.3.50 Network Access Mode This parameter is defined in 3GPP TS 23.008 [20]. 7.6.3.51 Mobile Not Reachable Reason This parameter stores the reason for the MS being absent when an attempt to deliver a short message to an MS fails at the MSC, SGSN or both. It is defined in 3GPP TS 23.040. 7.6.3.52 Cancellation Type This parameter indicates the reason of location cancellation. It is defined in 3GPP TS 23.060 [104]. The HLR shall not send Cancel Location with a Cancellation Type of ""initialAttachProcedure"" to the SGSN unless the SGSN has indicated support of this cancellation type within UpdateGprsLocation or the HLR has enough knowledge that the SGSN supports ""initialAttachProcedure"". If the HLR needs to send a cancellation type of ""initialAttachProcedure"" but cannot do so due to non-support by the SGSN, the HLR shall send Cancel Location with a Cancellation Type of ""updateProcedure"" and delete the stored SGSN-Number. 7.6.3.53 All GPRS Data This parameter indicates to the SGSN that all GPRS Subscription Data shall be deleted for the subscriber. 7.6.3.54 Complete Data List Included This parameter indicates to the SGSN or MME that the complete GPRS Subscription Data/EPS Subscription Data stored for the Subscriber shall be replaced with the GPRS Subscription Data/EPS Subscription Data received. 7.6.3.55 PDP Context Identifier This parameter is used to identify a PDP context for the subscriber. 7.6.3.56 LSA Information This parameter refers to one or more localised service areas a subscriber may be a member of, together with the priority, the preferential access indicator, the active mode support indicator and active mode indication of each localised service area. The access right outside these localised service areas is also indicated. 7.6.3.57 SoLSA support indicator This parameter indicates that the VLR or the SGSN supports SoLSA subscription. 7.6.3.58 LSA Information Withdraw This parameter indicates that LSA information shall be deleted from the VLR or the SGSN. 7.6.3.59 LMU Indicator This parameter indicates the presence of an LMU. 7.6.3.60 LCS Information This parameter defines the LCS related information for an MS subscriber and contains the following components: - GMLC List (see clause 7.6.3.61). - LCS Privacy Exception List (see clause 7.6.3.62). - MO-LR List (see clause 7.6.3.65A). - Additional LCS Privacy Exception List (see clause 7.6.3.62A). 7.6.3.61 GMLC List This parameter contains the addresses of all GMLCs that are permitted to issue a call/session unrelated or call/session related MT-LR location request for this MS. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.62 LCS Privacy Exception List This parameter defines the classes of LCS Client that are allowed to locate any target MS. For each class, the following information is provided: - SS-Code (see clauseÊ7.6.4.1); - a list of LCS privacy exception parameters (see clauseÊ7.6.3.63). 7.6.3.62A Additional LCS Privacy Exception List This parameter defines the classes of LCS Client that are allowed to locate any target MS. For each class, the following information is provided: - SS-Code (see clauseÊ7.6.4.1); - a list of LCS privacy exception parameters (see clauseÊ7.6.3.63). The Additional LCS Privacy Exception List shall be present only if the LCS Privacy Exception List is present and contains LCS privacy exception parameters for 4 privacy exception classes. 7.6.3.63 LCS Privacy Exception Parameters This parameter gives the status of each LCS privacy exception class and any additional parameters relevant to this class. The parameter contains the following information: - provisioned SS-Status (see clauseÊ7.6.3.17); - privacy notification to MS user (see clause 7.6.3.65B); - external client List (see clauseÊ7.6.3.64); - internal client List (see clause 7.6.3.65). - service type List (see clauseÊ7.6.3.65D); 7.6.3.64 External Client List This parameter is only applicable to the call/session unrelated privacy class and call/session related privacy class, and gives the identities of the external clients that are allowed to locate a target MS for a MT-LR. Each identity is an international (e.g.E.164) address. For each identified external client, GMLC restrictions may be defined. It may also be indicated if the MS shall be notified of a non-restricted MT-LR from each identified LCS client and, if so, whether notification only or notification with privacy verification shall apply. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.65 Internal Client List This parameter is only applicable to the PLMN operator privacy class and gives the identities of the internal PLMN operator clients that are allowed to locate a target MS for an NI-LR or MT-LR. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.65A MO-LR List This parameter defines the classes of MO-LR for which a subscription exists for a particular MS. For each class, the following information is provided: - SS-Code (see clauseÊ7.6.4.1). 7.6.3.65B Privacy Notification to MS User This parameter is applicable to the call/session unrelated privacy class and call/session related privacy class. For non-call/call related privacy class it indicates whether the MS user shall be notified for that class MT-LR from any value added LCS client when the MT-LR is restricted and be enabled to accept or override the restriction. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.65C GMLC List Withdraw This parameter indicates whether the subscriber's LCS GMLC list shall be deleted from the VLR or SGSN. 7.6.3.65D Service Type List This parameter is only applicable to the Service type privacy class and gives the identities of the service type of the clients that are allowed to locate a target MS for an MT-LR. Usage of this parameter is defined in 3GPP TS 23.271. 7.6.3.66 IST Alert Timer This parameter indicates the IST Alert Timer value that must be used in the MSC to inform the HLR about the call activities that the subscriber performs. Units are minutes. 7.6.3.67 Call Termination Indicator This parameter indicates whether the MSC shall terminate a specific ongoing call, or all the call activities related to a specified subscriber. 7.6.3.68 IST Information Withdraw This parameter indicates that IST information shall be deleted from the VMSC. 7.6.3.69 IST Support Indicator This parameter indicates the degree of IST functionality supported by the MSC (Visited MSC or Gateway MSC). It can take one of the following values: - Basic IST functionality; - IST command service (in addition to the basic IST functionality and including the ability to terminate all calls being carried for the identified subscriber). 7.6.3.70 Super-Charger Supported In HLR This parameter is used by the HLR to indicate support of the Super-Charger functionality and an indication of the age of the subscription data stored in the HLR. 7.6.3.71 Super-Charger Supported In Serving Network Entity This parameter is used to indicate support of the Super-Charger functionality by the originating entity and to indicate either that subscription data is required or the date and time of the last know subscriber data modification. 7.6.3.72 Age Indicator This parameter is used by the HLR to determine the validity of the subscription data retained by the serving network entity in a Super-Charged network. 7.6.3.73 GPRS enhancements support indicator This parameter indicates to the HLR that the SGSN supports GPRS enhancements. 7.6.3.74 Extension QoS-Subscribed This parameter indicates the enhanced QoS subscribed for a certain service. It is defined in 3GPP TS 23.060. This parameter is an extension to QoS-Subscribed. 7.6.3.75 SGSN CAMEL Subscription Info This parameter identifies the subscriber as having CAMEL services that are invoked in the SGSN. 7.6.3.75A Extension-2 QoS-Subscribed This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used when the maximum bit rate exceeds 8640 kbps. For more details, refer to 3GPP TS 24.008Ê[35]. 7.6.3.75B Extension-3 QoS-Subscribed This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used when the maximum/guaranteed bit rate for uplink exceeds 8640 kbps. For more details, refer to 3GPP TS 24.008Ê[35]. 7.6.3.75C Extension-4 QoS-Subscribed This parameter indicates the additional QoS information to the Extension QoS-subscribed parameter. It is a further extension to Extension QoS-Subscribed. This parameter shall be used to define the Evolved Allocation/Retention Priority parameter, which includes the Priority Level, the Preemption Capability value and the Preemption vulnerability value, as described in 3GPP TS 29.060 [105]. 7.6.3.76 MO-SMS-CSI This parameter identifies the subscriber as having mobile originating SMS CAMEL services as defined in 3GPP TS 23.078. For the CAMEL phase 3 the MO-SMS-CSI is the same as the SMS-CSI. 7.6.3.76a MT-SMS-CSI This parameter identifies the subscriber as having mobile terminating SMS CAMEL services as defined in 3GPP TS 23.078. 7.6.3.77 GPRS-CSI This parameter identifies the subscriber as having GPRS CAMEL services as defined in 3GPP TS 23.078. 7.6.3.78 CAMEL subscription info This parameter indicates the CSI that can be controlled by CSE. 7.6.3.79 Extensible Call barring information for CSE This parameter contains for each call barring service for CSE: - SS-Code; - a list of extensible call barring feature parameters. The list may contain one item per Basic Service Group. - password; - wrong password attempt counter; - notification-to-CSE flag. 7.6.3.80 Extensible Forwarding information for CSE This parameter represents the information for CSE related to each call forwarding service: - the SS-Code of the relevant call forwarding service; - if required, a list of extensible forwarding feature parameters; - the list may contain one item per Basic Service Group; - notification-to-CSE flag. 7.6.3.81 Modification Request for CSI This parameter indicates the CAMEL subscription information to be modified by CSE. 7.6.3.81a Modification Request for ODB data This parameter indicates the operator determined barring data to be modified by CSE. 7.6.3.82 Modification Request for SS Information This parameter indicates the call forwarding, call barring, call hold, call waiting, explicit call transfer, calling line identification presentation and calling line identification restriction supplementary service data to be modified by CSE. 7.6.3.83 Call Barring Data This parameter contains the extensible call barring feature list (see clauseÊ7.6.3.21) and Notification to CSE flag. 7.6.3.84 Call Forwarding Data This parameter contains the extensible call forwarding feature list (see clause 7.6.3.16) and Notification to CSE flag. 7.6.3.85 ODB Data This parameter contains the ODB general data, ODB HPLMN specific data. 7.6.3.86 Requested Subscription Info This parameter indicates the subscription information being requested. 7.6.3.87 CS Allocation/Retention priority This parameter indicates the allocation/retention priority for Circuit Switched (CS). It corresponds to the allocation/retention priority that is defined in 3GPPÊTSÊ23.107Ê[154]. 7.6.3.88 ODB Info This parameter contains the ODB data and Notification to CSE flag. 7.6.3.89 Suppress VT-CSI This parameter is used to suppress the invocation of terminating CAMEL services at the VMSC. 7.6.3.90 Suppress Incoming Call Barring This parameter is used to suppress the invocation of Incoming Call Barrings. 7.6.3.91 gsmSCF Initiated Call This parameter is used to indicate that the call was initiated by the gsmSCF. 7.6.3.91a SuppressMTSS This parameter is used to suppress the invocation of terminating supplementary services 7.6.3.92 Call barring support indicator This parameter is used to indicate that the SGSN supports the call barring services for SMS. 7.6.3.93 MNP Info Result This parameter refers to the Mobile Number Portability (MNP) information result (see 3GPP TSÊ23.078Ê[98] and 3GPP TS 23.066 [108]). This parameter may contain the following information: - Routeing Number (see clause 7.6.2.63). - IMSI (see 3GPP TS 23.078[98], see also clause 7.6.2.1). - MSISDN (see clause 7.6.2.17). - Number Portability Status (see clause 7.6.5.14). 7.6.3.94 Allowed Services This parameter is used by the HLR to indicate which service is available for a call when two services have been requested, for the SCUDIF feature described in 3GPP TS 23.172 [126]. 7.6.3.95 Unavailability Cause This parameter is used to indicate the reason for the unavailability of one of the services as indicated by the Allowed Services IE (see 7.6.3.94) when two services have been requested, for the SCUDIF feature described in 3GPP TS 23.172 [126]. 7.6.3.96 MNP Requested Info This parameter indicates by its presence that Mobile Number Portability (MNP) information is requested for the subscriber, as defined in 3GPP TSÊ23.078Ê[98]. 7.6.3.97 Access Restriction Data This parameter refers to the radio access technologies that are possibly restricted to a subscriber via subscription data. For the use of the parameter, see 3GPP TS 23.012 [23] for the CS domain and 3GPP TS 23.060[104], 3GPP TS 29.060 [105] clause 7.5.3 and 3GPP TS 29.274 [149] clause 7.3.6 for the PS domain. 7.6.3.98 Supported RAT types indicator This parameter indicates which RAT types are supported/served by the MSC/VLR or SGSN or MME 7.6.3.99 UE SRVCC Capability This parameter indicates, if present, the support of SRVCC capability by the UE. 7.6.3.100 Temporary Empty CSG Subscription data Indicator This parameter indicates that the CSS has currently no CSG subscription data for this roaming user but registers the VLR or SGSN, so to inform them if later changes in CSG subscription data occur. 7.6.3.101 WLAN-offloadability This parameter refers to the WLAN offloadability for E-UTRAN or UTRAN. This parameter is defined in 3GPP TS 29.272 [144]. 7.6.3.102 IMSI-Group-Id This parameter refers to the IMSI-Group identifier. This parameter is defined in 3GPP TS 29.272 [144]. 7.6.4 Supplementary services parameters 7.6.4.1 SS-Code This parameter may refer to one supplementary service or a set of supplementary services as defined in 3GPP TS 22.004. For MAP this includes: - Calling Line Identification Presentation service (CLIP); - Calling Line Identification Restriction service (CLIR); - Connected Line Identification Presentation service (COLP); - Connected Line Identification Restriction service (COLR); - Calling Name Presentation (CNAP); - All Call Forwarding services, including Call Deflection; - Call Waiting (CW); - Call Hold (HOLD); - Multi-Party service (MPTY); - Closed User Group (CUG); - All Charging services; - All Call Restriction services; - Explicit Call Transfer service (ECT); - enhanced Multi-Level Precedence and Pre-emption service (eMLPP); - Completion of Calls to Busy Subscriber, originating side (CCBS-A); - Completion of Calls to Busy Subscriber, destination side (CCBS-B); - All LCS privacy exceptions (see clauseÊ7.6.4.44); - Mobile Originating Location Request (MO-LR) (see clause 7.6.4.45); - Multicall (MC). 7.6.4.1A SS-Code 2 This parameter is used to refer to one or a set of supplementary services (as 7.6.4.1 ""SS-Code"") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]). 7.6.4.2 SS-Status This parameter refers to the state information of individual supplementary services as defined in 3GPP TS 23.011. 7.6.4.3 SS-Data This parameter refers to the necessary set of information required in order to characterise one supplementary service: - SS-Code (see clause 7.6.4.1); - SS-Status (if applicable) (see clause 7.6.4.2); - Override subscription option (see clause 7.6.4.4); - CLI Restriction (see clause 7.6.4.5); - Basic Service Group Code (see clause 7.6.4.40). 7.6.4.4 Override Category This parameter refers to the subscription option Override Category attached to a supplementary service. It can take the following two values: - Enabled; - Disabled. 7.6.4.5 CLI Restriction Option This parameter refers to the subscription option Restriction mode attached to the CLIR supplementary service. It can take the following three values: - Permanent; - Temporary (Default Restricted); - Temporary (Default Allowed). 7.6.4.6 Forwarding Options This parameter refers to a forwarding option attached to a supplementary service. It can take one of the following values: - notification to forwarding party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - notification to calling party (see 3GPP TS 22.082 [10] for the meaning of this parameter); - redirecting presentation (see 3GPP TS 22.082 [10] for the meaning of this parameter); - Forwarding reason (see 3GPP TS 22.082 [10] for the meaning of this parameter). 7.6.4.7 No reply condition timer This parameter refers to the no reply condition timer for call forwarding on no reply. 7.6.4.8 - 7.6.4.14 Void 7.6.4.15 Forwarding information This parameter represents the information related to each call forwarding service: - the SS-Code of the relevant call forwarding service (see clause 7.6.4.1); - if required, a list of forwarding feature parameters (see clause 7.6.4.16). the list may contain one item per Basic Service Group. 7.6.4.16 Forwarding feature This parameter applies to each combination of call forwarding service and Basic Service Group and contains the following information, as required: - Basic Service Group (see clause 7.6.4.40); - SS-Status (see clause 7.6.4.2); - forwarded-to number (see clause 7.6.2.22); - forwarded-to subaddress (see clause 7.6.2.23); - forwarding options (see clause 7.6.4.6); - no reply condition timer (see clause 7.6.4.7); - long forwarded-to number (see clause 7.6.2.22A). If a number is required to define the forwarded-to destination then: - If the VLR supports Long Forwarded-to Numbers then the long forwarded-to number shall be present and the forwarded-to number shall be absent. - If the VLR does not support Long Forwarded-to Numbers then the forwarded-to number shall be present and the long forwarded-to number shall be absent. 7.6.4.17 Void 7.6.4.18 Call barring information This parameter contains for each call barring service: - SS-Code (see clauseÊ7.6.4.1); - a list of call barring feature parameters (see clauseÊ7.6.4.19). The list may contain one item per Basic Service Group. 7.6.4.19 Call barring feature This parameter gives the status of call barring services as applicable to each Basic Service Group. The parameter contains the following information: - Basic Service Group (see clauseÊ7.6.4.40); - SS-Status (see clauseÊ7.6.4.2). 7.6.4.20 New password This parameter refers to the password which the subscriber just registered in the network. This parameter refers to a password used by the subscriber for supplementary service control. 7.6.4.21 Current password This parameter refers to a password used by the subscriber for supplementary service control. 7.6.4.22 Guidance information This parameter refers to guidance information given to a subscriber who is requested to provide a password. One of the following information may be given: - ""enter password""; this information is used for checking of the old password; - ""enter new password""; this information is used during password registration for the request of the first new password; - ""enter new password again""; this information is used during password registration for the request of the new password again for verification. 7.6.4.23 Void 7.6.4.24 SS-Info This parameter refers to all the information related to a supplementary service and is a choice between: - forwarding information (see clauseÊ7.6.4.15); - call barring information (see clauseÊ7.6.4.18); - CUG info (see clauseÊ7.6.4.8); - SS-Data (see clauseÊ7.6.4.3). - eMLPP information (see clause 7.6.4.41). 7.6.4.25 - 7.6.4.35 Void 7.6.4.36 USSD Data Coding Scheme This parameter contains the information of the alphabet and the language used for the unstructured information in an Unstructured Supplementary Service Data operation. The coding of this parameter is according to the Cell Broadcast Data Coding Scheme as specified in 3GPP TS 23.038 [25]. 7.6.4.37 USSD String This parameter contains a string of unstructured information in an Unstructured Supplementary Service Data operation. The string is sent either by the mobile user or the network. The contents of a string sent by the MS are interpreted by the network as specified in 3GPP TS 22.090 [16]. 7.6.4.38 Bearer service This parameter may refer to a single bearer service, a set of bearer services or to all bearer services as defined in 3GPP TS 22.002 [3]. This parameter is used only for supplementary service management. 7,6,4.38A Bearer Service 2 This parameter is used to indicate the bearer service or set of bearer services (as 7.6.4.38 ""Bearer service"") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]). 7.6.4.39 Teleservice This parameter may refer to a single teleservice, a set of teleservices or to all teleservices as defined in 3GPP TS 22.003 [4]. This parameter is used only for supplementary service management. 7.6.4.39A Teleservice 2 This parameter is used to indicate the teleservice or set of teleservices (as 7.6.4.39 ""Teleservice"") related to Network Signal Info 2 for SCUDIF calls (see 3GPP TS 23.172 [126]). 7.6.4.40 Basic Service Group This parameter refers to the Basic Service Group either as a bearer service (see clause 7.6.4.38) or a teleservice (see clause 7.6.4.39). This parameter is used only for supplementary service management. The null value (i.e. neither bearer service nor teleservice) is used to denote the group containing all bearer services and all teleservices. 7.6.4.41 eMLPP information This parameter contains two parameters which are associated with the eMLPP service. The following two parameters are included: - maximum entitled priority: - indicates the highest priority level the subscriber is allowed to apply for an outgoing call set-up; - default priority: - defines the priority level which shall be assigned to a call if no explicit priority is indicated during call set-up. 7.6.4.42 SS-event This parameter indicates the Supplementary Service for which an invocation notification is sent towards the gsmSCF. It can indicate one of the following services: - Explicit Call Transfer (ECT) - Call Deflection (CD) - Multi-Party call (MPTY) - Completion of Calls to Busy Subscriber (CCBS) 7.6.4.43 SS-event data This parameter contains additional information related to Supplementary Service invocation. Depending on the service invoked it can contain the following information: ECT A list with all Called Party Numbers involved. CD The called Party number involved. 7.6.4.44 LCS Privacy Exceptions Distinct SS codes are assigned to the following classes of LCS client in a target MS subscriber's privacy exception list. - Universal Class; - Call/session related value added class; - Call/session unrelated value added class; - PLMN operator class. - Service type class. 7.6.4.45 Mobile Originating Location Request (MO-LR) Distinct SS codes are assigned to the following classes of MO-LR: - Basic Self Location; - Autonomous Self Location; - Transfer to Third Party. 7.6.4.46 NbrUser This parameter indicates the maximum number of parallel bearers that may be used as defined by the user at registration of the MC SS. 7.6.4.47 MC Subscription Data This parameter contains two parameters which are associated with the MC service. The following two parameters are included: - NbrUser: indicates the maximum number of parallel bearers that may be used as defined by the user at registration of the MC SS - NbrSB: indicates the maximum number of parallel bearers that may be used as defined by the user's subscription. 7.6.4.48 MC Information This parameter contains three parameters which are associated with the MC service. The following parameters are included: - NbrSB; - NbrUser; - NbrSN. Definitions of these parameters are provided in 3GPP TS 23.135. 7.6.4.49 CCBS Request State This parameter indicates the current state of the CCBS request. It can take one of seven values: - request; - recall; - active; - completed; - suspended; - frozen; - deleted. 7.6.4.50 Basic Service Group 2 This parameter refers to the Basic Service Group either as a bearer service (see clause 7.6.4.38) or a teleservice (see clause 7.6.4.39). This parameter is used only for supplementary service management. 7.6.5 Call parameters 7.6.5.1 Call reference number This parameter refers to a call reference number allocated by a call control MSC. 7.6.5.2 Interrogation type This parameter refers to the type of interrogation for routing information which is sent from a GMSC to an HLR. It can take either of two values: - basic call (for information to route a call before the call has been extended to the VMSC of the called party); - forwarding (for information to route the call to the forwarded-to destination after the VMSC of the forwarding party has requested the GMSC to resume handling of the call. 7.6.5.3 OR interrogation This parameter indicates that the GMSC which interrogated the HLR for routeing information is not in the same PLMN as the HLR, and therefore that the call will potentially be optimally routed. 7.6.5.4 OR capability This parameter indicates the phase of OR which the GMSC supports. 7.6.5.5 Forwarding reason This parameter indicates the reason for which the call is to be forwarded. It can take one of three values: - busy subscriber; - mobile subscriber not reachable; - no subscriber reply. 7.6.5.6 Forwarding interrogation required This parameter indicates that if the VMSC of the forwarding subscriber requests the GMSC to resume handling of the call the GMSC shall interrogate the HLR for forwarding information. 7.6.5.7 O-CSI This parameter identifies the subscriber as having originating CAMEL services as defined in 3GPP TS 23.078. 7.6.5.7A D-CSI This parameter identifies the subscriber as having originating CAMEL dialled services as defined in 3GPP TS 23.078. 7.6.5.7B T-CSI This parameter identifies the subscriber as having terminating CAMEL services in the GMSC, as defined in 3GPP TSÊ23.078. 7.6.5.7C VT-CSI This parameter identifies the subscriber as having terminating CAMEL services in the VMSC, as defined in 3GPPÊTSÊ23.078. 7.6.5.7D O-IM-CSI This parameter identifies the subscriber as having originating IP Multimedia Core Network CAMEL services as defined in 3GPP TS 23.278. 7.6.5.7E D-IM-CSI This parameter identifies the subscriber as having originating IP Multimedia Core Network CAMEL dialled services as defined in 3GPP TS 23.278. 7.6.5.7F VT-IM-CSI This parameter identifies the subscriber as having terminating IP Multimedia Core Network CAMEL services as defined in 3GPPÊTSÊ23.278. 7.6.5.8 Void 7.6.5.9 Void 7.6.5.10 Void 7.6.5.11 CCBS Feature This parameter corresponds to the 'CCBS Description' parameter in 3GPP TS 23.093. It refers to the necessary set of information required in order to characterise a certain CCBS request. The parameter may contain the following information: - CCBS Index (see 3GPP TS 23.093 for the use of this parameter); - B-subscriber number (see clause 7.6.2.48); - B-subscriber subaddress (see clause 7.6.2.49); - Basic Service Group Code (see clause 7.6.4.40). 7.6.5.12 UU Data This parameter includes User-To-User Data. It is defined in 3GPP TS 23.087. 7.6.5.13 UUS CF Interaction This parameter indicates if the call forwarding or call deflection has been activated after UUS1 request has been accepted . It is defined in 3GPP TS 23.087. 7.6.5.14 Number Portability Status This parameter indicates the number portability status of subscriber. See 3GPP TS 23.066 [108]. 7.6.5.15 Pre-paging supported This parameter indicates that the entity which sent it supports pre-paging. 7.6.5.16 MT Roaming Retry Supported The parameter indicates that the entity which sent it supports MT Roaming Retry. When sent by the HLR, it further indicates that the GMSC also supports MT Roaming Retry. 7.6.5.17 MT Roaming Retry The parameter indicates that the GMSC receiving the IE shall start MT roaming retry (see 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]). 7.6.5.18 Paging Area The parameter indicates the paging area where the MS is currently located (see 3GPP TS 23.012 [23] and 3GPP TS 23.018 [97]). 7.6.5.19 Call Priority The parameter indicates the eMLPP priority of the call (see 3GPP TS 23.067 [136]). 7.6.5.20 MTRF Supported The parameter indicates that the entity which sends it supports MT Roaming Forwarding. 7.6.5.21 LCLS Global Call Reference (LCLS GCR) This parameter refers to a globally unique call identifier for the duration of the call (see 3GPP TS 29.205 [146]). This parameter is used to identify a call and to correlate the call legs of a call to determine if the call is a local call within the BSS. 7.6.5.22 LCLS-Negotiation This parameter is used to request MSC-B to indicate LCLS, see 3GPP TS 29.205 [146] clause B.2.1.4 LCLS Negotiation Request. 7.6.5.23 LCLS-Configuration-Preference This parameter contains information to indicate the negotiated LCLS configuration preference, see 3GPP TS 29.205 [146] clause B.2.1.10 LCLS Configuration Preference. 7.6.6 Radio parameters 7.6.6.1 - 7.6.6.3 Void 7.6.6.4 GERAN Classmark This information element is sent from one MSC to the other MSC in the signalling for inter MSC handover. It is used to convey information related to cell capabilities, as defined in 3GPP TS 48.008. 7.6.6.5 BSSMAP Service Handover This parameter refers to the Service Handover information element defined in 3GPP TS 48.008 7.6.6.5A BSSMAP Service Handover List This parameter refers to the list of Service Handover information elements defined in 3GPP TS 48.008. This parameter shall be used when there are multiple bearers and at least one of the bearers has an associated BSSMAP Service Handover parameter. 7.6.6.6 RANAP Service Handover This parameter refers to the Service Handover information element defined in 3GPP TS 25.413. 7.6.6.7 HO-Number Not Required This parameter indicates that no handover or relocation number allocation is necessary. 7.6.6.8 Integrity Protection Information This parameter refers to the Integrity Protection Information element defined in 3GPP TS 25.413. 7.6.6.9 Encryption Information This parameter refers to the Encryption Information element defined in 3GPP TS 25.413. 7.6.6.10 Radio Resource Information This parameter refers to the Channel Type information element defined in 3GPP TS 48.008 [49]. 7.6.6.10A Radio Resource List This parameter refers to list of RAB-id's and their associated Channel Type information elements defined in 3GPP TS 48.008. This parameter shall be used when there are multiple bearers and at least one of the bearers has an associated Radio Resource Information parameter. 7.6.6.10B Chosen Radio Resource Information This parameter refers to the Chosen Channel and Speech Version information elements defined in 3GPP TS 48.008. 7.6.6.11 Key Status This parameter refers to the Key Status element defined in 3GPP TS 25.413. 7.6.6.12 Selected UMTS Algorithms This parameters identifies the UMTS integrity and optionally encryption algorithms selected by MSC-B. Coding of this parameter is defined in 3GPP TS 25.413. 7.6.6.13 Allowed GSM Algorithms This parameters identifies the allowed GSM algorithms in MSC-B. Coding of this parameter is defined in 3GPP TS 48.008. 7.6.6.14 Allowed UMTS Algorithms This parameters identifies the allowed UMTS algorithms in MSC-B. Coding of this parameter is defined in 3GPP TS 25.413. 7.6.6.15 Selected GSM Algorithm This parameter identifies the GSM algorithm selected by GSM BSC controlled by MSC-B. Coding of this parameter is defined in 3GPP TS 48.008. 7.6.6.16 Iu-Currently Used Codec This parameter indicates the codec used at the Iu interface before handover. 7.6.6.17 Iu-Supported Codecs List This parameter indicates the codecs supported by the UE and by MSC-A and the associated modes in priority order (the first entry being the highest priority codec). MSC-B uses this information to select the associated transcoder resources. 7.6.6.17A Iu-Available Codecs List This parameter indicates the codecs available at the Iu interface in MSC-B and the associated modes."
"MSC-A uses this information to decide whether a change to a different codec at the Iu interface is possible. 7.6.6.18 Iu-Selected Codec When sent by MSC-B, this parameter indicates the codec selected by MSC-B for the Iu interface. When sent by MSC-A, this parameter indicates the codec to be used by MSC-B at the Iu interface. 7.6.6.19 RAB Configuration Indicator This parameter indicates by its presence that MSC-A (or MSC-B in case of subsequent handover) has generated the RAB parameters according to the preferred codec (first entry in the Iu-Supported Codecs List). 7.6.6.20 UESBI-Iu This parameter refers to the UESBI-Iu (UE Specific Behaviour Information over the Iu interface) information element defined in 3GPP TS 25.413. 7.6.6.21 Alternative Channel Type This parameter refers to the Channel Type information element defined in 3GPP TS 48.008 [49] for the alternative radio access bearer. This parameter is used for SCUDIF calls (see 3GPP TS 23.172 [126]). 7.6.6.22 AoIP-Supported Codecs List Anchor This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Supported Codecs List (Anchor) in 3GPP TS 23.009 [21]. 7.6.6.23 AoIP-Available Codecs List Map This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Available Codecs List (Map) in 3GPP TS 23.009 [21]. 7.6.6.24 AoIP-Selected Codec Target This parameter is used for inter-MSC handover with AoIP access and the procedures and contents of the parameter are as defined in AoIP-Selected Codec (Target) in 3GPP TS 23.009 [21]. 7.6.7 Authentication parameters 7.6.7.1 Authentication set list This parameter represents a list of sets of authentication parameters for a given subscriber. The list either contains Authentication Triplets (Rand, Sres, Kc) or Authentication Quintuplets (Rand, Xres, Ck, Ik, Autn). If the list contains Authentication Quintuplets, the order of sequence in this list is chronological, the first quintuplet in the list is the oldest one. 7.6.7.2 Rand This parameter represents a random number used for authentication. 7.6.7.3 Sres This parameter represents the response to an authentication request. 7.6.7.4 Kc This parameter refers to a key used for ciphering purposes. 7.6.7.5 Xres This parameter represents the response to an UMTS authentication request. 7.6.7.5A Ck This parameter refers to a key used for UMTS ciphering purposes. 7.6.7.5B Ik This parameter refers to the Integrity Key. 7.6.7.5C Autn This parameter refers to the Authentication Token. 7.6.7.5D KASME This parameter refers to the Key for the Access Security Management Entity. 7.6.7.6 Cksn This parameter refers to a ciphering key sequence number. 7.6.7.6A Ksi This parameter refers to a key set identifier. 7.6.7.6B Auts This parameter refers to the resynchronisation token. 7.6.7.7 Ciphering mode This parameter refers to the ciphering mode which is associated with a radio channel. It may take values as follows: - no encryption; - identification of specific ciphering algorithm. 7.6.7.8 Current Security Context This parameter represents a list of security context parameters for a given subscriber. The list either contains GSM Security Context data (Kc, Cksn) or UMTS Security Context Data (Ck, Ik, Ksi). 7.6.7.9 Failure cause This parameter refers to an authentication failure which has occurred. It may take values as follows: - wrong user response; - wrong network signature. 7.6.7.10 Re-attempt It indicates whether the failure ocurred in a normal authentication attempt or in an authentication reattempt (there was a previous unsuccessful authentication). 7.6.7.11 Access Type It indicates whether the authentication procedure was initiated due to a call, an emergency call, a location updating, a supplementary service procedure, a short message transfer, a GPRS attach procedure, a routing area updating, a service request, a MS initiated Detach in GPRS, a PDP context activation or a PDP context deactivation procedure. 7.6.8 Short message parameters 7.6.8.1 SM-RP-DA This parameter represents the destination address used by the short message service relay sub-layer protocol. It can be either of the following: - IMSI (see clauseÊ7.6.2.1); - LMSI (see clauseÊ7.6.2.16); - MS-ISDN (see clauseÊ7.6.2.17); - roaming number (see clauseÊ7.6.2.19); - service centre address (see clauseÊ7.6.2.27). 7.6.8.2 SM-RP-OA This parameter refers to the originating address used by the short message service relay sub-layer protocol. It can be either of the following: - MS-ISDN (see clauseÊ7.6.2.17); - service centre address (see clauseÊ7.6.2.27). 7.6.8.3 MWD status This parameter indicates whether or not the address of the originator service centre is already contained in the Message Waiting Data file. In addition, it contains the status of the Memory Capacity Exceeded Flag (MCEF), the status of the Mobile subscriber Not Reachable Flag (MNRF), the status of the Mobile station Not Reachable for GPRS flag (MNRG), the status of the Mobile station Not Reachable for 5G-3GPP access flag (MNR5G) and the status of the Mobile station Not Reachable for 5G-Non-3GPP access flag (MNR5GN3G). 7.6.8.4 SM-RP-UI This parameter represents the user data field carried by the short message service relay sub-layer protocol. 7.6.8.5 SM-RP-PRI This parameter is used to indicate whether or not delivery of the short message shall be attempted when a service centre address is already contained in the Message Waiting Data file. 7.6.8.6 SM Delivery Outcome This parameter indicates the cause for setting the message waiting data. It can take one of the following values: - Absent subscriber; - MS memory capacity exceeded; - Successful transfer. 7.6.8.7 More Messages To Send This parameter is used to indicate whether or not the service centre has more short messages to send. 7.6.8.8 Alert Reason This parameter is used to indicate the reason why the service centre is alerted. It can take one of the following values: - MS present; - Memory Available. 7.6.8.9 Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent. For the values for this parameter see 3GPP TS 23.040. 7.6.8.10 Alert Reason Indicator This parameter indicates that the alert reason is sent to the HLR due to GPRS activity. 7.6.8.10A Additional Alert Reason Indicator This parameter indicates that the alert reason is sent to the HLR due to IMS activity. 7.6.8.11 Additional SM Delivery Outcome This parameter is used to indicate the GPRS delivery outcome in case a combination between delivery outcome for GPRS and non-GPRS are sent to the HLR. 7.6.8.12 Additional Absent Subscriber Diagnostic SM This parameter indicates the reason of the additional SM Delivery Outcome. 7.6.8.13 Delivery Outcome Indicator This parameter indicates that the delivery outcome sent to the HLR is for GPRS. 7.6.8.14 GPRS Node Indicator This parameter indicates by its presence that the Network Node Number sent by the HLR, SMS-Router or IP-SM-GW is to be considered as the SGSN number (although it may actually be an SMS-Router Number or IP-SM-GW Number). 7.6.8.14A IMS Node Indicator This parameter indicates by its presence that the Network Node Number sent by the HLR is an IP-SM-GW number. 7.6.8.15 GPRS Support Indicator This parameter indicates that the SMS-GMSC supports GPRS specific procedure of combine delivery of Short Message via MSC and/or via the SGSN. 7.6.8.16 SM-RP-MTI This parameter represents the RP-Message Type Indicator of the Short Message. It is used to distinguish a SM sent to the mobile station in order to acknowledge an MO-SM initiated by the mobile from a normal MT-SM. This parameter is formatted according to the formatting rules of address fields as described in 3GPP TS 23.040. 7.6.8.17 SM-RP-SMEA This parameter represents the RP-Originating SME-address of the Short Message Entity that has originated the SM. This parameter is used by the short message service relay sub-layer protocol and is formatted according to the formatting rules of address fields as described in 3GPP TS 23.040. 7.6.8.18 IP-SM-GW SM Delivery Outcome This parameter is used to indicate the delivery outcome for the IMS domain. 7.6.8.19 IP-SM-GW Absent Subscriber Diagnostic SM This parameter indicates the reason of the IP-SM-GW SM Delivery Outcome. 7.6.8.20 IP-SM-GW Indicator This parameter indicates by its presence that sm-deliveryOutcome is for delivery via IMS. 7.6.8.21 SM Delivery Timer This parameter indicates the SM Delivery Timer value set in the SMS-GMSC to the IP-SM-GW, SGSN or MSC/VLR. It may be taken into account by the domain selection procedure in the IP-SM-GW. Units are in seconds. 7.6.8.22 SM Delivery Start Time This parameter indicates the timestamp (in UTC) at which the SM Delivery Supervision Timer was started in the SMS-GMSC. 7.6.8.23 Maximum Retransmission Time This parameter indicates the maximum retransmission time (in UTC) until which the SMS-GMSC is capable to retransmit the MT Short Message. 7.6.8.24 Requested Retransmission Time This parameter indicates the retransmission time (in UTC) at which the SMS-GMSC is requested to retransmit the MT Short Message. 7.6.8.25 Maximum UE Availability Time This parameter indicates the timestamp (in UTC) until which a UE using a power saving mechanism (such as extended idle mode DRX) is expected to be reachable for SM Delivery. This information may be used by the SMS Center to prioritize the retransmission of Short Message to UEs using a power saving mechanism. 7.6.8.26 SMS-GMSC Alert Event This parameter indicates the event that causes the MME (via an IWF) or the SGSN to alert the SMS-GMSC for retransmitting an MT Short Message. 7.6.8.27 SMS-GMSC Address This parameter contains the E.164 number of the SMS-GMSC or SMS Router, in international number format as described in ITU-T Recommendation E.164 [67]. 7.6.8.28 SMS-GMSC Diameter Address This parameter contains the Diameter Identity of the SMS-GMSC or SMS Router. 7.6.8.29 New SGSN Number This parameter contains the E.164 number of the new SGSN serving the MS. 7.6.8.30 New MME Number This parameter contains the E.164 number of the new MME serving the MS. 7.6.8.31 New SGSN Diameter Address This parameter contains the Diameter Identity of the new SGSN serving the MS. 7.6.8.32 New MME Diameter Address This parameter contains the Diameter Identity of the new MME serving the MS. 7.6.8.33 New MSC Number This parameter contains the E.164 number of the new MSC serving the MS. 7.6.8.34 SMSF 3GPP Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent for 5G 3GPP access. For the values for this parameter see 3GPP TS 23.040. 7.6.8.35 SMSF Non 3GPP Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent for 5G Non 3GPP access. For the values for this parameter see 3GPP TS 23.040. 7.6.8.36 SMSF 3GPP Delivery Outcome Indicator This parameter indicates that the delivery outcome IE is associated to the SM delivery via the SMSF for 3GPP access. 7.6.8.37 SMSF Non-3GPP Delivery Outcome Indicator This parameter indicates that the delivery outcome IE is associated to the SM delivery via the SMSF for Non-3GPP access. 7.6.8.38 SMSF 3GPP SM Delivery Outcome This parameter is used to indicate the delivery outcome at the SMSF for 3GPP access. 7.6.8.39 SMSF Non-3GPP SM Delivery Outcome This parameter is used to indicate the delivery outcome at the SMSF for non-3GPP access. 7.6.8.40 SMSF 3GPP Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent for 5G 3GPP access. For the values for this parameter see 3GPP TS 23.040. 7.6.8.41 SMSF Non 3GPP Absent Subscriber Diagnostic SM This parameter is used to indicate the reason why the subscriber is absent for 5G Non 3GPP access. For the values for this parameter see 3GPP TS 23.040. 7.6.9 Access and signalling system related parameters 7.6.9.1 AN-apdu This parameter includes one or two concatenated complete 3GPP TS 25.413 or 3GPP TS 48.006 [48] messages, as described in 3GPP TSÊ23.009 and 3GPP TSÊ29.010. The access network protocol ID indicates that the message or messages are according to either 3GPP TS 48.006 [48] or 3GPP TSÊ25.413. For the coding of the messages see 3GPP TSÊ25.413, 3GPP TS 48.006 [48] and 3GPP TS 48.008 [49]. 7.6.9.2 CM service type This parameter identifies the service category being requested by the subscriber: - mobile originating call; - emergency call establishment; - short message service; - mobile originating call re-establishment; - mobile terminating call; - SS request; - Voice group call set-up; - Voice broadcast set-up. 7.6.9.3 Access connection status This parameter represents the following access connection status information: - RR-connection status (established/not established); - ciphering mode (on/off); - authentication status (authenticated/not authenticated). 7.6.9.4 External Signal Information This parameter contains concatenated information elements (including tag and length) which are defined by a common protocol version, preceded by the associated protocol ID. It is used to transport information of the indicated protocol via MAP interfaces. 7.6.9.5 Access signalling information This parameter refers to any set of information elements imported from 3GPP TS 24.008 [35]. 7.6.9.6 Location update type This parameter refers to the location update type (normal, periodic or IMSI attach) contained in the 3GPP TS 24.008 [35] LOCATION REGISTRATION REQUEST message. 7.6.9.7 Protocol ID This parameter refers to the protocol to which the coding of the content of the associated External Signal Information conforms. The following values are defined: - 04.08; - 08.06; - ETSÊ300Ê102-1. This value indicates the protocol defined by ETSÊ300Ê102-1 (EDSS1). 7.6.9.8 Network signal information This parameter is transported as external signal information. The protocol ID shall be set to ""ETSÊ300Ê102-1"". The network signal information may include the following information elements as defined in 3GPP TS 29.007 [56]: - ISDN BC; the tag and length are defined by ETSÊ300Ê102-1. For the content, see 3GPP TS 29.007 [56]. - HLC; the tag and length are defined by ETSÊ300Ê102-1. For the content, see 3GPP TS 29.007 [56]. - LLC; the tag and length are defined by ETSÊ300Ê102-1. For the content, see 3GPP TS 29.007 [56]. They are contained in the Signal Information parameter according to figureÊ7.6/1 (irrespective of the order): FigureÊ7.6/1: Network signal information parameter 7.6.9.8A Network signal information 2 This parameter is transported as additional external signal information for SCUDIF calls, described in 3GPP TS 23.172 [126]. The protocol ID and possibly included information elements are identical to Network Signal Information, defined in 7.6.9.8, ""Network signal information"". 7.6.9.9 Call Info This parameter is transported as external signal information. The protocol ID shall be set to ""3GPP TS 24.008 [35]"". The Call Info includes the set of information elements from the original SETUP message and is imported from 3GPP TS 24.008 [35]. 7.6.9.10 Additional signal info This parameter is transported as external signal information. The protocol ID shall be set to ""ETSÊ300Ê356"". The additional signal information may include the following information elements: - Calling Party Number as defined by ETSÊ300Ê356. - Generic Number as defined by ETSÊ300Ê356. They are contained in the Signal Information parameter according to figureÊ7.6/2 (irrespective of the order): FigureÊ7.6/2: Additional signal information parameter 7.6.10 System operations parameters 7.6.10.1 Network resources This parameter refers to a class or type of network resource: - PLMN; - HLR; - VLR (current or previous); - MSC (controlling or current); - EIR; - radio sub-system. 7.6.10.2 Trace reference This parameter represents a reference associated with a GSM only tracing request as defined in 3GPP TS 52.008 [61]. The parameter is managed by OMC/EM. 7.6.10.2A Trace reference 2 This parameter represents a reference associated with a tracing request as defined in 3GPP TS 32.421 [131] and 3GPP TS 32.422 [132]. The parameter is managed by EM. 7.6.10.3 Trace type This parameter identifies the type of trace for GSM only tracing request. Trace types are fully defined in 3GPP TSÊ52.008 [61]. If the activation of the tracing is requested only for UMTS, then this parameter shall contain value ""No MSC Trace"" for MSC Record Type and value ""No BSS Trace"" for BSS Record Type. 7.6.10.4 Additional network resources This parameter refers to a class or type of network resource: - SGSN; - GGSN; - GMLC; - gsmSCF; - NPLR; - AuC. 7.6.10.5 Trace depth list This parameter identifies the list of depths of trace per network element. See 3GPP TS 32.422 [132]. 7.6.10.6 Trace NE type list This parameter identifies the list of network elements to be traced. See 3GPP TS 32.422 [132]. 7.6.10.7 Trace interface list This parameter identifies the list of interfaces or protocols per network element to be traced. See 3GPP TS 32.422 [132]. 7.6.10.8 Trace event list This parameter identifies the list of events per network element, which trigger a Trace Recording Session. See 3GPP TS 32.422 [132]. 7.6.10.9 Trace support indicator This parameter indicates that UMTS trace parameters are supported in the VLR or in the SGSN. 7.6.10.10 Trace Propagation List This parameter indicates UMTS trace propagation parameters sent from one MSC to the other MSC in the signalling for inter MSC handover/relocation. See 3GPP TS 32.422 [132]. 7.6.10.11 MDT-Configuration This parameter contains Minimization of Drive Test Configuration Data as defined in 3GPP TS 32.422 [132]. 7.6.10.12 MDT User Consent This parameter contains an indicator whether user consent for MDT activation is available or not as defined in 3GPP TS 32.422 [132]. 7.6.11 Location Service Parameters 7.6.11.1 Age of Location Estimate This parameter indicates how long ago the location estimate was obtained. 7.6.11.2 Deferred MT-LR Response Indicator This parameter shows that this is a response to a deferred mt-lr request. 7.6.11.3 Deferred MT-LR Data This parameter is used to report the deferred location event type, the location information and reason why the serving node aborted monitoring the event to the GMLC. The termination cause mt-lrRestart shall be used to trigger the GMLC to restart the location procedure in all the cases where the sending node detects that the location procedure cannot be successfully performed anymore by the sending node and that it could be successfully performed by another node (as for example when. Cancel Location or Send Identification has been received). The location information shall be included only if the termination cause is mt-lrRestart. The network node number contained in the location information refers to the node where the MS/UE has moved to and shall be included if available, like in case Send Identification has been received. 7.6.11.4 LCS Client ID This parameter provides information related to the identity of an LCS client. 7.6.11.5 LCS Event This parameter identifies an event associated with the triggering of a location estimate. 7.6.11.6 Void 7.6.11.7 LCS Priority This parameter gives the priority of the location request. 7.6.11.8 LCS QoS This parameter defines the Quality of Service (QoS) for any location request. It is composed of the following elements. 1) Response Time Indicates the category of response time Ð ""low delay"" or ""delay tolerant"". 2) Horizontal Accuracy Indicates the required horizontal accuracy of the location estimate. 3) Vertical Coordinate Indicates if a vertical coordinate is required (in addition to horizontal coordinates). 4) Vertical Accuracy Indicates the required vertical accuracy of the location estimate (inclusion is optional). 5) Velocity Request Indicates that velocity should be returned if available (inclusion is optional). 7.6.11.9 CS LCS Not Supported by UE This parameter is used by the VLR to indicate to the HLR that the UE does not support neither UE Based nor UE Assisted positioning metheds for Circuit Switched Location Services. VLR defines the presence of this parameter on the basis of the Classmark 3 information. 7.6.11.10 PS LCS Not Supported by UE This parameter is used by the SGSN to indicate to the HLR that the UE does not support neither UE Based nor UE Assisted positioning metheds for Packet Switched Location Services. SGSN defines the presence of this parameter on the basis of the UE capability information and the access technology supported by the SGSN. 7.6.11.11 Location Estimate This parameter gives an estimate of the location of an MS in universal coordinates and the accuracy of the estimate. The estimate is expressed in terms of the geographical shapes defined by 3GPP TS 23.032. and is composed of the type of shape plus the encoding of the shape itself. Any type of shape defined in 3GPP TS 23.032 can be filled in in the Location Estimate parameter, but only the encoding of the following shapes shall be carried by Location Estimate: - Ellipsoid point with uncertainty circle - Ellipsoid point with uncertainty ellipse - Ellipsoid point with altitude and uncertainty ellipsoid - Ellipsoid arc - Ellipsoid point The encoding for the remaining types of shape, defined in the 3GPP TS 23.032, shall be filled in in the Additional Location Estimate parameter. 7.6.11.11A GERAN Positioning Data This parameter provides positioning data associated with a successful or unsuccessful location attempt for a target MS described in 3GPP TS 49.031 [59a]. 7.6.11.11B UTRAN Positioning Data This parameter provides positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120]. It contains the positioningDataDiscriminator and positioningDataSet parts of the RANAP PositionData element only. 7.6.11.11C GERAN GANSS Positioning Data This parameter provides GANSS positioning data associated with a successful or unsuccessful location attempt for a target MS as described in 3GPP TS 49.031 [59a] if GANSS has been used. 7.6.11.11D UTRAN GANSS Positioning Data This parameter provides GANSS positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120] if GANSS has been used. It contains the GANSS-PositioningDataSet part of the RANAP PositionData element only. 7.6.11.11E UTRAN Additional Positioning Data This parameter provides additional positioning data associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120] if Additional Positioning has been used. It contains the Additional-PositioningDataSet part of the RANAP PositionData element only. 7.6.11.11F UTRAN Barometric Pressure Measurement This parameter provides barometric pressure measurement associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120]. 7.6.11.11G UTRAN Civic Address This parameter provides civic address associated with a successful location attempt for a target MS as described in 3GPP TS 25.413 [120]. 7.6.11.12 Location Type This parameter indicates the type of location estimate required by the LCS client. Possible location estimate types include: - current location; - current or last known location; - initial location for an emergency services call; - deferred location event type; - notification verification only. 7.6.11.13 NA-ESRD This parameter only applies to location for an emergency services call in North America and gives the North American Emergency Services Routing Digits. 7.6.11.14 NA-ESRK This parameter only applies to location for an emergency services call in North America and gives the North American Emergency Services Routing Key. 7.6.11.15 LCS Service Type Id This parameter defines the LCS Service Type of the current positioning request. The possible values are defined in 3GPP TS 22.071 [123] 7.6.11.16 Privacy Override This parameter indicates if MS privacy is overridden by the LCS client when the GMLC and VMSC/SGSN for an MT-LR are in the same country. 7.6.11.17 Supported LCS Capability Sets This parameter indicates which capability sets of LCS are supported in the VLR or SGSN. 7.6.11.18 LCS Codeword This parameter contains the codeword associated to current positioning request as described in 3GPP TS 23.271 [26a]. 7.6.11.19 NA-ESRK Request This parameter allows the MSC to indicate that it requires the GMLC to allocate a NA-ESRK based on the target MS location estimate. This parameter only applies to emergency services calls in North America. 7.6.11.20 Supported GAD Shapes This parameter indicates which of the shapes defined in 3GPP TS 23.032 are supported. If the parameter is not provided then the receiving node shall assume that the sending entity supports the following shapes: - Ellipsoid point with uncertainty circle - Ellipsoid point with uncertainty ellipse - Ellipsoid point with altitude and uncertainty ellipsoid - Ellipsoid arc - Ellipsoid point 7.6.11.21 Additional Location Estimate This parameter gives an estimate of the location of an MS/UE in universal coordinates and the accuracy of the estimate. This parameter allows the location estimate to be expressed in any of the geographical shapes defined in 3GPP TS 23.032 7.6.11.22 Cell Id Or SAI For GERAN access, this parameter contains the Global Cell Identifier for the cell that the subscriber is currently attached to. For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to. 7.6.11.23 LCS-Reference Number This parameter represents a reference between a request and a responce of a deferred mt-lr procedure as deccribed in 3GPP TS 23.271 [26a]. 7.6.11.24 LCS Privacy Check This parameter refers to the requested privacy check related actions (call/session unrelated and/or call/session related) from MSC or SGSN provided by H-GMLC. Possible requested actions are: - positioning allowed without notifying the UE user; - positioning allowed with notification to the UE user; - positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user or if there is no response to the notification; - positioning requires notification and verification by the UE user; positioning is allowed only if granted by the UE user; - positioning not allowed. 7.6.11.25 Additional LCS Capability Sets This parameter indicates which capability sets of LCS are supported in the VLR or SGSN. 7.6.11.26 Area Event Info This parameter defines the requested deferred MT-LR area event information. The parameter consists of area definition, type of area event, occurrence info and minimum interval time. 7.6.11.27 Velocity Estimate This parameter gives an estimate of the velocity of an MS and the accuracy of the estimate. The estimate is expressed in terms of speed and bearing as defined by 3GPP TS 23.032 [122], and is composed of the velocity terms plus the encoding of the velocity itself. Only the encoding of the following velocity definitions shall be carried by the Velocity Estimate: - Horizontal Velocity - Horizontal with Vertical Velocity - Horizontal Velocity with Uncertainty - Horizontal with Vertical Velocity and Uncertainty 7.6.11.28 Accuracy Fulfilment Indicator This parameter indicates the fulfilled accuracy of the positioning procedure. For details see 3GPP TS 23.271 [26a]. 7.6.11.29 MO-LR Short Circuit Indicator This parameter indicates whether MO-LR short circuit feature is permitted. For details see 3GPP TS 23.271 [26a]. 7.6.11.30 Reporting PLMN List This parameter provides a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made. For details see 3GPP TS 23.271 [26a]. 7.6.11.31 Periodic LDR information This parameter refers to the periodic reporting interval and reporting amount of the deferred periodic location. For details see 3GPP TS 23.271 [26a]. 7.6.11.32 Sequence Number This parameter refers to the number of the periodic location reports completed. The sequence number would be set to 1 in the first location report and increment by 1 for each new report. When the number reaches the reporting amountÊvalue, the H-GMLC (for a periodic MT-LR or a periodic MO-LR transfer to third party) will know the procedure is complete. For details see 3GPP TS 23.271 [26a]. 7.6.12 Void 7.7 Representation of a list of a basic parameter in service-primitives In some service-primitives several instances of a basic parameter of clauseÊ7.6 are required. In the service descriptions such cases will be represented as ParameterNameLIST in the tables where ParameterName refers to one of the parameters defined in clauseÊ7.6. This corresponds to the following construction rule: FigureÊ7.7/1: Construction of Lists 8 Mobility services 8.1 Location management services 8.1.1 Void 8.1.1.1 Void 8.1.1.2 Void 8.1.1.3 Void 8.1.2 MAP_UPDATE_LOCATION service 8.1.2.1 Definition This service is used by the VLR to update the location information stored in the HLR. This service is also used by an IWF that registers an MME as MSC for MT-SMS. The MAP_UPDATE_LOCATION service is a confirmed service using the service primitives given in tableÊ8.1/2. 8.1.2.2 Service primitives TableÊ8.1/2: MAP_UPDATE_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) MSC Address M M(=) VLR number M M(=) LMSI U C(=) Supported CAMEL Phases C C(=) SoLSA Support Indicator C C(=) IST Support Indicator C C(=) Super-Charger Supported in Serving Network Entity C C(=) Long FTN Supported C C(=) Supported LCS Capability Sets C C(=) Offered CAMEL 4 CSIs C C(=) Inform Previous Network Entity C C(=) CS LCS Not Supported by UE C C(=) V-GMLC Address U C(=) IMEISV C C(=) Skip Subscriber Data Update U C(=) Supported RAT Types Indicator U C(=) Paging Area U C(=) Restoration Indicator U C(=) MTRF Supported U C(=) Equivalent PLMN List C C(=) MSISDN-less Operation Supported C C(=) MME-Diameter-Address-For MT-SMS C C(=) Reset-IDs Supported C C(=) ADD Capability U C(=) Paging Area Capability U C(=) HLR number C C(=) User error C C(=) Provider error O 8.1.2.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. MSC Address See definition for MSC number in clauseÊ7.6.2. The MSC address is used for short message delivery only and for each incoming call set-up attempt the MSRN will be requested from the VLR. VLR number See definition in clauseÊ7.6.2. LMSI See definition in clauseÊ7.6.2. It is an operator option to provide the LMSI from the VLR; it is mandatory for the HLR to support the LMSI handling procedures. Supported CAMEL Phases This parameter indicates which phases of CAMEL are supported. Must be present if a CAMEL phase different from phase 1 is supported. Otherwise may be absent. HLR number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory in case of successful HLR updating. SoLSA Support Indicator This parameter is used by the VLR to indicate to the HLR in the Update Location indication that SoLSA is supported. If this parameter is not included in the Update Location indication and the Subscriber is marked as only allowed to roam in Subscribed LSAs, then the HLR shall reject the roaming and indicate to the VLR that roaming is not allowed to that Subscriber in the VLR. This SoLSA Support Indicator shall be stored by the HLR per VLR where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a VLR and no SoLSA Support indicator is stored for that VLR, the location status of that Subscriber shall be set to Restricted. IST Support Indicator This parameter is used to indicate to the HLR that the VMSC supports basic IST functionality, that is, the VMSC is able to terminate the Subscriber Call Activity that originated the IST Alert when it receives the IST alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Update Location indication and the Subscriber is marked as an IST Subscriber, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Roaming, Incoming or Outgoing calls), or allow service assuming the associated risk of not having the basic IST mechanism available. This parameter can also indicate that the VMSC supports the IST Command service, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Update Location indication and the HLR supports the IST Command capability, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Roaming, Incoming or Outgoing calls), or allow service assuming the associated risk of not having the IST Command mechanism available. Long FTN Supported This parameter indicates that the VLR supports Long Forwarded-to Numbers. Super-Charger Supported in Serving Network Entity This parameter is used by the VLR to indicate to the HLR that the VLR supports the Super-Charger functionality and whether subscription data has been retained by the VLR. If subscription data has been retained by the VLR the age indicator shall be included. Otherwise the VLR shall indicate that subscriber data is required. If this parameter is absent then the VLR does not support the Super-Charger functionality. Supported LCS Capability Sets This parameter indicates, if present, the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the VLR does not support LCS at all. If this parameter is absent then the VLR may support at most LCS capability set 1, that is LCS Release98 or Release99 version. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR (see clause 7.6.3.36D). Inform Previous Network Entity This parameter is used by the VLR to ask the HLR to inform the previous network entity about the update by sending the previous network entity a Cancel Location message. It is used if Super-Charger is supported in the network and either the serving network entity has not been able to inform the previous network entity that MS has moved (i.e. if it has not sent Send Identification to the previous serving entity) or the MTRF Supported flag is set in the MAP_UPDATE LOCATION request. CS LCS Not Supported by UE See definition in clauseÊ7.6.11. V-GMLC address See definition in clauseÊ7.6.2. IMEISV For definition of the parameter see clause 7.6.2. For the use of this parameter see 3GPP TS 23.012. IMEISV shall be present if ADD function is supported and a new IMEISV is to be notified to the HLR (The functional requirements for the presence of IMEISV due to ADD are described in 3GPP TS 22.101 clause 7.4). Skip Subscriber Data Update The presence of the parameter is optional and if present it indicates that the service is solely used to inform the HLR about change of IMEISV or Paging Area. The parameter is used to optimise signalling load during Location Update procedure. Supported RAT Types Indicator This parameter indicates, if present, which access technologies (e.g. GERAN and / or UTRAN) are served by the MSC/VLR (see clause 7.6.3) Paging Area This parameter indicates, if present, the paging area where the MS is currently located (see clause 7.6.5.18) Restoration Indicator This parameter indicates, if present, that the HLR shall send in the MAP-INSERT-SUBSCRIBER-DATA the MME Name if the subscriber is registered to EPS, or the SGSN Number if available and if the subscriber is registered to GPRS. The VLR may set this indicator during a CSFB mobile originated call if the VLR performs an implicit location update (see 3GPP TS 23.272 [143]). MTRF Supported See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. Equivalent PLMN List This parameter indicates the equivalent PLMN list of which the VLR requests the corresponding CSG Subscription data. MSISDN-less Operation Supported See clause 3.6.1.5 of 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. MME-Diameter-Address-For-MT-SMS This parameter may be sent by an IWF that registers an MME for MT-SMS. The MME-Diameter-Address-For-MT-SMS may be stored in the HLR and may be sent in SMS interrogation responses to SMS-GMSCs. Reset-IDs Supported This parameter indicates, if present, the support of Reset-IDs by the MSC. ADD Capability This parameter indicates, if present, the support of ADD function by the HLR. Paging Area Capability This parameter indicates, if present, the support of Paging Area function by the HLR. The HLR shall report the same capability for all subscribers. User error In case of unsuccessful updating, an error cause shall be returned by the HLR. The following error causes defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - unknown subscriber; - roaming not allowed; This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the VLR number. The cause is qualified by the roaming restriction reason ""PLMN Not Allowed"", ""Supported RAT Types Not Allowed"" or ""Operator Determined Barring"". If no qualification is received (HLR with MAP Version 1), ""PLMN Not Allowed"" is taken as default. This cause shall be used when the HLR rejects a MAP Update Location request received for an MSISDN-less subscription from a VLR not supporting MSISDN-less operation (see clause 3.6.1.5 of 3GPP TS 23.012 [23]). - system failure; - unexpected data value. Provider error For definition of provider errors see clauseÊ7.6.1. 8.1.3 MAP_CANCEL_LOCATION service 8.1.3.1 Definition This service is used between HLR and VLR to delete a subscriber record from the VLR. It may be invoked automatically when an MS moves from one VLR area to another, to remove the subscriber record from the old VLR, or by the HLR operator to enforce a location updating from the VLR to the HLR, e.g. on withdrawal of a subscription. Also this service is used between HLR and SGSN to delete a subscriber record from the SGSN. It may be invoked automatically when an MS moves from one SGSN area to another, to remove the subscriber record from the old SGSN, or by the HLR operator to enforce a location updating from the SGSN to the HLR. This service is also used to request the SGSN to indicate to the MS to initiate an immediate re-attach procedure. In an EPS this service is used between HSS and IWF and between IWF and IWF to delete the subscriber record from the MME or SGSN or to release bearer resources without deleting the subscriber record. This service is also used to request the MME or SGSN to indicate to the UE to initiate an immediate re-attach procedure. The MAP_CANCEL_LOCATION service is a confirmed service using the primitives defined in tableÊ8.1/3."
"8.1.3.2 Service primitives TableÊ8.1/3: MAP_CANCEL_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) LMSI C C(=) Cancellation Type C C(=) MTRF Supported And Authorized U C(=) MTRF Supported And Not Authorized U C(=) New MSC Number U C(=) New VLR Number U C(=) New LMSI U C(=) Reattach Required U C(=) User error C C(=) Provider error O 8.1.3.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. LMSI See definition in clauseÊ7.6.2. The LMSI shall be included if it has been received from VLR. LMSI is not applicable between SGSN and HLR. Value 0000 0000 can be used to indicate that the LMSI is not in use. Cancellation Type See definition in clauseÊ7.6.3. The presence of this parameter is mandatory when the Cancel Location is sent to the SGSN or IWF. The parameter may also be sent during an inter-VLR location update If the VLR receives this parameter and does not understand it the VLR shall ignore it and should by default assume an Update procedure. If the SGSN receives this parameter indicating initial attach procedure, the SGSN shall do as specified in 3GPP TS 23.060 [104], and shall not delete the subscription data. MTRF Supported And Authorized See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. MTRF Supported And Not Authorized See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. New MSC Number This parameter refers to the E.164 address of the new VMSC. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported And Authorized flag is present. New VLR Number This parameter contains the new VLR Number. See definition in clauseÊ7.6.2. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported And Authorized flag is present. New LMSI See definition in clauseÊ7.6.2 for LMSI. This parameter shall be present if the MTRF Supported And Authorized flag is present and the HLR has received the LMSI in Update Location from the new VLR. Reattach Required When present and when the Cancellation Type indicates a subscription withdraw, this parameter indicates that the MME (informed via the IWF) or the SGSN shall delete the subscription data and request the UE or MS to initiate an immediate re-attach procedure as described in 3GPP TS 23.401 [145] and in 3GPP TS 23.060 [12]. User error If the cancellation fails, an error cause is to be returned by the VLR or by the SGSN or IWF. One of the following error causes defined in clauseÊ7.6.1 shall be used: - unexpected data value; - data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 8.1.4 MAP_SEND_IDENTIFICATION service 8.1.4.1 Definition The MAP_SEND_IDENTIFICATION service is used between a VLR and a previous VLR to retrieve IMSI and authentication data for a subscriber registering afresh in that VLR. It may also be used to send the MSC number from a VLR to a previous VLR. The MAP_SEND_IDENTIFICATION service is a confirmed service using the service primitives defined in tableÊ8.1/4. 8.1.4.2 Service primitives TableÊ8.1/4: MAP_SEND_IDENTIFICATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) TMSI M M(=) Number of requested vectors M M(=) Segmentation prohibited indicator C C(=) MSC Number U C(=) Previous Location Area Id U C(=) Hop Counter U C (=) MTRF Supported U C(=) VLR Number U C(=) New LMSI U C(=) IMSI C C(=) Authentication set U C(=) Current Security Context U C(=) MT call pending flag U C(=) Last used LTE PLMN ID U C(=) User error C C(=) Provider error O 8.1.4.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. TMSI See definition in clauseÊ7.6.2. If multiple service requests are present in a dialogue then this parameter shall be present in every service request. Number of requested vectors A number indicating how many authentication vectors the new VLR is prepared to receive. The previous VLR shall not return more vectors than indicated by this parameter. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one Segmentation prohibited indicator This parameter indicates if the new VLR or SGSN allows segmentation of the response at MAP user level. This parameter may be present only in the first request of the dialogue. IMSI See definition in clauseÊ7.6.2. The IMSI is to be returned if the service succeeds. If multiple service requests are present in a dialogue and the service succeeds then this parameter shall not be present in any service response other than the first one MSC Number This is the ISDN number assigned to the MSC currently serving the MS. This parameter shall be present if the MTRF Supported flag is present. Previous Location Area Id See definition in clauseÊ7.6.2. Together with the TMSI the Previous Location Area Id can be used to derive the IMSI. Authentication set See definition in clauseÊ7.6.7. If the service succeeds a list of up to five authentication sets is returned, if there are any available. Current Security Context See definition in clause 7.6.7. If the service succeeds, a list of either GSM or UMTS Security Context parameters can be returned. This parameter shall not be included if the Key Status associated to the current security context indicates this is a new keyset that has not been used yet. If this parameter is present in the message, the new VLR shall consider that the keyset has already been used (i.e. the key status is ""old""). MT call pending flag This flag indicates by its presence that there is a Mobile Terminating call pending in the old MSC/VLR. See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. Hop Counter For the use of this parameter see 3GPPÊTSÊ23.012Ê[23]. MTRF Supported See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. VLR Number This is the ISDN number assigned to the VLR currently serving the MS. See definition in clauseÊ7.6.2. The use and conditions of presence of this parameter are specified in 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23]. This parameter shall be present if the MTRF Supported flag is present. New LMSI See definition in clauseÊ7.6.2 for LMSI. This parameter may be present if the MTRF Supported flag is present. Last used LTE PLMN ID See 3GPP TS 23.272 [143] for the use of this parameter and the conditions for its presence. User error This parameter is mandatory if the service fails. The following error cause defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - unidentified subscriber. Provider error For definition of provider errors see clauseÊ7.6.1. 8.1.5 Void 8.1.5.1 Void 8.1.5.2 Void 8.1.5.3 Void 8.1.6 MAP_PURGE_MS service 8.1.6.1 Definition This service is used between the VLR and the HLR to cause the HLR to mark its data for an MS so that any request for routing information for a mobile terminated call or a mobile terminated short message will be treated as if the MS is not reachable. It is invoked when the subscriber record for the MS is to be deleted in the VLR, either by MMI interaction or automatically, e.g. because the MS has been inactive for several days. This service shall not be used if both the VLR and HLR support the Super-Charger functionality. Also this service is used between the SGSN and the HLR to cause the HLR to mark its data for an MS so that any request for routing information for a mobile terminated short message or a network requested PDP-context activation will be treated as if the MS is not reachable. It is invoked when the subscriber record for the MS is to be deleted in the SGSN, either by MMI interaction or automatically, e.g. because the MS has been inactive for several days. This service shall not be used if both the SGSN and HLR support the Super-Charger functionality. In an EPS this service is used between IWF and IWF and between IWF and HSS. The MAP_PURGE_MS service is a confirmed service using the primitives defined in tableÊ8.1/6. 8.1.6.2 Service primitives TableÊ8.1/6: MAP_PURGE_MS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) VLR number C C(=) Freeze TMSI C C(=) Freeze P-TMSI C C(=) Freeze M-TMSI C C(=) SGSN number C C(=) Last known location C C(=) User error C C(=) Provider error O 8.1.6.3 Parameter definitions and use Invoke ID See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. VLR number Shall be present if the sender is VLR. See definition in clauseÊ7.6.2. SGSN number Shall be present if the sender is SGSN. See definition in clause 7.6.2. In an EPS, this parameter may contain the IWF number. Freeze TMSI This parameter is sent to the VLR to indicate that the TMSI has to be frozen. It shall be present if the received VLR number matches the stored VLR number. Freeze P-TMSI This parameter is sent to the SGSN to indicate that the P-TMSI has to be frozen. It shall be present if the received SGSN number matches the stored SGSN number. Freeze M-TMSI This parameter is sent to the IWF to indicate that the M-TMSI has to be frozen. It shall be present if the received node number matches the stored IWF number. Last known location This parameter contains the last known location of the purged UE. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error See definition of provider errors in clauseÊ7.6.1. 8.1.7 MAP_UPDATE_GPRS_LOCATION service 8.1.7.1 Definition This service is used by the SGSN to update the location information stored in the HLR. In an EPS, this service is used between IWF and IWF and between IWF and HSS. The MAP_UPDATE_GPRS_LOCATION service is a confirmed service using the service primitives given in tableÊ8.1/7. 8.1.7.2 Service primitives TableÊ8.1/7: MAP_UPDATE_GPRS_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) SGSN number M M(=) SGSN address M M(=) Supported CAMEL Phases C C(=) SoLSA Support Indicator C C(=) Super-Charger Supported in Serving Network Entity C C(=) GPRS enhancements support indicator C C(=) Supported LCS Capability Sets C C(=) Offered CAMEL 4 CSIs C C(=) Inform Previous Network Entity C C(=) PS LCS Not Supported by UE C C(=) V-GMLC Address U C(=) Call barring support indicator C C(=) IMEISV C C(=) Skip Subscriber Data Update U C(=) Supported RAT Types Indicator U C(=) EPS Info C C(=) Serving Node Type Indicator C C(=) Supported Features U C(=) Used RAT Type U C(=) GPRS Subscription Data not needed Indicator C C(=) EPS Subscription Data Not Needed Indicator C C(=) Node-Type-Indicator U C(=) Area Restricted Indicator C C(=) UE Reachable Indicator C C(=) T-ADS Data Retrieval Support Indicator C C(=) Homogeneous Support Of IMS Voice Over PS Sessions C C(=) Update of Homogeneous Support Of IMS Voice Over PS Sessions C C(=) UE SRVCC Capability C C(=) Equivalent PLMN List C C(=) MME Number for MT SMS C C(=) SMS-Only C C(=) SMS Register Request C C(=) Removal of MME Registration for SMS C C(=) MSISDN-less Operation Supported C C(=) SGSN Name C C(=) SGSN Realm C C(=) Lgd Support Indicator C C(=) Adjacent-PLMNs C C(=) Reset-IDs Supported C C(=) ADD Capability U C(=) SGSN-MME Separation Support Indicator C C(=) HLR number C C(=) MME Registered for SMS C C(=) User error C C(=) Provider error O 8.1.7.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. SGSN number See definition in clauseÊ7.6.2. In an EPS, this parameter is populated with an IWF number if received from an IWF. SGSN address See definition in clauseÊ7.6.2. In an EPS, this parameter is populated with an IWF address if received from an IWF. Supported CAMEL Phases This parameter indicates which phases of CAMEL are supported. The SGSN can only support CAMEL phase 3 or greater. SoLSA Support Indicator This parameter is used by the SGSN to indicate to the HLR in the Update GPRS Location indication that SoLSA is supported. If this parameter is not included in the Update GPRS Location indication and the Subscriber is marked as only allowed to roam in Subscribed LSAs, then the HLR shall reject the roaming and indicate to the SGSN that roaming is not allowed to that Subscriber in the SGSN. This SoLSA Support Indicator shall be stored by the HLR per SGSN where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a SGSN and no SoLSA Support indicator is stored for that SGSN, the location status of that Subscriber has to be set to Restricted. Super-Charger Supported in Serving Network Entity This parameter is used by the SGSN to indicate to the HLR that the SGSN supports the Super-Charger functionality and whether subscription data has been retained by the SGSN. If subscription data has been retained by the SGSN the age indicator shall be included. Otherwise the SGSN shall indicate that subscriber data is required. If this parameter is absent then the SGSN does not support the Super-Charger functionality. GPRS enhancements support indicator This parameter is used by the SGSN to indicate to the HLR in the Update GPRS Location indication that GPRS enhancements are supported. If this parameter is included in the Update GPRS Location indication the HLR may send the extension QoS parameter in the PDP contexts to the SGSN. The HLR may send the extension-2 QoS, the extension-3 QoS and the extension-4 QoS parameters with the extension QoS parameter. HLR number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory in case of successful HLR updating. Supported LCS Capability Sets This parameter indicates, if present, the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the SGSN does not support LCS at all. The SGSN is not allowed to indicate support for LCS capability set 1. If this parameter is absent then the SGSN does not support LCS at all. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the SGSN (see clause 7.6.3.36D). Inform Previous Network Entity This parameter is used by the SGSN to ask the HLR to inform the previous network entity about the update by sending the previous network entity a Cancel Location message. It is used in case Super-Charger is supported in the network and the serving network entity has not been able to inform the previous network entity that MS has moved, that is if it has not sent SGSN Context Request to the previous serving entity. PS LCS Not Supported by UE See definition in clauseÊ7.6.11. V-GMLC address See definition in clauseÊ7.6.2. Call Barring support indicator See definition in clauseÊ7.6.3.92. IMEISV For definition of the parameter see clause 7.6.2. For the use of this parameter see 3GPP TS 23.060. IMEISV shall be present if ADD function is supported and the IMEISV is new in SGSN (The functional requirements for the presence of IMEISV due to ADD are described in 3GPP TS 22.101 clause 7.4). Skip Subscriber Data Update The presence of the parameter is optional and if present it indicates that subscriber data download during the updateGprsLocation procedure may be skipped by the HLR e.g. because the service is solely used to inform the HLR about change of IMEISV. The parameter is used to optimise signalling load during Location Update procedure. Supported RAT Types Indicator This parameter indicates, if present, which access technologies (e.g. GERAN and/or UTRAN and/or E-UTRAN) are served by the SGSN or MME (see clause 7.6.3) EPS Info This parameter may indicate that the MME or SGSN has selected a new PDN GW for an APN. If so, the HSS shall skip subscriber data update (insert subscriber data) and only note the new PDN GW. Otherwise this parameter may indicate the appropriate instruction to be performed by the HSS which is one or more of a) Update Location; i.e. send CancelLocation to the old MME and replace the stored MME id (if Serving Node Type Indicator is present and the stored MME id is different from the received MME id), or send CancelLocation to the old SGSN and replace the stored SGSN id (if Serving Node Type Indicator is absent and the stored SGSN id is different from the received SGSN id); b) Cancel SGSN; i.e. send CancelLocation to the SGSN and delete the stored SGSN id. c) Initial Attach; i.e. send CancelLocation to the MME (if Serving Node Type Indicator is absent) or to the SGSN (if Serving Node Type Indicator is present) with cancellation type set to ""initial attach procedure"" Serving Node Type Indicator This parameter indicates by its presence that the subscriber's serving node is an MME (which is either stand alone or combined with an SGSN) and it indicates by its absence that the subscriber's serving node is an SGSN (which is either stand alone or combined with an MME). Supported Features This parameter shall be used by an IWF to forward feature support indications as received from the MME or SGSN via S6a/S6d. It shall also be used by the SGSN to indicate support of the Dedicated Core Network functionality to the HLR. Used RAT Type This parameter may indicate the RAT type currently used by the serving node. GPRS Subscription Data not needed Indicator This parameter indicates by its presence that the SGSN (or MME/IWF) does not request GPRS Subscription Data in addition to EPS Subscription Data. EPS Subscription Data Not Needed Indicator This parameter indicates by its presence that the SGSN does not request EPS Subscription Data in addition to GPRS Subscription Data. NOTE: The indicator is only applicable to an SGSN which only supports Gn and Gp interfaces and does not support S4 interface. Node-Type Indicator This parameter indicates by its presence that the requesting node is a combined MME/SGSN. Absence of this Indicator indicates that the requesting node is a single MME or SGSN. When Node-Type Indicator is absent and Serving Node Type Indicator is present, the HSS may skip checking SMS/LCS supported features and skip the download of SMS/LCS-related subscription data to a standalone MME. Area Restricted Indicator This parameter indicates by its presence that the network node area is restricted due to regional subscription. This parameter is used by the IWF only. UE-Reachable Indicator This parameter indicates by its presence that the UE is reachable. NOTE: In general any UpdateGPRS-Location request message (with or without UE-Reachable Indicator) implicitly conveys the information that the UE is now reachable. This explicit indicator shall be set only when UpdateGPRS-Location is used for the only and no other purpose than indicating UE reachability. The HLR shall skip subscriber data downloading and any mobility management functionality other than reporting the UE's reachability to relevant core network entities. T-ADS Data Retrieval Support Indicator This parameter indicates by its presence that the SGSN supports retrieval of T-ADS data with the Provide-Subscriber-Info service. Homogeneous Support Of IMS Voice Over PS Sessions This parameter when present indicates that IMS voice over PS sessions is homogeneously supported in the complete SGSN area or that IMS voice over PS sessions is homogeneously not supported in the complete SGSN area. Update of Homogeneous Support Of IMS Voice Over PS Sessions This parameter when present indicates that Homogeneous Support of IMS Voice Over PS Sessions is updated. If the Homogeneous Support of IMS Voice Over PS Session is not present, the value of the Homogeneous Support of IMS Voice Over PS Sessions shall be updated as unknown to the serving node. UE SRVCC Capability See definition in clause 7.6.3.99. Equivalent PLMN List This parameter indicates the equivalent PLMN list of which the MME/SGSN requests the corresponding CSG Subscription data. MME Number for MT SMS This parameter contains the ISDN number of the MME allocated for MT SMS (see 3GPP TS 23.003 [17]). It is present when the MME requests to be registered for SMS. SMS-Only This parameter indicates to the HSS that the UE needs only PS domain services and SMS services. SMS Register Request This parameter indicates to the HSS that if the MME (via IWF) needs to be registered for SMS, prefers not to be registered for SMS or has no preference to be registered for SMS, see 3GPP TS 23.272 [143]. This parameter indicates to the HSS that if the SGSN needs to be registered for SMS, prefers not to be registered for SMS or has no preference to be registered for SMS, see 3GPP TS 23.060 [104]. Removal of MME Registration for SMS This parameter indicates by its presence that the MME requests to remove its registration for SMS. MSISDN-less Operation Supported This parameter indicates by its presence that the SGSN supports MSISDN-less operation (see clause 5.3.17 of 3GPP TS 23.060 [23]). An SGSN which supports MSISDN-less operation shall set this parameter. SGSN Name See definition in clauseÊ7.6.2. This parameter is provided in a request when the serving node is an SGSN and the SGSN supports Lgd interface for LCS and/or Gdd interface for SMS. SGSN Realm See definition in clauseÊ7.6.2. This parameter is provided in a request when the serving node is an SGSN and the SGSN supports Lgd interface for LCS and/or Gdd interface for SMS. Lgd Support Indicator This parameter, by its presence, indicates to the HSS that the SGSN supports Lgd interface for LCS. When absent the SGSN supports only Lg interface for LCS, if LCS is supported. Adjacent PLMNs This parameter indicates the list of PLMNs where an UE served by the SGSN is likely to make a handover from the PLMN where the SGSN is located. This list is statically configured by the operator in the SGSN, according to the geographical disposition of the different PLMNs in that area, the roaming agreements, etc... Reset-IDs Supported This parameter indicates, if present, the support of Reset-IDs by the SGSN. ADD Capability This parameter indicates, if present, the support of ADD function by the HLR. SGSN-MME Separation Support Indicator This parameter indicates by its presence that the HSS separately stores SGSN Id and MME Id. A combined MME/SGSN shall not send Update-GPRS-Location at intra node inter RAT routing area update if a Separation Indicator was not received previously. MME Registered for SMS This parameter indicates by its presence that the HSS has registered the MME for SMS. User error In case of unsuccessful updating, an error cause shall be returned by the HLR. The following error causes defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - unknown subscriber; - roaming not allowed. This cause will be sent if the MS is not allowed to roam into the PLMN indicated by the SGSN number. The cause is qualified by the roaming restriction reason ""PLMN Not Allowed"", ""Supported RAT Types Not Allowed"" or ""Operator Determined Barring"". This cause shall be used when the HLR rejects a MAP Update Gprs Location request received for an MSISDN-less subscription from a SGSN not supporting MSISDN-less operation. - system failure; - unexpected data value. The diagnostic in the Unknown Subscriber may indicate ""Imsi Unknown"" or ""Gprs or EPS Subscription Unknown"". Provider error For definition of provider errors see clauseÊ7.6.1. 8.1.8 MAP-NOTE-MM-EVENT 8.1.8.1 Definition This service is used between the VLR and the gsmSCF or between the SGSN and the gsmSCF when a mobility management event for a subscriber has been processed successfully, that subscriber is provisioned with M-CSI or MG-CSI and the relevant mobility management event is marked for reporting. This service is also used between the VLR and the Presence Network Agent or between the SGSN and the Presence Network Agent to notify the Presence Network Agent when a mobility management event for a subscriber has been processed successfully, that subscriber is provisioned with M-CSI or MG-CSI and the relevant mobility management event is marked for reporting (see 3GPP TS 23.141 [128]). 8.1.8.2 Service primitives The service primitives are shown in tableÊ8.1/8. TableÊ8.1/8: MAP_NOTE_MM_EVENT parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Event Met M M(=) Service Key M M(=) IMSI M M(=) Basic MSISDN M M(=) Location Information for GPRS C C(=) Location Information C C(=) LSA Identity C C(=) Supported CAMEL Phases M M(=) Offered CAMEL 4 Functionalities C C(=) User error C C(=) Provider error O 8.1.8.3 Parameter use Event Met This parameter indicates the mobility management event that has lead to the notification. It shall have one of the following values for a mobility management event reported by the VLR: - Location update in the same VLR service area; - Location update to another VLR service area; - IMSI attach; - MS initiated IMSI detach (explicit detach); - Network initiated IMSI detach (implicit detach). It shall have one of the following values for a mobility management event reported by the SGSN: - Routeing area update in the same SGSN service area; - Routeing area update to another SGSN service area; - GPRS attach; - MS initiated GPRS detach; - Network initiated GPRS detach; - Network initiated transfer to the ""not reachable for paging"" state. Service Key See clause 7.6.x. IMSI See clause 7.6.x. Basic MSISDN See clause 7.6.x. Location Information See clause 7.6.2.30. This information shall be sent when the event is reported by a VLR, if available. If the event is reported as part of an SGs location update procedure, this information shall include the LAI and the Location Information for EPS if available. Location Information for GPRS See clause 7.6.2.30a. This information shall be sent when the event is reported by an SGSN, if available. LSA Identity See clause 7.6.x. This information shall be sent, if available. Supported CAMEL Phases See clause 7.6.x. This information shall always be sent. Offered CAMEL 4 Functionalities This parameter indicates the CAMEL phase 4 functionalities offered by the sending entity, VMSC/VLR or SGSN (see clause 7.6.3.36G). User error This parameter is sent by the receiving entity when an error is detected. It shall have one of the following values: - Data Missing; - Unexpected Data Value; - Unknown Subscriber; - MM-EventNotSupported. Provider error This is defined in clause 7.6.1. 8.1.9 MAP_UPDATE_VCSG_LOCATION service 8.1.9.1 Definition This procedure is used by the VLR or SGSN to register the MS in the CSS when - the VPLMN supports Autonomous CSG Roaming - and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN - and the MS has requested an initial attach or a location area procedure or a routing area procedure to a CSG cell - and the VLR or SGSN has not yet registered the MS in the CSS. The MAP_UPDATE_VCSG_LOCATION service is a confirmed service using the service primitives given in table 8.1/9. 8.1.9.2 Service primitives Table 8.1/9: MAP_UPDATE_VCSG_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) VLR number C C(=) SGSN number C C(=) MSISDN C C(=) Temporary Empty CSG Subscription data Indicator C C(=) User error C C(=) Provider error O 8.1.9.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. VLR number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory when the service is used by the VLR. SGSN number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory when the service is used by the SGSN. MSISDN See definition in clauseÊ7.6.2. Shall be present if this parameter is available. Temporary Empty CSG Subscription data Indicator See definition in clauseÊ7.6.3.100. This parameter shall be present if the CSS accepts the request and there is no CSG Subscription data (empty CSG-ID list) for the roaming MS in the CSS. User error The following error causes defined in clauseÊ7.6.1 may be used: - unknown subscriber; - system failure; - unexpected data value. Provider error For definition of provider errors see clause 7.6.1 8.1.10 MAP_ CANCEL_VCSG_LOCATION service 8.1.10.1 Definition This service is used between CSS and VLR to delete a roaming user record including the CSG subscription data and the CSS number from the VLR. The service is also used between CSS and SGSN to delete a roaming user record including the CSG subscription data and the CSS number from the SGSN. It may be invoked when there is removal of the CSG subscription data in CSS and of the MS registration including the case where a MS was registered in CSS but without CSG data. The MAP_CANCEL_VCSG_LOCATION service is a confirmed service using the primitives defined in tableÊ8.1/10. 8.1.10.2 Service primitives TableÊ8.1/10: MAP_CANCEL_VCSG_LOCATION Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) User error C C(=) Provider error O 8.1.10.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. User error If the cancellation fails, an error cause is to be returned by the VLR or by the SGSN. One of the following error causes defined in clauseÊ7.6.1 shall be used: - unexpected data value; - data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 8.2 Paging and search 8.2.1 MAP_PAGE service 8.2.1.1 Definition This service is used between VLR and MSC to initiate paging of an MS for mobile terminated short message or unstructured SS notification. The MAP_PAGE service is a confirmed service using the primitives from tableÊ8.2/1. 8.2.1.2 Service primitives TableÊ8.2/1: MAP_PAGE Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) Stored location area Id M M(=) TMSI U C(=) User error C C(=) Provider error O 8.2.1.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is used to define the paging subgroup. If the TMSI is not supplied, paging on the radio path uses the IMSI as an identifier. Stored location area Id See definition in clauseÊ7.6.2. TMSI See definition in clauseÊ7.6.2. The TMSI is included if paging on the radio channel is to use the TMSI as an identifier. User error The following error causes defined in clauseÊ7.6.1 may be sent by the user in case of a paging error, depending on the failure reason: - absent subscriber; - unknown location area; - busy subscriber; - system failure; - this corresponds to the case where there is no call associated with the MAP_PAGE service, i.e. if the call has been released but the dialogue to the VLR has not been aborted; - unexpected data value. Provider error See definition in clauseÊ7.6.1. 8.2.2 MAP_SEARCH_FOR_MS service 8.2.2.1 Definition This service is used between VLR and MSC to initiate paging of an MS in all location areas of that VLR. It is used if the VLR does not hold location area information confirmed by radio contact. The MAP_SEARCH_FOR_MS service is a confirmed service using the primitives from tableÊ8.2/2. 8.2.2.2 Service primitives TableÊ8.2/2: MAP_SEARCH_FOR_MS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) Current location area Id C C(=) User error C C(=) Provider error O 8.2.2.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is used to identify the subscriber when paging on the radio path. Current location area Id See definition in clauseÊ7.6.2. In case of successful outcome of the service, i.e. if the MS responds to paging, the Location Area Id of the area in which the MS responded is given in the response. User error The following error causes defined in clauseÊ7.6.1 shall be sent by the user if the search procedure fails, depending on the failure reason: - absent subscriber; this error cause is returned by the MSC if the MS does not respond to the paging request; - system failure; - this corresponds to the case where there is no call associated with the MAP_SEARCH_FOR_MS service, i.e. if the call has been released but the dialogue to the VLR has not been aborted; - busy subscriber; - unexpected data value. Provider error See definition in clauseÊ7.6.1. 8.3 Access management services 8.3.1 MAP_PROCESS_ACCESS_REQUEST service 8.3.1.1 Definition This service is used between MSC and VLR to initiate processing of an MS access to the network, e.g. for mobile originated short message submission or after being paged by the network. The MAP_PROCESS_ACCESS_REQUEST service is a confirmed service using the primitives from tableÊ8.3/1. 8.3.1.2 Service primitives TableÊ8.3/1: MAP_PROCESS_ACCESS_REQUEST Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) CM service type M M(=) Access connection status M M(=) Current Location Area Id M M(=) Serving cell Id M M(=) TMSI C C(=) Cksn C C(=) IMSI C C(=) C C(=) IMEI C C(=) C C(=) MSISDN U C(=) User error C C(=) Provider error O 8.3.1.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. CM service type See definition in clauseÊ7.6.9. Access connection status See definition in clauseÊ7.6.9. Current Location Area Id See definition in clauseÊ7.6.2. This parameter is used to update the VLR in case of previous VLR failure. Serving cell Id See definition in clause 7.6.2. TMSI See definition in clauseÊ7.6.2. Either TMSI or IMSI as received from the MS are included in the Request/Indication, but one shall be present. In case of CM Service Type ""Emergency Call Establishment"", the IMEI may replace IMSI/TMSI. Cksn See definition in clauseÊ7.6.7. In case of access with TMSI, the Cksn shall be present. IMSI See definition in clauseÊ7.6.2. Either TMSI or IMSI as received from the MS are included in the Request/Indication, but one shall be present. In case of CM Service Type ""Emergency Call Establishment"", the IMEI may replace IMSI/TMSI. In the Response/Confirmation, the IMSI is to be sent in case of successful outcome of the service. In case of CM Service Type ""Emergency Call Establishment"", IMEI may replace IMSI. IMEI See definition in clauseÊ7.6.2. The IMEI may replace IMSI/TMSI in the Request/Indication and IMSI in the Response/Confirmation only in case the CM Service Type indicates ""Emergency Call Establishment"". MSISDN See definition in clauseÊ7.6.2. The MSISDN is included in case of successful outcome of the service as an operator option, e.g. if it is needed at the MSC for charging purposes in case of call forwarding. User error One of the following error causes defined in clauseÊ7.6.1 shall be sent by the user if the access request fails, depending on the failure reason: - unidentified subscriber; - illegal subscriber; this error is sent if a correlated authentication procedure has not authenticated the subscriber; - illegal equipment; this error is sent if an IMEI check failed, i.e. the IMEI is prohibited-listed or not permitted-listed; - roaming not allowed; - this cause is used after VLR restart if the subscriber has no subscription for the current location area, e.g. due to regional subscription. The cause will be qualified by ""location area not allowed"" or ""national roaming not allowed"", respectively; - unknown location area; - system failure; - unexpected data value. Provider error For definition of provider errors see clauseÊ7.6.1. 8.4 Handover services It should be noted that the handover services used on the B-interface have not been updated for Release 99. The B-interface is not fully operational specified. It is strongly recommended not to implement the B-interface as an external interface. 8.4.1 MAP_PREPARE_HANDOVER service 8.4.1.1 Definition This service is used between MSC-A and MSC-B (E-interface) when a call is to be handed over or relocated from MSC A to MSC B. The MAP_PREPARE_HANDOVER service is a confirmed service using the primitives from tableÊ8.4/1."
"8.4.1.2 Service primitives TableÊ8.4/1: MAP_PREPARE_HANDOVER Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Target Cell Id C C(=) Target RNC Id C C(=) HO-NumberNotRequired C C(=) IMSI C C(=) Integrity Protection Information C C(=) Encryption Information C C(=) Radio Resource Information C C(=) AN-APDU C C(=) C C(=) Allowed GSM Algorithms C C(=) Allowed UMTS Algorithms C C(=) Radio Resource List C C(=) RAB ID C C(=) GERAN Classmark C C(=) BSSMAP Service Handover C C(=) BSSMAP Service Handover List C C(=) RANAP Service Handover C C(=) Iu-Currently Used Codec C C(=) Iu-Supported Codecs List C C(=) RAB Configuration Indicator C C(=) ASCI Call Reference C C(=) UESBI-Iu C C(=) IMEISV C C(=) Alternative Channel Type C C(=) Trace_Propagation_List C C(=) AoIP-Supported Codecs List Anchor C C(=) Regional Subscription Data U (C=) CSG Subscription Data U (C=) LCLS Global Call Reference C C(=) LCLS-Negotiation C C(=) LCLS-Configuration-Preference C C(=) Multiple Bearer Requested C C(=) Handover Number C C(=) Relocation Number List C C(=) Multicall Bearer Information C C(=) Multiple Bearer Not Supported C C(=) Selected UMTS Algorithms C C(=) Chosen Radio Resource Information C C(=) Iu-Selected Codec C C(=) Iu-Available Codecs List C C(=) AoIP-Selected Codec Target C C(=) AoIP-Available Codecs List Map C C(=) User error C C(=) Provider error O 8.4.1.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. Target Cell Id For definition of this parameter see clauseÊ7.6.2. This parameter is only included if the service is not in an ongoing transaction. This parameter shall also be excluded if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009. Target RNC Id For definition of this parameter see clauseÊ7.6.2. This parameter shall be included if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009. HO-Number Not Required For definition of this parameter see clauseÊ7.6.6. IMSI For definition of this parameter see clauseÊ7.6.2. This UMTS parameter shall be included if: - available and - if the access network protocol is BSSAP and - there is an indication that the MS also supports UMTS. Integrity Protection Information For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the access network protocol is BSSAP. Encryption Information For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the access network protocol is BSSAP. Radio Resource Information For definition of this parameter see clauseÊ7.6.6. This GSM parameter shall be included if the access network protocol is RANAP and there is an indication that the UE also supports GSM. If the parameter Radio Resource List is sent , the parameter Radio Resource Information shall not be sent. AN-APDU For definition of this parameter see clauseÊ7.6.9. Allowed GSM Algorithms For definition of this parameter see clause 7.6.6. This parameters includes allowed GSM algorithms. This GSM parameter shall be included if: - the service is a part of the Inter-MSC SRNS Relocation procedure and - Ciphering or Security Mode Setting procedure has been performed.and - there is an indication that the UE also supports GSM. Allowed UMTS Algorithms For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if all of the following conditions apply: - access network protocol is BSSAP and - Integrity Protection Information and Encryption Information are not available and - Ciphering or Security Mode Setting procedure has been performed. Radio Resource List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if the access network protocol is RANAP and there is an indication that the UE also supports GSM. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B. If the parameter Radio Resource Information is sent , the parameter Radio Resource List shall not be sent. RAB ID For definition of this parameter see clauseÊ7.6.2. This parameter shall be included when MSC-A supports multiple bearers and access network protocol is BSSAP and the RAB ID has a value other than 1. GERAN Classmark For definition of this parameter see clauseÊ7.6.6 This parameter shall be included if available. BSSMAP Service Handover For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is RANAP. If the parameter BSSMAP Service Handover List is sent, the parameter BSSMAP Service Handover shall not be sent. BSSMAP Service Handover List For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is RANAP. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B. If the parameter BSSMAP Service Handover is sent, the parameter BSSMAP Service Handover List shall not be sent. RANAP Service Handover For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is BSSAP. Iu-Currently Used Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if the handover is requested for a speech bearer and the MS is in UMTS or GERAN Iu-mode access. This parameter shall not be included if the Iu-Supported Codecs List is not included. Iu-Supported Codecs List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included by MSC-A, if the handover is requested for a speech bearer. RAB Configuration Indicator For definition of this parameter see clauseÊ7.6.6. This parameter may be included if the handover is requested for a speech bearer and MSC-A knows by means of configuration information that MSC-B supports the use of the Iu-Supported Codecs List parameter. This parameter shall not be included if the Iu-Supported Codecs List is not included. ASCI Call Reference This parameter contains either the broadcast call reference or group call reference. It shall be included if a subscriber is undergoing handover during a VGCS or VBS call, where MSC-B already has a Bearer established, so that MSC-B can determine the Group or Broadcast Call to which it shall attach the subscriber, see 3GPP TS 48.008 [49]. UESBI-Iu For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is BSSAP. IMEISV For definition of the parameter see clause 7.6.2. This parameter shall be present, if available. This is used e.g. for Management based Trace Activation (see 3GPP TS 32.422). Alternative Channel Type For definition of this parameter see clauseÊ7.6.6 It shall be present for a SCUDIF call if the access network protocol is BSSAP. Trace Propagation List See definition in clauseÊ7.6.10. This parameter shall be included when MSC-A requests trace invocation. AoIP-Supported Codecs List Anchor For definition of this parameter see clauseÊ7.6.6. This parameter may be included by MSC-A, if the handover is requested for a speech bearer and mobile terminal supports GSM codec types. Regional Subscription Data The list of subscribed Zone Codes as received from the HLR may be included by MSC-A at intra PLMN inter MSC handover and may be stored at MSC-B for use at subsequent intra MSC handover. CSG Subscription Data The subscribed CSG Subscription Information as received from the HLR may be included by MSC-A at intra PLMN inter MSC handover and at inter PLMN inter MSC handover when the target PLMN is an ePLMN, and may be stored at MSC-B for use at subsequent intra MSC handover. LCLS Global Call Reference For definition of this parameter see clauseÊ7.6.5.21. This parameter shall be included when MSC-A supports LCLS. LCLS-Negotiation For definition of this parameter see clauseÊ7.6.5.22. This parameter shall be included when MSC-A supports LCLS. LCLS-Configurations-Preference For definition of this parameter see clauseÊ7.6.5.23. This parameter shall be included when MSC-A supports LCLS. Multiple Bearer Requested For a definition of this parameter see clause 7.6.2. This parameter shall be sent when MSC-A requests multiple bearers to MSC-B. Handover Number For definition of this parameter see clauseÊ7.6.2. This parameter shall be returned at handover, unless the parameter HO-NumberNotRequired is sent. If the parameter Handover Number is returned, the parameter Relocation Number List shall not be returned. Relocation Number List For definition of this parameter see clauseÊ7.6.2. This parameter shall be returned at relocation, unless the parameter HO-NumberNotRequired is sent. If the parameter Relocation Number List is returned, the parameter Handover Number shall not be returned. Multicall Bearer Information For a definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation in the case that MSC-B supports multiple bearers. Multiple Bearer Not Supported For a definition of this parameter see clause 7.6.2. This parameter shall be returned at relocation when MSC-B receives Multiple Bearer Requested parameter and MSC-B does not support multiple bearers. Selected UMTS Algorithms For definition of this parameter see clauseÊ7.6.6. This parameters includes the UMTS integrity and optionally encryption algorithms selected by RNC under the control of MSC-B. This UMTS parameter shall be included if the service is a part of the inter MSC inter system handover from GSM to UMTS. Chosen Radio Resource Information For definition of this parameter see clauseÊ7.6.6. This parameter shall be returned at relocation if the encapsulated PDU is RANAP RAB Assignment Response and MS is in GSM access. Iu-Selected Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if an Iu-Supported Codecs List was received in the service request and MSC-B supports the selection of codec based on the Iu-Supported Codecs List and the target radio access network is connected to MSC-B via the Iu interface, even if the Iu-Selected Codec is equal to the Iu-Currently Used Codec received in the service request. This parameter shall not be included if the Iu-Supported Codecs List was not received in the service request. Iu-Available Codecs List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included by an MSC-B supporting TrFO, if the Iu-Supported Codecs List was included by MSC-A and the target radio access is UMTS or GERAN Iu-mode. AoIP-Selected Codec Target For definition of this parameter see clauseÊ7.6.6. This parameter may be included by an MSC-B supporting TrFO, if the AoIP-Supported Codecs List Anchor was included by MSC-A and if AoIP is used on the target A interface with transcoder inserted in the MGW. AoIP-Available Codecs List Map For definition of this parameter see clauseÊ7.6.6. This parameter may be included by an MSC-B supporting TrFO, if the AoIP-Supported Codecs List Anchor was included by MSC-A and if AoIP is used on the target A interface with transcoder inserted in the MGW. User error For definition of this parameter see clauseÊ7.6.1. The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - No handover number available. - Target cell outside group call area; - System failure. - Unexpected data value. - Data Missing. Provider error See definition of provider errors in clauseÊ7.6.1. 8.4.2 MAP_SEND_END_SIGNAL service 8.4.2.1 Definition This service is used between MSC-B and MSC-A (E-interface) indicating that the radio path has been established by MSC-B to the MS. MSC-A retains then the main control of the call until it clears. The response is used by MSC-A to inform MSC-B that all resources for the call can be released in MSC-B, either because the call has been released in MSC-A or because the call has been successfully handed over or relocated from MSC-B to another MSC. The MAP_SEND_END_SIGNAL service is a confirmed service using the primitives from tableÊ8.4/2. 8.4.2.2 Service primitives TableÊ8.4/2: MAP_SEND_END_SIGNAL Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) AN-APDU M M(=) Provider error O 8.4.2.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. AN-APDU For definition of this parameter see clauseÊ7.6.9. Provider error For definition of this parameter see clauseÊ7.6.1. 8.4.3 MAP_PROCESS_ACCESS_SIGNALLING service 8.4.3.1 Definition This service is used between MSC-B and MSC-A (E-interface) to pass information received on the A interface or Iu-interface in MSC B to MSC A. The MAP_PROCESS_ACCESS_SIGNALLING service is a non-confirmed service using the primitives from tableÊ8.4/3. 8.4.3.2 Service primitives TableÊ8.4/3: MAP_PROCESS_ACCESS_SIGNALLING Parameter name Request Indication Invoke Id M M(=) AN-APDU M M(=) Selected GSM Algorithm C C(=) Selected UMTS Algorithms C C(=) Chosen Radio Resource Information C C(=) Selected RAB id C C(=) Iu-Selected Codec C C(=) Iu-Available Codecs List C C(=) AoIP-Selected Codec Target C C(=) AoIP-Available Codecs List Map C C(=) 8.4.3.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. AN-APDU For definition of this parameter see clauseÊ7.6.9. Selected GSM algorithm For definition of this parameter see clauseÊ7.6.6. This parameter shall be present if the encapsulated PDU is Security Mode Complete and MS is in GSM access. Selected UMTS Algorithms For definition of this parameter see clauseÊ7.6.6. This parameters includes the UMTS integrity and optionally encryption algorithms selected by RNC under the control of MSC-B. This UMTS parameter shall be included if the encapsulated PDU is BSSMAP Cipher Mode Complete and the MS is in UMTS, or an interystem handover to UMTS is performed in MSC-B, or in the case of intra MSC-B intra UMTS relocation. Chosen Radio Resource Information For definition of this parameter see clauseÊ7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Response and MS is in GSM access. Selected RAB ID The selected radio access bearer that was kept at subsequent intra-MSC handover from UMTS to GSM after multiple bearers were used. Iu-Selected Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included - if MSC-B changes the selected codec and the MS is in UMTS or GERAN Iu-mode access; - if intersystem handover to UMTS or GERAN Iu-mode is performed in MSC-B; or - if MSC-B received a Forward Access Signalling service request including an Iu-Supported Codecs List and the MS is in UMTS or GERAN Iu-mode access. This parameter shall not be included if the Iu-Supported Codecs List was not received either in the Prepare Handover service request or in the Forward Access Signalling service request. Iu-Available Codecs List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included by an MSC-B supporting TrFO - if the Iu-Available Codecs List has changed in MSC-B; - if intersystem handover to UMTS or GERAN Iu-mode is performed in MSC-B; or - if MSC-B received a Forward Access Signalling service request including an Iu-Supported Codecs List and the MS is in UMTS or GERAN Iu-mode access. AoIP-Selected Codec Target For definition of this parameter see clauseÊ7.6.6. This parameter may be included - if A interface codec is changed in MSC-B; or - if intersystem handover to AoIP capable BSC is performed in MSC-B and if AoIP is used on the target A interface with transcoder inserted in the MGW; or - if MSC-B received a Forward Access Signalling service request including an AoIP-Supported Codecs List and the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW. This parameter shall not be included if the AoIP-Supported Codecs List Anchor was not received either in the Prepare Handover service request or in the Forward Access Signalling service request. AoIP-Available Codecs List Map For definition of this parameter see clauseÊ7.6.6. This parameter may be included by an MSC-B supporting TrFO - if the AoIP-Available Codecs List has changed in MSC-B; or - if intersystem handover to AoIP capable BSC is performed in MSC-B where AoIP is used on the target A interface with transcoder inserted in the MGW; or - if MSC-B received a Forward Access Signalling service request including an AoIP-Supported Codecs List Anchor and the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW. 8.4.4 MAP_FORWARD_ACCESS_SIGNALLING service 8.4.4.1 Definition This service is used between MSC-A and MSC-B (E-interface) to pass information to be forwarded to the A-interface or Iu-interface of MSC-B. The MAP_FORWARD_ACCESS_SIGNALLING service is a non-confirmed service using the primitives from tableÊ8.4/4. 8.4.4.2 Service primitives TableÊ8.4/4: MAP_FORWARD_ACCESS_SIGNALLING Parameter name Request Indication Invoke Id M M(=) Integrity Protection Information C C(=) Encryption Information C C(=) Key Status C C(=) AN-APDU M M(=) Allowed GSM Algorithms C C(=) Allowed UMTS Algorithms C C(=) Radio Resource Information C C(=) Radio Resource List C C(=) BSSMAP Service Handover C C(=) BSSMAP Service Handover List C C(=) RANAP Service Handover C C(=) Iu-Currently Used Codec C C(=) Iu-Supported Codecs List C C(=) RAB Configuration Indicator C C(=) Iu-Selected Codec C C(=) Alternative Channel Type C C(=) Trace Propagation List C C(=) AoIP-Supported Codecs List Anchor C C(=) AoIP-Selected Codec Target C C(=) UESBI-Iu C C(=) IMEISV C C(=) 8.4.4.3 Parameter use For the definition and use of all parameters and errors, see clauseÊ7.6.1. Invoke Id For definition of this parameter see clauseÊ7.6.1. Integrity Protection Information For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command. Encryption Information For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command. Key Status For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if available and if the encapsulated PDU is BSSMAP Cipher Mode Command. AN-APDU For definition of this parameter see clauseÊ7.6.9. Allowed GSM Algorithms This parameters includes allowed GSM algorithms. This GSM parameter shall be included if the encapsulated PDU is RANAP Security Mode Command and there is an indication that the UE also supports GSM. Allowed UMTS Algorithms For definition of this parameter see clauseÊ7.6.6. This UMTS parameter shall be included if Integrity Protection Information and Encryption Information are not available and the encapsulated PDU is BSSMAP Cipher Mode Command. Radio Resource Information For definition of this parameter see clauseÊ7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Request. If the parameter Radio Resource List is sent, the parameter Radio Resource Information shall not be sent. Radio Resource List For definition of this parameter see clauseÊ7.6.6. This parameter shall be sent if the encapsulated PDU is RANAP RAB Assignment Request and MSC-A requests modification of multiple bearers. If the parameter Radio Resource Information is sent, the parameter Radio Resource List shall not be sent. BSSMAP Service Handover For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the encapsulated PDU is RANAP RAB Assignment Request. If the parameter BSSMAP Service Handover List is sent, the parameter BSSMAP Service Handover shall not be sent. BSSMAP Service Handover List For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the encapsulated PDU is RANAP RAB Assignment Request and MSC-A requests modification of multiple bearers. If the parameter BSSMAP Service Handover is sent, the parameter BSSMAP Service Handover List shall not be sent. RANAP Service Handover For definition of this parameter see clauseÊ7.6.6.. It shall be present if it is available and the encapsulated PDU is BSSMAP Assignment Request. Iu-Currently Used Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request for a speech bearer and the MS is in UMTS or GERAN Iu-mode access. This parameter shall not be included if the Iu-Supported Codecs List is not included. Iu-Supported Codecs List For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request and - a new bearer is allocated for speech; - an existing bearer is modified from data to speech; or - for an existing speech bearer the order of priority in the Iu-Supported Codecs List needs to be modified. This parameter shall not be included if the Iu-Selected Codec is included. RAB Configuration Indicator For definition of this parameter see clauseÊ7.6.6. This parameter may be included if the encapsulated PDU is a RANAP RAB Assignment Request for a speech bearer, and MSC-A knows by means of configuration information that MSC-B supports the use of the Iu-Supported Codecs List parameter. This parameter shall not be included if the Iu-Supported Codecs List is not included. Iu-Selected Codec For definition of this parameter see clauseÊ7.6.6. This parameter shall be included if - the encapsulated PDU is a RANAP RAB Assignment Request or BSSMAP Assignment Request for an existing speech bearer; and - the MS is in UMTS or GERAN Iu-mode access; and - an Iu-Available Codecs List was received by MSC-A for this speech bearer before, either in the Prepare Handover service response or in the Process Access Signalling service request. This parameter shall not be included if the Iu-Supported Codecs List is included. Alternative Channel Type For definition of this parameter see clauseÊ7.6.6. This parameter shall be present for a SCUDIF call if the encapsulated PDU is BSSMAP Assignment Request. Trace Propagation List See definition in clauseÊ7.6.10. This parameter shall be included when MSC-A requests trace invocation. AoIP-Supported Codecs List Anchor For definition of this parameter see clauseÊ7.6.6. This parameter may be included if the encapsulated PDU is a BSSMAP Assignment Request and - a new bearer is allocated for speech; - an existing bearer is modified from data to speech; or - for an existing speech bearer the order of priority in the AoIP-Supported Codecs List needs to be modified. This parameter shall not be included if the AoIP-Selected Codec Target is included. AoIP-Selected Codec Target For definition of this parameter see clauseÊ7.6.6. This parameter may be included if - the encapsulated PDU is a BSSMAP Assignment Request for an existing speech bearer; and - the MS is in AoIP capable GSM access where AoIP is used on the target A interface with transcoder inserted in the MGW; and - an AoIP-Available Codecs List was received by MSC-A for this speech bearer before, either in the Prepare Handover service response or in the Process Access Signalling service request. This parameter shall not be included if the AoIP-Supported Codecs List Anchor is included. UESBI-Iu For definition of this parameter see clauseÊ7.6.6. It shall be present if it is available and the access network protocol is BSSAP and the parameter has not already been sent to the target MSC. IMEISV For definition of the parameter see clause 7.6.2. This parameter shall be present if available and if not already sent to the target MSC. This is used e.g. for Management based Trace Activation (see 3GPP TS 32.422). 8.4.5 MAP_PREPARE_SUBSEQUENT_HANDOVER service 8.4.5.1 Definition This service is used between MSC-B and MSC-A (E-interface) to inform MSC-A that it has been decided that a handover or relocation to either MSC-A or a third MSC (MSC-B') is required. The MAP_PREPARE_SUBSEQUENT_HANDOVER service is a confirmed service using the primitives from tableÊ8.4/5. 8.4.5.2 Service primitives TableÊ8.4/5: MAP_PREPARE_SUBSEQUENT_HANDOVER Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Target Cell Id C C(=) Target RNC Id C C(=) Target MSC Number M M(=) Selected RAB ID C C(=) GERAN Classmark C C(=) RAB Configuration Indicator C C(=) AN-APDU M M(=) C C(=) User error C C(=) Provider error O 8.4.5.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. Target Cell Id For definition of this parameter see clauseÊ7.6.2. This parameter shall be excluded if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009. Target RNC Id For definition of this parameter see clauseÊ7.6.2. This parameter shall be included if the service is a part of the Inter-MSC SRNS Relocation procedure or the inter-system handover GSM to UMTS procedure described in 3GPP TS 23.009. Target MSC Number For definition of this parameter see clauseÊ7.6.2. Selected RAB ID For definition of this parameter see clauseÊ7.6.2. GERAN Classmark For definition of this parameter see clauseÊ7.6.6 This parameter shall be included if available. RAB Configuration Indicator For definition of this parameter see clauseÊ7.6.6. This parameter may be included if the call is a speech call and MSC-B knows by means of configuration information that MSC-B' (and MSC-A) supports the use of the Iu-Supported Codecs List parameter. AN-APDU For definition of this parameter see clauseÊ7.6.9. User error For definition of this parameter see clauseÊ7.6.1. The following error causes defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown MSC; - Subsequent handover failure; - Unexpected data value; - Data Missing. Provider error For definition of this parameter see clauseÊ7.6.1. 8.4.6 MAP_ALLOCATE_HANDOVER_NUMBER service 8.4.6.1 Definition This service is used between MSC and VLR (B-interface) to request a handover number. The MAP_ALLOCATE_HANDOVER_NUMBER service is a confirmed service using the primitives from tableÊ8.4/6. 8.4.6.2 Service primitives TableÊ8.4/6: MAP_ALLOCATE_HANDOVER_NUMBER Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) User error C C(=) Provider error O 8.4.6.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. User error For definition of this parameter see clauseÊ7.6.1. The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - No handover number available. Provider error For definition of this parameter see clauseÊ7.6.1. 8.4.7 MAP_SEND_HANDOVER_REPORT service 8.4.7.1 Definition This service is used between VLR and MSC-B (B-interface) to transfer the handover number to be forwarded to and used by MSC-A. The MAP_SEND_HANDOVER_REPORT service is a confirmed service using the primitives from tableÊ8.4/7. 8.4.7.2 Service primitives TableÊ8.4/7: MAP_SEND_HANDOVER_REPORT Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Handover Number M M(=) Linked Id M M(=) Provider error O 8.4.7.3 Parameter use Invoke Id For definition of this parameter see clauseÊ7.6.1. Handover Number For definition of this parameter see clauseÊ7.6.2. Linked Id For definition of this parameter see clauseÊ7.6.1. This service is linked with MAP_ALLOCATE_HANDOVER_NUMBER. Provider error For definition of this parameter see clauseÊ7.6.1. 8.5 Authentication management services 8.5.1 MAP_AUTHENTICATE service The MAP_AUTHENTICATE service is used on the MAP B interface. This interface is not fully operational specified. It is strongly recommended not to implement the B-interface as an external interface. 8.5.1.1 Definition This service is used between the VLR and the MSC when the VLR receives a MAP service indication from the MSC concerning a location registration, call set-up, operation on a supplementary service or a request from the MSC to initiate authentication. The service is a confirmed service and consists of four service primitives. 8.5.1.2 Service primitives The service primitives are shown in tableÊ8.5/1. TableÊ8.5/1: MAP_AUTHENTICATE parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) RAND M M(=) CKSN M M(=) SRES M M(=) Provider error O 8.5.1.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. RAND See clauseÊ7.6.7 for the use of this parameter. CKSN See clauseÊ7.6.7 for the use of this parameter. SRES See clauseÊ7.6.7 for the use of this parameter. Provider error See clauseÊ7.6.1 for the use of this parameter. 8.5.2 MAP_SEND_AUTHENTICATION_INFO service 8.5.2.1 Definition This service is used between the VLR and the HLR for the VLR to retrieve authentication information from the HLR. The VLR requests up to five authentication vectors. Also this service is used between the SGSN and the HLR for the SGSN to retrieve authentication information and/or UE Usage Type from the HLR. The SGSN requests up to five authentication vectors. Also this service is used between the BSF and the HLR for the BSF to retrieve authentication information from the HLR. The BSF shall only request one authentication vector at a time. In an EPS, this service is used between IWF and IWF and between IWF and HSS. If the requesting node type is different from ""MME"" and the user is a UMTS subscriber, the HLR shall return authentication quintuplets. If the requesting node type is different from MME and the user is a GSM subscriber, the HLR shall return authentication triplets. If the requesting node type is ""MME"", the HSS shall return EPS authentication vectors. If the requesting node type is a combined MME/SGSN, the HSS shall return requested authentication vectors for the actual RAT and may return additional authentication vectors for the other RAT. If the HLR cannot provide the VLR, the SGSN or the BSF with triplets, an empty response is returned. The VLR, the SGSN, or the BSF may then re-use old authentication triplets, except where this is forbidden under the conditions specified in 3GPP TS 43.020Ê[24]. If the HLR cannot provide the VLR, the SGSN or the BSF with quintuplets, an empty response is returned. The VLR, the SGSN or the BSF shall not re-use old authentication quintuplets. If the HSS cannot provide the IWF with EPS authentication vectors, an empty response is returned. If the VLR or SGSN or IWF or BSF receives a MAP_SEND_AUTHENTICATION_INFO response containing a User Error parameter as part of the handling of an authentication procedure, the authentication procedure in the VLR or SGSN or MME or BSF shall fail. Security related network functions are further described in 3GPP TS 43.020 [24] and 3GPP TS 33.200. The service is a confirmed service and consists of four service primitives. 8.5.2.2 Service primitives The service primitives are shown in tableÊ8.5/2. TableÊ8.5/2: MAP_SEND_AUTHENTICATION_INFO parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI C C(=) Number of requested vectors C C(=) Requesting node type C C(=) Re-synchronisation Info C C(=) Segmentation prohibited indicator C C (=) Immediate response preferred indicator U C (=) Requesting PLMN ID C C(=) Number of additional requested vectors C C(=) Additional requested Vectors are for EPS C C(=) UE Usage Type Request Indication C C(=) AuthenticationSetList C C(=) UE Usage Type C C(=) User error C C(=) Provider error O 8.5.2.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. IMSI See clauseÊ7.6.2 for the use of this parameter. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Number of requested vectors A number indicating how many authentication vectors the VLR, the SGSN, the MME or the BSF is prepared to receive. The HLR shall not return more vectors than indicated by this parameter. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Requesting node type The type of the requesting node (SGSN, MME, combined MME/SGSN, VLR, or BSF). This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Re-synchronisation Info For definition and use of this parameter see 3GPP TS 33.200. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one.. Segmentation prohibited indicator This parameter indicates if the VLR, the SGSN or the IWF allows segmentation of the response at MAP user level. This parameter may be present only in the first request of the dialogue. Immediate response preferred indicator This parameter indicates that one of the requested authentication vectors is requested for immediate use in the VLR, the SGSN, the MME or the BSF. It may be used by the HLR together with the number of requested vectors and the number of vectors stored in the HLR to determine the number of vectors to be obtained from the AuC. It shall be ignored if the number of available vectors is greater than the number of requested vectors. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Requesting PLMN ID The PLMN-ID of the requesting node. See3GPP TS 23.003. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Number of additional requested vectors A number indicating how many additional authentication vectors the combined MME/SGSN or IWF is prepared to receive. The HLR shall not return more vectors than indicated by this parameter. This parameter shall be present only if the requesting node type is a combined MME/SGSN. A combined MME/SGSN that wants to request only EPS-Vectors (only non-EPS-Vectors) shall set the requesting node type to ""MME"" (""SGSN""). This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. Additional vectors are for EPS This parameter shall be absent if Number of additional vectors is absent. The parameter indicates by its presence that additional vectors (i.e. not for immediate use) are for EPS. This parameter shall be present in the first (or only) request of the dialogue. If multiple service requests are present in a dialogue then this parameter shall not be present in any service request other than the first one. UE Usage Type Request Indication This parameter indicates by its presence that the HLR (if it supports the Dedicated Core Network functionality) shall include the UE Usage Type in the response to the SGSN. This parameter is not applicable for VLRs. AuthenticationSetList A set of one to five authentication vectors are transferred from the HLR to the VLR, from the HLR to the SGSN or IWF or from the HLR to the BSF, if the outcome of the service was successful. UE Usage Type This parameter shall be present if UE Usage Type Request Indication was present in the request and the HLR supports the Dedicated Core Networks functionality (see 3GPP TS 23.060 [104]) and a UE Usage Type is available in the subscription data of the user. In this case, if the Immediate Response Preferred parameter is not set, the HLR may return no authentication vectors in the response. User error One of the following error causes defined in clauseÊ7.6.1 shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason: - unknown subscriber; - unexpected data value; - system failure; - data missing. Provider error See clauseÊ7.6.1 for the use of this parameter. 8.5.3 MAP_AUTHENTICATION_FAILURE_REPORT service 8.5.3.1 Definition This service is used between the VLR and the HLR or between the SGSN or HLR for reporting of authentication failures. 8.5.3.2 Service primitives The service primitives are shown in tableÊ8.5/3. TableÊ8.5/3: MAP_AUTHENTICATION_FAILURE_REPORT parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) Failure cause M M(=) Re-attempt M M(=) Access Type M M(=) Rand M M(=) VLR number C C(=) SGSN number C C(=) User error C C(=) Provider error O 8.5.3.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. IMSI See clauseÊ7.6.2 for the use of this parameter. Failure Cause See clauseÊ7.6.7 for use of this parameter. Re-attempt See clause 7.6.7 for use of this parameter. Access Type See clause 7.6.7 for use of this parameter. Rand This parameter identifies the specific AV that failed authentication. See clause 7.6.7 for use of this parameter. VLR number Shall be present if the sender is VLR. See definition in clauseÊ7.6.2. SGSN number Shall be present if the sender is SGSN. See definition in clause 7.6.2. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - Unknown Subscriber; - System Failure; - Unexpected Data Value. Provider error These are defined in clauseÊ7.6. 8.6 Security management services 8.6.1 MAP_SET_CIPHERING_MODE service 8.6.1.1 Definitions This service is used between the VLR and the MSC to set the ciphering mode and to start ciphering if applicable. It is called when another service requires that information is to be sent on the radio path in encrypted form. The service is a non-confirmed service and consists of two service primitives. 8.6.1.2 Service primitives The service primitives are shown in tableÊ8.6/1. TableÊ8.6/1: MAP_SET_CIPHERING_MODE parameters Parameter name Request Indication Invoke id M M(=) Ciphering mode M M(=) Kc C C(=) 8.6.1.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. Ciphering mode See clauseÊ7.6.7 for the use of this parameter. Kc The Kc parameter should be included when the ciphering mode parameter indicates that ciphering must be performed. 8.7 International mobile equipment identities management services 8.7.1 MAP_CHECK_IMEI service 8.7.1.1 Definition This service is used between the VLR and the MSC, between the MSC and the EIR, between the SGSN and EIR, and between IWF and EIR to request check of IMEI."
"If the IMEI is not available in the MSC or in the SGSN, it is requested from the MS and transferred to the EIR in the service request. This service may also be used to request the BMUEF from the EIR. The service is a confirmed service and consists of four service primitives. 8.7.1.2 Service primitives The service primitives are shown in tableÊ8.7/1. TableÊ8.7/1: MAP_CHECK_IMEI parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMEI C C(=) C C(=) IMEISV C C(=) C(=) C(=) Requested Equipment Info M M(=) Equipment status C C(=) BMUEF C C(=) User error C C(=) Provider error O 8.7.1.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. Requested Equipment Info This parameter indicates whether Equipment Status or BMUEF or both is requested. IMEI See clauseÊ7.6.2 for the use of this parameter. The parameter shall not be included in the service request between the VLR and the MSC, but one of IMEI and IMEISV is mandatory in the service request from the MSC to the EIR, from the SGSN to the EIR and from the IWF to the EIR. It is not included in the service response from the EIR to the MSC, the SGSN or the IWF, but one of IMEI and IMEISV is mandatory in the service response from the MSC to the VLR on successful outcome. IMEISV See clauseÊ7.6.2 for the use of this parameter. IMEISV shall be present if BMUEF is requested. Equipment status See clauseÊ7.6.3 for the use of this parameter. This parameter is sent by the responder in case of successful outcome of the service if Equipment status was requested. BMUEF See clauseÊ7.6.4 for the use of this parameter. This parameter is sent by the responder in case of successful outcome of the service if BMUEF was requested. User error One of the following error causes defined in clauseÊ7.6.1 shall be sent by the user in case of unsuccessful outcome of the service, depending on the respective failure reason: - unknown equipment; this error is returned by the responder when the IMEI is not known in the EIR; - system failure; - data missing. Provider error See clauseÊ7.6.1 for the use of this parameter. 8.7.2 MAP_OBTAIN_IMEI service 8.7.2.1 Definition This service is used between the VLR and the MSC to request the IMEI. If the IMEI is not available in the MSC, it is requested from the MS. The service is a confirmed service and consists of four service primitives. 8.7.2.2 Service primitives The service primitives are shown in tableÊ8.7/2. TableÊ8.7/2: MAP_OBTAIN_IMEI parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMEI C C(=) User error C C(=) Provider error O 8.7.2.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. IMEI See clauseÊ7.6.2 for the use of this parameter. The parameter is included in the service response from the MSC to the VLR on successful outcome of the service. User error If the service fails, the VLR sends the user error System Failure (see clauseÊ7.6.1) to the MSC. Provider error See clauseÊ7.6.1 for the use of this parameter. 8.8 Subscriber management services 8.8.1 MAP-INSERT-SUBSCRIBER-DATA service 8.8.1.1 Definition This service is used by an HLR to update a VLR with certain subscriber data in the following occasions: - the operator has changed the subscription of one or more supplementary services, basic services or data of a subscriber. Note that in case of withdrawal of a Basic or Supplementary service this primitive shall not be used; - the operator has applied, changed or removed Operator Determined Barring; - the subscriber has changed data concerning one or more supplementary services by using a subscriber procedure; - the HLR provides the VLR with subscriber parameters at location updating of a subscriber or at restoration. In this case, this service is used to indicate explicitly that a supplementary service is not provisioned, if the supplementary service specification requires it. The only supplementary services which have this requirement are the CLIR and COLR services. Network access mode is provided only in restoration. If the Super-Charger functionality is supported the HLR may not need to provide the VLR with subscriber parameters at location updating of a subscriber. See TS 23.116. Also this service is used by an HLR to update an SGSN with certain subscriber data in the following occasions: - if the GPRS subscription has changed; - if the network access mode is changed; - the operator has applied, changed or removed Operator Determined Barring; - the subscriber has changed data concerning one or more supplementary services by using a subscriber procedure; - the HLR provides the SGSN with subscriber parameters at GPRS location updating of a subscriber. If the Super Charger functionality is supported the HLR may not need to provide the SGSN with subscriber parameters. See 3GPP TS 23.116. Also this service is used by a CSS to update an SGSN or a VLR with VPLMN-CSG-Subscription data in the following occasions: - if the VPLMN-CSG subscription data has changed; - the CSS provides the VLR or SGSN with VPLMN-CSG subscription data at VCSG location updating of a subscriber. In an EPS, this service is used by an HSS to update an MME via IWF with certain subscriber data in the following occasions: - the EPS subscription has changed; - the operator has applied, changed or removed Operator Determined Barring; - the HSS provides the MME via IWF(MME) with subscriber parameters at EPS location updating of a subscriber unless an explicit indication to skip subscriber data update has been received. In an EPS, this service is used by an IWF to indicate to the MME via IWF that the HSS has requested to be notified when the UE has become reachable. It is a confirmed service and consists of the primitives shown in tableÊ8.8/1. 8.8.1.2 Service primitives TableÊ8.8/1: MAP-INSERT-SUBSCRIBER-DATA Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI C C(=) MSISDN C C(=) Additional MSISDN C C(=) Category C C(=) Subscriber Status C C(=) Bearer service List C C(=) C C(=) Teleservice List C C(=) C C(=) Forwarding information List C C(=) Call barring information List C C(=) CUG information List C C(=) SS-Data List C C(=) eMLPP Subscription Data C C(=) MC-Subscription Data C C(=) Operator Determined Barring General data C C(=) C C(=) Operator Determined Barring HPLMN data C C(=) Roaming Restriction Due To Unsupported Feature C C(=) Regional Subscription Data C C(=) VLR CAMEL Subscription Info C C(=) Voice Broadcast Data C C(=) Voice Group Call Data C C(=) Network access mode C C(=) GPRS Subscription Data C C(=) EPS Subscription Data C C(=) VPLMN LIPA Allowed C C(=) Roaming Restricted In SGSN/MME Due To Unsupported Feature C C(=) North American Equal Access preferred Carrier Id List U C(=) SGSN CAMEL Subscription Info C C(=) LSA Information C C(=) IST Alert Timer C C(=) SS-Code List C C(=) LMU Identifier C C(=) LCS Information C C(=) CS Allocation/Retention priority C C(=) Super-Charger Supported In HLR C C(=) Subscribed Charging Characteristics C C(=) Access Restriction Data C C(=) ICS Indicator U C(=) CSG Subscription Data C C(=) VPLMN CSG Subscription Data C C(=) UE Reachability Request Indicator C C(=) SGSN Number C C(=) MME-Name C C(=) Subscribed Periodic RAU-TAU Timer C C(=) Subscribed Periodic LAU Timer C C(=) MDT User Consent C C(=) PS and SMS-Only Service Provision C C(=) SMS in SGSN Allowed C C(=) CS-to-PS-SRVCC-Allowed-Indicator C C(=) P-CSCF Restoration Request C C(=) Adjacent Access Restriction Data C C(=) IMSI-Group-Id List C C(=) UE Usage Type C C(=) User Plane Integrity Protection Indicator C C(=) DL-Buffering Suggested Packet Count C C(=) Reset-IDs C C(=) eDRX-Cycle-Length List C C(=) IAB-Operation-Allowed-Indicator C C(==) Regional Subscription Response C C(=) Supported CAMEL Phases C C (=) Offered CAMEL 4 CSIs C C (=) Supported Features U C (=) User error U C(=) Provider error O 8.8.1.3 Parameter use All parameters are described in clauseÊ7.6. The following clarifications are applicable: Network access mode This parameter defines if the subscriber has access to MSC/VLR and/or to SGSN/MME. This parameter is used by SGSN/MME and MSC/VLR. In VLR, the parameter is used only as part of Restore Data Procedure and the parameter is not stored in the VLR. This parameter shall always be sent to the SGSN and viaIWF to the MME as part of the GPRS subscriber data at GPRS/MME location updating. It shall be sent to the SGSN and via IWF to the MME if it is changed as a result of administrative action. This parameter shall not be used by the CSS. IMSI It is only included if the service is not used in an ongoing transaction (e.g. location updating). This parameter is used by the VLR and the SGSN and IWF. MSISDN For subscriptions with MSISDN: It is included at location updating and when it is changed. The MSISDN sent shall be the basic MSISDN. This parameter is used by the VLR and the SGSN and IWF. For a subscription without MSISDN: The HLR shall not populate this parameter if the VLR or SGSN explicitly indicated support of MSISDN-less operation. NOTE 1: See clauses 8.1.2.3 and 8.1.7.3 for the case where the VLR or SGSN does not support MSISDN-less operation. Additional MSISDN If subscribed, the Additional MSISDN is included at location updating and when it is changed. This parameter is used by the SGSN and IWF. This parameter shall be ignored by the VLR if received. If the SGSN does not indicate support of the feature the HSS shall not send the parameter. Category It is included either at location updating or when it is changed. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. Subscriber Status It is included either at location updating or when it is changed. To apply, remove or update Operator Determined Barring Categories the Subscriber Status is set to Operator Determined Barring. In this case ODB General Data shall also be present. If the Operator Determined Barring applies and the subscriber is registered in the HPLMN and HPLMN specific Operator Determined Barring applies then ODB HPLMN Specific Data shall also be present. To remove all Operator Determined Barring Categories the Subscriber Status shall be set to ""Service Granted"". This parameter is used by the VLR and the SGSN and IWF. This parameter shall not be used by the CSS. Bearer service List A list of Extensible Bearer service parameters (Extensible Bearer service is defined in clauseÊ7.6). An Extensible Bearer service parameter must be the code for an individual Bearer service, except in the cases described below. The codes for the Bearer service groups ""allAlternateSpeech-DataCDA"" and ""allAlternateSpeech-DataCDS"" shall, if applicable, be sent from the HLR to the VLR as a pair. The codes for the Bearer service groups ""allSpeechFollowedByDataCDA"" and ""allSpeechFollowedByDataCDS"" shall, if applicable, be sent from the HLR to the VLR as a pair. If it is included in the Request/Indication, it includes either all Extensible Bearer services subscribed (at location updating or at restoration) or only the ones added (at subscriber data modification). If the VLR receives an Indication containing any Extensible Bearer service parameters which it does not support/allocate it returns them in the response to the HLR and discards the unsupported Extensible Bearer services (no error is sent back), except in the cases described below. If the VLR receives the codes for the Bearer service groups ""allSpeechFollowedByDataCDA"" and ""allSpeechFollowedByDataCDS"" and supports one or more of the circuit-switched synchronous or asynchronous data rates specified for simple data bearer services, it shall accept the bearer service codes, and not return them in the response to the HLR. If the VLR does not support any of the circuit-switched synchronous or asynchronous data rates specified for simple data bearer services, and receives the pair of codes for ""allAlternateSpeech-DataCDA"" and ""allAlternateSpeech-DataCDS"" or the pair of codes for ""allSpeechFollowedByDataCDA"" and ""allSpeechFollowedByDataCDS"", it shall reject the pair of codes by returning them in the response to the HLR. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Teleservice List A list of Extensible Teleservice parameters (Extensible Teleservice is defined in clauseÊ7.6). An Extensible Teleservice parameter must be the code for an individual Teleservice. If it is included in the Request/Indication, it contains either all Extensible Teleservices subscribed (at location updating or at restoration) or the ones added (at subscriber data modification). Only the Extensible Teleservices that are relevant to the node at which the message is received should be included in the Teleservice List. If the VLR or the SGSN or the IWF receives an Indication containing any Extensible Teleservice parameters which it does not support/allocate it returns them in the response to the HLR and discards the unsupported Extensible Teleservices (no error is sent back). This parameter is used by the VLR and the SGSN and the IWF. This parameter shall not be used by the CSS. Forwarding information List A list of Extensible Forwarding information parameters (Extensible Forwarding information is defined in clauseÊ7.6). It includes Call Forwarding services either at location updating or at restoration or when they are changed. Each Extensible Forwarding information parameter shall be treated independently of all other parameters in the primitive. The Extensible Forwarding information shall include the SS-Code for an individual call forwarding supplementary service. The Extensible Forwarding information shall contain one or more Extensible Forwarding Features (Extensible Forwarding Feature is defined in clauseÊ7.6). The Extensible Forwarding Feature may include an Extensible Basic Service Group. This shall be interpreted according to the rules in clauseÊ8.8.1.4. The Extensible Forwarding Feature shall contain an Extensible SS-Status parameter. If the Extensible SS-Status indicates that call forwarding is registered then (except for call forwarding unconditional) the Extensible Forwarding Feature shall contain a number to define the forwarded-to destination and, if available, the forwarded-to subaddress. In other states the forwarded-to number and, if applicable, the forwarded-to subaddress shall not be included. For call forwarding unconditional the forwarded-to number and, if applicable, the forwarded-to subaddress shall not be included. If the VLR does not receive a forwarded-to subaddress then it shall assume that a forwarded-to subaddress has not been registered. The Extensible Forwarding Feature shall contain the extensible forwarding options (except for call forwarding unconditional where the extensible forwarding options shall not be included). Bits 3 and 4 of the extensible forwarding options shall be ignored by the VLR, and may be set to any value by the HLR. For call forwarding on no reply: If the extensible SS-Status indicates that call forwarding is registered then the Extensible Forwarding Feature shall contain an extensible no reply condition timer. In other states the no reply condition timer shall not be included. For call forwarding services other than call forwarding on no reply: The Extensible Forwarding Feature shall not contain a no reply condition timer. If the VLR receives an Indication containing any Call Forwarding service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and discards the unsupported Call Forwarding service codes (noÊerror is sent back). This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Call barring information List A list of Extensible Call barring information parameters (Extensible Call barring information is defined in clauseÊ7.6). It includes Call Barring services either at location updating or at restoration or when they are changed. Each Extensible Call barring information parameter shall be treated independently of all other parameters in the primitive. The Extensible Call barring information shall include the SS-Code for an individual call barring supplementary service. The Extensible Call barring information shall contain one or more Extensible Call Barring Features (Extensible Call Barring Feature is defined in clauseÊ7.6). The Extensible Call Barring Feature may include an Extensible Basic Service Group. This shall be interpreted according to the rules in clauseÊ8.8.1.4. The Extensible Call Barring Feature shall contain an extensible SS-Status parameter. If the VLR or the SGSN or the IWF receives an Indication containing any Extensible Call Barring service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and discards the unsupported Extensible Call Barring service codes (no error is sent back). This parameter shall not be used by the CSS. CUG information List A list of CUG information list parameters (CUG information is defined in clauseÊ7.6). It includes CUG information either at location updating or at restoration or when it is changed. At location updating, restoration or when there is a change in CUG data, the HLR shall include the complete CUG SubscriptionList and, if there are options per basic group, it shall also include the complete CUG-FeatureList. If there are not options per extensible basic service group the CUG-FeatureList shall not be included. In any dialogue, the first insertSubscriberData message which contains CUG information shall include a non-empty CUG-SubscriptionList. When the VLR receives CUG data it shall replace the stored CUG data with the received data set. If CUG-FeatureList is omitted in the Insert Subscriber Data operation VLR shall interpret that no options per extensible basic service group exist, and then it shall apply the default values i.e. no outgoing access, no incoming access, no preferential CUG exists. If CUG-Feature is received without preferential CUG, the VLR shall interpret that no preferential CUG applies. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. Note that data consistency between CUG subscription data and CUG feature data is the responsibility of the HLR. If the VLR does not support the CUG service it returns its code to the HLR in the parameter SS-Code List and discards the received information (no error is sent back). This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. SS-Data List A list of Extensible SS-Data parameters (Extensible SS-Data is defined in clauseÊ7.6). It is sent for any other supplementary service than Call Forwarding, Call Barring, CUG and eMLPP either at location updating or at restoration or when they are changed. Each SS-Data parameter shall be treated independently of all other parameters in the primitive. The Extensible SS-Data shall include the SS-Code for an individual supplementary service. The Extensible SS-Data shall contain an Extensible SS-Status parameter and any subscription options that are applicable to the service defined by the SS-Code. The SS-Data may include a Basic Service Group List. This shall be interpreted according to the rules in clauseÊ8.8.1.4. If the VLR receives an Indication containing any supplementary service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and therefore discards the unsupported service codes received (no error is sent back). This parameter is used by the SGSN only for LCS. If the SGSN receives an Indication containing any LCS related supplementary service codes which it does not support/allocate it returns them to the HLR in the parameter SS-Code List and therefore discards the unsupported service codes received (no error is sent back). SS-codes not related to the supported LCS capability set shall be discarded. If the IWF receives an Indication containing any LCS related supplementary service codes, it returns them to the HSS in the parameter SS-Code List and therefore discards the service codes received (no error is sent back). SS-codes not related to the supported LCS capability set shall be discarded. This parameter shall not be used by the CSS. Operator Determined Barring General data If it is included in a Request/Indication, it includes all the Operator Determined Barring categories that may be applied to a subscriber registered in any PLMN. This parameter is only included in a Request/Indication when the parameter Subscriber Status is set to the value Operator Determined Barring. Note that all General Operator Determined Barring Categories shall be set to their actual status. If the VLR or the SGSN or IWF receives an Indication containing Operator Determined Barring General Data which shows that the subscriber is subject to barring not supported / not allocated by the VLR or by the SGSN, it returns Operator Determined Barring General Data in the response to the HLR to show the barring categories which are not supported / not allocated by the VLR or by the SGSN. This parameter is used by the VLR and the SGSN and IWF. This parameter shall not be used by the CSS. Operator Determined Barring HPLMN data It includes all the Operator Determined Barring categories that may be applied only to a subscriber registered in the HPLMN. Therefore, it shall only be transferred to the VLR or to the SGSN or IWF when the subscriber is roaming into the HPLMN and when the parameter Subscriber Status is set to the value Operator Determined Barring. Note that all HPLMN Operator Determined Barring Categories shall be set to their actual status. If Subscriber Status is set to the value Operator Determined Barring and no Operator Determined Barring HPLMN data is present then the VLR or the SGSN or IWF shall not apply any HPLMN specific ODB services to the subscriber. This parameter is used by the VLR and the SGSN and IWF. This parameter shall not be used by the CSS. eMLPP Subscription Data If included in the Insert Subscriber Data request this parameter defines the priorities the subscriber might apply for a call (as defined in clause 7.6). It contains both subparameters of eMLPP. If the VLR does not support the eMLPP service it returns its code to the HLR in the parameter SS-Code List and therefore discards the received information (no error is sent back). eMLPP subscription data that have been stored previously in a subscriber data record in the VLR are completely replaced by the new eMLPP subscription data received in a MAP_INSERT_SUBSCRIBER_DATA during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. MC Subscription Data If included in the Insert Subscriber Data request, this parameter provides the MC Subscription Data as defined in clauseÊ7.6. If the VLR does not support the MC service, it returns its code to the HLR in the parameter SS-Code List and therefore discards the received information (no error is sent back). MC subscription data that have been stored previously in a subscriber data record in the VLR are completely replaced by the new MC subscription data received in a MAP_INSERT_SUBSCRIBER_DATA during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Roaming Restriction Due To Unsupported Feature The HLR may decide to include this parameter in the request if certain services or features are indicated as not supported by the MSC/VLR (e.g. Advice of Charge Charging Level). If this parameter is sent to the VLR the MSC area is restricted by the HLR and the VLR. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Regional Subscription Data If included in the Insert Subscriber Data request this parameter defines the subscriber's subscription area for the addressed VLR, for the addressed SGSN or for the addressed MME (as defined in clauseÊ7.6). It contains the complete list of up to 10 Zone Codes that apply to a subscriber in the currently visited PLMN. The HLR shall send only those Zone Codes which are stored against the CC and NDC of the VLR, the SGSN or the MME to be updated. NOTE 2: Support of this parameter is a network operator option and it will not be sent to networks which do not support Regional Subscription. Regional subscription data that have been stored previously in a subscriber data record in the VLR, in the SGSN or in the MME are completely replaced by the regional subscription data received in an Insert Subscriber Data indication during either an Update Location or Restore Data procedure or a stand alone Insert Subscriber data procedure. After the regional subscription data are inserted the VLR or the SGSN shall derive whether its location areas are allowed or not. If the whole MSC or SGSN area is restricted it will be reported to HLR by returning the Regional Subscription Response. The VLR or the SGSN returns a Regional Subscription Response indicating that a problem with the Zone Code has been detected in one of the following cases: - Too Many Zone Codes: more than 10 Zone Codes are to be stored in the VLR or in the SGSN. - Regional Subscription Not Supported by the VLR or the SGSN. - Zone Codes Conflict: the VLR or the SGSN detects that the zone codes indicate conflicting service permission for a location area. Zone codes which have no mapping to location areas shall be ignored. If a sequence of MAP_INSERT_SUBSCRIBER_DATA services is used during a dialogue, Regional Subscription Data shall be accepted only in one service. Regional Subscription Data received in a subsequent service shall be rejected with the error Unexpected Data Value. If Regional Subscription Data are not included in any MAP_INSERT_SUBSCRIBER_DATA service, there is no restriction of roaming due to Regional Subscription. This parameter is used by the VLR, the SGSN and the IWF. This parameter shall not be used by the CSS. Voice Broadcast Data This parameter contains a list of group id's a user might have subscribed to; (VBS-Data is defined in clause 7.6). It includes VBS information either at location updating or at restoration or when it is changed. At location updating, restoration or when there is a change in VBS data, the HLR shall include the complete VBS-Data. When the VLR receives VBS-Data within a dialogue it shall replace the stored VBS-data with the received data set. All subsequent VBS-data received within this dialogue shall be interpreted as add-on data. If VBS-data is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VBS data. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Voice Group Call Data This parameter contains a list of group id's a user might have subscribed to; see clause 7.6. At location updating, restoration or when there is a change in VGCS data, the HLR shall include the complete VGCS Data. When the VLR receives VGCS-Data within a dialogue it shall replace the stored VGCS-Data with the received data set. All VGCS-Data received within this dialogue shall be interpreted as add-on data. If VBCS-Data is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VGCS-Data. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. North American Equal Access preferred Carrier Id List A list of the preferred carrier identity codes that are subscribed to. When the VLR receives this parameter from the HLR, it shall replace the previously stored preferred carrier identity codes with the received ones. It is not possible to delete all the preferred carrier identity codes from the VLR using this service. To delete all the preferred carrier identity codes from the VLR, the HLR shall use the MAP_CANCEL_LOCATION service. This parameter shall not be used by the CSS. LSA Information If included in the ISD request, this parameter contains a list of localised service area identities a user might have subscribed to together with the priority, the preferential access indicator, the active mode support indicator and active mode indication of each localised service area; see clause 7.6. The access right outside these localised service areas is also indicated. In all cases mentioned below, the LSA information shall only include LSA Data applicable to the VPLMN where the Subscriber is located. The VLR number, received in the MAP-UPDATE_LOCATION primitive, or the SGSN number, received in the MAP_UPDATE_GPRS_LOCATION primitive, can be used, alongside data stored in the HLR, to determine the LSA Data applicable to the VPLMN. At restoration, location updating or GPRS location updating the HLR shall include the complete set of applicable LSA Information. When there is a change in LSA data the HLR shall include at least the new and/or modified LSA data. When there is a change in the access right outside the localised service areas the HLR shall include the LSA only access indicator. When the SGSN or the VLR receives LSA information within a dialogue it shall check if the received data has to be considered as the entire LSA information. If so, it shall replace the stored LSA information with the received data set, otherwise it shall replace the data only for the modified LSA data (if any) and/or access right, and add the new LSA data (if any) to the stored LSA Information. If the entire LSA information is received, it shall always include the LSA only access indicator value together with the LSA data applicable for the PLMN (if any). If LSA Information is omitted in the Insert Subscriber Data operation the SGSN or the VLR shall keep the previously stored LSA Information. If the SGSN or the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used by the VLR and the SGSN, and if the IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. IST Alert Timer This parameter contains the IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs. At Location Updating, restoration, or when there is a change in the IST data defined for the Subscriber, the HLR shall include the IST Alert timer. This parameter shall not be used by the CSS. LMU Identifier This parameter indicates the presence of an LMU. This parameter is used only by the VLR and shall be ignored if received by an SGSN or an IWF. This parameter shall not be used by the CSS. LCS Information This parameter provides the following LCS related information for an MS subscriber: - list of GMLCs in the HPLMN; - privacy exception list; - MO-LR list. At restoration and location updating, the HLR shall include the complete LCS data of the subscriber. When there is a change in LCS subscriber data the HLR shall include at least the new and/or modified LCS data. LCS data that is not modified need not be included. The VLR/SGSN shall keep any previously stored LCS Information that is not included in an Insert Subscriber Data operation. If the VLR/SGSN detects that there is overlapping in the LCS information received within a dialogue, it shall send the error Unexpected Data Value. However, if the VLR receives the LCS code in both the LCS Information and the SS Data List, then the VLR shall not interpret this as overlapping data. This parameter is used by the VLR and the SGSN and the IWF. This parameter shall not be used by the CSS. Super-Charger Supported In HLR This parameter is used by the HLR to indicate support for the Super-Charger functionality. If this parameter is present it shall include an indication of the age of the subscription data stored in the HLR. If this parameter is absent then the HLR does not support the Super-Charger functionality. This parameter shall not be used by the CSS. SS-Code List The list of SS-Code parameters for the services that are provided to a subscriber but are not supported/allocated by the VLR/SGSN/IWF (SS-Code is defined in clauseÊ7.6). The list can only include individual SS-Codes that were sent in the service request. For the VLR, this list can also include SS-Codes for the eMLPP and/or CUG services if the above mentioned conditions, as described in eMLPP Subscription Data and/or CUG information List, are met (that is, eMLPP Subscription Data and/or CUG information List are received). This parameter shall not be used by the CSS. ICS-Indicator This optional flag indicates to the MSC Server enhanced for ICS (see 3GPP TS 23.292 [135]) whether the MSC Server shall attempt the IMS registration. This parameter is used by the VLR and the SGSN. This parameter shall not be used by the CSS. CSG-Subscription Data This parameter contains a list of CSG-Ids, the associated expiration dates (see 3GPP TS 22.011 [138]) and a list of corresponding APNs (see 3GPP TS 29.272 [144]. When the VLR or SGSN or MME receives CSG-Subscription Data from the HLR/HSS it shall replace the stored CSG-Subscription Data from the HLR/HSS (if any) with the received data. This parameter is used by the VLR and the SGSN and IWF, except the list of corresponding APNs is not applicable to the VLR, and the VLR shall ignore this list if it is received. This parameter shall not be used by the CSS. VPLMN CSG Subscription Data This parameter contains a list of CSG-Ids, the associated expiration dates (see 3GPP TS 22.011 [138]). When the VLR or SGSN or MME receives VPLMN CSG Subscription Data from the CSS, it shall replace the stored VPLMN-CSG Subscription Data from the CSS (if any) with the received VPLMN CSG Subscription data. This parameter is used by the VLR, the SGSN and MME. This parameter is not applicable for the HLR/HSS, and the VLR or SGSN or IWF shall ignore this parameter if it is received from the HLR/HSS. CSG Subscription Data from the HLR/HSS and VPLMN CSG Subscription Data from the CSS are managed independently in the VLR or SGSN or MME. If the same CSG Id exists in both CSG subscription data from the CSS and CSG subscription data from the HLR/HSS, the CSG subscription data from the HLR/HSS shall take precedence over the CSG subscription data from the CSS in further use. UE Reachability Request Indicator This parameter indicates by its presence that the HSS is awaiting a Notification of UE Reachability. This parameter is used by the IWF only. This parameter shall not be used by the CSS. MME Name This parameter contains the MME identity used over the SGs interface (see 3GPP TS 23.003 [17] clause 19.4.2.4) when stored in the HSS. Otherwise this parameter contains the Diameter Identity of the MME (see 3GPP TS 23.003 [17]). If the subscriber is registered to EPS and the length of the MME Name does not exceed 55 octets, the HLR shall send the MME Name to the VLR during the data restoration procedure if the 'Restoration Indicator' is set in the MAP_RESTORE_DATA request, and during an Update Location procedure if the 'Restoration Indicator' is set in the MAP_UPDATE_LOCATION request. This parameter may be used by the MSC/VLR, e.g. to page the UE via SGs. This parameter shall not be used by the CSS. Subscribed Periodic RAU-TAU Timer This parameter contains the subscribed periodic RAU/TAU timer (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]) and is used by the SGSN and MME (via IWF). The SGSN and MME shall handle the Subscribed Periodic RAU-TAU Timer as specified in clause 5.2.1.1.2 of 3GPP TS 29.272 [144]. If the VLR receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Subscribed Periodic LAU Timer This parameter contains the subscribed periodic LAU timer value (see 3GPP TS 23.012 [23]) and is used by the MSC/VLR. The MSC/VLR shall handle the Subscribed Periodic LAU Timer as specified in clause 3.7.3 of 3GPP TS 23.012 [23]. If the SGSN receives this parameter it shall ignore it. This parameter shall not be used by the CSS. SGSN Number This parameter contains the Identity of the SGSN (see 3GPP TS 23.003 [17])."
"If the subscriber is registered to GPRS, the HLR shall send the SGSN Number if available to the VLR during the data restoration procedure if the 'Restoration Indicator' is set in the MAP_RESTORE_DATA request, and during an Update Location procedure if the 'Restoration Indicator' is set in the MAP_UPDATE_LOCATION request. This parameter may be used by the MSC/VLR, e.g. to page the UE via Gs. This parameter shall not be used by the CSS. MDT User Consent This parameter indicates the user consent availability for MDT activation, see 3GPP TS 32.422 [132]. This parameter is used by the VLR, the SGSN and the IWF. This parameter shall not be used by the CSS. PS and SMS-only Service Provision This parameter indicates whether the subscription is for PS Only and permits CS service access only for SMS. SMS in SGSN Allowed This parameter indicates whether the HSS allows SMS to be provided by SGSN over NAS. User Plane Integrity Protection Indicator This parameter indicates by its presence that the SGSN may decide to activate integrity protection of the user plane when GERAN is used (see 3GPP TS 43.020 [24]). If the VLR receives this parameter it shall ignore it. DL-Buffering Suggested Packet Count This parameter indicates a suggested DL-Buffering Packet Count. The MME (via IWF) and SGSN may take it into account in addition to local policies, to determine whether to invoke extended buffering of downlink packets at the SGW for High Latency Communication. Otherwise, the MME or SGSN shall make this determination based on local policies only (see 3GPP TS 29.272 [144]). If the VLR receives this parameter it shall ignore it. Reset-IDs This parameter contains a list of subscribed Reset-IDs. eDRX-Cycle-Length List This list shall contain the subscribed eDRX cycle length, along with the RAT type to which it is applicable. IAB-Operation-Allowed-Indicator This parameter indicates by its presence that IAB operation is authorized for the UE. See 3GPPÊTSÊ401Ê[145]. Regional Subscription Response If included in the response this parameter indicates one of: - Network Node Area Restricted entirely because of regional subscription; - Too Many Zone Codes to be inserted; - Zone Codes Conflict; - Regional Subscription not Supported by the VLR or by the SGSN or MME. If the VLR determines after insertion of Regional Subscription Data that the entire MSC area is restricted, the VLR shall respond with a Regional Subscription Response indicating MSC Area Restricted. Otherwise MSC Area Restricted is not sent. The HLR shall check whether the current MSC area is no longer restricted. If the SGSN determines after insertion of Regional Subscription Data that the entire SGSN area is restricted, the SGSN shall respond with a Regional Subscription Response indicating SGSN Area Restricted. Otherwise SGSN Area Restricted is not sent. The HLR shall check whether the current SGSN area is no longer restricted. This parameter is used by the VLR, the SGSN and the IWF. This parameter shall not be used by the CSS. VLR CAMEL Subscription Info This parameter is sent for subscribers who have CAMEL services which are invoked in the MSC. - In CAMEL phase 1, this parameter contains only the O-CSI. - In CAMEL Phase 2, this parameter may contain O-CSI, SS-CSI and TIF-CSI. In CAMEL Phase 2 and onwards, TDP-Criteria for O-CSI may be associated with O-CSI. - In CAMEL Phase 3, this parameter may contain O-CSI, D-CSI, SS-CSI, VT-CSI, MO-SMS-CSI, M-CSI and TIF-CSI. In CAMEL Phase 3 and onwards, TDP-Criteria for VT-CSI may be associated with VT-CSI. - In CAMEL Phase 4, this parameter may contain O-CSI, D-CSI, SS-CSI, VT-CSI, MO-SMS-CSI, MT-SMS-CSI, M-CSI and TIF-CSI. In CAMEL Phase 4, TDP-Criteria for MT-SMS-CSI may be associated with MT-SMS-CSI. The VLR CAMEL Subscription Info is sent at location updating or when any information in the applicable CAMEL Subscription Info in the HLR has been changed. At location updating, the complete set of VLR CAMEL Subscription Info is sent in one dialogue. When CAMEL Subscription Information is changed in the HLR and changed data have to be sent to the VLR, then: - for CAMEL Phase 1 and CAMEL Phase 2, the complete set of VLR CAMEL Subscription Info is sent in one dialogue; - for CAMEL Phase 3 or higher, one or more specific elements of VLR CAMEL Subscription Info are sent in one dialogue. When the VLR receives a specific element of VLR CAMEL Subscription Info, it shall overwrite the corresponding specific element of VLR CAMEL Subscription Info (if any) which it has stored for that subscriber. For CAMEL Phase 1 and CAMEL Phase 2 , the VLR CAMEL Subscription Info consists of any one or more of: - O-CSI (irrespective of the value of the ""CAMEL Capability Handling"" inside O-CSI),TDP-Criteria for O-CSI,SS-CSI and TIF-CSI. (The complete set of above shall be sent even if only one CSI has changed in case of stand alone ISD. The omitted elements of above list will be withdrawn in the VLR.) From CAMEL phase 3 onwards, the specific elements of VLR CAMEL Subscription Info which may be sent are: O-CSI (irrespective of the value of the ""CAMEL Capability Handling"" inside O-CSI), TDP criteria for O-CSI, SS-CSI and TIF-CSI; (The complete set of above shall be sent even if only one CSI has changed in case of stand alone ISD. The omitted elements of above list will be withdrawn in the VLR.) - D-CSI; - VT-CSI; - TDP-Criteria for VT-CSI; - MO-SMS-CSI; - MT-SMS-CSI; - TDP-Criteria for MT-SMS-CSI; - M-CSI. If the VLR CAMEL Subscription Info is omitted in the Insert Subscriber Data operation the VLR shall keep the previously stored VLR CAMEL Subscription Info. Within one dialogue subsequent received data are interpreted as add-on data. If the VLR detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. The VLR CAMEL Subscription Info may contain the TIF-CSI (Translation Information Flag) for CAMEL Phase 2 and higher. See 3GPP TS 23.072 for the use of this parameter and the conditions for its presence. This parameter shall not be used by the CSS. Supported CAMEL Phases The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. This parameter is used by the VLR and SGSN. A VLR or SGSN not supporting any CAMEL Phase may omit this parameter. An IWF shall omit this parameter. This parameter shall not be used by the CSS. GPRS Subscription Data This parameter contains a list of PDP-contexts a user has subscribed to; see clause 7.6. At GPRS location updating the HLR shall include the complete GPRS Subscription Data. When there is a change in GPRS subscriber data the HLR shall include only the new and/or modified PDP contexts. When the SGSN receives GPRS Subscription Data within a dialogue it shall check if the received data has to be considered as the entire GPRS subscription data. If so, it shall replace the stored GPRS Subscription Data with the received data set, otherwise it shall replace the data only for the modified PDP contexts (if any) and add the new PDP contexts (if any) to the stored GPRS Subscription Data. If GPRS Subscription Data is omitted in the Insert Subscriber Data operation the SGSN shall keep the previously stored GPRS Subscription Data. If the SGSN detects that there is overlapping in the information received within a dialogue, it shall send the error Unexpected Data Value. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it. The SGSN shall handle the SIPTO-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the SIPTO-Local-Network-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the LIPA Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the Restoration-Priority information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. This parameter shall not be used by the CSS. EPS Subscription Data This parameter contains: - the UE level APN-OI Replacement (see 3GPP TS 23.401 [145]), and - the Subscriber Profile ID for RAT/Frequency Priority (RFSP-ID) (see 3GPP TS 23.401 [145], 3GPP TS 36.413 [147] and 3GPP TS 23.060 [104]), and - the AMBR (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]), and - a list of APN Configurations, - a session transfer number for SRVCC (STN-SR) (see 3GPP TS 23.003 [17]). - MPS CS Priority, which by its presence indicates the UE is subscribed to the eMLPP in the CS domain. - MPS EPS Priority, which by its presence indicates the UE is subscribed to the MPS in the EPS domain. - Subscribed vSRVCC (see 3GPP 29.272 [144]). This parameter is used only by the MME via IWF and SGSN. If the VLR receives this parameter it shall ignore it. The MPS CS Priority and MPS EPS Priority inside the parameter are used only by the MME via IWF. If the SGSN receives them it shall ignore them. The SGSN shall handle the SIPTO-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the SIPTO-Local-Network-Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the LIPA Permission information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the Restoration-Priority information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. The SGSN shall handle the WLAN-offloadability information as specified in 3GPP TS 29.272 [144] clause 5.2.1.1.2. This parameter shall not be used by the CSS. VPLMN LIPA Allowed This parameter by its presence indicates that the UE is allowed to use LIPA in the PLMN where the UE is attached (see 3GPP TS 23.401 [145] and 3GPP TS 23.060 [104]). This parameter is used only by the IWF and SGSN. If the VLR receives this parameter it shall ignore it. This parameter shall not be used by the CSS. SGSN CAMEL Subscription Info The SGSN CAMEL Subscription Info is sent at GPRS location updating or when any information in the applicable SGSN CAMEL Subscription Info in the HLR has been changed. - In CAMEL Phase 3, this parameter may contain one or both of GPRS-CSI and MO-SMS-CSI. - In CAMEL Phase 4, this parameter may contain GPRS-CSI, MO-SMS-CSI and MT-SMS-CSI and TDP-Criteria for MT-SMS-CSI. At GPRS location updating the complete set of SGSN CAMEL Subscription Info is sent. When CAMEL Subscription Information is changed in the HLR and changed data have to be sent to the SGSN, then one or more specific elements of SGSN CAMEL Subscription Info are sent in one dialogue. When the SGSN receives a specific element of SGSN CAMEL Subscription Info, it shall overwrite the corresponding specific element of SGSN CAMEL Subscription Info (if any) which it has stored for that subscriber. The specific elements of SGSN CAMEL Subscription Info which may be sent are: - MO-SMS-CSI; - MT-SMS-CSI; - TDP-Criteria for MT-SMS-CSI; - GPRS-CSI; - MC-CSI. This parameter is used only by the SGSN and if the VLR or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Roaming Restricted In SGSN/MME Due To Unsupported Feature The HSS/HLR may decide to include this parameter in the request if certain services or features are indicated as not supported by the SGSN/IWF. This parameter is used only by the SGSN and IWFand if the VLR receives this parameter it shall ignore it. This parameter shall not be used by the CSS. CS Allocation/Retention priority The CS Allocation/Retention priority is used only for Circuit Switched (CS). This parameter specifies relative importance to compare with other bearers about allocation and retention of bearer. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR or SGSN (see clause 7.6.3.36D). An IWF shall omit this parameter. This parameter shall not be used by the CSS. Subscribed Charging Characteristics This parameter refers to the Subscribed Charging Characteristics as defined in 3GPP TS 32.251. For a detailed description of the use of the parameter, see 3GPP TS 32.251. This parameter is used only by the SGSN and IWF and if the VLR receives this parameter it shall ignore it. This parameter shall not be used by the CSS. Access Restriction Data This parameter indicates the allowed RAT for the PLMN where the UE is attached according to subscription data. (see clause 7.6.3.97) If the VLR/SGSN/MME supports the Access Restriction feature but does not receive the Access Restriction Data parameter from the HSS/HLR at location updating or restoration, the VLR/SGSN/MME shall assume that the subscriber's profile does not have any restrictions enabled. For a detailed description of the use of the parameter, see 3GPP TS 23.012 [23] for the CS domain and 3GPP TS 23.060[104], 3GPP TS 29.060 [105] clause 7.5.3 and 3GPP TS 29.274 [149] clause 7.3.6 for the PS domain. This parameter shall not be used by the CSS. Supported Features This parameter shall be used by an IWF to forward feature support indications as received from the MME or SGSN via S6a/S6d. This parameter shall not be used by the CSS. CS-to-PS-SRVCC-Allowed-Indicator This parameter indicates by its presence to the MSC Server enhanced for ICS (see 3GPP TS 23.292 [135]) that CS to PS SRVCC is subscribed. This parameter is used by the VLR. P-CSCF Restoration Request This parameter indicates by its presence that the HSS requests to the SGSN or the MME (via the IWF) the execution of the HSS-based P-CSCF restoration procedures, as described in 3GPP TS 23.380 [150], clause 5.4. This parameter shall not be used by the CSS. Adjacent Access Restriction Data This parameter indicates the allowed RAT in each one of the indicated PLMN IDs, according to subscription data. This parameter shall not be used by the CSS. IMSI-Group-Id List A list of IMSI-Group-Id parameters each of which identifies an IMSI-Group the subscriber belongs to. UE Usage Type This parameter indicates the usage characteristics of the UE that enables the selection of a specific Dedicated Core Network . It shall not be sent to VLRs and shall not be sent to SGSNs that did not indicate support of the Dedicated Core Network functionality within GPRS-Location Update. When the Insert-Subscriber-Data operation is used within an Update-GPRS-Location Dialogue, the HLR shall include this parameter if the SGSN indicated support of the Dedicated Core Network functionality and a UE Usage Type is available in the subscription data of the user. Outside the Update-Gprs-Location Dialogue the HLR shall include this parameter towards the SGSN that supports the Dedicated Core Network functionality if the value changed. User error Only one of the following values is applicable: - Unidentified subscriber; - Data missing; - Unexpected data value. 8.8.1.4 Basic service information related to supplementary services A number of parameters that relate to supplementary services can be qualified by a Basic Service Group (or a Basic Service Group List). This clauseÊexplains how this information is to be interpreted. Supplementary service parameters to which this clauseÊis applicable only apply to the basic service groups described in this clause, and only those basic service groups shall be overwritten at the VLR or the SGSN. The Basic Service Group (or Basic Service Group List) is optional. If present the Basic Service Group (or each element of the Basic Service Group List) shall be one of: - an Elementary Basic Service Group for which the supplementary service is applicable to at least one basic service in the group and for which the subscriber has a subscription to at least one basic service in the group; - the group ""All Teleservices"" provided that the service is applicable to at least one teleservice and that the subscriber has a subscription to at least one teleservice which is in the same Elementary Basic Service Group as a teleservice to which the service is applicable; - the group ""All Bearer Services"" provided that the service is applicable to at least one bearer service and that the subscriber has a subscription to at least one bearer service which is in the same Elementary Basic Service Group as a basic service to which the service is applicable. If the Basic Service Group (or Basic Service Group List) is not present then the parameter shall apply to all Basic Service Groups. If the basic service information is not a single Elementary Basic Service Group then the parameter shall be taken as applying individually to all the Elementary Basic Service Groups for which: - the supplementary service is applicable to at least one basic service in the Basic Service Group; and - the subscriber has a subscription to at least one basic service in the Basic Service Group. The VLR and the SGSN are not required to store supplementary services data for Basic Service Groups which are not supported at the VLR or the SGSN respectively. 8.8.2 MAP-DELETE-SUBSCRIBER-DATA service 8.8.2.1 Definition This service is used by an HLR to remove certain subscriber data from a VLR or SGSN if the subscription of one or more supplementary services or basic services is withdrawn. Note that this service is not used in case of erasure or deactivation of supplementary services. This service is also used by an HLR to remove GPRS subscription data from an SGSN. This service is also used by an HSS via IWF to remove EPS subscription data from an MME. This service is also used by a CSS to remove the CSG subscription data from an MME via IWF or a VLR/SGSN. It is a confirmed service and consists of the primitives shown in tableÊ8.8/2. 8.8.2.2 Service primitives TableÊ8.8/2: MAP-DELETE-SUBSCRIBER-DATA Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) Basic service List C C(=) SS-Code List C C(=) Roaming Restriction Due To Unsupported Feature C C(=) Camel Subscription Info Withdraw C C(=) Specific CSI Withdraw C C(=) Regional Subscription Data C C(=) VBS Group Indication C C(=) VGCS Group Indication C C(=) GPRS Subscription Data Withdraw C C(=) EPS Subscription Data Withdraw C C(=) Roaming Restricted In SGSN/MME Due To Unsupported Feature C C(=) LSA Information Withdraw C C(=) IST Information Withdraw C C(=) Regional Subscription Response C C(=) GMLC List Withdraw C C(=) Subscribed Charging Characteristics Withdraw C C(=) CSG Information Deleted C C(=) VPLMN CSG Information Deleted C C(=) APN-OI-Replacement Withdraw C C(=) STN-SR Withdraw C C(=) Subscribed vSRVCC Withdraw C C(=) Subscribed Periodic RAU-TAU Timer Withdraw C C(=) Subscribed Periodic LAU Timer Withdraw C C(=) Additional MSISDN Withdraw C C(=) CS-to-PS-SRVCC Withdraw C C(=) User Plane Integrity Protection Withdraw C C(=) DL-Buffering Suggested Packet Count Withdraw C C(=) UE-Usage-Type Withdraw C C(=) Reset-IDs Withdraw C C(=) IAB-Operation-Withdraw C C(=) User error C C(=) Provider error O 8.8.2.3 Parameter use All parameters are described in clauseÊ7.6. The following clarifications are applicable: Basic service List A list of Extensible Basic service parameters (Extensible Basic service is defined in clauseÊ7.6). It is used when one, several or all basic services are to be withdrawn from the subscriber. If the VLR or the SGSN receives a value for an Extensible Basic Service which it does not support, it shall ignore that value. This parameter is used by the VLR and by the SGSN; if the IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. SS-Code List A list of SS-Code parameters (SS-Code is defined in clauseÊ7.6). It is used when several or all supplementary services are to be withdrawn from the subscriber. There are three possible options: - deletion of basic service(s); The parameter Basic service List is only included. - deletion of supplementary service(s); The parameter SS-Code List is only included. - deletion of basic and supplementary services; Both Basic service List and SS-Code List are included. This parameter is used by the VLR and SGSN and IWF for Call Barring and LCS. Otherwise, this parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Roaming Restriction Due To Unsupported Feature This parameter is used if Roaming Restriction Due To Unsupported Feature is deleted from the subscriber data. This may occur if unsupported features or services are removed from the subscriber data in the HLR. If this parameter is sent the VLR shall check if the current Location Area is possibly allowed now. This parameter is used only by the VLR and if the SGSN or IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. CAMEL Subscription Info Withdraw This parameter is used to indicate that CAMEL Subscription Info shall be deleted from the VLR or from the SGSN. All CAMEL Subscription Info for the subscriber shall be deleted. This parameter is used by the VLR and by the SGSN. This parameter should not be sent in the same message as the Specific CSI Withdraw parameter; if the IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Specific CSI Withdraw This parameter is used to indicate that one or more specific elements of CAMEL Subscription Info shall be deleted from the VLR or from the SGSN. The specific elements of CAMEL Subscription Info which may be withdrawn are: - O-CSI with TDP criteria for O-CSI; - SS-CSI; - TIF-CSI; - D-CSI; - VT-CSI with TDP criteria for VT-CSI; - MO-SMS-CSI; - MT-SMS-CSI with TDP-Criteria for MT-SMS-CSI; - M-CSI; - MG-CSI; - GPRS-CSI. This parameter is used by the VLR and by the SGSN; if the IWF receices this parameter it shall ignore it. It shall not be sent to VLRs that do not support CAMEL phase 3 or higher. This parameter should not be sent in the same message as the CAMEL Subscription Info Withdraw parameter. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Regional Subscription Identifier Contains one single Zone Code (as defined in clauseÊ7.6) and is used if all Zone Codes shall be deleted from the subscriber data. When all the Zone Codes are deleted, the VLR, the SGSN or the MME shall check for its location areas whether they are allowed or not. If the whole Network Node area is restricted, the VLR, the SGSN or the MME (via the IWF) will report it to HLR by returning the Regional Subscription Response ""Network Node Area Restricted"". The binary coding of the Zone Code value received in a Delete Subscriber Data request shall not be checked by the VLR, the SGSN or the MME. Note that support of this parameter is a network operator option and it shall not be sent to networks which do not support Regional Subscription. If Regional Subscription is not supported by the VLR, the SGSN or the MME, the request for deletion of Zone Codes is refused by sending the Regional Subscription Response ""Regional Subscription Not Supported"" to the HLR. If no Zone Codes are stored in the respective subscriber data record, the request for deleting all Zone Code information shall be ignored and no Regional Subscription Response shall be returned. This parameter is used by the VLR, the SGSN and the MME. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. VBS Group Indication Contains an indication (flag) which is used if all Group Ids shall be deleted from the subscriber data for the Voice Broadcast teleservice. If VBS is not supported in the VLR or no Group Ids are stored for VBS in the respective subscriber record, the request for deletion of all Group Ids shall be ignored. This parameter is used only by the VLR and if the SGSN or the IWF receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. VGCS Group Indication Contains an indication (flag) which is used if all Group Id's shall be deleted from the subscriber data for the Voice Group Call teleservice. This parameter is used only by the VLR and if the SGSN receives this parameter it shall ignore it. If VGCS is not supported in the VLR or no Group Ids are stored for VGCS in the respective subscriber record, the request for deletion of all Group Ids shall be ignored. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. GPRS Subscription Data Withdraw This parameter is used to indicate whether all GPRS Subscription Data for the subscriber shall be deleted or if only a subset of the stored GPRS Subscription Data for the subscriber shall be deleted. In the latter case only those PDP contexts whose identifiers are included in the subsequent identifier list will be deleted. This parameter is used only by the SGSN and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. EPS Subscription Data Withdraw This parameter is used to indicate whether all EPS Subscription Data for the subscriber shall be deleted or if only a subset of the stored EPS Subscription Data for the subscriber shall be deleted. In the latter case, only those APN Configurations whose identifiers are included in the subsequent identifier list will be deleted. This parameter is used only by the SGSN and the MME and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Roaming Restricted In SGSN/MME Due To Unsupported Feature This parameter is used if Roaming Restricted In SGSN/MME Due To Unsupported Feature is deleted from the GPRS/EPS subscriber data. This may occur if unsupported features or services are removed from the GPRS/EPS subscriber data in the HLR. If this parameter is sent the SGSN shall check if the current Location Area is possibly allowed now. This parameter is used only by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. LSA Information Withdraw This parameter is used to indicate whether all LSA Information for the subscriber shall be deleted or if only a subset of the stored LSA Information for the subscriber shall be deleted. In the latter case only the LSA data whose LSA identities are included in the subsequent LSA data list will be deleted. This parameter is used by the VLR and the SGSN. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. IST Information Withdraw This parameter is used to indicate that the IST condition has been removed for the subscriber. See 3GPP TS 43.035 for the use of this parameter. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Regional Subscription Response If included in the Delete Subscriber Data response this parameter indicates one of: - Network Node Area Restricted; - Regional Subscription Not Supported. This parameter is used by the VLR, the SGSN and the IWF. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. GMLC List Withdraw This parameter indicates that the subscriber's LCS GMLC List shall be deleted from the VLR or SGSN. This parameter is used by the VLR and the SGSN and IWF. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Subscribed Charging Characteristics Withdraw This parameter indicates that the Subscribed Charging Characteristics shall be replaced with a local default value in the SGSN or in the MME (see 3GPP TS 32.251). This parameter is used only by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. CSG Information Deleted This parameter indicates that CSG Subscription Information received from the HLR/HSS shall be deleted from VLR, SGSN, or MME. This parameter is used by the VLR, SGSN and the IWF. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. VPLMN CSG Information Deleted This parameter indicates that CSG Subscription Information received from the CSS shall be deleted from VLR, SGSN. This parameter is used by the VLR and SGSN. This parameter is not applicable for the HLR/HSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the HLR/HSS. APN-OI-Replacement Withdraw This parameter indicates that APN-OI-Replacement shall be deleted from the SGSN or the MME. This parameter is used by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. STN-SR Withdraw This parameter indicates that STN-SR shall be deleted from the SGSN or the MME. This parameter is used by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Subscribed vSRVCC Withdraw This parameter indicates that Subscribed vSRVCC shall be deleted from the MME. This parameter is used by the MME and the IWF and if the SGSN or VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Subscribed Periodic RAU-TAU Timer Withdraw This parameter indicates that Subscribed Periodic RAU-TAU Timer value shall be deleted from the SGSN or the MME. This parameter is used by the SGSN and the IWF and if the VLR receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Subscribed Periodic LAU Timer Withdraw This parameter indicates that Subscribed Periodic LAU Timer value shall be deleted from the VLR. This parameter is used by the VLR and if the MME or SGSN receives this parameter it shall ignore it. This parameter is not applicable for the CSS and the VLR or SGSN or IWF shall ignore this parameter if it is received from the CSS. Additional MSISDN Withdraw This parameter indicates that Additional MSISDN shall be deleted from the SGSN or MME. This parameter is used by the SGSN and the IWF. CS-to-PS-SRVCC Withdraw This parameter indicates by its presence that CS to PS SRVCC is no longer subscribed. User Plane Integrity Protection Withdraw This parameter indicates by its presence that User Plane Integrity Protection may no longer be required. DL-Buffering Suggested Packet Count Withdraw This parameter indicates by its presence that a suggested DL-Buffering Packet Count is no longer subscribed. UE-Usage-Type Withdraw This parameter indicates by its presence that a UE-Usage-Type is no longer subscribed. This parameter is not applicable for VLRs. The HLR shall include this parameter towards the SGSN or MME (via IWF) that supports the Dedicated Core Network functionality if the subscription to a UE-Usage-Type is removed. Reset-IDs Withdraw This parameter indicates by its presence that Reset-IDs are no longer subscribed. IAB-Operation-Withdraw This parameter indicates by its presence that IAB operation is no longer authorized for the UE. User error Only one of the following values is applicable: - Unidentified subscriber; - Data missing; - Unexpected data value. 8.9 Identity management services 8.9.1 MAP-PROVIDE-IMSI service 8.9.1.1 Definition This service is used by a VLR in order to get, via the MSC, the IMSI of a subscriber (e.g. when a subscriber has identified itself with a TMSI not allocated to any subscriber in the VLR). It is a confirmed service and consists of the primitives shown in tableÊ8.9/1. 8.9.1.2 Service primitives TableÊ8.9/1: MAP-PROVIDE-IMSI Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI C C(=) User error C C(=) Provider error O 8.9.1.3 Parameter use All parameters are described in clauseÊ7.6. The following clarifications are applicable: IMSI This parameter is received when the request is successfully carried out. It contains the requested IMSI. User error Only one of the following values is applicable: - Absent subscriber. 8.9.2 MAP-FORWARD-NEW-TMSI service 8.9.2.1 Definition This service is used by a VLR to allocate, via MSC, a new TMSI to a subscriber during an ongoing transaction (e.g. call set-up, location updating or supplementary services operation). It is a confirmed service and consists of the primitives shown in tableÊ8.9/2. 8.9.2.2 Service primitives TableÊ8.9/2: MAP-FORWARD-NEW-TMSI Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) TMSI M M(=) Provider error O 8.9.2.3 Parameter use The parameter TMSI is described in clauseÊ7.6. 8.10 Fault recovery services 8.10.1 MAP_RESET service 8.10.1.1 Definition This service is used by the HSS/HLR or CSS, after a restart, to indicate to a list of VLRs, SGSNs or MMEs (via IWF) that a failure occurred. This service may also be used by the HSS/HLR as part of operation and maintenance actions e.g. to allow planned HLR/HSS outage without service interruption, or to update subscription data shared by multiple subscribers. The MAP_RESET service is a non-confirmed service using the service primitives defined in tableÊ8.10/1. 8.10.1.2 Service primitives TableÊ8.10/1: MAP_RESET Parameter name Request Indication Invoke Id M M(=) Sending Node Number M M(=) HLR Id LIST U C(=) Reset-ID LIST C C(=) Subscription Data C C(=) Subscription Data Deletion C C(=) 8.10.1.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. SendingNode Number For a restart of the HLR/HSS, this parameter shall contain the HLR number. See definition in clauseÊ7.6.2. For a restart of the CSS, this parameter shall contain the CSS number. See definition in clause 7.6.2. HLR Id LIST The HLR Id List is a list of HLR Ids. If the parameter is present in the indication, the VLR, the SGSN or the MME may base the retrieval of subscribers to be restored on their IMSI: the subscribers affected by the reset are those whose IMSI leading digits are equal to one of these numbers. If the parameter and the Reset-ID List is absent, subscribers to be restored are those for which the OriginatingEntityNumber received at location updating time matches the equivalent parameter of the Reset Indication. This parameter shall only be applicable for a restart of the HLR/HSS. It shall not be present if Reset-ID LIST is present. Reset-ID LIST The Reset-ID LIST is a list of Reset-IDs. It shall not be present if Reset-IDs are not supported by the HLR/HSS and by theVLR or SGSN or MME (via IWF). If the parameter is present in the indication, the VLR, the SGSN or the MME may base the retrieval of affected subscribers (i.e. those impacted by the restoration or by the shared data update) on their subscribed Reset-IDs: The subscribers affected by the reset are those whose subscription contains at least one of these Reset-IDs."
"Subscription Data If the Reset Procedure is used to add/ modify subscription data shared by multiple subscribers, this Information Element shall contain the part of the subscription profile that either is to be added to the subscription profile stored in the VLR, MME or SGSN or combined MME/SGSN or is replacing a part of the subscription profiles of the impacted subscribers stored in the VLR, MME or SGSN. Shall be absent if Subsciption Data Deletion is present. Shall be absent if Reset-ID LIST is absent Subscription Data Deletion If the Reset Procedure is used to delete subscription data shared by multiple subscribers, this Information Element shall contain the identifications of the part of the subscription profile that is to be deleted from the subscription profiles of the impacted subscribers stored in the VLR, MME or SGSN. Shall be absent if Subsciption Data is present. Shall be absent if Reset-ID LIST is absent 8.10.2 MAP_FORWARD_CHECK_SS_INDICATION service 8.10.2.1 Definition This service may be used by an HLR as an implementation option, to indicate to a mobile subscriber that supplementary services parameters may have been altered, e.g. due to a restart. If received from the HLR, the VLR shall forward this indication to the MSC, which in turn forwards it to the MS. The HLR only sends this indication after successful completion of the subscriber data retrieval from HLR to VLR that ran embedded in a MAP_UPDATE_LOCATION procedure. The MAP_FORWARD_CHECK_SS_INDICATION service is a non-confirmed service using the service primitives defined in tableÊ8.10/2. 8.10.2.2 Service primitives TableÊ8.10/2: MAP_FORWARD_CHECK_SS_INDICATION Parameter name Request Indication Invoke Id M M(=) 8.10.2.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. 8.10.3 MAP_RESTORE_DATA service 8.10.3.1 Definition This service is invoked by the VLR on receipt of a MAP_PROVIDE_ROAMING_NUMBER indication for an unknown IMSI, or for a known IMSI with the indicator "" Subscriber Data Confirmed by HLR"" set to ""Not confirmed"". The service is used to update the LMSI in the HLR, if provided, and to request the HLR to send all data to the VLR that are to be stored in the subscriber's IMSI record. This service may be invoked by the VLR on receipt of a ""MAP-MT-FORWARD-SHORT-MESSAGE"" message for an unknown IMSI, or for a known IMSI with the indicator ""Subscriber Data Confirmed by HLR"" set to ""Not confirmed"". The service is used to update the LMSI in the HLR, if provided, and to request the HLR to send all data to the VLR that are to be stored in the subscriber's IMSI record. The HLR shall return the error ""system failure"" to the VLR if the subscriber is not registered on the VLR. The MAP_RESTORE_DATA service is a confirmed service using the service primitives defined in tableÊ8.10/3. 8.10.3.2 Service primitives TableÊ8.10/3: MAP_RESTORE_DATA Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) LMSI U C(=) Supported CAMEL phases C C(=) SoLSA Support Indicator C C(=) IST Support Indicator C C(=) Super-Charger Supported in Serving Network Entity C C(=) Long FTN Supported C C(=) Supported LCS Capability Sets C C(=) Offered CAMEL 4 CSIs C C(=) Restoration Indicator U C(=) Supported RAT Types Indicator U C(=) MTRF Supported U C(=) MSISDN-less Operation Supported C C(=) HLR number C C(=) MS Not Reachable Flag C C(=) User error C C(=) Provider error O 8.10.3.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. LMSI See definition in clauseÊ7.6.2. It is an operator option to provide the LMSI from the VLR; it is mandatory for the HLR to support the LMSI handling procedures. Supported CAMEL Phases This parameter indicates which phases of CAMEL are supported. Must be present if a CAMEL phase different from phase 1 is supported. Otherwise may be absent. SoLSA Support Indicator This parameter is used by the VLR to indicate to the HLR in the Restore Data indication that SoLSA is supported. If this parameter is not included in the Restore Data indication then the HLR shall not perform any specific error handling. This SoLSA Support Indicator shall be stored by the HLR per VLR where there are Subscribers roaming. If a Subscriber is marked as only allowed to roam in Subscribed LSAs while roaming in a VLR and no SoLSA Support indicator is stored for that VLR, the location status of that Subscriber shall be set to Restricted. IST Support Indicator This parameter is used to indicate to the HLR that the VMSC supports basic IST functionality, that is, the VMSC is able to terminate the Subscriber Call Activity that originated the IST Alert when it receives the IST alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Restore Data indication and the Subscriber is marked as an IST Subscriber, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Outgoing calls), or allow service assuming the associated risk of not having the basic IST mechanism available. This parameter can also indicate that the VMSC supports the IST Command service, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Restore Data indication and the HLR supports the IST Command capability, then the HLR may limit the service for the subscriber (by inducing an Operator Determined barring of Outgoing calls), or allow service assuming the associated risk of not having the IST Command mechanism available. Long FTN Supported This parameter indicates that the VLR supports Long Forwarded-to Numbers. Super-Charger Supported in Serving Network Entity This parameter is used by the VLR to indicate to the HLR that the VLR supports the Super-Charger functionality and that subscriber data is required. If this parameter is absent then the VLR does not support the Super-Charger functionality. Supported LCS Capability Sets This parameter indicates, if present, the capability sets of LCS which are supported. If the parameter is sent but no capability set is marked as supported then the VLR does not support LCS at all. If this parameter is absent then the VLR may support at most LCS capability set 1, that is LCS Release98 or Release99 version. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the VMSC/VLR (see clause 7.6.3.36D). Restoration Indicator This parameter indicates, if present, that the HLR shall send in the MAP-INSERT-SUBSCRIBER-DATA the MME Name if the subscriber is registered to EPS, or the SGSN Number if available and if the subscriber is registered to GPRS. The VLR may set this indicator if it supports Gs or SGs interfaces. Supported RAT Types Indicator This parameter indicates, if present, which access technologies (e.g. GERAN and / or UTRAN) are served by the MSC/VLR (see clause 7.6.3) MTRF Supported See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. MSISDN-less Operation Supported See clause 3.6.1.5 of 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. HLR number See definition in clauseÊ7.6.2. The presence of this parameter is mandatory in case of successful outcome of the service. MS Not Reachable Flag See definition in clauseÊ7.6.8. This parameter shall be present in case of successful outcome of the service, if the ""MS Not Reachable flag"" was set in the HLR. User error In case of unsuccessful outcome of the service, an error cause shall be returned by the HLR. The following error causes defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - unknown subscriber; - system failure; - unexpected data value; - data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 8.11 Subscriber Information services 8.11.1 MAP-ANY-TIME-INTERROGATION service 8.11.1.1 Definition This service is used by the gsmSCF, to request information (e.g. subscriber state and location) from the HLR or the GMLC at any time. This service may also be used by the gsmSCF to request the Mobile Number Portability (MNP) information from the NPLR. This service is also used by the Presence Network Agent to request information, (e.g. subscriber state and location) about the subscriber (associated with a presentity) from the HLR at any time (see 3GPP TS 23.141 [128]). When this service is used to the HLR, the subscriber state, location, Time Zone, or T-ADS data may be requested. When this service is used to the GMLC, only the location may be requested. When this service is used to the NPLR, only the MNP information may be requested. The MAP-ANY-TIME-INTERROGATION service is a confirmed service using the service primitives defined in tableÊ8.11/1. 8.11.1.2 Service primitives TableÊ8.11/1: Any_Time_Interrogation Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Requested Info M M(=) Requested domain C C(=) MNP Requested Info C C(=) gsmSCF-Address M M(=) IMSI C C(=) MSISDN C C(=) Location Information C C(=) Location Information for GPRS C C(=) Location Information for EPS C C(=) Subscriber State C C(=) PS Subscriber State C C(=) EPS Subscriber State C C(=) IMEI C C(=) MS Classmark 2 C C(=) GPRS MS Class C C(=) MNP info Result C C(=) IMS Voice Over PS Sessions Support Indicator C C(=) Last UE Activity Time C C(=) Last RAT Type C C(=) Time Zone C C(=) Daylight Saving Time C C(=) User error C C(=) Provider error O 8.11.1.3 Parameter definition and use All parameters are described in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.018 [97] and 3GPPÊTSÊ23.078Ê[98]. The HLR or GMLC may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Interrogation indication. The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98]. IMS Voice Over PS Sessions Support Indicator This parameter indicates the most recent IMS-Voice-Over-PS-Sessions support (based on the Last UE Activity Time), as received from the serving nodes. This parameter shall be present if Requested Info indicates that T-ADS Data are requested. Last UE Activity Time This parameter indicates the most recent available point in time of the UE's last radio contact, as received from the serving nodes. This value may not represent the absolute last instant of radio activity of the UE, when any of the serving nodes has not answered to the T-ADS query. This parameter may be present if requested Info indicates that T-ADS Data are requested. This value may not be available when all the serving nodes have indicated an homogeneous support or an homogeneous non support of IMS Voice Over PS Sessions, since in that case, the serving nodes do not need to be explicitly asked for T-ADS Data. Last RAT Type This parameter indicates the most recent available RAT Type of the access (based on the Last UE Activity Time), as received from the serving nodes. This parameter shall be present if requested Info indicates that T-ADS Data are requested and the IMS Voice Over PS Sessions Support Indicator does not take the value ""unknown"". This value may not represent the absolute last RAT Type of the UE, when any of the serving nodes has not answered to the T-ADS query. This parameter may be present if requested Info indicates that T-ADS Data are requested. This value may not be available when all the serving nodes have indicated an homogeneous support or an homogeneous non support of IMS Voice Over PS Sessions, since in that case, the serving nodes do not need to be explicitly asked for T-ADS Data. Time Zone This parameter indicates the Time Zone of the location in the visited network where the UE is attached, including any adjustment for summertime (daylight saving time). Daylight Saving Time This parameter indicates the Daylight Saving Time (in steps of 1 hour) used to adjust for summertime the time zone of the location where the UE is attached in the visited network. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Any Time Interrogation Not Allowed; - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error These are defined in clause 7.6.1. 8.11.2 MAP-PROVIDE-SUBSCRIBER-INFO service 8.11.2.1 Definition This service is used to request information (e.g. subscriber state and location) from the VLR, SGSN or MME (via an IWF) at any time. The MAP-PROVIDE-SUBSCRIBER-INFO service is a confirmed service using the primitives defined in tableÊ8.11/2. 8.11.2.2 Service primitives TableÊ8.11/2: Provide_Subscriber_Information Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Requested Info M M(=) IMSI M M(=) LMSI U O Call Priority U O Location Information C C(=) Location Information for GPRS C C(=) Subscriber State C C(=) PS Subscriber State C C(=) IMEI C C(=) MS Classmark 2 C C(=) GPRS MS Class C C(=) IMS Voice Over PS Sessions Support Indicator C C(=) Last UE Activity Time C C(=) Last RAT Type C C(=) Location Information for EPS C C(=) Time Zone C C(=) Daylight Saving Time C C(=) User error C C(=) Provider error O 8.11.2.3 Parameter definition and use All parameters are defined in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.018 [97] and 3GPPÊTSÊ23.078Ê[98]. Call Priority This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the HLR supports this parameter and if the Call Priority was received in the MAP_SEND_ROUTING_INFORMATION request. IMS Voice Over PS Sessions Support Indicator This parameter indicates whether IMS Voice Over PS Sessions is supported at the UE's current Routing Area. This parameter shall be present if the UE's current Routing Area is known to the SGSN and the Requested Info indicates that T-ADS Data are requested; otherwise it shall be absent. Last UE Activity Time This parameter indicates the point in time of the UE's last radio contact. This parameter shall be present if requested Info indicates that T-ADS Data are request. Last RAT Type This parameter indicates the RAT Type of the access where the UE was present at the time of the last radio contact. This parameter shall be present if requested Info indicates that T-ADS Data are request. Time Zone This parameter indicates the Time Zone of the location in the visited network where the UE is attached, including any adjustment for summertime (daylight saving time). Daylight Saving Time This parameter indicates the Daylight Saving Time (in steps of 1 hour) used to adjust for summertime the time zone of the location where the UE is attached in the visited network. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Data Missing; - Unexpected Data Value. If the subscriber is not found on the VLR, SGSN or MME, this may be indicated to the requester with the ""Unexpected Subscriber"" value inside the Unexpected Data Value error Provider error These are defined in clause 7.6.1. 8.11.3 MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION service 8.11.3.1 Definition This service is used by the gsmSCF, to request subscription information (e.g. call forwarding supplementary service data or CSI) from the HLR at any time. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this service. 8.11.3.2 Service primitives TableÊ8.11/3: Any_Time_Subscription_Interrogation Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Requested Subscription Info M M(=) GsmSCF-Address M M(=) IMSI C C(=) MSISDN C C(=) Long FTN Supported C C(=) Call Forwarding Data C C(=) Call Barring Data C C(=) ODB Info C C(=) CAMEL Subscription Info C C(=) Supported CAMEL phases in VLR C C(=) Supported CAMEL phases in SGSN C C(=) Offered CAMEL 4 CSIs in VLR C C(=) Offered CAMEL 4 CSIs in SGSN C C(=) MSISDN-BS-List C C(=) CSG Subscription Data C C(=) Call Hold Data C C(=) Call Waiting Data C C(=) Explicit Call Transfer Data C C(=) Calling Line Identification Presentation Data C C(=) Calling Line Identification Restriction Data C C(=) User error C C(=) Provider error O 8.11.3.3 Parameter definition and use All parameters are described in clauseÊ7.6. The HLR may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Subscription_Interrogation indication. The gsmSCF-address shall contain the IM-SSF address when the IM-SSF takes the role of the gsmSCF. The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Unexpected Data Value; - Unknown Subscriber; - BearerServiceNotProvisioned; - TeleserviceNotProvisioned; - CallBarred; - IllegalSS-Operation; - SS-NotAvailable; - InformationNotAvailable; - Any Time Subscription Interrogation Not Allowed; - Data Missing. Provider error These are defined in clause 7.6.1. 8.11.4 MAP-ANY-TIME-MODIFICATION service 8.11.4.1 Definition This service is used by the gsmSCF, to modify information of the HLR at any time. This service is also used by the Presence Network Agent to activate or deactivate reporting of mobility management events (associated with a presentity) from the VLR or SGSN (see 3GPP TS 23.141 [128]). This service is also used by a Service Related Entity (e.g. the IP-SM-GW) to activate a one-time subscription of UE-reachability in the MME (see 3GPP TS 23.204 [134]) and SGSN (see 3GPP TS 23.060 [104]). This service is also used by external Short Message Gateway (IP-SM-GW) for updating the IP-SM-GW Number stored in the HLR, and for retrieving SC Address from the HLR. 8.11.4.2 Service primitives TableÊ8.11/4: Any_Time_Modification Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) gsmSCF-Address M M(=) Subscriber Identity M M(=) Modification request for ODB data C C(=) Modification request for SS information C C(=) Modification request for CSI C C(=) Modification request for CSG C C(=) Long FTN Supported C C(=) Modification request for IP-SM-GW data C C(=) Activation request for UE-Reachability C C(=) Ext Forwarding information-for-CSE C C(=) Ext Call barring information-for-CSE C C(=) ODB Info C C(=) CAMEL subscription info C C(=) Service Centre Address C C(=) User error C C(=) Provider error O 8.11.4.3 Parameter definition and use All parameters are described in clauseÊ7.6. The HLR may be able to use the value of the parameter gsmSCF-address to screen a MAP_Any_Time_Modification indication. The use of parameters other than described below and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. gsmSCF-Address This parameter indicates the address of the interrogating gsmSCF. The gsmSCF Address shall be in international E.164 format. If the service is used by IP-SM-GW, the parameter contains the address of the IP-SM-GW. See also 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. Modification request for CSG This parameter is used by the gsmSCF to request notification of modification of CSG subscription data. Modification request for IP-SM-GW data This parameter is used by the external IP-SM-GW for updating the IP-SM-GW Number and IP-SM-GW Diameter Address stored in the HLR. If this parameter is present then other modification requests shall not be present. Activation request for UE Reachability This parameter is used by the Service Related Entity (e.g. IP-SM-GW) to activate the one-time subscription for UE-Reachability. If this parameter is present then other modification requests shall not be present. Service Centre Address See definition in clauseÊ7.6.2. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Any Time Modification Not Allowed; - Data Missing; - Unexpected Data Value; - Unknown Subscriber; - Bearer service not provisioned; This error is returned only if not even a subset of the requested bearer service group has been subscribed to; - Teleservice not provisioned; This error is returned only if not even a subset of the requested teleservice group has been subscribed to; - Call Barred; - Illegal SS operation; - SS error status; - SS incompatibility; - SS subscription violation; - Information Not Available. Provider error These are defined in clause 7.6.1. 8.11.5 MAP-NOTE-SUBSCRIBER-DATA-MODIFIED service 8.11.5.1 Definition This service is used by the HLR to inform the gsmSCF that subscriber data have been modified. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this service. This service is also used by the HLR to inform the Service Related Entity (e.g. IP-SM-GW) that the UE has become reachable (see 3GPP TS 23.204 [134]). 8.11.5.2 Service primitives TableÊ8.11/5: Note_Subscriber_Data_Modified Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) MSISDN M M(=) Ext Forwarding information-for-CSE C C(=) Ext Call barring information-for-CSE C C(=) ODB Info C C(=) CAMEL subscription info C C(=) CSG Subscription Data C C CW info C C(=) CH info C C(=) CLIP Info C C(=) CLIR Info C C(=) ECT Info C C(=) All Information Sent C C(=) UE reachable C C(=) User error C C(=) Provider error O 8.11.5.3 Parameter definition and use Invoke id See clause 7.6.1 for the use of this parameter. IMSI See clause 7.6.2 for the use of this parameter. MSISDN See clause 7.6.2 for the use of this parameter. In an IP Multimedia Core Network, if no MSISDN is available, the HLR shall populate this parameter with the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). Ext Forwarding information-for-CSE See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]. Ext Call barring information-for-CSE See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]. ODB Info See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]. CAMEL subscription info See clause 7.6.3 for the use of this parameter. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. CSG Subscription Data This parameter contains a list of CSG-Ids and the associated expiration dates (see 3GPP TS 22.011 [138]). The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98]. CW Info This parameter contains the status of the call waiting supplementary service. The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] CH Info This parameter contains the status of the call hold supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] ECT Info This parameter contains the status of the explicit call transfer supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] CLIP Info This parameter contains the status of the calling line identification presentation supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] CLIR Info This parameter contains the status of the calling line identification restriction supplementary service.The use of this parameter and the requirements for their presence are specified in 3GPP TS 23.078 [98] All Information Sent This parameter is set when the HLR has sent all information to gsmSCF. UE Reachable This parameter is used when the HLR indicates to the Service related entity (e.g. IP-SM-GW) that the UE is reachable again. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error These are defined in clause 7.6.1. The use of the parameters and the requirements for their presence are specified in 3GPP TS 23.078 [98] and 3GPP TS 23.278 [125]. 9 Operation and maintenance services 9.1 Subscriber tracing services 9.1.1 MAP-ACTIVATE-TRACE-MODE service 9.1.1.1 Definition This service is used between the HLR and the VLR to activate subscriber tracing in the VLR. Also this service is used between the HLR and the SGSN to activate subscriber tracing in the SGSN. The MAP-ACTIVATE-TRACE-MODE service is a confirmed service using the primitives from tableÊ9.1/1. 9.1.1.2 Service primitives TableÊ9.1/1: MAP-ACTIVATE-TRACE-MODE Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI C C(=) Trace reference M M(=) Trace type M M(=) Trace reference 2 C C(=) Trace depth list C C(=) Trace NE type list C C(=) Trace interface list C C(=) Trace event list C C(=) Trace support indicator C C(=) OMC Id U C(=) MDT-Configuration C C(=) User error C C(=) Provider error O 9.1.1.3 Parameter use Invoke id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is a mandatory parameter in a stand-alone operation. Trace reference See definition in clauseÊ7.6.10. This parameter contains trace reference for GSM only tracing request. Trace type See definition in clauseÊ7.6.10. This parameter contains trace type for GSM only tracing request. OMC Id See definition in clauseÊ7.6.2. The use of this parameter is an operator option. Trace reference 2 See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace depth list See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace NE type list See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace interface list See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace event list See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. Trace support indicator See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. MDT-Configuration See definition in clauseÊ7.6.10. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unidentified Subscriber; - Facility Not Supported; - Tracing Buffer Full; - System Failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 9.1.2 MAP-DEACTIVATE-TRACE-MODE service 9.1.2.1 Definition This service is used between the VLR and the HLR for deactivating subscriber tracing in the VLR. Also this service is used between the SGSN and the HLR for deactivating subscriber tracing in the SGSN. The MAP-DEACTIVATE-TRACE-MODE service is a confirmed service using the primitives from tableÊ9.1/2. 9.1.2.2 Service primitives TableÊ9.1/2: MAP-DEACTIVATE-TRACE-MODE Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI C C(=) Trace reference M M(=) Trace reference 2 C C(=) User error C C(=) Provider error O 9.1.2.3 Parameter use Invoke id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is a mandatory parameter in a stand-alone operation. Trace reference See definition in clauseÊ7.6.10. Trace reference 2 See definition in clauseÊ7.6.10. This parameter shall be used for UMTS trace activation. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unidentified Subscriber; - Facility Not Supported; - System Failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 9.1.3 MAP-TRACE-SUBSCRIBER-ACTIVITY service 9.1.3.1 Definition This service is used between the VLR and the MSC to activate the subscriber tracing in the MSC. The MAP-TRACE-SUBSCRIBER-ACTIVITY service is a non-confirmed service using the primitives from tableÊ9.1/3. 9.1.3.2 Service primitives TableÊ9.1/3: MAP-TRACE-SUBSCRIBER-ACTIVITY Parameter name Request Indication Invoke id M M(=) IMSI C C(=) Trace reference M M(=) Trace type M M(=) OMC Id U C(=) 9.1.3.3 Parameter use Invoke id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The controlling MSC shall provide either the IMSI or the IMEI to the servicing MSC. Trace reference See definition in clauseÊ7.6.10. Trace type See definition in clauseÊ7.6.10. OMC Id See definition in clauseÊ7.6.2. The use of this parameter is an operator option. 9.2 Other operation and maintenance services 9.2.1 MAP-SEND-IMSI service 9.2.1.1 Definition This service is used by a VLR in order to fetch the IMSI of a subscriber in case of some Operation & Maintenance procedure where subscriber data are needed in the Visited PLMN and MSISDN is the only subscriber's identity known. It is a confirmed service and consists of the primitives shown in tableÊ9.2/1. 9.2.1.2 Service primitives TableÊ9.2/1: MAP-SEND-IMSI Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSISDN M M(=) IMSI C C(=) User error C C(=) Provider error O 9.2.1.3 Parameter use All parameters are described in clauseÊ7.6. The following clarifications are applicable. User error Only one of the following values is applicable: - Unknown subscriber; - Unexpected data value; - Data missing. 10 Call handling services 10.1 MAP_SEND_ROUTING_INFORMATION service 10.1.1 Definition This service is used between the Gateway MSC and the HLR. The service is invoked by the Gateway MSC to perform the interrogation of the HLR in order to route a call towards the called MS. This is a confirmed service using the primitives listed in tableÊ10.1/1. This service is also used between the GMSC and the NPLR and between the gsmSCF and the HLR. 10.1.2 Service primitives TableÊ10.1/1: MAP_SEND_ROUTING_INFORMATION parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Interrogation Type M M(=) GMSC or gsmSCF Address M M(=) MSISDN M M(=) C C(=) OR Interrogation C C(=) OR Capability C C(=) CUG Interlock C C(=) C C(=) CUG Outgoing Access C C(=) C C(=) Number of Forwarding C C(=) Network Signal Info C C(=) Supported CAMEL Phases C C(=) C C(=) Suppress T-CSI C C(=) Offered CAMEL 4 CSIs C C(=) Suppression of Announcement C C(=) Call Reference Number C C(=) Forwarding Reason C C(=) Basic Service Group C C(=) Basic Service Group 2 C C(=) Alerting Pattern C C(=) CCBS Call C C(=) Supported CCBS Phase C C(=) Additional Signal Info C C(=) IST Support Indicator C C(=) Pre-paging supported C C(=) Call Diversion Treatment Indicator C C(=) Long FTN Supported C C(=) Suppress VT-CSI C C(=) Suppress Incoming Call Barring C C(=) SuppressMTSS C C(=) gsmSCF Initiated Call C C(=) Network Signal Info 2 C C(=) MT Roaming Retry Supported U C(=) Call Priority U C(=) IMSI C C(=) MSRN C C(=) Forwarding Data C C(=) Forwarding Interrogation Required C C(=) VMSC address C C(=) ReleaseResourcesSupported C C(=) GMSC Camel Subscription Info C C(=) Location Information C C(=) Subscriber State C C(=) Basic Service Code C C(=) CUG Subscription Flag C C(=) North American Equal Access preferred Carrier Id U C(=) User error C C(=) SS-List U C(=) CCBS Target C C(=) Keep CCBS Call Indicator C C(=) IST Alert Timer C C(=) Number Portability Status U C(=) Supported CAMEL Phases in VMSC C Offered CAMEL 4 CSIs in VMSC C C(=) MSRN 2 C C(=) Forwarding Data 2 C C(=) SS-List 2 C C(=) Basic Service Code 2 C C(=) Allowed Services C C(=) Unavailability Cause C C(=) Provider error O GSMÊBearer Capability U C(=) 10.1.3 Parameter use See clauseÊ7.6 for a definition of the parameters used in addition to the following. Note that: - a conditional parameter whose use is defined only in 3GPP TS 23.078 shall be absent if the sending entity does not support CAMEL; - a conditional parameter whose use is defined only in 3GPP TS 23.079 [99] shall be absent if the sending entity does not support optimal routeing; - a conditional parameter whose use is defined only in 3GPP TS 23.078 & 3GPP TS 23.079 [99] shall be absent if the sending entity supports neither CAMEL nor optimal routeing. Interrogation Type See 3GPP TS 23.079 [99] for the use of this parameter. GMSC or gsmSCF address The E.164 address of the GMSC or the gsmSCF. This parameter contains the gsmSCF address if the gsmSCF iniated call parameter is present, otherwise it is the GMSC address. MSISDN This is the Mobile Subscriber ISDN number assigned to the called subscriber. In the Request & Indication it is the number received by the GMSC in the ISUP IAM. If the call is to be forwarded and the HLR supports determination of the redirecting number, the HLR inserts the basic MSISDN in the Response. See 3GPP TS 23.066 [108] for the use of this parameter and the conditions for its presence in the response. OR Interrogation See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. OR Capability See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. CUG Interlock See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. CUG Outgoing Access See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. Number of Forwarding See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. Network Signal Info See 3GPP TS 23.018 [97] for the conditions for the presence of the components of this parameter. Supported CAMEL Phases The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. T-CSI Suppression The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Offered CAMEL 4 CSIs This parameter indicates the CAMEL phase 4 CSIs offered in the GMSC/VLR (see clause 7.6.3.36D). Suppression Of Announcement The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Call Reference Number The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97]. Forwarding Reason See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. Basic Service Group See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. Basic Service Group 2 See 3GPP TS 23.079[99] for the use of this parameter and the conditions for its presence. Alerting Pattern See 3GPP TS 23.018 [97] and 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence. CCBS Call See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Supported CCBS Phase This parameter indicates by its presence that CCBS is supported and the phase of CCBS which is supported. Additional Signal Info See 3GPP TS 23.081 [27] and 3GPP TS 23.088 [33] for the conditions for the presence of the components of this parameter. IST Support Indicator This parameter is used to indicate to the HLR that the GMSC supports basic IST functionality, that is, the GMSC is able to terminate the subscriber call activity that originated the IST Alert when it receives the IST Alert response indicating that the call(s) shall be terminated. If this parameter is not included in the Send Routing Information indication and the subscriber is marked as an IST subscriber, then the HLR may limit the service for the call (by barring the incoming call if it is not subject to forwarding, or suppressing Call Forwarding from the GMSC), or allow the call assuming the associated risk of not having the basic IST mechanism available. This parameter can also indicate that the GMSC supports the IST Command, including the ability to terminate all calls being carried for the identified subscriber by using the IMSI as a key. If this additional capability is not included in the Send Routing Information indication and the subscriber is marked as an IST subscriber, then the HLR may limit the service for the subscriber (by barring the incoming calls if they are not subject to forwarding, or suppressing Call Forwarding from the GMSC), or allow the incoming calls assuming the associated risk of not having the IST Command mechanism available. Pre-paging supported See 3GPP TS 23.018 for the use of this parameter and the conditions for its presence. Call Diversion Treatment Indicator This parameter indicates whether or not call diversion is allowed. Network Signal Info 2 See 3GPP TS 23.172 [126] for the conditions for the presence of the components of this parameter. MT Roaming Retry Supported See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. Call Priority This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the GMSC supports the eMLPP feature and if the call is an eMLPP call. The eMLPP priority levels A and B shall be mapped to the Call Priority level 0. IMSI See 3GPP TS 23.018 [97] and 3GPP TS 23.066 [108] for the use of this parameter and the conditions for its presence. MSRN See 3GPP TS 23.018 [97], 3GPP TS 23.066 [108] and 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence."
"If the NPLR returns only the MSISDN-number without Routeing Number to the GMSC, the MSISDN-number shall be returned as MSRN. Forwarding Data This parameter includes a number to define the forwarded-to destination, the forwarding reason and the forwarding options Notification to calling party and Redirecting presentation, and can include the forwarded-to subaddress. See 3GPP TS 23.018 [97] and 3GPP TS 23.079 [99] for the conditions for the presence of its components. Forwarding Interrogation Required See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. Long FTN Supported This parameter indicates that the GMSC supports Long Forwarded-to Numbers. Suppress VT-CSI The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Suppress Incoming Call Barring The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. gsmSCF Initiated Call The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. SuppressMTSS The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. VMSC address See 3GPP TS 23.079 [99] and 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence. In addition this parameter shall be present if the ReleaseResourcesSupported parameter is present. Release Resources Supported This parameter indicates by its presence that the MAP_RELEASE_RESOURCES service is supported at the VMSC. It shall be present if so indicated by the VMSC with MAP_PROVIDE_ROAMING_NUMBER confirm. GMSC CAMEL Subscription Info The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Location Information The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Subscriber State The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. CUG Subscription Flag The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. North American Equal Access preferred Carrier Id This parameter is returned to indicate the preferred carrier identity to be used to set-up the call (i.e. forwarding the call or establishing the roaming leg). SS-List This parameter includes SS-codes and will be returned as an operator option. The HLR shall not send PLMN-specific SS-codes across PLMN boundaries. However if the GMSC receives PLMN-specific SS-codes from a foreign PLMN's HLR the GMSC may ignore it. If the GMSC attempts to process the PLMN- specific SS- codes, this may lead to unpredictable behaviour but the GMSC shall continue call processing. Basic Service Code The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. If the CAMEL service is not involved, this parameter includes the basic service code and will be returned as an operator option. The HLR shall not send a PLMN-specific Basic Service Code across PLMN boundaries. However if the GMSC receives a PLMN-specific Basic Service Code from a foreign PLMN's HLR the GMSC may ignore it. If the GMSC attempts to process the PLMN specific Basic Service codes, this may lead to unpredictable behaviour but the GMSC shall continue call processing. CCBS Target See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Keep CCBS Call Indicator See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. IST Alert Timer It includes the IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs. This parameter is only sent to the GMSC in response to a Send Routing Information request which indicates the the GMSC supports IST. Number Portability Status This parameter indicates the number portability status of the subscriber. This parameter may be present if the sender of SRIack is NPLR. Supported CAMEL Phases in VMSC The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078. Offered CAMEL 4 CSIs in VMSC This parameter is defined in clause 7.6.3.36F. MSRN 2 The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. Forwarding Data 2 The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. SS-List 2 The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. Basic Service Code 2 The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. Allowed Services The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. Unavailability Cause The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.172 [126]. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Unknown Subscriber; The diagnostic for the Unknown Subscriber error may indicate ""NPDB Mismatch"". - Number changed; - Call Barred; This error will indicate that either incoming calls are barred for this MS or that calls are barred due to Operator Determined Barring (see 3GPP TS 22.041 [8] for a definition of this network feature); - CUG Reject; The value of this error cause will indicate the reason for CUG Reject; - Bearer Service Not Provisioned; - Teleservice Not Provisioned; A subscription check has been performed and the call has not passed the check due to incompatibility with regard to the requested service. Depending on the nature of the incompatibility, either of these messages will be returned; - Facility Not Supported; - Absent Subscriber; This indicates that the location of the MS is not known (either the station is not registered and there is no location information available or the Provide Roaming Number procedure fails due to IMSI detached flag being set), or the GMSC requested forwarding information with a forwarding reason of not reachable, and the call forwarding on MS not reachable service is not active; this may also indicate that the MS has moved to a new MSC/VLR and that MT Roaming Retry is requested (see 3GPP TS 23.018 [97]); - Busy Subscriber; This indicates that Call Forwarding on Busy was not active for the specified basic service group when the GMSC requested forwarding information with a forwarding reason of busy; The error may also indicate that the subscriber is busy due to an outstanding CCBS recall. In the error data it may then be specified that CCBS is possible for the busy encountered call; - No Subscriber Reply; This indicates that Call Forwarding on No Reply was not active for the specified basic service group when the GMSC requested forwarding information with a forwarding reason of no reply; - OR Not Allowed; This indicates that the HLR is not prepared to accept an OR interrogation from the GMSC, or that calls to the specified subscriber are not allowed to be optimally routed; - Forwarding Violation; - System Failure; - Data Missing; - Unexpected Data Value. See clauseÊ7.6.1.4 for a definition of these errors. Provider error These are defined in clauseÊ7.6. GSMÊBearer Capability This information is passed according to the rules specified in 3GPP TS 29.007 [56]. There may be two GSMÊBearer Capabilities supplied. 10.2 MAP_PROVIDE_ROAMING_NUMBER service 10.2.1 Definition This service is used between the HLR and VLR. The service is invoked by the HLR to request a VLR to send back a roaming number to enable the HLR to instruct the GMSC to route an incoming call to the called MS. This service is also used between old VLR and new VLR during the MT Roaming Forwarding procedure. The service is invoked by the old VLR to request a roaming number from the new VLR to be able to route an incoming call to the called UE. This is a confirmed service which uses the primitives described in tableÊ10.2/1. 10.2.2 Service primitives TableÊ10.2/1: MAP_PROVIDE_ROAMING_NUMBER parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) MSC Number M M(=) MSISDN U C(=) LMSI C C(=) GSMÊBearer Capability C C(=) Network Signal Info C C(=) Suppression Of Announcement C C(=) Call Reference Number C C(=) GMSC Address C C(=) OR Interrogation C C(=) OR Not Supported in GMSC C C(=) Alerting Pattern C C(=) CCBS Call C C(=) Supported CAMEL Phases in interrogating node C C(=) Additional Signal Info C C(=) Pre-paging supported C C(=) Long FTN Supported C C(=) Suppress VT-CSI C C(=) Offered CAMEL 4 CSIs in interrogating node C C(=) MT Roaming Retry Supported U C(=) Paging Area U C(=) Call Priority U C(=) MTRF Indicator U C(=) Old MSC Number U C (=) Last used LTE PLMN ID U C(=) Roaming Number C C(=) VMSC address U C(=) ReleaseResourcesSupported U C(=) User error C C(=) Provider error O 10.2.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. Note that: - a conditional parameter whose use is defined only in 3GPP TS 23.078 [98] shall be absent if the sending entity does not support CAMEL; - a conditional parameter whose use is defined only in 3GPP TS 23.079 [99] shall be absent if the sending entity does not support optimal routeing; - a conditional parameter whose use is defined only in 3GPP TS 23.078 [98] & 3GPP TS 23.079 [99] shall be absent if the sending entity supports neither CAMEL nor optimal routeing. IMSI This is the IMSI of the called Subscriber. MSC Number This is the ISDN number assigned to the MSC currently serving the MS. When the service is used between HLR and VLR, the MSC number will have been stored in the HLR as provided at location updating. When used between old VLR and new VLR during an MT Roaming Forwarding procedure, the MSC number will have been provided at location cancelling or within Send Identification. MSISDN See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. LMSI See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. In addition, for the mobile terminating roaming forwarding procedure between the old VLR and the new VLR, this parameter shall be present if the MTRF Indicator is present and theÊoldÊVLRÊhas received the new LMSI inÊCancel LocationÊfrom the HLR or in Send Identification from the new VLR. GSMÊBearer Capability See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. This information is passed according to the rules specified in TS 3GPP TS 29.007 [56]. There may be two GSMÊBearer Capabilities supplied. Network Signal Info See 3GPP TS 23.018 [97] for the conditions for the presence of the components of this parameter. Suppression Of Announcement The use of this parameter and the requirements for its presence are specified in 3GPP TS 23.078 [98]. Call Reference Number The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97]. GMSC Address The use of this parameter and the conditions for its presence are specified in 3GPP TS 23.078 [98], 3GPP TS 23.079 [99] and 3GPP TS 23.018 [97]. OR Interrogation See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. OR Not Supported in GMSC See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. Supported CAMEL Phases in interrogating node This parameter is defined in clause 7.6.3.36I.Alerting Pattern See 3GPP TS 23.078 [98] for the use of this parameter and the conditions for its presence. CCBS Call See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Additional Signal Info See 3GPP TS 23.081 [27] for the conditions for the presence of the components of this parameter. Pre-paging supported See 3GPP TS 23.018 for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present. Long FTN supported See 3GPP TS 23.082 for the use of this parameter and the conditions for its presence. Suppress VT-CSI See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence. Offered CAMEL 4 CSIs in interrogating node This parameter is defined in clause 7.6.3.36E. MT Roaming Retry Supported See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present. Paging Area See 3GPP TS 23.018 [97] and 3GPP TS 23.012 [23] for the use of this parameter and the conditions for its presence. This information element is not applicable for MTRF, and shall be ignored if received while the MTRF Indicator is present. Call Priority This parameter indicates the eMLPP priority of the call (see 3GPP TS 24.067 [137]). This parameter should be present if the HLR supports this parameter and if the Call Priority was received in the MAP_SEND_ROUTING_INFORMATION request. MTRF Indicator This indicator indicates by its presence that the service is used between old VLR and new VLR during an MT Roaming Forwarding procedure. See 3GPP TS 23.018 [97]. Old MSC Number This parameter refers to the E.164 address of the old MSC. The use of this parameter is specified in 3GPP TS 23.018 [97]. This information element is applicable only if the MTRF Indicator is set. Last used LTE PLMN ID See 3GPP TS 23.272 [143] for the use of this parameter and the conditions for its presence. This information element is applicable only if the MTRF Indicator is set. Roaming Number See 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. VMSC address See 3GPP TS 23.079 [99], 3GPP TS 23.078 [98] and 3GPP TS 23.018 [97] for the use of this parameter and the conditions for its presence. This parameter shall be present during the Mobile Terminating Roaming Forwarding Call during Retrieval of Routeing Information procedure if an MSRN is allocated by the new MSC/VLR. ReleaseResourcesSupported This parameter indicates by its presence that the MAP_RELEASE_RESOURCES service is supported at the VMSC. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Absent Subscriber; This error will be returned if the IMSI detach flag is set. - No Roaming Number Available; - OR Not Allowed; This indicates that the MAP_PROVIDE_ROAMING_NUMBER indication included the OR interrogation indicator, but the VLR does not support optimal routeing. - Facility Not Supported; - System Failure; - Data Missing; - Unexpected Data Value. See clauseÊ7.6 for a definition of these reasons. Provider error These are defined in clauseÊ7.6. 10.3 MAP_RESUME_CALL_HANDLING service 10.3.1 Definition This service is used between the terminating VMSC and the GMSC. The service is invoked by the terminating VMSC to request the GMSC to resume handling the call and forward it to the specified destination. This is a confirmed service which uses the Primitives listed in tableÊ10.3/1. 10.3.2 Service primitives TableÊ10.3/1: MAP_RESUME_CALL_HANDLING parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Call Reference Number C C(=) Basic Service Group C C(=) Basic Service Group 2 C C(=) IMSI C C(=) Forwarding Data C C(=) CUG Interlock C C(=) CUG Outgoing Access C C(=) O-CSI C C(=) D-CSI C C(=) CCBS Target C C(=) UU Data C C(=) UUS CF Interaction C C(=) All Information Sent C C(=) MSISDN C C(=) MT Roaming Retry U C(=) User error C C(=) Provider error O 10.3.3 Parameter use Information received in subsequent segment of a segmented dialogue shall not overwrite information received in an earlier segment. See clauseÊ7.6 for a definition of the parameters used, in addition to the following. Call Reference Number See 3GPP TS 23.079 [99] for the use of this parameter. This parameter shall be present in the first segment of the dialogue. Basic Service Group See 3GPP TS 23.079 [99] for the use of this parameter. This parameter shall be present in the first segment of the dialogue. Basic Service Group 2 See 3GPP TS 23.079[99] for the use of this parameter. If this parameter is present, it shall be in the first segment of the dialogue. IMSI This is the IMSI of the forwarding Subscriber. This parameter shall be present in the first segment of the dialogue. Forwarding Data This parameter includes a number to define the forwarded-to destination, the forwarding reason and the forwarding options Notification to calling party and Redirecting presentation, and can include the forwarded-to subaddress. See 3GPP TS 23.079 [99] for the conditions for the presence of its components. This parameter shall be present in a first segment of the dialogue. CUG Interlock See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. CUG Outgoing Access See 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. O-CSI See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence. For CAMEL phases 1 & 2, the O-CSI shall contain only one set of O-BCSM TDP data. D-CSI The Dialled Services-CSI. See 3GPP TS 23.078 for the use of this parameter and the conditions for its presence. CCBS Target See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. UU Data See 3GPP TS 23.087 for the use of this parameter and the conditions for its presence. UUS CF Interaction See 3GPP TS 23.087 for the use of this parameter and the conditions for its presence. All Information Sent This parameter is set when the VMSC has sent all information to GMSC. MT Roaming Retry See 3GPP TS 23.018 [97], 3GPP TS 23.012 [23] and 3GPP TS 23.079 [99] for the use of this parameter and the conditions for its presence. When this parameter is present, only the Call Reference Number and All Information Sent IEs shall be present; the other IEs shall be ignored by the GMSC if received. MSISDN This parameter is the basic MSISDN of the forwarding subscriber. It shall be present if the VMSC supports determination of the redirecting number. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Optimal Routeing not allowed; - Forwarding failed; - Unexpected Data Value; - Data Missing. Provider error These are defined in clauseÊ7.6. 10.4 MAP_PREPARE_GROUP_CALL service 10.4.1 Definition This service is used by the Anchor_MSC to inform the Relay_MSC about a group call set-up. The MAP_PREPARE_GROUP_CALL service is a confirmed service using the service primitives given in table 10.4/1. 10.4.2 Service primitives Table 10.4/1: MAP_PREPARE_GROUP_CALL service Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Teleservice M M(=) ASCI Call Reference M M(=) Ciphering Algorithm M M(=) Group Key Number VK-Id C C(=) VSTK Key C C(=) VSTK-RAND C C(=) Priority C C(=) CODEC-Information M M(=) Uplink Free Indicator M M(=) Talker Channel Parameter C C(=) Uplink Reply Indicator C C(=) Group Call Number M M(=) User Error C C(=) Provider Error O 10.4.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1. Teleservice Voice Broadcast Service or Voice Group Call Service. ASCI Call Reference Broadcast call reference or group call reference. This item is used to access the VBS-GCR or VGCS-GCR within the Relay_MSC. Ciphering Algorithm The ciphering algorithm to be used for the group call. Group Key Number VK-Id This Group Key Number has to be broadcast and is used by the mobile station to derive the key for ciphering on the radio interface (see 3GPP TS 43.020 [24]). Values 2 to 15 are reserved for future use. Shall be present if the ciphering applies. VSTK The VGCS/VBS Short Term Key is used to derive the key for ciphering on the radio interface (see 3GPP TS 43.020 [24]). Shall be present if the ciphering applies. VSTK-RAND This random number has to be broadcast and is used by the mobile station to derive the group key for ciphering on the radio interface (see 3GPP TS 43.020 [24]). Shall be present if the ciphering applies. Priority Default priority level related to the call if eMLPP applies. CODEC-Information Information on the codecs allowed for this call. Uplink Free Indicator A flag indicating whether the call is initiated from a dispatcher. Talker Channel Parameter A flag indicating by its presence that a dedicated channel shall be established and maintained for the talking service subscriber. Uplink Reply Indicator A flag indicating by its presence that the uplink reply procedure is applicable for the voice group call or voice broadcast call. Group Call Number This temporary allocated E.164 number is used for routing the call from the Anchor MSC to the Relay MSC. User Error For definition of this parameter see clauseÊ7.6.1 The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - No Group Call Number available; - System Failure; - Unexpected Data Value. Provider Error See definition of provider error in clauseÊ7.6.1. 10.5 MAP_PROCESS_GROUP CALL_SIGNALLING service 10.5.1 Definitions This service is used between Relay MSC and Anchor MSC for transmission of Group Call notifications. The MAP_PROCESS_GROUP_CALL_SIGNALLING service is a non-confirmed service using the service primitives given in table 10.5/1. 10.5.2 Service primitives Table 10.5/1: MAP_PROCESS_GROUP_CALL_SIGNALLING service Parameter name Request Indication Invoke Id M M(=) Uplink Request C C(=) Uplink Release Indication C C(=) AN-APDU C C(=) Release Group Call C C(=) Talker Priority C C(=) Additional Info C C(=) Emergency Mode Reset Command Flag C C(=) 10.5.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1 Uplink Request This information element indicates to the anchor MSC that a service subscriber roaming in the relay MSC area requests access to the uplink. Uplink Release Indication This information element if included by the Relay MSC indicates to the Anchor MSC that the uplink has become free. AN-APDU This parameter contains the Notification Data message as defined in3GPP TS 48.008 [49]. Release Group Call This information element if included by the Relay MSC indicates to the Anchor MSC that the service subscriber who has initiated the call and who currently has access to the uplink terminates the call. Talker Priority For the definition and use of this parameter see 3GPP TS 43.068 [100] Additional Info For the definition and use of this parameter see 3GPP TS 43.068 [100] Emergency Mode Reset Command Flag For the definition and use of this parameter see 3GPP TS 43.068 [100] 10.6 MAP_FORWARD_GROUP_CALL_SIGNALLING service 10.6.1 Definitions This service is used between Anchor MSC and Relay MSC for transmission of Group Call notifications. The MAP_FORWARD_GROUP_CALL_SIGNALLING service is a non-confirmed service using the service primitives given in table 10.6/1. 10.6.2 Service primitives Table 10.6/1: MAP_FORWARD_GROUP_CALL_SIGNALLING service Parameter name Request Indication Invoke Id M M(=) IMSI C C(=) Uplink Request Acknowledgement C C(=) Uplink Release Indication C C(=) Uplink Reject Command C C(=) Uplink Seized Command C C(=) Uplink Release Command C C(=) AN-APDU C C(=) State Attributes C C(=) Talker Priority C C(=) Additional Info C C(=) Emergency Mode Reset Command Flag C C(=) SM RP UI C C(=) 10.6.3 Parameter definitions and use IMSI Identity of the service subscriber who has established the call and who is allowed to terminate the call. Invoke Id See definition in clauseÊ7.6.1. Uplink Request Acknowledgement This information element is used for positive acknowledgement of an uplink request. Uplink Release Indication This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink has become free. Uplink Reject Command This information element is used for negative acknowledgement of an uplink request. Uplink Seized Command This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink is no longer free. Uplink Release Command This information element if included by the Anchor MSC indicates to the Relay MSC that the uplink which is granted to a MS in the relay MSC area shall be released. AN-APDU This parameter contains the Notification Data message as defined in 3GPP TS 48.008 [49] State Attributes This information element is used to allow service logic running in an Anchor MSC to mute a VGCS talker even when the talker is served on a Relay MSC. The IE is used to build a GCC message that provides a mechanism to induce the VGCS talker terminal to mute/unmute the downlink at the Anchor MSC, as defined in 3GPP TS 44.068. Talker Priority For the definition and use of this parameter see 3GPP TS 43.068 [100] Additional Info For the definition and use of this parameter see 3GPP TS 43.068 [100] Emergency Mode Reset Command Flag For the definition and use of this parameter see 3GPP TS 43.068 [100] SM RP UI See definition in clauseÊ7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. 10.7 MAP_SEND_GROUP_CALL_END_SIGNAL service 10.7.1 Definitions This service is used between the Relay MSC and the Anchor MSC. When the VGCS/ VBS calling service subscriber is in the Relay MSC area the MAP_SEND_GROUP_CALL_END_SIGNAL indicates that at least the downlink channel in the originating cell is established. For all other VGCS/ VBS call set-up scenarios (i.e. calling service subscriber in Anchor MSC area, calling service subscriber in other Relay MSC area, dispatcher originated call) the MAP_SEND_GROUP_CALL_END_SIGNAL indicates that at least the downlink channel in any one cell within the VGCS/ VBS call area in the Relay MSC is established. The response is used by the Anchor MSC to inform the Relay MSC that all resources for the call can be released in the Relay MSC because the call has been released in the Anchor MSC. The MAP_SEND_GROUP_CALL_END_SIGNAL service is a confirmed service using the service primitives given in table 10.7/1. 10.7.2 Service primitives Table 10.7/1: MAP_SEND_GROUP_CALL_END_SIGNAL service Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI C C(=) Talker Priority C C(=) Additional Info C C(=) Provider Error O 10.7.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1 IMSI Identity of the service subscriber who has established the call and who is allowed to terminate the call. Shall be present if the call was established by a service subscriber roaming in the relay MSC area. Talker Priority For the definition and use of this parameter see 3GPP TS 43.068 [100] Additional Info For the definition and use of this parameter see 3GPP TS 43.068 [100] Provider Error See definition of provider error in clauseÊ7.6.1. 10.7A MAP_SEND_GROUP_CALL_INFO service 10.7A.1 Definitions This service is used in a RANflex configuration (see 3GPP TS 23.236 [133]) between the subscriber's visited MSC and group call serving MSC of the subscriber's location area. The MAP_SEND_GROUP_CALL_INFO service is a confirmed service using the service primitives given in table 10.7A/1. 10.7A.2 Service primitives Table 10.7A/1: MAP_SEND_GROUP_CALL_INFO service Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Requested Info M M(=) Teleservice M M(=) Cell Id C C(=) Group Id M M(=) IMSI C C(=) C C(=) Talker Priority C C(=) Additional Info C C(=) C C(=) TMSI C C(=) CKSN C C(=) Anchor MSC Address C C(=) ASCI Call Reference C C(=) Additional Subscriptions C C(=) Kc C C(=) User Error C C(=) Provider Error O 10.7A.3 Parameter definitions and use Invoke Id See definition in clauseÊ7.6.1 Requested Info For the definition and use of this parameter see 3GPP TS 43.068 [100] Teleservice Voice Broadcast Service or Voice Group Call Service. Cell Id Identity of the initiating service subscriber's current cell. Group Id For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101]. If prefixes are used together with group IDs, the most significant digit of the Group Id contains the prefix. IMSI If sent in the request: Identity of the service subscriber who has established the call and who is allowed to terminate the call. If sent in the response: Identity of the uplink requesting service subscriber. Talker Priority For the definition and use of this parameter see 3GPP TS 43.068 [100] Additional Info For the definition and use of this parameter see 3GPP TS 43.068 [100] TMSI See definition in clauseÊ7.6.2. CKSN See clauseÊ7.6.7 for the use of this parameter. Anchor MSC Address For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101] ASCI Call Reference For the definition and use of this parameter see 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101] Additional Subscriptions For the definition and use of this parameter see 3GPP TS 43.068 [100] Kc See clauseÊ7.6.7 for the use of this parameter. User Error For definition of this parameter see clauseÊ7.6.1 The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - System Failure; - Unexpected Data Value; - Data Missing - TeleserviceNotProvisioned; - Unknown Subscriber; - Ongoing Call. Provider Error See definition of provider error in clauseÊ7.6.1. 10.8 Void 10.9 Void 10.10 MAP_SET_REPORTING_STATE service 10.10.1 Definition This service is used between the HLR and the VLR to set the reporting state for a requested service. It is a confirmed service using the service primitives shown in table 10.10/1. 10.10.2 Service primitives TableÊ10.10/1: MAP_SET_REPORTING_STATE parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI C C(=) LMSI C C(=) CCBS Monitoring C C(=) CCBS Subscriber Status C C(=) User error C C(=) Provider error O 10.10.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. IMSI The IMSI is a mandatory parameter if the service is used as the only one in a dialogue. CCBS Monitoring This parameter indicates whether monitoring for CCBS shall be started or stopped. If it indicates that monitoring shall be started this service corresponds to the message 'Start Reporting' in 3GPP TS 23.093 [107]; if it indicates that monitoring shall be stopped this service corresponds to the message 'Stop Reporting' in 3GPP TS 23.093 [107]. CCBS Subscriber Status See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System Failure; - Unidentified Subscriber; - Unexpected Data Value; - Data Missing; - Resource Limitation; - Facility Not Supported. NOTE: This error is reserved for future use. Provider error These are defined in clause 7.6. 10.11 MAP_STATUS_REPORT service 10.11.1 Definition This service is used by the VLR to report an event or call outcome to the HLR. It is a confirmed service using the service primitives shown in table 10.11/1. 10.11.2 Service primitives TableÊ10.11/1: MAP_STATUS_REPORT parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) CCBS Subscriber Status C C(=) Monitoring Mode C C(=) Call Outcome C C(=) User error C C(=) Provider error O 10.11.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. CCBS Subscriber Status If this parameter is present without Monitoring Mode and Call Outcome this service corresponds to the message 'Event Report' in 3GPP TS 23.093 [107]. See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Monitoring Mode If this parameter is present with CCBS Call Outcome this service corresponds to the message 'CCBS Call Report' in 3GPP TS 23.093 [107]. See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Call Outcome See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - Unknown Subscriber; - System Failure; - Unexpected Data Value; - Data Missing. Provider error These are defined in clauseÊ7.6. 10.12 MAP_REMOTE_USER_FREE service 10.12.1 Definition This service is used between the HLR and the VLR to report that the B subscriber is now idle and that the A subscriber can be notified. It is a confirmed service using the service primitives shown in table 10.12/1. 10.12.2 Service primitives TableÊ10.12/1: MAP_REMOTE_USER_FREE parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) Call Info M M(=) CCBS Feature M M(=) Translated B Number M M(=) Replace B Number C C(=) Alerting Pattern C C(=) RUF Outcome C C(=) User error C C(=) Provider error O 10.12.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. Call Info See 3GPP TS 23.093 [107] for the use of this parameter. CCBS Feature See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature. Translated B Number See 3GPP TS 23.093 [107] for the use of this parameter. Replace B Number See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Alerting Pattern See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. RUF Outcome See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - Unexpected Data Value; - Data Missing; - Incompatible Terminal; - This error is returned by the responder when the terminal used for CCBS activation is not compatible with the terminal used for the CCBS recall. For details refer to 3GPP TS 24.008 [35]; - Absent Subscriber (IMSI Detach; Restricted Area; No Page Response); - System Failure; - Busy Subscriber (CCBS Busy). Provider error These are defined in clauseÊ7.6. 10.13 MAP_IST_ALERT service 10.13.1 Definition This service is used between the MSC (Visited MSC or Gateway MSC) and the HLR, to report that the IST timer running for a call for the Subscriber has expired. It is a confirmed service using the service primitives shown in tableÊ10.13/1. 10.13.2 Service primitives TableÊ10.13/1: MAP_IST_ALERT parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) IST Alert Timer C C(=) IST Information Withdraw C C(=) Call termination Indicator C C(=) User error C C(=) Provider error O 10.13.3 Parameter use All parameters are described in clause 7.6. The following clarifications are applicable: IST Alert Timer If included in the IST Alert response, it includes the new IST Alert timer value that must be used to inform the HLR about the call activities that the subscriber performs. IST Information Withdraw If included in the IST Alert response, this parameter is used to indicate that the IST condition has been removed for the subscriber. When the MSC receives this parameter, IST control for that call shall be terminated. Call termination Indicator If included in the IST Alert response, this parameter is used to indicate whether the MSC shall terminate the call activity that had previously triggered the IST Alert procedure, or it shall also release all other call activities for the specified subscriber (outgoing call activities if the IST Alert is initiated by the VMSC, or incoming call activities if the IST Alert is initiated by the GMSC). Release of all other call activities is possible only if the MSC has the capability to link the call activities for the Subscriber by using the IMSI as key. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Unexpected Data Value; - Resource Limitation; - Facility Not Supported; - Unknown Subscriber. 10.14 MAP_IST_COMMAND service 10.14.1 Definition This service is used by the HLR to instruct the MSC (Visited MSC or Gateway MSC) to terminate ongoing call activities for a specific subscriber. It is a confirmed service using the service primitives shown in table 10.14/1. 10.14.2 Service primitives TableÊ10.14/1: MAP_IST_COMMAND parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI M M(=) User error C C(=) Provider error O 10.14.3 Parameter use All parameters are described in clause 7.6. The following clarifications are applicable: User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Unexpected Data Value; - Resource Limitation; - Facility Not Supported; - Unknown Subscriber. 10.15 MAP_RELEASE_RESOURCES service 10.15.1 Definition This service is used between the GMSC and the terminating VMSC."
"The service is invoked by the GMSC to request the VMSC to release the resources associated with the specified MSRN. This is a confirmed service which uses the Primitives listed in tableÊ10.15/1. 10.15.2 Service primitives TableÊ10.15/1: MAP_RELEASE_RESOURCES parameters Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSRN M M(=) User error C C(=) Provider error O 10.15.3 Parameter use MSRN See 3GPP TS 23.018 [97] for the use of this parameter. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Unexpected Data Value; Provider error These are defined in clauseÊ7.6. 11 Supplementary services related services 11.1 MAP_REGISTER_SS service 11.1.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to register data related to a supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.1./1. 11.1.2 Service primitives TableÊ11.1/1: MAP_REGISTER_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Basic service C C(=) Forwarded-to number with subaddress C C(=) No reply condition time C C(=) EMLPP default priority C C(=) C C(=) Long FTN Supported C C(=) NbrUser C C(=) C C(=) Forwarding information C C(=) User error C C(=) Provider error O 11.1.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates the supplementary service which the mobile subscriber wants to register. Basic service This parameter indicates for which basic service group the supplementary service is to be registered. If it is not included, the registration request applies to all basic services. Forwarded-to number with subaddress This parameter is obligatory if the registration applies to one or more call forwarding supplementary services. It can optionally include a sub-address. No reply condition time This parameter is included if the registration applies to the Call Forwarding on No Reply supplementary service (or a superset of this service) and the mobile subscriber supplies a value for this time. EMLPP default priority This parameter is sent by the initiator to register the eMLPP default priority level and is returned by the responder at successful outcome of the service. Long FTN Supported This parameter indicates that the mobile station supports Long Forwarded-to Numbers. NbrUser This parameter is sent by the initiator to register the MC maximum number of user defined circuit switched bearers to be used. Forwarding information This parameter is returned by the responder at successful outcome of the service, if the registration request concerned one or a group of Call Forwarding supplementary services. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; - Call Barred; - Bearer service not provisioned; - This error is returned only if not even a subset of the requested bearer service group has been subscribed to; - Teleservice not provisioned; This error is returned only if not even a subset of the requested teleservice group has been subscribed to; - Illegal SS operation; - SS error status; - SS incompatibility. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.2 MAP_ERASE_SS service 11.2.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.2/1. 11.2.2 Service primitives TableÊ11.2/1: MAP_ERASE_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Basic service C C(=) Forwarding information C C(=) User error C C(=) Provider error O 11.2.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates the supplementary service which the mobile subscriber wants to erase. Basic service This parameter indicates for which basic service group the supplementary service should be erased. If it is not included, the erasure request applies to all basic services. Forwarding information This parameter is returned by the responder at successful outcome of the service, if the erasure request concerned one or a group of Call Forwarding supplementary services. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Bearer service not provisioned; This error is returned only if not even a subset of the requested bearer service group has been subscribed to; - Teleservice not provisioned; This error is returned only if not even a subset of the requested teleservice group has been subscribed to; - Call Barred; - Illegal SS operation; - SS error status. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.3 MAP_ACTIVATE_SS service 11.3.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to activate a supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.3/1. 11.3.2 Service primitives TableÊ11.3/1: MAP_ACTIVATE_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Long FTN Supported C C(=) Basic service C C(=) Forwarding information C C(=) Call barring information C C(=) SS-Data C C(=) User error C C(=) Provider error O 11.3.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates the supplementary service which the mobile subscriber wants to activate. Basic service This parameter indicates for which basic service groups the requested supplementary service(s) should be activated. If it is not included, the activation request applies to all basic services. Forwarding information This parameter is returned by the responder at successful outcome of the service, if the activation request concerned Call Forwarding. Long FTN Supported This parameter indicates that the mobile station supports Long Forwarded-to Numbers. Call barring information This parameter is returned by the responder at successful outcome of the service, if the activation request concerned Call Barring. SS-Data This parameter is returned by the responder at successful outcome of the service, if the activation request concerned for example Call Waiting. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Bearer service not provisioned; - This error is returned only if not even a subset of the requested bearer service group has been subscribed to. - Teleservice not provisioned; - This error is returned only if not even a subset of the requested teleservice group has been subscribed to. - Call Barred; - Illegal SS operation; - SS error status; - SS subscription violation; - SS incompatibility; - Negative PW check; - Number Of PW Attempts Violation. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.4 MAP_DEACTIVATE_SS service 11.4.1 Definitions This service is used between the MSC and the VLR and between the VLR and the HLR to deactivate a supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.4/1. 11.4.2 Service primitives TableÊ11.4/1: MAP_DEACTIVATE_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Basic service C C(=) Forwarding information C C(=) Call barring information C C(=) SS-Data C C(=) User error C C(=) Provider error O 11.4.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates the supplementary service which the mobile subscriber wants to deactivate. Basic service This parameter indicates for which basic service group the requested supplementary service(s) should be deactivated. If it is not included the deactivation request applies to all basic services. Forwarding information This parameter is returned by the responder at successful outcome of the service, if the deactivation request concerned one or a group of Call Forwarding supplementary services. Call barring information This parameter is returned by the responder at successful outcome of the service, if the activation request concerned one or a group of Call Barring supplementary services. SS-Data This parameter is returned by the responder at successful outcome of the service, for example if the deactivation request concerned the Call Waiting supplementary service. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Bearer service not provisioned; This error is returned only if not even a subset of the requested bearer service group has been subscribed to; - Teleservice not provisioned; This error is returned only if not even a subset of the requested teleservice group has been subscribed to; - Call Barred; - Illegal SS operation; - SS error status; - SS subscription violation; - Negative PW check; - Number Of PW Attempts Violation. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.5 MAP_INTERROGATE_SS service 11.5.1 Definitions This service is used between the MSC and the VLR and between the VLR and the HLR to retrieve information related to a supplementary service. The VLR will relay the message to the HLR if necessary. The service is a confirmed service and consists of four service primitives. 11.5.2 Service primitives The service primitives are shown in tableÊ11.5/1. TableÊ11.5/1: MAP_INTERROGATE_SS parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) Basic service C C(=) Long FTN Supported C C(=) SS-Status C C(=) Basic service Group LIST C C(=) Forwarding feature LIST C C(=) CLI restriction Info C C(=) EMLPP Info C C(=) MC Information C C(=) CCBS Feature LIST C C(=) User error C C(=) Provider error O 11.5.3 Parameter use For additional information on parameter use refer to the GSMÊ04.8x and 04.9x-series of technical specifications. Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code The mobile subscriber can only interrogate a single supplementary service per service request. Basic service This parameter indicates for which basic service group the given supplementary service is interrogated. If it is not included, the interrogation request applies to all basic services. SS-Status This parameter is included by the responder if: - the interrogated supplementary service can only be subscribed for all applicable basic services simultaneously; or - the interrogated supplementary service is not active for any of the interrogated basic services, or - the interrogation was for the CCBS supplementary service and no CCBS request is active or the service is not provisioned. Basic service group LIST This parameter LIST is used to include one or a series of basic service groups for which the interrogated supplementary service is active. If the interrogated supplementary service is not active for any of the interrogated (and provisioned) basic service groups, the SS-Status parameter is returned. Long FTN Supported This parameter indicates that the mobile station supports Long Forwarded-to Numbers. Forwarding feature LIST The forwarding feature parameter is described in clauseÊ7.6.4. A list of one or more forwarding features is returned by the responder when the interrogation request applied to Call Forwarding supplementary service. If no basic service code parameter is provided within this sequence, the forwarding feature parameter applies to all provisioned basic services. CLI restriction Info The CLI-RestrictionInfo parameter is returned by the responder when the interrogation request applies to the CLIR supplementary service. EMLPP Info The eMLPP info (maximum entitled priority and default priority) is returned by the responder if the interrogation request applies to the eMLPP supplementary service. MC Information The MC information (NbrSB, NbrUser and NbrSN) is returned by the responder if the interrogation request applies to the MC supplementary service. For a definition of these 3 components, refer to 3GPP TS 23.135 and 3GPP TS 24.135. CCBS Feature LIST The CCBS feature parameter is described in clause 7.6. A list of one or more CCBS features is returned by the responder when the interrogation request applied to the CCBS supplementary service. See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature. User error This error is sent by the responder upon unsuccessful outcome of the interrogation service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Bearer Service not provisioned; This error is returned only if not even a subset of the interrogated bearer services are provided; - Teleservice not provisioned; This error is returned only if not even a subset of the interrogated teleservices are provided; - Call Barred; - Illegal SS operation; - SS not available. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.6 Void 11.7 MAP_REGISTER_PASSWORD service 11.7.1 Definitions This service is used between the MSC and the VLR and between the VLR and the HLR if the mobile subscriber requests to register a new password. The VLR will relay the message to the HLR. The service is a confirmed service and consists of four service primitives. 11.7.2 Service primitives The service primitives are shown in tableÊ11.7/1. TableÊ11.7/1: MAP_REGISTER_PASSWORD parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) New password C C(=) User error C C(=) Provider error O 11.7.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. SS-Code This parameter indicates for which supplementary service(s) the password should be registered. New Password See clauseÊ7.6.4 for the use of this parameter. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Call Barred; - SS subscription violation; - Password registration failure; - Negative PW check; - Number Of PW Attempts Violation. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.8 MAP_GET_PASSWORD service 11.8.1 Definitions This service is used between the HLR and the VLR and between the VLR and the MSC when the HLR receives a request from the mobile subscriber for an operation on a supplementary service which requires a password from the subscriber. The VLR will relay the message to the MSC. The service is a confirmed service and uses the service primitives shown in table 11.8/1. 11.8.2 Service primitives TableÊ11.8/1: MAP_GET_PASSWORD parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Linked id C C(=) Guidance info M M(=) Current password M M(=) Provider error O 11.8.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. Linked Id See clauseÊ7.6.1 for the use of this parameter. If the MAP_GET_PASSWORD service is used in conjunction with the MAP_REGISTER_PASSWORD service, this parameter must be present; otherwise it must be absent. Guidance info See clauseÊ7.6.4 for the use of this parameter. Current password See clauseÊ7.6.4 for the use of this parameter. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.9 MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service 11.9.1 Definitions This service is used between the MSC and the VLR, between the VLR and the HLR, between the HLR and gsmSCF and between the HLR and HLR to relay information in order to allow unstructured supplementary service operation. The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST service is a confirmed service using the primitives from tableÊ11.9/1. 11.9.2 Service primitives TableÊ11.9/1: MAP_PROCESS_UNSTRUCTURED_SS_REQUEST parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) USSD Data Coding Scheme M M(=) C C(=) USSD String M M(=) C C(=) MSISDN C C(=) User error C C(=) Provider error O 11.9.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. USSD Data Coding Scheme See clauseÊ7.6.4 for the use of this parameter. The presence of the parameter in the response is dependent on the unstructured supplementary service application. If this parameter is present, then the USSD String parameter has to be present. USSD String See clauseÊ7.6.1 for the use of this parameter. The presence of the parameter in the response is dependent on the unstructured supplementary service application. If this parameter is present, then the USSD Data Coding Scheme parameter has to be present. MSISDN The subscriber's basic MSISDN. See definition in clauseÊ7.6.2. For Follow Me when the service request is sent from the HLR of the A subscriber, the parameter shall contain the MSISDN of the A subscriber, see 3GPP TS 23.094 [129]. For other purposes the MSISDN may be included as an operator option, e.g. to allow addressing the subscriber's data in the gsmSCF with the MSISDN. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; This error is returned by the responder if it is not able to deal with the contents of the USSD string. - Call Barred; - Unknown Alphabet. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.10 MAP_UNSTRUCTURED_SS_REQUEST service 11.10.1 Definitions This service is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires information from the mobile user, in connection with unstructured supplementary service handling. The MAP_UNSTRUCTURED_SS_REQUEST service is a confirmed service using the primitives from tableÊ11.10/1. 11.10.2 Service primitives TableÊ11.10/1: MAP_UNSTRUCTURED_SS_REQUEST parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) USSD Data Coding Scheme M M(=) C C(=) USSD String M M(=) C C(=) Alerting Pattern C C(=) User error C C(=) Provider error O 11.10.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. USSD Data Coding Scheme See clauseÊ7.6.4 for the use of this parameter. The presence of the parameter in the response is dependent on the mobile user's MMI input. If this parameter is present, then the USSD String parameter has to be present. USSD String See clauseÊ7.6.1 for the use of this parameter. The presence of the parameter in the response is dependent on the mobile user's MMI input. If this parameter is present, then the USSD Data Coding Scheme parameter has to be present. Alerting Pattern See clause 7.6.3 for the use of this parameter. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; This error is returned by the responder if it is not able to deal with the contents of the USSD string; - Absent Subscriber; - Illegal Subscriber; This error indicates that delivery of the unstructured supplementary service data failed because the MS failed authentication; - Illegal Equipment; - USSD Busy; - Unknown Alphabet. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.11 MAP_UNSTRUCTURED_SS_NOTIFY service 11.11.1 Definitions This service is used between the gsmSCF and the HLR, the HLR and the VLR and between the VLR and the MSC when the invoking entity requires a notification to be sent to the mobile user, in connection with unstructured supplementary services handling. The MAP_UNSTRUCTURED_SS_NOTIFY service is a confirmed service using the primitives from tableÊ11.11/1. 11.11.2 Service primitives TableÊ11.11/1: MAP_UNSTRUCTURED_SS_NOTIFY parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) USSD Data Coding Scheme M M(=) USSD String M M(=) Alerting Pattern C C(=) User error C C(=) Provider error O 11.11.3 Parameter use Invoke id See clauseÊ7.6.1 for the use of this parameter. USSD Data Coding Scheme: See clauseÊ7.6.4 for the use of this parameter. USSD String: See clauseÊ7.6.1 for the use of this parameter. Alerting Pattern See clause 7.6.3 for the use of this parameter. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; This error is returned by the responder if it is not able to deal with the contents of the USSD string. - Absent Subscriber; - Illegal Subscriber; This error indicates that delivery of the unstructured supplementary service data failed because the MS failed authentication. - Illegal Equipment; - USSD Busy; - Unknown Alphabet. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.12 MAP_SS_INVOCATION_NOTIFY 11.12.1 Definition This service is used between the MSC and the gsmSCF when the subscriber invokes one of the following supplementary services; Call Deflection (CD), Explicit Call Transfer (ECT) or Multi Party (MPTY). This service is used between the HLR and the gsmSCF when the subscriber invokes the CCBS supplementary service. 11.12.2 Service primitives The service primitives are shown in tableÊ11.12/1. TableÊ11.12/1: SS_INVOCATION_NOTIFY parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) MSISDN M M(=) IMSI M M(=) SS- event M M(=) SS- event data C C(=) B-subscriber Number C C(=) CCBS Request State C C(=) User error C C(=) Provider error O 11.12.3 Parameter use All parameters are described in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.078. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error This is defined in clause 7.6.1. 11.13 MAP_REGISTER_CC_ENTRY service 11.13.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to register data for a requested call completion supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in table 11.13/1. 11.13.2 Service primitives TableÊ11.13/1: MAP_REGISTER_CC_ENTRY parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS Code M M(=) CCBS Feature C C(=) C C(=) Translated B number C C(=) Service Indicator C C(=) Call Info C C(=) Network Signal Info C C(=) User error C C(=) Provider error O 11.13.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. SS-Code This parameter indicates the call completion supplementary service for which the mobile subscriber wants to register an entry. CCBS Feature See 3GPP TS 23.093 [107] for the conditions for the presence of the parameters included in the CCBS feature. Translated B Number See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Service Indicator This parameter corresponds to the parameters 'Presentation Indicator' and 'CAMEL Invoked' in 3GPP TS 23.093 [107]. It indicates which services have been invoked for the original call (e.g. CLIR, CAMEL). See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Call Info See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. Network Signal Info See 3GPP TS 23.093 [107] for the use of this parameter and the conditions for its presence. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data missing; - Unexpected data value; - Call Barred; - Illegal SS operation; - SS error status; - SS incompatibility. - Short Term Denial; - Long Term Denial; - Facility Not Supported; NOTE: This error is reserved for future use. Private Extensions shall not be sent with these user errors for this operation. Provider error See clauseÊ7.6.1 for the use of this parameter. 11.14 MAP_ERASE_CC_ENTRY service 11.14.1 Definition This service is used between the MSC and the VLR and between the VLR and the HLR to erase data related to a call completion supplementary service. The VLR will relay the message to the HLR. The service is a confirmed service and uses the service primitives shown in tableÊ11.14/1. 11.14.2 Service primitives TableÊ11.14/1: MAP_ERASE_CC_ENTRY parameters Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) SS-Code M M(=) C(=) C(=) CCBS Index C C(=) SS-Status C C(=) User error C C(=) Provider error O 11.14.3 Parameter use See clauseÊ7.6 for a definition of the parameters used, in addition to the following. SS-Code This parameter indicates the call completion supplementary service for which the mobile subscriber wants to erase an entry/entries. CCBS Index See 3GPP TS 23.093 [107] for the use of this parameter and the condition for its presence. SS-Status Depending on the outcome of the service request this parameter may indicate either provisioned and active or not provisioned. User error This parameter is sent by the responder upon unsuccessful outcome of the service, and then takes one of the following values, defined in clauseÊ7.6.1: - System failure; - Data Missing; - Unexpected data value; - Call Barred; - Illegal SS operation; - SS error status. Private Extensions shall not be sent with these user errors for this operation. Provider error See clauseÊ7.6.1 for the use of this parameter. 12 Short message service management services 12.1 MAP-SEND-ROUTING-INFO-FOR-SM service 12.1.1 Definition This service is used between the gateway MSC and the HLR to retrieve the routing information needed for routing the short message to the servicing MSC or MME but not both, or SGSN, or (for T4-device triggering via the IMS) IP-SM-GW, or SMSF. This service is also used between the gateway MSC and SMS Router, and SMS Router and HLR in order to enforce routing of the SM delivery via the HPLMN of the receiving MS. This service is also used between HLR and IP-SM-GW, and between IP-SM-GW and HLR in order to allow MT-SM delivery (other than T4-device triggering) via the IMS. This service is also used with an IWF interfacing the S6c interface. The MAP-SEND-ROUTING-INFO-FOR-SM is a confirmed service using the primitives from tableÊ12.1/1. 12.1.2 Service primitives TableÊ12.1/1: MAP-SEND-ROUTING-INFO-FOR-SM Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSISDN M M(=) SM-RP-PRI M M(=) Service Centre Address M M(=) SM-RP-MTI C C(=) SM-RP-SMEA C C(=) GPRS Support Indicator C C(=) SM-Delivery Not Intended U C(=) IP-SM-GW Guidance Support Indicator U C(=) Single Attempt Delivery C C(=) IMSI C C(=) C C(=) Correlation ID C C(=) T4 Trigger Indicator C C(=) SMSF Support Indicator C C(=) Network Node Number C C(=) Network Node Diameter Address C C(=) LMSI C C(=) GPRS Node Indicator C C(=) Additional Number C C(=) Additional Network Node Diameter Address C C(=) IP-SM-GW Guidance U C(=) Third Number C C(=) Third Network Node Diameter Address C C(=) IMS Node Indicator C C(=) SMSF 3GPP Number C C(=) SMSF 3GPP Diameter Address C C(=) SMSF Non-3GPP Number C C(=) SMSF Non-3GPP Diameter Address C C(=) SMSF 3GPP Address Indicator C C(=) SMSF Non 3GPP Address Indicator C C(=) User error C C(=) Provider error O 12.1.3 Parameter use Invoke id See definition in clauseÊ7.6.1. MSISDN See definition in clauseÊ7.6.2. When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR following an T4 Submit Trigger (see 3GPP TS 23.682 [148]), MSISDN may not be available. In this case the UE shall be identified by the IMSI and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), MSISDN may not be available. In this case the UE shall be identified by a Correlation ID (SIP-URI-B) and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). SM-RP-PRI See definition in clauseÊ7.6.8. Service Centre Address See definition in clauseÊ7.6.2. SM-RP-MTI See definition in clauseÊ7.6.8. This parameter shall be present when the feature ÇÊSM filtering by the HPLMNÊÈ is supported by the SMS-GMSC and when the equivalent parameter is received from the short message service relay sub-layer protocol. SM-RP-SMEA See definition in clauseÊ7.6.8. This parameter shall be present when the feature ÇÊSM filtering by the HPLMNÊÈ is supported by the SMS-GMSC and when the equivalent parameter is received from the short message service relay sub-layer protocol. GPRS Support Indicator See definition in clause 7.6.8. The presence of this parameter is mandatory if the SMS-GMSC supports receiving of the two numbers from the HLR. SM-Delivery Not Intended This parameter indicates by its presence that delivery of a short message is not intended. It further indicates whether only IMSI or only MCC+MNC are requested. This parameter may be set by entities that request the service without intending to deliver a short message (e.g. MMS Relay/Server), and shall be evaluated by the SMS Router and may be evaluated by the HLR. IP-SM-GW Guidance Support Indicator This parameter indicates whether or not the SMS-GMSC is prepared to receive IP-SM-GW Guidance in the response. Single Attempt Delivery This parameter indicates the short message is only valid for delivering once, and the HLR/HSS does not need to add the received SC address into MWD list in the case there is no serving node available to provide SMS to the user. IMSI See definition in clauseÊ7.6.2. In Request and Indication: IMSI shall be present if MSISDN is not available. When SEND-ROUTING-INFO-FOR-SM is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), IMSI may not be available. In this case the IMSI parameter shall be populated with the HLR-ID value. In Response and Confirm: If enforcement of routing an SM via the HPLMN of the receiving MS is deployed, this parameter contains an MT Correlation ID instead of an IMSI when the service is used between SMS-GMSC and SMS Router (see 3GPP TS 23.040 [26] for more information). If the ""SM-Delivery Not Intended"" parameter was present in the Indication with a value of ""only MCC+MNC requested"", then this parameter may contain MCC+MNC+dummy MSIN. The presence of this parameter is mandatory in a successful case. T4 Trigger Indicator This indicator indicates by its presence that the request is sent in the context of T4 device triggering (see 3GPP TS 23.682 [148]). When received, the HLR may return up to three serving node numbers and shall not forward the request to an IP-SM-GW or SMS Router. SMSF Support Indicator It indicates that the requesting node is capable of receiving ISDN numbers and/or Diameter addresses of the SMSF as target of MT-SMS. Correlation ID The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user. SIP-URI-A and HLR-ID shall be absent from this parameter. The Correlation ID indicates by its presence that the request is sent in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [134]). When received, the HLR shall return the IP-SM-GW number and shall not forward the request to an IP-SM-GW. Network Node Number See definition in clauseÊ7.6.2. This parameter is provided in a successful response. If the ""SM-Delivery Not Intended"" parameter was present in the Indication a dummy address (encoded in the same manner as the dummy MSISDN defined in clause 3.3 of 3GPPÊTSÊ23.003Ê[17]) may be provided. See clause 12.1.4. Network Node Diameter Address See definition in clauseÊ7.6.2. See clause 12.1.4. LMSI See definition in clauseÊ7.6.2. It is an operator option to provide this parameter from the VLR; it is mandatory for the HLR to include the LMSI in a successful response, if the VLR has used the LMSI. GPRS Node Indicator See definition in clause 7.6.8. Outside the context of T4 device triggering: The presence of this parameter is mandatory if only the SGSN number is sent in the Network Node Number (i.e. if the value within Network Node Number is to be considered as SGSN-Number and Additional Number is absent). Within the context of T4 device triggering: The presence of this parameter is mandatory if the value within Network Node Number is to be considered as SGSN-Number and Third Number is absent. Additional Number See definition in clauseÊ7.6.2. See clause 12.1.4. Additional Network Node Diameter Address See definition in clauseÊ7.6.2. See clause 12.1.4. IP-SM-GW Guidance This parameter contains the recommended and the minimum timer values for supervision of MT-Forward-Short-Message response. Shall be absent if the IP-SM-GW-Guidance Support Indicator in the request is absent. This parameter is only used by IP-SM-GW and SMS-GMSC. Third Number See definition in clauseÊ7.6.2. See clause 12.1.4. Third Network Node Diameter Address See definition in clauseÊ7.6.2. See clause 12.1.4 IMS Node Indicator See definition in clause 7.6.8. Outside the context of T4 device triggering: The parameter is not applicable and shall be absent. Within the context of T4 device triggering: The presence of this parameter is mandatory if the value within Network Node Number is to be considered as IP-SM-GW-Number and Third Number is absent. SMSF 3GPP Number This parameter contains the ISDN number of the SMSF target node for MT-SMS over 3GPP access. SMSF 3GPP Diameter Address This parameter contains the Diameter Name and Realm of the SMSF target node for MT-SMS over 3GPP access. SMSF Non-3GPP Number This parameter contains the ISDN number of the SMSF target node for MT-SMS over non-3GPP access. SMSF Non-3GPP Diameter Address This parameter contains the Diameter Name and Realm of the SMSF target node for MT-SMS over non-3GPP access. SMSF 3GPP Address Indicator It indicates that the parameter Network Node Number (and Network Node Diameter Address, if present) contains the address of an SMSF for 3GPP access. SMSF Non-3GPP Address Indicator It indicates that the parameter Network Node Number (and Network Node Diameter Address, if present) contains the address of an SMSF for non-3GPP access. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown subscriber; - Call Barred; - Teleservice Not Provisioned; - Absent Subscriber_SM; - Facility Not Supported; - System failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.1.4 Identities of MT-SMS Target Nodes In a successful MAP-Send-Routing-Info-For-SM response at least one MT-SMS Target Node identity or an SMS Router identity shall be present and this shall be an E.164 number within the Network Node Number parameter. In addition, optionally a second Target Node identity or an SMS Router identity may be present as E.164 number within the Additional Number Parameter. In T4 device trigger scenarios in addition to a second Target Node identity, a third Target Node Identity may be present as E.164 number within the Third Number parameter. In addition to the E.164 identity of an MT-SMS Target Node or an SMSRouter, the presence of the Diameter Name/Realm of the corresponding target node or SMS Router follows the hereafter rules: - If Network Node Number contains an MME number for SMS, Network Node Diameter Address shall be present and contain the Diameter address of the MME. - If Network Node Number contains an MSC number, Network Node Diameter Address may be present and shall contain the Diameter address of the MME. - If Network Node Number contains an SGSN number, Network Node Diameter Address shall be present only if the HSS has received the information that SGSN supports the Gdd interface. - If Network Node Number contains an SMS Router number, Network Node Diameter Address may be present and shall contain the SMS Router Diameter address. - If Network Node Number contains an IP-SM-GW number, Network Node Diameter Address may be present and shall contain the IP-SM-GW Diameter address. Similar for Additional Number - Additional Network Node Diameter Address; Similar for Third Number - Third Network Node Diameter Address. In scenarios supporting interworking with 5G System, an E.164 Number and a Diameter Address of the SMSF may be present, for both 3GPP and non-3GPP accesses. In addition: - If Network Node Number contains an SMSF 3GPP number, Network Node Diameter Address may be present and shall contain the SMSF 3GPP Diameter address. - If Network Node Number contains an SMSF Non-3GPP number, Network Node Diameter Address may be present and shall contain the SMSF Non-3GPP Diameter address. 12.2 MAP-MO-FORWARD-SHORT-MESSAGE service 12.2.1 Definition This service is used between the serving MSC or the SGSN or IP-SM-GW and the SMS Interworking MSC to forward mobile originated short messages. The MAP-MO-FORWARD-SHORT-MESSAGE service is a confirmed service using the service primitives given in tableÊ12.2/1. 12.2.2 Service primitives TableÊ12.2/1: MAP-MO-FORWARD-SHORT-MESSAGE Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) SM RP DA M M(=) SM RP OA M M(=) SM RP UI M M(=) C C(=) IMSI C C(=) Correlation ID C C(=) SM Delivery Outcome C C(=) User error C C(=) Provider error O 12.2.3 Parameter use Invoke id See definition in clauseÊ7.6.1."
"SM RP DA See definition in clauseÊ7.6.8. In the mobile originated SM transfer this parameter contains the Service Centre address received from the mobile station. SM RP OA See definition in clauseÊ7.6.8. The MSISDN received from the VLR or from the SGSN is inserted in this parameter in the mobile originated SM transfer. A Dummy MSISDN value is used for MSISDN-less SMS in IMS. In this case the originating user is identified by SIP-URI-A (see Correlation ID). SM RP UI See definition in clauseÊ7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. IMSI See definition in clauseÊ7.6.2.1. The IMSI of the originating subscriber shall be inserted in this parameter in the mobile originated SM transfer. Correlation ID The Correlation ID is composed of an HLR-Id identifying the destination user's HLR, a SIP-URI-B identifying the MSISDN-less destination user, and a SIP-URI-A identifying the originating user. The Correlation ID indicates by its presence that the request is sent in the context of MSISDN-less SMS delivery in IMS (see 3GPP TS 23.204 [134]), and that a Report-SM-Delivery status needs to be sent to the HLR to add the SC address to the MWD. SM Delivery Outcome See definition in clauseÊ7.6.8. This parameter indicates the status of the mobile terminated SM delivery. Shall be present if Correlation ID is present and shall take one of the unsuccessful outcome values. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Facility Not Supported; - System Failure; - SM Delivery Failure; - The reason of the SM Delivery Failure can be one of the following in the mobile originated SM: - unknown Service Centre address; - Service Centre congestion; - invalid Short Message Entity address; - subscriber not Service Centre subscriber; - protocol error. - Unexpected Data Value Provider error For definition of provider errors see clauseÊ7.6.1. 12.3 MAP-REPORT-SM-DELIVERY-STATUS service 12.3.1 Definition This service is used between the gateway MSC and the HLR or the external Short Message Gateway (IP-SM-GW) and the HLR. The MAP-REPORT-SM-DELIVERY-STATUS service is used to set the Message Waiting Data into the HLR or to inform the HLR of successful SM transfer after polling. This service is invoked by the gateway MSC or the external Short Message Gateway (IP-SM-GW). The MAP-REPORT-SM-DELIVERY-STATUS service is a confirmed service using the service primitives given in tableÊ12.3/1. 12.3.2 Service primitives TableÊ12.3/1: MAP-REPORT-SM-DELIVERY-STATUS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSISDN M M(=) IMSI C C(=) Service Centre Address M M(=) SM Delivery Outcome M M(=) Absent Subscriber Diagnostic SM C C(=) GPRS Support Indicator C C(=) Delivery Outcome Indicator C C(=) Additional SM Delivery Outcome C C(=) Additional Absent Subscriber Diagnostic SM C C(=) IP-SM-GW-Indicator C C(=) IP-SM-GW SM Delivery Outcome C C(=) IP-SM-GW Absent Subscriber Diagnostic SM C C(=) Single Attempt Delivery C C(=) Correlation ID C C(=) SMSF 3GPP Delivery Outcome Indicator C C(=) SMSF 3GPP SM Delivery Outcome C C(=) SMSF 3GPP Absent Subscriber Diagnostic SM C C(=) SMSF non-3GPP Delivery Outcome Indicator C C(=) SMSF non-3GPP SM Delivery Outcome C C(=) SMSF non-3GPP Absent Subscriber Diagnostic SM C C(=) MSIsdn-Alert C C(=) User error C C(=) Provider error O 12.3.3 Parameter use Invoke id See definition in clauseÊ7.6.1. MSISDN See definition in clauseÊ7.6.2. When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR following an T4 Submit Trigger (see 3GPP TS 23.682 [148]), MSISDN may not be available. In this case the UE shall be identified by the IMSI and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), MSISDN may not be available. In this case the UE shall be identified by a Correlation ID (SIP-URI-B) and the MSISDN shall take the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]). IMSI See definition in clauseÊ7.6.2. When REPORT-SM-DELIVERY-STATUS is sent by the SMS-GMSC to the HLR in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]), IMSI may not be available. In this case the IMSI parameter shall be populated with an HLR-ID). Service Centre Address See definition in clauseÊ7.6.2. SM Delivery Outcome See definition in clauseÊ7.6.8. This parameter indicates the status of the mobile terminated SM delivery. Absent Subscriber Diagnostic SM See definition in clauseÊ7.6.8. GPRS Support Indicator See definition in clause 7.6.8. The presence of this parameter is mandatory if the SMS-GMSC supports handling of two delivery outcomes. Delivery Outcome Indicator See definition in clause 7.6.8. Additional SM Delivery Outcome See definition in clause 7.6.8. Additional Absent Subscriber Diagnostic SM See definition in clause 7.6.8. IP-SM-GW Indicator See definition in clause 7.6.8. IP-SM-GW SM Delivery Outcome See definition in clause 7.6.8. IP-SM-GW Absent Subscriber Diagnostic SM See definition in clause 7.6.8. Single Attempt Delivery This parameter indicates the short message is only valid for delivering once, and the HLR/HSS does not need to add the received SC address into MWD list. It may only be present in the case the delivery of the short message failed due to absent subscriber or MS memory capacity exceeded. Editor's Note: Description of the use of this parameter might be needed in 3GPP TS 23.040. Correlation ID The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user. SIP-URI-A and HLR-ID shall be absent from this parameter. SMSF 3GPP Delivery Outcome Indicator See definition in clause 7.6.8. SMSF 3GPP SM Delivery Outcome See definition in clause 7.6.8. SMSF 3GPP Absent Subscriber Diagnostic SM See definition in clause 7.6.8. SMSF Non-3GPP Delivery Outcome Indicator See definition in clause 7.6.8. SMSF Non-3GPP SM Delivery Outcome See definition in clause 7.6.8. SMSF Non-3GPP Absent Subscriber Diagnostic SM See definition in clause 7.6.8. MSIsdn-Alert See definition in clauseÊ7.6.2. This parameter shall be present in case of unsuccessful delivery, when the MSISDN received in the operation is different from the stored MSIsdn-Alert; the stored MSIsdn-Alert is the value that is returned to the gateway MSC. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown Subscriber; - Message Waiting List Full; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.4 MAP-READY-FOR-SM service 12.4.1 Definition This service is used between the MSC and VLR as well as between the VLR and the HLR. The MSC initiates this service if a subscriber indicates memory available situation. The VLR uses the service to indicate this to the HLR. The VLR initiates this service if a subscriber, whose message waiting flag is active in the VLR, has radio contact in the MSC. Also this service is used between the SGSN and the HLR. The SGSN initiates this service if a subscriber indicates memory available situation. The SGSN uses the service to indicate this to the HLR. Also this service is used between the HSS and the MME via an IWF. The MME initiates this service if a subscriber indicates memory available situation. The MME uses the service to indicate this to the HLR. The SGSN initiates this service if a subscriber, whose message waiting flag is active in the SGSN, has radio contact in the GPRS. The MME initiates this service if a subscriber, whose message waiting flag is active in the MME, has radio contact via LTE. Also this service is used between the external Short Message Gateway (IP-SM-GW) and the HLR. The IP-SM-GW initiates this service if a subscriber indicates memory available situation. The IP-SM-GW uses the service to indicate this to the HLR. The IP-SM-GW initiates this service if a subscriber, whose message waiting flag is active in the IP-SM-GW, is reachable in IMS. The MAP-READY-FOR-SM service is a confirmed service using the primitives from tableÊ12.4/1. 12.4.2 Service primitives TableÊ12.4/1: MAP-READY-FOR-SM Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) IMSI C C(=) TMSI C C(=) Alert Reason M M(=) Alert Reason Indicator C C(=) Additional Alert Reason Indicator C C(=) Maximum UE Availability Time C C(=) User error C C(=) Provider error O 12.4.3 Parameter use Invoke id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. The IMSI is used always between the VLR and the HLR and between the SGSN and the HLR and between the HSS and the IWF. Between the MSC and the VLR the identification can be either IMSI or TMSI. TMSI See definition in clauseÊ7.6.2. The identification can be either IMSI or TMSI between MSC and VLR. Alert Reason See definition in clauseÊ7.6.8. This parameter indicates if the mobile subscriber is present or the MS has memory available. Alert Reason Indicator See definition in clauseÊ7.6.8. This parameter by its presence indicates the message is sent from SGSN, and by its absence indicates the message is sent from VLR or MME via IWF. Additional Alert Reason Indicator See definition in clauseÊ7.6.8. Maximum UE Availability Time See definition in clauseÊ7.6.8. This information element may be included by the SGSN or MSC when notifying the HLR that the MS is reachable. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown Subscriber; - Facility Not Supported; - System Failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.5 MAP-ALERT-SERVICE-CENTRE service 12.5.1 Definition This service is used between the HLR and the interworking MSC. The HLR initiates this service, if the HLR detects that a subscriber, whose MSISDN is in the Message Waiting Data file, is active or the MS has memory available. This service is also used between an MME (via an IWF), SGSN or an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPPÊTSÊ23.272Ê[143] and 3GPP TS 23.040 [6]) and the SMS-GMSC (possibly via an SMS Router), to indicate that a MS, for which one or more MT SMS have been requested to be retransmitted at a later time, is now available for MT SMS delivery or has moved under the coverage of another MME, SGSN or MSC. This procedure is used according to the call flows described in clause 10.1 of 3GPP TS 23.040 [26]. The MAP-ALERT-SERVICE-CENTRE service is a confirmed service using the primitives from tableÊ12.5/1. 12.5.2 Service primitives TableÊ12.5/1: MAP-ALERT-SERVICE-CENTRE Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MSIsdn-Alert M M(=) IMSI C C(=) Correlation ID C C(=) Service Centre Address M M(=) Maximum UE Availability Time C C(=) SMS-GMSC Alert Event C C(=) SMS-GMSC Diameter Address C C(=) New SGSN Number C C(=) New SGSN Diameter Address C C(=) New MME Number C C(=) New MME Diameter Address C C(=) New MSC Number C C(=) User error C C(=) Provider error O 12.5.3 Parameter use Invoke id See definition in clauseÊ7.6.1. MSIsdn-Alert See definition in clauseÊ7.6.2. When the service is used between the HLR and the SMS-IWMSC, the provided MSISDN shall be the one which is stored in the Message Waiting Data file. If no MSISDN is available, the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]) shall be sent and an IMSI or Correlation ID (SIP-URI-B) shall be present. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, the dummy MSISDN value (see clause 3 of 3GPP TS 23.003 [17]) shall be sent and an IMSI shall be present. IMSI When the service is used between the HLR and the SMS-IWMSC, the provided IMSI shall be the identifier which is stored in the Message Waiting Data file if no MSISDN is available in the context of T4 device triggering (see 3GPP TS 23.682 [148]). When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain the IMSI in the request sent from the MME (via an IWF), SGSN or MSC, or the User Identifier Alert previously sent in the MT Forward Short Message response, when the request is sent from the SMS Router to the SMS-GMSC. Correlation ID When the service is used between the HLR and the SMS-IWMSC, the provided SIP-URI-B within the Correlation ID parameter shall be the identifier which is stored in the Message Waiting Data file if no MSISDN is available in a retry context of SMS for IMS UE to IMS UE without MSISDN (see 3GPP TS 23.204 [134]). HLR-ID and SIP-URI-A shall be absent. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall not be included. Service Centre Address See definition in clauseÊ7.6.2. When the service is used between the HLR and the SMS-IWMSC, this information element shall contain the E.164 number of the Service Center. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain the E.164 number of the SMS-GMSC (or SMS Router) previously received in the SMS-GMSC Address IE in the MT Forward Short Message Request. Maximum UE Availability Time See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall be included, if available. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall not be included. SMS-GMSC Alert Event See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall either indicate that the MS is now available for MT SMS or that the MS has moved under the coverage of another MME, SGSN or MSC. New SGSN Number See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another SGSN. When present, it shall contain the E.164 number of the new SGSN serving the MS. New MME Number See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME. When present, it shall contain the E.164 number of the new MME serving the MS. New SGSN Diameter Address See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element shall be included if available and if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another SGSN. When present, it shall contain the Diameter Identity of the new SGSN serving the MS. New MME Diameter Address See definition in clauseÊ7.6.8. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF) or SGSN and the SMS-GMSC, this information element shall be included if available and if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME. When present, it shall contain the Diameter Identity of the new MME serving the MS. SMS-GMSC Diameter Address See definition in clauseÊ7.6.2. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MME (via an IWF), SGSN or MSC and the SMS-GMSC, this information element shall contain, if available, the Diameter Identity of the SMS-GMSC (or SMS Router) previously received in the SMS-GMSC Diameter Address IE in the MT Forward Short Message Request. New MSC Number See definition in clauseÊ7.6.8.33. When the service is used between the HLR and the SMS-IWMSC, this information element shall not be included. When the service is used between an MSC and the SMS-GMSC, this information element may be included if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MSC. When present, it shall contain the E.164 number of the new MSC serving the MS. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - System Failure; - Unexpected Data Value; - Data missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.6 MAP-INFORM-SERVICE-CENTRE service 12.6.1 Definition This service is used between the HLR and the gateway MSC (transiting an SMS Router, if present) to inform the Service Centre which MSISDN number is stored in the Message Waiting Data file. If the stored MSISDN number is not the same as the one received from the gateway MSC in the MAP-SEND-ROUTING-INFO-FOR-SM service primitive the stored MSISDN number is included in the message. Additionally the status of MCEF, MNRF, MNRG, MNR5G and MNR5GN3G flags and the inclusion of the particular Service Centre address in the Message Waiting Data list is informed to the gateway MSC when appropriate. If the HLR has stored a single MNRR, the value is included in the Absent Subscriber Diagnostic SM parameter. If the HLR has stored a second MNRR, the value of the MNRR for the MSC is included in the Absent Subscriber Diagnostic SM parameter and the value of the MNRR for the SGSN is included in the Additional Absent Subscriber Diagnostic SM parameter. The MAP-INFORM-SERVICE-CENTRE service is a non-confirmed service using the primitives from tableÊ12.6/1. 12.6.2 Service primitives TableÊ12.6/1: MAP-INFORM-SERVICE-CENTRE Parameter name Request Indication Invoke Id M M(=) MSIsdn-Alert C C(=) MWD Status C C(=) Absent Subscriber Diagnostic SM C C(=) Additional Absent Subscriber Diagnostic SM C C(=) SMSF 3GPP Absent Subscriber Diagnostic SM C C(=) SMSF Non 3GPP Absent Subscriber Diagnostic SM C C(=) 12.6.3 Parameter use Invoke id See definition in clauseÊ7.6.1. MSIsdn-Alert See definition in clauseÊ7.6.2. This parameter refers to the MSISDN stored in a Message Waiting Data file in the HLR. MWD Status See definition in clauseÊ7.6.8. This parameter indicates the status of the MCEF, MNRF, MNRG, MNR5G and MNR5GN3G flags and the status of the particular SC address presence in the Message Waiting Data list. Absent Subscriber Diagnostic SM See definition in clause 7.6.8. Additional Absent Subscriber Diagnostic SM See definition in clause 7.6.8. SMSF 3GPP Absent Subscriber Diagnostic SM See definition in clause 7.6.8. SMSF Non 3GPP Absent Subscriber Diagnostic SM See definition in clause 7.6.8. 12.7 MAP-SEND-INFO-FOR-MT-SMS service 12.7.1 Definition This service is used between the MSC and the VLR. The service is invoked by the MSC receiving a mobile terminated short message to request subscriber related information from the VLR. The MAP-SEND-INFO-FOR-MT-SMS service is a confirmed service using the primitives from tableÊ12.7/1. 12.7.2 Service primitives TableÊ12.7/1: MAP-SEND-INFO-FOR-MT-SMS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) SM RP DA M M(=) IMSI C C(=) MSISDN C C(=) User error C C(=) Provider error O 12.7.3 Parameter use Invoke id See definition in clauseÊ7.6.1. SM RP DA See definition in clauseÊ7.6.8. This parameter shall contain either an IMSI or an LMSI. IMSI See definition in clauseÊ7.6.2. This parameter shall be present if the SM RP DA parameter contains an LMSI; otherwise it shall be absent. MSISDN See definition in clauseÊ7.6.2. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown subscriber; - Unidentified Subscriber; - Absent subscriber; - Unexpected Data Value; - Data Missing; - Illegal subscriber; - Illegal equipment; - Subscriber busy for MT SMS; - System Failure. Provider error For definition of provider errors see clauseÊ7.6.1. 12.8 MAP-SEND-INFO-FOR-MO-SMS service 12.8.1 Definition This service is used between the MSC and the VLR. The service is invoked by the MSC which has to handle a mobile originated short message request to request the subscriber related information from the VLR. The MAP-SEND-INFO-FOR-MO-SMS service is a confirmed service using the primitives from tableÊ12.8/1. 12.8.2 Service primitives TableÊ12.8/1: MAP-SEND-INFO-FOR-MO-SMS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) Service Centre Address M M(=) MSISDN C C(=) User error C C(=) Provider error O 12.8.3 Parameter use Invoke id See definition in clauseÊ7.6.1. Service Centre Address See definition in clauseÊ7.6.2. MSISDN See definition in clauseÊ7.6.2. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Teleservice Not Provisioned; - Call Barred; - Unexpected Data Value; - Data Missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.9 MAP-MT-FORWARD-SHORT-MESSAGE service 12.9.1 Definition This service is used between the gateway MSC and the serving MSC or the SGSN (transiting an SMS Router, if present) or the IP-SM-GW to forward mobile terminated short messages. The MAP-MT-FORWARD-SHORT-MESSAGE service is a confirmed service using the service primitives given in tableÊ12.9/1. 12.9.2 Service primitives TableÊ12.9/1: MAP-MT-FORWARD-SHORT-MESSAGE Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) SM RP DA M M(=) SM RP OA M M(=) SM RP UI M M(=) C C(=) More Messages To Send C C(=) SM Delivery Timer C C(=) SM Delivery Start Time C C(=) SMS Over IP Only Indicator C C(=) Correlation ID C C(=) Maximum Retransmission Time C C(=) SMS-GMSC Address C C(=) SMS-GMSC Diameter Address C C(=) Requested Retransmission Time C C(=) User Identifier Alert C C(=) User error C C(=) Provider error O 12.9.3 Parameter use Invoke id See definition in clauseÊ7.6.1. SM RP DA See definition in clauseÊ7.6.8. This parameter can contain either an IMSI or a LMSI. The use of the LMSI is an operator option. The LMSI can be provided if it is received from the HLR. The IMSI is used if the use of the LMSI is not available. This parameter is omitted (i.e. is present and takes the value ""noSM-RP-DA"") in the mobile terminated subsequent SM transfers. When a Correlation ID is present, the IMSI parameter within SM RP DA shall be populated with the HLR-ID and the destination user is identified by the SIP-URI-B within the Correlation ID. SM RP OA See definition in clauseÊ7.6.8. The Service Centre address received from the originating Service Centre is inserted in this parameter. This parameter is omitted in the mobile terminated subsequent SM transfers. SM RP UI See definition in clauseÊ7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. A short message transfer protocol data unit may also be inserted in this parameter in the message delivery acknowledgement from the MSC or from the SGSN to the Service Centre. More Messages To Send See definition in clauseÊ7.6.8. The information from the MMS indication received from the Service Centre is inserted in this parameter. SM Delivery Timer See definition in clauseÊ7.6.8. SM Delivery Start Time See definition in clauseÊ7.6.8. SMS Over IP Only Indicator This indicator indicates by its presence that the IP-SM-GW shall try to deliver the short message via IMS without retrying to other domains. It shall be present in messages sent to the IP-SM-GW following a T4-Submit Trigger message (see 3GPP TS 23.682 [148]) but not in messages sent to MSC or SGSN (possibly transiting an SMS-Router). The indicator also indicates to the IP-SM-GW by its presence that the IMSI within the message is a real IMSI and not a MT-Correlation ID allocated by the IP-SM-GW. Correlation ID The Correlation ID parameter contains the SIP-URI-B identifying the (MSISDN-less) destination user and the SIP-URI-A identifying the (MSISDN-less) originating user. HLR-ID shall be absent from this parameter. Maximum Retransmission Time See definition in clauseÊ7.6.8. SMS-GMSC Address See definition in clauseÊ7.6.8. This information element shall be present if the Maximum Retransmission Time IE is present in the message. When present, it shall contain the E.164 number of the SMS-GMSC in the request sent by the SMS-GMSC or the E.164 number of the SMS Router in the request sent by the SMS Router. SMS-GMSC Diameter Address See definition in clauseÊ7.6.8. This information element shall be present if available and if the Maximum Retransmission Time IE is present in the message. When present, it shall contain the Diameter Identity of the SMS-GMSC in the request sent by the SMS-GMSC or the Diameter Identity of the SMS Router in the request sent by the SMS Router. Requested Retransmission Time See definition in clauseÊ7.6.8. This information element may only be present if the MT Forward Short Message Response contains the User error set to Absent Subscriber_SM and if the Maximum Retransmission Time information element is present in the MT Forward Short Message Request. It may be included by an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPPÊTSÊ23.272Ê[143] and 3GPP TS 23.040 [6]) or the SGSN if the UE is using a power saving mechanism (such as extended idle mode DRX) and the UE is currently not reachable. The Requested Retransmission Time shall not exceed the Maximum Retransmission Time received from the SMS-GMSC. User-Identifier-Alert See definition in clauseÊ7.6.8. This information element shall be present in the message from the SMS Router to the SMS-GMSC, if the Requested Retransmission Time IE is present in the message. When present, this information shall contain an MT Correlation ID. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unidentified subscriber; - Absent Subscriber_SM; - Subscriber busy for MT SMS; - Facility Not Supported; - Illegal Subscriber indicates that delivery of the mobile terminated short message failed because the mobile station failed authentication; - Illegal equipment indicates that delivery of the mobile terminated short message failed because an IMEI check failed, i.e. the IMEI was prohibited-listed or not permitted-listed; - System Failure; - SM Delivery Failure: - The reason of the SM Delivery Failure can be one of the following in the mobile terminated SM: - memory capacity exceeded in the mobile equipment; - protocol error; - mobile equipment does not support the mobile terminated short message service. - Unexpected Data Value; - Data Missing. Provider error For definition of provider errors see clauseÊ7.6.1. 12.10 MAP-MT-FORWARD-SM-FOR-VGCS service 12.10.1 Definition This service is used between the SMS gateway MSC and the Group Call Anchor MSC to forward mobile terminated short messages into an ongoing voice group call. The MAP-MT-FORWARD-SM-FOR-VGCS service is a confirmed service using the service primitives given in tableÊ12.10/1. 12.10.2 Service primitives TableÊ12.10/1: MAP-MT-FORWARD-SM-VGCS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) ASCI Call Reference M M(=) SM RP OA M M(=) SM RP UI M M(=) C C(=) Dispatcher List C C(=) Ongoing Call Indicator C C(=) User error C C(=) Provider error O 12.10.3 Parameter use Invoke id See definition in clauseÊ7.6.1. ASCI Call Reference Group call reference. This item is used to access the VGCS-GCR within the Anchor_MSC. SM RP OA See definition in clauseÊ7.6.8. The Service Centre address received from the originating Service Centre is inserted in this parameter. SM RP UI See definition in clauseÊ7.6.8. The short message transfer protocol data unit received from the Service Centre is inserted in this parameter. A short message transfer protocol data unit may also be inserted in this parameter in the message delivery acknowledgement from the MSC to the Service Centre. Dispatcher List A list of identities (international E.164 phone numbers) identifying the dispatchers of the VGCS call. It shall be present if received from the GCR; otherwise shall be absent. Ongoing Call Indicator Indicates by its presence that the VGCS call is ongoing. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - System Failure; - Unexpected Data Value. Provider error For definition of provider errors see clauseÊ7.6.1. 13 Network-Requested PDP Context Activation services 13.1 MAP_SEND_ROUTING_INFO_FOR_GPRS service 13.1.1 Definition This service is used by the GGSN to request GPRS routing information from the HLR. 13.1.2 Service primitives TableÊ13.1/1: MAP_SEND_ROUTING_INFO_FOR_GPRS Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) GGSN address C C(=) C C(=) GGSN number M M(=) SGSN address C C(=) Mobile Not Reachable Reason C C(=) User error C C(=) Provider error O 13.1.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. GGSN address This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR. GGSN number See definition in clauseÊ7.6.2. SGSN address This parameter shall be present if the outcome of the Send Routing Info For GPRS request to the GPRS application process in the HLR is positive. Mobile Not Reachable Reason This parameter shall be present if the outcome of the Send Routing Info For GPRS request to the GPRS application process in the HLR is positive and the MNRG flag in the HLR is set. See definition in clause 7.6.3.51. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - Absent Subscriber; - System Failure; - Data Missing; - Unexpected Data Value; - Unknown Subscriber. The diagnostic in the Unknown Subscriber may indicate ""Imsi Unknown"" or ""Gprs Subscription Unknown"". - Call Barred; This error will indicate that the received PDP PDUs in the GGSN shall be barred for this MS due to Operator Determined Barring. (The CallBarringCause must be the operatorBarring.) Provider error These are defined in clause 7.6.1. 13.2 MAP_FAILURE_REPORT service 13.2.1 Definition This service is used by the GGSN to inform the HLR that network requested PDP-context activation has failed. 13.2.2 Service primitives TableÊ13.2/1: MAP_FAILURE_REPORT Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) GGSN address C C(=) C C(=) GGSN number M M(=) User error C C(=) Provider error O 13.2.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. GGSN address This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR. GGSN number See definition in clauseÊ7.6.2. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error These are defined in clause 7.6.1. 13.3 MAP_NOTE_MS_PRESENT_FOR_GPRS service 13.3.1 Definition This service is used by the HLR to inform the GGSN that the MS is present for GPRS again. 13.3.2 Service primitives TableÊ13.3/1: MAP_NOTE_MS_PRESENT_FOR_GPRS Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) IMSI M M(=) GGSN address C C(=) SGSN address M M(=) User error C C(=) Provider error O 13.3.3 Parameter definition and use Invoke Id See definition in clauseÊ7.6.1. IMSI See definition in clauseÊ7.6.2. GGSN address This parameter shall be present if the protocol-converting GSN is used between the GGSN and the HLR. SGSN address See definition in clauseÊ7.6.2. User error This parameter is sent by the responder when an error is detected and if present, takes one of the following values: - System Failure; - Data Missing; - Unexpected Data Value; - Unknown Subscriber. Provider error These are defined in clause 7.6.1. 13A Location Service Management Services 13A.1 MAP-SEND-ROUTING-INFO-FOR-LCS Service 13A.1.1 Definition This service is used between the GMLC and the HLR to retrieve the routing information needed for routing a location service request to the servicing VMSC, SGSN, MME or 3GPP AAA server. The MAP-SEND-ROUTING-INFO-FOR-LCS is a confirmed service using the primitives from tableÊ13A.1/1. 13A.1.2 Service Primitives TableÊ13A.1/1: MAP-SEND-ROUTING-INFO-FOR-LCS Parameter name Request Indication Response Confirm Invoke Id M M(=) M(=) M(=) MLC Number M M(=) MSISDN C C(=) C C(=) IMSI C C(=) C C(=) LMSI C C(=) Network Node Number C C(=) GPRS Node Indicator C C(=) Additional Number C C(=) Supported LCS Capability Sets C C(=) Additional LCS Capability Sets C C(=) MME Name C C(=) SGSN Name C C(=) SGSN Realm C C(=) AAA Server Name C C(=) V-GMLC Address U C(=) Additional V-GMLC Address U C(=) H-GMLC Address C C(=) PPR Address U C(=) User error C C(=) Provider error O 13A.1.3 Parameter Use Invoke id See definition in clauseÊ7.6.1. MLC Number See definition in clauseÊ7.6.2. MSISDN See definition in clauseÊ7.6.2. The request shall carry either the IMSI or MSISDN. The response shall carry whichever of these was not included in the request (see 3GPP TS 23.271 for details). IMSI See definition in clauseÊ7.6.2. LMSI See definition in clauseÊ7.6.2. It is an operator option to provide this parameter from the VLR; it is mandatory for the HLR to include the LMSI in a successful response, if the VLR has used the LMSI. Network Node Number See definition in clauseÊ7.6.2. This parameter is provided in a successful response. If the Network Node Number and Additional Number are received in the GMLC, the Network Node Number is used in preference to the Additional Number. If the serving node has no ISDN number, the HLR shall populate the Network Node Number parameter with a dummy ISDN number of ""0"". GPRS Node Indicator See definition in clauseÊ7.6.8. The presence of this parameter is mandatory only if the SGSN number is sent in the Network Node Number. Additional Number See definition in clauseÊ7.6.2. This parameter is provided in a successful response. If the Network Node Number and Additional Number are received in the GMLC, the Network Node Number is used in preference to the Additional Number. Supported LCS Capability Sets See definition in clauseÊ7.6.11. This parameter indicates the LCS capability of the serving node that is indicated by the Network Node Number. This parameter is provided only if LCS capability sets are available in HLR and Network Node Number is present in this message. Additional LCS Capability Sets See definition in clauseÊ7.6.11. This parameter indicates the LCS capability of the serving node that is indicated by the Additional Number. This parameter is provided only if LCS capability sets are available in HLR and Additional Number is present in this message. MME Name See definition in clauseÊ7.6.2. This parameter is provided in a successful response when the serving node is an MME. SGSN Name See definition in clauseÊ7.6.2. This parameter is provided in a successful response when the serving node is an SGSN and the SGSN has indicated its support for Lgd interface. SGSN Realm See definition in clauseÊ7.6.2. This parameter is provided in a successful response when the serving node is an SGSN and the SGSN has indicated its support for Lgd interface. AAA Server Name See definition in clauseÊ7.6.2. This parameter is provided in a successful response when the serving node is a 3GPPÊAAA server. V-GMLC address See definition in clauseÊ7.6.2. . This parameter indicates the V-GMLC address of the serving node that is indicated by the Network Node Number. Additional V-GMLC address See definition in clauseÊ7.6.2. This parameter indicates the V-GMLC address of the serving node that is indicated by the Additional Number. This parameter is provided only if additional LCS capability sets are available in HLR and Additional Number is present in this message. H-GMLC address See definition in clauseÊ7.6.2. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. PPR address See definition in clauseÊ7.6.2. User error The following errors defined in clauseÊ7.6.1 may be used, depending on the nature of the fault: - Unknown subscriber; - Absent Subscriber; - Facility Not Supported; - System failure; - Unexpected Data Value; - Data missing; - Unauthorised requesting network. Provider error For definition of provider errors see clauseÊ7.6.1. 13A.2 MAP-PROVIDE-SUBSCRIBER-LOCATION Service 13A.2.1 Definition This service is used by a GMLC to request the location of a target MS from the visited MSC or SGSN at any time. This is a confirmed service using the primitives from tableÊ13A.2/1."
"13A.2.2 Service Primitives TableÊ13A.2/1: Provide_Subscriber_Location Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) Location Type M M(=) MLC Number M M(=) LCS Client ID M M(=) Privacy Override U C(=) IMSI C C(=) MSISDN C C(=) LMSI C C(=) LCS Priority C C(=) LCS QoS C C(=) IMEI U C(=) Supported GAD Shapes C C(=) LCS-Reference Number C C(=) LCS Codeword C C(=) LCS Service Type Id C C(=) LCS Privacy Check C C(=) Area Event Info C C(=) H-GMLC Address C C(=) Reporting PLMN List C C(=) PeriodicLDRInfo C C(=) MO-LR Short Circuit Indicator C C(=) C C(=) Location Estimate M M(=) GERAN Positioning Data C C(=) UTRAN Positioning Data C C(=) GERAN GANSS Positioning Data C C(=) UTRAN GANSS Positioning Data C C(=) UTRAN Additional Positioning Data C C(=) UTRAN Barometric Pressure Measurement C C(=) UTRAN Civic Address C C(=) Age of Location Estimate C C(=) Additional Location Estimate C C(=) Deferred MT-LR Response Indicator C C(=) Cell Id Or SAI C C(=) Accuracy Fulfilment Indicator C C(=) Target Serving Node for Handover C C(=) User error C C(=) Provider error O 13A.2.3 Parameter Definition and Use All parameters are defined in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in 3GPP TS 23.271 [26a]. Location Type This parameter identifies the type of location information requested. MLC Number This is the E.164 number of the requesting GMLC. LCS Client ID This parameter provides information related to the identity of an LCS client. Privacy Override This parameter indicates if MS privacy is overridden by the LCS client when the GMLC and VMSC or SGSN for an MT-LR are in the same country. IMSI The IMSI is provided to identify the target MS. At least one of the IMSI or MSISDN is mandatory. MSISDN The MSISDN is provided to identify the target MS. At least one of the IMSI or MSISDN is mandatory. LMSI The LMSI shall be provided if previously supplied by the HLR. This parameter is only used in the case of the MT-LR for CS domain. LCS Priority This parameter indicates the priority of the location request. LCS QoS This parameter indicates the required quality of service in terms of response time and accuracy. IMEI The requirements for its presence are specified in 3GPP TS 23.271 [26a]. Supported GAD Shapes This parameter indicates which of the shapes defined in 3GPP TS 23.032 [122] are supported. LCS-Reference Number This parameter shall be included if a deferred MT-LR procedure is performed for a UE available event, an area event or a periodic positioning event. LCS Codeword See definition in clause 7.6.11.18. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. LCS Service Type Id See definition in clause 7.6.11.15. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. LCS Privacy Check See definition in clause 7.6.11. The requirements for its and its components presence are specified in 3GPP TS 23.271 [26a]. Area Event Info See definition in clauseÊ7.6.11. The parameter shall be included if a deferred MT-LR procedure is performed for an area event. H-GMLC address See definition in clauseÊ7.6.2. The parameter shall be included if a deferred MT-LR procedure is performed for a UE available event, an area event or a periodic positioning event. Location Estimate This parameter provides the location estimate if this is encoded in one of the supported geographical shapes. Otherwise this parameter shall consist of one octet, which shall be discarded by the receiving node. GERAN Positioning Data This parameter indicates the usage of each positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If Positioning Data received from the RAN contains no Positioning Methods, Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. UTRAN Positioning Data This parameter indicates the usage of each positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no Positioning Methods, UTRAN Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. GERAN GANSS Positioning Data This parameter indicates the usage of each GANSS positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If GANSS Positioning Data received from the RAN contains no GANSS method, GERAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. UTRAN GANSS Positioning Data This parameter indicates the usage of each GANSS positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no GANSS Positioning Data Set, UTRAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Additional Positioning Data This parameter indicates the usage of each Additional positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no Additional Positioning Data Set, UTRAN Additional Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Barometric Pressure Measurement This parameter indicates the uncompensated barometric pressure measurement at the MS. The absence of this parameter implies that a barometric pressure measurement was not available or could not be successfully obtained. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Civic Address This parameter indicates the civic address of the MS. The absence of this parameter implies that a civic address was not available or could not be successfully obtained. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. Age of Location Estimate This parameter indicates how long ago the location estimate was obtained. Additional Location Estimate This parameter provides the location estimate when not provided by the Location Estimate parameter. It may be sent only if the parameter Supported GAD Shapes has been received in the Provide Subscriber Location indication and the shape to be included is supported by the GMLC. Deferred MT-LR Response Indicator See definition in clauseÊ7.6.11.2. Cell Id Or SAI For GERAN access, this parameter indicates Global Cell Identifier of the cell that the served subscriber is currently attached to. For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to. This parameter is included only for North American Emergency Calls as described in 3GPP TS 23.271 [26a]. Accuracy Fulfilment Indicator See definition in clauseÊ7.6.11.28. MO-LR Short Circuit Indicator This parameter indicates whether MO-LR Short Circuit is permitted for periodic location. Reporting PLMN List This parameter indicates a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made. Periodic LDR information This parameter indicates the reporting amount and reporting interval of deferred periodic location. Target Serving Node for Handover This parameter provides the address of the target side serving node for handover of an IMS Emergency Call. User error This parameter is sent by the responder when the location request has failed or cannot proceed and if present, takes one of the following values defined in clauseÊ7.6.1. - System Failure; - Data Missing; - Unexpected Data Value; - Facility Not Supported; - Unidentified Subscriber; - Illegal Subscriber; - Illegal Equipment; - Absent Subscriber (diagnostic information may also be provided); - Unauthorised requesting network; - Unauthorised LCS Client with detailed reason; - Position method failure with detailed reason. Provider error These are defined in clause 7.6.1. 13A.3 MAP-SUBSCRIBER-LOCATION-REPORT Service 13A.3.1 Definition This service is used by a VMSC or SGSN to provide the location of a target MS to a GMLC when a request for location is either implicitly administered or made at some earlier time. This is a confirmed service using the primitives from tableÊ13A.3/1. 13A.3.2 Service Primitives TableÊ13A.3/1: Subscriber_Location_Report Parameter name Request Indication Response Confirm Invoke id M M(=) M(=) M(=) LCS Event M M(=) LCS Client ID M M(=) Network Node Number M M(=) IMSI C C(=) MSISDN C C(=) NA-ESRD C C(=) C C(=) NA-ESRK C C(=) C C(=) IMEI U C(=) Location Estimate C C(=) GERAN Positioning Data C C(=) UTRAN Positioning Data C C(=) GERAN GANSS Positioning Data C C(=) UTRAN GANSS Positioning Data C C(=) UTRAN Additional Positioning Data C C(=) UTRAN Barometric Pressure Measurement C C(=) UTRAN Civic Address C C(=) Age of Location Estimate C C(=) LMSI U C(=) GPRS Node Indicator C C(=) Additional Location Estimate C C(=) Deferred MT-LR Data C C(=) LCS-Reference Number C C(=) C C(=) NA-ESRK Request C C(=) Cell Id Or SAI C C(=) H-GMLC Address C C(=) C C(=) LCS Service Type Id C C(=) Pseudonym Indicator C C(=) Accuracy Fulfilment Indicator C C(=) Sequence Number C C(=) Periodic LDR Info C C(=) MO-LR Short Circuit Indicator C C(=) C C(=) Target Serving Node for Handover C C(=) Reporting PLMN List C C(=) User error C C(=) Provider error O 13A.3.3 Parameter Definition and Use All parameters are defined in clauseÊ7.6. The use of these parameters and the requirements for their presence are specified in. 3GPP TS 23.271 [26a]. LCS Event This parameter indicates the event that triggered the Subscriber Location Report. LCS Client ID This parameter provides information related to the identity of the recipient LCS client. Network Node Number See definition in clauseÊ7.6.2. This parameter provides the address of the sending node. IMSI The IMSI shall be provided if available to the VMSC or SGSN. MSISDN The MSISDN shall be provided if available to the VMSC or SGSN. NA-ESRD If the target MS has originated an emergency service call in North America, the NA-ESRD shall be provided by the VMSC if available. If the target MS has originated an emergency service call in North America and NA-ESRK Request is included in Subscriber_Location_Report-Arg, an NA-ESRK or NA-ESRD, but not both, may also be included in the response to the MSC, see 3GPP TS 23.271 [26a]. NA-ESRK If the target MS has originated an emergency service call in North America, the NA-ESRK shall be provided by the VMSC if assigned. If the target MS has originated an emergency service call in North America and NA-ESRK Request is included in Subscriber_Location_Report-Arg, an NA-ESRK or NA-ESRD, but not both, may also be included in the response to the MSC, see 3GPP TS 23.271 [26a]. IMEI The requirements for its presence are specified in 3GPP TS 23.271 [26a]. Location Estimate This parameter provides the location estimate. The absence of this parameter implies that a location estimate was not available or could not be successfully obtained. If the obtained location estimate is not encoded in one of the supported geographical shapes then this parameter shall consist of one octet, which shall be discarded by the receiving node. GERAN Positioning Data This parameter indicates the usage of each positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If Positioning Data received from the RAN contains no Positioning Methods, Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. UTRAN Positioning Data This parameter indicates the usage of each positioning method that was successfullyattempted to determine the location estimate. If Position Data received from the RAN contains no Positioning Methods, UTRAN Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. GERAN GANSS Positioning Data This parameter indicates the usage of each GANSS positioning method that was attempted to determine the location estimate either successfully or unsuccessfully. If GANSS Positioning Data received from the RAN contains no GANSS method, GERAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is GERAN, see 3GPP TS 23.271 [26a]. UTRAN GANSS Positioning Data This parameter indicates the usage of each GANSS positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no GANSS Positioning Data Set, UTRAN GANSS Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Additional Positioning Data This parameter indicates the usage of each Additional positioning method that was successfully attempted to determine the location estimate. If Position Data received from the RAN contains no Additional Positioning Data Set, UTRAN Additional Positioning Data is excluded from the MAP message. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Barometric Pressure Measurement This parameter indicates the uncompensated barometric pressure measurement at the MS. The absence of this parameter implies that a barometric pressure measurement was not available or could not be successfully obtained. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. UTRAN Civic Address This parameter indicates the civic address of the MS. The absence of this parameter implies that a civic address was not available or could not be successfully obtained. It may be included in the message only if the access network is UTRAN, see 3GPP TS 23.271 [26a]. Age of Location Estimate This parameter indicates how long ago the location estimate was obtained. LMSI The LMSI may be provided if assigned by the VLR. GPRS Node Indicator See definition in clauseÊ7.6.8. This presence of this parameter is mandatory only if the SGSN number is sent in the Network Node Number. Additional Location Estimate This parameter provides the location estimate when not provided by the Location Estimate parameter.. Deferred MT-LR Data See definition in clauseÊ7.6.11.3. LCS-Reference Number This parameter shall be included if the Subscriber Location Report is the response to a deferred MT location request. NA-ESRK Request If the target MS has originated an emergency service call in North America, NA-ESRK Request may be included to indicate that the MSC is able to accept NA-ESRK in the Response message, see clause 7.6.11.19. Cell Id Or SAI For GERAN access, this parameter indicates Global Cell Identifier of the cell that the served subscriber is currently attached to. For UTRAN access, this parameter contains the Service Area Identifier for the cell that the subscriber is currently attached to. This parameter is included only for Emergency Calls as described in 3GPP TS 23.271 [26a]. H-GMLC address See definition in clauseÊ7.6.2. The parameter shall be included if the Subscriber Location Report is the response to a deferred MT location request for a UE available event, an area event or a periodic positioning event. This parameter shall be included in a Subscriber Location Report response if a deferred MO-LR TTTP procedure is initiated for a periodic positioning event. LCS Service Type Id See definition in clause 7.6.11.15. The requirements for its presence are specified in 3GPP TS 23.271 [26a]. Pseudonym Indicator This parameter indicates by its presence that the pseudonym is required. Refer to 3GPP TS 23.271 [26a]. Accuracy Fulfilment Indicator For a mobile terminated periodic LDR, this parameter indicates whether the obtained location estimate satisfies the requested accuracy or not, provided that this indication is obtained from RAN or the UE with the location estimate. Periodic LDR Information This parameter refers to the periodic reporting interval and reporting amount of the deferred periodic location. MO-LR Short Circuit Indicator This parameter indicates whether MO-LR Short Circuit is permitted for periodic location. Reporting PLMN List This parameter indicates a list of PLMNs in which subsequent periodic MO-LR TTTP requests will be made. Sequence Number This parameter refers to the number of the periodic location reports completed. The sequence number would be set to 1 in the first location report and increment by 1 for each new report. When the number reaches the reporting amountÊvalue, the H-GMLC (for a periodic MT-LR or a periodic MO-LR transfer to third party) will know the procedure is complete. For details see 3GPP TS 23.271 [26a]. Target Serving Node for Handover This parameter provides the address of the target side serving node for handover of an IMS Emergency Call. User error This parameter is sent by the responder when the received message contains an error, cannot be forwarded or stored for an LCS client or cannot be accepted for some other reason and if present, takes one of the following values defined in clauseÊ7.6.1. - System Failure; - Data Missing; - Unexpected Data Value; - Resource Limitation; - Unknown Subscriber; - Unauthorised requesting network; - Unknown or unreachable LCS Client. Provider error These are defined in clause 7.6.1. 13A.4 Void 13A.4.1 Void 13A.4.2 Void 13A.4.3 Void 13A.5 Void 13A.5.1 Void 13A.5.2 Void 13A.5.3 Void 13A.6 Void 13A.6.1 Void 13A.6.2 Void 13A.6.3 Void 13A.7 Void 13A.7.1 Void 13A.7.2 Void 13A.7.3 Void 13A.8 Void 13A.8.1 Void 13A.8.2 Void 13A.8.3 Void 13A.9 Void 13A.9.1 Void 13A.9.2 Void 13A.9.3 Void 14 General 14.1 Overview Clauses 14 to 17 specify the protocol elements to be used to provide the MAP services described in clauseÊ7. ClauseÊ15 specifies the elements of procedures for the MAP protocol. ClauseÊ16 specifies the mapping onto TC service primitives. ClauseÊ17 specifies the application contexts, operation packages and abstract syntaxes for the MAP protocol as well as the encoding rules to be applied. 14.2 Underlying services The MAP protocol relies on the services provided by the Transaction Capabilities (TC) of Signalling System Number No. 7, as referenced in clauseÊ6. 14.3 Model The MAP Protocol Machine (MAP PM) can be modelled as a collection of service state machines (SSMs) - one per MAP specific service invoked - coordinated by a MAP dialogue control function with its one state machine: MAP dialogue state machine (DSM). There are two types of Service State Machines: Requesting Service State Machines (RSM) and Performing Service State Machines (PSM). A new invocation of a MAP PM is employed on the receipt of a MAP-OPEN request primitive or a TC-BEGIN indication primitive. Each invocation controls exactly one MAP dialogue. For each MAP specific service invoked during a dialogue, a MAP RSM is created at the requestor's side and a MAP PSM is created at the performer's side. This modelling is used only to facilitate understanding and the MAP behaviour descriptions and is not intended to suggest any implementation. SDL descriptions are organised according to this model. How the MAP-service-user and the MAP refer to a MAP dialogue (i.e. a MAP PM invocation) is a local implementation matter. How TC dialogue identifiers are assigned to a MAP PM invocation is also a local implementation matter. 14.4 Conventions The behaviour of the MAP PM depends on the application-context-name associated with the dialogue. One major difference is that the MAP requests the transfer of the application-context-name by TC only for those contexts which do not belong to the so-called ""version one context set"". The ""version one context set"" is a set of application-contexts which model the behaviour of a MAP V1 implementation according to the latest phase 1 version of GSMÊ09.02. This set is defined in clauseÊ15. The procedures described in clauseÊ15 are used when the application-context-name does not refer to a dialogue between an MSC and its VLR. When the application-context-name refers to a dialogue between an MSC and its VLR the MAP PM procedures are a local implementation matter. 15 Elements of procedure 15.1 Handling of unknown operations Unknown operations (i.e. a standard operation introduced in a later version of the MAP specification, or a private operation) can be introduced into MAP in a backwards compatible way. This means that the receiver of an unknown operation shall, if the dialogue state allows it, send a TC-REJECT component to the sender of the operation indicating 'unrecognised operation' and continue with the processing of further components or messages exchanged within the dialogue as if the unknown operation had not been received. The standardised structure of a MAP dialogue shall not be affected by the invocation of unknown operations, i.e. if a dialogue uses only a TC-BEGIN message which is acknowledged by a TC-END message, a TC-CONTINUE message shall not be used to invoke an unknown operation. However the standardised structure of a MAP dialogue may be affected by the rejection of unknown operations, i.e. if a dialogue uses only a TC-BEGIN message which is acknowledged by a TC-END message, a TC-CONTINUE message followed by a TC-END message may be used to carry the rejection of an unknown operation and the response to the standardised operation. The entity which initiated a dialogue whose standardised structure is a TC-BEGIN message which is acknowledged by a TC-END message shall not send any messages in that dialogue after the TC-BEGIN. Note that if the dialogue structure is affected as described in this paragraph the TC-CONTINUE shall include the dialogue portion required to confirm the acceptance of the dialogue. Unknown operations may be invoked in the following types of message (there is no restriction as to how many unknown operations can be invoked in a message): - TC-BEGIN: the component to invoke the unknown operation shall follow the component of the standard operation which is included in this message. - TC-CONTINUE: the component to invoke the unknown operation may be transported as the only component in a stand-alone message or may be grouped with existing operations. In the latter case a specific sequencing of components is not required. - TC-END: if the component to invoke the unknown operation is grouped with an existing operation a specific sequencing of components is not required The TC-REJECT component may be sent in the following messages: - TC-CONTINUE or TC-END: either as the only component of the message or grouped with an existing component. The choice is up to the MAP-Service User. If the received message contains only unknown operations the MAP-Service User shall send the TC-REJECT components in a TC-CONTINUE message to the peer entity, if the dialogue state allows it. If the received message contains unknown operations and standard operations and the standardised structure of the dialogue requires the response to the standard operation to be sent within a TC-END message, then the MAP-Service User may send the response to the standard operations and the TC-REJECT components for the unknown operations in a TC-CONTINUE message followed by a TC-END message. Neither a specific distribution of the components to the TC messages nor a specific sequencing of components is required. Note that the SDL diagrams of clauses 19Ê-Ê25 do not show the report to the MAP-Service User about the reception of the unknown operation. This has been done for simplicity of description; the MAP PM may inform the MAP-Service User. The sender of the unknown operation shall ensure that there is enough room in the used message for the unknown operation. 15.2 Dialogue establishment The establishment of a MAP dialogue involves two MAP-service-users: the dialogue-initiator and the dialogue-responder. This procedure is driven by the following signals: - a MAP-OPEN request primitive from the dialogue-initiator; - a TC-BEGIN indication primitive occurring at the responding side; - a MAP-OPEN response primitive from the dialogue-responder; - the first TC-CONTINUE indication primitive occurring at the initiating side; and under specific conditions: - a TC-END indication primitive occurring at the initiating side; - a TC-U-ABORT indication primitive occurring at the initiating side; - a TC-P-ABORT indication primitive occurring at the initiating side. One instance of the MAP dialogue state machine runs at the initiating side, and one at the responding side. 15.2.1 Behaviour at the initiating side The behaviour of the MAP dialogue state machine at the initiating side is defined in sheets 1ÊÐÊ8 of the process MAP_DSM (figure 15.6/3). Sheet 3: When the MAP dialogue state machine at the initiating side is waiting for a response from the responding side, a TC-END indication which echoes the AC name which was sent in the TC-BEGIN indicates acceptance of the dialogue. Sheet 3: If the dialogue opening is accepted, any components included in the TC-END are processed and passed to the MAP-Service User. The dialogue is closed by sending a MAP-CLOSE to the MAP-Service User. Sheet 3, sheet 4, sheet 5, sheet 6, sheet 7, sheet 8: when a dialogue is terminated, the MAP dialogue state machine terminates all instances of the Requesting_MAP_SSM which are active for this dialogue. Sheet 4: A TC-P-ABORT with an abort parameter Incorrect_Transaction_Portion indicates that the responding side does not support a MAP version higher than 1. This triggers a MAP-OPEN confirm indicating that the dialogue is refused, with a refuse reason potential version incompatibility. The MAP-Service User may then decide to retry the dialogue at MAP version 1. Sheet 8: When the MAP dialogue state machine at the initiating side is waiting for a response from the responding side, a TC-CONTINUE indication which echoes the AC name which was sent in the TC-BEGIN indicates acceptance of the dialogue. Sheet 8: If the dialogue opening is accepted, any components included in the TC-CONTINUE are processed and passed to the MAP-Service User. The dialogue has then reached the established state. 15.2.2 Behaviour at the responding side The behaviour of the MAP dialogue state machine at the responding side is defined in sheets 0ÊÐÊ14 of the process MAP_DSM (figure 15.6/3). Sheet 9: If no application context information is included in the TC-BEGIN indication, this implies a MAP version 1 dialogue. An explicit application context indicating version 1 is treated as abnormal behaviour. Sheet 11: The v1 application context name which corresponds to a v1 operation is derived using the information in table 15.2/1. TableÊ15.2/1: Mapping of V1 operation codes on to application-context-names Operation Application-context-name (note 1) updateLocation networkLocUpContext-v1 cancelLocation locationCancellationContext-v1 provideRoamingNumber roamingNumberEnquiryContext-v1 insertSubscriberData subscriberDataMngtContext-v1 deleteSubscriberData subscriberDataMngtContext-v1 sendParameters infoRetrievalContext-v1 networkLocUpContext-v1 (note 2) beginSubscriberActivity networkFunctionalSsContext-v1 sendRoutingInfo locationInfoRetrievalContext-v1 performHandover handoverControlContext-v1 reset resetContext-v1 activateTraceMode tracingContext-v1 deactivateTraceMode tracingContext-v1 sendRoutingInfoForSM shortMsgGatewayContext-v1 forwardSM shortMsgRelayContext-v1 reportSM-deliveryStatus shortMsgGatewayContext-v1 noteSubscriberPresent mwdMngtContext-v1 alertServiceCentreWithoutResult shortMsgAlertContext-v1 checkIMEI EquipmentMngtContext-v1 NOTE 1: These symbolic names refer to the object identifier value defined in clauseÊ17 and allocated to each application-context used for the MAP. NOTE 2: The choice between the application contexts is based on the parameters received in the operation. Sheet 12: If the dialogue is accepted, each component present in the TC-BEGIN is forwarded to an instance of a Performing_MAP_SSM, by executing the procedure Process_Components. Sheet 13: If the MAP dialogue state machine receives a MAP-OPEN response with a result accepted, it waits for any MAP specific service request or response primitives or a MAP-DELIMITER request. Sheet 13, sheet 14: When a dialogue is terminated, the MAP dialogue state machine terminates all instances of the Requesting_MAP_SSM or Performing_MAP_SSM which are active for this dialogue. Sheet 14: A MAP-DELIMITER request triggers a TC-CONTINUE request to accept the dialogue. The dialogue has then reached the established state. 15.3 Dialogue continuation Once established the dialogue is said to be in a continuation phase. The behaviour of the MAP dialogue state machine in this phase is defined in sheets 15ÊÐÊ17 of the process MAP_DSM (figure 15.6/3). Both MAP users can request the transfer of MAP APDUs until one of them requests the termination of the dialogue. Normal closure of an established dialogue is shown on sheet 16; abnormal termination is shown on sheet 17. 15.4 Load control If an entity which should respond to a MAP dialogue opening request is overloaded, it uses the AC of the request to determine whether to discard the request. The priority level allocated to each application-context is described in clauseÊ5, tables 5.1/1, 5.1/2, and 5.1/3. 15.5 Procedures for MAP specific services This clauseÊdescribes the MAP procedures for MAP specific services. These procedures are driven by the following types of event: - a MAP specific request or a MAP specific response primitive; - a component handling primitive from TC. A Service State Machine is activated when of one of the following signals is received: - a MAP request primitive, which activates a requesting SSM; - a TC-INVOKE indication primitive without a linked identifier, which activates a performing SSM. For component handling primitives there are two types of event: - events which activate a Service State Machine or which can be related to an existing one; - events which cannot be related to a Service State Machine. 15.5.1 Service invocation The behaviour of the requesting SSM which handles a service is defined by the SDL for the process Requesting_MAP_SSM. The requesting SSM receives a MAP service request from the MAP-Service User via the MAP dialogue state machine and sends a TC-INVOKE request to TCAP. When a confirm is received from TCAP via the MAP dialogue state machine, the requesting SSM forwards a MAP service confirm to the MAP-Service User. The response to a MAP service invocation may come in the form of a linked request. If the linked request corresponds to a class 4 operation, this is handled by the requesting SSM. If the linked request corresponds to a class 1, 2 or 3 operation, the MAP dialogue state machine sends a notification to the requesting SSM and creates an instance of a performing SSM to handle the linked request. The test ""Linked_Operation_Allowed"" on sheet 3 of the process Requesting_MAP_SSM takes the (TRUE) exit if the definition of the parent operation includes the received linked operation as a permitted linked operation; otherwise the test takes the (FALSE) exit. The mapping of MAP specific services on to remote operations is given in tableÊ16.2/1. 15.5.2 Void 15.5.3 Service invocation receipt The behaviour of the performing SSM which handles a service is defined by the SDL for the process Performing_MAP_SSM. The performing SSM receives a TC-INVOKE component from TCAP via the MAP dialogue state machine and sends a MAP service indication to the MAP-Service User. When a MAP service response is received from the MAP-Service User via the MAP dialogue state machine, the performing SSM forwards a TC-RESULT or TC-U-ERROR component to TCAP. 15.5.4 Void 15.5.5 Handling of components received from TC The procedure Process_Components shows the handling of components received in a TC-BEGIN, TC-CONTINUE or TC-END message. Sheet 2: If a linked invoke component corresponds to a class 4 operation, the MAP dialogue state machine sends it to the requesting SSM instance identified by the linked invoke ID. If a linked invoke component corresponds to any other class of operation, the MAP dialogue state machine sends a notification to the requesting SSM instance identified by the linked invoke ID, creates an instance of a performing SSM and sends the invoke component to it. 15.6 SDL descriptions The following SDL specification describes a system which includes three blocks: MAP-user, MAP-provider and TC. Such a system resides in each network component supporting MAP and communicates with its peers via the lower layers of the signalling network which are part of the environment. Only the MAP-provider is fully described in this clause. The various types of processes which form the MAP-User block and the TC block are described respectively in clauses 18 to 25 of the present document and in CCITT Recommendation Q.774. The MAP-Provider block communicates with the MAP_USER via two channels U1 and U2. Via U1 the MAP-provider receives the MAP request and response primitives. Via U2 it sends the MAP indication and confirm primitives. The MAP-Provider block communicates with TC via two channels P1 and P2. Via P1 the MAP-Provider sends all the TC request primitives. Via P2 it receives all the TC indication primitives. The MAP-Provider block is composed of the four following types of process: a) MAP_DSM: This type of process handles a dialogue for transport of MAP messages. There exists one process instance per MAP dialogue. b) Load_Ctrl: This type of process is in charge of load control. There is only one instance of this process in each system. c) Requesting_MAP_SSM: This type of process handles a MAP service requested during a dialogue. An instance of this process is created by the instance of the MAP_DSM process for each requested MAP service. d) Performing_MAP_SSM: This type of process handles a MAP service performed during a dialogue. An instance of this process is created by the instance of the MAP_DSM process for each MAP service to be performed. A process MAP_DSM exchanges external signals with other blocks as well as internal signals with the other processes of the MAP-Provider block. The external signals are either MAP service primitives or TC service primitives. The signal routes used by the various processes are organised as follows: a) A process MAP_DSM receives and sends events from/to the MAP_user via signal route User1/User2. These routes use channels U1 and U2 respectively. b) A process MAP_DSM receives and sends events from/to the TCAP via signal route TC1/TC2. These routes use channels P1 and P2 respectively. c) A process MAP_DSM receives and sends events from/to the LOAD_CTRL process via signal route Load1/Load2. These routes are internal. d) A process MAP_DSM sends events to the Performing_MAP_SSM processes via signal route Intern1. This route is internal. e) A process MAP_DSM sends events to the Requesting_MAP_SSM processes via signal route Intern2. This route is internal. f) A process Performing_MAP_SSM sends events to the MAP_USER via signal route User3. This route uses channel U2. g) A process Performing_MAP_SSM sends events to the TCAP via signal route TC3. This route uses channel P1. h) A process Requesting_MAP_SSM sends events to the MAP_USER via signal route User4. This route uses channel U2. i) A process Requesting_MAP_SSM sends events to the TCAP via signal route TC4. This route uses channel P1. Figure 15.6/1: System MAP_Stack Figure 15.6/2: Block MAP_Provider Figure 15.6/3a: Process MAP_DSM (sheet 1) Figure 15.6/3b: Process MAP_DSM (sheet 2) Figure 15.6/3c: Process MAP_DSM (sheet 3) Figure 15.6/3d: Process MAP_DSM (sheet 4) Figure 15.6/3e: Process MAP_DSM (sheet 5) Figure 15.6/3f: Process MAP_DSM (sheet 6) Figure 15.6/3g: Process MAP_DSM (sheet 7) Figure 15.6/3h: Process MAP_DSM (sheet 8) Figure 15.6/3i: Process MAP_DSM (sheet 9) Figure 15.6/3j: Process MAP_DSM (sheet 10) Figure 15.6/3k: Process MAP_DSM (sheet 11) Figure 15.6/3l: Process MAP_DSM (sheet 12) Figure 15.6/3m: Process MAP_DSM (sheet 13) Figure 15.6/3n: Process MAP_DSM (sheet 14) Figure 15.6/30: Process MAP_DSM (sheet 15) Figure 15.6/3p: Process MAP_DSM (sheet 16) Figure 15.6/3q: Process MAP_DSM (sheet 17) Figure 15.6/4a: Procedure Process_Components (sheet 1) Figure 15.6/4b: Procedure Process_Components (sheet 2) Figure 15.6/4c: Procedure Process_Components (sheet 3) Figure 15.6/4d: Procedure Process_Components (sheet 4) Figure 15.6/4e: Procedure Process_Components (sheet 5) Figure 15.6/5: Process Load_Ctrl Figure 15.6/6a: Process Requesting_MAP_SSM (sheet 1) Figure 15.6/6b: Process Requesting_MAP_SSM (sheet 2) Figure 15.6/6c: Process Requesting_MAP_SSM (sheet 3) Figure 15.6/6d: Process Requesting_MAP_SSM (sheet 4) Figure 15.6/8a: Process Performing_MAP_SSM (sheet 1) Figure 15.6/8b: Process Performing_MAP_SSM (sheet 2) 16 Mapping on to TC services 16.1 Dialogue control Dialogue control services are mapped to TC dialogue handling services. The TC-UNI service is not used by the MAP PM. 16.1.1 Directly mapped parameters The following parameters of the MAP-OPEN request and indication primitives are directly mapped on to the corresponding parameters of the TC-BEGIN primitives: - destination address; - originating address. 16.1.2 Use of other parameters of dialogue handling primitives 16.1.2.1 Dialogue Id The value of this parameter is associated with the MAP PM invocation in an implementation dependent manner. 16.1.2.2 Application-context-name The application-context-name parameter of a MAP primitive is mapped to the application-context-name parameter of TC dialogue handling primitives according to the rules described in clauseÊ15.1. 16.1.2.3 User information The user information parameter of TC dialogue primitives is used to carry the MAP dialogue APDUs. 16.1.2.4 Component present This parameter is used by the MAP PM as described in CCITT Recommendation Q.771. It is not visible to the MAP user. 16.1.2.5 Termination The value of this parameter of the TC-END request primitive is set by the MAP PM on the basis of the release method parameter of the MAP-CLOSE request primitive, except when the dialogue state machine is in the state DIALOGUE INITIATED, in which case the Termination parameter shall always indicate ""pre-arranged end"". 16.1.2.6 P-Abort-Cause Values of the P-abort-cause parameter are mapped to the values of the provider-reason parameter of the MAP P ABORT indication primitive according to tableÊ16.1/1, except in the dialogue initiated phase for the ""incorrectTransactionPortion"" and ""noCommonDialoguePortion"" values which are mapped to the ""potential incompatibility problem"" value of the refuse-reason parameter of the MAP-OPEN cnf primitive. The source parameter in the MAP-P-ABORT ind takes the value ""TC problem"". 16.1.2.7 Quality of service The quality of service of TC request primitives is set by the MAP as shown below."
"- Return option: ""Return message on error"" or ""Discard message on error"" as required by the network operator; - Sequence control: ""Sequence guaranteed"" or ""Sequence result not guaranteed"" as required by the network operator; - ""Sequence guaranteed"" shall be used when a segmented result is to be transferred (e.g. subscriber data in response to SendParameters). It may also be appropriate to use Sequence guaranteed when a series of InsertSubscriberData, ProcessAccessSignalling or ForwardAccessSignalling operations is used. It is essential that the TC message which indicates acceptance of a dialogue opening request is received by the dialogue initiator before any subsequent message in that dialogue; otherwise the dialogue opening will fail. The dialogue responder shall ensure that this requirement is met by: - Sending the dialogue acceptance message in a TC END, if the dialogue structure requires it; or - Using ""Sequence guaranteed"", if the dialogue acceptance message is sent in a TC CONTINUE; or - Waiting until the dialogue acceptance message has been acknowledged by the dialogue initiator before sending a subsequent message, if the dialogue acceptance message is sent in a TC CONTINUE. TableÊ16.1/1: Mapping of P-Abort cause in TC-P-ABORT indication on to provider-reason in MAP-P-ABORT indication TC P-Abort cause MAP provider-reason unrecognised message type provider malfunction unrecognised transaction Id supporting dialogue released badlyFormattedTransactionPortion provider malfunction incorrectTransactionPortion provider malfunction (note) resourceLimitation resource limitation abnormalDialogue provider malfunction noCommonDialoguePortion version incompatibility NOTE: Or version incompatibility in the dialogue initiated phase. 16.2 Service specific procedures Specific services are mapped to TC component handling services. 16.2.1 Directly mapped parameters The Invoke Id parameter of the MAP request and indication primitive is directly mapped on to the Invoke Id parameter of the component handling primitives. 16.2.2 Use of other parameters of component handling primitives 16.2.2.1 Dialogue Id The value of this parameter is associated with the MAP PM invocation in an implementation dependent manner. 16.2.2.2 Class The value of this parameter is set by the MAP PM according to the type of the operation to be invoked. 16.2.2.3 Linked Id When a service response is mapped to a class 4 operation, the value of this parameter is set by the MAP PM and corresponds to the value assigned by the user to the initial service request (i.e. the value of the invoke ID parameter of the request primitive). Otherwise if such a parameter is included in MAP request/indication primitives it is directly mapped to the linked ID parameter of the associated TC INVOKE request/indication primitives. 16.2.2.4 Operation When mapping a request primitive on to a Remote Operations PDU (invoke), the MAP PM shall set the operation code according to the mapping described in tableÊ16.2/1. When mapping a response primitive on to a Remote Operations service, the MAP PM shall set the operation code of the TC-RESULT-L/NL primitive (if required) to the same value as the one received at invocation time. TableÊ16.2/1: Mapping of MAP specific services on to MAP operations MAP-SERVICE operation MAP-ACTIVATE-SS activateSS MAP-ACTIVATE-TRACE-MODE activateTraceMode MAP-ALERT-SERVICE-CENTRE alertServiceCentre MAP-ANY-TIME-INTERROGATION anyTimeInterrogaton MAP_AUTHENTICATION_FAILURE_REPORT authenticationFailureReport MAP-ANY-TIME-MODIFICATION anyTimeModification MAP-ANY-TIME-SUBSCRIPTION-INTERROGATION anyTimeSubscriptionInterrogation MAP-CANCEL-LOCATION cancelLocation MAP-CHECK-IMEI checkIMEI MAP-DEACTIVATE-SS deactivateSS MAP-DEACTIVATE-TRACE-MODE deactivateTraceMode MAP-DELETE-SUBSCRIBER-DATA deleteSubscriberData MAP-ERASE-CC-ENTRY eraseCC-Entry MAP-ERASE-SS eraseSS MAP-FAILURE-REPORT failureReport MAP-FORWARD-ACCESS-SIGNALLING forwardAccessSignalling MAP-FORWARD-CHECK-SS-INDICATION forwardCheckSsIndication MAP-FORWARD-GROUP-CALL-SIGNALLING forwardGroupCallSignalling MAP-MT-FORWARD-SHORT-MESSAGE mt-forwardSM MAP-MO-FORWARD-SHORT-MESSAGE mo-forwardSM MAP-GET-PASSWORD getPassword MAP-INFORM-SERVICE-CENTRE informServiceCentre MAP-INSERT-SUBSCRIBER-DATA insertSubscriberData MAP-INTERROGATE-SS interrogateSs MAP-IST-ALERT istAlert MAP-IST-COMMAND istCommand MAP-NOTE-MS-PRESENT-FOR-GPRS noteMsPresentForGprs MAP-NOTE-SUBSCRIBER-DATA-MODIFIED noteSubscriberDataModified MAP-PREPARE-GROUP-CALL prepareGroupCall MAP-PREPARE-HANDOVER prepareHandover MAP-PREPARE-SUBSEQUENT-HANDOVER prepareSubsequentHandover MAP-PROCESS-ACCESS-SIGNALLING processAccessSignalling MAP-PROCESS-GROUP-CALL-SIGNALLING processGroupCallSignalling MAP-PROCESS-UNSTRUCTURED-SS-REQUEST processUnstructuredSS-Request MAP-PROVIDE-ROAMING-NUMBER provideRoamingNumber MAP-PROVIDE-SUBSCRIBER-LOCATION provideSubscriberLocation MAP-PROVIDE-SUBSCRIBER-INFO provideSubscriberInfo MAP-PURGE-MS purgeMS MAP-READY-FOR-SM readyForSM MAP-REGISTER-CC-ENTRY registerCC-Entry MAP-REGISTER-PASSWORD registerPassword MAP-REGISTER-SS registerSS MAP-REMOTE-USER-FREE remoteUserFree MAP-REPORT-SM-DELIVERY-STATUS reportSmDeliveryStatus MAP-RESET reset MAP-RESTORE-DATA restoreData MAP-SEND_GROUP-CALL_END_SIGNAL sendGroupCallEndSignal MAP-SEND-GROUP-CALL-INFO sendGroupCallInfo MAP-SEND-END-SIGNAL sendEndSignal MAP-SEND-AUTHENTICATION-INFO sendAuthenticationInfo MAP-SEND-IMSI sendIMSI MAP-SEND-IDENTIFICATION sendIdentification MAP-SEND-ROUTING-INFO-FOR-SM sendRoutingInfoForSM MAP-SEND-ROUTING-INFO-FOR-GPRS sendRoutingInfoForGprs MAP-SEND-ROUTING-INFO-FOR-LCS sendRoutingInfoForLCS MAP-SEND-ROUTING-INFORMATION sendRoutingInfo MAP-SET-REPORTING-STATE setReportingState MAP-STATUS-REPORT statusReport MAP-SUBSCRIBER-LOCATION-REPORT subscriberLocationReport MAP-SUPPLEMENTARY-SERVICE-INVOCATION-NOTIFICATION ss-Invocation-Notification MAP-UNSTRUCTURED-SS-NOTIFY unstructuredSS-Notify MAP-UNSTRUCTURED-SS-REQUEST unstructuredSS-Request MAP-UPDATE-GPRS-LOCATION updateGprsLocation MAP-UPDATE-LOCATION updateLocation MAP-NOTE-MM-EVENT NoteMM-Event MAP-UPDATE-VCSG-LOCATION updateVcsgLocation MAP-CANCEL-VCSG-LOCATION cancelVcsgLocation 16.2.2.5 Error The error parameter in a TC-U-ERROR indication primitive is mapped to the user error parameter in the MAP confirm primitive of the service associated with the operation to which the error is attached. The user error parameter in MAP response primitives is mapped to the error parameter of the TC U ERROR request primitive, except for ""initiating-release"" and ""resource-limitation"" which are mapped to the problem code parameter of the TC-U-REJECT request primitive. 16.2.2.6 Parameters The parameters of MAP specific request and indication primitives are mapped to the argument parameter of TC-INVOKE primitives. The parameters of MAP specific response and confirm primitives are mapped to the result parameter of TC-RESULT-L primitives, the parameter of TC-U-ERROR primitives or the argument of TC-INVOKE primitives when mapping on linked class 4 operations is used. 16.2.2.7 Time out The value of this parameter is set by the MAP PM according to the type of operation invoked. 16.2.2.8 Last component This parameter is used by the MAP PM as described in CCITT Recommendation Q.711. It is not visible from the MAP user. 16.2.2.9 Problem code 16.2.2.9.1 Mapping to MAP User Error The following values of the user error parameter are mapped as follows to values of the TC problem code parameter. These values are generated by the MAP user. This mapping is valid from the TC-U-REJECT indication primitive to the MAP confirm service primitive and from the MAP response service primitive to the TC-U-REJECT request primitive. TableÊ16.2/2: Mapping of MAP User Error parameter on to TC problem code in TC-U-REJECT primitives MAP User Error TC problem code resource limitation resource limitation initiating release initiating release 16.2.2.9.2 Mapping to MAP Provider Error parameter The following values of the TC problem code parameter of the TC-U-REJECT indication primitive are mapped as follows to values of the MAP Provider Error parameter of the MAP confirm primitive. TableÊ16.2/3: Mapping of TC problem code in TC-U-REJECT on to MAP Provider Error parameter TC problem code MAP Provider Error duplicated invoke Id duplicated invoke id unrecognised operation service not supported mistyped parameter mistyped parameter The following values of the problem code parameters of the TC-L-REJECT primitive are mapped to values of the provider error parameter of the MAP confirm primitive as follows. TableÊ16.2/4: Mapping of TC problem code in TC-L-REJECT on to MAP Provider Error parameter TC problem code MAP Provider Error return result unexpected unexpected response from the peer return error unexpected unexpected response from the peer 16.2.2.9.3 Mapping to diagnostic parameter The following values of the problem code parameter of the TC-R-REJECT and TC-U-REJECT primitive are mapped to values of the diagnostic parameter of the MAP-NOTICE indication primitive as follows: TableÊ16.2/5: Mapping of TC problem code of TC-R-REJECT and TC-U-REJECT on to diagnostic parameter TC problem code MAP diagnostic General problem - abnormal event detected by the peer Invoke problem - unrecognised linked ID - abnormal event detected by the peer - linked response unexpected - response rejected by the peer - unexpected linked operation - response rejected by the peer Return result problem - unrecognised invoke ID - response rejected by the peer - return result unexpected - response rejected by the peer - mistyped parameter - response rejected by the peer Return error problem - unrecognised invoke ID - response rejected by the peer - return error unexpected - response rejected by the peer - unrecognised error - response rejected by the peer - unexpected error - response rejected by the peer - mistyped parameter - response rejected by the peer The following values of the problem code parameter of the TC-L-REJECT primitive are mapped to values of the diagnostic parameter of the MAP-NOTICE indication primitive as follows. TableÊ16.2/6: Mapping of TC problem code of TC-L-REJECT on to diagnostic parameter TC problem code MAP diagnostic General problems - abnormal event received from the peer Invoke problem - unrecognised linked ID - abnormal event received from the peer Return result problem - unrecognised invoke ID - abnormal event received from the peer Return error problem - unrecognised invoke ID - abnormal event received from the peer 17 Abstract syntax of the MAP protocol 17.1 General This clauseÊspecifies the Abstract Syntaxes for the Mobile Application Part as well as the associated set of Operations and Errors, using the Abstract Syntax Notation One (ASN.1), defined in ITU-T Recommendations X.680 and X.681 with additions as defined in clauseÊ17.1.4 on Compatibility Considerations and the OPERATION and ERROR external information object classes, defined in ITU-T Recommendation X.880. The Abstract Syntax is defined for all interfaces specified in clauseÊ4.4 except for the A- and B-interfaces. The Mobile Application Part protocol is defined by two Abstract Syntaxes: - one Abstract Syntax which encompass all Operations and Errors identified by the various MAP subsystem numbers. This Abstract Syntax represents the set of values each of which is a value of the ASN.1 type TCAPMessages. TCMessage as defined in ITU-T Recommendation Q.773 with the component relationconstraint clauses resolved by the operation and error codes included in the ASN.1 modules MAP-*Operations and MAP-Errors. However, only the subset of this abstract syntax which is required by the procedures defined for an entity needs to be supported. - one Abstract Syntax identified by the OBJECT IDENTIFIER value MAP-DialogueInformation.map-DialogueAS. This Abstract Syntax represents the set of values each of which is a value of the ASN.1 type MAP-DialogueInformation.MAP-DialoguePDU. Such a value of the ASN.1 single-ASN.1-type element is contained within the user-information element of the TCAPMessages.DialoguePortion ASN.1 type. This Abstract Syntax name is to be used as a direct reference. 17.1.1 Encoding rules The encoding rules which are applicable to the defined Abstract Syntaxes are the Basic Encoding Rules for Abstract Syntax Notation One, defined in ITU-T Recommendation X.690 with the same exceptions as in ITU-T Recommendation Q.773, clauseÊ4 Message Representation. When the definite form is used for length encoding, a data value of length less than 128 octets must have the length encoded in the short form. When the long form is employed to code a length, the minimum number of octets shall be used to code the length field. OCTET STRING values and BIT STRING values must be encoded in a primitive form. There is no restriction to the use of empty constructors (e.g. an empty SEQUENCE type). That is, the encoding of the content of any data value shall consist of zero, one or more octets. 17.1.2 Use of TC The mapping of OPERATION and ERROR to TC components is defined in ETS 300 287 (version 2) which is based on ITU-T Recommendation Q.773. NOTE 1: The class of an operation is not stated explicitly but is specified as well in the ASN.1 operation definition. Class 1: RESULT and ERROR appear in ASN.1 operation definition. Class 2: only ERROR appears in ASN.1 operation definition. Class 3: only RESULT appears in ASN.1 operation definition. Class 4: both RESULT and ERROR do not appear in ASN.1 operation definition. The field ""ARGUMENT"", ""PARAMETER"" or ""RESULT"" (for information objects of class OPERATION and ERROR) is always optional from a syntactic point of view. However, except when specifically mentioned with the ASN.1 comment ""-- optional"" , the ""parameter"" part of a component has to be considered as mandatory from a semantic point of view. When an optional element is missing in an invoke component or in an inner data structure while it is required by the context, an error component is returned if specified in the information object associated with the operation ; the associated type of error is ""DataMissing"". This holds also when the entire parameter of an invoke component is missing while it is required by the context. NOTE 2: When a mandatory element is missing in the parameter or inner data structure of any component, a reject component is returned (if the dialogue still exists). The problem code to be used is ""Mistyped parameter"". The Timer Values used in the operation definitions are indicated as ASN.1 comments. The Timer Value Ranges are: s = from 3 seconds to 10 seconds; m = from 15 seconds to 30 seconds; ml = from 1 minute to 10 minutes; l = from 28 hours to 38 hours. 17.1.2.1 Use of Global Operation and Error codes defined outside MAP An entity supporting an application context greater than 2 shall be capable of receiving an operation or error code, within an application context defined in GSM 29.002, encoded as either an Object Identifier (as defined in ITU-T Recommendation X.690 ) or an integer value (as defined in clauseÊ17.5). Related restrictions regarding the use of Object Identifiers are as follows: - The length of the Object Identifier shall not exceed 16 octets and the number of components of the Object Identifier shall not exceed 16. - Object Identifiers shall be used only for operations or errors defined outside of GSM 29.002. - Global error codes may be sent only in response to a global operation. If a standard operation is received then a global error code shall not be sent in response. Handling of an unknown operation codes by the receiving entity is defined in clauseÊ15.1.1. 17.1.3 Use of information elements defined outside MAP An information element or a set of information elements (messages) transparently carried in the Mobile Application Part but defined in other recommendations/technical specifications are handled in one of the following ways: i) The contents of each information element (without the octets encoding the identifier and the length in the recommendation/technical specification where it is defined unless explicitly stated otherwise) is carried as the value of an ASN.1 type derived from the OCTET STRING data type. Additionally, the internal structure may be explained by means of comments. In case of misalignment the referred to recommendation/technical specification takes precedence. ii) The complete information element (including the octets encoding the identifier and the length in the recommendation/technical specification where it is defined) or set of information elements and the identity of the associated protocol are carried as the value of the ExternalSignalInfo data type defined in the present document. Where more than one information element is carried, the information elements are sent contiguously with no filler octets between them. 17.1.4 Compatibility considerations The following ASN.1 modules conform to ITU-T Recommendation X.680 and X.681 . An extension marker (""..."") is used wherever future protocol extensions are foreseen. The ""..."" construct applies only to SEQUENCE and ENUMERATED data types. An entity supporting a version greater than 1 shall not reject an unsupported extension following ""..."" of that SEQUENCE or ENUMERATED data type. The Encoding Rules from clauseÊ17.1.1 apply to every element of the whole Transfer Syntax especially to the ASN.1 type EXTERNAL. The extension container ""privateExtensionList"" is defined in this specification in order to carry extensions which are defined outside this specification. Private extensions can be defined by, for example, network operators, manufacturers, and regional standardisation bodies. Private extensions shall: 1) if included in operations of an AC of V2, follow the extension marker and be tagged using PRIVATE tags up to and including 29. NOTE: This type of extension is in most cases used only within a PLMN. 2) if included in operations of an AC of V3 or higher: be included only in the Private Extension Container that is defined in the specification. NOTE: This type of extension can be used between PLMNs. Private extensions shall not be included in v2 supplementary service operations. Private extensions shall not be included within user error for RegisterCCEntry and EraseCCEntry operations. PCS extensions shall be included in the PCS Extension Container that is defined in this specification. In order to improve extensibility, a few error parameters have been defined as a CHOICE between the version 2 description and a SEQUENCE including the version 2 description and an extension container. Operations used in a v2-application-context must consider only the first alternative while operations used in a vn-application-context (n>2) must consider only the second alternative. 17.1.5 Structure of the Abstract Syntax of MAP For each MAP parameter which has to be transferred by a MAP Protocol Data Unit (MAP message), there is a PDU field (an ASN.1 type) which has the same name as the corresponding parameter, except for the differences required by the ASN.1 notation (blanks between words are removed or replaced by hyphen, the first letter of the first word is capital and the first letter of each of the following words ise capitalised, e.g. ""no reply condition time"" is mapped to ""NoReplyConditionTime""). Additionally some words may be abbreviated as follows: bs basic service ch call handling cug closed user group ho handover ic incoming call id identity info information mm mobility management lcs location services ms mobile service oc outgoing call om operation & maintenance pw Password sm short message service ss supplementary service The MAP protocol is composed of several ASN.1 modules dealing with either operations, errors, data types, and, if applicable, split into those dealing with mobile services, call handling services, supplementary services and short message services. For operations and errors the code values are given as parameters, in order to allow use of the defined information objects also by other protocols (e.g. 3GPP TS 24.080 [38]). The ASN.1 source lines are preceded by line-numbers at the left margin in order to enable the usage of the cross-reference in annexÊA. The module containing the definition of the operation packages for MAP is: 1. MAP-OperationPackages. The module containing the definition of the application contexts for MAP is: 2. MAP-ApplicationContexts. The module containing the data types for the Abstract Syntax to be used for TCAPMessages.DialoguePortion for MAP is: 3. MAP-DialogueInformation. The module containing the supported operations is: 4. MAP-Protocol. The modules containing all operation definitions for MAP are: 5. MAP-MobileServiceOperations; 6. MAP-OperationAndMaintenanceOperations; 7. MAP-CallHandlingOperations; 8. MAP-SupplementaryServiceOperations; 9. MAP-ShortMessageServiceOperations; 10. MAP-Group-Call-Operations; 11. MAP-LocationServiceOperations. The module containing all error definitions for MAP is: 12. MAP-Errors. Modules containing all data type definitions for MAP are: 13. MAP-MS-DataTypes; 14. MAP-OM-DataTypes; 15. MAP-CH-DataTypes; 16. MAP-SS-DataTypes; 17. MAP-SS-Code; 18. MAP-SM-DataTypes; 19. MAP-ER-DataTypes; 20. MAP-CommonDataTypes; 21. MAP-TS-Code; 22. MAP-BS-Code; 23. MAP-ExtensionDataTypes; 24. MAP-GR-DataTypes; 25. MAP-LCS-DataTypes. References are made also to modules defined outside of the present document. They are defined in the technical specification Mobile Services Domain, technical specification Transaction Capability and ITU-T Recommendation X.880 respectively: MobileDomainDefinitions; TCAPMessages, DialoguePDUsÊ; Remote-Operations-Information-Objects. 17.1.6 Application Contexts The following informative table lists the latest versions of the Application Contexts used in this specification, with the operations used by them and, where applicable, whether or not the operation description is exactly the same as for previous versions. Information in 17.6 & 17.7 relates only to the ACs in this table. AC Name AC Version Operations Used Comments locationCancellationContext v3 cancelLocation equipmentMngtContext V3 checkIMEI imsiRetrievalContext v2 sendIMSI infoRetrievalContext v3 sendAuthenticationInfo interVlrInfoRetrievalContext v3 sendIdentification handoverControlContext v3 prepareHandover forwardAccessSignalling sendEndSignal processAccessSignalling prepareSubsequentHandover the syntax of this operation has been extended in comparison with release 98 version mwdMngtContext v3 readyForSM msPurgingContext v3 purgeMS shortMsgAlertContext v2 alertServiceCentre resetContext v3 reset networkUnstructuredSsContext v2 processUnstructuredSS-Request unstructuredSS-Request unstructuredSS-Notify tracingContext v3 activateTraceMode deactivateTraceMode networkFunctionalSsContext v2 registerSS eraseSS activateSS deactivateSS registerPassword interrogateSS getPassword shortMsgMO-RelayContext v3 mo-forwardSM shortMsgMT-RelayContext v3 mt-forwardSM shortMsgMT-VGCS-RelayContext v3 mt-forwardSM-VGCS shortMsgGatewayContext v3 sendRoutingInfoForSM reportSM-DeliveryStatus InformServiceCentre the syntax of this operation has been extended in comparison with release 96 version networkLocUpContext v3 updateLocation forwardCheckSs-Indication restoreData insertSubscriberData activateTraceMode the syntax is the same in v1 & v2 gprsLocationUpdateContext v3 updateGprsLocation insertSubscriberData activateTraceMode subscriberDataMngtContext v3 insertSubscriberData deleteSubscriberData roamingNumberEnquiryContext v3 provideRoamingNumber locationInfoRetrievalContext v3 sendRoutingInfo gprsNotifyContext v3 noteMsPresentForGprs gprsLocationInfoRetrievalContext v4 sendRoutingInfoForGprs failureReportContext v3 failureReport callControlTransferContext v4 resumeCallHandling subscriberInfoEnquiryContext v3 provideSubscriberInfo anyTimeEnquiryContext v3 anyTimeInterrogation anyTimeInfoHandlingContext v3 anyTimeSubscriptionInterrogation anyTimeModification ss-InvocationNotificationContext v3 ss-InvocationNotification groupCallControlContext v3 prepareGroupCall processGroupCallSignalling forwardGroupCallSignalling sendGroupCallEndSignal reportingContext v3 setReportingState statusReport remoteUserFree callCompletionContext v3 registerCC-Entry eraseCC-Entry istAlertingContext v3 istAlert ServiceTerminationContext v3 istCommand locationSvcEnquiryContext v3 provideSubscriberLocation subscriberLocationReport locationSvcGatewayContext v3 sendRoutingInfoForLCS mm-EventReportingContext v3 noteMM-Event subscriberDataModificationNotificationContext v3 noteSubscriberDataModified authenticationFailureReportContext v3 authenticationFailureReport resourceManagementContext v3 releaseResources groupCallInfoRetievalContext v3 sendGroupCallInfo vcsgLocationUpdateContext v3 updateVcsgLocation insertSubscriberData vcsgLocationCancelContext v3 cancelVcsgLocation NOTE (*): The syntax of the operations is not the same as in previous versions unless explicitly stated In the word-text of ASN.1 Modules hidden text is used for marking the begin (.$modulename), interrupt (.#), continuation (.$) and end (.#END) of ASN.1 Source. This allows to automatically extract the ASN.1 Sources. These markers should not be deleted! In addition, hidden text is also used to overcome some compiler restrictions In addition no line break should occur when printing a paragraph in ASN.1 source, otherwise the line-numbering of word is inconsistent with the line-numbering in Annex A. For Completeness the module MAP-Frame is included as hidden text. .$MAP-Frame DEFINITIONS ::= BEGIN IMPORTS Component, TCMessage FROM TCAPMessages dialogue-as-id, DialoguePDU FROM DialoguePDUs updateLocation FROM MAP-Protocol map-DialogueAS, MAP-DialoguePDU FROM MAP-DialogueInformation map-ac FROM MAP-ApplicationContexts ; ZZZZ-Dummy ::= NULL .#END 17.2 Operation packages 17.2.1 General aspects This clauseÊdescribes the operation-packages which are used to build the application-contexts defined in clauseÊ17.3. Each operation-package is a specification of the roles of a pair of communicating objects (i.e. a pair of MAP-Providers), in terms of operations which they can invoke of each other. The grouping of operations into one or several packages does not necessarily imply any grouping in terms of Application Service Elements. The following ASN.1 information object class is used to describe operation-packages in this clause: OPERATION-PACKAGE ::= CLASS { &Both OPERATION OPTIONAL, &Consumer OPERATION OPTIONAL, &Supplier OPERATION OPTIONAL, &id OBJECT IDENTIFIER UNIQUE OPTIONAL } WITH SYNTAX { [ OPERATIONS &Both ] [ CONSUMER INVOKES &Supplier ] [ SUPPLIER INVOKES &Consumer ] [ ID &id ] } Since the application-context definitions provided in clauseÊ17.3 use only an informal description technique, only the type notation is used in the following clauses to define operation-packages. The following definitions are used throughout this clause (n>=2): - v1-only operation: An operation which shall be used only in v1 application-contexts; - vn-only operation: An operation which shall be used only in vn application-contexts; - v(n-1)-operation: An operation whose specification has not been modified since the MAP v(n-1) specifications or if the modifications are considered as not affecting v(n-1) implementations; - v(n-1)-equivalent operation: The version of an operation which excludes all the information elements and errors which have been added since the MAP v(n-1) specification; - vn-only package: An operation package which contains only vn-only operations; - v(n-1)-package: An operation package which contains only v(n-1)- operations. The names of vn-packages are suffixed by ""-vn"" where n>=2. For each operation package which is not vn-only (n>=2) and which does not include only v(n-1)-operations, there is a v(n-1)-equivalent package. Except when a definition is explicitly provided in the following clauses, the v(n 1) equivalent package includes the v(n-1)-equivalent operations of the operations which belong to this package. 17.2.2 Packages specifications 17.2.2.1 Location updating This operation package includes the operations required for location management procedures between HLR and VLR. locationUpdatingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { updateLocation} SUPPLIER INVOKES { forwardCheckSs-Indication} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.2 Location cancellation This operation package includes the operations required for location cancellation and MS purging procedures between HLR and VLR and between HLR and SGSN. locationCancellationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR CONSUMER INVOKES { cancelLocation} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.3 Roaming number enquiry This operation package includes the operations required for roaming number enquiry procedures between HLR or old VLR and VLR. roamingNumberEnquiryPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is HLR or old VLR CONSUMER INVOKES { provideRoamingNumber} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.4 Information retrieval This operation package includes the operation required for the authentication information retrieval procedure between HLR and VLR and between HLR and SGSN. infoRetrievalPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { sendAuthenticationInfo} } The v2-equivalent package is defined as follows: infoRetrievalPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { sendAuthenticationInfo} } The v1-equivalent package is defined as follows: infoRetrievalPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR or VLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { sendParameters} } 17.2.2.5 Inter-VLR information retrieval This operation package includes the operations required for inter VLR information retrieval procedures. interVlrInfoRetrievalPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is VLR CONSUMER INVOKES { sendIdentification} } The v2-equivalent package is defined as follows: interVlrInfoRetrievalPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is VLR CONSUMER INVOKES { sendIdentification} } The v1-equivalent package is : infoRetrievalPackage-v1. 17.2.2.6 IMSI retrieval This operation package includes the operation required for the IMSI retrieval procedure between HLR and VLR. imsiRetrievalPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { sendIMSI} } This package is v2 only. 17.2.2.7 Call control transfer This operation package includes the operation required for the call control transfer procedure between VMSC and GMSC. callControlTransferPackage-v4 OPERATION-PACKAGE ::= { -- Supplier is GMSC if Consumer is VMSC CONSUMER INVOKES { resumeCallHandling} } The v3-equivalent package can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.8 Void 17.2.2.9 Void 17.2.2.10 Interrogation This operation package includes the operations required for interrogation procedures between MSC and HLR or NPLR or between HLR and gsmSCF. interrogationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR or NPLR if Consumer is MSC -- Supplier is HLR if Consumer is gsmSCF CONSUMER INVOKES { sendRoutingInfo} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.11 Void 17.2.2.12 Handover Control This operation package includes the operations required for handover procedures between MSCs. handoverControlPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is MSCB if Consumer is MSCA CONSUMER INVOKES { prepareHandover | forwardAccessSignalling} SUPPLIER INVOKES { sendEndSignal | processAccessSignalling | prepareSubsequentHandover} } The v2-equivalent package can be determined according to the rules described in clauseÊ17.2.1. The v1-equivalent package is defined as follows. handoverControlPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is MSCB if Consumer is MSCA CONSUMER INVOKES { performHandover | forwardAccessSignalling | traceSubscriberActivity} SUPPLIER INVOKES { sendEndSignal | noteInternalHandover | processAccessSignalling | performSubsequentHandover} } 17.2.2.13 Subscriber Data management stand alone This operation package includes the operations required for stand alone subscriber data management procedures between HLR and VLR or between HLR and SGSN. Also this operation package includes the operations required for stand alone subscriber data management procedures between CSS and VLR or between CSS and SGSN. For the CSS Ð VLR interface and CSS Ð SGSN interface only version 3 of this operation package is applicable. subscriberDataMngtStandAlonePackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR or CSS CONSUMER INVOKES { insertSubscriberData | deleteSubscriberData} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.14 Equipment management This operation package includes the operations required for equipment management procedures between EIR and MSC or between EIR and SGSN. equipmentMngtPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is EIR if Consumer is MSC -- Supplier is EIR if Consumer is SGSN CONSUMER INVOKES { checkIMEI} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.15 Subscriber data management This operation package includes the operations required for subscriber data management procedures between HLR and VLR or between HLR and SGSN. Also this operation package includes the operations required for subscriber data management procedures between CSS and VLR or between CSS and SGSN. For the CSS Ð VLR interface and CSS Ð SGSN interface only version 3 of this operation package is applicable. subscriberDataMngtPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR or CSS CONSUMER INVOKES { insertSubscriberData} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.16 Location register restart This operation package includes the operations required for location register restart procedures between HLR and VLR or between HLR and SGSN and also between CSS and VLR or between CSS and SGSN. resetPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR or CSS CONSUMER INVOKES { reset} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. For CSS-VLR interface and CSS-SGSN interface, only version 3 of this operation package is applicable. 17.2.2.17 Tracing stand-alone This operation package includes the operations required for stand alone tracing procedures between HLR and VLR or between HLR and SGSN. tracingStandAlonePackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR CONSUMER INVOKES { activateTraceMode | deactivateTraceMode} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.18 Functional SS handling This operation package includes the operations required for functional supplementary services procedures between VLR and HLR. functionalSsPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { registerSS | eraseSS | activateSS | deactivateSS | registerPassword | interrogateSS} SUPPLIER INVOKES { getPassword} } The v1-equivalent package can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.19 Tracing This operation package includes the operations required for tracing procedures between HLR and VLR or between HLR and SGSN. tracingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR CONSUMER INVOKES { activateTraceMode} } The v1-equivalent and v2-equivalent packages can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.20 Binding This operation package includes the operation required to initialise a supplementary service procedure between VLR and HLR or between gsmSCF and HLR. bindingPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is gsmSCF if Consumer is HLR CONSUMER INVOKES { beginSubscriberActivity} } This package is v1 only. 17.2.2.21 Unstructured SS handling This operation package includes the operations required for unstructured supplementary services procedures between VLR and HLR, between the HLR and the gsmSCF, and between HLR and HLR. unstructuredSsPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is gsmSCF or HLR if Consumer is HLR CONSUMER INVOKES { processUnstructuredSS-Request} SUPPLIER INVOKES { unstructuredSS-Request | unstructuredSS-Notify} } The v1-equivalent package is defined as follows: unstructuredSsPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is gsmSCF if Consumer is HLR CONSUMER INVOKES { processUnstructuredSS-Data} } 17.2.2.22 MO Short message relay services This operation package includes the operations required for short message relay service procedures between IWMSC and VMSC or between GMSC and MSC or between SGSN and IWMSC. mo-ShortMsgRelayPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is IWMSC if Consumer is MSC -- Supplier is IWMSC if Consumer is SGSN CONSUMER INVOKES { mo-forwardSM} } The v2-equivalent package is defined as follows: shortMsgRelayPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is IWMSC if Consumer is MSC -- Supplier is MSC or SGSN if Consumer is GMSC -- Supplier is IWMSC if Consumer is SGSN CONSUMER INVOKES { forwardSM} } The v1-equivalent package can be determined according to the rules described in clauseÊ17.2.1. 17.2.2.23 Short message gateway services This operation package includes the operations required for short message service gateway procedures between MSC and HLR. shortMsgGatewayPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GMSC CONSUMER INVOKES { sendRoutingInfoForSM | reportSM-DeliveryStatus} SUPPLIER INVOKES { informServiceCentre} } The v2-equivalent package can be determined according to the rules described in clause 17.2.1. The v1-equivalent package is defined as follows: shortMsgGatewayPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GMSC CONSUMER INVOKES { sendRoutingInfoForSM | reportSMDeliveryStatus} } 17.2.2.24 MT Short message relay services This operation package includes the operations required for short message relay service procedures between GMSC and MSC or between GMSC and SGSN. mt-ShortMsgRelayPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is MSC or SGSN or SMS-Router or IP-SM-GW if Consumer is GMSC CONSUMER INVOKES { mt-forwardSM} } The v2-equivalent package is: shortMsgRelayPackage-v2 17.2.2.25 Void 17.2.2.26 Message waiting data management This operation package includes the operations required for short message waiting data procedures between HLR and VLR, between HLR and SGSN. mwdMngtPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is SGSN -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { readyForSM} } The v2-equivalent package can be determined according to the rules described in clause 17.2.1. The v1-equivalent package is defined as follows: mwdMngtPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { noteSubscriberPresent} } 17.2.2.27 Alerting This operation package includes the operations required for alerting between HLR and IWMSC. alertingPackage-v2 OPERATION-PACKAGE ::= { -- Supplier is IWMSC if Consumer is HLR CONSUMER INVOKES { alertServiceCentre} } The v1-equivalent package is defined as follows. alertingPackage-v1 OPERATION-PACKAGE ::= { -- Supplier is IWMSC if Consumer is HLR CONSUMER INVOKES { alertServiceCentreWithoutResult} } 17.2.2.28 Data restoration This operation package includes the operations required for VLR data restoration between HLR and VLR. dataRestorationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { restoreData} } The v2-equivalent package can be determined according to the rules described in clause 17.2.1. The v1-equivalent package is: infoRetrievalPackage-v1 17.2.2.29 Purging This operation package includes the operations required for purging between HLR and VLR or between HLR and SGSN. purgingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { purgeMS} } The v2-equivalent package can be determined according to the rules described in clause 17.2.1. 17.2.2.30 Subscriber information enquiry This operation package includes the operations required for subscriber information enquiry procedures between HLR and VLR or between HLR and SGSN. subscriberInformationEnquiryPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is HLR CONSUMER INVOKES { provideSubscriberInfo} } This package is v3 only. 17.2.2.31 Any time information enquiry This operation package includes the operations required for any time information enquiry procedures between gsmSCF and HLR or between gsmSCF and GMLC or between gsmSCF and NPLR. anyTimeInformationEnquiryPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR or GMLC or NPLR if Consumer is gsmSCF CONSUMER INVOKES { anyTimeInterrogation} } This package is v3 only. 17.2.2.32 Group Call Control This operation package includes the operations required for group call and broadcast call procedures between MSCs. groupCallControlPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is relay MSC if Consumer is anchor MSC CONSUMER INVOKES { prepareGroupCall | forwardGroupCallSignalling} SUPPLIER INVOKES { sendGroupCallEndSignal | processGroupCallSignalling} } This package is v3 only. 17.2.2.32A Group Call Info Retrieval This operation package includes the operations required for group call and broadcast call info retrieval between MSCs. groupCallInfoRetrievalPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is group call serving MSC if Consumer is visited MSC -- Supplier is visited MSC if Consumer is group call serving MSC CONSUMER INVOKES { sendGroupCallInfo} } This package is v3 only. 17.2.2.33 Void 17.2.2.34 Void 17.2.2.35 Gprs location updating This operation package includes the operations required for the gprs location management procedures between HLR and SGSN. gprsLocationUpdatingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { updateGprsLocation} } This package is v3 only. 17.2.2.36 Gprs Interrogation This operation package includes the operations required for interrogation procedures between HLR and GGSN. gprsInterrogationPackage-v4 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GGSN CONSUMER INVOKES { sendRoutingInfoForGprs} } The v3-equivalent package is defined as follows. gprsInterrogationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GGSN CONSUMER INVOKES { sendRoutingInfoForGprs} } 17.2.2.37 Failure reporting This operation package includes the operations required for failure reporting between HLR and GGSN. failureReportingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GGSN CONSUMER INVOKES { failureReport} } This package is v3 only. 17.2.2.38 GPRS notifying This operation package includes the operations required for notifying that GPRS subscriber is present between HLR and GGSN. gprsNotifyingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is GGSN if Consumer is HLR CONSUMER INVOKES { noteMsPresentForGprs} } This package is v3 only. 17.2.2.39 Supplementary Service invocation notification This operation package includes the operations required for Supplementary Service invocation notification procedures between the MSC and the gsmSCF and between the HLR and the gsmSCF. ss-InvocationNotificationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is gsmSCF if Consumer is MSC -- Supplier is gsmSCF if Consumer is HLR CONSUMER INVOKES { ss-InvocationNotification} } This package is v3 only. 17.2.2.40 Set Reporting State This operation package includes the operation required for procedures between HLR and VLR to set the reporting state. setReportingStatePackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is HLR CONSUMER INVOKES { setReportingState} } This package is v3 only. 17.2.2.41 Status Report This operation package includes the operation required for procedures between VLR and HLR to report call results and events. statusReportPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { statusReport} } This package is v3 only. 17.2.2.42 Remote User Free This operation package includes the operation required by the HLR to indicate to the VLR that the remote user is free. remoteUserFreePackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR if Consumer is HLR CONSUMER INVOKES { remoteUserFree} } This package is v3 only. 17.2.2.43 Call Completion This operation package includes the operations required for procedures between VLR and HLR for subscriber control of call completion services."
"callCompletionPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR CONSUMER INVOKES { registerCC-Entry | eraseCC-Entry} } This package is v3 only. 17.2.2.44 Location service gateway services This operation package includes the operations required for location service gateway procedures between GMLC and HLR. locationSvcGatewayPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is GMLC CONSUMER INVOKES { sendRoutingInfoForLCS} } This package is v3 only. 17.2.2.45 Location service enquiry This operation package includes the operations required for the location service enquiry procedures between GMLC and MSC and between GMLC and SGSN. locationSvcEnquiryPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is MSC or SGSN if Consumer is GMLC CONSUMER INVOKES { provideSubscriberLocation} } This package is v3 only. 17.2.2.45A Location service reporting This operation package includes the operations required for the location service enquiry procedures between MSC and GMLC and between SGSN and GMLC. locationSvcReportingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is GMLC if Consumer is MSC -- Supplier is GMLC if Consumer is SGSN CONSUMER INVOKES { subscriberLocationReport} } 17.2.2.46 Void 17.2.2.47 Void 17.2.2.48 Void 17.2.2.49 IST Alerting This operation package includes the operation required for alerting procedures between the MSC (Visited MSC or Gateway MSC) and HLR. ist-AlertingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VMSC -- Supplier is HLR if Consumer is GMSC CONSUMER INVOKES { istAlert} } This package is v3 only. 17.2.2.50 Service Termination This operation package includes the operation required for immediate service termination procedures between the HLR and the Visited MSC or between the HLR and the Gateway MSC. serviceTerminationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VMSC or GMSC if Consumer is HLR CONSUMER INVOKES { istCommand} } This package is v3 only. 17.2.2.51 Mobility Management event notification This operation package includes the operations required for Mobility Management event notification procedures between VLR and gsmSCF. mm-EventReportingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is gsmSCF if Consumer is VLR CONSUMER INVOKES { noteMM-Event} } This package is v3 only. 17.2.2.52 Any time information handling This operation package includes the operations required for any time information handling procedures between gsmSCF and HLR. anyTimeInformationHandlingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is gsmSCF CONSUMER INVOKES { anyTimeSubscriptionInterrogation | anyTimeModification} } This package is v3 only. 17.2.2.53 Subscriber Data modification notification This operation package includes the operations required for Subscriber Data modification notification procedures between HLR and gsmSCF. subscriberDataModificationNotificationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is gsmSCF if Consumer is HLR CONSUMER INVOKES { noteSubscriberDataModified} } This package is v3 only. 17.2.2.54 Authentication Failure Report This operation package includes the operation required for procedures between VLR and HLR or the SGSN and the HLR for reporting of authentication failures. authenticationFailureReportPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is HLR if Consumer is VLR -- Supplier is HLR if Consumer is SGSN CONSUMER INVOKES { authenticationFailureReport} } This package is v3 only. 17.2.2.55 Resource Management This operation package includes the operation required for procedures between GMSC and VMSC for resource management purpose. resourceManagementPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VMSC if Consumer is GMSC CONSUMER INVOKES { releaseResources} } This package is v3 only. 17.2.2.56 MT Short message relay VGCS services This operation package includes the operations required for short message relay service procedures between SMS GMSC and MSC. mt-ShortMsgRelay-VGCS-Package-v3 OPERATION-PACKAGE ::= { -- Supplier is MSC if Consumer is GMSC CONSUMER INVOKES { mt-forwardSM-VGCS} } This package is v3 only. 17.2.2.57 Vcsg location updating This operation package includes the operations required for the vcsg location management procedures between CSS and VLR or between CSS and SGSN. vcsgLocationUpdatingPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is CSS if Consumer is VLR or SGSN CONSUMER INVOKES { updateVcsgLocation} } This operation package is v3 only. 17.2.2.58 Vcsg location cancellation This operation package includes the operations required for the vcsg location cancellation procedures between CSS and VLR or between CSS and SGSN. vcsgLocationCancellationPackage-v3 OPERATION-PACKAGE ::= { -- Supplier is VLR or SGSN if Consumer is CSS CONSUMER INVOKES { cancelVcsgLocation} } This operation package is v3 only. 17.3 Application contexts 17.3.1 General aspects An application-context is assigned for each dialogue established by a MAP-user. In the present document each application-context is assigned a name which is supplied in the MAP-OPEN Req primitive by the MAP-User and transmitted to the peer under certain circumstances. The following ASN.1 information object class is used to describe the main aspects of application-contexts in the following clauses: APPLICATION-CONTEXT ::= CLASS { &Symmetric OPERATION-PACKAGE OPTIONAL, &InitiatorConsumerOf OPERATION-PACKAGE OPTIONAL, &ResponderConsumerOf OPERATION-PACKAGE OPTIONAL, &code OBJECT IDENTIFIER } WITH SYNTAX { [ OPERATIONS OF &Symmetric ] [ INITIATOR CONSUMER OF &InitiatorConsumerOf RESPONDER CONSUMER OF &ResponderConsumerOf ] ID &code } The following definitions are used throughout this clause: - v1-application-context: An application-context which contains only v1-packages and uses only TC v1 facilities; - v1 context set: the set of v1-application-contexts defined in the present document. - vn-application-context (n>=2): An application-context which contains only vn-packages; The names of v1-application-contexts are suffixed by ""-v1"" while other names are suffixed by ""-vn"" where n>=2. Application-contexts which do not belong to the v1 context set use v2 TC facilities. The last component of each application-context-name (i.e. the last component of the object identifier value) assigned to an application-context which belongs to the v1 context set indicates explicitly ""version1"". For each application-context which does not belong to the ""v1 context set"" there is a v1-equivalent application context. This is a v1-application-context which includes the v1-equivalents of the packages included in the original context. Each application-context uses the abstract-syntax associated with the operation-packages it includes and uses the transfer-syntax derived from it by applying the encoding rules defined in clauseÊ17.1.1. ACs which do not belong to the v1 context set require the support of the abstract-syntax identified by the object identifier value: MAP-DialogueInformation.map-Dialogue-AS defined in clauseÊ17.4. 17.3.2 Application context definitions 17.3.2.1 Void 17.3.2.2 Location Updating This application context is used between HLR and VLR for location updating procedures. networkLocUpContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { locationUpdatingPackage-v3 | dataRestorationPackage-v3} RESPONDER CONSUMER OF { subscriberDataMngtPackage-v3 | tracingPackage-v3} ID {map-ac networkLocUp(1) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac networkLocUp(1) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac networkLocUp(1) version1(1)} 17.3.2.3 Location Cancellation This application context is used between HLR and VLR or between HLR and SGSN for location cancellation procedures. For the HLR - SGSN interface only version 3 of this application context is applicable. locationCancellationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR INITIATOR CONSUMER OF { locationCancellationPackage-v3} ID {map-ac locationCancel(2) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID map-ac locationCancel(2) version2(2) The following application-context-name is assigned to the v1-equivalent application-context: ID map-ac locationCancel(2) version1(1) 17.3.2.4 Roaming number enquiry This application context is used between HLR and VLR for roaming number enquiry procedures. roamingNumberEnquiryContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR if Initiator is HLR INITIATOR CONSUMER OF { roamingNumberEnquiryPackage-v3} ID {map-ac roamingNbEnquiry(3) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac roamingNbEnquiry(3) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac roamingNbEnquiry(3) version1(1)} 17.3.2.5 Void 17.3.2.6 Location Information Retrieval This application-context is used between GMSC and HLR or between GMSC and NPLR or between gsmSCF and HLR when retrieving location information. For the GMSC - NPLR interface version 1, version 2 and version 3 of this application context are applicable. locationInfoRetrievalContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR or NPLR if Initiator is GMSC -- Responder is HLR if Initiator is gsmSCF INITIATOR CONSUMER OF { interrogationPackage-v3} ID {map-ac locInfoRetrieval(5) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac locInfoRetrieval(5) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac locInfoRetrieval(5) version1(1)} 17.3.2.7 Call control transfer This application context is used for the call control transfer procedure between the VMSC and the GMSC. callControlTransferContext-v4 APPLICATION-CONTEXT ::= { -- Responder is GMSC if Initiator is VMSC INITIATOR CONSUMER OF { callControlTransferPackage-v4} ID {map-ac callControlTransfer(6) version4(4)} } The following application-context-name is assigned to the v3-equivalent application-context: ID {map-ac callControlTransfer(6) version3(3)} 17.3.2.8 Void 17.3.2.9 Void 17.3.2.10 Void 17.3.2.11 Location registers restart This application context is used between HLR and VLR or between HLR and SGSN for location register restart procedures or between CSS and VLR or between CSS and SGSN for CSG Subscriber Server restart procedures. For the HLR - VLR interface and for the HLR - SGSN interface version 1, version 2 and version 3 of this application context are applicable For the CSS - VLR interface and the CSS - SGSN interface version 3 of this application context is applicable. resetContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR or CSS INITIATOR CONSUMER OF { resetPackage-v3} ID {map-ac reset(10) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac reset(10) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac reset(10) version1(1)} 17.3.2.12 Handover control This application context is used for handover procedures between MSCs. handoverControlContext-v3 APPLICATION-CONTEXT ::= { -- Responder is MSCB if Initiator is MSCA INITIATOR CONSUMER OF { handoverControlPackage-v3} ID {map-ac handoverControl(11) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac handoverControl(11) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac handoverControl(11) version1(1)} 17.3.2.13 IMSI Retrieval This application context is used for IMSI retrieval between HLR and VLR. imsiRetrievalContext-v2 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { imsi-RetrievalPackage-v2} ID {map-ac imsiRetrieval(26) version2(2)} } This application-context is v2 only. 17.3.2.14 Equipment Management This application context is used for equipment checking between MSC and EIR or between SGSN and EIR. For the SGSN - EIR interface version 1 and version 2 and version 3 of this application context are applicable: equipmentMngtContext-v3 APPLICATION-CONTEXT ::= { -- Responder is EIR if Initiator is MSC -- Responder is EIR if Initiator is SGSN INITIATOR CONSUMER OF { equipmentMngtPackage-v3} ID {map-ac equipmentMngt(13) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: equipmentMngtContext-v2 APPLICATION-CONTEXT ::= { -- Responder is EIR if Initiator is MSC -- Responder is EIR if Initiator is SGSN INITIATOR CONSUMER OF { equipmentMngtPackage-v2} ID {map-ac equipmentMngt(13) version2(2)} } The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac equipmentMngt(13) version1(1)} 17.3.2.15 Information retrieval This application context is used for authentication information retrieval between HLR and VLR or between HLR and SGSN. For the HLR - SGSN interface version 1 and version 2 and version 3 of this application context are applicable. infoRetrievalContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { infoRetrievalPackage-v3} ID {map-ac infoRetrieval(14) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: infoRetrievalContext-v2 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { infoRetrievalPackage-v2} ID {map-ac infoRetrieval(14) version2(2)} } The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac infoRetrieval(14) version1(1)} 17.3.2.16 Inter-VLR information retrieval This application context is used for information retrieval between VLRs. interVlrInfoRetrievalContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR if Initiator is VLR INITIATOR CONSUMER OF { interVlrInfoRetrievalPackage-v3} ID {map-ac interVlrInfoRetrieval(15) version3(3)} } The v2-equivalent application-context is: interVlrInfoRetrievalContext-v2 APPLICATION-CONTEXT ::= { -- Responder is VLR if Initiator is VLR INITIATOR CONSUMER OF { interVlrInfoRetrievalPackage-v2} ID {map-ac interVlrInfoRetrieval(15) version2(2)} } The v1-equivalent application-context is: ID {map-ac infoRetrieval(14) version1(1)} 17.3.2.17 Stand Alone Subscriber Data Management This application context is used for stand alone subscriber data management between HLR and VLR or between HLR and SGSN. For the HLR - SGSN interface only version 3 of this application context is applicable. Also this application context is used for stand alone subscriber data management between CSS and VLR or between CSS and SGSN. For the CSS Ð VLR interface and CSS Ð SGSN interface only version 3 of this application context is applicable: subscriberDataMngtContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR or CSS INITIATOR CONSUMER OF { subscriberDataMngtStandAlonePackage-v3} ID {map-ac subscriberDataMngt(16) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac subscriberDataMngt(16) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac subscriberDataMngt(16) version1(1)} 17.3.2.18 Tracing This application context is used between HLR and VLR or between HLR and SGSN for stand alone tracing control procedures. For the HLR - SGSN interface version 1, version 2 and version 3 of this application context are applicable. tracingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR INITIATOR CONSUMER OF { tracingStandAlonePackage-v3} ID {map-ac tracing(17) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac tracing(17) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac tracing(17) version1(1)} 17.3.2.19 Network functional SS handling This application context is used for functional-like SS handling procedures between VLR and HLR. networkFunctionalSsContext-v2 APPLICATION-CONTEXT ::= { -- Responder is HLR, Initiator is VLR INITIATOR CONSUMER OF { functionalSsPackage-v2} ID {map-ac networkFunctionalSs(18) version2(2)} } The v1-equivalent application-context is defined as follows: networkFunctionalSsContext-v1 APPLICATION-CONTEXT ::= { -- Responder is HLR, Initiator is VLR INITIATOR CONSUMER OF { functionalSsPackage-v1 | unstructuredSsPackage-v1 | bindingPackage-v1} ID {map-ac networkFunctionalSs(18) version1(1)} } 17.3.2.20 Network unstructured SS handling This application context is used for handling stimuli-like procedures between HLR and VLR, between the HLR and gsmSCF, and between HLR and HLR. networkUnstructuredSsContext-v2 APPLICATION-CONTEXT ::= { -- Responder is HLR, Initiator is VLR -- Responder is VLR, Initiator is HLR -- Responder is gsmSCF, Initiator is HLR -- Responder is HLR, Initiator is gsmSCF -- Responder is HLR, Initiator is HLR OPERATIONS OF { unstructuredSsPackage-v2} ID {map-ac networkUnstructuredSs(19) version2(2)} } The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac networkFunctionalSs(18) version1(1)} 17.3.2.21 Short Message Gateway This application context is used for short message gateway procedures. shortMsgGatewayContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GMSC INITIATOR CONSUMER OF { shortMsgGatewayPackage-v3} ID {map-ac shortMsgGateway(20) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac shortMsgGateway(20) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac shortMsgGateway(20) version1(1)} 17.3.2.22 Mobile originating Short Message Relay This application context is used between MSC and IWMSC or between SGSN and IWMSC for mobile originating short message relay procedures. For the SGSN - IWMSC interface version 1, version 2 and version 3 of this application context are applicable. shortMsgMO-RelayContext-v3 APPLICATION-CONTEXT ::= { -- Responder is IWMSC if Initiator is MSC -- Responder is IWMSC if Initiator is SGSN INITIATOR CONSUMER OF { mo-ShortMsgRelayPackage-v3} ID {map-ac shortMsgMO-Relay(21) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac shortMsgMO-Relay(21) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac shortMsg-Relay(21) version1(1)} 17.3.2.23 Void 17.3.2.24 Short message alert This application context is used for short message alerting procedures. shortMsgAlertContext-v2 APPLICATION-CONTEXT ::= { -- Responder is IWMSC if Initiator is HLR INITIATOR CONSUMER OF { alertingPackage-v2} ID {map-ac shortMsgAlert(23) version2(2)} } The following application-context-name is symbolically assigned to the v1-equivalent application-context: ID {map-ac shortMsgAlert(23) version1(1)} 17.3.2.25 Short message waiting data management This application context is used between VLR and HLR or between SGSN and HLR for short message waiting data management procedures. For the SGSN - HLR interface only version 3 of this application context is applicable. mwdMngtContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is SGSN -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { mwdMngtPackage-v3} ID {map-ac mwdMngt(24) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac mwdMngt(24) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac mwdMngt(24) version1(1)} 17.3.2.26 Mobile terminating Short Message Relay This application context is used between GMSC and MSC or between GMSC and SGSN for mobile terminating short message relay procedures. For the GMSC - SGSN interface version 2 and version 3 of this application context and the equivalent version 1 application context are applicable. shortMsgMT-RelayContext-v3 APPLICATION-CONTEXT ::= { -- Responder is MSC or SGSN if Initiator is GMSC INITIATOR CONSUMER OF { mt-ShortMsgRelayPackage-v3} ID {map-ac shortMsgMT-Relay(25) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac shortMsgMT-Relay(25) version2(2)} The following application-context-name is assigned to the v1-equivalent application-context: ID {map-ac shortMsg-Relay(21) version1(1)} 17.3.2.27 MS purging This application context is used between HLR and VLR or between HLR and SGSN for MS purging procedures. For the SGSN - HLR interface only version 3 of this application context is applicable. msPurgingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { purgingPackage-v3} ID {map-ac msPurging(27) version3(3)} } The following application-context-name is assigned to the v2-equivalent application-context: ID {map-ac msPurging(27) version2(2)} 17.3.2.28 Subscriber information enquiry This application context is used between HLR and VLR or between HLR and SGSN for subscriber information enquiry procedures. subscriberInfoEnquiryContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is HLR INITIATOR CONSUMER OF { subscriberInformationEnquiryPackage-v3} ID {map-ac subscriberInfoEnquiry(28) version3(3)} } This application-context is v3 only. 17.3.2.29 Any time information enquiry This application context is used between gsmSCF and HLR or between gsmSCF and GMLC or between gsmSCF and NPLR for any time information enquiry procedures. anyTimeInfoEnquiryContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR or GMLC or NPLR if Initiator is gsmSCF INITIATOR CONSUMER OF { anyTimeInformationEnquiryPackage-v3} ID {map-ac anyTimeInfoEnquiry(29) version3(3)} } This application-context is v3 only. 17.3.2.30 Group Call Control This application context is used between anchor MSC and relay MSC for group call and broadcast call procedures. groupCallControlContext-v3 APPLICATION-CONTEXT ::= { -- Responder is relay MSC if Initiator is anchor MSC INITIATOR CONSUMER OF { groupCallControlPackage-v3} ID {map-ac groupCallControl(31) version3(3)} } This application-context is v3 only. 17.3.2.30A Group Call Info Retrieval This application context is used between group call serving MSC and visited MSC for group call and broadcast call procedures. groupCallInfoRetControlContext-v3 APPLICATION-CONTEXT ::= { -- Responder is group call serving MSC if Initiator is visited MSC -- Responder is visited MSC if Initiator is group call serving MSC INITIATOR CONSUMER OF { groupCallInfoRetrievalPackage-v3} ID {map-ac groupCallInfoRetrieval(45) version3(3)} } This application-context is v3 only. 17.3.2.31 Void 17.3.2.32 Gprs Location Updating This application context is used between HLR and SGSN for gprs location updating procedures. gprsLocationUpdateContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { gprsLocationUpdatingPackage-v3} RESPONDER CONSUMER OF { subscriberDataMngtPackage-v3 | tracingPackage-v3} ID {map-ac gprsLocationUpdate(32) version3(3)} } This application-context is v3 only. 17.3.2.33 Gprs Location Information Retreival This application context is used between HLR and GGSN when retrieving gprs location information. gprsLocationInfoRetrievalContext-v4 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GGSN INITIATOR CONSUMER OF { gprsInterrogationPackage-v4} ID {map-ac gprsLocationInfoRetrieval(33) version4(4)} } The following application-context-name is assigned to the v3-equivalent application-context: ID {map-ac gprsLocationInfoRetrieval(33) version3(3)} 17.3.2.34 Failure Reporting This application context is used between HLR and GGSN to inform that network requested PDP-context activation has failed. failureReportContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GGSN INITIATOR CONSUMER OF { failureReportingPackage-v3} ID {map-ac failureReport(34) version3(3)} } This application-context is v3 only. 17.3.2.35 GPRS Notifying This application context is used between HLR and GGSN for notifying that GPRS subscriber is present again. gprsNotifyContext-v3 APPLICATION-CONTEXT ::= { -- Responder is GGSN if Initiator is HLR INITIATOR CONSUMER OF { gprsNotifyingPackage-v3} ID {map-ac gprsNotify(35) version3(3)} } This application-context is v3 only. 17.3.2.36 Supplementary Service invocation notification This application context is used between the MSC and the gsmSCF and between the HLR and the gsmSCF for Supplementary Service invocation notification procedures. ss-InvocationNotificationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is gsmSCF, Initiator is MSC -- Responder is gsmSCF, Initiator is HLR INITIATOR CONSUMER OF { ss-InvocationNotificationPackage-v3} ID {map-ac ss-InvocationNotification(36) version3(3)} } This application-context is v3 only. 17.3.2.37 Reporting This application context is used between HLR and VLR for reporting procedures. reportingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR if Initiator is HLR -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { setReportingStatePackage-v3 | statusReportPackage-v3 | remoteUserFreePackage-v3} RESPONDER CONSUMER OF { setReportingStatePackage-v3 | statusReportPackage-v3} ID {map-ac reporting(7) version3(3)} } This application-context is v3 only. 17.3.2.38 Call Completion This application context is used between VLR and the HLR for subscriber control of call completion services. callCompletionContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR INITIATOR CONSUMER OF { callCompletionPackage-v3} ID {map-ac callCompletion(8) version3(3)} } This application-context is v3 only. 17.3.2.39 Location Service Gateway This application context is used for location service gateway procedures. locationSvcGatewayContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is GMLC INITIATOR CONSUMER OF { locationSvcGatewayPackage-v3} ID {map-ac locationSvcGateway(37) version3(3)} } 17.3.2.40 Location Service Enquiry This application context is used for location service enquiry procedures. locationSvcEnquiryContext-v3 APPLICATION-CONTEXT ::= { -- Responder is MSC or SGSN if Initiator is GMLC -- Responder is GMLC if Initiator is MSC -- Responder is GMLC if Initiator is SGSN INITIATOR CONSUMER OF { locationSvcEnquiryPackage-v3 | locationSvcReportingPackage-v3} ID {map-ac locationSvcEnquiry(38) version3 (3)} } 17.3.2.41 Void 17.3.2.42 Void 17.3.2.43 Void 17.3.2.44 IST Alerting This application context is used between MSC (Visited MSC or Gateway MSC) and HLR for alerting services within IST procedures. istAlertingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VMSC -- Responder is HLR if Initiator is GMSC INITIATOR CONSUMER OF { ist-AlertingPackage-v3} ID {map-ac alerting(4) version3(3)} } This application-context is v3 only. 17.3.2.45 Service Termination This application context is used between HLR and MSC (Visited MSC or Gateway MSC) for service termination services within IST procedures. serviceTerminationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VMSC or GMSC if Initiator is HLR INITIATOR CONSUMER OF { serviceTerminationPackage-v3} ID {map-ac serviceTermination(9) version3(3)} } This application-context is v3 only. 17.3.2.46 Mobility Management event notification This application context is used between VLR and gsmSCF for Mobility Management event notification procedures. mm-EventReportingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is gsmSCF, Initiator is VLR INITIATOR CONSUMER OF { mm-EventReportingPackage-v3} ID {map-ac mm-EventReporting(42) version3(3)} } This application-context is v3 only. 17.3.2.47 Any time information handling This application context is used between gsmSCF and HLR for any time information handling procedures. anyTimeInfohandlingContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is gsmSCF INITIATOR CONSUMER OF { anyTimeInformationHandlingPackage-v3} ID {map-ac anyTimeInfoHandling(43) version3(3)} } This application-context is v3 only. 17.3.2.48 Subscriber Data modification notification This application context is used between HLR and gsmSCF for Subscriber Data modification notification procedures. subscriberDataModificationNotificationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is gsmSCF, Initiator is HLR INITIATOR CONSUMER OF { subscriberDataModificationNotificationPackage-v3} ID {map-ac subscriberDataModificationNotification(22) version3(3)} } This application-context is v3 only. 17.3.2.49 Authentication Failure Report This application context is used between VLR and HLR or SGSN and HLR for reporting of authentication failures. authenticationFailureReportContext-v3 APPLICATION-CONTEXT ::= { -- Responder is HLR if Initiator is VLR -- Responder is HLR if Initiator is SGSN INITIATOR CONSUMER OF { authenticationFailureReportPackage-v3 } ID {map-ac authenticationFailureReport(39) version3(3)} } This application-context is v3 only. 17.3.2.50 Resource Management This application context is used between GMSC and VMSC for resource management purpose. resourceManagementContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VMSC if Initiator is GMSC INITIATOR CONSUMER OF { resourceManagementPackage-v3 } ID {map-ac resourceManagement(44) version3(3)} } This application-context is v3 only. 17.3.2.51 Mobile terminating Short Message Relay VGCS This application context is used between SMS-GMSC and MSC for mobile terminating short message relay procedures for VGCS. shortMsgMT-Relay-VGCS-Context-v3 APPLICATION-CONTEXT ::= { -- Responder is MSC if Initiator is SMS-GMSC INITIATOR CONSUMER OF { mt-ShortMsgRelay-VGCS-Package-v3} ID {map-ac shortMsgMT-Relay-VGCS(41) version3(3)} } This application-context is v3 only. 17.3.2.52 Vcsg Location Updating This application context is used between CSS and VLR or between CSS and SGSN for vcsg location updating procedures. vcsgLocationUpdateContext-v3 APPLICATION-CONTEXT ::= { -- Responder is CSS if Initiator is VLR or SGSN INITIATOR CONSUMER OF { vcsgLocationUpdatingPackage-v3} RESPONDER CONSUMER OF { subscriberDataMngtPackage-v3} ID {map-ac vcsgLocationUpdate(46) version3(3)} } This application-context is v3 only. 17.3.2.53 Vcsg Location Cancellation This application context is used between CSS and VLR or between CSS and SGSN for vcsg location cancellation procedures. vcsgLocationCancellationContext-v3 APPLICATION-CONTEXT ::= { -- Responder is VLR or SGSN if Initiator is CSS INITIATOR CONSUMER OF { vcsgLocationCancellationPackage-v3} ID {map-ac vcsgLocationCancel(47) version3(3)} } This application-context is v3 only. 17.3.3 ASN.1 Module for application-context-names The following ASN.1 module summarises the application-context-name assigned to MAP application-contexts. .$MAP-ApplicationContexts { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ApplicationContexts (2) version20 (20)} DEFINITIONS ::= BEGIN -- EXPORTS everything IMPORTS gsm-NetworkId, ac-Id FROM MobileDomainDefinitions { itu-t (0) identified-organization (4) etsi (0) mobileDomain (0) mobileDomainDefinitions (0) version1 (1)} ; -- application-context-names map-ac OBJECT IDENTIFIER ::= {gsm-NetworkId ac-Id} networkLocUpContext-v3 OBJECT IDENTIFIER ::= {map-ac networkLocUp(1) version3(3)} locationCancellationContext-v3 OBJECT IDENTIFIER ::= {map-ac locationCancel(2) version3(3)} roamingNumberEnquiryContext-v3 OBJECT IDENTIFIER ::= {map-ac roamingNbEnquiry(3) version3(3)} authenticationFailureReportContext-v3 OBJECT IDENTIFIER ::= {map-ac authenticationFailureReport(39) version3(3)} locationInfoRetrievalContext-v3 OBJECT IDENTIFIER ::= {map-ac locInfoRetrieval(5) version3(3)} resetContext-v3 OBJECT IDENTIFIER ::= {map-ac reset(10) version3(3)} handoverControlContext-v3 OBJECT IDENTIFIER ::= {map-ac handoverControl(11) version3(3)} equipmentMngtContext-v3 OBJECT IDENTIFIER ::= {map-ac equipmentMngt(13) version3(3)} infoRetrievalContext-v3 OBJECT IDENTIFIER ::= {map-ac infoRetrieval(14) version3(3)} interVlrInfoRetrievalContext-v3 OBJECT IDENTIFIER ::= {map-ac interVlrInfoRetrieval(15) version3(3)} subscriberDataMngtContext-v3 OBJECT IDENTIFIER ::= {map-ac subscriberDataMngt(16) version3(3)} tracingContext-v3 OBJECT IDENTIFIER ::= {map-ac tracing(17) version3(3)} networkFunctionalSsContext-v2 OBJECT IDENTIFIER ::= {map-ac networkFunctionalSs(18) version2(2)} networkUnstructuredSsContext-v2 OBJECT IDENTIFIER ::= {map-ac networkUnstructuredSs(19) version2(2)} shortMsgGatewayContext-v3 OBJECT IDENTIFIER ::= {map-ac shortMsgGateway(20) version3(3)} shortMsgMO-RelayContext-v3 OBJECT IDENTIFIER ::= {map-ac shortMsgMO-Relay(21) version3(3)} shortMsgAlertContext-v2 OBJECT IDENTIFIER ::= {map-ac shortMsgAlert(23) version2(2)} mwdMngtContext-v3 OBJECT IDENTIFIER ::= {map-ac mwdMngt(24) version3(3)} shortMsgMT-RelayContext-v3 OBJECT IDENTIFIER ::= {map-ac shortMsgMT-Relay(25) version3(3)} shortMsgMT-Relay-VGCS-Context-v3 OBJECT IDENTIFIER ::= {map-ac shortMsgMT-Relay-VGCS(41) version3(3)} imsiRetrievalContext-v2 OBJECT IDENTIFIER ::= {map-ac imsiRetrieval(26) version2(2)} msPurgingContext-v3 OBJECT IDENTIFIER ::= {map-ac msPurging(27) version3(3)} subscriberInfoEnquiryContext-v3 OBJECT IDENTIFIER ::= {map-ac subscriberInfoEnquiry(28) version3(3)} anyTimeInfoEnquiryContext-v3 OBJECT IDENTIFIER ::= {map-ac anyTimeInfoEnquiry(29) version3(3)} callControlTransferContext-v4 OBJECT IDENTIFIER ::= {map-ac callControlTransfer(6) version4(4)} ss-InvocationNotificationContext-v3 OBJECT IDENTIFIER ::= {map-ac ss-InvocationNotification(36) version3(3)} groupCallControlContext-v3 OBJECT IDENTIFIER ::= {map-ac groupCallControl(31) version3(3)} groupCallInfoRetrievalContext-v3 OBJECT IDENTIFIER ::= {map-ac groupCallInfoRetrieval(45) version3(3)} gprsLocationUpdateContext-v3 OBJECT IDENTIFIER ::= {map-ac gprsLocationUpdate(32) version3(3)} gprsLocationInfoRetrievalContext-v4 OBJECT IDENTIFIER ::= {map-ac gprsLocationInfoRetrieval(33) version4(4)} failureReportContext-v3 OBJECT IDENTIFIER ::= {map-ac failureReport(34) version3(3)} gprsNotifyContext-v3 OBJECT IDENTIFIER ::= {map-ac gprsNotify(35) version3(3)} reportingContext-v3 OBJECT IDENTIFIER ::= {map-ac reporting(7) version3(3)} callCompletionContext-v3 OBJECT IDENTIFIER ::= {map-ac callCompletion(8) version3(3)} istAlertingContext-v3 OBJECT IDENTIFIER ::= {map-ac istAlerting(4) version3(3)} serviceTerminationContext-v3 OBJECT IDENTIFIER ::= {map-ac immediateTermination(9) version3(3)} locationSvcGatewayContext-v3 OBJECT IDENTIFIER ::= {map-ac locationSvcGateway(37) version3(3)} locationSvcEnquiryContext-v3 OBJECT IDENTIFIER ::= {map-ac locationSvcEnquiry(38) version3(3)} mm-EventReportingContext-v3 OBJECT IDENTIFIER ::= {map-ac mm-EventReporting(42) version3(3)} anyTimeInfoHandlingContext-v3 OBJECT IDENTIFIER ::= {map-ac anyTimeInfoHandling(43) version3(3)} subscriberDataModificationNotificationContext-v3 OBJECT IDENTIFIER ::= {map-ac subscriberDataModificationNotification(22) version3(3)} resourceManagementContext-v3 OBJECT IDENTIFIER ::= {map-ac resourceManagement(44) version3(3)} vcsgLocationUpdateContext-v3 OBJECT IDENTIFIER ::= {map-ac vcsgLocationUpdate(46) version3(3)} vcsgLocationCancellationContext-v3 OBJECT IDENTIFIER ::= {map-ac vcsgLocationCancel(47) version3(3)} -- The following Object Identifiers are reserved for application-contexts -- existing in previous versions of the protocol -- AC Name & Version Object Identifier -- -- networkLocUpContext-v1 map-ac networkLocUp (1) version1 (1) -- networkLocUpContext-v2 map-ac networkLocUp (1) version2 (2) -- locationCancellationContext-v1 map-ac locationCancellation (2) version1 (1) -- locationCancellationContext-v2 map-ac locationCancellation (2) version2 (2) -- roamingNumberEnquiryContext-v1 map-ac roamingNumberEnquiry (3) version1 (1) -- roamingNumberEnquiryContext-v2 map-ac roamingNumberEnquiry (3) version2 (2) -- locationInfoRetrievalContext-v1 map-ac locationInfoRetrieval (5) version1 (1) -- locationInfoRetrievalContext-v2 map-ac locationInfoRetrieval (5) version2 (2) -- resetContext-v1 map-ac reset (10) version1 (1) -- resetContext-v2 map-ac reset (10) version2 (2) -- handoverControlContext-v1 map-ac handoverControl (11) version1 (1) -- handoverControlContext-v2 map-ac handoverControl (11) version2 (2) -- sIWFSAllocationContext-v3 map-ac sIWFSAllocation (12) version3 (3) -- equipmentMngtContext-v1 map-ac equipmentMngt (13) version1 (1) -- equipmentMngtContext-v2 map-ac equipmentMngt (13) version2 (2) -- infoRetrievalContext-v1 map-ac infoRetrieval (14) version1 (1) -- infoRetrievalContext-v2 map-ac infoRetrieval (14) version2 (2) -- interVlrInfoRetrievalContext-v2 map-ac interVlrInfoRetrieval (15) version2 (2) -- subscriberDataMngtContext-v1 map-ac subscriberDataMngt (16) version1 (1) -- subscriberDataMngtContext-v2 map-ac subscriberDataMngt (16) version2 (2) -- tracingContext-v1 map-ac tracing (17) version1 (1) -- tracingContext-v2 map-ac tracing (17) version2 (2) -- networkFunctionalSsContext-v1 map-ac networkFunctionalSs (18) version1 (1) -- shortMsgGatewayContext-v1 map-ac shortMsgGateway (20) version1 (1) -- shortMsgGatewayContext-v2 map-ac shortMsgGateway (20) version2 (2) -- shortMsgRelayContext-v1 map-ac shortMsgRelay (21) version1 (1) -- shortMsgAlertContext-v1 map-ac shortMsgAlert (23) version1 (1) -- mwdMngtContext-v1 map-ac mwdMngt (24) version1 (1) -- mwdMngtContext-v2 map-ac mwdMngt (24) version2 (2) -- shortMsgMT-RelayContext-v2 map-ac shortMsgMT-Relay (25) version2 (2) -- msPurgingContext-v2 map-ac msPurging (27) version2 (2) -- callControlTransferContext-v3 map-ac callControlTransferContext (6) version3 (3) -- gprsLocationInfoRetrievalContext-v3 map-ac gprsLocationInfoRetrievalContext (33) version3 (3) .#END 17.4 MAP Dialogue Information .$MAP-DialogueInformation { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-DialogueInformation (3) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS map-DialogueAS, MAP-DialoguePDU ; IMPORTS gsm-NetworkId, as-Id FROM MobileDomainDefinitions { itu-t (0) identified-organization (4) etsi (0) mobileDomain (0) mobileDomainDefinitions (0) version1 (1)} AddressString FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network(1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; -- abstract syntax name for MAP-DialoguePDU map-DialogueAS OBJECT IDENTIFIER ::= {gsm-NetworkId as-Id map-DialoguePDU (1) version1 (1)} MAP-DialoguePDU ::= CHOICE { map-open [0] MAP-OpenInfo, map-accept [1] MAP-AcceptInfo, map-close [2] MAP-CloseInfo, map-refuse [3] MAP-RefuseInfo, map-userAbort [4] MAP-UserAbortInfo, map-providerAbort [5] MAP-ProviderAbortInfo} MAP-OpenInfo ::= SEQUENCE { destinationReference [0] AddressString OPTIONAL, originationReference [1] AddressString OPTIONAL, ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-AcceptInfo ::= SEQUENCE { ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-CloseInfo ::= SEQUENCE { ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-RefuseInfo ::= SEQUENCE { reason Reason, ..., extensionContainer ExtensionContainer OPTIONAL, -- extensionContainer must not be used in version 2 alternativeApplicationContext OBJECT IDENTIFIER OPTIONAL -- alternativeApplicationContext must not be used in version 2 } Reason ::= ENUMERATED { noReasonGiven (0), invalidDestinationReference (1), invalidOriginatingReference (2)} MAP-UserAbortInfo ::= SEQUENCE { map-UserAbortChoice MAP-UserAbortChoice, ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-UserAbortChoice ::= CHOICE { userSpecificReason [0] NULL, userResourceLimitation [1] NULL, resourceUnavailable [2] ResourceUnavailableReason, applicationProcedureCancellation [3] ProcedureCancellationReason} ResourceUnavailableReason ::= ENUMERATED { shortTermResourceLimitation (0), longTermResourceLimitation (1)} ProcedureCancellationReason ::= ENUMERATED { handoverCancellation (0), radioChannelRelease (1), networkPathRelease (2), callRelease (3), associatedProcedureFailure (4), tandemDialogueRelease (5), remoteOperationsFailure (6)} MAP-ProviderAbortInfo ::= SEQUENCE { map-ProviderAbortReason MAP-ProviderAbortReason, ..., extensionContainer ExtensionContainer OPTIONAL -- extensionContainer must not be used in version 2 } MAP-ProviderAbortReason ::= ENUMERATED { abnormalDialogue (0), invalidPDU (1)} .#END 17.5 MAP operation and error codes .$MAP-Protocol { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Protocol (4) version20 (20)} DEFINITIONS ::= BEGIN IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} updateLocation, cancelLocation, cancelVcsgLocation, purgeMS, sendIdentification, updateGprsLocation, updateVcsgLocation, prepareHandover, sendEndSignal, processAccessSignalling, forwardAccessSignalling, prepareSubsequentHandover, sendAuthenticationInfo, authenticationFailureReport, checkIMEI, insertSubscriberData, deleteSubscriberData, reset, forwardCheckSS-Indication, restoreData, provideSubscriberInfo, anyTimeInterrogation, anyTimeSubscriptionInterrogation, anyTimeModification, sendRoutingInfoForGprs, failureReport, noteMsPresentForGprs, noteMM-Event, noteSubscriberDataModified FROM MAP-MobileServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MobileServiceOperations (5) version20 (20)} activateTraceMode, deactivateTraceMode, sendIMSI FROM MAP-OperationAndMaintenanceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OperationAndMaintenanceOperations (6) version20 (20)} sendRoutingInfo, provideRoamingNumber, resumeCallHandling, setReportingState, statusReport, remoteUserFree, ist-Alert, ist-Command, releaseResources FROM MAP-CallHandlingOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CallHandlingOperations (7) version20 (20)} registerSS, eraseSS, activateSS, deactivateSS, interrogateSS, processUnstructuredSS-Request, unstructuredSS-Request, unstructuredSS-Notify, registerPassword, getPassword, ss-InvocationNotification, registerCC-Entry, eraseCC-Entry FROM MAP-SupplementaryServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SupplementaryServiceOperations (8) version20 (20)} sendRoutingInfoForSM, mo-ForwardSM, mt-ForwardSM, reportSM-DeliveryStatus, alertServiceCentre, informServiceCentre, readyForSM, mt-ForwardSM-VGCS FROM MAP-ShortMessageServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9) version20 (20)} prepareGroupCall, processGroupCallSignalling, forwardGroupCallSignalling, sendGroupCallEndSignal, sendGroupCallInfo FROM MAP-Group-Call-Operations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Group-Call-Operations (22) version20 (20)} provideSubscriberLocation, sendRoutingInfoForLCS, subscriberLocationReport FROM MAP-LocationServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-LocationServiceOperations (24) version20 (20)} ; Supported-MAP-Operations OPERATION ::= {updateLocation | cancelLocation | cancelVcsgLocation | purgeMS | sendIdentification | updateGprsLocation | updateVcsgLocation | prepareHandover | sendEndSignal | processAccessSignalling | forwardAccessSignalling | prepareSubsequentHandover | sendAuthenticationInfo | authenticationFailureReport | checkIMEI | insertSubscriberData | deleteSubscriberData | reset | forwardCheckSS-Indication | restoreData | provideSubscriberInfo | anyTimeInterrogation | anyTimeSubscriptionInterrogation | anyTimeModification | sendRoutingInfoForGprs | failureReport |noteMsPresentForGprs | noteMM-Event | noteSubscriberDataModified | activateTraceMode | deactivateTraceMode | sendIMSI | sendRoutingInfo | provideRoamingNumber | resumeCallHandling | setReportingState | statusReport | remoteUserFree | ist-Alert | ist-Command | registerSS | eraseSS | activateSS | deactivateSS | interrogateSS | processUnstructuredSS-Request | unstructuredSS-Request | unstructuredSS-Notify | registerPassword | getPassword | ss-InvocationNotification | registerCC-Entry | eraseCC-Entry | sendRoutingInfoForSM | mo-ForwardSM | mt-ForwardSM | reportSM-DeliveryStatus | alertServiceCentre | informServiceCentre | readyForSM | prepareGroupCall | processGroupCallSignalling | forwardGroupCallSignalling | sendGroupCallEndSignal | provideSubscriberLocation | sendRoutingInfoForLCS | subscriberLocationReport | releaseResources | mt-ForwardSM-VGCS | sendGroupCallInfo } -- The following operation codes are reserved for operations -- existing in previous versions of the protocol -- Operation Name AC used Oper. Code -- -- sendParameters map-ac infoRetrieval (14) version1 (1) local:9 -- processUnstructuredSS-Data map-ac networkFunctionalSs (18) version1 (1) local:19 -- performHandover map-ac handoverControl (11) version1 (1) local:28 -- performSubsequentHandover map-ac handoverControl (11) version1 (1) local:30 -- provideSIWFSNumber map-ac sIWFSAllocation (12) version3 (3) local:31 -- siwfs-SignallingModify map-ac sIWFSAllocation (12) version3 (3) local:32 -- noteInternalHandover map-ac handoverControl (11) version1 (1) local:35 -- noteSubscriberPresent map-ac mwdMngt (24) version1 (1) local:48 -- alertServiceCentreWithoutResult map-ac shortMsgAlert (23) version1 (1) local:49 -- traceSubscriberActivity map-ac handoverControl (11) version1 (1) local:52 -- beginSubscriberActivity map-ac networkFunctionalSs (18) version1 (1) local:54 -- The following error codes are reserved for errors -- existing in previous versions of the protocol -- Error Name AC used Error Code -- -- unknownBaseStation map-ac handoverControl (11) version1 (1) local:2 -- invalidTargetBaseStation map-ac handoverControl (11) version1 (1) local:23 -- noRadioResourceAvailable map-ac handoverControl (11) version1 (1) local:24 .#END 17.6 MAP operations and errors 17.6.1 Mobile Service Operations .$MAP-MobileServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MobileServiceOperations (5) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS -- location registration operations updateLocation, cancelLocation, purgeMS, sendIdentification, -- gprs location registration operations updateGprsLocation, -- vcsg location registration operations updateVcsgLocation, cancelVcsgLocation, -- subscriber information enquiry operations provideSubscriberInfo, -- any time information enquiry operations anyTimeInterrogation, -- any time information handling operations anyTimeSubscriptionInterrogation, anyTimeModification, -- subscriber data modification notification operations noteSubscriberDataModified, -- handover operations prepareHandover, sendEndSignal, processAccessSignalling, forwardAccessSignalling, prepareSubsequentHandover, -- authentication management operations sendAuthenticationInfo, authenticationFailureReport, -- IMEI management operations checkIMEI, -- subscriber management operations insertSubscriberData, deleteSubscriberData, -- fault recovery operations reset, forwardCheckSS-Indication, restoreData, -- gprs location information retrieval operations sendRoutingInfoForGprs, -- failure reporting operations failureReport, -- gprs notification operations noteMsPresentForGprs, -- Mobility Management operations noteMM-Event ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, unknownSubscriber, unknownMSC, unidentifiedSubscriber, unknownEquipment, roamingNotAllowed, ati-NotAllowed, noHandoverNumberAvailable, subsequentHandoverFailure, absentSubscriber, mm-EventNotSupported, atsi-NotAllowed, atm-NotAllowed, bearerServiceNotProvisioned, teleserviceNotProvisioned, callBarred, illegalSS-Operation, ss-ErrorStatus, ss-NotAvailable, ss-Incompatibility, ss-SubscriptionViolation, informationNotAvailable, targetCellOutsideGroupCallArea FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} UpdateLocationArg, UpdateLocationRes, CancelLocationArg, CancelLocationRes, PurgeMS-Arg, PurgeMS-Res, SendIdentificationArg, SendIdentificationRes, UpdateGprsLocationArg, UpdateGprsLocationRes, UpdateVcsgLocationArg, UpdateVcsgLocationRes, CancelVcsgLocationArg, CancelVcsgLocationRes, PrepareHO-Arg, PrepareHO-Res, ForwardAccessSignalling-Arg, ProcessAccessSignalling-Arg, SendEndSignal-Arg, SendEndSignal-Res, PrepareSubsequentHO-Res, PrepareSubsequentHO-Arg, SendAuthenticationInfoArg, SendAuthenticationInfoRes, AuthenticationFailureReportArg, AuthenticationFailureReportRes, CheckIMEI-Arg, CheckIMEI-Res, InsertSubscriberDataArg, InsertSubscriberDataRes, DeleteSubscriberDataArg, DeleteSubscriberDataRes, ResetArg, RestoreDataArg, RestoreDataRes, ProvideSubscriberInfoArg, ProvideSubscriberInfoRes, AnyTimeSubscriptionInterrogationArg, AnyTimeSubscriptionInterrogationRes, AnyTimeModificationArg, AnyTimeModificationRes, NoteSubscriberDataModifiedArg, NoteSubscriberDataModifiedRes, AnyTimeInterrogationArg, AnyTimeInterrogationRes, SendRoutingInfoForGprsArg, SendRoutingInfoForGprsRes, FailureReportArg, FailureReportRes, NoteMsPresentForGprsArg, NoteMsPresentForGprsRes, NoteMM-EventArg, NoteMM-EventRes FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} ; -- location registration operations updateLocation OPERATION ::= { --Timer m ARGUMENT UpdateLocationArg RESULT UpdateLocationRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber | roamingNotAllowed} CODE local:2 } cancelLocation OPERATION ::= { --Timer m ARGUMENT CancelLocationArg RESULT CancelLocationRes -- optional ERRORS { dataMissing | unexpectedDataValue} CODE local:3 } purgeMS OPERATION ::= { --Timer m ARGUMENT PurgeMS-Arg RESULT PurgeMS-Res -- optional ERRORS{ dataMissing | unexpectedDataValue| unknownSubscriber} CODE local:67 } sendIdentification OPERATION ::= { --Timer s ARGUMENT SendIdentificationArg RESULT SendIdentificationRes ERRORS { dataMissing | unidentifiedSubscriber} CODE local:55 } -- gprs location registration operations updateGprsLocation OPERATION ::= { --Timer m ARGUMENT UpdateGprsLocationArg RESULT UpdateGprsLocationRes ERRORS { systemFailure | unexpectedDataValue | unknownSubscriber | roamingNotAllowed} CODE local:23 } -- subscriber information enquiry operations provideSubscriberInfo OPERATION ::= { --Timer m ARGUMENT ProvideSubscriberInfoArg RESULT ProvideSubscriberInfoRes ERRORS { dataMissing | unexpectedDataValue} CODE local:70 } -- any time information enquiry operations anyTimeInterrogation OPERATION ::= { --Timer m ARGUMENT AnyTimeInterrogationArg RESULT AnyTimeInterrogationRes ERRORS { systemFailure | ati-NotAllowed | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:71 } -- any time information handling operations anyTimeSubscriptionInterrogation OPERATION ::= { --Timer m ARGUMENT AnyTimeSubscriptionInterrogationArg RESULT AnyTimeSubscriptionInterrogationRes ERRORS { atsi-NotAllowed | dataMissing | unexpectedDataValue | unknownSubscriber | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-NotAvailable | informationNotAvailable} CODE local:62 } anyTimeModification OPERATION ::= { --Timer m ARGUMENT AnyTimeModificationArg RESULT AnyTimeModificationRes ERRORS { atm-NotAllowed | dataMissing | unexpectedDataValue | unknownSubscriber | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-SubscriptionViolation | ss-ErrorStatus | ss-Incompatibility | informationNotAvailable} CODE local:65 } -- subscriber data modification notification operations noteSubscriberDataModified OPERATION ::= { --Timer m ARGUMENT NoteSubscriberDataModifiedArg RESULT NoteSubscriberDataModifiedRes -- optional ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:5 } -- handover operations prepareHandover OPERATION ::= { --Timer m ARGUMENT PrepareHO-Arg RESULT PrepareHO-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | noHandoverNumberAvailable | targetCellOutsideGroupCallArea } CODE local:68 } sendEndSignal OPERATION ::= { --Timer l ARGUMENT SendEndSignal-Arg RESULT SendEndSignal-Res CODE local:29 } processAccessSignalling OPERATION ::= { --Timer s ARGUMENT ProcessAccessSignalling-Arg CODE local:33 } forwardAccessSignalling OPERATION ::= { --Timer s ARGUMENT ForwardAccessSignalling-Arg CODE local:34 } prepareSubsequentHandover OPERATION ::= { --Timer m ARGUMENT PrepareSubsequentHO-Arg RESULT PrepareSubsequentHO-Res ERRORS { unexpectedDataValue | dataMissing | unknownMSC | subsequentHandoverFailure} CODE local:69 } -- authentication management operations sendAuthenticationInfo OPERATION ::= { --Timer m ARGUMENT SendAuthenticationInfoArg -- optional -- within a dialogue sendAuthenticationInfoArg shall not be present in -- subsequent invoke components. If received in a subsequent invoke component -- it shall be discarded."
"RESULT SendAuthenticationInfoRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:56 } authenticationFailureReport OPERATION ::= { --Timer m ARGUMENT AuthenticationFailureReportArg RESULT AuthenticationFailureReportRes -- optional ERRORS { systemFailure | unexpectedDataValue | unknownSubscriber} CODE local:15 } -- IMEI management operations checkIMEI OPERATION ::= { --Timer m ARGUMENT CheckIMEI-Arg RESULT CheckIMEI-Res ERRORS { systemFailure | dataMissing | unknownEquipment} CODE local:43 } -- subscriber management operations insertSubscriberData OPERATION ::= { --Timer m ARGUMENT InsertSubscriberDataArg RESULT InsertSubscriberDataRes -- optional ERRORS { dataMissing | unexpectedDataValue | unidentifiedSubscriber} CODE local:7 } deleteSubscriberData OPERATION ::= { --Timer m ARGUMENT DeleteSubscriberDataArg RESULT DeleteSubscriberDataRes -- optional ERRORS { dataMissing | unexpectedDataValue | unidentifiedSubscriber} CODE local:8 } -- fault recovery operations reset OPERATION ::= { --Timer m ARGUMENT ResetArg CODE local:37 } forwardCheckSS-Indication OPERATION ::= { --Timer s CODE local:38 } restoreData OPERATION ::= { --Timer m ARGUMENT RestoreDataArg RESULT RestoreDataRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:57 } -- gprs location information retrieval operations sendRoutingInfoForGprs OPERATION ::= { --Timer m ARGUMENT SendRoutingInfoForGprsArg RESULT SendRoutingInfoForGprsRes ERRORS { absentSubscriber | systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber | callBarred } CODE local:24 } -- failure reporting operations failureReport OPERATION ::= { --Timer m ARGUMENT FailureReportArg RESULT FailureReportRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:25 } -- gprs notification operations noteMsPresentForGprs OPERATION ::= { --Timer m ARGUMENT NoteMsPresentForGprsArg RESULT NoteMsPresentForGprsRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:26 } noteMM-Event OPERATION ::= { --Timer m ARGUMENT NoteMM-EventArg RESULT NoteMM-EventRes ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber | mm-EventNotSupported} CODE local:89 } -- vcsg location registration operations updateVcsgLocation OPERATION ::= { --Timer m ARGUMENT UpdateVcsgLocationArg RESULT UpdateVcsgLocationRes ERRORS { systemFailure | unexpectedDataValue | unknownSubscriber} CODE local:53 } cancelVcsgLocation OPERATION ::= { --Timer m ARGUMENT CancelVcsgLocationArg RESULT CancelVcsgLocationRes -- optional ERRORS { dataMissing | unexpectedDataValue} CODE local:36 } .#END 17.6.2 Operation and Maintenance Operations .$MAP-OperationAndMaintenanceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OperationAndMaintenanceOperations (6) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS activateTraceMode, deactivateTraceMode, sendIMSI ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, unknownSubscriber, unidentifiedSubscriber, tracingBufferFull FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} ActivateTraceModeArg, ActivateTraceModeRes, DeactivateTraceModeArg, DeactivateTraceModeRes FROM MAP-OM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OM-DataTypes (12) version20 (20)} ISDN-AddressString, IMSI FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ; activateTraceMode OPERATION ::= { --Timer m ARGUMENT ActivateTraceModeArg RESULT ActivateTraceModeRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unidentifiedSubscriber | tracingBufferFull} CODE local:50 } deactivateTraceMode OPERATION ::= { --Timer m ARGUMENT DeactivateTraceModeArg RESULT DeactivateTraceModeRes -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unidentifiedSubscriber} CODE local:51 } sendIMSI OPERATION ::= { --Timer m ARGUMENT ISDN-AddressString RESULT IMSI ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:58 } .#END 17.6.3 Call Handling Operations .$MAP-CallHandlingOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CallHandlingOperations (7) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS sendRoutingInfo, provideRoamingNumber, resumeCallHandling, setReportingState, statusReport, remoteUserFree, ist-Alert, ist-Command, releaseResources ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, or-NotAllowed, unknownSubscriber, numberChanged, bearerServiceNotProvisioned, teleserviceNotProvisioned, noRoamingNumberAvailable, absentSubscriber, busySubscriber, noSubscriberReply, callBarred, forwardingViolation, forwardingFailed, cug-Reject, resourceLimitation, incompatibleTerminal, unidentifiedSubscriber FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} SendRoutingInfoArg, SendRoutingInfoRes, ProvideRoamingNumberArg, ProvideRoamingNumberRes, ResumeCallHandlingArg, ResumeCallHandlingRes, SetReportingStateArg, SetReportingStateRes, StatusReportArg, StatusReportRes, RemoteUserFreeArg, RemoteUserFreeRes, IST-AlertArg, IST-AlertRes, IST-CommandArg, IST-CommandRes, ReleaseResourcesArg, ReleaseResourcesRes FROM MAP-CH-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CH-DataTypes (13) version20 (20)} ; sendRoutingInfo OPERATION ::= { --Timer m -- The timer is set to the upper limit of the range if the GMSC supports pre-paging. ARGUMENT SendRoutingInfoArg RESULT SendRoutingInfoRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | or-NotAllowed | unknownSubscriber | numberChanged | bearerServiceNotProvisioned | teleserviceNotProvisioned | absentSubscriber | busySubscriber | noSubscriberReply | callBarred | cug-Reject | forwardingViolation} CODE local:22 } provideRoamingNumber OPERATION ::= { --Timer m -- The timer is set to the upper limit of the range if the HLR supports pre-paging. ARGUMENT ProvideRoamingNumberArg RESULT ProvideRoamingNumberRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | or-NotAllowed | absentSubscriber | noRoamingNumberAvailable} CODE local:4 } resumeCallHandling OPERATION ::= { --Timer m ARGUMENT ResumeCallHandlingArg RESULT ResumeCallHandlingRes -- optional ERRORS { forwardingFailed | or-NotAllowed | unexpectedDataValue | dataMissing } CODE local:6 } setReportingState OPERATION ::= { --Timer m ARGUMENT SetReportingStateArg RESULT SetReportingStateRes -- optional ERRORS { systemFailure | unidentifiedSubscriber | unexpectedDataValue | dataMissing | resourceLimitation | facilityNotSupported} CODE local:73 } statusReport OPERATION ::= { --Timer m ARGUMENT StatusReportArg RESULT StatusReportRes -- optional ERRORS { unknownSubscriber | systemFailure | unexpectedDataValue | dataMissing} CODE local:74 } remoteUserFree OPERATION ::= { --Timer ml ARGUMENT RemoteUserFreeArg RESULT RemoteUserFreeRes ERRORS { unexpectedDataValue | dataMissing | incompatibleTerminal | absentSubscriber | systemFailure | busySubscriber} CODE local:75 } ist-Alert OPERATION ::= { --Timer m ARGUMENT IST-AlertArg RESULT IST-AlertRes -- optional ERRORS { unexpectedDataValue | resourceLimitation | unknownSubscriber | systemFailure | facilityNotSupported} CODE local:87 } ist-Command OPERATION::= { --Timer m ARGUMENT IST-CommandArg RESULT IST-CommandRes -- optional ERRORS { unexpectedDataValue | resourceLimitation | unknownSubscriber | systemFailure | facilityNotSupported} CODE local:88 } releaseResources OPERATION::= { --Timer m ARGUMENT ReleaseResourcesArg RESULT ReleaseResourcesRes -- optional ERRORS { unexpectedDataValue | systemFailure } CODE local:20 } .#END 17.6.4 Supplementary service operations .$MAP-SupplementaryServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SupplementaryServiceOperations (8) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS registerSS, eraseSS, activateSS, deactivateSS, interrogateSS, processUnstructuredSS-Request, unstructuredSS-Request, unstructuredSS-Notify, registerPassword, getPassword, ss-InvocationNotification, registerCC-Entry, eraseCC-Entry ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, unknownSubscriber, bearerServiceNotProvisioned, teleserviceNotProvisioned, callBarred, illegalSS-Operation, ss-ErrorStatus, ss-NotAvailable, ss-SubscriptionViolation, ss-Incompatibility, pw-RegistrationFailure, negativePW-Check, numberOfPW-AttemptsViolation, unknownAlphabet, ussd-Busy, absentSubscriber, illegalSubscriber, illegalEquipment, shortTermDenial, longTermDenial, facilityNotSupported FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} RegisterSS-Arg, SS-Info, SS-ForBS-Code, InterrogateSS-Res, USSD-Arg, USSD-Res, Password, GuidanceInfo, SS-InvocationNotificationArg, SS-InvocationNotificationRes, RegisterCC-EntryArg, RegisterCC-EntryRes, EraseCC-EntryArg, EraseCC-EntryRes FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} ; -- supplementary service handling operations registerSS OPERATION ::= { --Timer m ARGUMENT RegisterSS-Arg RESULT SS-Info -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-ErrorStatus | ss-Incompatibility} CODE local:10 } eraseSS OPERATION ::= { --Timer m ARGUMENT SS-ForBS-Code RESULT SS-Info -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-ErrorStatus } CODE local:11 } activateSS OPERATION ::= { --Timer m ARGUMENT SS-ForBS-Code RESULT SS-Info -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-ErrorStatus | ss-SubscriptionViolation | ss-Incompatibility | negativePW-Check | numberOfPW-AttemptsViolation} CODE local:12 } deactivateSS OPERATION ::= { --Timer m ARGUMENT SS-ForBS-Code RESULT SS-Info -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-ErrorStatus | ss-SubscriptionViolation | negativePW-Check | numberOfPW-AttemptsViolation} CODE local:13 } interrogateSS OPERATION ::= { --Timer m ARGUMENT SS-ForBS-Code RESULT InterrogateSS-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | bearerServiceNotProvisioned | teleserviceNotProvisioned | callBarred | illegalSS-Operation | ss-NotAvailable} CODE local:14 } processUnstructuredSS-Request OPERATION ::= { --Timer 10 minutes ARGUMENT USSD-Arg RESULT USSD-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | unknownAlphabet | callBarred} CODE local:59 } unstructuredSS-Request OPERATION ::= { --Timer ml ARGUMENT USSD-Arg RESULT USSD-Res -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | absentSubscriber | illegalSubscriber | illegalEquipment | unknownAlphabet | ussd-Busy} CODE local:60 } unstructuredSS-Notify OPERATION ::= { --Timer ml ARGUMENT USSD-Arg RETURN RESULT TRUE ERRORS { systemFailure | dataMissing | unexpectedDataValue | absentSubscriber | illegalSubscriber | illegalEquipment | unknownAlphabet | ussd-Busy} CODE local:61 } registerPassword OPERATION ::= { --Timer ml ARGUMENT SS-Code RESULT Password ERRORS { systemFailure | dataMissing | unexpectedDataValue | callBarred | ss-SubscriptionViolation | pw-RegistrationFailure | negativePW-Check | numberOfPW-AttemptsViolation} -- LINKED { -- getPassword} CODE local:17 } getPassword OPERATION ::= { --Timer m ARGUMENT GuidanceInfo RESULT Password CODE local:18 } ss-InvocationNotification OPERATION ::= { --Timer m ARGUMENT SS-InvocationNotificationArg RESULT SS-InvocationNotificationRes -- optional ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber} CODE local:72 } registerCC-Entry OPERATION ::= { --Timer m ARGUMENT RegisterCC-EntryArg RESULT RegisterCC-EntryRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | callBarred | illegalSS-Operation | ss-ErrorStatus | ss-Incompatibility | shortTermDenial | longTermDenial | facilityNotSupported} CODE local:76 } eraseCC-Entry OPERATION ::= { --Timer m ARGUMENT EraseCC-EntryArg RESULT EraseCC-EntryRes ERRORS { systemFailure | dataMissing | unexpectedDataValue | callBarred | illegalSS-Operation | ss-ErrorStatus} CODE local:77 } .#END 17.6.5 Short message service operations .$MAP-ShortMessageServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ShortMessageServiceOperations (9) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS sendRoutingInfoForSM, mo-ForwardSM, mt-ForwardSM, reportSM-DeliveryStatus, alertServiceCentre, informServiceCentre, readyForSM, mt-ForwardSM-VGCS ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, unknownSubscriber, unidentifiedSubscriber, illegalSubscriber, illegalEquipment, teleserviceNotProvisioned, callBarred, subscriberBusyForMT-SMS, sm-DeliveryFailure, messageWaitingListFull, absentSubscriberSM FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} RoutingInfoForSM-Arg, RoutingInfoForSM-Res, MO-ForwardSM-Arg, MO-ForwardSM-Res, MT-ForwardSM-Arg, MT-ForwardSM-Res, ReportSM-DeliveryStatusArg, ReportSM-DeliveryStatusRes, AlertServiceCentreArg, InformServiceCentreArg, ReadyForSM-Arg, ReadyForSM-Res, MT-ForwardSM-VGCS-Arg, MT-ForwardSM-VGCS-Res FROM MAP-SM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version20 (20)} ; sendRoutingInfoForSM OPERATION ::= { --Timer m ARGUMENT RoutingInfoForSM-Arg RESULT RoutingInfoForSM-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unknownSubscriber | teleserviceNotProvisioned | callBarred | absentSubscriberSM} CODE local:45 } mo-ForwardSM OPERATION ::= { --Timer ml ARGUMENT MO-ForwardSM-Arg RESULT MO-ForwardSM-Res -- optional ERRORS { systemFailure | unexpectedDataValue | facilityNotSupported | sm-DeliveryFailure} CODE local:46 } mt-ForwardSM OPERATION ::= { --Timer ml -- the timer value may be subject to negotiation between GMSC and IP-SM-GW ARGUMENT MT-ForwardSM-Arg RESULT MT-ForwardSM-Res -- optional ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unidentifiedSubscriber | illegalSubscriber | illegalEquipment | subscriberBusyForMT-SMS | sm-DeliveryFailure | absentSubscriberSM} CODE local:44 } reportSM-DeliveryStatus OPERATION ::= { --Timer s ARGUMENT ReportSM-DeliveryStatusArg RESULT ReportSM-DeliveryStatusRes -- optional ERRORS { dataMissing | unexpectedDataValue | unknownSubscriber | messageWaitingListFull} CODE local:47 } alertServiceCentre OPERATION ::= { --Timer s ARGUMENT AlertServiceCentreArg RETURN RESULT TRUE ERRORS { systemFailure | dataMissing | unexpectedDataValue} CODE local:64 } informServiceCentre OPERATION ::= { --Timer s ARGUMENT InformServiceCentreArg CODE local:63 } readyForSM OPERATION ::= { --Timer m ARGUMENT ReadyForSM-Arg RESULT ReadyForSM-Res -- optional ERRORS { dataMissing | unexpectedDataValue | facilityNotSupported | unknownSubscriber} CODE local:66 } mt-ForwardSM-VGCS OPERATION ::= { --Timer ml ARGUMENT MT-ForwardSM-VGCS-Arg RESULT MT-ForwardSM-VGCS-Res -- optional ERRORS { systemFailure | unexpectedDataValue } CODE local:21 } .#END 17.6.6 Errors .$MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS -- generic errors systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, incompatibleTerminal, resourceLimitation, -- identification and numbering errors unknownSubscriber, numberChanged, unknownMSC, unidentifiedSubscriber, unknownEquipment, -- subscription errors roamingNotAllowed, illegalSubscriber, illegalEquipment, bearerServiceNotProvisioned, teleserviceNotProvisioned, -- handover errors noHandoverNumberAvailable, subsequentHandoverFailure, targetCellOutsideGroupCallArea, -- operation and maintenance errors tracingBufferFull, -- call handling errors or-NotAllowed, noRoamingNumberAvailable, busySubscriber, noSubscriberReply, absentSubscriber, callBarred, forwardingViolation, forwardingFailed, cug-Reject, -- any time interrogation errors ati-NotAllowed, -- any time information handling errors atsi-NotAllowed, atm-NotAllowed, informationNotAvailable, -- supplementary service errors illegalSS-Operation, ss-ErrorStatus, ss-NotAvailable, ss-SubscriptionViolation, ss-Incompatibility, unknownAlphabet, ussd-Busy, pw-RegistrationFailure, negativePW-Check, numberOfPW-AttemptsViolation, shortTermDenial, longTermDenial, -- short message service errors subscriberBusyForMT-SMS, sm-DeliveryFailure, messageWaitingListFull, absentSubscriberSM, -- Group Call errors noGroupCallNumberAvailable, ongoingGroupCall, -- location service errors unauthorizedRequestingNetwork, unauthorizedLCSClient, positionMethodFailure, unknownOrUnreachableLCSClient, -- Mobility Management errors mm-EventNotSupported ; IMPORTS ERROR FROM Remote-Operations-Information-Objects {joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0) } SS-Status FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} SS-IncompatibilityCause, PW-RegistrationFailureCause, SM-DeliveryFailureCause, SystemFailureParam, DataMissingParam, UnexpectedDataParam, FacilityNotSupParam, UnknownSubscriberParam, NumberChangedParam, UnidentifiedSubParam, RoamingNotAllowedParam, IllegalSubscriberParam, IllegalEquipmentParam, BearerServNotProvParam, TeleservNotProvParam, TracingBufferFullParam, NoRoamingNbParam, OR-NotAllowedParam, AbsentSubscriberParam, BusySubscriberParam, NoSubscriberReplyParam, CallBarredParam, ForwardingViolationParam, ForwardingFailedParam, CUG-RejectParam, ATI-NotAllowedParam, SubBusyForMT-SMS-Param, MessageWaitListFullParam, AbsentSubscriberSM-Param, ResourceLimitationParam, NoGroupCallNbParam, IncompatibleTerminalParam, ShortTermDenialParam, LongTermDenialParam, UnauthorizedRequestingNetwork-Param, UnauthorizedLCSClient-Param, PositionMethodFailure-Param, UnknownOrUnreachableLCSClient-Param, MM-EventNotSupported-Param, ATSI-NotAllowedParam, ATM-NotAllowedParam, IllegalSS-OperationParam, SS-NotAvailableParam, SS-SubscriptionViolationParam, InformationNotAvailableParam, TargetCellOutsideGCA-Param, OngoingGroupCallParam FROM MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version20 (20)} ; -- generic errors systemFailure ERROR ::= { PARAMETER SystemFailureParam -- optional CODE local:34 } dataMissing ERROR ::= { PARAMETER DataMissingParam -- optional -- DataMissingParam must not be used in version <3 CODE local:35 } unexpectedDataValue ERROR ::= { PARAMETER UnexpectedDataParam -- optional -- UnexpectedDataParam must not be used in version <3 CODE local:36 } facilityNotSupported ERROR ::= { PARAMETER FacilityNotSupParam -- optional -- FacilityNotSupParam must not be used in version <3 CODE local:21 } incompatibleTerminal ERROR ::= { PARAMETER IncompatibleTerminalParam -- optional CODE local:28 } resourceLimitation ERROR ::= { PARAMETER ResourceLimitationParam -- optional CODE local:51 } -- identification and numbering errors unknownSubscriber ERROR ::= { PARAMETER UnknownSubscriberParam -- optional -- UnknownSubscriberParam must not be used in version <3 CODE local:1 } numberChanged ERROR ::= { PARAMETER NumberChangedParam -- optional CODE local:44 } unknownMSC ERROR ::= { CODE local:3 } unidentifiedSubscriber ERROR ::= { PARAMETER UnidentifiedSubParam -- optional -- UunidentifiedSubParam must not be used in version <3 CODE local:5 } unknownEquipment ERROR ::= { CODE local:7 } -- subscription errors roamingNotAllowed ERROR ::= { PARAMETER RoamingNotAllowedParam CODE local:8 } illegalSubscriber ERROR ::= { PARAMETER IllegalSubscriberParam -- optional -- IllegalSubscriberParam must not be used in version <3 CODE local:9 } illegalEquipment ERROR ::= { PARAMETER IllegalEquipmentParam -- optional -- IllegalEquipmentParam must not be used in version <3 CODE local:12 } bearerServiceNotProvisioned ERROR ::= { PARAMETER BearerServNotProvParam -- optional -- BearerServNotProvParam must not be used in version <3 CODE local:10 } teleserviceNotProvisioned ERROR ::= { PARAMETER TeleservNotProvParam -- optional -- TeleservNotProvParam must not be used in version <3 CODE local:11 } -- handover errors noHandoverNumberAvailable ERROR ::= { CODE local:25 } subsequentHandoverFailure ERROR ::= { CODE local:26 } targetCellOutsideGroupCallArea ERROR ::= { PARAMETER TargetCellOutsideGCA-Param -- optional CODE local:42 } -- operation and maintenance errors tracingBufferFull ERROR ::= { PARAMETER TracingBufferFullParam -- optional CODE local: 40 } -- call handling errors noRoamingNumberAvailable ERROR ::= { PARAMETER NoRoamingNbParam -- optional CODE local:39 } absentSubscriber ERROR ::= { PARAMETER AbsentSubscriberParam -- optional -- AbsentSubscriberParam must not be used in version <3 CODE local:27 } busySubscriber ERROR ::= { PARAMETER BusySubscriberParam -- optional CODE local:45 } noSubscriberReply ERROR ::= { PARAMETER NoSubscriberReplyParam -- optional CODE local:46 } callBarred ERROR ::= { PARAMETER CallBarredParam -- optional CODE local:13 } forwardingViolation ERROR ::= { PARAMETER ForwardingViolationParam -- optional CODE local:14 } forwardingFailed ERROR ::= { PARAMETER ForwardingFailedParam -- optional CODE local:47 } cug-Reject ERROR ::= { PARAMETER CUG-RejectParam -- optional CODE local:15 } or-NotAllowed ERROR ::= { PARAMETER OR-NotAllowedParam -- optional CODE local:48 } -- any time interrogation errors ati-NotAllowed ERROR ::= { PARAMETER ATI-NotAllowedParam -- optional CODE local:49 } -- any time information handling errors atsi-NotAllowed ERROR ::= { PARAMETER ATSI-NotAllowedParam -- optional CODE local:60 } atm-NotAllowed ERROR ::= { PARAMETER ATM-NotAllowedParam -- optional CODE local:61 } informationNotAvailable ERROR ::= { PARAMETER InformationNotAvailableParam -- optional CODE local:62 } -- supplementary service errors illegalSS-Operation ERROR ::= { PARAMETER IllegalSS-OperationParam -- optional -- IllegalSS-OperationParam must not be used in version <3 CODE local:16 } ss-ErrorStatus ERROR ::= { PARAMETER SS-Status -- optional CODE local:17 } ss-NotAvailable ERROR ::= { PARAMETER SS-NotAvailableParam -- optional -- SS-NotAvailableParam must not be used in version <3 CODE local:18 } ss-SubscriptionViolation ERROR ::= { PARAMETER SS-SubscriptionViolationParam -- optional -- SS-SubscriptionViolationParam must not be used in version <3 CODE local:19 } ss-Incompatibility ERROR ::= { PARAMETER SS-IncompatibilityCause -- optional CODE local:20 } unknownAlphabet ERROR ::= { CODE local:71 } ussd-Busy ERROR ::= { CODE local:72 } pw-RegistrationFailure ERROR ::= { PARAMETER PW-RegistrationFailureCause CODE local:37 } negativePW-Check ERROR ::= { CODE local:38 } numberOfPW-AttemptsViolation ERROR ::= { CODE local:43 } shortTermDenial ERROR ::= { PARAMETER ShortTermDenialParam -- optional CODE local:29 } longTermDenial ERROR ::= { PARAMETER LongTermDenialParam -- optional CODE local:30 } -- short message service errors subscriberBusyForMT-SMS ERROR ::= { PARAMETER SubBusyForMT-SMS-Param -- optional CODE local:31 } sm-DeliveryFailure ERROR ::= { PARAMETER SM-DeliveryFailureCause CODE local:32 } messageWaitingListFull ERROR ::= { PARAMETER MessageWaitListFullParam -- optional CODE local:33 } absentSubscriberSM ERROR ::= { PARAMETER AbsentSubscriberSM-Param -- optional CODE local:6 } -- Group Call errors noGroupCallNumberAvailable ERROR ::= { PARAMETER NoGroupCallNbParam -- optional CODE local:50 } ongoingGroupCall ERROR ::= { PARAMETER OngoingGroupCallParam -- optional CODE local:22 } -- location service errors unauthorizedRequestingNetwork ERROR ::= { PARAMETER UnauthorizedRequestingNetwork-Param -- optional CODE local:52 } unauthorizedLCSClient ERROR ::= { PARAMETER UnauthorizedLCSClient-Param -- optional CODE local:53 } positionMethodFailure ERROR ::= { PARAMETER PositionMethodFailure-Param -- optional CODE local:54 } unknownOrUnreachableLCSClient ERROR ::= { PARAMETER UnknownOrUnreachableLCSClient-Param -- optional CODE local:58 } mm-EventNotSupported ERROR ::= { PARAMETER MM-EventNotSupported-Param -- optional CODE local:59 } .#END 17.6.7 Group Call operations .$MAP-Group-Call-Operations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Group-Call-Operations (22) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS prepareGroupCall, sendGroupCallEndSignal, forwardGroupCallSignalling, processGroupCallSignalling, sendGroupCallInfo ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, unexpectedDataValue, noGroupCallNumberAvailable, ongoingGroupCall, unknownSubscriber, teleserviceNotProvisioned, dataMissing FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} PrepareGroupCallArg, PrepareGroupCallRes, SendGroupCallEndSignalArg, SendGroupCallEndSignalRes, ForwardGroupCallSignallingArg, ProcessGroupCallSignallingArg, SendGroupCallInfoArg, SendGroupCallInfoRes FROM MAP-GR-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-GR-DataTypes (23) version20 (20)} ; prepareGroupCall OPERATION ::= { --Timer m ARGUMENT PrepareGroupCallArg RESULT PrepareGroupCallRes ERRORS { systemFailure | noGroupCallNumberAvailable | unexpectedDataValue} CODE local:39 } sendGroupCallEndSignal OPERATION ::= { --Timer l ARGUMENT SendGroupCallEndSignalArg RESULT SendGroupCallEndSignalRes CODE local:40 } processGroupCallSignalling OPERATION ::= { --Timer s ARGUMENT ProcessGroupCallSignallingArg CODE local:41 } forwardGroupCallSignalling OPERATION ::= { --Timer s ARGUMENT ForwardGroupCallSignallingArg CODE local:42 } sendGroupCallInfo OPERATION ::= { --Timer m ARGUMENT SendGroupCallInfoArg RESULT SendGroupCallInfoRes ERRORS { systemFailure | ongoingGroupCall | unexpectedDataValue | dataMissing | teleserviceNotProvisioned | unknownSubscriber} CODE local:84 } .#END 17.6.8 Location service operations .$MAP-LocationServiceOperations { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-LocationServiceOperations (24) version20 (20)} DEFINITIONS ::= BEGIN EXPORTS provideSubscriberLocation, sendRoutingInfoForLCS, subscriberLocationReport ; IMPORTS OPERATION FROM Remote-Operations-Information-Objects { joint-iso-itu-t remote-operations(4) informationObjects(5) version1(0)} systemFailure, dataMissing, unexpectedDataValue, facilityNotSupported, unknownSubscriber, absentSubscriber, unauthorizedRequestingNetwork, unauthorizedLCSClient, positionMethodFailure, resourceLimitation, unknownOrUnreachableLCSClient, unidentifiedSubscriber, illegalEquipment, illegalSubscriber FROM MAP-Errors { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-Errors (10) version20 (20)} RoutingInfoForLCS-Arg, RoutingInfoForLCS-Res, ProvideSubscriberLocation-Arg, ProvideSubscriberLocation-Res, SubscriberLocationReport-Arg, SubscriberLocationReport-Res FROM MAP-LCS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-LCS-DataTypes (25) version20 (20)} ; sendRoutingInfoForLCS OPERATION ::= { --Timer m ARGUMENT RoutingInfoForLCS-Arg RESULT RoutingInfoForLCS-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unknownSubscriber | absentSubscriber | unauthorizedRequestingNetwork } CODE local:85 } provideSubscriberLocation OPERATION ::= { --Timer ml ARGUMENT ProvideSubscriberLocation-Arg RESULT ProvideSubscriberLocation-Res ERRORS { systemFailure | dataMissing | unexpectedDataValue | facilityNotSupported | unidentifiedSubscriber | illegalSubscriber | illegalEquipment | absentSubscriber | unauthorizedRequestingNetwork | unauthorizedLCSClient | positionMethodFailure } CODE local:83 } subscriberLocationReport OPERATION ::= { --Timer m ARGUMENT SubscriberLocationReport-Arg RESULT SubscriberLocationReport-Res ERRORS { systemFailure | dataMissing | resourceLimitation | unexpectedDataValue | unknownSubscriber | unauthorizedRequestingNetwork | unknownOrUnreachableLCSClient} CODE local:86 } .#END 17.6.9 Void 17.7 MAP constants and data types 17.7.1 Mobile Service data types .$MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS -- location registration types UpdateLocationArg, UpdateLocationRes, CancelLocationArg, CancelLocationRes, PurgeMS-Arg, PurgeMS-Res, SendIdentificationArg, SendIdentificationRes, UpdateGprsLocationArg, UpdateGprsLocationRes, IST-SupportIndicator, SupportedLCS-CapabilitySets, UpdateVcsgLocationArg, UpdateVcsgLocationRes, CancelVcsgLocationArg, CancelVcsgLocationRes, -- handover types ForwardAccessSignalling-Arg, PrepareHO-Arg, PrepareHO-Res, PrepareSubsequentHO-Arg, PrepareSubsequentHO-Res, ProcessAccessSignalling-Arg, SendEndSignal-Arg, SendEndSignal-Res, -- authentication management types SendAuthenticationInfoArg, SendAuthenticationInfoRes, AuthenticationFailureReportArg, AuthenticationFailureReportRes, -- security management types Kc, Cksn, -- equipment management types CheckIMEI-Arg, CheckIMEI-Res, -- subscriber management types InsertSubscriberDataArg, InsertSubscriberDataRes, LSAIdentity, DeleteSubscriberDataArg, DeleteSubscriberDataRes, Ext-QoS-Subscribed, Ext2-QoS-Subscribed, Ext3-QoS-Subscribed, Ext4-QoS-Subscribed, SubscriberData, ODB-Data, SubscriberStatus, ZoneCodeList, maxNumOfZoneCodes, O-CSI, D-CSI, O-BcsmCamelTDPCriteriaList, T-BCSM-CAMEL-TDP-CriteriaList, SS-CSI, ServiceKey, DefaultCallHandling, DefaultSMS-Handling, DefaultGPRS-Handling, CamelCapabilityHandling, BasicServiceCriteria, SupportedCamelPhases, OfferedCamel4CSIs, OfferedCamel4Functionalities, maxNumOfCamelTDPData, CUG-Index, CUG-Info, CUG-Interlock, InterCUG-Restrictions, IntraCUG-Options, NotificationToMSUser, QoS-Subscribed, IST-AlertTimerValue, T-CSI, T-BcsmTriggerDetectionPoint, APN, AdditionalInfo, -- fault recovery types ResetArg, RestoreDataArg, RestoreDataRes, -- provide subscriber info types GeographicalInformation, MS-Classmark2, GPRSMSClass, -- subscriber information enquiry types ProvideSubscriberInfoArg, ProvideSubscriberInfoRes, SubscriberInfo, LocationInformation, LocationInformationGPRS, SubscriberState, GPRSChargingID, MNPInfoRes, RouteingNumber, -- any time information enquiry types AnyTimeInterrogationArg, AnyTimeInterrogationRes, -- any time information handling types AnyTimeSubscriptionInterrogationArg, AnyTimeSubscriptionInterrogationRes, AnyTimeModificationArg, AnyTimeModificationRes, -- subscriber data modification notification types NoteSubscriberDataModifiedArg, NoteSubscriberDataModifiedRes, -- gprs location information retrieval types SendRoutingInfoForGprsArg, SendRoutingInfoForGprsRes, -- failure reporting types FailureReportArg, FailureReportRes, -- gprs notification types NoteMsPresentForGprsArg, NoteMsPresentForGprsRes, -- Mobility Management types NoteMM-EventArg, NoteMM-EventRes, NumberPortabilityStatus, PagingArea, -- VGCS / VBS types types GroupId, Long-GroupId, AdditionalSubscriptions ; IMPORTS maxNumOfSS, SS-SubscriptionOption, SS-List, SS-ForBS-Code, Password, OverrideCategory, CliRestrictionOption FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} Ext-BearerServiceCode FROM MAP-BS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-BS-Code (20) version20 (20)} Ext-TeleserviceCode FROM MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-TS-Code (19) version20 (20)} AddressString, ISDN-AddressString, ISDN-SubaddressString, FTN-AddressString, AccessNetworkSignalInfo, IMSI, IMEI, TMSI, HLR-List, LMSI, Identity, GlobalCellId, CellGlobalIdOrServiceAreaIdOrLAI, Ext-BasicServiceCode, NAEA-PreferredCI, EMLPP-Info, MC-SS-Info, SubscriberIdentity, AgeOfLocationInformation, LCSClientExternalID, LCSClientInternalID, Ext-SS-Status, LCSServiceTypeID, ASCI-CallReference, TBCD-STRING, LAIFixedLength, PLMN-Id, EMLPP-Priority, GSN-Address, DiameterIdentity, Time, E-UTRAN-CGI, NR-CGI, TA-Id, NR-TA-Id, RAIdentity, NetworkNodeDiameterAddress FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} AbsentSubscriberDiagnosticSM FROM MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version20 (20)} TracePropagationList FROM MAP-OM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OM-DataTypes (12) version20 (20)} ; -- location registration types UpdateLocationArg ::= SEQUENCE { imsi IMSI, msc-Number [1] ISDN-AddressString, vlr-Number ISDN-AddressString, lmsi [10] LMSI OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , vlr-Capability [6] VLR-Capability OPTIONAL, informPreviousNetworkEntity [11] NULL OPTIONAL, cs-LCS-NotSupportedByUE [12] NULL OPTIONAL, v-gmlc-Address [2] GSN-Address OPTIONAL, add-info [13] ADD-Info OPTIONAL, pagingArea [14] PagingArea OPTIONAL, skipSubscriberDataUpdate [15] NULL OPTIONAL, -- The skipSubscriberDataUpdate parameter in the UpdateLocationArg and the ADD-Info -- structures carry the same semantic. restorationIndicator [16] NULL OPTIONAL, eplmn-List [3] EPLMN-List OPTIONAL, mme-DiameterAddress [4] NetworkNodeDiameterAddress OPTIONAL } VLR-Capability ::= SEQUENCE{ supportedCamelPhases [0] SupportedCamelPhases OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , solsaSupportIndicator [2] NULL OPTIONAL, istSupportIndicator [1] IST-SupportIndicator OPTIONAL, superChargerSupportedInServingNetworkEntity [3] SuperChargerInfo OPTIONAL, longFTN-Supported [4] NULL OPTIONAL, supportedLCS-CapabilitySets [5] SupportedLCS-CapabilitySets OPTIONAL, offeredCamel4CSIs [6] OfferedCamel4CSIs OPTIONAL, supportedRAT-TypesIndicator [7] SupportedRAT-Types OPTIONAL, longGroupID-Supported [8] NULL OPTIONAL, mtRoamingForwardingSupported [9] NULL OPTIONAL, msisdn-lessOperation-Supported [10] NULL OPTIONAL, reset-ids-Supported [11] NULL OPTIONAL } SupportedRAT-Types::= BIT STRING { utran (0), geran (1), gan (2), i-hspa-evolution (3), e-utran (4), nb-iot (5)} (SIZE (2..8)) -- exception handling: bits 6 to 7 shall be ignored if received and not understood SuperChargerInfo ::= CHOICE { sendSubscriberData [0] NULL, subscriberDataStored [1] AgeIndicator } AgeIndicator ::= OCTET STRING (SIZE (1..6)) -- The internal structure of this parameter is implementation specific. IST-SupportIndicator ::= ENUMERATED { basicISTSupported (0), istCommandSupported (1), ...} -- exception handling: -- reception of values > 1 shall be mapped to ' istCommandSupported ' SupportedLCS-CapabilitySets ::= BIT STRING { lcsCapabilitySet1 (0), lcsCapabilitySet2 (1), lcsCapabilitySet3 (2), lcsCapabilitySet4 (3) , lcsCapabilitySet5 (4) } (SIZE (2..16)) -- Core network signalling capability set1 indicates LCS Release98 or Release99 version. -- Core network signalling capability set2 indicates LCS Release4. -- Core network signalling capability set3 indicates LCS Release5. -- Core network signalling capability set4 indicates LCS Release6. -- Core network signalling capability set5 indicates LCS Release7 or later version. -- A node shall mark in the BIT STRING all LCS capability sets it supports. -- If no bit is set then the sending node does not support LCS. -- If the parameter is not sent by an VLR then the VLR may support at most capability set1. -- If the parameter is not sent by an SGSN then no support for LCS is assumed. -- An SGSN is not allowed to indicate support of capability set1. -- Other bits than listed above shall be discarded. UpdateLocationRes ::= SEQUENCE { hlr-Number ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ..., add-Capability NULL OPTIONAL, pagingArea-Capability [0]NULL OPTIONAL } ADD-Info ::= SEQUENCE { imeisv [0] IMEI, skipSubscriberDataUpdate [1] NULL OPTIONAL, -- The skipSubscriberDataUpdate parameter in the UpdateLocationArg and the ADD-Info -- structures carry the same semantic. ...} PagingArea ::= SEQUENCE SIZE (1..5) OF LocationArea LocationArea ::= CHOICE { laiFixedLength [0] LAIFixedLength, lac [1] LAC} LAC ::= OCTET STRING (SIZE (2)) -- Refers to Location Area Code of the Location Area Identification defined in -- 3GPP TS 23.003 [17]. -- Location Area Code according to 3GPP TS 24.008 [35] CancelLocationArg ::= [3] SEQUENCE { identity Identity, cancellationType CancellationType OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., typeOfUpdate [0] TypeOfUpdate OPTIONAL, mtrf-SupportedAndAuthorized [1] NULL OPTIONAL, mtrf-SupportedAndNotAuthorized [2] NULL OPTIONAL, newMSC-Number [3] ISDN-AddressString OPTIONAL, newVLR-Number [4] ISDN-AddressString OPTIONAL, new-lmsi [5] LMSI OPTIONAL, reattach-Required [6] NULL OPTIONAL } --mtrf-SupportedAndAuthorized and mtrf-SupportedAndNotAuthorized shall not -- both be present TypeOfUpdate ::= ENUMERATED { sgsn-change (0), mme-change (1), ...} -- TypeOfUpdate shall be absent if CancellationType is different from updateProcedure -- and initialAttachProcedure CancellationType ::= ENUMERATED { updateProcedure (0), subscriptionWithdraw (1), ..., initialAttachProcedure (2)} -- The HLR shall not send values other than listed above CancelLocationRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} PurgeMS-Arg ::= [3] SEQUENCE { imsi IMSI, vlr-Number [0] ISDN-AddressString OPTIONAL, sgsn-Number [1] ISDN-AddressString OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., locationInformation [2] LocationInformation OPTIONAL, locationInformationGPRS [3] LocationInformationGPRS OPTIONAL, locationInformationEPS [4] LocationInformationEPS OPTIONAL } PurgeMS-Res ::= SEQUENCE { freezeTMSI [0] NULL OPTIONAL, freezeP-TMSI [1] NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., freezeM-TMSI [2] NULL OPTIONAL } SendIdentificationArg ::= SEQUENCE { tmsi TMSI, numberOfRequestedVectors NumberOfRequestedVectors OPTIONAL, -- within a dialogue numberOfRequestedVectors shall be present in -- the first service request and shall not be present in subsequent service requests. -- If received in a subsequent service request it shall be discarded. segmentationProhibited NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., msc-Number ISDN-AddressString OPTIONAL, previous-LAI [0] LAIFixedLength OPTIONAL, hopCounter [1] HopCounter OPTIONAL, mtRoamingForwardingSupported [2] NULL OPTIONAL, newVLR-Number [3] ISDN-AddressString OPTIONAL, new-lmsi [4] LMSI OPTIONAL } HopCounter ::= INTEGER (0..3) SendIdentificationRes ::= [3] SEQUENCE { imsi IMSI OPTIONAL, -- IMSI shall be present in the first (or only) service response of a dialogue. -- If multiple service requests are present in a dialogue then IMSI -- shall not be present in any service response other than the first one. authenticationSetList AuthenticationSetList OPTIONAL, currentSecurityContext [2]CurrentSecurityContext OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ..., lastUsedLtePLMN-Id [4] PLMN-Id OPTIONAL, mtCallPendingFlag [5] NULL OPTIONAL } -- authentication management types AuthenticationSetList ::= CHOICE { tripletList [0] TripletList, quintupletList [1] QuintupletList } TripletList ::= SEQUENCE SIZE (1..5) OF AuthenticationTriplet QuintupletList ::= SEQUENCE SIZE (1..5) OF AuthenticationQuintuplet AuthenticationTriplet ::= SEQUENCE { rand RAND, sres SRES, kc Kc, ...} AuthenticationQuintuplet ::= SEQUENCE { rand RAND, xres XRES, ck CK, ik IK, autn AUTN, ...} CurrentSecurityContext ::= CHOICE { gsm-SecurityContextData [0] GSM-SecurityContextData, umts-SecurityContextData [1] UMTS-SecurityContextData } GSM-SecurityContextData ::= SEQUENCE { kc Kc, cksn Cksn, ... } UMTS-SecurityContextData ::= SEQUENCE { ck CK, ik IK, ksi KSI, ... } RAND ::= OCTET STRING (SIZE (16)) SRES ::= OCTET STRING (SIZE (4)) Kc ::= OCTET STRING (SIZE (8)) XRES ::= OCTET STRING (SIZE (4..16)) CK ::= OCTET STRING (SIZE (16)) IK ::= OCTET STRING (SIZE (16)) AUTN ::= OCTET STRING (SIZE (16)) AUTS ::= OCTET STRING (SIZE (14)) Cksn ::= OCTET STRING (SIZE (1)) -- The internal structure is defined in 3GPP TS 24.008 KSI ::= OCTET STRING (SIZE (1)) -- The internal structure is defined in 3GPP TS 24.008 AuthenticationFailureReportArg ::= SEQUENCE { imsi IMSI, failureCause FailureCause, extensionContainer ExtensionContainer OPTIONAL, ... , re-attempt BOOLEAN OPTIONAL, accessType AccessType OPTIONAL, rand RAND OPTIONAL, vlr-Number [0] ISDN-AddressString OPTIONAL, sgsn-Number [1] ISDN-AddressString OPTIONAL } AccessType ::= ENUMERATED { call (0), emergencyCall (1), locationUpdating (2), supplementaryService (3), shortMessage (4), gprsAttach (5), routingAreaUpdating (6), serviceRequest (7), pdpContextActivation (8), pdpContextDeactivation (9), ..., gprsDetach (10)} -- exception handling: -- received values greater than 10 shall be ignored. AuthenticationFailureReportRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} FailureCause ::= ENUMERATED { wrongUserResponse (0), wrongNetworkSignature (1)} -- gprs location registration types UpdateGprsLocationArg ::= SEQUENCE { imsi IMSI, sgsn-Number ISDN-AddressString, sgsn-Address GSN-Address, extensionContainer ExtensionContainer OPTIONAL, ... , sgsn-Capability [0] SGSN-Capability OPTIONAL, informPreviousNetworkEntity [1] NULL OPTIONAL, ps-LCS-NotSupportedByUE [2] NULL OPTIONAL, v-gmlc-Address [3] GSN-Address OPTIONAL, add-info [4] ADD-Info OPTIONAL, eps-info [5] EPS-Info OPTIONAL, servingNodeTypeIndicator [6] NULL OPTIONAL, skipSubscriberDataUpdate [7] NULL OPTIONAL, usedRAT-Type [8] Used-RAT-Type OPTIONAL, gprsSubscriptionDataNotNeeded [9] NULL OPTIONAL, nodeTypeIndicator [10] NULL OPTIONAL, areaRestricted [11] NULL OPTIONAL, ue-reachableIndicator [12] NULL OPTIONAL, epsSubscriptionDataNotNeeded [13] NULL OPTIONAL, ue-srvcc-Capability [14] UE-SRVCC-Capability OPTIONAL, eplmn-List [15] EPLMN-List OPTIONAL, mmeNumberforMTSMS [16] ISDN-AddressString OPTIONAL, smsRegisterRequest [17] SMSRegisterRequest OPTIONAL, sms-Only [18] NULL OPTIONAL, removalofMMERegistrationforSMS [22] NULL OPTIONAL, sgsn-Name [19] DiameterIdentity OPTIONAL, sgsn-Realm [20] DiameterIdentity OPTIONAL, lgd-supportIndicator [21] NULL OPTIONAL, adjacentPLMN-List [23] AdjacentPLMN-List OPTIONAL } SMSRegisterRequest::= ENUMERATED { sms-registration-required (0), sms-registration-not-preferred (1), no-preference (2), ...} Used-RAT-Type::= ENUMERATED { utran (0), geran (1), gan (2), i-hspa-evolution (3), e-utran (4), ..., nb-iot (5)} -- The value e-utran indicates wide-band e-utran EPS-Info ::= CHOICE{ pdn-gw-update [0] PDN-GW-Update, isr-Information [1] ISR-Information } PDN-GW-Update ::= SEQUENCE{ apn [0] APN OPTIONAL, pdn-gw-Identity [1] PDN-GW-Identity OPTIONAL, contextId [2] ContextId OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ... } -- The pdn-gw-update IE shall include the pdn-gw-Identity, and the apn or/and the contextID. -- The HSS shall ignore the eps-info IE if it includes a pdn-gw-update IE which does not -- include pdn-gw-Identity. -- The pdn-gw-Identity is defined as OPTIONAL for backward compatility reason with -- outdated earlier versions of this specification. ISR-Information::= BIT STRING { updateLocation (0), cancelSGSN (1), initialAttachIndicator (2)} (SIZE (3..8)) -- exception handling: reception of unknown bit assignments in the -- ISR-Information data type shall be discarded by the receiver SGSN-Capability ::= SEQUENCE{ solsaSupportIndicator NULL OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... , superChargerSupportedInServingNetworkEntity [2] SuperChargerInfo OPTIONAL , gprsEnhancementsSupportIndicator [3] NULL OPTIONAL, supportedCamelPhases [4] SupportedCamelPhases OPTIONAL, supportedLCS-CapabilitySets [5] SupportedLCS-CapabilitySets OPTIONAL, offeredCamel4CSIs [6] OfferedCamel4CSIs OPTIONAL, smsCallBarringSupportIndicator [7] NULL OPTIONAL, supportedRAT-TypesIndicator [8] SupportedRAT-Types OPTIONAL, supportedFeatures [9] SupportedFeatures OPTIONAL, t-adsDataRetrieval [10] NULL OPTIONAL, homogeneousSupportOfIMSVoiceOverPSSessions [11] BOOLEAN OPTIONAL, -- ""true"" indicates homogeneous support, ""false"" indicates homogeneous non-support -- in the complete SGSN or MME area cancellationTypeInitialAttach [12] NULL OPTIONAL, msisdn-lessOperation-Supported [14] NULL OPTIONAL, updateofHomogeneousSupportOfIMSVoiceOverPSSessions [15] NULL OPTIONAL, reset-ids-Supported [16] NULL OPTIONAL, ext-SupportedFeatures [17] Ext-SupportedFeatures OPTIONAL } -- the supportedFeatures , t-adsDataRetrieval, -- homogeneousSupportOfIMSVoiceOverPSSessions -- /updateofHomogeneousSupportOfIMSVoiceOverPSSessions and -- ext-SupportedFeatures are also applied to the MME/IWF SupportedFeatures::= BIT STRING { odb-all-apn (0), odb-HPLMN-APN (1), odb-VPLMN-APN (2), odb-all-og (3), odb-all-international-og (4), odb-all-int-og-not-to-HPLMN-country (5), odb-all-interzonal-og (6), odb-all-interzonal-og-not-to-HPLMN-country (7), odb-all-interzonal-og-and-internat-og-not-to-HPLMN-country (8), regSub (9), trace (10), lcs-all-PrivExcep (11), lcs-universal (12), lcs-CallSessionRelated (13), lcs-CallSessionUnrelated (14), lcs-PLMN-operator (15), lcs-ServiceType (16), lcs-all-MOLR-SS (17), lcs-basicSelfLocation (18), lcs-autonomousSelfLocation (19), lcs-transferToThirdParty (20), sm-mo-pp (21), barring-OutgoingCalls (22), baoc (23), boic (24), boicExHC (25), localTimeZoneRetrieval (26), additionalMsisdn (27), smsInMME (28), smsInSGSN (29), ue-Reachability-Notification (30), state-Location-Information-Retrieval (31), partialPurge (32), gddInSGSN (33), sgsnCAMELCapability (34), pcscf-Restoration (35), dedicatedCoreNetworks (36), non-IP-PDN-Type-APNs (37), non-IP-PDP-Type-APNs (38), nrAsSecondaryRAT (39) } (SIZE (26..40)) -- for the definition and usage of the above features see the 3GPP TS 29.272 [144]. -- Additional supported features are encoded in Ext-SupportedFeatures bit string. Ext-SupportedFeatures ::= BIT STRING { unlicensedSpectrumAsSecondaryRAT (0) } (SIZE (1..40)) UE-SRVCC-Capability::= ENUMERATED { ue-srvcc-not-supported (0), ue-srvcc-supported (1), ...} UpdateGprsLocationRes ::= SEQUENCE { hlr-Number ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ..., add-Capability NULL OPTIONAL, sgsn-mmeSeparationSupported [0] NULL OPTIONAL, mmeRegisteredforSMS [1] NULL OPTIONAL } EPLMN-List ::= SEQUENCE SIZE (1..50) OF PLMN-Id AdjacentPLMN-List ::= SEQUENCE SIZE (1..50) OF PLMN-Id -- handover types ForwardAccessSignalling-Arg ::= [3] SEQUENCE { an-APDU AccessNetworkSignalInfo, integrityProtectionInfo [0] IntegrityProtectionInformation OPTIONAL, encryptionInfo [1] EncryptionInformation OPTIONAL, keyStatus [2] KeyStatus OPTIONAL, allowedGSM-Algorithms [4] AllowedGSM-Algorithms OPTIONAL, allowedUMTS-Algorithms [5] AllowedUMTS-Algorithms OPTIONAL, radioResourceInformation [6] RadioResourceInformation OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ..., radioResourceList [7] RadioResourceList OPTIONAL, bssmap-ServiceHandover [9] BSSMAP-ServiceHandover OPTIONAL, ranap-ServiceHandover [8] RANAP-ServiceHandover OPTIONAL, bssmap-ServiceHandoverList [10] BSSMAP-ServiceHandoverList OPTIONAL, currentlyUsedCodec [11] Codec OPTIONAL, iuSupportedCodecsList [12] SupportedCodecsList OPTIONAL, rab-ConfigurationIndicator [13] NULL OPTIONAL, iuSelectedCodec [14] Codec OPTIONAL, alternativeChannelType [15] RadioResourceInformation OPTIONAL, tracePropagationList [17] TracePropagationList OPTIONAL, aoipSupportedCodecsListAnchor [18] AoIPCodecsList OPTIONAL, aoipSelectedCodecTarget [19] AoIPCodec OPTIONAL, uesbi-Iu [20] UESBI-Iu OPTIONAL, imeisv [21] IMEI OPTIONAL } AllowedGSM-Algorithms ::= OCTET STRING (SIZE (1)) -- internal structure is coded as Algorithm identifier octet from -- Permitted Algorithms defined in 3GPP TS 48.008 -- A node shall mark all GSM algorithms that are allowed in MSC-B AllowedUMTS-Algorithms ::= SEQUENCE { integrityProtectionAlgorithms [0] PermittedIntegrityProtectionAlgorithms OPTIONAL, encryptionAlgorithms [1] PermittedEncryptionAlgorithms OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} PermittedIntegrityProtectionAlgorithms ::= OCTET STRING (SIZE (1..maxPermittedIntegrityProtectionAlgorithmsLength)) -- Octets contain a complete PermittedIntegrityProtectionAlgorithms data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413. -- Padding bits are included, if needed, in the least significant bits of the -- last octet of the octet string. maxPermittedIntegrityProtectionAlgorithmsLength INTEGER ::= 9 PermittedEncryptionAlgorithms ::= OCTET STRING (SIZE (1..maxPermittedEncryptionAlgorithmsLength)) -- Octets contain a complete PermittedEncryptionAlgorithms data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included, if needed, in the least significant bits of the -- last octet of the octet string. maxPermittedEncryptionAlgorithmsLength INTEGER ::= 9 KeyStatus ::= ENUMERATED { old (0), new (1), ...} -- exception handling: -- received values in range 2-31 shall be treated as ""old"" -- received values greater than 31 shall be treated as ""new"" PrepareHO-Arg ::= [3] SEQUENCE { targetCellId [0] GlobalCellId OPTIONAL, ho-NumberNotRequired NULL OPTIONAL, targetRNCId [1] RNCId OPTIONAL, an-APDU [2] AccessNetworkSignalInfo OPTIONAL, multipleBearerRequested [3] NULL OPTIONAL, imsi [4] IMSI OPTIONAL, integrityProtectionInfo [5] IntegrityProtectionInformation OPTIONAL, encryptionInfo [6] EncryptionInformation OPTIONAL, radioResourceInformation [7] RadioResourceInformation OPTIONAL, allowedGSM-Algorithms [9] AllowedGSM-Algorithms OPTIONAL, allowedUMTS-Algorithms [10] AllowedUMTS-Algorithms OPTIONAL, radioResourceList [11] RadioResourceList OPTIONAL, extensionContainer [8] ExtensionContainer OPTIONAL, ... , rab-Id [12] RAB-Id OPTIONAL, bssmap-ServiceHandover [13] BSSMAP-ServiceHandover OPTIONAL, ranap-ServiceHandover [14] RANAP-ServiceHandover OPTIONAL, bssmap-ServiceHandoverList [15] BSSMAP-ServiceHandoverList OPTIONAL, asciCallReference [20] ASCI-CallReference OPTIONAL, geran-classmark [16] GERAN-Classmark OPTIONAL, iuCurrentlyUsedCodec [17] Codec OPTIONAL, iuSupportedCodecsList [18] SupportedCodecsList OPTIONAL, rab-ConfigurationIndicator [19] NULL OPTIONAL, uesbi-Iu [21] UESBI-Iu OPTIONAL, imeisv [22] IMEI OPTIONAL, alternativeChannelType [23] RadioResourceInformation OPTIONAL, tracePropagationList [25] TracePropagationList OPTIONAL, aoipSupportedCodecsListAnchor [26] AoIPCodecsList OPTIONAL, regionalSubscriptionData [27] ZoneCodeList OPTIONAL, lclsGlobalCallReference [28] LCLS-GlobalCallReference OPTIONAL, lcls-Negotiation [29] LCLS-Negotiation OPTIONAL, lcls-Configuration-Preference [30] LCLS-ConfigurationPreference OPTIONAL, csg-SubscriptionDataList [31] CSG-SubscriptionDataList OPTIONAL } LCLS-GlobalCallReference ::= OCTET STRING (SIZE (13..15)) -- Octets are coded as specified in 3GPP TS 29.205 [146] LCLS-Negotiation::= BIT STRING { permission-indicator-not-allowed-bit (0), permission-indicator-spare-bit (1)} (SIZE (2..8)) --for definition and allowed combination of bits 0 and 1 see 3GPP TS 29.205 -- exception handling: bits 2 to 7 shall be ignored if received and not understood LCLS-ConfigurationPreference::= BIT STRING { forward-data-sending-indicator (0), backward-data-sending-indicator (1), forward-data-reception-indicator (2), backward-data-reception-indicator (3)} (SIZE (4..8)) -- exception handling: bits 4 to 7 shall be ignored if received and not understood BSSMAP-ServiceHandoverList ::= SEQUENCE SIZE (1.. maxNumOfServiceHandovers) OF BSSMAP-ServiceHandoverInfo BSSMAP-ServiceHandoverInfo ::= SEQUENCE { bssmap-ServiceHandover BSSMAP-ServiceHandover, rab-Id RAB-Id, -- RAB Identity is needed to relate the service handovers with the radio access bearers. ...} maxNumOfServiceHandovers INTEGER ::= 7 BSSMAP-ServiceHandover ::= OCTET STRING (SIZE (1)) -- Octets are coded according the Service Handover information element in -- 3GPP TS 48.008. RANAP-ServiceHandover ::= OCTET STRING (SIZE (1)) -- Octet contains a complete Service-Handover data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included in the least significant bits. RadioResourceList ::= SEQUENCE SIZE (1.. maxNumOfRadioResources) OF RadioResource RadioResource ::= SEQUENCE { radioResourceInformation RadioResourceInformation, rab-Id RAB-Id, -- RAB Identity is needed to relate the radio resources with the radio access bearers. ...} maxNumOfRadioResources INTEGER ::= 7 PrepareHO-Res ::= [3] SEQUENCE { handoverNumber [0] ISDN-AddressString OPTIONAL, relocationNumberList [1] RelocationNumberList OPTIONAL, an-APDU [2] AccessNetworkSignalInfo OPTIONAL, multicallBearerInfo [3] MulticallBearerInfo OPTIONAL, multipleBearerNotSupported NULL OPTIONAL, selectedUMTS-Algorithms [5] SelectedUMTS-Algorithms OPTIONAL, chosenRadioResourceInformation [6] ChosenRadioResourceInformation OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., iuSelectedCodec [7] Codec OPTIONAL, iuAvailableCodecsList [8] CodecList OPTIONAL, aoipSelectedCodecTarget [9] AoIPCodec OPTIONAL, aoipAvailableCodecsListMap [10] AoIPCodecsList OPTIONAL } SelectedUMTS-Algorithms ::= SEQUENCE { integrityProtectionAlgorithm [0] ChosenIntegrityProtectionAlgorithm OPTIONAL, encryptionAlgorithm [1] ChosenEncryptionAlgorithm OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} ChosenIntegrityProtectionAlgorithm ::= OCTET STRING (SIZE (1)) -- Octet contains a complete IntegrityProtectionAlgorithm data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included in the least significant bits. ChosenEncryptionAlgorithm ::= OCTET STRING (SIZE (1)) -- Octet contains a complete EncryptionAlgorithm data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included in the least significant bits."
"ChosenRadioResourceInformation ::= SEQUENCE { chosenChannelInfo [0] ChosenChannelInfo OPTIONAL, chosenSpeechVersion [1] ChosenSpeechVersion OPTIONAL, ...} ChosenChannelInfo ::= OCTET STRING (SIZE (1)) -- Octets are coded according the Chosen Channel information element in 3GPP TS 48.008 ChosenSpeechVersion ::= OCTET STRING (SIZE (1)) -- Octets are coded according the Speech Version (chosen) information element in 3GPP TS -- 48.008 PrepareSubsequentHO-Arg ::= [3] SEQUENCE { targetCellId [0] GlobalCellId OPTIONAL, targetMSC-Number [1] ISDN-AddressString, targetRNCId [2] RNCId OPTIONAL, an-APDU [3] AccessNetworkSignalInfo OPTIONAL, selectedRab-Id [4] RAB-Id OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ..., geran-classmark [6] GERAN-Classmark OPTIONAL, rab-ConfigurationIndicator [7] NULL OPTIONAL } PrepareSubsequentHO-Res ::= [3] SEQUENCE { an-APDU AccessNetworkSignalInfo, extensionContainer [0] ExtensionContainer OPTIONAL, ...} ProcessAccessSignalling-Arg ::= [3] SEQUENCE { an-APDU AccessNetworkSignalInfo, selectedUMTS-Algorithms [1] SelectedUMTS-Algorithms OPTIONAL, selectedGSM-Algorithm [2] SelectedGSM-Algorithm OPTIONAL, chosenRadioResourceInformation [3] ChosenRadioResourceInformation OPTIONAL, selectedRab-Id [4] RAB-Id OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ..., iUSelectedCodec [5] Codec OPTIONAL, iuAvailableCodecsList [6] CodecList OPTIONAL, aoipSelectedCodecTarget [7] AoIPCodec OPTIONAL, aoipAvailableCodecsListMap [8] AoIPCodecsList OPTIONAL } AoIPCodecsList ::= SEQUENCE { codec1 [1] AoIPCodec, codec2 [2] AoIPCodec OPTIONAL, codec3 [3] AoIPCodec OPTIONAL, codec4 [4] AoIPCodec OPTIONAL, codec5 [5] AoIPCodec OPTIONAL, codec6 [6] AoIPCodec OPTIONAL, codec7 [7] AoIPCodec OPTIONAL, codec8 [8] AoIPCodec OPTIONAL, extensionContainer [9] ExtensionContainer OPTIONAL, ...} -- Codecs are sent in priority order where codec1 has highest priority AoIPCodec ::= OCTET STRING (SIZE (1..3)) -- The internal structure is defined as follows: -- octet 1 Coded as Speech Codec Elements in 3GPP TS 48.008 -- with the exception that FI, PI, PT and TF bits shall -- be set to 0 -- octets 2,3 Optional; in case of AMR codec types it defines -- the supported codec configurations as defined in -- 3GPP TS 48.008 SupportedCodecsList ::= SEQUENCE { utranCodecList [0] CodecList OPTIONAL, geranCodecList [1] CodecList OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} CodecList ::= SEQUENCE { codec1 [1] Codec, codec2 [2] Codec OPTIONAL, codec3 [3] Codec OPTIONAL, codec4 [4] Codec OPTIONAL, codec5 [5] Codec OPTIONAL, codec6 [6] Codec OPTIONAL, codec7 [7] Codec OPTIONAL, codec8 [8] Codec OPTIONAL, extensionContainer [9] ExtensionContainer OPTIONAL, ...} -- Codecs are sent in priority order where codec1 has highest priority Codec ::= OCTET STRING (SIZE (1..4)) -- The internal structure is defined as follows: -- octet 1 Coded as Codec Identification code in 3GPP TS 26.103 -- octets 2,3,4 Parameters for the Codec as defined in 3GPP TS -- 26.103, if available, length depending on the codec GERAN-Classmark ::= OCTET STRING (SIZE (2..87)) -- Octets are coded according the GERAN Classmark information element in 3GPP TS 48.008 SelectedGSM-Algorithm ::= OCTET STRING (SIZE (1)) -- internal structure is coded as Algorithm identifier octet from Chosen Encryption -- Algorithm defined in 3GPP TS 48.008 -- A node shall mark only the selected GSM algorithm SendEndSignal-Arg ::= [3] SEQUENCE { an-APDU AccessNetworkSignalInfo, extensionContainer [0] ExtensionContainer OPTIONAL, ...} SendEndSignal-Res ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ...} RNCId ::= OCTET STRING (SIZE (7)) -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code according to 3GPP TS 24.008 -- octets 6 and 7 RNC Id or Extended RNC Id value according to -- 3GPP TS 25.413 RelocationNumberList ::= SEQUENCE SIZE (1..maxNumOfRelocationNumber) OF RelocationNumber MulticallBearerInfo ::= INTEGER (1..maxNumOfRelocationNumber) RelocationNumber ::= SEQUENCE { handoverNumber ISDN-AddressString, rab-Id RAB-Id, -- RAB Identity is needed to relate the calls with the radio access bearers. ...} RAB-Id ::= INTEGER (1..maxNrOfRABs) maxNrOfRABs INTEGER ::= 255 maxNumOfRelocationNumber INTEGER ::= 7 RadioResourceInformation ::= OCTET STRING (SIZE (3..13)) -- Octets are coded according the Channel Type information element in 3GPP TS 48.008 IntegrityProtectionInformation ::= OCTET STRING (SIZE (18..maxNumOfIntegrityInfo)) -- Octets contain a complete IntegrityProtectionInformation data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included, if needed, in the least significant bits of the -- last octet of the octet string. maxNumOfIntegrityInfo INTEGER ::= 100 EncryptionInformation ::= OCTET STRING (SIZE (18..maxNumOfEncryptionInfo)) -- Octets contain a complete EncryptionInformation data type -- as defined in 3GPP TS 25.413, encoded according to the encoding scheme -- mandated by 3GPP TS 25.413 -- Padding bits are included, if needed, in the least significant bits of the -- last octet of the octet string. maxNumOfEncryptionInfo INTEGER ::= 100 -- authentication management types SendAuthenticationInfoArg ::= SEQUENCE { imsi [0] IMSI, numberOfRequestedVectors NumberOfRequestedVectors, segmentationProhibited NULL OPTIONAL, immediateResponsePreferred [1] NULL OPTIONAL, re-synchronisationInfo Re-synchronisationInfo OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., requestingNodeType [3] RequestingNodeType OPTIONAL, requestingPLMN-Id [4] PLMN-Id OPTIONAL, numberOfRequestedAdditional-Vectors [5] NumberOfRequestedVectors OPTIONAL, additionalVectorsAreForEPS [6] NULL OPTIONAL, ueUsageTypeRequestIndication [7] NULL OPTIONAL } NumberOfRequestedVectors ::= INTEGER (1..5) Re-synchronisationInfo ::= SEQUENCE { rand RAND, auts AUTS, ...} SendAuthenticationInfoRes ::= [3] SEQUENCE { authenticationSetList AuthenticationSetList OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., eps-AuthenticationSetList [2] EPS-AuthenticationSetList OPTIONAL, ueUsageType [3] UE-UsageType OPTIONAL } EPS-AuthenticationSetList ::= SEQUENCE SIZE (1..5) OF EPC-AV UE-UsageType::= OCTET STRING (SIZE (4)) -- octets are coded as defined in 3GPP TS 29.272 [144] EPC-AV ::= SEQUENCE { rand RAND, xres XRES, autn AUTN, kasme KASME, extensionContainer ExtensionContainer OPTIONAL, ...} KASME ::= OCTET STRING (SIZE (32)) RequestingNodeType ::= ENUMERATED { vlr (0), sgsn (1), ..., s-cscf (2), bsf (3), gan-aaa-server (4), wlan-aaa-server (5), mme (16), mme-sgsn (17) } -- the values 2, 3, 4 and 5 shall not be used on the MAP-D or Gr interfaces -- exception handling: -- received values in the range (6-15) shall be treated as ""vlr"" -- received values greater than 17 shall be treated as ""sgsn"" -- equipment management types CheckIMEI-Arg ::= SEQUENCE { imei IMEI, requestedEquipmentInfo RequestedEquipmentInfo, extensionContainer ExtensionContainer OPTIONAL, ...} CheckIMEI-Res ::= SEQUENCE { equipmentStatus EquipmentStatus OPTIONAL, bmuef UESBI-Iu OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ...} RequestedEquipmentInfo::= BIT STRING { equipmentStatus (0), bmuef (1)} (SIZE (2..8)) -- exception handling: reception of unknown bit assignments in the -- RequestedEquipmentInfo data type shall be discarded by the receiver UESBI-Iu ::= SEQUENCE { uesbi-IuA [0] UESBI-IuA OPTIONAL, uesbi-IuB [1] UESBI-IuB OPTIONAL, ...} UESBI-IuA ::= BIT STRING (SIZE(1..128)) -- See 3GPP TS 25.413 UESBI-IuB ::= BIT STRING (SIZE(1..128)) -- See 3GPP TS 25.413 EquipmentStatus ::= ENUMERATED { permittedListed (0), prohibitedListed (1), trackingListed (2)} -- subscriber management types InsertSubscriberDataArg ::= SEQUENCE { imsi [0] IMSI OPTIONAL, COMPONENTS OF SubscriberData, extensionContainer [14] ExtensionContainer OPTIONAL, ... , naea-PreferredCI [15] NAEA-PreferredCI OPTIONAL, -- naea-PreferredCI is included at the discretion of the HLR operator. gprsSubscriptionData [16] GPRSSubscriptionData OPTIONAL, roamingRestrictedInSgsnDueToUnsupportedFeature [23] NULL OPTIONAL, networkAccessMode [24] NetworkAccessMode OPTIONAL, lsaInformation [25] LSAInformation OPTIONAL, lmu-Indicator [21] NULL OPTIONAL, lcsInformation [22] LCSInformation OPTIONAL, istAlertTimer [26] IST-AlertTimerValue OPTIONAL, superChargerSupportedInHLR [27] AgeIndicator OPTIONAL, mc-SS-Info [28] MC-SS-Info OPTIONAL, cs-AllocationRetentionPriority [29] CS-AllocationRetentionPriority OPTIONAL, sgsn-CAMEL-SubscriptionInfo [17] SGSN-CAMEL-SubscriptionInfo OPTIONAL, chargingCharacteristics [18] ChargingCharacteristics OPTIONAL, accessRestrictionData [19] AccessRestrictionData OPTIONAL, ics-Indicator [20] BOOLEAN OPTIONAL, eps-SubscriptionData [31] EPS-SubscriptionData OPTIONAL, csg-SubscriptionDataList [32] CSG-SubscriptionDataList OPTIONAL, ue-ReachabilityRequestIndicator [33] NULL OPTIONAL, sgsn-Number [34] ISDN-AddressString OPTIONAL, mme-Name [35] DiameterIdentity OPTIONAL, subscribedPeriodicRAUTAUtimer [36] SubscribedPeriodicRAUTAUtimer OPTIONAL, vplmnLIPAAllowed [37] NULL OPTIONAL, mdtUserConsent [38] BOOLEAN OPTIONAL, subscribedPeriodicLAUtimer [39] SubscribedPeriodicLAUtimer OPTIONAL, vplmn-Csg-SubscriptionDataList [40] VPLMN-CSG-SubscriptionDataList OPTIONAL, additionalMSISDN [41] ISDN-AddressString OPTIONAL, psAndSMS-OnlyServiceProvision [42] NULL OPTIONAL, smsInSGSNAllowed [43] NULL OPTIONAL, cs-to-ps-SRVCC-Allowed-Indicator [44] NULL OPTIONAL, pcscf-Restoration-Request [45] NULL OPTIONAL, adjacentAccessRestrictionDataList [46] AdjacentAccessRestrictionDataList OPTIONAL, imsi-Group-Id-List [47] IMSI-GroupIdList OPTIONAL, ueUsageType [48] UE-UsageType OPTIONAL, userPlaneIntegrityProtectionIndicator [49] NULL OPTIONAL, dl-Buffering-Suggested-Packet-Count [50] DL-Buffering-Suggested-Packet-Count OPTIONAL, reset-Id-List [51] Reset-Id-List OPTIONAL, eDRX-Cycle-Length-List [52] EDRX-Cycle-Length-List OPTIONAL, ext-AccessRestrictionData [53] Ext-AccessRestrictionData OPTIONAL, iab-Operation-Allowed-Indicator [54] NULL OPTIONAL } -- If the Network Access Mode parameter is sent, it shall be present only in -- the first sequence if seqmentation is used EDRX-Cycle-Length-List ::= SEQUENCE SIZE (1..8) OF EDRX-Cycle-Length EDRX-Cycle-Length ::= SEQUENCE { rat-Type [0] Used-RAT-Type, eDRX-Cycle-Length-Value [1] EDRX-Cycle-Length-Value, ...} -- The eDRX-Cycle-Length contains the subscribed eDRX-Cycle-Length applicable to a -- a specific RAT Type. EDRX-Cycle-Length-Value ::= OCTET STRING (SIZE (1)) -- The EDRX-Cycle-Length-Value shall be encoded as specified in clause 7.3.216 of -- 3GPPÊTSÊ29.272Ê[144]. Reset-Id-List ::= SEQUENCE SIZE (1..50) OF Reset-Id Reset-Id ::= OCTET STRING (SIZE (1..4)) -- Reset-Ids shall be unique within the HPLMN. DL-Buffering-Suggested-Packet-Count ::= INTEGER (-1..2147483647) -- values are defined in 3GPP TS 29.272 [144] Group-Service-ID ::= INTEGER (0..4294967295) -- values are defined in 3GPP TS 29.272 [144] Local-GroupID ::= OCTET STRING (SIZE (1..10)) -- Refers to Local group ID defined by an operator identified by the PLMN-ID. -- for details see 3GPP TS 29.272 [144] IMSI-GroupIdList ::= SEQUENCE SIZE (1..50) OF IMSI-GroupId IMSI-GroupId ::= SEQUENCE { group-Service-Id [0] Group-Service-ID, plmnId [1] PLMN-Id, local-Group-ID [2] Local-GroupID, ...} SubscribedPeriodicRAUTAUtimer ::= INTEGER (0..4294967295) -- This parameter carries the subscribed periodic TAU/RAU timer value in seconds as -- specified in 3GPP TS 24.008 [35]. SubscribedPeriodicLAUtimer ::= INTEGER (0..4294967295) -- This parameter carries the subscribed periodic LAU timer value in seconds as -- specified in 3GPP TS 24.008 [35]. CSG-SubscriptionDataList ::= SEQUENCE SIZE (1..50) OF CSG-SubscriptionData CSG-SubscriptionData ::= SEQUENCE { csg-Id CSG-Id, expirationDate Time OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., lipa-AllowedAPNList [0] LIPA-AllowedAPNList OPTIONAL, plmn-Id [1] PLMN-Id OPTIONAL } VPLMN-CSG-SubscriptionDataList ::= SEQUENCE SIZE (1..50) OF CSG-SubscriptionData CSG-Id ::= BIT STRING (SIZE (27)) -- coded according to 3GPP TS 23.003 [17]. LIPA-AllowedAPNList ::= SEQUENCE SIZE (1..maxNumOfLIPAAllowedAPN) OF APN maxNumOfLIPAAllowedAPN INTEGER ::= 50 EPS-SubscriptionData ::= SEQUENCE { apn-oi-Replacement [0] APN-OI-Replacement OPTIONAL, -- this apn-oi-Replacement refers to the UE level apn-oi-Replacement. rfsp-id [2] RFSP-ID OPTIONAL, ambr [3] AMBR OPTIONAL, apn-ConfigurationProfile [4] APN-ConfigurationProfile OPTIONAL, stn-sr [6] ISDN-AddressString OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ..., mps-CSPriority [7] NULL OPTIONAL, mps-EPSPriority [8] NULL OPTIONAL, subscribed-vsrvcc [9] NULL OPTIONAL } -- mps-CSPriority by its presence indicates that the UE is subscribed to the eMLPP in -- the CS domain, referring to the 3GPP TS 29.272 [144] for details. -- mps-EPSPriority by its presence indicates that the UE is subscribed to the MPS in -- the EPS domain, referring to the 3GPP TS 29.272 [144] for details. -- -- subscribed-vsrvcc by its presence indicates that the UE is subscribed to the vSRVCC in -- the EPS domain, referring to the 3GPP TS 29.272 [144] for details. APN-OI-Replacement ::= OCTET STRING (SIZE (9..100)) -- Octets are coded as APN Operator Identifier according to TS 3GPP TS 23.003 [17] RFSP-ID ::= INTEGER (1..256) APN-ConfigurationProfile ::= SEQUENCE { defaultContext ContextId, completeDataListIncluded NULL OPTIONAL, -- If segmentation is used, completeDataListIncluded may only be present in the -- first segment of APN-ConfigurationProfile. epsDataList [1] EPS-DataList, extensionContainer [2] ExtensionContainer OPTIONAL, ... , additionalDefaultContext [3] ContextId OPTIONAL -- for details see the 3GPP TS 29.272 [144]. } EPS-DataList ::= SEQUENCE SIZE (1..maxNumOfAPN-Configurations) OF APN-Configuration maxNumOfAPN-Configurations INTEGER ::= 50 APN-Configuration ::= SEQUENCE { contextId [0] ContextId, pdn-Type [1] PDN-Type, servedPartyIP-IPv4-Address [2] PDP-Address OPTIONAL, apn [3] APN, eps-qos-Subscribed [4] EPS-QoS-Subscribed, pdn-gw-Identity [5] PDN-GW-Identity OPTIONAL, pdn-gw-AllocationType [6] PDN-GW-AllocationType OPTIONAL, vplmnAddressAllowed [7] NULL OPTIONAL, chargingCharacteristics [8] ChargingCharacteristics OPTIONAL, ambr [9] AMBR OPTIONAL, specificAPNInfoList [10] SpecificAPNInfoList OPTIONAL, extensionContainer [11] ExtensionContainer OPTIONAL, servedPartyIP-IPv6-Address [12] PDP-Address OPTIONAL, ..., apn-oi-Replacement [13] APN-OI-Replacement OPTIONAL, -- this apn-oi-Replacement refers to the APN level apn-oi-Replacement. sipto-Permission [14] SIPTO-Permission OPTIONAL, lipa-Permission [15] LIPA-Permission OPTIONAL, restoration-Priority [16] Restoration-Priority OPTIONAL, sipto-local-network-Permission [17] SIPTO-Local-Network-Permission OPTIONAL, wlan-offloadability [18] WLAN-Offloadability OPTIONAL, non-IP-PDN-Type-Indicator [19] NULL OPTIONAL, nIDD-Mechanism [20] NIDD-Mechanism OPTIONAL, sCEF-ID [21] FQDN OPTIONAL, pdn-ConnectionContinuity [22] PDN-ConnectionContinuity OPTIONAL -- absence of pdn-ConnectionContinuity indicates that the handling is left to -- local VPLMN policy } PDN-ConnectionContinuity ::= ENUMERATED { maintainPDN-Connection (0), disconnectPDN-ConnectionWithReactivationRequest (1), disconnectPDN-ConnectionWithoutReactivationRequest (2) } NIDD-Mechanism ::= ENUMERATED { sGi-based-data-delivery (0), sCEF-based-data-delivery (1) -- The default value, when this information element is not present, is -- sGi-based-data-delivery (0) } PDN-Type ::= OCTET STRING (SIZE (1)) -- Octet is coded as follows: -- Bits -- 3 2 1 -- 0 0 1 IPv4 -- 0 1 0 IPv6 -- 0 1 1 IPv4v6 -- 1 0 0 IPv4_or_IPv6 -- Bits 8-4 shall be coded as zero. -- for details see 3GPP TS 29.272 [144] EPS-QoS-Subscribed ::= SEQUENCE { qos-Class-Identifier [0] QoS-Class-Identifier, allocation-Retention-Priority [1] Allocation-Retention-Priority, extensionContainer [2] ExtensionContainer OPTIONAL, ... } AMBR ::= SEQUENCE { max-RequestedBandwidth-UL [0] Bandwidth, max-RequestedBandwidth-DL [1] Bandwidth, extensionContainer [2] ExtensionContainer OPTIONAL, ..., extended-Max-RequestedBandwidth-UL [3] BandwidthExt OPTIONAL, extended-Max-RequestedBandwidth-DL [4] BandwidthExt OPTIONAL -- extended-Max-RequestedBandwidth-UL/DL shall be populated according to the -- description of the corresponding parameters in 3GPP TS 29.272 [144] } SpecificAPNInfoList ::= SEQUENCE SIZE (1..maxNumOfSpecificAPNInfos) OF SpecificAPNInfo maxNumOfSpecificAPNInfos INTEGER ::= 50 SpecificAPNInfo ::= SEQUENCE { apn [0] APN, pdn-gw-Identity [1] PDN-GW-Identity, extensionContainer [2] ExtensionContainer OPTIONAL, ... } Bandwidth ::= INTEGER -- bits per second BandwidthExt ::= INTEGER -- kilobits per second QoS-Class-Identifier ::= INTEGER (1..9) -- values are defined in 3GPP TS 29.212 Allocation-Retention-Priority ::= SEQUENCE { priority-level [0] INTEGER, pre-emption-capability [1] BOOLEAN OPTIONAL, pre-emption-vulnerability [2] BOOLEAN OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ... } PDN-GW-Identity ::= SEQUENCE { pdn-gw-ipv4-Address [0] PDP-Address OPTIONAL, pdn-gw-ipv6-Address [1] PDP-Address OPTIONAL, pdn-gw-name [2] FQDN OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ... } FQDN ::= OCTET STRING (SIZE (9..255)) PDN-GW-AllocationType ::= ENUMERATED { static (0), dynamic (1)} WLAN-Offloadability ::= SEQUENCE { wlan-offloadability-EUTRAN [0] WLAN-Offloadability-Indication OPTIONAL, wlan-offloadability-UTRAN [1] WLAN-Offloadability-Indication OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ... } WLAN-Offloadability-Indication ::= ENUMERATED { notAllowed (0), allowed (1)} AccessRestrictionData ::= BIT STRING { utranNotAllowed (0), geranNotAllowed (1), ganNotAllowed (2), i-hspa-evolutionNotAllowed (3), wb-e-utranNotAllowed (4), ho-toNon3GPP-AccessNotAllowed (5), nb-iotNotAllowed (6), enhancedCoverageNotAllowed (7) } (SIZE (2..8)) -- exception handling: -- The VLR shall ignore the access restriction data related to an access type not -- supported by the node. -- The handling of the access restriction data by the SGSN is described in clause -- 5.3.19 of TS 23.060, in clause 7.5.3 of TS 29.060 and clause 7.3.6 of TS 29.274. -- Additional access restrictions are encoded in Ext-AccessRestrictionData bit string. Ext-AccessRestrictionData ::= BIT STRING { nrAsSecondaryRATNotAllowed (0), unlicensedSpectrumAsSecondaryRATNotAllowed (1) } (SIZE (1..32)) AdjacentAccessRestrictionDataList ::= SEQUENCE SIZE (1..50) OF AdjacentAccessRestrictionData AdjacentAccessRestrictionData ::= SEQUENCE { plmnId [0] PLMN-Id, accessRestrictionData [1] AccessRestrictionData, ... , ext-AccessRestrictionData [2] Ext-AccessRestrictionData OPTIONAL } CS-AllocationRetentionPriority ::= OCTET STRING (SIZE (1)) -- This data type encodes each priority level defined in 3GPP TS 23.107 [154] as the --binary value of the priority level. IST-AlertTimerValue ::= INTEGER (15..255) LCSInformation ::= SEQUENCE { gmlc-List [0] GMLC-List OPTIONAL, lcs-PrivacyExceptionList [1] LCS-PrivacyExceptionList OPTIONAL, molr-List [2] MOLR-List OPTIONAL, ..., add-lcs-PrivacyExceptionList [3] LCS-PrivacyExceptionList OPTIONAL } -- add-lcs-PrivacyExceptionList may be sent only if lcs-PrivacyExceptionList is -- present and contains four instances of LCS-PrivacyClass. If the mentioned condition -- is not satisfied the receiving node shall discard add-lcs-PrivacyExceptionList. -- If an LCS-PrivacyClass is received both in lcs-PrivacyExceptionList and in -- add-lcs-PrivacyExceptionList with the same SS-Code, then the error unexpected -- data value shall be returned. GMLC-List ::= SEQUENCE SIZE (1..maxNumOfGMLC) OF ISDN-AddressString -- if segmentation is used, the complete GMLC-List shall be sent in one segment maxNumOfGMLC INTEGER ::= 5 NetworkAccessMode ::= ENUMERATED { packetAndCircuit (0), onlyCircuit (1), onlyPacket (2), ...} -- if unknown values are received in NetworkAccessMode -- they shall be discarded. GPRSDataList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF PDP-Context maxNumOfPDP-Contexts INTEGER ::= 50 PDP-Context ::= SEQUENCE { pdp-ContextId ContextId, pdp-Type [16] PDP-Type, pdp-Address [17] PDP-Address OPTIONAL, qos-Subscribed [18] QoS-Subscribed, vplmnAddressAllowed [19] NULL OPTIONAL, apn [20] APN, extensionContainer [21] ExtensionContainer OPTIONAL, ... , ext-QoS-Subscribed [0] Ext-QoS-Subscribed OPTIONAL, pdp-ChargingCharacteristics [1] ChargingCharacteristics OPTIONAL, ext2-QoS-Subscribed [2] Ext2-QoS-Subscribed OPTIONAL, -- ext2-QoS-Subscribed may be present only if ext-QoS-Subscribed is present. ext3-QoS-Subscribed [3] Ext3-QoS-Subscribed OPTIONAL, -- ext3-QoS-Subscribed may be present only if ext2-QoS-Subscribed is present. ext4-QoS-Subscribed [4] Ext4-QoS-Subscribed OPTIONAL, -- ext4-QoS-Subscribed may be present only if ext3-QoS-Subscribed is present. apn-oi-Replacement [5] APN-OI-Replacement OPTIONAL, -- this apn-oi-Replacement refers to the APN level apn-oi-Replacement and has -- higher priority than UE level apn-oi-Replacement. ext-pdp-Type [6] Ext-PDP-Type OPTIONAL, -- contains the value IPv4v6 defined in 3GPP TS 29.060 [105], if the PDP can be -- accessed by dual-stack UEs ext-pdp-Address [7] PDP-Address OPTIONAL, -- contains an additional IP address in case of dual-stack static IP address assignment -- for the UE. -- it may contain an IPv4 or an IPv6 address/prefix, and it may be present -- only if pdp-Address is present; if both are present, each parameter shall -- contain a different type of address (IPv4 or IPv6). ambr [10] AMBR OPTIONAL, -- this ambr contains the AMBR associated to the APN included in the -- PDP-Context (APN-AMBR). sipto-Permission [8] SIPTO-Permission OPTIONAL, lipa-Permission [9] LIPA-Permission OPTIONAL, restoration-Priority [11] Restoration-Priority OPTIONAL, sipto-local-network-Permission [12] SIPTO-Local-Network-Permission OPTIONAL, nIDD-Mechanism [13] NIDD-Mechanism OPTIONAL, sCEF-ID [14] FQDN OPTIONAL } Restoration-Priority ::= OCTET STRING (SIZE (1)) -- Octet 1: -- Restoration Priority. This octet encodes the Restoration Priority, -- as the binary value of the Restoration-Priority described in 3GPP TS 29.272 [144]. SIPTO-Permission ::= ENUMERATED { siptoAboveRanAllowed (0), siptoAboveRanNotAllowed (1) } SIPTO-Local-Network-Permission ::= ENUMERATED { siptoAtLocalNetworkAllowed (0), siptoAtLocalNetworkNotAllowed (1) } LIPA-Permission ::= ENUMERATED { lipaProhibited (0), lipaOnly (1), lipaConditional (2) } ContextId ::= INTEGER (1..maxNumOfPDP-Contexts) GPRSSubscriptionData ::= SEQUENCE { completeDataListIncluded NULL OPTIONAL, -- If segmentation is used, completeDataListIncluded may only be present in the -- first segment of GPRSSubscriptionData. gprsDataList [1] GPRSDataList, extensionContainer [2] ExtensionContainer OPTIONAL, ..., apn-oi-Replacement [3] APN-OI-Replacement OPTIONAL -- this apn-oi-Replacement refers to the UE level apn-oi-Replacement. } SGSN-CAMEL-SubscriptionInfo ::= SEQUENCE { gprs-CSI [0] GPRS-CSI OPTIONAL, mo-sms-CSI [1] SMS-CSI OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., mt-sms-CSI [3] SMS-CSI OPTIONAL, mt-smsCAMELTDP-CriteriaList [4] MT-smsCAMELTDP-CriteriaList OPTIONAL, mg-csi [5] MG-CSI OPTIONAL } GPRS-CSI ::= SEQUENCE { gprs-CamelTDPDataList [0] GPRS-CamelTDPDataList OPTIONAL, camelCapabilityHandling [1] CamelCapabilityHandling OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, notificationToCSE [3] NULL OPTIONAL, csi-Active [4] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present when GPRS-CSI is sent to SGSN. -- They may only be included in ATSI/ATM ack/NSDC message. -- GPRS-CamelTDPData and camelCapabilityHandling shall be present in -- the GPRS-CSI sequence. -- If GPRS-CSI is segmented, gprs-CamelTDPDataList and camelCapabilityHandling shall be -- present in the first segment GPRS-CamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF GPRS-CamelTDPData -- GPRS-CamelTDPDataList shall not contain more than one instance of -- GPRS-CamelTDPData containing the same value for gprs-TriggerDetectionPoint. GPRS-CamelTDPData ::= SEQUENCE { gprs-TriggerDetectionPoint [0] GPRS-TriggerDetectionPoint, serviceKey [1] ServiceKey, gsmSCF-Address [2] ISDN-AddressString, defaultSessionHandling [3] DefaultGPRS-Handling, extensionContainer [4] ExtensionContainer OPTIONAL, ... } DefaultGPRS-Handling ::= ENUMERATED { continueTransaction (0) , releaseTransaction (1) , ...} -- exception handling: -- reception of values in range 2-31 shall be treated as ""continueTransaction"" -- reception of values greater than 31 shall be treated as ""releaseTransaction"" GPRS-TriggerDetectionPoint ::= ENUMERATED { attach (1), attachChangeOfPosition (2), pdp-ContextEstablishment (11), pdp-ContextEstablishmentAcknowledgement (12), pdp-ContextChangeOfPosition (14), ... } -- exception handling: -- For GPRS-CamelTDPData sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- GPRS-CamelTDPDatasequence. APN ::= OCTET STRING (SIZE (2..63)) -- Octets are coded according to TS 3GPP TS 23.003 [17] PDP-Type ::= OCTET STRING (SIZE (2)) -- Octets are coded according to TS 3GPP TS 29.060 [105] -- Only the values PPP, IPv4, IPv6 and Non-IP are allowed for this parameter. Ext-PDP-Type ::= OCTET STRING (SIZE (2)) -- Octets are coded, similarly to PDP-Type, according to TS 3GPP TS 29.060 [105]. -- Only the value IPv4v6 is allowed for this parameter. PDP-Address ::= OCTET STRING (SIZE (1..16)) -- Octets are coded according to TS 3GPP TS 29.060 [105] -- The possible size values are: -- 1-7 octets X.25 address type -- 4 octets IPv4 address type -- 16 octets Ipv6 address type QoS-Subscribed ::= OCTET STRING (SIZE (3)) -- Octets are coded according to TS 3GPP TS 24.008 [35] Quality of Service Octets -- 3-5. Ext-QoS-Subscribed ::= OCTET STRING (SIZE (1..9)) -- OCTET 1: -- Allocation/Retention Priority (This octet encodes each priority level defined in -- 3GPP TS 23.107 [154] as the binary value of the priority level, declaration in -- 3GPP TS 29.060 [105]) -- Octets 2-9 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets -- 6-13. Ext2-QoS-Subscribed ::= OCTET STRING (SIZE (1..3)) -- Octets 1-3 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets 14-16. -- If Quality of Service information is structured with 14 octet length, then -- Octet 1 is coded according to 3GPP TS 24.008 [35] Quality of Service Octet 14. Ext3-QoS-Subscribed ::= OCTET STRING (SIZE (1..2)) -- Octets 1-2 are coded according to 3GPP TS 24.008 [35] Quality of Service Octets 17-18. Ext4-QoS-Subscribed ::= OCTET STRING (SIZE (1)) -- Octet 1: -- Evolved Allocation/Retention Priority. This octet encodes the Priority Level (PL), -- the Preemption Capability (PCI) and Preemption Vulnerability (PVI) values, as -- described in 3GPP TS 29.060 [105]. ChargingCharacteristics ::= OCTET STRING (SIZE (2)) -- Octets are coded according to 3GPP TS 32.215. LSAOnlyAccessIndicator ::= ENUMERATED { accessOutsideLSAsAllowed (0), accessOutsideLSAsRestricted (1)} LSADataList ::= SEQUENCE SIZE (1..maxNumOfLSAs) OF LSAData maxNumOfLSAs INTEGER ::= 20 LSAData ::= SEQUENCE { lsaIdentity [0] LSAIdentity, lsaAttributes [1] LSAAttributes, lsaActiveModeIndicator [2] NULL OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} LSAInformation ::= SEQUENCE { completeDataListIncluded NULL OPTIONAL, -- If segmentation is used, completeDataListIncluded may only be present in the -- first segment. lsaOnlyAccessIndicator [1] LSAOnlyAccessIndicator OPTIONAL, lsaDataList [2] LSADataList OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} LSAIdentity ::= OCTET STRING (SIZE (3)) -- Octets are coded according to TS 3GPP TS 23.003 [17] LSAAttributes ::= OCTET STRING (SIZE (1)) -- Octets are coded according to TS 3GPP TS 48.008 [49] SubscriberData ::= SEQUENCE { msisdn [1] ISDN-AddressString OPTIONAL, category [2] Category OPTIONAL, subscriberStatus [3] SubscriberStatus OPTIONAL, bearerServiceList [4] BearerServiceList OPTIONAL, -- The exception handling for reception of unsupported / not allocated -- bearerServiceCodes is defined in clause 8.8.1 teleserviceList [6] TeleserviceList OPTIONAL, -- The exception handling for reception of unsupported / not allocated -- teleserviceCodes is defined in clause 8.8.1 provisionedSS [7] Ext-SS-InfoList OPTIONAL, odb-Data [8] ODB-Data OPTIONAL, roamingRestrictionDueToUnsupportedFeature [9] NULL OPTIONAL, regionalSubscriptionData [10] ZoneCodeList OPTIONAL, vbsSubscriptionData [11] VBSDataList OPTIONAL, vgcsSubscriptionData [12] VGCSDataList OPTIONAL, vlrCamelSubscriptionInfo [13] VlrCamelSubscriptionInfo OPTIONAL } Category ::= OCTET STRING (SIZE (1)) -- The internal structure is defined in ITU-T Rec Q.763. SubscriberStatus ::= ENUMERATED { serviceGranted (0), operatorDeterminedBarring (1)} BearerServiceList ::= SEQUENCE SIZE (1..maxNumOfBearerServices) OF Ext-BearerServiceCode maxNumOfBearerServices INTEGER ::= 50 TeleserviceList ::= SEQUENCE SIZE (1..maxNumOfTeleservices) OF Ext-TeleserviceCode maxNumOfTeleservices INTEGER ::= 20 ODB-Data ::= SEQUENCE { odb-GeneralData ODB-GeneralData, odb-HPLMN-Data ODB-HPLMN-Data OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} ODB-GeneralData ::= BIT STRING { allOG-CallsBarred (0), internationalOGCallsBarred (1), internationalOGCallsNotToHPLMN-CountryBarred (2), interzonalOGCallsBarred (6), interzonalOGCallsNotToHPLMN-CountryBarred (7), interzonalOGCallsAndInternationalOGCallsNotToHPLMN-CountryBarred (8), premiumRateInformationOGCallsBarred (3), premiumRateEntertainementOGCallsBarred (4), ss-AccessBarred (5), allECT-Barred (9), chargeableECT-Barred (10), internationalECT-Barred (11), interzonalECT-Barred (12), doublyChargeableECT-Barred (13), multipleECT-Barred (14), allPacketOrientedServicesBarred (15), roamerAccessToHPLMN-AP-Barred (16), roamerAccessToVPLMN-AP-Barred (17), roamingOutsidePLMNOG-CallsBarred (18), allIC-CallsBarred (19), roamingOutsidePLMNIC-CallsBarred (20), roamingOutsidePLMNICountryIC-CallsBarred (21), roamingOutsidePLMN-Barred (22), roamingOutsidePLMN-CountryBarred (23), registrationAllCF-Barred (24), registrationCFNotToHPLMN-Barred (25), registrationInterzonalCF-Barred (26), registrationInterzonalCFNotToHPLMN-Barred (27), registrationInternationalCF-Barred (28)} (SIZE (15..32)) -- exception handling: reception of unknown bit assignments in the -- ODB-GeneralData type shall be treated like unsupported ODB-GeneralData -- When the ODB-GeneralData type is removed from the HLR for a given subscriber, -- in NoteSubscriberDataModified operation sent toward the gsmSCF -- all bits shall be set to ""O"". ODB-HPLMN-Data ::= BIT STRING { plmn-SpecificBarringType1 (0), plmn-SpecificBarringType2 (1), plmn-SpecificBarringType3 (2), plmn-SpecificBarringType4 (3)} (SIZE (4..32)) -- exception handling: reception of unknown bit assignments in the -- ODB-HPLMN-Data type shall be treated like unsupported ODB-HPLMN-Data -- When the ODB-HPLMN-Data type is removed from the HLR for a given subscriber, -- in NoteSubscriberDataModified operation sent toward the gsmSCF -- all bits shall be set to ""O"". Ext-SS-InfoList ::= SEQUENCE SIZE (1..maxNumOfSS) OF Ext-SS-Info Ext-SS-Info ::= CHOICE { forwardingInfo [0] Ext-ForwInfo, callBarringInfo [1] Ext-CallBarInfo, cug-Info [2] CUG-Info, ss-Data [3] Ext-SS-Data, emlpp-Info [4] EMLPP-Info} Ext-ForwInfo ::= SEQUENCE { ss-Code SS-Code, forwardingFeatureList Ext-ForwFeatureList, extensionContainer [0] ExtensionContainer OPTIONAL, ...} Ext-ForwFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF Ext-ForwFeature Ext-ForwFeature ::= SEQUENCE { basicService Ext-BasicServiceCode OPTIONAL, ss-Status [4] Ext-SS-Status, forwardedToNumber [5] ISDN-AddressString OPTIONAL, -- When this data type is sent from an HLR which supports CAMEL Phase 2 -- to a VLR that supports CAMEL Phase 2 the VLR shall not check the -- format of the number forwardedToSubaddress [8] ISDN-SubaddressString OPTIONAL, forwardingOptions [6] Ext-ForwOptions OPTIONAL, noReplyConditionTime [7] Ext-NoRepCondTime OPTIONAL, extensionContainer [9] ExtensionContainer OPTIONAL, ..., longForwardedToNumber [10] FTN-AddressString OPTIONAL } Ext-ForwOptions ::= OCTET STRING (SIZE (1..5)) -- OCTET 1: -- bit 8: notification to forwarding party -- 0 no notification -- 1 notification -- bit 7: redirecting presentation -- 0 no presentation -- 1 presentation -- bit 6: notification to calling party -- 0 no notification -- 1 notification -- bit 5: 0 (unused) -- bits 43: forwarding reason -- 00 ms not reachable -- 01 ms busy -- 10 no reply -- 11 unconditional -- bits 21: 00 (unused) -- OCTETS 2-5: reserved for future use. They shall be discarded if -- received and not understood. Ext-NoRepCondTime ::= INTEGER (1..100) -- Only values 5-30 are used. -- Values in the ranges 1-4 and 31-100 are reserved for future use -- If received: -- values 1-4 shall be mapped on to value 5 -- values 31-100 shall be mapped on to value 30 Ext-CallBarInfo ::= SEQUENCE { ss-Code SS-Code, callBarringFeatureList Ext-CallBarFeatureList, extensionContainer ExtensionContainer OPTIONAL, ...} Ext-CallBarFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF Ext-CallBarringFeature Ext-CallBarringFeature ::= SEQUENCE { basicService Ext-BasicServiceCode OPTIONAL, ss-Status [4] Ext-SS-Status, extensionContainer ExtensionContainer OPTIONAL, ...} CUG-Info ::= SEQUENCE { cug-SubscriptionList CUG-SubscriptionList, cug-FeatureList CUG-FeatureList OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ...} CUG-SubscriptionList ::= SEQUENCE SIZE (0..maxNumOfCUG) OF CUG-Subscription CUG-Subscription ::= SEQUENCE { cug-Index CUG-Index, cug-Interlock CUG-Interlock, intraCUG-Options IntraCUG-Options, basicServiceGroupList Ext-BasicServiceGroupList OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ...} CUG-Index ::= INTEGER (0..32767) -- The internal structure is defined in ETS 300 138. CUG-Interlock ::= OCTET STRING (SIZE (4)) IntraCUG-Options ::= ENUMERATED { noCUG-Restrictions (0), cugIC-CallBarred (1), cugOG-CallBarred (2)} maxNumOfCUG INTEGER ::= 10 CUG-FeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF CUG-Feature Ext-BasicServiceGroupList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF Ext-BasicServiceCode maxNumOfExt-BasicServiceGroups INTEGER ::= 32 CUG-Feature ::= SEQUENCE { basicService Ext-BasicServiceCode OPTIONAL, preferentialCUG-Indicator CUG-Index OPTIONAL, interCUG-Restrictions InterCUG-Restrictions, extensionContainer ExtensionContainer OPTIONAL, ...} InterCUG-Restrictions ::= OCTET STRING (SIZE (1)) -- bits 876543: 000000 (unused) -- Exception handling: -- bits 876543 shall be ignored if received and not understood -- bits 21 -- 00 CUG only facilities -- 01 CUG with outgoing access -- 10 CUG with incoming access -- 11 CUG with both outgoing and incoming access Ext-SS-Data ::= SEQUENCE { ss-Code SS-Code, ss-Status [4] Ext-SS-Status, ss-SubscriptionOption SS-SubscriptionOption OPTIONAL, basicServiceGroupList Ext-BasicServiceGroupList OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ...} LCS-PrivacyExceptionList ::= SEQUENCE SIZE (1..maxNumOfPrivacyClass) OF LCS-PrivacyClass maxNumOfPrivacyClass INTEGER ::= 4 LCS-PrivacyClass ::= SEQUENCE { ss-Code SS-Code, ss-Status Ext-SS-Status, notificationToMSUser [0] NotificationToMSUser OPTIONAL, -- notificationToMSUser may be sent only for SS-codes callSessionRelated -- and callSessionUnrelated. If not received for SS-codes callSessionRelated -- and callSessionUnrelated, -- the default values according to 3GPP TS 23.271 shall be assumed. externalClientList [1] ExternalClientList OPTIONAL, -- externalClientList may be sent only for SS-code callSessionUnrelated to a -- visited node that does not support LCS Release 4 or later versions. -- externalClientList may be sent only for SS-codes callSessionUnrelated and -- callSessionRelated to a visited node that supports LCS Release 4 or later versions. plmnClientList [2] PLMNClientList OPTIONAL, -- plmnClientList may be sent only for SS-code plmnoperator. extensionContainer [3] ExtensionContainer OPTIONAL, ..., ext-externalClientList [4] Ext-ExternalClientList OPTIONAL, -- Ext-externalClientList may be sent only if the visited node supports LCS Release 4 or -- later versions, the user did specify more than 5 clients, and White Book SCCP is used. serviceTypeList [5] ServiceTypeList OPTIONAL -- serviceTypeList may be sent only for SS-code serviceType and if the visited node -- supports LCS Release 5 or later versions. -- -- if segmentation is used, the complete LCS-PrivacyClass shall be sent in one segment } ExternalClientList ::= SEQUENCE SIZE (0..maxNumOfExternalClient) OF ExternalClient maxNumOfExternalClient INTEGER ::= 5 PLMNClientList ::= SEQUENCE SIZE (1..maxNumOfPLMNClient) OF LCSClientInternalID maxNumOfPLMNClient INTEGER ::= 5 Ext-ExternalClientList ::= SEQUENCE SIZE (1..maxNumOfExt-ExternalClient) OF ExternalClient maxNumOfExt-ExternalClient INTEGER ::= 35 ExternalClient ::= SEQUENCE { clientIdentity LCSClientExternalID, gmlc-Restriction [0] GMLC-Restriction OPTIONAL, notificationToMSUser [1] NotificationToMSUser OPTIONAL, -- If notificationToMSUser is not received, the default value according to -- 3GPP TS 23.271 shall be assumed. extensionContainer [2] ExtensionContainer OPTIONAL, ... } GMLC-Restriction ::= ENUMERATED { gmlc-List (0), home-Country (1) , ... } -- exception handling: -- At reception of any other value than the ones listed the receiver shall ignore -- GMLC-Restriction. NotificationToMSUser ::= ENUMERATED { notifyLocationAllowed (0), notifyAndVerify-LocationAllowedIfNoResponse (1), notifyAndVerify-LocationNotAllowedIfNoResponse (2), ..., locationNotAllowed (3) } -- exception handling: -- At reception of any other value than the ones listed the receiver shall ignore -- NotificationToMSUser. ServiceTypeList ::= SEQUENCE SIZE (1..maxNumOfServiceType) OF ServiceType maxNumOfServiceType INTEGER ::= 32 ServiceType ::= SEQUENCE { serviceTypeIdentity LCSServiceTypeID, gmlc-Restriction [0] GMLC-Restriction OPTIONAL, notificationToMSUser [1] NotificationToMSUser OPTIONAL, -- If notificationToMSUser is not received, the default value according to -- 3GPP TS 23.271 shall be assumed. extensionContainer [2] ExtensionContainer OPTIONAL, ... } MOLR-List ::= SEQUENCE SIZE (1..maxNumOfMOLR-Class) OF MOLR-Class maxNumOfMOLR-Class INTEGER ::= 3 MOLR-Class ::= SEQUENCE { ss-Code SS-Code, ss-Status Ext-SS-Status, extensionContainer [0] ExtensionContainer OPTIONAL, ...} ZoneCodeList ::= SEQUENCE SIZE (1..maxNumOfZoneCodes) OF ZoneCode ZoneCode ::= OCTET STRING (SIZE (2)) -- internal structure is defined in TS 3GPP TS 23.003 [17] maxNumOfZoneCodes INTEGER ::= 10 InsertSubscriberDataRes ::= SEQUENCE { teleserviceList [1] TeleserviceList OPTIONAL, bearerServiceList [2] BearerServiceList OPTIONAL, ss-List [3] SS-List OPTIONAL, odb-GeneralData [4] ODB-GeneralData OPTIONAL, regionalSubscriptionResponse [5] RegionalSubscriptionResponse OPTIONAL, supportedCamelPhases [6] SupportedCamelPhases OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ... , offeredCamel4CSIs [8] OfferedCamel4CSIs OPTIONAL, supportedFeatures [9] SupportedFeatures OPTIONAL, ext-SupportedFeatures [10] Ext-SupportedFeatures OPTIONAL } RegionalSubscriptionResponse ::= ENUMERATED { networkNode-AreaRestricted (0), tooManyZoneCodes (1), zoneCodesConflict (2), regionalSubscNotSupported (3)} DeleteSubscriberDataArg ::= SEQUENCE { imsi [0] IMSI, basicServiceList [1] BasicServiceList OPTIONAL, -- The exception handling for reception of unsupported/not allocated -- basicServiceCodes is defined in clause 6.8.2 ss-List [2] SS-List OPTIONAL, roamingRestrictionDueToUnsupportedFeature [4] NULL OPTIONAL, regionalSubscriptionIdentifier [5] ZoneCode OPTIONAL, vbsGroupIndication [7] NULL OPTIONAL, vgcsGroupIndication [8] NULL OPTIONAL, camelSubscriptionInfoWithdraw [9] NULL OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ..., gprsSubscriptionDataWithdraw [10] GPRSSubscriptionDataWithdraw OPTIONAL, roamingRestrictedInSgsnDueToUnsuppportedFeature [11] NULL OPTIONAL, lsaInformationWithdraw [12] LSAInformationWithdraw OPTIONAL, gmlc-ListWithdraw [13] NULL OPTIONAL, istInformationWithdraw [14] NULL OPTIONAL, specificCSI-Withdraw [15] SpecificCSI-Withdraw OPTIONAL, chargingCharacteristicsWithdraw [16] NULL OPTIONAL, stn-srWithdraw [17] NULL OPTIONAL, epsSubscriptionDataWithdraw [18] EPS-SubscriptionDataWithdraw OPTIONAL, apn-oi-replacementWithdraw [19] NULL OPTIONAL, csg-SubscriptionDeleted [20] NULL OPTIONAL, subscribedPeriodicTAU-RAU-TimerWithdraw [22] NULL OPTIONAL, subscribedPeriodicLAU-TimerWithdraw [23] NULL OPTIONAL, subscribed-vsrvccWithdraw [21] NULL OPTIONAL, vplmn-Csg-SubscriptionDeleted [24] NULL OPTIONAL, additionalMSISDN-Withdraw [25] NULL OPTIONAL, cs-to-ps-SRVCC-Withdraw [26] NULL OPTIONAL, imsiGroupIdList-Withdraw [27] NULL OPTIONAL, userPlaneIntegrityProtectionWithdraw [28] NULL OPTIONAL, dl-Buffering-Suggested-Packet-Count-Withdraw [29] NULL OPTIONAL, ue-UsageTypeWithdraw [30] NULL OPTIONAL, reset-idsWithdraw [31] NULL OPTIONAL, iab-OperationWithdraw [32] NULL OPTIONAL } SpecificCSI-Withdraw ::= BIT STRING { o-csi (0), ss-csi (1), tif-csi (2), d-csi (3), vt-csi (4), mo-sms-csi (5), m-csi (6), gprs-csi (7), t-csi (8), mt-sms-csi (9), mg-csi (10), o-IM-CSI (11), d-IM-CSI (12), vt-IM-CSI (13) } (SIZE(8..32)) -- exception handling: -- bits 11 to 31 shall be ignored if received by a non-IP Multimedia Core Network entity. -- bits 0-10 and 14-31 shall be ignored if received by an IP Multimedia Core Network entity. -- bits 11-13 are only applicable in an IP Multimedia Core Network. -- Bit 8 and bits 11-13 are only applicable for the NoteSubscriberDataModified operation. GPRSSubscriptionDataWithdraw ::= CHOICE { allGPRSData NULL, contextIdList ContextIdList} EPS-SubscriptionDataWithdraw ::= CHOICE { allEPS-Data NULL, contextIdList ContextIdList} ContextIdList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF ContextId LSAInformationWithdraw ::= CHOICE { allLSAData NULL, lsaIdentityList LSAIdentityList } LSAIdentityList ::= SEQUENCE SIZE (1..maxNumOfLSAs) OF LSAIdentity BasicServiceList ::= SEQUENCE SIZE (1..maxNumOfBasicServices) OF Ext-BasicServiceCode maxNumOfBasicServices INTEGER ::= 70 DeleteSubscriberDataRes ::= SEQUENCE { regionalSubscriptionResponse [0] RegionalSubscriptionResponse OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} VlrCamelSubscriptionInfo ::= SEQUENCE { o-CSI [0] O-CSI OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ..., ss-CSI [2] SS-CSI OPTIONAL, o-BcsmCamelTDP-CriteriaList [4] O-BcsmCamelTDPCriteriaList OPTIONAL, tif-CSI [3] NULL OPTIONAL, m-CSI [5] M-CSI OPTIONAL, mo-sms-CSI [6] SMS-CSI OPTIONAL, vt-CSI [7] T-CSI OPTIONAL, t-BCSM-CAMEL-TDP-CriteriaList [8] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL, d-CSI [9] D-CSI OPTIONAL, mt-sms-CSI [10] SMS-CSI OPTIONAL, mt-smsCAMELTDP-CriteriaList [11] MT-smsCAMELTDP-CriteriaList OPTIONAL } MT-smsCAMELTDP-CriteriaList ::= SEQUENCE SIZE (1.. maxNumOfCamelTDPData) OF MT-smsCAMELTDP-Criteria MT-smsCAMELTDP-Criteria ::= SEQUENCE { sms-TriggerDetectionPoint SMS-TriggerDetectionPoint, tpdu-TypeCriterion [0] TPDU-TypeCriterion OPTIONAL, ... } TPDU-TypeCriterion ::= SEQUENCE SIZE (1..maxNumOfTPDUTypes) OF MT-SMS-TPDU-Type maxNumOfTPDUTypes INTEGER ::= 5 MT-SMS-TPDU-Type ::= ENUMERATED { sms-DELIVER (0), sms-SUBMIT-REPORT (1), sms-STATUS-REPORT (2), ... } -- exception handling: -- For TPDU-TypeCriterion sequences containing this parameter with any -- other value than the ones listed above the receiver shall ignore -- the whole TPDU-TypeCriterion sequence. -- In CAMEL phase 4, sms-SUBMIT-REPORT shall not be used and a received TPDU-TypeCriterion -- sequence containing sms-SUBMIT-REPORT shall be wholly ignored. D-CSI ::= SEQUENCE { dp-AnalysedInfoCriteriaList [0] DP-AnalysedInfoCriteriaList OPTIONAL, camelCapabilityHandling [1] CamelCapabilityHandling OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, notificationToCSE [3] NULL OPTIONAL, csi-Active [4] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present when D-CSI is sent to VLR/GMSC. -- They may only be included in ATSI/ATM ack/NSDC message. -- DP-AnalysedInfoCriteria and camelCapabilityHandling shall be present in -- the D-CSI sequence. -- If D-CSI is segmented, then the first segment shall contain dp-AnalysedInfoCriteriaList -- and camelCapabilityHandling. Subsequent segments shall not contain -- camelCapabilityHandling, but may contain dp-AnalysedInfoCriteriaList. DP-AnalysedInfoCriteriaList ::= SEQUENCE SIZE (1..maxNumOfDP-AnalysedInfoCriteria) OF DP-AnalysedInfoCriterium maxNumOfDP-AnalysedInfoCriteria INTEGER ::= 10 DP-AnalysedInfoCriterium ::= SEQUENCE { dialledNumber ISDN-AddressString, serviceKey ServiceKey, gsmSCF-Address ISDN-AddressString, defaultCallHandling DefaultCallHandling, extensionContainer ExtensionContainer OPTIONAL, ...} SS-CSI ::= SEQUENCE { ss-CamelData SS-CamelData, extensionContainer ExtensionContainer OPTIONAL, ..., notificationToCSE [0] NULL OPTIONAL, csi-Active [1] NULL OPTIONAL -- notificationToCSE and csi-Active shall not be present when SS-CSI is sent to VLR. -- They may only be included in ATSI/ATM ack/NSDC message. } SS-CamelData ::= SEQUENCE { ss-EventList SS-EventList, gsmSCF-Address ISDN-AddressString, extensionContainer [0] ExtensionContainer OPTIONAL, ...} SS-EventList ::= SEQUENCE SIZE (1..maxNumOfCamelSSEvents) OF SS-Code -- Actions for the following SS-Code values are defined in CAMEL Phase 3: -- ect SS-Code ::= '00110001'B -- multiPTY SS-Code ::= '01010001'B -- cd SS-Code ::= '00100100'B -- ccbs SS-Code ::= '01000100'B -- all other SS codes shall be ignored -- When SS-CSI is sent to the VLR, it shall not contain a marking for ccbs. -- If the VLR receives SS-CSI containing a marking for ccbs, the VLR shall discard the -- ccbs marking in SS-CSI. maxNumOfCamelSSEvents INTEGER ::= 10 O-CSI ::= SEQUENCE { o-BcsmCamelTDPDataList O-BcsmCamelTDPDataList, extensionContainer ExtensionContainer OPTIONAL, ..., camelCapabilityHandling [0] CamelCapabilityHandling OPTIONAL, notificationToCSE [1] NULL OPTIONAL, csiActive [2] NULL OPTIONAL} -- notificationtoCSE and csiActive shall not be present when O-CSI is sent to VLR/GMSC. -- They may only be included in ATSI/ATM ack/NSDC message. -- O-CSI shall not be segmented. O-BcsmCamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF O-BcsmCamelTDPData -- O-BcsmCamelTDPDataList shall not contain more than one instance of -- O-BcsmCamelTDPData containing the same value for o-BcsmTriggerDetectionPoint. -- For CAMEL Phase 2, this means that only one instance of O-BcsmCamelTDPData is allowed -- with o-BcsmTriggerDetectionPoint being equal to DP2. maxNumOfCamelTDPData INTEGER ::= 10 O-BcsmCamelTDPData ::= SEQUENCE { o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint, serviceKey ServiceKey, gsmSCF-Address [0] ISDN-AddressString, defaultCallHandling [1] DefaultCallHandling, extensionContainer [2] ExtensionContainer OPTIONAL, ... } ServiceKey ::= INTEGER (0..2147483647) O-BcsmTriggerDetectionPoint ::= ENUMERATED { collectedInfo (2), ..., routeSelectFailure (4) } -- exception handling: -- For O-BcsmCamelTDPData sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- O-BcsmCamelTDPDatasequence. -- For O-BcsmCamelTDP-Criteria sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- O-BcsmCamelTDP-Criteria sequence. O-BcsmCamelTDPCriteriaList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF O-BcsmCamelTDP-Criteria T-BCSM-CAMEL-TDP-CriteriaList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF T-BCSM-CAMEL-TDP-Criteria O-BcsmCamelTDP-Criteria ::= SEQUENCE { o-BcsmTriggerDetectionPoint O-BcsmTriggerDetectionPoint, destinationNumberCriteria [0] DestinationNumberCriteria OPTIONAL, basicServiceCriteria [1] BasicServiceCriteria OPTIONAL, callTypeCriteria [2] CallTypeCriteria OPTIONAL, ..., o-CauseValueCriteria [3] O-CauseValueCriteria OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL } T-BCSM-CAMEL-TDP-Criteria ::= SEQUENCE { t-BCSM-TriggerDetectionPoint T-BcsmTriggerDetectionPoint, basicServiceCriteria [0] BasicServiceCriteria OPTIONAL, t-CauseValueCriteria [1] T-CauseValueCriteria OPTIONAL, ... } DestinationNumberCriteria ::= SEQUENCE { matchType [0] MatchType, destinationNumberList [1] DestinationNumberList OPTIONAL, destinationNumberLengthList [2] DestinationNumberLengthList OPTIONAL, -- one or both of destinationNumberList and destinationNumberLengthList -- shall be present ...} DestinationNumberList ::= SEQUENCE SIZE (1..maxNumOfCamelDestinationNumbers) OF ISDN-AddressString -- The receiving entity shall not check the format of a number in -- the dialled number list DestinationNumberLengthList ::= SEQUENCE SIZE (1..maxNumOfCamelDestinationNumberLengths) OF INTEGER(1..maxNumOfISDN-AddressDigits) BasicServiceCriteria ::= SEQUENCE SIZE(1..maxNumOfCamelBasicServiceCriteria) OF Ext-BasicServiceCode maxNumOfISDN-AddressDigits INTEGER ::= 15 maxNumOfCamelDestinationNumbers INTEGER ::= 10 maxNumOfCamelDestinationNumberLengths INTEGER ::= 3 maxNumOfCamelBasicServiceCriteria INTEGER ::= 5 CallTypeCriteria ::= ENUMERATED { forwarded (0), notForwarded (1)} MatchType ::= ENUMERATED { inhibiting (0), enabling (1)} O-CauseValueCriteria ::= SEQUENCE SIZE(1..maxNumOfCAMEL-O-CauseValueCriteria) OF CauseValue T-CauseValueCriteria ::= SEQUENCE SIZE(1..maxNumOfCAMEL-T-CauseValueCriteria) OF CauseValue maxNumOfCAMEL-O-CauseValueCriteria INTEGER ::= 5 maxNumOfCAMEL-T-CauseValueCriteria INTEGER ::= 5 CauseValue ::= OCTET STRING (SIZE(1)) -- Type extracted from Cause parameter in ITU-T Recommendation Q.763. -- For the use of cause value refer to ITU-T Recommendation Q.850. DefaultCallHandling ::= ENUMERATED { continueCall (0) , releaseCall (1) , ...} -- exception handling: -- reception of values in range 2-31 shall be treated as ""continueCall"" -- reception of values greater than 31 shall be treated as ""releaseCall"" CamelCapabilityHandling ::= INTEGER(1..16) -- value 1 = CAMEL phase 1, -- value 2 = CAMEL phase 2, -- value 3 = CAMEL Phase 3, -- value 4 = CAMEL phase 4: -- reception of values greater than 4 shall be treated as CAMEL phase 4. SupportedCamelPhases ::= BIT STRING { phase1 (0), phase2 (1), phase3 (2), phase4 (3)} (SIZE (1..16)) -- A node shall mark in the BIT STRING all CAMEL Phases it supports. -- Other values than listed above shall be discarded. OfferedCamel4CSIs ::= BIT STRING { o-csi (0), d-csi (1), vt-csi (2), t-csi (3), mt-sms-csi (4), mg-csi (5), psi-enhancements (6) } (SIZE (7..16)) -- A node supporting Camel phase 4 shall mark in the BIT STRING all Camel4 CSIs -- it offers. -- Other values than listed above shall be discarded. OfferedCamel4Functionalities ::= BIT STRING { initiateCallAttempt (0), splitLeg (1), moveLeg (2), disconnectLeg (3), entityReleased (4), dfc-WithArgument (5), playTone (6), dtmf-MidCall (7), chargingIndicator (8), alertingDP (9), locationAtAlerting (10), changeOfPositionDP (11), or-Interactions (12), warningToneEnhancements (13), cf-Enhancements (14), subscribedEnhancedDialledServices (15), servingNetworkEnhancedDialledServices (16), criteriaForChangeOfPositionDP (17), serviceChangeDP (18), collectInformation (19) } (SIZE (15..64)) -- A node supporting Camel phase 4 shall mark in the BIT STRING all CAMEL4 -- functionalities it offers. -- Other values than listed above shall be discarded. SMS-CSI ::= SEQUENCE { sms-CAMEL-TDP-DataList [0] SMS-CAMEL-TDP-DataList OPTIONAL, camelCapabilityHandling [1] CamelCapabilityHandling OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, notificationToCSE [3] NULL OPTIONAL, csi-Active [4] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present -- when MO-SMS-CSI or MT-SMS-CSI is sent to VLR or SGSN. -- They may only be included in ATSI/ATM ack/NSDC message."
"-- SMS-CAMEL-TDP-Data and camelCapabilityHandling shall be present in -- the SMS-CSI sequence. -- If SMS-CSI is segmented, sms-CAMEL-TDP-DataList and camelCapabilityHandling shall be -- present in the first segment SMS-CAMEL-TDP-DataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF SMS-CAMEL-TDP-Data -- SMS-CAMEL-TDP-DataList shall not contain more than one instance of -- SMS-CAMEL-TDP-Data containing the same value for sms-TriggerDetectionPoint. SMS-CAMEL-TDP-Data ::= SEQUENCE { sms-TriggerDetectionPoint [0] SMS-TriggerDetectionPoint, serviceKey [1] ServiceKey, gsmSCF-Address [2] ISDN-AddressString, defaultSMS-Handling [3] DefaultSMS-Handling, extensionContainer [4] ExtensionContainer OPTIONAL, ... } SMS-TriggerDetectionPoint ::= ENUMERATED { sms-CollectedInfo (1), ..., sms-DeliveryRequest (2) } -- exception handling: -- For SMS-CAMEL-TDP-Data and MT-smsCAMELTDP-Criteria sequences containing this -- parameter with any other value than the ones listed the receiver shall ignore -- the whole sequence. -- -- If this parameter is received with any other value than sms-CollectedInfo -- in an SMS-CAMEL-TDP-Data sequence contained in mo-sms-CSI, then the receiver shall -- ignore the whole SMS-CAMEL-TDP-Data sequence. -- -- If this parameter is received with any other value than sms-DeliveryRequest -- in an SMS-CAMEL-TDP-Data sequence contained in mt-sms-CSI then the receiver shall -- ignore the whole SMS-CAMEL-TDP-Data sequence. -- -- If this parameter is received with any other value than sms-DeliveryRequest -- in an MT-smsCAMELTDP-Criteria sequence then the receiver shall -- ignore the whole MT-smsCAMELTDP-Criteria sequence. DefaultSMS-Handling ::= ENUMERATED { continueTransaction (0) , releaseTransaction (1) , ...} -- exception handling: -- reception of values in range 2-31 shall be treated as ""continueTransaction"" -- reception of values greater than 31 shall be treated as ""releaseTransaction"" M-CSI ::= SEQUENCE { mobilityTriggers MobilityTriggers, serviceKey ServiceKey, gsmSCF-Address [0] ISDN-AddressString, extensionContainer [1] ExtensionContainer OPTIONAL, notificationToCSE [2] NULL OPTIONAL, csi-Active [3] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present when M-CSI is sent to VLR. -- They may only be included in ATSI/ATM ack/NSDC message. MG-CSI ::= SEQUENCE { mobilityTriggers MobilityTriggers, serviceKey ServiceKey, gsmSCF-Address [0] ISDN-AddressString, extensionContainer [1] ExtensionContainer OPTIONAL, notificationToCSE [2] NULL OPTIONAL, csi-Active [3] NULL OPTIONAL, ...} -- notificationToCSE and csi-Active shall not be present when MG-CSI is sent to SGSN. -- They may only be included in ATSI/ATM ack/NSDC message. MobilityTriggers ::= SEQUENCE SIZE (1..maxNumOfMobilityTriggers) OF MM-Code maxNumOfMobilityTriggers INTEGER ::= 10 MM-Code ::= OCTET STRING (SIZE (1)) -- This type is used to indicate a Mobility Management event. -- Actions for the following MM-Code values are defined in CAMEL Phase 4: -- -- CS domain MM events: -- Location-update-in-same-VLR MM-Code ::= '00000000'B -- Location-update-to-other-VLR MM-Code ::= '00000001'B -- IMSI-Attach MM-Code ::= '00000010'B -- MS-initiated-IMSI-Detach MM-Code ::= '00000011'B -- Network-initiated-IMSI-Detach MM-Code ::= '00000100'B -- -- PS domain MM events: -- Routeing-Area-update-in-same-SGSN MM-Code ::= '10000000'B -- Routeing-Area-update-to-other-SGSN-update-from-new-SGSN -- MM-Code ::= '10000001'B -- Routeing-Area-update-to-other-SGSN-disconnect-by-detach -- MM-Code ::= '10000010'B -- GPRS-Attach MM-Code ::= '10000011'B -- MS-initiated-GPRS-Detach MM-Code ::= '10000100'B -- Network-initiated-GPRS-Detach MM-Code ::= '10000101'B -- Network-initiated-transfer-to-MS-not-reachable-for-paging -- MM-Code ::= '10000110'B -- -- If the MSC receives any other MM-code than the ones listed above for the -- CS domain, then the MSC shall ignore that MM-code. -- If the SGSN receives any other MM-code than the ones listed above for the -- PS domain, then the SGSN shall ignore that MM-code. T-CSI ::= SEQUENCE { t-BcsmCamelTDPDataList T-BcsmCamelTDPDataList, extensionContainer ExtensionContainer OPTIONAL, ..., camelCapabilityHandling [0] CamelCapabilityHandling OPTIONAL, notificationToCSE [1] NULL OPTIONAL, csi-Active [2] NULL OPTIONAL} -- notificationToCSE and csi-Active shall not be present when VT-CSI/T-CSI is sent -- to VLR/GMSC. -- They may only be included in ATSI/ATM ack/NSDC message. -- T-CSI shall not be segmented. T-BcsmCamelTDPDataList ::= SEQUENCE SIZE (1..maxNumOfCamelTDPData) OF T-BcsmCamelTDPData --- T-BcsmCamelTDPDataList shall not contain more than one instance of --- T-BcsmCamelTDPData containing the same value for t-BcsmTriggerDetectionPoint. --- For CAMEL Phase 2, this means that only one instance of T-BcsmCamelTDPData is allowed --- with t-BcsmTriggerDetectionPoint being equal to DP12. --- For CAMEL Phase 3, more TDP's are allowed. T-BcsmCamelTDPData ::= SEQUENCE { t-BcsmTriggerDetectionPoint T-BcsmTriggerDetectionPoint, serviceKey ServiceKey, gsmSCF-Address [0] ISDN-AddressString, defaultCallHandling [1] DefaultCallHandling, extensionContainer [2] ExtensionContainer OPTIONAL, ...} T-BcsmTriggerDetectionPoint ::= ENUMERATED { termAttemptAuthorized (12), ... , tBusy (13), tNoAnswer (14)} -- exception handling: -- For T-BcsmCamelTDPData sequences containing this parameter with any other -- value than the ones listed above, the receiver shall ignore the whole -- T-BcsmCamelTDPData sequence. -- gprs location information retrieval types SendRoutingInfoForGprsArg ::= SEQUENCE { imsi [0] IMSI, ggsn-Address [1] GSN-Address OPTIONAL, ggsn-Number [2] ISDN-AddressString, extensionContainer [3] ExtensionContainer OPTIONAL, ...} SendRoutingInfoForGprsRes ::= SEQUENCE { sgsn-Address [0] GSN-Address, ggsn-Address [1] GSN-Address OPTIONAL, mobileNotReachableReason [2] AbsentSubscriberDiagnosticSM OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} -- failure report types FailureReportArg ::= SEQUENCE { imsi [0] IMSI, ggsn-Number [1] ISDN-AddressString , ggsn-Address [2] GSN-Address OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} FailureReportRes ::= SEQUENCE { ggsn-Address [0] GSN-Address OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} -- gprs notification types NoteMsPresentForGprsArg ::= SEQUENCE { imsi [0] IMSI, sgsn-Address [1] GSN-Address, ggsn-Address [2] GSN-Address OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} NoteMsPresentForGprsRes ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ...} -- fault recovery types ResetArg ::= SEQUENCE { sendingNodenumber SendingNode-Number, hlr-List HLR-List OPTIONAL, -- The hlr-List parameter shall only be applicable for a restart of the HSS/HLR. extensionContainer [0] ExtensionContainer OPTIONAL, ..., reset-Id-List [1] Reset-Id-List OPTIONAL, subscriptionData [2] InsertSubscriberDataArg OPTIONAL, subscriptionDataDeletion [3] DeleteSubscriberDataArg OPTIONAL} SendingNode-Number ::= CHOICE { hlr-Number ISDN-AddressString, css-Number [1] ISDN-AddressString} RestoreDataArg ::= SEQUENCE { imsi IMSI, lmsi LMSI OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , vlr-Capability [6] VLR-Capability OPTIONAL, restorationIndicator [7] NULL OPTIONAL } RestoreDataRes ::= SEQUENCE { hlr-Number ISDN-AddressString, msNotReachable NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} -- VBS/VGCS types VBSDataList ::= SEQUENCE SIZE (1..maxNumOfVBSGroupIds) OF VoiceBroadcastData VGCSDataList ::= SEQUENCE SIZE (1..maxNumOfVGCSGroupIds) OF VoiceGroupCallData maxNumOfVBSGroupIds INTEGER ::= 50 maxNumOfVGCSGroupIds INTEGER ::= 50 VoiceGroupCallData ::= SEQUENCE { groupId GroupId, -- groupId shall be filled with six TBCD fillers (1111)if the longGroupId is present extensionContainer ExtensionContainer OPTIONAL, ..., additionalSubscriptions AdditionalSubscriptions OPTIONAL, additionalInfo [0] AdditionalInfo OPTIONAL, longGroupId [1] Long-GroupId OPTIONAL } -- VoiceGroupCallData containing a longGroupId shall not be sent to VLRs that did not -- indicate support of long Group IDs within the Update Location or Restore Data -- request message AdditionalInfo ::= BIT STRING (SIZE (1..136)) -- Refers to Additional Info as specified in 3GPP TS 43.068 AdditionalSubscriptions ::= BIT STRING { privilegedUplinkRequest (0), emergencyUplinkRequest (1), emergencyReset (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. VoiceBroadcastData ::= SEQUENCE { groupid GroupId, -- groupId shall be filled with six TBCD fillers (1111)if the longGroupId is present broadcastInitEntitlement NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., longGroupId [0] Long-GroupId OPTIONAL } -- VoiceBroadcastData containing a longGroupId shall not be sent to VLRs that did not -- indicate support of long Group IDs within the Update Location or Restore Data -- request message GroupId ::= TBCD-STRING (SIZE (3)) -- When Group-Id is less than six characters in length, the TBCD filler (1111) -- is used to fill unused half octets. -- Refers to the Group Identification as specified in 3GPP TS 23.003 -- and 3GPP TS 43.068/ 43.069 Long-GroupId ::= TBCD-STRING (SIZE (4)) -- When Long-Group-Id is less than eight characters in length, the TBCD filler (1111) -- is used to fill unused half octets. -- Refers to the Group Identification as specified in 3GPP TS 23.003 -- and 3GPP TS 43.068/ 43.069 -- provide subscriber info types ProvideSubscriberInfoArg ::= SEQUENCE { imsi [0] IMSI, lmsi [1] LMSI OPTIONAL, requestedInfo [2] RequestedInfo, extensionContainer [3] ExtensionContainer OPTIONAL, ..., callPriority [4] EMLPP-Priority OPTIONAL } ProvideSubscriberInfoRes ::= SEQUENCE { subscriberInfo SubscriberInfo, extensionContainer ExtensionContainer OPTIONAL, ...} SubscriberInfo ::= SEQUENCE { locationInformation [0] LocationInformation OPTIONAL, subscriberState [1] SubscriberState OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ... , locationInformationGPRS [3] LocationInformationGPRS OPTIONAL, ps-SubscriberState [4] PS-SubscriberState OPTIONAL, imei [5] IMEI OPTIONAL, ms-Classmark2 [6] MS-Classmark2 OPTIONAL, gprs-MS-Class [7] GPRSMSClass OPTIONAL, mnpInfoRes [8] MNPInfoRes OPTIONAL, imsVoiceOverPS-SessionsIndication [9] IMS-VoiceOverPS-SessionsInd OPTIONAL, lastUE-ActivityTime [10] Time OPTIONAL, lastRAT-Type [11] Used-RAT-Type OPTIONAL, eps-SubscriberState [12] PS-SubscriberState OPTIONAL, locationInformationEPS [13] LocationInformationEPS OPTIONAL, timeZone [14] TimeZone OPTIONAL, daylightSavingTime [15] DaylightSavingTime OPTIONAL, locationInformation5GS [16] LocationInformation5GS OPTIONAL } -- If the HLR receives locationInformation, subscriberState or ms-Classmark2 from an SGSN or -- MME (via an IWF), it shall discard them. -- If the HLR receives locationInformationGPRS, ps-SubscriberState, gprs-MS-Class or -- locationInformationEPS (outside the locationInformation IE) from a VLR, it shall -- discard them. -- If the HLR receives parameters which it has not requested, it shall discard them. -- The locationInformation5GS IE should be absent if UE did not access via 5GS and IM-SSF. IMS-VoiceOverPS-SessionsInd ::= ENUMERATED { imsVoiceOverPS-SessionsNotSupported (0), imsVoiceOverPS-SessionsSupported (1), unknown (2) } -- ""unknown"" shall not be used within ProvideSubscriberInfoRes TimeZone ::= OCTET STRING (SIZE (2..3)) -- Refer to the 3GPP TS 29.272 [144] for details. DaylightSavingTime ::= ENUMERATED { noAdjustment (0), plusOneHourAdjustment (1), plusTwoHoursAdjustment (2) } -- Refer to the 3GPP TS 29.272 [144] for details. MNPInfoRes ::= SEQUENCE { routeingNumber [0] RouteingNumber OPTIONAL, imsi [1] IMSI OPTIONAL, msisdn [2] ISDN-AddressString OPTIONAL, numberPortabilityStatus [3] NumberPortabilityStatus OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ... } -- The IMSI parameter contains a generic IMSI, i.e. it is not tied necessarily to the -- Subscriber. MCC and MNC values in this IMSI shall point to the Subscription Network of -- the Subscriber. See 3GPP TS 23.066 [108]. RouteingNumber ::= TBCD-STRING (SIZE (1..5)) NumberPortabilityStatus ::= ENUMERATED { notKnownToBePorted (0), ownNumberPortedOut (1), foreignNumberPortedToForeignNetwork (2), ..., ownNumberNotPortedOut (4), foreignNumberPortedIn (5) } -- exception handling: -- reception of other values than the ones listed the receiver shall ignore the -- whole NumberPortabilityStatus; -- ownNumberNotPortedOut or foreignNumberPortedIn may only be included in Any Time -- Interrogation message. MS-Classmark2 ::= OCTET STRING (SIZE (3)) -- This parameter carries the value part of the MS Classmark 2 IE defined in -- 3GPP TS 24.008 [35]. GPRSMSClass ::= SEQUENCE { mSNetworkCapability [0] MSNetworkCapability, mSRadioAccessCapability [1] MSRadioAccessCapability OPTIONAL } MSNetworkCapability ::= OCTET STRING (SIZE (1..8)) -- This parameter carries the value part of the MS Network Capability IE defined in -- 3GPP TS 24.008 [35]. MSRadioAccessCapability ::= OCTET STRING (SIZE (1..50)) -- This parameter carries the value part of the MS Radio Access Capability IE defined in -- 3GPP TS 24.008 [35]. RequestedInfo ::= SEQUENCE { locationInformation [0] NULL OPTIONAL, subscriberState [1] NULL OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., currentLocation [3] NULL OPTIONAL, requestedDomain [4] DomainType OPTIONAL, imei [6] NULL OPTIONAL, ms-classmark [5] NULL OPTIONAL, mnpRequestedInfo [7] NULL OPTIONAL, locationInformationEPS-Supported [11] NULL OPTIONAL, t-adsData [8] NULL OPTIONAL, requestedNodes [9] RequestedNodes OPTIONAL, servingNodeIndication [10] NULL OPTIONAL, localTimeZoneRequest [12] NULL OPTIONAL } -- currentLocation and locationInformationEPS-Supported shall be absent if -- locationInformation is absent -- t-adsData shall be absent in messages sent to the VLR -- requestedNodes shall be absent if requestedDomain is ""cs-Domain"" -- servingNodeIndication shall be absent if locationInformation is absent; -- servingNodeIndication shall be absent if current location is present; -- servingNodeIndication indicates by its presence that only the serving node's -- address (MME-Name or SGSN-Number or VLR-Number) is requested. DomainType ::= ENUMERATED { cs-Domain (0), ps-Domain (1), ...} -- exception handling: -- reception of values > 1 shall be mapped to 'cs-Domain' RequestedNodes ::= BIT STRING { mme (0), sgsn (1)} (SIZE (1..8)) -- Other bits than listed above shall be discarded. LocationInformation ::= SEQUENCE { ageOfLocationInformation AgeOfLocationInformation OPTIONAL, geographicalInformation [0] GeographicalInformation OPTIONAL, vlr-number [1] ISDN-AddressString OPTIONAL, locationNumber [2] LocationNumber OPTIONAL, cellGlobalIdOrServiceAreaIdOrLAI [3] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ... , selectedLSA-Id [5] LSAIdentity OPTIONAL, msc-Number [6] ISDN-AddressString OPTIONAL, geodeticInformation [7] GeodeticInformation OPTIONAL, currentLocationRetrieved [8] NULL OPTIONAL, sai-Present [9] NULL OPTIONAL, locationInformationEPS [10] LocationInformationEPS OPTIONAL, userCSGInformation [11] UserCSGInformation OPTIONAL } -- sai-Present indicates that the cellGlobalIdOrServiceAreaIdOrLAI parameter contains -- a Service Area Identity. -- currentLocationRetrieved shall be present -- if the location information were retrieved after a successfull paging. -- if the locationinformationEPS IE is present then the cellGlobalIdOrServiceAreaIdOrLAI IE, -- theÊageOfLocationInformation IE, the geographicalInformation IE, the geodeticInformation IE -- and the currentLocationRetrieved IE (outside the locationInformationEPS IE) shall be -- absent. As an exception, both the cellGlobalIdOrServiceAreaIdOrLAI IE including an LAI and -- the locationinformationEPS IE may be present in a MAP-NOTE-MM-EVENT. -- UserCSGInformation contains the CSG ID, Access mode, and the CSG Membership Indication in -- the case the Access mode is Hybrid Mode. -- The locationInformationEPS IE should be absent if locationInformationEPS-Supported was not -- received in the RequestedInfo IE. LocationInformationEPS ::= SEQUENCE { e-utranCellGlobalIdentity [0] E-UTRAN-CGI OPTIONAL, trackingAreaIdentity [1] TA-Id OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, geographicalInformation [3] GeographicalInformation OPTIONAL, geodeticInformation [4] GeodeticInformation OPTIONAL, currentLocationRetrieved [5] NULL OPTIONAL, ageOfLocationInformation [6] AgeOfLocationInformation OPTIONAL, ..., mme-Name [7] DiameterIdentity OPTIONAL } -- currentLocationRetrieved shall be present if the location information -- was retrieved after successful paging. LocationInformationGPRS ::= SEQUENCE { cellGlobalIdOrServiceAreaIdOrLAI [0] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL, routeingAreaIdentity [1] RAIdentity OPTIONAL, geographicalInformation [2] GeographicalInformation OPTIONAL, sgsn-Number [3] ISDN-AddressString OPTIONAL, selectedLSAIdentity [4] LSAIdentity OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ..., sai-Present [6] NULL OPTIONAL, geodeticInformation [7] GeodeticInformation OPTIONAL, currentLocationRetrieved [8] NULL OPTIONAL, ageOfLocationInformation [9] AgeOfLocationInformation OPTIONAL, userCSGInformation [10] UserCSGInformation OPTIONAL } -- sai-Present indicates that the cellGlobalIdOrServiceAreaIdOrLAI parameter contains -- a Service Area Identity. -- currentLocationRetrieved shall be present if the location information -- was retrieved after successful paging. -- UserCSGInformation contains the CSG ID, Access mode, and the CSG Membership Indication in -- the case the Access mode is Hybrid Mode. LocationInformation5GS ::= SEQUENCE { nrCellGlobalIdentity [0] NR-CGI OPTIONAL, e-utranCellGlobalIdentity [1] E-UTRAN-CGI OPTIONAL, geographicalInformation [2] GeographicalInformation OPTIONAL, geodeticInformation [3] GeodeticInformation OPTIONAL, amf-address [4] FQDN OPTIONAL, trackingAreaIdentity [5] TA-Id OPTIONAL, currentLocationRetrieved [6] NULL OPTIONAL, ageOfLocationInformation [7] AgeOfLocationInformation OPTIONAL, vplmnId [8] PLMN-Id OPTIONAL, localtimeZone [9] TimeZone OPTIONAL, rat-Type [10] Used-RAT-Type OPTIONAL, extensionContainer [11] ExtensionContainer OPTIONAL, ..., nrTrackingAreaIdentity [12] NR-TA-Id OPTIONAL } -- currentLocationRetrieved shall be present if the location information -- was retrieved after successful paging. UserCSGInformation ::= SEQUENCE { csg-Id [0] CSG-Id, extensionContainer [1] ExtensionContainer OPTIONAL, ..., accessMode [2] OCTET STRING (SIZE(1)) OPTIONAL, cmi [3] OCTET STRING (SIZE(1)) OPTIONAL } -- The encoding of the accessMode and cmi parameters are as defined in 3GPP TS 29.060 [105]. GeographicalInformation ::= OCTET STRING (SIZE (8)) -- Refers to geographical Information defined in 3GPP TS 23.032. -- Only the description of an ellipsoid point with uncertainty circle -- as specified in 3GPP TS 23.032 is allowed to be used -- The internal structure according to 3GPP TS 23.032 is as follows: -- Type of shape (ellipsoid point with uncertainty circle) 1 octet -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Uncertainty code 1 octet GeodeticInformation ::= OCTET STRING (SIZE (10)) -- Refers to Calling Geodetic Location defined in Q.763 (1999). -- Only the description of an ellipsoid point with uncertainty circle -- as specified in Q.763 (1999) is allowed to be used -- The internal structure according to Q.763 (1999) is as follows: -- Screening and presentation indicators 1 octet -- Type of shape (ellipsoid point with uncertainty circle) 1 octet -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Uncertainty code 1 octet -- Confidence 1 octet LocationNumber ::= OCTET STRING (SIZE (2..10)) -- the internal structure is defined in ITU-T Rec Q.763 SubscriberState ::= CHOICE { assumedIdle [0] NULL, camelBusy [1] NULL, netDetNotReachable NotReachableReason, notProvidedFromVLR [2] NULL} PS-SubscriberState ::= CHOICE { notProvidedFromSGSNorMME [0] NULL, ps-Detached [1] NULL, ps-AttachedNotReachableForPaging [2] NULL, ps-AttachedReachableForPaging [3] NULL, ps-PDP-ActiveNotReachableForPaging [4] PDP-ContextInfoList, ps-PDP-ActiveReachableForPaging [5] PDP-ContextInfoList, netDetNotReachable NotReachableReason } PDP-ContextInfoList ::= SEQUENCE SIZE (1..maxNumOfPDP-Contexts) OF PDP-ContextInfo PDP-ContextInfo ::= SEQUENCE { pdp-ContextIdentifier [0] ContextId, pdp-ContextActive [1] NULL OPTIONAL, pdp-Type [2] PDP-Type, pdp-Address [3] PDP-Address OPTIONAL, apn-Subscribed [4] APN OPTIONAL, apn-InUse [5] APN OPTIONAL, nsapi [6] NSAPI OPTIONAL, transactionId [7] TransactionId OPTIONAL, teid-ForGnAndGp [8] TEID OPTIONAL, teid-ForIu [9] TEID OPTIONAL, ggsn-Address [10] GSN-Address OPTIONAL, qos-Subscribed [11] Ext-QoS-Subscribed OPTIONAL, qos-Requested [12] Ext-QoS-Subscribed OPTIONAL, qos-Negotiated [13] Ext-QoS-Subscribed OPTIONAL, chargingId [14] GPRSChargingID OPTIONAL, chargingCharacteristics [15] ChargingCharacteristics OPTIONAL, rnc-Address [16] GSN-Address OPTIONAL, extensionContainer [17] ExtensionContainer OPTIONAL, ..., qos2-Subscribed [18] Ext2-QoS-Subscribed OPTIONAL, -- qos2-Subscribed may be present only if qos-Subscribed is present. qos2-Requested [19] Ext2-QoS-Subscribed OPTIONAL, -- qos2-Requested may be present only if qos-Requested is present. qos2-Negotiated [20] Ext2-QoS-Subscribed OPTIONAL, -- qos2-Negotiated may be present only if qos-Negotiated is present. qos3-Subscribed [21] Ext3-QoS-Subscribed OPTIONAL, -- qos3-Subscribed may be present only if qos2-Subscribed is present. qos3-Requested [22] Ext3-QoS-Subscribed OPTIONAL, -- qos3-Requested may be present only if qos2-Requested is present. qos3-Negotiated [23] Ext3-QoS-Subscribed OPTIONAL, -- qos3-Negotiated may be present only if qos2-Negotiated is present. qos4-Subscribed [25] Ext4-QoS-Subscribed OPTIONAL, -- qos4-Subscribed may be present only if qos3-Subscribed is present. qos4-Requested [26] Ext4-QoS-Subscribed OPTIONAL, -- qos4-Requested may be present only if qos3-Requested is present. qos4-Negotiated [27] Ext4-QoS-Subscribed OPTIONAL, -- qos4-Negotiated may be present only if qos3-Negotiated is present. ext-pdp-Type [28] Ext-PDP-Type OPTIONAL, -- contains the value IPv4v6 defined in 3GPP TS 29.060 [105], if the PDP can be -- accessed by dual-stack UEs. ext-pdp-Address [29] PDP-Address OPTIONAL -- contains an additional IP address in case of dual-stack static IP address assignment -- for the UE. -- it may contain an IPv4 or an IPv6 address/prefix, and it may be present -- only if pdp-Address is present; if both are present, each parameter shall -- contain a different type of address (IPv4 or IPv6). } NSAPI ::= INTEGER (0..15) -- This type is used to indicate the Network layer Service Access Point TransactionId ::= OCTET STRING (SIZE (1..2)) -- This type carries the value part of the transaction identifier which is used in the -- session management messages on the access interface. The encoding is defined in -- 3GPP TS 24.008 TEID ::= OCTET STRING (SIZE (4)) -- This type carries the value part of the Tunnel Endpoint Identifier which is used to -- distinguish between different tunnels between the same pair of entities which communicate -- using the GPRS Tunnelling Protocol The encoding is defined in 3GPP TS 29.060. GPRSChargingID ::= OCTET STRING (SIZE (4)) -- The Charging ID is a unique four octet value generated by the GGSN when -- a PDP Context is activated. A Charging ID is generated for each activated context. -- The encoding is defined in 3GPP TS 29.060. NotReachableReason ::= ENUMERATED { msPurged (0), imsiDetached (1), restrictedArea (2), notRegistered (3)} -- any time interrogation info types AnyTimeInterrogationArg ::= SEQUENCE { subscriberIdentity [0] SubscriberIdentity, requestedInfo [1] RequestedInfo, gsmSCF-Address [3] ISDN-AddressString, extensionContainer [2] ExtensionContainer OPTIONAL, ...} AnyTimeInterrogationRes ::= SEQUENCE { subscriberInfo SubscriberInfo, extensionContainer ExtensionContainer OPTIONAL, ...} -- any time information handling types AnyTimeSubscriptionInterrogationArg ::= SEQUENCE { subscriberIdentity [0] SubscriberIdentity, requestedSubscriptionInfo [1] RequestedSubscriptionInfo, gsmSCF-Address [2] ISDN-AddressString, extensionContainer [3] ExtensionContainer OPTIONAL, longFTN-Supported [4] NULL OPTIONAL, ...} AnyTimeSubscriptionInterrogationRes ::= SEQUENCE { callForwardingData [1] CallForwardingData OPTIONAL, callBarringData [2] CallBarringData OPTIONAL, odb-Info [3] ODB-Info OPTIONAL, camel-SubscriptionInfo [4] CAMEL-SubscriptionInfo OPTIONAL, supportedVLR-CAMEL-Phases [5] SupportedCamelPhases OPTIONAL, supportedSGSN-CAMEL-Phases [6] SupportedCamelPhases OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ... , offeredCamel4CSIsInVLR [8] OfferedCamel4CSIs OPTIONAL, offeredCamel4CSIsInSGSN [9] OfferedCamel4CSIs OPTIONAL, msisdn-BS-List [10] MSISDN-BS-List OPTIONAL, csg-SubscriptionDataList [11] CSG-SubscriptionDataList OPTIONAL, cw-Data [12] CallWaitingData OPTIONAL, ch-Data [13] CallHoldData OPTIONAL, clip-Data [14] ClipData OPTIONAL, clir-Data [15] ClirData OPTIONAL, ect-data [16] EctData OPTIONAL } CallWaitingData ::= SEQUENCE { cwFeatureList [1] Ext-CwFeatureList, notificationToCSE [2] NULL OPTIONAL, ... } Ext-CwFeatureList ::= SEQUENCE SIZE (1..maxNumOfExt-BasicServiceGroups) OF Ext-CwFeature Ext-CwFeature ::= SEQUENCE { basicService [1]ÊExt-BasicServiceCode, ss-Status [2]ÊExt-SS-Status, ... } ClipData ::= SEQUENCE { ss-Status [1] Ext-SS-Status, overrideCategory [2] OverrideCategory, notificationToCSE [3] NULL OPTIONAL, ... } ClirData ::= SEQUENCE { ss-Status [1] Ext-SS-Status, cliRestrictionOption [2] CliRestrictionOption OPTIONAL, notificationToCSE [3] NULL OPTIONAL, ... } CallHoldData ::= SEQUENCE { ss-Status [1] Ext-SS-Status, notificationToCSE [2] NULL OPTIONAL, ... } EctData ::= SEQUENCE { ss-Status [1] Ext-SS-Status, notificationToCSE [2] NULL OPTIONAL, ... } RequestedSubscriptionInfo ::= SEQUENCE { requestedSS-Info [1] SS-ForBS-Code OPTIONAL, odb [2] NULL OPTIONAL, requestedCAMEL-SubscriptionInfo [3] RequestedCAMEL-SubscriptionInfo OPTIONAL, supportedVLR-CAMEL-Phases [4] NULL OPTIONAL, supportedSGSN-CAMEL-Phases [5] NULL OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ..., additionalRequestedCAMEL-SubscriptionInfo [7] AdditionalRequestedCAMEL-SubscriptionInfo OPTIONAL, msisdn-BS-List [8] NULL OPTIONAL, csg-SubscriptionDataRequested [9] NULL OPTIONAL, cw-Info [10] NULL OPTIONAL, clip-Info [11] NULL OPTIONAL, clir-Info [12] NULL OPTIONAL, hold-Info [13] NULL OPTIONAL, ect-Info [14] NULL OPTIONAL } MSISDN-BS-List ::= SEQUENCE SIZE (1..maxNumOfMSISDN) OF MSISDN-BS maxNumOfMSISDN INTEGER ::= 50 MSISDN-BS ::= SEQUENCE { msisdn ISDN-AddressString, basicServiceList [0] BasicServiceList OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} RequestedCAMEL-SubscriptionInfo ::= ENUMERATED { o-CSI (0), t-CSI (1), vt-CSI (2), tif-CSI (3), gprs-CSI (4), mo-sms-CSI (5), ss-CSI (6), m-CSI (7), d-csi (8)} AdditionalRequestedCAMEL-SubscriptionInfo ::= ENUMERATED { mt-sms-CSI (0), mg-csi (1), o-IM-CSI (2), d-IM-CSI (3), vt-IM-CSI (4), ...} -- exception handling: unknown values shall be discarded by the receiver. CallForwardingData ::= SEQUENCE { forwardingFeatureList Ext-ForwFeatureList, notificationToCSE NULL OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ...} CallBarringData ::= SEQUENCE { callBarringFeatureList Ext-CallBarFeatureList, password Password OPTIONAL, wrongPasswordAttemptsCounter WrongPasswordAttemptsCounter OPTIONAL, notificationToCSE NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} WrongPasswordAttemptsCounter ::= INTEGER (0..4) ODB-Info ::= SEQUENCE { odb-Data ODB-Data, notificationToCSE NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} CAMEL-SubscriptionInfo ::= SEQUENCE { o-CSI [0] O-CSI OPTIONAL, o-BcsmCamelTDP-CriteriaList [1] O-BcsmCamelTDPCriteriaList OPTIONAL, d-CSI [2] D-CSI OPTIONAL, t-CSI [3] T-CSI OPTIONAL, t-BCSM-CAMEL-TDP-CriteriaList [4] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL, vt-CSI [5] T-CSI OPTIONAL, vt-BCSM-CAMEL-TDP-CriteriaList [6] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL, tif-CSI [7] NULL OPTIONAL, tif-CSI-NotificationToCSE [8] NULL OPTIONAL, gprs-CSI [9] GPRS-CSI OPTIONAL, mo-sms-CSI [10] SMS-CSI OPTIONAL, ss-CSI [11] SS-CSI OPTIONAL, m-CSI [12] M-CSI OPTIONAL, extensionContainer [13] ExtensionContainer OPTIONAL, ..., specificCSIDeletedList [14] SpecificCSI-Withdraw OPTIONAL, mt-sms-CSI [15] SMS-CSI OPTIONAL, mt-smsCAMELTDP-CriteriaList [16] MT-smsCAMELTDP-CriteriaList OPTIONAL, mg-csi [17] MG-CSI OPTIONAL, o-IM-CSI [18] O-CSI OPTIONAL, o-IM-BcsmCamelTDP-CriteriaList [19] O-BcsmCamelTDPCriteriaList OPTIONAL, d-IM-CSI [20] D-CSI OPTIONAL, vt-IM-CSI [21] T-CSI OPTIONAL, vt-IM-BCSM-CAMEL-TDP-CriteriaList [22] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL } AnyTimeModificationArg ::= SEQUENCE { subscriberIdentity [0] SubscriberIdentity, gsmSCF-Address [1] ISDN-AddressString, modificationRequestFor-CF-Info [2] ModificationRequestFor-CF-Info OPTIONAL, modificationRequestFor-CB-Info [3] ModificationRequestFor-CB-Info OPTIONAL, modificationRequestFor-CSI [4] ModificationRequestFor-CSI OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, longFTN-Supported [6] NULL OPTIONAL, ..., modificationRequestFor-ODB-data [7] ModificationRequestFor-ODB-data OPTIONAL, modificationRequestFor-IP-SM-GW-Data [8] ModificationRequestFor-IP-SM-GW-Data OPTIONAL, activationRequestForUE-reachability [9] RequestedServingNode OPTIONAL, modificationRequestFor-CSG [10] ModificationRequestFor-CSG OPTIONAL, modificationRequestFor-CW-Data [11] ModificationRequestFor-CW-Info OPTIONAL, modificationRequestFor-CLIP-Data [12] ModificationRequestFor-CLIP-Info OPTIONAL, modificationRequestFor-CLIR-Data [13] ModificationRequestFor-CLIR-Info OPTIONAL, modificationRequestFor-HOLD-Data [14] ModificationRequestFor-CH-Info OPTIONAL, modificationRequestFor-ECT-Data [15] ModificationRequestFor-ECT-Info OPTIONAL } ModificationRequestFor-CW-Info ::= SEQUENCE { basicService [0] Ext-BasicServiceCode OPTIONAL, ss-Status [1] Ext-SS-Status OPTIONAL, modifyNotificationToCSE [2] ModificationInstruction OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CH-Info ::= SEQUENCE { ss-Status [0] Ext-SS-Status OPTIONAL, modifyNotificationToCSE [1] ModificationInstruction OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-ECT-Info ::= SEQUENCE { ss-Status [0] Ext-SS-Status OPTIONAL, modifyNotificationToCSE [1] ModificationInstruction OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CLIR-Info ::= SEQUENCE { ss-Status [0] Ext-SS-Status OPTIONAL, cliRestrictionOption [1] CliRestrictionOption OPTIONAL, modifyNotificationToCSE [2] ModificationInstruction OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CLIP-Info ::= SEQUENCE { ss-Status [0] Ext-SS-Status OPTIONAL, overrideCategory [1] OverrideCategory OPTIONAL, modifyNotificationToCSE [2] ModificationInstruction OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CSG ::= SEQUENCE { modifyNotificationToCSE [0] ModificationInstruction OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} RequestedServingNode ::= BIT STRING { mmeAndSgsn (0)} (SIZE (1..8)) ServingNode ::= BIT STRING { mme (0), sgsn (1)} (SIZE (2..8)) -- Other bits than listed above shall be discarded. AnyTimeModificationRes ::= SEQUENCE { ss-InfoFor-CSE [0] Ext-SS-InfoFor-CSE OPTIONAL, camel-SubscriptionInfo [1] CAMEL-SubscriptionInfo OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., odb-Info [3] ODB-Info OPTIONAL, cw-Data [4] CallWaitingData OPTIONAL, ch-Data [5] CallHoldData OPTIONAL, clip-Data [6] ClipData OPTIONAL, clir-Data [7] ClirData OPTIONAL, ect-data [8] EctData OPTIONAL, serviceCentreAddress [9] AddressString OPTIONAL } ModificationRequestFor-CF-Info ::= SEQUENCE { ss-Code [0] SS-Code, basicService [1] Ext-BasicServiceCode OPTIONAL, ss-Status [2] Ext-SS-Status OPTIONAL, forwardedToNumber [3] AddressString OPTIONAL, forwardedToSubaddress [4] ISDN-SubaddressString OPTIONAL, noReplyConditionTime [5] Ext-NoRepCondTime OPTIONAL, modifyNotificationToCSE [6] ModificationInstruction OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CB-Info ::= SEQUENCE { ss-Code [0] SS-Code, basicService [1] Ext-BasicServiceCode OPTIONAL, ss-Status [2] Ext-SS-Status OPTIONAL, password [3] Password OPTIONAL, wrongPasswordAttemptsCounter [4] WrongPasswordAttemptsCounter OPTIONAL, modifyNotificationToCSE [5] ModificationInstruction OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-ODB-data ::= SEQUENCE { odb-data [0] ODB-Data OPTIONAL, modifyNotificationToCSE [1] ModificationInstruction OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} ModificationRequestFor-CSI ::= SEQUENCE { requestedCamel-SubscriptionInfo [0] RequestedCAMEL-SubscriptionInfo, modifyNotificationToCSE [1] ModificationInstruction OPTIONAL, modifyCSI-State [2] ModificationInstruction OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ..., additionalRequestedCAMEL-SubscriptionInfo [4] AdditionalRequestedCAMEL-SubscriptionInfo OPTIONAL } -- requestedCamel-SubscriptionInfo shall be discarded if -- additionalRequestedCAMEL-SubscriptionInfo is received ModificationRequestFor-IP-SM-GW-Data ::= SEQUENCE { modifyRegistrationStatus [0] ModificationInstruction OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ..., ip-sm-gw-DiameterAddress [2] NetworkNodeDiameterAddress OPTIONAL -- ip-sm-gw-DiameterAddress may be present when ModificationInstruction is ""activate"" } ModificationInstruction ::= ENUMERATED { deactivate (0), activate (1)} -- subscriber data modification notification types NoteSubscriberDataModifiedArg ::= SEQUENCE { imsi IMSI, msisdn ISDN-AddressString, forwardingInfoFor-CSE [0] Ext-ForwardingInfoFor-CSE OPTIONAL, callBarringInfoFor-CSE [1] Ext-CallBarringInfoFor-CSE OPTIONAL, odb-Info [2] ODB-Info OPTIONAL, camel-SubscriptionInfo [3] CAMEL-SubscriptionInfo OPTIONAL, allInformationSent [4] NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., ue-reachable [5] ServingNode OPTIONAL, csg-SubscriptionDataList [6] CSG-SubscriptionDataList OPTIONAL, cw-Data [7] CallWaitingData OPTIONAL, ch-Data [8] CallHoldData OPTIONAL, clip-Data [9] ClipData OPTIONAL, clir-Data [10] ClirData OPTIONAL, ect-data [11] EctData OPTIONAL } NoteSubscriberDataModifiedRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} -- mobility management event notificatioon info types NoteMM-EventArg::= SEQUENCE { serviceKey ServiceKey, eventMet [0] MM-Code, imsi [1] IMSI, msisdn [2] ISDN-AddressString, locationInformation [3] LocationInformation OPTIONAL, supportedCAMELPhases [5] SupportedCamelPhases OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ..., locationInformationGPRS [7] LocationInformationGPRS OPTIONAL, offeredCamel4Functionalities [8] OfferedCamel4Functionalities OPTIONAL } NoteMM-EventRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} Ext-SS-InfoFor-CSE ::= CHOICE { forwardingInfoFor-CSE [0] Ext-ForwardingInfoFor-CSE, callBarringInfoFor-CSE [1] Ext-CallBarringInfoFor-CSE } Ext-ForwardingInfoFor-CSE ::= SEQUENCE { ss-Code [0] SS-Code, forwardingFeatureList [1] Ext-ForwFeatureList, notificationToCSE [2] NULL OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} Ext-CallBarringInfoFor-CSE ::= SEQUENCE { ss-Code [0] SS-Code, callBarringFeatureList [1] Ext-CallBarFeatureList, password [2] Password OPTIONAL, wrongPasswordAttemptsCounter [3] WrongPasswordAttemptsCounter OPTIONAL, notificationToCSE [4] NULL OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ...} -- vcsg location registration types UpdateVcsgLocationArg ::= SEQUENCE { imsi IMSI, msisdn [2] ISDN-AddressString OPTIONAL, vlr-Number [0] ISDN-AddressString OPTIONAL, sgsn-Number [1] ISDN-AddressString OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... } UpdateVcsgLocationRes ::= SEQUENCE { temporaryEmptySubscriptiondataIndicator NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... } CancelVcsgLocationArg ::= SEQUENCE { identity Identity, extensionContainer ExtensionContainer OPTIONAL, ... } CancelVcsgLocationRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ... } .#END 17.7.2 Operation and maintenance data types .$MAP-OM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-OM-DataTypes (12) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS ActivateTraceModeArg, ActivateTraceModeRes, DeactivateTraceModeArg, DeactivateTraceModeRes, TracePropagationList ; IMPORTS AddressString, IMSI, GSN-Address, GlobalCellId, E-UTRAN-CGI, TA-Id, RAIdentity, LAIFixedLength, PLMN-Id FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; ActivateTraceModeArg ::= SEQUENCE { imsi [0] IMSI OPTIONAL, traceReference [1] TraceReference, traceType [2] TraceType, omc-Id [3] AddressString OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., traceReference2 [5] TraceReference2 OPTIONAL, traceDepthList [6] TraceDepthList OPTIONAL, traceNE-TypeList [7] TraceNE-TypeList OPTIONAL, traceInterfaceList [8] TraceInterfaceList OPTIONAL, traceEventList [9] TraceEventList OPTIONAL, traceCollectionEntity [10] GSN-Address OPTIONAL, mdt-Configuration [11] MDT-Configuration OPTIONAL } MDT-Configuration ::= SEQUENCE { jobType JobType, areaScope AreaScope OPTIONAL, listOfMeasurements ListOfMeasurements OPTIONAL, reportingTrigger [0] ReportingTrigger OPTIONAL, reportInterval ReportInterval OPTIONAL, reportAmount [1] ReportAmount OPTIONAL, eventThresholdRSRP EventThresholdRSRP OPTIONAL, eventThresholdRSRQ [2] EventThresholdRSRQ OPTIONAL, loggingInterval [3] LoggingInterval OPTIONAL, loggingDuration [4] LoggingDuration OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ..., measurementPeriodUMTS [6] PeriodUMTS OPTIONAL, measurementPeriodLTE [7] PeriodLTE OPTIONAL, collectionPeriodRRM-UMTS [8] PeriodUMTS OPTIONAL, collectionPeriodRRM-LTE [9] PeriodLTE OPTIONAL, positioningMethod [10] PositioningMethod OPTIONAL, measurementQuantity [11] MeasurementQuantity OPTIONAL, eventThreshold1F [12] EventThreshold1F OPTIONAL, eventThreshold1I [13] EventThreshold1I OPTIONAL, mdt-Allowed-PLMN-List [14] MDT-Allowed-PLMNId-List OPTIONAL } MDT-Allowed-PLMNId-List ::= SEQUENCE SIZE (1..16) OF PLMN-Id PeriodUMTS ::= ENUMERATED { d250ms (0), d500ms (1), d1000ms (2), d2000ms (3), d3000ms (4), d4000ms (5), d6000ms (6), d8000ms (7), d12000ms (8), d16000ms (9), d20000ms (10), d24000ms (11), d28000ms (12), d32000ms (13), d64000ms (14)} PeriodLTE ::= ENUMERATED { d1024ms (0), d1280ms (1), d2048ms (2), d2560ms (3), d5120ms (4), d10240ms (5), d1min (6)} PositioningMethod ::= OCTET STRING (SIZE (1)) -- Octet is coded as described in 3GPP TS 32.422 [132]. MeasurementQuantity ::= OCTET STRING (SIZE (1)) -- Octet is coded as described in 3GPP TS 32.422 [132]. EventThreshold1F ::= INTEGER (-120..165) EventThreshold1I ::= INTEGER (-120..-25) JobType ::= ENUMERATED { immediate-MDT-only (0), logged-MDT-only (1), trace-only (2), immediate-MDT-and-trace (3)} AreaScope ::= SEQUENCE { cgi-List [0] CGI-List OPTIONAL, e-utran-cgi-List [1] E-UTRAN-CGI-List OPTIONAL, routingAreaId-List [2] RoutingAreaId-List OPTIONAL, locationAreaId-List [3] LocationAreaId-List OPTIONAL, trackingAreaId-List [4] TrackingAreaId-List OPTIONAL, extensionContainer [5] ExtensionContainer OPTIONAL, ... } CGI-List ::= SEQUENCE SIZE (1..32) OF GlobalCellId E-UTRAN-CGI-List ::= SEQUENCE SIZE (1..32) OF E-UTRAN-CGI RoutingAreaId-List ::= SEQUENCE SIZE (1..8) OF RAIdentity LocationAreaId-List ::= SEQUENCE SIZE (1..8) OF LAIFixedLength TrackingAreaId-List ::= SEQUENCE SIZE (1..8) OF TA-Id ListOfMeasurements ::= OCTET STRING (SIZE (4)) -- Octets are coded as described in 3GPP TS 32.422. ReportingTrigger ::= OCTET STRING (SIZE (1)) -- Octet is coded as described in 3GPP TS 32.422. ReportInterval ::= ENUMERATED { umts250ms (0), umts500ms (1), umts1000ms (2), umts2000ms (3), umts3000ms (4), umts4000ms (5), umts6000ms (6), umts8000ms (7), umts12000ms (8), umts16000ms (9), umts20000ms (10), umts24000ms (11), umts28000ms (12), umts32000ms (13), umts64000ms (14), lte120ms (15), lte240ms (16), lte480ms (17), lte640ms (18), lte1024ms (19), lte2048ms (20), lte5120ms (21), lte10240ms (22), lte1min (23), lte6min (24), lte12min (25), lte30min (26), lte60min (27)} ReportAmount ::= ENUMERATED { d1 (0), d2 (1), d4 (2), d8 (3), d16 (4), d32 (5), d64 (6), infinity (7)} EventThresholdRSRP ::= INTEGER (0..97) EventThresholdRSRQ ::= INTEGER (0..34) LoggingInterval ::= ENUMERATED { d1dot28 (0), d2dot56 (1), d5dot12 (2), d10dot24 (3), d20dot48 (4), d30dot72 (5), d40dot96 (6), d61dot44 (7)} LoggingDuration ::= ENUMERATED { d600sec (0), d1200sec (1), d2400sec (2), d3600sec (3), d5400sec (4), d7200sec (5)} TraceReference ::= OCTET STRING (SIZE (1..2)) TraceReference2 ::= OCTET STRING (SIZE (3)) TraceRecordingSessionReference ::= OCTET STRING (SIZE (2)) TraceType ::= INTEGER (0..255) -- Trace types are fully defined in 3GPP TS 52.008. [61] TraceDepthList ::= SEQUENCE { msc-s-TraceDepth [0] TraceDepth OPTIONAL, mgw-TraceDepth [1] TraceDepth OPTIONAL, sgsn-TraceDepth [2] TraceDepth OPTIONAL, ggsn-TraceDepth [3] TraceDepth OPTIONAL, rnc-TraceDepth [4] TraceDepth OPTIONAL, bmsc-TraceDepth [5] TraceDepth OPTIONAL, ... , mme-TraceDepth [6] TraceDepth OPTIONAL, sgw-TraceDepth [7] TraceDepth OPTIONAL, pgw-TraceDepth [8] TraceDepth OPTIONAL, eNB-TraceDepth [9] TraceDepth OPTIONAL, msc-s-TraceDepthExtension [10] TraceDepthExtension OPTIONAL, mgw-TraceDepthExtension [11] TraceDepthExtension OPTIONAL, sgsn-TraceDepthExtension [12] TraceDepthExtension OPTIONAL, ggsn-TraceDepthExtension [13] TraceDepthExtension OPTIONAL, rnc-TraceDepthExtension [14] TraceDepthExtension OPTIONAL, bmsc-TraceDepthExtension [15] TraceDepthExtension OPTIONAL, mme-TraceDepthExtension [16] TraceDepthExtension OPTIONAL, sgw-TraceDepthExtension [17] TraceDepthExtension OPTIONAL, pgw-TraceDepthExtension [18] TraceDepthExtension OPTIONAL, eNB-TraceDepthExtension [19] TraceDepthExtension OPTIONAL } -- If one of the TraceDepthExtension types is sent, the corresponding TraceDepth type -- shall also be sent with the same enumeration value to allow the receiver not supporting -- the Extension to fall back to the non extended type. -- If one of the TraceDepthExtension types is received and supported, the corresponding -- TraceDepth type shall be ignored. TraceDepth ::= ENUMERATED { minimum (0), medium (1), maximum (2), ...} -- The value medium is applicable only for RNC. For other network elements, if value medium -- is received, value minimum shall be applied. TraceDepthExtension ::= ENUMERATED { minimumWithoutVendorSpecificExtension (0), mediumWithoutVendorSpecificExtension (1), maximumWithoutVendorSpecificExtension (2), ...} -- The value mediumWithoutVendorSpecificExtension is applicable only for RNC. For other -- network elements, if value mediumWithoutVendorSpecificExtension is received, value -- minimumWithoutVendorSpecificExtension shall be applied. TraceNE-TypeList ::= BIT STRING { msc-s (0), mgw (1), sgsn (2), ggsn (3), rnc (4), bm-sc (5) , mme (6), sgw (7), pgw (8), eNB (9)} (SIZE (6..16)) -- Other bits than listed above shall be discarded. TraceInterfaceList ::= SEQUENCE { msc-s-List [0] MSC-S-InterfaceList OPTIONAL, mgw-List [1] MGW-InterfaceList OPTIONAL, sgsn-List [2] SGSN-InterfaceList OPTIONAL, ggsn-List [3] GGSN-InterfaceList OPTIONAL, rnc-List [4] RNC-InterfaceList OPTIONAL, bmsc-List [5] BMSC-InterfaceList OPTIONAL, ..., mme-List [6] MME-InterfaceList OPTIONAL, sgw-List [7] SGW-InterfaceList OPTIONAL, pgw-List [8] PGW-InterfaceList OPTIONAL, eNB-List [9] ENB-InterfaceList OPTIONAL} MSC-S-InterfaceList ::= BIT STRING { a (0), iu (1), mc (2), map-g (3), map-b (4), map-e (5), map-f (6), cap (7), map-d (8), map-c (9)} (SIZE (10..16)) -- Other bits than listed above shall be discarded. MGW-InterfaceList ::= BIT STRING { mc (0), nb-up (1), iu-up (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. SGSN-InterfaceList ::= BIT STRING { gb (0), iu (1), gn (2), map-gr (3), map-gd (4), map-gf (5), gs (6), ge (7), s3 (8), s4 (9), s6d (10)} (SIZE (8..16)) -- Other bits than listed above shall be discarded. GGSN-InterfaceList ::= BIT STRING { gn (0), gi (1), gmb (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. RNC-InterfaceList ::= BIT STRING { iu (0), iur (1), iub (2), uu (3)} (SIZE (4..8)) -- Other bits than listed above shall be discarded. BMSC-InterfaceList ::= BIT STRING { gmb (0)} (SIZE (1..8)) -- Other bits than listed above shall be discarded. MME-InterfaceList ::= BIT STRING { s1-mme (0), s3 (1), s6a (2), s10 (3), s11 (4)} (SIZE (5..8)) -- Other bits than listed above shall be discarded. SGW-InterfaceList ::= BIT STRING { s4 (0), s5 (1), s8b (2), s11 (3), gxc (4)} (SIZE (5..8)) -- Other bits than listed above shall be discarded. PGW-InterfaceList ::= BIT STRING { s2a (0), s2b (1), s2c (2), s5 (3), s6b (4), gx (5), s8b (6), sgi (7)} (SIZE (8..16)) -- Other bits than listed above shall be discarded. ENB-InterfaceList ::= BIT STRING { s1-mme (0), x2 (1), uu (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. TraceEventList ::= SEQUENCE { msc-s-List [0] MSC-S-EventList OPTIONAL, mgw-List [1] MGW-EventList OPTIONAL, sgsn-List [2] SGSN-EventList OPTIONAL, ggsn-List [3] GGSN-EventList OPTIONAL, bmsc-List [4] BMSC-EventList OPTIONAL, ..., mme-List [5] MME-EventList OPTIONAL, sgw-List [6] SGW-EventList OPTIONAL, pgw-List [7] PGW-EventList OPTIONAL} MSC-S-EventList ::= BIT STRING { mo-mtCall (0), mo-mt-sms (1), lu-imsiAttach-imsiDetach (2), handovers (3), ss (4)} (SIZE (5..16)) -- Other bits than listed above shall be discarded. MGW-EventList ::= BIT STRING { context (0)} (SIZE (1..8)) -- Other bits than listed above shall be discarded. SGSN-EventList ::= BIT STRING { pdpContext (0), mo-mt-sms (1), rau-gprsAttach-gprsDetach (2), mbmsContext (3)} (SIZE (4..16)) -- Other bits than listed above shall be discarded. GGSN-EventList ::= BIT STRING { pdpContext (0), mbmsContext (1)} (SIZE (2..8)) -- Other bits than listed above shall be discarded. BMSC-EventList ::= BIT STRING { mbmsMulticastServiceActivation (0)} (SIZE (1..8)) -- Other bits than listed above shall be discarded. MME-EventList ::= BIT STRING { ue-initiatedPDNconectivityRequest (0), serviceRequestts (1), initialAttachTrackingAreaUpdateDetach (2), ue-initiatedPDNdisconnection (3), bearerActivationModificationDeletion (4), handover (5)} (SIZE (6..8)) -- Other bits than listed above shall be discarded. SGW-EventList ::= BIT STRING { pdn-connectionCreation (0), pdn-connectionTermination (1), bearerActivationModificationDeletion (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. PGW-EventList ::= BIT STRING { pdn-connectionCreation (0), pdn-connectionTermination (1), bearerActivationModificationDeletion (2)} (SIZE (3..8)) -- Other bits than listed above shall be discarded. TracePropagationList ::= SEQUENCE { traceReference [0] TraceReference OPTIONAL, traceType [1] TraceType OPTIONAL, traceReference2 [2] TraceReference2 OPTIONAL, traceRecordingSessionReference [3] TraceRecordingSessionReference OPTIONAL, rnc-TraceDepth [4] TraceDepth OPTIONAL, rnc-InterfaceList [5] RNC-InterfaceList OPTIONAL, msc-s-TraceDepth [6] TraceDepth OPTIONAL, msc-s-InterfaceList [7] MSC-S-InterfaceList OPTIONAL, msc-s-EventList [8] MSC-S-EventList OPTIONAL, mgw-TraceDepth [9] TraceDepth OPTIONAL, mgw-InterfaceList [10] MGW-InterfaceList OPTIONAL, mgw-EventList [11] MGW-EventList OPTIONAL, ..., rnc-TraceDepthExtension [12] TraceDepthExtension OPTIONAL, msc-s-TraceDepthExtension [13] TraceDepthExtension OPTIONAL, mgw-TraceDepthExtension [14] TraceDepthExtension OPTIONAL } -- If one of the TraceDepthExtension types is sent, the corresponding TraceDepth type -- shall also be sent with the same enumeration value to allow the receiver not supporting -- the Extension to fall back to the non extended type. -- If one of the TraceDepthExtension types is received and supported, the corresponding -- TraceDepth type shall be ignored. ActivateTraceModeRes ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ..., traceSupportIndicator [1] NULL OPTIONAL } DeactivateTraceModeArg ::= SEQUENCE { imsi [0] IMSI OPTIONAL, traceReference [1] TraceReference, extensionContainer [2] ExtensionContainer OPTIONAL, ..., traceReference2 [3] TraceReference2 OPTIONAL } DeactivateTraceModeRes ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ...} .#END 17.7.3 Call handling data types .$MAP-CH-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CH-DataTypes (13) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS SendRoutingInfoArg, SendRoutingInfoRes, ProvideRoamingNumberArg, ProvideRoamingNumberRes, ResumeCallHandlingArg, ResumeCallHandlingRes, NumberOfForwarding, SuppressionOfAnnouncement, CallReferenceNumber, SetReportingStateArg, SetReportingStateRes, StatusReportArg, StatusReportRes, RemoteUserFreeArg, RemoteUserFreeRes, IST-AlertArg, IST-AlertRes, IST-CommandArg, IST-CommandRes, UU-Data, ReleaseResourcesArg, ReleaseResourcesRes ; IMPORTS SubscriberInfo, SupportedCamelPhases, OfferedCamel4CSIs, CUG-Interlock, O-CSI, D-CSI, O-BcsmCamelTDPCriteriaList, T-BCSM-CAMEL-TDP-CriteriaList, IST-SupportIndicator, IST-AlertTimerValue, T-CSI, NumberPortabilityStatus, PagingArea FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} ForwardingOptions, SS-List, CCBS-Feature FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} ISDN-AddressString, ISDN-SubaddressString, FTN-AddressString, ExternalSignalInfo, Ext-ExternalSignalInfo, IMSI, LMSI, Ext-BasicServiceCode, AlertingPattern, NAEA-PreferredCI, EMLPP-Priority, PLMN-Id FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; CUG-CheckInfo ::= SEQUENCE { cug-Interlock CUG-Interlock, cug-OutgoingAccess NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} NumberOfForwarding ::= INTEGER (1..5) SendRoutingInfoArg ::= SEQUENCE { msisdn [0] ISDN-AddressString, cug-CheckInfo [1] CUG-CheckInfo OPTIONAL, numberOfForwarding [2] NumberOfForwarding OPTIONAL, interrogationType [3] InterrogationType, or-Interrogation [4] NULL OPTIONAL, or-Capability [5] OR-Phase OPTIONAL, gmsc-OrGsmSCF-Address [6] ISDN-AddressString, callReferenceNumber [7] CallReferenceNumber OPTIONAL, forwardingReason [8] ForwardingReason OPTIONAL, basicServiceGroup [9] Ext-BasicServiceCode OPTIONAL, networkSignalInfo [10] ExternalSignalInfo OPTIONAL, camelInfo [11] CamelInfo OPTIONAL, suppressionOfAnnouncement [12] SuppressionOfAnnouncement OPTIONAL, extensionContainer [13] ExtensionContainer OPTIONAL, ..., alertingPattern [14] AlertingPattern OPTIONAL, ccbs-Call [15] NULL OPTIONAL, supportedCCBS-Phase [16] SupportedCCBS-Phase OPTIONAL, additionalSignalInfo [17] Ext-ExternalSignalInfo OPTIONAL, istSupportIndicator [18] IST-SupportIndicator OPTIONAL, pre-pagingSupported [19] NULL OPTIONAL, callDiversionTreatmentIndicator [20] CallDiversionTreatmentIndicator OPTIONAL, longFTN-Supported [21] NULL OPTIONAL, suppress-VT-CSI [22] NULL OPTIONAL, suppressIncomingCallBarring [23] NULL OPTIONAL, gsmSCF-InitiatedCall [24] NULL OPTIONAL, basicServiceGroup2 [25] Ext-BasicServiceCode OPTIONAL, networkSignalInfo2 [26] ExternalSignalInfo OPTIONAL, suppressMTSS [27] SuppressMTSS OPTIONAL, mtRoamingRetrySupported [28] NULL OPTIONAL, callPriority [29] EMLPP-Priority OPTIONAL } SuppressionOfAnnouncement ::= NULL SuppressMTSS ::= BIT STRING { suppressCUG (0), suppressCCBS (1) } (SIZE (2..16)) -- Other bits than listed above shall be discarded InterrogationType ::= ENUMERATED { basicCall (0), forwarding (1)} OR-Phase ::= INTEGER (1..127) CallReferenceNumber ::= OCTET STRING (SIZE (1..8)) ForwardingReason ::= ENUMERATED { notReachable (0), busy (1), noReply (2)} SupportedCCBS-Phase ::= INTEGER (1..127) -- exception handling: -- Only value 1 is used. -- Values in the ranges 2-127 are reserved for future use. -- If received values 2-127 shall be mapped on to value 1. CallDiversionTreatmentIndicator ::= OCTET STRING (SIZE(1)) -- callDiversionAllowed (xxxx xx01) -- callDiversionNotAllowed (xxxx xx10) -- network default is call diversion allowed SendRoutingInfoRes ::= [3] SEQUENCE { imsi [9] IMSI OPTIONAL, -- IMSI must be present if SendRoutingInfoRes is not segmented. -- If the TC-Result-NL segmentation option is taken the IMSI must be -- present in one segmented transmission of SendRoutingInfoRes. extendedRoutingInfo ExtendedRoutingInfo OPTIONAL, cug-CheckInfo [3] CUG-CheckInfo OPTIONAL, cugSubscriptionFlag [6] NULL OPTIONAL, subscriberInfo [7] SubscriberInfo OPTIONAL, ss-List [1] SS-List OPTIONAL, basicService [5] Ext-BasicServiceCode OPTIONAL, forwardingInterrogationRequired [4] NULL OPTIONAL, vmsc-Address [2] ISDN-AddressString OPTIONAL, extensionContainer [0] ExtensionContainer OPTIONAL, ... , naea-PreferredCI [10] NAEA-PreferredCI OPTIONAL, -- naea-PreferredCI is included at the discretion of the HLR operator."
"ccbs-Indicators [11] CCBS-Indicators OPTIONAL, msisdn [12] ISDN-AddressString OPTIONAL, numberPortabilityStatus [13] NumberPortabilityStatus OPTIONAL, istAlertTimer [14] IST-AlertTimerValue OPTIONAL, supportedCamelPhasesInVMSC [15] SupportedCamelPhases OPTIONAL, offeredCamel4CSIsInVMSC [16] OfferedCamel4CSIs OPTIONAL, routingInfo2 [17] RoutingInfo OPTIONAL, ss-List2 [18] SS-List OPTIONAL, basicService2 [19] Ext-BasicServiceCode OPTIONAL, allowedServices [20] AllowedServices OPTIONAL, unavailabilityCause [21] UnavailabilityCause OPTIONAL, releaseResourcesSupported [22] NULL OPTIONAL, gsm-BearerCapability [23] ExternalSignalInfo OPTIONAL } AllowedServices ::= BIT STRING { firstServiceAllowed (0), secondServiceAllowed (1) } (SIZE (2..8)) -- firstService is the service indicated in the networkSignalInfo -- secondService is the service indicated in the networkSignalInfo2 -- Other bits than listed above shall be discarded UnavailabilityCause ::= ENUMERATED { bearerServiceNotProvisioned (1), teleserviceNotProvisioned (2), absentSubscriber (3), busySubscriber (4), callBarred (5), cug-Reject (6), ...} -- exception handling: -- Reception of other values than the ones listed shall result in the service -- being unavailable for that call. CCBS-Indicators ::= SEQUENCE { ccbs-Possible [0] NULL OPTIONAL, keepCCBS-CallIndicator [1] NULL OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} RoutingInfo ::= CHOICE { roamingNumber ISDN-AddressString, forwardingData ForwardingData} ForwardingData ::= SEQUENCE { forwardedToNumber [5] ISDN-AddressString OPTIONAL, -- When this datatype is sent from an HLR which supports CAMEL Phase 2 -- to a GMSC which supports CAMEL Phase 2 the GMSC shall not check the -- format of the number forwardedToSubaddress [4] ISDN-SubaddressString OPTIONAL, forwardingOptions [6] ForwardingOptions OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ..., longForwardedToNumber [8] FTN-AddressString OPTIONAL} ProvideRoamingNumberArg ::= SEQUENCE { imsi [0] IMSI, msc-Number [1] ISDN-AddressString, msisdn [2] ISDN-AddressString OPTIONAL, lmsi [4] LMSI OPTIONAL, gsm-BearerCapability [5] ExternalSignalInfo OPTIONAL, networkSignalInfo [6] ExternalSignalInfo OPTIONAL, suppressionOfAnnouncement [7] SuppressionOfAnnouncement OPTIONAL, gmsc-Address [8] ISDN-AddressString OPTIONAL, callReferenceNumber [9] CallReferenceNumber OPTIONAL, or-Interrogation [10] NULL OPTIONAL, extensionContainer [11] ExtensionContainer OPTIONAL, ... , alertingPattern [12] AlertingPattern OPTIONAL, ccbs-Call [13] NULL OPTIONAL, supportedCamelPhasesInInterrogatingNode [15] SupportedCamelPhases OPTIONAL, additionalSignalInfo [14] Ext-ExternalSignalInfo OPTIONAL, orNotSupportedInGMSC [16] NULL OPTIONAL, pre-pagingSupported [17] NULL OPTIONAL, longFTN-Supported [18] NULL OPTIONAL, suppress-VT-CSI [19] NULL OPTIONAL, offeredCamel4CSIsInInterrogatingNode [20] OfferedCamel4CSIs OPTIONAL, mtRoamingRetrySupported [21] NULL OPTIONAL, pagingArea [22] PagingArea OPTIONAL, callPriority [23] EMLPP-Priority OPTIONAL, mtrf-Indicator [24] NULL OPTIONAL, oldMSC-Number [25] ISDN-AddressString OPTIONAL, lastUsedLtePLMN-Id [26] PLMN-Id OPTIONAL } ProvideRoamingNumberRes ::= SEQUENCE { roamingNumber ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ..., releaseResourcesSupported NULL OPTIONAL, vmsc-Address ISDN-AddressString OPTIONAL } ResumeCallHandlingArg ::= SEQUENCE { callReferenceNumber [0] CallReferenceNumber OPTIONAL, basicServiceGroup [1] Ext-BasicServiceCode OPTIONAL, forwardingData [2] ForwardingData OPTIONAL, imsi [3] IMSI OPTIONAL, cug-CheckInfo [4] CUG-CheckInfo OPTIONAL, o-CSI [5] O-CSI OPTIONAL, extensionContainer [7] ExtensionContainer OPTIONAL, ccbs-Possible [8] NULL OPTIONAL, msisdn [9] ISDN-AddressString OPTIONAL, uu-Data [10] UU-Data OPTIONAL, allInformationSent [11] NULL OPTIONAL, ..., d-csi [12] D-CSI OPTIONAL, o-BcsmCamelTDPCriteriaList [13] O-BcsmCamelTDPCriteriaList OPTIONAL, basicServiceGroup2 [14] Ext-BasicServiceCode OPTIONAL, mtRoamingRetry [15] NULL OPTIONAL } UU-Data ::= SEQUENCE { uuIndicator [0] UUIndicator OPTIONAL, uui [1] UUI OPTIONAL, uusCFInteraction [2] NULL OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} UUIndicator ::= OCTET STRING (SIZE (1)) -- Octets are coded according to ETS 300 356 UUI ::= OCTET STRING (SIZE (1..131)) -- Octets are coded according to ETS 300 356 ResumeCallHandlingRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} CamelInfo ::= SEQUENCE { supportedCamelPhases SupportedCamelPhases, suppress-T-CSI NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , offeredCamel4CSIs [0] OfferedCamel4CSIs OPTIONAL } ExtendedRoutingInfo ::= CHOICE { routingInfo RoutingInfo, camelRoutingInfo [8] CamelRoutingInfo} CamelRoutingInfo ::= SEQUENCE { forwardingData ForwardingData OPTIONAL, gmscCamelSubscriptionInfo [0] GmscCamelSubscriptionInfo, extensionContainer [1] ExtensionContainer OPTIONAL, ...} GmscCamelSubscriptionInfo ::= SEQUENCE { t-CSI [0] T-CSI OPTIONAL, o-CSI [1] O-CSI OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., o-BcsmCamelTDP-CriteriaList [3] O-BcsmCamelTDPCriteriaList OPTIONAL, t-BCSM-CAMEL-TDP-CriteriaList [4] T-BCSM-CAMEL-TDP-CriteriaList OPTIONAL, d-csi [5] D-CSI OPTIONAL} SetReportingStateArg ::= SEQUENCE { imsi [0] IMSI OPTIONAL, lmsi [1] LMSI OPTIONAL, ccbs-Monitoring [2] ReportingState OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} ReportingState ::= ENUMERATED { stopMonitoring (0), startMonitoring (1), ...} -- exception handling: -- reception of values 2-10 shall be mapped to 'stopMonitoring' -- reception of values > 10 shall be mapped to 'startMonitoring' SetReportingStateRes ::= SEQUENCE{ ccbs-SubscriberStatus [0] CCBS-SubscriberStatus OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} CCBS-SubscriberStatus ::= ENUMERATED { ccbsNotIdle (0), ccbsIdle (1), ccbsNotReachable (2), ...} -- exception handling: -- reception of values 3-10 shall be mapped to 'ccbsNotIdle' -- reception of values 11-20 shall be mapped to 'ccbsIdle' -- reception of values > 20 shall be mapped to 'ccbsNotReachable' StatusReportArg ::= SEQUENCE{ imsi [0] IMSI, eventReportData [1] EventReportData OPTIONAL, callReportdata [2] CallReportData OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} EventReportData ::= SEQUENCE{ ccbs-SubscriberStatus [0] CCBS-SubscriberStatus OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ...} CallReportData ::= SEQUENCE{ monitoringMode [0] MonitoringMode OPTIONAL, callOutcome [1] CallOutcome OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ...} MonitoringMode ::= ENUMERATED { a-side (0), b-side (1), ...} -- exception handling: -- reception of values 2-10 shall be mapped 'a-side' -- reception of values > 10 shall be mapped to 'b-side' CallOutcome ::= ENUMERATED { success (0), failure (1), busy (2), ...} -- exception handling: -- reception of values 3-10 shall be mapped to 'success' -- reception of values 11-20 shall be mapped to 'failure' -- reception of values > 20 shall be mapped to 'busy' StatusReportRes ::= SEQUENCE { extensionContainer [0] ExtensionContainer OPTIONAL, ...} RemoteUserFreeArg ::= SEQUENCE{ imsi [0] IMSI, callInfo [1] ExternalSignalInfo, ccbs-Feature [2] CCBS-Feature, translatedB-Number [3] ISDN-AddressString, replaceB-Number [4] NULL OPTIONAL, alertingPattern [5] AlertingPattern OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ...} RemoteUserFreeRes ::= SEQUENCE{ ruf-Outcome [0] RUF-Outcome, extensionContainer [1] ExtensionContainer OPTIONAL, ...} RUF-Outcome ::= ENUMERATED{ accepted (0), rejected (1), noResponseFromFreeMS (2), -- T4 Expiry noResponseFromBusyMS (3), -- T10 Expiry udubFromFreeMS (4), udubFromBusyMS (5), ...} -- exception handling: -- reception of values 6-20 shall be mapped to 'accepted' -- reception of values 21-30 shall be mapped to 'rejected' -- reception of values 31-40 shall be mapped to 'noResponseFromFreeMS' -- reception of values 41-50 shall be mapped to 'noResponseFromBusyMS' -- reception of values 51-60 shall be mapped to 'udubFromFreeMS' -- reception of values > 60 shall be mapped to 'udubFromBusyMS' IST-AlertArg ::= SEQUENCE{ imsi [0] IMSI, extensionContainer [1] ExtensionContainer OPTIONAL, ...} IST-AlertRes ::= SEQUENCE{ istAlertTimer [0] IST-AlertTimerValue OPTIONAL, istInformationWithdraw [1] NULL OPTIONAL, callTerminationIndicator [2] CallTerminationIndicator OPTIONAL, extensionContainer [3] ExtensionContainer OPTIONAL, ...} IST-CommandArg ::= SEQUENCE{ imsi [0] IMSI, extensionContainer [1] ExtensionContainer OPTIONAL, ...} IST-CommandRes ::= SEQUENCE{ extensionContainer ExtensionContainer OPTIONAL, ...} CallTerminationIndicator ::= ENUMERATED { terminateCallActivityReferred (0), terminateAllCallActivities (1), ...} -- exception handling: -- reception of values 2-10 shall be mapped to ' terminateCallActivityReferred ' -- reception of values > 10 shall be mapped to ' terminateAllCallActivities ' -- In MSCs not supporting linkage of all call activities, any value received shall -- be interpreted as ' terminateCallActivityReferred ' ReleaseResourcesArg ::= SEQUENCE{ msrn ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ...} ReleaseResourcesRes ::= SEQUENCE{ extensionContainer ExtensionContainer OPTIONAL, ...} .#END 17.7.4 Supplementary service data types .$MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RegisterSS-Arg, SS-Info, SS-Status, SS-SubscriptionOption, SS-ForBS-Code, InterrogateSS-Res, USSD-Arg, USSD-Res, USSD-DataCodingScheme, USSD-String, Password, GuidanceInfo, SS-List, SS-InfoList, OverrideCategory, CliRestrictionOption, NoReplyConditionTime, ForwardingOptions, maxNumOfSS, SS-Data, SS-InvocationNotificationArg, SS-InvocationNotificationRes, CCBS-Feature, RegisterCC-EntryArg, RegisterCC-EntryRes, EraseCC-EntryArg, EraseCC-EntryRes ; IMPORTS AddressString, ISDN-AddressString, ISDN-SubaddressString, FTN-AddressString, IMSI, BasicServiceCode, AlertingPattern, EMLPP-Priority, MaxMC-Bearers, MC-Bearers, ExternalSignalInfo FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} ; RegisterSS-Arg ::= SEQUENCE { ss-Code SS-Code, basicService BasicServiceCode OPTIONAL, forwardedToNumber [4] AddressString OPTIONAL, forwardedToSubaddress [6] ISDN-SubaddressString OPTIONAL, noReplyConditionTime [5] NoReplyConditionTime OPTIONAL, ..., defaultPriority [7] EMLPP-Priority OPTIONAL, nbrUser [8] MC-Bearers OPTIONAL, longFTN-Supported [9] NULL OPTIONAL } NoReplyConditionTime ::= INTEGER (5..30) SS-Info ::= CHOICE { forwardingInfo [0] ForwardingInfo, callBarringInfo [1] CallBarringInfo, ss-Data [3] SS-Data} ForwardingInfo ::= SEQUENCE { ss-Code SS-Code OPTIONAL, forwardingFeatureList ForwardingFeatureList, ...} ForwardingFeatureList ::= SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF ForwardingFeature ForwardingFeature ::= SEQUENCE { basicService BasicServiceCode OPTIONAL, ss-Status [4] SS-Status OPTIONAL, forwardedToNumber [5] ISDN-AddressString OPTIONAL, forwardedToSubaddress [8] ISDN-SubaddressString OPTIONAL, forwardingOptions [6] ForwardingOptions OPTIONAL, noReplyConditionTime [7] NoReplyConditionTime OPTIONAL, ..., longForwardedToNumber [9] FTN-AddressString OPTIONAL } SS-Status ::= OCTET STRING (SIZE (1)) -- bits 8765: 0000 (unused) -- bits 4321: Used to convey the ""P bit"",""R bit"",""A bit"" and ""Q bit"", -- representing supplementary service state information -- as defined in TS 3GPP TS 23.011 [22] -- bit 4: ""Q bit"" -- bit 3: ""P bit"" -- bit 2: ""R bit"" -- bit 1: ""A bit"" ForwardingOptions ::= OCTET STRING (SIZE (1)) -- bit 8: notification to forwarding party -- 0 no notification -- 1 notification -- bit 7: redirecting presentation -- 0 no presentation -- 1 presentation -- bit 6: notification to calling party -- 0 no notification -- 1 notification -- bit 5: 0 (unused) -- bits 43: forwarding reason -- 00 ms not reachable -- 01 ms busy -- 10 no reply -- 11 unconditional when used in a SRI Result, -- or call deflection when used in a RCH Argument -- bits 21: 00 (unused) CallBarringInfo ::= SEQUENCE { ss-Code SS-Code OPTIONAL, callBarringFeatureList CallBarringFeatureList, ...} CallBarringFeatureList ::= SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF CallBarringFeature CallBarringFeature ::= SEQUENCE { basicService BasicServiceCode OPTIONAL, ss-Status [4] SS-Status OPTIONAL, ...} SS-Data ::= SEQUENCE { ss-Code SS-Code OPTIONAL, ss-Status [4] SS-Status OPTIONAL, ss-SubscriptionOption SS-SubscriptionOption OPTIONAL, basicServiceGroupList BasicServiceGroupList OPTIONAL, ..., defaultPriority EMLPP-Priority OPTIONAL, nbrUser [5] MC-Bearers OPTIONAL } SS-SubscriptionOption ::= CHOICE { cliRestrictionOption [2] CliRestrictionOption, overrideCategory [1] OverrideCategory} CliRestrictionOption ::= ENUMERATED { permanent (0), temporaryDefaultRestricted (1), temporaryDefaultAllowed (2)} OverrideCategory ::= ENUMERATED { overrideEnabled (0), overrideDisabled (1)} SS-ForBS-Code ::= SEQUENCE { ss-Code SS-Code, basicService BasicServiceCode OPTIONAL, ..., longFTN-Supported [4] NULL OPTIONAL } GenericServiceInfo ::= SEQUENCE { ss-Status SS-Status, cliRestrictionOption CliRestrictionOption OPTIONAL, ..., maximumEntitledPriority [0] EMLPP-Priority OPTIONAL, defaultPriority [1] EMLPP-Priority OPTIONAL, ccbs-FeatureList [2] CCBS-FeatureList OPTIONAL, nbrSB [3] MaxMC-Bearers OPTIONAL, nbrUser [4] MC-Bearers OPTIONAL, nbrSN [5] MC-Bearers OPTIONAL } CCBS-FeatureList ::= SEQUENCE SIZE (1..maxNumOfCCBS-Requests) OF CCBS-Feature maxNumOfCCBS-Requests INTEGER ::= 5 CCBS-Feature ::= SEQUENCE { ccbs-Index [0] CCBS-Index OPTIONAL, b-subscriberNumber [1] ISDN-AddressString OPTIONAL, b-subscriberSubaddress [2] ISDN-SubaddressString OPTIONAL, basicServiceGroup [3] BasicServiceCode OPTIONAL, ...} CCBS-Index ::= INTEGER (1..maxNumOfCCBS-Requests) InterrogateSS-Res ::= CHOICE { ss-Status [0] SS-Status, basicServiceGroupList [2] BasicServiceGroupList, forwardingFeatureList [3] ForwardingFeatureList, genericServiceInfo [4] GenericServiceInfo } USSD-Arg ::= SEQUENCE { ussd-DataCodingScheme USSD-DataCodingScheme, ussd-String USSD-String, ... , alertingPattern AlertingPattern OPTIONAL, msisdn [0] ISDN-AddressString OPTIONAL } USSD-Res ::= SEQUENCE { ussd-DataCodingScheme USSD-DataCodingScheme, ussd-String USSD-String, ...} USSD-DataCodingScheme ::= OCTET STRING (SIZE (1)) -- The structure of the USSD-DataCodingScheme is defined by -- the Cell Broadcast Data Coding Scheme as described in -- TS 3GPP TS 23.038 [25] USSD-String ::= OCTET STRING (SIZE (1..maxUSSD-StringLength)) -- The structure of the contents of the USSD-String is dependent -- on the USSD-DataCodingScheme as described in TS 3GPP TS 23.038 [25]. maxUSSD-StringLength INTEGER ::= 160 Password ::= NumericString (FROM (""0""|""1""|""2""|""3""|""4""|""5""|""6""|""7""|""8""|""9"")) (SIZE (4)) GuidanceInfo ::= ENUMERATED { enterPW (0), enterNewPW (1), enterNewPW-Again (2)} -- How this information is really delivered to the subscriber -- (display, announcement, ...) is not part of this -- specification. SS-List ::= SEQUENCE SIZE (1..maxNumOfSS) OF SS-Code maxNumOfSS INTEGER ::= 30 SS-InfoList ::= SEQUENCE SIZE (1..maxNumOfSS) OF SS-Info BasicServiceGroupList ::= SEQUENCE SIZE (1..maxNumOfBasicServiceGroups) OF BasicServiceCode maxNumOfBasicServiceGroups INTEGER ::= 13 SS-InvocationNotificationArg ::= SEQUENCE { imsi [0] IMSI, msisdn [1] ISDN-AddressString, ss-Event [2] SS-Code, -- The following SS-Code values are allowed : -- ect SS-Code ::= '00110001'B -- multiPTY SS-Code ::= '01010001'B -- cd SS-Code ::= '00100100'B -- ccbs SS-Code ::= '01000100'B ss-EventSpecification [3] SS-EventSpecification OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., b-subscriberNumber [5] ISDN-AddressString OPTIONAL, ccbs-RequestState [6] CCBS-RequestState OPTIONAL } CCBS-RequestState ::= ENUMERATED { request (0), recall (1), active (2), completed (3), suspended (4), frozen (5), deleted (6) } SS-InvocationNotificationRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ... } SS-EventSpecification ::= SEQUENCE SIZE (1..maxEventSpecification) OF AddressString maxEventSpecification INTEGER ::= 2 RegisterCC-EntryArg ::= SEQUENCE { ss-Code [0] SS-Code, ccbs-Data [1] CCBS-Data OPTIONAL, ...} CCBS-Data ::= SEQUENCE { ccbs-Feature [0] CCBS-Feature, translatedB-Number [1] ISDN-AddressString, serviceIndicator [2] ServiceIndicator OPTIONAL, callInfo [3] ExternalSignalInfo, networkSignalInfo [4] ExternalSignalInfo, ...} ServiceIndicator ::= BIT STRING { clir-invoked (0), camel-invoked (1)} (SIZE(2..32)) -- exception handling: -- bits 2 to 31 shall be ignored if received and not understood RegisterCC-EntryRes ::= SEQUENCE { ccbs-Feature [0] CCBS-Feature OPTIONAL, ...} EraseCC-EntryArg ::= SEQUENCE { ss-Code [0] SS-Code, ccbs-Index [1] CCBS-Index OPTIONAL, ...} EraseCC-EntryRes ::= SEQUENCE { ss-Code [0] SS-Code, ss-Status [1] SS-Status OPTIONAL, ...} .#END 17.7.5 Supplementary service codes .$MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} DEFINITIONS ::= BEGIN SS-Code ::= OCTET STRING (SIZE (1)) -- This type is used to represent the code identifying a single -- supplementary service, a group of supplementary services, or -- all supplementary services. The services and abbreviations -- used are defined in TS 3GPP TS 22.004 [5]. The internal structure is -- defined as follows: -- -- bits 87654321: group (bits 8765), and specific service -- (bits 4321) allSS SS-Code ::= '00000000'B -- reserved for possible future use -- all SS allLineIdentificationSS SS-Code ::= '00010000'B -- reserved for possible future use -- all line identification SS clip SS-Code ::= '00010001'B -- calling line identification presentation clir SS-Code ::= '00010010'B -- calling line identification restriction colp SS-Code ::= '00010011'B -- connected line identification presentation colr SS-Code ::= '00010100'B -- connected line identification restriction mci SS-Code ::= '00010101'B -- reserved for possible future use -- malicious call identification allNameIdentificationSS SS-Code ::= '00011000'B -- all name identification SS cnap SS-Code ::= '00011001'B -- calling name presentation -- SS-Codes '00011010'B to '00011111'B are reserved for future -- NameIdentification Supplementary Service use. allForwardingSS SS-Code ::= '00100000'B -- all forwarding SS cfu SS-Code ::= '00100001'B -- call forwarding unconditional allCondForwardingSS SS-Code ::= '00101000'B -- all conditional forwarding SS cfb SS-Code ::= '00101001'B -- call forwarding on mobile subscriber busy cfnry SS-Code ::= '00101010'B -- call forwarding on no reply cfnrc SS-Code ::= '00101011'B -- call forwarding on mobile subscriber not reachable cd SS-Code ::= '00100100'B -- call deflection allCallOfferingSS SS-Code ::= '00110000'B -- reserved for possible future use -- all call offering SS includes also all forwarding SS ect SS-Code ::= '00110001'B -- explicit call transfer mah SS-Code ::= '00110010'B -- reserved for possible future use -- mobile access hunting allCallCompletionSS SS-Code ::= '01000000'B -- reserved for possible future use -- all Call completion SS cw SS-Code ::= '01000001'B -- call waiting hold SS-Code ::= '01000010'B -- call hold ccbs-A SS-Code ::= '01000011'B -- completion of call to busy subscribers, originating side -- this SS-Code is used only in InsertSubscriberData, DeleteSubscriberData -- and InterrogateSS ccbs-B SS-Code ::= '01000100'B -- completion of call to busy subscribers, destination side -- this SS-Code is used only in InsertSubscriberData and DeleteSubscriberData mc SS-Code ::= '01000101'B -- multicall allMultiPartySS SS-Code ::= '01010000'B -- reserved for possible future use -- all multiparty SS multiPTY SS-Code ::= '01010001'B -- multiparty allCommunityOfInterest-SS SS-Code ::= '01100000'B -- reserved for possible future use -- all community of interest SS cug SS-Code ::= '01100001'B -- closed user group allChargingSS SS-Code ::= '01110000'B -- reserved for possible future use -- all charging SS aoci SS-Code ::= '01110001'B -- advice of charge information aocc SS-Code ::= '01110010'B -- advice of charge charging allAdditionalInfoTransferSS SS-Code ::= '10000000'B -- reserved for possible future use -- all additional information transfer SS uus1 SS-Code ::= '10000001'B -- UUS1 user-to-user signalling uus2 SS-Code ::= '10000010'B -- UUS2 user-to-user signalling uus3 SS-Code ::= '10000011'B -- UUS3 user-to-user signalling allBarringSS SS-Code ::= '10010000'B -- all barring SS barringOfOutgoingCalls SS-Code ::= '10010001'B -- barring of outgoing calls baoc SS-Code ::= '10010010'B -- barring of all outgoing calls boic SS-Code ::= '10010011'B -- barring of outgoing international calls boicExHC SS-Code ::= '10010100'B -- barring of outgoing international calls except those directed -- to the home PLMN Country barringOfIncomingCalls SS-Code ::= '10011001'B -- barring of incoming calls baic SS-Code ::= '10011010'B -- barring of all incoming calls bicRoam SS-Code ::= '10011011'B -- barring of incoming calls when roaming outside home PLMN -- Country allPLMN-specificSS SS-Code ::= '11110000'B plmn-specificSS-1 SS-Code ::= '11110001'B plmn-specificSS-2 SS-Code ::= '11110010'B plmn-specificSS-3 SS-Code ::= '11110011'B plmn-specificSS-4 SS-Code ::= '11110100'B plmn-specificSS-5 SS-Code ::= '11110101'B plmn-specificSS-6 SS-Code ::= '11110110'B plmn-specificSS-7 SS-Code ::= '11110111'B plmn-specificSS-8 SS-Code ::= '11111000'B plmn-specificSS-9 SS-Code ::= '11111001'B plmn-specificSS-A SS-Code ::= '11111010'B plmn-specificSS-B SS-Code ::= '11111011'B plmn-specificSS-C SS-Code ::= '11111100'B plmn-specificSS-D SS-Code ::= '11111101'B plmn-specificSS-E SS-Code ::= '11111110'B plmn-specificSS-F SS-Code ::= '11111111'B allCallPrioritySS SS-Code ::= '10100000'B -- reserved for possible future use -- all call priority SS emlpp SS-Code ::= '10100001'B -- enhanced Multilevel Precedence Pre-emption (EMLPP) service allLCSPrivacyException SS-Code ::= '10110000'B -- all LCS Privacy Exception Classes universal SS-Code ::= '10110001'B -- allow location by any LCS client callSessionRelated SS-Code ::= '10110010'B -- allow location by any value added LCS client to which a call/session -- is established from the target MS callSessionUnrelated SS-Code ::= '10110011'B -- allow location by designated external value added LCS clients plmnoperator SS-Code ::= '10110100'B -- allow location by designated PLMN operator LCS clients serviceType SS-Code ::= '10110101'B -- allow location by LCS clients of a designated LCS service type allMOLR-SS SS-Code ::= '11000000'B -- all Mobile Originating Location Request Classes basicSelfLocation SS-Code ::= '11000001'B -- allow an MS to request its own location autonomousSelfLocation SS-Code ::= '11000010'B -- allow an MS to perform self location without interaction -- with the PLMN for a predetermined period of time transferToThirdParty SS-Code ::= '11000011'B -- allow an MS to request transfer of its location to another LCS client .#END 17.7.6 Short message data types .$MAP-SM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RoutingInfoForSM-Arg, RoutingInfoForSM-Res, MO-ForwardSM-Arg, MO-ForwardSM-Res, MT-ForwardSM-Arg, MT-ForwardSM-Res, ReportSM-DeliveryStatusArg, ReportSM-DeliveryStatusRes, AlertServiceCentreArg, InformServiceCentreArg, ReadyForSM-Arg, ReadyForSM-Res, SM-DeliveryOutcome, AlertReason, Additional-Number, MT-ForwardSM-VGCS-Arg, MT-ForwardSM-VGCS-Res ; IMPORTS AddressString, ISDN-AddressString, SignalInfo, IMSI, LMSI, ASCI-CallReference, Time, NetworkNodeDiameterAddress, HLR-Id FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} AbsentSubscriberDiagnosticSM FROM MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; RoutingInfoForSM-Arg ::= SEQUENCE { msisdn [0] ISDN-AddressString, sm-RP-PRI [1] BOOLEAN, serviceCentreAddress [2] AddressString, extensionContainer [6] ExtensionContainer OPTIONAL, ... , gprsSupportIndicator [7] NULL OPTIONAL, -- gprsSupportIndicator is set only if the SMS-GMSC supports -- receiving of two numbers from the HLR sm-RP-MTI [8] SM-RP-MTI OPTIONAL, sm-RP-SMEA [9] SM-RP-SMEA OPTIONAL, sm-deliveryNotIntended [10] SM-DeliveryNotIntended OPTIONAL, ip-sm-gwGuidanceIndicator [11] NULL OPTIONAL, imsi [12] IMSI OPTIONAL, t4-Trigger-Indicator [14] NULL OPTIONAL, singleAttemptDelivery [13] NULL OPTIONAL, correlationID [15] CorrelationID OPTIONAL, smsf-supportIndicator [16] NULL OPTIONAL } SM-DeliveryNotIntended ::= ENUMERATED { onlyIMSI-requested (0), onlyMCC-MNC-requested (1), ...} SM-RP-MTI ::= INTEGER (0..10) -- 0 SMS Deliver -- 1 SMS Status Report -- other values are reserved for future use and shall be discarded if -- received SM-RP-SMEA ::= OCTET STRING (SIZE (1..12)) -- this parameter contains an address field which is encoded -- as defined in 3GPP TS 23.040. An address field contains 3 elementsÊ: -- address-length -- type-of-address -- address-value RoutingInfoForSM-Res ::= SEQUENCE { imsi IMSI, locationInfoWithLMSI [0] LocationInfoWithLMSI, extensionContainer [4] ExtensionContainer OPTIONAL, ..., ip-sm-gwGuidance [5] IP-SM-GW-Guidance OPTIONAL } IP-SM-GW-Guidance ::= SEQUENCE { minimumDeliveryTimeValue SM-DeliveryTimerValue, recommendedDeliveryTimeValue SM-DeliveryTimerValue, extensionContainer ExtensionContainer OPTIONAL, ...} LocationInfoWithLMSI ::= SEQUENCE { networkNode-Number [1] ISDN-AddressString, lmsi LMSI OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., gprsNodeIndicator [5] NULL OPTIONAL, -- gprsNodeIndicator is set only if the SGSN number is sent as the -- Network Node Number additional-Number [6] Additional-Number OPTIONAL, networkNodeDiameterAddress [7] NetworkNodeDiameterAddress OPTIONAL, additionalNetworkNodeDiameterAddress [8] NetworkNodeDiameterAddress OPTIONAL, thirdNumber [9] Additional-Number OPTIONAL, thirdNetworkNodeDiameterAddress [10] NetworkNodeDiameterAddress OPTIONAL, imsNodeIndicator [11] NULL OPTIONAL, -- gprsNodeIndicator and imsNodeIndicator shall not both be present. -- additionalNumber and thirdNumber shall not both contain the same type of number. smsf-3gpp-Number [12] ISDN-AddressString OPTIONAL, smsf-3gpp-DiameterAddress [13] NetworkNodeDiameterAddress OPTIONAL, smsf-non-3gpp-Number [14] ISDN-AddressString OPTIONAL, smsf-non-3gpp-DiameterAddress [15] NetworkNodeDiameterAddress OPTIONAL, smsf-3gpp-address-indicator [16] NULL OPTIONAL, smsf-non-3gpp-address-indicator [17] NULL OPTIONAL -- -- If smsf-supportIndicator was not included in the request, in RoutingInfoForSM-Arg, -- then smsf-3gpp Number/DiameterAddress, smsf-non-3gpp Number/DiameterAddress and -- smsf-address-indicator and smsf-non-3gpp-address-indicator shall be absent. -- -- If smsf-3gpp-address-indicator is present, it indicates that the networkNode-Number -- (and networkNodeDiameterAddress, if present) contains the address of an SMSF for -- 3GPP access. -- -- If smsf-non-3gpp-address-indicator is present, it indicates that the -- networkNode-Number (and networkNodeDiameterAddress, if present) contains the -- address of an SMSF for non 3GPP access. -- -- At most one of gprsNodeIndicator, imsNodeIndicator, smsf-3gpp-address-indicator -- and smsf-non-3gpp-address-indicator shall be present. Absence of all these -- indicators indicate that the networkNode-Number (and networkNodeDiameterAddress, -- if present) contains the address of an MSC/MME. } Additional-Number ::= CHOICE { msc-Number [0] ISDN-AddressString, sgsn-Number [1] ISDN-AddressString} -- msc-number can be the MSC number or -- the SMS Router number or the MME number for MT SMS -- sgsn-number can be the SGSN number or the SMS Router number MO-ForwardSM-Arg ::= SEQUENCE { sm-RP-DA SM-RP-DA, sm-RP-OA SM-RP-OA, sm-RP-UI SignalInfo, extensionContainer ExtensionContainer OPTIONAL, ... , imsi IMSI OPTIONAL, correlationID [0] CorrelationID OPTIONAL, sm-DeliveryOutcome [1] SM-DeliveryOutcome OPTIONAL } MO-ForwardSM-Res ::= SEQUENCE { sm-RP-UI SignalInfo OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} MT-ForwardSM-Arg ::= SEQUENCE { sm-RP-DA SM-RP-DA, sm-RP-OA SM-RP-OA, sm-RP-UI SignalInfo, moreMessagesToSend NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., smDeliveryTimer SM-DeliveryTimerValue OPTIONAL, smDeliveryStartTime Time OPTIONAL, smsOverIP-OnlyIndicator [0] NULL OPTIONAL, correlationID [1] CorrelationID OPTIONAL, maximumRetransmissionTime [2] Time OPTIONAL, smsGmscAddress [3] ISDN-AddressString OPTIONAL, smsGmscDiameterAddress [4] NetworkNodeDiameterAddress OPTIONAL } -- SM-DeliveryTimerValue contains the value used by the SMS-GMSC CorrelationID ::= SEQUENCE { hlr-id [0] HLR-Id OPTIONAL, sip-uri-A [1] SIP-URI OPTIONAL, sip-uri-B [2] SIP-URI} SIP-URI ::= OCTET STRING -- octets are coded as defined in IETF RFCÊ3261Ê MT-ForwardSM-Res ::= SEQUENCE { sm-RP-UI SignalInfo OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... } SM-RP-DA ::= CHOICE { imsi [0] IMSI, lmsi [1] LMSI, serviceCentreAddressDA [4] AddressString, noSM-RP-DA [5] NULL} SM-RP-OA ::= CHOICE { msisdn [2] ISDN-AddressString, serviceCentreAddressOA [4] AddressString, noSM-RP-OA [5] NULL} SM-DeliveryTimerValue ::= INTEGER (30..600) ReportSM-DeliveryStatusArg ::= SEQUENCE { msisdn ISDN-AddressString, serviceCentreAddress AddressString, sm-DeliveryOutcome SM-DeliveryOutcome, absentSubscriberDiagnosticSM [0] AbsentSubscriberDiagnosticSM OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ..., gprsSupportIndicator [2] NULL OPTIONAL, -- gprsSupportIndicator is set only if the SMS-GMSC supports -- handling of two delivery outcomes deliveryOutcomeIndicator [3] NULL OPTIONAL, -- DeliveryOutcomeIndicator is set when the SM-DeliveryOutcome -- is for GPRS additionalSM-DeliveryOutcome [4] SM-DeliveryOutcome OPTIONAL, -- If received, additionalSM-DeliveryOutcome is for GPRS -- If DeliveryOutcomeIndicator is set, then AdditionalSM-DeliveryOutcome shall be absent additionalAbsentSubscriberDiagnosticSM [5] AbsentSubscriberDiagnosticSM OPTIONAL, -- If received additionalAbsentSubscriberDiagnosticSM is for GPRS -- If DeliveryOutcomeIndicator is set, then AdditionalAbsentSubscriberDiagnosticSM -- shall be absent ip-sm-gw-Indicator [6] NULL OPTIONAL, -- the ip-sm-gw indicator indicates by its presence that sm-deliveryOutcome -- is for delivery via IMS -- If present, deliveryOutcomeIndicator shall be absent. ip-sm-gw-sm-deliveryOutcome [7] SM-DeliveryOutcome OPTIONAL, -- If received ip-sm-gw-sm-deliveryOutcome is for delivery via IMS -- If ip-sm-gw-Indicator is set, then ip-sm-gw-sm-deliveryOutcome shall be absent ip-sm-gw-absentSubscriberDiagnosticSM [8] AbsentSubscriberDiagnosticSM OPTIONAL, -- If received ip-sm-gw-sm-absentSubscriberDiagnosticSM is for delivery via IMS -- If ip-sm-gw-Indicator is set, then ip-sm-gw-sm-absentSubscriberDiagnosticSM -- shall be absent imsi [9] IMSI OPTIONAL, singleAttemptDelivery [10] NULL OPTIONAL, correlationID [11] CorrelationID OPTIONAL, smsf-3gpp-deliveryOutcomeIndicator [12] NULL OPTIONAL, -- smsf-3gpp-deliveryOutcome is set when the SM-DeliveryOutcome -- is for 3GPP-SMSF smsf-3gpp-deliveryOutcome [13] SM-DeliveryOutcome OPTIONAL, -- If smsf-3gpp-deliveryOutcomeIndicator is set, then smsf-3gpp-deliveryOutcome -- shall be absent smsf-3gpp-absentSubscriberDiagSM [14] AbsentSubscriberDiagnosticSM OPTIONAL, -- If smsf-3gpp-deliveryOutcomeIndicator is set, then -- smsf-3gpp-absentSubscriberDiagSM shall be absent smsf-non-3gpp-deliveryOutcomeIndicator [15] NULL OPTIONAL, -- smsf-non-3gpp-deliveryOutcomeIndicator is set when the SM-DeliveryOutcome -- is for non-3GPP-SMSF smsf-non-3gpp-deliveryOutcome [16] SM-DeliveryOutcome OPTIONAL, -- If smsf-non-3gpp-deliveryOutcomeIndicator is set, then smsf-non-3gpp-deliveryOutcome -- shall be absent smsf-non-3gpp-absentSubscriberDiagSM [17] AbsentSubscriberDiagnosticSM OPTIONAL -- If smsf-non-3gpp-deliveryOutcomeIndicator is set, then -- smsf-non-3gpp-absentSubscriberDiagSM shall be absent } SM-DeliveryOutcome ::= ENUMERATED { memoryCapacityExceeded (0), absentSubscriber (1), successfulTransfer (2)} ReportSM-DeliveryStatusRes ::= SEQUENCE { storedMSISDN ISDN-AddressString OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} AlertServiceCentreArg ::= SEQUENCE { msisdn ISDN-AddressString, serviceCentreAddress AddressString, ..., imsi IMSI OPTIONAL, correlationID CorrelationID OPTIONAL, maximumUeAvailabilityTime [0] Time OPTIONAL, smsGmscAlertEvent [1] SmsGmsc-Alert-Event OPTIONAL, smsGmscDiameterAddress [2] NetworkNodeDiameterAddress OPTIONAL, newSGSNNumber [3] ISDN-AddressString OPTIONAL, newSGSNDiameterAddress [4] NetworkNodeDiameterAddress OPTIONAL, newMMENumber [5] ISDN-AddressString OPTIONAL, newMMEDiameterAddress [6] NetworkNodeDiameterAddress OPTIONAL, newMSCNumber [7] ISDN-AddressString OPTIONAL } SmsGmsc-Alert-Event ::= ENUMERATED { msAvailableForMtSms (0), msUnderNewServingNode (1) } InformServiceCentreArg ::= SEQUENCE { storedMSISDN ISDN-AddressString OPTIONAL, mw-Status MW-Status OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , absentSubscriberDiagnosticSM AbsentSubscriberDiagnosticSM OPTIONAL, additionalAbsentSubscriberDiagnosticSM [0] AbsentSubscriberDiagnosticSM OPTIONAL, -- additionalAbsentSubscriberDiagnosticSM may be present only if -- absentSubscriberDiagnosticSM is present. -- if included, additionalAbsentSubscriberDiagnosticSM is for GPRS and -- absentSubscriberDiagnosticSM is for non-GPRS smsf3gppAbsentSubscriberDiagnosticSM [1] AbsentSubscriberDiagnosticSM OPTIONAL, smsfNon3gppAbsentSubscriberDiagnosticSM [2] AbsentSubscriberDiagnosticSM OPTIONAL } MW-Status ::= BIT STRING { sc-AddressNotIncluded (0), mnrf-Set (1), mcef-Set (2) , mnrg-Set (3), mnr5g-Set (4), mnr5gn3g-Set (5)} (SIZE (6..16)) -- exception handling: -- bits 6 to 15 shall be ignored if received and not understood ReadyForSM-Arg ::= SEQUENCE { imsi [0] IMSI, alertReason AlertReason, alertReasonIndicator NULL OPTIONAL, -- alertReasonIndicator is set only when the alertReason -- sent to HLR is for GPRS extensionContainer ExtensionContainer OPTIONAL, ..., additionalAlertReasonIndicator [1] NULL OPTIONAL, -- additionalAlertReasonIndicator is set only when the alertReason -- sent to HLR is for IP-SM-GW maximumUeAvailabilityTime Time OPTIONAL } ReadyForSM-Res ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} AlertReason ::= ENUMERATED { ms-Present (0), memoryAvailable (1)} MT-ForwardSM-VGCS-Arg ::= SEQUENCE { asciCallReference ASCI-CallReference, sm-RP-OA SM-RP-OA, sm-RP-UI SignalInfo, extensionContainer ExtensionContainer OPTIONAL, ...} MT-ForwardSM-VGCS-Res ::= SEQUENCE { sm-RP-UI [0] SignalInfo OPTIONAL, dispatcherList [1] DispatcherList OPTIONAL, ongoingCall NULL OPTIONAL, extensionContainer [2] ExtensionContainer OPTIONAL, ..., additionalDispatcherList [3] AdditionalDispatcherList OPTIONAL } -- additionalDispatcherList shall be absent if dispatcherList is absent or -- contains less than 5 ISDN-AddressStrings DispatcherList ::= SEQUENCE SIZE (1..maxNumOfDispatchers) OF ISDN-AddressString maxNumOfDispatchers INTEGER ::= 5 AdditionalDispatcherList ::= SEQUENCE SIZE (1..maxNumOfAdditionalDispatchers) OF ISDN-AddressString maxNumOfAdditionalDispatchers INTEGER ::= 15 .#END 17.7.7 Error data types .$MAP-ER-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ER-DataTypes (17) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RoamingNotAllowedParam, CallBarredParam, CUG-RejectParam, SS-IncompatibilityCause, PW-RegistrationFailureCause, SM-DeliveryFailureCause, SystemFailureParam, DataMissingParam, UnexpectedDataParam, FacilityNotSupParam, OR-NotAllowedParam, UnknownSubscriberParam, NumberChangedParam, UnidentifiedSubParam, IllegalSubscriberParam, IllegalEquipmentParam, BearerServNotProvParam, TeleservNotProvParam, TracingBufferFullParam, NoRoamingNbParam, AbsentSubscriberParam, BusySubscriberParam, NoSubscriberReplyParam, ForwardingViolationParam, ForwardingFailedParam, ATI-NotAllowedParam, SubBusyForMT-SMS-Param, MessageWaitListFullParam, AbsentSubscriberSM-Param, AbsentSubscriberDiagnosticSM, ResourceLimitationParam, NoGroupCallNbParam, IncompatibleTerminalParam, ShortTermDenialParam, LongTermDenialParam, UnauthorizedRequestingNetwork-Param, UnauthorizedLCSClient-Param, PositionMethodFailure-Param, UnknownOrUnreachableLCSClient-Param, MM-EventNotSupported-Param, ATSI-NotAllowedParam, ATM-NotAllowedParam, IllegalSS-OperationParam, SS-NotAvailableParam, SS-SubscriptionViolationParam, InformationNotAvailableParam, TargetCellOutsideGCA-Param, OngoingGroupCallParam, PositionMethodFailure-Diagnostic, UnauthorizedLCSClient-Diagnostic ; IMPORTS SS-Status FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} SignalInfo, BasicServiceCode, NetworkResource, AdditionalNetworkResource, IMSI, Time FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; RoamingNotAllowedParam ::= SEQUENCE { roamingNotAllowedCause RoamingNotAllowedCause, extensionContainer ExtensionContainer OPTIONAL, ..., additionalRoamingNotAllowedCause [0] AdditionalRoamingNotAllowedCause OPTIONAL } -- if the additionalRoamingNotallowedCause is received by the MSC/VLR or SGSN then the -- roamingNotAllowedCause shall be discarded. AdditionalRoamingNotAllowedCause ::= ENUMERATED { supportedRAT-TypesNotAllowed (0), ...} RoamingNotAllowedCause ::= ENUMERATED { plmnRoamingNotAllowed (0), operatorDeterminedBarring (3)} CallBarredParam ::= CHOICE { callBarringCause CallBarringCause, -- call BarringCause must not be used in version 3 and higher extensibleCallBarredParam ExtensibleCallBarredParam -- extensibleCallBarredParam must not be used in version <3 } CallBarringCause ::= ENUMERATED { barringServiceActive (0), operatorBarring (1)} ExtensibleCallBarredParam ::= SEQUENCE { callBarringCause CallBarringCause OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ... , unauthorisedMessageOriginator [1] NULL OPTIONAL, anonymousCallRejection [2] NULL OPTIONAL } -- unauthorisedMessageOriginator and anonymousCallRejection shall be mutually exclusive. CUG-RejectParam ::= SEQUENCE { cug-RejectCause CUG-RejectCause OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} CUG-RejectCause ::= ENUMERATED { incomingCallsBarredWithinCUG (0), subscriberNotMemberOfCUG (1), requestedBasicServiceViolatesCUG-Constraints (5), calledPartySS-InteractionViolation (7)} SS-IncompatibilityCause ::= SEQUENCE { ss-Code [1] SS-Code OPTIONAL, basicService BasicServiceCode OPTIONAL, ss-Status [4] SS-Status OPTIONAL, ...} PW-RegistrationFailureCause ::= ENUMERATED { undetermined (0), invalidFormat (1), newPasswordsMismatch (2)} SM-EnumeratedDeliveryFailureCause ::= ENUMERATED { memoryCapacityExceeded (0), equipmentProtocolError (1), equipmentNotSM-Equipped (2), unknownServiceCentre (3), sc-Congestion (4), invalidSME-Address (5), subscriberNotSC-Subscriber (6)} SM-DeliveryFailureCause ::= SEQUENCE { sm-EnumeratedDeliveryFailureCause SM-EnumeratedDeliveryFailureCause, diagnosticInfo SignalInfo OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ...} AbsentSubscriberSM-Param ::= SEQUENCE { absentSubscriberDiagnosticSM AbsentSubscriberDiagnosticSM OPTIONAL, -- AbsentSubscriberDiagnosticSM can be either for non-GPRS -- or for GPRS extensionContainer ExtensionContainer OPTIONAL, ..., additionalAbsentSubscriberDiagnosticSM [0] AbsentSubscriberDiagnosticSM OPTIONAL, -- if received, additionalAbsentSubscriberDiagnosticSM -- is for GPRS and absentSubscriberDiagnosticSM is -- for non-GPRS imsi [1] IMSI OPTIONAL, -- when sent from HLR to IP-SM-GW, IMSI shall be present if UNRI is not set -- to indicate that the absent condition is met for CS and PS but not for IMS. requestedRetransmissionTime [2] Time OPTIONAL, userIdentifierAlert [3] IMSI OPTIONAL } AbsentSubscriberDiagnosticSM ::= INTEGER (0..255) -- AbsentSubscriberDiagnosticSM values are defined in 3GPP TS 23.040 SystemFailureParam ::= CHOICE { networkResource NetworkResource, -- networkResource must not be used in version 3 extensibleSystemFailureParam ExtensibleSystemFailureParam -- extensibleSystemFailureParam must not be used in version <3 } ExtensibleSystemFailureParam ::= SEQUENCE { networkResource NetworkResource OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., additionalNetworkResource [0] AdditionalNetworkResource OPTIONAL, failureCauseParam [1] FailureCauseParam OPTIONAL } FailureCauseParam ::= ENUMERATED { limitReachedOnNumberOfConcurrentLocationRequests (0), ... } -- if unknown value is received in FailureCauseParam it shall be ignored DataMissingParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} UnexpectedDataParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., unexpectedSubscriber [0] NULL OPTIONAL} -- the unexpectedSubscriber indication in the unexpectedDataValue error shall not be used -- for operations that allow the unidentifiedSubscriber error. FacilityNotSupParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., shapeOfLocationEstimateNotSupported [0] NULL OPTIONAL, neededLcsCapabilityNotSupportedInServingNode [1] NULL OPTIONAL } OR-NotAllowedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} UnknownSubscriberParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., unknownSubscriberDiagnostic UnknownSubscriberDiagnostic OPTIONAL} UnknownSubscriberDiagnostic ::= ENUMERATED { imsiUnknown (0), gprs-eps-SubscriptionUnknown (1), ..., npdbMismatch (2)} -- if unknown values are received in -- UnknownSubscriberDiagnostic they shall be discarded NumberChangedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} UnidentifiedSubParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} IllegalSubscriberParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} IllegalEquipmentParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} BearerServNotProvParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} TeleservNotProvParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} TracingBufferFullParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} NoRoamingNbParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} AbsentSubscriberParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., absentSubscriberReason [0] AbsentSubscriberReason OPTIONAL} AbsentSubscriberReason ::= ENUMERATED { imsiDetach (0), restrictedArea (1), noPageResponse (2), ... , purgedMS (3), mtRoamingRetry (4), busySubscriber (5)} -- exception handling: at reception of other values than the ones listed the -- AbsentSubscriberReason shall be ignored. -- The AbsentSubscriberReason: purgedMS is defined for the Super-Charger feature -- (see TS 23.116). If this value is received in a Provide Roaming Number response -- it shall be mapped to the AbsentSubscriberReason: imsiDetach in the Send Routeing -- Information response -- The AbsentSubscriberReason: mtRoamingRetry is used during MT Roaming Retry, -- see 3GPP TS 23.018[97]. -- The AbsentSubscriberReason: busySubscriber is used during MT Roaming Forwarding, -- see 3GPP TS 23.018[97]. BusySubscriberParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., ccbs-Possible [0] NULL OPTIONAL, ccbs-Busy [1] NULL OPTIONAL} NoSubscriberReplyParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ForwardingViolationParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ForwardingFailedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ATI-NotAllowedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ATSI-NotAllowedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ATM-NotAllowedParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} IllegalSS-OperationParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} SS-NotAvailableParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} SS-SubscriptionViolationParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} InformationNotAvailableParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} SubBusyForMT-SMS-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ... , gprsConnectionSuspended NULL OPTIONAL } -- If GprsConnectionSuspended is not understood it shall -- be discarded MessageWaitListFullParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ResourceLimitationParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} NoGroupCallNbParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} IncompatibleTerminalParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ShortTermDenialParam ::= SEQUENCE { ...} LongTermDenialParam ::= SEQUENCE { ...} UnauthorizedRequestingNetwork-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} UnauthorizedLCSClient-Param ::= SEQUENCE { unauthorizedLCSClient-Diagnostic [0] UnauthorizedLCSClient-Diagnostic OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... } UnauthorizedLCSClient-Diagnostic ::= ENUMERATED { noAdditionalInformation (0), clientNotInMSPrivacyExceptionList (1), callToClientNotSetup (2), privacyOverrideNotApplicable (3), disallowedByLocalRegulatoryRequirements (4), ..., unauthorizedPrivacyClass (5), unauthorizedCallSessionUnrelatedExternalClient (6), unauthorizedCallSessionRelatedExternalClient (7) } -- exception handling: -- any unrecognized value shall be ignored PositionMethodFailure-Param ::= SEQUENCE { positionMethodFailure-Diagnostic [0] PositionMethodFailure-Diagnostic OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... } PositionMethodFailure-Diagnostic ::= ENUMERATED { congestion (0), insufficientResources (1), insufficientMeasurementData (2), inconsistentMeasurementData (3), locationProcedureNotCompleted (4), locationProcedureNotSupportedByTargetMS (5), qoSNotAttainable (6), positionMethodNotAvailableInNetwork (7), positionMethodNotAvailableInLocationArea (8), ... } -- exception handling: -- any unrecognized value shall be ignored UnknownOrUnreachableLCSClient-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} MM-EventNotSupported-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} TargetCellOutsideGCA-Param ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} OngoingGroupCallParam ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} .#END 17.7.8 Common data types .$MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS -- general data types and values AddressString, ISDN-AddressString, maxISDN-AddressLength, FTN-AddressString, ISDN-SubaddressString, ExternalSignalInfo, Ext-ExternalSignalInfo, AccessNetworkSignalInfo, SignalInfo, maxSignalInfoLength, AlertingPattern, TBCD-STRING, DiameterIdentity, Time, HLR-Id, -- data types for numbering and identification IMSI, TMSI, Identity, SubscriberId, IMEI, HLR-List, LMSI, GlobalCellId, NetworkResource, AdditionalNetworkResource, NAEA-PreferredCI, NAEA-CIC, ASCI-CallReference, SubscriberIdentity, PLMN-Id, E-UTRAN-CGI, NR-CGI, TA-Id, NR-TA-Id, RAIdentity, NetworkNodeDiameterAddress, -- data types for CAMEL CellGlobalIdOrServiceAreaIdOrLAI, CellGlobalIdOrServiceAreaIdFixedLength, LAIFixedLength, -- data types for subscriber management BasicServiceCode, Ext-BasicServiceCode, EMLPP-Info, EMLPP-Priority, MC-SS-Info, MaxMC-Bearers, MC-Bearers, Ext-SS-Status, -- data types for geographic location AgeOfLocationInformation, LCSClientExternalID, LCSClientInternalID, LCSServiceTypeID, -- gprs location registration types GSN-Address ; IMPORTS TeleserviceCode, Ext-TeleserviceCode FROM MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-TS-Code (19) version20 (20)} BearerServiceCode, Ext-BearerServiceCode FROM MAP-BS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-BS-Code (20) version20 (20)} SS-Code FROM MAP-SS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-Code (15) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; -- general data types TBCD-STRING ::= OCTET STRING -- This type (Telephony Binary Coded Decimal String) is used to -- represent several digits from 0 through 9, *, #, a, b, c, two -- digits per octet, each digit encoded 0000 to 1001 (0 to 9), -- 1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c); 1111 used -- as filler when there is an odd number of digits. -- bits 8765 of octet n encoding digit 2n -- bits 4321 of octet n encoding digit 2(n-1) +1 DiameterIdentity ::= OCTET STRING (SIZE(9..255)) -- content of DiameterIdentity is defined in IETF RFC 3588 [139] AddressString ::= OCTET STRING (SIZE (1..maxAddressLength)) -- This type is used to represent a number for addressing -- purposes. It is composed of -- a) one octet for nature of address, and numbering plan -- indicator. -- b) digits of an address encoded as TBCD-String. -- a) The first octet includes a one bit extension indicator, a -- 3 bits nature of address indicator and a 4 bits numbering -- plan indicator, encoded as follows: -- bit 8: 1 (no extension) -- bits 765: nature of address indicator -- 000 unknown -- 001 international number -- 010 national significant number -- 011 network specific number -- 100 subscriber number -- 101 reserved -- 110 abbreviated number -- 111 reserved for extension -- bits 4321: numbering plan indicator -- 0000 unknown -- 0001 ISDN/Telephony Numbering Plan (Rec ITU-T E.164) -- 0010 spare -- 0011 data numbering plan (ITU-T Rec X.121) -- 0100 telex numbering plan (ITU-T Rec F.69) -- 0101 spare -- 0110 land mobile numbering plan (ITU-T Rec E.212) -- 0111 spare -- 1000 national numbering plan -- 1001 private numbering plan -- 1111 reserved for extension -- all other values are reserved. -- b) The following octets representing digits of an address -- encoded as a TBCD-STRING. maxAddressLength INTEGER ::= 20 ISDN-AddressString ::= AddressString (SIZE (1..maxISDN-AddressLength)) -- This type is used to represent ISDN numbers. maxISDN-AddressLength INTEGER ::= 9 FTN-AddressString ::= AddressString (SIZE (1..maxFTN-AddressLength)) -- This type is used to represent forwarded-to numbers. -- If NAI = international the first digits represent the country code (CC) -- and the network destination code (NDC) as for E.164. maxFTN-AddressLength INTEGER ::= 15 ISDN-SubaddressString ::= OCTET STRING (SIZE (1..maxISDN-SubaddressLength)) -- This type is used to represent ISDN subaddresses. -- It is composed of -- a) one octet for type of subaddress and odd/even indicator. -- b) 20 octets for subaddress information. -- a) The first octet includes a one bit extension indicator, a -- 3 bits type of subaddress and a one bit odd/even indicator, -- encoded as follows: -- bit 8: 1 (no extension) -- bits 765: type of subaddress -- 000 NSAP (X.213/ISO 8348 AD2) -- 010 User Specified -- All other values are reserved -- bit 4: odd/even indicator -- 0 even number of address signals -- 1 odd number of address signals -- The odd/even indicator is used when the type of subaddress -- is ""user specified"" and the coding is BCD. -- bits 321: 000 (unused) -- b) Subaddress information. -- The NSAP X.213/ISO8348AD2 address shall be formatted as specified -- by octet 4 which contains the Authority and Format Identifier -- (AFI). The encoding is made according to the ""preferred binary -- encoding"" as defined in X.213/ISO834AD2. For the definition -- of this type of subaddress, see ITU-T Rec I.334. -- For User-specific subaddress, this field is encoded according -- to the user specification, subject to a maximum length of 20 -- octets. When interworking with X.25 networks BCD coding should -- be applied. maxISDN-SubaddressLength INTEGER ::= 21 ExternalSignalInfo ::= SEQUENCE { protocolId ProtocolId, signalInfo SignalInfo, -- Information about the internal structure is given in -- clauseÊ7.6.9. extensionContainer ExtensionContainer OPTIONAL, -- extensionContainer must not be used in version 2 ...} SignalInfo ::= OCTET STRING (SIZE (1..maxSignalInfoLength)) maxSignalInfoLength INTEGER ::= 200 -- This NamedValue represents the theoretical maximum number of octets which is -- available to carry a single instance of the SignalInfo data type, -- without requiring segmentation to cope with the network layer service. -- However, the actual maximum size available for an instance of the data -- type may be lower, especially when other information elements -- have to be included in the same component."
"ProtocolId ::= ENUMERATED { gsm-0408 (1), gsm-0806 (2), gsm-BSSMAP (3), -- Value 3 is reserved and must not be used ets-300102-1 (4)} Ext-ExternalSignalInfo ::= SEQUENCE { ext-ProtocolId Ext-ProtocolId, signalInfo SignalInfo, -- Information about the internal structure is given in -- clauseÊ7.6.9.10 extensionContainer ExtensionContainer OPTIONAL, ...} Ext-ProtocolId ::= ENUMERATED { ets-300356 (1), ... } -- exception handling: -- For Ext-ExternalSignalInfo sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- Ext-ExternalSignalInfo sequence. AccessNetworkSignalInfo ::= SEQUENCE { accessNetworkProtocolId AccessNetworkProtocolId, signalInfo LongSignalInfo, -- Information about the internal structure is given in clauseÊ7.6.9.1 extensionContainer ExtensionContainer OPTIONAL, ...} LongSignalInfo ::= OCTET STRING (SIZE (1..maxLongSignalInfoLength)) maxLongSignalInfoLength INTEGER ::= 2560 -- This Named Value represents the maximum number of octets which is available -- to carry a single instance of the LongSignalInfo data type using -- White Book SCCP with the maximum number of segments. -- It takes account of the octets used by the lower layers of the protocol, and -- other information elements which may be included in the same component. AccessNetworkProtocolId ::= ENUMERATED { ts3G-48006 (1), ts3G-25413 (2), ...} -- exception handling: -- For AccessNetworkSignalInfo sequences containing this parameter with any -- other value than the ones listed the receiver shall ignore the whole -- AccessNetworkSignalInfo sequence. AlertingPattern ::= OCTET STRING (SIZE (1) ) -- This type is used to represent Alerting Pattern -- bits 8765Ê: 0000 (unused) -- bits 43Ê: type of Pattern -- 00 level -- 01 category -- 10 category -- all other values are reserved. -- bits 21Ê: type of alerting alertingLevel-0 AlertingPatternÊ::= '00000000'B alertingLevel-1 AlertingPatternÊ::= '00000001'B alertingLevel-2 AlertingPatternÊ::= '00000010'B -- all other values of Alerting level are reserved -- Alerting Levels are defined in GSM 02.07 alertingCategory-1 AlertingPatternÊ::= '00000100'B alertingCategory-2 AlertingPatternÊ::= '00000101'B alertingCategory-3 AlertingPatternÊ::= '00000110'B alertingCategory-4 AlertingPatternÊ::= '00000111'B alertingCategory-5 AlertingPatternÊ::= '00001000'B -- all other values of Alerting Category are reserved -- Alerting categories are defined in GSM 02.07 GSN-Address ::= OCTET STRING (SIZE (5..17)) -- Octets are coded according to TS 3GPP TS 23.003 [17] Time ::= OCTET STRING (SIZE (4)) -- Octets are coded according to IETF RFC 3588 [139] -- data types for numbering and identification IMSI ::= TBCD-STRING (SIZE (3..8)) -- digits of MCC, MNC, MSIN are concatenated in this order. Identity ::= CHOICE { imsi IMSI, imsi-WithLMSI IMSI-WithLMSI} IMSI-WithLMSI ::= SEQUENCE { imsi IMSI, lmsi LMSI, -- a special value 00000000 indicates that the LMSI is not in use ...} ASCI-CallReference ::= TBCD-STRING (SIZE (1..8)) -- digits of VGCS/VBS-area,Group-ID are concatenated in this order if there is a -- VGCS/VBS-area. TMSI ::= OCTET STRING (SIZE (1..4)) SubscriberId ::= CHOICE { imsi [0] IMSI, tmsi [1] TMSI} IMEI ::= TBCD-STRING (SIZE (8)) -- Refers to International Mobile Station Equipment Identity -- and Software Version Number (SVN) defined in TS 3GPP TS 23.003 [17]. -- If the SVN is not present the last octet shall contain the -- digit 0 and a filler. -- If present the SVN shall be included in the last octet. HLR-Id ::= IMSI -- leading digits of IMSI, i.e. (MCC, MNC, leading digits of -- MSIN) forming HLR Id defined in TS 3GPP TS 23.003 [17]. HLR-List ::= SEQUENCE SIZE (1..maxNumOfHLR-Id) OF HLR-Id maxNumOfHLR-Id INTEGER ::= 50 LMSI ::= OCTET STRING (SIZE (4)) GlobalCellId ::= OCTET STRING (SIZE (5..7)) -- Refers to Cell Global Identification defined in TS 3GPP TS 23.003 [17]. -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code according to TS 3GPP TS 24.008 [35] -- octets 6 and 7 Cell Identity (CI) according to TS 3GPP TS 24.008 [35] NetworkResource ::= ENUMERATED { plmn (0), hlr (1), vlr (2), pvlr (3), controllingMSC (4), vmsc (5), eir (6), rss (7)} AdditionalNetworkResource ::= ENUMERATED { sgsn (0), ggsn (1), gmlc (2), gsmSCF (3), nplr (4), auc (5), ... , ue (6), mme (7)} -- if unknown value is received in AdditionalNetworkResource -- it shall be ignored. NAEA-PreferredCI ::= SEQUENCE { naea-PreferredCIC [0] NAEA-CIC, extensionContainer [1] ExtensionContainer OPTIONAL, ...} NAEA-CIC ::= OCTET STRING (SIZE (3)) -- The internal structure is defined by the Carrier Identification -- parameter in ANSI T1.113.3. Carrier codes between ""000"" and ""999"" may -- be encoded as 3 digits using ""000"" to ""999"" or as 4 digits using -- ""0000"" to ""0999"". Carrier codes between ""1000"" and ""9999"" are encoded -- using 4 digits. SubscriberIdentity ::= CHOICE { imsi [0] IMSI, msisdn [1] ISDN-AddressString } LCSClientExternalID ::= SEQUENCE { externalAddress [0] ISDN-AddressString OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... } LCSClientInternalID ::= ENUMERATED { broadcastService (0), o-andM-HPLMN (1), o-andM-VPLMN (2), anonymousLocation (3), targetMSsubscribedService (4), ... } -- for a CAMEL phase 3 PLMN operator client, the value targetMSsubscribedService shall be used LCSServiceTypeID ::= INTEGER (0..127) -- the integer values 0-63 are reserved for Standard LCS service types -- the integer values 64-127 are reserved for Non Standard LCS service types -- Standard LCS Service Types emergencyServices LCSServiceTypeID ::= 0 emergencyAlertServices LCSServiceTypeID ::= 1 personTracking LCSServiceTypeID ::= 2 fleetManagement LCSServiceTypeID ::= 3 assetManagement LCSServiceTypeID ::= 4 trafficCongestionReporting LCSServiceTypeID ::= 5 roadsideAssistance LCSServiceTypeID ::= 6 routingToNearestCommercialEnterprise LCSServiceTypeID ::= 7 navigation LCSServiceTypeID ::= 8 --this service type is reserved for use in previous releases citySightseeing LCSServiceTypeID ::= 9 localizedAdvertising LCSServiceTypeID ::= 10 mobileYellowPages LCSServiceTypeID ::= 11 trafficAndPublicTransportationInfo LCSServiceTypeID ::= 12 weather LCSServiceTypeID ::= 13 assetAndServiceFinding LCSServiceTypeID ::= 14 gaming LCSServiceTypeID ::= 15 findYourFriend LCSServiceTypeID ::= 16 dating LCSServiceTypeID ::= 17 chatting LCSServiceTypeID ::= 18 routeFinding LCSServiceTypeID ::= 19 whereAmI LCSServiceTypeID ::= 20 -- The values of LCSServiceTypeID are defined according to 3GPP TS 22.071. -- Non Standard LCS Service Types serv64 LCSServiceTypeID ::= 64 serv65 LCSServiceTypeID ::= 65 serv66 LCSServiceTypeID ::= 66 serv67 LCSServiceTypeID ::= 67 serv68 LCSServiceTypeID ::= 68 serv69 LCSServiceTypeID ::= 69 serv70 LCSServiceTypeID ::= 70 serv71 LCSServiceTypeID ::= 71 serv72 LCSServiceTypeID ::= 72 serv73 LCSServiceTypeID ::= 73 serv74 LCSServiceTypeID ::= 74 serv75 LCSServiceTypeID ::= 75 serv76 LCSServiceTypeID ::= 76 serv77 LCSServiceTypeID ::= 77 serv78 LCSServiceTypeID ::= 78 serv79 LCSServiceTypeID ::= 79 serv80 LCSServiceTypeID ::= 80 serv81 LCSServiceTypeID ::= 81 serv82 LCSServiceTypeID ::= 82 serv83 LCSServiceTypeID ::= 83 serv84 LCSServiceTypeID ::= 84 serv85 LCSServiceTypeID ::= 85 serv86 LCSServiceTypeID ::= 86 serv87 LCSServiceTypeID ::= 87 serv88 LCSServiceTypeID ::= 88 serv89 LCSServiceTypeID ::= 89 serv90 LCSServiceTypeID ::= 90 serv91 LCSServiceTypeID ::= 91 serv92 LCSServiceTypeID ::= 92 serv93 LCSServiceTypeID ::= 93 serv94 LCSServiceTypeID ::= 94 serv95 LCSServiceTypeID ::= 95 serv96 LCSServiceTypeID ::= 96 serv97 LCSServiceTypeID ::= 97 serv98 LCSServiceTypeID ::= 98 serv99 LCSServiceTypeID ::= 99 serv100 LCSServiceTypeID ::= 100 serv101 LCSServiceTypeID ::= 101 serv102 LCSServiceTypeID ::= 102 serv103 LCSServiceTypeID ::= 103 serv104 LCSServiceTypeID ::= 104 serv105 LCSServiceTypeID ::= 105 serv106 LCSServiceTypeID ::= 106 serv107 LCSServiceTypeID ::= 107 serv108 LCSServiceTypeID ::= 108 serv109 LCSServiceTypeID ::= 109 serv110 LCSServiceTypeID ::= 110 serv111 LCSServiceTypeID ::= 111 serv112 LCSServiceTypeID ::= 112 serv113 LCSServiceTypeID ::= 113 serv114 LCSServiceTypeID ::= 114 serv115 LCSServiceTypeID ::= 115 serv116 LCSServiceTypeID ::= 116 serv117 LCSServiceTypeID ::= 117 serv118 LCSServiceTypeID ::= 118 serv119 LCSServiceTypeID ::= 119 serv120 LCSServiceTypeID ::= 120 serv121 LCSServiceTypeID ::= 121 serv122 LCSServiceTypeID ::= 122 serv123 LCSServiceTypeID ::= 123 serv124 LCSServiceTypeID ::= 124 serv125 LCSServiceTypeID ::= 125 serv126 LCSServiceTypeID ::= 126 serv127 LCSServiceTypeID ::= 127 PLMN-Id ::= OCTET STRING (SIZE (3)) -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit E-UTRAN-CGI ::= OCTET STRING (SIZE (7)) -- Octets are coded as described in 3GPP TS 29.118 [152]. NR-CGI ::= OCTET STRING (SIZE (8)) -- Octets are coded as described in 3GPP TS 38.413 [153]. TA-Id ::= OCTET STRING (SIZE (5)) -- Octets are coded as described in 3GPP TS 29.118 [152]. NR-TA-Id ::= OCTET STRING (SIZE (6)) -- Octets are coded as described in 3GPP TS 38.413 [153]. RAIdentity ::= OCTET STRING (SIZE (6)) -- Routing Area Identity is coded in accordance with 3GPP TS 29.060 [105]. -- It shall contain the value part defined in 3GPP TS 29.060 only. I.e. the 3GPP TS 29.060 -- type identifier octet shall not be included. NetworkNodeDiameterAddress::= SEQUENCE { diameter-Name [0] DiameterIdentity, diameter-Realm [1] DiameterIdentity } -- data types for CAMEL CellGlobalIdOrServiceAreaIdOrLAI ::= CHOICE { cellGlobalIdOrServiceAreaIdFixedLength [0] CellGlobalIdOrServiceAreaIdFixedLength, laiFixedLength [1] LAIFixedLength} CellGlobalIdOrServiceAreaIdFixedLength ::= OCTET STRING (SIZE (7)) -- Refers to Cell Global Identification or Service Are Identification -- defined in 3GPP TS 23.003. -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code according to 3GPP TS 24.008 -- octets 6 and 7 Cell Identity (CI) value or -- Service Area Code (SAC) value -- according to 3GPP TS 23.003 LAIFixedLength ::= OCTET STRING (SIZE (5)) -- Refers to Location Area Identification defined in 3GPP TS 23.003 [17]. -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit -- or filler (1111) for 2 digit MNCs -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code according to 3GPP TS 24.008 [35] -- data types for subscriber management BasicServiceCode ::= CHOICE { bearerService [2] BearerServiceCode, teleservice [3] TeleserviceCode} Ext-BasicServiceCode ::= CHOICE { ext-BearerService [2] Ext-BearerServiceCode, ext-Teleservice [3] Ext-TeleserviceCode} EMLPP-Info ::= SEQUENCE { maximumentitledPriority EMLPP-Priority, defaultPriority EMLPP-Priority, extensionContainer ExtensionContainer OPTIONAL, ...} EMLPP-Priority ::= INTEGER (0..15) -- The mapping from the values A,B,0,1,2,3,4 to the integer-value is -- specified as follows where A is the highest and 4 is the lowest -- priority level -- the integer values 7-15 are spare and shall be mapped to value 4 priorityLevelA EMLPP-Priority ::= 6 priorityLevelB EMLPP-Priority ::= 5 priorityLevel0 EMLPP-Priority ::= 0 priorityLevel1 EMLPP-Priority ::= 1 priorityLevel2 EMLPP-Priority ::= 2 priorityLevel3 EMLPP-Priority ::= 3 priorityLevel4 EMLPP-Priority ::= 4 MC-SS-Info ::= SEQUENCE { ss-Code [0] SS-Code, ss-Status [1] Ext-SS-Status, nbrSB [2] MaxMC-Bearers, nbrUser [3] MC-Bearers, extensionContainer [4] ExtensionContainer OPTIONAL, ...} MaxMC-Bearers ::= INTEGER (2..maxNumOfMC-Bearers) MC-Bearers ::= INTEGER (1..maxNumOfMC-Bearers) maxNumOfMC-Bearers INTEGER ::= 7 Ext-SS-Status ::= OCTET STRING (SIZE (1..5)) -- OCTET 1: -- -- bits 8765: 0000 (unused) -- bits 4321: Used to convey the ""P bit"",""R bit"",""A bit"" and ""Q bit"", -- representing supplementary service state information -- as defined in TS 3GPP TS 23.011 [22] -- bit 4: ""Q bit"" -- bit 3: ""P bit"" -- bit 2: ""R bit"" -- bit 1: ""A bit"" -- OCTETS 2-5: reserved for future use. They shall be discarded if -- received and not understood. -- data types for geographic location AgeOfLocationInformation ::= INTEGER (0..32767) -- the value represents the elapsed time in minutes since the last -- network contact of the mobile station (i.e. the actuality of the -- location information). -- value ""0"" indicates that the MS is currently in contact with the -- network -- value ""32767"" indicates that the location information is at least -- 32767 minutes old .#END 17.7.9 Teleservice Codes .$MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-TS-Code (19) version20 (20)} DEFINITIONS ::= BEGIN TeleserviceCode ::= OCTET STRING (SIZE (1)) -- This type is used to represent the code identifying a single -- teleservice, a group of teleservices, or all teleservices. The -- services are defined in TS GSM 22.003 [4]. -- The internal structure is defined as follows: -- bits 87654321: group (bits 8765) and specific service -- (bits 4321) Ext-TeleserviceCode ::= OCTET STRING (SIZE (1..5)) -- This type is used to represent the code identifying a single -- teleservice, a group of teleservices, or all teleservices. The -- services are defined in TS GSM 22.003 [4]. -- The internal structure is defined as follows: -- OCTET 1: -- bits 87654321: group (bits 8765) and specific service -- (bits 4321) -- OCTETS 2-5: reserved for future use. If received the -- Ext-TeleserviceCode shall be -- treated according to the exception handling defined for the -- operation that uses this type. -- Ext-TeleserviceCode includes all values defined for TeleserviceCode. allTeleservices TeleserviceCode ::= '00000000'B allSpeechTransmissionServices TeleserviceCode ::= '00010000'B telephony TeleserviceCode ::= '00010001'B emergencyCalls TeleserviceCode ::= '00010010'B allShortMessageServices TeleserviceCode ::= '00100000'B shortMessageMT-PP TeleserviceCode ::= '00100001'B shortMessageMO-PP TeleserviceCode ::= '00100010'B allFacsimileTransmissionServices TeleserviceCode ::= '01100000'B facsimileGroup3AndAlterSpeech TeleserviceCode ::= '01100001'B automaticFacsimileGroup3 TeleserviceCode ::= '01100010'B facsimileGroup4 TeleserviceCode ::= '01100011'B -- The following non-hierarchical Compound Teleservice Groups -- are defined in TS 3GPP TS 22.030: allDataTeleservices TeleserviceCode ::= '01110000'B -- covers Teleservice Groups 'allFacsimileTransmissionServices' -- and 'allShortMessageServices' allTeleservices-ExeptSMS TeleserviceCode ::= '10000000'B -- covers Teleservice Groups 'allSpeechTransmissionServices' and -- 'allFacsimileTransmissionServices' -- -- Compound Teleservice Group Codes are only used in call -- independent supplementary service operations, i.e. they -- are not used in InsertSubscriberData or in -- DeleteSubscriberData messages. allVoiceGroupCallServices TeleserviceCode ::= '10010000'B voiceGroupCall TeleserviceCode ::= '10010001'B voiceBroadcastCall TeleserviceCode ::= '10010010'B allPLMN-specificTS TeleserviceCode ::= '11010000'B plmn-specificTS-1 TeleserviceCode ::= '11010001'B plmn-specificTS-2 TeleserviceCode ::= '11010010'B plmn-specificTS-3 TeleserviceCode ::= '11010011'B plmn-specificTS-4 TeleserviceCode ::= '11010100'B plmn-specificTS-5 TeleserviceCode ::= '11010101'B plmn-specificTS-6 TeleserviceCode ::= '11010110'B plmn-specificTS-7 TeleserviceCode ::= '11010111'B plmn-specificTS-8 TeleserviceCode ::= '11011000'B plmn-specificTS-9 TeleserviceCode ::= '11011001'B plmn-specificTS-A TeleserviceCode ::= '11011010'B plmn-specificTS-B TeleserviceCode ::= '11011011'B plmn-specificTS-C TeleserviceCode ::= '11011100'B plmn-specificTS-D TeleserviceCode ::= '11011101'B plmn-specificTS-E TeleserviceCode ::= '11011110'B plmn-specificTS-F TeleserviceCode ::= '11011111'B .#END 17.7.10 Bearer Service Codes .$MAP-BS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-BS-Code (20) version20 (20)} DEFINITIONS ::= BEGIN BearerServiceCode ::= OCTET STRING (SIZE (1)) -- This type is used to represent the code identifying a single -- bearer service, a group of bearer services, or all bearer -- services. The services are defined in TS 3GPP TS 22.002 [3]. -- The internal structure is defined as follows: -- -- plmn-specific bearer services: -- bits 87654321: defined by the HPLMN operator -- rest of bearer services: -- bit 8: 0 (unused) -- bits 7654321: group (bits 7654), and rate, if applicable -- (bits 321) Ext-BearerServiceCode ::= OCTET STRING (SIZE (1..5)) -- This type is used to represent the code identifying a single -- bearer service, a group of bearer services, or all bearer -- services. The services are defined in TS 3GPP TS 22.002 [3]. -- The internal structure is defined as follows: -- -- OCTET 1: -- plmn-specific bearer services: -- bits 87654321: defined by the HPLMN operator -- -- rest of bearer services: -- bit 8: 0 (unused) -- bits 7654321: group (bits 7654), and rate, if applicable -- (bits 321) -- OCTETS 2-5: reserved for future use. If received the -- Ext-TeleserviceCode shall be -- treated according to the exception handling defined for the -- operation that uses this type. -- Ext-BearerServiceCode includes all values defined for BearerServiceCode. allBearerServices BearerServiceCode ::= '00000000'B allDataCDA-Services BearerServiceCode ::= '00010000'B dataCDA-300bps BearerServiceCode ::= '00010001'B dataCDA-1200bps BearerServiceCode ::= '00010010'B dataCDA-1200-75bps BearerServiceCode ::= '00010011'B dataCDA-2400bps BearerServiceCode ::= '00010100'B dataCDA-4800bps BearerServiceCode ::= '00010101'B dataCDA-9600bps BearerServiceCode ::= '00010110'B general-dataCDA BearerServiceCode ::= '00010111'B allDataCDS-Services BearerServiceCode ::= '00011000'B dataCDS-1200bps BearerServiceCode ::= '00011010'B dataCDS-2400bps BearerServiceCode ::= '00011100'B dataCDS-4800bps BearerServiceCode ::= '00011101'B dataCDS-9600bps BearerServiceCode ::= '00011110'B general-dataCDS BearerServiceCode ::= '00011111'B allPadAccessCA-Services BearerServiceCode ::= '00100000'B padAccessCA-300bps BearerServiceCode ::= '00100001'B padAccessCA-1200bps BearerServiceCode ::= '00100010'B padAccessCA-1200-75bps BearerServiceCode ::= '00100011'B padAccessCA-2400bps BearerServiceCode ::= '00100100'B padAccessCA-4800bps BearerServiceCode ::= '00100101'B padAccessCA-9600bps BearerServiceCode ::= '00100110'B general-padAccessCA BearerServiceCode ::= '00100111'B allDataPDS-Services BearerServiceCode ::= '00101000'B dataPDS-2400bps BearerServiceCode ::= '00101100'B dataPDS-4800bps BearerServiceCode ::= '00101101'B dataPDS-9600bps BearerServiceCode ::= '00101110'B general-dataPDS BearerServiceCode ::= '00101111'B allAlternateSpeech-DataCDA BearerServiceCode ::= '00110000'B allAlternateSpeech-DataCDS BearerServiceCode ::= '00111000'B allSpeechFollowedByDataCDA BearerServiceCode ::= '01000000'B allSpeechFollowedByDataCDS BearerServiceCode ::= '01001000'B -- The following non-hierarchical Compound Bearer Service -- Groups are defined in TS 3GPP TS 22.030: allDataCircuitAsynchronous BearerServiceCode ::= '01010000'B -- covers ""allDataCDA-Services"", ""allAlternateSpeech-DataCDA"" and -- ""allSpeechFollowedByDataCDA"" allAsynchronousServices BearerServiceCode ::= '01100000'B -- covers ""allDataCDA-Services"", ""allAlternateSpeech-DataCDA"", -- ""allSpeechFollowedByDataCDA"" and ""allPadAccessCDA-Services"" allDataCircuitSynchronous BearerServiceCode ::= '01011000'B -- covers ""allDataCDS-Services"", ""allAlternateSpeech-DataCDS"" and -- ""allSpeechFollowedByDataCDS"" allSynchronousServices BearerServiceCode ::= '01101000'B -- covers ""allDataCDS-Services"", ""allAlternateSpeech-DataCDS"", -- ""allSpeechFollowedByDataCDS"" and ""allDataPDS-Services"" -- -- Compound Bearer Service Group Codes are only used in call -- independent supplementary service operations, i.e. they -- are not used in InsertSubscriberData or in -- DeleteSubscriberData messages. allPLMN-specificBS BearerServiceCode ::= '11010000'B plmn-specificBS-1 BearerServiceCode ::= '11010001'B plmn-specificBS-2 BearerServiceCode ::= '11010010'B plmn-specificBS-3 BearerServiceCode ::= '11010011'B plmn-specificBS-4 BearerServiceCode ::= '11010100'B plmn-specificBS-5 BearerServiceCode ::= '11010101'B plmn-specificBS-6 BearerServiceCode ::= '11010110'B plmn-specificBS-7 BearerServiceCode ::= '11010111'B plmn-specificBS-8 BearerServiceCode ::= '11011000'B plmn-specificBS-9 BearerServiceCode ::= '11011001'B plmn-specificBS-A BearerServiceCode ::= '11011010'B plmn-specificBS-B BearerServiceCode ::= '11011011'B plmn-specificBS-C BearerServiceCode ::= '11011100'B plmn-specificBS-D BearerServiceCode ::= '11011101'B plmn-specificBS-E BearerServiceCode ::= '11011110'B plmn-specificBS-F BearerServiceCode ::= '11011111'B .#END 17.7.11 Extension data types .$MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS PrivateExtension, ExtensionContainer, SLR-ArgExtensionContainer; -- IOC for private MAP extensions MAP-EXTENSION ::= CLASS { &ExtensionType OPTIONAL, &extensionId OBJECT IDENTIFIER } -- The length of the Object Identifier shall not exceed 16 octets and the -- number of components of the Object Identifier shall not exceed 16 -- data types ExtensionContainer ::= SEQUENCE { privateExtensionList [0]PrivateExtensionList OPTIONAL, pcs-Extensions [1]PCS-Extensions OPTIONAL, ...} SLR-ArgExtensionContainer ::= SEQUENCE { privateExtensionList [0]PrivateExtensionList OPTIONAL, slr-Arg-PCS-Extensions [1]SLR-Arg-PCS-Extensions OPTIONAL, ...} PrivateExtensionList ::= SEQUENCE SIZE (1..maxNumOfPrivateExtensions) OF PrivateExtension PrivateExtension ::= SEQUENCE { extId MAP-EXTENSION.&extensionId ({ExtensionSet}), extType MAP-EXTENSION.&ExtensionType ({ExtensionSet}{@extId}) OPTIONAL} maxNumOfPrivateExtensions INTEGER ::= 10 ExtensionSet MAP-EXTENSION ::= {... -- ExtensionSet is the set of all defined private extensions } -- Unsupported private extensions shall be discarded if received. PCS-Extensions ::= SEQUENCE { ...} SLR-Arg-PCS-Extensions ::= SEQUENCE { ..., na-ESRK-Request [0] NULL OPTIONAL } .#END 17.7.12 Group Call data types .$MAP-GR-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-GR-DataTypes (23) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS PrepareGroupCallArg, PrepareGroupCallRes, SendGroupCallEndSignalArg, SendGroupCallEndSignalRes, ForwardGroupCallSignallingArg, ProcessGroupCallSignallingArg, SendGroupCallInfoArg, SendGroupCallInfoRes ; IMPORTS ISDN-AddressString, IMSI, TMSI, EMLPP-Priority, ASCI-CallReference, SignalInfo, GlobalCellId, AccessNetworkSignalInfo FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} Ext-TeleserviceCode FROM MAP-TS-Code { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-TS-Code (19) version20 (20)} Kc, AdditionalInfo, GroupId, Long-GroupId, AdditionalSubscriptions, Cksn FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} ExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} ; PrepareGroupCallArg ::= SEQUENCE { teleservice Ext-TeleserviceCode, asciCallReference ASCI-CallReference, codec-Info CODEC-Info, cipheringAlgorithm CipheringAlgorithm, groupKeyNumber-Vk-Id [0] GroupKeyNumber OPTIONAL, groupKey [1] Kc OPTIONAL, -- this parameter shall not be sent and shall be discarded if received priority [2] EMLPP-Priority OPTIONAL, uplinkFree [3] NULL OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., vstk [5] VSTK OPTIONAL, vstk-rand [6] VSTK-RAND OPTIONAL, talkerChannelParameter [7] NULL OPTIONAL, uplinkReplyIndicator [8] NULL OPTIONAL} VSTK ::= OCTET STRING (SIZE (16)) VSTK-RAND ::= OCTET STRING (SIZE (5)) -- The 36 bit value is carried in bit 7 of octet 1 to bit 4 of octet 5 -- bits 3, 2, 1, and 0 of octet 5 are padded with zeros. PrepareGroupCallRes ::= SEQUENCE { groupCallNumber ISDN-AddressString, extensionContainer ExtensionContainer OPTIONAL, ...} SendGroupCallEndSignalArg ::= SEQUENCE { imsi IMSI OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., talkerPriority [0]TalkerPriority OPTIONAL, additionalInfo [1]AdditionalInfo OPTIONAL } TalkerPriority ::= ENUMERATED { normal (0), privileged (1), emergency (2)} SendGroupCallEndSignalRes ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ...} ForwardGroupCallSignallingArg ::= SEQUENCE { imsi IMSI OPTIONAL, uplinkRequestAck [0] NULL OPTIONAL, uplinkReleaseIndication [1] NULL OPTIONAL, uplinkRejectCommand [2] NULL OPTIONAL, uplinkSeizedCommand [3] NULL OPTIONAL, uplinkReleaseCommand [4] NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., stateAttributes [5] StateAttributes OPTIONAL, talkerPriority [6] TalkerPriority OPTIONAL, additionalInfo [7] AdditionalInfo OPTIONAL, emergencyModeResetCommandFlag [8] NULL OPTIONAL, sm-RP-UI [9] SignalInfo OPTIONAL, an-APDU [10] AccessNetworkSignalInfo OPTIONAL } ProcessGroupCallSignallingArg ::= SEQUENCE { uplinkRequest [0] NULL OPTIONAL, uplinkReleaseIndication [1] NULL OPTIONAL, releaseGroupCall [2] NULL OPTIONAL, extensionContainer ExtensionContainer OPTIONAL, ..., talkerPriority [3] TalkerPriority OPTIONAL, additionalInfo [4] AdditionalInfo OPTIONAL, emergencyModeResetCommandFlag [5] NULL OPTIONAL, an-APDU [6] AccessNetworkSignalInfo OPTIONAL } GroupKeyNumber ::= INTEGER (0..15) CODEC-Info ::= OCTET STRING (SIZE (5..10)) -- Refers to channel type -- coded according to 3GPP TS 48.008 [49] and including Element identifier and Length CipheringAlgorithm ::= OCTET STRING (SIZE (1)) -- Refers to 'permitted algorithms' in 'encryption information' -- coded according to 3GPP TS 48.008 [49]: -- Bits 8-1 -- 8765 4321 -- 0000 0001 No encryption -- 0000 0010 GSM A5/1 -- 0000 0100 GSM A5/2 -- 0000 1000 GSM A5/3 -- 0001 0000 GSM A5/4 -- 0010 0000 GSM A5/5 -- 0100 0000 GSM A5/6 -- 1000 0000 GSM A5/7 StateAttributes ::= SEQUENCE { downlinkAttached [5] NULL OPTIONAL, uplinkAttached [6] NULL OPTIONAL, dualCommunication [7] NULL OPTIONAL, callOriginator [8] NULL OPTIONAL } -- Refers to 3GPP TS 44.068 for definitions of StateAttributes fields. SendGroupCallInfoArg ::= SEQUENCE { requestedInfo RequestedInfo, groupId Long-GroupId, teleservice Ext-TeleserviceCode, cellId [0] GlobalCellId OPTIONAL, imsi [1] IMSI OPTIONAL, tmsi [2] TMSI OPTIONAL, additionalInfo [3] AdditionalInfo OPTIONAL, talkerPriority [4] TalkerPriority OPTIONAL, cksn [5] Cksn OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ... } RequestedInfo ::= ENUMERATED { anchorMSC-AddressAndASCI-CallReference (0), imsiAndAdditionalInfoAndAdditionalSubscription (1), ... } -- exception handling: -- an unrecognized value shall be rejected by the receiver with a return error cause of -- unexpected data value SendGroupCallInfoRes ::= SEQUENCE { anchorMSC-Address [0] ISDN-AddressString OPTIONAL, asciCallReference [1] ASCI-CallReference OPTIONAL, imsi [2] IMSI OPTIONAL, additionalInfo [3] AdditionalInfo OPTIONAL, additionalSubscriptions [4] AdditionalSubscriptions OPTIONAL, kc [5] Kc OPTIONAL, extensionContainer [6] ExtensionContainer OPTIONAL, ... } .#END 17.7.13 Location service data types .$MAP-LCS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-LCS-DataTypes (25) version20 (20)} DEFINITIONS IMPLICIT TAGS ::= BEGIN EXPORTS RoutingInfoForLCS-Arg, RoutingInfoForLCS-Res, ProvideSubscriberLocation-Arg, ProvideSubscriberLocation-Res, SubscriberLocationReport-Arg, SubscriberLocationReport-Res, LocationType, DeferredLocationEventType, LCSClientName, LCS-QoS, Horizontal-Accuracy, ResponseTime, Ext-GeographicalInformation, VelocityEstimate, SupportedGADShapes, Add-GeographicalInformation, LCSRequestorID, LCS-ReferenceNumber, LCSCodeword, AreaEventInfo, ReportingPLMNList, PeriodicLDRInfo, SequenceNumber, LCSClientType, LCS-Priority, OccurrenceInfo, IntervalTime ; IMPORTS AddressString, ISDN-AddressString, IMEI, IMSI, LMSI, SubscriberIdentity, AgeOfLocationInformation, LCSClientExternalID, LCSClientInternalID, LCSServiceTypeID, CellGlobalIdOrServiceAreaIdOrLAI, PLMN-Id, GSN-Address, DiameterIdentity FROM MAP-CommonDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-CommonDataTypes (18) version20 (20)} ExtensionContainer, SLR-ArgExtensionContainer FROM MAP-ExtensionDataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-ExtensionDataTypes (21) version20 (20)} USSD-DataCodingScheme, USSD-String FROM MAP-SS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SS-DataTypes (14) version20 (20)} APN, SupportedLCS-CapabilitySets FROM MAP-MS-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-MS-DataTypes (11) version20 (20)} Additional-Number FROM MAP-SM-DataTypes { itu-t identified-organization (4) etsi (0) mobileDomain (0) gsm-Network (1) modules (3) map-SM-DataTypes (16) version20 (20)} ; RoutingInfoForLCS-Arg ::= SEQUENCE { mlcNumber [0] ISDN-AddressString, targetMS [1] SubscriberIdentity, extensionContainer [2] ExtensionContainer OPTIONAL, ...} RoutingInfoForLCS-Res ::= SEQUENCE { targetMS [0] SubscriberIdentity, lcsLocationInfo [1] LCSLocationInfo, extensionContainer [2] ExtensionContainer OPTIONAL, ..., v-gmlc-Address [3] GSN-Address OPTIONAL, h-gmlc-Address [4] GSN-Address OPTIONAL, ppr-Address [5] GSN-Address OPTIONAL, additional-v-gmlc-Address [6] GSN-Address OPTIONAL } LCSLocationInfo ::= SEQUENCE { networkNode-Number ISDN-AddressString, -- NetworkNode-number can be msc-number, sgsn-number or a dummy value of ""0"" lmsi [0] LMSI OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... , gprsNodeIndicator [2] NULL OPTIONAL, -- gprsNodeIndicator is set only if the SGSN number is sent as the Network Node Number additional-Number [3] Additional-Number OPTIONAL, supportedLCS-CapabilitySets [4] SupportedLCS-CapabilitySets OPTIONAL, additional-LCS-CapabilitySets [5] SupportedLCS-CapabilitySets OPTIONAL, mme-Name [6] DiameterIdentity OPTIONAL, aaa-Server-Name [8] DiameterIdentity OPTIONAL, sgsn-Name [9] DiameterIdentity OPTIONAL, sgsn-Realm [10] DiameterIdentity OPTIONAL } ProvideSubscriberLocation-Arg ::= SEQUENCE { locationType LocationType, mlc-Number ISDN-AddressString, lcs-ClientID [0] LCS-ClientID OPTIONAL, privacyOverride [1] NULL OPTIONAL, imsi [2] IMSI OPTIONAL, msisdn [3] ISDN-AddressString OPTIONAL, lmsi [4] LMSI OPTIONAL, imei [5] IMEI OPTIONAL, lcs-Priority [6] LCS-Priority OPTIONAL, lcs-QoS [7] LCS-QoS OPTIONAL, extensionContainer [8] ExtensionContainer OPTIONAL, ... , supportedGADShapes [9] SupportedGADShapes OPTIONAL, lcs-ReferenceNumber [10] LCS-ReferenceNumber OPTIONAL, lcsServiceTypeID [11] LCSServiceTypeID OPTIONAL, lcsCodeword [12] LCSCodeword OPTIONAL, lcs-PrivacyCheck [13] LCS-PrivacyCheck OPTIONAL, areaEventInfo [14] AreaEventInfo OPTIONAL, h-gmlc-Address [15] GSN-Address OPTIONAL, mo-lrShortCircuitIndicator [16] NULL OPTIONAL, periodicLDRInfo [17] PeriodicLDRInfo OPTIONAL, reportingPLMNList [18] ReportingPLMNList OPTIONAL } -- one of imsi or msisdn is mandatory -- If a location estimate type indicates activate deferred location or cancel deferred -- location, a lcs-Reference number shall be included. LocationType ::= SEQUENCE { locationEstimateType [0] LocationEstimateType, ..., deferredLocationEventType [1] DeferredLocationEventType OPTIONAL } LocationEstimateType ::= ENUMERATED { currentLocation (0), currentOrLastKnownLocation (1), initialLocation (2), ..., activateDeferredLocation (3), cancelDeferredLocation (4) , notificationVerificationOnly (5) } -- exception handling: -- a ProvideSubscriberLocation-Arg containing an unrecognized LocationEstimateType -- shall be rejected by the receiver with a return error cause of unexpected data value DeferredLocationEventType ::= BIT STRING { msAvailable (0) , enteringIntoArea (1), leavingFromArea (2), beingInsideArea (3) , periodicLDR (4) } (SIZE (1..16)) -- beingInsideArea is always treated as oneTimeEvent regardless of the possible value -- of occurrenceInfo inside areaEventInfo. -- exception handling: -- a ProvideSubscriberLocation-Arg containing other values than listed above in -- DeferredLocationEventType shall be rejected by the receiver with a return error cause of -- unexpected data value. LCS-ClientID ::= SEQUENCE { lcsClientType [0] LCSClientType, lcsClientExternalID [1] LCSClientExternalID OPTIONAL, lcsClientDialedByMS [2] AddressString OPTIONAL, lcsClientInternalID [3] LCSClientInternalID OPTIONAL, lcsClientName [4] LCSClientName OPTIONAL, ..., lcsAPN [5] APN OPTIONAL, lcsRequestorID [6] LCSRequestorID OPTIONAL } LCSClientType ::= ENUMERATED { emergencyServices (0), valueAddedServices (1), plmnOperatorServices (2), lawfulInterceptServices (3), ... } -- exception handling: -- unrecognized values may be ignored if the LCS client uses the privacy override -- otherwise, an unrecognized value shall be treated as unexpected data by a receiver -- a return error shall then be returned if received in a MAP invoke LCSClientName ::= SEQUENCE { dataCodingScheme [0] USSD-DataCodingScheme, nameString [2] NameString, ..., lcs-FormatIndicator [3] LCS-FormatIndicator OPTIONAL } -- The USSD-DataCodingScheme shall indicate use of the default alphabet through the -- following encoding -- bit 7 6 5 4 3 2 1 0 -- 0 0 0 0 1 1 1 1 NameString ::= USSD-String (SIZE (1..maxNameStringLength)) maxNameStringLength INTEGER ::= 63 LCSRequestorID ::= SEQUENCE { dataCodingScheme [0] USSD-DataCodingScheme, requestorIDString [1] RequestorIDString, ..., lcs-FormatIndicator [2] LCS-FormatIndicator OPTIONAL } RequestorIDString ::= USSD-String (SIZE (1..maxRequestorIDStringLength)) maxRequestorIDStringLength INTEGER ::= 63 LCS-FormatIndicator ::= ENUMERATED { logicalName (0), e-mailAddress (1), msisdn (2), url (3), sipUrl (4), ... } LCS-Priority ::= OCTET STRING (SIZE (1)) -- 0 = highest priority -- 1 = normal priority -- all other values treated as 1 LCS-QoS ::= SEQUENCE { horizontal-accuracy [0] Horizontal-Accuracy OPTIONAL, verticalCoordinateRequest [1] NULL OPTIONAL, vertical-accuracy [2] Vertical-Accuracy OPTIONAL, responseTime [3] ResponseTime OPTIONAL, extensionContainer [4] ExtensionContainer OPTIONAL, ..., velocityRequest [5] NULL OPTIONAL } Horizontal-Accuracy ::= OCTET STRING (SIZE (1)) -- bit 8 = 0 -- bits 7-1 = 7 bit Uncertainty Code defined in 3GPP TS 23.032. The horizontal location -- error should be less than the error indicated by the uncertainty code with 67% -- confidence. Vertical-Accuracy ::= OCTET STRING (SIZE (1)) -- bit 8 = 0 -- bits 7-1 = 7 bit Vertical Uncertainty Code defined in 3GPP TS 23.032. -- The vertical location error should be less than the error indicated -- by the uncertainty code with 67% confidence. ResponseTime ::= SEQUENCE { responseTimeCategory ResponseTimeCategory, ...} -- note: an expandable SEQUENCE simplifies later addition of a numeric response time. ResponseTimeCategory ::= ENUMERATED { lowdelay (0), delaytolerant (1), ... } -- exception handling: -- an unrecognized value shall be treated the same as value 1 (delaytolerant) SupportedGADShapes ::= BIT STRING { ellipsoidPoint (0), ellipsoidPointWithUncertaintyCircle (1), ellipsoidPointWithUncertaintyEllipse (2), polygon (3), ellipsoidPointWithAltitude (4), ellipsoidPointWithAltitudeAndUncertaintyElipsoid (5), ellipsoidArc (6) } (SIZE (7..16)) -- A node shall mark in the BIT STRING all Shapes defined in 3GPP TS 23.032 it supports. -- exception handling: bits 7 to 15 shall be ignored if received. LCS-ReferenceNumber::= OCTET STRING (SIZE(1)) LCSCodeword ::= SEQUENCE { dataCodingScheme [0] USSD-DataCodingScheme, lcsCodewordString [1] LCSCodewordString, ...} LCSCodewordString ::= USSD-String (SIZE (1..maxLCSCodewordStringLength)) maxLCSCodewordStringLength INTEGER ::= 20 LCS-PrivacyCheck ::= SEQUENCE { callSessionUnrelated [0] PrivacyCheckRelatedAction, callSessionRelated [1] PrivacyCheckRelatedAction OPTIONAL, ...} PrivacyCheckRelatedAction ::= ENUMERATED { allowedWithoutNotification (0), allowedWithNotification (1), allowedIfNoResponse (2), restrictedIfNoResponse (3), notAllowed (4), ...} -- exception handling: -- a ProvideSubscriberLocation-Arg containing an unrecognized PrivacyCheckRelatedAction -- shall be rejected by the receiver with a return error cause of unexpected data value AreaEventInfo ::= SEQUENCE { areaDefinition [0] AreaDefinition, occurrenceInfo [1] OccurrenceInfo OPTIONAL, intervalTime [2] IntervalTime OPTIONAL, ...} AreaDefinition ::= SEQUENCE { areaList [0] AreaList, ...} AreaList ::= SEQUENCE SIZE (1..maxNumOfAreas) OF Area maxNumOfAreas INTEGER ::= 10 Area ::= SEQUENCE { areaType [0] AreaType, areaIdentification [1] AreaIdentification, ...} AreaType ::= ENUMERATED { countryCode (0), plmnId (1), locationAreaId (2), routingAreaId (3), cellGlobalId (4), ..., utranCellId (5) } AreaIdentification ::= OCTET STRING (SIZE (2..7)) -- The internal structure is defined as follows: -- octet 1 bits 4321 Mobile Country Code 1st digit -- bits 8765 Mobile Country Code 2nd digit -- octet 2 bits 4321 Mobile Country Code 3rd digit -- bits 8765 Mobile Network Code 3rd digit if 3 digit MNC included -- or filler (1111) -- octet 3 bits 4321 Mobile Network Code 1st digit -- bits 8765 Mobile Network Code 2nd digit -- octets 4 and 5 Location Area Code (LAC) for Local Area Id, -- Routing Area Id and Cell Global Id -- octet 6 Routing Area Code (RAC) for Routing Area Id -- octets 6 and 7 Cell Identity (CI) for Cell Global Id -- octets 4 until 7 Utran Cell Identity (UC-Id) for Utran Cell Id OccurrenceInfo ::= ENUMERATED { oneTimeEvent (0), multipleTimeEvent (1), ...} IntervalTime ::= INTEGER (1..32767) -- minimum interval time between area reports in seconds PeriodicLDRInfoÊ::= SEQUENCE { reportingAmount ReportingAmount, reportingInterval ReportingInterval, ...} -- reportingInterval x reportingAmount shall not exceed 8639999 (99 days, 23 hours, -- 59 minutes and 59 seconds) for compatibility with OMA MLP and RLP ReportingAmountÊ::= INTEGER (1..maxReportingAmount) maxReportingAmount INTEGERÊ::= 8639999 ReportingIntervalÊ::= INTEGER (1..maxReportingInterval) -- ReportingInterval is in seconds maxReportingInterval INTEGERÊ::= 8639999 ReportingPLMNList::= SEQUENCE { plmn-ListPrioritized [0] NULL OPTIONAL, plmn-List [1] PLMNList, ...} PLMNList::= SEQUENCE SIZE (1..maxNumOfReportingPLMN) OF ReportingPLMN maxNumOfReportingPLMN INTEGER ::= 20 ReportingPLMN::= SEQUENCE { plmn-Id [0] PLMN-Id, ran-Technology [1] RAN-Technology OPTIONAL, ran-PeriodicLocationSupport [2] NULL OPTIONAL, ...} RAN-Technology ::= ENUMERATED { gsm (0), umts (1), ...} ProvideSubscriberLocation-Res ::= SEQUENCE { locationEstimate Ext-GeographicalInformation, ageOfLocationEstimate [0] AgeOfLocationInformation OPTIONAL, extensionContainer [1] ExtensionContainer OPTIONAL, ... , add-LocationEstimate [2] Add-GeographicalInformation OPTIONAL, deferredmt-lrResponseIndicator [3] NULL OPTIONAL, geranPositioningData [4] PositioningDataInformation OPTIONAL, utranPositioningData [5] UtranPositioningDataInfo OPTIONAL, cellIdOrSai [6] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL, sai-Present [7] NULL OPTIONAL, accuracyFulfilmentIndicator [8] AccuracyFulfilmentIndicator OPTIONAL, velocityEstimate [9] VelocityEstimate OPTIONAL, mo-lrShortCircuitIndicator [10] NULL OPTIONAL, geranGANSSpositioningData [11] GeranGANSSpositioningData OPTIONAL, utranGANSSpositioningData [12] UtranGANSSpositioningData OPTIONAL, targetServingNodeForHandover [13] ServingNodeAddress OPTIONAL, utranAdditionalPositioningData [14] UtranAdditionalPositioningData OPTIONAL, utranBaroPressureMeas [15] UtranBaroPressureMeas OPTIONAL, utranCivicAddress [16] UtranCivicAddress OPTIONAL } -- if deferredmt-lrResponseIndicator is set, locationEstimate is ignored. -- the add-LocationEstimate parameter shall not be sent to a node that did not indicate the -- geographic shapes supported in the ProvideSubscriberLocation-Arg -- The locationEstimate and the add-locationEstimate parameters shall not be sent if -- the supportedGADShapes parameter has been received in ProvideSubscriberLocation-Arg -- and the shape encoded in locationEstimate or add-LocationEstimate is not marked -- as supported in supportedGADShapes. In such a case ProvideSubscriberLocation -- shall be rejected with error FacilityNotSupported with additional indication -- shapeOfLocationEstimateNotSupported. -- sai-Present indicates that the cellIdOrSai parameter contains a Service Area Identity. AccuracyFulfilmentIndicator ::= ENUMERATED { requestedAccuracyFulfilled (0), requestedAccuracyNotFulfilled (1), ... } Ext-GeographicalInformation ::= OCTET STRING (SIZE (1..maxExt-GeographicalInformation)) -- Refers to geographical Information defined in 3GPP TS 23.032. -- This is composed of 1 or more octets with an internal structure according to -- 3GPP TS 23.032 -- Octet 1: Type of shape, only the following shapes in 3GPP TS 23.032 are allowed: -- (a) Ellipsoid point with uncertainty circle -- (b) Ellipsoid point with uncertainty ellipse -- (c) Ellipsoid point with altitude and uncertainty ellipsoid -- (d) Ellipsoid Arc -- (e) Ellipsoid Point -- Any other value in octet 1 shall be treated as invalid -- Octets 2 to 8 for case (a) Ð Ellipsoid point with uncertainty circle -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Uncertainty code 1 octet -- Octets 2 to 11 for case (b) Ð Ellipsoid point with uncertainty ellipse: -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Uncertainty semi-major axis 1 octet -- Uncertainty semi-minor axis 1 octet -- Angle of major axis 1 octet -- Confidence 1 octet -- Octets 2 to 14 for case (c) Ð Ellipsoid point with altitude and uncertainty ellipsoid -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Altitude 2 octets -- Uncertainty semi-major axis 1 octet -- Uncertainty semi-minor axis 1 octet -- Angle of major axis 1 octet -- Uncertainty altitude 1 octet -- Confidence 1 octet -- Octets 2 to 13 for case (d) Ð Ellipsoid Arc -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- Inner radius 2 octets -- Uncertainty radius 1 octet -- Offset angle 1 octet -- Included angle 1 octet -- Confidence 1 octet -- Octets 2 to 7 for case (e) Ð Ellipsoid Point -- Degrees of Latitude 3 octets -- Degrees of Longitude 3 octets -- -- An Ext-GeographicalInformation parameter comprising more than one octet and -- containing any other shape or an incorrect number of octets or coding according -- to 3GPP TS 23.032 shall be treated as invalid data by a receiver. -- -- An Ext-GeographicalInformation parameter comprising one octet shall be discarded -- by the receiver if an Add-GeographicalInformation parameter is received -- in the same message. -- -- An Ext-GeographicalInformation parameter comprising one octet shall be treated as -- invalid data by the receiver if an Add-GeographicalInformation parameter is not -- received in the same message. maxExt-GeographicalInformation INTEGER ::= 20 -- the maximum length allows for further shapes in 3GPP TS 23.032 to be included in later -- versions of 3GPP TS 29.002 VelocityEstimate ::= OCTET STRING (SIZE (4..7)) -- Refers to Velocity description defined in 3GPP TS 23.032. -- This is composed of 4 or more octets with an internal structure according to -- 3GPP TS 23.032 -- Octet 1: Type of velocity, only the following types in 3GPP TS 23.032 are allowed: -- (a) Horizontal Velocity -- (b) Horizontal with Vertical Velocity -- (c) Horizontal Velocity with Uncertainty -- (d) Horizontal with Vertical Velocity and Uncertainty -- For types Horizontal with Vertical Velocity and Horizontal with Vertical Velocity -- and Uncertainty, the direction of the Vertical Speed is also included in Octet 1 -- Any other value in octet 1 shall be treated as invalid -- Octets 2 to 4 for case (a) Horizontal velocity: -- Bearing 1 octet -- Horizontal Speed 2 octets -- Octets 2 to 5 for case (b) Ð Horizontal with Vertical Velocity: -- Bearing 1 octet -- Horizontal Speed 2 octets -- Vertical Speed 1 octet -- Octets 2 to 5 for case (c) Ð Horizontal velocity with Uncertainty: -- Bearing 1 octet -- Horizontal Speed 2 octets -- Uncertainty Speed 1 octet -- Octets 2 to 7 for case (d) Ð Horizontal with Vertical Velocity and Uncertainty: -- Bearing 1 octet -- Horizontal Speed 2 octets -- Vertical Speed 1 octet -- Horizontal Uncertainty Speed 1 octet -- Vertical Uncertainty Speed 1 octet PositioningDataInformation ::= OCTET STRING (SIZE (2..maxPositioningDataInformation)) -- Refers to the Positioning Data defined in 3GPP TS 49.031. -- This is composed of 2 or more octets with an internal structure according to -- 3GPP TS 49.031. maxPositioningDataInformation INTEGER ::= 10 -- UtranPositioningDataInfo ::= OCTET STRING (SIZE (3..maxUtranPositioningDataInfo)) -- Refers to the Position Data defined in 3GPP TS 25.413. -- This is composed of the positioningDataDiscriminator and the positioningDataSet -- included in positionData as defined in 3GPP TS 25.413. maxUtranPositioningDataInfo INTEGER ::= 11 -- GeranGANSSpositioningData ::= OCTET STRING (SIZE (2..maxGeranGANSSpositioningData)) -- Refers to the GANSS Positioning Data defined in 3GPP TS 49.031. -- This is composed of 2 or more octets with an internal structure according to -- 3GPP TS 49.031. maxGeranGANSSpositioningData INTEGER ::= 10 -- UtranGANSSpositioningData ::= OCTET STRING (SIZE (1..maxUtranGANSSpositioningData)) -- Refers to the Position Data defined in 3GPP TS 25.413. -- This is composed of the GANSS-PositioningDataSet only, included in PositionData -- as defined in 3GPP TS 25.413. maxUtranGANSSpositioningData INTEGER ::= 9 -- UtranAdditionalPositioningData ::= OCTET STRING (SIZE (1..maxUtranAdditionalPositioningData)) -- Refers to the Position Data defined in 3GPP TS 25.413. -- This is composed of the Additional-PositioningDataSet only, included in PositionData -- as defined in 3GPP TS 25.413. maxUtranAdditionalPositioningData INTEGER ::= 8 -- UtranBaroPressureMeas ::= INTEGER (30000..115000) -- Refers to the barometric pressure measurement defined in 3GPP TS 25.413. -- This is composed of the BarometricPressureMeasurement only as defined in 3GPP TS -- 25.413. UtranCivicAddress ::= OCTET STRING -- Refers to the civic address defined in 3GPP TS 25.413. -- This is composed of the CivicAddress only as defined in 3GPP TS 25.413. Add-GeographicalInformation ::= OCTET STRING (SIZE (1..maxAdd-GeographicalInformation)) -- Refers to geographical Information defined in 3GPP TS 23.032."
"-- This is composed of 1 or more octets with an internal structure according to -- 3GPP TS 23.032 -- Octet 1: Type of shape, all the shapes defined in 3GPP TS 23.032 are allowed: -- Octets 2 to n (where n is the total number of octets necessary to encode the shape -- according to 3GPP TS 23.032) are used to encode the shape itself in accordance with the -- encoding defined in 3GPP TS 23.032 -- -- An Add-GeographicalInformation parameter, whether valid or invalid, received -- together with a valid Ext-GeographicalInformation parameter in the same message -- shall be discarded. -- -- An Add-GeographicalInformation parameter containing any shape not defined in -- 3GPP TS 23.032 or an incorrect number of octets or coding according to -- 3GPP TS 23.032 shall be treated as invalid data by a receiver if not received -- together with a valid Ext-GeographicalInformation parameter in the same message. maxAdd-GeographicalInformation INTEGER ::= 91 -- the maximum length allows support for all the shapes currently defined in 3GPP TS 23.032 SubscriberLocationReport-Arg ::= SEQUENCE { lcs-Event LCS-Event, lcs-ClientID LCS-ClientID, lcsLocationInfo LCSLocationInfo, msisdn [0] ISDN-AddressString OPTIONAL, imsi [1] IMSI OPTIONAL, imei [2] IMEI OPTIONAL, na-ESRD [3] ISDN-AddressString OPTIONAL, na-ESRK [4] ISDN-AddressString OPTIONAL, locationEstimate [5] Ext-GeographicalInformation OPTIONAL, ageOfLocationEstimate [6] AgeOfLocationInformation OPTIONAL, slr-ArgExtensionContainer [7] SLR-ArgExtensionContainer OPTIONAL, ... , add-LocationEstimate [8] Add-GeographicalInformation OPTIONAL, deferredmt-lrData [9] Deferredmt-lrData OPTIONAL, lcs-ReferenceNumber [10] LCS-ReferenceNumber OPTIONAL, geranPositioningData [11] PositioningDataInformation OPTIONAL, utranPositioningData [12] UtranPositioningDataInfo OPTIONAL, cellIdOrSai [13] CellGlobalIdOrServiceAreaIdOrLAI OPTIONAL, h-gmlc-Address [14] GSN-Address OPTIONAL, lcsServiceTypeID [15] LCSServiceTypeID OPTIONAL, sai-Present [17] NULL OPTIONAL, pseudonymIndicator [18] NULL OPTIONAL, accuracyFulfilmentIndicator [19] AccuracyFulfilmentIndicator OPTIONAL, velocityEstimate [20] VelocityEstimate OPTIONAL, sequenceNumber [21] SequenceNumber OPTIONAL, periodicLDRInfo [22] PeriodicLDRInfo OPTIONAL, mo-lrShortCircuitIndicator [23] NULL OPTIONAL, geranGANSSpositioningData [24] GeranGANSSpositioningData OPTIONAL, utranGANSSpositioningData [25] UtranGANSSpositioningData OPTIONAL, targetServingNodeForHandover [26] ServingNodeAddress OPTIONAL, utranAdditionalPositioningData [27] UtranAdditionalPositioningData OPTIONAL, utranBaroPressureMeas [28] UtranBaroPressureMeas OPTIONAL, utranCivicAddress [29] UtranCivicAddress OPTIONAL } -- one of msisdn or imsi is mandatory -- a location estimate that is valid for the locationEstimate parameter should -- be transferred in this parameter in preference to the add-LocationEstimate. -- the deferredmt-lrData parameter shall be included if and only if the lcs-Event -- indicates a deferredmt-lrResponse. -- if the lcs-Event indicates a deferredmt-lrResponse then the locationEstimate -- and the add-locationEstimate parameters shall not be sent if the -- supportedGADShapes parameter had been received in ProvideSubscriberLocation-Arg -- and the shape encoded in locationEstimate or add-LocationEstimate was not marked -- as supported in supportedGADShapes. In such a case terminationCause -- in deferredmt-lrData shall be present with value -- shapeOfLocationEstimateNotSupported. -- If a lcs event indicates deferred mt-lr response, the lcs-Reference number shall be -- included. -- sai-Present indicates that the cellIdOrSai parameter contains a Service Area Identity. Deferredmt-lrData ::= SEQUENCE { deferredLocationEventType DeferredLocationEventType, terminationCause [0] TerminationCause OPTIONAL, lcsLocationInfo [1] LCSLocationInfo OPTIONAL, ...} -- lcsLocationInfo may be included only if a terminationCause is present -- indicating mt-lrRestart. LCS-Event ::= ENUMERATED { emergencyCallOrigination (0), emergencyCallRelease (1), mo-lr (2), ..., deferredmt-lrResponse (3) , deferredmo-lrTTTPInitiation (4), emergencyCallHandover (5) } -- deferredmt-lrResponse is applicable to the delivery of a location estimate -- for an LDR initiated earlier by either the network (via an MT-LR activate deferred -- location) or the UE (via a deferred MO-LR TTTP initiation) -- exception handling: -- a SubscriberLocationReport-Arg containing an unrecognized LCS-Event -- shall be rejected by a receiver with a return error cause of unexpected data value TerminationCause ::= ENUMERATED { normal (0), errorundefined (1), internalTimeout (2), congestion (3), mt-lrRestart (4), privacyViolation (5), ..., shapeOfLocationEstimateNotSupported (6) , subscriberTermination (7), uETermination (8), networkTermination (9) } -- mt-lrRestart shall be used to trigger the GMLC to restart the location procedure, -- either because the sending node knows that the terminal has moved under coverage -- of another MSC or SGSN (e.g. Send Identification received), or because the subscriber -- has been deregistered due to a Cancel Location received from HLR. -- -- exception handling -- an unrecognized value shall be treated the same as value 1 (errorundefined) SequenceNumber ::= INTEGER (1..maxReportingAmount) ServingNodeAddress ::= CHOICE { msc-Number [0] ISDN-AddressString, sgsn-Number [1] ISDN-AddressString, mme-Number [2] DiameterIdentity } SubscriberLocationReport-Res ::= SEQUENCE { extensionContainer ExtensionContainer OPTIONAL, ..., na-ESRK [0] ISDN-AddressString OPTIONAL, na-ESRD [1] ISDN-AddressString OPTIONAL, h-gmlc-Address [2] GSN-Address OPTIONAL, mo-lrShortCircuitIndicator [3] NULL OPTIONAL, reportingPLMNList [4] ReportingPLMNList OPTIONAL, lcs-ReferenceNumber [5] LCS-ReferenceNumber OPTIONAL } -- na-ESRK and na-ESRD are mutually exclusive -- -- exception handling -- receipt of both na-ESRK and na-ESRD shall be treated the same as a return error .#END 17.7.14 Void 18 General on MAP user procedures 18.1 Introduction Clauses 18 to 25 describe the use of MAP services for GSMÊsignalling procedures. GSMÊsignalling procedures may involve one or several interfaces running one or several application protocols. The present document addresses only the signalling procedures which require at least the use of one MAP service. When a signalling procedure takes place in the network, an application process invocation is created in each system component involved. Part of the application process invocation acts as a MAP user and handles one or several MAP dialogues. For each dialogue it employs an instance of the MAP service provider. It may also use other communication services to exchange information on other interfaces, but detailed description of these aspects is outside the scope of the present document. 18.2 Common aspects of user procedure descriptions 18.2.1 General conventions For each signalling procedure the present document provides a brief textual overview accompanied by a flow diagram which represent the functional interactions between system components. Functional interactions are labelled using the MAP service name when the interaction results from a service request or by this service name followed by the symbol ""ack"" when this interaction results from a service response. For each of the system components involved, the present document also provides a detailed textual description of the application process behaviour as well as an SDL diagram. SDL diagrams describe the sequence of events, as seen by the MAP-User, which occurs at MAP service provider boundaries as well as external events which occur at other interfaces and which impact on the previous sequence. External events do not necessarily correspond to the messages of other protocols used in the system component. The MAP-user procedures are described as if a set of interworking functions (IWF) between the MAP-user and the other protocol entities was implemented (see figureÊ18.2/1). Such interworking functions are assumed to perform either an identity mapping or some processing or translation as required to eliminate information irrelevant to the MAP-user. The mapping of service primitives on to protocol elements is described in clauses 14 to 17. GSMÊsignalling procedures are built from one or more sub-procedures (e.g. authentication, ciphering, ...). Sub procedures from which signalling procedures are built are represented using SDL MACRO descriptions. In case of any discrepancy between the textual descriptions and the SDL descriptions, the latter take precedence. 18.2.2 Naming conventions Events related to MAP are represented by MAP service primitives. The signal names used in the SDL diagrams are derived from the service primitive names defined in clauses 7 to 12, with some lexical transformations for readability and parsability purposes (blanks between words are replaced by underscores, the first letter of each word is capitalised). Events received and sent on other interfaces are named by appending the message or signal name to a symbol representing the interface type, with some lexical transformations for readability and parsability purposes (blanks between words are replaced by underscores, the first letter of each word is capitalised). The following symbols are used to represent the interface types: ""I"": For interfaces to the fixed network. ""I"" stands for ISUP interface. ""A"": For interfaces between the MSC and the BSS (i.e. A-interfaces); ""Gb"": For interfaces between the SGSN and the BSS (i.e. Gb-interfaces); ""OM"": For network management interfaces (communication with OMC, MML interface, ...); ""SC"": For interfaces to a Service Centre; ""HO_CA"": For internal interfaces to the Handover Control Application. ""US"": For a local USSD application. These naming conventions can be summarised by the following BNF description: <Event_Name> ::= <MAP_Primitive> | <External_Event> <MAP_Primitive> ::= <MAP_Open> | <MAP_Close> | <MAP_U_Abort> | <MAP_P_Abort> | <MAP_Specific> | <MAP_Notice> <MAP_Open> ::= MAP_Open_Req | MAP_Open_Ind | MAP_Open_Rsp | MAP_Open_Cnf <MAP_Close> ::= MAP_Close_Req | MAP_Close_Ind <MAP_U_Abort> ::= MAP_U_Abort_Req | MAP_U_Abort_Ind <MAP_P_Abort> ::= MAP_P_Abort_Ind <MAP_Notice> ::= MAP_Notice_Ind <MAP_Specific> ::= <MAP_Req> | <MAP_Ind> | <MAP_Rsp> | <MAP_Cnf> <MAP_Req> ::= MAP_<Service_Name>_Req <MAP_Ind> ::= MAP_<Service_Name>_Ind <MAP_Rsp> ::= MAP_<Service_Name>_Rsp <MAP_Cnf> ::= MAP_<Service_Name>_Cnf <External_Event> ::= <Interface_Type>_<External_Signal> <Interface_Type> ::= I | A | Gb | OM | SC | HO AC | US <External_Signal> ::= <Lexical_Unit> <Service_Name> ::= <Lexical_Unit> <Lexical_Unit> ::= <Lexical_Component> | <Lexical_Unit>_ <Lexical_Component> <Lexical_Component> ::= <Upper_Case_Letter><Letter_Or_Digit_List> <Letter_Or_Digit_List> ::= <Letter_Or_Digit> | <Letter_Or_Digit_List><Letter_Or_Digit> <Letter_Or_Digit> ::= <Letter> | <Digit> <Letter> ::= <Lower_Case_Letter> | <Upper_Case_Letter> <Upper_Case_Letter> ::= A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z <Lower_Case_Letter> ::= a|b|c|d|e|f|g|h|i|j|k|l|m|n|o|p|q|r|s|t|u|v|w|x|y|z <Digit> ::= 1|2|3|4|5|6|7|8|9|0 FigureÊ18.2/1: Interfaces applicable to the MAP-User 18.2.3 Convention on primitives parameters 18.2.3.1 Open service When the originating and destination reference parameters shall be included in the MAP-OPEN request primitive, their value are indicated as a comment to the signal which represents this primitive. 18.2.3.2 Close service When a pre-arranged released is requested, a comment is attached to the signal which represents the MAP-CLOSE request primitive. In the absence of comment, a normal release is assumed. 18.2.4 Version handling at dialogue establishment Unless explicitly indicated in subsequent clauses, the following principles regarding version handling procedures at dialogue establishment are applied by the MAP-user. 18.2.4.1 Behaviour at the initiating side When a MAP user signalling procedure has to be executed, the MAP-user issues a MAP-OPEN request primitive with an appropriate application-context-name. If several names are supported (i.e. several versions) a suitableÊone is selected using the procedures described in clauseÊ5. If version n is selected (where 1 < n <= highest existing version) and a MAP-OPEN Confirm primitive is received in response to the MAP-OPEN request with a result parameter set to ""refused"" and a diagnostic parameter indicating ""application context not supported"" or ""potential version incompatibility problem"", the MAP-User issues a new MAP-OPEN request primitive with the equivalent version y context (where 1 <= y < n). This is informally represented in the SDL diagrams by task symbols indicating 'Perform Vr procedure"". 18.2.4.2 Behaviour at the responding side On receipt of a MAP-OPEN indication primitive, the MAP-User analyses the application-context-name and executes the procedure associated with the requested version context. For example,if it refers to a version one context, the associated V1 procedure is executed; if it refers to a version two context, the associated V2 procedure is executed;etc. 18.2.5 Abort Handling Unless explicitly indicated in subsequent clauses, the following principles are applied by the MAP-user regarding abort handling procedures: On receipt of a MAP-P-ABORT indication or MAP-U-ABORT Indication primitive from any MAP-provider invocation, the MAP-User issues a MAP-U-ABORT Request primitive to each MAP-provider invocation associated with the same user procedure. If applicable a decision is made to decide if the affected user procedure has to be retried or not. 18.2.6 SDL conventions The MAP SDLs make use of a number of SDL concepts and conventions, where not all of them may be widely known. Therefore, this clauseÊoutlines the use of a few concepts and conventions to improve understanding of the MAP SDLs. The MAP User SDLs make use of SDL Processes, Procedures and Macros. Processes are independent from each other even if one process starts another one: The actions of both of them have no ordering in time. SDL Procedures and Macros are just used to ease writing of the specification: They contain parts of a behaviour used in several places, and the corresponding Procedure/Macro definition has to be expanded at the position of the Procedure/Macro call. All Processes are started at system initialisation and live forever, unless process creation/termination is indicated explicitly (i.e. a process is created by some other process). The direction of Input/Output Signals in the SDL graphs is used to indicate the entity to which/from which communication is directed. If a process A communicates in parallel with processes B and C, all Inputs/Outputs to/from B are directed to one side, whereas communication with C is directed to the other side. However, there has been no formal convention used that communication to a certain entity (e.g. a HLR) will always be directed to a certain side (e.g. right). In each state all those Input Signals are listed, which result in an action and/or state change. If an Input Signal is not listed in a state, receipt of this input should lead to an implicit consumption without any action or state change (according to the SDL rules). This implicit consumption is mainly used for receipt of the MAP DELIMITER indication and for receipt of a MAP CLOSE indication, except for a premature MAP CLOSE. 18.3 Interaction between MAP Provider and MAP Users Each MAP User is defined by at least one SDL process. On the dialogue initiating side, the MAP User will create a new instance of a MAP Provider implicit by issuing a MAP-OPEN request. This instance corresponds to a TC Dialogue and lives as long as the dialogue exists (see also clauseÊ14.3). There is a fixed relation between MAP User and this Provider instance, i.e. all MAP service primitives from the MAP User for this dialogue are sent to this instance and all TC components received by this MAP Provider are mapped onto service primitives sent to this MAP User. On the receiving side a MAP Provider instance is created implicit by receipt of a TC BEGIN indication. The corresponding MAP User is determined by the Application Context name included in this primitive, i.e. each Application Context is associated with one and only one MAP User. An instance of this User will be created implicitly by receiving a MAP-OPEN indication. Note that in some cases there exist several SDL Processes for one MAP User (Application Context), e.g. the processes Register_SS_HLR, Erase_SS_HLR, Activate_SS_HLR, Deactivate_SS_HLR, Interrogate_SS_HLR, and Register_Password for the AC Network_Functional_SS_Handling. In these cases, a coordinator process is introduced acting as a MAP User, which in turn starts a sub-process depending on the first MAP service primitive received. 19 Mobility procedures 19.1 Location management Procedures The signalling procedures in this clause support: - Interworking between the VLR and the HLR and between the VLR and the previous VLR (PVLR) when a non-GPRS subscriber performs a location update to a new VLR service area; - Interworking between the SGSN, the HLR and the VLR when a subscriber with both GPRS and non-GPRS subscriptions performs a routeing area update in an SGSN and the Gs interface is implemented; - Interworking between the SGSN and the VLR when a GPRS subscriber performs a routeing area update to a new SGSN service area; - Interworking between the HLR and the VLR and between the HLR and the SGSN to delete a subscriber record from the VLR or the SGSN; - Interworking between the VLR and the HLR and between the SGSN and the HLR to report to the HLR that a subscriber record has been purged from the VLR or the SGSN. The MAP co-ordinating process in the HLR to handle a dialogue opened with the network location updating context is shown in figure 19.1/1. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ19.1/1: Process Location_Management_Coordinator_HLR 19.1.1 Location updating 19.1.1.1 General The stage 2 specification for GPRS is in 3GPP TS 23.060 [104]. The interworking between the MAP signalling procedures and the GPRS procedures in the SGSN and the HLR is shown by the transfer of signals between these procedures. The message flow for successful inter-VLR location updating when the IMSI can be retrieved from the PVLR is shown in figure 19.1.1/2. The message flow for successful inter-VLR location updating when the IMSI cannot be retrieved from the PVLR is shown in figure 19.1.1/3. The message flow for successful GPRS Attach/RA update procedure (Gs interface not installed) is shown in figure 19.1.1/4. The message flow for successful GPRS Attach/RA update procedure combined with a successful VLR location updating (Gs interface installed) is shown in figure 19.1.1/5. PVLR = Previous VLR 1) A_LU_REQUEST (Note 1) 2) MAP_SEND_IDENTIFICATION_req/ind 3) MAP_SEND_IDENTIFICATION_rsp/cnf 4) MAP_UPDATE_LOCATION_req/ind 5) MAP_CANCEL_LOCATION_req/ind 6) MAP_CANCEL_LOCATION_rsp/cnf 7) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 2) 8) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 2) 9) MAP_INSERT_SUBSCRIBER_DATA_req/ind 10) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 11) MAP_UPDATE_LOCATION_rsp/cnf 12) A_LU_CONFIRM (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TSÊ24.008Ê[35]. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: Services printed in italics are optional. FigureÊ19.1.1/2: Message flow for location updating to a new VLR area, when the IMSI can be retrieved from the previous VLR PVLR = Previous VLR 1) A_LU_REQUEST (Note 1) 2) A_IDENTITY_REQUEST (Note 1) 3) A_IDENTITY_RESPONSE (Note 1) 4) MAP_UPDATE_LOCATION_req/ind 5) MAP_CANCEL_LOCATION_req/ind 6) MAP_CANCEL_LOCATION_rsp/cnf 7) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 2) 8) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 2) 9) MAP_INSERT_SUBSCRIBER_DATA_req/ind 10) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 11) MAP_UPDATE_LOCATION_rsp/cnf 12) A_LU_CONFIRM (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TSÊ24.008Ê[35]. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: Services printed in italics are optional. FigureÊ19.1.1/3: Message flow for location updating to a new VLR area, when the IMSI cannot be retrieved from the previous VLR PSGSN = Previous SGSN 1) Gb_ATTACH_REQUEST or RA_UPDATE_REQUEST (Note 1, note 2) 2) MAP_UPDATE_GPRS_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_req/ind 4) MAP_CANCEL_LOCATION_rsp/cnf 5) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 3) 6) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 3) 7) MAP_INSERT_SUBSCRIBER_DATA_req/ind 8) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 9) MAP_UPDATE_GPRS_LOCATION_rsp/cnf 10) Gb_ATTACH_ACCEPT or RA_UPDATE_ACCEPT (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TSÊ24.008Ê[35]. The services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For security functions (authentication, ciphering, IMEI check) triggering refer to 3GPP TSÊ23.060Ê[104]. The MAP signalling invoked for these functions is described in clauseÊ25 of the present document. NOTE 3: Services printed in italics are optional. NOTE 4: Refer to 3GPP TSÊ23.060Ê[104] for termination of the procedure and triggering of the signalling on the interface between the BSS and the SGSN. FigureÊ19.1.1/4: Message flow for GPRS location updating (Gs interface not installed) 1) Gb_ATTACH_REQUEST or RA_UPDATE_REQUEST (Note 1, note 2) 2) MAP_UPDATE_GPRS_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_req/ind 4) MAP_CANCEL_LOCATION_rsp/cnf 5) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 3) 6) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 3) 7) MAP_INSERT_SUBSCRIBER_DATA_req/ind 8) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 9) MAP_UPDATE_GPRS_LOCATION_rsp/cnf 10) Gs_LOCATION_UPDATE_REQUEST (Note 4) 11) MAP_UPDATE_LOCATION_req/ind (Note 5) 12) MAP_INSERT_SUBSCRIBER_DATA_req/ind 13) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 14) MAP_UPDATE_LOCATION_rsp/cnf 15) Gs_LOCATION_UPDATE_ACCEPT (Note 4) 16) Gb_ATTACH_ACCEPT or RA_UPDATE_ACCEPT (Note 1) 17) Gb_TMSI_REALLOCATION_COMPLETE (Note 1) 18) Gs_TMSI_REALLOCATION_COMPLETE (Note 4) NOTE 1: For details of the procedure on the radio path, see 3GPP TSÊ24.008Ê[35]. The services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For security functions (authentication, ciphering, IMEI check) triggering refer to 3GPP TSÊ23.060Ê[104]. MAP processes invoked for those procedures are described in clauseÊ25.5. NOTE 3: Services printed in italics are optional. NOTE 5: For details of the procedure on the path between the SGSN and the VLR, see 3GPP TSÊ29.018Ê[106]. The services shown in chain lines indicate the trigger provided by the signalling on the path between the SGSN and the VLR, and the signalling triggered on the path between the SGSN and the VLR. NOTE 4: Refer to 3GPP TSÊ23.060Ê[104] for termination of the procedure and triggering of the signalling on the interface between the BSS and the SGSN. NOTE 5: For simplicity, the Location Cancellation procedure towards the previous VLR and optional tracing activation towards the new VLR are not shown in this figure. FigureÊ19.1.1/5: Message flow for GPRS location updating (Gs interface installed) 19.1.1.2 Procedures in the VLR The MAP process in the VLR for location updating for a non-GPRS subscriber is shown in figure 19.1.1/6. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP process in the VLR to retrieve the IMSI of a subscriber from the previous VLR (PVLR) is shown in figure 19.1.1/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The process in the VLR for location updating for a GPRS subscriber when the Gs interface is installed is shown in figure 19.1.1/8. The macro GPRS_Location_Update_Completion_VLR is shown in figure 19.1.1/9. The macro invokes a process not defined in this clause; the definition of this process can be found as follows: Subscriber_Present_VLR see clauseÊ25.10.1. The macro GPRS_Update_HLR_VLR is shown in figure 19.1.1/10. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2; Insert_Subs_Data_VLR see clauseÊ25.7.1; Activate_Tracing_VLR see clauseÊ25.9.4. 19.1.1.3 Procedure in the PVLR The MAP process in the PVLR to handle a request for the IMSI of a subscriber from the new VLR is shown in figure 19.1.1/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 19.1.1.4 Procedure in the SGSN The MAP process in the SGSN for location updating for a GPRS subscriber is shown in figure 19.1.1/12. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2; Insert_Subs_Data_SGSN see clauseÊ25.7.2; Activate_Tracing_SGSN see clauseÊ25.9.5. Sheet 2: The procedure Check_User_Error_In_Serving_Network_Entity is specific to Super-Charger; it is specified in 3GPP TSÊ23.116 [110]. 19.1.1.5 Procedures in the HLR The MAP process in the HLR to handle a location updating request from a VLR is shown in figure 19.1.1/13. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. The MAP process in the HLR to handle a location updating request from an SGSN is shown in figure 19.1.1/14. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2; Control_Tracing_With_SGSN_HLR see clauseÊ25.9.7. Sheet 2: The procedure Super_Charged_Cancel_Location_HLR is specific to Super-Charger; it is specified in 3GPPÊTSÊ23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the ""No"" exit of the test ""Result=Pass?"". Sheet 2: The procedure Super_Charged_Location_Updating_HLR is specific to Super-Charger; it is specified in 3GPPÊTSÊ23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the ""No"" exit of the test ""Result=Pass?"". Sheet 2: If the HLR supports the Administrative Restriction of Subscribers' Access feature and roaming is allowed in the VPLMN then the HLR may check the ""Supported RAT Types"" received from the VLR against the access restriction parameters. If this check fails then the decision box ""Roaming allowed in this PLMN"" shall take the exit ""No"". The MAP process in the HLR to notify Short Message Service Centres that a subscriber is now reachable is shown in figure 19.1.1/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Alert_Service_Centre_HLR see clauseÊ25.10.3. Figure 19.1.1/6 (sheet 1 of 2): Process Update_Location_VLR Figure 19.1.1/6 (sheet 2 of 2): Process Update_Location_VLR Figure 19.1.1/7 (sheet 1 of 2): Process Send_Identification_VLR Figure 19.1.1/7 (sheet 2 of 2): Process Send_Identification_VLR FigureÊ19.1.1/8 (sheet 1 of 2): Process GPRS_Update_Location_Area_VLR FigureÊ19.1.1/8 (sheet 2 of 2): Process GPRS_Update_Location_Area_VLR FigureÊ19.1.1/9: Macro GPRS_Location_Update_Completion_VLR FigureÊ19.1.1/10 (sheet 1 of 2): Macro GPRS_Update_HLR_VLR FigureÊ19.1.1/10 (sheet 2 of 2): Macro GPRS_Update_HLR_VLR Figure 19.1.1/11 (sheet 1 of 2): Process Send_Identification_PVLR Figure 19.1.1/11 (sheet 2 of 2): Process Send_Identification_PVLR FigureÊ19.1.1/12 (sheet 1 of 2): Process Update_GPRS_Location_SGSN FigureÊ19.1.1/12 (sheet 2 of 2): Process Update_GPRS_Location_SGSN FigureÊ19.1.1/13 (sheet 1 of 3): Process Update_Location_HLR FigureÊ19.1.1/13 (sheet 2 of 3): Process Update_Location_HLR FigureÊ19.1.1/13 (sheet 3 of 3): Process Update_Location_HLR FigureÊ19.1.1/14 (sheet 1 of 2): Process Update_GPRS_Location_HLR FigureÊ19.1.1/14 (sheet 2 of 2): Process Update_GPRS_Location_HLR FigureÊ19.1.1/15: Process Subscriber_Present_HLR 19.1.1A Location updating for VCSG 19.1.1A.1 General The message flow for successful VCSG location updating between VLR and CSS or between SGSN and CSS is shown in figure 19.1.1A/1. 1) MAP_UPDATE_VCSG_LOCATION_req/ind 2) MAP_INSERT_SUBSCRIBER_DATA_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 4) MAP_UPDATE_VCSG_LOCATION_rsp/cnf Figure 19.1.1A/1: Message flow for VCSG location updating 19.1.1A.2 Procedures in the VLR The MAP process in the VLR for VCSG location updating for a roaming subscriber is shown in figure 19.1.1A/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Insert_Subs_Data_VLR see clause 25.7.2. 19.1.1A.3 Procedures in the SGSN The MAP process in the SGSN for VCSG location updating for a roaming subscriber is shown in figure 19.1.1A/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Insert_Subs_Data_SGSN see clause 25.7.2. 19.1.1A.4 Procedures in the CSS The MAP process in the CSS to handle a VCSG location updating request from a VLR or SGSN is shown in figure 19.1.1A/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1; Check_Indication see clause 25.2.1; Check_Confirmation see clause 25.2.2; Insert_VCSG_Subs_Data_Framed_CSS see clause 19.5A.1. Figure 19.1.1A/2 (sheet 1 of 2): Process Update_VCSG_Location_VLR Figure 19.1.1A/2 (sheet 2 of 2): Process Update_VCSG_Location_VLR Figure 19.1.1A/3 (sheet 1 of 2): Process Update_VCSG_Location_SGSN Figure 19.1.1A/3 (sheet 2 of 2): Process Update_VCSG_Location_SGSN Figure 19.1.1A/4 (sheet 1 of 2): Process Update_VCSG_Location_CSS Figure 19.1.1A/4 (sheet 2 of 2): Process Update_VCSG_Location_CSS 19.1.2 Location Cancellation 19.1.2.1 General Location cancellation is used to delete a subscriber record from the serving node (VLR or SGSN). The procedure is invoked: - because the subscriber has registered with a new serving node, or - because the HPLMN operator has decided to delete the subscriber record from the serving node, e.g. because the subscription has been withdrawn, or because roaming restrictions have been imposed. Location cancellation can be used to force location updating including updating of subscriber data in the serving node at the next subscriber access. The message flow for location cancellation for a non-GPRS subscriber is shown in figure 19.1.2/1. The message flow for location cancellation for a GPRS subscriber is shown in figure 19.1.2/2. 1) MAP_UPDATE_LOCATION_req/ind 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf NOTE: The service shown in dotted lines indicates the trigger provided by other MAP signalling. FigureÊ19.1.2/1: Message flow for Location Cancellation (non-GPRS) 1) MAP_UPDATE_GPRS_LOCATION_req/ind 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf NOTE: The service shown in dotted lines indicates the trigger provided by other MAP signalling. FigureÊ19.1.2/2: Message flow for Location Cancellation (GPRS) 19.1.2.2 Procedure in the HLR The MAP process in the HLR to cancel the location information in a VLR is shown in figure 19.1.2/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP process in the HLR to cancel the location information in a VLR as an independent process invoked from another process is shown in figure 19.1.2/4. The MAP process in the HLR to cancel the location information in an SGSN is shown in figure 19.1.2/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP process in the HLR to cancel the location information in an SGSN as an independent process invoked from another process is shown in figure 19.1.2/6. 19.1.2.3 Procedure in the VLR The MAP process in the VLR to handle a location cancellation request is shown in figure 19.1.2/7. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 19.1.2.4 Procedure in the SGSN The MAP process in the SGSN to handle a location cancellation request is shown in figure 19.1.2/8. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ19.1.2/3: Process Cancel_Location_HLR FigureÊ19.1.2/4: Process Cancel_Location_Child_HLR FigureÊ19.1.2/5: Process Cancel_GPRS_Location_HLR FigureÊ19.1.2/6: Process Cancel_GPRS_Location_Child_HLR FigureÊ19.1.2/7: Process Cancel_Location_VLR FigureÊ19.1.2/8: Process Cancel_Location_SGSN 19.1.2A Location Cancellation for VCSG 19.1.2A.1 General Location cancellation for VCSG is used to delete a subscriber record from the serving node (VLR or SGSN). The procedure is invoked: - because there is a removal of the CSG subscription data in the CSS and of the MS registration - because the CSS has decided to cancel the registration of the MS which does not have CSG subscription data in the CSS. NOTE: How the CSS determines when to cancel the registration of the MS is implementation dependent. The message flow for VCSG location cancellation for a subscriber is shown in figure 19.1.2A/1. 1) MAP_CANCEL_VCSG_LOCATION_req/ind 2) MAP_CANCEL_VCSG_LOCATION_rsp/cnf FigureÊ19.1.2A/1: Message flow for VCSG Location Cancellation 19.1.2A.2 Procedure in the CSS The MAP process in the CSS to cancel the VCSG location information in a VLR is shown in figure 19.1.2A/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP process in the CSS to cancel the VCSG location information in a SGSN is shown in figure 19.1.2A/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 19.1.2A.3 Procedure in the VLR The MAP process in the VLR to handle a VCSG location cancellation request is shown in figure 19.1.2A/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 19.1.2A.4 Procedure in the SGSN The MAP process in the SGSN to handle a VCSG location cancellation request is shown in figure 19.1.2A/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ19.1.2A/2: Process Cancel_VCSG_Location_CSS FigureÊ19.1.2A/3: Process Cancel_VCSG_Location_VLR FigureÊ19.1.2A/4: Process Cancel_VCSG_Location_SGSN 19.1.3 Void 19.1.4 MS Purging 19.1.4.1 General O&M procedures in the VLR or SGSN can trigger MS purging either because of administrative action or because the MS has been inactive for an extended period. The O&M process in the VLR or in the SGSN should ensure that during the MS purging procedure any other attempt to access the MS record is blocked, to maintain consistency of data. The message flow for a VLR to report MS purging to the HLR is shown in figure 19.1.4/1. The message flow for an SGSN to report MS purging to the HLR is shown in figure 19.1.4/2. 1) MAP_PURGE_MS_req/ind 2) MAP_PURGE_MS_rsp/cnf FigureÊ19.1.4/1: Message flow for MS purging (non-GPRS) 1) MAP_PURGE_MS_req/ind 2) MAP_PURGE_MS_rsp/cnf FigureÊ19.1.4/2: Message flow for MS purging (GPRS) 19.1.4.2 Procedure in the VLR The MAP process in the VLR to report MS purging to the HLR is shown in figure 19.1.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 19.1.4.3 Procedure in the SGSN The MAP process in the SGSN to report MS purging to the HLR is shown in figure 19.1.4/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: The procedure Purge_MS_In_Serving_Network_Entity is specific to Super-Charger; it is specified in 3GPP TSÊ23.116 [110]. If the HLR does not support the Super-Charger functionality, processing continues from the ""No"" exit of the test ""Result=Pass?"". 19.1.4.4 Procedure in the HLR The MAP process in the HLR to handle a notification from a VLR or an SGSN that an MS record has been purged is shown in figure 19.1.4/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. If the notification was received from a VLR, the MAP process communicates with the location management application process specified in 3GPPÊTSÊ23.012Ê[23]; if the notification was received from an SGSN, the MAP process communicates with the GPRS mobility management application process specified in 3GPPÊTSÊ23.060Ê[104]. FigureÊ19.1.4/3: Process Purge_MS_VLR FigureÊ19.1.4/4 (sheet 1 of 2): Process Purge_MS_SGSN FigureÊ19.1.4/4 (sheet 2 of 2): Process Purge_MS_SGSN FigureÊ19.1.4/5: Process Purge_MS_HLR 19.2 Handover procedures 19.2.1 General In this clause, the term ""Inter-MSC handover"" is used to denote handover or relocation between different MSCs. The interfaces involved for Inter-MSC handover are shown in figureÊ19.2/1. There are two Inter-MSC handover procedures: 1) Basic Inter-MSC handover: The call is handed over from the controlling MSC(MSCÑA) to another MSC(MSCÑB) (figureÊ19.2/1a). FigureÊ19.2/2 shows the message flow for a successful handover from MSC A to MSCÑB, including a request for handover number allocation from MSC B to VLR B. 2) Subsequent Inter-MSC handover: After the call has been handed over from MSC A to MSC B, a further handover either to MSC A (figureÊ19.2/1a) or to a third MSC (MSC B') (figureÊ19.2/1b) may be necessary in order to continue the call. FigureÊ19.2/3 shows the message flow for a successful subsequent handover to MSC B'. For a successful subsequent handover to MSC A, the messages to and from MSC B' and VLR B' are omitted.. a) Basic handover procedure MSC A to MSC B and subsequent handover procedure MSC B to MSC A. b) Subsequent handover procedure MSC B to MSC B'. FigureÊ19.2/1: Interface structure for handover 1) MAP_PREPARE_HANDOVER_req/ind 2) MAP_ALLOCATE_HANDOVER_NUMBER_req/ind 3) MAP_SEND_HANDOVER_REPORT_req/ind 4) MAP_PREPARE_HANDOVER_rsp/cnf 5) MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note) 6) MAP_PROCESS_ACCESS_SIGNALLING_req/ind 7) MAP_SEND_END_SIGNAL_req/ind 8) MAP_FORWARD_ACCESS_SIGNALLING_req/ind 9) MAP_PROCESS_ACCESS_SIGNALLING_req/ind 10) MAP_SEND_END_SIGNAL_rsp/cnf NOTE: This can be sent at any time after the connection between MSC A and MSC B is established. FigureÊ19.2/2: Example of a successful basic handover procedure to MSC B 1) MAP_PREPARE_HANDOVER_req/ind 2) MAP_ALLOCATE_HANDOVER_NUMBER_req/ind 3) MAP_SEND_HANDOVER_REPORT_req/ind 4) MAP_PREPARE_HANDOVER_rsp/cnf 5) MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note 1) 6) MAP_PROCESS_ACCESS_SIGNALLING_req/ind 7) MAP_SEND_END_SIGNAL_req/ind 8) MAP_PREPARE_SUBSEQUENT_HANDOVER_req/ind 9) MAP_PREPARE_HANDOVER_req/ind 10) MAP_ALLOCATE_HANDOVER_NUMBER_req/ind 11) MAP_SEND_HANDOVER_REPORT_req/ind 12) MAP_PREPARE_HANDOVER_rsp/cnf 13) MAP_SEND_HANDOVER_REPORT_rsp/cnf (Note 2) 14) MAP_PREPARE_SUBSEQUENT_HANDOVER_rsp/cnf 15) MAP_PROCESS_ACCESS_SIGNALLING_req/ind 16) MAP_SEND_END_SIGNAL_req/ind 17) MAP_SEND_END_SIGNAL_rsp/cnf (Note 3) NOTE 1: This can be sent at any time after the connection between MSC A and MSC B is established. NOTE 2: This can be sent at any time after the connection between MSC A and MSC B' is established. NOTE 3: At this stage, the subsequent handover is complete. Any further interworking between MSC A and MSC B' is the same as the interworking between MSC A and MSC B after basic handover FigureÊ19.2/3: Example of a successful subsequent handover to a third MSC The MAP signalling procedures for inter-MSC handover support the allocation of a handover number or one or more relocation numbers and the transfer of encapsulated BSSAP or RANAP messages. The minimum application context version for the MAP handover application context shall be: - version 3 for inter-MSC UTRAN to UTRAN handover; - version 3 for inter-MSC intersystem handover from GSM BSS to UTRAN; - version 2 for inter-MSC intersystem handover from UTRAN to GSM BSS. NOTE: If the MAP handover application context version 2 is used, subsequent handover to UTRAN is not possible. The minimum application context version for the MAP handover application context should be version 2 for inter-MSC handover from GSM BSS to GSM BSS. NOTE: If the MAP handover application context version 2 or lower is used, subsequent handover to UTRAN is not possible. The BSSAP or RANAP messages encapsulated in MAP messages are processed by the Handover Control Application in each MSC. The information in the encapsulated BSSAP or RANAP messages is passed from the Handover Control Application to the MAP process at the sending end; the notation used in the SDL diagrams for the MAP processes is ""HO_CA_MESSAGE_ind(Message transfer)"". The information in the encapsulated BSSAP or RANAP messages is passed from the MAP process to the Handover Control Application at the sending end; the notation used in the SDL diagrams for the MAP processes is ""HO_CA_MESSAGE_req(Message transfer)"". For details of the interworking between the A-interface and MAP procedures or the Iu-interface and MAP procedures, see 3GPP TSÊ23.009Ê[21] and 3GPP TSÊ29.010Ê[58]. 19.2.2 Procedure in MSC A This clause describes the inter-MSC handover procedure in MSC A; it covers basic inter-MSC handover to another MSC (MSC B) and subsequent inter-MSC handover to a third MSC (MSC B') or back to the controlling MSC (MSC A). The MAP process in MSC A to handle inter-MSC handover is shown in figure 19.2/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1. Check_Confirmation see clauseÊ25.2.2. Communication between the MAP handover process and the Handover Control application is represented by the HO_CA_MESSAGE service. For a detailed description of the interworking between the Handover Control applications in different MSCs for the inter-MSC handover procedure, see 3GPP TSÊ23.009Ê[21]. 19.2.2.1 Basic handover The handling in MSC A for basic inter-MSC handover is shown in sheets 1 to 6 of figure 19.2/4."
"Sheet 1: The MAP_PREPARE_HANDOVER request may contain: - an indication that handover number allocation is not required; - the target Cell ID, for compatibility for handover to GSM; - the target RNC ID, for SRNS relocation or inter-system handover from GSM to UMTS; - the IMSI; - UMTS encryption information and UMTS integrity protection information, which are necessary for inter-system handover from GSM to UMTS; - GSM radio resource information (channel type); - the LCLS Global Call Reference; - the LCLS-Negotiation; - the LCLS-Configuration-Preference. The conditions for the presence of these parameters and the processing in MSC B (3G_MSC B) are described in detail in 3GPPÊTSÊ29.010Ê[58], 3GPPÊTSÊ23.009Ê[21] and 3GPPÊTSÊ29.205Ê[146]. Sheet 2: The MAP_PREPARE_HANDOVER confirmation contains one of: - no handover number, if the MAP_PREPARE_HANDOVER request included an indication that handover number allocation is not required; - a handover number; - one or more relocation numbers. Sheet 2: The MAP_PREPARE_HANDOVER confirmation contains BSSAP or RANAP signalling information, which is passed to the Handover Control application in MSC A. Sheet 2: If the MAP_PREPARE_HANDOVER confirmation contains an indication that MSC B does not support multiple bearers, the Handover Control application in MSC A may request handover of one bearer to the same cell in MSC B. Sheet 5: If the original MAP_PREPARE_HANDOVER request included a parameter indicating that handover number allocation is not required, the Handover Control application in MSC A may request a handover number (or one or more relocation numbers); this triggers a further MAP_PREPARE_HANDOVER request towards MSC B. 19.2.2.2 Handling of access signalling The Handover Control application in MSC A may forward access signalling to any of the MS, RNS B or BSS B using the MAP_FORWARD_ACCESS_SIGNALLING service; any of the MS, RNS B or BSS B may forward access signalling to the Handover Control application in MSC A using the MAP_PROCESS_ACCESS_SIGNALLING service. These are non-confirmed services. 19.2.2.3 Subsequent handover The handling in MSC A for subsequent inter-MSC handover is shown in sheets 7 & 8 of figure 19.2/4. If the Handover Control Application determines that the call is to be handed over to a third MSC (MSC B') it triggers another instance of the MAP process to handle the basic handover to MSC B', and reports the result of the subsequent handover to the instance of the MAP process which handles the dialogue with MSC B. Sheet 8: While the MAP process in MSC A is waiting for the completion of subsequent handover, it relays access signalling between the Handover Control application and the MS, RNS B or BSS B as described in clause 19.2.2.2. 19.2.3 Procedure in MSC B This clause describes the handover or relocation procedure in MSC B; it covers basic handover or relocation from the controlling MSC (MSC A) and subsequent handover or relocation. The MAP process in MSC B to handle handover or relocation is shown in figure 19.2/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1. Check_Confirmation see clauseÊ25.2.2. Communication between the MAP handover process and the Handover Control application is represented by the HO_CA_MESSAGE service. For a detailed description of the interworking between the Handover Control applications in different MSCs for the inter-MSC handover procedure, see 3GPP TSÊ23.009Ê[21]. The ordering of allocation of handover number and radio resources shown in the SDL diagrams is not mandatory. 19.2.3.1 Basic handover The handling in MSC B for basic inter-MSC handover is shown in sheets 1 to 7 of figure 19.2/5. Sheet 2: If the MAP_PREPARE_HANDOVER indication included a parameter requesting multiple bearers but MSC B does not support multiple bearers, MSC B sends a MAP_PREPARE_HANDOVER response indicating that multiple bearers are not supported, and waits for a possible MAP_PREPARE_HANDOVER indication requesting handover of a single bearer. Sheet 6: If the original MAP_PREPARE_HANDOVER indication included a parameter indicating that handover number allocation is not required, MSC A may send a further MAP_PREPARE_HANDOVER request to request the allocation of a handover number (or one or more relocation numbers). 19.2.3.2 Handling of access signalling The Handover Control application in MSC A may forward access signalling to any of the MS, RNS B or BSS B using the MAP_FORWARD_ACCESS_SIGNALLING service; any of the MS, RNS B or BSS B may forward access signalling to the Handover Control application in MSC A using the MAP_PROCESS_ACCESS_SIGNALLING service. These are non-confirmed services. Signals to or from any of the MS, RNS B or BSS B are routed through the Handover Control application in MSC B. 19.2.3.3 Subsequent handover The handling in MSC B for subsequent inter-MSC handover is shown in sheet 8 of figure 19.2/5. While the MAP process in MSC B is waiting for the completion of subsequent handover, it relays access signalling between MSC A and the MS, RNS B or BSS B through the Handover Control application as described in clause 19.2.3.2. 19.2.4 Macro Receive_Error_From_HO_CA This macro is used by the handover processes in MSC A and MSC B to receive errors from the Handover Control Application at any state of a handover process. 19.2.5 Procedure in VLR B The process in VLR-B to handle a request for a handover number is shown in figure 19.2/7. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. FigureÊ19.2/4 (sheet 1 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 2 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 3 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 4 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 5 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 6 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 7 of 8): Process HO_MSC_A FigureÊ19.2/4 (sheet 8 of 8): Process HO_MSC_A FigureÊ19.2/5 (sheet 1 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 2 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 3 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 4 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 5 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 6 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 7 of 8): Process HO_MSC_B FigureÊ19.2/5 (sheet 8 of 8): Process HO_MSC_B FigureÊ19.2/6: Macro Receive_error_from_HO_CA FigureÊ19.2/7: Process HO_VLR_B 19.3 Fault recovery procedures When a location register has restarted after a fault, the fault recovery procedures ensure that the subscriber data in the VLR or in the SGSN become consistent with the subscriber data that are stored in the HLR for the MS concerned and that the location information in the HLR , the VLR and the SGSN reflect accurately the current location of the MS. The stage 2 specification of fault recovery procedures in location registers is 3GPP TS 23.007 [19]. 19.3.1 VLR fault recovery procedures 19.3.1.1 General Restoration of an IMSI record in a VLR can be triggered by a location registration request from the MS or by a request from the HLR for a roaming number to route a mobile terminated call to the MS. If the restoration is triggered by a location registration request from the MS, the VLR performs the location updating procedure described in 3GPPÊTSÊ23.012Ê[23] and clause 19.1.1 of the present document. If the restoration is triggered by a request for a roaming number, the VLR provides the roaming number and triggers an independent dialogue to restore the subscriber data as described in 3GPPÊTSÊ23.018Ê[97]. The message flow for data restoration triggered by a request for a roaming number is shown in figure 19.3.1/1. 1) MAP_PROVIDE_ROAMING_NUMBER_req/ind 2) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf 3) MAP_SEND_AUTHENTICATION_INFO_req/ind (Note 1, note 2) 4) MAP_SEND_AUTHENTICATION_INFO_rsp/cnf (Note 1, note 2) 5) MAP_RESTORE_DATA_req/ind 6) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, note 3) 7) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, note 3) 8) MAP_INSERT_SUBSCRIBER_DATA_req/ind 9) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 10) MAP_RESTORE_DATA_rsp/cnf NOTE 1: Services printed in italics are optional. NOTE 2: If authentication is required. NOTE 3: If subscriber tracing is active in the HLR. FigureÊ19.3/1: Message flow for VLR restoration at mobile terminated call set-up 19.3.1.2 Procedure in the VLR The procedure in the VLR to handle a dialogue for subscriber data restoration is defined in clauseÊ21.2.6 of the present document. 19.3.1.3 Procedure in the HLR The MAP process in the HLR to handle a request for data restoration in the VLR is shown in figure 19.3.1/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clauseÊ25.2.1; Control_Tracing_With_VLR_HLR see clauseÊ25.9.6. FigureÊ19.3.1/2: Process Restore_Data_HLR 19.3.2 HLR fault recovery procedures 19.3.2.1 General For the HLR, periodic back-up of data to non-volatile memory is mandatory. Data that have been changed after the last back-up and before the restart of the HLR cannot be recovered by reload from the non-volatile memory. Therefore, a restoration procedure is triggered for each IMSI record that has been affected by the HLR fault at the first authenticated radio contact with the MS concerned. As an implementation option, a notification can be forwarded to the MS to alert the subscriber to check the parameters for supplementary services that allow subscriber controlled input (MAP_FORWARD_CHECK_SS_INDICATION service). If the VLR receives this notification from the HLR it shall forward the notification to the MS. If the Gs-interface is implemented the VLR shall not forward this notification. A restoration procedure may also be triggered for IMSI records that shares subscription data with other IMSI records when the shared subscription data is modified, added or deleted. This option presumes the support of Reset-IDs. The message flow for HLR restoration for a non-GPRS subscriber is shown in figure 19.3.2/1. The message flow for HLR restoration for a GPRS subscriber is shown in figure 19.3.2/2. 1) MAP_RESET_req/ind 2) MAP_PROCESS_ACCESS_REQUEST_req/ind 3) MAP_UPDATE_LOCATION_req/ind 4) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, Note 2) 5) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, Note 2) 6) MAP_INSERT_SUBSCRIBER_DATA_req/ind 7) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 8) MAP_UPDATE_LOCATION_rsp/cnf 9) MAP_FORWARD_CHECK_SS_INDICATION_req/ind (Note 1) 10) MAP_FORWARD_CHECK_SS_INDICATION_req/ind (Note 1) NOTE 1: Services printed in italics are optional. NOTE 2: If subscriber tracing is active in the HLR. Steps 2 to 10 may be skipped if the procedure is used to update shared subscription data. FigureÊ19.3.2/1: Message flow for HLR restoration (non-GPRS) 1) MAP_RESET_req/ind 2) MAP_UPDATE_GPRS_LOCATION_req/ind 3) MAP_ACTIVATE_TRACE_MODE_req/ind (Note 1, Note 2) 4) MAP_ACTIVATE_TRACE_MODE_rsp/cnf (Note 1, Note 2) 5) MAP_INSERT_SUBSCRIBER_DATA_req/ind 6) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 7) MAP_UPDATE_GPRS_LOCATION_rsp/cnf NOTE 1: Services printed in italics are optional. NOTE 2: If subscriber tracing is active in the HLR. Steps 2 to 7 may be skipped if the procedure is used to update shared subscription data. FigureÊ19.3.2/2: Message flow for HLR restoration (GPRS) 19.3.2.2 Procedure in the HLR The MAP process in the HLR to notify the relevant serving nodes that the HLR has restarted is shown in figure 19.3.2/3. The SGSN address list includes one instance of the address of each SGSN in which (according to the HLR data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the HLR restart. The VLR address list includes one instance of the address of each VLR in which (according to the HLR data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the HLR restart. The MAP process in the HLR to notify a VLR that the HLR has restarted is shown in figure 19.3.2/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2. The MAP process in the HLR to notify an SGSN that the HLR has restarted is shown in figure 19.3.2/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2. 19.3.2.3 Procedure in the VLR The MAP process in the VLR to handle a notification that an HLR has restarted is shown in figure 19.3.2/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. When Reset-IDs are not supported or not present in the MAP_RESET indication, the VLR uses the HLR number or the HLR identity list included in the MAP_RESET indication to identify the IMSI records which are affected by the HLR restart. When Reset-IDs are supported and present in the MAP_RESET indication, the VLR uses the Reset-IDs included in the MAP_RESET indication to identify the affected IMSI records. The task ""Update Data"" includes any required action to let the update come into effect. If the update of shared subscription data requires only local updates in the VLR (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring). If the update of shared subscription data implies initiating a signalling interaction towards other nodes, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE. NOTE: The rational for the recommendationÊto defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user's activity. To avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the VLR may take a maximum operator configuration-depending time. 19.3.2.4 Procedure in the SGSN The MAP process in the SGSN to handle a notification that an HLR has restarted is shown in figure 19.3.2/7. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. When Reset-IDs are not supported or not present in the MAP_RESET indication, the SGSN uses the HLR number or the HLR identity list included in the MAP_RESET indication to identify the IMSI records which are affected by the HLR restart. When Reset-IDs are supported and present in the MAP_RESET indication, the SGSN uses the Reset-IDs included in the MAP_RESET indication to identify the affected IMSI records. The task ""Update Data"" includes any required action to let the update come into effect. If the update of shared subscription data requires only local updates in the SGSN (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring). If the update of shared subscription data implies initiating a signalling interaction towards other nodes, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE. NOTE: The rational for the recommendationÊto defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user's activity. To avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the SGSN may take a maximum operator configuration-depending time. FigureÊ19.3.2/3: Process Restart_HLR FigureÊ19.3.2/4: Process Send_Reset_To_VLR_HLR FigureÊ19.3.2/5: Process Send_Reset_To_SGSN_HLR FigureÊ19.3.2/6: Process Receive_Reset_VLR FigureÊ19.3.2/7: Process Receive_Reset_SGSN 19.3.3 CSS fault recovery procedures 19.3.3.1 General For the CSS, periodic back-up of data to non-volatile memory is mandatory. Serving node numbers that have been changed after the last back-up and before the restart of the CSS cannot be recovered by reload from the non-volatile memory. Therefore, a restoration procedure is triggered for each IMSI record that has been affected by the CSS fault at the first authenticated radio contact with the MS concerned. The message flow for CSS restoration for a non-GPRS subscriber is shown in figure 19.3.3/1. The message flow for CSS restoration for a GPRS subscriber is shown in figure 19.3.3/2. 1) MAP_RESET_req/ind 2) MAP_UPDATE_VCSG_LOCATION_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_req/ind 4) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 5) MAP_UPDATE_VCSG_LOCATION_rsp/cnf Figure 19.3.3/1: Message flow for CSS restoration (non-GPRS) 1) MAP_RESET_req/ind 2) MAP_UPDATE_VCSG_LOCATION_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_req/ind 4) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf 5) MAP_UPDATE_VCSG_LOCATION_rsp/cnf Figure 19.3.3/2: Message flow for CSS restoration (GPRS) 19.3.3.2 Procedure in the CSS The MAP process in the CSS to notify the relevant serving nodes that the CSS has restarted is shown in figure 19.3.3/3. The SGSN address list includes one instance of the address of each SGSN in which (according to the CSS data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the CSS restart. The VLR address list includes one instance of the address of each VLR in which (according to the CSS data retrieved from the non-volatile memory) there is at least one subscriber registered who is affected by the CSS restart. The MAP process in the CSS to notify a VLR that the CSS has restarted is shown in figure 19.3.3/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clause 25.1.2. The MAP process in the CSS to notify an SGSN that the CSS has restarted is shown in figure 19.3.3/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clause 25.1.2. 19.3.3.3 Procedure in the VLR The MAP process in the VLR to handle a notification that a CSS has restarted is shown in figure 19.3.3/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1. The VLR uses the CSS number (filled in Sending Node number parameter) included in the MAP_RESET indication to identify the user's IMSI records which are affected by the CSS restart. 19.3.3.4 Procedure in the SGSN The MAP process in the SGSN to handle a notification that a CSS has restarted is shown in figure 19.3.3/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1. The SGSN uses the CSS number (filled in Sending Node number parameter) included in the MAP_RESET indication to identify the user's IMSI records which are affected by the CSS restart. Figure 19.3.3/3: Process Restart_CSS Figure 19.3.3/4: Process Send_Reset_To_VLR_CSS Figure 19.3.3/5: Process Send_Reset_To_SGSN_CSS Figure 19.3.3/6: Process Receive_Reset_From_CSS_VLR Figure 19.3.3/7: Process Receive_Reset_From_CSS_SGSN 19.4 Mobility Management event notification procedure 19.4.1 General The Mobility Management event notification procedure is used to notify a gsmSCF about the successful completion of a Mobility Management event. The message flow for Mobility Management event notification is shown in figure 19.4/1. 1) MAP_REPORT_MM_EVENT_req/ind 2) MAP_REPORT_MM_EVENT_rsp/cnf FigureÊ19.5/1: Message flow for Mobility Management event notification 19.4.2 Procedure in the VLR or SGSN The MAP process in the VLR or the SGSN to report a Mobility Management event to the gsmSCF is shown in figure 19.4/2.The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation: see clauseÊ25.2.2. 19.4.3 Procedure in the gsmSCF The MAP process in the gsmSCF to handle the report of a Mobility Management event is shown in figure 19.4/3.The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; FigureÊ19.4/2: Process Notify_MM_Event_VLR_Or_SGSN Figure 19.4/3: Process Notify_MM_Event_gsmSCF 19.5 HLR Insert Subscriber Data macros 19.5.1 Macro Insert_Subs_Data_Framed_HLR This macro is used to transfer subscriber data to the VLR as part of an existing dialogue for location updating or data restoration. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows: Wait_For_Insert_Subs_Data_Cnf see clauseÊ25.7.5; Send_Insert_Subs_Data_HLR: see clauseÊ25.7.7. The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. If the VLR has indicated that it does not support a service or feature (e.g. Closed User Group or Advice Of Charge Charging Level) which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restriction Due To Unsupported Feature flag to roaming restricted and sends Roaming Restriction Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. If subscriber data for CAMEL Phase 2 or later services are sent to a VLR which does not support the appropriate phase of CAMEL, the service behaviour may be unpredictable or incorrect. The HLR should therefore ensure that at the conclusion of a stand alone Insert Subscriber data procedure the data in the VLR do not require a capability that the VLR does not have. Possible mechanisms to ensure this are described in 3GPP TS 23.078Ê[98]. The HLR should send a Forwarded-to number which is not in E.164 international format to the VLR only when the HLR has ascertained that the VLR supports CAMEL Phase 2 or later. Thus, the ISD message containing the Forwarded-to number which is not in E.164 international format shall be sent to the VLR only if the HLR previously received confirmation from the VLR at Location Update that CAMEL Phase 2 or later is supported. 19.5.2 Macro Insert_GPRS_Subs_Data_Framed_HLR This macro is used to transfer subscriber data to the SGSN as part of an existing dialogue for location updating. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows: Wait_For_Insert_GPRS_Subs_Data_Cnf see clauseÊ25.7.5; Send_Insert_Subs_Data_HLR: see clauseÊ25.7.7. The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. If the SGSN has indicated that it does not support a service or feature which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restricted In SGSN Due To Unsupported Feature flag to roaming restricted and sends Roaming Restricted In SGSN Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. FigureÊ19.5/1: Macro Insert_Subs_Data_Framed_HLR FigureÊ19.5/2: Macro Insert_GPRS_Subs_Data_Framed_HLR 19.5A CSS Insert Subscriber Data macros 19.5A.1 Macro Insert_VCSG_Subs_Data_Framed_CSS This macro is used to transfer CSG subscriber data from the CSS to the VLR or the SGSN as part of an existing dialogue for VCSG location updating. The macro invokes a macro and a process not defined in this clause; the definitions of the macro and the process can be found as follows: Wait_For_Insert_VCSG_Subs_Data_Cnf see clause 25.7.9; Send_Insert_VCSG_Subs_Data_CSS: see clause 25.7.10. The CSS may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. If the VLR or the SGSN has indicated that it does not support a service or feature which the CSS operator regards as essential for the subscriber, the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit. If the CSS operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit, the CSS sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Figure 19.5A/1: Macro Insert_VCSG_Subs_Data_Framed_CSS 20 Operation and maintenance procedures 20.1 General The Operation and Maintenance procedures are used to support operation and maintenance of the network. The following procedures exist for operation and maintenance purposes: i) Tracing procedures; ii) Subscriber Data Management procedures; iii) Subscriber Identity procedure. The following application contexts refer to complex MAP Users consisting of several processes: - subscriberDataManagementContext; - tracingContext. Each of these two application contexts needs a co-ordinating process in the VLR or in the SGSN as described in the following clauses. 20.1.1 Tracing Co-ordinator for the VLR The Tracing Co-ordinator process in the VLR is shown the figureÊ20.1/1. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 20.1.2 Tracing Co-ordinator for the SGSN The Tracing Co-ordinator process in the SGSN is shown in figureÊ20.1/2. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 20.1.3 Subscriber Data Management Co-ordinator for the VLR The Subscriber Data Management Co-ordinator process in the VLR is shown in figureÊ20.1/3 and figure 20.1/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 20.1.4 Subscriber Data Management Co-ordinator for the SGSN The Subscriber Data Management Co-ordinator process in the SGSN is shown in figureÊ20.1/4 and figure 20.1/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ20.1/1: Process Co_Tracing_VLR FigureÊ20.1/2: Process Co_Tracing_SGSN FigureÊ20.1/3: Process Co_SDM_VLR FigureÊ20.1/4: Process Co_SDM_SGSN Figure 20.1/5: Process Co_CSG_SDM_VLR Figure 20.1/6: Process Co_CSG_SDM_SGSN 20.2 Tracing procedures Three types of tracing procedures exist: i) Subscriber tracing management procedures; ii) Subscriber tracing procedures; iii) Event tracing procedures. The subscriber tracing management procedures are used to manage the status and the type of the tracing. The subscriber tracing activation procedure is used at location updating or data restoration when the trace mode of a subscriber is set active in the HLR or, as a stand alone procedure, when the subscriber is already registered and the trace mode becomes active in the HLR. The procedures to activate tracing in the VLR are shown in figures 20.2/1 and 20.2/3. The procedures to activate tracing in the SGSN are shown in figures 20.2/2 and 20.2/4. 1) Subscriber Tracing Activation 2) MAP_ACTIVATE_TRACE_MODE_req/ind 3) MAP_ACTIVATE_TRACE_MODE_rsp/cnf 4) Subscriber Tracing Activation Accepted FigureÊ20.2/1: Stand-alone subscriber tracing activation procedure for non-GPRS 1) Subscriber Tracing Activation 2) MAP_ACTIVATE_TRACE_MODE_req/ind 3) MAP_ACTIVATE_TRACE_MODE_rsp/cnf 4) Subscriber Tracing Activation Accepted FigureÊ20.2/2: Stand-alone subscriber tracing activation procedure for GPRS 1) MAP_UPDATE_LOCATION or MAP_RESTORE_DATA_req/ind 2) MAP_ACTIVATE_TRACE_MODE_req/ind 3) MAP_ACTIVATE_TRACE_MODE_rsp/cnf 4) MAP_UPDATE_LOCATION_rsp/cnf or MAP_RESTORE_DATA_rsp/cnf FigureÊ20.2/3: Subscriber tracing activation procedure at location updating or data restoration 1) MAP_UPDATE_GPRS_LOCATION_req/ind 2) MAP_ACTIVATE_TRACE_MODE_req/ind 3) MAP_ACTIVATE_TRACE_MODE_rsp/cnf 4) MAP_UPDATE_GPRS_LOCATION_rsp/cnf FigureÊ20.2/4: Subscriber tracing activation procedure at GPRS location updating The MAP_ACTIVATE_TRACE_MODE request includes the IMSI, trace reference, trace type and identity of the OMC. The subscriber tracing deactivation procedure is used when tracing of a subscriber in the VLR or in the SGSN is no longer required. The procedures are shown in figuresÊ20.2/5 and 20.2/6. 1) Subscriber Tracing Deactivation 2) MAP_DEACTIVATE_TRACE_MODE_req/ind 3) MAP_DEACTIVATE_TRACE_MODE_rsp/cnf 4) Subscriber Tracing Deactivation Accepted FigureÊ20.2/5: Subscriber tracing deactivation procedure for non-GPRS 1) Subscriber Tracing Deactivation 2) MAP_DEACTIVATE_TRACE_MODE_req/ind 3) MAP_DEACTIVATE_TRACE_MODE_rsp/cnf 4) Subscriber Tracing Deactivation Accepted FigureÊ20.2/6: Subscriber tracing deactivation procedure for GPRS The subscriber tracing procedures are used when the VLR detects any subscriber related activity for which the trace mode is activated, e.g. the VLR receives a MAP_PROCESS_ACCESS_REQUEST indication. The procedure is shown in figureÊ20.2/7. 1) MAP_PROCESS_ACCESS_REQUEST_req/ind 2) MAP_TRACE_SUBSCRIBER_ACTIVITY_req/ind 3) Subscriber tracing information FigureÊ20.2/7: Subscriber tracing procedure in the serving MSC 20.2.1 Subscriber tracing activation procedure 20.2.1.1 Procedures in the HLR A subscriber tracing activation request from the OMC starts the appropriate process in the HLR: ATM_With_VLR_HLR if tracing is required in the MSC/VLR, ATM_With_SGSN_HLR if tracing is required in the SGSN. The process in the HLR to activate tracing in the VLR is shown in figureÊ20.2/8. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the Repeat attempt counter has reached its limit, the test ""Repeat Attempt"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options. The process in the HLR to activate tracing in the SGSN is shown in figureÊ20.2/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the Repeat attempt counter has reached its limit, the test ""Repeat Attempt"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options. 20.2.1.2 Procedure in the VLR The process in the VLR to activate tracing in a stand-alone dialogue is shown in figureÊ20.2/10. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. 20.2.1.3 Procedure in the SGSN The process in the SGSN to activate tracing in a stand-alone dialogue is shown in figureÊ20.2/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. 20.2.2 Subscriber tracing deactivation procedure 20.2.2.1 Procedures in the HLR A subscriber tracing deactivation request from the OMC starts the appropriate process in the HLR: DTM_HLR_With_VLR if tracing is no longer required in the MSC/VLR, DTM_HLR_With_SGSN if tracing is no longer required in the SGSN. The process in the HLR to deactivate tracing in the VLR is shown in figureÊ20.2/12. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the Repeat attempt counter has reached its limit, the test ""Repeat Attempt"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options. The process in the HLR to deactivate tracing in the SGSN is shown in figureÊ20.2/13. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the Repeat attempt counter has reached its limit, the test ""Repeat Attempt"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The number of repeat attempts and the interval between successive repeat attempts are operator options. 20.2.2.2 Procedure in the VLR The process in the VLR to deactivate tracing is shown in figureÊ20.2/14. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. 20.2.2.3 Procedure in the SGSN The process in the SGSN to deactivate tracing is shown in figureÊ20.2/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. FigureÊ20.2/8 (sheet 1 of 2): Process ATM_With_VLR_HLR FigureÊ20.2/8 (sheet 2 of 2): Process ATM_With_VLR_HLR FigureÊ20.2/9 (sheet 1 of 2): Process ATM_with_SGSN_HLR FigureÊ20.2/9 (sheet 2 of 2): Process ATM_with_SGSN_HLR FigureÊ20.2/10: Process ATM_Standalone_VLR FigureÊ20.2/11: Process ATM_Standalone_SGSN FigureÊ20.2/12 (sheet 1 of 2): Process DTM_with_VLR_HLR FigureÊ20.2/12 (sheet 2 of 2): Process DTM_with_VLR_HLR FigureÊ20.2/13 (sheet 1 of 2): Process DTM_with_SGSN_HLR FigureÊ20.2/13 (sheet 2 of 2): Process DTM_with_SGSN_HLR FigureÊ20.2/14: Process DTM_Standalone_VLR FigureÊ20.2/15: Process DTM_Standalone_SGSN 20.3 Subscriber data management procedures for HLR Two types of subscriber data management procedures exist: 1) Subscriber Deletion; 2) Subscriber Data Modification. The subscriber deletion and subscriber data modification procedures are initiated by the OMC (see figures 20.3/1 , 20.3/2, 20.3/3 and 20.3/4). 1) Delete Subscriber 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf 4) Subscriber Deleted FigureÊ20.3/1: Subscriber deletion procedure for non-GPRS In the subscriber deletion procedure for a non-GPRS subscriber the subscriber data are removed from the VLR and the HLR. The HLR uses the MAP_CANCEL_LOCATION service. 1) Delete GPRS Subscriber 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf 4) GPRS Subscriber Deleted FigureÊ20.3/2: Subscriber deletion procedure for GPRS In the subscriber deletion procedure for a GPRS subscriber the subscriber data are removed from the SGSN and the HLR. The HLR uses the MAP_CANCEL_LOCATION service. 1) Modify Subscriber Data 2) MAP_CANCEL_LOCATION_req/ind, MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf, MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) Subscriber Data Modified FigureÊ20.3/3: Subscriber data modification procedure for non-GPRS 1) Modify GPRS Subscriber Data 2) MAP_CANCEL_LOCATION_req/ind, MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_CANCEL_LOCATION_rsp/cnf, MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) GPRS Subscriber Data Modified FigureÊ20.3/4: Subscriber data modification procedure for GPRS In the subscriber data modification procedure the subscriber data are modified in the HLR and when necessary also in the VLR or in the SGSN. The HLR initiates one of the MAP_INSERT_SUBSCRIBER_DATA, MAP_DELETE_SUBSCRIBER_DATA or MAP_CANCEL_LOCATION services depending on the modified data. 20.3.1 Subscriber deletion procedure 20.3.1.1 Procedure in the HLR The subscriber deletion process in the HLR is shown in figureÊ20.3/5. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows: Cancel_GPRS_Location_Child_HLR see clauseÊ19.1.2.2; Cancel_Location_Child_HLR see clauseÊ19.1.2.2. 20.3.1.2 Procedure in the VLR The subscriber deletion procedure in the VLR is described in clauseÊ19.1.2.3 of the present document. 20.3.1.3 Procedure in the SGSN The subscriber deletion procedure in the SGSN is described in clauseÊ19.1. 2.4 of the present document. 20.3.2 Subscriber data modification procedure 20.3.2.1 Procedure in the HLR The OMC can modify the subscriber data in several different ways. The modifications can be categorised in the following groups: 1) data shall be modified in the HLR; no effect in the VLR; 2) data shall be modified in both the HLR and the VLR; 3) withdrawal of a basic service or a supplementary service requiring change to VLR data; 4) modification affects the roaming permission for the subscriber and the subscriber record shall be removed from the VLR data base; 5) withdrawal of non-GPRS Subscription caused by a change of Network Access Mode; 6) data shall be modified in the HLR; no effect in the SGSN; 7) data shall be modified in both the HLR and the SGSN; 8) withdrawal of GPRS subscription data or a basic service or a supplementary service requiring change to SGSN data; 9) modification affects the roaming permission for the subscriber and the subscriber record shall be removed from the SGSN data base; 10) withdrawal of GPRS Subscription caused by a change of Network Access Mode; 11) authentication algorithm or authentication key of the subscriber is modified. In cases 2 and 7 the HLR uses the MAP_INSERT_SUBSCRIBER_DATA service. In cases 3 and 8 the HLR uses the MAP_DELETE_SUBSCRIBER_DATA service. In cases 4, 5, 9, 10 and 11 the HLR uses the MAP_CANCEL_LOCATION service. If the deletion of subscriber data fails, the HLR may repeat the request; the number of repeat attempts and the time in between are HLR operator options, depending on the error returned by the VLR or the SGSN. The subscriber data modification process in the HLR is shown in figure 20.3/6. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows: Insert_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.3; Cancel_Location_Child_HLR see clauseÊ19.1.2.2; Insert_GPRS_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.4; Cancel_GPRS_Location_Child_HLR see clauseÊ19.1.2.2. The macro Delete_Subscriber_Data_HLR is shown in figure 20.3/7. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The macro Delete_GPRS_Subscriber_Data_HLR is shown in figure 20.3/8. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 20.3.2.2 Procedures in the VLR The process in the VLR to update subscriber data in a stand-alone dialogue is shown in figure 20.3/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clauseÊ25.2.1; Insert_Subs_Data_VLR see clauseÊ25.7.1. The process in the VLR to delete subscriber data is shown in figure 20.3/10. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. 20.3.2.3 Procedures in the SGSN The process in the SGSN to update subscriber data in a stand-alone dialogue is shown in figure 20.3/11. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clauseÊ25.2.1; Insert_Subs_Data_SGSN see clauseÊ25.7.2. The process in the SGSN to delete subscriber data is shown in figure 20.3/12. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. FigureÊ20.3/5: Process Delete_Subscriber_HLR FigureÊ20.3/6 (sheet 1 of 2): Process Modify_Data_HLR FigureÊ20.3/6 (sheet 2 of 2): Process Modify_Data_HLR FigureÊ20.3/7: Macro Delete_Subscriber_Data_HLR FigureÊ20.3/8: Macro Delete_GPRS_Subscriber_Data_HLR FigureÊ20.3/9 (sheet 1 of 2): Process Ins_Subs_Data_Stand_Alone_VLR FigureÊ20.3/9 (sheet 2 of 2): Process Ins_Subs_Data_Stand_Alone_VLR FigureÊ20.3/10: Process Delete_Subs_Data_VLR FigureÊ20.3/11 (sheet 1 of 2): Process Ins_Subs_Data_Stand_Alone_SGSN FigureÊ20.3/11 (sheet 2 of 2): Process Ins_Subs_Data_Stand_Alone_SGSN FigureÊ20.3/12: Process Delete_Subs_Data_SGSN 20.3A Subscriber Data Management procedures for CSS Two types of subscriber data management procedures exist: 1) Subscriber Deletion; 2) Subscriber Data Modification. The subscriber deletion and subscriber data modification procedures are initiated by the OMC (see figures 20.3A/1, 20.3A/2, 20.3A/3 and 20.3A/4). 1) Delete Subscriber 2) MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) Subscriber Deleted Figure 20.3A/1: Subscriber deletion procedure for non-GPRS In the subscriber deletion procedure for a non-GPRS subscriber the CSG subscription data for the subscriber in the VPLMN are removed from the VLR and the CSS. The CSS uses the MAP_DELETE_SUBSCRIBER_DATA service."
"1) Delete GPRS Subscriber 2) MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) GPRS Subscriber Deleted Figure 20.3A/2: Subscriber deletion procedure for GPRS In the subscriber deletion procedure for a GPRS subscriber the CSG subscription data for the GPRS subscriber in the VPLMN are removed from the SGSN and the CSS. The CSS uses the MAP_DELETE_SUBSCRIBER_DATA service. 1) Modify Subscriber Data 2) MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) Subscriber Data Modified Figure 20.3A/3: Subscriber data modification procedure for non-GPRS 1) Modify GPRS Subscriber Data 2) MAP_INSERT_SUBSCRIBER_DATA_req/ind or MAP_DELETE_SUBSCRIBER_DATA_req/ind 3) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf or MAP_DELETE_SUBSCRIBER_DATA_rsp/cnf 4) GPRS Subscriber Data Modified Figure 20.3A/4: Subscriber data modification procedure for GPRS In the subscriber data modification procedure the CSG subscription data in the VPLMN for the subscriber data are modified in the CSS and when necessary also in the VLR or in the SGSN. The CSS initiates one of the MAP_INSERT_SUBSCRIBER_DATA or MAP_DELETE_SUBSCRIBER_DATA services depending on the modified data. 20.3A.1 Subscriber deletion procedure 20.3A.1.1 Procedure in the CSS The process in the CSS to delete subscriber is shown in figure 20.3A/5. In this case the CSS uses the MAP_DELETE_SUBSCRIBER_DATA service. 20.3A.1.2 Procedure in the VLR The process in the VLR for the CSG subscriber deletion procedure is shown in figure 20.3A/9. 20.3A.1.3 Procedure in the SGSN The process in the SGSN for the CSG subscriber deletion procedure is shown in figure 20.3A/11. 20.3A.2 Subscriber data modification procedure 20.3A.2.1 Procedure in the CSS The OMC can modify the CSG subscriber data in several different ways. The modifications can be categorised in the following groups: 1) CSG subsctiption data shall be modified in the CSS; no effect in the VLR; 2) CSG subsctiption data shall be modified in both the CSS and the VLR; 3) withdrawal of CSG subscription data requiring change to VLR data. 4) CSG subsctiption data shall be modified in the CSS; no effect in the SGSN; 5) CSG subsctiption data shall be modified in both the CSS and the SGSN; 6) withdrawal of CSG subscription data requiring change to SGSN data. In cases 2 and 5 the CSS uses the MAP_INSERT_SUBSCRIBER_DATA service. In cases 3 and 6 the CSS uses the MAP_DELETE_SUBSCRIBER_DATA service. If the deletion of CSG subscriber data fails, the CSS may repeat the request; the number of repeat attempts and the time in between are CSS operator options, depending on the error returned by the VLR or the SGSN. The CSS removes the routeting information after the completion of CSG subscriber data deletion procedure. The CSG subscriber data modification process in the CSS is shown in figure 20.3A/6. The MAP process invokes processes not defined in this clause; the definitions of these processes can be found as follows: Insert_VCSG_Subs_Data_Stand_Alone_CSS see clause 25.7.8; The macro Delete_VCSG_Subs_Data_CSS is shown in figure 20.3A/7. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. 20.3A.2.2 Procedures in the VLR The process in the VLR to update CSG subscription data in the VPLMN for the subscriber in a stand-alone dialogue is shown in figure 20.3A/8. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clause 25.2.1; Insert_Subs_Data_VLR see clause 25.7.1. The process in the VLR to delete CSG subscriber data is shown in figure 20.3A/9. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. 20.3A.2.3 Procedures in the SGSN The process in the SGSN to update CSG subscription data in the VPLMN for the GPRS subscriber in a stand-alone dialogue is shown in figure 20.3A/10. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clause 25.2.1; Insert_Subs_Data_SGSN see clause 25.7.2. The process in the SGSN to delete subscriber data is shown in figure 20.3A/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. Figure 20.3A/5: Process Delete_Subscriber_CSS Figure 20.3A/6 (sheet 1 of 2): Process Modify_Data_CSS Figure 20.3A/6 (sheet 2 of 2): Process Modify_Data_CSS Figure 20.3A/7: Macro Delete_VCSG_Subs_Data_CSS Figure 20.3A/8 (sheet 1 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_VLR Figure 20.3A/8 (sheet 2 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_VLR Figure 20.3A/9: Process Delete_VCSG_Subs_Data_VLR Figure 20.3A/10 (sheet 1 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_SGSN Figure 20.3A/10 (sheet 2 of 2): Process Ins_VCSG_Subs_Data_Stand_Alone_SGSN Figure 20.3A/11: Process Delete_VCSG_Subs_Data_SGSN 20.4 Subscriber Identity procedure In the subscriber identity procedure the IMSI of the subscriber is retrieved from the HLR. The procedure is shown in figureÊ20.4/1. 1) Identity request 2) MAP_SEND_IMSI_req/ind 3) MAP_SEND_IMSI_rsp/cnf 4) Identity confirm FigureÊ20.4/1: The subscriber identity procedure 20.4.1 Procedure in the VLR The subscriber identity process in the VLR is shown in figureÊ20.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 20.4.2 Procedure in the HLR The subscriber identity process in the HLR is shown in figureÊ20.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. FigureÊ20.4/2: Process Send_IMSI_VLR FigureÊ20.4/3: Process Send_IMSI_HLR 21 Call handling procedures 21.1 General The MAP call handling procedures are used: - to retrieve routeing information to handle a mobile terminating call; - to transfer control of a call back to the GMSC if the call is to be forwarded; - to retrieve and transfer information between anchor MSC and relay MSC for inter MSC group calls / broadcast calls; - to handle the reporting of MS status for call completion services; - to handle the notification of remote user free for CCBS; - to handle the alerting and termination of ongoing call activities for a specific subscriber; - to handle early release of no longer needed resources; - to relay a mobile terminating call from the old to the new MSC during the Mobile Terminating Roaming Forwarding procedure. The procedures to handle a mobile originating call and a mobile terminating call after the call has arrived at the destination MSC do not require any signalling over a MAP interface. These procedures are specified in 3GPP TS 23.018Ê[97]. The stage 2 specification for the retrieval of routeing information to handle a mobile terminating call is in 3GPP TS 23.018Ê[97]; modifications to this procedure for CAMEL are specified in 3GPP TS 23.078 [98], for optimal routeing of a basic mobile-to-mobile call in 3GPP TS 23.079 [99] and for CCBS in 3GPP TS 23.093 [107]. The interworking between the MAP signalling procedures and the call handling procedures for each entity (GMSC, HLR and VLR) is shown by the transfer of signals between these procedures. The stage 2 specification for the transfer of control of a call back to the GMSC if the call is to be forwarded is in 3GPP TS 23.079 [99]. The interworking between the MAP signalling procedures and the call handling procedures for each entity (VMSC and GMSC) is shown by the transfer of signals between these procedures. The stage 2 specifications for inter MSC group calls / broadcast calls are in 3GPP TS 43.068 [100] and 3GPP TS 43.069 [101]. The interworking between the MAP signalling procedures and the group call /broadcast call procedures for each entity (Anchor MSC and Relay MSC) is shown by the transfer of signals between these procedures. The interworking between the call handling procedures and signalling protocols other than MAP are shown in 3GPP TS 23.018, 3GPP TS 23.078 and 3GPP TS 23.079 [99]. The stage 2 specification for the handling of reporting of MS status for call completion services and notification of remote user free for CCBS is in 3GPP TS 23.093 [107]. The stage 2 specification for the Mobile Terminating Roaming Forwarding procedure is in 3GPP TS 23.018Ê[97] and 3GPP TS 23.012 [23]. 21.2 Retrieval of routing information 21.2.1 General The message flows for successful retrieval of routeing information for a mobile terminating call are shown in figureÊ21.2/1 (mobile terminating call which has not been optimally routed) and 21.2/2 (mobile-to-mobile call which has been optimally routed). The message flow for successful retrieval of routeing information for a gsmSCF initiated call is shown in figure 21.2/3. The message flow for a successful Mobile Terminating Roaming Forwarding procedure is shown in figure 21.2/4. 1) I_IAM (Note 1) 2) MAP_SEND_ROUTING_INFORMATION_req/ind (Note 2) 3) MAP_PROVIDE_SUBSCRIBER_INFO_req/ind (Note 3, Note 4) 4) MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf (Note 4) 5) MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 4) 6) MAP_SEND_ROUTING_INFORMATION_req/ind (Note 4) 7) MAP_PROVIDE_ROAMING_NUMBER_req/ind 8) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf 9) MAP_SEND_ROUTING_INFORMATION_rsp/cnf 10) I_IAM (Note 1) 11) MAP_RESTORE_DATA_req/ind (Note 4) 12) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 4) 13) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 4) 12) MAP_RESTORE_DATA_rsp/cnf (Note 4) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations and ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: This service may also be used by an ISDN exchange for obtaining routing information from the HLR. NOTE 3: As a network operator option, the HLR sends MAP_PROVIDE_SUBSCRIBER_INFORMATION to the VLR. For further details on the CAMEL procedures refer to 3GPP TS 23.078 [98]. NOTE 4: Services printed in italics are optional. FigureÊ21.2/1: Message flow for retrieval of routeing information (non-optimally routed call) 1) I_IAM (Note 1) 2) MAP_SEND_ROUTING_INFORMATION_req/ind 3) MAP_PROVIDE_SUBSCRIBER_INFO_req/ind (Note 2) 4) MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf (Note 2) 5) MAP_PROVIDE_ROAMING_NUMBER_req/ind (Note 2) 6) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf (Note 2) 7) MAP_SEND_ROUTING_INFORMATION_rsp/cnf 8) I_IAM (Note 1) 9) MAP_RESTORE_DATA_req/ind (Note 3) 10) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 11) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) 12) MAP_RESTORE_DATA_rsp/cnf (Note 3) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: For Optimal Routeing phase 1, only one of the information flows for Provide Subscriber Info and Provide Roaming Number is used. NOTE 3: Services printed in italics are optional. FigureÊ21.2/2: Message flow for retrieval of routeing information (optimally routed call) 1) MAP_SEND_ROUTING_INFORMATION_req/ind 2) MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 1) 3) MAP_SEND_ROUTING_INFORMATION_req/ind (Note 1) 4) MAP_PROVIDE_ROAMING_NUMBER_req/ind 5) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf 6) MAP_SEND_ROUTING_INFORMATION_rsp/cnf 7) MAP_RESTORE_DATA_req/ind (Note 1) 8) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 1) 9) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 1) 10) MAP_RESTORE_DATA_rsp/cnf (Note 1) NOTE 1: Services printed in italics are optional. FigureÊ21.2/3: Message flow for retrieval of routeing information for a gsmSCF initiated call The following MAP services are used to retrieve routing information: MAP_SEND_ROUTING_INFORMATION see clauseÊ10.1; MAP_PROVIDE_ROAMING_NUMBER see clauseÊ10.2; MAP_PROVIDE_SUBSCRIBER_INFO see clauseÊ8.11.2; MAP_RESTORE_DATA see clauseÊ8.10.3. 1) I_IAM 2) MAP_CANCEL_LOCATION_req/ind 3) MAP_PROVIDE_ROAMING_NUMBER_req/ind 4) MAP_ PROVIDE_ROAMING_NUMBER_rsp/cnf 5) I_IAM FigureÊ21.2/4: Message flow for Mobile Terminating Roaming Forwarding The following MAP services are used for the Mobile Terminating Roaming Forwarding procedure: MAP_PROVIDE_ ROAMING_NUMBER see clauseÊ10.2; 21.2.2 Procedure in the GMSC The MAP process in the GMSC to retrieve routeing information for a mobile terminating call is shown in figure 21.2/6. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 1: if the MAP_SEND_ROUTING_INFORMATION request included the OR Interrogation parameter, the test ""OR interrogation?"" takes the ""Yes"" exit; otherwise the test takes the ""No"" exit. 21.2.9 Process in the gsmSCF For the purposes of retrieving routeing information from the HLR, the gsmSCF takes the role of the GMSC and follows the process specified in clause 21.2.2. 21.2.4 Procedure in the HLR The MAP process in the HLR to retrieve routeing information for a mobile terminating call is shown in figure 21.2/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 3: if the MAP_PROVIDE_ROAMING_NUMBER request included the OR Interrogation parameter, the test ""OR interrogation?"" takes the ""Yes"" exit; otherwise the test takes the ""No"" exit. 21.2.5 Procedure in the VLR to provide a roaming number The MAP process in the VLR to provide a roaming number for a mobile terminating call is shown in figure 21.2/8. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; 21.2.6 Procedure in the VLR to restore subscriber data The MAP process in the HLR to restore subscriber data is shown in figure 21.2/9. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2; Insert_Subs_Data_VLR see clauseÊ25.7.1; Activate_Tracing_VLR see clauseÊ25.9.4. 21.2.7 Procedure in the VLR to provide subscriber information The MAP process in the VLR to provide subscriber information for a mobile terminating call subject to CAMEL invocation is shown in figure 21.2/9. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; 21.2.8 Procedure in the old VLR to request a Roaming Number (MTRF) The MAP process in the old VLR for Mobile Terminating Roaming Forwarding is shown in figure 21.2/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2 Check_Confirmation see clause 25.2.2 FigureÊ21.2/6 (sheet 1 of 2): Process SRI_GMSC FigureÊ21.2/6 (sheet 2 of 2): Process SRI_GMSC FigureÊ21.2/7 (sheet 1 of 3): Process SRI_HLR FigureÊ21.2/7 (sheet 2 of 3): Process SRI_HLR FigureÊ21.2/7 (sheet 3 of 3): Process SRI_HLR FigureÊ21.2/8: Process PRN_VLR FigureÊ21.2/9: Process Restore_Data_VLR FigureÊ21.2/10: Process PSI_VLR FigureÊ21.2/11: Process PRN_Old_VLR 21.3 Transfer of call handling 21.3.1 General The message flow for successful transfer of call handling to forward a call is shown in figure 21.3/1. 1) MAP_RESUME_CALL_HANDLING_req/ind 2) MAP_SEND_ROUTING_INFORMATION_req/ind (Note 2) 3) MAP_SEND_ROUTING_INFORMATION_rsp/cnf (Note 2) 4) MAP_RESUME_CALL_HANDLING_rsp/cnf 5) I_REL (Note 1) 6) I_IAM (Note 1) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: Services printed in italics are optional. FigureÊ21.3/1: Message flow for transfer of call handling If the HLR indicated in the response to the original request for routeing information that forwarding interrogation is required, the GMSC executes the Send Routeing Information procedure with the HLR to obtain forwarding information; otherwise the GMSC uses the forwarding data which were sent in the MAP_RESUME_CALL_HANDLING req/ind. 21.3.2 Process in the VMSC The MAP process in the VMSC to retrieve routeing information for a mobile terminating call is shown in figure 21.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. If the capacity of a message signal unit in the lower layers of the protocol is enough to carry all the information which has to be sent to the GMSC, the test ""Segmentation needed?"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. 21.3.3 Process in the GMSC The MAP process in the GMSC to handle a request for the GMSC to resume call handling is shown in figure 21.3/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; If the parameter All Information Sent was present in the MAP_RESUME_CALL_HANDLING indication, the test ""All Information Sent"" takes the ""Yes"" exit; otherwise the test takes the ""No"" exit. FigureÊ21.3/2: Process RCH_VMSC FigureÊ21.3/3: Process RCH_GMSC 21.4 Inter MSC Group Call Procedures 21.4.1 General The message flow for successful inter MSC group call / broadcast call set-up is shown in figure 21.4/1. 1) I_IAM (Note 1) 2) MAP_PREPARE_GROUP_CALL_req/ind 3) MAP_PREPARE_GROUP_CALL_rsp/cnf 4) I_IAM (Note 1) 5) MAP_SEND_GROUP_CALL_END_SIGNAL_req/ind 6) I_ACM (Note 1) 7) I_ACM (Note 1) 8) MAP_FORWARD_GROUP_CALL_SIGNALLING_req/ind (Note 2) 9) MAP_PROCESS_GROUP_CALL_SIGNALLING_req/ind (Note 2) 10) MAP_SEND_GROUP_CALL_END_SIGNAL_rsp/cnf 11) I_REL (Note 3) 12) I_REL (Note 3) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations and ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: The MAP_FORWARD_GROUP_CALL_SIGNALLING and MAP_PROCESS_GROUP_CALL_SIGNALLING services are not applicable for voice broadcast calls. NOTE 3: The call can be released from the PSTN/ISDN or the Relay MSC FigureÊ21.4/1: Message flow for inter MSC group call / broadcast call 21.4.2 Process in the Anchor MSC The MAP process in the Anchor MSC to retrieve and transfer information from / to the Relay MSC for VBS and VGCS calls is shown in figure 21.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2. 21.4.3 Process in the Relay MSC The MAP process in the Relay MSC to receive and transfer information from / to the Anchor MSC for VBS and VGCS calls is shown in figure 21.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1. FigureÊ21.4/2 (sheet 1 of 2): Process ASCI_Anchor_MSC FigureÊ21.4/2 (sheet 2 of 2): Process ASCI_Anchor_MSC FigureÊ21.4/3 (sheet 1 of 2): Process ASCI_Relay_MSC FigureÊ21.4/3 (sheet 2 of 2): Process ASCI_Relay_MSC 21.4A Inter MSC Group Call Info Retrieval 21.4A.1 General The message flow for successful inter MSC group call info retrieval is shown in figure 21.4A/1. FigureÊ21.4A/1: Message flow for inter MSC group call info retrieval 21.4A.2 Process in the MSC The MAP process in the MSC to retrieve and group call information is shown in figure 21.4A/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Receive_Open_Ind see clauseÊ25.1.2; FigureÊ21.4A/2 (sheet 1 of 2): Process Group_Call_Info_Retrieval_MSC FigureÊ21.4A/2 (sheet 2 of 2): Process Group_Call_Info_Retrieval_MSC 21.5 Void 21.6 CCBS: monitoring and reporting the status of the subscriber 21.6.1 Reporting co-ordinator process in the VLR The MAP co-ordinating process in the VLR to handle a dialogue opened with the reporting application context is shown in figure 21.6/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 21.6.2 Setting the reporting state Ð stand-alone The message flow for setting the reporting state in a stand-alone dialogue is shown in figure 21.6/1. 1) MAP_SET_REPORTING_STATE_req/ind 2) MAP_SET_REPORTING_STATE_rsp/cnf Figure 21.6/1: Message flow for setting the reporting state Ð stand-alone dialogue 21.6.2.1 Process in the HLR The MAP process in the HLR to set the reporting state in the VLR in a stand-alone dialogue is shown in figureÊ21.6/7. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The result of a request to stop reporting is not reported to the CCBS application in the HLR. 21.6.2.2 Process in the VLR The MAP process in the VLR to set the reporting state is shown in figure 21.6/8. The macro Set_Reporting_State_VLR is shown in figure 21.6/9. 21.6.3 Status Reporting The message flows for reporting the status of a subscriber are shown in figures 21.6/2 and 21.6/3. 1) MAP_STATUS_REPORT_req/ind 2) MAP_STATUS_REPORT_rsp/cnf Figure 21.6/2: Message flow for status reporting, when monitoring continues in the VLR 1) MAP_STATUS_REPORT_req/ind 2) MAP_STATUS_REPORT_rsp/cnf 3) MAP_SET_REPORTING_STATE_req/ind 4) MAP_SET_REPORTING_STATE_rsp/cnf Figure 21.6/3: Message flow for status reporting, when monitoring stops The MAP_SET_REPORTING_STATE request is used to stop monitoring in the VLR. If the HLR requires the VLR to continue monitoring, it closes the dialogue without sending a MAP_SET_REPORTING_STATE request. 21.6.3.1 Process in the VLR The MAP process in the VLR to send a status report to the HLR is shown in figure 21.6/10. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. This process can be used to report: - an event, such as the user becoming free, or - the result of a CCBS call attempt to the HLR 21.6.3.2 Process in the HLR The MAP process in the HLR to handle a status report is shown in figure 21.6/11. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; It is an implementation option whether to send the MAP_DELIMITER request before invoking the macro Set_Reporting_State_HLR. The macro Receive_Status_Report_HLR is shown in figure 21.6/12. The macro Set_Reporting_State_HLR is shown in figure 21.6/13. The macro invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. 21.6.4 CCBS: Remote User Free The message flows for handling remote user free are shown in figures 21.6/4 and 21.6/5. 1) MAP_REMOTE_USER_FREE_req/ind 2) MAP_REMOTE_USER_FREE_rsp/cnf Figure 21.6/4: Remote User Free: recall not accepted 1) MAP_REMOTE_USER_FREE_req/ind 2) MAP_REMOTE_USER_FREE_rsp/cnf 3) MAP_STATUS_REPORT_req/ind 4) MAP_STATUS_REPORT_rsp/cnf Figure 21.6/5: Remote User Free: recall accepted 21.6.4.1 Process in the HLR The MAP process in the HLR to handle Remote User Free is shown in figure 21.6/14. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 21.6.3.2 Process in the VLR The MAP process in the VLR to handle Remote User Free is shown in figure 21.6/15. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. FigureÊ21.6/6: Process Reporting_Coord_VLR FigureÊ21.6/7: Process Set_Reporting_State_Stand_Alone_HLR FigureÊ21.6/8: Process Set_Reporting_State_VLR FigureÊ21.6/9: Macro Receive_Set_Reporting_State_VLR FigureÊ21.6/10 (sheet 1 of 2): Process Send_Status_Report_VLR FigureÊ21.6/10 (sheet 2 of 2): Process Send_Status_Report_VLR FigureÊ21.6/11: Process Status Report_HLR FigureÊ21.6/12: Macro Receive_Status_Report_HLR FigureÊ21.6/13: Macro Set_Reporting_State_HLR Figure 21.6/14: Process Remote_User_Free_HLR Figure 21.6/15 (sheet 1 of 2): Process Remote_User_Free_VLR Figure 21.6/15 (sheet 2 of 2): Process Remote_User_Free_VLR 21.7 Void 21.8 Void 21.9 Immediate Service Termination (IST) 21.9.1 IST Alert The Immediate Service Termination Alert procedure is used to keep track of the call activities performed by subscribers who are marked as being subject to IST monitoring and, possibly, to terminate the call activities for which the alert was sent, or all the call activities related to the subscriber for whom the alert was sent. The message flow for alerting is shown in figure 21.9/1; the MSC may be a Visited MSC or a Gateway MSC. 1) MAP_IST_ALERT_req/ind 2) MAP_IST_ALERT_rsp/cnf FigureÊ21.9/1: Message flow for IST Alert 21.9.1.1 Procedure in the MSC The MAP process in the MSC (Visited MSC or Gateway MSC) is shown in figure 21.9/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. 21.9.1.2 Procedure in the HLR The MAP process in the HLR is shown in figure 21.9/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1; 21.9.2 IST Command The Immediate Service Termination Command procedure is used to terminate the call activities related to a subscriber. The message flow for the IST Command procedure is shown in figure 21.9/2; the MSC may be a Visited MSC or a Gateway MSC. 1) MAP_IST_COMMAND_req/ind 2) MAP_IST_COMMAND_rsp/cnf FigureÊ21.9/2: Message flow for IST Command 21.9.2.1 Procedure in the HLR The MAP process in the HLR is shown in figure 21.9/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. 21.9.2.2 Procedure in the MSC The MAP process in the MSC is shown in figure 21.9.6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1. Figure 21.9/3: Process IST_Alert_MSC Figure 21.9/4: Process IST_Alert_HLR Figure 21.9/5: Process IST_Command_HLR Figure 21.9/6: Process IST_Command_MSC 21.10 Resource Management 21.10.1 General The message flow for successful release of resources is shown in figure 21.10/1. 1) I_IAM (Note 1) 2) MAP_SEND_ROUTING_INFORMATION_req/ind 3) MAP_PROVIDE_ROAMING_NUMBER_req/ind 4) I_REL (Note 1) 5) MAP_PROVIDE_ROAMING_NUMBER_rsp/cnf 6) MAP_SEND_ROUTING_INFORMATION_rsp/cnf 7) MAP_RELEASE_RESOURCES (Note 2) NOTE 1: TUP or ISUP may be used in signalling between MSCs, depending on the network type between the MSCs. For further details on the TUP and ISUP procedures refer to the following ITU-T Recommendations & ETSI specification: - Q.721 725 Telephone User Part (TUP); - ETS 300 356-1 Integrated Services Digital Network (ISDN); Signalling System No.7; ISDN User Part (ISUP) version 2 for the international interface; Part 1: Basic services. NOTE 2: Services printed in italics are optional. FigureÊ21.10/1: Message flow for early release of resources 21.3.2 Process in the GMSC The MAP process in the GMSC to release resources is shown in figure 21.10/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 21.3.3 Process in the VMSC The MAP process in the VMSC to handle a request for the GMSC to release resources is shown in figure 21.10/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; FigureÊ21.10/2: Process Release Resources_GMSC FigureÊ21.10/3: Process Release Resources_VMSC 22 Supplementary services procedures 22.1 Supplementary service co-ordinator processes 22.1.1 Supplementary service co-ordinator process for the MSC The co-ordinator process in the MSC to handle a CM connection request with CM service type Supplementary service activation is shown in figure 22.1/1. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Process_Access_Request_MSC see clauseÊ25.4.1. 22.1.2 Void 22.1.3 Functional supplementary service co-ordinator process for the HLR The MAP co-ordinator process in the HLR to handle a dialogue opened with the networkFunctionalSS application context is shown in figure 22.1/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. 22.1.4 Call completion supplementary service co-ordinator process for the HLR The MAP co-ordinator process in the HLR to handle a dialogue opened with the callCompletion application context is shown in figure 22.1/4. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ22.1/1 (sheet 1 of 2): Process SS_Coordinator_MSC FigureÊ22.1/1 (sheet 2 of 2): Process SS_Coordinator_MSC FigureÊ22.1/2 void FigureÊ22.1/3: Process SS_Coordinator_HLR FigureÊ22.1/4: Process CC_Coordinator_HLR 22.2 Registration procedure 22.2.1 General The registration procedure is used to register data related to a supplementary service in the HLR. The registration procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below. The registration procedure is shown in figureÊ22.2.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_INSERT_SUBSCRIBER_DATA (see clauses 8 and 25); The following service is certainly used: MAP_REGISTER_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_REGISTER_SS (Note 1) 4) MAP_REGISTER_SS_req/ind 5) MAP_REGISTER_SS_req/ind 6) MAP_REGISTER_SS_rsp/cnf 7) MAP_REGISTER_SS_rsp/cnf 8) A_REGISTER_SS ack (Note 1) 9) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 10) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: Services printed in italics are optional. FigureÊ22.2.1/1: Message flow for supplementary service registration 22.2.2 Procedure in the MSC The A_REGISTER_SS service indication received by the MAP process in the MSC contains the SS-Code and any parameters that are related to the supplementary service. The MAP user transfers the received information to the VLR in the MAP_REGISTER_SS request without checking the contents of the service indication. Rules for the mapping are described in 3GPP TS 29.011 [59]. The information in the MAP_REGISTER_SS confirm from the VLR is relayed to the MS in the A_REGISTER_SS response message as described in 3GPP TSÊ24.08x, 3GPP TSÊ24.08x and 3GPP TSÊ29.011. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The registration process in the MSC is shown in figureÊ22.2.2/1. 22.2.3 Procedure in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The MAP process in the VLR transfers the information received in the MAP_REGISTER_SS indication to the HLR in the MAP_REGISTER_SS request without checking the contents. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference. If the MAP_REGISTER_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_REGISTER_SS response. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The registration process in the VLR is shown in figureÊ22.2.3/1. 22.2.4 Procedure in the HLR The MAP process invokes a macro and a process not defined in this clause; the definitions of the macro and process can be found as follows: Check_Indication see clause 25.2.1; Insert_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.3. The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]): The registration process in the HLR is shown in figureÊ22.2.4/1. FigureÊ22.2.2/1: Process Register_SS_MSC FigureÊ22.2.3/1 (sheet 1 of 2): Process Register_SS_VLR FigureÊ22.2.3/1 (sheet 2 of 2): Process Register_SS_VLR FigureÊ22.2.4/1: Process Register_SS_HLR 22.3 Erasure procedure 22.3.1 General The erasure procedure is used to erase data related to a supplementary service in the HLR. The erasure procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below. The erasure procedure is shown in figureÊ22.3.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_INSERT_SUBSCRIBER_DATA (see clauses 8 and 25); The following service is certainly used: MAP_ERASE_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_ERASE_SS (Note 1) 4) MAP_ERASE_SS_req/ind 5) MAP_ERASE_SS_req/ind 6) MAP_ERASE_SS_rsp/cnf 7) MAP_ERASE_SS_rsp/cnf 8) A_ERASE_SS ack (Note 1) 9) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 10) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: Services printed in italics are optional. FigureÊ22.3.1/1: Message flow for supplementary service erasure 22.3.2 Procedure in the MSC The MSC procedure for erasure is identical to that specified for registration in clauseÊ22.2.2. The text and diagrams in clauseÊ22.2.2 apply with all references to registration changed to erasure. 22.3.3 Procedure in the VLR The VLR procedure for erasure is identical to that specified for registration in clauseÊ22.2.3. The text and diagrams in clauseÊ22.2.3 apply with all references to registration changed to erasure. 22.3.4 Procedure in the HLR The HLR procedure for erasure is identical to that specified for registration in clauseÊ22.2.4. The text and diagrams in clauseÊ22.2.4 apply with all references to registration changed to erasure. 22.4 Activation procedure 22.4.1 General The activation procedure is used to activate a supplementary service in the HLR. The activation procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below. The activation procedure is shown in figureÊ22.4.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_GET_PASSWORD (defined in clauseÊ11); MAP_INSERT_SUBSCRIBER_DATA (see clauses 8 and 25); The following service is certainly used: MAP_ACTIVATE_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_ACTIVATE_SS (Note 1) 4) MAP_ACTIVATE_SS_req/ind 5) MAP_ACTIVATE_SS_req/ind 6) MAP_GET_PASSWORD_req/ind (Note 3) 7) MAP_GET_PASSWORD_req/ind (Note 3) 8) A_GET_PASSWORD (Note 1, Note 3) 9) A_GET_PASSWORD ack (Note 1, Note 3) 10) MAP_GET_PASSWORD_rsp/cnf (Note 3) 11) MAP_GET_PASSWORD_rsp/cnf (Note 3) 12) MAP_ACTIVATE_SS_rsp/cnf 13) MAP_ACTIVATE_SS_rsp/cnf 14) A_ACTIVATE_SS ack (Note 1) 15) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 16) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 of this document. NOTE 3: Services printed in italics are optional. FigureÊ22.4.1/1: Message flow for supplementary service activation 22.4.2 Procedure in the MSC The A_ACTIVATE_SS service indication received by the MAP user in the MSC contains the SS-Code and any parameters related to the supplementary service. The MSC transfers the received information to the VLR in the MAP_ACTIVATE_SS request without checking the contents of the service indication. Rules for the mapping are described in 3GPP TS 29.011 [59]. The information in the MAP_ACTIVATE_SS confirm from the VLR is relayed to the MS in the A_ACTIVATE_SS response message, as described in TSÊ24.08x, 3GPP TSÊ24.08x and 3GPP TSÊ29.011. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The activation process in the MSC is shown in figureÊ22.4.2/1. 22.4.3 Procedure in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The MAP process in the VLR transfers the information received in the MAP_ACTIVATE_SS indication to the HLR in the MAP_ACTIVATE_SS request without checking the contents. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference. If the MAP_REGISTER_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_ACTIVATE_SS response. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The activation process in the VLR is shown in figureÊ22.4.3/1."
"22.4.4 Procedure in the HLR The MAP process invokes a macro and a process not defined in this clause; the definitions of the macro and process can be found as follows: Check_Indication see clause 25.2.1; Insert_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.3. The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]): The activation process in the HLR is shown in figureÊ22.4.4/1. FigureÊ22.4.2/1: Process Activate_SS_MSC FigureÊ22.4.3/1 (sheet 1 of 2): Process Activate_SS_VLR FigureÊ22.4.3/1 (sheet 2 of 2): Process Activate_SS_VLR FigureÊ22.4.4/1 (sheet 1 of 2): Process Activate_SS_HLR FigureÊ22.4.4/1 (sheet 2 of 2): Process Activate_SS_HLR 22.5 Deactivation procedure 22.5.1 General The deactivation procedure is used to deactivate a supplementary service in the HLR. The deactivation procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described in the clauses below. The deactivation procedure is shown in figureÊ22.5.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_GET_PASSWORD (defined in clauseÊ11); MAP_INSERT_SUBSCRIBER_DATA (see clauses 8 and 25); The following service is certainly used: MAP_DEACTIVATE_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_DEACTIVATE_SS (Note 1) 4) MAP_DEACTIVATE_SS_req/ind 5) MAP_DEACTIVATE_SS_req/ind 6) MAP_GET_PASSWORD_req/ind (Note 3) 7) MAP_GET_PASSWORD_req/ind (Note 3) 8) A_GET_PASSWORD (Note 1, Note 3) 9) A_GET_PASSWORD ack (Note 1, Note 3) 10) MAP_GET_PASSWORD_rsp/cnf (Note 3) 11) MAP_GET_PASSWORD_rsp/cnf (Note 3) 12) MAP_DEACTIVATE_SS_rsp/cnf 13) MAP_DEACTIVATE_SS_rsp/cnf 14) A_DEACTIVATE_SS ack (Note 1) 15) MAP_INSERT_SUBSCRIBER_DATA_req/ind (Note 3) 16) MAP_INSERT_SUBSCRIBER_DATA_rsp/cnf (Note 3) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: Services printed in italics are optional. FigureÊ22.5.1/1: Message flow for supplementary service deactivation 22.5.2 Procedure in the MSC The MSC procedure for deactivation is identical to that specified for activation in clauseÊ22.4.2. The text and diagrams in clauseÊ22.4.2 apply with all references to activation changed to deactivation. 22.5.3 Procedures in the VLR The VLR procedure for deactivation is identical to that specified for activation in clauseÊ22.4.3. The text and diagrams in clauseÊ22.4.3 apply with all references to activation changed to deactivation. 22.5.4 Procedures in the HLR The HLR procedure for deactivation is identical to that specified for activation in clauseÊ22.4.4. The text and diagrams in clauseÊ22.4.4 apply with all references to activation changed to deactivation. 22.6 Interrogation procedure 22.6.1 General The interrogation procedure is used to retrieve information related to a supplementary service from the VLR or the HLR. It is the VLR which decides whether an interrogation request should be forwarded to the HLR or not. Some non-supplementary service related services may be invoked as a result of the procedure, as described in the clauses below. The interrogation procedure is shown in figureÊ22.6.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); The following service is certainly used: MAP_INTERROGATE_SS (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_INTERROGATE_SS (Note 1) 4) MAP_INTERROGATE_SS_req/ind 5) MAP_INTERROGATE_SS_req/ind 6) MAP_INTERROGATE_SS_rsp/cnf 7) MAP_INTERROGATE_SS_rsp/cnf 8) A_INTERROGATE_SS ack (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines indicate the trigger provided by the signalling on the radio path, and the signalling triggered on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: Services printed in italics are optional. FigureÊ22.6.1/1: Message flow for supplementary service interrogation 22.6.2 Procedure in the MSC The MSC procedures for interrogation are identical to those specified for registration in clauseÊ22.2.2. The text and diagrams in clauseÊ22.2.2 apply with all references to registration changed to interrogation. 22.6.3 Procedures in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The interrogation is answered either by the VLR or by the HLR, depending on the service interrogated. 1) Interrogation to be handled by the VLR The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to a successful result, a partially successful result or an error being returned. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). 2) Interrogation to be handled by the HLR If the interrogation is to be handled by the HLR, the MAP process in the VLR transfers the information received in the MAP_INTERROGATE_SS indication to the HLR in the MAP_INTERROGATE_SS request without checking the contents of the service indication. The MAP_OPEN request includes the IMSI of the subscriber as the destination reference and the VLR number as the originating reference. If the MAP_INTERROGATE_SS confirm is properly formed and contains a result or a user error, the MAP process in the VLR shall transfer the information contained in this primitive to the MSC in the MAP_INTERROGATE_SS response. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The Interrogation process in the VLR is shown in figureÊ22.6.3/1. 22.6.4 Procedure in the HLR The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. The HLR acts as follows: The interrogation is answered either by the VLR or by the HLR, depending on the service interrogated. 1) Interrogation to be handled by the VLR If the interrogation procedure should have been answered by the VLR, then the HLR assumes that the VLR does not support the interrogated supplementary service, and returns the SS Not Available error to the VLR. 2) Interrogation to be handled by HLR The supplementary service request shall be processed according to 3GPP TS 23.011 [22] and the 23.08x and 23.09x-series of technical specifications. This handling may lead to either a successful result or an error being returned. For call independent SS operations, each message shall contain only a single component. Messages which contain more than one component will be stopped at the air interface (as specified in 3GPP TS 29.011 [59]). The Interrogation process in the HLR is shown in figureÊ22.6.4/1. FigureÊ22.6.3/1 (sheet 1 of 2): Process Interrogate_SS_VLR FigureÊ22.6.3/1 (sheet 2 of 2): Process Interrogate_SS_VLR FigureÊ22.6.4/1: Process Interrogate_SS_HLR 22.7 Void FigureÊ22.7.2/1 void FigureÊ22.7.3/1 void 22.8 Password registration procedure 22.8.1 General The password registration procedure is used to register a password in the HLR. The password registration procedure is a fully transparent communication between the MS and the HLR, except that some services may be invoked as a result of the procedure, as described below. The password registration procedure is shown in figureÊ22.8.1/1. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); The following services are certainly used: MAP_REGISTER_PASSWORD (defined in clauseÊ11); MAP_GET_PASSWORD (defined in clauseÊ11). 1) A_CM_SERV_REQ (Note 1) 2) MAP_PROCESS_ACCESS_REQUEST (Note 2) 3) A_REGISTER_PASSWORD (Note 1) 4) MAP_REGISTER_PASSWORD_req/ind 5) MAP_REGISTER_PASSWORD_req/ind 6) MAP_GET_PASSWORD_req/ind (Note 3) 7) MAP_GET_PASSWORD_req/ind (Note 3) 8) A_GET_PASSWORD (Note 1, Note 3) 9) A_GET_PASSWORD ack (Note 1, Note 3) 10) MAP_GET_PASSWORD_rsp/cnf (Note 3) 11) MAP_GET_PASSWORD_rsp/cnf (Note 3) 12) MAP_GET_PASSWORD_req/ind (Note 3) 13) MAP_GET_PASSWORD_req/ind (Note 3) 14) A_GET_PASSWORD (Note 1, Note 3) 15) A_GET_PASSWORD ack (Note 1, Note 3) 16) MAP_GET_PASSWORD_rsp/cnf (Note 3) 17) MAP_GET_PASSWORD_rsp/cnf (Note 3) 18) MAP_GET_PASSWORD_req/ind (Note 3) 19) MAP_GET_PASSWORD_req/ind (Note 3) 20) A_GET_PASSWORD (Note 1, Note 3) 21) A_GET_PASSWORD ack (Note 1, Note 3) 22) MAP_GET_PASSWORD_rsp/cnf (Note 3) 23) MAP_GET_PASSWORD_rsp/cnf (Note 3) 24) MAP_REGISTER_PASSWORD_rsp/cnf 25) MAP_REGISTER_PASSWORD_rsp/cnf 26) A_REGISTER_PASSWORD (Note 1) NOTE 1: For details of the procedure on the radio path, see 3GPP TS 24.008 [35], 3GPP TS 24.010 [36], 3GPP TS 24.08x and 3GPP TS 24.09x. Services shown in dotted lines are triggers/ triggered signalling on the radio path. NOTE 2: For details of the Process Access Request procedure, refer to clauseÊ25.4 in the present document. NOTE 3: The use of each of the three MAP_GET_PASSWORD operations is described in clauseÊ22.8.4. FigureÊ22.8.1/1: Message flow for supplementary service password registration 22.8.2 Procedure in the MSC The password registration procedure in the MSC is identical to that for activation specified in clauseÊ22.4.2. All the text and diagrams in clauseÊ22.4.2 apply with all references to activation changed to password registration. 22.8.3 Procedure in the VLR The password registration procedure in the VLR is identical to that for activation specified in clauseÊ22.4.3. All the text and diagrams in clauseÊ22.4.3 apply with all references to activation changed to password registration. 22.8.4 Procedure in the HLR The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. The HLR shall process the MAP_REGISTER_PASSWORD indication as specified in 3GPP TS 23.011 [22]. During the handling of password registration, the password procedure is initiated (as specified in 3GPP TS 23.011 [22]) This involves the sending of MAP_GET_PASSWORD requests to the VLR. The password registration process in the HLR is shown in figureÊ22.8.4/1. FigureÊ22.8.4/1 (sheet 1 of 2): Process Register_PW_HLR FigureÊ22.8.4/1 (sheet 2 of 2): Process Register_PW_HLR 22.9 Mobile Initiated USSD procedure 22.9.1 General The procedure supports supplementary service signalling procedures which allow PLMN specific services to be introduced. The message flow for the procedure can be found in 3GPP TS 23.090 [34]. The following services may be used: MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauses 9 and 25); MAP_PROVIDE_IMSI (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_CHECK_IMEI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25); MAP_UNSTRUCTURED_SS_REQUEST (defined in clauseÊ11); MAP_UNSTRUCTURED_SS_NOTIFY (defined in clauseÊ11). The following service is certainly used: MAP_PROCESS_UNSTRUCTURED_SS_REQUEST (defined in clauseÊ11). 22.9.2 Procedure in the MSC The process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. The A_PROCESS_UNSTRUCTURED_SS_REQUEST from the MS contains information input by the user; the message may be fed to an application contained locally in the MSC or to the VLR. The rules for determining this are specified in 3GPP TS 23.090 [34]. 1) Message Destined for the VLR If the message is destined for the VLR then the MSC shall transfer the message to the VLR using the mapping specified in detail in 3GPP TS 29.011 [59]. 2) Message Destined for the Local Application If the message is destined for the local USSD application then the MSC shall transfer the information contained in the message to the application. The process in the MSC is shown in figureÊ22.9.2/1. 22.9.3 Procedure in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST from the MSC contains information input by the user; the message may be fed to an application contained locally in the VLR or to the HLR. The rules for determining this are specified in 3GPP TS 23.090 [34]. 1) Message Destined for the HLR If the message is destined for the HLR then the VLR shall transfer the message transparently to the HLR. 2) Message Destined for the Local Application If the message is destined for the local USSD application then the VLR shall transfer the information contained in the message to the application. The process in the VLR is shown in figure 22.9.3/1. 22.9.4 Procedure in the HLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The MAP_PROCESS_UNSTRUCTURED_SS_REQUEST from the VLR contains information input by the user. If the alphabet used for the message is understood then the message shall be fed to an application contained locally in the HLR or to the gsmSCF or to a secondary HLR where the USSD application is located. 1) Message Destined for the Local Application If the message is destined for the local USSD application then the HLR shall transfer the information contained in the message to the local application. 2) Message Destined for the gsmSCF or the secondary HLR If the message is destined for the gsmSCF or the secondary HLR then the primary HLR shall transfer the message transparently to the next node. The process in the primary HLR is shown in figureÊ22.9.4/1. 22.9.5 Procedures in the gsmSCF/secondary HLR The MAP process invokes a macro not defined in this clause; the definition of this macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. The process in the gsmSCF or secondary HLR is shown in figureÊ22.9.5/1. FigureÊ22.9.2/1 (sheet 1 of 3): Process MS_Init_USSD_MSC FigureÊ22.9.2/1 (sheet 2 of 3): Process MS_Init_USSD_MSC FigureÊ22.9.2/1 (sheet 3 of 3): Process MS_Init_USSD_MSC FigureÊ22.9.3/1 (sheet 1 of 4): Process MS_Init_USSD_VLR FigureÊ22.9.3/1 (sheet 2 of 4): Process MS_Init_USSD_VLR FigureÊ22.9.3/1 (sheet 3 of 4): Process_MS_Init_USSD_VLR FigureÊ22.9.3/1 (sheet 4 of 4): Process_MS_Init_USSD_VLR FigureÊ22.9.3/2 void FigureÊ22.9.4/1 (sheet 1 of 4): Process MS_Init_USSD_HLR FigureÊ22.9.4/1 (sheet 2 of 4): Process MS_Init_USSD_HLR FigureÊ22.9.4/1 (sheet 3 of 4): Process MS_Init_USSD_HLR FigureÊ22.9.4/1 (sheet 4 of 4): Process MS_Init_USSD_HLR Figure 22.9.5/1 (sheet 1 of 2): Process MS_Init_USSD_gsmSCF_Secondary_HLR Figure 22.9.5/1 (sheet 2 of 2): Process MS_Init_USSD_gsmSCF_Secondary_HLR 22.10 Network initiated USSD procedure 22.10.1 General The procedure supports supplementary service signalling procedures which allow PLMN specific services to be introduced. The message flow for the procedure can be found in 3GPP TS 23.090 [34]. The following services may be used: MAP_PAGE (see clauses 8 and 25); MAP_SEARCH_FOR_MOBILE_SUBSCRIBER (see clauses 8 and 25); MAP_PROCESS_ACCESS_REQUEST (see clauses 8 and 25); MAP_AUTHENTICATE (see clauses 8 and 25); MAP_SET_CIPHERING_MODE (see clauses 8 and 25); MAP_FORWARD_NEW_TMSI (see clauses 8 and 25); MAP_READY_FOR_SM (see clauses 12 and 25). At least one of the following services will certainly be used, and both may be used: MAP_UNSTRUCTURED_SS_REQUEST (defined in clauseÊ11); MAP_UNSTRUCTURED_SS_NOTIFY (defined in clauseÊ11). 22.10.2 Procedure in the MSC The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Page_MSC see clause 25.3.1; Search_For_MS_MSC see clause 25.3.2; Process_Access_Request_MSC see clause 25.4.1. The process in the MSC is shown in figureÊ22.10.2/1. 22.10.3 Procedure in the VLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Indication see clause 25.2.1; Check_Confirmation see clause 25.2.2. The process in the VLR is shown in figureÊ22.10.3/1. MSC Initiated USSD If a USSD application in the MSC wishes to use the network initiated USSD procedure, and a connection to the MS does not exist then the MSC opens a dialogue with the VLR. This dialogue leads to the VLR performing page or search using the macro Start_USSD_VLR. Macro Start_USSD_VLR The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Confirmation see clause 25.2.1; Process_Access_Request_VLR see clause 25.4.2. The macro is shown in figureÊ22.10.3/2. 22.10.4 Procedure in the HLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clause 25.1.1; Receive_Open_Cnf see clause 25.1.2; Check_Indication see clause 25.2.1; Check_Confirmation see clause 25.2.2. The process in the primary HLR is shown in figuresÊ22.10.4/1 and 22.10.4/2. 22.10.5 Procedure in the gsmSCF or secondary HLR The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. The procedure in the gsmSCF or secondary HLR is shown in figureÊ22.10.5/1. FigureÊ22.10.2/1 (sheet 1 of 4): Process NW_Init_USSD_MSC FigureÊ22.10.2/1 (sheet 2 of 4): Process NW_Init_USSD_MSC FigureÊ22.10.2/1 (sheet 3 of 4): Process NW_Init_USSD_MSC FigureÊ22.10.2/1 (sheet 4 of 4): Process NW_Init_USSD_MSC FigureÊ22.10.3/1 (sheet 1 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/1 (sheet 2 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/1 (sheet 3 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/1 (sheet 4 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/1 (sheet 5 of 5): Process NW_Init_USSD_VLR FigureÊ22.10.3/2 (sheet 1 of 2): Macro Start_USSD_VLR FigureÊ22.10.3/2 (sheet 2 of 2): Macro Start_USSD_VLR FigureÊ22.10.4/1 (sheet 1 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/1 (sheet 2 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/1 (sheet 3 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/1 (sheet 4 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/1 (sheet 5 of 5): Process NW_Init_USSD_HLR FigureÊ22.10.4/2: Macro Start_USSD_HLR FigureÊ22.10.5/1 (sheet 1 of 2): Process NW_Init_USSD_gsmSCF_secondary_HLR FigureÊ22.10.5/1 (sheet 2 of 2): Process NW_Init_USSD_gsmSCF_Secondary_HLR 22.11 Common macros for clauseÊ22 The following macros are used for the description of more than one of the supplementary service processes described in clauseÊ22. 22.11.1 SS Password handling macros Macro Get_Password_MSC This macro is used by the MSC to relay a request for password from the VLR to the MS, and to relay a response from the MS back to the VLR. The macro is shown in figureÊ22.11.1/1. Macro Get_Password_VLR This macro is used by the VLR to relay a request for password from the HLR to the MSC, and to relay a response from the MSC back to the HLR. The macro invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clause 25.2.1. The macro is shown in figureÊ22.11.1/2. 22.11.2 Void FigureÊ22.11.1/1: Macro Get_Password_MSC FigureÊ22.11.1/2: Macro Get_Password_VLR FigureÊ22.11.2/1 void FigureÊ22.11.2/2 void FigureÊ22.11.2/3 void FigureÊ22.11.2/4 void FigureÊ22.11.2/5 void 22.12 Supplementary Service Invocation Notification procedure 22.12.1 General The Supplementary Service Invocation Notification procedure is used to notify a gsmSCF about the invocation of a GSM Supplementary Service. The supplementary service invocation notification procedure is shown in figureÊ22.12.1/1. The following service is certainly used: MAP_SS_INVOCATION_NOTIFY (defined in clause 11). 1) MAP_SS_INVOCATION_NOTIFY_req/ind 2) MAP_SS_INVOCATION_NOTIFY_rsp/cnf FigureÊ22.12.1/1: Message flow for supplementary service invocation notification 22.12.2 Procedure in the MSC The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clause 25.1.2; Check_Confirmation see clause 25.2.2. The supplementary service invocation notification process in the MSC is shown in figure 22.12.2/1. 22.12.3 Procedure in the gsmSCF The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clause 25.1.1. The supplementary service invocation notification process in thegsmSCF is shown in figureÊ22.12.3/1. Figure 22.12.2/1: Process Notify_SS_Invocation_MSC Figure 22.12.3/1: Process Note_SS_Invocation_gsmSCF 22.13 Activation of a CCBS request 22.13.1 General The message flow to activate a CCBS request is shown in figure 22.13.1/1. The following service is certainly used: MAP_REGISTER_CC_ENTRY (defined in clause 11). 1) MAP_REGISTER_CC_ENTRY_req/ind 2) MAP_REGISTER_CC_ENTRY_rsp/cnf Figure 22.13.1/1: Message flow to activate a CCBS request 22.13.2 Procedure in the VLR The MAP process in the VLR to activate a CCBS request is shown in figure 22.13.2/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 22.13.3 Procedure in the HLR The MAP process in the HLR to activate a CCBS request is shown in figure 22.13.2/1. FigureÊ22.13.2/1: Process Register_CC_Entry_VLR FigureÊ22.13.3/1: Process Register_CC_Entry_HLR 22.14 Deactivation of a CCBS request 22.14.1 General The message flow to deactivate a CCBS request is shown in figure 22.14.1/1. The following service is certainly used: MAP_ERASE_CC_ENTRY (defined in clause 11). 1) MAP_ERASE_CC_ENTRY_req/ind 2) MAP_ERASE_CC_ENTRY_rsp/cnf Figure 22.14.1/1: Message flow to deactivate a CCBS request 22.14.2 Procedure in the VLR The MAP process in the VLR to deactivate a CCBS request is shown in figure 22.14.2/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 22.14.3 Procedure in the HLR The MAP process in the HLR to deactivate a CCBS request is shown in figure 22.14.2/1. FigureÊ22.14.2/1: Process Erase_CC_Entry_VLR FigureÊ22.14.3/1: Process Erase_CC_Entry_HLR 23 Short message service procedures 23.1 General The short message service procedures are used to control both mobile originated and mobile terminated short message transfer. Four procedures exist for short message services: - mobile originated short message service transfer; - mobile terminated short message service transfer; - short message alert procedure; - short message delivery status report procedure. The following application context refers to a complex MAP user consisting of several processes: - shortMessageGatewayContext. This application context needs a co-ordinating process in the HLR. Additionally a co-ordinating process needed for the mobile originated situation in the MSC, because the A_CM_SERV_REQ message does not distinguish between mobile originated short message transfer and the short message alert procedures. NOTE: the A_CM_SERV_REQ message is not used for SMS over GPRS. The modelling is based on the assumption that the SGSN will trigger the appropriate process, according to whether an RP_MO_DATA or an RP_SM_MEMORY_AVAILABLE is received over the LLC layer. When the ""SMS in MME"" architecture option is supported, the clause 23 and its associated figures applies where HSS replaces HLR and where MME is handled as a MSC, except the procedures between the serving MSC and the VLR which, here, are not applicable to the MME. NOTE: MSC and MME cannot be both registered as serving nodes for MT SMS at a given time (cf 3GPP TS 23.272 [2]) 23.1.1 Mobile originated short message service Co-ordinator for the MSC The process starts when the MSC receives an A_CM_SERV_REQ message (see 3GPP TS 24.008 [35]), with a CM service type indicating short message service, from the A-interface. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Process_Access_Request_MSC see clauseÊ25.4.1. If the macro Process_Access_Request_MSC takes the ""OK"" exit (which means that the MSC has sent an A_CM_SERVICE_ACCEPT to the MS), , the MS initiates mobile originated short message transfer or sends an indication that it has memory available for more short messages. The SMS Co-ordinator process in the MSC is shown in figureÊ23.1/1. 23.1.2 Short message Gateway Co-ordinator for the HLR The process starts when the HLR receives a MAP_OPEN indication using when the application context shortMessageGatewayContext. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. The SM Gateway Co-ordinator process in the HLR is shown in figureÊ23.1/2. If the Receive_Open_Ind macro takes the Vr exit then HLR shall perform the MAP dialogue as specified for the appropriate application context version. Depending on the subscriber data, handling at the MAP user application level may be performed as specified in clauses 23.3.2 and 23.5.2 of the present document: FigureÊ23.1/1 (sheet 1 of 2): Process Co_SMS_MSC FigureÊ23.1/1 (sheet 2 of 2): Process Co_SMS_MSC FigureÊ23.1/2: Process Co_SM_Gateway_HLR 23.2 The mobile originated short message transfer procedure The mobile originated short message service procedure is used to forward a short message from a mobile subscriber to a Service Centre. The message flow for the mobile originated short message service procedure is shown in figureÊ23.2/1. 1) Short Message (3GPP TS 24.011 [37]). 2) MAP_SEND_INFO_FOR_MO_SMS (*). 3) MAP_SEND_INFO_FOR_MO_SMS_ACK (*). 4) TCAP BEGIN (**) 4a) TCAP CONTINUE (**) 4b) MAP_MO_FORWARD_SHORT_MESSAGE. 5) Short message (3GPP TS 23.040). 6) Short message Acknowledgement (3GPP TS 23.040). 7) MAP_MO_FORWARD_SHORT_MESSAGE_ACK. 8) Short Message Acknowledgement (3GPP TS 24.011 [37]). (*) Messages 2) and 3) are not used by the SGSN. (**) If a) the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message and b) the Interworking MSC operator and the serving node (MSC or SGSN) operator agreed not to use the TCAP handshake countermeasure against SMS fraud for messages exchanged between their networks (see 3GPP TS 33.204 [34a]) then the TCAP handshake may be omitted. FigureÊ23.2/1: Mobile originated short message transfer In addition the following MAP services are used: MAP_PROCESS_ACCESS_REQUEST (see clauseÊ8.3); (*) MAP_AUTHENTICATE (see clauseÊ8.5); (*) MAP_SET_CIPHERING_MODE (see clauseÊ8.6); (*) MAP_PROVIDE_IMSI (see clauseÊ8.9); (*) MAP_CHECK_IMEI (see clauseÊ8.7); MAP_FORWARD_NEW_TMSI (see clauseÊ8.9); (*) MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauseÊ9.1); (*) MAP_READY_FOR_SM (see clauseÊ12.4). (*) These services are not used by the SGSN. 23.2.1 Procedure in the serving MSC Any CAMEL-specific handling defined in this clause is omitted if the MSC does not support CAMEL control of MO SMS, or if the subscriber does not have a subscription for CAMEL control of MO SMS. The process starts when the MSC receives a short message from the MS. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2. Sheet 1: If the MSC is integrated with the SMS-IWMSC, it communicates directly with the Short Message Service Centre (SMSC) using one of the protocols described in 3GPP TS 23.039 [25a]; otherwise it communicates with the SMS-IWMSC using MAP. Sheet 3: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message, the test ""Message segmentation needed"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. Sheet 3:The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the serving MSC's operator and the SMS-IWMSC's operator (see 3GPP TS 33.204 [34a]). The mobile originated short message service process in the MSC is shown in figureÊ23.2/2. 23.2.2 Procedure in the VLR Any CAMEL-specific handling defined in this clause is omitted if the VLR does not support CAMEL control of MO SMS. The process starts when the VLR receives a dialogue opening request followed by a MAP_PROCESS_ACCESS_REQUEST including a CM service type Short Message Service. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1; Process_Access_Request_VLR see clauseÊ25.4.2. The mobile originated short message transfer process in the VLR is shown in figureÊ23.2/3. 23.2.3 Procedure in the SGSN Any CAMEL-specific handling defined in this clause is omitted if the SGSN does not support CAMEL control of MO SMS, or if the subscriber does not have a subscription for CAMEL control of MO SMS. The process starts when the SGSN receives a short message received from the MS over the Gb interface. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Sheet 2: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MO_FORWARD_SHORT_MESSAGE request in a single TC message, the test ""Message segmentation needed"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. Sheet 2:The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the serving SGSN's operator and the SMS-IWMSC's operator (see 3GPP TS 33.204 [34a]). The mobile originated short message service process in the SGSN is shown in figure 23.2/4. 23.2.4 Procedure in the SMS Interworking MSC (SMS-IWMSC) This procedure applies only when the SMS-IWMSC is not integrated with the serving MSC or SGSN. The process starts when the SMS-IWMSC receives a dialogue opening request with the application context shortMsgMO-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. Sheet 1:The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the SMS-IWMSC's operator and the serving node's operator (see 3GPP TS 33.204 [34a]). The mobile originated short message service transfer process in the SMS-IWMSC is shown in figureÊ23.2/5. FigureÊ23.2/2 (sheet 1 of 4): Process MO_SM_MSC FigureÊ23.2/2 (sheet 2 of 4): Process MO_SM_MSC FigureÊ23.2/2 (sheet 3 of 4): Process MO_SM_MSC FigureÊ23.2/2 (sheet 4 of 4): Process MO_SM_MSC FigureÊ23.2/3 (sheet 1 of 2): Process MOSM_VLR FigureÊ23.2/3 (sheet 2 of 2): Process MO_SM_VLR Figure 23.2/4 (sheet 1 of 3): Process MO_SM_SGSN Figure 23.2/4 (sheet 2 of 3): Process MO_SM_SGSN Figure 23.2/4 (sheet 3 of 3): Process MO_SM_SGSN FigureÊ23.2/5 (sheet 1 of 2): Process MO_SM_IWMSC FigureÊ23.2/5 (sheet 2 of 2): Process MO_SM_IWMSC 23.3 The mobile terminated short message transfer procedure The mobile terminated short message transfer procedure is used for forwarding a short message or several short messages from a Service Centre to a mobile subscriber. The message flow for the mobile terminated short message procedure for a single short message transfer is shown in figureÊ23.3/1. FigureÊ23.3/1: Mobile terminated short message service procedures 1) Short Message (3GPP TS 23.040). 2) MAP_SEND_ROUTING_INFO_FOR_SM. 3) MAP_SEND_ROUTING_INFO_FOR_SM_ACK. 4) TCAP BEGIN (***) 4a) TCAP CONTINUE (***) 4b) MAP_MT_FORWARD_SHORT_MESSAGE. The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 5) MAP_SEND_INFO_FOR_MT_SMS (*). 5a) MAP_CONTINUE_CAMEL_SMS_HANDLING (*)(**) 5b) MAP_SEND_INFO_FOR_MT_SMS (*)(**) 6) MAP_PAGE/MAP_SEARCH_FOR_MOBILE_SUBSCRIBER (*). 7) Page (3GPP TS 24.008 [35]). 8) Page response (3GPP TS 24.008 [35]). 9) MAP_PROCESS_ACCESS_REQUEST_ACK and MAP_SEARCH_FOR_MOBILE_SUBSCRIBER_ACK (*). 10) MAP_SEND_INFO_FOR_MT_SMS_ACK (*). 11) Short Message (3GPP TS 24.011 [37]). 12) Short Message Acknowledgement (3GPP TS 24.011 [37]). 13) MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 14) Short Message Acknowledgement (3GPP TS 23.040). (*) Messages 5), 5a), 5b), 6), 9), and 10) are not used by the SGSN. (**) These messages are used only for a subscriber provisioned with MT-SMS-CSI in the VLR. (***) If a) - the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, and b) the SMS Gateway MSC operator and the serving node (MSC or SGSN) operator agreed not to use the TCAP handshake countermeasure against SMS fraud for messages exchanged between their networks (see 3GPP TS 33.204 [34a]) then the TCAP handshake may be omitted. The message flow for the mobile terminated short message procedure for multiple short message transfer is shown in figureÊ23.3/2. FigureÊ23.3/2: Mobile terminated short message procedure for multiple short message transfer 1) Short Message (3GPP TS 23.040 [26]). 2) MAP_SEND_ROUTING_INFO_FOR_SM. 3) MAP_SEND_ROUTING_INFO_FOR_SM_ACK. 4) TCAP BEGIN (***) 4a TCAP CONTINUE (***) 4b) MAP_MT_FORWARD_SHORT_MESSAGE (note 1). The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 5) MAP_SEND_INFO_FOR_MT_SMS (*). 5a) MAP_CONTINUE_CAMEL_SMS_HANDLING (*)(**) 5b) MAP_SEND_INFO_FOR_MT_SMS (*)(**) 6) MAP_PAGE/MAP_SEARCH_FOR_MOBILE_SUBSCRIBER (*). 7) Page (3GPP TS 48.008 [49]). 8) Page response (3GPP TS 24.008 [35]). 9) MAP_PROCESS_ACCESS_REQUEST_ACK and MAP_SEARCH_FOR_MOBILE_SUBSCRIBER_ACK (*). 10) MAP_SEND_INFO_FOR_MT_SMS_ACK (*). 11) Short Message (3GPP TS 24.011 [37]). 12) Short Message Acknowledgement (3GPP TS 24.011 [37]). 13) MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 14) Short Message Acknowledgement (3GPP TS 23.040 [26]). 15) Short Message (3GPP TS 23.040 [26]). 16) MAP_MT_FORWARD_SHORT_MESSAGE (note 2). The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 17) Short Message (3GPP TS 24.011 [37]). 18) Short Message Acknowledgement (3GPP TS 24.011 [37]). 19) MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 20) Short Message Acknowledgement (3GPP TS 23.040 [26]). (*) Messages 5), 5a), 5b) 6), 9), and 10) are not used by the SGSN. (**) These messages are used only for a subscriber provisioned with MT-SMS-CSI in the VLR. (***) If a) the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, and b) the SMS Gateway MSC operator and the serving node (MSC or SGSN) operator agreed not to use the TCAP handshake countermeasure against SMS fraud for messages exchanged between their networks (see 3GPP TS 33.204 [34a]) then the TCAP handshake may be omitted. NOTE 1: The ""More Messages To Send"" flag is TRUE. NOTE 2: The ""More Messages To Send"" flag is FALSE. In the multiple short message transfer the service MAP_MT_FORWARD_SHORT_MESSAGE can be used several times. However, the short message transfer is always acknowledged to the Service Centre before the next short message is sent. In addition the following MAP services are used: MAP_PROCESS_ACCESS_REQUEST (see clauseÊ8.3); (*) MAP_PAGE (see clauseÊ8.2); (*) MAP_SEARCH_FOR_MS (see clauseÊ8.2); (*) MAP_AUTHENTICATE (see clauseÊ8.5); (*) MAP_SET_CIPHERING_MODE (see clauseÊ8.6); (*) MAP_CHECK_IMEI (see clauseÊ8.7); MAP_FORWARD_NEW_TMSI (see clauseÊ8.9); (*) MAP_REPORT_SM_DELIVERY_STATUS (see clauseÊ12.3); MAP_INFORM_SERVICE_CENTRE (see clauseÊ12.6); MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauseÊ9.1); (*) MAP_READY_FOR_SM (see clauseÊ12.4). (*) These services are not used by the SGSN. A message flow example for the mobile terminated short message procedure for a single short message transfer in an environment that makes use of an SMS Router for MT-short-message-transfer is shown in figureÊ23.3/2a. NOTE: This message flow can be applied only if no IP-SM-GW deployed in the same network. FigureÊ23.3/2a Mobile terminated short message procedure with SMS Router 1) Short Message (3GPP TS 23.040 [26]) 2) & 3) MAP_SEND_ROUTING_INFO_FOR_SM NOTE: The HLR relays the message MAP_SEND_ROUTING_INFO_FOR_SM received from the SMS-GMSC to the SMS Router on SCCP level. How this is done is implementation specific. 4) MAP_SEND_ROUTING_INFO_FOR_SM 5) MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE 6) MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE 7) Conditionally: Inform Service Centre (3GPP TS 23.040 [26]) 8) MAP_MT_FORWARD_SHORT_MESSAGE The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. NOTE: In this example the SMS-GMSC decides to attempt delivery via MSC. Therefore the SCCP called party SSN shall be set to SSN for MSC. 9) MAP_MT_FORWARD_SHORT_MESSAGE The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 10) MAP_MT_FORWARD_SHORT_MESSAGE_ERROR NOTE: In this example delivery via the MSC is unsuccessful e.g. due to IMSI detached 11) MAP_MT_FORWARD_SHORT_MESSAGE_ERROR 12) MAP_MT_FORWARD_SHORT_MESSAGE NOTE: In this example the SMS-GMSC decides to retry delivery via the SGSN. Therefore the SCCP called party SSN shall be set to the SSN for SGSN. 13) MAP_MT_FORWARD_SHORT_MESSAGE The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK. 14) MAP_MT_FORWARD_SHORT_MESSAGE_ACK NOTE: In this example delivery via SGSN is successful 15) MAP_MT_FORWARD_SHORT_MESSAGE_ACK 16) Conditionally: MAP_REPORT_SM_DELIVERY_STATUS NOTE: In this example unsuccessful delivery via MSC and successful delivery via SGSN is reported 17) MAP_REPORT_SM_DELIVERY_STATUS_Ack 18) Short Message Acknowledgement (3GPP TS 23.040 [26]). A message flow example for the mobile terminated short message procedure for a single short message transfer in an environment that makes use of an IP-SM-GW (see 3GPP TS 23.204 [134]) for MT-short-message-transfer is shown in figureÊ23.3/2b. NOTE: SMS Routers can apply this message flow as well. FigureÊ23.3/2b Mobile terminated short message procedure with IP-SM-GW 1) Short Message (3GPP TS 23.040 [26]) 2) MAP_SEND_ROUTING_INFO_FOR_SM the message is forwarded to the IP-SM-GW assigned to the recipient of the SM the message may contain IP-SM-GW Guidance support indication 3) MAP_SEND_ROUTING_INFO_FOR_SM 4) MAP_SEND_ROUTING_INFO_FOR_SM since the message is received from an IP-SM-GW, it is not forwarded to an IP-SM-GW 5) MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE 6) MAP_SEND_ROUTING_INFO_FOR_SM_ACK and conditionally MAP_INFORM_SERVICE_CENTRE The IP-SM-GW returns its own address within the network node number parameter The message may include IP-SM-GW Guidance 7) Conditionally: Inform Service Centre (3GPP TS 23.040 [26]) 8) MAP_MT_FORWARD_SHORT_MESSAGE If the IP-SM-GW-Guidance support indicator was present in message 2 and IP-SM-GW-Guidance was present in message 6, message 8 shall contain the used timer value for supervision of MAP_MT_FORWARD_SHORT_MESSAGE_ACK; the used timer should be identical to the recommended value received in message 6 to ensure that the IP-SM-GW can attempt delivery to multiple domains if necessary and shall not be lower than the minimum value received in message 6 to ensure that an IP-SM-GW can attempt delivery to at least one domain. Otherwise, The message should include the timer value used at the SMS-GMSC for the supervision of the MAP_MT_FORWARD_SHORT_MESSAGE_ACK."
"9) MAP_MT_FORWARD_SHORT_MESSAGE_ACK 10) Conditionally: MAP_REPORT_SM_DELIVERY_STATUS NOTE: As an IP-SM-GW is deployed the message is acknowledged ignoring its content 11) MAP_REPORT_SM_DELIVERY_STATUS_Ack 12) Conditionally: MAP_REPORT_SM_DELIVERY_STATUS since the message is received from an IP-SM-GW, it is processed 13) MAP_REPORT_SM_DELIVERY_STATUS_Ack NOTE: Step 12 and 13 is independent of steps 10, 11, and 14. They can run in parallel. 14) Short Message Acknowledgement (3GPP TS 23.040 [26]). 23.3.1 Procedure in the SMS-GMSC Any CAMEL-specific handling described in this clause is omitted if the SMS-GMSC does not support CAMEL. CAMEL-specific handling is invoked only if the SMS-GMSC is integrated with the VMSC. The process starts when the SMS-GMSC receives an SC_RP_MT_DATA indication from a Service Centre. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. Process MT_SM_GMSC sheet 1: If the MAP_SEND_ROUTING_INFO_FOR_SM confirmation included an LMSI, it shall be included in the sm-RP-DA information field of the first MAP_MT_FORWARD_SHORT_MESSAGE request sent to the serving MSC. In this case, the IMSI shall be included in the Destination Reference of the MAP_OPEN request. The SMS-GMSC shall not send an LMSI to an SGSN. If the SMS-GMSC does not send an LMSI to the serving node, the sm-RP-DA information field in the first MAP_MT_FORWARD_SHORT_MESSAGE request sent to the serving MSC or SGSN shall contain the IMSI, and the Destination Reference in the MAP_OPEN request shall not be present. The parameter SM_RP_OA shall contain the Service Centre address. Process MT_SM_GMSC sheet 1: The indication of which number belongs to the SGSN and which to the MSC, received from the HLR in the MAP_SEND_ROUTING_INFO_FOR_SM confirm (see clause 23.3.2) will enable the SMS-GMSC to map the causes received from one or both serving nodes into the appropriate causes for non GPRS, GPRS or both, and send them to the SC and the HLR. Process MT_SM_GMSC sheet 2: The SMS-GMSC maps ""Unexpected data value"" and ""System failure"" MAP errors from the serving node to a ""System failure"" RP_ERROR error cause. The mapping between other MAP error causes and the RP_ERROR error cause is given in 3GPP TSÊ23.040Ê[26] and 3GPP TSÊ24.011Ê[37]. Process MT_SM_GMSC sheet 2: If the SMS-GMSC receives both MSC and SGSN numbers from the HLR as routeing information, it may choose which serving node to use for the first delivery attempt. Process MT_SM_GMSC sheet 2: If the SMS-GMSC makes two delivery attempts, it may report the result of each delivery attempt to the HLR according to the conditions described below. Procedure MT_SM_Delivery_Attempt_GMSC sheet 1: if the macro MT_SM_Transfer_MSC takes the Error exit, the SMS-GMSC maps the MAP User Error to the corresponding SC_RP error, as defined in 3GPP TSÊ23.040Ê[26]. Procedure MT_SM_Delivery_Attempt_GMSC sheet 3: The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the GMSC's operator and the serving node's operator (see 3GPP TS 33.204 [34a]). Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 2, sheet 4, sheet 5: The SMS-GMSC invokes the macro Report_SM_Delivery_Stat_GMSC if: - the reason received from the serving node for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause ""MS memory capacity exceeded"", and the SC address is not yet included in the MWD set, or - the reason received from the serving node for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause MS memory capacity exceeded, and the corresponding flag in the HLR (as indicated in the information received in the MAP_INFORM_ SERVICE_CENTRE) is not set, or - the reason received from the serving node (MSC or SGSN) for failure to deliver the message is absent subscriber_SM and the absent subscriber diagnostic is different from the absent subscriber diagnostic received in the MAP_INFORM_ SERVICE_CENTRE. Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 2, sheet 4, sheet 5: If absent subscriber diagnostic information (see 3GPP TSÊ23.040Ê[26]) is included with the absent subscriber_SM error indication then the SMS-GMSC relays this information to the HLR using the MAP_REPORT_SM_DELIVERY_STATUS service. Procedure MT_SM_Delivery_Attempt_GMSC sheet 1, sheet 4: The More Messages To Send flag is set to TRUE or FALSE according to the information received from the Service Centre. Procedure MT_SM_Delivery_Attempt_GMSC sheet 3: If the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SHORT_MESSAGE request in a single TC message, the test ""Message segmentation needed"" takes the ""No"" exit; otherwise the test takes the ""Yes"" exit. The mobile terminated short message transfer process in the SMS-GMSC is shown in figureÊ23.3/3. The procedure MT_SM_Delivery_Attempt_GMSC is shown in figureÊ23.3/4. The macro MT_SM_Transfer_MSC is shown in figureÊ23.3/7. The SMS-GMSC may include the Maximum Retransmission Time IE in the MT Forward Short Message Request to indicate that it is capable to retransmit the Short Message until the indicated maximum retransmission time, if the following conditions are fulfilled: - the destination user pertains to the PLMN of the SMS-GMSC; and - if an SMS Router is used for MT SMS sent to destination users pertaining to the PLMN of the SMS-GMSC, the SMS Router is known to support the Alert Service Centre procedure specified in clause 12.5. The SMS-GMSC shall include its E.164 number in the SMS-GMSC address and, if available its Diameter Identity in the SMS-GMSC Diameter Address in the request if it also includes the Maximum-Retransmission-Time IE. If subsequently, the SMS-GMSC receives an Alert Service Centre request from an MME (via an IWF), SGSN or MSC, the SMS-GMSC shall retransmit pending MT SMS(s) for the destination user identified by the User Identifier Alert, to the same serving node if the SMS-GMSC Alert Event indicates that the MS is available for MT SMS, or to the new serving node if the SMS-GMSC Alert Event indicates that the MS has moved under the coverage of another MME, SGSN or MSC. In the latter case, if neither New MSC Number, nor New SGSN Number, nor New SGSN Diameter Address, nor New MME Number, nor New MME Diameter Address are received in the Alert Service Centre request, the SMS-GMSC shall initiate a Send Routing Info for SM procedure to retrieve the new serving node 's address from the HLR. 23.3.2 Procedure in the HLR The process starts when the HLR receives a MAP_SEND_ROUTING_INFO_FOR_SM indication from the SMS-GMSC. If an SMS Router is deployed, the HLR receives MAP_SEND_ROUTING_INFO_FOR_SM from the SMSÊRouter (step 4 in figure 23.3/2a); relaying a message received from the SMS-GMSC to the SMS Router on SCCP level (steps 2 and 3 in figure 23.3/2a) is done by implementation specific means and is not shown in figure 23.3/5. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.1. Sheet 1: The decision box ""Relay to IP-SM-GW"" takes the ""yes"" exit if an IP-SM-GW is deployed and the message was not received from an IP-SM-GW. Sheet 3: If the SMS-GMSC does not support GPRS functionality, it uses the protocol defined in the Release 96 version of this specification. The parameter ""msc-Number"" in ""RoutingInfoForSM-Res"" in the Release 96 version of the protocol definition corresponds to the parameter ""networkNode-Number"" in ""RoutingInfoForSM-Res"" in the Release 97 (and later) version of the protocol definition; therefore if the HLR populates the parameter ""networkNode-Number"" with the SGSN number, the Release 96 SMS-GMSC will interpret the SGSN number as an MSC number. If the HLR populates the ""gprsNodeIndicator"" parameter in the MAP_SEND_ROUTING_INFO_FOR_SM response, a Release 96 SMS-GMSC will silently discard the parameter. Sheet 5: If the HLR received a LMSI from the VLR at location updating, it shall include the LMSI in the MAP_SEND_ROUTING_INFO_FOR_SM response only if the MAP_SEND_ROUTING_INFO_FOR_SM response also includes the MSC number. The mobile terminated short message transfer process in the HLR is shown in figureÊ23.3/5. 23.3.3 Procedure in the Serving MSC Any CAMEL-specific handling defined in this clause is omitted if the MSC does not support CAMEL control of MT SMS, or if the subscriber does not have a subscription for CAMEL control of MT SMS. The process starts when the MSC receives a dialogue opening request with the application context shortMsgMT-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. The mobile terminated short message transfer process in the serving MSC is shown in figure 23.3/6 Procedure MT_SM_VMSC sheet 1: The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the Serving MSC's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]). The macro MT_SM_Transfer_MSC may be invoked either in a stand-alone serving MSC or in a serving MSC which is integrated with the SMS-GMSC. It is used to transfer the first MT short message of a possible sequence of messages. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Confirmation see clauseÊ25.2.2. Page_MSC see clauseÊ25.3.1; Search_for_MS_MSC see clauseÊ25.3.2; Process_Access_Request_MSC see clauseÊ25.4.1; Trace_Subscriber_Activity_MSC see clauseÊ25.9.1. The macro MT_SM_Transfer_MSC is shown in figure 23.3/7. The macro Check_Subscr_Identity_For_MT_SMS is shown in figure 23.3/8. 3GPP TS 29.118 [152] specifies the extensions applicable to the MT SMS procedure over SGs for a UE using extended idle mode DRX (as defined in 3GPP TSÊ23.682 [148]). If the MS is using a power saving mechanism such as extended idle mode DRX (see 3GPP TSÊ23.682 [148]), and if the MT Forward Short Message Request includes the Maximum Retransmission Time IE, an MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPPÊTSÊ23.272Ê[143] and 3GPP TS 23.040 [6]) may return an MT Forward Short Message Response with the User Error set to Absent Subscriber_SM and with the Requested-Retransmission-Time IE requesting the SMS-GMSC to retransmit the Short Message at a later time prior to the Maximum Retransmission Time. In that case, the MSC shall store (if not already done) the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and shall not set the MNRF flag. NOTE: This mechanism does not cause additional signalling at the HSS to retransmit the Short Message. An MSC using Deployment Option 2 (see clause 8.2.4a.1 of 3GPPÊTSÊ23.272Ê[143] and 3GPP TS 23.040 [6]) shall initiate the MAP Service Center Alert procedure to alert the SMS-GMSC when the UE, for which one or more MT SMS have been requested to be retransmitted at a later time, becomes available for MT SMS delivery or moves under the coverage of another MSC prior to the requested SM retransmission time. The MSC shall then delete the stored SMS-GMSC address after the Alert Service Centre procedure is completed. 23.3.4 Procedure in the VLR Any CAMEL-specific handling defined in this clause is omitted if the VLR does not support CAMEL control of MT SMS. The process starts when the VLR receives a dialogue opening request from the MSC. The process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2; Process_Access_Request_VLR see clauseÊ25.4.2. The mobile terminated short message transfer process in the VLR is shown in figureÊ23.3/9. If the VLR has no IMSI record, or if the record is marked ""Subscriber Data Not Confirmed by HLR"", the VLR may perform the data restoration procedure as specified in clause 4.2.2 in 3GPP TS 23.007 [19]. 23.3.5 Procedure in the SGSN Any CAMEL-specific handling defined in this clause is omitted if the SGSN does not support CAMEL control of MT SMS, or if the subscriber does not have a subscription for CAMEL control of MT SMS. The process starts when the SGSN receives a dialogue opening request with the application context shortMsgMT-RelayContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. The mobile terminated short message transfer process in the SGSN is shown in figure 23.3/10. Procedure MT_SM_SGSN sheet 1: The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the Serving SGSN's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]). The macro MT_SM_Transfer_SGSN is used to transfer the first MT short message of a possible sequence of messages. It is shown in figure 23.3/11. If the MS is using extended idle mode DRX (as defined in 3GPP TSÊ23.682 [148]) and the MS is expected to respond to paging shortly or within the time frame indicated by the SM-Delivery-Timer and SM-Delivery-Start-Time IEs, the SGSN should page the MS and attempt to deliver the short message to the MS. If the MS is using extended idle mode DRX (as defined in 3GPP TSÊ23.682 [148]) and the MS is expected to not respond to paging shortly or within the time frame indicated by the SM-Delivery-Timer and SM-Delivery-Start-Time IEs, the SGSN may behave as specified in figure 23.3/11 for an MS that is not reachachable, i.e. set the MNRG flag and return an Absent Subscriber Error to the SMS-GMSC, while still paging the MS. NOTE 1: This mechanism is not intended for MSs which are known to wake up shortly (e.g. within the next 10 seconds) as enough time needs to elapse, between the sending of the MT Forward Short Message Response and the subsequent Ready For SM procedure towards the HLR when the MS becomes reachable, for the Report SM Delivery Status procedure to take place beforehand from the SMS-GMSC to the HLR. If the MS is using a power saving mechanism such as extended idle mode DRX (see 3GPP TSÊ23.682 [148]), and if the MT Forward Short Message Request includes the Maximum Retransmission Time IE, the SGSN may return an MT Forward Short Message Response with the User Error set to Absent Subscriber_SM and with the Requested-Retransmission-Time IE requesting the SMS-GMSC to retransmit the Short Message at a later time prior to the Maximum Retransmission Time. In that case, the SGSN shall store (if not already done) the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and shall not set the MNRG flag. NOTE 2: This mechanism does not cause additional signalling at the HSS to retransmit the Short Message. The SGSN shall initiate the MAP Service Center Alert procedure to alert the SMS-GMSC when the UE, for which one or more MT SMS have been requested to be retransmitted at a later time, becomes available for MT SMS delivery or moves under the coverage of another MME or SGSN prior to the requested SM retransmission time. The SGSN shall then delete the stored SMS-GMSC address after the Alert Service Centre procedure is completed. The macro Check_Subscr_Identity_For_MT_SMS is shown in figure 23.3/8. The page and search procedures are shown in figuresÊ23.3/12 and 23.3/13. 23.3.6 Procedure in the SMS Router If SMS Router is deployed together with IP-SM-GW, then mobile terminated short message transfer process for IP-SM-GW applies as described in clauseÊ23.3.7. The mobile terminated short message transfer process in the SMS Router is shown in figureÊ23.3/14. Procedure MT_SM_SMS_ROUTER sheet 2: Allocated MT Correlation IDs have a limited lifetime, managed by Timer T1. The value of Timer T1 shall be operator configurable (its value being dependant on such factors as subscriber base, network size, number of roaming/SMS interworking partners, average and peak SMS traffic load, etc.). The value of the timer T1 shall cover at least the time indicated by the SM Delivery Start Time and SM Delivery Timer and, if the SMS Router support the Alert Service Centre procedure specified in clause 12.5, the Maximum Retransmission Time signalled in the MAP-MT-FORWARD-SHORT-MESSAGE. Procedure MT_SM_SMS_ROUTER sheet 2: MAP parameters to be stored against the MT Correlation ID are IMSI, networkNode-Number, gprsNodeIndicator, and additional-Number (if and as received within MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_cnf), and optionally MSISDN as received within MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_ind from the SMS-GMSC (and relayed by the HLR)). The SMS Router may also store the GT, or just the CC and NDC parts of the GT, of the SMS-GMSC from which the MAP_SEND_ROUTING_INFO_FOR_SHORT_MESSAGE_ind was received. Procedure MT_SM_SMS_ROUTER sheet 3: The SCCP called party SSN received with Open_ind is used to decide whether the new dialogue is opend with the MSC or with the SGSN. The detail of replacing RP-OA is described in TS23.040 [26]. Procedure MT_SM_SMS_ROUTER sheet 4: The decision box ""Retry expected"" takes the ""Yes"" exit if two addresses were received from the HLR, the first delivery attempt was unsuccessful, and the second attempt has not yet been made. Procedure MT_SM_SMS_ROUTER sheet 4: The task ""Release MT Correlation ID"" includes deleting of data stored against the MT Correlation ID. If the MT Forward Short Message Request includes the Maximum-Retransmission-Time IE, the SMS Router shall store the SMS-GMSC address and, if available, the SMS-GMSC Diameter Identity received in the request and replace it by its SMS Router address (E.164 number) and, if available, its SMS Router Diameter Identity when forwarding the request to the MME (via an IFW), SGSN or MSC. If the MT Forward Short Message Response includes the Requested-Retransmission-Time IE, the SMS Router shall include the User Identifier Alert IE when forwarding the response to the SMS-GMSC. NOTE: The User Identifier Alert is further used in the Alert Service Centre procedure specified in clause 12.5 to enable the SMS-GMSC to identify and retransmit all pending MT SMS messages towards the destination user. When receiving an Alert Service Centre request from an MME (via an IWF), SGSN or MSC, the SMS-Router shall replace the IMSI received in the IMSI IE by the User Identifier Alert previously sent in the MT Forward Short Message Response, and forward that request to the SMS-GMSC. 23.3.7 Procedure in the IP-SM-GW Process MT_SM_IPSMGW sheet 3: After unsuccessful delivery via the S-CSCF the IP-SM-GW may retry delivery via MSC and/or SGSN if MSC address and/or SGSN address are available (unless the reported error was ""memory capacity exceeded"" in which case a retry shall not be done). If the retry is successful, a positive response is returned to the SMS-GMSC. If the retry is unsuccessful, an error indication is returned to the SMS-GMSC as follows: If one of the error indications received from S-CSCF, MSC, or SGSN is AbsentsSubscriberSM or UnidentifiedSubscriber, this error shall be returned to the SMS-GMSC. Process MT_SM_IPSMGW sheet 3: The IP-SM-GW invokes the macro Report_SM_Delivery_Stat_IPSMGW if: - the reason for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause ""MS memory capacity exceeded"", and the SC address is not yet included in the MWD set, or - the reason for failure to deliver the message is absent subscriber_SM, unidentified subscriber or SM delivery failure with error cause MS memory capacity exceeded, and the corresponding flag in the HLR (as indicated in the information received in the MAP_INFORM_SERVICE_CENTRE) is not set, or - the reason for failure to deliver the message is absent subscriber_SM and the absent subscriber diagnostic is different from the absent subscriber diagnostic received in the MAP_INFORM_SERVICE_CENTRE. The mobile terminated short message transfer process in the IP-SM-GW is shown in figureÊ23.3/15. FigureÊ23.3/3 (sheet 1 of 2): Process MT_SM_GMSC Figure 23.3/3 (sheet 2 of 2): Process MT_SM_GMSC FigureÊ23.3/4 (sheet 1 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 2 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 3 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 4 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 5 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 6 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 7 of 8): Procedure MT_SM_Delivery_Attempt_GMSC FigureÊ23.3/4 (sheet 8 of 8): Procedure MT_SM_Delivery_Attempt_GMSC Figure 23.3/5 (sheet 1 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 2 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 3 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 4 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 5 of 6): Process MT_SM_HLR Figure 23.3/5 (sheet 6 of 6): Process MT_SM_HLR Figure 23.3/5a (sheet 1 of 1): Procedure Perform_Relaying FigureÊ23.3/6 (sheet 1 of 4): Procedure MT_SM_VMSC FigureÊ23.3/6 (sheet 2 of 4): Procedure MT_SM_VMSC FigureÊ23.3/6 (sheet 3 of 4): Procedure MT_SM_VMSC FigureÊ23.3/6 (sheet 4 of 4): Procedure MT_SM_VMSC FigureÊ23.3/7 (sheet 1 of 4): Macro MT_SM_Transfer_MSC FigureÊ23.3/7 (sheet 2 of 4): Macro MT_SM_Transfer_MSC FigureÊ23.3/7 (sheet 3 of 4): Macro MT_SM_Transfer_MSC FigureÊ23.3/7 (sheet 4 of 4): Macro MT_SM_Transfer_MSC FigureÊ23.3/8: Macro Check_Subscr_Identity_For_MT_SMS FigureÊ23.3/9 (sheet 1 of 3): Process MT_SM_VLR FigureÊ23.3/9 (sheet 2 of 3): Process MT_SM_VLR Figure 23.3/9 (sheet 3 of 3): Process MT_SM_VLR Figure 23.3/10 (sheet 1 of 4): Process MT_SM_SGSN Figure 23.3/10 (sheet 2 of 4): Process MT_SM_ SGSN Figure 23.3/10 (sheet 3 of 4): Process MT_SM_ SGSN Figure 23.3/10 (sheet 4 of 4): Process MT_SM_ SGSN Figure 23.3/11 (sheet 1 of 3): Macro MT_SM_TRANSFER_SGSN Figure 23.3/11 (sheet 2 of 3): Macro MT_SM_TRANSFER_SGSN Figure 23.3/11 (sheet 3 of 3): Macro MT_SM_TRANSFER_SGSN Figure 23.3/12 (sheet 1 of 1): Procedure Page_SMS_SGSN Figure 23.3/13 (sheet 1 of 1): Procedure Search_SMS_SGSN Figure 23.3/14 (sheet 1 of 4): Process MT_SM_ SMS_ROUTER Figure 23.3/14 (sheet 2 of 4): Process MT_SM_ SMS_ROUTER Figure 23.3/14 (sheet 3 of 4): Process MT_SM_ SMS_ROUTER Figure 23.3/14 (sheet 4 of 4): Process MT_SM_ SMS_ROUTER Figure 23.3/15 (sheet 1 of 3): Process MT_SM_ IPSMGW Figure 23.3/15 (sheet 2 of 3): Process MT_SM_ IPSMGW Figure 23.3/15 (sheet 3 of 3): Process MT_SM_ IPSMGW 23.4 The Short Message Alert procedure The Short Message Alert procedure is used to alert the Service Centre when the mobile subscriber is active after a short message transfer has failed because the mobile subscriber is not reachable, or when the MS has indicated that it has memory capacity to accept a short message. The message flow for the Short Message Alert procedure for the case when the mobile subscriber was not reachable is shown in figureÊ23.4/1. 1) CM Service Request (**), Page response or Location Updating (3GPP TS 24.008 [35]). 2) MAP_PROCESS_ACCESS_REQUEST / MAP_UPDATE_LOCATION_AREA (**). 3) MAP_READY_FOR_SM (Mobile Present) / MAP_UPDATE_LOCATION / Supplementary Service Control Request (*). 4) MAP_READY_FOR_SM_ACK (*). 5) MAP_ALERT_SERVICE_CENTRE (notes 1 and 2). 6) Alert Service Centre (3GPP TS 23.040). 7) MAP_ALERT_SERVICE_CENTRE_ACK. NOTE 1: To all Service Centres in the Message Waiting List. NOTE 2: The HLR initiates the MAP_ALERT_SERVICE_CENTRE service only if the MS Memory Capacity Exceeded flag is clear. (*) For GPRS, messages 3) and 4) are sent/received by the SGSN. (**) These messages are not used by the SGSN. FigureÊ23.4/1: Short message alert procedure (Mobile is present) The message flow for the Short Message Alert procedure for the case where the MS indicates that it has memory capacity to accept one or more short messages is shown in figureÊ23.4/2. 1) SM memory capacity available ( 3GPP TS 24.011 [37]). 2) MAP_READY_FOR_SM (Memory Available) (*). 3) MAP_READY_FOR_SM (Memory Available) (**). 4) MAP_READY_FOR_SM_ACK (**). 5) MAP_READY_FOR_SM_ACK (*). 6) SM memory capacity available (Acknowledge) (3GPP TS 24.011 [37]). 7) MAP_ALERT_SERVICE_CENTRE (note). 8) Alert Service Centre (3GPP TS 23.040). 9) MAP_ALERT_SERVICE_CENTRE_ACK. NOTE: To all Service Centres in the Message Waiting List. (*) Messages 2) and 5) are not used by the SGSN. (**) For GPRS, messages 3) and 4) are sent/received by the SGSN. FigureÊ23.4/2: Short message alert procedure (MS memory capacity available) In addition the following MAP services are used in the MS memory available case: MAP_PROCESS_ACCESS_REQUEST (see clauseÊ8.3); (*) MAP_AUTHENTICATE (see clauseÊ8.5); (*) MAP_SET_CIPHERING_MODE (see clauseÊ8.6); (*) MAP_PROVIDE_IMSI (see clauseÊ8.9); (*) MAP_CHECK_IMEI (see clauseÊ8.7); MAP_FORWARD_NEW_TMSI (see clauseÊ8.9); (*) MAP_TRACE_SUBSCRIBER_ACTIVITY (see clauseÊ9.1). (*) (*) These services are not used by the SGSN. The Short Message Alert procedure when the MS indicates successful transfer after polling is shown in figureÊ23.4/3. 1) MAP_REPORT_SM_DELIVERY_STATUS (Successful Transfer). 2) MAP_REPORT_SM_DELIVERY_STATUS_ACK. 3) MAP_ALERT_SERVICE_CENTRE (note). 4) Alert Service Centre (3GPP TS 23.040). 5) MAP_ALERT_SERVICE_CENTRE_ACK. NOTE: To all Service Centres in the Message Waiting List. FigureÊ23.4/3: Short message alert procedure (Successful transfer after polling) 23.4.1 Procedure in the Serving MSC Ð the MS has memory available The process starts when the MSC receives a notification from the MS that it has memory available. The process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Confirmation see clauseÊ25.2.2. The short message alert process in the MSC for the MS memory capacity available case is shown in figureÊ23.4/4. 23.4.2 Procedures in the VLR 23.4.2.1 The Mobile Subscriber is present If the VLR successfully handles a MAP_PROCESS_ACCESS_REQUEST indication or a MAP_UPDATE_LOCATION_AREA indication while the MS Not Reachable Flag (MNRF) is set, the VLR sends a MAP_READY_FOR_SM request to the HLR. The Alert Reason is set to indicate that the mobile subscriber is present for non GPRS. If authentication fails during the handling of a MAP_PROCESS_ACCESS_REQUEST indication or a MAP_UPDATE_LOCATION_AREA indication, the VLR shall not send a MAP_READY_FOR_SM request to the HLR. The process in the VLR is described in detail in clauseÊ25.10.1. 23.4.2.2 The MS has memory available The process starts when the VLR receives dialogue opening request followed by a MAP_PROCESS_ACCESS_REQUEST indication including a CM service type Short Message Service. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Indication see clauseÊ25.2.1; Check_Confirmation see clauseÊ25.2.2. The short message alert process in the VLR for the MS memory capacity available case is shown in figure 23.4/5. 23.4.3 Procedures in the SGSN 23.4.3.1 The Mobile Subscriber is present If the SGSN successfully handles a Page response, Attach request or Routing Area Update request message (3GPP TS 24.008 [35]), while the MS Not Reachable for GPRS (MNRG) flag is set, the SGSN sends a MAP_READY_FOR_SM request to the HLR. The Alert Reason is set to indicate that the mobile subscriber is present for GPRS. If authentication fails during the handling of a Page response, Attach request or Routing Area Update request, the SGSN shall not send a MAP_READY_FOR_SM request to the HLR The process in the SGSN is described in detail in clauseÊ25.10.23. 23.4.3.2 The Mobile Equipment has memory available The process starts when the SGSN receives an RP_SM_MEMORY_AVAILABLE indication from the MS. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The short message alert procedure in the SGSN for the MS memory capacity available case is shown in figureÊ23.4/6. 23.4.4 Procedure in the HLR The process starts when the HLR receives a dialogue opening request using the application context mwdMngtContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1; Alert_Service_Centre_HLR see clauseÊ25.10.3. Sheet 1: If the dialogue opening request is from an SGSN, version 2 and version 1 of the application context are not applicable. The short message alert process in the HLR is shown in figure 23.4/7. 23.4.5 Procedure in the SMS Interworking MSC The process starts when the SMS-IWMSC receives a dialogue opening request using the application context shortMsgAlertContext. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1. The short message alert process in the SMS-IWMSC is shown in figureÊ23.4/8. FigureÊ23.4/4: Procedure SM_Alert_MSC FigureÊ23.4/5 (sheet 1 of 2): Procedure SM_Alert_VLR FigureÊ23.4/5 (sheet 2 of 2): Procedure SM_Alert_VLR Figure 23.4/6 (sheet 1 of 2): Process SM_Alert_SGSN Figure 23.4/6 (sheet 2 of 2): Process SM_Alert_SGSN Figure 23.4/7 (sheet 1 of 2): Process SM_Alert_HLR Figure 23.4/7 (sheet 2 of 2): Process SM_Alert_HLR FigureÊ23.4/8: Process Alert_SC_IWMSC 23.5 The SM delivery status report procedure The SM delivery status report procedure is used: - to set the Service Centre address into the message waiting list in the HLR after short message delivery has failed because the subscriber is absent or unidentified or the memory capacity is exceeded. The procedure sets: - the Memory Capacity Exceeded Flag (MCEF) in the HLR if the MS memory does not have room for more messages; - and/or the MS Not Reachable Flag for non-GPRS if there is no record for the subscriber in the VLR or the subscriber does not respond to paging for delivery via the MSC; - and/or the MS Not Reachable for GPRS (MNRG) flag if there is no record for the subscriber in the SGSN or the subscriber does not respond to paging for delivery via the SGSN; - and/or the UE Not Reachable for IP (UNRI) flag if delivery via the IMS was not successful. - to report to the HLRthat delivery has succeeded. The conditions for report of a successful delivery are described in clauseÊ23.3.1. The message flow for the SM delivery status report procedure is shown in figureÊ23.5/1. 1) MAP_MT_FORWARD_SHORT_MESSAGE_ACK/_NACK (Absent subscriber_SM, unidentified subscriber or memory capacity exceeded). 2) MAP_REPORT_SM_DELIVERY_STATUS. (The HLR ignores the content of this message when an IP-SM-GW is deployed) 2a) MAP_REPORT_SM_DELIVERY_STATUS (sent only by IP-SM-GW) 2b) MAP-REPORT_SM_DELIVERY_STATUS_ACK. 3) MAP_REPORT_SM_DELIVERY_STATUS_ACK. 4) Short Message Negative Acknowledgement (3GPP TS 23.040). FigureÊ23.5/1: Short message delivery status report procedure 23.5.1 Procedure in the SMS-GMSC The conditions for the GMSC to invoke the short message delivery status report procedure are specified in clause 23.3.1. The short message delivery status report macro in the SMS-GMSC is shown in figureÊ23.5/2. 23.5.2 Procedure in the HLR When the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indication while an IP-SM-GW is deployed in the network and the message is not received from an IP-SM-GW, it ignores the information received in the message; otherwise it acts as described in clauseÊ23.6, macro Report_SM_Delivery_Stat_HLR. The short message delivery status report process in the HLR is shown in figureÊ23.5/3. 23.5.3 Procedure in the IP-SM-GW The conditions for the IP-SM-GW and for SMS Router, if deployed with IP-SM-GW, to invoke the short message delivery status report procedure are specified in clause 23.3.7. The short message delivery status report macro in the IP-SM-GW is shown in figureÊ23.5/4. Figure 23.5/2: Macro Report_SM_Delivery_Stat_GMSC FigureÊ23.5/3: Process SM_Delivery_Status_Report_HLR FigureÊ23.5/4: Macro Report_SM_Delivery_Stat_IPSMGW 23.6 The macro Report_SM_Delivery_Stat_HLR This macro is invoked when the HLR receives a MAP_REPORT_SM_DELIVERY_STATUS indication from the SMS-GMSC. The macro invokes macros not defined in this clause; the definitions of these macros can be found as follows: Check_Indication see clauseÊ25.2.1; Alert_Service_Centre_HLR see clauseÊ25.10.3. Sheet 1: If the MAP_REPORT_SM_DELIVERY_STATUS indication did not include the GPRS support indicator, the HLR deduces the domain for which the delivery report applies as follows: - if the subscriber is a GPRS-only subscriber, the report applies for GPRS; - if the subscriber is a non-GPRS-only subscriber, the report applies for non-GPRS; - if the subscriber is a GPRS and non-GPRS subscriber and the subscription option for MT SMS delivery when the SMS-GMSC does not support GPRS is set to ""Delivery via the SGSN"", the report applies for GPRS; - if the subscriber is a GPRS and non-GPRS subscriber and the subscription option for MT SMS delivery when the SMS-GMSC does not support GPRS is set to ""Delivery via the MSC"", the report applies for non-GPRS; The short message delivery status report macro in the HLR is shown in figureÊ23.6/1. FigureÊ23.6/1 (sheet 1 of 2): Macro Report_SM_Delivery_Stat_HLR FigureÊ23.6/1 (sheet 2 of 2): Macro Report_SM_Delivery_Stat_HLR 23.7 The mobile terminated short message transfer procedure for VGCS The mobile terminated short message transfer for VGCS procedure is used for forwarding a short message from a Service Centre to the group call anchor MSC. The message flow for the mobile terminated short message transfer procedure for VGCS is shown in figureÊ23.7/1. FigureÊ23.7/1: Mobile terminated short message for VGCS service procedures 1) Short Message (3GPP TS 23.040). 2) TCAP BEGIN (*) 3) TCAP CONTINUE (*) 4) MAP_MT_FORWARD_SM_FOR_VGCS. 5) GCR_SMS_INTERROGATION (3GPP TS 43.068). 6) GCR_SMS_INTERROGATION_ACK (3GPP TS 43.068). 7) MAP_MT_FORWARD_SM_FOR_VGCS_ACK. 8) Short Message Acknowledgement (3GPP TS 23.040). (*) If a) - the capacity of a message signal unit in the lower layers of the protocol is enough to carry the content of the MAP_OPEN request and the content of the MAP_MT_FORWARD_SM_FOR_VGCS request in a single TC message, and b) the SMS Gateway MSC operator and the serving node (Anchor-MSC) operator agreed not to use the TCAP handshake countermeasure against SMS fraud for messages exchanged between their networks (see 3GPP TS 33.204 [34a]) then the TCAP handshake may be omitted. 23.7.1 Procedure in the SMS-GMSC The process starts when the SMS-GMSC receives an SC_RP_MT_DATA indication from a Service Centre. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The mobile terminated short message transfer for VGCS process in the SMS-GMSC is shown in figureÊ23.7/2. 23.7.2 Procedure in the Anchor MSC The process starts when the MSC receives a dialogue opening request with the application context shortMsgMT-Relay-VGCS-Context. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; The mobile terminated short message transfer for VGCS process in the Anchor MSC is shown in figure 23.7/3 Procedure MT_SM_VGCS_GMSC sheet 1: The decision box ""TCAP Handshake required"" takes the ""yes"" or ""no"" exit depending on agreements between the Serving MSC's operator and the SMS Gateway MSC's operator (see 3GPP TS 33.204 [34a]). FigureÊ23.7/2 (sheet 1 of 2): Process MT_SM_VGCS_GMSC FigureÊ23.7/2 (sheet 2 of 2): Process MT_SM_VGCS_GMSC FigureÊ23.7/3 (sheet 1 of 2): Process MT_SM_VGCS_Anchor MSC FigureÊ23.7/3 (sheet 2 of 2): Process MT_SM_VGCS_Anchor MSC 24 GPRS process description The MAP GPRS procedures are used for the Network Requested PDP-Context Activation procedures. The stage 2 specification for General Packet Radio Service (GPRS) is in 3GPP TS 23.060 [104]. 24.1 Procedure for retrieval of routeing information for GPRS 24.1.1 Process in the GGSN The MAP process in the GGSN to request routeing information for a network requested PDP context activation is shown in figure 24.1/2. The MAP process invokes macros not defined in this clause; the definition of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24.1.2 Process in the HLR The MAP process in the HLR to provide routing information for a network-requested PDP context activation is shown in figure 24.1/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. FigureÊ24.1/1: Process SRI_GPRS_GGSN FigureÊ24.1/2: Process SRI_GPRS_HLR 24.2 Procedure for reporting failure to establish a network requested PDP context 24.2.1 Process in the GGSN The MAP process in the GGSN to report the failure to establish a network requested PDP context is shown in figure 24.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24.2.2 Process in the HLR The MAP process in the HLR to handle a notification from the GGSN that a network requested PDP context could not be established is shown in figure 24.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check Indication see clause 25.2.1. FigureÊ24.2/1: Process Failure_Report_GGSN FigureÊ24.2/2: Process Failure_Report_HLR 24.3 Procedure for reporting that an MS has become reachable for GPRS 24.3.1 Process in the HLR The MAP process in the HLR to report that an MS is reachable for GPRS is shown in figure 24.3/1. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24.3.2 Process in the GGSN for Note Ms Present For Gprs The MAP process in the GGSN to handle a notification that the subscriber is present for GPRS again is shown in figure 24.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. FigureÊ24.3/1: Process Note_MS_Present_For_GPRS_HLR FigureÊ24.3/2: Process Note_MS_Present_For_GPRS_GGSN 24A CSE interrogation and control of subscriber data 24A.1 General The MAP procedures for interrogation and control of subscriber data are used to allow the CSE: - to retrieve subscriber data from the HLR; - to modify subscriber data in the HLR; - to receive notification from the HLR when there is a change in subscriber data; - to request information about the location of a subscriber from the HLR or the GMLC; - to request information about the state of a subscriber from the HLR. The following application context refers to a complex MAP user consisting of several processes: - anyTimeInfoHandlingContext This application context needs a co-ordinating process in the HLR. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; The Any Time Info Handling Co-ordinator process in the HLR is shown in figureÊ24A.1/1. FigureÊ24A.1/1: Process Co_ATIH_HLR 24A.2 Any Time Subscription Interrogation procedure 24A.2.1 General The message flow for successful retrieval of subscription information related to an any time subscription interrogation from the CAMEL server are shown in figure 24A.1/1. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this procedure (see 3GPP TS 23.278Ê[125]). FigureÊ24A.2/1: Message flow for any time subscription interrogation The following MAP service is used to retrieve requested information: MAP_ANY_TIME_SUBSCRIPTION_INTERROGATION see clauseÊ8.11.3."
"24A.2.2 Process in the gsmSCF The MAP process in the gsmSCF to obtain subscription information in response to a request from the application process in the gsmSCF is shown in figure 24A.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2 24A.2.3 Process in the HLR The MAP process in the HLR to provide subscription information in response to an interrogation from the CAMEL server is shown in figure 24A.2/3. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Check_Indication see clauseÊ25.2.2 If the MAP_ANY_TIME_SUBSCRIPTION_INTERROGATION service response cannot be carried in a single TC-Result component, it is carried in one or more TC-Result-NL components (each sent in a TC-CONTINUE), followed by a TC-Result-L component in a TC-END message. FigureÊ24A.2/2: Process ATSI_gsmSCF FigureÊ24A.2/3: Process ATSI_HLR 24A.3 Any Time Modification procedure 24A.3.1 General The message flow for successful modification of subscription information related to an any time modification request from the CAMEL server is shown in figure 24A.3/1 FigureÊ24A.3/1: Message flow for any time modification The following MAP service is used to modify subscription information: MAP_ANY_TIME_MODIFICATION see clauseÊ8.11.4. 24A.3.2 Process in the gsmSCF The MAP process in the gsmSCF to modify subscription information in response to a request from the application process in the gsmSCF is shown in figure 24A.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2 24A.3.3 Process in the HLR The MAP process in the HLR to modify subscriber information in response to a modification request from the CAMEL server is shown in figure 24A.3/3. The MAP process invokes a macro and a process not defined in this clause; the definitions of these can be found as follows: Check_Indication see clauseÊ25.2.2; Insert_Subs_Data_Stand_Alone_HLR see clauseÊ25.7.3; If the macro takes the OK exit, the MAP process waits for a service indication. If the MAP_ANY_TIME_MODIFICATION service response cannot be carried in a single TC-Result component, it is carried in one or more TC-Result-NL components (each sent in a TC-CONTINUE), followed by a TC-Result-L component in a TC-END message. If the serving node (VLR or SGSN) is to be updated after the modification, the MAP process creates an instance of the appropriate process (Insert_Subs_Data_Stand_Alone_HLR for VLR update, Insert_GPRS_Subs_Data_Stand_Alone_HLR for SGSN update). FigureÊ24A.3/2: Process ATM_gsmSCF FigureÊ24A.3/3: Process ATM_HLR 24A.4 Subscriber Data Modification Notification procedure 24A.4.1 General The Subscriber Data Modification Notification procedure is used to notify a gsmSCF about the modification of subscriber data. In an IP Multimedia Core Network, an IM-SSF can take on the role of a gsmSCF for this procedure. The stage 2 specification for Subscriber Data Modification Notification is in 3GPP TS 23.078Ê[98] and 3GPP TS 23.278Ê[125]. The interworking between the MAP signalling procedures and the Subscriber Data Modification Notification procedures for each entity (HLR, gsmSCF) is shown by the transfer of signals between these processes. The following services are used: FigureÊ24A.4/1: Message flow for subscriber data modification notification The following MAP service is used to send the notification to the gsmSCF: MAP_NOTE_SUBSCRIBER_DATA_MODIFIED see clauseÊ8.11.5. 24A.4.2 Process in the HLR The MAP process in the HLR to send modified data to the gsmSCF is shown in figure 24A.4/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. If the required information cannot be carried in a single MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service request, the HLR segments the information into two or more requests. The ""All Information Sent"" parameter is omitted from each request except the last. Sheet 2: If the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service request contained the ""All Information Sent"" parameter, the test ""All information sent"" takes the ""Yes"" exit. 24A.4.3 Process in the gsmSCF The MAP process in the gsmSCF to handle a notification to the gsmSCF of change of subscriber data is shown in figure 24A.4/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clauseÊ25.2.1 If the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indication contained the ""All Information Sent"" parameter, the test ""All information sent"" takes the ""Yes"" exit. If the test ""All information sent"" takes the ""No"" exit, the MAP process stores the data received in the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indication. If the test ""All information sent"" takes the ""Yes"" exit, the MAP process assembles the data received in all the MAP_NOTE_SUBSCRIBER_DATA_MODIFIED service indications received in the dialogue and sends the assembled data to the application process in the gsmSCF. Figure 24A.4/2 (sheet 1 of 2): Process NSDC_HLR Figure 24A.4/2 (sheet 2 of 2): Process NSDC_HLR Figure 24A.4/3: Process NSDC_gsmSCF 24A.5 Any Time Interrogation procedure 24A.5.1 General The message flows for successful retrieval of subscriber information related to an any time interrogation from the CAMEL server are shown in figure 24A.5/1 for interrogation directed to an HLR and figure 24A.5/2 for interrogation directed to a GMLC. 1) MAP_ANY_TIME_INTERROGATION_req/ind 2) MAP_PROVIDE_SUBSCRIBER_INFO_req/ind 3) MAP_PROVIDE_SUBSCRIBER_INFO_rsp/cnf 4) MAP_ANY_TIME_INTERROGATION_rsp/cnf FigureÊ24A.5/1: Message flow for any time interrogation (gsmSCF to HLR) The following MAP services are used to retrieve information about the status and/or location of a subscriber: MAP_ANY_TIME_INTERROGATION see clauseÊ8.11.1; MAP_PROVIDE_SUBSCRIBER_INFO see clauseÊ8.11.2. The HLR sends the MAP_PROVIDE_SUBSCRIBER_INFO request to the SGSN or the VLR, according to the domain for which the gsmSCF requested the information. 1) MAP_ANY_TIME_INTERROGATION_req/ind 2) MAP_ANY_TIME_INTERROGATION_rsp/cnf Figure 24A.5/2: Message flow for any time interrogation (gsmSCF to GMLC) The following MAP service is used to retrieve location information from a GMLC: MAP_ANY_TIME_INTERROGATION see clauseÊ8.11.1; In addition, the GMLC may use MAP Services specific to Location Services. 24A.5.2 Procedures in the gsmSCF The process in the gsmSCF to request information about the location and/or state of a subscriber from the HLR is shown in figure 24A.5/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. The process in the gsmSCF to request location information from the GMLC is shown in figure 24A.5/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 24A.5.3 Procedure in the HLR The MAP process in the HLR to provide subscriber information in response to an interrogation from the CAMEL server is shown in figure 24A.5/5. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clauseÊ25.2.2. 24A.5.4 Procedure in the GMLC The MAP process in the GMLC to provide location information in response to a request from the gsmSCF is shown in figure 24A.5/6. The MAP process invokes a macro not defined in this clause; the definition of this macro can be found as follows: Receive_Open_Ind see clauseÊ25.1.1. FigureÊ24A.5/3: Process ATI_To_HLR_gsmSCF FigureÊ24A.5/4: Process ATI_To_GMLC_gsmSCF FigureÊ24A.5/5 (sheet 1 of 2): Process ATI_HLR FigureÊ24A.5/5 (sheet 2 of 2): Process ATI_HLR FigureÊ24A.5/6: Process ATI_GMLC 24B Location Services process description 24B.1 Routeing information retrieval procedure for LCS 24B.1.1 General The message flow for successful retrieval of routeing information related to location services is shown in figure 24B.1/1. FigureÊ24B.1/1: Message flow for retrieval of routeing information for LCS The following MAP service is used to retrieve routeing information: MAP_SEND_ROUTING_INFO_FOR_LCS see clauseÊ13A.1. 24B.1.2 Process in the GMLC The MAP process in the GMLC to request routeing information for LCS is shown in figure 24B.1/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24B.1.3 Process in the HLR The MAP process in the HLR to handle a request for routeing information for LCS is shown in figure 24B.1/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. FigureÊ24B.1/2: Process SRI_LCS_GMLC FigureÊ24B.1/3: Process SRI_LCS_HLR 24B.2 Provide Subscriber Location procedure 24B.2.1 General The message flow for successful retrieval of the location information of a target MS related to location services is shown in figure 24B.1/1. FigureÊ24B.2/1: Message flow for retrieval of location information The following MAP service is used to retrieve location information: MAP_PROVIDE_SUBSCRIBER_LOCATION see clauseÊ13A.2. 24B.2.2 Process in the GMLC The MAP process in the GMLC to request location information from an MSC or an SGSN is shown in figure 24B.2/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24B.2.3 Process in the MSC The MAP process in the MSC to handle a request for location information from a GMLC is shown in figure 24B.2/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. 24B.2.4 Process in the SGSN The MAP process in the SGSN to handle a request for location information from a GMLC is shown in figure 24B.2/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. FigureÊ24B.2/2: Process PSL_GMLC FigureÊ24B.2/3: Process PSL_MSC FigureÊ24B.2/4: Process PSL_SGSN 24B.3 Subscriber Location Report procedure 24B.3.1 General The message flow for successful report of the location information of a target MS related to location services is shown in figure 24B.3/1. FigureÊ24B.3/1: Message flow for report of the location information The following MAP services are used to report location information: MAP_SUBSCRIBER_LOCATION_REPORT see clauseÊ13A.3. 24B.3.2 Process in the MSC The MAP process in the MSC to send a subscriber location report to the GMLC is shown in figure 24B.3/2. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24B.3.3 Process in the SGSN The MAP process in the SGSN to send a subscriber location report to the GMLC is shown in figure 24B.3/3. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Cnf see clauseÊ25.1.2; Check_Confirmation see clause 25.2.2. 24B.3.4 Process in the GMLC The MAP process in the GMLC to handle a subscriber location report is shown in figure 24B.3/4. The MAP process invokes macros not defined in this clause; the definitions of these macros can be found as follows: Receive_Open_Ind see clauseÊ25.1.1; Check_Indication see clause 25.2.1. Figure 24B.3/2: Process SLR_MSC Figure 24B.3/3: Process SLR_SGSN Figure 24B.3/4: Process SLR_GMLC 25 General macro description 25.1 MAP_OPEN handling macros 25.1.1 Macro Receive_Open_Ind This macro is used by a MAP service-user procedure when a peer entity requests opening of a dialogue. 25.1.2 Macro Receive_Open_Cnf This macro is used by a user procedure after it has requested opening of a dialogue towards a peer entity. Figure 25.1/1 (sheet 1 of 2): Macro Receive_Open_Ind Figure 25.1/1 (sheet 2 of 2): Macro Receive_Open_Ind FigureÊ25.1/2: Macro Receive_Open_Cnf FigureÊ25.1/3: Macro Check_Reference 25.2 Macros to check the content of indication and confirmation primitives 25.2.1 Macro Check_Indication This macro checks that an indication includes all the parameters required by the application, no more and no less, and that the parameters are all within the correct range. It does not handle syntax checking; that is part of the function of the MAP protocol machine. 25.2.2 Macro Check_Confirmation This macro checks whether a confirmation contains an error or a result, and if it contains a result whether the result is correctly formed. FigureÊ25.2/1: Macro Check_Indication FigureÊ25.2/2: Macro Check_Confirmation 25.3 The page and search macros 25.3.1 Macro PAGE_MSC This macro is called if an unstructured SS notification, a network-initiated unstructured SS request or a mobile terminating short message is to be delivered to the MS and the current location area identity of the MS is known in the VLR. If an MM-connection over the radio link already exists for the given IMSI, the MSC sets the access connection status according to the characteristics of the existing connection (i.e. RR-connection established, ciphering mode on/off, MM-connection existing and authenticated or not). If the MSC pages the MS and the VLR provided the TMSI, the MSC uses it to identify the MS at the radio interface; otherwise the MSC uses the IMSI. The MSC also uses the IMSI to determine the page group (see 3GPP TS 24.008 [35]). If the MS responds with a channel request containing an establishment cause which is not ""answer to paging"" the MSC sends a MAP_PAGE response primitive with user error Busy Subscriber. This gives priority to the mobile originating request. Alternatively, as an implementation option, the MSC may treat this as a response to paging, which gives priority to the mobile terminating request. If the paging is for MT SMS delivery and the VLR aborts the transaction before the MSC receives a response from the MS, the MSC aborts the transaction with the SMS-GMSC. 25.3.2 Macro Search_For_MS_MSC This macro is called if an unstructured SS notification, a network-initiated unstructured SS request or a mobile terminating short message is to be delivered to the MS and the current location area identity of the MS is not known in VLR. If an MM-connection over the radio link already exists for the given IMSI, the MSC returns a MAP_SEARCH_FOR_MS response containing the IMSI and current location area identification of the called MS to the VLR and sets the access connection status according to the characteristics of the existing connection (i.e. RR-connection established, ciphering mode on/off, MM-connection existing and authenticated or not). If the MSC pages the MS, the MSC uses the IMSI to identify the subscriber and the page group (see 3GPP TS 24.008 [35]). If the MS responds with a channel request containing an establishment cause which is not ""answer to paging"" the MSC sends a MAP_SEARCH_FOR_MS response with user error Busy Subscriber. This gives priority to the mobile originating request. Alternatively, as an implementation option, the MSC may treat this as a response to paging, which gives priority to the mobile terminating request. If the paging is for MT SMS delivery and the VLR aborts the transaction before the MSC receives a response from the MS, the MSC aborts the transaction with the SMS-GMSC. FigureÊ25.3/1: Macro Page_MSC FigureÊ25.3/2: Macro Search_for_MS_MSC 25.4 Macros for handling an Access Request These macros are invoked when a MS accesses the network, e.g. to submit an MO short message or when responding to paging. The macros handle identification and authentication of the mobile subscriber as well as invocation of security related features (see 3GPP TS 42.009 [6]). 25.4.1 Macro Process_Access_Request_MSC Sheet 1: The MAP_PROCESS_ACCESS_REQUEST request includes the following parameters: - the received subscriber identification (IMSI, TMSI); - the CM service type, indicating the type of request; - the status of the access connection, i.e. whether a connection to this MS already exists and if so, whether it is already authenticated and ciphered; - the current location area id of the MS; and - the CKSN received from the MS. Sheet 2, sheet 3: If the MSC receives an A_SETUP indication while it is waiting for further instructions from the VLR or for the acknowledgment of TMSI reallocation from the MS, the MSC saves the setup request for processing after control has returned from the macro Process_Access_Request_MSC to the calling process. Sheet 3: When the MSC is waiting for a possible instruction to allocate a new TMSI, a MAP_DELIMITER indication indicates that TMSI reallocation is not required. Sheet 3: If the MS sends a TMSI reallocation failure in response to the TMSI reallocation command, the MSC takes the OK exit; the VLR treats the lack of response as a provider error (see macro Process_Access_Request_VLR). 25.4.2 Macro Process_Access_Request_VLR Sheet 3: If the MSC does not send a positive response to the MAP_FORWARD_NEW_TMSI request, this is treated as a MAP_FORWARD_NEW_TMSI confirmation containing a provider error. The Macro takes the Error exit. If TMSI reallocation does not succeed, the old TMSI is frozen, to prevent it from being reallocated. In this case, both old and new TMSIs are regarded as valid. 25.4.3 Macro Obtain_Identity_VLR This macro is invoked by the macro Process_Access_Request_VLR if the subscriber's identity is not known in the VLR. It is an operator option to allow or prevent retrieval of the IMSI without encryption. 25.4.4 Process Update_Location_Child_VLR This process is started when the subscriber successfully accesses the network, e.g. for mobile originated short message submission, response to paging or supplementary services handling. The procedure Notify_gsmSCF is specified in 3GPP TS 23.078. FigureÊ25.4/1 (sheet 1 of 3): Macro Process_Access_Request_MSC FigureÊ25.4/1 (sheet 2 of 3): Macro Process_Access_Request_MSC FigureÊ25.4/1 (sheet 3 of 3): Macro Process_Access_Request_MSC FigureÊ25.4/2 (sheet 1 of 3): Macro Process_Access_Request_VLR FigureÊ25.4/2 (sheet 2 of 3): Macro Process_Access_Request_VLR FigureÊ25.4/2 (sheet 3 of 3): Macro Process_Access_Request_VLR FigureÊ25.4/3: Macro Obtain_Identity_VLR FigureÊ25.4/4 (sheet 1 of 2): Process Update_Location_Child_VLR FigureÊ25.4/4 (sheet 2 of 2): Process Update_Location_Child_VLR 25.5 Authentication macros and processes The following macros are used in the network in order to enable authentication of a mobile subscriber. 25.5.1 Macro Authenticate_MSC This macro is used by the MSC to relay a request for authentication transparently from the VLR to the MS, wait for a response from the MS and relay the response from the MS back to the VLR. 25.5.2 Macro Authenticate_VLR This macro is used by the VLR to control the authentication of a subscriber. Sheet 1: The test ""Received SRES=Expected SRES"" indicates: - a comparison of the Signed RESult received from the MS with the Signed RESult received from the HLR, if GSM authentication is used (see 3GPP TS 43.020 [24]), or - a comparison of the RESult received from the MS with the expected RESult received from the HLR, if UMTS authentication is used (see 3GPP TS 33.102). 25.5.3 Macro Obtain_Authent_Params_VLR This macro is used by the VLR to request authentication vectors from the HLR. Sheet 1, sheet 2, sheet 3: It is an operator option whether to allow the re-use of old authentication triplets. Sheet 2, sheet 3: Old UMTS quintuplets shall not be re-used. Sheet 2: if the VLR requests more authentication vectors in the same dialogue, the subsequent MAP_SEND_AUTHENTIFICATION_INFO request has no parameters. 25.5.4 Process Obtain_Authentication_Sets_VLR This process is initiated by the VLR to fetch authentication vectors from a subscriber's HLR independently of any other processing. 25.5.5 Process Obtain_Authent_Sets_SGSN The procedure for authentication when the serving node is an SGSN is described in 3GPP TS 23.060 [104] and 3GPP TS 24.008 [35]. This Process is used by the SGSN to request authentication vectors from the HLR. Sheet 1, sheet 2: It is an operator option whether to allow the re-use of old authentication triplets. Sheet 2: Old UMTS quintuplets shall not be re-used. 25.5.6 Process Obtain_Authent_Sets_HLR This process is used to provide authentication vectors (triplets or quintuplets) in response to a request from a VLR or an SGSN. Upon receipt of an authentication information request for a UMTS subscriber, the HLR shall return authentication quintuplets. If the user is a GSM subscriber, the HLR shall return authentication triplets. 25.5.7 Authentication Failure Reporting 25.5.7.1 General The Authentication Failure Report procedure is used to notify an HLR about the occurrence of an authentication failure in the SGSN or VLR. The message flows for this procedure are shown in figuresÊ25.5/7& 25.5/8. FigureÊ25.5/7: Message Flow for Authentication Failure Report Ð VLR to HLR FigureÊ25.5/8: Message Flow for Authentication Failure Report Ð SGSN to HLR 25.5.7.2 Process in the VLR 25.5.7.3 Process in the SGSN 25.5.7.4 Process in the HLR FigureÊ25.5/1: Macro Authenticate_MSC FigureÊ25.5/2 (sheet 1 of 2): Macro Authenticate_VLR FigureÊ25.5/2 (sheet 2 of 2): Macro Authenticate_VLR FigureÊ25.5/3 (sheet 1 of 3): Macro Obtain_Authent_Params_VLR FigureÊ25.5/3 (sheet 2 of 3): Macro Obtain_Authent_Params_VLR FigureÊ25.5/3 (sheet 3 of 3): Macro Obtain_Authent_Params_VLR FigureÊ25.5/4: Process Obtain_Authent_Sets_VLR FigureÊ25.5/5 (sheet 1 of 2): Process Obtain_Authent_Sets_SGSN FigureÊ25.5/5 (sheet 2 of 2): Process Obtain_Authent_Sets_SGSN FigureÊ25.5/6 (sheet 1 of 2): Process Obtain_Authent_Sets_HLR FigureÊ25.5/6 (sheet 2 of 2): Process Obtain_Authent_Sets_HLR FigureÊ25.5/7: Procedure Check_Available_Vectors FigureÊ25.5/9: Process Report_Authentication_Failure_VLR FigureÊ25.5/10: Process Report_Authentication_Failure_SGSN FigureÊ25.5/11: Process Note_Authentication_Failure_HLR 25.6 IMEI Handling Macros The following macros are used in the network in order to enable handling and checking of the mobile equipment identity. 25.6.1 Macro Check_IMEI_MSC This macro is used by the MSC to receive a request from the VLR, relay it to the EIR, and pass the result from the EIR back to the VLR. Sheet 1: If the dialogue with the EIR drops back to a previous protocol version and the EIR returned an error, the MSC relays the error to the VLR in the MAP_CHECK_IMEI response. If the dialogue with the EIR failed, or the EIR returned a badly formed result, the MSC sends a System Failure error to the VLR in the MAP_CHECK_IMEI response. 25.6.2 Macro Check_IMEI_VLR This macro is used by the VLR to control the check of a mobile equipment's IMEI. It may also be used to request the BMUEF from the EIR. 25.6.3 Process Check_IMEI_SGSN This process is used by the SGSN to control the check of a mobile equipment's IMEI. It may also be used to request the BMUEF from the EIR. 25.6.4 Process Check_IMEI_EIR This process is used by the EIR to obtain the status of a mobile equipment, upon request from the MSC or from the SGSN. It may also be used to obtain the BMUEF. 25.6.5 Macro Obtain_IMEI_MSC This macro is used by the MSC to respond to a request from the VLR to provide the IMEI. 25.6.6 Macro Obtain_IMEI_VLR This macro is used by the VLR to obtain the IMEI from the MSC. FigureÊ25.6/1 (sheet 1 of 2): Macro Check_IMEI_MSC FigureÊ25.6/1 (sheet 2 of 2): Macro Check_IMEI_MSC FigureÊ25.6/2: Macro Check_IMEI_VLR FigureÊ25.6/3 (sheet 1 of 2): Process Check_IMEI_SGSN FigureÊ25.6/3 (sheet 2 of 2): Process Check_IMEI_SGSN FigureÊ25.6/4: Process Check_IMEI_EIR FigureÊ25.6/5: Macro Obtain_IMEI_MSC FigureÊ25.6/6: Macro Obtain_IMEI_VLR 25.7 Insert Subscriber Data macros and processes 25.7.1 Macro Insert_Subs_Data_VLR This macro is used by any procedure in the VLR that triggers the reception of subscriber data (e.g. Update Location, Update VCSG Location or Restore Data). 25.7.2 Macro Insert_Subs_Data_SGSN This macro is used by any procedure that triggers the reception of subscriber data (e.g. Update GPRS Location or Update VCSG Location ). 25.7.3 Process Insert_Subs_Data_Stand_Alone_HLR This process is used by HLR to transfer subscriber data to the VLR in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of subscriber data is performed either by the operator or by the subscriber and this change has to be reported to the VLR. Sheet 1: The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. Sheet 1, sheet 2: If the VLR has indicated that it does not support a service or feature (e.g. Closed User Group or Advice Of Charge Charging Level) which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restriction Due To Unsupported Feature flag to roaming restricted and sends Roaming Restriction Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 1, sheet 2: If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 2: It is an operator option whether to repeat the download of subscriber data if the VLR returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the VLR. If subscriber data for CAMEL Phase 2 or later services are sent to a VLR which does not support the appropriate phase of CAMEL, the service behaviour may be unpredictable or incorrect. The HLR should therefore ensure that at the conclusion of a stand alone Insert Subscriber data procedure the data in the VLR do not require a capability that the VLR does not have. Possible mechanisms to ensure this are described in 3GPP TS 23.078Ê[98]. The HLR should send a Forwarded-to number which is not in E.164 international format to the VLR only when the HLR has ascertained that the VLR supports CAMEL Phase 2 or later. Thus, the ISD message containing the Forwarded-to number which is not in E.164 international format shall be sent to the VLR only if the HLR previously received confirmation from the VLR at Location Update that CAMEL Phase 2 or later is supported. 25.7.4 Process Insert_GPRS_Subs_Data_Stand_Alone_HLR This process is used by the HLR to transfer subscriber data from the HLR to the SGSN in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of subscriber data is performed either by the operator or by the subscriber and this change has to be reported to the SGSN. Sheet 1: The HLR may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. Sheet 1, sheet 2: If the SGSN has indicated that it does not support a service or feature which the HLR operator regards as essential for the subscriber, the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit; the HLR sets the Roaming Restricted In SGSN Due To Unsupported Feature flag to roaming restricted and sends Roaming Restricted In SGSN Due To Unsupported Feature in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 1, sheet 2: If the HLR operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_GPRS_Subs_Data_Cnf takes the Replace_Service exit, the HLR sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 2: It is an operator option whether to repeat the download of subscriber data if the SGSN returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the SGSN. 25.7.5 Macro Wait_for_Insert_Subs_Data_Cnf This macro is used by any process or macro that describes the handling in the HLR of the transfer of subscriber data to the VLR (e.g. Update Location or Restore Data). 25.7.6 Macro Wait_for_Insert_GPRS_Subs_Data_Cnf This macro is used by any process or macro that describes the handling in the HLR of the transfer of subscriber data to the SGSN (e.g. Update GPRS Location). 25.7.7 Process Send_Insert_Subs_Data_HLR This process is used by any process or macro in the HLR where a MAP_INSERT_SUBSCRIBER_DATA request is sent to the VLR or to the SGSN. 25.7.8 Process Insert_VCSG_Subs_Data_Stand_Alone_CSS This process is used by the CSS to transfer CSG subscriber data from the CSS to the VLR or the SGSN in a stand alone mode, i.e. in a separate dialogue. This is done whenever a change of CSG subscriber data in the CSS is performed either by the operator or by the subscriber and this change has to be reported to the VLR or the SGSN. Sheet 1: The CSS may wait for each MAP_INSERT_SUBSCRIBER_DATA request to be acknowledged before it sends the next request, or it may handle the requests and the confirmations in parallel. Sheet 1, sheet 2: If the VLR or the SGSN has indicated that it does not support a service or feature which the CSS operator regards as essential for the subscriber, the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit. Sheet 1, sheet 2: If the CSS operator does not regard the unsupported service or feature as essential for the subscriber but the macro Wait_for_Insert_VCSG_Subs_Data_Cnf takes the Replace_Service exit, the CSS sends the data for a replacement service in a subsequent MAP_INSERT_SUBSCRIBER_DATA request. Sheet 2: It is an operator option whether to repeat the download of CSG subscriber data if the VLR or theSGSN returns an error response. The number of repeat attempts and the interval between them is also an operator option, depending on the error response from the VLR or the SGSN. 25.7.9 Macro Wait_for_Insert_VCSG_Subs_Data_Cnf This macro is used by any process or macro that describes the handling in the CSS of the transfer of CSG subscriber data to the VLR or to the SGSN (e.g. Update VCSG Location). 25.7.10 Process Send_Insert_VCSG_Subs_Data_CSS This process is used by any process or macro in the CSS where a MAP_INSERT_SUBSCRIBER_DATA request is sent to the VLR or to the SGSN. FigureÊ25.7/1: Macro Insert_Subs_Data_VLR FigureÊ25.7/2: Macro Insert_Subs_Data_SGSN FigureÊ25.7/3 (sheet 1 of 2): Process Insert_Subs_Data_Stand_Alone_HLR FigureÊ25.7/3 (sheet 2 of 2): Process Insert_Subs_Data_Stand_Alone_HLR FigureÊ25.7/4 (sheet 1 of 2): Process Insert_GPRS_Subs_Data_Stand_Alone_HLR FigureÊ25.7/4 (sheet 2 of 2): Process Insert_GPRS_Subs_Data_Stand_Alone_HLR FigureÊ25.7/5: Macro Wait_for_Insert_Subs_Data_Cnf FigureÊ25.7/6: Macro Wait_for_Insert_GPRS_Subs_Data_Cnf FigureÊ25.7/7: Process Send_Insert_Subs_Data_HLR Figure 25.7/8 (sheet 1 of 2): Process Insert_VCSG_Subs_Data_Stand_Alone_CSS Figure 25.7/8 (sheet 2 of 2): Process Insert_VCSG_Subs_Data_Stand_Alone_CSS Figure 25.7/9: Macro Wait_for_Insert_VCSG_Subs_Data_Cnf Figure 25.7/10: Process Send_Insert_VCSG_Subs_Data_CSS 25.8 Request IMSI Macros 25.8.1 Macro Obtain_IMSI_MSC This macro describes the handling of the request received from the VLR to provide the IMSI of a subscriber (e.g. at Location Updating). 25.8.2 Macro Obtain_IMSI_VLR This macro describes the way VLR requests the MSC the IMSI of a subscriber (e.g. at Location Updating). FigureÊ25.8/1: Macro Obtain_IMSI_MSC FigureÊ25.8/2: Macro Obtain_IMSI_VLR 25.9 Tracing macros 25.9.1 Macro Trace_Subscriber_Activity_MSC This macro shows the handling in the MSC for a request from the VLR to trace the activity of a subscriber. 25.9.2 Macro Trace_Subscriber_Activity_VLR This macro is called during the handling of subscriber activity in the VLR to activate tracing if necessary. 25.9.3 Macro Trace_Subscriber_Activity_SGSN This macro is called during the handling of subscriber activity in the SGSN to activate tracing if necessary. 25.9.4 Macro Activate_Tracing_VLR This macro shows the handling in the VLR for a request from the HLR to activate tracing for a subscriber. 25.9.5 Macro Activate_Tracing_SGSN This macro shows the handling in the SGSN for a request from the HLR to activate tracing for a subscriber. 25.9.6 Macro Control_Tracing_With_VLR_HLR This macro shows the handling in the HLR to activate tracing in the VLR if it is required during a dialogue between the VLR and the HLR 25.9.7 Macro Control_Tracing_With_SGSN_HLR This macro shows the handling in the HLR to activate tracing in the SGSN if it is required during a dialogue between the SGSN and the HLR FigureÊ25.9/1: Macro Trace_Subscriber_Activity_MSC FigureÊ25.9/2: Macro Trace_Subscriber_Activity_VLR FigureÊ25.9/3: Macro Trace_Subscriber_Activity_SGSN FigureÊ25.9/4: Macro Activate_Tracing_VLR FigureÊ25.9/5: Macro Activate_Tracing_SGSN FigureÊ25.9/6: Macro Control_Tracing_With_VLR_HLR FigureÊ25.9/7: Macro Control_Tracing_With_SGSN_HLR 25.10 Short Message Alert procedures 25.10.1 Process Subscriber_Present_VLR The VLR invokes the process Subscriber_Present_VLR when the mobile subscriber becomes active. The general description of the short message alert procedures is in clauseÊ23.4 of the present document. 25.10.2 Process SubscriberPresent_SGSN The SGSN invokes the process Subscriber_Present_SGSN when it receives a Page response, a GPRS Attach request or a Routing area update request message (3GPP TS 24.008 [35]). The general description of the short message alert procedures is in clauseÊ23.4 of the present document. 25.10.3 Macro Alert_Service_Centre_HLR The HLR invokes the macro Alert_Service_Centre_HLR when Service Centre(s) are to be alerted. 25.10.4 Process Alert_SC_HLR It is an operator option to resend the MAP_ALERT_SERVICE_CENTRE request to the SMS-IWMSC if the alert is unsuccessful. The number of repeat attempts and the interval between them is also an operator option. The service centre address should be purged from the MWD list if the alert is consistently unsuccessful. FigureÊ25.10/1: Process Subscriber_Present_VLR FigureÊ25.10/2: Process Subscriber_Present_SGSN FigureÊ25.10/3: Macro Alert_Service_Centre_HLR FigureÊ25.10/4: Process Alert_SC_HLR Annex A (informative): ASN.1 Cross-reference listing and fully expanded sources The ASN.1 Cross-reference listing and the fully expanded ASN.1 sources of the MAP protocol are provided for information at http://www.3gpp.org/ftp/Specs/archive/29_series/29.002/ASN.1/ Annex B (informative): Void Annex C (informative): Message Segmentation Mechanisms Various segmentation mechanisms are in use to overcome the problem where a MAP parameter carried in an Invoke, Result (or Error) component is too long to fit into a single SCCP UDT message. These mechanisms are: C.1 SCCP segmentation Instead of one UDT message several XUDT messages are used according to Signalling Connection Control Part, Signalling System no. 7 ITU-T recommendation (07/96) Q.711 to Q.716 ('White Book SCCP'). This mechanism may be used for all MAP messages. If no segmentation mechanism at the TCAP or MAP level is available, this is the only remaining possibility. This mechanism has no impact on the MAP provider level and above; the MAP provider sees the parameter as being sent in a single segment. It should be noted that not all SCCP transit nodes (world wide) currently support the transfer of XUDT messages. Therefore XUDT messages may be lost without notice, depending on the route the message takes. The routes which successive messages take between two end points can differ because of load balancing. It is therefore recommended that this mechanism is used only for: a) messages which do not cross PLMN boundaries (when the PLMN operator ensures that all SCCP transit nodes within his PLMN support White Book SCCP) b) messages with low priority i.e. loss of the message does not result in serious misoperation. It should be noted that the decision whether or not a message crosses PLMN boundaries needs to be taken at the MAP application level; it is therefore based on the message's operation code rather than on the SCCP called party address, i.e. only messages which never cross PLMN boundaries due to the type of message (SendIdentification, SendRoutingInfo without OR, AnyTimeInterrogation, ...) can be regarded as not crossing PLMN boundaries. C.2 TCAP segmentation At the TCAP level the following segmentation mechanisms are available: C.2.1 Empty Begin In a dialogue with AC version >1 the first forward message (Begin) must contain a Dialogue Portion. Instead of sending the Dialogue Portion and the Component Portion in the first forward message, an empty Begin (i.e. without a Component Portion) is sent, followed (after successful dialogue establishment) by a Continue message which can carry a longer Component Portion since no Dialogue Portion is present in the second forward message. C.2.2 Empty Continue In a dialogue with AC version >1 the first backward message (Continue / End) must contain a Dialogue Portion. Instead of sending the Dialogue Portion and the Component Portion in the first backward message, an empty Continue (i.e. without a Component Portion) is sent, followed by a Continue/End message which can carry a longer Component Portion since no Dialogue Portion is present in the second backward message. C.2.3 TC-Result-NL A Result component may be segmented into one or several Result-Not-Last components followed by a Result-Last component. As specified in clause 15.6.3, the MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the result of the associated operation. Note that this segmentation mechanism runs the risk that the message carrying the Result-Last component arrives before the message carrying a Result-Not-Last component which results in failure. The use of SCCP class 1 ""Sequence guaranteed"", which raises the chance of in sequence delivery, is recommended. C.3 MAP Segmentation At the MAP level the following segmentation mechanisms are available: C.3.1 Invoke without explicit indication An Invoke component may be segmented into several Invoke components. These may be sent in burst mode (in which case SCCP class 1 is recommended) or in acknowledged mode. The receiving node does not get an indication of whether or not more segments will be received, so it must not close the dialogue. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the invoke of the associated operation. C.3.2 Invoke with explicit indication An Invoke component may be segmented into several Invoke components sent in acknowledged mode. Each component contains at the MAP level an indication of whether or not subsequent components will follow. The receiving node terminates the dialogue when the last component is received. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the invoke of the associated operation. C.3.3 Result A Result (last) component may be segmented into several Result (last) components sent in acknowledged mode where a new (empty) Invoke component serves as an acknowledgment. The last segment is not acknowledged. The MAP user parameter shall be split so that each segment is compatible with the type defined for the parameter of the result of the associated operation. The following tables show the applicability of the mechanisms described above: AC Version 4: Parameter SCCP-segmentation Empty Begin Empty Continue TC-Result-NL Invoke without indication Invoke with indication Result ResumeCallHandlingArg allowed not allowed n.a. n.a. not allowed recommended n.a. AC Version 3: Parameter SCCP-segmentation Empty Begin Empty Continue TC-Result-NL Invoke without indication Invoke with indication Result InsertSubscriberDataArg risky not allowed n.a. n.a. recommended n.a. n.a. SendIdentificationRes allowed n.a. not allowed not allowed n.a. n.a. recommended PrepareHO-Arg allowed not allowed n.a. n.a. not allowed n.a. n.a. PrepareHO-Res allowed n.a. recommended not recommended n.a. n.a. not allowed ProcessAccessSignalling-Arg allowed n.a. n.a. n.a. not allowed n.a. n.a. ForwardAccessSignalling-Arg allowed n.a. n.a. n.a. not allowed n.a. n.a. PrepareSubsequentHO-Arg allowed n.a. n.a. n.a. not allowed n.a. n.a. PrepareSubsequentHO-Res allowed n.a."
"n.a not recommended n.a. n.a. not allowed SendAuthenticationInfoRes risky n.a. not allowed not allowed n.a. n.a. recommended ProvideSubscriberInfoRes allowed n.a. not allowed not recommended n.a. n.a. not allowed AnyTimeInterrogationRes allowed n.a. not allowed not recommended n.a. n.a. not allowed AnyTimeModificationRes allowed n.a. not allowed recommended n.a. n.a. not allowed AnyTimeSubscriptionInterrogationRes allowed n.a. not allowed recommended n.a. n.a. not allowed noteSubscriberDataModifiedArg allowed not allowed n.a. n.a. not allowed recommended n.a. SendRoutingInfoRes allowed n.a. not allowed recommended n.a. n.a. not allowed MO-ForwardSM-Arg risky recommended n.a. n.a. not allowed n.a. n.a. MT-ForwardSM-Arg risky recommended n.a. n.a. not allowed n.a. n.a. AC Version 2: Parameter SCCP-segmentation Empty Begin Empty Continue TC-Result-NL Invoke without indication Invoke with indication Result InsertSubscriberDataArg risky not allowed not allowed n.a. recommended n.a. n.a. SendIdentificationRes allowed n.a. not allowed not recommended n.a. n.a. not allowed SendAuthenticationInfoRes risky n.a. not allowed not recommended n.a. n.a. not allowed ForwardSM-Arg risky recommended n.a. n.a. not allowed n.a. n.a. PrepareHO-Res allowed n.a. recommended not recommended n.a. n.a. not allowed AC Version 1: Parameter SCCP-segmentation Empty Begin Empty Continue TC-Result-NL Invoke without indication Invoke with indication Result InsertSubscriberDataArg risky n.a. n.a. n.a. recommended n.a. n.a. SentParameterList risky n.a. n.a. recommended n.a. n.a. not allowed In the tables above the keywords ""recommended"", ""allowed"", ""risky"", ""not recommended"", ""not allowed"" and ""n.a."" are used as follows: ""recommended"" indicates that the normative part of this specification explicitly specifies the use of this mechanism for the parameter in question; ""allowed"" indicates that the normative part of this specification allows the use of this mechanism for the sending node and mandates support of this mechanism for the receiving node; ""risky"" indicates that the mechanism is ""allowed"".However, the use of this mechanism for the parameter in question may result in serious misoperation because SCCP transit nodes are not guaranteed to support XUDT messages. ""not recommended"" indicates that the normative part of this specification does not explicitly specify the use of this mechanism for the parameter in question. ""not allowed"" indicates that the normative part of this specification implicitly prohibits the use of this mechanism for the parameter in question. ""n.a."" indicates that the mechanism is not applicable for the parameter in question. Annex D (informative): Void Annex E (informative): Change History Date TSGÊ# TSG Doc. CR Rev Subject/Comment New 04 N2-99227 A002 3 Use of E interface 3.1.0 04 N2-99578 A003 Introduction of TIF-CSI for Call Deflection 3.1.0 04 N2-99233 A004 Clarification in ASN.1 encoding of O-CSI and T-CSI 3.1.0 04 N2-99269 A005 Introduction of MSISDN in USSD operation 3.1.0 04 N2-99650 A006 Modification of the O-CSI ASN.1 structure 3.1.0 04 N2-99250 A007 Adding of MAP_DELIMITER_req to the Status report operation 3.1.0 04 N2-99628 A008 Correction to the Purge MS ""Detailed procedure in the HLR"" 3.1.0 04 N2-99677 A009 Adding of MNP-indicator to the SRI ack 3.1.0 04 N2-99228 A010 New subscription options for call forwarding 3.1.0 04 N2-99585 A011 Adding the support of ANSI SCCP which is required in North America (World Zone 1) 3.1.0 04 N2-99515 A012 Introduction of 3-digit MNCs correction 3.1.0 04 N2-99520 A013 Export of NAEA-CIC 3.1.0 04 N2-99548 A014 Clarification to text to identify how the LSA data relevant in the current VPLMN can be determined 3.1.0 04 3C99-468 A015 Alignment with 04.80 3.1.0 04 N2-99519 A016 VBS data 3.1.0 04 N2-99461 A017 Introduction of Data Missing error to the Resume Call Handling 3.1.0 04 N2-99583 A018 Removal of 3-digit MNCs 3.1.0 04 N2-99676 A019 Corrections of mapping from MAP service to TC service 3.1.0 04 3C99-206 A020 Introduction of UUS service to Resume Call Handling 3.1.0 05 N2-99906 021 Clarification on VLR CAMEL Subscription Info 3.2.0 05 N2-99908 022 Clarification on DestinationNumberCriteria 3.2.0 05 N2-99910 023 Removal of TDP-Criteria from RCH 3.2.0 05 N2-99934 025 Various corrections related to GGSN-HLR Interface. 3.2.0 05 N2-99936 034 Update Location handling for GPRS-only subscription 3.2.0 05 N2-99938 035 Correction of OP & AC definitions for NoteMS-PresentForGPRS 3.2.0 05 N2-99952 036 Removal of redundant information from RCH 3.2.0 05 N2-99956 026 OR capability IE in PRN 3.2.0 05 N2-99964 024 1 GMSC-CAMEL phase 2 support IE in PRN 3.2.0 05 N2-99A19 028 Alignment of 29.002 with 02.67 3.2.0 05 N2-99A45 029 1 Non-CAMEL IST implementation 3.2.0 05 N2-99B57 027 2 Addition of the information elements and the ASN.1 definitions for Pre-paging 3.2.0 05 N2-99C27 042 Clarification on 'Supported CAMEL Phases' in ISD ack 3.2.0 05 N2-99C78 044 Editing error correction on VLR capabilities 3.2.0 05 N2-99D06 043 1 Addition of exception handling to the CancellationType 3.2.0 05 N2-99D33 046 Clarification of LR-REJECT cause corresponding to RoamingRestrictionDueTo UnsupportedFeature 3.2.0 05 N2-99D35 047 Clarification of returning the MSISDN in SRIack 3.2.0 06 N2-99G06 033 3 Introduction of the Super-Charger Concept in TS 29.002 3.3.0 06 N2-99G18 032 2 Introduction of White Book SCCP in MAP 3.3.0 06 N2-99G50 070 Addition of GGSN number for the SRIforGPRS 3.3.0 06 N2-99J88 075 1 Introduction of Follow Me 3.3.0 06 N2-99K12 077 Use of SSN for GPRS 3.3.0 06 N2-99K24 069 Correction of the USSD procedure in the HLR. 3.3.0 06 N2-99K52 060 1 MAP Impacts for Location Services (LCS) 3.3.0 06 N2-99K58 045 4 Authentication Enhancements 3.3.0 06 N2-99K60 050 5 QoS-Subscribed field modification 3.3.0 06 N2-99L20 073 1 Introduction of CAMEL Phase 3 in 3GPP TS 29.002 3.3.0 06 N2-99J52 074 Restructuring of MAP Location Management Procedures for the Circuit Switched Domain 3.3.0 06 N2-99J92 068 Update of SDLs to support Super-Charger 3.3.0 New version created to fix a CR implementation error 3.3.1 07 N2B000436 048 5 Introduction of Multicall 3.4.0 07 N2B000319 059 1 Alternative solution for ALR 3.4.0 07 N2B000461 063 4 MNP Database Mismatch 3.4.0 07 N2B000375 066 5 Addition of the FTN-AddressString 3.4.0 07 N2B000456 079 4 Correction of SS Invocation Notification for CCBS 3.4.0 07 N2A000023 080 Corrections to ATSI, ATM, NCSD 3.4.0 07 N2B000046 083 Privacy notification/verification for call related privacy class 3.4.0 07 N2B000142 084 2 Addition of CS Allocation/retention priority 3.4.0 07 N2B000144 086 1 Editorial cleanup of 29.002 3.4.0 07 N2B000100 087 Correction of LSA information 3.4.0 07 N2B000067 089 Security interworking between release 99 and pre-99 MSC/VLRs 3.4.0 07 N2B000113 090 1 Improving GPRS charging efficiency 3.4.0 07 N2B000120 094 2 QoS-Subscribed field enhancements 3.4.0 07 N2B000322 095 1 RANAP support on the E-interface 3.4.0 07 N2B000191 099 UMTS Authentication 3.4.0 07 N2B000466 100 5 Support of 3G Handover, including Multicall 3.4.0 07 N2B000372 101 1 Introduction of Service Area Identification 3.4.0 07 N2B000380 102 2 Clarification on Authentication Info Retrieval 3.4.0 07 N2B000330 103 1 Addition of UMTS security to MAP B interface 3.4.0 07 N2B000244 104 Re-Synchronisation Info 3.4.0 07 N2B000324 105 1 Introduction of additional service parameters for inter-system handover 3.4.0 07 N2B000281 107 Removal of architectural information from clause 4 3.4.0 07 N2-000454 110 1 Introduction of Authentication Failure Report 3.4.0 07 N2B000357 111 Use of MAP private extensions to implement region-specific requirements 3.4.0 07 N2B000470 112 Prioritisation of MAP application context related to VGCS/VBS 3.4.0 07 N2B000472 113 Correction of SS-Codes for LCS 3.4.0 08 N4-000098 115 1 Minor corrections to CAMEL3 NSDC/ATM/ATSI information flows 3.5.0 08 N4-000094 117 1 Using DSD to delete CCBS-B from the subscriber 3.5.0 08 N4-000089 118 1 Indication in PRN of support of Long FTNs 3.5.0 08 N4-000073 120 1 QoS-Subscribed field enhancements 3.5.0 08 N4-000050 121 Correction of introduction of additional service parameters for inter-system handover 3.5.0 08 N4-000100 122 2 Proposed information flow on NSDC 3.5.0 08 N4-000321 124 3 CAMEL Subscription Info 3.5.0 08 N4-000068 125 Clarification to GMLC List definition 3.5.0 08 N4-000320 127 1 Optionality of parameters in d-csi and in sms-csi 3.5.0 08 N4-000209 130 Version 3 tags for handover messages 3.5.0 08 N4-000211 132 Correction of version handling at dialogue establishment 3.5.0 08 N4-000357 133 1 Various corrections and/or cleanup to 29.002 3.5.0 08 N4-000217 134 Correction of errors in Figure 25.1/1: Macro Receive_Open_Ind 3.5.0 08 N4-000326 135 1 Addition of charging characteristics per PDP context 3.5.0 08 N4-000264 138 Clarification of SAI-ack segmentation procedure 3.5.0 08 N4-000392 139 1 Indication of unsupported position method 3.5.0 08 N4-000276 141 Clarification for ReportSM-DeliveryStatus operation 3.5.0 08 N4-000349 142 1 Addition of a parameter in the subsequent Handover from UMTS to GSM with Multicall 3.5.0 08 N4-000278 143 Editorial correction to MSC-A handover SDLs 3.5.0 08 N4-000378 144 1 Use of NAM parameter with MAP-INSERT-SUBSCRIBER-DATA service between HLR and SGSN 3.5.0 08 N4-000293 145 Addition of state attributes in Forward group call signalling 3.5.0 08 N4-000294 146 New user error 'target cell outside group call area' in MAP Prepare Handover message 3.5.0 08 N4-000374 149 Correction to the description of MAP-MO-Forward-Short-Message service 3.5.0 08 N4-000407 148 4 Changes to MAP for secure transport of MAP messages 4.0.0 08 Version 4.0.1 created to allow inclusion of automatic update of Annexes A and B and of clause 17 4.0.1 09 N4-000543 152 1 Clarifications for secure MAP transport 4.1.0 09 N4-000539 153 1 Generalization of version handling text in clause 18.2.4 4.1.0 09 N4-000491 158 Deletion of informative Annexe C 4.1.0 09 N4-000540 159 Aligning 29.002 with 25.413 (UTRAN Iu Interface RANAP Signalling) 4.1.0 09 N4-000541 160 AUTS and AUTN parameter length 4.1.0 09 N4-000744 161 2 Clarification on Authentication Failure Report ack 4.1.0 09 N4-000666 163 1 Correction on Location Information 4.1.0 09 N4-000777 174 2 Optionality of parameters in GPRS-CSI 4.1.0 09 N4-000788 176 1 Correction to QoS indication 4.1.0 09 N4-000747 178 1 Clarification of use of Radio Resource Information 4.1.0 09 N4-000750 180 2 Correction to MSC-A handover SDLs 4.1.0 09 N4-000736 182 Removal of LSAIdentity from NoteMM-EventArg 4.1.0 09 N4-000772 184 LCS Support for CAMEL Phase 3 4.1.0 09 N4-000751 186 1 Correction to MSC-A handover SDLs 4.1.0 09 N4-000779 188 Clarification for segmentation of D-CSI and SMS-CSI 4.1.0 10 N4-000912 166 3 Corrections and clarifications for USSD procedures on the HLR - gsmSCF interface 4.2.0 10 N4-000908 191 1 Corrections of ISD data structure for CAMEL phase 3 4.2.0 10 N4-001069 193 2 USSD Corrections for Follow Me 4.2.0 10 N4-001071 196 1 GSM to 3G Handover: MAP parameter Target Cell ID 4.2.0 10 N4-000921 198 ASN.1 description of targetCellId 4.2.0 10 N4-001073 200 1 IMSI in MAP_PREPARE_HANDOVER 4.2.0 10 N4-001076 208 1 Alignment of the Target RNC-ID 4.2.0 10 N4-001089 211 1 Export of GSN-Address data type 4.2.0 10 N4-001095 212 Transport of long RANAP messages on MAP-E interface 4.2.0 - - - - Automatic update of annexes A and B 4.2.1 11 N4-010036 206 1 Correction to LCS application context 4.3.0 11 N4-010276 215 2 Add parameters to ISD and SRI for GPRS to handle ODB for PS 4.3.0 11 N4-010033 217 Correction to maximum number of RAB's 4.3.0 11 N4-010198 222 2 PS domain support for LCS Release 4 4.3.0 11 N4-010058 224 Failure of Update GPRS Location when HLR is not reachable 4.3.0 11 N4-010287 231 1 Extension of call related privacy class for LCS Release 4 4.3.0 11 N4-010375 232 2 Maximum number of LCS Clients 4.3.0 11 N4-010261 234 MAP over IP according to SIGTRAN 4.3.0 11 N4-010465 236 1 Requesting node type in authentication set request 4.3.0 11 N4-010360 246 Adding EXPORT definition for LSAIdentity 4.3.0 11 N4-010361 247 Removing duplicate parameters from ss-CSI 4.3.0 11 N4-010362 248 Correction to description of SS-CSI in HLR to VLR information flow 4.3.0 11 N4-010365 250 GSM to UMTS handover: addition of MAP parameter RNC ID 4.3.0 11 N4-010393 252 Clarification of the use of multicall bearer information 4.3.0 11 N4-010428 258 Adding EXPORT definition for GeographicalInformation 4.3.0 11 N4-010446 260 Failure of Authentication Parameter GPRS when HLR is not reachable 4.3.0 11 N4-010484 262 1 Correction to D-CSI 4.3.0 12 N4-010728 239 4 Addition of selected UMTS algorithm indication to the handover procedures 4.4.0 12 N4-010730 241 4 Addition of allowed GSM algorithms indication to the handover procedures 4.4.0 12 N4-010733 244 4 Addition of allowed UMTS algorithm indication to the handover procedures 4.4.0 12 N4-010735 245 4 Addition of selected GSM algorithm indication to the handover procedures 4.4.0 12 N4-010739 254 2 Addition of radio resource list to the handover procedures 4.4.0 12 NP-010247 256 3 Addition of GSM channel type and GSM chosen channel indications to handover procedures 4.4.0 12 N4-010787 264 3 Add support in MAP for all shapes defined in 23.032 4.4.0 12 N4-010633 270 1 Correction to description of RNCId parameter 4.4.0 12 N4-010635 272 1 Correction to Encryption Information and Integrity Protection parameters 4.4.0 12 N4-010767 279 3 Essential drawbacks on services due to introduction of Super-Charger function 4.4.0 12 N4-010741 283 1 Introduction of selected Rab-id to the Process Access Signalling operation 4.4.0 12 N4-010673 285 Mistake in the definition of Authentication Failure Report Application Context 4.4.0 12 N4-010551 266 Add support in MAP for Ellipsoid Point 4.4.0 12 N4-010778 168 5 Security Header modification 4.4.0 12 N4-010785 267 3 Additional Parameters in Authentication Failure Report 4.4.0 12 N4-010783 268 3 MS presence notification procedure for LCS 4.4.0 12 N4-010790 289 2 Component level granularity of protection 4.4.0 Corrupted headers fixed 4.4.1 13 N4-010840 290 Clarifications on long forwarded-to numbers 4.5.0 13 N4-010929 291 1 Corrections for Deferred MT-LR 4.5.0 13 N4-010930 292 2 Clarifications on SupportedLCS-CapabilitySets 4.5.0 13 N4-010958 295 2 Corrections on the introduction of LCS for PS domain 4.5.0 13 N4-010970 302 2 Additional SGSN related values to Access Type 4.5.0 13 N4-010976 306 Addition of data type definitions to EXPORT statements for the usage in CAP 4.5.0 13 N4-011017 307 2 Minimum MAP application context for intersystem MSC handover from GSM to UMTS 4.5.0 13 N4-011019 309 2 Minimum MAP application context for intersystem MSC handover from UMTS to GSM 4.5.0 13 N4-010845 277 1 Correction on the SDL of NW initiated USSD operations 4.5.0 13 Editorial Clean up 4.5.0 14 N4-011031 313 Clarification on LCS parameters in MAP 4.6.0 14 N4-011043 314 Handling of linked operations in the MAP protocol machine 4.6.0 14 N4-011285 316 Corrections on the SDL diagrams for LCS 4.6.0 14 N4-011198 318 1 Indication of deletion of CSI in Notify Subscriber Data Change 4.6.0 14 N4-011074 320 Correct length of Add-GeographicalInformation 4.6.0 14 N4-011091 322 Clarify encoding of RNC Id 4.6.0 14 N4-011094 324 Clarify encoding of RANAP parameters in MAP 4.6.0 14 N4-011097 325 Clarifications on long forwarded-to numbers 4.6.0 14 N4-011227 331 1 Clarification of methodology for maintaining data consistency in Supercharger 4.6.0 14 N4-011173 334 Addition of RAB ID to Prepare Handover procedure 4.6.0 14 N4-011175 336 Correction to the Allowed GSM Algorithms parameter 4.6.0 14 N4-011177 337 1 Correction of references 4.6.0 14 N4-011190 339 CUG-Info is not exported from 29.002 4.6.0 14 N4-011209 341 Clarification on NSCD when data is withdrawn 4.6.0 14 N4-011211 343 Clarification of sending CAMEL information in stand alone ISD case 4.6.0 14 N4-011262 344 Correction of the priority for ""SRI for LCS"" 4.6.0 14 N4-011273 347 ASN.1 correction 4.6.0 14 N4-011437 349 2 Handling of MNRR in the HLR & SMS-GMSC 4.6.0 14 N4-011433 354 1 Minimum MAP application context for G2G inter-MSC handover 4.6.0 14 N4-011439 359 2 Alignment of parameter lengths with those prescribed in 08.08 4.6.0 14 N4-011423 360 1 Aligning the security header elements with TS33.200 4.6.0 14 N4-011394 364 Syntax error in the ATM result and ATSI result 4.6.0 14 N4-011381 355 1 LCS Capability Handling for UE's 5.0.0 15 N4-020300 368 4 Collective CAMEL Phase 4 CR 5.1.0 15 N4-020013 373 Inclusion of complete ODB data in ATSI and NSDC 5.1.0 15 N4-020266 381 2 Introduction of the ""Requestor ID"" 5.1.0 15 N4-020068 386 Correction to AC version of gprsLocationInfoRetrievalContext 5.1.0 15 N4-020248 390 1 Incomplete description of Restore Data parameters 5.1.0 15 N4-020183 403 Clarification on CODEC-Info 5.1.0 15 N4-020250 407 1 ODB alignment 5.1.0 16 N4-020530 428 2 LCS: error handling if shape not supported by GMLC 5.2.0 16 N4-020622 453 Addition of Radio Resource List to the Forward Access Signalling operation 5.2.0 16 N4-020641 460 Clarification on Resume Call Handling 5.2.0 16 N4-020746 440 2 Clarification on SendAuthenticationInfo 5.2.0 16 N4-020750 446 1 Addition of Service Handover parameters to MAP Handover messages 5.2.0 16 N4-020318 398 Check of NAM and Requesting Node Type on receipt of SendAuthenticationInfo 5.2.0 16 N4-020333 410 Handling the MNRR flag in the HLR & SMS-GMSC 5.2.0 16 N4-020499 420 1 Clarfication of introducing Session related and unrelated class 5.2.0 16 N4-020511 430 1 Corrections on the introduction of LCS for PS domain 5.2.0 16 N4-020743 448 1 Corrections in SS-code chapter 5.2.0 16 N4-020408 423 Clarification of handling of MT-SMS-TPDU-Type and SMS-TDP 5.2.0 16 N4-020410 425 Clarify conditions to trigger restart of MTLR-Deferred procedure 5.2.0 16 N4-020468 414 1 Corrections to the handling of Any Time Interrogation and Provide Subscriber Info 5.2.0 16 N4-020476 435 1 Change PS-connected in PS-PDPactive 5.2.0 16 N4-020483 422 1 Triggering of gsmSCF for MT-SMS-CSI 5.2.0 16 N4-020485 408 2 Transferring the MS classmark & IMEI to the gsmSCF 5.2.0 16 N4-020543 441 Correction of Object Identifiers for ASN.1 modules 5.2.0 16 N4-020608 450 Enhancement to LCS in the PS domain 5.2.0 16 N4-020623 454 Addition of Location Information GPRS to Note MM Event operation 5.2.0 16 N4-020703 421 4 LCS: Codeword and Service Type 5.2.0 16 N4-020756 436 2 Splitting of CAMEL phase 4 5.2.0 17 N4-021001 437 3 Compatible upgrade to ASN.1:1997 of 29.002 5.3.0 17 NP-020399 462 2 Introduction of GERAN classmark 5.3.0 17 N4-020841 465 Clarification on Call Deflection 5.3.0 17 N4-021040 470 1 Correction to the usage of ""Roaming not allowed"" error 5.3.0 17 N4-021041 471 1 Clarifications on Send Identification 5.3.0 17 N4-021094 479 2 Handling of partial implementations of CAMEL phase 4 5.3.0 17 N4-021047 480 Removal of ChargingNotification feature 5.3.0 17 N4-020810 481 CR29.002-443 (rel5) on extensions to ATM for CAMEL control of IMS 5.3.0 17 N4-020809 482 CR to 29.002 for the support of the MAP Si interface 5.3.0 18 N4-021290 499 Correction to segmentation of O-CSI and T-CSI 5.4.0 18 N4-021418 508 ODB correction 5.4.0 18 N4-021563 511 1 Addtion of reference number to deferred location request procedure 5.4.0 18 N4-021573 516 2 Correction to the Service Handover parameters 5.4.0 18 N4-021299 442 3 Description of MT SM delivery via two serving nodes 5.4.0 18 N4-021294 474 2 Correction of handling of MT-SMS in the SGSN 5.4.0 18 N4-021124 475 ODB and CB for SMS 5.4.0 18 N4-021153 486 Correction of IMEI check for SGSN 5.4.0 18 N4-021467 489 5 Available codecs list and selected codec indication 5.4.0 18 N4-021194 490 Clarification of the use of Requested CAMEL Subscription Info parameters 5.4.0 18 N4-021252 495 Correction to RCH Ð adding O-CSI trigger criteria 5.4.0 18 N4-021264 496 Additional MM-Code for MG-CSI 5.4.0 18 N4-021296 497 1 Additional handling of partial implementations of CAMEL phase 4 5.4.0 18 N4-021383 512 Correcion of Codeword Handling 5.4.0 18 N4-021443 513 Reference to TS 23.078 in TS 29.002 regarding handling of VMSC address is missing 5.4.0 18 N4-021524 521 1 Editorial clean up 5.4.0 18 N4-021531 522 Introduction of the CHOICE element ""netDetNotReachable"" for PS-SubscriberState 5.4.0 18 N4-021260 491 1 Addition of LCS Format Indicator to LCS Client ID 6.0.0 18 N4-021504 517 2 Addition of V-GMLC Address to the Update Location and Update GPRS Location requests 6.0.0 18 N4-021567 518 3 Addition of V-GMLC and H-GMLC Addresses to the Send Routing Info for LCS response 6.0.0 18- N4-021506 519 2 Addition of PPR Address to the Send Routing Info for LCS response 6.0.0 19 N4-030234 509 3 Introduction of Call Barring for SMS in PS domain 6.1.0 19 N4-030325 524 3 Clean-up of SMS procedures chapter 6.1.0 19 NP-030068 545 2 Correction to interactions between CAMEL control of MO SMS and barring 6.1.0 19 N4-030061 526 Incrementing ASN.1 module versions 6.1.0 19 N4-030063 528 LCS diagnostic alignment 6.1.0 19 N4-030054 529 Addition of LCS Capability Set 4 6.1.0 19 N4-030301 533 1 Correction to the definitions of Radio Resource List and BSSMAP Service Handover List 6.1.0 19 N4-030305 541 2 Handover of Group Calls where MSC-B has bearer established 6.1.0 19 N4-030287 551 1 Change of SS-Code List description for Insert Subscriber Data 6.1.0 19 N4-030289 559 1 Missing of ""Continue Monitoring message"" in SDL 21.7_3.2 6.1.0 19 N4-030297 563 1 Alignment of TS 29.002 with TS 23.107 regarding QoS subscribed data 6.1.0 19 N4-030222 566 1 Introduction of MSC Number as a new parameter in MAP-SEND-IDENTIFICATION operation 6.1.0 20 N4-030692 536 2 Additional SGSN Related Access Type Ð Detach 6.2.0 20 N4-030658 568 4 Addition of Positioning Data IE to Provide Subscriber Location and Send Location Report 6.2.0 20 N4-030638 574 1 Provision of SDL diagrams and removal of redundant text in chapter 25 6.2.0 20 N4-030713 595 2 Removal of redundant text from 29.002 Chapter 23 6.2.0 20 N4-030439 599 LCS Client external ID 6.2.0 20 N4-030682 607 1 Provision of SDL diagrams and removal of redundant text in chapter 22 6.2.0 20 N4-030608 608 1 Addition of LCS capability sets to MAP_SRI_for_LCS response 6.2.0 20 N4-030647 612 1 Enhancement of the CheckIMEI operation to retrieve the BMUEF 6.2.0 20 N4-030678 619 1 Correction to naming of PRN parameter 6.2.0 20 N4-030609 624 1 Addition of Privacy Check Related Action to Provide Subscriber Location request 6.2.0 20 N4-030642 610 1 Transfer of UE-specific behaviour bitmap at handover 6.2.0 20 N4-030601 633 Missing SMSs over MSC even if the MS is capable of such sending 6.2.0 21 N4-031043 584 2 Correction to MAP Process Secure_MAP_DSM SDLsÊ 6.3.0 21 N4-031053 664 1 Correction of encoding description of Group-Id 6.3.0 21 N4-030828 657 Reduce maximum length of ""LCS Requestor ID"" and ""LCS Codeword"". 6.3.0 21 N4-030922 647 1 UESBI -IU format 6.3.0 21 N4-031069 616 3 Incorrect Charging with MNP 6.3.0 21 N4-031057 660 2 Notification of the 2nd BSG in case of Late CF with OR 6.3.0 21 N4-031059 614 3 HLR Interrogation for SCUDIF calls 6.3.0 21 N4-030785 644 Removal of tables in clause 7.6 6.3.0 21 N4-030806 649 Correction of References 6.3.0 21 N4-030815 648 Correction of wrong AC name in the table in 17.1.6 6.3.0 21 N4-030824 654 New LCS Service Types 6.3.0 21 N4-030951 671 SS-Barring Category 6.3.0 21 N4-031006 650 1 Add SGSN, GGSN, GMLC, gsmSCF, NPLR and AuC to network resource parameter 6.3.0 21 N4-0301038 645 1 Introduction of North American Interim Location Based Routing of Emergency Call 6.3.0 21 N4-031065 674 Positioning Data for UTRAN LCS 6.3.0 21 N4-030953 637 1 Provision of SDL diagrams and removal of redundant text in chapter 19 6.3.0 21 N4-030745 639 Provision of SDL diagrams and removal of redundant text in chapter 20 6.3.0 21 N4-030747 641 Provision of SDL diagrams and removal of redundant text in chapter 21 6.3.0 21 N4-030748 642 Removal of SIWF description 6.3.0 21 N4-030749 643 Deletion of redundant Annex D 6.3.0 22 N4-031098 677 Enhancements for the Partial Implementation for ""Change of position procedure armed with criteria"" 6.4.0 22 N4-031135 687 Collective CR for Rel-6 Enhanced Dialled Services 6.4.0 22 N4-031274 648 2 Message Segmentation Mechanisms 6.4.0 22 N4-031315 703 Addition of requestingPLMN-ID to Send Authentication Info Request 6.4.0 22 N4-031372 680 2 Addition of CGI to LCS procedures 6.4.0 22 N4-031373 696 2 Include v-gmlc parameter in RESTORE DATA MAP message 6.4.0 22 N4-031365 702 2 Deferred MT-LR Area Event 6.4.0 22 N4-031132 686 More spare bits for CAMEL4 enhancements 6.4.0 22 N4-031163 692 Clarification on D-CSI segmentation 6.4.0 22 N4-031342 676 2 MNP correction for prepaid charging 6.4.0 22 N4-031338 695 1 Remove reduntant option for retrieval of routeing information in figure 21.2.3 6.4.0 22 N4-031108 679 Modification of description for conditions on inclusion of Positioning Data 6.4.0 22 N4-031317 689 2 HSDPA impacts to MAP 6.4.0 22 NP-030533 704 EXPORT data types to CAP (Change of position armed with criteria) 6.4.0 23 N4-040310 668 3 Codec Modification/ Mid-Call Codec Negotiation after Inter-MSC Relocation 6.5.0 23 N4-040193 670 2 Correction of Inter-MSC SRSN Relocation procedure 6.5.0 23 N4-040249 701 3 Introduction of Presence Stage 3 (Ph, Pc and Pg) to the MAP interface 6.5.0 23 N4-040333 708 2 Correction to Insert Subscriber Data message for LCS SS 6.5.0 23 N4-040328 709 1 SCCP segmentation for Inter PLMN MAP message 6.5.0 23 N4-040327 711 2 Inclusion of UTRAN Positioning Data parameter 6.5.0 23 N4-040284 717 1 Include administrative restriction subscription parameter 6.5.0 23 N4-040340 720 2 Add new Unavailability cause for SCUDIF 6.5.0 23 N4-040171 721 CR implemented by fault 6.5.0 23 N4-040182 724 Removal of R-GMLC Address 6.5.0 23 N4-040322 725 1 MO-LR Service Identity support 6.5.0 23 N4-040267 726 1 CAMEL4 SCUDIF notification during active call for prepay 6.5.0 24 N4-040520 731 Introduction of North American Interim Location Based Routing of Emergency Call 6.6.0 24 N4-040585 735 Modify IMEI parameter usage definition in MAP-PSL and MAP-SLR 6.6.0 24 N4-040600 736 Addition of SAI-Present indication to the LCS procedures 6.6.0 24 N4-040601 737 Clarification on the use of MSISDN parameter for Follow Me functionality 6.6.0 24 N4-04732 734 1 Add Additional V-GMLC parameter in MAP-SRI-INFO-FOR-LCS 6.6.0 24 N4-040736 718 6 Addition of IMEISV to Update Location Procedure for ADD function 6.6.0 25 N4-040929 739 Export of UU-Data data type 6.7.0 25 N4-041021 743 Wrong SDL flow page implemented 6.7.0 25 N4-041128 732 2 Pre-Paging Resource Optimization 6.7.0 26 N4-041272 747 Incorrect Implementation of CR 731 6.8.0 26 N4-041477 752 Correction to the service response parameters of ATI 6.8.0 26 N4-041662 746 1 Introducing VGCS/VBS ciphering 6.8.0 26 N4-041683 757 2 Clarification about returning authentication data for a subscriber (GSM or UMTS) 6.8.0 26 N4-041684 748 1 LCS Capability Handling for UE's 6.8.0 26 N4-041685 753 1 Enable NA-ESRD Provision from a GMLC for E911 Location in North America 6.8.0 26 N4-041641 740 2 SMS Fraud countermeasures 6.8.0 27 N4-050212 749 1 Management Based Activation Impacts 6.9.0 27 N4-050369 761 1 Addition of LAI to SendIdentification Request 6.9.0 27 N4-050430 760 1 Subscribed Charging Characteristics 6.9.0 27 N4-050444 759 1 Addition of TCAP-Handshake for MO-ForwardSM 6.9.0 27 N4-050446 745 2 Introduction of Hop Counter for Send Identification 6.9.0 27 N4-050463 738 8 Rel-6 trace management additions to trace activation and deactivation procedures 6.9.0 27 N4-050467 763 2 Pseudonym indicator support in MO-LR 6.9.0 28 C4-050737 769 1 Correction to Trace parameters to allow trace at the BM-SC 6.10.0 28 C4-050832 770 6 Full RANAP support of network initiated SCUDIF 6.10.0 28 C4-050895 766 2 Clarification on the use of Access Restriction Data parameter 6.10.0 28 C4-050784 765 1 Addition of CollectInformation procedure to OfferedCAMEL4Functionalities 7.0.0 29 C4-051013 771 ASN.1 module version update 7.1.0 29 C4-051295 776 2 Enabling the Providing of Velocity 7.1.0 29 C4-051333 772 1 Support of talker priorities and talker identity presentation 7.1.0 29 C4-051334 773 1 Delivery of SMS to voice group call 7.1.0 29 C4-051368 777 2 CS data Mobile Terminating calls from PSTN 7.1.0 29 C4-051336 780 2 Correction on misalignment with stage 2 for Location Services 7.1.0 30 C4-051775 783 2 Addition of UMTS Trace parameters to handover procedure 7.2.0 31 C4-060320 794 1 Addition of UMTS Trace parameters to handover procedure 7.3.0 31 C4-060295 790 1 Removal of MAPsec material 7.3.0 31 C4-060315 787 1 addition of ""supported RAT types indicator"" during location/routing area update 7.3.0 31 C4-060378 792 1 Addition of Periodic Location Feature Support 7.3.0 31 C4-060434 781 3 New LocationType for the notification based on current location of target UE 7.3.0 31 C4-060318 788 1 SMS Relay Application Context Names for Version 1 7.3.0 31 C4-060041 789 Precision on segmentation of MAP GPRSSubscriptionData parameter 7.3.0 31 C4-060250 801 Improvements to VGCS Call Establishment 7.3.0 31 C4-060011 786 Addition of Authentication Domains in MAP Send Authentication Info 7.3.0 32 C4-060813 0808 2 List of MSISDNs and Basic Service Code for MAP Any Time Subscription Interrogation."
"7.4.0 32 C4-060499 0803 Correction of LCS parameter for emergency call usage 7.4.0 32 C4-060680 0814 SSN for FFN 7.4.0 32 C4-060706 0817 Removal of MAPsec material 7.4.0 33 CP-060522 0818 1 Removal of ASN.1 Expanded Source 7.5.0 33 C4-061047 0805 1 Interoperability between VBS/VGCS and RANflex 7.5.0 34 CP-060741 0795 1 Support of SMS over IP networks 7.6.0 34 C4-061800 0828 1 Extension of Group ID 7.6.0 34 C4-061633 0829 Addition of Teleservice Code to SendGroupCallInfo 7.6.0 34 C4-061775 0834 Accuracy Fulfillment Indicator parameter to MAP SLR for deferred MT-LR 7.6.0 34 C4-060693 0832 2 Optional Suppress Terminating Services Bit String in SRI 7.6.0 34 C4-061632 0807 2 Introduction of sending application-specific data to group call members 8.0.0 35 C4-070140 0843 ASN.1 module version update 8.1.0 35 C4-070097 0837 Corrections to RAB Configuration Indicator and Iu-Selected codec 8.1.0 35 C4-070229 0840 Addition of capability to route MT-SMs via the HPLMN of the receiving MS 8.1.0 36 C4-070388 0849 Mobile Termination whilst the MS is moving to another MSC 8.2.0 36 C4-070394 0842 2 Addition of SMS over IP functionality 8.2.0 36 CP-070476 0859 Detailed procedure in the IP-SM-GW 8.2.0 37 C4-071055 0862 QoS Extension 8.3.0 37 C4-071072 0863 Talker Channel Parameter 8.3.0 37 C4-071266 0869 LMSI For MT-SMS 8.3.0 37 C4-071281 0873 1 NPI for the call forwarding to number 8.3.0 37 C4-071285 0864 1 Limit on number of concurrent MT-LR location requests 8.3.0 37 C4-071383 0868 2 Corrections to SMS over IP handling 8.3.0 38 C4-071724 0876 TCRT: Clarification on coding of Notification Data 8.4.0 38 C4-071815 0879 Removal of CCBS_Call_Report_Ack and Event_Report_Ack 8.4.0 38 C4-071855 0881 Restriction on the use of ccbs-A SS indication 8.4.0 38 C4-071891 0877 3 SMS Router Optimization 8.4.0 38 C4-071997 0875 1 Behaviour of the IP-SM-GW for SM Delivery Status Report 8.4.0 39 C4-080267 0885 Updating of RAT Types 8.5.0 39 C4-080148 0883 SDL correction for procedure Check_Available_Vectors 8.5.0 39 C4-080532 0886 2 HLR involvement in SMS Router Optimization 8.5.0 40 C4-081277 0888 1 Extension of Group ID 8.6.0 40 C4-080647 0882 1 Paging optimization with A/Iu flex 8.6.0 41 C4-081730 0890 Addition of IMS Centralized Service subscription information 8.7.0 41 C4-082447 0891 1 eMLPP Priority in MAP SRI, PRN and PSI request 8.7.0 41 C4-082335 0892 1 Gr+ enhancements for EPS 8.7.0 42 C4-082721 0894 Gr alignment 8.8.0 42 C4-082758 0896 RAT Frequency Selection Priority 8.8.0 42 C4-083029 0899 Change in AMBR placement 8.8.0 42 C4-083221 0901 PDN-GW-Identity 8.8.0 42 C4-083223 0902 APN-OIReplacement 8.8.0 42 C4-083247 0903 Access Restriction 8.8.0 42 CP-080706 0906 1 Access Restriction Data Handling 8.8.0 42 Cp-080771 0895 4 Closed Subscriber Group 8.8.0 42 SDL files added in Zip-file 8.8.1 43 C4-090140 0908 Context Identifier for Update or Removal of PDN GW 8.9.0 43 C4-090269 0911 Handling LCS Subscription Data 8.9.0 43 C4-090507 0914 PDN GW Update for Wildcard APN 8.9.0 43 C4-090701 0909 1 Ready for SM 8.9.0 43 C4-090855 0915 Handling SMS Subscription Data 8.9.0 43 C4-090889 0916 Allocation Retention Priority Definition 8.9.0 44 C4-091071 0919 SMS over IP 8.10.0 44 C4-091028 0917 MAP RESTORE DATA service 8.10.0 44 C4-091377 0921 1 Subscription Data Clarification for MAP Interface 8.10.0 44 C4-091429 0920 1 Trace 8.10.0 44 C4-091435 0922 1 Supported Features 8.10.0 44 CP-090379 0923 1 User Data Download 8.10.0 45 C4-091713 0924 Notification of SMS over IP Non-Delivery for E-UTRAN and UE Reachability 8.11.0 45 C4-092244 0927 SGSN interface list for trace 8.11.0 45 C4-092254 0925 2 Cancel Location for Initial Attach 8.11.0 45 C4-092291 0929 Fix APN-Configuration to support dual IP addresses 8.11.0 46 C4-094140 0941 1 Alignment of specifications on Usage of MAP_SEND_AUTHENTICATION_INFO 8.12.0 46 C4-093972 0942 1 SMS over SGs charging 8.12.0 46 C4-094136 0936 1 Subscription to Notification of UE Reachability 8.12.0 46 C4-093588 0935 1 Evolved ARP 9.0.0 46 C4-093294 0932 2 APN level APN-OI-Replacement 9.0.0 46 C4-093221 0933 1 ICS-Flag 9.0.0 47 C4-100386 0949 Correction to the location information EPS IE 9.1.0 47 C4-101003 0951 1 User CSG Information for CAMEL 9.1.0 47 C4-100946 0945 2 Support of Location Continuity on the Lg Interface 9.1.0 47 C4-100947 0958 2 Enhancement of MAP-SEND-ROUTING-INFO-FOR-LCS Service for EPS 9.1.0 47 C4-100264 0943 Evolved ARP Corrections 9.1.0 47 C4-100920 0928 4 AoIP Ð MAP level codec negotiation for GSM codecs 9.1.0 47 C4-100265 0944 Dual Stack support in GPRS 9.1.0 47 C4-100353 0939 2 Support MT Roaming Retry on Pre-paging 9.1.0 47 C4-100892 0954 1 TCRT: Uplink reply procedure 9.1.0 47 C4-100881 0956 1 TADS support in MAP 9.1.0 47 C4-101010 0950 1 UE-AMBR in GPRS Subscription 9.1.0 47 CP-100234 0960 Incorrect KASME length 9.1.0 47 CP-100203 0952 5 EPS Subcsriber State and Location Information Request 9.1.0 48 C4-101236 0971 CR implementation CR 642 9.2.0 48 C4-101403 0963 1 Correction to missing GANSS position data in Provide Subscriber Location and Provide Subscriber Location Report services 9.2.0 48 C4-101400 0967 1 Tracking Area Identity Length 9.2.0 48 C4-101131 0961 ASN.1 Module Version Update 9.2.0 48 C4-101135 0962 EPS state and location retrieval 9.2.0 49 C4-101802 0975 1 Sending of MME name or SGSN Number to the VLR during the data restoration procedure 9.3.0 49 C4-101805 0977 1 Data Restoration for SMS 9.3.0 49 C4-102251 0966 3 MAP SRI Return Error message 9.3.0 49 C4-102269 0985 1 EPS Subscription Data over Gr 9.3.0 49 C4-102376 0980 3 RP-OA modification in SMS Router 9.3.0 49 C4-101809 0976 1 Addition of SIPTO permissions in PS subscription data 10.0.0 49 C4-102250 0957 4 Prevention of Timeout in IP-SM-GW 10.0.0 49 CP-100608 0979 2 Addition of SS codes to the ATSI and ATM procedures 10.0.0 50 C4-103099 0990 2 locationInformationEPS in Subscriber Info response 10.1.0 50 C4-102699 0988 1 Removal of MAP Update GPRS Location message during detach or last PDN connection deactivation via 3GPP access 10.1.0 50 C4-102737 0993 1 URRP for SGSN 10.1.0 50 C4-103156 1005 Location data including only serving node address 10.1.0 50 C4-103157 0997 2 Correction to ATM for call waiting 10.1.0 50 C4-103314 1002 2 Periodic TAU/RAU timer in HSS subscription 10.1.0 50 C4-102614 0991 ASN.1 module version upgrade 10.1.0 50 C4-102687 0987 1 Addition of MPS Priority in Subscription Data 10.1.0 50 C4-102809 0986 1 Addition of LIPA permission in Subscription Data 10.1.0 51 C4-110389 1006 2 UE SRVCC Capability Support in MAP Message 10.2.0 51 C4-110292 1008 1 Use of recovered MME Name / SGSN Name in MSC/VLR 10.2.0 51 C4-110133 1009 Zone Code Propagation at Handover 10.2.0 51 C4-110665 1016 Retrieval of T-ADS data via MAP ATI 10.2.0 51 C4-110759 1018 1 Mobile Terminating Roaming Forwarding 10.2.0 51 C4-110778 1007 2 Minimization of Drive Tests (MDT) 10.2.0 51 C4-110793 1015 1 Introduction of LCLS functionality in TS 29.002 10.2.0 51 C4-110958 1017 2 Enhancements of T-ADS data retrieval via MAP ATI 10.2.0 52 C4-111112 1024 Correction on Subscriber Data Withdrawal 10.3.0 52 C4-111611 1030 2 Missing MME Name in EPS Location Information 10.3.0 52 C4-111534 1020 1 MDT user consent 10.3.0 52 C4-111567 1021 1 SC Address in IP-SM-GW Register Response 10.3.0 52 C4-111402 1025 1 Periodic LAU timer in HSS subscription 10.3.0 52 C4-111414 1026 1 New LMSI handling for MTRF 10.3.0 52 C4-111416 1029 1 Addition of VMSC Address in PRN Ack 10.3.0 53 C4-112067 1047 Use of UE-Reachability by SGSN 10.4.0 53 C4-112081 1042 1 APN-AMBR for GPRS 10.4.0 53 C4-112096 1033 1 MTRF and Super Charger interactions 10.4.0 53 C4-111986 1043 ASN.1 exports for 32.298 11.0.0 53 C4-112033 1032 1 Addition of Anonymous Call Rejection in the CS domain 11.0.0 53 C4-112209 1037 2 Add vSRVCC updates to the Gr interface 11.0.0 53 C4-112222 1040 2 MAP-READY-FOR-SM for IP-SM-GW 11.0.0 54 C4-112930 1053 1 Provide Subscriber Information handling for UE under LTE 11.1.0 54 C4-112988 1063 PDN-Type 11.1.0 54 C4-112990 1056 1 Equivalent PLMN CSG Subscription Request 11.1.0 54 C4-113037 1055 2 LCLS negotiation MAP update 11.1.0 54 C4-112464 1039 4 Cancellation type initial attach 11.1.0 55 C4-120406 1064 1 Initial Attach Indication in MAP_CANCEL_LOCATION 11.2.0 55 C4-120420 1073 1 Removal of Subscribed Periodic TAU/RAU timer in HSS subscription 11.2.0 55 C4-120528 1072 2 User Unknown Error in Provide Subscriber Info MAP operation 11.2.0 55 C4-120224 1066 UE reachability 11.2.0 55 C4-120322 1070 TC-RT: Introduction of group IDs with prefix 11.2.0 55 C4-120416 1067 1 CSG subscription data propagation 11.2.0 55 C4-120423 1069 1 Trace Depth 11.2.0 56 C4-120707 1078 Editorial corrections to TS 29.002 11.3.0 56 C4-120713 1079 Equivalent PLMN CSG Subscription Request for CS 11.3.0 56 C4-120732 1080 EPS location in MAP Note MM Event 11.3.0 56 C4-120959 1065 3 CSG ID and Local Time for NPLI 11.3.0 56 C4-121086 1082 Clarification on HLR procedure for SMS delivery via IP-SM-GW 11.3.0 56 C4-121222 1059 4 Procedures for Update VCSG Location service 11.3.0 56 C4-121223 1049 9 Retrieving CSG subscription data from the CSS to the VLR/SGSN 11.3.0 56 C4-121227 1060 5 CSG Data Management in the VPLMN 11.3.0 57 C4-121465 1089 - TC RT: Number of Dispatcher extension 11.4.0 57 C4-121635 1088 1 Check IMEI Error 11.4.0 57 C4-121805 1092 2 Local Time Zone 11.4.0 57 C4-121534 1084 1 IMSI in MAP-MO-FORWARD-SHORT-MESSAGE 11.4.0 57 C4-121817 1068 5 PS additional number 11.4.0 57 C4-121813 1090 2 SRI for SM and MME Diameter address 11.4.0 57 C4-121802 1091 2 MSISDN-less MT-SMS 11.4.0 57 C4-121625 1083 1 PS only subscription w/o MSISDN 11.4.0 57 C4-121809 1077 4 SMS in MME/SGSN 11.4.0 57 C4-121648 1085 1 CSS Reset Procedures 11.4.0 57 C4-121650 1086 2 Temporary empty CSG suscription data 11.4.0 58 C4-122660 1106 4 Clarification on EPS Info 11.5.0 58 C4-122497 1108 1 Pdp Type 11.5.0 58 C4-122164 1093 1 Trace Depth extension 11.5.0 58 C4-121847 1094 AC version for Reset 11.5.0 58 C4-122469 1095 4 MSISDN-less UEs 11.5.0 58 C4-122476 1096 3 T4 Device Trigger via IMS 11.5.0 58 C4-122187 1097 2 T4 Trigger indication to IP-SM-GW 11.5.0 58 C4-122190 1098 2 Add Diameter Addresses to MT-SMS target node registrations 11.5.0 58 C4-121870 1099 IMSI in AbsentSubscriberSM-param 11.5.0 58 C4-122165 1101 1 Handling of current security context during inter-VLR location update 11.5.0 59 C4-130330 1118 1 SGSN acting on access restriction e-utranNotAllowed 11.6.0 59 C4-130293 1119 1 Registration for SMS Request for SMS in SGSN 11.6.0 59 C4-130305 1120 1 MDT parameters 11.6.0 59 C4-130335 1121 1 Providing Diameter identity of the SGSN to the GMLC over Lh interface 12.0.0 59 C4-130340 1122 1 SGSN indicating support of Lgd interface and providing its Diameter identity to HLR over Gr interface 12.0.0 59 C4-130423 1123 2 Validity Time of Short Message 12.0.0 59 C4-130256 1114 Mobile Terminating call pending flag in MAP Send Identification response 12.0.0 60 C4-131046 1147 2 Subscribed RFSP index for Gn SGSNs 12.1.0 60 C4-131061 1142 3 MME identity for restoration procedures 12.1.0 60 C4-130603 1128 Expicit T4-Trigger Indicator in SRI-SM 12.1.0 60 C4-130929 1126 1 Restoration Priority during SGW and PGW restoration procedures 12.1.0 60 CP-130379 1132 3 SIPTO permission for Local Network enhancements 12.1.0 60 C4-130859 1131 1 Clarification on RNC ID value 12.1.0 60 C4-130979 1129 1 Storing Last known Location Information of purged UE in HSS 12.1.0 60 C4-131040 1135 2 Maximum value for subscribed periodic timers 12.1.0 61 C4-131488 1158 2 Addition of Missing Supported Features 12.2.0 61 C4-131261 1160 ASN.1 module version update 12.2.0 61 C4-131540 1149 1 Returning to former LTE PLMN after CSFB 12.2.0 61 C4-131398 1152 2 Complements for Gdd support 12.2.0 61 C4-131445 1153 1 GERAN Iu Mode 12.2.0 61 C4-131478 1150 2 CancelLocation requesting reattach 12.2.0 61 C4-131529 1161 Enforcing access restriction during I-RAT RAU/TAU procedures 12.2.0 61 C4-131370 1130 2 SMS for IMS UE to IMS UE without MSISDN 12.2.0 62 C4-131758 1162 1 Addition of a reference to TS 23.018 for MTRF optimal routing 12.3.0 62 C4-131759 1163 1 Removal of Editor's Notes for Single-shot SM 12.3.0 62 C4-131764 1165 1 Clarification on Serving Node for SMS 12.3.0 62 C4-132011 1167 MME Initiated Removal of MME Registration for SMS 12.3.0 62 C4-132125 1169 1 Update of Homogeneous Support of IMS Voice Over PS Sessions 12.3.0 62 C4-132202 1171 1 Time Zone retrieval from a Gn/Gp-SGSN 12.3.0 63 C4-140243 1174 1 Addition of SGSN CAMEL Capability to SupportedFeatures 12.4.0 64 C4-140515 1177 CS to PS SRVCC 12.5.0 64 C4-140897 1179 Indication of IMEISV during Inter-MSC Handover 12.5.0 65 C4-141526 1181 1 P-CSCF Restoration Indication 12.6.0 65 C4-141653 1182 1 Closing TS 29.234 and reused AVP in TS 29.273 12.6.0 66 C4-141778 1183 1 MDT PLMN List 12.7.0 66 C4-142039 1187 1 WLAN offloadability for MAP 12.7.0 68 C4-150647 1188 1 Access restriction per VPLMN 13.0.0 68 C4-150880 1190 Access Restriction Data per PLMN 13.0.0 69 C4-151177 1191 ASN.1 module version update 13.1.0 70 C4-151631 1194 Reference Correction 13.2.0 70 C4-151813 1192 1 Introducing IMSI-Group ID Lists to the insert subscriber data 13.2.0 70 C4-151801 1195 1 Retrieval of ""UE Usage Type"" over MAP-Gr 13.2.0 70 C4-152198 1196 1 Positioning enhancement impacts on MAP protocol 13.2.0 70 CP-150868 1198 2 Mobile Terminating SMS handling for extended Idle mode DRX Ð Additional Option 13.2.0 70 CP-150869 1197 2 Mobile Terminating SMS handling for extended Idle mode DRX 13.2.0 71 C4-161271 1202 1 Alert procedure from MME/SGSN to SMS-GMSC for MT SMS to UE using eDRX 13.3.0 71 C4-161062 1200 Requested Retransmission Time in MT-Forward-SM response 13.3.0 71 C4-161527 1205 2 New PDN-Type for Cellular IoT 13.3.0 71 C4-161492 1204 2 Addition of NB-IoT radio access type to the Access-Restriction-Data feature 13.3.0 71 C4-161161 1203 Time Zone in MAP-Any-Time-Interrogation 13.3.0 71 C4-161317 1201 1 User Plane Integrity Protection Indicator 13.3.0 72 C4-162090 1213 Clause Numbering 13.4.0 72 C4-163271 1215 3 Group-Service-Id 13.4.0 2016-06 CT#72 CP-160217 1216 1 Use of recovered MME Name / SGSN Name in MSC/VLR 14.0.0 2016-06 CT#72 CP-160217 1214 1 Zone Code Propagation at Handover 14.0.0 2016-09 CT#73 CP-160430 1219 Retrieval of T-ADS data via MAP ATI 14.1.0 2016-09 CT#73 CP-160583 1218 2 Mobile Terminating Roaming Forwarding 14.1.0 2016-09 CT#73 CP-160423 1221 1 Minimization of Drive Tests (MDT) 14.1.0 2016-12 CT#74 CP-160667 1225 1 Introduction of LCLS functionality in TS 29.002 14.2.0 2016-12 CT#74 CP-160665 1229 1 Enhancements of T-ADS data retrieval via MAP ATI 14.2.0 2016-12 CT#74 CP-160659 1227 Correction on Subscriber Data Withdrawal 14.2.0 2016-12 CT#74 CP-160683 1230 3 Missing MME Name in EPS Location Information 14.2.0 2016-12 CT#74 CP-160657 1233 MDT user consent 14.2.0 2016-12 CT#74 CP-160683 1231 1 SC Address in IP-SM-GW Register Response 14.2.0 2017-03 CT#75 CP-170034 1236 T4 Triggering 14.3.0 2017-03 CT#75 CP-170039 1234 1 Enhanced Coverage 14.3.0 2017-03 CT#75 CP-170039 1235 1 Inter-RAT PDN-Continuity 14.3.0 2017-03 CT#76 CP-171039 1237 - T-ADS info retrieval 15.0.0 2017-09 CT#77 CP-172021 1239 - ASN.1 module version update 15.1.0 2017-12 CT#78 CP-173016 1243 2 Correction on subscribed eDRX parameter value 15.2.0 2017-12 CT#78 CP-173036 1240 - Access Restrictions to NR as Secondary RAT 15.2.0 2017-12 CT#78 CP-173036 1241 - Extended Qos 15.2.0 2018-03 CT#79 CP-180027 1244 2 Access restriction to unlicensed spectrum as secondary RAT 15.3.0 2018-10 Cover page version number was corrected 15.3.1 2018-12 CT#82 C4-187638 1245 2 Location Information used by IM-SSF in 5G 15.4.0 2019-06 CT#84 CP-191020 1249 ASN.1 corrections 15.5.0 2019-06 CT#84 CP-191058 1250 1 SMSF Address 15.5.0 2020-03 CT#87 CP-200049 1253 Correction on Location Information used by IM-SSF in 5G 15.6.0 2020-03 CT#87 CP-200027 1251 3 Addition of IAB operation permission to subscriber data 16.0.0 2020-12 CT#90e CP-203027 1255 Inform SC 16.1.0 2020-12 CT#90e CP-203027 1257 SMSF parameter description 16.1.0 2021-03 CT#91e CP-210053 1260 Correction on length of 5GS TAI 16.2.0 2021-03 CT#91e CP-210036 1261 Clarification for dummy Network Node Number 17.0.0 2021-03 CT#91e CP-210036 1259 1 Support of MAP messages at the UDM for SMS in 5GS 17.0.0 2021-06 CT#92e CP-211075 1263 ASN.1 module version update 17.1.0 2021-06 CT#92e CP-211319 1265 Misimplemented CR on Inclusive language review: EIR lists 17.1.0 2022-06 CT#96 CP-221045 1266 - 3GPPÊTSÊ23.107 missing in clause 2 17.2.0 Page 1 CR page 1006 3GPP 3GPP TS 29.002 V17.1.0 (2021-06) 14 Release 17 3GPP 3GPP TS 29.272 V18.2.0 (2023-12) Technical Specification 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Evolved Packet System (EPS); Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related interfaces based on Diameter protocol (Release 18) The present document has been developed within the 3rd Generation Partnership Project (3GPP TM) and may be further elaborated for the purposes of 3GPP. The present document has not been subject to any approval process by the 3GPP Organizational Partners and shall not be implemented. This Specification is provided for future development work within 3GPP only. The Organizational Partners accept no liability for any use of this Specification. Specifications and Reports for implementation of the 3GPP TM system should be obtained via the 3GPP Organizational Partners' Publications Offices. 3GPP Postal address 3GPP support office address 650 Route des Lucioles - Sophia Antipolis Valbonne - FRANCE Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 Internet http://www.3gpp.org Copyright Notification No part may be reproduced except as authorized by written permission. The copyright and the foregoing restriction extend to reproduction in all media. © 2023, 3GPP Organizational Partners (ARIB, ATIS, CCSA, ETSI, TSDSI, TTA, TTC). All rights reserved. UMTSª is a Trade Mark of ETSI registered for the benefit of its members 3GPPª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners LTEª is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners GSM¨ and the GSM logo are registered and owned by the GSM Association Contents Foreword 10 1 Scope 11 2 References 11 3 Definitions and abbreviations 14 3.1 Definitions 14 3.2 Abbreviations 14 4 General Description 15 5 MME Ð HSS (S6a) and SGSN Ð HSS (S6d) 15 5.1 Introduction 15 5.2 Mobility Services 15 5.2.1 Location Management Procedures 15 5.2.1.1 Update Location 15 5.2.1.1.1 General 15 5.2.1.1.2 Detailed behaviour of the MME and the SGSN 18 5.2.1.1.3 Detailed behaviour of the HSS 23 5.2.1.2 Cancel Location 27 5.2.1.2.1 General 27 5.2.1.2.2 Detailed behaviour of the MME and the SGSN 27 5.2.1.2.3 Detailed behaviour of the HSS 28 5.2.1.3 Purge UE 28 5.2.1.3.1 General 28 5.2.1.3.2 Detailed behaviour of the MME and the SGSN 29 5.2.1.3.3 Detailed behaviour of HSS 30 5.2.2 Subscriber Data Handling Procedures 30 5.2.2.1 Insert Subscriber Data 30 5.2.2.1.1 General 30 5.2.2.1.2 Detailed behaviour of the MME and the SGSN 33 5.2.2.1.3 Detailed behaviour of HSS 36 5.2.2.2 Delete Subscriber Data 38 5.2.2.2.1 General 38 5.2.2.2.2 Detailed behaviour of the MME and the SGSN 41 5.2.2.2.3 Detailed behaviour of the HSS 42 5.2.3 Authentication Procedures 42 5.2.3.1 Authentication Information Retrieval 42 5.2.3.1.1 General 42 5.2.3.1.2 Detailed behaviour of the MME and the SGSN 44 5.2.3.1.3 Detailed behaviour of the HSS 44 5.2.4 Fault Recovery Procedures 46 5.2.4.1 Reset 46 5.2.4.1.1 General 46 5.2.4.1.2 Detailed behaviour of the MME and the SGSN 47 5.2.4.1.3 Detailed behaviour of the HSS 48 5.2.5 Notification Procedures 49 5.2.5.1 Notification 49 5.2.5.1.1 General 49 5.2.5.1.2 Detailed behaviour of the MME and the SGSN 52 5.2.5.1.3 Detailed behaviour of the HSS 53 5A MME Ð CSS (S7a) and SGSN Ð CSS (S7d) 54 5A.1 Introduction 54 5A.2 Mobility Services 54 5A.2.1 Location Management Procedures 54 5A.2.1.1 Update VCSG Location 54 5A.2.1.1.1 General 54 5A.2.1.1.2 Detailed behaviour of the MME and the SGSN 55 5A.2.1.1.3 Detailed behaviour of the CSS 56 5A.2.1.2 Cancel VCSG Location 56 5A.2.1.2.1 General 56 5A.2.1.2.2 Detailed behaviour of the MME and the SGSN 57 5A.2.1.2.3 Detailed behaviour of the CSS 57 5A.2.2 Subscriber Data Handling Procedures 57 5A.2.2.1 Insert VCSG Subscriber Data 57 5A.2.2.1.1 General 57 5A.2.2.1.2 Detailed behaviour of the MME and the SGSN 58 5A.2.2.1.3 Detailed behaviour of CSS 59 5A.2.2.2 Delete VCSG Subscriber Data 59 5A.2.2.2.1 General 59 5A.2.2.2.2 Detailed behaviour of the MME and the SGSN 60 5A.2.2.2.3 Detailed behaviour of the CSS 60 5A.2.3 Fault Recovery Procedures 60 5A.2.3.1 VCSG Reset 60 5A.2.3.1.1 General 60 5A.2.3.1.2 Detailed behaviour of the MME and the SGSN 61 5A.2.3.1.3 Detailed behaviour of the CSS 61 6 MME Ð EIR (S13) and SGSN Ð EIR (S13') 62 6.1 Introduction 62 6.2 ME Identity Check Procedures 62 6.2.1 ME Identity Check 62 6.2.1.1 General 62 6.2.1.2 Detailed behaviour of the MME and the SGSN 63 6.2.1.3 Detailed behaviour of the EIR 63 7 Protocol Specification and Implementation 64 7.1 Introduction 64 7.1.1 Use of Diameter base protocol 64 7.1.2 Securing Diameter Messages 64 7.1.3 Accounting functionality 64 7.1.4 Use of sessions 64 7.1.5 Transport protocol 64 7.1.6 Routing considerations 65 7.1.7 Advertising Application Support 65 7.1.8 Diameter Application Identifier 65 7.1.9 Use of the Supported-Features AVP 66 7.2 Commands 67 7.2.1 Introduction 67 7.2.2 Command-Code values 67 7.2.3 Update-Location-Request (ULR) Command 68 7.2.4 Update-Location-Answer (ULA) Command 69 7.2.5 Authentication-Information-Request (AIR) Command 69 7.2.6 Authentication-Information-Answer (AIA) Command 70 7.2.7 Cancel-Location-Request (CLR) Command 70 7.2.8 Cancel-Location-Answer (CLA) Command 70 7.2.9 Insert-Subscriber-Data-Request (IDR) Command 71 7.2.10 Insert-Subscriber-Data-Answer (IDA) Command 71 7.2.11 Delete-Subscriber-Data-Request (DSR) Command 72 7.2.12 Delete-Subscriber-Data-Answer (DSA) Command 73 7.2.13 Purge-UE-Request (PUR) Command 74 7.2.14 Purge-UE-Answer (PUA) Command 74 7.2.15 Reset-Request (RSR) Command 75 7.2.16 Reset-Answer (RSA) Command 75 7.2.17 Notify-Request (NOR) Command 76 7.2.18 Notify-Answer (NOA) Command 76 7.2.19 ME-Identity-Check-Request (ECR) Command 77 7.2.20 ME-Identity-Check-Answer (ECA) Command 77 7.2.21 Update-VCSG-Location-Request (UVR) Command 78 7.2.22 Update-VCSG-Location-Answer (UVA) Command 78 7.2.23 Cancel-VCSG-Location-Request (CVR) Command 78 7.2.24 Cancel-VCSG-Location-Answer (CVA) Command 79 7.3 Information Elements 80 7.3.1 General 80 7.3.2 Subscription-Data 89 7.3.3 Terminal-Information 90 7.3.4 IMEI 91 7.3.5 Software-Version 91 7.3.6 3GPP2-MEID 91 7.3.7 ULR-Flags 91 7.3.8 ULA-Flags 93 7.3.9 Visited-PLMN-Id 93 7.3.10 Feature-List AVP 93 7.3.10.1 Feature-List AVP for the S6a/S6d application 93 7.3.10.2 Feature-List AVP for the S7a/S7d application 106 7.3.11 Requested-EUTRAN-Authentication-Info 106 7.3.12 Requested-UTRAN- GERAN-Authentication-Info 106 7.3.13 RAT-Type 106 7.3.14 Number-Of-Requested-Vectors 106 7.3.15 Re-Synchronization-Info 107 7.3.16 Immediate-Response-Preferred 107 7.3.17 Authentication-Info 107 7.3.18 E-UTRAN-Vector 107 7.3.19 UTRAN-Vector 107 7.3.20 GERAN-Vector 108 7.3.21 Network-Access-Mode 108 7.3.22 HPLMN-ODB 108 7.3.23 Item-Number 108 7.3.24 Cancellation-Type 108 7.3.25 DSR-Flags 109 7.3.26 DSA-Flags 111 7.3.27 Context-Identifier 111 7.3.28 Void 112 7.3.29 Subscriber-Status 112 7.3.30 Operator-Determined-Barring 112 7.3.31 Access-Restriction-Data 112 7.3.32 APN-OI-Replacement 113 7.3.33 All-APN-Configurations-Included-Indicator 113 7.3.34 APN-Configuration-Profile 114 7.3.35 APN-Configuration 114 7.3.36 Service-Selection 116 7.3.37 EPS-Subscribed-QoS-Profile 116 7.3.38 VPLMN-Dynamic-Address-Allowed 116 7.3.39 STN-SR 116 7.3.40 Allocation-Retention-Priority 117 7.3.41 AMBR 117 7.3.42 MIP-Home-Agent-Address 117 7.3.43 MIP-Home-Agent-Host 118 7.3.44 PDN-GW-Allocation-Type 118 7.3.45 MIP6-Agent-Info 118 7.3.46 RAT-Frequency-Selection-Priority-ID 118 7.3.47 IDA-Flags 118 7.3.48 PUA-Flags 119 7.3.49 NOR-Flags 119 7.3.50 User-Id 120 7.3.51 Equipment-Status 120 7.3.52 Regional-Subscription-Zone-Code 121 7.3.53 RAND 121 7.3.54 XRES 121 7.3.55 AUTN 121 7.3.56 KASME 121 7.3.57 Confidentiality-Key AVP 121 7.3.58 Integrity-Key AVP 121 7.3.59 Kc AVP 121 7.3.60 SRES 121 7.3.61 Void 121 7.3.62 PDN-Type 121 7.3.63 Trace-Data AVP 122 7.3.64 Trace-Reference AVP 122 7.3.65 Void 123 7.3.66 Void 123 7.3.67 Trace-Depth AVP 123 7.3.68 Trace-NE-Type-List AVP 123 7.3.69 Trace-Interface-List AVP 123 7.3.70 Trace-Event-List AVP 123 7.3.71 OMC-Id AVP 123 7.3.72 GPRS-Subscription-Data 123 7.3.73 Complete-Data-List-Included-Indicator 124 7.3.74 PDP-Context 124 7.3.75 PDP-Type 125 7.3.75A Ext-PDP-Type 125 7.3.76 Void 125 7.3.77 QoS-Subscribed 125 7.3.78 CSG-Subscription-Data 125 7.3.79 CSG-Id 125 7.3.80 Expiration-Date 125 7.3.81 Roaming-Restricted-Due-To-Unsupported-Feature 126 7.3.82 Specific-APN-Info AVP 126 7.3.83 Alert-Reason AVP 126 7.3.84 LCS-Info 126 7.3.85 GMLC-Number 126 7.3.86 LCS-PrivacyException 127 7.3.87 SS-Code 127 7.3.88 SS-Status 127 7.3.89 Notification-To-UE-User 127 7.3.90 External-Client 127 7.3.91 Client-Identity 128 7.3.92 GMLC-Restriction 128 7.3.93 PLMN-Client 128 7.3.94 Service-Type 128 7.3.95 ServiceTypeIdentity 128 7.3.96 MO-LR 128 7.3.97 Void 129 7.3.98 Trace-Collection-Entity AVP 129 7.3.99 Teleservice-List 129 7.3.100 TS-Code 129 7.3.101 Call-Barring-Info 129 7.3.102 SGSN-Number 129 7.3.103 IDR-Flags 129 7.3.104 ICS-Indicator 130 7.3.105 Visited-Network-Identifier 130 7.3.106 IMS-Voice-Over-PS-Sessions-Supported 131 7.3.107 Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions 131 7.3.108 Last-UE-Activity-Time 131 7.3.109 GMLC-Address 131 7.3.110 EPS-User-State 131 7.3.111 EPS-Location-Information 132 7.3.112 MME-User-State 132 7.3.113 SGSN-User-State 132 7.3.114 User-State 132 7.3.115 MME-Location-Information 133 7.3.116 SGSN-Location-Information 133 7.3.117 E-UTRAN-Cell-Global-Identity 134 7.3.118 Tracking-Area-Identity 134 7.3.119 Cell-Global-Identity 134 7.3.120 Routing-Area-Identity 134 7.3.121 Location-Area-Identity 134 7.3.122 Service-Area-Identity 134 7.3.123 Geographical-Information 134 7.3.124 Geodetic-Information 134 7.3.125 Current-Location-Retrieved 134 7.3.126 Age-Of-Location-Information 135 7.3.127 Active-APN 135 7.3.128 Error-Diagnostic 135 7.3.129 Ext-PDP-Address AVP 136 7.3.130 UE-SRVCC-Capability 136 7.3.131 MPS-Priority 136 7.3.132 VPLMN-LIPA-Allowed 136 7.3.133 LIPA-Permission 136 7.3.134 Subscribed-Periodic-RAU-TAU-Timer 137 7.3.135 SIPTO-Permission 137 7.3.136 MDT-Configuration 137 7.3.137 Job-Type 138 7.3.138 Area-Scope 138 7.3.139 List-Of-Measurements 138 7.3.140 Reporting-Trigger 138 7.3.141 Report-Interval 138 7.3.142 Report-Amount 138 7.3.143 Event-Threshold-RSRP 138 7.3.144 Event-Threshold-RSRQ 138 7.3.145 Logging-Interval 138 7.3.146 Logging-Duration 139 7.3.147 Relay-Node-Indicator 139 7.3.148 MDT-User-Consent 139 7.3.149 PUR-Flags 139 7.3.150 Subscribed-VSRVCC 139 7.3.151 Equivalent-PLMN-List 140 7.3.152 CLR-Flags 140 7.3.153 UVR-Flags 140 7.3.154 UVA-Flags 140 7.3.155 VPLMN-CSG-Subscription-Data 141 7.3.156 Local-Time-Zone 141 7.3.157 A-MSISDN 141 7.3.158 Void 141 7.3.159 MME-Number-for-MT-SMS 141 7.3.160 Void 142 7.3.161 Void 142 7.3.162 SMS-Register-Request 142 7.3.163 Time-Zone 142 7.3.164 Daylight-Saving-Time 142 7.3.165 Subscription-Data-Flags 142 7.3.166 Measurement-Period-LTE 143 7.3.167 Measurement-Period-UMTS 143 7.3.168 Collection-Period-RRM-LTE 143 7.3.169 Collection-Period-RRM-UMTS 143 7.3.170 Positioning-Method 143 7.3.171 Measurement-Quantity 143 7.3.172 Event-Threshold-Event-1F 144 7.3.173 Event-Threshold-Event-1I 144 7.3.174 Restoration-Priority 144 7.3.175 SGs-MME-Identity 144 7.3.176 SIPTO-Local-Network-Permission 144 7.3.177 Coupled-Node-Diameter-ID 144 7.3.178 OC-Supported-Features 144 7.3.179 OC-OLR 144 7.3.180 ProSe-Subscription-Data 144 7.3.181 WLAN-offloadability 145 7.3.182 WLAN-offloadability-EUTRAN 145 7.3.183 WLAN-offloadability-UTRAN 145 7.3.184 Reset-ID 145 7.3.185 MDT-Allowed-PLMN-Id 146 7.3.186 Adjacent-PLMNs 146 7.3.187 Adjacent-Access-Restriction-Data 146 7.3.188 DL-Buffering-Suggested-Packet-Count 146 7.3.189 IMSI-Group-Id 147 7.3.190 Group-Service-Id 147 7.3.191 Group-PLMN-Id 147 7.3.192 Local-Group-Id 148 7.3.193 AESE-Communication-Pattern 148 7.3.194 Communication-Pattern-Set 148 7.3.195 Monitoring-Event-Configuration 149 7.3.196 Monitoring-Event-Report 150 7.3.197 UE-Reachability-Configuration 150 7.3.198 eNodeB-ID 151 7.3.199 Supported-Services 151 7.3.200 Supported-Monitoring-Events 151 7.3.201 AIR-Flags 151 7.3.202 UE-Usage-Type 152 7.3.203 DRMP 152 7.3.204 Non-IP-PDN-Type-Indicator 152 7.3.205 Non-IP-Data-Delivery-Mechanism 152 7.3.206 Additional-Context-Identifier 153 7.3.207 SCEF-Realm 153 7.3.208 Subscription-Data-Deletion 153 7.3.209 Preferred-Data-Mode 153 7.3.210 Emergency-Info 153 7.3.211 Load 154 7.3.212 V2X-Subscription-Data 154 7.3.213 V2X-Permission 154 7.3.214 PDN-Connection-Continuity 154 7.3.215 eDRX-Cycle-Length 155 7.3.216 eDRX-Cycle-Length-Value 155 7.3.217 UE-PC5-AMBR 155 7.3.218 Extended eNodeB-ID 155 7.3.219 MBSFN-Area 155 7.3.220 MBSFN-Area-ID 155 7.3.221 Carrier-Frequency 156 7.3.222 RDS-Indicator 156 7.3.223 Service-Gap-Time 156 7.3.224 Aerial-UE-Subscription-Information 156 7.3.225 Broadcast-Location-Assistance-Data-Types 156 7.3.226 Paging-Time-Window 158 7.3.227 Operation-Mode 158 7.3.228 Paging-Time-Window-Length 158 7.3.229 eDRX-Related-RAT 158 7.3.230 Core-Network-Restrictions 159 7.3.231 Interworking-5GS-Indicator 159 7.3.232 Ethernet-PDN-Type-Indicator 159 7.3.233 Subscribed-ARPI 159 7.3.234 IAB-Operation-Permission 159 7.3.235 V2X-Subscription-Data-Nr 160 7.3.236 UE-PC5-QoS 160 7.3.237 PC5-QoS-Flow 160 7.3.238 5QI 160 7.3.239 PC5-Flow-Bitrates 160 7.3.240 Guaranteed-Flow-Bitrates 161 7.3.241 Maximum-Flow-Bitrates 161 7.3.242 PC5-Range 161 7.3.243 PC5-Link-AMBR 161 7.3.244 Third-Context-Identifier 161 7.4 Result-Code and Experimental-Result Values 161 7.4.1 General 161 7.4.2 Success 161 7.4.3 Permanent Failures 161 7.4.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001) 161 7.4.3.2 DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) 162 7.4.3.3 DIAMETER_ERROR_RAT_NOT_ALLOWED (5421) 162 7.4.3.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) 162 7.4.3.5 DIAMETER_ERROR_EQUIPMENT_UNKNOWN (5422) 162 7.4.3.6 DIAMETER_ERROR_UNKNOWN_SERVING_NODE (5423) 162 7.4.4 Transient Failures 162 7.4.4.1 DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181) 162 7.4.4.2 DIAMETER_ERROR_CAMEL_SUBSCRIPTION_PRESENT (4182) 162 8 User identity to HSS resolution 162 Annex A (normative): MME mapping table for S6a and NAS Cause Code values 163 Annex B(normative): SGSN mapping table for S6d and NAS Cause Code values 166 Annex C (normative): Diameter overload control mechanism 168 C.1 General 168 C.2 S6a/S6d interfaces 168 C.2.1 General 168 C.2.2 HSS behaviour 168 C.2.3 MME/SGSN behaviour 168 Annex D (Informative): Diameter overload control node behaviour 169 D.1 Message prioritisation over S6a/d 169 Annex E (normative): Diameter message priority mechanism 169 E.1 General 169 E.2 S6a/S6d interfaces 169 E.2.1 General 169 E.2.2 HSS, CSS, EIR behaviour 169 E.2.3 MME/SGSN behaviour 170 Annex F (normative): Diameter load control mechanism 171 F.1 General 171 F.2 S6a/S6d interfaces 171 F.2.1 General 171 F.2.2 HSS behaviour 171 F.2.3 MME/SGSN behaviour 171 Annex G (informative): Change history 172 Foreword This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). The contents of the present document are subject to continuing work within the TSG and may change following formal TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an identifying change of release date and an increase in version number as follows: Version x.y.z where: x the first digit: 1 presented to TSG for information; 2 presented to TSG for approval; 3 or greater indicates TSG approved document under change control. y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. z the third digit is incremented when editorial only changes have been incorporated in the document. In the present document, modal verbs have the following meanings: shall indicates a mandatory requirement to do something shall not indicates an interdiction (prohibition) to do something The constructions ""shall"" and ""shall not"" are confined to the context of normative provisions, and do not appear in Technical Reports. The constructions ""must"" and ""must not"" are not used as substitutes for ""shall"" and ""shall not"". Their use is avoided insofar as possible, and they are not used in a normative context except in a direct citation from an external, referenced, non-3GPP document, or so as to maintain continuity of style when extending or modifying the provisions of such a referenced document. should indicates a recommendation to do something should not indicates a recommendation not to do something may indicates permission to do something need not indicates permission not to do something The construction ""may not"" is ambiguous and is not used in normative elements. The unambiguous constructions ""might not"" or ""shall not"" are used instead, depending upon the meaning intended. can indicates that something is possible cannot indicates that something is impossible The constructions ""can"" and ""cannot"" are not substitutes for ""may"" and ""need not"". will indicates that something is certain or expected to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document will not indicates that something is certain or expected not to happen as a result of action taken by an agency the behaviour of which is outside the scope of the present document might indicates a likelihood that something will happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document might not indicates a likelihood that something will not happen as a result of action taken by some agency the behaviour of which is outside the scope of the present document In addition: is (or any other verb in the indicative mood) indicates a statement of fact is not (or any other negative verb in the indicative mood) indicates a statement of fact The constructions ""is"" and ""is not"" do not indicate requirements. 1 Scope The present document describes the Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) related diameter-based interfaces towards the Home Subscriber Server (HSS) or the CSG Subscriber Server (CSS), and the MME and the SGSN related diameter-based interface towards the Equipment Identity Register (EIR). This specification defines the Diameter application for the MME-HSS, S6a reference point, for the MME-CSS, S7a reference point, for the SGSN-HSS, S6d reference point, and for the SGSN-CSS, S7d reference point. The interactions between the HSS/CSS and the MME/SGSN are specified, including the signalling flows. This specification defines the Diameter application for the MME-EIR, S13 reference point, and for the SGSN-EIR, S13' reference point. The interactions between the MME/SGSN and the EIR are specified, including the signalling flows. In this specification, if there is no specific indication, the following principles apply: - ""SGSN"" refers to an SGSN which at least supports the S4 interface and may support Gn and Gp interfaces. - ""S4-SGSN"" refers to an SGSN which supports the S4 interface and does not support Gn and Gp interfaces. - Gn/Gp-SGSN refers to an SGSN which supports the Gn and Gp interfaces and does not support S4 interface. - ""GPRS subscription data"" refers to the parameters in the HLR column in Table 5.2. in 3GPPÊTSÊ23.008Ê[30]. - ""EPS subscription data"" refers to the parameters in the HSS column in Table 5.2A-1 in 3GPPÊTSÊ23.008Ê[30]. The Evolved Packet System stage 2 description (architecture and functional solutions) is specified in 3GPPÊTSÊ23.401Ê[2] and in 3GPPÊTSÊ23.060Ê[12]. SGSN CAMEL Subscription Data are not supported over S6d interface. 2 References The following documents contain provisions which, through reference in this text, constitute provisions of the present document. - References are either specific (identified by date of publication, edition number, version number, etc.) or non specific. - For a specific reference, subsequent revisions do not apply. - For a non-specific reference, the latest version applies. In the case of a reference to a 3GPP document (including a GSM document), a non-specific reference implicitly refers to the latest version of that document in the same Release as the present document. [1] 3GPPÊTRÊ21.905: ""Vocabulary for 3GPP Specifications"". [2] 3GPPÊTSÊ23.401: ""GPRS enhancements for E-UTRAN access "". [3] 3GPPÊTSÊ23.003: ""Numbering, addressing and identification"". [4] Void. [5] 3GPPÊTSÊ33.401: ""3GPP System Architecture Evolution: Security Architecture"". [6] Void"". [7] IETFÊRFCÊ2234: ""Augmented BNF for syntax specifications"". [8] 3GPPÊTSÊ32.299: ""Charging management; Diameter charging applications"". [9] 3GPPÊTSÊ29.229: ""Cx and Dx interfaces based on the Diameter protocol"". [10] 3GPPÊTSÊ29.212: ""Policy and Charging Control (PCC); Reference points"". [11] 3GPPÊTSÊ29.214: ""Policy and Charging Control over Rx reference point"". [12] 3GPPÊTSÊ23.060: ""General Packet Radio Service (GPRS); Service description; StageÊ2"". [13] 3GPPÊTSÊ22.016: ""International Mobile station Equipment Identities (IMEI)"". [14] IETFÊRFCÊ4960: ""Stream Control Transmission Protocol"". [15] Void [16] 3GPPÊTSÊ33.210: ""3G Security; Network Domain Security; IP Network Layer Security"".. [17] 3GPPÊTSÊ29.228: ""IP multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and Message Elements"". [18] 3GPPÊTSÊ33.102: ""3G Security; Security Architecture"". [19] 3GPPÊTSÊ36.413: ""Evolved Universal Terrestrial Radio Access Network (E-UTRAN); S1 Application Protocol (S1AP)"". [20] IETFÊRFCÊ5778: ""Diameter Mobile IPv6: Support for Home Agent to Diameter Server Interaction"". [21] 3GPPÊTSÊ29.061: ""Interworking between the Public Land Mobile Network (PLMN) supporting packet based services and Packet Data Networks (PDN)"". [22] 3GPPÊTSÊ32.298: ""Charging Management; CDR parameter description"". [23] 3GPPÊTSÊ32.422: ""Telecommunication management; Subscriber and equipment trace; Trace control and configuration management"". [24] 3GPPÊTSÊ29.002: ""Mobile Application Part (MAP) specification"". [25] 3GPPÊTSÊ29.329: ""Sh Interface based on the Diameter protocol"". [26] IETFÊRFCÊ5447: ""Diameter Mobile IPv6: Support for Network Access Server to Diameter Server Interaction"". [27] IETFÊRFCÊ4004: ""Diameter Mobile IPv4 Application"". [28] 3GPP2 A.S0022: ""Interoperability Specification (IOS) for Evolved High Rate Packet Data (eHRPD) Radio Access Network Interfaces and Interworking with Enhanced Universal Terrestrial Radio Access Network (E-UTRAN)"". [29] 3GPPÊTSÊ23.011: ""Technical realization of Supplementary Services - General Aspects"". [30] 3GPPÊTSÊ23.008: ""Organization of subscriber data"". [31] 3GPPÊTSÊ24.008: ""Mobile radio interface Layer 3 specification; Core network protocols; Stage 3"". [32] IETFÊRFCÊ5516: ""Diameter Command Code Registration for Third Generation Partnership Project (3GPP) Evolved Packet System (EPS)"". [33] 3GPPÊTSÊ32.251: ""Telecommunication management; Charging management; Packet Switched (PS) domain charging"". [34] 3GPPÊTSÊ23.292: ""IP Multimedia Subsystem (IMS) centralized services "". [35] 3GPPÊTSÊ23.216: ""Single Radio Voice Call Continuity (SRVCC)"". [36] 3GPPÊTSÊ23.015:""Technical realization of Operator Determined Barring (ODB)"". [37] 3GPPÊTSÊ29.173: ""Diameter-based SLh interface for Control Plane LCS"". [38] 3GPPÊTSÊ29.303: ""Domain Name System Procedures; Stage 3"". [39] 3GPPÊTSÊ29.060: ""General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface"". [40] 3GPPÊTSÊ36.300: ""Evolved Universal Terrestrial Radio Access (E-UTRA) and Evolved Universal Terrestrial Radio Access Network (E-UTRAN); Overall description; Stage 2"". [41] ITU-TÊRecommendationÊE.164: ""The international public telecommunication numbering plan"". [42] 3GPPÊTSÊ22.042: ""Network Identity and TimeZone (NITZ); Service description; Stage 1"". [43] 3GPPÊTSÊ23.007: ""Restoration procedures"". [44] 3GPPÊTSÊ23.272: ""Circuit Switched (CS) fallback in Evolved Packet System (EPS); Stage 2"". [45] 3GPPÊTSÊ29.010: ""Information element mapping between Mobile Station - Base Station System (MS - BSS) and Base Station System - Mobile-services Switching Centre (BSS - MSC)"". [46] 3GPPÊTSÊ29.118: ""Mobility Management Entity (MME) ÐVisitor Location Register (VLR)SGs interface specification "". [47] 3GPPÊTSÊ29.172: ""Evolved Packet Core (EPC) LCS Protocol (ELP) between the Gateway Mobile Location Centre (GMLC) and the Mobile Management Entity (MME)"". [48] 3GPPÊTSÊ29.338: ""Diameter based protocols to support Short Message Service (SMS) capable Mobile Management Entities (MMEs)"". [49] 3GPPÊTSÊ29.344: ""Proximity-services (ProSe) Function to Home Subscriber Server (HSS) aspects; Stage 3"". [50] IETFÊRFCÊ7683: ""Diameter Overload Indication Conveyance"". [51] 3GPPÊTSÊ23.380: ""IMS Restoration Procedures"". [52] 3GPPÊTSÊ22.153: ""Multimedia Priority Service"". [53] 3GPPÊTSÊ23.221: ""Architectural requirements"". [54] 3GPPÊTSÊ29.336: ""Home Subscriber Server (HSS) diameter interfaces for interworking with packet data networks and applications"". [55] 3GPPÊTSÊ23.682: ""Architecture enhancements to facilitate communications with packet data networks and applications "". [56] 3GPPÊTSÊ29.217: ""Congestion reporting over Np reference point"". [57] IETFÊRFCÊ7944: ""Diameter Routing Message Priority"". [58] 3GPPÊTSÊ43.020: ""Security related network functions"". [59] 3GPPÊTSÊ29.273: ""Evolved Packet System (EPS); 3GPP EPS AAA interfaces"". [60] IETFÊRFCÊ8583: ""Diameter Load Information Conveyance"". [61] IETFÊRFCÊ6733: ""Diameter Base Protocol"". [62] 3GPPÊTSÊ36.331: ""Evolved Universal Terrestrial Radio Access (E-UTRA); Radio Resource Control (RRC); Protocol specification"". [63] 3GPPÊTSÊ29.128: ""Mobility Management Entity (MME) and Serving GPRS Support Node (SGSN) interfaces for interworking with packet data networks and applications"". [64] 3GPPÊTSÊ24.301: ""Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS); Stage 3"". [65] 3GPPÊTSÊ36.423: ""Evolved Universal Terrestrial Radio Access Network (E-UTRAN); X2 Application Protocol (X2AP)"". [66] 3GPPÊTSÊ29.503: ""Unified Data Management Services"". [67] 3GPPÊTSÊ23.502: ""Procedures for the 5G System; Stage 2"". [68] 3GPP TSÊ23.287: ""Architecture enhancements for 5G System (5GS) to support Vehicle-to-Everything (V2X) services"". [69] 3GPPÊTSÊ23.501: ""System Architecture for the 5G System; Stage 2"". [70] 3GPPÊTSÊ29.563: ""5G System; Home Subscriber Server (HSS) services for interworking with Unified Data Management (UDM); Stage 3"". [71] GSMAÊPRDÊIR.73: ""Steering of Roaming Implementation Guidelines"". 3 Definitions and abbreviations 3.1 Definitions For the purposes of the present document, the terms and definitions given in 3GPPÊTRÊ21.905Ê[1] and the following apply. A term defined in the present document takes precedence over the definition of the same term, if any, in 3GPPÊTRÊ21.905Ê[1]. CSG subscription data from CSS: It identifies the CSG subscription data that a MME or a SGSN has received from a CSS for a subscriber identified by its IMSI."
"CSG subscription data from HSS: It identifies the CSG subscription data that a MME or a SGSN has received from a HSS for a subscriber identified by its IMSI. 3.2 Abbreviations For the purposes of the present document, the abbreviations given in TRÊ21.905Ê[1] and the following apply. An abbreviation defined in the present document takes precedence over the definition of the same abbreviation, if any, in TRÊ21.905Ê[1]. AVP Attribute Value Pair C Conditional CSS CSG Subscriber Server DCN Dedicated Core Network DRMP Diameter Routing Message Priority DSCP Differentiated Services Code Point EIR Equipment Identity Register ESM EPS Session Management HSS Home Subscriber Server IAB Integrated Access and Backhaul IE Information Element LAA Licensed Assisted Access LWA LTE/WLAN Aggregation LWIP LTE/WLAN Radio Level Integration with IPsec Tunnel M Mandatory MME Mobility Management Entity NR New Radio O Optional ODB Operator Determined Barring SCEF Service Capability Exposure Function URRP-MME User Reachability Request Parameter for MME URPP-SGSN User Reachability Request Parameter for SGSN 4 General Description This document describes the S6a/S6d and S13/S13' interfaces related procedures, message parameters and protocol specifications. The procedures, message parameters and protocol are similar between S6a and S6d. S6a is used for location changes of the MME, while S6d is for location changes of the SGSN. Refer to clauseÊ5 for the differences, especially clauseÊ5.2.1. The procedures, message parameters and protocol are identical as for the S13 and S13'. See clauseÊ6 for details. In the tables that describe the Information Elements transported by each Diameter command, each Information Element is marked as (M) Mandatory, (C) Conditional or (O) Optional in the ""Cat."" column. For the correct handling of the Information Element according to the category type, see the description detailed in clauseÊ6 of the 3GPPÊTSÊ29.228Ê[17]. 5 MME Ð HSS (S6a) and SGSN Ð HSS (S6d) 5.1 Introduction The S6a interface enables the transfer of subscriber related data between the MME and the HSS as described in the 3GPPÊTSÊ23.401Ê[2]. The S6d interface enables the transfer of subscriber related data between the SGSN and the HSS as described in 3GPPÊTSÊ23.060Ê[12]. 5.2 Mobility Services 5.2.1 Location Management Procedures 5.2.1.1 Update Location 5.2.1.1.1 General The Update Location Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to update location information in the HSS. The procedure shall be invoked by the MME or SGSN and is used: - to inform the HSS about the identity of the MME or SGSN currently serving the user, and optionally in addition; - to update MME or SGSN with user subscription data; subscription data that are applicable to MMEs but not to SGSNs should not be sent to the SGSN unless the SGSN is known to be a combined MME/SGSN; similarly subscription data that are applicable to SGSNs but not to MMEs should not be sent to the MME unless the MME is known to be a combined MME/SGSN. - to provide the HSS with other user data, such as Terminal Information or UE SRVCC Capability. This procedure is mapped to the commands Update-Location-Request/Answer (ULR/ULA) in the Diameter application specified in clause 7. Table 5.2.1.1.1/1 specifies the involved information elements for the request. Table 5.2.1.1.1/2 specifies the involved information elements for the answer. Table 5.2.1.1.1/1: Update Location Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Terminal Information (See 7.3.3) Terminal-Information O This information element shall contain information about the user's mobile equipment. Within this Information Element, only the IMEI and the Software-Version AVPs shall be used on the S6a/S6d interface. ULR Flags (See 7.3.7) ULR-Flags M This Information Element contains a bit mask. See 7.3.7 for the meaning of the bits. Visited PLMN Id (See 7.3.9) Visited-PLMN-Id M This IE shall contain the MCC and the MNC, see 3GPPÊTSÊ23.003Ê[3]. It may be used to apply roaming based features. Equivalent PLMN List (See 7.3.151) Equivalent-PLMN-List O This Information Element shall contain the equivalent PLMN list of which the MME/SGSN requests the corresponding CSG Subscription data. RAT Type (See 7.3.13) RAT-Type M This Information Element contains the radio access type the UE is using. See clauseÊ7.3.13 for details. SGSN number (See 7.3.102) SGSN-Number C This Information Element contains the ISDN number of the SGSN, see 3GPPÊTSÊ23.003Ê[3]. It shall be present when the message is sent on the S6d interface and the SGSN supports LCS (using MAP based Lg interface) or SMS functionalities or the Gs interface. It may be present when the message is sent on the S6a interface and the requesting node is a combined MME/SGSN. Homogeneous Support of IMS Voice Over PS Sessions Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions O This Information Element, if present, indicates whether or not ""IMS Voice over PS Sessions"" is supported homogeneously in all TAs or RAs in the serving node (MME or SGSN or combined MME/SGSN). The value ""SUPPORTED"" indicates that there is support for ""IMS Voice over PS Sessions"" in all TAs or RAs. The value ""NOT_SUPPORTED"" indicates that theres is not support for ""IMS Voice over PS Sessions"" in any of the TAs or RAs. V-GMLC address GMLC-Address C This Information Element shall contain, if available, the IPv4 or IPv6 address of the V-GMLC associated with the serving node. Active APN Active-APN O This Information Element, if present, contains the list of active APNs stored by the MME or SGSN, including the identity of the PDN GW assigned to each APN. For the case of explicitly subscribed APNs, the following information shall be present: - Context-Identifier: context id of subscribed APN in use - Service-Selection: name of subscribed APN in use - MIP6-Agent-Info: including PDN GW identity in use for subscribed APN - Visited-Network-Identifier: identifies the PLMN where the PDN GW was allocated For the case of the Wildcard APN, the following information shall be present: - Context-Identifier: context id of the Wildcard APN - Specific-APN-Info: list of APN-in use and related PDN GW identity when the subscribed APN is the wildcard APN It may be present when MME or SGSN needs to restore PDN GW data in HSS due to a Reset procedure. UE SRVCC Capability UE-SRVCC-Capability C This information element shall indicate if the UE supports or does not support the SRVCC capability and shall be present if the MME or the SGSN supports SRVCC and this information is available to the MME or the SGSN. MME Number for MT SMS MME-Number-for-MT-SMS C This Information Element contains the ISDN number of the MME to route SMS to the UE through the MME, see 3GPPÊTSÊ23.003Ê[3]. It shall be present when the MME supports SMS in MME and wishes to provide SMS in MME. SMS Register Request SMS-Register-Request C This information element is used to inform the HSS if the MME or the SGSN needs to be registered for SMS, prefers not to be registered for SMS or has no preference. It shall be present when the MME supports SMS in MME and requests to be registered for SMS. It shall be present when the SGSN supports ""SMS in SGSN"" as defined in clauseÊ5.3.18 in 23.060Ê[12], and requests to be registered for SMS. SGs MME identity SGs-MME-Identity O This information element is used to inform the HSS of the MME identity that the MME will use over the SGs interface. This information element shall be present, if the MME supports this information element and if the MME identity used over SGs is different from the MME Diameter identity used over S6a. Coupled node's Diameter identity Coupled-Node-Diameter-ID O This information element contains the Diameter identity of the coupled node (i.e. MME's Diameter identity for the SGSN and SGSN's Diameter identity for the MME) when the message is sent by the combined MME/SGSN. This information element may be present when the message is sent on the S6a/S6d interface and the requesting node is a combined MME/SGSN. Adjacent PLMNs Adjacent-PLMNs O This information element, if present, shall contain the list of PLMNs where an UE served by the MME/SGSN is likely to make a handover from the PLMN where the MME/SGSN is located. This list is statically configured by the operator in the MME/SGSN, according to the geographical disposition of the different PLMNs in that area, the roaming agreements, etc... Supported Services (3GPPÊTSÊ29.336Ê[54]) Supported-Services O If present, this Information Element shall contain AVPs indicating details of the services supported by the MME/SGSN. Table 5.2.1.1.1/2: Update Location Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable: - User Unknown - Unknown EPS Subscription - RAT Not Allowed - Roaming Not Allowed Error-Diagnostic Error-Diagnostic O If the Experimental Result indicates ""Unknown EPS Subscription"", Error Diagnostic may be present to indicate whether or not GPRS subscription data are subscribed (i.e. whether or not Network Access Mode stored in the HSS indicates that only circuit service is allowed). If the Experimental Result indicates ""Roaming Not Allowed"", and the Update Location is rejected due to ODB, Error Diagnostic may be present to indicate the specific type of ODB. ULA-Flags (See 7.3.8) ULA-Flags C This Information Element contains a bit mask. See 7.3.8 for the meaning of the bits. It shall be present only when the Result-Code AVP is DIAMETER_SUCCESS. Subscription Data (See 7.3.2) Subscription-Data C This Information Element shall contain the complete subscription profile of the user. It shall be present if success is reported, unless an explicit ""skip subscriber data"" indication was present in the request. Reset-IDs (See 7.3.184) Reset-ID O The Reset-ID uniquely identifies a fallible resource in the HSS on which the user (IMSI) depends. In the event of a restart of the fallible resource a Reset message containing the Reset-ID will exactly identify the impacted subscribers. 5.2.1.1.2 Detailed behaviour of the MME and the SGSN The MME shall make use of this procedure to update the MME identity stored in the HSS (e.g. at initial attach, inter MME tracking area update or radio contact after HSS reset). The SGSN shall make use of this procedure to update the SGSN identity stored in the HSS (e.g. at initial attach, inter SGSN routing area update or radio contact after HSS reset). The MME shall make use of this procedure to request SMS data and to become registered for SMS. The SGSN shall make use of this procedure to request to become registered for SMS. A combined MME/SGSN which uses different Diameter Identities for the MME and SGSN parts shall not send a second ULR when in a first ULA the ULA-Flag ""Separation Indication"" was not set. For UEs receiving emergency services, in which the UE was not successfully authenticated, the MME or SGSN shall not make use of the Update Location procedure. If the Update Location request is to be sent due to an inter node (SGSN to MME) update and the previous SGSN is a Gn/Gp SGSN, the MME shall set the ""Single-Registration-Indication"" flag in the ULR-Flags information element in the request. If the Update Location request is to be sent due to an initial attach, the MME or SGSN shall set the ""Initial-Attach-Indicator"" flag in the ULR-Flags information element in the request. If the Update Location request is sent due to a Tracking Area Update following intra-PLMN inter-MME or AMF to MME handover, then the MME may set the Intra-PLMN-inter-MME handover flag in the ULR-Flags information element in the request. If the Update Location request is sent due to a Tracking Area Update following inter-PLMN inter-MME or AMF to MME handover, then the MME may set the Inter-PLMN-inter-MME handover flag in the ULR-Flags information element in the request. In order to avoid handovers failing (including the cases of emergency and non-emergency EPS fallback voice handovers), the Intra-PLMN-inter-MME handover flag and Inter-PLMN-inter-MME handover flags are required if the HPLMN deploys Steering of Roaming functionality that interferes with the Diameter signalling procedures e.g. as described in the sectionÊ6.1 of GSMAÊPRDÊIR.73Ê[71]. Otherwise, these flags are left to be configured based on operator policy. NOTE 0: It is useful if the HPLMN discloses how they do Steering of Roaming to the VPLMN. The VPLMN can be configured to comply if they support this feature in the MME. When receiving and supporting Reset-ID AVPs in the response, the MME or SGSN shall delete all the stored Reset-IDs, if there are any, and then store all the received Reset-IDs. A combined MME/SGSN shall set the ""Skip Subscriber Data"" flag in the ULR-Flags if subscriber data are already available due to a previous identical location update. Otherwise the MME/SGSN shall not set the ""Skip Subscriber Data"" flag in the ULR-Flags. A combined MME/SGSN that has advertised its support for the combined MME/SGSN capability, by either including the SGSN Number within ULR sent over S6a or including the Coupled-Node-Diameter-ID within ULR sent over S6a/S6d or by using same Diameter identity over S6a and S6d interfaces, shall be prepared to receive a single subscription data update message (IDR or DSR) from the HSS when the subscription data is modified. If the MME or SGSN knows about the homogeneity of the support of IMS Voice over PS Sessions in all TAs or RAs associated to that serving node (i.e., it is supported in all the TA/RAs or it is not supported in any of the TA/RAs) and for the serving subscriber taking into account roaming relationship for IMS Voice over PS Sessions, it shall include this indication to the HSS in the ""Homogeneous Support of IMS Voice over PS Sessions"" IE. The MME or SGSN may include dynamic APN and PGW ID data in the list of Active-APN AVPs, in order to restore this information in the HSS after a Reset procedure. The MME/SGSN may include an equivalent PLMN list to request the CSG Subscription data of the equivalent PLMNs. A standalone MME shall not indicate its support for any SGSN specific features, and it shall not request explicitly the download of GPRS data (via the GPRS-Subscription-Data-Indicator flag; see clauseÊ7.3.7). A standalone MME that does not support the ""SMS in MME"" feature shall not provide its MME Number for MT SMS, ""SMS only"" indication or SMS Registration Request and therefore not indicate its support for any SMS related features (such as ODB or barring services). For an SGSN, if a DIAMETER_ERROR_CAMEL_SUBSCRIPTION_PRESENT is received, the SGSN shall initiate the update location procedure with MAP over Gr interface and use Gr for the subsequent mobility procedures. For a standalone MME or SGSN, if EPS or GPRS subscription data is received, the standalone MME or SGSN shall replace all of the EPS or GPRS subscription data of the user in the MME or SGSN. Any optional EPS or GPRS data not received, but stored in the standalone MME or SGSN, shall be deleted. For a combined MME/SGSN, if EPS subscription data of the user is received, it shall replace all of the EPS subscription data of the user. Any optional EPS data not received by the combined MME/SGSN, but stored in the MME/SGSN, shall be deleted. For a combined MME/SGSN, if GPRS subscription data of the user is received, it shall replace all of the GPRS subscription data of the user. Any optional GPRS data not received by the combined MME/ SGSN, but stored in the MME/SGSN, shall be deleted. When receiving an Update Location response from the HSS, the MME or SGSN shall check the result code. If it indicates success the MME or SGSN shall store the received subscription profile (if any), and it shall store the HSS identity as received in the Origin-Host AVP. If an Additional MSISDN (A-MSISDN) is available in the subscription data and downloaded in the A-MSISDN AVP to the MME/SGSN in an Update Location and if the MME or SGSN supports the additional MSISDN feature, the MME or SGSN shall use the Additional MSISDN as C-MSISDN. For UEs receiving emergency services (i.e. emergency attached UEs or normal attached UEs with a UE Requested PDN Connection for emergency services), and if the MME or SGSN supports emergency services for users in limited service state, the MME or SGSN shall proceed even if the Update Location procedure fails (e.g. authenticated users with roaming restrictions or RAT-Type restrictions in HSS). When receiving GPRS-Subscription-Data AVP in the response, the SGSN or combined MME/SGSN shall delete all the stored PDP-Contexts, if there are any, and then store all the received PDP-Contexts. When receiving the APN-Configuration-Profile AVP in a ULA, the MME or SGSN shall delete all the stored APN-Configurations, if there are any, and then store all the received APN-Configurations. For each of the received APN-Configurations in the APN-Configuration-Profile, if both the MIP6-Agent-Info and the PDN-GW-Allocation-Type AVPs are absent in the APN-Configuration AVP and the MME or SGSN does not have any associated PGW information, the MME or SGSN shall perform the PGW selection (static or dynamic) according to the local configuration. If MIP6-Agent-Info is present, and PDN-GW-Allocation-Type is not present, this means that the PDN GW address included in MIP6-Agent-Info has been statically allocated. If the MIP6-Agent-Info contains an FQDN of the PDN GW, the MME shall retrieve the PGW PLMN ID from the MIP-Home-Agent-Host AVP within the MIP6-Agent-Info AVP. When receiving an Update Location response from the HSS in the TAU or RAU procedure, for each of the received APN-Configurations in the APN-Configuration-Profile, if both the MIP6-Agent-Info and the PDN-GW-Allocation-Type AVPs are absent in the APN-Configuration AVP and the MME or SGSN has associated PGW information and the UE-level access restriction ""HO-To-Non-3GPP-Access Not Allowed"" is not set, the MME or SGSN should send a Notify Request if HO to the WLAN is supported in the network, including the APN and PDN GW identity to the HSS in order to restore this information in the HSS e.g. after a Reset procedure. If the MME/SGSN supports interworking with Gn/Gp-SGSNs, it shall ensure that the Context -Identifier sent over GTPv1 for each of the received APN-Configurations is within the range of 1 and 255. NOTE 1: If the MME/SGSN receives from HSS a Context-Identifier value higher than 255, how this value is mapped to a value between 1 and 255 is implementation specific. If the subscriber is not roaming and the SIPTO-Permission information for an APN is present, the MME or SGSN shallÊallow SIPTO above RAN for that APNÊonly if the SIPTO-Permission information indicates so. If the subscriber is not roaming and the SIPTO-Permission information for an APN is not present, the MME or SGSNÊmay allow SIPTO above RAN for that APN. If the subscriber is roaming and the SIPTO-Permission information for an APN is present, the MME or SGSN shall allow SIPTO above RAN for that APN only if the SIPTO-Permission information indicates so and the VPLMN Dynamic Address is allowed and the MME or SGSN selects a PDN GW in the VPLMN. If the subscriber is roaming and the SIPTO-Permission information for an APN is not present, the MME or SGSN shall not allow SIPTO above RAN for that APN. NOTE 2: Based on local configuration, the MME or SGSN can determine not to allow SIPTO above RAN for an APN,Êregardless if the SIPTO-Permission information is present. If the subscriber is not roaming and the SIPTO-Local-Network-Permission information for an APN is present, the MME or SGSN shall allow SIPTO at the local network for that APNÊonly if the SIPTO-Local-Network-Permission information indicates so. If the subscriber is not roaming and the SIPTO-Local-Network-Permission information for an APN is not present, the MME or SGSN may allow SIPTO at the local network for that APN. If the subscriber is roaming and the SIPTO-Local-Network-Permission information for an APN is present, the MME or SGSN shall allow SIPTO at the local network for that APN only if the SIPTO-Local-Network-Permission information indicates so and the VPLMN Dynamic Address is allowed and the MME or SGSN selects a L-GW in the VPLMN. If the subscriber is roaming and the SIPTO-Local-Network-Permission information for an APN is not present, the MME or SGSN shall not allow SIPTO at the local network for that APN. NOTE 3: Based on local configuration, the MME or SGSN can determine not to allow SIPTO at the local network for an APN,Êregardless if the SIPTO-Local-Network-Permission information is present. If MPS-Priority AVP is present and the UE is subscribed to the eMLPP or 1x RTT priority service in the CS domain as indicated by the MPS-CS-Priority bit of the AVP, the MME shall allow the UE to initiate the RRC connection with higher priority than other normal UEs during CS Fallback procedure. If the MPS-Priority AVP is present and the UE is subscribed to MPS in the EPS domain as indicated by the MPS-EPS-Priority bit of the AVP, the MME shall allow the UE to initiate the RRC connection with higher priority than other normal UEs. If the subscriber is not roaming, the MME or SGSN may allow or prohibit the UE to use LIPA as indicated by LIPA-Permission for a specific APN. If the subscriber is roaming and the VPLMN-LIPA-Allowed AVP indicates that the UE is not allowed to use LIPA in the VPLMN where the UE is attached, the MME or SGSN shall not provide LIPA for the UE and shall not consider the LIPA-Permission AVP. If the VPLMN-LIPA-Allowed AVP indicates that the UE is allowed to use LIPA in the VPLMN, the MME or SGSN may allow or prohibit the UE to use LIPA as indicated by LIPA-Permission for a specific APN. The VPLMN-Dynamic-Address-Allowed AVP shall not be considered if it is received when the MME or SGSN establishes a PDN connection with LIPA. If the LIPA-Permission information for an APN indicates LIPA only, the MME or SGSN shall only allow LIPA for that APN via the authorized CSGs according to the CSG Subscription Data. If the LIPA-Permission information for an APN indicates LIPA prohibited, the MME or SGSN shall not allow LIPA for that APN. If the LIPA-Permission information for an APN indicates LIPA conditional, the MME or SGSN shall allow non LIPA, and LIPA for that APN via the authorized CSGs according to the CSG Subscription Data. If the LIPA-Permission AVP is not present for a specific APN, the APN shall not be allowed to use LIPA. The LIPA-Permission information for the Wildcard APN shall apply to any APN that is not explicitly present in the subscription data. The SIPTO-Permission information for the Wildcard APN shall apply to any APN that is not explicitly present in the subscription data. The SIPTO-Local-Network-Permission information for the Wildcard APN shall apply to any APN that is not explicitly present in the subscription data. If the subscription data received for a certain APN indicates that the APN was authorized as a consequence of having the Wildcard APN in the user subscription in HSS, then the MME shall not store this APN data beyond the lifetime of the UE session and the MME shall delete them upon disconnection of the UE. If the MME supports the Relay Node functionality (see 3GPPÊTSÊ36.300Ê[40]) and the subscription data indicates that the subscriber is not a relay, the MME shall reject the attach request from a device attempting to attach to EPS as a Relay Node. If a device requests to be attached to EPS as an UE, the MME shall proceed with the attach procedure regardless of the content of the Relay Node Indicator. If trace data are received in the subscriber data, the MME or SGSN shall start a Trace Session. For details, see 3GPPÊTSÊ32.422Ê[23]. If the Ext-PDP-Type AVP is present in the PDP-Context AVP, the SGSN or combined MME/SGSN shall ignore the value of the PDP-Type AVP. If the subscriber is not roaming and the Subscribed-Periodic-RAU-TAU-Timer information is present, the MME or SGSN shall allocate the subscribed value to the UE as periodic RAU or TAU timer. If the subscriber is roaming and the Subscribed-Periodic-RAU-TAU-Timer information is present, the MME or SGSN may use the subscribed periodic RAU/TAU timer value as an indication to decide for allocating a locally configured periodic RAU/TAU timer value to the UE. For a combined MME/SGSN, the node may include the Coupled-Node-Diameter-ID AVP to allow the HSS to determine if the UE is served by the MME and SGSN parts of the same combined MME/SGSN. When the message is sent over S6a interface and if this AVP is included, the MME shall include the Diameter identity of the coupled SGSN which is used by the SGSN over S6d interface. When the message is sent over S6d interface and if this AVP is included, the SGSN shall include the Diameter identity of the coupled MME which is used by the MME over S6a interface. NOTE 4: The Coupled-Node-Diameter-ID AVP allows the HSS to determine if the UE is served by the MME and SGSN parts of the same combined MME/SGSN, when the SGSN number is not available and when Diameter identity of S6a and S6d interfaces of the combined MME/SGSN are not the same. If the MME supports the ""SMS in MME"" feature and the UE has requested a combined EPS/IMSI attach or Combined TA/LA Update (see 3GPPÊTSÊ23.272Ê[44]) and the MME is not currently registered for SMS, the MME requests to be registered for SMS by indicating its MME Number for MT SMS in the request, including the SMS-Register-Request AVP and the SMS-Only-Indication flag set in the ULR-Flags AVP if UE indicates ""SMS only"". If the MME supports the ""SMS in MME"" feature, when receving an EPS attach or a TAU from a UE accessing NB-IoT which requests SMS by indicating ""SMS transfer without Combined Attach"" (see 3GPPÊTSÊ23.401Ê[2]), and if the MME is not currently registered for SMS, the MME requests to be registered for SMS by indicating its MME Number for MT SMS in the request, including the SMS-Register-Request AVP. If the HSS provides the MME with SMS data in the ULA and the ULA-Flags is received with ""MME Registered for SMS"" flag set, the MME shall store this data for providing SMS in MME service and consider itself registered for SMS. If the SGSN supports the ""SMS in SGSN"" feature as specified in 3GPPÊTSÊ23.060Ê[12], clauseÊ5.3.18, and wishes to provide SMS via SGSN it shall set the ""SMS in SGSN"" flag in the Feature-List AVP, and include SMS-Register-Request AVP. If the SGSN supports the Diameter based Gdd interface for SMS in SGSN, it shall set the ""Gdd-in-SGSN"" flag in the Feature-List AVP. If the UE has indicated ""SMS-Only"" this shall be indicated to the HSS setting the SMS-OnlyÐIndication flag in the ULR-Flags AVP. NOTE 5: the setting of the ""SMS in SGSN"" feature bit reflects the ""SMS in SGSN Offered"" as described in stage 2 above. If the SMS-In-SGSN-Allowed-Indication flag is set in the received Subscription-Data-Flags AVP, the SGSN shall store the subscription data for providing SMS in SGSN service. If the subscriber is not roaming and the Restoration-Priority information for a certain APN is present, the MME or SGSN shall consider the subscribed value as the relative priority of the user's PDN connection among PDN connections to the same APN when restoring PDN connections affected by an SGW or PGW failure/restart (see 3GPPÊTSÊ23.007Ê[43]). If the subscriber is roaming and the Restoration-Priority information for a certain APN is present, the MME or SGSN may use the subscribed value as an indication of the relative priority of the user's PDN connection among PDN connections to the same APN based on service level agreements. The MME/SGSN may use a locally configured value as default restoration priority if the Restoration-Priority AVP for a certain APN is not present, or if it is not permitted by service level agreements for an in-bound roamer. If the subscription data received for a certain APN includes WLAN-offloadability AVP, then the MME or SGSN shall determine the offloadability of the UE's PDN Connection(s) to that APN based on subscription data and locally configured policy (e.g. for roaming users or when the subscription data does not include any offloadability indication). NOTE 6: As indicated in clauseÊ7.3.31, if the UE-level access restriction ""HO-To-Non-3GPP-Access Not Allowed"" is set, the offload of PDN Connections to WLAN is not allowed for any APN. If the subscription data received for the user includes the DL-Buffering-Suggested-Packet-Count AVP, then the MME or SGSN should take into account the subscription data, in addition to local policies, to determine whether to invoke extended buffering of downlink packets at the SGW for High Latency Communication. Otherwise, the MME or SGSN shall make this determination based on local policies only. When receiving IMSI-Group-Id AVP(s) within the Subscription-Data AVP, the MME or SGSN shall replace stored IMSI-Group Ids (if any) with the received information rather than add the received information to the stored information. When receiving one or more Monitoring-Event-Configuration AVP(s) in the ULA, the MME or SGSN shall start the detection of the Monitoring events indicated in those AVP(s), if not already started, and shall stop the detection and delete the previous monitoring events (if any) which are not indicated in those AVP(s). If there is a failure when starting the detection (e.g. maximum resources exceeded), the MME or SGSN shall not store the failed configuration(s) and shall send a notification of those events whose configuration have failed, as described in clauseÊ5.2.5.1.2 (NOR/NOA commands). If the Subscription-Data AVP is received in the ULA but it does not contain any Monitoring-Event-Configuration AVP(s), the MME or SGSN shall stop the detection and delete all stored monitoring event configurations (if any). If the MME/SGSN supports Monitoring, the MME/SGSN shall include the Supported-Services AVP with Supported-Monitoring-Events included in the ULR command. If the MME and the UE support Attach without PDN connection (i.e. EMM-REGISTERED without PDN connection) and the PDN-Connection-Restricted flag is set in the received Subscription-Data-Flags AVP, the MME shall not establish any non-emergency PDN connectionand shall tear down any existing non-emergency PDN connection for this user. If the subscription data received for the user includes the Preferred-Data-Mode AVP, for an IP APN configuration or for a non-IP APN configuration with SGi based delivery, then the MME should (if the subscriber is not roaming) or may (if the subscriber is roaming) take into account the subscription data, in addition to local policies and the UE's Preferred Network Behaviour, to determine whether to transmit the traffic associated with this APN over the User Plane and/or over the Control Plane.Otherwise, the MME shall make this determination based on local policies and the UE's Preferred Network Behaviour only. If the MME receives from the HSS an Update Location response containing the Emergency-Info AVP in the Subscription-Data, the MME shall use the PDN-GW identity included in Emergency-Info as the PDN-GW used to establish emergency PDN connections with the emergency APN, for non-roaming authenticated UEs requesting the handover of an emergency PDN connection if the MME is configured to use a dynamic PDN-GW for emergency services for such user. When receiving V2X-Subscription-Data in the ULA, the MME shall determine whether the UE is authorized to use V2X communication over PC5 according to V2X subscription data and UE provided network capability. If the UE is authorized to use V2X communication over PC5, the MME shall store the ""V2X service authorized"" indication together with the UE AMBR used for PC5 interface (i.e. UE-PC5-AMBR), and provide such information to the eNodeB when needed. If the MME/SGSN receives from the HSS an Update Location response without the bit set for ""NR as Secondary RAT"" in the Feature-List AVP, the MME/SGSN, based on local policy, may restrict access for NR as secondary RAT when all relevant entities except HSS supports it. If the MME receives from the HSS an Update Location response containing in the subscription data the Core-Network-Restrictions AVP with the bit ""5GC not allowed"" set, the MME shall restrict mobility towards 5GC. 5.2.1.1.3 Detailed behaviour of the HSS When receiving an Update Location request the HSS shall check whether subscription data exists for the IMSI. If the HSS determines that there is not any type of subscription for the IMSI (including EPS, GPRS and CS subscription data), a Result Code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If the Update Location Request is received over the S6a interface, and the subscriber has not any APN configuration, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. If the Update Location Request is received over S6a, from an MME that does not support the ""Non-IP PDN Type APNs"" feature, and the user's subscripton profile contains only APN configurations of type ""Non-IP"", the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. If the Update Location Request is received over the S6d interface, and the subscriber has neither an APN configuration profile nor GPRS subscription data, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. When sending DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION, an Error Diagnostic information may be added to indicate whether or not GPRS subscription data are subscribed (i.e. whether or not Network Access Mode stored in the HSS indicates that only CS service is allowed). The HSS shall check whether the RAT type the UE is using is allowed for the subscriber in the serving PLMN. If it is not, a Result Code of DIAMETER_ERROR_RAT_NOT_ALLOWED shall be returned. The HSS shall check whether access to EPC is allowed, based on the active Core Network Restrictions of the subscriber. If access to EPC is restricted, a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION shall be returned. The HSS shall check whether roaming is not allowed in the VPLMN due to ODB. If so a Result Code of DIAMETER_ERROR_ROAMING_NOT_ALLOWED shall be returned. When this error is sent due to the MME or SGSN not supporting a certain ODB category, an Error Diagnostic information element may be added to indicate the type of ODB; if this error is sent due to the ODB indicating ""Barring of Roaming"", Error Diagnostic shall not be included. If the Update Location Request is received over the S6d interface and the HSS supports the ""SGSN CAMEL Capability"" feature, and the SGSN indicates support of SGSN CAMEL capability, the HSS shall check if the subscriber has SGSN CAMEL Subscription data. If the subscriber has SGSN CAMEL Subscription data, the HSS shall return a Result Code of DIAMETER_ERROR_CAMEL_SUBSCRIPTION_PRESENT. If the Update Location Request is received over the S6a interface, the HSS shall send a Cancel Location Request with a Cancellation-Type of MME_UPDATE_PROCEDURE (CLR; see clause 7.2.7) to the previous MME (if any) and replace the stored MME-Identity with the received value (the MME-Identity is received within the Origin-Host AVP). The HSS shall reset the ""UE purged in MME"" flag and delete any stored last known MME location information of the (no longer) purged UE. If the ""Single-Registration-Indication"" flag was set in the received request, the HSS shall send a Cancel Location Request with a Cancellation-Type of SGSN_UPDATE_PROCEDURE to the SGSN (MAP Cancel Location), and delete the stored SGSN address and SGSN number. If the ""Initial-Attach-Indicator"" flag was set in the received request, and the ""Single-Registration-Indication"" flag was not set, the HSS shall send a Cancel Location Request with a Cancellation-Type of INITIAL_ATTACH_PROCEDURE (CLR; see clause 7.2.7, or MAP Cancel Location) to the SGSN if there is an SGSN registration. If the Update Location Request is received over the S6d interface, the HSS shall send a Cancel Location Request with a Cancellation-Type of SGSN_UPDATE_PROCEDURE (CLR; see clause 7.2.7, or MAP Cancel Location) to the previous SGSN (if any) and replace the stored SGSN-Identity with the received value (the SGSN-Identity is received within the Origin-Host AVP). The HSS shall reset the ""UE purged in SGSN"" flag and delete any stored last known SGSN location information of the (no longer) purged UE. If the ""Initial-Attach-Indicator"" flag was set in the received request, the HSS shall send a Cancel Location Request with a Cancellation-Type of INITIAL_ATTACH_PROCEDURE (CLR; see clause 7.2.7) to the MME if there is an MME registration. When the HSS receives the Update Location Request, if a 15th digit of the IMEI AVP is received, the HSS may discard the digit. If the Update Location Request includes either the ULR-flag Inter-PLMN-inter-MME or the ULR-flag intra-PLMN-inter-MME, then the HSS may ignore this information. NOTEÊ1: These flags are intended for use by Steering of Roaming functions that are not standardised by 3GPP and which operate by interfering with the Diameter procedures."
"If the Update Location Request includes the list of active APNs, the HSS shall delete all the stored dynamic PDN GW information, if there are any, and then replace them by the PDN GW information received in the list of Active-APN AVPs. If the Update Location Request includes an equivalent PLMN list, the HSS shall return the CSG list (if any) for each equivalent PLMN to the MME with the subscription data, and Visited-PLMN-Id AVP shall be present in the CSG-Subscription-Data AVP to indicate the corresponding PLMN. If there is no equivalent PLMN list received, the HSS may not include Visited-PLMN-Id AVP in the CSG-Subscription-Data AVP, and the CSG-Subscription-Data AVP shall contain the CSG subscription data of the registered PLMN of the MME or the SGSN. If the Update Location Request is received over the S6a interface for a user for which the URRP-MME parameter is set in the HSS, the HSS shall clear the URRP-MME parameter and send an indication to the corresponding Service Related Entities. If the Update Location Request is received over the S6d interface for a user for which the URRP-SGSN parameter is set in the HSS, the HSS shall clear the URRP-SGSN parameter and send an indication to the corresponding Service Related Entities. If no result code has been sent to the MME or SGSN so far, the HSS shall include the subscription data in the ULA command according to the ULR-Flags and the supported/unsupported features of the MME or SGSN, unless an explicit ""skip subscriber data"" indication has been received in the request, and shall return a Result Code of DIAMETER_SUCCESS. When the APN-Configuration-Profile AVP is present in the Subscription-Data AVP sent within a ULA, the AVP shall contain at least the default APN Configuration and a Context-Identifier AVP that identifies the per subscriber's default APN configuration. The default APN Configuration shall not contain the Wildcard APN (see 3GPPÊTSÊ23.003Ê[3], clauseÊ9.2); the default APN shall always contain an explicit APN. The GPRS Subscription data (if available in the HSS) shall only be present in the ULA command if it was indicated by the serving node in the ULR-Flags AVP (see clauseÊ7.3.7), or when the subscription data is returned by a Pre-Rel-8 HSS (via an IWF) or when the Update Location Request is received over the S6d interface and there is no APN configuration profile stored for the subscriber. The HSS shall use the indication received in the GPRS-Subscription-Data-Indicator for future use in the subscriber data update procedures. The HSS shall store the new terminal information and/or the new UE SRVCC capability, if they are present in the request. If the UE SRVCC capability is not present, the HSS shall store that it has no knowledge of the UE SRVCC capability. If the MME/SGSN indicates support of the Additional-MSISDN feature and an additional MSISDN (A-MSISDN) is available in the subscription data, the HSS shall send the provisioned additional MSISDN together with the MSISDN. If the MME/SGSN does not support the Additional-MSISDN feature, the HSS shall populate the MSISDN AVP either with the subscribed MSISDN or the subscribed additional MSISDN based on operator policy and availability. NOTEÊ2: When the MME/SGSN does not support the Additional-MSISDN feature, the MME/SGSN will use the MSISDN from the MSISDN AVP as C-MSISDN. LCS-Info, Teleservice-List and Call-Barring-Info data shall be included according to the list of supported features indicated by the serving node (see clauseÊ7.3.10). If the HSS supports the ""SMS in MME"" feature and receives the indication that the MME supports the ""SMS in MME"" feature and requests to be registered for SMS by including the MME Number for MT SMS, SMS-Register-Request AVP and/or setting the SMS-Only-Indication flag in the ULR-Flags AVP if indicated from the UE, the HSS shall determine if SMS can be provided via the MME as described in 3GPPÊTSÊ23.272Ê[44]. If SMS in MME is accepted the HSS shall register the MME for SMS, store the ""MME number for MT SMS"" as the corresponding MSC number to be used for MT SMS and return an indication of MME registered for SMS in ULA-Flags AVP. If the MME is successfully registered for SMS the HSS shall download the available SMS related subscription data that may comprise SMS teleservice, MSISDN, ODB and barring services for SMS according to supported features. Also, if the user is considered as not reachable (i.e., MNRF flag is set in HSS for that user), and the UE is considered to have free available memory (i.e., MCEF flag is not set in HSS for that user), the HSS shall send a MAP-Alert-Service-Centre message or S6c-Alert-Service-Centre-Request to the SMS-IWMSC (see 3GPPÊTSÊ29.338Ê[48]). If the HSS supports the ""SMS in SGSN"" feature as described in 3GPPÊTSÊ23.060Ê[12], clauseÊ5.3.18 and receives the indication from the SGSN that it supports ""SMS in SGSN"" feature, and SMS-Register-Request AVP and/or the SMS-Only-Indication flag in the ULR-Flags AVP if indicated from the UE, and the PS subscriber data allow for SMS services (e.g. the subscription information indicates ""PS and SMS-Only""), the HSS shall determine if SMS can be provided via the SGSN as described in 3GPPÊTSÊ23.060Ê[12]. If ""SMS in SGSN"" is accepted the HSS shall indicate in the ULA that ""SMS in SGSN"" is allowed to the SGSN and shall handle MT SMS as described in 3GPPÊTSÊ23.060Ê[12], clauseÊ5.3.18. If the HSS supports the ""Gdd-in-SGSN"" feature and receives the indication from the SGSN that it supports the ""Gdd-in-SGSN"" feature, the HSS shall store the information that the SGSN supports the Gdd interface. Also, if the user is considered as not reachable (i.e., MNRG flag is set in HSS for that user), and the UE is considered to have free available memory (i.e., MCEF flag is not set in HSS for that user), the HSS shall send a MAP-Alert-Service-Centre message or S6c-Alert-Service-Centre-Request to the SMS-IWMSC (see 3GPPÊTSÊ29.338Ê[48]). The HSS may use the indication received in the Node-Type-Indicator for future use in the subscriber data update procedures. Subscriber-Status AVP shall be present in the Subscription-Data AVP when sent within a ULA. If the value ""OPERATOR_DETERMINED_BARRING"" is sent, the Operator-Determined-Barring AVP or HPLMN-ODB AVP shall also be present in the Subscription-Data AVP, or vice versa. Access-Restriction-Data AVP shall be present within the Subscription-Data AVP sent within a ULA if at least one of the defined restrictions applies. The AMBR AVP shall be present in the Subscription-Data AVP when the APN-Configuration-Profile AVP is sent within a ULA (as part of the Subscription-Data AVP) and may be present in the Subscription-Data AVP when the GPRS-Subscription-Data AVP is present. The EPS-Subscribed-QoS-Profile AVP and the AMBR AVP shall be present in the APN-Configuration AVP when the APN-Configuration AVP is sent in the APN-Configuration-Profile AVP and when the APN-Configuration-Profile AVP is sent within a ULA (as part of the Subscription-Data AVP). For those APNs that have been authorized as a consequence of having the Wildcard APN in the user subscription, the HSS shall include the specific APN name and associated PDN-GW identity inside the APN context of the Wildcard APN. This indicates to the MME that the particular APN shall not be cached in the MME and it shall be deleted when the UE session is terminated. If a Result Code of DIAMETER_SUCCESS is returned, the HSS shall set the Separation Indication in the response. If the HSS receives an indication in the ULR command about the homogeneous support of IMS Voice over PS Sessions in all TA/RAs associated to a serving node, it may use this information in the future in order to skip the T-ADS data retrieval, as described in clauseÊ5.2.2.1 (IDR/IDA commands). Subscribed-VSRVCC AVP shall be present within the Subscription-Data AVP sent within a ULA only if the user is subscribed to the SRVCC and vSRVCC. If the UE is allowed to use Proximity-based Services in the visited PLMN, the HSS shall include ProSe-Subscription-Data AVP within the Subscription-Data AVP sent within a ULA. If the HSS receives the SGs MME identity and if the HSS supports this information element, the HSS shall store it for use with VLR restoration. If the HSS receives Update Location Request over both the S6a and S6d interfaces then based on the following conditions the HSS concludes if the UE is served by the MME and SGSN parts of the same combined MME/SGSN: - if both the messages contain the same SGSN number; or - if the Diameter identity received over S6a matches with the Diameter identity received over S6d; or - if the Coupled-Node-Diameter-ID AVP received over S6a interface matches with the Diameter identity received within Origin-Host AVP over S6d interface OR if the Coupled-Node-Diameter-ID AVP received over S6d interface matches with the Diameter identity received within Origin-Host AVP over S6a interface. If the HSS supports the handling of access restrictions for adjacent PLMNs, and it receives a list of adjacent PLMNs from the MME/SGSN, the HSS may send the associated Access Restriction Data, according to local operator policies, in the Adjacent-Access-Restriction-Data AVP, so the MME/SGSN can use this information to allow, or prevent, inter-RAT inter-PLMN handovers towards any of the PLMNs indicated by the HSS. The HSS shall not include in the list of Adjacent-Access-Restriction-Data the PLMN-ID, and its access restrictions, of the current PLMN where the MME/SGSN is located, since this information is already conveyed in the Access-Restriction-Data AVP inside the Subscription-Data AVP. If the HSS supports Monitoring events and receives a Supported-Services AVP it shall only trigger those services which are supported by the MME/SGSN. If the HSS has previously received over SWx (see 3GPPÊTSÊ29.273Ê[59]) the identity of the PDN-GW to be used for the establishment of emergency PDN connections, it shall include it as part of the Subscription-Data AVP (in the Emergeny-Info AVP), in the Update Location response to the MME. If the UE is allowed to use V2X service in the visited PLMN and the MME supports V2X service, the HSS shall include V2X-Subscription-Data AVP into Subscription-Data AVP within the ULA command. If the MME/SGSN supports the ""External-Identifier"" feature, the HSS shall include the External-Identifier associated with Monitoring Event Configuration in the External-Identifier AVP if populated in the subscription. When multiple External Identifiers are defined for a same subscription, the HSS shall send a default External Identifier in the External-Identifier AVP of the Subscription-Data AVP, and shall include a specific External Identifier (if different from the default External Identifier) associated to each Monitoring Event Configuration in the External-Identifier AVP of each Monitoring-Event-Configuration AVP occurrence inside the Subscription-Data AVP. The Aerial-UE-Subscription-Information AVP shall be present within the Subscription-Data AVP sent within a ULA only if the user has Aerial UE subscription information. 5.2.1.2 Cancel Location 5.2.1.2.1 General The Cancel Location Procedure shall be used between the HSS and the MME and between the HSS and the SGSN to delete a subscriber record from the MME or SGSN. The procedure shall be invoked by the HSS and is used: - to inform the MME or SGSN about a subscription withdrawal, or a change in the subscriber profile that does not allow PS services anymore (e.g., the Network Access Mode does not allow PS services), or a change in the subscriber profile that does not allow access to EPC anymore, or - to inform the MME or SGSN about an ongoing update procedure i.e. MME or SGSN change or - to inform the MME or SGSN about an initial attach procedure. This procedure is mapped to the commands Cancel-Location-Request/Answer (CLR/CLA) in the Diameter application specified in clause 7. Table 5.2.1.2.1/1 specifies the involved information elements for the request. Table 5.2.1.2.1/2 specifies the involved information elements for the answer. Table 5.2.1.2.1/1: Cancel Location Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Cancellation Type (See 7.3.24) Cancellation-Type M Defined values that can be used are: - MME-Update Procedure, - SGSN-Update Procedure, - Subscription Withdrawal, - Update Procedure_IWF, - Initial Attach Procedure. CLR Flags (See 7.3.152) CLR-Flags O This Information Element contains a bit mask. See 7.3.152 for the meaning of the bits and the condition for each bit to be set or not. Table 5.2.1.2.1/2: Cancel Location Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M The result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). 5.2.1.2.2 Detailed behaviour of the MME and the SGSN When receiving a Cancel Location request the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_SUCCESS is returned. If it is known, the MME or SGSN shall check the Cancellation Type and act accordingly. If the Cancellation Type is ""Subscription Withdrawal"", the MME or SGSN shall delete the subscription data and detach the UE; in addition, if the Reattach-Required flag is set, the MME or SGSN shall indicate to the UE to initiate an immediate re-attach procedure, as described in 3GPPÊTSÊ23.401Ê[2] and 3GPPÊTSÊ23.060Ê[12]. A result code of DIAMETER_SUCCESS shall be returned. If a cancellation type of ""Initial Attach Procedure"" is received, the MME or SGSN shall not delete the subscription data. For details see 3GPPÊTSÊ23.401Ê[2] and 3GPPÊTSÊ23.060Ê[12]. If the MME receives this cancelation type, and it is registered for SMS, it shall consider itself as unregistered for SMS. Also in this case a result code of DIAMETER_SUCCESS shall be returned. When a UE is served by a single combined MME/SGSN for both E-UTRAN and non-E-UTRAN access, the combined MME/SGSN shall check the Cancellation-Type. If it indicates Subscription Withdrawal or Update Procedure_IWF, the CLR is processed both in the MME part and in the SGSN part of the combined node. If it indicates Initial Attach Procedure, and if the CLR-Flags AVP is received and supported by the combined MME/SGSN, the CLR is processed only in the affected part of the combined node as indicated by the ""S6a/S6d-Indicator"" flag in the CLR-Flags AVP. Otherwise, the CLR is processed only in the affected part of the combined node and subscription data are kept for the not affected part. 5.2.1.2.3 Detailed behaviour of the HSS The HSS shall make use of this procedure when the subscription is withdrawn by the HSS operator, and when the HSS detects that the UE has moved to a new MME or SGSN area, and when EPC access is not allowed due to Core Network Restrictions. The HSS+UDM shall also make use of this procedure when the HSS+UDM detects that the UE has moved to a new AMF area, if the AMF indicates to the HSS+UDM to cancel MME and/or SGSN. The HSS+UDM shall include a cancellation type as specified in clauseÊ5.4.2.2 of 3GPP TSÊ29.563Ê[70]. The HSS shall include a cancellation type of ""Subscription Withdrawal"" if the subscription is withdrawn by the operator, or if the subscriber profile does not allow PS services anymore, or if the Core Network Restrictions do not allow access to EPC anymore; the HSS may set the Reattach-Required flag in order to request the MME or the SGSN to trigger an immediate reattachment of the UE. The HSS shall include a cancellation type of ""MME Update Procedure"" if the UE moved to a new MME area. The HSS shall include a cancellation type of ""SGSN Update Procedure"" if the UE moved to a new SGSN area. The HSS shall include a cancellation type of ""Initial Attach Procedure"" if the cancel location is initiated due to an Initial Attach from the UE. The HSS shall include the CLR-Flags with the ""S6a/S6d-Indicator"" flag indicating the affected part of the combined node if the cancel location is to be sent to a combined MME/SGSN during initial attach procedure. 5.2.1.3 Purge UE 5.2.1.3.1 General The Purge UE Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to indicate that the subscriber's profile has been deleted from the MME or SGSN either by an MMI interaction or automatically, e.g. because the UE has been inactive for several days. This procedure is mapped to the commands Purge-UE-Request/Answer (PUR/PUA) in the Diameter application specified in clause 7. Table 5.2.1.3.1/1 specifies the involved information elements for the request. Table 5.2.1.3.1/2 specifies the involved information elements for the answer. Table 5.2.1.3.1/1: Purge UE Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. PUR-Flags (See 7.3.149) PUR-Flags O If present, this Information Element shall contain a bitmask. See clauseÊ7.3.149 for the meaning of the bits. EPS-Location-Information (See 7.3.111) EPS-Location-Information C This Information Element shall contain the last known EPS-Location Information of the purged UE. Shall be present if available. Table 5.2.1.3.1/2: Purge UE Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indication success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable: - User Unknown PUA-Flags (See 7.3.48) PUA-Flags C This Information Element shall contain a bit mask. See clauseÊ7.3.48 for the meaning of the bits. It shall be present only when the Result-Code AVP is DIAMETER_SUCCESS. 5.2.1.3.2 Detailed behaviour of the MME and the SGSN The MME shall make use of this procedure to set the ""UE Purged in the MME"" flag in the HSS when the subscription profile is deleted from the MME database due to MMI interaction or after long UE inactivity. The SGSN shall make use of this procedure to set the ""UE Purged in SGSN"" flag in the HSS when the subscription profile is deleted from the SGSN database due to MMI interaction or after long UE inactivity. The combined MME/SGSN when using a single Origin-Host identity shall make use of this procedure to set the ""UE Purged in MME"" and ""UE Purged in SGSN"" flags in the HSS when the subscription profile is deleted from the common MME/SGSN database due to MMI interaction or after long UE inactivity on all registered accesses. If the HSS has indicated support for the Partial Purge feature (see clauseÊ7.3.10), the combined MME/SGSN may also indicate to the HSS a Purge of the UE in only one of the serving nodes in the combined node (either in the MME or in the SGSN). The combined MME/SGSN when using different Origin-Host identities for MME and SGSN shall send two Purge UE Requests as if it was not combined. When receiving a Purge UE response from the HSS the MME shall check the Result Code. If it indicates success, the MME shall check the PUA flag ""freeze M-TMSI"", and if set freeze the M-TMSI i.e. block it for immediate re-use. When receiving a Purge UE response from the HSS the SGSN shall check the Result Code. If it indicates success, the SGSN shall check the PUA flag ""freeze P-TMSI"", and if set freeze the P-TMSI i.e. block it for immediate re-use. When receiving a Purge UE response from the HSS the combined MME/SGSN shall check the Result Code. If it indicates success, the combined MME/SGSN shall check the PUA flag ""freeze M-TMSI"" and ""freeze P-TMSI"", and if set freeze the M-TMSI and/or the P-TMSI i.e. block it for immediate re-use. 5.2.1.3.3 Detailed behaviour of HSS When receiving a Purge UE request the HSS shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If it is known, the HSS shall set the result code to DIAMETER_SUCCESS and compare the received identity in the Origin-Host with the stored MME-Identity and with the stored SGSN-Identity. If the received identity matches the stored MME-identity and the stored SGSN-Identity (no matter whether the node type indicator bit in ULR-Flags was set or clear), then: - if the HSS supports the Partial Purge feature (see clauseÊ7.3.10), and the combined MME/SGSN indicated that the UE was purged in only one of the serving nodes, the HSS shall set the PUA flags according to the serving node where the purge was done (i.e., either ""freeze M-TMSI"" if the purge was done in the MME, or ""freeze P-TMSI"" if the purge was done in the SGSN); similarly, the HSS shall either set the ""UE purged in MME"" flag and store the received last known MME Location information of the purged UE, or set the ""UE purged in SGSN"" flag and store the received last known SGSN-Location Information of the purged UE, accordingly; - if the HSS does not support the Partial Purge feature, or the combined MME/SGSN did not indicate that the UE was purged in only one of the serving nodes, the HSS shall set the PUA flags ""freeze M-TMSI"" and ""freeze P-TMSI"" in the answer message and set the flag ""UE purged in MME"" and ""UE purged in SGSN"" and store the received last known EPS Location Information of the purged UE; If the received identity matches the stored MME-identity but not the stored SGSN-identity, the HSS shall set the PUA flag ""freeze M-TMSI"" and clear the PUA flag ""freeze P-TMSI"" in the answer message, set the flag ""UE purged in MME"" and store the received last known MME location information of the purged UE; If the received identity matches the stored SGSN-identity but not the stored MME-identity, the HSS shall set the PUA flag ""freeze P-TMSI"" and clear the PUA flag ""freeze M-TMSI"" in the answer message and set the flag ""UE purged in SGSN"" and store the received last known SGSN location information of the purged UE; If the received identity does not match the stored MME-identity and does not match the stored SGSN-identity, the HSS shall clear the PUA flags ""freeze M-TMSI"" and ""freeze P-TMSI in the answer message. 5.2.2 Subscriber Data Handling Procedures 5.2.2.1 Insert Subscriber Data 5.2.2.1.1 General The Insert Subscriber Data Procedure shall be used between the HSS and the MME and between the HSS and the SGSN for updating and/or requesting certain user data in the MME or SGSN in the following situations: - due to administrative changes of the user data in the HSS and the user is now located in an MME or SGSN, i.e. if the user was given a subscription and the subscription has changed; subscription data that are applicable to MMEs but not to SGSNs should not be sent to the SGSN unless the SGSN is known to be a combined MME/SGSN; similarly subscription data that are applicable to SGSNs but not to MMEs should not be sent to the MME unless the MME is known to be a combined MME/SGSN. - the operator has applied, changed or removed Operator Determined Barring for this user; - activate subscriber tracing in the MME or the SGSN; - to indicate to the MME or SGSN that the HSS has requested to be notified when the UE has become reachable; - to request from the MME or SGSN the necessary data to support the T-ADS functionality; - to retrieve location information and/or state information from the MME or the SGSN; - to retrieve from the MME or the SGSN the Local Time Zone of the location in the visited network where the UE is attached; - to update the STN-SR (e.g., as a result of an Sh interaction with an SCC-AS). - to update the MME/SGSN with the identity of a dynamically allocated PDN GW as a result of the first PDN connection establishment associated with an APN over non 3GPP access or 5GS.. - to update the MME with the identity of a PDN GW for Emergency Services as a result of the PDN connection establishment for Emergency Services over non 3GPP access. - to indicate to the MME that the HSS has deregistered the MME for SMS. - to indicate to the MME/SGSN that the HSS-based P-CSCF restoration procedure, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4, shall be executed. - to request the MME or the SGSN to configure and report the detection of Monitoring events, or delete stored Monitoring events configuration. - to update the MME with the O&M configured desired Active Time for power saving mode (PSM), or with the value received from the SCEF if Active Time is provided as part of the Suggested-Network-Configuration AVP. - to update the MME with the O&M configured desired Core Network Restrictions to restrict/allow mobility to 5GC. If the HSS knows that the UE has attached to the MME and SGSN parts of the same combined MME/SGSN via both the E-UTRAN and UTRAN/GERAN (refer to clauseÊ5.2.1.1.2, 5.2.1.1.3 for further details), the HSS should invoke this procedure for a single time to update and/or request certain user data in the combined MME/SGSN, i.e. the HSS should not invoke this procedure for each of the MME and the SGSN registered respectively. If the Node-Type-Indicator information has been previously received as cleared in the ULR-Flags and if the MME has not been registered for SMS during update location procedure for the MME, the HSS may skip any change of the SMS related subscription data and consequently does not have to make use of the Insert Subscriber Data procedure to update the SMS subscription data in the MME. This procedure is mapped to the commands Insert Subscriber Data-Request/Answer (IDR/IDA) in the Diameter application specified in clauseÊ7. Table 5.2.2.1.1/1 specifies the involved information elements for the request. Table 5.2.2.1.1/2 specifies the involved information elements for the answer. Table 5.2.2.1.1/1: Insert Subscriber Data Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Subscription Data (See 7.3.2) Subscription-Data M This Information Element shall contain the part of the subscription profile that either is to be added to the subscription profile stored in the MME or SGSN or is replacing a part of the subscription profile stored in the MME or SGSN. IDR Flags (See 7.3.103) IDR-Flags C This Information Element shall contain a bit mask. See 7.3.103 for the meaning of the bits. Reset-IDs (See 7.3.184) Reset-ID O The Reset-ID uniquely identifies a fallible resource in the HSS on which the user (IMSI) depends. In the event of a restart of the fallible resource a Reset message containing the Reset-ID will exactly identify the impacted subscribers. Table 5.2.2.1.1/2: Insert Subscriber Data Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. A combined MME/SGSN that makes use of separate origin host values in Update Location Request messages sent on S6a and Update Location Request messages sent on S6d can detect whether the IDR from HSS was sent to the MME or to the SGSN. IDA sent from such combined MME/SGSN corresponds to the MME's or the SGSN's supported features respectively. A combined MME/SGSN that makes use of a common origin host value in Update Location Request messages sent on S6a and Update Location Request messages sent on S6d cannot detect whether the IDR from HSS was sent to the MME or to the SGSN. IDA sent from such combined MME/SGSN uses the union of the MME's and the SGSN's supported features. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. Result-Code AVP shall be used to indicate success / errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown IMS Voice over PS Sessions Supported (See 7.3.106) IMS-Voice-Over-PS-Sessions-Supported C If available to the serving node, this information element shall indicate whether or not ""IMS Voice over PS Sessions"" is supported by the UE's most recently used TA or RA in the serving node (MME or SGSN or combined MME/SGSN). If the UE is in detached state, this information element shall not be included in the response. Last UE Activity Time (See 7.3.108) Last-UE-Activity-Time C If available to the serving node, this information element shall contain the time of the last radio contact with the UE. If the UE is in detached state, this information element shall not be included in the response. RAT Type (See 7.3.13) RAT-Type C If available to the serving node, this information element shall indicate the RAT Type of the access where the UE was present at the time of the last radio contact. If the UE is in detached state, this information element shall not be included in the response. IDA-Flags (See 7.3.47) IDA-Flags C This Information Element shall contain a bit mask. See 7.3.47 for the meaning of the bits. EPS-User-State (See 7.3.110) EPS-User-State C This Information Element shall contain the EPS-User State. It shall be present if EPS user state was requested within IDR. EPS-Location-Information (See 7.3.111) EPS-Location-Information C This Information Element shall contain the EPS-Location Information. It shall be present if EPS location information was requested within IDR. Local Time Zone (See 7.3.156) Local-Time-Zone C This Information Element shall contain information on the Local Time Zone of the location in the visited network where the UE is attached. It shall be present if the Local Time Zone was requested within IDR. Monitoring Event Report Monitoring-Event-Report C This Information Element shall contain the report of Monitoring event. It shall be present if Monitoring event configuration is included within IDR and any of the requested Monitoring events are available to be reported. (see NOTE 1) Monitoring Event Config Status Monitoring-Event-Config-Status C This Information Element shall be present if Monitoring event configuration is included in IDR. It shall contain all the configuration status for each Monitoring event that was requested. Supported Services (3GPPÊTSÊ29.336Ê[54]) Supported-Services O If present, this Information Element shall contain AVPs indicating details of the services supported by the MME/SGSN. NOTE 1: In IWK-SCEF scenarios, an event is available to be reported by the visited MME only if the event is considered as authorized by the visited MME after checking with the IWK-SCEF. Otherwise, the immediate report shall be not be sent in this command (S6a/IDA), and it shall be sent over T6a using RIR command (see 3GPPÊTSÊ29.128Ê[63]. 5.2.2.1.2 Detailed behaviour of the MME and the SGSN When receiving an Insert Subscriber Data request the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If it is known, the MME or SGSN shall replace the specific part of the stored subscription data with the received data, or shall add the received data to the stored data. When receiving the APN-Configuration-Profile AVP within the Subscription-Data AVP, the MME or SGSN shall check the All-APN-Configurations-Included-Indicator value. If it indicates ""All_APN_CONFIGURATIONS_INCLUDED"", the MME or SGSN shall delete all stored APN-Configurations and then store all received APN-Configurations. Otherwise, the MME or SGSN shall check the Context-Identifier value of each received APN-Configuration. If the Context-Identifier of a received APN-Configuration matches a Context-Identifier of a stored APN-Configuration, the MME or SGSN shall replace the stored APN-Configuration with the received APN-Configuration. If the Context-Identifier of a received APN-Configuration does not match a Context-Identifier of a stored APN-Configuration, the MME or SGSN shall add the received APN-Configuration to the stored APN-Configurations. If the addition or update of the subscription data succeeds in the MME or SGSN, the Result-Code shall be set to DIAMETER_SUCCESS. The MME or SGSN shall then acknowledge the Insert Subscriber Data message by returning an Insert Subscriber Data Answer. For each of the received APN-Configurations in the APN-Configuration-Profile, if both the MIP6-Agent-Info and the PDN-GW-Allocation-Type AVPs are absent in the APN-Configuration AVP, the MME or SGSN shall perform the PGW selection (static or dynamic) according to the local configuration. If MIP6-Agent-Info is present, and PDN-GW-Allocation-Type is not present, this means that the PDN GW address included in MIP6-Agent-Info has been statically allocated. If the MME/SGSN supports interworking with Gn/Gp-SGSNs, it shall ensure that the context identifier sent over GTPv1 for each of the received APN-Configurations is within the range of 1 and 255. NOTE 1: If the MME/SGSN receives from HSS a Contex-Identifier value higher than 255, how this value is mapped to a value between 1 and 255 is implementation specific. If the MME is requested to notify the HSS when the UE becomes reachable, the MME shall set the URRP-MME parameter to indicate the need to inform the HSS about UE reachability, e.g. when the next NAS activity from the UE is detected. If the SGSN is requested to notify the HSS when the UE becomes reachable, the SGSN shall set the URRP-SGSN parameter to indicate the need to inform the HSS about UE reachability, e.g. when the next NAS activity from the UE is detected. When receiving GPRS-Subscription-Data AVP within the Subscription-Data AVP, the SGSN or combined MME/SGSN shall check the Complete-Data-List-Included-Indicator value. If it indicates ""All_PDP_CONTEXTS_INCLUDED"", the SGSN or combined MME/SGSN shall delete all stored PDP-Contexts and then store all received PDP-Contexts. Otherwise, the SGSN or combined MME/SGSN shall check the Context-Identifier value of each received PDP-Context. If the Context-Identifier of a received PDP-Context matches a Context-Identifier of a stored PDP-Context, the SGSN or combined MME/SGSN shall replace the stored PDP-Context with the received PDP-Context. If the Context-Identifier of a received PDP-Context does not match a Context-Identifier of a stored PDP-Context, the SGSN or combined MME/SGSN shall add the received PDP-Context to the stored PDP-Contexts. If the MME or SGSN receives an empty Subscription-Data AVP, it shall take no action with regard to the stored subscription data. When receiving HPLMN-ODB AVP within the Subscription-Data AVP, the MME or SGSN shall replace stored HPLMN-ODB data (if any) with the received information rather than add the received information to the stored information. Unsupported Barring categories need not be stored. When receiving Operator-Determined-Barring AVP within the Subscription-Data AVP, the MME or SGSN shall replace stored ODB subscription information (if any) with the received information rather than add the received information to the stored information. Unsupported Barring categories need not be stored. When receiving Access-Restriction-Data or Adjacent-Access-Restriction-Data AVPs within the Subscription-Data AVP, the MME or SGSN shall replace the corresponding stored information (if any) with the new received information, rather than adding received information to stored information. The handling of access restrictions per-PLMN is defined in 3GPPÊTSÊ23.221Ê[53], clauseÊ6.3.5a and in 3GPPÊTSÊ23.401Ê[2] clauseÊ4.3.28. When receiving APN-OI-Replacement AVP within the Subscription-Data AVP, the MME or SGSN shall replace the stored information (if any) with the received information. When receiving Regional-Subscription-Zone-Code AVP within the Subscription-Data AVP, the MME or SGSN shall replace stored Zone Codes (if any) with the received information rather than add the received information to the stored information. MMEs and SGSNs that do not support regional subscription need not store zone codes. If due to regional subscription restrictions or access restrictions the entire SGSN area is restricted, SGSN shall report it to the HSS by returning the ""SGSN Area Restricted"" indication within the IDA flags. When receiving CSG-Subscription-Data AVPs within the Subscription-Data AVP the MME or SGSN shall replace all stored information from previously received CSG-Subscription-Data AVPs (if any) with the received information rather than add the received information to the stored information. When receiving Teleservice-List AVP, Call-Barring-Info, or LCS-Info AVP, the MME or SGSN shall replace stored information (if any) with the received information rather than add the received information to the stored information. When receiving ProSe-Subscription-Data AVP, the MME or combined MME/SGSN shall replace stored information (if any) with the received information rather than add the received information to the stored information. When receiving and supporting Reset-ID AVPs within the request, the MME or SGSN shall replace stored information (if any) with received information rather than add received information to stored information."
"When receiving the IDR-Flags with the ""T-ADS Data Request"" bit set, and the UE is in attached state, the MME or SGSN or combined MME/SGSN shall return in the IDA message the time stamp of the UE's most recent radio contact and the associated RAT Type, and an indication of whether or not IMS Voice over PS is supported in the current (and most recently used) TA or RA. If the UE is in detached state, the MME or SGSN or combined MME/SGSN shall answer successfully to the T-ADS request from HSS, but it shall not include any of the T-ADS IEs in the response (IMS Voice over PS Sessions Supported, RAT Type and Last UE Activity Time). When receiving the IDR-Flags with the ""EPS User State Request"" bit and/or ""EPS Location Information Request"" bits set the MME or SGSN shall return the corresponding user information to the HSS. If the serving node is a combined MME/SGSN, and the UE is attached via both E-UTRAN and UTRAN/GERAN on the same node, the combined MME/SGSN shall provide the corresponding user information relevant for both MME and SGSN. If the Current Location Request bit was also set and the UE is in idle mode and is expected to be reachable even when it uses a power saving feature (e.g. extended idle mode DRX or PSM as defined in 3GPPÊTSÊ23.685Ê[55]), then the MME or SGSN or combined MME/SGSN shall page the UE in order to return the most up-to-date corresponding user information. If the Current Location Request bit was also set and either paging is unsuccessful or the UE is not expected to be reachable, then the last known location of the UE shall be returned to the HSS. If the Current Location Request bit was also set and the UE (attached via E-UTRAN) is in connected mode, then the MME or combined MME/SGSN shall use S1AP Location Reporting Control procedure towards the eNB prior to reporting the E-UTRAN Cell Global Identification in order to return the UE's most up-to-date cell information. When the location is returned to the HSS, the MME or the combined MME/SGSN shall provide the age of location information if stored in the MME or the combined MME/SGSN or received from eNB. When receiving the IDR-Flags with only the ""Current Location Request"" bit set (i.e. the ""EPS Location Information Request"" bit is not set), the MME or SGSN or combined MME/SGSN shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. If the ""Local Time Zone Request"" bit was set the MME or SGSN if supported shall provide the Local Time Zone corresponding to the location (e.g. TAI or RAI) of the UE to the HSS. If the MME or SGSN cannot fulfil the received request, e.g. due to a database error or any of the required actions cannot be performed, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. If subscription data are received, the MME or SGSN shall mark the subscription record ""Subscriber to be restored in HSS"". If trace data are received in the subscriber data, the MME or SGSN shall start a Trace Session. For details, see 3GPPÊTSÊ32.422Ê[23]. If the Ext-PDP-Type AVP is present in the PDP-Context AVP, the SGSN or combined MME/SGSN shall ignore the value of the PDP-Type AVP. When receiving the IDR-Flags with the bit ""Remove SMS Registration"" set, the MME shall consider itself unregistered for SMS. If the subscription data received for a certain APN includes WLAN-offloadability AVP, then the MME or SGSN shall determine the offloadability of the UE's PDN Connection(s) to that APN based on subscription data and locally configured policy (e.g. for roaming users or when the subscription data does not include any offloadability indication). NOTE 2: As indicated in clauseÊ7.3.31, if the UE-level access restriction ""HO-To-Non-3GPP-Access Not Allowed"" is set, the offload of PDN Connections to WLAN is not allowed for any APN. When receiving the IDR-Flags with the ""P-CSCF Restoration Request"" bit set, the MME or SGSN or combined MME/SGSN shall execute the procedures for HSS-based P-CSCF Restoration, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4. If the subscription data received for the user includes the DL-Buffering-Suggested-Packet-Count AVP, then the MME or SGSN should take into account the subscription data, in addition to local policies, to determine whether to invoke extended buffering of downlink packets at the SGW for High Latency Communication. Otherwise, the MME or SGSN shall make this determination based on local policies only. When receiving IMSI-Group-Id AVP(s) within the Subscription-Data AVP, the MME or SGSN shall replace stored IMSI-Group Ids (if any) with the received information rather than add the received information to the stored information. In the present clause, if the feature ""Extended Reference IDs"" (see clauseÊ7.3.10) is supported by the HSS and the MME/SGSN, the term ""SCEF Reference ID"" shall refer to the content of the 64-bit long ""SCEF-Reference-ID-Ext"" AVP, and the term ""SCEF Reference ID for Deletion"" shall refer to the content of the 64-bit long ""SCEF-Reference-ID-for-Deletion-Ext"" AVP. When receiving a Monitoring-Event-Configuration in the IDR: - if the SCEF Reference ID for Deletion is present in the IDR, the MME or SGSN shall stop the detection of the Monitoring event related to the SCEF Reference ID for Deletion and SCEF-ID pair, and shall delete the corresponding Monitoring event configuration data; - if the SCEF Reference ID is present in the IDR but not stored in the MME or SGSN, the MME or SGSN shall store the received Monitoring event configuration data related to the SCEF Reference ID and SCEF-ID pair, and shall start the detection for the specified Monitoring event(s). - if the SCEF Reference ID is present in the IDR and stored in the MME or SGSN, the MME or SGSN shall replace the stored Monitoring event configuration data related to the SCEF Reference ID and SCEF-ID pair with the received information. NOTE 3: In roaming scenarios the MME/SGSN can reply immediately to the HSS without waiting for the outcome of the interaction with the IWK-SCEF. For the monitoring event configurations for which the configuration status have changed since the last status informed to the HSS, the MME/SGSN shall notify the HSS about the outcome of the interaction with the IWK-SCEF as specified in clauseÊ5.2.5.1.2. If the HSS indicates the support of Monitoring event feature to the MME/SGSN and the MME/SGSN supports Monitoring, the MME/SGSN shall include the Supported-Services AVP with Supported-Monitoring-Event included in the IDA command. When receiving the Maximum-Response-Time in Monitoring-Event-Configuration in IDR, the MME shall use the Maximum-Response-Time as the Active Time for the usage of PSM in UE. If not, when the MME receives the Active-Time in subscription data, the MME shall use the Active-Time as the Active Time for the usage of PSM in UE. When receiving AESE-Communication-Pattern AVP(s) within the Subscription-Data AVP with an SCEF Reference ID for which the MME has already stored data, it shall delete the stored data (CP set(s)) and store the received ones. When receiving AESE-Communication-Pattern AVP(s) within the Subscription-Data AVP with one or more SCEF Reference ID for deletion the MME shall delete the data related to the indicated SCEF Reference ID. If the MME and the UE support an Attach without PDN connection (i.e. EMM-REGISTERED without PDN connection) and the PDN-Connection-Restricted flag is set in the received Subscription-Data-Flags AVP, the MME shall not establish any non-emergency PDN connection and shall tear down any existing non-emergency PDN connection for this user. If the subscription data received for the user includes the Preferred-Data-Mode AVP, for an IP APN configuration or for a non-IP APN configuration with SGi based delivery, then the MME should (if the subscriber is not roaming) or may (if the subscriber is roaming) take into account the subscription data, in addition to local policies and the UE's Preferred Network Behaviour, to determine whether to transmit the traffic associated with this APN over the User Plane and/or over the Control Plane. Otherwise, the MME shall make this determination based on local policies and the UE's Preferred Network Behaviour only. If the MME subscription data received for the user includes the Emergency-Info AVP, the MME shall use the PDN-GW identity contained in such AVP as the PDN-GW used to establish emergency PDN connections with the emergency APN, for non-roaming authenticated UEs requesting the handover of an emergency PDN connection if the MME is configured to use a dynamic PDN-GW for emergency services for such user. When receiving V2X-Subscription-Data in the IDR, the MME shall determine whether the UE is authorized to use V2X communication over PC5 according to V2X subscription data and UE provided network capability. If the UE is authorized to use V2X communication over PC5, the MME shall store the ""V2X service authorized"" indication together with the UE AMBR used for PC5 interface (i.e. UE-PC5-AMBR), and provide such information to the eNodeB when needed. If the MME/SGSN receives from the HSS an Insert Subscriber Data request without the bit set for ""NR as Secondary RAT"" in the Feature-List AVP, the MME/SGSN, based on local policy, may restrict access for NR as secondary RAT when all relevant entities except HSS supports it. If the MME receives from the HSS Insert Subscriber Data request containing in the subscription data the Core-Network-Restrictions AVP with the bit ""5GC not allowed"" set, the MME shall restrict mobility towards 5GC. When receiving Paging-Time-Window AVPs within the Subscription-Data AVP, the MME or SGSN shall replace stored information (if any) with the received information rather than add the received information to the stored information. 5.2.2.1.3 Detailed behaviour of HSS The HSS shall make use of this procedure to replace a specific part of the user data stored in the MME or SGSN with the data sent, or to add a specific part of user data to the data stored in the MME or SGSN. The HSS shall also make use of this procedure to indicate to the MME that it is no longer registered for SMS. NOTE: When a Cancel Location message is required for other reasons, the use of IDR to indicate that the MME is no longer registered for SMS is not needed (see clauseÊ5.2.1.2). Subscriber-Status AVP shall be present in the Subscription-Data AVP, sent within IDR, if the current value in the MME or SGSN needs to be changed. To remove all Operator Determined Barring Categories the Subscriber-Status shall be set to ""SERVICE_GRANTED"". If Subscriber-Status AVP is present and set to OPERATOR_DETERMINED_BARRING, the Operator-Determined-Barring AVP or HPLMN-ODB AVP shall also be present in the Subscription-Data AVP. Access-Restriction-Data AVP shall be present within the Subscription-Data AVP send within an IDR if the information stored in the MME or SGSN needs to be modified. APN-OI-Replacement AVP shall be present in the Subscription-Data AVP sent within an IDR, if the UE level APN-OI-Replacement has been added or modified in the HSS. The APN-Configuration-Profile AVP shall be present in the Subscription-Data AVP sent within an IDR if the Context-Identifier associated with the default APN configuration is changed or at least one APN-Configuration is added or modified by the HSS. If the default APN is changed in the HSS, the APN-Configuration-Profile AVP shall contain the Context-Identifier associated with the default APN and the APN-Configuration AVP for the default APN. The default APN Configuration shall not contain the Wildcard APN (see 3GPPÊTSÊ23.003Ê[3], clauseÊ9.2); the default APN shall always contain an explicit APN. The EPS-Subscribed-QoS-Profile AVP and the AMBR AVP shall be present in the APN-Configuration AVP when the APN-Configuration AVP is sent in the APN-Configuration-Profile AVP and when the APN-Configuration-Profile AVP is sent within a IDR (as part of the Subscription-Data AVP). If the GPRS-Subscription-Data-Indicator information has been previously received as set in the ULR-Flags during update location procedure for the SGSN or combined MME/SGSN, the HSS shall make use of this procedure to replace the GPRS Subscription Data stored in the SGSN or combined MME/SGSN with the data sent or to add a PDP-Context to the data stored in the SGSN or combined MME/SGSN. ProSe-Subscription-Data AVP shall be present in the Subscription-Data AVP sent within an IDR, if the ProSe Subscription data has been added or modified in the HSS. If the HSS receives a message (e.g. via MAP ATM or Sh Sh-Subs-Notif) from a Service Related Entity (e.g. IP-SM-GW) indicating that the UE is unreachable, - the HSS shall associate the subscription to UE reachability of the service-related entity to the URRP-MME and the URRP-SGSN parameters (if not already done) - and if the URRP-MME and/or the URRP-SGSN parameters were not already set (i.e. at least one service-related entity already listed as subscribed), the HSS shall - set the URRP-MME and/or URRP-SGSN parameters and - send an IDR command to the registered MME and/or to the registered SGSN including the ""UE Reachability Request flag"" in the IDR Request Flags in order to request the MME and/or SGSN to notify the HSS when the UE becomes reachable again, unless the HSS knows from the previous ULR command that the registered MME and/or the registerd SGSN do not support UE reachability notifications. If the IDR is sent for the only purpose to request the MME and/or SGSN about the UE reachability status notification, the Subscription-Data AVP shall be included empty. If the HSS has received a message from a service related entity requesting EPS User State and/or EPS Location Information without the Serving Node Indication IE, the HSS shall set the ""EPS User State Request"" bit and/or ""EPS Location Information Request"" bit respectively in the IDR-Flags. The HSS may optionally also set the ""Current Location Request"" bit along with the ""EPS Location Information Request"" bit in the IDR-Flags, if the most up-to-date set of information is needed, unless the HSS knows from the previous ULR command that the registered MME and/or the registered SGSN do not support State/Location Information retrieval. If the IDR is sent only for the purpose of requesting the MME or the SGSN User State or Location Information, the Subscription-Data AVP included shall be empty. If the HSS cannot request EPS Location Information from the MME/SGSN e.g. because the UE is purged from the MME/SGSN, the HSS may make use of stored EPS Location information received in a previous IDA or PUR message. If the HSS has received a message from an AS requesting the current access network's support status of ""IMS Voice over PS Sessions"", and there is no indication about homogeneous support of IMS Voice over PS Sessions in all the serving nodes currently registered in HSS for the UE, the HSS shall set the ""T-ADS Data Request flag"" in the IDR Request Flags, unless the HSS knows from the previous ULR command that the registered MME and/or the registered SGSN do not support T-ADS data retrieval. If the IDR is sent for the only purpose to retrieve the ""IMS Voice over PS Sessions Supported"" indication from the MME or SGSN, the Subscription-Data AVP included shall be empty. If the HSS has received a message from an AS requesting the Local Time Zone, the HSS shall set the "" Local Time Zone Request"" bit in the IDR-Flags, unless the HSS knows from the previous ULR command that the registered MME and/or the registered SGSN do not support Local Time Zone retrieval. If the IDR is sent only for the purpose of requesting the Local Time Zone, the Subscription-Data AVP included shall be empty. If the HSS received an indication in a former ULR command from the MME or SGSN about homogeneous support of IMS Voice over PS Sessions in all TA/RAs associated to that serving node, it may use this information to skip the retrieval of T-ADS data. This can only be done if all the registered serving nodes in HSS for the UE indicated in ULR the same type of homogeneous support (i.e. both serving nodes indicated ""SUPPORTED"", or both serving nodes indicated ""NOT_SUPPORTED""); otherwise, the retrieval of T-ADS data shall be done, to receive the time of the last radio contact with the UE. All APN and PGW-ID pairs stored in the HSS not associated with an explicit APN subscription, (i.e. the access to that APN has been authorized as a consequence of having the Wildcard APN in the user subscription), shall be included by the HSS inside the APN context of the Wildcard APN, as multiple instances of the Specific-APN-Info AVP. When receiving an Insert Subscriber Data answer with ""SGSN Area Restricted"" the HSS shall set the SGSN area restricted flag as ""SGSN area restricted"". Subscribed-VSRVCC AVP may be present within the Subscription-Data AVP sent within an ISR only if the user is subscribed to the SRVCC and vSRVCC. If the HSS determines that the MME shall be unregistered for SMS it shall set the ""Remove SMS Registration"" bit in the IDR-Flags. If the IDR is sent for the only purpose to indicate that the MME is no longer registered for SMS, the Subscription-Data AVP shall be included empty. If the HSS needs to request to the MME/SGSN the execution of the HSS-based P-CSCF restoration procedure, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4, the HSS shall set the ""P-CSCF Restoration Request"" bit in the IDR-Flags, if supported by the MME/SGSN. If the IDR is sent only for the purpose of requesting the execution of the HSS-based P-CSCF restoration procedures, the Subscription-Data AVP included shall be empty. If the HSS receives a SCEF request to configure Monitoring events for the UE to be handled by the MME/SGSN or receives a SCEF request for deleting Monitoring events for the UE in the MME/SGSN, the HSS shall include Monitoring-Event-Configuration AVP(s) in the Subscription-Data AVP sent within the IDR. If the HSS has registered both an MME and an SGSN as serving nodes for a given user, and both nodes are not part of a same combined MME/SGSN node, the HSS shall send the Monitoring-Event-Configuration AVP(s) to each one of the serving nodes that supports the Monitoring event service. If the HSS receives the IDA with Monitoring-Event-Report AVP(s), the HSS shall forward the Monitoring-Event-Report AVP(s) to the SCEF associated to those Monitoring events. If the HSS does not receive a SCEF request to configure Monitoring events for the UE to be handled by the MME/SGSN and does not receive an Active Time with the Suggested-Network-Configuration AVP , the HSS may send an O&M configured desired Active Time value within the Active-Time AVP. If the HSS receives a Supported-Services AVP it shall only trigger those services which are supported by the MME/SGSN. If the HSS has previously received over SWx (see 3GPPÊTSÊ29.273Ê[59]) the identity of the PDN-GW to be used for the establishment of emergency PDN connections, it shall send it to the registered MME (if any) in the IDR command as part of the Subscription-Data AVP (in the Emergeny-Info AVP). If V2X subscription data has been added or modified in the HSS, the HSS shall include the V2X-Subscription-Data AVP in the Subscription-Data AVP sent within an IDR. If the External-Identifier associated with Monitoring Event Configuration for the UE has been added or modified in the HSS and the MME/SGSN supports the ""External-Identifier"" feature, the HSS shall include the External-Identifier AVP in the Subscription-Data AVP. When multiple External Identifiers are defined for a same subscription, the HSS shall send a default External Identifier in the External-Identifier AVP of the Subscription-Data AVP, and shall include a specific External Identifier (if different from the default External Identifier) associated to each Monitoring Event Configuration in the External-Identifier AVP of each Monitoring-Event-Configuration AVP occurrence inside the Subscription-Data AVP. The Aerial-UE-Subscription-Information AVP may be present within the Subscription-Data AVP sent within an IDR only if the user has Aerial UE subscription information. If Core Network Restrictions in subscription data (5GC allowed/not allowed) has been added or modified in the HSS, the HSS shall include the Core-Network-Restrictions AVP in the Subscription-Data AVP sent within an IDR. 5.2.2.2 Delete Subscriber Data 5.2.2.2.1 General This procedure shall be used between the MME and the HSS and between the SGSN and the HSS, to remove some data of the HSS user profile stored in the MME or SGSN. The procedure shall be invoked by the HSS and it corresponds to the functional level operation Delete Subscriber Data (see 3GPPÊTSÊ23.401Ê[2]). It shall be used to remove: - a subset (wich may or may not be the complete set of APN configurations) of the APN Configuration Profile for the subscriber from the SGSN or combined MME/SGSN; - a proper subset (i.e. a subset that is not equal to the complete set of APN configurations and does not contain the default APN configuration) of the APN Configuration Profile for the subscriber from the MME; - the regional subscription; - the subscribed charging characteristics; - Session Transfer Number for SRVCC; - trace data; - ProSe subscription data; - Reset-IDs; - MSISDN; - UE Usage Type; - V2X subscription data. - External Identifier(s). If the HSS knows that the UE has attached to the MME and SGSN parts of the same combined MME/SGSN via both E-UTRAN and UTRAN/GERAN(refer to clauseÊ5.2.1.1.2, 5.2.1.1.3 for further details), the HSS should invoke this procedure for a single time to remove some or all data of the HSS user profile stored in the combined MME/SGSN, i.e. not invoke this procedure for each of the MME and the SGSN registered respectively. If the Node-Type-Indicator information has been previously received as cleared in the ULR-Flags and if the MME has not been registered for SMS during update location procedure for the MME, the HSS may skip any removal of the SMS related subscription data and consequently does not have to make use of the Delete Subscriber Data procedure to update the SMS subscription data in the MME. This procedure is mapped to the commands Delete-Subscriber-Data-Request/Answer (DSR/DSA) in the Diameter application specified in clause 7. Table 5.2.2.2.1/1 specifies the involved information elements for the request. Table 5.2.2.2.1/2 specifies the involved information elements for the answer. Table 5.2.2.2.1/1: Delete Subscriber Data Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. DSR Flags (See 7.3.25) DSR-Flags M This Information Element shall contain a bit mask. See 7.3.25 for the meaning of the bits. Trace Reference (See 7.3.64) Trace- Reference C This parameter shall contain the same value as used for the activation of the Trace Session. This element shall be present only if the ""Trace Data Withdrawal"" bit is set in the DSR-Flags. Context Identifier (See 7.3.27) Context-Identifier C This parameter shall identify the PDN subscription context or GPRS-PDP context that shall be deleted. This element shall be present only if the ""PDN subscription contexts Withdrawal"" bit or the ""PDP context withdrawal"" bit is set in the DSR-Flags. In the ""PDN subscription contexts Withdrawal"" case, the Context-Identifier shall not be associated with the default APN configuration. For the compatibility with the MAP protocol as defined in the 3GPPÊTSÊ29.002Ê[24], this parameter shall not have a value of zero. TS Code List (See 7.3.100) TS-Code C This parameter shall contain the teleservice codes that are to be deleted from the subscription. This element shall be present only if the ""SMS Withdrawal"" bit is set in the DSR-Flags and the SMS related teleservice codes are to be deleted. SS Code List (See 7.3.87) SS-Code C This parameter shall contain the supplementary service codes that are to be deleted from the subscription. This element shall be present only if the ""SMS Withdrawal"" bit is set or the ""LCS Withdrawal"" bit is set in the DSR-Flags. SCEF-Id (See 3GPPÊTSÊ29.336Ê[54]) SCEF-ID C This parameter shall contain the identity of the SCEF to which monitoring events that are to be deleted are associated. This element shall be present if the ""Delete monitoring events"" bit is set in the DSR-Flags. eDRX Related RAT List eDRX-Related-RAT C This parameter shall contain the RAT types for which the eDRX Cycle Lengths is to be deleted from the subscription. This element shall be present only if the ""eDRX-Cycle-Length-Withdrawal"" bit is set in the DSR-Flags and the corresponding eDRX Cycle Lengths are to be deleted. If the ""eDRX-Cycle-Length-Withdrawal"" bit is set in DSR-Flags, but the eDRX-Related-RAT AVP is absent in this command, the MME/SGSN shall delete the stored eDRX cycle lengths for all RATs. External Identifiers External-Identifiers O If present, this parameter shall contain the External Identifier(s) to be deleted from the subscriber data; the MME/SGSN shall also delete those monitoring events that include an External-Identifier AVP in their event configuration matching any of the External-Identifiers in this IE. This IE shall be absent if the ""External-Identifier-Withdrawal"" bit is not set in the DSR-Flags. If this IE is absent, and ""External-Identifier-Withdrawal"" bit is set in DSR-Flags, the MME/SGSN shall delete the default External-Identifier in the Subscription-Data AVP and it shall also delete all monitoring events that include an External-Identifier AVP in their event configuration. Table 5.2.2.2.1/2: Delete Subscriber Data Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown DSA Flags (See 7.3.26) DSA-Flags C This Information Element shall contain a bit mask. See 7.3.26 for the meaning of the bits. 5.2.2.2.2 Detailed behaviour of the MME and the SGSN When receiving a Delete Subscriber Data request, the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If it is known, but the Context-Identifier is associated with the default APN configuration, the MME shall not delete the PDN subscription context, and return an error with a Result-Code set to DIAMETER_UNABLE_TO_COMPLY. Otherwise, the MME or SGSN shall delete the corresponding data according to the indication as sent in the request, and acknowledge the Delete Subscriber Data message by returning a Delete Subscriber Data Answer. If an MME receives a Delete Subscriber Data Request with the ""Complete APN Configuration Profile Withdrawal"" bit set in the DSR-Flags AVP, it shall return an error with a Result-Code set to DIAMETER_UNABLE_TO_COMPLY. If the deletion of the subscription data succeeds in the MME or SGSN, the Result-Code shall be set to DIAMETER_SUCCESS. If the Regional Subscription is deleted from the subscription data, the SGSN shall check for its routing areas whether they are allowed or not. If the entire SGSN area is restricted, SGSN shall report it to the HSS by returning the ""SGSN Area Restricted"" indication within the DSA flags. If the EPS Subscription Data is deleted from the subscription data, the MME or SGSN shall check whether all EPS Subscription Data for the subscriber is deleted or if only a subset of the stored EPS Subscription Data for the subscriber is deleted, the MME or SGSN may then deactivate the associated affected active EPS bearers. If the Subscribed Charging Characteristics are deleted from the subscription data, the Gn/Gp-SGSN shall maintain the existing Subscribed Charging Characteristics throughout the lifetime of the existing MM and PDP contexts, see 3GPPÊTSÊ32.251Ê[33]. If the Subscribed Charging Characteristics are deleted from the subscription data, the MME or S4-SGSN shall maintain the existing Subscribed Charging Characteristics throughout the lifetime of the existing IP CAN bearer, see 3GPPÊTSÊ32.251Ê[33]. If the MSISDN is deleted from the subscription data, the MME or SGSN shall maintain the existing MSISDN throughout the lifetime of the existing PDN connections that were established prior to the deletion of the MSISDN (i.e., other network nodes, such as PDN-GW, are not informed of such deletion for the existing PDN connections). The MME/SGSN shall also delete those monitoring events related to the deleted MSISDN. If the MME or SGSN cannot fulfil the received request for other reasons, e.g. due to a database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. In this case, the MME or SGSN shall mark the subscription record ""Subscriber to be restored in HSS"". If trace data are deleted from the subscription data, the MME or SGSN shall deactivate the Trace Session identified by the trace reference. For details, see 3GPPÊTSÊ32.422Ê[23]. If External Identifiers are requested to be deleted from the subscription data, the MME/SGSN shall check whether any of the identifiers to be deleted match the default External-Identifier provided by HSS in the Subscrition-Data AVP (unless all External Identifiers are requested to be deleted from the subscription); in such case, the MME/SGSN shall reject the request and return an error with a Result-Code set to DIAMETER_UNABLE_TO_COMPLY (if default External Identifier is wanted to be deleted, no External Identifier must be provided in the request). The MME/SGSN shall also delete those monitoring events related to the deleted External Identifiers, or all monitoring events associated to any External Identifier if default External Identifier is deleted. 5.2.2.2.3 Detailed behaviour of the HSS The HSS shall make use of this procedure to remove deleted subscription data from the MME or SGSN. The HSS shall make use of this procedure to remove deleted GPRS Subscription Data from the SGSN or combined MME/SGSN if the GPRS-Subscription-Data-Indicator information has been previously received as set in the ULR-Flags during update location procedure for the MME. The HSS shall not set the ""Complete APN Configuration Profile Withdrawal"" bit in the DSR-Flags AVP when sending a Delete Subscriber Data Request to an MME, since the default APN shall always be present in an MME. When receiving a Delete Subscriber Data Answer with ""SGSN Area Restricted"" the HSS shall set the SGSN area restricted flag as ""SGSN area restricted"". 5.2.3 Authentication Procedures 5.2.3.1 Authentication Information Retrieval 5.2.3.1.1 General The Authentication Information Retrieval Procedure shall be used by the MME and by the SGSN to request Authentication Information from the HSS. This procedure is mapped to the commands Authentication-Information-Request/Answer (AIR/AIA) in the Diameter application specified in clause 7. Table 5.2.3.1.1/1 specifies the involved information elements for the request. Table 5.2.3.1.1/2 specifies the involved information elements for the answer. Table 5.2.3.1.1/1: Authentication Information Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Requested E-UTRAN Authentication Info (See 7.3.11) Requested-EUTRAN-Authentication-Info C This information element shall contain the information related to authentication requests for E-UTRAN. Requested UTRAN/GERAN Authentication Info (See 7.3.12) Requested-UTRAN-GERAN Authentication-Info C This information element shall contain the information related to authentication requests for UTRAN or GERAN. Visited PLMN ID (See 7.3.9) Visited-PLMN-ID M This IE shall contain the MCC and the MNC of the visited PLMN, see 3GPPÊTSÊ23.003Ê[3]. AIR Flags (See 7.3.201) AIR-Flags O This IE, if present, contains a bit mask. See clauseÊ7.3.201 for the meaning of the different bits. Table 5.2.3.1.1/2: Authentication Information Answer Information element name Mapping to Diameter AVP Cat. Description Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. This IE shall contain the Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown - Unknown EPS Subscription - Authentication Data Unavailable Error-Diagnostic Error-Diagnostic O If the Experimental Result indicated ""Unknown EPS Subscription"", Error Diagnostic may be present to indicate whether or not GPRS subscription data are subscribed (i.e. whether or not Network Access Mode stored in the HSS indicates that only CS service is allowed). Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Authentication Info (See 7.3.17) Authentication-Info C This IE shall contain the Authentication Vectors. UE Usage Type (See 7.3.202) UE-Usage-Type C This IE shall be present if the HSS supports the Dedicated Core Networks feature, and the ""Send UE Usage Type"" flag was set in the AIR-Flags AVP in the AIR command, and this information is available in the user subscription. If present, this IE shall contain the UE Usage Type of the subscriber (see clauseÊ7.3.202). 5.2.3.1.2 Detailed behaviour of the MME and the SGSN The MME or SGSN shall make use of this procedure in order to retrieve the Authentication Vectors from the HSS. If the MME or SGSN supports Emergency services for users in limited service state, and the user's IMSI is not available from the UE, or the user's IMSI is marked as unauthenticated, the MME or SGSN shall not make use of the Authentication Information Retrieval procedure. If the request is triggered by a synchronization failure during E-UTRAN authentication, the MME or combined MME/SGSN shall include the Re-Synchronization Information in the Requested-EUTRAN-Authentication-Info AVP in the request. If the request is triggered by a synchronization failure during UTRAN or GERAN authentication, the SGSN or combined MME/SGSN shall include the Re-Synchronization Information in the Requested-UTRAN-GERAN-Authentication-Info AVP in the request. Re-Synchronization Information shall not be present in both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP. A stand alone MME shall include the Requested-EUTRAN-Authentication-Info AVP and shall not include the Requested-UTRAN-GERAN-Authentication-Info AVP in the request. The Immediate-Response-Preferred AVP should be present if a EUTRAN-Vector is needed for immediate use. A stand alone SGSN shall not include the Requested-EUTRAN-Authentication-Info AVP and shall include the Requested-UTRAN-GERAN-Authentication-Info AVP in the request. The Immediate-Response-Preferred AVP should be present if a UTRAN/GERAN-Vector is needed for immediate use. A combined MME/SGSN may include both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP in the request. If both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP are present in the request, the Immediate-Response-Preferred AVP shall be present if the requested authentication vectors are needed for immediate use. The content of the Immediate-Response-Preferred AVP shall correspond to the access type which the UE is currently to be authenticated. The Immediate-Response-Preferred AVP shall not be present in both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP. The presence of an Immediate-Response-Preferred AVP shall indicate that a vector is needed for immediate use. When EUTRAN-AVs and UTRAN-AVs or GERAN-AVs are requested, presence of Immediate-Response-Preferred AVP within the Requested-EUTRAN-Authentication-Info AVP shall indicate that EUTRAN-AVs are requested for immediate use in the MME/SGSN; presence of Immediate-Response-Preferred AVP within the Requested-UTRAN-GERAN-Authentication-Info AVP shall indicate that UTRAN-AVs or GERAN-AVs are requested for immediate use in the MME/SGSN. It may be used by the HSS to determine the number of vectors to be obtained from the AuC and the number of vectors downloaded to the MME or SGSN. If the MME or SGSN supports the Dedicated Core Networks functionality, and the MME or SGSN needs to retrieve the UE Usage Type from the HSS, it shall set the ""Send UE Usage Type"" flag in the AIR-Flags AVP in the AIR command. When receiving an Authentication Information response from the HSS, the MME or SGSN shall check the Result Code. If it indicates success and Authentication Information is present in the result, the MME or SGSN shall use the received vectors. For details see 3GPPÊTSÊ33.401Ê[5]. If the MME or SGSN supports Emergency services for users in limited service state, the MME or SGSN shall proceed even if the Authentication Information Retrieval procedure has failed. In this case, the MME or SGSN shall mark the user's IMSI as unauthenticated. Vectors with lower Item Number should be used before Vectors with higher Item Number are used in the MME or SGSN. For Vectors received within different requests those received by the earlier request should be used before those received by the later request. 5.2.3.1.3 Detailed behaviour of the HSS When receiving an Authentication Information request the HSS shall check whether subscription data exists for the IMSI. If the HSS determines that there is not any type of subscription for the IMSI (including EPS, GPRS and CS subscription data), a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If the Authentication Information Request contains a Requested-EUTRAN-Authentication-Info AVP but no Requested-UTRAN-GERAN-Authentication-Info AVP, and the subscriber has not any APN configuration, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. If the Authentication Information Request contains a Requested-UTRAN-GERAN-Authentication-Info AVP but no Requested-EUTRAN-Authentication-Info AVP, and the subscriber has neither an APN configuration profile nor GPRS subscription data, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION."
"If the Authentication Information Request contains both Requested-EUTRAN-Authentication-Info AVP and Requested-UTRAN-GERAN-Authentication-Info AVP, and the Requested-EUTRAN-Authentication-Info AVP does not contain an Immediate-Response-Preferred AVP, and the subscriber has not any APN configuration, the HSS shall not return E-UTRAN vectors. If the Authentication Information Request contains both Requested-EUTRAN-Authentication-Info AVP and Requested-UTRAN-GERAN-Authentication-Info AVP, and the Requested-EUTRAN-Authentication-Info AVP contains an Immediate-Response-Preferred AVP, and the subscriber does not have any APN configuration, the HSS shall return a Result Code of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION. When sending DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION, an Error Diagnostic information may be added to indicate whether or not GPRS subscription data are subscribed (i.e. whether or not Network Access Mode stored in the HSS indicates that only circuit service is allowed). If EUTRAN-Authentication-Info is requested, the HSS shall check if serving nodes within the realm identified by the received Origin-Realm AVP are allowed to request authentication information for use in the serving network identified by the received Visited-PLMN-Id AVP. The HSS shall then request the AuC to generate the corresponding requested Authentication Vectors (AVs). Subject to load considerations and/or other implementation specific considerations which may be based on the presence of an Immediate-Response-Preferred AVP, less AVs than the requested number of AVs may be generated. If EUTRAN-Authentication-Info is requested, when receiving AVs from the AuC, the HSS shall generate the KASME before sending the response to the MME or combined MME-SGSN. If the AuC is unable to calculate any corresponding AVs due to unallowed attachment for the UE, e.g. the UE is attaching via E-UTRAN with a SIM card equipped, the HSS shall return an error DIAMETER_AUTHORIZATION_REJECTED, the HSS shall not return any AV to the requesting node in the response. Otherwise, if no corresponding pre-computed AV is available, and the AuC is unable to calculate any corresponding AVs due to unknown failures, such as the internal database error, the result code shall be set to DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE. The MME or the SGSN may request authentication vectors again. For details see 3GPPÊTSÊ33.401Ê[5]. KASME generation is not performed before sending the response to the SGSN. If the Requested-EUTRAN-Authentication-Info AVP is present in the request, the HSS shall download E-UTRAN authentication vectors to the MME. If the Requested-UTRAN-GERAN-Authentication-Info AVP is present in the request, the HSS shall download UTRAN or GERAN authentication vectors to the SGSN. If the Immediate Response Preferred parameter has been received, the HSS may use it together with the number of requested vectors and the number of vectors stored in the HSS that are pre-computed to determine the number of vectors to be obtained from the AuC. The HSS may return less number of vectors than requested to the MME or SGSN. If both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP are in the request, and one of them includes the Immediate Response Preferred parameter, the HSS may omit the vectors request that are not for immediate use. If both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP are in the request, and both of them includes the Immediate Response Preferred parameter, the HSS may return E-UTRAN authentication vectors and UTRAN or GERAN authentication vectors. KASME is always computed for each E-UTRAN vector due to the PLMN-binding before sending the response to the MME independent of the presence of the Immediate Response Preferred parameter. If the Re-Synchronization-Info AVP has been received, the HSS shall check the AUTS parameter before sending new authentication vectors to the MME or the SGSN. For details see 3GPPÊTSÊ33.102Ê[18]. If both the Requested-EUTRAN-Authentication-Info AVP and the Requested-UTRAN-GERAN-Authentication-Info AVP are in the request, and both of them include the Re-Synchronization-Info AVP, the HSS shall not check the AUTS parameter and return the result code of DIAMETER_UNABLE_TO_COMPLY. Any authentication vectors shall not be sent by the HSS to the requesting node in the response. If more than one EPS or UTRAN or GERAN Vector is to be included within one Authentication-Info AVP, the Item-Number AVP shall be present within each Vector. If the HSS supports the Dedicated Core Networks functionality, and the MME or SGSN has set the ""Send UE Usage Type"" flag in the AIR-Flags AVP in the AIR command: - if the UE Usage Type value is available in the subscription data of the user: - if the Immediate Response Preferred parameter is not present in the Requested-EUTRAN-Authentication-Info nor in the Requested-UTRAN-GERAN-Authentication-Info, the HSS may return no authentication vectors in the response; the HSS shall then return the result code DIAMETER_SUCCESS and may return the generated AVs (if any) to the MME or SGSN; - the HSS shall include the UE-Usage-Type AVP in the AIA response command if the result code is DIAMETER_SUCCESS or DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE. - if the UE Usage Type value is not available in the subscription data of the user, the HSS shall answer as if the MME/SGSN had not requested the UE Usage Type parameter. 5.2.4 Fault Recovery Procedures 5.2.4.1 Reset 5.2.4.1.1 General The Reset Procedure shall be used by the HSS, after a restart, to indicate to the MME and to the SGSN that a failure has occurred. The Reset Procedure may also be used by the HSS as part of operation and maintenance actions e.g. to allow planned HSS outage without service interruption, or to update subscription data shared by multiple subscribers. This procedure is mapped to the commands Reset-Request/Answer (RSR/RSA) in the Diameter application specified in clause 7. Table 5.2.4.1.1/1 specifies the involved information elements for the request. Table 5.2.4.1.1/2 specifies the involved information elements for the answer. Table 5.2.4.1.1/1: Reset Request Information element name Mapping to Diameter AVP Cat. Description User Id List (See 7.3.50) User-Id O This IE shall contain a list of User-Ids where a User-Id comprises the leading digits of an IMSI (i.e. MCC, MNC, leading digits of MSIN) and it shall identify the set of subscribers whose IMSIs begin with the User-Id. The HSS may include this information element if the occurred failure is limited to subscribers identified by one or more User-Ids. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Reset-IDs (See 7.3.184) Reset-ID O If present, this information element identifies the set of impacted subscribers. Subscription Data (See 7.3.2) Subscription-Data O If the Reset Procedure is used to add/ modify subscription data shared by multiple subscribers, this Information Element shall contain the part of the subscription profile that either is to be added to the subscription profile stored in the MME or SGSN or combined MME/SGSN or is replacing a part of the subscription profiles of the impacted subscribers stored in the MME or SGSN. Shall be absent if Subscription-Data-Deletion AVP is present. Shall be absent if Reset-ID AVP is absent Subscription Data Deletion (See 7.3.208) Subscription-Data-Deletion O If the Reset Procedure is used to delete subscription data shared by multiple subscribers, this Information Element shall contain identifications of the part of the subscription profile that is to be deleted from the subscription profiles of the impacted subscribers stored in the MME or SGSN or combined MME/SGSN. Shall be absent if Subscription-Data AVP is present. Shall be absent if Reset-ID AVP is absent Table 5.2.4.1.1/2: Reset Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. There are no Experimental-Result codes applicable for this command. 5.2.4.1.2 Detailed behaviour of the MME and the SGSN When receiving a Reset message neither containing Subscription-Data nor Subscription-Data-Deletion the MME or SGSN or combined MME/SGSN shall mark all impacted subscriber records ""Location Information Confirmed in HSS "" as ""Not Confirmed"". When receiving a Reset message containing Subscription-Data or Subscription-Data-Deletion the MME or SGSN or combined MME/SGSN shall update all impacted subscriber records accordingly, i.e. each impacted subscriber record is updated as if an individual IDR or DSR for that subscriber was received; for details see clauses 5.2.2.1.2 and 5.2.2.2.2. The MME or SGSN or combined MME/SGSN shall not mark successfully updated subscriber records ""Location Information Confirmed in HSS "" as ""Not Confirmed"". If an impacted subscriber record cannot be updated for any reason (e.g. the updated data is considered not shareable by the MME or SGSN or combined MME/SGSN, or the update requires an individual acknowledgement to be sent to the HSS), the MME or SGSN or combined MME/SGSN shall mark that record ""Location Information Confirmed in HSS "" as ""Not Confirmed"". NOTE: Which subscription data are considered by the MME or SGSN or combined MME/SGSN not shareable by multiple subscribers is implementation specific. If the update of shared subscription data requires only local updates in the MME or SGSN or combined MME/SGSN (i.e., the update of the profile does not imply to initiate any signalling interaction towards other network nodes), the updates should be performed immediately (e.g. deleting an Operator Determined Barring). If the update of shared subscription data implies initiating a signalling interaction towards other nodes (e.g. towards the PGW/PCRF for the change of an APN configuration parameter, such as APN-AMBR), depending on the UE's state the following shall apply: - If the UE is in CONNECTED state, the updates shall be performed immediately including signalling towards other nodes. - If the UE is in IDLE state, the signalling towards other nodes should be deferred to the next authenticated radio contact with that UE. NOTE: The rational for the recommendationÊto defer signalling towards other nodes until the next authenticated radio contact is to consider impacts to the network only when the updates are required, and to spread the signalling towards other nodes over some time, based on user's activity. In both cases, to avoid high processing/signalling load resulting from shared subscription data update, processing/signalling actions resulting from data updates in the MME or SGSN or combined MME/SGSN may take a maximum operator configuration-depending time. If the Reset-IDs IE is supported and received, the MME or SGSN or combined MME/SGSN shall make use of the Reset-IDs (together with the HSS's realm) in order to determine which subscriber records are impacted (i.e. check whether at least one received Reset-ID is associated with the subscriber); otherwise the MME or SGSN or combined MME/SGSN shall make use of the HSS Identity received in the Origin-Host AVP (by comparing it with the value stored after successful ULA) and may make use of the received User-Id-List (if any) in order to determine which subscriber records are impacted. At the next authenticated radio contact with the UE concerned, if the subscriber record ""Location Information Confirmed in HSS"" is marked as ""Not Confirmed"", the restoration procedure shall be triggered. See also 3GPPÊTSÊ29.118Ê[46] clauseÊ5.9.2. 5.2.4.1.3 Detailed behaviour of the HSS The HSS shall make use of this procedure in order to indicate to all relevant MMEs, SGSN, and combined MME/SGSNs that the HSS has restarted and may have lost the current MME-Identity and SGSN-Identity of some of its subscribers who may be currently roaming in the MME area and/or SGSN area, and that the HSS, therefore, cannot send a Cancel Location messages or Insert Subscriber Data messages when needed. The HSS may make use of this procedure in order to indicate to all relevant MMEs, SGSN, and combined MME/SGSNs that the HSS has updated subscription data shared by some of its subscribers who may be currently roaming in the MME area and/or SGSN area. If the Reset-ID feature is not supported by the MME/SGSN and HSS, the HSS optionally may include a list of Ids identifying a subset of subscribers served by the HSS, if the occurred failure is limited to those subscribers. If the Reset-ID feature is supported by the MME or SGSN, the HSS optionally may include one (or several) Reset-ID AVPs identifying e.g. failed hardware components if the occured failure is limited to those subscribers associated with e.g. the identified failed hardware components. The HSS should invoke this procedure towards a combined MME/SGSN only for a single time even if some of the impacted subscribers are attached to the combined MME/SGSN via UTRAN/GERAN and some of the impacted subscribers are attached to the combined MME/SGSN via E-UTRAN. 5.2.5 Notification Procedures 5.2.5.1 Notification 5.2.5.1.1 General The Notification Procedure shall be used between the MME and the HSS and between the SGSN and the HSS when an inter MME or SGSN location update does not occur but the HSS needs to be notified about - an update of terminal information; - an update of the UE SRVCC capability (only if the MME/SGSN supports SRVCC). The Notification Procedure shall also be used between the MME and the HSS and between the SGSN and the HSS if the HSS needs to be notified about: - an assignment/change of a dynamically allocated PDN GW for an APN, if such a notification is needed taking into account the access restrictions and the type of PDN; NOTE: If the PDN is of type ""non-IP"", the APN is not accessible via non-3GPP access and therefore the PDN-GW ID does not need to be conveyed across accesses. - an assignment/change of a dynamically allocated PDN GW for the establishment of emergency PDN connections, if such notification is needed for a non roaming authenticated user, based on operator policy (e.g. on whether the operator uses static PDN GW or not for emergency services) taking into account the access restrictions and feature support; - the failed monitoring event configurations at the MME or SGSN (if received in ULA) or the status of the monitoring event configurations at the IWK-SCEF; - the deletion of a monitoring event configuration in SCEF for a UE (i.e. due to an SCEF restart, see 3GPPÊTSÊ23.007Ê[43]). The Notification Procedure shall be used between the MME and the HSS when an inter MME location update does not occur but the HSS needs to be notified about - the need to send a Cancel Location to the current SGSN. The Notification Procedure shall be used between the MME and the HSS when the ""SMS in MME"" feature is applied and between the SGSN and the HSS when an earlier short message delivery failed and the HSS needs to be notified about: - the UE is reachable or the UE has memory capacity available to receive one or more short messages. The Notification Procedure shall be used between the MME and the HSS and between the SGSN and the HSS when the HSS has requested to be notified about: - the UE is reachable. The Notification Procedure shall be used between the MME and the HSS and between the SGSN and the HSS to notify the HSS about: - an update of the Homogeneous Support of IMS Voice Over PS Sessions. The Notification Procedure shall be used between the MME and the HSS to notify the HSS about: - removal of MME registration for SMS. This procedure is mapped to the commands Notify-Request/Answer (NOR/NOA) in the Diameter application specified in clause 7. Table 5.2.5.1.1/1 specifies the involved information elements for the request. Table 5.2.5.1.1/2 specifies the involved information elements for the answer. Table 5.2.5.1.1/1: Notify Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Terminal Information (See 7.3.3) Terminal-Information C This information element shall contain information about the user's mobile equipment. When notifying the HSS about any change of Terminal Information, the MME or SGSN shall include the new Terminal Information in the request. Within this Information Element, only the IMEI and the Software-Version AVPs shall be used on the S6a/S6d interface. PDN GW Identity (See 7.3.45) MIP6-Agent-Info C This IE shall contain the identity of the selected and dynamically allocated PDN GW for an APN. It shall be present if a new PDN-GW has been selected and the subscriber is allowed handover to non 3GPP access or 5GS interworking without N26 interface enabled. When notifying the HSS about a newly selected PDN GW, the MME or SGSN shall include the PDN-GW-Identity in the request. For establishment of emergency PDN connections, this IE shall contain the identity of the PDN-GW used to establish those PDN connections. PGW PLMN ID Visited-Network-Identifier C This IE identifies the PLMN in which the PDN GW is located. It shall be present when the PDN GW Identity is present and does not contain an FQDN. Context Identifier (See 7.3.27) Context-Identifier O This parameter shall identify the APN Configuration with which the selected PDN GW shall be correlated. It may be present if it is available and the PDN-GW is present and is particular for one specific APN and not common to all the APNs. For the compatibility with the MAP protocol as defined in the 3GPPÊTSÊ29.002Ê[24], this parameter shall not have a value of zero. APN (See TSÊ23.008Ê[30]) Service-Selection (See IETFÊRFCÊ5778Ê[20]) C This IE shall contain the APN for the selected and dynamically allocated PDN GW. For establishment of non-emergency PDN connections, it shall be present if the selected PDN-GW is present and is particular for one specific APN and not common to all the APNs. For establishment of emergency PDN connections (i.e., the Emergency-Services AVP is present, with the Emergency-Indication flag set), this AVP shall be left absent. Alert Reason (See 7.3.83) Alert-Reason C This parameter shall indicate if the mobile subscriber is present or the MS has memory available. It shall be present when notifying the HSS about the presence of the UE or the UE has memory capacity available to receive one or more short messages. UE SRVCC Capability UE-SRVCC-Capability C This information element shall indicate if the UE supports or does not support the SRVCC capability. If the MME/SGSN supports SRVCC and the UE SRVCC Capability has changed, the MME or SGSN shall include the new UE SRVCC Capability in the request. NOR Flags (See 7.3.49) NOR-Flags C This Information Element shall contain a bit mask. See 7.3.49 for the meaning of the bits. Absence of this information element shall be interpreted as all bits set to 0. When notifying the HSS about the need to send cancel location to the current SGSN, the MME shall set the ""Single-Registration-Indication"" flag in the NOR-Flags. When notifying the HSS about the ""restricted"" status of the current SGSN area, the SGSN shall set the ""SGSN area restricted"" flag in the NOR-Flags. When notifying the HSS about the reachability of the UE or the UE has memory capacity available to receive one or more short messages, the MME, if the ""SMS in MME"" feature is applied, or SGSN shall set the ""Ready for SM"" flag correspondingly in the NOR-Flags. When notifying the HSS that the UE is reachable, the MME or SGSN shall set the ""UE Reachable"" flag correspondingly in the NOR-Flags. When notifying the HSS about update of the Homogeneous Support of IMS Voice Over PS Sessions, the MME or the SGSN shall set the ""Homogeneous Support of IMS Voice Over PS Sessions"" flag and S6a/S6d-Indicator flag for a combined MME/SGSN correspondingly in the NOR-Flags. When notifying the HSS about removal of MME registration for SMS, the MME shall set the ""Removal of MME Registration for SMS"" flag correspondingly in the NOR-Flags. Homogeneous Support of IMS Voice Over PS Sessions (See 7.3.107) Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions C This Information Element shall be present if Homogeneous Support of IMS Voice Over PS Sessions is modified to one of the values ""SUPPORTED"" or ""NOT_SUPPORTED"". The value ""SUPPORTED"" indicates that there is support for ""IMS Voice over PS Sessions"" in all TAs or RAs. The value ""NOT_SUPPORTED"" indicates that there is not support for ""IMS Voice over PS Sessions"" in any of the TAs or RAs. Maximum UE Availability Time Maximum-UE-Availability-Time O This information element may be included when notifying the HSS that the UE is reachable. When present, it shall indicate the timestamp (in UTC) until which a UE using a power saving mechanism (such as extended idle mode DRX) is expected to be reachable for SM Delivery. This information may be used by the SMS Center to prioritize the retransmission of Short Message to UEs using a power saving mechanism. Monitoring Event Config Status Monitoring-Event-Config-Status C This information element shall be present if the MME/SGSN sends the Notify Request after receiving the Configuration-Information-Answer from the IWK-SCEF. This information element shall only contain the monitoring event configuration status of those events whose configuration status has changed since the last status informed to the HSS. This information element shall also be present if any of the monitoring events configurations received in ULA failed and shall only contain the monitoring event configuration status of those events whose detection could not be started at the MME/SGSN. This information element shall also be present if the MME or SGSN determines that a Monitoring Event Configuration for a UE is to be deleted in the HSS (i.e. SCEF responds to a Monitoring Event Report with DIAMETER_ERROR_SCEF_REFERENCE_ID_UNKNOWN). Emergency Services (See 3GPPÊTSÊ29.273Ê[59]) Emergency-Services C The MME shall include this information element, and set the Emergency-Indication flag, to notify the HSS that a new PDN-GW has been selected for the establishment of an emergency PDN connection, whose identify is conveyed in the ""PDN GW Identity"" IE. Table 5.2.5.1.1/2: Notify Answer Information element name Mapping to Diameter AVP Cat. Description Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S6a/S6d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. 5.2.5.1.2 Detailed behaviour of the MME and the SGSN If the MME or SGSN supports Emergency services, the MME or SGSN shall not make use of the Notification procedure for emergency attached unauthenticated UEs; for authenticated UEs, the MME shall make use of the Notification procedure to inform the HSS about the PDN-GW selected to establish emergency PDN connections, if the MME is configured to use a dynamic PGW for emergency services for such UEs. The MME or SGSN shall not make use of the Notification procedure to inform the HSS about the identity of the dynamically selected PDN-GW, if the access restrictions indicate that the user is not allowed to get service via non-3GPP access, or the PDN type of the APN is of type ""non-IP"". The MME or SGSN shall include conditional AVPs in NOR according to the description given in table 5.2.5.1.1/1. If the MME sends a Notify Request to inform the HSS that the UE has become reachable again, the MME shall clear the corresponding URRP-MME for the UE. If the SGSN sends a Notify Request to inform the HSS that the UE has become reachable again, the SGSN shall clear the corresponding URRP-SGSN for the UE. If the MME sends a Notify Request to inform the HSS about the presence of the UE to receive one or more short messages, the MME shall clear the corresponding MNRF for the UE. If the SGSN sends a Notify Request to inform the HSS about the presence of the UE to receive one or more short messages, the SGSN shall clear the corresponding MNRG for the UE. If the MME or SGSN determines that it needs to update the Homogeneous Support of IMS Voice Over PS Sessions in the HSS, the MME or SGSN shall send a Notify Request with the ""Homogeneous Support of IMS Voice Over PS Sessions"" bit set in the NOR-Flags AVP; if there is homogeneous support, or homogeneous non-support, of IMS Voice Over PS Sessions, the MME or SGSN shall report it by including the updated Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP; if the support is not homogeneous, the MME or SGSN shall report it by leaving such AVP absent in the Notify Request to the HSS. MME or SGSN shall ensure the status of Homogeneous Support of IMS Voice Sessions in HSS does not contradict with the value of ""IMS voice over PS session indicator"" provided to UE over NAS as specified in 3GPPÊTSÊ24.008Ê[31] and 3GPPÊTSÊ24.301Ê[64]; if ""IMS voice over PS session indicator"" sent to UE has changed from ""not supported"" to ""supported"" when status Homogenous Support of IMS Voice in HSS is ""not supported"", MME or SGSN shall immediately send Notify Request indicating as either homogenous support or not homogeneous; if ""IMS voice over PS session indicator"" sent to UE has changed from ""supported"" to ""not supported"" when status Homogenous Support of IMS Voice in HSS is ""supported"", MME or SGSN shall immediately send Notify Request indicating as either homogenous non-support or not homogeneous. If the MME needs to indicate to the HSS that it is no longer registered for SMS in the HSS, the MME shall send a Notify Request with ""Removal of MME Registration for SMS"" flag set in the NOR-Flags AVP. When receiving a Notify response from the HSS, if the result code indicates DIAMETER_ERROR_UNKNOWN_SERVING_NODE, the MME or SGSN shall consider the Notification procedure as failed, and it shall mark the subscriber record as ""Subscriber to be restored in HSS"". When receiving a Notify response from the HSS, if the result code indicates DIAMETER_ERROR_USER_UNKNOWN, the MME or SGSN shall detach the subscriber and remove the subscriber from its database. If the MME/SGSN has received the monitoring event configurations in an ULA command and one, several or all event detections fail to be started (e.g due to maximum resources exceeded), the MME/SGSN shall send the Notify Request command with the Monitoring-Event-Config-Status AVP for the failed monitoring event configurations. If the MME or SGSN receives a failure response, e.g. DIAMETER_UNABLE_TO_COMPLY, corresponding to a Notify Request to notify the HSS about the selected PDN-GW, the MME or SGSN shall not trigger a detach for the subscriber based only on this failure. NOTE 1: A failure to indicate the selected PDN-GW to the HSS does not impact connectivity provided via 3GPP access. When the MME/SGSN has received the Configuration-Information-Answer from the IWK-SCEF during the monitoring event configuration procedure, the MME/SGSN shall send the Notify Request command with the Monitoring-Event-Config-Status AVP as received from the IWK-SCEF in the Configuration-Information-Answer, for the monitoring event configurations whose status have changed (due to authorization performed by the IWK-SCEF) since last informed to the HSS. NOTE 2: If the Monitoring-Event-Configuration was received at the MME/SGSN in the ULA command, then the HSS is not yet informed of any status of the monitoring event configuration. In this case, the entire Monitoring-Event-Config-Status as received from IWK-SCEF has to be transferred to the HSS through a Notify Request Command. If the MME or SGSN determines that a Monitoring Event Configuration for a UE is to be deleted in the HSS (i.e. SCEF responds to a Monitoring Event Report with DIAMETER_ERROR_SCEF_REFERENCE_ID_UNKNOWN), the MME or SGSN shall send a Notify Request with the Monitoring-Event-Config-Status AVP. The Monitoring-Event-Config-Status AVP shall include the error as received from SCEF. 5.2.5.1.3 Detailed behaviour of the HSS When receiving a Notify request the HSS shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If the IMSI is known, and the source MME or SGSN originating the Notify message is not currently registered in HSS for that UE, a result code of DIAMETER_ ERROR_ UNKNOWN_SERVING_NODE shall be returned. If the IMSI is known, and the source MME or SGSN is currently registered in HSS, the HSS shall set the result code to DIAMETER_SUCCESS, unless otherwise stated, and - store the new terminal information if present in the request; - store the new UE SRVCC capability if present in the request; - store the new PDN GW and PLMN ID for an APN if present in the request and the APN is present in the subscription and if PDN GW is dynamically allocated; otherwise the HSS shall not store the new PDN GW data and shall set the result code to DIAMETER_ UNABLE_TO_COMPLY; - store the new PDN GW and PLMN ID, and the APN itself, if both are present in the request, and the APN is not present in the subscription but a wild card APN is present in the subscription; - if the Emergency Services IE is present, with the Emergency-Indication flag set, store the new PDN GW, as the PDN GW used to establish emergency PDN connections; the HSS shall store this information not bound to any specific APN; - mark the location area as ""restricted"" if so indicated in the request; - send Cancel Location to the current SGSN if so indicated in the request; - if the UE has become reachable again, and NOR is received on S6a from an MME or on S6d from an SGSN, the HSS shall respectively clear the URRP-MME or the URPP-SGSN parameter for the UE and send an indication t of UE reachability from MME or SGSN o the Service Related Entities if there is any; - when NOR is received on S6d from an SGSN (with the Alert Reason present), the HSS shall reset the MNRG flag and send a MAP-Alert-Service-Centre message or S6c-Alert-Service-Centre-Request (see 3GPPÊTSÊ29.338Ê[48], i.e. the behaviour in the HSS should be the same as when a MAP-Ready for SM is received from an SGSN; - when NOR is received on S6a from an MME (with the Alert Reason present), the HSS shall reset the MNRF flag and send a MAP-Alert-Service-Centre message or S6c-Alert-Service-Centre-Request (see 3GPPÊTSÊ29.338Ê[48], i.e. the behaviour in the HSS should be the same as when a MAP-Ready for SM is received from a VLR/MSC; - when NOR is received on S6a from an MME or on S6d from an SGSN to update the Homogeneous Support of IMS Voice Over PS Sessions, the HSS shall store the updated Homogeneous Support of IMS Voice Over PS Sessions and may use this information in the future in order to skip the T-ADS data retrieval, as described in clauseÊ5.2.2.1 (IDR/IDA commands). If the ""Homogeneous Support of IMS Voice Over PS Sessions"" bit is set in the NOR-Flags AVP received but without Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP present in the NOR message, the HSS shall take the Homogeneous Support of IMS Voice Over PS Sessions as unknown to the serving node. If the ""Homogeneous Support of IMS Voice Over PS Sessions"" bit is not set in the NOR-Flags AVP, the HSS shall ignore (if present) the Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP; - when NOR is received on S6a from an MME for removal of MME registration for SMS, the HSS shall remove the MME registration for SMS and the ""MME number for SMS"" as the corresponding MSC number to be used for MT SMS. - when NOR is received on S6a from an MME or on S6d from an SGSN with the Monitoring-Event-Config-Status AVP, the HSS shall either trigger a Monitoring event cancelation procedure for the monitoring events that were not successfully authorized at the MME/SGSN by the IWK-SCEF or a Monitoring event suspension procedure for the monitoring events that were not successfully configured at the MME/SGSN, as specified in clauseÊ7.2.2.2 of 3GPPÊTSÊ29.336Ê[54]. The HSS shall trigger a Monitoring event cancelation or suspension procedure based on the result code as indicated by MME/SGSN (e.g. DIAMETER_ERROR_UNAUTHORIZED_REQUESTING_ENTITY (5510) returned by IWK-SCEF triggers a Monitoring event cancelation procedure in HSS). - when NOR is received on S6a from an MME or on S6d from an SGSN with an indication of the deletion of a monitoring event configuration in SCEF (DIAMETER_ERROR_SCEF_REFERENCE_ID_UNKNOWN in the Monitoring-Event-Config-Status AVP), the HSS shall locally delete the corresponding Monitoring Event Configuration and shall not trigger a Monitoring event cancelation procedure. and then send the response to the MME or SGSN. 5A MME Ð CSS (S7a) and SGSN Ð CSS (S7d) 5A.1 Introduction The S7a interface enables the transfer of subscriber related CSG data in the VPLMN between the MME and the CSS as described in 3GPPÊTSÊ23.401Ê[2]. The S7d interface enables the transfer of subscriber related CSG data in the VPLMN between the SGSN and the CSS as described in 3GPPÊTSÊ23.060Ê[12]. 5A.2 Mobility Services 5A.2.1 Location Management Procedures 5A.2.1.1 Update VCSG Location 5A.2.1.1.1 General The Update VCSG Location Procedure shall be used between the MME and the CSS or between the SGSN and the CSS to update location information in the CSS or retrieve the CSG subscription data of the UE from the CSS. The procedure allows: - to inform the CSS about the identity of the MME or SGSN currently serving the user, - to update MME or SGSN with user CSG subscription data received from the CSS. This procedure is mapped to the commands Update-VCSG-Location-Request/Answer (UVR/UVA) in the Diameter application specified in clause 7. Table 5A.2.1.1.1/1 specifies the involved information elements for the request. Table 5A.2.1.1.1/2 specifies the involved information elements for the answer. Table 5A.2.1.1.1/1: Update VCSG Location Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. MSISDN MSISDN C This information element shall contain the user MSISDN, formatted according to 3GPPÊTSÊ29.329Ê[25]. It shall be present if available. UVR Flags (See 7.3.153) UVR-Flags M This Information Element contains a bit mask. See 7.3.153 for the meaning of the bits. SGSN number (See 7.3.102) SGSN-Number C This Information Element contains the ISDN number of the SGSN, see 3GPPÊTSÊ23.003Ê[3]. It shall be present when the message is sent on the S7d interface. It may be present when the message on the S7a interface and the requesting node is a combined MME/SGSN. Table 5A.2.1.1.1/2: Update VCSG Location Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S7a/S7d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable: - User Unknown VPLMN CSG Subscription Data (See 7.3.155) VPLMN-CSG-Subscription-Data C This Information Element shall contain the list of CSG Ids and the associated expiry dates stored in the CSS. It shall be present if success is reported, unless an explicit ""skip subscriber data"" indication was present in the request or the Temporary Empty VPLMN CSG Subscription Data flag is set. UVA Flags (See 7.3.154) UVA-Flags C This Information Element contains a bit mask. See 7.3.154 for the meaning of the bits. 5A.2.1.1.2 Detailed behaviour of the MME and the SGSN The MME or SGSN shall make use of this procedure to register the UE in the CSS and to retrieve the ""CSG subscription data from CSS"" when: - the VPLMN supports Autonomous CSG Roaming - and the HPLMN has enabled Autonomous CSG Roaming in the VPLMN - and the UE has requested an initial attach or a tracking area procedure or a routing area procedure to a CSG cell - and the MME or SGSN have not yet registered the UE in the CSS. If the Autonomous CSG Roaming in the VPLMN is not supported or is not allowed by the HPLMN of the subscriber, the MME or SGSN shall not make use of the Update CSG Location procedure. For UEs receiving emergency services, in which the UE was not successfully authenticated, the MME or SGSN shall not make use of the Update VCSG Location procedure. A combined MME/SGSN shall set the ""Skip Subscriber Data"" flag in the UVR-Flags if the ""CSG subscription data from CSS"" are already available due to a previously VCSG Location updating. A combined MME/SGSN that has chosen the option to include the SGSN Number within an Update VCSG Request sent over S7a shall be prepared to receive a single CSG subscription data update message from the CSS when the CSG subscription data is modified in the CSS. When receiving an Update VCSG Location Answer from the CSS, the MME or SGSN shall check the result code."
"If it indicates success the MME or SGSN shall delete all the stored ""CSG subscription data from CSS"" (if any) and then store the received ""CSG subscription data from the CSS"" (if any), and it shall store the CSS identity as received in the Origin-Host AVP. If the same CSG Id exists in both ""CSG subscription data from CSS"" and ""CSG subscription data from HSS"", the ""CSG subscription data from HSS"" shall take precedence over the ""CSG subscription data from CSS"" in further use. If an error response is received from the CSS, the MME or SGSN shall not reject the UE and shall end the procedure when the UE is attaching to a normal cell. If the UE is attaching to a CSG cell, in this case the MME or SGSN shall check if there is such CSG Id from the HSS. If there is no such CSG Id, the MME or SGSN shall reject the UE. 5A.2.1.1.3 Detailed behaviour of the CSS When receiving an Update VCSG Location request the CSS shall check whether the user is known. If the user is not known, and if the Update VCSG Location Request is received over the S7a/S7d interface, the CSS may: - store the MME or SGSN identity received within the Origin-Host AVP, and include the UVA-Flags AVP with ""Temporary Empty VPLMN CSG Subscription Data"" flag set, and return a Result Code of DIAMETER_ SUCCESS, or - return a Result Code of DIAMETER_ERROR_USER_UNKNOWN. NOTE: A mechanism is needed in the CSS to associate the CSG subscription data of the user with the received IMSI. If the Update VCSG Location Request is received over the S7a/S7d interface, the CSS shall replace the stored MME or SGSN identity with the received value (the identity is received within the Origin-Host AVP). If no result code indicating an error is sent to the MME or SGSN, the CSS shall include the VPLMN CSG subscription data in the Update VCSG Location Answer unless an explicit ""skip subscriber data"" indication has been received in the request, and shall return a Result Code of DIAMETER_SUCCESS. 5A.2.1.2 Cancel VCSG Location 5A.2.1.2.1 General The Cancel VCSG Location Procedure shall be used between the CSS and the MME and between the CSS and the SGSN. The procedure shall be invoked by the CSS and is used: - to inform the MME or SGSN about the subscriber's VCSG subscription withdrawal by the CSS operator and the removal of their registration in the CSS. This procedure is mapped to the commands Cancel-VCSG-Location-Request/Answer (CVR/CVA) in the Diameter application specified in clause 7. Table 5A.2.1.2.1/1 specifies the involved information elements for the request. Table 5A.2.1.2.1/2 specifies the involved information elements for the answer. Table 5A.2.1.2.1/1: Cancel VCSG Location Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Cancellation Type (See 7.3.24) Cancellation-Type M Defined values that can be used are: - Subscription Withdrawal, applied to the VPLMN CSG subscription. Table 5A.2.1.2.1/2: Cancel VCSG Location Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M The result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). 5A.2.1.2.2 Detailed behaviour of the MME and the SGSN When receiving a Cancel VCSG Location request the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_SUCCESS is returned. If it is known, the MME or SGSN shall check if the Cancellation Type is Subscription Withdrawal. In this case, the MME or SGSN shall remove the information of their registration in the CSS and the stored VPLMN CSG subscription if any. Also in this case a result code of DIAMETER_SUCCESS is returned. When a UE is served by a single combined MME/SGSN for both E-UTRAN and non-E-UTRAN access, the combined MME/SGSN shall check if the Cancellation Type is Subscription Withdrawal. In this case, the Cancel VCSG Location request is processed both in the MME part and in the SGSN part of the combined node. 5A.2.1.2.3 Detailed behaviour of the CSS The CSS shall make use of this procedure when the user's VPLMN CSG subscription is withdrawn by the CSS operator and shall include a cancellation type of ""Subscription Withdrawal. 5A.2.2 Subscriber Data Handling Procedures 5A.2.2.1 Insert VCSG Subscriber Data 5A.2.2.1.1 General The Insert VCSG Subscriber Data Procedure shall be used between the CSS and the MME and between the CSS and the SGSN for updating CSG subscription data in the MME or SGSN in the following situations: - due to administrative changes of the user data in the CSS and the user is now located in an MME or SGSN, i.e. if the user was given a CSG subscription and the CSG subscription has changed; If the CSS knows that the UE has attached to the same combined MME/SGSN via both the E-UTRAN and UTRAN/GERAN, i.e. the CSS has received the Update VCSG Location Request over both the S7a interface and S7d interface respectively with the same SGSN number, the CSS should invoke this procedure for a single time to update CSG subscription data in the combined MME/SGSN, i.e. the CSS should not invoke this procedure for each of the MME and the SGSN registered respectively. This procedure is mapped to the commands Insert-Subscriber Data-Request/Answer (IDR/IDA) in the Diameter application specified in clauseÊ7. Table 5A.2.2.1.1/1 specifies the involved information elements for the request. Table 5A.2.2.1.1/2 specifies the involved information elements for the answer. Table 5A.2.2.1.1/1: Insert VCSG Subscriber Data Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. VPLMN CSG Subscription Data (See 7.3.2) VPLMN-CSG-Subscription-Data M This Information Element shall contain the list of CSG Ids and the associated expiry dates stored in the VPLMN CSS. Table 5A.2.2.1.1/2: Insert VCSG Subscriber Data Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. Result-Code AVP shall be used to indicate success / errors defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]).The Experimental-Result AVP shall be used for S7a/S7d errors. This is a grouped AVP which shall contain the 3GPP Vendor Id in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown. 5A.2.2.1.2 Detailed behaviour of the MME and the SGSN When receiving an Insert VCSG Subscriber Data request, the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If the request does not contain any CSG-Subscription-Data AVP, Experimental-Result shall be set to DIAMETER_ERROR_SUBS_DATA_ABSENT. If the request contains at least one CSG-Subscription-Data AVPs, the MME or SGSN shall delete all the stored ""CSG subscription data from CSS"" (if any), and then store the received ""CSG subscription data from CSS"". If the MME or SGSN cannot fulfil the received request, e.g. due to a database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. If the same CSG Id exists in both ""CSG subscription data from CSS"" and ""CSG subscription data from HSS"", the ""CSG subscription data from HSS"" shall take precedence over the ""CSG subscription data from CSS"" in further use. 5A.2.2.1.3 Detailed behaviour of CSS The CSS shall make use of this procedure to delete the ""CSG subscription data from CSS"" stored in the MME or SGSN and replace them with the CSG subscription data sent. If the CSS receives a Insert VCSG Subscriber Data answer with the Result Code DIAMETER_ERROR_USER_UNKNOWN, the CSS shall clear the stored MME or SGSN identity. 5A.2.2.2 Delete VCSG Subscriber Data 5A.2.2.2.1 General This procedure shall be used between the CSS and the MME or between the CSS and the SGSN, to remove all the ""CSG subscription data from CSS"" stored in the MME or SGSN. The procedure shall be invoked by the CSS. If the CSS knows that the UE has attached to the same combined MME/SGSN via both E-UTRAN and UTRAN/GERAN, i.e. the CSS has received the Update VCSG Location Request over both the S7a interface and S7d interface respectively with the same SGSN number, the CSS should invoke this procedure for a single time to remove all the ""CSG subscription data from CSS"" stored in the combined MME/SGSN, i.e. not invoke this procedure for each of the MME and the SGSN registered respectively. This procedure is mapped to the commands Delete-Subscriber-Data-Request/Answer (DSR/DSA) in the S7a/S7d Diameter application specified in clauseÊ7. Table 5A.2.2.2.1/1 specifies the involved information elements for the request. Table 5A.2.2.2.1/2 specifies the involved information elements for the answer. Table 5A.2.2.2.1/1: Delete VCSG Subscriber Data Request Information element name Mapping to Diameter AVP Cat. Description IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) M This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. DSR Flags (See 7.3.25) DSR-Flags M This Information Element shall contain a bit mask. See 7.3.25 for the meaning of the bits. Table 5A.2.2.2.1/2: Delete VCSG Subscriber Data Answer Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S7a/S7d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - User Unknown 5A.2.2.2.2 Detailed behaviour of the MME and the SGSN When receiving a Delete VCSG Subscriber Data request, the MME or SGSN shall check whether the IMSI is known. If it is not known, a result code of DIAMETER_ERROR_USER_UNKNOWN shall be returned. If it is known, the MME or SGSN shall delete all the stored ""CSG subscription data from CSS"". If the deletion of the subscription data succeeds in the MME or SGSN, the Result-Code shall be set to DIAMETER_SUCCESS. If the MME or SGSN cannot fulfil the received request for other reasons, e.g. due to a database error, it shall set the Result-Code to DIAMETER_UNABLE_TO_COMPLY. 5A.2.2.2.3 Detailed behaviour of the CSS The CSS shall make use of this procedure to remove all the CSG subscription data associated to CSS from the MME or SGSN. NOTE: When a Delete VCSG Subscriber Data procedure occurs, the MME or SGSN remains registered in the CSS If the CSS receives a Delete VCSG Subscriber Data answer with the Result Code DIAMETER_ERROR_USER_UNKNOWN from the MME or SGSN, the CSS shall clear the stored MME or SGSN identity. 5A.2.3 Fault Recovery Procedures 5A.2.3.1 VCSG Reset 5A.2.3.1.1 General The VCSG Reset Procedure shall be used by the CSS, after a restart, to indicate to the MME and to the SGSN that a failure has occurred. This procedure is mapped to the commands Reset-Request/Answer (RSR/RSA) in the S7a/S7d Diameter application specified in clause 7. Table 5A.2.3.1.1/1 specifies the involved information elements for the request. Table 5A.2.3.1.1/2 specifies the involved information elements for the answer. Table 5A.2.3.1.1/1: VCSG Reset Request Information element name Mapping to Diameter AVP Cat. Description Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. Table 5A.2.3.1.1/2: VCSG Reset Answer Information element name Mapping to Diameter AVP Cat. Description Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S7a/S7d errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. There are no Experimental-Result codes applicable for this command. Supported Features (See 3GPPÊTSÊ29.229Ê[9]) Supported-Features O If present, this information element shall contain the list of features supported by the origin host. 5A.2.3.1.2 Detailed behaviour of the MME and the SGSN When receiving a VCSG Reset message, the MME or SGSN or combined MME/SGSN, for all roaming users for which they have a registration in CSS, shall mark ""Location Information Confirmed in CSS"" record as ""Not Confirmed"". The MME or SGSN or combined MME/SGSN shall make use of the CSS Identity received in the Origin-Host AVP (by comparing it with the value stored after successful ULA) in order to determine which user records are impacted. When, as described in 3GPPÊTSÊ23.007Ê[43], an event requiring the MME or SGSN to check the ""CSG subscription data from CSS"" occurs, and if the user record ""Location Information Confirmed in CSS"" is marked as ""Not Confirmed"", the restoration procedure shall be triggered. 5A.2.3.1.3 Detailed behaviour of the CSS The CSS shall make use of this procedure in order to indicate to all relevant MMEs, SGSNs, and combined MME/SGSNs that the CSS has restarted and may have lost the current MME-Identity and SGSN-Identity of some of its users who may be currently roaming in the MME area and/or SGSN area, and to which the CSS, therefore, cannot send e.g. Insert VCSG Subscriber Data messages when needed. The CSS should invoke this procedure towards a combined MME/SGSN only for a single time even if some of the impacted subscribers are attached to the combined MME/SGSN via UTRAN/GERAN and some of the impacted subscribers are attached to the combined MME/SGSN via E-UTRAN. 6 MME Ð EIR (S13) and SGSN Ð EIR (S13') 6.1 Introduction The S13 interface shall enable the ME Identity check procedure between the MME and the EIR as described in the 3GPPÊTSÊ23.401Ê[2]. The S13' interface shall enable the ME Identity check procedure between the SGSN and the EIR as described in the 3GPPÊTSÊ23.060Ê[12]. 6.2 ME Identity Check Procedures 6.2.1 ME Identity Check 6.2.1.1 General This Mobile Equipment Identity Check Procedure shall be used between the MME and the EIR and between the SGSN and the EIR to check the Mobile Equipment's identity status (e.g. to check that it has not been stolen, or, to verify that it does not have faults). This procedure is mapped to the commands ME-Identity-Check-Request/Answer (ECR/ECA) in the Diameter application specified in clause 6. Table 6.2.1.1/1 specifies the involved information elements for the request. Table 6.2.1.1/2 specifies the involved information elements for the answer. Table 6.2.1.1/1: ME Identity Check Request Information element name Mapping to Diameter AVP Cat. Description Terminal Information (See 7.3.3) Terminal-Information M This information element shall contain the information about the used mobile equipment i.e. the IMEI. Within this Information Element, only the IMEI and the Software-Version AVPs shall be used on the S13/S13' interface. IMSI User-Name (See IETFÊRFCÊ6733Ê[61]) O This information element shall contain the user IMSI, formatted according to 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2. Table 6.2.1.1/2: ME Identity Check Answer Information element name Mapping to Diameter AVP Cat. Description Result (See 7.4) Result-Code / Experimental-Result M This IE shall contain the result of the operation. The Result-Code AVP shall be used to indicate success / errors as defined in the Diameter base protocol (see IETFÊRFCÊ6733Ê[61]). The Experimental-Result AVP shall be used for S13/S13' errors. This is a grouped AVP which shall contain the 3GPP Vendor ID in the Vendor-Id AVP, and the error code in the Experimental-Result-Code AVP. The following errors are applicable in this case: - Unknown equipment Equipment Status (See 7.3.51) Equipment-Status C This information element shall contain the status of the requested mobile equipment as defined in 3GPPÊTSÊ22.016Ê[13]. It shall be present if the result of the ME Identity Check is DIAMETER_SUCCESS. 6.2.1.2 Detailed behaviour of the MME and the SGSN The MME or the SGSN shall make use of this procedure to check the ME identity, if the MME or the SGSN is configured to check the IMEI with the EIR. Terminal-Information, when sent by the MME/SGSN to the EIR, shall contain the IMEI AVP, and it may contain also the Software-Version AVP. IMSI may be sent together with Terminal Information to the EIR for operator-determined purposes. When receiving the ME Identity Check answer from the EIR, the MME or the SGSN shall check the result code and the equipment status. Dependent upon the result, the MME or the SGSN will decide its subsequent actions (e.g. sending an Attach Reject if the EIR indicates that the Mobile Equipment is unknown or prohibited listed). 6.2.1.3 Detailed behaviour of the EIR When receiving an ME Identity Check request, the EIR shall check whether the mobile equipment is known. The EIR shall identify the mobile equipment based on the first 14 digits of the IMEI AVP; if a 15th digit is received in the IMEI AVP, this digit shall be ignored by the EIR. Based on operator policies, the EIR may also use the Software-Version AVP, in addition to the first 14 digits of the IMEI AVP, to check the equipment identity against prohibited and tracking lists (see 3GPPÊTSÊ22.016Ê[13]). If the mobile equipment identity is not known, a result code of DIAMETER_ERROR_ EQUIPMENT_UNKNOWN is returned. If it is known, the EIR shall return DIAMETER_SUCCESS with the equipment status. 7 Protocol Specification and Implementation 7.1 Introduction 7.1.1 Use of Diameter base protocol The Diameter base protocol as specified in IETFÊRFCÊ6733Ê[61] shall apply except as modified by the defined support of the methods and the defined support of the commands and AVPs, result and error codes as specified in this specification. Unless otherwise specified, the procedures (including error handling and unrecognised information handling) shall be used unmodified. 7.1.2 Securing Diameter Messages For secure transport of Diameter messages, see 3GPPÊTSÊ33.210Ê[16]. If there are no intermediate Diameter Agent networks located between the visited PLMN and the home PLMN, the HSS or the first Diameter Agent located in the home PLMN which has direct connection with the serving network is required to check that the realm contained in the Origin-Realm AVP in the request from the serving network corresponds to the right serving network. If there are intermediate Diameter Agent networks located between the visited PLMN and home PLMN, the first Diameter Agent which has direct connection with the serving network is required to check that the realm contained in the Origin-Realm AVP in the request from the serving network corresponds to the right serving network. NOTE 1: How to do the above check is implementation specific, e.g. it may be done by checking if the IP addresses of the serving network nodes match with the realm received in the Origin-Realm AVP in the request. NOTE 2: Network configurations where a (potential) visited PLMN acts as intermediate Diameter Agent network are not allowed. NOTE 3: In the case there are intermediate Diameter Agent networks, the home network has to trust these intermediate Diameter agent networks to do the check and other hop by hop security check. This trust is usually substantiated by contracts since there are no remote technical means to verify if the checks were actually performed. 7.1.3 Accounting functionality Accounting functionality (Accounting Session State Machine, related command codes and AVPs) shall not be used on the S6a, S6d, S13 and S13' interfaces. 7.1.4 Use of sessions Between the MME and the HSS and between the SGSN and the HSS and between the MME and the EIR, Diameter sessions shall be implicitly terminated. An implicitly terminated session is one for which the server does not maintain state information. The client shall not send any re-authorization or session termination requests to the server. The Diameter base protocol specified in IETFÊRFCÊ6733Ê[61] includes the Auth-Session-State AVP as the mechanism for the implementation of implicitly terminated sessions. The client (server) shall include in its requests (responses) the Auth-Session-State AVP set to the value NO_STATE_MAINTAINED (1), as described in IETFÊRFCÊ6733Ê[61]. As a consequence, the server shall not maintain any state information about this session and the client shall not send any session termination request. Neither the Authorization-Lifetime AVP nor the Session-Timeout AVP shall be present in requests or responses. 7.1.5 Transport protocol Diameter messages over the S6a, S6d, S13, S13', S7a and S7d interfaces shall make use of SCTP IETFÊRFCÊ4960Ê[14]. 7.1.6 Routing considerations This clause specifies the use of the Diameter routing AVPs Destination-Realm and Destination-Host. If an MME or SGSN knows the address/name of the HSS for a certain user, and the associated home network domain name, both the Destination-Realm and Destination-Host AVPs shall be present in the request. NOTE: When sending a ULR command for a certain user due to HSS restoration procedure (i.e, after the MME/SGSN have received a Reset command from the HSS), the MME or the SGSN might consider the stored address/name of the HSS for the user to be invalid and hence not known. If an MME or SGSN knows only the home network domain name for a certain user, the Destination-Realm AVP shall be present and the command shall be routed to the next Diameter node. If an MME or SGSN knows only the identity of the user, the home network domain name shall be derived from the user's IMSI (MNC and MCC values) to construct the EPC Home Network Realm/Domain, as indicated in 3GPPÊTSÊ23.003Ê[3], clauseÊ19.2, and use it as Destination-Realm. Consequently, the Destination-Host AVP is declared as optional in the ABNF for all requests initiated by an MME or SGSN. The address/name of the EIR shall be locally configured in the MME. Requests initiated by the HSS towards an MME or SGSN shall include both Destination-Host and Destination-Realm AVPs. The HSS obtains the Destination-Host AVP to use in requests towards an MME or SGSN, from the Origin-Host AVP received in previous requests from the MME or SGSN. Consequently, the Destination-Host AVP is declared as mandatory in the ABNF for all requests initiated by the HSS. The Origin-Host AVP received in requests from the MME may contain a Diameter identity of the MME encoded as specified in clauseÊ19.4.2.4 of 3GPPÊTSÊ23.003Ê[3]. The Origin-Host AVP received in requests from the SGSN may contain a Diameter identity of the SGSN encoded as specified in clauseÊ19.4.2.6 of 3GPPÊTSÊ23.003Ê[3]. The HSS obtains the Destination-Realm AVP to use in requests towards an MME or SGSN, from the Origin-Realm AVP received in previous requests from the MME or SGSN. The Origin-Realm AVP in the requests received by the HSS in roaming cases, should contain the domain name of the network to which the MME or the SGSN belongs, encoded as specified in clauseÊ19.2 of 3GPPÊTSÊ23.003Ê[3]. The Destination-Realm AVP is declared as mandatory in the ABNF for all requests. If the Vendor-Specific-Application-ID AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node, and it shall not be used for routing purposes. 7.1.7 Advertising Application Support The HSS, MME, SGSN and EIR shall advertise support of the Diameter S6a/S6d and/or S13/S13' Application by including the value of the application identifier in the Auth-Application-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The vendor identifier value of 3GPP (10415) shall be included in the Supported-Vendor-Id AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands, and in the Vendor-Id AVP within the Vendor-Specific-Application-Id grouped AVP of the Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands. The Vendor-Id AVP included in Capabilities-Exchange-Request and Capabilities-Exchange-Answer commands that is not included in the Vendor-Specific-Application-Id AVPs as described above shall indicate the manufacturer of the Diameter node as per IETFÊRFCÊ6733Ê[61]. 7.1.8 Diameter Application Identifier This clause specifies three Diameter applications: The S6a/S6d interface application, the S13/S13' interface application, and the S7a/S7d interface application. The S6a/S6d interface application allows a Diameter server and a Diameter client: - to exchange location information; - to authorize a user to access the EPS; - to exchange authentication information; - to download and handle changes in the subscriber data stored in the server. The S6a/S6d interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the S6a/S6d interface application is 16777251 (allocated by IANA). The S13/S13' interface application allows a Diameter server and a Diameter client: - to check the validity of the ME Identity. The S13/S13' interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the S13/S13' interface application is 16777252 (allocated by IANA). The S7a/S7d interface application allows a Diameter server and a Diameter client: - to authorize a user to access CSGs identified in the CSS while roaming; - to download and handle changes in CSG subscriber data stored in the CSS. The S7a/S7d interface protocol shall be defined as an IETF vendor specific Diameter application, where the vendor is 3GPP. The vendor identifier assigned by IANA to 3GPP (http://www.iana.org/assignments/enterprise-numbers) is 10415. The Diameter application identifier assigned to the S7a/S7d interface application is 16777308 (allocated by IANA). 7.1.9 Use of the Supported-Features AVP When new functionality is introduced on the S6a/S6d interfaces, it should be defined as optional. If backwards incompatible changes can not be avoided, the new functionality shall be introduced as a new feature and support advertised with the Supported-Features AVP. The usage of the Supported-Features AVP on the S6a/S6d interfaces is consistent with the procedures for the dynamic discovery of supported features as defined in clauseÊ7.2 of 3GPPÊTSÊ29.229Ê[9]. When extending the application by adding new AVPs for a feature, the new AVPs shall have the M bit cleared and the AVP shall not be defined mandatory in the command ABNF. As defined in 3GPPÊTSÊ29.229Ê[9], the Supported-Features AVP is of type grouped and contains the Vendor-Id, Feature-List-ID and Feature-List AVPs. On the all reference points as specified in this specificaion, the Supported-Features AVP is used to identify features that have been defined by 3GPP and hence, for features defined in this document, the Vendor-Id AVP shall contain the vendor ID of 3GPP (10415). If there are multiple feature lists defined for the reference point, the Feature-List-ID AVP shall differentiate those lists from one another. The Table 7.3.10/1 defines the features applicable to the S6a/S6d interfaces for the feature list with a Feature-List-ID of 1. The Table 7.3.10/2 defines the features applicable to the S6a/S6d interfaces for the feature list with a Feature-List-ID of 2. NOTE 1: If the support of a feature by the receiver is required in order for the receiver to be able to correctly process the request command, then the feature is included in the Supported-Features AVP and the M-bit of the Supported-Features AVP has to be set in the request command, according to 3GPPÊTSÊ29.229Ê[9] clauseÊ7.2.1. NOTE 2: Currently none of the features that can be included in the Supported-Features AVP of the ULR command requires that the HSS supports them to successfully process the ULR command. For this reason the MME or SGSN does not need to set the M-bit of the Supported-Features AVP in the ULR command. This corresponds to the exception to the general rule requiring the setting of the M-bit of the Supported-Features AVP in a request described in 3GPPÊTSÊ29.229Ê[9] clauseÊ7.2.1. Setting the M-bit of the Supported-Features AVP in the ULR command will mean that, if any of the features is not supported, the HSS will reject the ULR command as according to 3GPPÊTSÊ29.229Ê[9] clauseÊ7.2.1. 7.2 Commands 7.2.1 Introduction This clause defines the Command code values and related ABNF for each command described in this specification. 7.2.2 Command-Code values This clause defines Command-Code values for the S6a/S6d interface application and S13/S13' interface application as allocated by IANA in the IETFÊRFCÊ5516Ê[32]. Every command is defined by means of the ABNF syntax IETFÊRFCÊ2234Ê[7], according to the Command Code Format (CCF) specification defined in IETFÊRFCÊ6733Ê[61]. In the case, the definition and use of an AVP is not specified in this document, the guidelines in IETFÊRFCÊ6733Ê[61] shall apply. The Vendor-Specific-Application-Id AVP shall not be included in any command sent by Diameter nodes supporting applications defined in this specification. If the Vendor-Specific-Application-Id AVP is received in any of the commands defined in this specification, it shall be ignored by the receiving node. NOTE: The Vendor-Specific-Application-Id is included as an optional AVP in all Command Code Format specifications defined in this specification in order to overcome potential interoperability issues with intermediate Diameter agents non-compliant with the IETFÊRFCÊ6733Ê[61]. The following Command Codes are defined in this specification: Table 7.2.2/1: Command-Code values for S6a/S6d Command-Name Abbreviation Code Clause Update-Location-Request ULR 316 7.2.3 Update-Location-Answer ULA 316 7.2.4 Cancel-Location-Request CLR 317 7.2.7 Cancel-Location-Answer CLA 317 7.2.8 Authentication-Information-Request AIR 318 7.2.5 Authentication-Information-Answer AIA 318 7.2.6 Insert-Subscriber-Data-Request IDR 319 7.2.9 Insert-Subscriber-Data-Answer IDA 319 7.2.10 Delete-Subscriber-Data-Request DSR 320 7.2.11 Delete-Subscriber-Data-Answer DSA 320 7.2.12 Purge-UE-Request PUR 321 7.2.13 Purge-UE-Answer PUA 321 7.2.14 Reset-Request RSR 322 7.2.15 Reset-Answer RSA 322 7.2.16 Notify-Request NOR 323 7.2.17 Notify-Answer NOA 323 7.2.18 For these commands, the Application-ID field shall be set to 16777251 (application identifier of the S6a/S6d interface application, allocated by IANA). Table 7.2.2/2: Command-Code values for S13/S13' Command-Name Abbreviation Code Clause ME-Identity-Check-Request ECR 324 7.2.19 ME-Identity-Check-Answer ECA 324 7.2.20 For these commands, the Application-ID field shall be set to 16777252 (application identifier of the S13/S13' interface application, allocated by IANA). Table 7.2.2/3: Command-Code values for S7a/S7d Command-Name Abbreviation Code Clause Update-VCSG-Location-Request UVR 8388638 7.2.21 Update-VCSG-Location-Answer UVA 8388638 7.2.22 Insert-Subscription-Data-Request IDR 319 7.2.9 Insert-Subscription-Data-Answer IDA 319 7.2.10 Delete-Subscriber-Data-Request DSR 320 7.2.11 Delete-Subscriber-Data-Answer DSA 320 7.2.12 Reset-Request RSR 322 7.2.15 Reset-Answer RSA 322 7.2.16 Cancel-VCSG-Location-Request CVR 8388642 7.2.23 Cancel-VCSG-Location-Answer CVA 8388642 7.2.24 For these commands, the Application-ID field shall be set to 16777308 (application identifier of the S7a/S7d interface application, allocated by IANA). 7.2.3 Update-Location-Request (ULR) Command The Update-Location-Request (ULR) command, indicated by the Command-Code field set to 316 and the ""R"" bit set in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Update-Location-Request> ::= < Diameter Header: 316, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] [ Terminal-Information ] { RAT-Type } { ULR-Flags } [UE-SRVCC-Capability ] { Visited-PLMN-Id } [ SGSN-Number ] [ Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions ] [ GMLC-Address ] *[ Active-APN ] [ Equivalent-PLMN-List ] [ MME-Number-for-MT-SMS ] [ SMS-Register-Request ] [ SGs-MME-Identity ] [ Coupled-Node-Diameter-ID ] [ Adjacent-PLMNs ] [ Supported-Services ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.4 Update-Location-Answer (ULA) Command The Update-Location-Answer (ULA) command, indicated by the Command-Code field set to 316 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Update-Location-Answer> ::= < Diameter Header: 316, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] [ Error-Diagnostic ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] [ ULA-Flags ] [ Subscription-Data ] *[ Reset-ID ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.5 Authentication-Information-Request (AIR) Command The Authentication-Information-Request (AIR) command, indicated by the Command-Code field set to 318 and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Authentication-Information-Request> ::= < Diameter Header: 318, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[Supported-Features] [ Requested-EUTRAN-Authentication-Info ] [ Requested-UTRAN-GERAN-Authentication-Info ] { Visited-PLMN-Id } [ AIR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.6 Authentication-Information-Answer (AIA) Command The Authentication-Information-Answer (AIA) command, indicated by the Command-Code field set to318 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Authentication-Information-Answer> ::= < Diameter Header: 318, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] [ Error-Diagnostic ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[Supported-Features] [ Authentication-Info ] [ UE-Usage-Type ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.7 Cancel-Location-Request (CLR) Command The Cancel-Location-Request (CLR) command, indicated by the Command-Code field set to 317 and the 'R' bit set in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Cancel-Location-Request> ::= < Diameter Header: 317, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[Supported-Features ] { Cancellation-Type } [ CLR-Flags ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.8 Cancel-Location-Answer (CLA) Command The Cancel-Location-Answer (CLA) command, indicated by the Command-Code field set to 317 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Cancel-Location-Answer> ::= < Diameter Header: 317, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.9 Insert-Subscriber-Data-Request (IDR) Command The Insert-Subscriber-Data-Request (IDR) command, indicated by the Command-Code field set to 319 and the 'R' bit set in the Command Flags field, is sent from HSS or CSS to MME or SGSN. Message Format when used over the S6a or S6d application: < Insert-Subscriber-Data-Request> ::= < Diameter Header: 319, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features] { Subscription-Data} [ IDR- Flags ] *[ Reset-ID ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a or S7d application: < Insert-Subscriber-Data-Request> ::= < Diameter Header: 319, REQ, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] *{ VPLMN-CSG-Subscription-Data } *[ Reset-ID ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.10 Insert-Subscriber-Data-Answer (IDA) Command The Insert-Subscriber-Data-Answer (IDA) command, indicated by the Command-Code field set to 319 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS or CSS. Message Format when used over the S6a or S6d application: < Insert-Subscriber-Data-Answer> ::= < Diameter Header: 319, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ IMS-Voice-Over-PS-Sessions-Supported ] [ Last-UE-Activity-Time ] [ RAT-Type ] [ IDA-Flags ] [ EPS-User-State ] [ EPS-Location-Information ] [Local-Time-Zone ] [ Supported-Services ] *[ Monitoring-Event-Report ] *[ Monitoring-Event-Config-Status ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a or S7d application: < Insert-Subscriber-Data-Answer> ::= < Diameter Header: 319, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.11 Delete-Subscriber-Data-Request (DSR) Command The Delete-Subscriber Data-Request (DSR) command, indicated by the Command-Code field set to 320 and the 'R' bit set in the Command Flags field, is sent from HSS or CSS to MME or SGSN."
"Message Format when used over the S6a/S6d application: < Delete-Subscriber-Data-Request > ::= < Diameter Header: 320, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] { DSR-Flags } [ SCEF-ID ] *[ Context-Identifier ] [ Trace-Reference ] *[ TS-Code ] *[ SS-Code ] [ eDRX-Related-RAT ] *[ External-Identifier ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] The SCEF-ID shall be present when the flag ""Delete monitoring events"" in DSR-Flags AVP is set. Message Format when used over the S7a/S7d application: < Delete-Subscriber-Data-Request > ::= < Diameter Header: 320, REQ, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[ Supported-Features ] { DSR-Flags } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.12 Delete-Subscriber-Data-Answer (DSA) Command The Delete-Subscriber Data-Answer (DSA) command, indicated by the Command-Code field set to 320 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS or CSS. Message Format when used over the S6a/S6d application: < Delete-Subscriber-Data-Answer> ::= < Diameter Header: 320, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ DSA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a /S7d application: < Delete-Subscriber-Data-Answer> ::= < Diameter Header: 320, PXY, 16777308> < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.13 Purge-UE-Request (PUR) Command The Purge-UE-Request (PUR) command, indicated by the Command-Code field set to 321 and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Purge-UE-Request> ::= < Diameter Header: 321, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] [ PUR-Flags ] *[ Supported-Features ] [ EPS-Location-Information ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.14 Purge-UE-Answer (PUA) Command The Purge-UE-Answer (PUA) command, indicated by the Command-Code field set to 321 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Purge-UE-Answer> ::= < Diameter Header: 321, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] [ PUA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.15 Reset-Request (RSR) Command The Reset-Request (RSR) command, indicated by the Command-Code field set to 322 and the 'R' bit set in the Command Flags field, is sent from HSS or CSS to MME or SGSN. Message Format when used over the S6a/S6d application: < Reset-Request> ::= < Diameter Header: 322, REQ, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } *[ Supported-Features ] *[ User-Id ] *[ Reset-ID ] [ Subscription-Data ] [ Subscription-Data-Deletion ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a /S7d application: < Reset-Request> ::= < Diameter Header: 322, REQ, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } *[ Supported-Features ] *[ Reset-ID ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.16 Reset-Answer (RSA) Command The Reset-Answer (RSA) command, indicated by the Command-Code field set to 322 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to HSS or CSS. Message Format when used over the S6a/S6d application: < Reset-Answer> ::= < Diameter Header: 322, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] Message Format when used over the S7a /S7d application: < Reset-Answer> ::= < Diameter Header: 322, PXY, 16777308 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.17 Notify-Request (NOR) Command The Notify-Request (NOR) command, indicated by the Command-Code field set to 323 and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to HSS. Message Format < Notify-Request> ::= < Diameter Header: 323, REQ, PXY, 16777251 > < Session-Id > [ Vendor-Specific-Application-Id ] [ DRMP ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ OC-Supported-Features ] *[ Supported-Features ] [ Terminal-Information ] [ MIP6-Agent-Info ] [ Visited-Network-Identifier ] [ Context-Identifier ] [Service-Selection] [ Alert-Reason ] [ UE-SRVCC-Capability ] [ NOR-Flags ] [ Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions ] [ Maximum-UE-Availability-Time ] *[ Monitoring-Event-Config-Status ] [ Emergency-Services ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.18 Notify-Answer (NOA) Command The Notify-Answer (NOA) command, indicated by the Command-Code field set to 323 and the 'R' bit cleared in the Command Flags field, is sent from HSS to MME or SGSN. Message Format < Notify-Answer> ::= < Diameter Header: 323, PXY, 16777251 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ OC-Supported-Features ] [ OC-OLR ] *[ Load ] *[ Supported-Features ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.19 ME-Identity-Check-Request (ECR) Command The ME-Identity-Check-Request (ECR) command, indicated by the Command-Code field set to 324 and the 'R' bit set in the Command Flags field, is sent from MME or SGSN to EIR. Message Format < ME-Identity-Check-Request > ::= < Diameter Header: 324, REQ, PXY, 16777252 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { Terminal-Information } [ User-Name ] *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.20 ME-Identity-Check-Answer (ECA) Command The ME-Identity-Check-Answer (ECA) command, indicated by the Command-Code field set to 324 and the 'R' bit cleared in the Command Flags field, is sent from EIR to MME or SGSN. Message Format < ME-Identity-Check-Answer> ::= < Diameter Header: 324, PXY, 16777252 > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Equipment-Status ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.21 Update-VCSG-Location-Request (UVR) Command The Update-VCSG-Location-Request (UVR) command, indicated by the Command-Code field set to 8388638 and the ""R"" bit set in the Command Flags field, is sent from MME or SGSN to CSS. Message Format < Update-VCSG-Location-Request> ::= < Diameter Header: 8388638, REQ, PXY, > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } [ Destination-Host ] { Destination-Realm } { User-Name } [ MSISDN ] [ SGSN-Number ] *[ Supported-Features ] { UVR-Flags } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.22 Update-VCSG-Location-Answer (UVA) Command The Update-VCSG-Location-Answer (UVA) command, indicated by the Command-Code field set to 8388638 and the 'R' bit cleared in the Command Flags field, is sent from CSS to MME or SGSN. Message Format < Update-VCSG-Location-Answer> ::= < Diameter Header: 8388638, PXY, > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] [ Result-Code ] [ Experimental-Result ] [ Error-Diagnostic ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ Supported-Features ] *[ VPLMN-CSG-Subscription-Data ] [ UVA-Flags ] *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.23 Cancel-VCSG-Location-Request (CVR) Command The Cancel-VCSG-Location-Request (CVR) command, indicated by the Command-Code field set to 8388642 and the 'R' bit set in the Command Flags field, is sent from CSS to MME or SGSN. Message Format < Cancel-VCSG-Location-Request> ::= < Diameter Header: 8388642, REQ, PXY, > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] { Auth-Session-State } { Origin-Host } { Origin-Realm } { Destination-Host } { Destination-Realm } { User-Name } *[Supported-Features ] { Cancellation-Type } *[ AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.2.24 Cancel-VCSG-Location-Answer (CVA) Command The Cancel-VCSG-Location-Answer (CVA) command, indicated by the Command-Code field set to 8388642 and the 'R' bit cleared in the Command Flags field, is sent from MME or SGSN to CSS. Message Format < Cancel-VCSG-Location-Answer> ::= < Diameter Header: 8388642, PXY, > < Session-Id > [ DRMP ] [ Vendor-Specific-Application-Id ] *[ Supported-Features ] [ Result-Code ] [ Experimental-Result ] { Auth-Session-State } { Origin-Host } { Origin-Realm } *[ AVP ] [ Failed-AVP ] *[ Proxy-Info ] *[ Route-Record ] 7.3 Information Elements 7.3.1 General The following table specifies the Diameter AVPs defined for the S6a/S6d interface protocol, the S7a/S7d interface protocol and the S13/S13' interface protocol, their AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-ID header of all AVPs defined in this specification shall be set to 3GPP (10415). For all AVPs which contain bit masks and are of the type Unsigned32, e.g., ULR-Flags, DSR-Flags, PUA-Flags, etc., bit 0 shall be the least significant bit. For example, to get the value of bit 0, a bit mask of 0x0001 should be used. Table 7.3.1/1: S6a/S6d, S7a/S7d and S13/S13' specific DiameterAVPs AVP Flag rules Attribute Name AVP Code Clause defined Value Type Must May Should not Must not May Encr. Subscription-Data 1400 7.3.2 Grouped M, V No Terminal-Information 1401 7.3.3 Grouped M, V No IMEI 1402 7.3.4 UTF8String M, V No Software-Version 1403 7.3.5 UTF8String M, V No QoS-Subscribed 1404 7.3.77 OctetString M, V No ULR-Flags 1405 7.3.7 Unsigned32 M, V No ULA-Flags 1406 7.3.8 Unsigned32 M, V No Visited-PLMN-Id 1407 7.3.9 OctetString M, V No Requested-EUTRAN-Authentication-Info 1408 7.3.11 Grouped M, V No Requested-UTRAN-GERAN-Authentication-Info 1409 7.3.12 Grouped M, V No Number-Of-Requested-Vectors 1410 7.3.14 Unsigned32 M, V No Re-Synchronization-Info 1411 7.3.15 OctetString M, V No Immediate-Response-Preferred 1412 7.3.16 Unsigned32 M, V No Authentication-Info 1413 7.3.17 Grouped M, V No E-UTRAN-Vector 1414 7.3.18 Grouped M, V No UTRAN-Vector 1415 7.3.19 Grouped M, V No GERAN-Vector 1416 7.3.20 Grouped M, V No Network-Access-Mode 1417 7.3.21 Enumerated M, V No HPLMN-ODB 1418 7.3.22 Unsigned32 M, V No Item-Number 1419 7.3.23 Unsigned32 M, V No Cancellation-Type 1420 7.3.24 Enumerated M, V No DSR-Flags 1421 7.3.25 Unsigned32 M, V No DSA-Flags 1422 7.3.26 Unsigned32 M, V No Context-Identifier 1423 7.3.27 Unsigned32 M, V No Subscriber-Status 1424 7.3.29 Enumerated M, V No Operator-Determined-Barring 1425 7.3.30 Unsigned32 M, V No Access-Restriction-Data 1426 7.3.31 Unsigned32 M, V No APN-OI-Replacement 1427 7.3.32 UTF8String M, V No All-APN-Configurations-Included-Indicator 1428 7.3.33 Enumerated M, V No APN-Configuration-Profile 1429 7.3.34 Grouped M, V No APN-Configuration 1430 7.3.35 Grouped M, V No EPS-Subscribed-QoS-Profile 1431 7.3.37 Grouped M, V No VPLMN-Dynamic-Address-Allowed 1432 7.3.38 Enumerated M, V No STN-SR 1433 7.3.39 OctetString M, V No Alert-Reason 1434 7.3.83 Enumerate M, V No AMBR 1435 7.3.41 Grouped M, V No CSG-Subscription-Data 1436 7.3.78 Grouped M. V No CSG-Id 1437 7.3.79 Unsigned32 M, V No PDN-GW-Allocation-Type 1438 7.3.44 Enumerated M, V No Expiration-Date 1439 7.3.80 Time M, V No RAT-Frequency-Selection-Priority-ID 1440 7.3.46 Unsigned32 M, V No IDA-Flags 1441 7.3.47 Unsigned32 M, V No PUA-Flags 1442 7.3.48 Unsigned32 M, V No NOR-Flags 1443 7.3.49 Unsigned32 M, V No User-Id 1444 7.3.50 UTF8String V M No Equipment-Status 1445 7.3.51 Enumerated M, V No Regional-Subscription-Zone-Code 1446 7.3.52 OctetString M, V No RAND 1447 7.3.53 OctetString M, V No XRES 1448 7.3.54 OctetString M, V No AUTN 1449 7.3.55 OctetString M, V No KASME 1450 7.3.56 OctetString M, V No Trace-Collection-Entity 1452 7.3.98 Address M, V No Kc 1453 7.3.59 OctetString M, V No SRES 1454 7.3.60 OctetString M, V No PDN-Type 1456 7.3.62 Enumerated M, V No Roaming-Restricted-Due-To-Unsupported-Feature 1457 7.3.81 Enumerated M, V No Trace-Data 1458 7.3.63 Grouped M, V No Trace-Reference 1459 7.3.64 OctetString M, V No Trace-Depth 1462 7.3.67 Enumerated M, V No Trace-NE-Type-List 1463 7.3.68 OctetString M, V No Trace-Interface-List 1464 7.3.69 OctetString M, V No Trace-Event-List 1465 7.3.70 OctetString M, V No OMC-Id 1466 7.3.71 OctetString M, V No GPRS-Subscription-Data 1467 7.3.72 Grouped M, V No Complete-Data-List-Included-Indicator 1468 7.3.73 Enumerated M, V No PDP-Context 1469 7.3.74 Grouped M, V No PDP-Type 1470 7.3.75 OctetString M, V No 3GPP2-MEID 1471 7.3.6 OctetString M, V No Specific-APN-Info 1472 7.3.82 Grouped M, V No LCS-Info 1473 7.3.84 Grouped M, V No GMLC-Number 1474 7.3.85 OctetString M, V No LCS-PrivacyException 1475 7.3.86 Grouped M, V No SS-Code 1476 7.3.87 OctetString M, V No SS-Status 1477 7.3.88 OctetString M, V No Notification-To-UE-User 1478 7.3.89 Enumerated M, V No External-Client 1479 7.3.90 Grouped M, V No Client-Identity 1480 7.3.91 OctetString M, V No GMLC-Restriction 1481 7.3.92 Enumerated M, V No PLMN-Client 1482 7.3.93 Enumerated M, V No Service-Type 1483 7.3.94 Grouped M, V No ServiceTypeIdentity 1484 7.3.95 Unsigned32 M, V No MO-LR 1485 7.3.96 Grouped M, V No Teleservice-List 1486 7.3.99 Grouped M, V No TS-Code 1487 7.3.100 OctetString M, V No Call-Barring-Info 1488 7.3.101 Grouped M, V No SGSN-Number 1489 7.3.102 OctetString M, V No IDR-Flags 1490 7.3.103 Unsigned32 M, V No ICS-Indicator 1491 7.3.104 Enumerated V M No IMS-Voice-Over-PS-Sessions-Supported 1492 7.3.106 Enumerated V M No Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions 1493 7.3.107 Enumerated V M No Last-UE-Activity-Time 1494 7.3.108 Time V M No EPS-User-State 1495 7.3.110 Grouped V M No EPS-Location-Information 1496 7.3.111 Grouped V M No MME-User-State 1497 7.3.112 Grouped V M No SGSN-User-State 1498 7.3.113 Grouped V M No User-State 1499 7.3.114 Enumerated V M No MME-Location Information 1600 7.3.115 Grouped V M No SGSN-Location-Information 1601 7.3.116 Grouped V M No E-UTRAN-Cell-Global-Identity 1602 7.3.117 OctetString V M No Tracking-Area-Identity 1603 7.3.118 OctetString V M No Cell-Global-Identity 1604 7.3.119 OctetString V M No Routing-Area-Identity 1605 7.3.120 OctetString V M No Location-Area-Identity 1606 7.3.121 OctetString V M No Service-Area-Identity 1607 7.3.122 OctetString V M No Geographical-Information 1608 7.3.123 OctetString V M No Geodetic-Information 1609 7.3.124 OctetString V M No Current-Location-Retrieved 1610 7.3.125 Enumerated V M No Age-Of-Location-Information 1611 7.3.126 Unsigned32 V M No Active-APN 1612 7.3.127 Grouped V M No Error-Diagnostic 1614 7.3.128 Enumerated V M No Ext-PDP-Address 1621 7.3.129 Address V M No UE-SRVCC-Capability 1615 7.3.130 Enumerated V M No MPS-Priority 1616 7.3.131 Unsigned32 V M No VPLMN-LIPA-Allowed 1617 7.3.132 Enumerated V M No LIPA-Permission 1618 7.3.133 Enumerated V M No Subscribed-Periodic-RAU-TAU-Timer 1619 7.3.134 Unsigned32 V M No Ext-PDP-Type 1620 7.3.75A OctetString V M No SIPTO-Permission 1613 7.3.135 Enumerated V M No MDT-Configuration 1622 7.3.136 Grouped V M No Job-Type 1623 7.3.137 Enumerated V M No Area-Scope 1624 7.3.138 Grouped V M No List-Of-Measurements 1625 7.3.139 Unsigned32 V M No Reporting-Trigger 1626 7.3.140 Unsigned32 V M No Report-Interval 1627 7.3.141 Enumerated V M No Report-Amount 1628 7.3.142 Enumerated V M No Event-Threshold-RSRP 1629 7.3.143 Unsigned32 V M No Event-Threshold-RSRQ 1630 7.3.144 Unsigned32 v M No Logging-Interval 1631 7.3.145 Enumerated V M No Logging-Duration 1632 7.3.146 Enumerated V M No Relay-Node-Indicator 1633 7.3.147 Enumerated V M No MDT-User-Consent 1634 7.3.148 Enumerated V M No PUR-Flags 1635 7.3.149 Unsigned32 V M No Subscribed-VSRVCC 1636 7.3.150 Enumerated V M No Equivalent-PLMN-List 1637 7.3.151 Grouped V M No CLR-Flags 1638 7.3.152 Unsigned32 V M No UVR-Flags 1639 7.3.153 Unsigned32 M, V No UVA-Flags 1640 7.3.154 Unsigned32 M, V No VPLMN-CSG-Subscription-Data 1641 7.3.155 Grouped M, V No Time-Zone 1642 7.3.163 UTF8String V M No A-MSISDN 1643 7.3.157 OctetString V M No MME-Number-for-MT-SMS 1645 7.3.159 OctetString V M No SMS-Register-Request 1648 7.3.162 Enumerated V M No Local-Time-Zone 1649 7.3.156 Grouped V M No Daylight-Saving-Time 1650 7.3.164 Enumerated V M No Subscription-Data-Flags 1654 7.3.165 Unsigned32 V M No Measurement-Period-LTE 1655 7.3.166 Enumerated V M No Measurement-Period-UMTS 1656 7.3.167 Enumerated V M No Collection-Period-RRM-LTE 1657 7.3.168 Enumerated V M No Collection-Period-RRM-UMTS 1658 7.3.169 Enumerated V M No Positioning-Method 1659 7.3.170 OctetString V M No Measurement-Quantity 1660 7.3.171 OctetString V M No Event-Threshold-Event-1F 1661 7.3.172 Integer32 V M No Event-Threshold-Event-1I 1662 7.3.173 Integer32 V M No Restoration-Priority 1663 7.3.174 Unsigned32 V M No SGs-MME-Identity 1664 7.3.175 UTF8String V M No SIPTO-Local-Network-Permission 1665 7.3.176 Unsigned32 V M No Coupled-Node-Diameter-ID 1666 7.3.177 DiameterIdentity V M No WLAN-offloadability 1667 7.3.181 Grouped V M No WLAN-offloadability-EUTRAN 1668 7.3.182 Unsigned32 V M No WLAN-offloadability-UTRAN 1669 7.3.183 Unsigned32 V M No Reset-ID 1670 7.3.184 OctetString V M No MDT-Allowed-PLMN-Id 1671 7.3.185 OctetString V M No Adjacent-PLMNs 1672 7.3.186 Grouped V M No Adjacent-Access-Restriction-Data 1673 7.3.187 Grouped V M No DL-Buffering-Suggested-Packet-Count 1674 7.3.188 Integer32 V M No IMSI-Group-Id 1675 7.3.189 Grouped V M No Group-Service-Id 1676 7.3.190 Unsigned32 V M No Group-PLMN-Id 1677 7.3.191 OctetString V M No Local-Group-Id 1678 7.3.192 OctetString V M No AIR-Flags 1679 7.3.201 Unsigned32 V M No UE-Usage-Type 1680 7.3.202 Unsigned32 V M No Non-IP-PDN-Type-Indicator 1681 7.3.204 Enumerated V M No Non-IP-Data-Delivery-Mechanism 1682 7.3.205 Unsigned32 V M No Additional-Context-ID 1683 7.3.206 Unsigned32 V M No SCEF-Realm 1684 7.3.207 DiameterIdentity V M No Subscription-Data-Deletion 1685 7.3.208 Grouped V M No Preferred-Data-Mode 1686 7.3.209 Unsigned32 V M No Emergency-Info 1687 7.3.210 Grouped V M No V2X-Subscription-Data 1688 7.3.212 Grouped V M No V2X-Permission 1689 7.3.213 Unsigned32 V M No PDN-Connection-Continuity 1690 7.3.214 Unsigned32 V M No eDRX-Cycle-Length 1691 7.3.215 Grouped V M No eDRX-Cycle-Length-Value 1692 7.3.216 OctetString V M No UE-PC5-AMBR 1693 7.3.217 Unsigned32 V M No MBSFN-Area 1694 7.3.219 Grouped V M No MBSFN-Area-ID 1695 7.3.220 Unsigned32 V M No Carrier-Frequency 1696 7.3.221 Unsigned32 V M No RDS-Indicator 1697 7.3.222 Enumerated V M No Service-Gap-Time 1698 7.3.223 Unsigned32 V M No Aerial-UE-Subscription-Information 1699 7.3.224 Unsigned32 V M No Broadcast-Location-Assistance-Data-Types 1700 7.3.225 Unsigned64 V M No Paging-Time-Window 1701 7.3.226 Grouped V M No Operation-Mode 1702 7.3.227 Unsigned32 V M No Paging-Time-Window-Length 1703 7.3.228 OctetString V M No Core-Network-Restrictions 1704 7.3.230 Unsigned32 V M No eDRX-Related-RAT 1705 7.3.229 Grouped V M No Interworking-5GS-Indicator 1706 7.3.231 Enumerated V M No Ethernet-PDN-Type-Indicator 1707 7.3.232 Enumerated V M No Subscribed-ARPI 1708 7.3.233 Unsigned32 V M No IAB-Operation-Permission 1709 7.3.234 Enumerated V M No V2X-Subscription-Data-Nr 1710 7.3.235 Grouped V M No UE-PC5-QoS 1711 7.3.236 Grouped V M No PC5-QoS-Flow 1712 7.3.237 Grouped V M No 5QI 1713 7.3.238 Integer32 V M No PC5-Flow-Bitrates 1714 7.3.239 Grouped V M No Guaranteed-Flow-Bitrates 1715 7.3.240 Integer32 V M No Maximum-Flow-Bitrates 1716 7.3.241 Integer32 V M No PC5-Range 1717 7.3.242 Integer32 V M No PC5-Link-AMBR 1718 7.3.243 Integer32 V M No Third-Context-Identifier 1719 7.3.244 Unsigned32 V M No NOTE 1: The AVP header bit denoted as ""M"", indicates whether support of the AVP is required. The AVP header bit denoted as ""V"", indicates whether the optional Vendor-ID field is present in the AVP header. For further details, see IETFÊRFCÊ6733Ê[61]. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. The following table specifies the Diameter AVPs re-used by the S6a/S6d interface protocol from existing Diameter Applications, including a reference to their respective specifications and when needed, a short description of their use within S6a and S6d. Any other AVPs from existing Diameter Applications, except for the AVPs from Diameter base protocol specified in IETFÊRFCÊ6733Ê[61], do not need to be supported. The AVPs from the Diameter base protocol specified in IETFÊRFCÊ6733Ê[61] are not included in table 7.3.1/2, but they may be re-used for the S6a/S6d protocol, the S7a/S7protocol and the S13/S13' protocol. Table 7.3.1/2: S6a/S6d, S7a/S7d and S13/S13' re-used Diameter AVPs Attribute Name Reference Comments M-bit Service-Selection IETFÊRFCÊ5778Ê[20] See clauseÊ7.3.36 3GPP-Charging-Characteristics 3GPPÊTSÊ29.061Ê[21] See 3GPPÊTSÊ32.251Ê[33] Annex A and 3GPPÊTSÊ32.298Ê[22] clauseÊ5.1.2.2.7 This attribute holds the EPS PDN Connection Charging Characteristics data for an EPS APN Configuration, or the PDP context Charging Characteristics for GPRS PDP context, or the Subscribed Charging Characteristics data for the subscriber level 3GPP Charging Characteristics; refer to 3GPPÊTSÊ23.008Ê[30]. Supported-Features 3GPPÊTSÊ29.229Ê[9] Feature-List-ID 3GPPÊTSÊ29.229Ê[9] Feature-List 3GPPÊTSÊ29.229Ê[9] See clauseÊ7.3.10 Served-Party-IP-Address 3GPPÊTSÊ32.299Ê[8] holds the PDN IP Address of the user QoS-Class-Identifier 3GPPÊTSÊ29.212Ê[10] Allocation-Retention-Priority 3GPPÊTSÊ29.212Ê[10] See clauseÊ7.3.40 Priority-Level 3GPPÊTSÊ29.212Ê[10] Pre-emption-Capability 3GPPÊTSÊ29.212Ê[10] Pre-emption-Vulnerability 3GPPÊTSÊ29.212Ê[10] Max-Requested-Bandwidth-DL 3GPPÊTSÊ29.214Ê[11] Max-Requested-Bandwidth-UL 3GPPÊTSÊ29.214Ê[11] Extended-Max-Requested-BW-DL 3GPPÊTSÊ29.214Ê[11] Extended-Max-Requested-BW-UL 3GPPÊTSÊ29.214Ê[11] RAT-Type 3GPPÊTSÊ29.212Ê[10] See clauseÊ7.3.13 Must set MSISDN 3GPPÊTSÊ29.329Ê[25] MIP6-Agent-Info IETFÊRFCÊ5447Ê[26] MIP-Home-Agent-Address IETFÊRFCÊ4004Ê[27] MIP-Home-Agent-Host IETFÊRFCÊ4004Ê[27] PDP-Address 3GPPÊTSÊ32.299Ê[8] Confidentiality-Key 3GPPÊTSÊ29.229Ê[9] See clauseÊ7.3.57 Integrity-Key 3GPPÊTSÊ29.229Ê[9] See clauseÊ7.3.58 Visited-Network-Identifier 3GPPÊTSÊ29.229Ê[9] See clauseÊ7.3.105 Must not set GMLC-Address 3GPPÊTSÊ29.173Ê[37] See clauseÊ7.3.109 Must not set User-CSG-Information 3GPPÊTSÊ32.299Ê[8] Must not set ProSe-Subscription-Data 3GPPÊTSÊ29.344Ê[49] See clauseÊ7.3.180 Must not set OC-Supported-Features IETFÊRFCÊ7683Ê[50] See clauseÊ7.3.178 Must not set OC-OLR IETFÊRFCÊ7683Ê[50] See clauseÊ7.3.179 Must not set SCEF-Reference-ID 3GPPÊTSÊ29.336Ê[54] Must not set SCEF-ID 3GPPÊTSÊ29.336Ê[54] Must not set AESE-Communication-Pattern 3GPPÊTSÊ29.336Ê[54] see clauseÊ7.3.193 Must not set Communication-Pattern-set 3GPPÊTSÊ29.336Ê[54] see clauseÊ7.3.194 Must not set Monitoring-Event-Configuration 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.195 Must not set Monitoring-Event-Report 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.196 Must not set UE-Reachability-Configuration 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.197 Must not set eNodeB-ID 3GPPÊTSÊ29.217Ê[56] See clauseÊ7.3.198 Must not set SCEF-Reference-ID-for-Deletion 3GPPÊTSÊ29.336Ê[54] Must not set Monitoring-Type 3GPPÊTSÊ29.336Ê[54] Must not set Maximum-Number-of-Reports 3GPPÊTSÊ29.336Ê[54] Must not set Monitoring-Duration 3GPPÊTSÊ29.336Ê[54] Must not set Charged-Party 3GPPÊTSÊ29.336Ê[54] Must not set Location-Information-Configuration 3GPPÊTSÊ29.336Ê[54] Must not set Reachability-Type 3GPPÊTSÊ29.336Ê[54] Must not set Maximum-Response-Time 3GPPÊTSÊ29.336Ê[54] Must not set Reachability-Information 3GPPÊTSÊ29.336Ê[54] Must not set Reachability-Cause 3GPPÊTSÊ29.128Ê[63] Must not set Monitoring-Event-Config-Status 3GPPÊTSÊ29.336Ê[54] Must not set Supported-Services 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.199 Must not set Supported-Monitoring-Events 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.200 Must not set DRMP IETFÊRFCÊ7944Ê[57] See clauseÊ7.3.203 Must not set Reference-ID-Validity-Time 3GPPÊTSÊ29.336Ê[54] Must not set Maximum-UE-Availability-Time 3GPPÊTSÊ29.338Ê[48] See clauseÊ5.3.3.22 Must not set Emergency-Services 3GPPÊTSÊ29.273Ê[59] Load IETFÊRFCÊ8583Ê[60] See clauseÊ7.3.211 Must not set Extended-eNodeB-ID 3GPPÊTSÊ29.217Ê[56] See clauseÊ7.3.218 Must not set External-Identifier 3GPPÊTSÊ29.336Ê[54] Must not set Loss-Of-Connectivity-Reason 3GPPÊTSÊ29.336Ê[54] Must not set Active-Time 3GPPÊTSÊ29.128Ê[63] Must not set Idle-Status-Indication 3GPPÊTSÊ29.128Ê[63] Must not set MTC-Provider-Info 3GPPÊTSÊ29.336Ê[54] Must not set Traffic-Profile 3GPPÊTSÊ29.336Ê[54] Must not set PDN-Connectivity-Status-Configuration 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.195 Must not set PDN-Connectivity-Status-Report 3GPPÊTSÊ29.336Ê[54] See clauseÊ7.3.196 Must not set Battery-Indicator 3GPPÊTSÊ29.336Ê[54] Battery-Indicator SCEF-Reference-ID-Ext 3GPPÊTSÊ29.336Ê[54] Must not set SCEF-Reference-ID-for-Deletion-Ext 3GPPÊTSÊ29.336Ê[54] Must not set NOTE 1: The M-bit settings for re-used AVPs override those of the defining specifications that are referenced. Values include: ""Must set"", ""Must not set"". If the M-bit setting is blank, then the defining specification applies. NOTE 2: If the M-bit is set for an AVP and the receiver does not understand the AVP, it shall return a rejection. If the M-bit is not set for an AVP, the receiver shall not return a rejection, whether or not it understands the AVP. If the receiver understands the AVP but the M-bit value does not match with the definition in this table, the receiver shall ignore the M-bit. 7.3.2 Subscription-Data The Subscription-Data AVP is of type Grouped. It shall contain the information related to the user profile relevant for EPS and GERAN/UTRAN. AVP format: Subscription-Data ::= <AVP header: 1400 10415> [ Subscriber-Status ] [ MSISDN ] [ A-MSISDN ] [ STN-SR ] [ ICS-Indicator ] [ Network-Access-Mode ] [ Operator-Determined-Barring ] [ HPLMN-ODB ] *10[ Regional-Subscription-Zone-Code ] [ Access-Restriction-Data ] [ APN-OI-Replacement ] [ LCS-Info ] [ Teleservice-List ] *[ Call-Barring-Info ] [ 3GPP-Charging-Characteristics ] [ AMBR ] [ APN-Configuration-Profile ] [ RAT-Frequency-Selection-Priority-ID ] [ Trace-Data] [ GPRS-Subscription-Data ] *[ CSG-Subscription-Data ] [ Roaming-Restricted-Due-To-Unsupported-Feature ] [ Subscribed-Periodic-RAU-TAU-Timer ] [ MPS-Priority ] [ VPLMN-LIPA-Allowed ] [ Relay-Node-Indicator ] [ MDT-User-Consent ] [ Subscribed-VSRVCC ] [ ProSe-Subscription-Data ] [ Subscription-Data-Flags ] *[ Adjacent-Access-Restriction-Data ] [ DL-Buffering-Suggested-Packet-Count ] *[ IMSI-Group-Id ] [ UE-Usage-Type ] *[ AESE-Communication-Pattern ] *[ Monitoring-Event-Configuration ] [ Emergency-Info ] [ V2X-Subscription-Data ] [ V2X-Subscription-Data-Nr ] *[ eDRX-Cycle-Length ] [ External-Identifier ] [ Active-Time ] [ Service-Gap-Time ] [ Broadcast-Location-Assistance-Data-Types ] [ Aerial-UE-Subscription-Information ] [ Core-Network-Restrictions ] *[ Paging-Time-Window ] [ Subscribed-ARPI ] [ IAB-Operation-Permission ] *[ AVP ] The AMBR included in this grouped AVP shall include the AMBR associated to the user's subscription (UE-AMBR); Max-Requested-Bandwidth-UL and Max-Requested-Bandwidth-DL within this AVP shall not both be set to ""0"". The APN-OI-Replacement included in this grouped AVP shall include the UE level APN-OI-Replacement associated to the user's subscription. When multiple External Identifiers are defined for the same subscription, the External-Identifier in this grouped AVP shall contain a default External Identifier determined by the HSS. 7.3.3 Terminal-Information The Terminal-Information AVP is of type Grouped. This AVP shall contain the information about the user's terminal. AVP format Terminal-Information ::= <AVP header: 1401 10415> [ IMEI ] [ 3GPP2-MEID ] [ Software-Version ] *[ AVP ] 7.3.4 IMEI The IMEI AVP is of type UTF8String. This AVP shall contain the International Mobile Equipment Identity, as specified in 3GPPÊTSÊ23.003Ê[3]. It should consist of 14 digits, including the 8-digit Type Allocation Code (TAC) and the 6-digit Serial Number (SNR). It may also include a 15th digit. 7.3.5 Software-Version The Software-Version AVP is of type UTF8String. This AVP shall contain the 2-digit Software Version Number (SVN) of the International Mobile Equipment Identity, as specified in 3GPPÊTSÊ23.003Ê[3]. 7.3.6 3GPP2-MEID This AVP is of type OctetString. This AVP contains the Mobile Equipment Identifier of the user's terminal. For further details on the encoding of the AVP data, refer to the encoding of the Mobile Identity (MEID) octets 3 to 10 in 3GPP2 A.S0022Ê[28] Annex A. 7.3.7 ULR-Flags The ULR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.7/1: Table 7.3.7/1: ULR-Flags Bit Name Description 0 Single-Registration-Indication This bit, when set, indicates that the HSS shall send Cancel Location to the SGSN. An SGSN shall not set this bit when sending ULR. 1 S6a/S6d-Indicator This bit, when set, indicates that the ULR message is sent on the S6a interface, i.e. the source node is an MME (or a combined MME/SGSN to which the UE is attached via E-UTRAN). This bit, when cleared, indicates that the ULR message is sent on the S6d interface, i.e. the source node is an SGSN (or a combined MME/SGSN to which the UE is attached via UTRAN or GERAN). 2 Skip Subscriber Data This bit, when set, indicates that the HSS may skip subscription data in ULA. If the subscription data has changed in the HSS after the last successful update of the MME/SGSN, the HSS shall ignore this bit and send the updated subscription data. If the HSS effectively skips the sending of subscription data, the GPRS-Subscription-Data-Indicator flag can be ignored. 3 GPRS-Subscription-Data-Indicator This bit, when set, indicates that the HSS shall include in the ULA command the GPRS subscription data, if available in the HSS; it shall be included in the GPRS-Subscription-Data AVP inside the Subscription-Data AVP (see 7.3.2). Otherwise, the HSS shall not include the GPRS-Subscription-Data AVP in the response, unless the Update Location Request is received over the S6d interface and there is no APN configuration profile stored for the subscriber, or when the subscription data is returned by a Pre-Rel-8 HSS (via an IWF). A standalone MME shall not set this bit when sending a ULR. 4 Node-Type-Indicator This bit, when set, indicates that the requesting node is a combined MME/SGSN. This bit, when cleared, indicates that the requesting node is a single MME or SGSN; in this case, if the S6a/S6d-Indicator is set, the HSS may skip the check of those supported features only applicable to the SGSN, and if, in addition the MME does not request to be registered for SMS, the HSS may consequently skip the download of the SMS related subscription data to a standalone MME. NOTE2 5 Initial-Attach-Indicator This bit, when set, indicates that the HSS shall send Cancel Location to the MME or SGSN if there is the MME or SGSN registration. 6 PS-LCS-Not-Supported-By-UE This bit, when set, indicates to the HSS that the UE does not support neither UE Based nor UE Assisted positioning methods for Packet Switched Location Services. The MME shall set this bit on the basis of the UE capability information. The SGSN shall set this bit on the basis of the UE capability information and the access technology supported by the SGSN. 7 SMS-Only-Indication This bit, when set, indicates that the UE indicated ""SMS only"" when requesting a combined IMSI attach or combined RA/LU. 8 Dual-Registration-5G-Indicator This bit, when set by an MME over S6a interface, indicates that the HSS+UDM shall not send Nudm_UECM_DeregistrationNotification to the registered AMF (if any); when not set by an MME over S6a interface, it indicates that the HSS+UDM shall send Nudm_UECM_DeregistrationNotification to the registered AMF (if any). See 3GPPÊTSÊ29.503Ê[66]. An SGSN shall not set this bit when sending ULR over S6d interface. 9 Inter-PLMN-inter-MME handover This bit, when set by an MME over S6a interface, indicates that an inter PLMN inter MME (or AMF to MME) handover is ongoing. 10 Intra-PLMN-inter-MME handover This bit, when set by an MME over S6a interface, indicates that an intra PLMN inter MME (or AMF to MME) handover is ongoing. NOTE1: Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving HSS. NOTE2: If the MME is registered for SMS then the HSS will download the SMS related data also for the standalone MME. 7.3.8 ULA-Flags The ULA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.8/1: Table 7.3.8/1: ULA-Flags Bit Name Description 0 Separation Indication This bit, when set, indicates that the HSS stores SGSN number and MME number in separate memory. A Rel-8 HSS shall set the bit. An IWF interworking with a pre Rel-8 HSS/HLR shall clear the bit. 1 MME Registered for SMS This bit, when set, indicates that the HSS has registered the MME for SMS. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.9 Visited-PLMN-Id The Visited-PLMN-Id AVP is of type OctetString. This AVP shall contain the concatenation of MCC and MNC. See 3GPPÊTSÊ23.003Ê[3]. The content of this AVP shall be encoded as an octet string according to table 7.3.9-1. See 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.1.13, PLMN list, for the coding of MCC and MNC. If MNC is 2 digits long, bits 5 to 8 of octet 2 are coded as ""1111"". Table 7.3.9/1: Encoding format for Visited-PLMN-Id AVP 8 7 6 5 4 3 2 1 MCC digit 2 MCC digit 1 octet 1 MNC digit 3 MCC digit 3 octet 2 MNC digit 2 MNC digit 1 octet 3 7.3.10 Feature-List AVP 7.3.10.1 Feature-List AVP for the S6a/S6d application The syntax of this AVP is defined in 3GPPÊTSÊ29.229Ê[9]. For the S6a/S6d application, the meaning of the bits shall be as defined in table 7.3.10/1 for the Feature-List-ID 1 and in table 7.3.10/2 for the Feature-List-ID 2. Table 7.3.10/1: Features of Feature-List-ID 1 used in S6a/S6d Feature bit Feature M/O Description 0 ODB-all-APN O Operator Determined Barring of all Packet Oriented Services This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update by sending DIAMETER_ERROR_ROAMING_NOT_ALLOWED and, optionally, including the type of ODB in the Error-Diagnostic AVP. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 1 ODB-HPLMN-APN O Operator Determined Barring of Packet Oriented Services from access points that are within the HPLMN whilst the subscriber is roaming in a VPLMN This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update by sending DIAMETER_ERROR_ROAMING_NOT_ALLOWED and, optionally, including the type of ODB in the Error-Diagnostic AVP. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 2 ODB-VPLMN-APN O Operator Determined Barring of Packet Oriented Services from access points that are within the roamed to VPLMN This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update by sending DIAMETER_ERROR_ROAMING_NOT_ALLOWED and, optionally, including the type of ODB in the Error-Diagnostic AVP. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 3 ODB-all-OG O Operator Determined Barring of all outgoing calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 4 ODB-all- InternationalOG O Operator Determined Barring of all outgoing international calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs.If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 5 ODB-all-InternationalOGNotToHPLMN-Country O Operator Determined Barring of all outgoing international calls except those directed to the home PLMN country This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 6 ODB-all-InterzonalOG O Operator Determined Barring of all outgoing inter-zonal calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 7 ODB-all-InterzonalOGNotToHPLMN-Country O Operator Determined Barring of all outgoing inter-zonal calls except those directed to the home PLMN country This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 8 ODB-all-InterzonalOGAndInternationalOGNotToHPLMN-Country O Operator Determined Barring of all outgoing international calls except those directed to the home PLMN country and Barring of all outgoing inter-zonal calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send this ODB barring category to the MME or SGSN within ULA. Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent this ODB category within IDR, the HSS may apply barring of roaming and send CLR. 9 RegSub O Regional Subscription This feature is applicable for the ULR/ULA, IDR/IDA and DSR/DSA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send Regional Subscription Zone Codes to the MME or SGSN within ULA."
"Instead the HSS may reject location update. If the MME or SGSN does not indicate support of this feature in IDA and the HSS has sent Regional Subscription Zone Codes within IDR, the HSS may apply barring of roaming and send CLR. 10 Trace O Trace Function This feature is applicable for the ULR/ULA, IDR/IDA and DSR/DSA command pairs. If the MME or SGSN does not indicate support of this feature in ULR, the HSS shall not send Trace Data to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent Trace Data withinÊIDR, the HSS may store this indication, and not send any further Trace Data to that MME or SGSN. If the MME or SGSN does not indicate support of this feature in DSA, and the HSS has sent Trace Data withinÊDSR, the HSS may store this indication, and not send any further Trace Data to that MME or SGSN 11 LCS-all-PrivExcep (NOTE 1) O All LCS Privacy Exception Classes This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 12 LCS-Universal (NOTE 1) O Allow location by any LCS client This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 13 LCS-CallSessionRelated (NOTE 1) O Allow location by any value added LCS client to which a call/session is established from the target UE This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 14 LCS-CallSessionUnrelated (NOTE 1) O Allow location by designated external value added LCS clients This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 15 LCS-PLMNOperator (NOTE 1) O Allow location by designated PLMN operator LCS clients This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 16 LCS-ServiceType (NOTE 1) O Allow location by LCS clients of a designated LCS service type This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports MAP based Lg interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 17 LCS-all-MOLR-SS (NOTE 1) O All Mobile Originating Location Request Classes This feature is applicable for the ULR/ULA and IDR/IDA command pairs. Over S6d interface, this feature is applicable when the SGSN supports MAP based Lg interface. If the MME or SGSN does not support this feature, the HSS shall not send the related LCS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that MME or SGSN. 18 LCS- BasicSelfLocation (NOTE 1) O Allow an MS to request its own location This feature is applicable for the ULR/ULA and IDR/IDA command pairs. Over S6d interface, this feature is applicable when the SGSN supports MAP based Lg interface. If the MME or SGSN does not support this feature, the HSS shall not send the related LCS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that MME or SGSN. 19 LCS- AutonomousSelfLocation (NOTE 1) O Allow an MS to perform self location without interaction with the PLMN This feature is applicable for the ULR/ULA and IDR/IDA command pairs. Over S6d interface, this feature is applicable when the SGSN supports MAP based Lg interface. If the MME or SGSN does not support this feature, the HSS shall not send the related LCS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that MME or SGSN. 20 LCS- TransferToThirdParty O Allow an MS to request transfer of its location to another LCS client This feature is applicable for the ULR/ULA and IDR/IDA command pairs. Over S6d interface, this feature is applicable when the SGSN supports MAP based Lg interface. If the MME or SGSN does not support this feature, the HSS shall not send the related LCS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that MME or SGSN. 21 SM-MO-PP (NOTE 1) O Short Message MO-PP This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 22 Barring-OutgoingCalls O Barring of Outgoing Calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 23 BAOC O Barring of all outgoing calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 24 BOIC O Barring of outgoing international calls This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 25 BOICExHC O Barring of outgoing international calls except those directed to the home PLMN Country This feature is applicable for the ULR/ULA and IDR/IDA command pairs. If the MME or SGSN does not support this feature, the HSS shall not send the related SMS information to the MME or SGSN within ULA. If the MME or SGSN does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME or SGSN. 26 UE-Reachability-Notification O UE Reachability Notifcation This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support the UE-Reachability-Notifications, the HSS shall not set the ""UE-Reachability-Request"" bit in IDR-Flags in subsequent IDR commands towards that MME or SGSN. 27 T-ADS Data Retrieval O Terminating Access Domain Selection Data Retrieval This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support the retrieval of T-ADS data via IDR/IDA commands, the HSS shall not set the ""T-ADS Data Request"" bit in IDR-Flags in subsequent IDR commands towards that MME or SGSN. 28 State/Location-Information-Retrieval O State/Location Information Retrieval This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support State/Location Information Retrieval, the HSS shall not set the ""EPS User State Request"", ""EPS Location Information Request"" or ""Current Location Request"" bits in IDR-Flags in subsequent IDR commands towards that MME or SGSN. 29 Partial Purge O Partial Purge from a Combined MME/SGSN This feature is applicable for the ULR/ULA and PUR/PUA command pairs, over S6a and S6d. If the HSS indicates in the ULA command that it does not support Partial Purge, the combined MME/SGSN shall not include in the PUR command the indication of the specific serving node where the Purge has been done. 30 Local Time Zone Retrieval O UE Time Zone Retrieval This feature is applicable for the ULR/ULA and IDR/IDA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support the retrieval of Local Time Zone via IDR/IDA commands, the HSS shall not set the ""Local Time Zone Request"" bit in IDR-Flags in subsequent IDR commands towards that MME or SGSN. 31 Additional MSISDN O Additional MSISDN This feature is applicable for the ULR/ULA, IDR/IDA and DSR/DSA command pairs, over S6a and S6d. If the MME or SGSN indicates in the ULR command that it does not support A-MSISDN, the HSS shall populate the MSISDN AVP either with the subscribed MSISDN or the subscribed additional MSISDN based on operator policy and availability and the HSS shall not send IDR with the A-MSISDN AVP or DSR with the ""A-MSISDN Withdrawal"" bit to the serving nodes when the subscription data is changed. If the MME or SGSN indicates in the IDA command that it does not support this feature and the HSS has already sent an A-MSISDN value withinÊIDR, the HSS may store this indication and not send any further A-MSISDN updates to that MME or SGSN. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""ODB-HPLMN-APN"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. NOTE 1: If both bits, corresponding to the feature defined for Lg interface and Lgd interface respectively, are not set, and the HSS supports the feature, the HSS shall not send the related LCS information to the SGSN within ULA and IDR. Table 7.3.10/2: Features of Feature-List-ID 2 used in S6a/S6d Feature bit Feature M/O Description 0 SMS in MME O SMS in MME This feature is applicable for the ULR/ULA, IDR/IDA, DSR/DSA, NOR/NOA command pairs, over S6a. It is used by the MME to notify the HSS it is capable of SMS transfer without the need of establishing an SGs association with an MSC. If the MME does not support this feature, the HSS shall not send the related SMS information to the MME within ULA. If the MME does not indicate support of this feature in IDA, and the HSS has sent the related SMS information withinÊIDR, the HSS may store this indication, and not send any further SMS information to that MME. If the HSS does not support this feature, the HSS shall ignore any request for a registration for SMS; the MME may store this feature indication, and not send any further request for a registration for SMS to the HSS. 1 SMS in SGSN O SMS in SGSN This feature is applicable for the ULR/ULA command pair, over S6d. If the SGSN indicates in the ULR command that it does not support this feature, the HSS shall not indicate ""SMS in SGSN Allowed"" to the SGSN. 2 Dia-LCS-all-PrivExcep (NOTE 1) O All LCS Privacy Exception Classes This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 3 Dia-LCS-Universal (NOTE 1) O Allow location by any LCS client This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 4 Dia-LCS-CallSessionRelated (NOTE 1) O Allow location by any value added LCS client to which a call/session is established from the target UE This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 5 Dia-LCS-CallSessionUnrelated (NOTE 1) O Allow location by designated external value added LCS clients This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 6 Dia-LCS-PLMNOperator (NOTE 1) O Allow location by designated PLMN operator LCS clients This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 7 Dia-LCS-ServiceType (NOTE 1) O Allow location by LCS clients of a designated LCS service type This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 8 Dia-LCS-all-MOLR-SS (NOTE 1) O All Mobile Originating Location Request Classes This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 9 Dia-LCS- BasicSelfLocation (NOTE 1) O Allow an MS to request its own location This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 10 Dia-LCS- AutonomousSelfLocation (NOTE 1) O Allow an MS to perform self location without interaction with the PLMN This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 11 Dia-LCS- TransferToThirdParty (NOTE 1) O Allow an MS to request transfer of its location to another LCS client This feature is applicable for the ULR/ULA and IDR/IDA command pairs over the S6d interface, when the SGSN supports Diameter based Lgd interface. If the SGSN does not support this feature, the HSS shall not send the related LCS information to the SGSN within ULA. If the SGSN does not indicate support of this feature in IDA, and the HSS has sent the related LCS information withinÊIDR, the HSS may store this indication, and not send any further LCS information to that SGSN. 12 Gdd-in-SGSN O Support of Diameter based Gdd interface for SMS in SGSN This feature is applicable for the ULR/ULA command pair over S6d, when the SGSN supports the Diameter based Gdd interface for SMS in SGSN. 13 Optimized-LCS-Proc-Support O Support for the optimized LCS procedure This feature is applicable for the ULR/ULA command pair over S6a/S6d, when the network supports ISR and when the node is combined MME/SGSN and supports optimized LCS procedure as described in 3GPPÊTSÊ29.172Ê[47] clauseÊ6.2.2. 14 SGSN CAMEL Capability O Support of SGSN CAMEL Capability This feature is applicable for the ULR/ULA command pair over S6d, when the SGSN supports the CAMEL capability. 15 ProSe Capability O Support of ProSe Capability This feature is applicable for the ULR/ULA and IDR/IDA command pairs over S6a (and S6d), when the MME (or combined MME/SGSN) supports the ProSe capability. If the MME or combined MME/SGSN does not support this feature, the HSS shall not send the related ProSe subscription data to the MME or combined MME/SGSN within ULA. If the MME or combined MME/SGSN does not indicate support of this feature in IDA, and the HSS has sent the related ProSe subscription data withinÊIDR, the HSS may store this indication, and not send any further ProSe subscription data to that MME. 16 P-CSCF Restoration O Support of P-CSCF Restoration This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a or S6d interfaces, when the MME or SGSN supports the execution of the P-CSCF restoration procedures. If the MME or the SGSN does not indicate support of this feature in ULR, the HSS shall not send subsequent IDR commands requesting the execution of HSS-based P-CSCF restoration procedures, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4. 17 Reset-IDs O Support of Reset-IDs This feature is applicable to the ULR/ULA and IDR/IDA and DSR/DSA and RSR/RSA command pairs over the S6a and S6d interfaces. If the MME or SGSN indicates in the ULR command that it does not support Reset-IDs, the HSS shall not include Reset-ID AVPs in RSR commands sent to that MME or SGSN. If the MME or SGSN indicates that it does not support this feature in IDA, and the HSS has already sent a Reset-ID value within IDR, the HSS may store this indication and not send any further Reset-ID updates to that MME or SGSN. 18 Communication-Pattern O Support of AESE communication patterns This feature is applicable to the ULR/ULA and IDR/IDA command pairs over S6a (and S6d), when the MME (or combined MME/SGSN) supports the AESE communication patterns. If the MME or combined MME/SGSN does not indicate the support for this feature, the HSS shall not send CP parameter sets to the MME or combined MME/SGSN within IDR/ULA command. If the MME or combined MME/SGSN indicates that it does not support this feature in IDA, and the HSS has already sent CP parameter sets within IDR, the HSS may store this indication and not send any further updates related to CP parameter sets to that MME or combined MME/SGSN. 19 Monitoring-Event O Support of Monitoring Event This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a or S6d interfaces, when the MME or SGSN supports the Monitoring event feature. If the MME or SGSN does not indicate support of this feature in ULR, the HSS shall not send Monitoring event configuration data to the MME or SGSN within ULA and shall not send subsequent IDR commands requesting the configuration of Monitoring events in the MME or SGSN. If the MME or SGSN indicates that it does not support this feature in IDA, and the HSS has already sent Monitoring event configuration data within IDR, the HSS may store this indication and not send any further updates related to Monitoring events to that MME or SGSN. 20 Dedicated Core Networks O Support of Dedicated Core Networks This feature is applicable to the ULR/ULA, IDR/IDA and DSR/DSA command pairs over the S6a and S6d interfaces. If the MME/SGSN does not indicate support of this feature in the ULR command, the HSS shall not send DCN-related subscription data (e.g., UE Usage Type) in ULA, and shall not send subsequent IDR or DSR commands when such subscription data are updated. If the MME/SGSN does not indicate support of this feature in the IDA command and the HSS has already sent DCN-related subscription data in IDR, the HSS may store this indication and not send further updates related to DCN subscription data. 21 Non-IP PDN Type APNs O Support of Non-IP PDN Type APNs This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a and S6d interfaces. If the MME/SGSN does not indicate support of this feature in the ULR command, the HSS shall not send APN configurations with a Non-IP PDN type in the subscription data sent in ULA or in IDR, and shall not send IDR commands with the only purpose to update such subscription data. If the MME or SGSN indicates in the IDA command that it does not support this feature, and the HSS has already sent Non-IP PDN Type APNs withinÊIDR, the HSS may store this indication, and not send any further updates related to Non-IP PDN Type APNs to that MME or SGSN. 22 Non-IP PDP Type APNs O Support of Non-IP PDP Type APNs This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a/S6d interface. If the MME/SGSN does not indicate support of this feature in the ULR command, the HSS shall not send PDP contexts (as part of the GPRS-Subscription-Data) with a Non-IP PDP type in the subscription data sent in ULA or in IDR, and shall not send IDR commands with the only purpose to update such subscription data. If the MME or SGSN indicates in the IDA command that it does not support this feature, and the HSS has already sent Non-IP PDP Type APNs withinÊIDR, the HSS may store this indication, and not send any further updates related to Non-IP PDP Type APNs to that MME or SGSN. 23 Removal of MSISDN O Support of Removal of MSISDN This feature is applicable to the ULR/ULA and DSR/DSA command pairs over the S6a/S6d interface. If the MME/SGSN does not indicate support of this feature in the ULR command, the HSS shall not send DSR with the ""MSISDN Withdrawal"" bit set, to remove an existing MSISDN value from the subscription profile stored in the MME/SGSN. 24 Emergency Service Continuity O Support of Emergency Services Continuity This feature is applicable to the ULR/ULA, NOR/NOA and IDR/IDA command pairs over the S6a interface, when the HSS and the MME support the continuity of emergency services upon mobility between 3GPP and WLAN accesses, as specified in 3GPPÊTSÊ23.401Ê[2], or continuity of emergency services upon mobility between EPS and 5GS without N26 interface, as specified in 3GPPÊTSÊ23.502Ê[67]. If the MME does not indicate support of this feature in a former ULR command, the HSS shall not include the Emergency Info in an ULA command and shall not send an IDR command to update the PGW in use for emergency services. If the HSS does not indicate support of this feature in a former ULA command, the MME shall not send a NOR command to update the PGW in use for emergency services. If the HSS supports this feature on S6a, it shall also support the Emergency Service Continuity feature on SWx, see 3GPPÊTSÊ29.273Ê[59]. 25 V2X Capability O Support of V2X Service This feature is applicable for the ULR/ULA and IDR/IDA command pairs over S6a (and S6d), when the MME (or combined MME/SGSN) supports the V2X service. If the MME or combined MME/SGSN does not support this feature, the HSS shall not send the related V2X subscription data to the MME or combined MME/SGSN within ULA. If the MME or combined MME/SGSN does not indicate support of this feature in IDA, and the HSS has sent the related V2X subscription data withinÊIDR, the HSS may store this indication, and not send any further V2X subscription data to that MME or that combined MME/SGSN. 26 External-Identifier O Support of External-Identifier This feature is applicable for the ULR/ULA, DSR/DSA and IDR/IDA command pairs over S6a (and S6d), when the MME (or combined MME/SGSN) supports the External-Identifier. If the MME or combined MME/SGSN does not support this feature: -The HSS shall not send the External-Identifier subscription data to the MME or combined MME/SGSN within ULA. -The HSS shall not send Monitoring Event configuration for UEs that are part of a group and have no MSISDN as part of its subscription data to the MME/SGSN. -The HSS shall not indicate External-Identifier-Withdrawal in the DSR-Flags AVP of the DSR. 27 NR as Secondary RAT O Support of NR as Secondary RAT This feature is applicable to the ULR/ULA and IDR/IDA command pairs over S6a (and S6d) when the MME (or combined MME/SGSN) supports NR as Secondary RAT, and over S6d when the SGSN supports the indication related to NR as Secondary RAT (such as, e.g., the related Access Restriction Data, or extended QoS parameters). If the MME, SGSN, or combined MME/SGSN does not support this feature, the HSS shall not send (in ULA) or update (in IDR) subscription data related to NR as Secondary RAT. If the HSS does not support this feature, the MME shall ignore the bit ""NR as Secondary RAT Not Allowed"" in Access-Restriction-Data. 28 Unlicensed Spectrum as Secondary RAT O Support of Unlicensed Spectrum as Secondary RAT This feature is applicable to the ULR/ULA and IDR/IDA command pairs over S6a (and S6d) when the MME (or combined MME/SGSN) supports the use of unlicensed spectrum in the form of LAA or LWA/LWIP as Secondary RAT. If the MME (or combined MME/SGSN) does not support this feature, the HSS shall not send (in ULA) or update (in IDR) subscription data related to the use of unlicensed spectrum in the form of LAA, LWA/LWIP or NR in unlicensed bands as Secondary RAT (such as, e.g., the related Access Restriction Data). If the HSS does not support this feature, the MME shall ignore the bit ""Unlicensed Spectrum as Secondary RAT Not Allowed"" in Access-Restriction-Data. 29 Ethernet PDN Type APNs O Support of Ethernet PDN Type APNs This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a and S6d interfaces. If the MME (or combined MME/SGSN) does not indicate support of this feature in the ULR command, the HSS shall not send APN configurations with an Ethernet PDN type in the subscription data sent in ULA or in IDR, and shall not send IDR commands with the only purpose to update such subscription data. If the MME (or combined MME/SGSN) indicates in the IDA command that it does not support this feature, and the HSS has already sent Ethernet PDN Type APNs withinÊIDR, the HSS may store this indication, and not send any further updates related to Ethernet PDN Type APNs to that MME (or combined MME/SGSN). 30 Extended Reference IDs O Extended Reference IDs This feature is applicable to the ULR/ULA and IDR/IDA command pairs over the S6a or S6d interfaces, when the HSS and MME/SGSN support handling 64-bit long Reference IDs. If the MME or SGSN does not indicate support of this feature in ULR, the HSS shall not send ULA or IDR commands containing 64-bit long SCEF Reference IDs or SCEF Reference IDs for Deletion. Feature bit: The order number of the bit within the Supported-Features AVP, e.g. ""1"". Feature: A short name that can be used to refer to the bit and to the feature, e.g. ""SMS in MME"". M/O: Defines if the implementation of the feature is mandatory (""M"") or optional (""O""). Description: A clear textual description of the feature. NOTE 1: If both bits, corresponding to the same feature defined for Lg interface and Lgd interface, are not set, and the HSS supports the feature, the HSS shall not send the related LCS information to the SGSN within ULA and IDR. Features that are not indicated in the Supported-Features AVPs within a given application message shall not be used to construct that message. 7.3.10.2 Feature-List AVP for the S7a/S7d application For the S7a/S7d application, the feature list does not contain any feature in this release. 7.3.11 Requested-EUTRAN-Authentication-Info The Requested-EUTRAN-Authentication-Info is of type Grouped. It shall contain the information related to the authentication requests for E-UTRAN. AVP format Requested-EUTRAN-Authentication-Info ::= <AVP header: 1408 10415> [ Number-Of-Requested-Vectors ] [ Immediate-Response-Preferred ] [ Re-synchronization-Info ] *[AVP] 7.3.12 Requested-UTRAN- GERAN-Authentication-Info The Requested-UTRAN-GERAN-Authentication-Info is of type Grouped. It shall contain the information related to the to authentication requests for UTRAN or GERAN. AVP format Requested-UTRAN-GERAN-Authentication-Info ::= <AVP header: 1409 10415> [ Number-Of-Requested-Vectors] [ Immediate-Response-Preferred ] [ Re-synchronization-Info ] *[AVP] 7.3.13 RAT-Type The RAT-Type AVP is of type Enumerated and is used to identify the radio access technology that is serving the UE. See 3GPPÊTSÊ29.212Ê[10] for the defined values. 3GPPÊTSÊ29.212Ê[10] defines distinct RAT-Type values for EUTRAN (WB-EUTRAN), EUTRAN-NB-IoT, LTE-M, WB-EUTRAN over satellite access, EUTRAN-NB-IoT over satellite access, LTE-M over satellite access; these values shall be used in the signaling between the serving nodes (MME/SGSN) and the HSS, e.g. to determine the corresponding access restrictions for the UE. 7.3.14 Number-Of-Requested-Vectors The Number-Of-Requested-Vectors AVP is of type Unsigned32. This AVP shall contain the number of AVs the MME or SGSN is prepared to receive. 7.3.15 Re-Synchronization-Info The Re-Synchronization-Info AVP is of type OctetString. It shall contain the concatenation of RAND and AUTS. 7.3.16 Immediate-Response-Preferred The Immediate-Response-Preferred AVP is of type Unsigned32. This optional AVP indicates by its presence that immediate response is preferred, and by its absence that immediate response is not preferred. If present, the value of this AVP is not significant. When EUTRAN-AVs and UTRAN-AVs or GERAN-AVs are requested, presence of this AVP within the Requested-EUTRAN-Authentication-Info AVP shall indicate that EUTRAN-AVs are requested for immediate use in the MME/SGSN; presence of this AVP within the Requested-UTRAN-GERAN-Authentication-Info AVP shall indicate that UTRAN-AVs or GERAN-AVs are requested for immediate use in the MME/SGSN. It may be used by the HSS to determine the number of vectors to be obtained from the AuC and the number of vectors downloaded to the MME or SGSN. 7.3.17 Authentication-Info The Authentication-Info AVP is of type Grouped. This AVP contains Authentication Vectors. AVP format: Authentication-Info ::= <AVP header: 1413 10415> *[ E-UTRAN-Vector ] *[UTRAN-Vector] *[GERAN-Vector] *[AVP] 7.3.18 E-UTRAN-Vector The E-UTRAN-Vector AVP is of type Grouped. This AVP shall contain an E-UTRAN Vector. AVP format: E-UTRAN-Vector ::= <AVP header: 1414 10415> [ Item-Number ] { RAND } { XRES } { AUTN } { KASME } *[AVP] 7.3.19 UTRAN-Vector The UTRAN-Vector AVP is of type Grouped. This AVP shall contain an UTRAN Vector. AVP format: UTRAN-Vector ::= <AVP header: 1415 10415> [ Item-Number ] { RAND } { XRES } { AUTN } { Confidentiality-Key } { Integrity-Key } *[AVP] 7.3.20 GERAN-Vector The GERAN-Vector AVP is of type Grouped. This AVP shall contain a GERAN Vector. AVP format: GERAN-Vector ::= <AVP header: 1416 10415> [ Item-Number ] { RAND } { SRES } { Kc } *[AVP] 7.3.21 Network-Access-Mode The Network-Access-Mode AVP is of type Enumerated. The following values are defined: PACKET_AND_CIRCUIT (0) Reserved (1) ONLY_PACKET (2) 7.3.22 HPLMN-ODB The HPLMN-ODB AVP is of type Unsigned32 and it shall contain a bit mask indicating the HPLMN specific services of a subscriber that are barred by the operator. The meaning of the bits is HPLMN specific: Table 7.3.22/1: HPLMN-ODB Bit Description 0 HPLMN specific barring type 1 1 HPLMN specific barring type 2 2 HPLMN specific barring type 3 3 HPLMN specific barring type 4 HPLMN-ODB may apply to mobile originated short messages; See 3GPPÊTSÊ23.015Ê[36]. 7.3.23 Item-Number The Item-Number AVP is of type Unsigned32. The Item Number is used to order Vectors received within one request. 7.3.24 Cancellation-Type The Cancellation-Type AVP is of type Enumerated and indicates the type of cancellation. The following values are defined: MME_UPDATE_PROCEDURE (0) This value is used when the Cancel Location is sent to the previous MME due to a received Update Location message from a new MME or due to the HSS+UDM receiving an Nudm_UEContextManagement service request from the AMF or due to the HSS receiving Nhss_UECM_SNDeregistration service operation from UDM (see clauseÊ5.4.2.2 of 3GPPÊTSÊ29.563Ê[70]). SGSN_UPDATE_PROCEDURE (1) This value is used when the Cancel Location is sent to the previous SGSN due to a received Update Location message from a new SGSN or due to the HSS+UDM receiving an Nudm_UEContextManagement service request from the AMF or due to the HSS receiving Nhss_UECM_SNDeregistration service operation from UDM (see clauseÊ5.4.2.2 of 3GPPÊTSÊ29.563Ê[70])."
"SUBSCRIPTION_WITHDRAWAL (2) This value is used: - when the Cancel Location is sent by the HSS to the current MME or SGSN due to withdrawal of the user's subscription by the HSS operator; - when the Cancel VCSG Location is sent by the CSS to the current MME or SGSN due to withdrawal of the user's VPLMN CSG subscription by the CSS operator. UPDATE_PROCEDURE_IWF (3) This value is used by an IWF when interworking with a pre-Rel-8 HSS. INITIAL_ATTACH_PROCEDURE (4) This value is used when the Cancel Location is sent to the MME or SGSN due to a received Update Location message during initial attach procedure from an SGSN or MME respectively. 7.3.25 DSR-Flags The DSR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits is defined in table 7.3.25/1: Table 7.3.25/1: DSR-Flags Bit Name Description 0 Regional Subscription Withdrawal This bit, when set, indicates that Regional Subscription shall be deleted from the subscriber data. 1 Complete APN Configuration Profile Withdrawal This bit, when set, indicates that all EPS APN configuration data for the subscriber shall be deleted from the subscriber data. This flag only applies to the S6d interface. 2 Subscribed Charging Characteristics Withdrawal This bit, when set, indicates that the Subscribed Charging Characteristics have been deleted from the subscription data. 3 PDN subscription contexts Withdrawal This bit, when set, indicates that the PDN subscription contexts whose identifier is included in the Context-Identifier AVP shall be deleted. (Note 1) 4 STN-SR This bit, when set, indicates that the Session Transfer Number for SRVCC shall be deleted from the subscriber data. 5 Complete PDP context list Withdrawal This bit, when set, indicates that all PDP contexts for the subscriber shall be deleted from the subscriber data. 6 PDP contexts Withdrawal This bit, when set, indicates that the PDP contexts whose identifier is included in the Context-Identifier AVP shall be deleted. (Note 2) 7 Roaming Restricted due to unsupported feature This bit, when set, indicates that the roaming restriction shall be deleted from the subscriber data in the MME or SGSN. 8 Trace Data Withdrawal This bit, when set, indicates that the Trace Data shall be deleted from the subscriber data. 9 CSG Deleted This bit, when set, indicates that - the ""CSG-Subscription-Data from HSS"" shall be deleted in the MME or SGSN when received over the S6a or S6d interface - the ""CSG-Subscription-Data from CSS"" shall be deleted in the MME or SGSN when received over the S7a or S7d interface. 10 APN-OI-Replacement This bit, when set, indicates that the UE level APN-OI-Replacement shall be deleted from the subscriber data. 11 GMLC List Withdrawal This bit, when set, indicates that the subscriber's LCS GMLC List shall be deleted from the MME or SGSN. 12 LCS Withdrawal This bit, when set, indicates that the LCS service whose code is included in the SS-Code AVP shall be deleted from the MME or SGSN. 13 SMS Withdrawal This bit, when set, indicates that the SMS service whose code is included in the SS-Code AVP or TS-Code AVP shall be deleted from the MME or SGSN. 14 Subscribed periodic RAU-TAU Timer Withdrawal This bit, when set, indicates that the subscribed periodic RAU TAU Timer value shall be deleted from the subscriber data. 15 Subscribed VSRVCC Withdrawal This bit, when set, indicates that the Subscribed VSRVCC shall be deleted from the subscriber data. 16 A-MSISDN Withdrawal This bit, when set, indicates that the additional MSISDN, if present, shall be deleted from the subscriber data. 17 ProSe Withdrawal This bit, when set, indicates that the ProSe subscription data shall be deleted from the MME or combined MME/SGSN. 18 Reset-IDs This bit, when set, indicates that the set of Reset-IDs shall be deleted from the MME or SGSN. 19 DL-Buffering-Suggested-Packet-Count Withdrawal This bit, when set, indicates that the DL-Buffering-Suggested-Packet-Count shall be deleted in the MME or SGSN. 20 Subscribed IMSI-Group-Id Withdrawal This bit, when set, indicates that all subscribed IMSI-Group-Id(s) shall be deleted in the MME or SGSN. 21 Delete monitoring events This bit when set indicates to the MME or SGSN to delete all the Monitoring events for the subscriber which are associated with the provided SCEF-ID. 22 User Plane Integrity Protection Withdrawal This bit, when set, indicates to the SGSN that User Plane Integrity Protection may no longer be required when GERAN is used. The MME shall ignore it. 23 MSISDN Withdrawal This bit, when set, indicates that the MSISDN shall be deleted from the subscriber data. It is also used by the MME/SGSN to delete those monitoring events created using the MSISDN. 24 UE Usage Type Withdrawal This bit, when set, indicates to the MME or SGSN that the UE Usage Type shall be deleted from the subscription data. 25 V2X Withdrawal This bit, when set, indicates that the V2X subscription data shall be deleted from the MME or combined MME/SGSN. 26 External-Identifier-Withdrawal This bit, when set, indicates that the External-Identifier shall be deleted from the subscriber data. It is also used by the MME/SGSN to delete those monitoring events created using the removed External Identifier or all monitoring events created for any External Identifier in case of removing the default External Identifier. 27 Aerial-UE-Subscription Withdrawal This bit, when set, indicates that the Aerial UE subscription shall be deleted from the subscriber data. 28 Paging Time Window Subscription Withdrawal This bit, when set, indicates that the Paging Time Window subscription shall be deleted from the subscriber data. 29 Active-Time-Withdrawal This bit, when set, indicates that the Active Time used for PSM shall be deleted from the subscriber data. 30 eDRX-Cycle-Length -Withdrawal This bit, when set, indicates that the eDRX-Cycle-Length shall be deleted from the subscriber data. . If the eDRX-Related-RAT is present in the DSR command, only the eDRX Cycle Length for indicated RAT types shall be deleted. Otherwise, the entire eDRX Cycle Length subscription for all RAT types shall be deleted. 31 Service-Gap-Time-Withdrawal This bit, when set, indicates that the Service Gap Time shall be deleted from the subscriber data. Note 1: If the Complete APN Configuration Profile Withdrawal bit is set, this bit should not be set. Note 2: If the Complete PDP context list Withdrawal bit is set, this bit should not be set. Note 3: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. Note 4: Bits 3 and 6 are excluding alternatives and shall not both be set. Note 5: When this AVP is transferred over the S7a/S7d interface, only the bit 9 (CSG Deleted) is meaningful, other bits shall be cleared. 7.3.26 DSA-Flags The DSA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits is defined in table 7.3.26/1: Table 7.3.26/1: DSA-Flags Bit Name Description 0 Network Node area restricted This bit, when set, shall indicate that the complete Network Node area (SGSN area) is restricted due to regional subscription. Note: Bits not defined in this table shall be cleared by the sending SGSN and discarded by the receiving HSS. 7.3.27 Context-Identifier The Context-Identifier AVP is of type Unsigned32. 7.3.28 Void 7.3.29 Subscriber-Status The 3GPP Subscriber Status AVP is of type Enumerated. It shall indicate if the service is barred or granted. The following values are defined: SERVICE_GRANTED (0) OPERATOR_DETERMINED_BARRING (1) 7.3.30 Operator-Determined-Barring The Operator-Determined-Barring AVP is of type Unsigned32 and it shall contain a bit mask indicating the services of a subscriber that are barred by the operator. The meaning of the bits is the following: Table 7.3.30/1: Operator-Determined-Barring Bit Description 0 All Packet Oriented Services Barred 1 Roamer Access HPLMN-AP Barred 2 Roamer Access to VPLMN-AP Barred 3 Barring of all outgoing calls 4 Barring of all outgoing international calls 5 Barring of all outgoing international calls except those directed to the home PLMN country 6 Barring of all outgoing inter-zonal calls 7 Barring of all outgoing inter-zonal calls except those directed to the home PLMN country 8 Barring of all outgoing international calls except those directed to the home PLMN country and Barring of all outgoing inter-zonal calls 7.3.31 Access-Restriction-Data The Access-Restriction-Data AVP is of type Unsigned32 and it shall contain a bit mask where each bit when set to 1 indicates a restriction. The meaning of the bits is the following: Table 7.3.31/1: Access-Restriction-Data Bit Description 0 UTRAN Not Allowed 1 GERAN Not Allowed 2 GAN Not Allowed 3 I-HSPA-Evolution Not Allowed 4 WB-E-UTRAN Not Allowed 5 HO-To-Non-3GPP-Access Not Allowed 6 NB-IoT Not Allowed 7 Enhanced Coverage Not Allowed 8 NR as Secondary RAT in E-UTRAN Not Allowed 9 Unlicensed Spectrum as Secondary RAT Not Allowed 10 NR in 5GS Not Allowed 11 LTE-M Not Allowed 12 WB-E-UTRAN Except LTE-M Not Allowed 13 WB-E-UTRAN(LEO) Not Allowed 14 WB-E-UTRAN(MEO) Not Allowed 15 WB-E-UTRAN(GEO) Not Allowed 16 WB-E-UTRAN(OTHERSAT) Not Allowed 17 NB-IoT(LEO) Not Allowed 18 NB-IoT(MEO) Not Allowed 19 NB-IoT(GEO) Not Allowed 20 NB-IoT(OTHERSAT) Not Allowed 21 LTE-M(LEO) Not Allowed 22 LTE-M(MEO) Not Allowed 23 LTE-M(GEO) Not Allowed 24 LTE-M(OTHERSAT) Not Allowed 25 NR (LEO) Not Allowed 26 NR (MEO) Not Allowed 27 NR (GEO) Not Allowed 28 NR (OTHERSAT) Not Allowed NOTEÊ1: Bits not defined in this table shall be cleared by the HSS and discarded by the receiving MME/SGSN. NOTEÊ2: Bits 11 and 12 are only used when bit 4 is not set. The restriction ""HO-To-Non-3GPP-Access Not Allowed"" shall take a higher precedence than the APN-level parameter ""WLAN-Offloadability"" (see clauseÊ7.3.181). 7.3.32 APN-OI-Replacement The APN-OI-Replacement AVP is of type UTF8String. This AVP shall indicate the domain name to replace the APN OI for the non-roaming case and the home routed roaming case when constructing the APN, and the APN-FQDN upon which to perform a DNS resolution. See 3GPPÊTSÊ23.003Ê[3] and 3GPPÊTSÊ29.303Ê[38]. The contents of the APN-OI-Replacement AVP shall be formatted as a character string composed of one or more labels separated by dots ("".""). 7.3.33 All-APN-Configurations-Included-Indicator The All-APN-Configurations-Included-Indicator AVP is of type Enumerated. The following values are defined: All_APN_CONFIGURATIONS_INCLUDED (0) MODIFIED_ADDED_APN_CONFIGURATIONS_INCLUDED (1) 7.3.34 APN-Configuration-Profile The APN-Configuration-Profile AVP is of type Grouped. It shall contain the information related to the user's subscribed APN configurations for EPS. The AVP format shall conform to: APN-Configuration-Profile ::= <AVP header: 1429 10415> { Context-Identifier } [ Additional-Context-Identifier ] [ Third-Context-Identifier ] { All-APN-Configurations-Included-Indicator } 1*{APN-Configuration} *[AVP] The Subscription-Data AVP associated with an IMSI contains one APN-Configuration-Profile AVP. Each APN-Configuration-Profile AVP contains one or more APN-Configuration AVPs. Each APN-Configuration AVP describes the configuration for a single APN. Therefore, the cardinality of the relationship between IMSI and APN is one-to-many. The Context-Identifier AVP shall identify the per subscriber's default APN configuration. If present, the Additional-Context-Identifier AVP shall identify another default APN configuration, only for those subscriptions containing more than one types of APNs i.e. among APNs with an IP-based PDN type, APNs with a Non-IP PDN type, and APNs with an Ethernet PDN type; in this case, each of those two default APN configurations shall have a different PDN type category (e.g. one default APN with an IP-based PDN type, and another default APN with a Non-IP PDN type). If present, the Third-Context-Identifier AVP shall identify another default APN configuration, only for those subscriptions containing more than two types of APNs i.e. among APNs with an IP-based PDN type, APNs with a Non-IP PDN type, and APNs with an Ethernet PDN type; in this case, each of those three default APN configurations shall have a different PDN type category (i.e. one default APN with an IP-based PDN type, and another default APN with a Non-IP PDN type and one default APN with an Ethernet PDN type). 7.3.35 APN-Configuration The APN-Configuration AVP is of type Grouped. It shall contain the information related to the user's subscribed APN configurations. The Context-Identifier in the APN-Configuration AVP shall identify that APN configuration, and it shall not have a value of zero. Furthermore, the Context-Identifier in the APN-Configuration AVP shall uniquely identify the EPS APN configuration per subscription. For a particular EPS user having multiple APN configurations, the Service-Selection AVP values shall be unique across APN-Configuration AVPs. The AVP format shall conform to: APN-Configuration ::= <AVP header: 1430 10415> { Context-Identifier } * 2Ê[ Served-Party-IP-Address ] { PDN-Type } { Service-Selection} [ EPS-Subscribed-QoS-Profile ] [ VPLMN-Dynamic-Address-Allowed ] [MIP6-Agent-Info ] [ Visited-Network-Identifier ] [ PDN-GW-Allocation-Type ] [ 3GPP-Charging-Characteristics ] [ AMBR ] *[ Specific-APN-Info ] [ APN-OI-Replacement ] [ SIPTO-Permission ] [ LIPA-Permission ] [ Restoration-Priority ] [ SIPTO-Local-Network-Permission ] [ WLAN-offloadability ] [ Non-IP-PDN-Type-Indicator ] [ Non-IP-Data-Delivery-Mechanism ] [ SCEF-ID ] [ SCEF-Realm ] [ Preferred-Data-Mode ] [ PDN-Connection-Continuity ] [ RDS-Indicator ] [ Interworking-5GS-Indicator ] [ Ethernet-PDN-Type-Indicator ] *[ AVP ] The AMBR included in this grouped AVP shall include the AMBR associated to this specific APN configuration (APN-AMBR). The Served-Party-IP-Address AVP may be present 0, 1 or 2 times. These AVPs shall be present if static IP address allocation is used for the UE, and they shall contain either of: - an IPv4 address, or - an IPv6 address/prefix, or - both, an IPv4 address and an IPv6 address/prefix. For the IPv6 prefix, the lower 64 bits of the address shall be set to zero. The PDN-GW-Allocation-Type AVP applies to the MIP6-Agent-Info AVP. Therefore, it shall not be present if MIP6-Agent-Info is not present. The APN-OI-Replacement included in this grouped AVP shall include the APN-OI-Replacement associated with this APN configuration. This APN-OI-Replacement has higher priority than UE level APN-OI-Replacement. The Visited-Network-Identifier AVP indicates the PLMN where the PGW was allocated, in case of dynamic PGW assignment. NOTE: If interworking with MAP is needed, the Context-Identifier will be in the range of 1 and 50. The Non-IP-Data-Delivery-Mechanism shall only be present when Non-IP-PDN-Type-Indicator is set to TRUE (1). The SCEF-ID AVP and the SCEF-Realm AVP shall only be present when Non-IP-PDN-Type-Indicator is set to TRUE (1), and Non-IP-Data-Delivery-Mechanism is set to SCEF-BASED-DATA-DELIVERY (1). The RDS-Indicator may be present when Non-IP-PDN-Type-Indicator is set to TRUE (1), and Non-IP-Data-Delivery-Mechanism is set to SCEF-BASED-DATA-DELIVERY (1). Absence of PDN-Connection-Continuity AVP indicates that the handling is left to local VPLMN policy. 7.3.36 Service-Selection The Service-Selection AVP is of type of UTF8String. This AVP shall contain either the APN Network Identifier (i.e. an APN without the Operator Identifier) per 3GPPÊTSÊ23.003Ê[3], clauses 9.1 & 9.1.1, or this AVP shall contain the wild card value per 3GPPÊTSÊ23.003Ê[3], clauseÊ9.2.1, and 3GPPÊTSÊ23.008Ê[30], clauseÊ2.13.6). The contents of the Service-Selection AVP shall be formatted as a character string composed of one or more labels separated by dots ("".""), or as the wild card APN, i.e., consisting of only one ASCII label, ""*"". This AVP is defined in IETFÊRFCÊ5778[20]. 7.3.37 EPS-Subscribed-QoS-Profile The EPS-Subscribed-QoS-Profile AVP is of type Grouped. It shall contain the bearer-level QoS parameters (QoS Class Identifier and Allocation Retention Priority) associated to the default bearer for an APN (see 3GPPÊTSÊ23.401Ê[2], clauseÊ4.7.3). AVP format EPS-Subscribed-QoS-Profile ::= <AVP header: 1431 10415> { QoS-Class-Identifier } { Allocation-Retention-Priority } *[AVP] NOTE: QoS-Class-Identifier is defined in 3GPPÊTSÊ29.212Ê[10] as an Enumerated AVP. The values allowed for this AVP over the S6a/S6d interface are only those associated to non-GBR bearers, as indicated in 3GPPÊTSÊ23.008Ê[30]; e.g., values QCI_1, QCI_2, QCI_3 and QCI_4, which are associated to GBR bearers, cannot be sent over S6a/S6d. 7.3.38 VPLMN-Dynamic-Address-Allowed The VPLMN-Dynamic-Address-Allowed AVP is of type Enumerated. It shall indicate whether for this APN, the UE is allowed to use the PDN GW in the domain of the HPLMN only, or additionally, the PDN GW in the domain of the VPLMN.. If this AVP is not present, this means that the UE is not allowed to use PDN GWs in the domain of the VPLMN. The following values are defined: NOTALLOWED (0) ALLOWED (1) 7.3.39 STN-SR The STN-SR AVP is of type OctetString and shall contain the Session Transfer Number for SRVCC. See 3GPPÊTSÊ23.003Ê[3] for the definition of STN-SR. This AVP contains an STN-SR, in international number format as described in ITU-T Rec E.164Ê[41], encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.40 Allocation-Retention-Priority The Allocation-Retention-Priorit AVP is of typeGrouped and is defined in 3GPPÊTSÊ29.212Ê[10]. It shall indicate the Priority of Allocation and Retention for the corresponding APN configuration. AVP format Allocation-Retention-Priority ::= <AVP header: 1034 10415> { Priority-Level } [ Pre-emption-Capability ] [ Pre-emption-Vulnerability ] If the Pre-emption-Capability AVP is not present in the Allocation-Retention-Priority AVP, the default value shall be PRE-EMPTION_CAPABILITY_DISABLED (1). If the Pre-emption-Vulnerability AVP is not present in the Allocation-Retention-Priority AVP, the default value shall be PRE-EMPTION_VULNERABILITY_ENABLED (0). 7.3.41 AMBR The AMBR AVP is of type Grouped. It shall contain the maximum requested bandwidth for Uplink and Downlink traffic. The Max-Requested-Bandwidth-(UL/DL) AVPs shall encode the bandwidth value in bits per second, having an upper limit of 4294967295 bits per second. The Extended-Max-Requested-BW-(UL/DL) AVPs shall encode the bandwidth value in kilobits (1000 bits) per second, having an upper limit of 4294967295 kilobits per second. When the maximum bandwidth value to be set for UL (or DL, respectively) traffic is lower than 4294967296 bits per second, the Max-Requested-Bandwidth-UL (or -DL, respectively) AVP shall be present, and set to the requested bandwidth value in bits per second, and the Extended-Max-Requested-BW-UL (or -DL, respectively) AVP shall be absent. When the maximum bandwidth value to be set for UL (or DL, respectively) traffic is higher than 4294967295 bits per second, the Max-Requested-Bandwidth-UL (or DL, respectively) AVP shall be present, and set to its upper limit 4294967295, and the Extended-Max-Requested-BW-UL (or -DL, respectively) shall be present, and set to the requested bandwidth value in kilobits (1000 bits) per second. NOTE: The value applicable for Max-Requested-Bandwidth-UL (or DL, respectively) is between 1 and 4294967295 bits per second, and the value applicable for Extended-Max-Requested-BW-UL (or -DL, respectively) is between 4294968 and 4294967295 kilobits per second. The AMBR AVP cannot indicate the requested bandwidth between 4294967296 and 4294967999 bits per second, and any larger value that cannot be represented in the granularity of kilobits per second. AVP format AMBR ::= <AVP header: 1435 10415> { Max-Requested-Bandwidth-UL } { Max-Requested-Bandwidth-DL } [ Extended-Max-Requested-BW-UL ] [ Extended-Max-Requested-BW-DL ] *[AVP] 7.3.42 MIP-Home-Agent-Address The MIP-Home-Agent-Address AVP is of type Address and is defined in IETFÊRFCÊ4004Ê[27]. This AVP shall contain either IPv4 or IPv6 address of the PDN-GW and this IP address shall be used as the PDN-GW IP address. 7.3.43 MIP-Home-Agent-Host The MIP-Home-Agent-Host is of type Grouped and is defined in IETFÊRFCÊ4004Ê[27]. This AVP shall contain a FQDN of the PDN-GW which shall be used to resolve the PDN-GW IP address using the Domain Name Service function. MIP-Home-Agent-Host grouped AVP is composed by Destination-Host and Destination-Realm AVPs. Destination-Host shall contain the hostname of the PDN-GW, formatted as described in 3GPPÊTSÊ29.303Ê[38], clauseÊ4.3.2. Destination-Realm shall be formatted as: epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org where MNC and MCC values indicate the PLMN where the PDN-GW is located. 7.3.44 PDN-GW-Allocation-Type The PDN-GW-Allocation-Type AVP is of type Enumerated. It shall indicate whether the PDN GW address included in MIP6-Agent-Info has been statically allocated (i.e. provisioned in the HSS by the operator), or dynamically selected by other nodes. The following values are defined: STATIC (0) DYNAMIC (1) 7.3.45 MIP6-Agent-Info The MIP6-Agent-InfoAVP is of type Grouped and is defined in IETFÊRFCÊ5447Ê[26]. This AVP shall contain the identity of the PDN-GW. This AVP is used to convey the identity of the PDN-GW between the MME/SGSN and the HSS regardless of the specific mobility protocol used (GTP or PMIPv6). The identity of PDN-GW is either an IP address transported in MIP-Home-Agent-Address or an FQDN transported in MIP-Home-Agent-Host. FQDN shall be used if known to the MME/SGSN/HSS. AVP format MIP6-Agent-Info ::= < AVP Header: 486 > *2[ MIP-Home-Agent-Address ] [ MIP-Home-Agent-Host ] [ MIP6-Home-Link-Prefix ] *[ AVP ] Within the MIP6-Agent-Info AVP, if static address allocation is used, there may be either: - an IPv4 address or an IPv6 address of the PGW contained in one MIP-Home-Agent-Address AVP; - both IPv4 address and IPv6 address of the PGW contained in two MIP-Home-Agent-Address AVPs. The AVP MIP6-Home-Link-Prefix is not used in S6a/S6d, but it is included here to reflect the complete IETF definition of the grouped AVP. 7.3.46 RAT-Frequency-Selection-Priority-ID The RAT-Frequency-Selection-Priority-ID AVP is of type Unsigned32 and shall contain the subscribed value of Subscriber Profile ID for RAT/Frequency Priority. For details, see 3GPPÊTSÊ23.401Ê[2] and 3GPPÊTSÊ23.060Ê[12] . The coding is defined in 3GPPÊTSÊ36.413Ê[19]. Values shall be in the range of 1 to 256. 7.3.47 IDA-Flags The IDA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meanings of the bits are defined in table 7.3.47/1: Table 7.3.47/1: IDA-Flags Bit Name Description 0 Network Node area restricted This bit, when set, shall indicate that the complete Network Node area (SGSN area) is restricted due to regional subscription. Note: Bits not defined in this table shall be cleared by the sending SGSN and discarded by the receiving HSS. 7.3.48 PUA-Flags The PUA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meanings of the bits are defined in table 7.3.48/1: Table 7.3.48/1: PUA-Flags bit name Description 0 Freeze M-TMSI This bit, when set, shall indicate to the MME that the M-TMSI needs to be frozen, i.e. shall not be immediately re-used. 1 Freeze P-TMSI This bit, when set, shall indicate to the SGSN that the P-TMSI needs to be frozen, i.e. shall not be immediately re-used. Note: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.49 NOR-Flags The NOR-Flags AVP is of type Unsigned32 and it contains a bit mask. The meaning of the bits is defined in table 7.3.49/1: Table 7.3.49/1: NOR-Flags bit name Description 0 Single-Registration-Indication This bit, when set, indicates that the HSS shall send Cancel Location to the SGSN. An SGSN shall not set this bit when sending NOR. 1 SGSN area restricted This bit, when set, shall indicate that the complete SGSN area is restricted due to regional subscription. 2 Ready for SM from SGSN This bit, when set, shall indicate that the UE is present or the UE has memory capacity available to receive one or more short messages via SGSN. 3 UE Reachable from MME This bit, when set, shall indicate that the UE has become reachable again from MME. 4 Reserved The use of this bit is deprecated. This bit shall be discarded by the receiving HSS. 5 UE Reachable from SGSN This bit, when set, shall indicate that the UE has become reachable again from SGSN. 6 Ready for SM from MME This bit, when set, shall indicate that the UE is present or the UE has memory capacity available to receive one or more short messages via MME. 7 Homogeneous Support of IMS Voice Over PS Sessions This bit, when set, shall indicate that the Homogeneous Support of IMS Voice Over PS Sessions is updated. 8 S6a/S6d-Indicator This bit, when set, shall indicate that the NOR message is sent on the S6a interface, i.e. the message is from the MME or the MME part on the combined MME/SGSN. This bit, when cleared, indicates that the NOR message is sent on the S6d interface, i.e. the message is from the SGSN or the SGSN part on the combined MME/SGSN. 9 Removal of MME Registration for SMS This bit, when set, shall indicate that the MME requests to remove its registration for SMS. NOTE 1: The S6a/S6d-Indicator flag shall be used together with Homogeneous Support of IMS Voice Over PS Sessions flag, i.e. if the Homogeneous Support of IMS Voice Over PS Sessions bit is set, the S6a/S6d-Indicator bit shall be set if the message is sent from the MME or the MME part on the combined MME/SGSN, and shall be cleared if the message is sent from the SGSN or the SGSN part on the combined MME/SGSN. This S6a/S6d-Indicator bit shall be discarded by the receiving HSS if the Homogeneous Support of IMS Voice Over PS Sessions bit is not set. NOTE 2: Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving HSS. 7.3.50 User-Id The User-Id AVP shall be of type UTF8String. It shall contain the leading digits of an IMSI (i.e. MCC, MNC, leading digits of MSIN, see 3GPPÊTSÊ23.003Ê[3], clauseÊ2.2) formatted as a character string. Within a HSS, a User-Id identifies a set of subscribers, each with identical leading IMSI digits. 7.3.51 Equipment-Status The Equipment-Status AVP is of type Enumerated, and shall contain the status of the mobile equipment. The following values are defined: PERMITTEDLISTED (0) PROHIBITEDLISTED (1) TRACKINGLISTED (2) 7.3.52 Regional-Subscription-Zone-Code The Regional-Subscription-Zone-Code AVP is of type OctetString. It shall contain a Zone Code (ZC) as defined in 3GPPÊTSÊ23.003Ê[3], clauseÊ4.4. Up to 10 Zone Codes per VPLMN can be defined as part of the users's subscription data. NOTE 1: Each zone code represents a collection of tracking area or routing areas (defined by the operator of the VPLMN) where the user is allowed, or disallowed, to roam. The determination of which areas are actually allowed, and which ones are not allowed, is done by the serving node (MME/SGSN) in an implementation-dependent manner. NOTE 2: The description of RSZI in 3GPPÊTSÊ23.003Ê[3] is applicable, in the context of this specification, not only to location areas, but also to routing and tracking areas. 7.3.53 RAND The RAND AVP is of type OctetString. This AVP shall contain the RAND. See 3GPPÊTSÊ33.401Ê[5]. 7.3.54 XRES The XRES AVP is of type OctetString. This AVP shall contain the XRES. See 3GPPÊTSÊ33.401Ê[5]. 7.3.55 AUTN The AUTN AVP is of type OctetString. This AVP shall contain the AUTN. See 3GPPÊTSÊ33.401Ê[5]. 7.3.56 KASME The KASME AVP is of type OctetString. This AVP shall contain the K_ASME. See 3GPPÊTSÊ33.401Ê[5]. 7.3.57 Confidentiality-Key AVP The Confidentiality-Key is of type OctetString, and shall contain the Confidentiality Key (CK). 7.3.58 Integrity-Key AVP The Integrity-Key is of type OctetString, and shall contain the Integrity Key (IK). 7.3.59 Kc AVP The Kc AVP is of type OctetString, and shall contain the Ciphering Key (Kc). 7.3.60 SRES The SRES AVP is of type OctetString. This AVP shall contain the SRES. See 3GPPÊTSÊ33.102Ê[18]. 7.3.61 Void 7.3.62 PDN-Type The PDN-Type AVP is of type Enumerated and indicates the address type of the PDN, when it is IP-based. NOTE: There are certain PDNs that can be accessed without using IP. These are identified by a specific PDN type indicator in their APN configuration settings (e.g. see clauses 7.3.204 and 7.3.232). The following values are defined: IPv4 (0) This value shall be used to indicate that the PDN can be accessed only in IPv4 mode. IPv6 (1) This value shall be used to indicate that the PDN can be accessed only in IPv6 mode. IPv4v6 (2) This value shall be used to indicate that the PDN can be accessed both in IPv4 mode, in IPv6 mode, and also from UEs supporting dualstack IPv4v6. IPv4_OR_IPv6 (3) This value shall be used to indicate that the PDN can be accessed either in IPv4 mode, or in IPv6 mode, but not from UEs supporting dualstack IPv4v6. It should be noted that this value will never be used as a requested PDN Type from the UE, since UEs will only use one of their supported PDN Types, i.e., IPv4 only, IPv6 only or IPv4v6 (dualstack). This value is only used as part of the APN subscription context, as an authorization mechanism between HSS and MME. 7.3.63 Trace-Data AVP The Trace-Data AVP is of type Grouped. This AVP shall contain the information related to trace function. AVP format Trace-Data ::= <AVP header: 1458 10415> {Trace-Reference} {Trace-Depth} {Trace-NE-Type-List} [Trace-Interface-List] {Trace-Event-List} [OMC-Id] {Trace-Collection-Entity} [MDT-Configuration] *[AVP] 7.3.64 Trace-Reference AVP The Trace-Reference AVP is of type OctetString. This AVP shall contain the concatenation of MCC, MNC and Trace ID, where the Trace ID is a 3 byte Octet String. See 3GPPÊTSÊ32.422Ê[23]. The content of this AVP shall be encoded as octet strings according to table 7.3.64/1. See 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.1.13, PLMN list, for the coding of MCC and MNC. If MNC is 2 digits long, bits 5 to 8 of octet 2 are coded as ""1111"". Table 7.3.64/1: Encoding format for Trace-Reference AVP 8 7 6 5 4 3 2 1 MCC digit 2 MCC digit 1 octet 1 MNC digit 3 MCC digit 3 octet 2 MNC digit 2 MNC digit 1 octet 3 Trace ID octet 4 octet 5 octet 6 7.3.65 Void 7.3.66 Void 7.3.67 Trace-Depth AVP The Trace-Depth AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Trace Depth. 7.3.68 Trace-NE-Type-List AVP The Trace-NE-Type-List AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ32.422Ê[23]. 7.3.69 Trace-Interface-List AVP The Trace-Interface-List AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ32.422Ê[23]. 7.3.70 Trace-Event-List AVP The Trace-Event-List AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ32.422Ê[23]. 7.3.71 OMC-Id AVP The OMC-Id AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. 7.3.72 GPRS-Subscription-Data The GPRS-Subscription-Data AVP is of type Grouped. It shall contain the information related to the user profile relevant for GPRS. AVP format: GPRS-Subscription-Data ::= <AVP header: 1467 10415> { Complete-Data-List-Included-Indicator } 1*50{PDP-Context} *[AVP] NOTE: The max number of PDP-Context AVP aligns with the value of maxNumOfPDP-Contexts as defined in 3GPPÊTSÊ29.002Ê[24]. 7.3.73 Complete-Data-List-Included-Indicator The Complete-Data-List-Included-Indicator AVP is of type Enumerated. The following values are defined: All_PDP_CONTEXTS_INCLUDED (0) MODIFIED_ADDED_PDP CONTEXTS_INCLUDED (1) 7.3.74 PDP-Context The PDP-Context AVP is of type Grouped. For a particular GPRS user having multiple PDP Context configurations, the Service-Selection AVP values may be the same for different PDP-Context AVPs. AVP format PDP-Context ::= <AVP header: 1469 10415> { Context-Identifier } { PDP-Type } [ PDP-Address ] { QoS-Subscribed } [ VPLMN-Dynamic-Address-Allowed ] { Service-Selection } [3GPP-Charging-Characteristics] [ Ext-PDP-Type ] [ Ext-PDP-Address ] [ AMBR ] [ APN-OI-Replacement ] [ SIPTO-Permission ] [ LIPA-Permission ] [ Restoration-Priority ] [ SIPTO-Local-Network-Permission ] [ Non-IP-Data-Delivery-Mechanism ] [ SCEF-ID ] *[AVP] The Ext-PDP-Address AVP may be present only if the PDP-Address AVP is present. If the Ext-PDP-Address AVP is present, then it shall not contain the same address type (IPv4 or IPv6) as the PDP-Address AVP. When PDP-Type takes the value Non-IP (HEX 02), the Ext-PDP-Type AVP shall be absent. The AMBR included in this grouped AVP shall include the AMBR associated to the APN included in the PDP-Context AVP (APN-AMBR). The APN-OI-Replacement included in this grouped AVP shall include the APN-OI-Replacement associated to the APN included in the PDP-Context. This APN-OI-Replacement has higher priority than UE level APN-OI-Replacement. The Non-IP-Data-Delivery-Mechanism shall only be present when PDP-Type takes the value Non-IP (HEX 02). The SCEF-ID shall only be present when Non-IP-Data-Delivery-Mechanism takes the value SCEF-BASED-DATA-DELIVERY (1). 7.3.75 PDP-Type The PDP-Type AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. The allowed values are one of IPv4 encoded as HEX (21) or IPv6 encoded as HEX (57) or Non-IP encoded as HEX (02). 7.3.75A Ext-PDP-Type The Ext-PDP-Type AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24] and 3GPPÊTSÊ29.060Ê[39] and shall contain the value of IPv4v6. 7.3.76 Void 7.3.77 QoS-Subscribed The QoS-Subscribed AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24] (octets of QoS-Subscribed, Ext-QoS-Subscribed, Ext2-QoS-Subscribed, Ext3-QoS-Subscribed and Ext4-QoS-Subscribed values are concatenated). 7.3.78 CSG-Subscription-Data The CSG-Subscription-Data AVP is of type Grouped. This AVP shall contain the CSG-Id, and may contain the associated Visited-PLMN-Id, an associated expiration date and the APNs which are allowed to be accessed via Local IP Access from the CSG. If the Visited-PLMN-Id is not present, the CSG-Subscription-Data corresponds to the registered PLMN (i.e. the visited PLMN) of the MME or the SGSN. AVP format CSG-Subscription-Data ::= <AVP header: 1436 10415> { CSG-Id } [ Expiration-Date ] *[ Service-Selection ] [ Visited-PLMN-Id ] *[AVP] 7.3.79 CSG-Id The CSG-Id AVP is of type Unsigned32. Values are coded according to 3GPPÊTSÊ23.003Ê[3]. Unused bits (least significant) shall be padded with zeros. 7.3.80 Expiration-Date The Expiration-Date AVP is of type Time (see IETFÊRFCÊ6733Ê[61]) and contains the point in time when subscription to the CSG-Id expires. 7.3.81 Roaming-Restricted-Due-To-Unsupported-Feature The Roaming-Restricted-Due-To-Unsupported-Feature AVP is of type Enumerated and indicates that roaming is restricted due to unsupported feature. The following value is defined: Roaming-Restricted-Due-To-Unsupported-Feature (0) 7.3.82 Specific-APN-Info AVP The Specific-APN-Info AVP is of type Grouped. It shall only be present in the APN configuration when the APN is a wild card APN. It shall contain the APN which is not present in the subscription context but the UE is authorized to connect to and the identity of the registered PDN-GW. The AVP format shall conform to: Specific-APN-Info ::= <AVP header: 1472 10415> { Service-Selection } { MIP6-Agent-Info } [ Visited-Network-Identifier ] *[ AVP ] 7.3.83 Alert-Reason AVP The Alert-Reason AVP is of type Enumerated. The following values are defined: UE_PRESENT (0) UE_MEMORY_AVAILABLE (1) 7.3.84 LCS-Info The LCS-Info AVP is of type Grouped. This AVP shall contain the following LCS related information for a subscriber: - list of GMLCs in the HPLMN that are permitted to issue a call/session unrelated or call/session related MT-LR location request for this UE; - privacy exception list that is applicable only over the S6d interface; - MO-LR list. AVP format LCS-Info ::= <AVP header: 1473 10415> *[ GMLC-Number] *[ LCS-PrivacyException ] *[ MO-LR ] *[AVP] 7.3.85 GMLC-Number The GMLC-Number AVP is of type OctetString. This AVP shall contain the ISDN number of the GMLC in international number format as described in ITU-T Rec E.164Ê[41] and shall be encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.86 LCS-PrivacyException The LCS-PrivacyException AVP is of type Grouped. This AVP shall contain the classes of LCS Client that are allowed to locate any target UE. AVP format LCS-PrivacyException ::= <AVP header: 1475 10415> { SS-Code } { SS-Status } [ Notification-To-UE-User ] *[ External-Client ] *[ PLMN-Client ] *[ Service-Type ] *[AVP] 7.3.87 SS-Code The SS-Code AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. 7.3.88 SS-Status The SS-Status AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. For details, see 3GPPÊTSÊ23.011Ê[29]. 7.3.89 Notification-To-UE-User The Notification- To-UE-User AVP is of type Enumerated. The following values are defined: NOTIFY_LOCATION_ALLOWED (0) NOTIFYANDVERIFY_LOCATION_ALLOWED_IF_NO_RESPONSE (1) NOTIFYANDVERIFY_LOCATION_NOT_ALLOWED_IF_NO_RESPONSE (2) LOCATION_NOT_ALLOWED (3) 7.3.90 External-Client The External-Client AVP is of type Grouped. This AVP shall contain the identities of the external clients that are allowed to locate a target UE for a MT-LR. AVP format External-Client ::= <AVP header: 1479 10415> { Client-Identity } [ GMLC-Restriction ] [ Notification-To-UE-User ] *[AVP] 7.3.91 Client-Identity The Client-Identity AVP is of type OctetString and it shall contain the ISDN number of the external client in international number format as described in ITU-T Rec E.164Ê[41] and shall be encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.92 GMLC-Restriction The GMLC-Restriction AVP is of type Enumerated. The following values are defined: GMLC_LIST (0) HOME_COUNTRY (1) 7.3.93 PLMN-Client The PLMN-Client AVP is of type Enumerated. The following values are defined: BROADCAST_SERVICE (0) O_AND_M_HPLMN (1) O_AND_M_VPLMN (2) ANONYMOUS_LOCATION (3) TARGET_UE_SUBSCRIBED_SERVICE (4) 7.3.94 Service-Type The Service-Type AVP is of type Grouped. This AVP shall contain the identities of the service type of the clients that are allowed to locate a target UE for an MT-LR. AVP format Service-Type ::= <AVP header: 1483 10415> { ServiceTypeIdentity } [ GMLC-Restriction ] [ Notification-To-UE-User ] *[AVP] 7.3.95 ServiceTypeIdentity The ServiceTypeIdentity AVP is of type Unsigned32. For details on the values of this AVP, see 3GPPÊTSÊ29.002Ê[24]. 7.3.96 MO-LR The MO-LR AVP is of type Grouped. This AVP shall contain the classes of MO-LR for which a subscription exists for a particular UE. AVP format MO-LR ::= <AVP header: 1485 10415> { SS-Code } { SS-Status } *[AVP] 7.3.97 Void 7.3.98 Trace-Collection-Entity AVP The Trace-Collection-Entity AVP is of type Address and contains the IPv4 or IPv6 address of the Trace Collection Entity, as defined in 3GPPÊTSÊ32.422Ê[23], clauseÊ5.9. 7.3.99 Teleservice-List The Teleservice-List AVP is of type Grouped. This AVP shall contain the service codes for the short message related teleservice for a subscriber: AVP format Teleservice-List ::= <AVP header: 1486 10415> 1 * { TS-Code }*Ê[ AVP ] 7.3.100 TS-Code The TS-Code AVP is of type OctetString. Octets are coded according to 3GPPÊTSÊ29.002Ê[24]. 7.3.101 Call-Barring-Info The Call-Barring-Info AVP is of type Grouped. This AVP shall contain the service codes for the short message related call barring services for a subscriber: AVP format Call-Barring-Info ::= <AVP header: 1488 10415> { SS-Code } { SS-Status } *[ AVP ] 7.3.102 SGSN-Number The SGSN-Number AVP is of type OctetString and it shall contain the ISDN number of the SGSN. For further details on the definition of this AVP, see 3GPPÊTSÊ23.003Ê[3]. This AVP contains an SGSN-Number in international number format as described in ITU-T Rec E.164Ê[41] and shall be encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings."
"This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.103 IDR-Flags The IDR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.103/1: Table 7.3.103/1: IDR-Flags bit name Description 0 UE Reachability Request This bit when set shall indicate to the MME or the SGSN that the HSS is awaiting a Notification of UE Reachability. 1 T-ADS Data Request This bit, when set, shall indicate to the MME or SGSN that the HSS requests the support status of ""IMS Voice over PS Sessions"", and the RAT Type and timestamp of the last radio contact with the UE. 2 EPS User State Request This bit, when set, shall indicate to the MME or the SGSN that the HSS requests the MME or the SGSN for the current user state. 3 EPS Location Information Request This bit, when set, shall indicate to the MME or the SGSN that the HSS requests the MME or SGSN for location information 4 Current Location Request This bit when set shall indicate to the MME or the SGSN that the HSS requests the MME or SGSN to provide the most current location information by paging the UE if the UE is in idle mode. This bit is used only in combination with the""EPS Location Information Request"" bit. 5 Local Time Zone Request This bit when set shall indicate to the MME or the SGSN that the HSS requests the MME or SGSN to provide information on the time zone of the location in the visited network where the UE is attached. 6 Remove SMS Registration This bit when set shall indicate to the MME that it shall consider itself unregistered for SMS. 7 RAT-Type Requested This bit when set shall indicate to the MME or the SGSN that the HSS requests the MME or SGSN to provide the RAT Type that corresponds to the requested EPS Location Information. This bit is used only in combination with the""EPS Location Information Request"" bit. 8 P-CSCF Restoration Request This bit, when set, shall indicate to the MME or SGSN that the HSS requests the execution of the HSS-based P-CSCF restoration procedures, as described in 3GPPÊTSÊ23.380Ê[51] clauseÊ5.4. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.104 ICS-Indicator The ICS-Indicator AVP is of type Enumerated. The meaning of the values is defined in 3GPPÊTSÊ23.292Ê[34] and 3GPPÊTSÊ23.216Ê[35]. The following values are defined: FALSE (0) TRUE (1) 7.3.105 Visited-Network-Identifier The Visited-Network-Identifier AVP contains the identity of the network where the PDN-GW was allocated, in the case of dynamic PDN-GW assignment. The AVP shall be encoded as: mnc<MNC>.mcc<MCC>.3gppnetwork.org 7.3.106 IMS-Voice-Over-PS-Sessions-Supported The IMS-Voice-Over-PS-Sessions-Supported AVP is of type Enumerated. The following values are defined: NOT_SUPPORTED (0) This value indicates that ""IMS Voice over PS Sessions"" is not supported by the UE's most recently used TA or RA in the serving node. SUPPORTED (1) This value indicates that ""IMS Voice over PS Sessions"" is supported by the UE's most recently used TA or RA in the serving node. 7.3.107 Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions The Homogeneous-Support-of-IMS-Voice-Over-PS-Sessions AVP is of type Enumerated. The following values are defined: NOT_SUPPORTED (0) This value indicates that ""IMS Voice over PS Sessions"" is not supported, homogeneously, in any of the TAs or RAs associated to the serving node for the served subscribers including consideration on roaming relationship for IMS Voice over PS. SUPPORTED (1) This value indicates that ""IMS Voice over PS Sessions"" is supported, homogeneously, in all of the TAs or RAs associated to the serving node for the served subscriber including consideration on roaming relationship for IMS Voice over PS. If this AVP is not present in the command, it indicates that there is no homogeneous support of IMS Voice Over PS Sessions on all the TA/RAs of the serving node, or that the homogeneity of this support is unknown to the serving node. NOTE: In order to ensure the T-ADS by HPLMN, MME or SGSN is expected to either set ""Homogenous Support of IMS Voice over PS Sessions"" AVP to ""NOT_SUPPORTED (0)"", or not to set this AVP for inbound roaming subscribers if there is no IMS Voice over PS roaming relationship with the HPLMN. 7.3.108 Last-UE-Activity-Time The Last-UE-Activity-Time AVP is of type Time (see IETFÊRFCÊ6733Ê[61]), and contains the point of time of the last radio contact of the serving node (MME or SGSN) with the UE. 7.3.109 GMLC-Address The GMLC-Address AVP is of type Address and shall contain the IPv4 or IPv6 address of the V-GMLC associated with the serving node. 7.3.110 EPS-User-State The EPS-User-State AVP is of type Grouped. It shall contain the information related to the user state in the MME and/or the SGSN. AVP format EPS-User-State ::= <AVP header:1495 10415> [MME-User-State] [SGSN-User-State] *[AVP] 7.3.111 EPS-Location-Information The EPS-Location Information AVP is of type Grouped. It shall contain the information related to the user location relevant for EPS. AVP format EPS-Location-Information ::= <AVP header: 1496 10415> [MME-Location-Information] [SGSN-Location-Information] *[AVP] 7.3.112 MME-User-State The MME-User-State AVP is of type Grouped. It shall contain the information related to the user state in the MME. AVP format MME-User-State ::= <AVP header: 1497 10415> [User-State] *[AVP] 7.3.113 SGSN-User-State The SGSN-User-State AVP is of type Grouped. It shall contain the information related to the user state in the SGSN. AVP format SGSN-User-State ::= <AVP header: 1498 10415> [User-State] *[AVP] 7.3.114 User-State The User-State AVP is of type Enumerated and indicates the user state in EPS. The following values are defined: DETACHED (0) The UE is in EMM_DEREGISTERED state. ATTACHED_NOT_REACHABLE_FOR_PAGING (1) The SGSN has determined from its internal data that the UE is attached to the network, but there is no EPS bearer active, and the UE is not reachable for paging. This value is only applicable to S4-SGSN. ATTACHED_REACHABLE_FOR_PAGING (2) The SGSN has determined from its internal data that the UE is attached to the network, but there is no EPS bearer active; the SGSN has not determined from its internal data that the UE is not reachable for paging. This value is only applicable to S4-SGSN. CONNECTED_NOT_REACHABLE_FOR_PAGING (3) The SGSN or MME has determined from its internal data that the UE is attached to the network, there is at least one EPS bearer active, and the UE is not reachable for paging. CONNECTED_REACHABLE_FOR_PAGING (4) The SGSN or MME has determined from its internal data that the UE is attached to the network, there is at least one EPS bearer active, and the SGSN or MME has not determined from its internal data that the UE is not reachable for paging. RESERVED (5) This value should not be used by MME or SGSN over S6a/S6d. If this value is received by the HSS from pre-rel-12 MME/SGSNs, the HSS shall consider that the UE is not reachable and use the ""Network determined not reachable"" state when reporting the User State to other network entities, e.g. over Sh. NOTE: The state associated to a ""Network determined not reachable"" condition should also be used by HSS when reporting to the requesting entity, e.g. over Sh, that the user was found to be not reachable (for instance, if the HSS receives no answer from the MME/SGSN to the user state query). 7.3.115 MME-Location-Information The MME-Location-Information AVP is of type Grouped. It shall contain the information related to the user location relevant for the MME. AVP format MME-Location-Information ::= <AVP header: 1600 10415> [E-UTRAN-Cell-Global-Identity] [Tracking-Area-Identity] [Geographical-Information] [Geodetic-Information] [Current-Location-Retrieved] [Age-Of-Location-Information] [User-CSG-Information] [ eNodeB-ID ] [ Extended-eNodeB-ID ] *[AVP] An eNodeB-ID AVP may be present for Monitoring event reporting. 7.3.116 SGSN-Location-Information The SGSN-Location-Information AVP is of type Grouped. It shall contain the information related to the user location relevant for the SGSN. AVP format SGSN-Location-Information ::= <AVP header: 1601 10415> [Cell-Global-Identity] [Location-Area-Identity] [Service-Area-Identity] [Routing-Area-Identity] [Geographical-Information] [Geodetic-Information] [Current-Location-Retrieved] [Age-Of-Location-Information] [ User-CSG-Information] *[AVP] 7.3.117 E-UTRAN-Cell-Global-Identity The E-UTRAN-Cell-Global-Identity AVP is of type OctetString and shall contain the E-UTRAN Cell Global Identification of the user which identifies the cell the user equipment is registered, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.118 Tracking-Area-Identity The Tracking-Area-Identity AVP is of type OctetString and shall contain the Tracking Area Identity of the user which identifies the tracking area where the user is located, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.119 Cell-Global-Identity The Cell-Global-Identity AVP is of type OctetString and shall contain the Cell Global Identification of the user which identifies the cell the user equipment is registered, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.120 Routing-Area-Identity The Routing-Area-Identity AVP is of type OctetString and shall contain the Routing Area Identity of the user which identifies the routing area where the user is located, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.121 Location-Area-Identity The Location-Area-Identity AVP is of type OctetString and shall contain the Location Area Identification of the user which identifies the Location area where the user is located, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.122 Service-Area-Identity The Service-Area-Identity AVP is of type OctetString and shall contain the Service Area Identifier of the user where the user is located, as specified in 3GPPÊTSÊ23.003Ê[3]. Octets are coded as described in 3GPPÊTSÊ29.002Ê[24]. 7.3.123 Geographical-Information The Geographical-Information AVP is of type OctetString and shall contain the geographical Information of the user. For details and octet encoding, see 3GPPÊTSÊ29.002Ê[24]. 7.3.124 Geodetic-Information The Geodetic-Information AVP is of type OctetString and shall contain the Geodetic Location of the user. For details and octet encoding, see 3GPPÊTSÊ29.002Ê[24]. 7.3.125 Current-Location-Retrieved The Current-Location-Retrieved AVP is of type Enumerated. The following values are defined: ACTIVE-LOCATION-RETRIEVAL (0) This value is used when location information was obtained after a successful paging procedure for Active Location Retrieval when the UE is in idle mode or after retrieving the most up-to-date location information from the eNB when the UE is in connected mode. 7.3.126 Age-Of-Location-Information The Age-Of-Location-Information AVP is of type Unsigned32 and shall contain the the elapsed time in minutes since the last network contact of the user equipment. For details, see 3GPPÊTSÊ29.002Ê[24]. 7.3.127 Active-APN The Active-APNs AVP is of type Grouped. It shall contain information about a dynamically established APN on a serving node, so the HSS can restore it, if it is eventually lost after a node restart. The AVP format shall conform to: Active-APN ::= <AVP header: 1612 10415> { Context-Identifier } [ Service-Selection ] [ MIP6-Agent-Info ] [ Visited-Network-Identifier ] *[ Specific-APN-Info ] *[ AVP ] 7.3.128 Error-Diagnostic The Error-Diagnostic AVP is of type Enumerated. The following values are defined: - GPRS_DATA_SUBSCRIBED (0) This value shall be used when Experimental-Error is DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION and there is GPRS Subscription Data for the user. - NO_GPRS_DATA_SUBSCRIBED (1) This value shall be used when Experimental-Error is DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION and there is not GPRS Subscription Data for the user. - ODB_ALL_APN (2) This value shall be used when Experimental-Error is DIAMETER_ERROR_ROAMING_NOT_ALLOWED and the Operator Determined Barring indicates ""All Packet Oriented Services Barred"" (see clauseÊ7.3.30). - ODB_HPLMN_APN (3) This value shall be used when Experimental-Error is DIAMETER_ERROR_ROAMING_NOT_ALLOWED and the Operator Determined Barring indicates ""Roamer Access HPLMN-AP Barred"" (see clauseÊ7.3.30). - ODB_VPLMN_APN (4) This value shall be used when Experimental-Error is DIAMETER_ERROR_ROAMING_NOT_ALLOWED and the Operator Determined Barring indicates ""Roamer Access to VPLMN-AP Barred"" (see clauseÊ7.3.30). 7.3.129 Ext-PDP-Address AVP The Ext-PDP-Address AVP is of type Address and indicates an additional address of the data protocol, and it may be included when the PDP supports dual-stack (IPv4v6). 7.3.130 UE-SRVCC-Capability The UE-SRVCC-Capability AVP is of type Enumerated. It shall indicate if the UE supports or does not support the SRVCC capability. The following values are defined: UE-SRVCC-NOT-SUPPORTED (0) UE-SRVCC-SUPPORTED (1) 7.3.131 MPS-Priority The MPS-Priority AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.131/1: Table 7.3.131/1: MPS-Priority Bit Name Description 0 MPS-CS-Priority This bit, when set, indicates that the UE is subscribed to the eMLPP or 1x RTT priority service in the CS domain. 1 MPS-EPS-Priority This bit, when set, indicates that the UE is subscribed to the MPS in the EPS domain. Note: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. NOTE: The HSS derives the information for MPS-CS-Priority from the eMLPP Subscription Data as defined in the 3GPPÊTSÊ29.002Ê[24] or 1x RTT priority service which is out of the scope of 3GPP. 7.3.132 VPLMN-LIPA-Allowed The VPLMN-LIPA-Allowed AVP is of type Enumerated. It shall indicate whether the UE is allowed to use LIPA in the VPLMN where the UE is roaming. The following values are defined: LIPA_NOTALLOWED (0) This value indicates that the UE is not allowed to use LIPA in the VPLMN where the UE is roaming. LIPA_ALLOWED (1) This value indicates that the UE is allowed to use LIPA in the VPLMN where the UE is roaming. 7.3.133 LIPA-Permission The LIPA-Permission AVP is of type Enumerated. It shall indicate whether the APN can be accessed via Local IP Access. The following values are defined: LIPA_PROHIBITED (0) This value indicates that this APN is prohibited to be accessed via LIPA. LIPA_ONLY (1) This value indicates that this APN can be accessed only via LIPA. LIPA_CONDITIONAL (2) This value indicates that this APN can be accessed via both non LIPA and LIPA. 7.3.134 Subscribed-Periodic-RAU-TAU-Timer The Subscribed-Periodic-RAU-TAU-Timer AVP is of type Unsigned32 and it shall contain the subscribed periodic RAU/TAU timer value in seconds as specified in 3GPPÊTSÊ24.008Ê[31]. 7.3.135 SIPTO-Permission The SIPTO-Permission AVP is of type Enumerated. It shall indicate whether the traffic associated with this particular APN is allowed or not for SIPTO above RAN. The following values are defined: SIPTO_above_RAN _ALLOWED (0) SIPTO_above_RAN _NOTALLOWED (1) 7.3.136 MDT-Configuration The MDT-Configuration AVP is of type Grouped. It shall contain MDT related information as specified in 3GPPÊTSÊ32.422Ê[23]. The AVP format shall conform to: MDT-Configuration ::= <AVP header: 1622 10415> { Job-Type } [ Area-Scope ] [ List-Of-Measurements ] [ Reporting-Trigger ] [ Report-Interval ] [ Report-Amount ] [ Event-Threshold-RSRP ] [ Event-Threshold-RSRQ ] [ Logging-Interval ] [ Logging-Duration ] [ Measurement-Period-LTE ] [ Measurement-Period-UMTS ] [ Collection-Period- RRM-LTE ] [ Collection-Period-RRM-UMTS ] [ Positioning-Method ] [ Measurement-Quantity] [ Event-Threshold-Event-1F ] [ Event-Threshold-Event-1I ] *[ MDT-Allowed-PLMN-Id ] *[ MBSFN-Area ] *[ AVP ] 7.3.137 Job-Type The Job-Type AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Job-Type. 7.3.138 Area-Scope The Area-Scope AVP is of type Grouped. See 3GPPÊTSÊ32.422Ê[23]. The AVP format shall conform to: Area-Scope ::= <AVP header: 1623 10415> *[ Cell-Global-Identity ] *[ E-UTRAN-Cell-Global-Identity ] *[ Routing-Area-Identity ] *[ Location-Area-Identity ] *[ Tracking-Area-Identity ] *[ AVP ] 7.3.139 List-Of-Measurements The List-Of-Measurements AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits is defined in 3GPPÊTSÊ32.422Ê[23]. The most significant bit is bit 8 of the first octet. 7.3.140 Reporting-Trigger The Reporting-Trigger AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits is defined in 3GPPÊTSÊ32.422Ê[23]. The most significant bit is bit 8 of the first octet. 7.3.141 Report-Interval The Report-Interval AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Report Interval 7.3.142 Report-Amount The Report-Amount AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Report Amount. 7.3.143 Event-Threshold-RSRP The Event-Threshold-RSRP AVP is of type Unsigned32. See 3GPPÊTSÊ32.422Ê[23] for allowed values 7.3.144 Event-Threshold-RSRQ The Event-Threshold-RSRQ AVP is of type Unsigned32. See 3GPPÊTSÊ32.422Ê[23] for allowed values 7.3.145 Logging-Interval The Logging-Interval AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Logging Interval 7.3.146 Logging-Duration The Logging-Duration AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Logging Duration 7.3.147 Relay-Node-Indicator The Relay-Node-Indicator AVP is of type Enumerated. It shall indicate whether the subscription data belongs to a Relay Node or not (see 3GPPÊTSÊ36.300Ê[40]). The following values are defined: NOT_RELAY_NODE (0) This value indicates that the subscription data does not belong to a Relay Node. RELAY_NODE (1) This value indicates that the subscription data belongs to a Relay Node. The default value when this AVP is not present is NOT_RELAY_NODE (0). 7.3.148 MDT-User-Consent The MDT-User-Consent AVP is of type Enumerated. It shall indicate whether the user has given his consent for MDT activation or not (see 3GPPÊTSÊ32.422Ê[23]). The following values are defined: CONSENT_NOT_GIVEN (0) CONSENT_GIVEN (1) The default value when this AVP is not present in ULA is CONSENT_NOT_GIVEN (0). Absence of this AVP in IDR shall be interpreted as the MDT-User-Consent has not been modified. The presence of this subscription parameter in ULA or IDR shall be independent of the support of the Trace Function by the MME/SGSN (see clauseÊ7.3.10). 7.3.149 PUR-Flags The PUR-Flags AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.149/1: Table 7.3.149/1: PUR-Flags bit name Description 0 UE Purged in MME This bit, when set, indicates that the combined MME/SGSN has purged the UE in the MME part of the node. This bit shall not be set by a standalone SGSN. 1 UE Purged in SGSN This bit, when set, shall indicate that the combined MME/SGSN has purged the UE in the SGSN part of the node. This bit shall not be set by a standalone MME. NOTE: Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving HSS. 7.3.150 Subscribed-VSRVCC The Subscribed-VSRVCC AVP is of type Enumerated. It shall indicate that the user is subscribed to the vSRVCC. The following value is defined: VSRVCC_SUBSCRIBED (0) Absence of this AVP in IDR shall be interpreted as the Subscribed-VSRVCC has not been modified. Absence of this AVP in ULA shall be interpreted as the user is not subscribed to the vSRVCC. 7.3.151 Equivalent-PLMN-List The Equivalent-PLMN-List AVP is of type Grouped. This AVP shall contain the equivalent PLMN IDs of the registered PLMN (i.e. the visited PLMN) of the MME or the SGSN. AVP format Equivalent-PLMN-List ::= <AVP header: 1637 10415> 1*{ Visited-PLMN-Id } *[AVP] 7.3.152 CLR-Flags The CLR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.152/1: Table 7.3.152/1: CLR-Flags Bit Name Description 0 S6a/S6d-Indicator (Note 1) This bit, when set, indicates that the CLR message is sent on the S6a interface, i.e. the message is to the MME or the MME part on the combined MME/SGSN. This bit, when cleared, indicates that the CLR message is sent on the S6d interface, i.e. the message is to the SGSN or the SGSN part on the combined MME/SGSN. 1 Reattach-Required This bit, when set, indicates that the MME or SGSN shall request the UE to initiate an immediate re-attach procedure as described in 3GPPÊTSÊ23.401Ê[2] and in 3GPPÊTSÊ23.060Ê[12]. NOTE 1: The S6a/S6d-Indicator flag shall be used during initial attach procedure for a combined MME/SGSN. The S6a/S6d-Indicator flag may also be sent to a standalone node. NOTE 2: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. NOTE 3: For the purpose of withdrawing ""Aerial UE Subscription"", HSS may send CLR with CLR-Flag set to Reattach-Required. 7.3.153 UVR-Flags The UVR-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.154/1: Table 7.3.154/1: UVR-Flags Bit Name Description 0 Skip Subscriber Data This bit, when set, indicates that the CSS may skip subscription data in UVA. If the CSG subscription data has changed in the CSS after the last successful update of the MME/SGSN, the CSS shall ignore this bit and send the updated CSG subscription data. Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving CSS. 7.3.154 UVA-Flags The UVA-Flags AVP is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.156/1: Table 7.3.156/1: UVA-Flags Bit Name Description 0 Temporary Empty VPLMN CSG Subscription Data This bit, when set, indicates that the CSS has currently no VPLMN CSG subscription data for this user but has registered the MME or SGSN, so to inform them if later changes in VPLMN CSG subscription data occur. Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving CSS. 7.3.155 VPLMN-CSG-Subscription-Data The VPLMN-CSG-Subscription-Data AVP is of type Grouped. This AVP shall contain the CSG-Id, and optionally an associated expiration date. AVP format VPLMN-CSG-Subscription-Data ::= <AVP header: 1641 10415> { CSG-Id } [ Expiration-Date ] *[AVP] 7.3.156 Local-Time-Zone The Local-Time-Zone AVP is of type Grouped and shall contain the Time Zone and the Daylight Saving Time (DST) adjustment of the location in the visited network where the UE is attached. The AVP format shall conform to: Local-Time-Zone ::= <AVP header: 1649 10415> { Time-Zone } { Daylight-Saving-Time } *Ê[ AVP ] 7.3.157 A-MSISDN The A-MSISDN AVP is of type OctetString. See 3GPPÊTSÊ23.003Ê[3] for the definition of the Additional MSISDN. This AVP contains an A-MSISDN, in international number format as described in ITU-T Rec E.164Ê[41], encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. This AVP may be present in the Subscription-Data AVP when sent within ULA. It may also be present in the Subscription-Data AVP, sent within an IDR, if the current value in the MME or SGSN needs to be changed. 7.3.158 Void 7.3.159 MME-Number-for-MT-SMS The MME-Number-for-MT-SMS AVP is of type OctetString and it shall contain the ISDN number corresponding to the MME for MT SMS. For further details on the definition of this AVP, see 3GPPÊTSÊ23.003Ê[3]. This AVP contains an international number with the format as described in ITU-T Rec E.164Ê[41] and shall be encoded as a TBCD-string. See 3GPPÊTSÊ29.002Ê[24] for encoding of TBCD-strings. This AVP shall not include leading indicators for the nature of address and the numbering plan; it shall contain only the TBCD-encoded digits of the address. 7.3.160 Void 7.3.161 Void 7.3.162 SMS-Register-Request The SMS-Register-Request AVP is of type Enumerated and it shall indicate whether the MME or the SGSN requires to be registered for SMS (e.g. SGs interface not supported) or if the MME or the SGSN prefers not to be registered for SMS or if the MME or the SGSN has no preference. The following values are defined: SMS_REGISTRATION_REQUIRED (0) SMS_REGISTRATION_NOT_PREFERRED (1) NO_PREFERENCE (2) The criteria for setting these values are defined in 3GPPÊTSÊ23.272Ê[44] and 3GPPÊTSÊ23.060Ê[12]. When the MME/SGSN includes the SMS-Register-Request AVP in ULR in order to modify its registration status for SMS, the MME/SGSN shall not set the ""Skip Subscriber Data"" flag within the ULR-Flags AVP. 7.3.163 Time-Zone The Time-Zone AVP is of type UTF8String and shall contain the time zone of the location in the visited network where the UE is attached. It contains the offset from UTC (Coordinated Universal Time) in units of 15 minutes, as defined in 3GPPÊTSÊ22.042Ê[42]. It shall be expressed as positive (i.e. with the leading plus signÊ[+]) if the local time is ahead of or equal to UTC of day and as negative (i.e. with the leading minus signÊ[-]) if it is behind UTC of day. The value contained in the Time-Zone AVP shall take into account daylight saving time, such that when the sending entity changes from regular (winter) time to daylight saving (summer) time, there is a change to the value in the Time-Zone AVP. The contents of the Time-Zone AVP shall be formatted as a character string with the following format: Basic format: ±n, with ""n"" being the number of units of 15 minutes from UTC. For example, if the offset is +2h=+8x15mn, the value of the Time-Zone AVP will be: ""+8"". 7.3.164 Daylight-Saving-Time The Daylight-Saving-Time AVP is of type Enumerated and shall contain the Daylight Saving Time (in steps of 1 hour) used to adjust for summertime the time zone of the location where the UE is attached in the visited network. The following values are defined: NO_ADJUSTMENT (0) PLUS_ONE_HOUR_ADJUSTMENT (1) PLUS_TWO_HOURS_ADJUSTMENT (2) 7.3.165 Subscription-Data-Flags The Subscription-Data-Flags is of type Unsigned32 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.165/1: Table 7.3.165/1: Subscription-Data-Flags Bit Name Description 0 PS-And-SMS-Only-Service-Provision-Indication This bit, when set, indicates that the subscription is for PS Only and permits CS service access only for SMS. 1 SMS-In-SGSN-Allowed-Indication This bit, when set, indicates that SMS in SGSN for the user is allowed. 2 User Plane Integrity Protection This bit, when set, indicates that the SGSN may decide to activate integrity protection of the user plane when GERAN is used (see 3GPPÊTSÊ43.020Ê[58]). The MME shall ignore it. 3 PDN-Connection-Restricted This bit, when set, indicates to the MME that it shall not establish any non-emergency PDN connection for this user if the MME and the UE supports Attach without PDN connection. The SGSN shall ignore it. 4 Acknowledgement-Of-Downlink-NAS-Data PDUs disabled This bit, when set, indicates to the MME that acknowledgement of downlink NAS data PDUs for Control Plane CIoT Optimization is disabled for this UE (even for APN configurations with RDS Indicator set to ENABLED (1)). When not set it indicated to the MME that acknowledgement of downlink NAS data PDUs for Control Plane CIoT Optimization is enabled (for APN configurations with RDS Indicator set to ENABLED (1)) for this UE, which is the default (see 3GPPÊTSÊ23.401Ê[2]). The SGSN shall ignore it. NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. 7.3.166 Measurement-Period-LTE The Measurement-Period-LTE AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Measurement period LTE. 7.3.167 Measurement-Period-UMTS The Measurement-Period-UMTS AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Measurement period UMTS. 7.3.168 Collection-Period-RRM-LTE The Collection-Period-RRM-LTE AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Collection period for RRM measurements LTE. 7.3.169 Collection-Period-RRM-UMTS The Collection-Period-RRM-UMTS AVP is of type Enumerated. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Collection period for RRM measurements UMTS. 7.3.170 Positioning-Method The Positioning-Method AVP is of type OctetString. It contains one octet carrying a bit map of 8 bits. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Positioning Method. 7.3.171 Measurement-Quantity The Measurement-Quantity AVP is of type OctetString. It contains one octet carrying a bit map of 8 bits. The possible values are those defined in 3GPPÊTSÊ32.422Ê[23] for Measurement quantity. 7.3.172 Event-Threshold-Event-1F The Event-Threshold-Event-1F AVP is of type Integer32. See 3GPPÊTSÊ32.422Ê[23] for allowed values. 7.3.173 Event-Threshold-Event-1I The Event-Threshold-Event-1I AVP is of type Integer32. See 3GPPÊTSÊ32.422Ê[23] for allowed values 7.3.174 Restoration-Priority The Restoration-Priority AVP is of type Unsigned32. It shall indicate the relative priority of a user's PDN connection among PDN connections to the same APN when restoring PDN connections affected by an SGW or PGW failure/restart (see 3GPPÊTSÊ23.007Ê[43]). Values 1 to 16 are defined, with value 1 as the highest level of priority. 7.3.175 SGs-MME-Identity The SGs-MME-Identity AVP is of type UTF8String. This AVP shall contain the MME identity used over the SGs interface and specified in 3GPPÊTSÊ23.003Ê[3] clauseÊ19.4.2.4. 7.3.176 SIPTO-Local-Network-Permission The SIPTO-Local-Network-Permission AVP is of type Unsigned32. It shall indicate whether the traffic associated with this particular APN is allowed or not for SIPTO at the local network. The following values are defined: ""SIPTO at Local Network ALLOWED"" 0 ""SIPTO at Local Network NOTALLOWED"" 1 7.3.177 Coupled-Node-Diameter-ID The Coupled-Node-Diameter-ID AVP is of type DiameterIdentity. This AVP shall contain the S6a or S6d Diameter identity of the coupled node as specified in 3GPPÊTSÊ23.003Ê[3] clauseÊ19.4.2.4 and clauseÊ19.4.2.6. 7.3.178 OC-Supported-Features The OC-Supported-Features AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[50]. This AVP is used to support Diameter overload control mechanism, see Annex C for more information. 7.3.179 OC-OLR The OC-OLR AVP is of type Grouped and it is defined in IETFÊRFCÊ7683Ê[50]. This AVP is used to support Diameter overload control mechanism, see Annex C for more information. 7.3.180 ProSe-Subscription-Data The ProSe-Subscription-Data AVP is of type Grouped. It shall contain the ProSe related subscription data. It was originally defined in 3GPPÊTSÊ29.344Ê[49]. AVP format ProSe-Subscription-Data ::= <AVP header: 3701 10415> { ProSe-Permission } *[AVP] 7.3.181 WLAN-offloadability The WLAN-offloadability AVP is of type Grouped. This AVP contains WLAN offloadability for E-UTRAN or UTRAN. AVP format: WLAN-offloadability ::= <AVP header: 1667> [ WLAN-offloadability-EUTRAN ] [ WLAN-offloadability-UTRAN ] *[ AVP ] 7.3.182 WLAN-offloadability-EUTRAN The WLAN-offloadability-EUTRAN AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.182/1: Table 7.3.182/1: WLAN-offloadability-EUTRAN bit name Description 0 WLAN offloadability for E-UTRAN This bit, when set, shall indicate that the traffic associated with the APN is allowed to be offloaded to WLAN from E-UTRAN using the WLAN/3GPP Radio Interworking feature. If not set, it means the traffic associated with the APN is not allowed to be offloaded to WLAN from E-UTRAN. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.183 WLAN-offloadability-UTRAN The WLAN-offloadability-UTRAN AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.183/1: Table 7.3.183/1: WLAN-offloadability-UTRAN bit name Description 0 WLAN offloadability for UTRAN This bit, when set, shall indicate that the traffic associated with the APN is allowed to be offloaded to WLAN from UTRAN using the WLAN/3GPP Radio Interworking feature. If not set, it means the traffic associated with the APN is not allowed to be offloaded to WLAN from UTRAN. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN.. 7.3.184 Reset-ID The Reset-ID is of type OctetString. The value shall uniquely (within the HSS's realm) identify a resource in the HSS that may fail or has restarted. In the Reset procedure, when used to add/modify/delete subscription data shared by multiple subscribers, the Reset-ID is used to identify the set of affected subscribers. 7.3.185 MDT-Allowed-PLMN-Id The MDT-Allowed-PLMN-Id AVP is of type OctetString. This AVP shall contain the concatenation of MCC and MNC. See 3GPPÊTSÊ23.003Ê[3]. The content of this AVP shall be encoded as an octet string according to table 7.3.185/1. This AVP identifies the PLMN in which the MDT data collection shall take place. See 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.1.13, PLMN list, for the coding of MCC and MNC. If MNC is 2 digits long, bits 5 to 8 of octet 2 are coded as ""1111"". Table 7.3.185/1: Encoding format for MDT-Allowed-PLMN-Id AVP 8 7 6 5 4 3 2 1 MCC digit 2 MCC digit 1 octet 1 MNC digit 3 MCC digit 3 octet 2 MNC digit 2 MNC digit 1 octet 3 7.3.186 Adjacent-PLMNs The Adjacent-PLMNs AVP is of type Grouped. This AVP shall contain a list of PLMN IDs where an UE served by the MME/SGSN is likely to make a handover from the PLMN where the MME/SGSN is located. AVP format: Adjacent-PLMNs ::= <AVP header: 1672 10415> 1*{ Visited-PLMN-Id } *[AVP] 7.3.187 Adjacent-Access-Restriction-Data The Adjacent-Access-Restriction-Data AVP is of type Grouped. This AVP shall contain a pair of PLMN ID and the associated Access Restriction Data for that PLMN. AVP format: Adjacent-Access-Restriction-Data ::= <AVP header: 1673 10415> { Visited-PLMN-Id } { Access-Restriction-Data } *[AVP] 7.3.188 DL-Buffering-Suggested-Packet-Count The DL-Buffering-Suggested-Packet-Count AVP is of type Integer32. It shall indicate whether extended buffering of downlink packets at the SGW, for High Latency Communication, is requested or not. When requested, it may also suggest the number of downlink packets to buffer at the SGW for this user. The following values are defined: ""Extended DL Data Buffering NOT REQUESTED"" 0 ""Extended DL Data Buffering REQUESTED, without a suggested number of packets"" -1 ""Extended DL Data Buffering REQUESTED, with a suggested number of packets"" > 0 ""Extended DL Data Buffering REQUESTED"", with or without a suggested number of packets to be buffered for this user, indicates that extended buffering of downlink packets at the SGW is applicable to this user. ""Extended DL Data Buffering NOT REQUESTED"" indicates that extended buffering of downlink packets at the SGW is not applicable to this user. 7.3.189 IMSI-Group-Id The IMSI-Group-Id AVP shall be of type Grouped. This AVP shall contain the information about the IMSI-Group-Id. AVP format IMSI-Group-Id ::= <AVP header: 1675 10415> { Group-Service-Id } { Group-PLMN-Id } { Local-Group-Id } *[AVP] For details see 3GPPÊTSÊ23.003Ê[3], clauseÊ19.9). 7.3.190 Group-Service-Id The Group-Service-Id AVP is of type Unsigned32 and it shall identify the specific service for which the IMSI-Group-Id is used. The following values are defined: Table 7.3.190-1: Group-Service-Id Value Description 1 Group specific NAS level congestion control 2 Group specific Monitoring of Number of UEs present in a geographical area Values greater than 1000 are reserved for home operator specific use. IMSI-Group-IDs with a Group-Service-Id in this range shall not be sent outside the HPLMN unless roaming agreements allow so. 7.3.191 Group-PLMN-Id The Group-PLMN-Id AVP is of type OctetString. This AVP shall contain the concatenation of MCC and MNC. See 3GPPÊTSÊ23.003Ê[3]. The content of this AVP shall be encoded as an octet string according to table 7.3.191-1. See 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.1.13, PLMN list, for the coding of MCC and MNC. If MNC is 2 digits long, bits 5 to 8 of octet 2 are coded as ""1111"". Table 7.3.191-1: Encoding format for Group-PLMN-Id AVP 8 7 6 5 4 3 2 1 MCC digit 2 MCC digit 1 octet 1 MNC digit 3 MCC digit 3 octet 2 MNC digit 2 MNC digit 1 octet 3 7.3.192 Local-Group-Id The Local-Group-Id AVP is of type OctetString. It shall contain an operator defined value, representing a group. 7.3.193 AESE-Communication-Pattern AESE-Communication-Pattern AVP is of type Grouped and is defined in 3GPPÊTSÊ29.336Ê[54]. AVP format AESE-Communication-Pattern ::= <AVP header: 3113 10415> [ SCEF-Reference-ID ] [ SCEF-Reference-ID-Ext ] { SCEF-ID } *[ SCEF-Reference-ID-for-Deletion ] *[ SCEF-Reference-ID-for-Deletion-Ext ] *[ Communication-Pattern-Set ] [ MTC-Provider-Info ] *[AVP] At least one reference ID (either in SCEF-Reference-ID or in SCEF-Reference-ID-Ext) or a reference ID for deletion (either in SCEF-Reference-ID-for-Deletion or in SCEF-Reference-ID-for-Deletion-Ext) shall be present. When the ""Extended Reference IDs"" feature is supported by the HSS and MME/SGSN, the SCEF-Reference-ID-Ext and SCEF-Reference-ID-for-Deletion-Ext AVPs shall be used insted of SCEF-Reference-ID and SCEF-Reference-ID-for-Deletion respectively. 7.3.194 Communication-Pattern-Set Communication-Pattern-Set AVP is of type Grouped and is defined in 3GPPÊTSÊ29.336Ê[54]. AVP format Communication-Pattern-Set ::= <AVP header: 3114 10415> [ Periodic-Communication-Indicator ] [ Communication-Duration-Time ] [ Periodic-Time ] *[ Scheduled-Communication-Time ] [ Stationary-Indication ] [ Reference-ID-Validity-Time ] [ Traffic-Profile ] [ Battery-Indicator ] *[AVP] If the Reference-ID-Validity-Time AVP is absent, it indicates that there is no expiration time defined for the Communication-Pattern-Set. 7.3.195 Monitoring-Event-Configuration The Monitoring-Event-Configuration AVP is of type Grouped. It shall contain the Monitoring event configuration related subscription data. It is originally defined in 3GPPÊTSÊ29.336Ê[54]. For S6a/S6d interface, the Monitoring-Event-Configuration AVP format is specified as following: AVP format: Monitoring-Event-Configuration ::= <AVP header: 3122 10415> [ SCEF-Reference-ID ] [ SCEF-Reference-ID-Ext ] { SCEF-ID } { Monitoring-Type } *[ SCEF-Reference-ID-for-Deletion ] *[ SCEF-Reference-ID-for-Deletion-Ext ] [ Maximum-Number-of-Reports ] [ Monitoring-Duration ] [ Charged-Party ] [ UE-Reachability-Configuration ] [ Location-Information-Configuration ] [ SCEF-Realm ] [ External-Identifier ] [ MTC-Provider-Info ] [ PDN-Connectivity-Status-Configuration ] *[ AVP ] When the Monitoring-Event-Configuration AVP is used over the S6a/S6d interfaces, the SCEF-Realm AVP shall be present and its value shall be obtained by the HSS from the Origin-Realm AVP of the Configuration-Information-Request command conveying the corresponding monitoring event configuration over the S6t interface from the SCEF to the HSS. The Monitoring-Type AVP shall only be taken into account in combination with SCEF-Reference-ID/SCEF-Reference-ID-Ext AVP; Monitoring-Type AVP shall be ignored for deletion of an event (i.e. when SCEF-Reference-ID-for-Deletion/SCEF-Reference-ID-for-Deletion-Ext AVP is present). Maximum-Number-of-Reports shall not be present over S6a/S6d interfaces if Monitoring-Type is AVAILABILITY_AFTER_DDN_FAILURE (6). Maximum-Number-of-Reports shall not be greater than one over S6a/S6d interfaces if Monitoring-Type is LOCATION_REPORTING (2) and MONTE-Location-Type is LAST_KNOWN_LOCATION (1). When multiple External Identifiers are defined for the same subscription, the External-Identifier in this grouped AVP, if present, shall contain the specific External Identifier to be associated with this monitoring event; if it is not present, the External Identifier associated with this monitoring event shall be the default External Identifier defined in the subscription (see clauseÊ7.3.2). When the ""Extended Reference IDs"" feature is supported by the HSS and MME/SGSN, the SCEF-Reference-ID-Ext and SCEF-Reference-ID-for-Deletion-Ext AVPs shall be used insted of SCEF-Reference-ID and SCEF-Reference-ID-for-Deletion respectively. 7.3.196 Monitoring-Event-Report The Monitoring-Event-Report AVP is of type Grouped. It shall contain the Monitoring event report data. It is originally defined in 3GPPÊTSÊ29.336Ê[54]."
"For S6a/S6d interface, the Monitoring-Event-Report AVP format is specified as following: AVP format: Monitoring Event Report::= <AVP header: 3123 10415> { SCEF-Reference-ID } [ SCEF-Reference-ID-Ext ] [ SCEF-ID ] [ Reachability-Information ] [ Reachability-Cause ] [ EPS-Location-Information ] [ Monitoring-Type ] [ Loss-Of-Connectivity-Reason ] [ Idle-Status-Indication ] [ Maximum-UE-Availability-Time ] *[ PDN-Connectivity-Status-Report ] *[ AVP ] For S6a/S6d interface, when the Monitoring-Type AVP takes the value UE_REACHABILITY (1), the Reachability-Information AVP shall take the value REACHABLE_FOR_DATA (1), and the Reachability-Cause AVP may be present. For S6a/S6d interface, when the Monitoring-Type AVP takes the value PDN_CONNECTIVITY_STATUS (10), the PDN-Connectivity-Status-Report AVP(s) shall contain the list of active PDNs, for the given APN provided in the monitoring event configuration, or for all APNs if no APN was provided; each PDN-Connectivity-Status-Report shall have the PDN-Connectivity-Status-Type set to value ""CREATED (0)"". When the ""Extended Reference IDs"" feature is supported by the HSS and MME/SGSN, the SCEF-Reference-ID-Ext AVP shall be used insted of SCEF-Reference-ID; in such case, the required AVP ""SCEF-Reference-ID"" shall be included in the grouped AVP by the sender, but its content shall be discarded by the receiver. 7.3.197 UE-Reachability-Configuration The UE-Reachability-Configuration AVP is of type Grouped, and it shall contain the details for configuration for UE reachability. It is originally defined in 3GPPÊTSÊ29.336Ê[54]. For S6a/S6d interface, the UE-Reachability-Configuration AVP format is specified as following: AVP format: UE-Reachability-Configuration::= <AVP header: 3129 10415> [ Reachability-Type ] [ Maximum-Response-Time ] *[ AVP ] NOTE: When a Maximum-Response-Time value is not received from the SCEF, the HSS can send an O&M configured desired active time value within the Maximum-Response-Time AVP. For S6a/S6d interface, the Reachability-Type AVP shall have bit 0 (""Reachability for SMS"") cleared, and it shall have bit 1 (""Reachability for Data"") set. 7.3.198 eNodeB-ID The eNodeB-ID AVP is of type OctetString, and indicates the eNodeB in which the UE is currently located. It is originally defined in 3GPPÊTSÊ29.217Ê[56]. 7.3.199 Supported-Services The Supported-Services AVP is of type Grouped and it shall contain the different bit masks representing the services supported by the MME/SGSN: AVP format Supported-Services::= <AVP header: 3143 10415> [ Supported-Monitoring-Events ] *[AVP] 7.3.200 Supported-Monitoring-Events The Supported-Monitoring-Events AVP is of type Unsigned64 and it shall contain a bit mask. The meaning of the bits shall be as defined in table 7.3.200-1: Table 7.3.200 -1: Supported-Monitoring-Events Bit Name Description 0 UE and UICC and/or new IMSI-IMEI-SV association only used on S6t interface 1 UE-reachability This bit shall be set if UE reachability Monitoring event is supported in the MME/SGSN 2 Location-of-the-UE This bit shall be set if Location of the UE and change in location of the UE Monitoring event is supported in the MME/SGSN 3 Loss-of-connectivity This bit shall be set if Loss of connectivity Monitoring event is supported in the MME/SGSN 4 Communication-failure This bit shall be set if Communication failure Monitoring event is supported in the MME/SGSN 5 Roaming-status only used on S6t interface 6 Availability after DDN failure This bit shall be set if Availability after DDN failure Monitoring event is supported in the MME/SGSN 7 Idle Status Indication This bit shall be set if Idle Status Indication reporting is supported in the MME/SGSN 8 PDN Connectivity Status This bit shall be set if PDN Connectivity Status monitoring event is supported in the MME/SGSN NOTE: Bits not defined in this table shall be cleared by the sender and discarded by the receiver of the command. 7.3.201 AIR-Flags The AIR-Flags AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.201/1: Table 7.3.201/1: AIR-Flags bit name Description 0 Send UE Usage Type This bit, when set, indicates that the MME or SGSN requests the HSS to send the subscription parameter ""UE Usage Type"". NOTE: Bits not defined in this table shall be cleared by the sending MME or SGSN and discarded by the receiving HSS. 7.3.202 UE-Usage-Type The UE-Usage-Type AVP is of type Unsigned32. This value shall indicate the usage characteristics of the UE that enables the selection of a specific Dedicated Core Network (DCN). See clauseÊ4.3.25 of 3GPPÊTSÊ23.401Ê[2]. The allowed values of UE-Usage-Type shall be in the range of 0 to 255. Values in the range of 0 to 127 are standardized and defined as follows: 0: Spare, for future use É 127: Spare, for future use Values in the range of 128 to 255 are operator-specific. 7.3.203 DRMP The DRMP AVP is of type Enumerated and it is defined in IETFÊRFCÊ7944Ê[57]. This AVP allows the HSS, the CSS, the EIR and the MME/SGSN to indicate the relative priority of Diameter messages. The DRMP AVP may be used to set the DSCP marking for transport of the associated Diameter message. 7.3.204 Non-IP-PDN-Type-Indicator The Non-IP-PDN-Type-Indicator AVP is of type Enumerated and indicates whether the APN has a Non-IP PDN type. The following values are defined: FALSE (0) This value indicates that the APN does not have a Non-IP PDN type. TRUE (1) This value indicates that the APN has a Non-IP PDN type and, in this case, the value indicated by the PDN-Type AVP inside APN-Configuration AVP shall be ignored. The default value when this AVP is not present is FALSE (0). 7.3.205 Non-IP-Data-Delivery-Mechanism The Non-IP-Data-Delivery-Mechanism AVP is of type Unsigned32 and indicates the mechanism to be used for Non-IP data delivery for a given APN. The following values are defined: SGi-BASED-DATA-DELIVERY (0) This value indicates that the Non-IP data is delivered via Point-To-Point tunnelling over the SGi interface. SCEF-BASED-DATA-DELIVERY (1) This value indicates that the Non-IP data is delivered via the SCEF. The default value when this AVP is not present is SGi-BASED-DATA-DELIVERY (0). 7.3.206 Additional-Context-Identifier The Additional-Context-Identifier AVP is of type Unsigned32 and indicates the identity of another default APN to be used when the subscription profile of the user contains APNs with more than one PDN type among IP-based PDN types, non-IP PDN types and Ethernet PDN types. 7.3.207 SCEF-Realm The SCEF-Realm AVP is of type DiameterIdentity and it shall contain the Diameter realm of the SCEF. For further details on the encoding of this AVP, see IETFÊRFCÊ6733Ê[61]. 7.3.208 Subscription-Data-Deletion The Subscription-Data-Deletion AVP is of type Grouped and indicates the shared subscription data that need to be deleted from the subscription profiles of the impacted subscribers. AVP format Subscription-Data-Deletion ::= <AVP header: 1685 10415> { DSR-Flags } [ SCEF-ID ] *[ Context-Identifier ] [ Trace-Reference ] *[ TS-Code ] *[ SS-Code ] *[ AVP ] 7.3.209 Preferred-Data-Mode The Preferred-Data-Mode AVP is of type Unsigned32 and it shall contain a bitmask. The meaning of the bits is defined in table 7.3.209/1: Table 7.3.209/1: Preferred-Data-Mode bit name Description 0 Data over User Plane Preferred This bit, when set, shall indicate that the User Plane is preferred for transmitting the traffic associated with the APN. If not set, it means that the User Plane is not preferred for transmitting the traffic associated with the APN. 1 Data over Control Plane Preferred This bit, when set, shall indicate that the Control Plane is preferred for transmitting the traffic associated with the APN. If not set, it means that the Control Plane is not preferred for transmitting the traffic associated with the APN. NOTE 1: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME. NOTE 2: At least one of the bits 0 and 1 shall be set to 1. Both bits 0 and 1 may be set to 1 to indicate that both User Plane and Control Plane are preferred for transmitting the traffic associated with the APN. NOTE 3: This parameter only applies to E-UTRAN and SGi PDN connections. Data over User Plane refers to PDN data transported over S1-U and Data Radio Bearer. Data over Control Plane refers to PDN data transported over NAS and Signalling Radio Bearer. 7.3.210 Emergency-Info The Emergency-Info AVP is of type Grouped. It shall contain the identity of the PDN-GW used for the establishment of emergency PDN connections. The AVP format shall conform to: Emergency-Info ::= <AVP header: 1687 10415> [ MIP6-Agent-Info ] *[ AVP ] 7.3.211 Load The Load AVP is of type Grouped and it is defined in IETFÊRFCÊ8583Ê[60]. This AVP is used to support Diameter load control mechanism, see Annex F for more information. 7.3.212 V2X-Subscription-Data The V2X-Subscription-Data AVP is of type Grouped. It shall contain the V2X related subscription data for the network scheduled LTE sidelink communication.. AVP format: V2X-Subscription-Data ::= <AVP header: 1688 10415> [ V2X-Permission ] [ UE-PC5-AMBR ] *[AVP] The UE-PC5-AMBR AVP within the V2X-Subscription-Data AVP indicates the UE AMBR used for LTE PC5 interface. 7.3.213 V2X-Permission The V2X-Permission AVP is of type Unsigned32 and it shall contain a bit mask that indicates the permissions for V2X service subscribed by the user. The meaning of the bits shall be as defined in table 7.3.x2-1: Table 7.3.x2-1: V2X-Permission Bit Name Description 0 Allow V2X communication over PC5 as Vehicle UE This bit, when set, indicates that the user is allowed to use V2X communication over PC5 as Vehicle UE in the serving PLMN. 1 Allow V2X communication over PC5 as Pedestrian UE This bit, when set, indicates that the user is allowed to use V2X communication over PC5 as Pedestrian UE in the serving PLMN. NOTE: Bits not defined in this table shall be cleared by the HSS and discarded by the MME. 7.3.214 PDN-Connection-Continuity The PDN-Connection-Continuity AVP is of type Unsigned32 and indicates how to handle the PDN connection when the UE moves between ""broadband"" (WB-E-UTRAN, UTRAN) and ""narrowband"" (NB-IoT, GPRS, EC-GSM-IoT). The following values are defined: MAINTAIN-PDN-CONNECTION (0) DISCONNECT-PDN-CONNECTION-WITH-REACTIVATION-REQUEST (1) DISCONNECT-PDN-CONNECTION-WITHOUT-REACTIVATION-REQUEST (2) This AVP corresponds to the ""PDN continuity at inter RAT mobility"" field as defined in 3GPPÊTSÊ23.401Ê[2] table 5.7.1-1. 7.3.215 eDRX-Cycle-Length The eDRX-Cycle-Length AVP is of type Grouped. This AVP shall contain an eDRX cycle length, along with the RAT type for which this cycle length is applicable to (e.g. E-UTRAN and NB-IOT). AVP format: eDRX-Cycle-Length ::= <AVP header: 1691 10415> { RAT-Type } { eDRX-Cycle-Length-Value } *[ AVP ] 7.3.216 eDRX-Cycle-Length-Value The eDRX-Cycle-Length-Value AVP is of type OctetString. This AVP shall contain the extended DRX cycle value subscribed for this user for a given RAT type. The contents of eDRX-Cycle-Length-Value shall consist of 1 octet. The encoding shall be as defined in 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.5.32, and it shall only contain the value of the field ""eDRX value"" for a given RAT type, i.e., the 4 least significant bits of the octet in this AVP shall contain bits 1-4 of octet 3 in the ""Extended DRX parameter"" IE (see Figure 10.5.5.32 of 3GPPÊTSÊ24.008Ê[31]), and the 4 most significant bits of the octet in this AVP shall be set to 0. 7.3.217 UE-PC5-AMBR The UE-PC5-AMBR AVP is of type Unsigned32. It indicates the maximum bits delivered by UE over the PC5 interface within a period of time. The unit of UE-PC5-AMBR is bits/s. 7.3.218 Extended eNodeB-ID The Extended eNodeB-ID AVP is of type OctetString, and indicates the eNodeB in which the UE is currently located. It is originally defined in 3GPPÊTSÊ29.217Ê[56]. 7.3.219 MBSFN-Area The MBSFN-Area AVP is of type Grouped. It contains a MBSFN Area ID and a Carrier Frequency (see 3GPPÊTSÊ32.422Ê[23]). The AVP format shall conform to: MBSFN-Area ::= <AVP header: 1694 10415> [ MBSFN-Area-ID ] [ Carrier-Frequency ] *[ AVP ] If both MBSFN-Area-ID and Carrier-Frequency values are present, a specific MBSFN area is indicated. If Carrier-Frequency value is present, but MBSFN-Area-ID is absent, all MBSFN areas on that carrier frequency are indicated. If both MBSFN-Area-ID and Carrier-Frequency are absent, any MBSFN area is indicated. 7.3.220 MBSFN-Area-ID The MBSFN-Area-ID AVP is of type Unsigned32 and it shall contain the MBSFN Area ID value, in the range of 0..255 (see 3GPPÊTSÊ36.331Ê[62]). 7.3.221 Carrier-Frequency The Carrier-Frequency AVP is of type Unsigned32 and it shall contain the Carrier Frequency value, in the range of 0..262143 (see 3GPPÊTSÊ36.331Ê[62]). 7.3.222 RDS-Indicator The RDS-Indicator AVP is of type Enumerated and indicates whether the Reliable Data Service (RDS) is enabled or disabled for the APN. See 3GPPÊTSÊ23.682Ê[55]. The following values are defined: DISABLED (0) ENABLED (1) The default value when this AVP is not present is DISABLED (0). 7.3.223 Service-Gap-Time The Service-Gap-Time AVP is of type Unsigned32 and indicates the minimum number of seconds during which the UE shall stay in ECM-IDLE mode, after leaving the ECM-CONNECTED mode, before being allowed to send a subsequent connection request to enter ECM-CONNECTED mode again. See description of the Service Gap Control feature in 3GPPÊTSÊ23.401Ê[2]. 7.3.224 Aerial-UE-Subscription-Information The Aerial-UE-Subscription-Information AVP is of type Unsigned32 and indicates the subscription of Aerial UE function. The following values are defined: AERIAL_UE_ALLOWED (0) AERIAL_UE_NOT_ALLOWED (1) This AVP corresponds to the ""Aerial UE subscription information"" information element as defined in 3GPPÊTSÊ36.413[19] and TSÊ36.423Ê[65]. 7.3.225 Broadcast-Location-Assistance-Data-Types The Broadcast-Location-Assistance-Data-Types AVP is of type Unsigned64. The content of this AVP is a bit mask which indicates the broadcast location assistance data types for which the UE is subscribed to receive ciphering keys used to decipher broadcast assistance data. The meaning of the bits is defined in table 7.3.225-1: Table 7.3.225-1: Broadcast-Location-Assistance-Data-Types bit name Description 0 Positioning SIB Type 1-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-1. 1 Positioning SIB Type 1-2 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-2. 2 Positioning SIB Type 1-3 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-3. 3 Positioning SIB Type 1-4 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-4. 4 Positioning SIB Type 1-5 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-5. 5 Positioning SIB Type 1-6 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-6. 6 Positioning SIB Type 1-7 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-7. 7 Positioning SIB Type 2-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-1. 8 Positioning SIB Type 2-2 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-2. 9 Positioning SIB Type 2-3 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-3. 10 Positioning SIB Type 2-4 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-4. 11 Positioning SIB Type 2-5 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-5. 12 Positioning SIB Type 2-6 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-6. 13 Positioning SIB Type 2-7 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-7. 14 Positioning SIB Type 2-8 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-8. 15 Positioning SIB Type 2-9 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-9. 16 Positioning SIB Type 2-10 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-10. 17 Positioning SIB Type 2-11 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-11. 18 Positioning SIB Type 2-12 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-12. 19 Positioning SIB Type 2-13 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-13. 20 Positioning SIB Type 2-14 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-14. 21 Positioning SIB Type 2-15 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-15. 22 Positioning SIB Type 2-16 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-16. 23 Positioning SIB Type 2-17 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-17. 24 Positioning SIB Type 2-18 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-18. 25 Positioning SIB Type 2-19 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-19. 26 Positioning SIB Type 3-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 3-1. 27 Positioning SIB Type 1-8 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 1-8. 28 Positioning SIB Type 2-20 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-20. 29 Positioning SIB Type 2-21 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-21. 30 Positioning SIB Type 2-22 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-22. 31 Positioning SIB Type 2-23 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-23. 32 Positioning SIB Type 2-24 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-24. 33 Positioning SIB Type 2-25 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 2-25. 34 Positioning SIB Type 4-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 4-1. 35 Positioning SIB Type 5-1 This bit, when set, indicates that the UE is subscribed to receive ciphering keys applicable to positioning SIB Type 5-1. NOTE: Bits not defined in this table shall be cleared by the sending HSS and discarded by the receiving MME or SGSN. 7.3.226 Paging-Time-Window The Paging-Time-Window AVP is of type Grouped. This AVP shall contain the Paging Time Window length, along with the Operation Mode (see clauseÊ7.3.227) for which this time window length is applicable to. AVP format: Paging-Time-Window ::= <AVP header: 1701 10415> { Operation-Mode } { Paging-Time-Window-Length } *[ AVP ] 7.3.227 Operation-Mode The Operation-Mode AVP is of type Unsigned32. This value shall indicate the operation mode for which the Paging-Time-Window-Length applies. See clauseÊ3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.5.32. The allowed values of Operation-Mode shall be in the range of 0 to 255. Values are defined as follows: 0: Spare, for future use 1: Iu mode 2: WB-S1 mode 3: NB-S1 mode 4 to 255: Spare, for future use 7.3.228 Paging-Time-Window-Length The Paging-Time-Window-Length AVP is of type OctetString. This AVP shall contain the Paging time window length subscribed for this user for a given operation mode. The contents of Paging-Time-Window-Length shall consist of 1 octet. The encoding shall be as defined in 3GPPÊTSÊ24.008Ê[31], clauseÊ10.5.5.32, and it shall only contain the value of the field ""Paging Time Window length"" for a given RAT type, i.e., the 4 most significant bits of the octet in this AVP shall contain bits 5-8 of octet 3 in the ""Extended DRX parameter"" IE (see Figure 10.5.5.32 of 3GPPÊTSÊ24.008Ê[31]), and the 4 least significant bits of the octet in this AVP shall be set to 0. 7.3.229 eDRX-Related-RAT The eDRX-Related-RAT AVP is of type Grouped. This AVP shall contain the RAT type to which the eDRX Cycle Length is related: AVP format eDRX-Related-RAT ::= <AVP header: 1705 10415> 1 * { RAT-Type } *[AVP] 7.3.230 Core-Network-Restrictions The Core-Network-Restrictions AVP is of type Unsigned32 and shall contain a bitmask indicating the types of Core Network that are disallowed for a given user. The meaning of the bits shall be as defined in table 7.3.230-1: Table 7.3.230-1: Core-Network-Restrictions Bit Name Description 0 Reserved The use of this bit is deprecated. This bit shall be discarded by the receiving MME. 1 5GC not allowed Access to 5GC not allowed. NOTE: Bits not defined in this table shall be cleared by the HSS and discarded by the MME. 7.3.231 Interworking-5GS-Indicator The Interworking-5GS-Indicator AVP is of type Enumerated and indicates whether the interworking between 5GS and EPS is subscribed or not subscribed for the APN. See 3GPPÊTSÊ23.502Ê[67]. The following values are defined: NOT-SUBSCRIBED (0) SUBSCRIBED (1) The default value when this AVP is not present is NOT-SUBSCRIBED (0). 7.3.232 Ethernet-PDN-Type-Indicator The Ethernet-PDN-Type-Indicator AVP is of type Enumerated and indicates whether the APN has an Ethernet PDN type. The following values are defined: FALSE (0) This value indicates that the APN does not have an Ethernet PDN type. TRUE (1) This value indicates that the APN has an Ethernet PDN type and in this case the value indicated by the PDN-Type AVP inside APN-Configuration AVP shall be ignored. The default value when this AVP is not present is FALSE (0). 7.3.233 Subscribed-ARPI The Subscribed-ARPI AVP is of type Unsigned32 and shall contain the subscribed value of the Additional RRM Policy Index. For details, see 3GPPÊTSÊ23.401Ê[2]. 7.3.234 IAB-Operation-Permission The IAB-Operation-Permission AVP is of type Enumerated. It shall indicate to the MME or SGSN whether the UE is allowed for IAB operation. See 3GPPÊTSÊ23.401Ê[2]. The following values are defined: IAB_OPERATION_ALLOWED (0) IAB_OPERATION_NOTALLOWED (1) 7.3.235 V2X-Subscription-Data-Nr The V2X-Subscription-Data-Nr AVP is of type Grouped. It shall contain the V2X related subscription data for the network scheduled NR sidelink communication. AVP format: V2X-Subscription-Data-Nr ::= <AVP header: 1710 10415> [ V2X-Permission ] [ UE-PC5-AMBR ] [ UE-PC5-QoS ] *[AVP] The UE-PC5-AMBR AVP within the V2X-Subscription-Data AVP indicates the UE AMBR used for NR PC5 interface. 7.3.236 UE-PC5-QoS The UE-PC5-QoS AVP is of type Grouped. It shall contain the PC5 QoS parameters for V2X communication over NR PC5 reference point. AVP format: UE-PC5-QoS ::= <AVP header: 1711 10415> 1*{ PC5-QoS-Flow } [ PC5-Link-AMBR ] *[AVP] 7.3.237 PC5-QoS-Flow The PC5-QoS-Flow AVP is of type Grouped. It shall contain the QoS parameters for a PC5 flow. AVP format: PC5-QoS-Flow ::= <AVP header: 1712 10415> { 5QI } [ PC5-Flow-Bitrates ] [ PC5-Range ] *[AVP] 7.3.238 5QI The 5QI AVP is of type Integer32. It shall contain the 5QI. See 3GPPÊTSÊ23.501Ê[69] for allowed values.If the 5QI is used in PC5 QoS parameter, it shall contain PQI, PQI is a special 5QI (see clauseÊ5.4.2.1 of 3GPPÊTSÊ23.287Ê[68]). 7.3.239 PC5-Flow-Bitrates The PC5-Flow-Bitrates AVP is of type Grouped. It shall contain the PC5 Flow Bit Rates, it's for GBR QoS Flows only. AVP format: PC5-Flow-Bitrates ::= <AVP header: 1714 10415> [ Guaranteed-Flow-Bitrates ] [ Maximum-Flow-Bitrates ] 7.3.240 Guaranteed-Flow-Bitrates The Guaranteed-Flow-Bitrates AVP is of type Integer32. It indicates the guaranteed bits delivered for the PC5 QoS flow by UE over the PC5 interface within a period of time. The unit of Guaranteed-Flow-Bitrates is bits/s. 7.3.241 Maximum-Flow-Bitrates The Maximum-Flow-Bitrates AVP is of type Integer32. It indicates the maximum bits delivered for the PC5 QoS flow by UE over the PC5 interface within a period of time. The unit of Maximum-Flow-Bitrates is bits/s. 7.3.242 PC5-Range The PC5-Range AVP is of type Integer32. It indicates the Range in the unit of meters. See clauseÊ5.4.2.4 of 3GPPÊTSÊ23.287Ê[68]. 7.3.243 PC5-Link-AMBR The PC5-Link-AMBR AVP is of type Integer32. It indicates t the PC5 Link Aggregated Bit Rates for all the Non-GBR QoS Flows. The unit of PC5-Link-AMBR is bits/s. 7.3.244 Third-Context-Identifier The Third-Context-Identifier AVP is of type Unsigned32 and indicates the identity of another default APN to be used when the subscription profile of the user contains APNs with three PDN types, i.e. IP-based PDN types, non-IP PDN types and Ethernet PDN types. 7.4 Result-Code and Experimental-Result Values 7.4.1 General This clause defines result code values that shall be supported by all Diameter implementations that conform to this specification. 7.4.2 Success Result codes that fall within the Success category shall be used to inform a peer that a request has been successfully completed. The Result-Code AVP values defined in the Diameter base protocol IETFÊRFCÊ6733Ê[61] shall be applied. 7.4.3 Permanent Failures Errors that fall within the Permanent Failures category shall be used to inform the peer that the request has failed, and should not be attempted again. The Result-Code AVP values defined in the Diameter base protocol IETFÊRFCÊ6733Ê[61] shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and the Result-Code AVP shall be absent. 7.4.3.1 DIAMETER_ERROR_USER_UNKNOWN (5001) This result code shall be sent by the HSS to indicate that the user identified by the IMSI is unknown 7.4.3.2 DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) This result code shall be sent by the HSS to indicate that no EPS subscription is associated with the IMSI. 7.4.3.3 DIAMETER_ERROR_RAT_NOT_ALLOWED (5421) This result code shall be sent by the HSS to indicate the RAT type the UE is using is not allowed for the IMSI. 7.4.3.4 DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) This result code shall be sent by the HSS to indicate that the subscriber is not allowed to roam within the MME or SGSN area. 7.4.3.5 DIAMETER_ERROR_EQUIPMENT_UNKNOWN (5422) This result code shall be sent by the EIR to indicate that the mobile equipment is not known in the EIR. 7.4.3.6 DIAMETER_ERROR_UNKNOWN_SERVING_NODE (5423) This result code shall be sent by the HSS to indicate that a Notify command has been received from a serving node which is not registered in HSS as the node currently serving the user. 7.4.4 Transient Failures Result codes that fall within the transient failures category shall be used to inform a peer that the request could not be satisfied at the time it was received, but may be able to satisfy the request in the future. The Result-Code AVP values defined in the Diameter base protocol IETFÊRFCÊ6733Ê[61]shall be applied. When one of the result codes defined here is included in a response, it shall be inside an Experimental-Result AVP and the Result-Code AVP shall be absent. 7.4.4.1 DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181) This result code shall be sent by the HSS to indicate that an unexpectedly transient failure occurs. The requesting node can try the request again in the future. 7.4.4.2 DIAMETER_ERROR_CAMEL_SUBSCRIPTION_PRESENT (4182) This result code shall be sent by the HSS to indicate that the subscriber to be registered has SGSN CAMEL Subscription data. 8 User identity to HSS resolution The User identity to HSS resolution mechanism enables the MME, SGSN (for non-roaming case) or Diameter Relay/proxy agents in the home network (for roaming case) to find the identity of the HSS that holds the subscriber data for a given user identity when multiple and separately addressable HSSs have been deployed in the home network. The resolution mechanism is not required in networks that utilise a single HSS. This User identity to HSS resolution mechanism may rely on routing capabilitites provided by Diameter and be implemented in the home operator network within dedicated Diameter Agents (Redirect Agents or Proxy Agents) responsible for determining the HSS identity based on the provided user identity. If this Diameter based implementation is selected by the Home network operator, the principles described below shall apply. In non-roaming case, in networks where more than one independently addressable HSS are deployed in the home network, each MME and SGSN shall be configured with the address/identity of a Diameter Agent (Redirect Agent or Proxy Agent) implementing this resolution mechanism. For support of roaming case, Diameter Relay agents and/or Diameter Proxy agents in the home network receiving the Diameter signalling from visited networks shall be configured with the address/identity of a Diameter Agent (Redirect Agent or Proxy Agent) implementing this resolution mechanism. To get the HSS identity that holds the subscriber data for a given user identity in the home network, the Diameter request normally destined to the HSS shall be sent to a pre-configured address/identity of a Diameter agent supporting the User identity to HSS resolution mechanism. - If this Diameter request is received by a Diameter Redirect Agent, the Diameter Redirect Agent shall determine the HSS identity based on the provided user identity and shall return a notification of redirection towards the HSS identity, in response to the Diameter request. Multiple HSS identities may be included in the response, as specified in IETFÊRFCÊ6733Ê[61]. In such a case, the requesting Diameter entity shall send the Diameter request to the first HSS identity in the ordered list received in the Diameter response from the Diameter Redirect Agent. If no successful response to the Diameter request is received, the requesting Diameter entity shall send a Diameter request to the next HSS identity in the ordered list. This procedure shall be repeated until a successful response from an HSS is received. After the user identity to HSS resolution, the MME or the SGSN shall store the determined HSS identity/name/Realm and shall use it in further Diameter requests to the same user identity. - If this Diameter request is received by a Diameter Proxy Agent, the Diameter Proxy Agent shall determine the HSS identity based on the provided user identity and - if the Diameter load control mechanism is supported (see IETFÊRFCÊ8583Ê[60]) - optionally also based on previously received load values from Load AVPs of type HOST. The Diameter Proxy Agent shall then forward the Diameter request directly to the determined HSS. In this case, the user identity to HSS resolution decision is communicated to the MME/SGSN in the Origin-Host/Origin-Realm AVPs of the response. The MME or the SGSN may store the determined HSS identity/name/Realm and may use it in further Diameter requests to the same user identity. In roaming case, whereas a Diameter Relay Agent is stateless, a stateful Diameter Proxy Agent in the home network may store the determined HSS identity/name/Realm and use it in further Diameter requests associated to the same user identity. NOTE: Alternatives to the user identity to HSS resolution Diameter based implementation are outside the scope of this specification. Annex A (normative): MME mapping table for S6a and NAS Cause Code values When the UE initiates Attach, Tracking Area Update or Service Request, there may be the need for the MME to communicate with the HSS via S6a to retrieve authentication data and/or subscription data. If this retrieval is rejected by the HSS, the received Diameter-Result-Code values or Experimental-Result values need to be mapped to appropriate cause codes over NAS to the UE. This mapping shall be as shown in Table A.1. If the retrieval is successful, not needed (e.g. because data are already available) or not possible (e.g. because HSS is unavailable or overloaded), detected error conditions need to be mapped to appropriate cause codes over NAS to the UE. This mapping shall be as shown in Table A.2. Table A.1: Mapping from S6a error code to NAS Cause Code values Reject indication received at MME over S6a NAS Cause Code sent to UE DIAMETER_ERROR_USER_UNKNOWN (5001) #8 ""EPS services and non-EPS services not allowed"" DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) without Error Diagnostic, or with Error Diagnostic of GPRS_DATA_SUBSCRIBED #15 ""No suitable cells in tracking area"" DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) with Error Diagnostic of NO_GPRS_DATA_SUBSCRIBED #7 ""EPS services not allowed"" DIAMETER_ERROR_RAT_NOT_ALLOWED (5421) #15 ""No suitable cells in tracking area"", or #13 ""Roaming not allowed in this tracking area"", or #12 ""Tracking area not allowed"" (NOTE 1) DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) , without Error Diagnostic #11 ""PLMN not allowed"" DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), with Error Diagnostic of ODB_HPLMN_APN or ODB_VPLMN_APN #14 ""EPS services not allowed in this PLMN"" DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), with Error Diagnostic of ODB_ALL_APN #15 ""No suitable cells in tracking area"" DIAMETER_AUTHORIZATION_REJECTED (5003) DIAMETER_UNABLE_TO_DELIVER (3002) DIAMETER_REALM_NOT_SERVED (3003) #15 ""No suitable cells in tracking area"", or #17 ""Network failure"", or #42 ""Severe network failure"" (NOTE 1) DIAMETER_UNABLE_TO_COMPLY (5012), DIAMETER_INVALID_AVP_VALUE (5004) DIAMETER_AVP_UNSUPPORTED (5001) DIAMETER_MISSING_AVP (5005) DIAMETER_RESOURCES_EXCEEDED (5006) DIAMETER_AVP_OCCURS_TOO_MANY_TIMES (5009) DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181) (NOTE 2) #17 ""Network failure"" or #42 ""Severe network failure"" (NOTE 1) NOTE 1: Any of those NAS Cause Code values may be sent to the UE, depending on operator's choice. NOTE 2: Any other permanent errors from the Diameter base protocol as defined in IETFÊRFCÊ6733Ê[61], not listed here, should be mapped to NAS Cause Code #17 ""Network failure"". Table A.2: Mapping from detected error condition to NAS Cause Code values Condition NAS cause code sent to UE The MME receives a SGsAP-LOCATION-UPDATE-REJECT message from the VLR indicating in the reject cause ""IMSI unknown in HLR"" or if the UE has packet only subscription. Only used in the Combined Tracking and Location Area Update procedure. #2 ""IMSI Unknown in HSS"" The MME receives in Update-Location-Answer message an indication of Roaming restricted in MME due to unsupported feature #14 ""EPS services not allowed in this PLMN"" The MME cannot service an UE generated request because CS domain is not available and SMS in MME is not supported. #18 ""CS domain not available"" The value OPERATOR_DETERMINED_BARRING is received in the Subscriber-Status AVP #15 ""No suitable cells in tracking area"" The HSS indicates that due to subscription to a ""regionally restricted service"" the UE is not allowed to operate in the tracking area. #12 ""Tracking area not allowed"" The CSG ID of the cell from where the UE has sent the TRACKING AREA UPDATE REQUEST message is not contained in the Allowed CSG list. #25 ""Not authorized for this CSG"" The MME detects that it cannot communicate with the HSS in the HPLMN of the subscriber. How the MME detect this is implementation specific. #15 ""No suitable cells in tracking area"" #14 ""EPS services not allowed in this PLMN"" #111 ""Protocol error, unspecified"" NOTE: Any of those NAS Cause Code values may be sent to the UE, depending on operator's choice / configuration, e.g. NAS Cause Code #14 is to be sent to the UE if the network is an LTE only network. The MME detects by internal configuration that roaming is not allowed. #11 ""PLMN not allowed"" The MME detects that it cannot send a request to the HSS due to HSS overload (see Annex C). #22 ""Congestion"" #42 ""Severe network failure"" NOTE 1: Cause #22 should be used. In addition, the MME may ask the UE not to retry before a backoff timer expires, based on an operator policy. The eventual timer value may take into account the value received in the corresponding active overload report and operator policy. NOTE 2: Cause #42 may be used, for attach requests, in case of severe overload, according to operator policy. Annex B(normative): SGSN mapping table for S6d and NAS Cause Code values When the UE initiates Attach, Routing Area Update or Service Request, there may be the need for the SGSN to communicate with the HSS via S6d to retrieve authentication data and/or subscription data. If this retrieval is rejected by the HSS, the received Diameter-Result-Code values or Experimental-Result valuesneed to be mapped to appropriate cause codes over NAS to the UE. NOTE: Mapping from MAP Gr error codes to NAS Cause Code values is described in the 3GPPÊTSÊ29.010Ê[45]. This mapping shall be as shown in Table B.1. If the retrieval is successful, not needed (e.g. because data are already available) or not possible (e.g. because HSS is unavailable or overloaded), detected error conditions need to be mapped to appropriate cause codes over NAS to the UE. This mapping shall be as shown in Table and B.2. Table B.1: Mapping from S6d error code to NAS Cause Code values Reject indication received at SGSN over S6d NAS Cause Code sent to UE DIAMETER_ERROR_USER_UNKNOWN (5001) #8 ""GPRS services and non-GPRS services not allowed"" DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION (5420) #7 ""GPRS services not allowed"" DIAMETER_ERROR_RAT_NOT_ALLOWED (5421) #15 ""No suitable cells in location area"", or #13 ""Roaming not allowed in this location area"", or #12 ""Location area not allowed"" (NOTE 1) DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004) , without Error Diagnostic #11 ""PLMN not allowed"" DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), with Error Diagnostic of ODB_HPLMN_APN or ODB_VPLMN_APN #14 ""GPRS services not allowed in this PLMN"" DIAMETER_ERROR_ROAMING_NOT_ALLOWED (5004), with Error Diagnostic of ODB_ALL_APN #15 ""No suitable cells in location area"" DIAMETER_AUTHORIZATION_REJECTED (5003) DIAMETER_UNABLE_TO_DELIVER (3002) #15 ""No suitable cells in location area"" DIAMETER_UNABLE_TO_COMPLY (5012), DIAMETER_INVALID_AVP_VALUE (5004) DIAMETER_AUTHENTICATION_DATA_UNAVAILABLE (4181) and no retry takes place (NOTE 2) #17 ""Network failure"" NOTE 1: Any of those NAS Cause Code values may be sent to the UE, depending on operator's choice. NOTE 2: Any other permanent errors from the Diameter base protocol as defined in IETFÊRFCÊ6733Ê[61], not listed here, should be also mapped to NAS Cause Code #17 ""Network failure""."
"Table B.2: Mapping from detected error condition to NAS Cause Code values Condition NAS cause code to UE The SGSN receives a BSSAP+-LOCATION-UPDATE-REJECT message from the VLR indicating in the reject cause ""IMSI unknown in HLR"" or if the UE has packet only subscription. Only used in the Combined Routing and Location Area Update procedure. #2 ""IMSI Unknown in HLR"" The SGSN receives in Update-Location-Answer message an indication of Roaming restricted in SGSN due to unsupported feature #14 ""GPRS services not allowed in this PLMN"" The value OPERATOR_DETERMINED_BARRING is received in the Subscriber-Status AVP #15 ""No suitable cells in routing area"" The HLR indicates that due to subscription to a ""regionally restricted service"" the MS is not allowed to operate in the location area. #12 ""Location area not allowed"" The CSG ID of the cell from where the UE has sent the ROUTING AREA UPDATE REQUEST message is not contained in the Allowed CSG list. #25 ""Not authorized for this CSG"" The SGSN indicates that the MS has requested ""SMS-only services"" and the SMS services are provided by the SGSN in the PS domain. #28 ""SMS provided via GPRS in this routing area"" The SGSN detects that it cannot communicate with the HLR in the HPLMN of the subscriber. How the SGSN detect this is implementation specific. #15 ""No suitable cells in routing area"" #14 ""GPRS services not allowed in this PLMN"" NOTE: Any of those NAS Cause Code values may be sent to the UE, depending on operator's choice / configuration, e.g. NAS Cause Code #14 is to be sent to the UE if the network is an LTE only network. The SGSN detects by internal configuration that roaming is not allowed. #11 ""PLMN not allowed"" The SGSN detects that it cannot send a request to the HSS due to HSS overload (see Annex C). #22 ""Congestion"". In addition, the MME may ask the UE not to retry before a backoff timer expires, based on an operator policy. The eventual timer value may take into account the value received in the corresponding active overload report and operator policy. Annex C (normative): Diameter overload control mechanism C.1 General IETFÊRFCÊ7683Ê[50] specifies a Diameter overload control mechanism which includes the definition and the transfer of related AVPs between Diameter nodes. Depending on regional/national requirements and network operator policy, priority traffic (e.g. MPS as described in 3GPPÊTSÊ22.153Ê[52]) shall be exempted from throttling due to Diameter overload control up to the point where requested traffic reduction cannot be achieved without throttling the priority traffic. C.2 S6a/S6d interfaces C.2.1 General Diameter overload control mechanism is an optional feature. It is recommended to make use of IETFÊRFCÊ7683Ê[50] on the S6a/S6d interfaces where, when applied, the MME or the SGSN shall behave as reacting nodes and the HSS as a reporting node. C.2.2 HSS behaviour The HSS requests traffic reduction from its clients when the HSS is in an overload situation, including OC-OLR AVP in answer commands as described in IETFÊRFCÊ7683Ê[50]. The HSS identifies that it is in an overload situation by implementation specific means. For example, the HSS may take into account the traffic over the S6a/d interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources, etc. The HSS determines the specific contents of OC-OLR AVP in overload reports and the HSS decides when to send OC-OLR AVPs by implementation specific means. C.2.3 MME/SGSN behaviour The MME/SGSN applies required traffic reduction received in answer commands to subsequent applicable requests, as per RFC 7683Ê[50]. Requested traffic reduction is achieved by the MME/SGSN by implementation specific means. For example, it may implement message throttling with prioritization or a message retaining mechanism for operations that can be postponed. Diameter requests related to priority traffic (e.g. MPS as identified by the MME/SGSN through access procedures) and emergency have the highest priority. Depending on regional/national regulatory and operator policies, these Diameter requests shall be the last to be throttled, when the MME/SGSN has to apply traffic reduction. Relative priority amongst various priority traffic (e.g. MPS) and emergency traffic is subject to regional/national regulatory and operator policies. As a result of the need to throttle traffic, the MME or SGSN may reject Attach, Tracking Area Update or Service Requests initiated by UEs. The possible NAS causes are described in the Annex A and B. Annex D (Informative): Diameter overload control node behaviour D.1 Message prioritisation over S6a/d This clause describes possible behaviours of the MME/SGSN regarding message prioritisation as guidance and for an informative purpose when Diameter overload control is applied over S6a/d. When the HSS is overloaded, the MME/SGSN will receive overload reports from the HSS requesting a reduction of the requests sent by the MME/SGSN. The following and not exhaustive considerations may be taken into account for the MME/SGSN throttling decisions: - Prioritisation of requests related to priority traffic (e.g. MPS as identified by the MME/SGSN through access procedures, emergency) - Identification of the procedures that can be deferred (e.g. UE reachable notification, purge after a long inactivity time), so to avoid to drop non deferrable procedures; - Prioritisation of certain types of requests (i.e. between AIR, ULR, PUR, NOR) according to the context of their use, in particular: - Higher prioritisation of ULR commands when used in relation with mobility management (e.g. handover) for an attached user, so to avoid the interruption of the service for the user; - Lower prioritisation of AIR and ULR commands when related to an initial attach, so to avoid the attachment of new users; - Skipping of optional authentication (e.g. in TAU procedures). Annex E (normative): Diameter message priority mechanism E.1 General IETFÊRFCÊ7944Ê[57] specifies a Diameter routing message priority mechanism that allows Diameter nodes to indicate the relative priority of Diameter messages. With this information, other Diameter nodes may leverage the relative priority of Diameter messages into routing, resource allocation, set the DSCP marking for transport of the associated Diameter message, and also abatement decisions when overload control is applied. E.2 S6a/S6d interfaces E.2.1 General The Diameter message priority mechanism is an optional feature. It is recommended to make use of IETF ÊRFC 7944Ê[57] over the S6a/S6d interfaces of an operator network when the overload control defined in Annex C is applied on these S6a/d interfaces. E.2.2 HSS, CSS, EIR behaviour When the HSS, the CSS or the EIR supports the Diameter message priority mechanism, the HSS, the CSS, or the EIR shall comply with IETFÊRFCÊ7944Ê[57]. The HSS or the CSS sending a request shall determine the required priority according to its policies. When priority is required, the HSS or the CSS shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the request according to the required priority level. When the HSS or the CSS receives the corresponding response, the HSS or the CSS shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request. When the HSS, the CSS, or the EIR receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, the HSS, the CSS, or the EIR may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, the HSS, the CSS, or the EIR shall include the DRMP AVP in the response.If: - the HSS, the CSS or the EIR supports using the Diameter message priority mechanism for DSCP marking purposes, - the transport network utilizes DSCP marking, and - message-dependant DSCP marking is possible for the protocol stack transporting Diameter, then the HSS, the CSS or the EIR shall set the DSCP marking for transport of the request or response according to the required priority level. When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific. E.2.3 MME/SGSN behaviour When the MME/SGSN supports the Diameter message priority mechanism, the MME/SGSN shall comply with IETFÊRFCÊ7944Ê[57]. The MME/SGSN sending a request shall determine the required priority according to its policies. When priority is required, the MME/SGSN shall include the DRMP AVP indicating the required priority level in the request it sends, and shall prioritise the requests according to the required priority level. When the MME/SGSN receives the corresponding response, it shall prioritise the received response according to the priority level received within the DRMP AVP if present in the response, otherwise according to the priority level of the corresponding request. When the MME/SGSN receives a request, it shall handle the request according to the received DRMP AVP priority level. For the response, it may modify the priority level received in the DRMP AVP according to its policies and shall handle the response according to the required priority level. If the required priority level is different from the priority level received in the request, it shall include the DRMP AVP in the response. If: - the MME/SGSN supports using the Diameter message priority mechanism for DSCP marking purposes, - the transport network utilizes DSCP marking, and - message-dependant DSCP marking is possible for the protocol stack transporting Diameter, then the MME/SGSN shall set the DSCP marking for transport of the request or response according to the required priority level. Diameter requests related to high priority traffic (e.g. MPS as identified by the MME/SGSN via the RRC Establishment Cause IE set to the highPriorityAccess value as per 3GPPÊTSÊ36.413Ê[19] or through subscription information in the MPS-Priority AVP, emergency) shall contain a DRMP AVP with a high priority of which the level value is operator dependent. When not-explicitly requested, the inclusion and priority value of the DRMP AVP in Diameter messages are implementation specific. Annex F (normative): Diameter load control mechanism F.1 General IETFÊRFCÊ8583Ê[60] specifies a mechanism for sharing of Diameter load information. It includes the definition and the transfer of related AVPs between Diameter nodes. F.2 S6a/S6d interfaces F.2.1 General Diameter load control mechanism is an optional feature. It is recommended to make use of IETFÊRFCÊ8583Ê[60] on the S6a/S6d interfaces where, when applied, the MME or the SGSN shall behave as receiving nodes and the HSS as a reporting node. F.2.2 HSS behaviour The HSS may report its current load by including a Load AVP of type HOST in answer commands as described in IETFÊRFCÊ8583Ê[60]. The HSS calculates its current load by implementation specific means. For example, the HSS may take into account the traffic over the S6a/d interfaces or other interfaces, the level of usage of internal resources (CPU, memory), the access to external resources, etc. The HSS determines when to send Load AVPs of type HOST by implementation specific means. F.2.3 MME/SGSN behaviour When performing next hop Diameter Agent selection for requests that are routed based on realm, the MME/SGSN may take into account load values from Load AVPs of type PEER received from candidate next hop Diameter nodes, as per IETFÊRFCÊ8583Ê[60]. Annex G (informative): Change history Date TSGÊ# TSG Doc."
"CR Rev Cat Subject/Comment New 2008-09 CT#41 CP-080475 V2.0.0 approved in CT#41 8.0.0 2008-12 CT#42 CP-080691 0001 1 S6a Vendor-Specific-Application-Id AVP 8.1.0 CP-080691 0002 1 RegSub feature CP-080691 0005 - Clarification on Immediate-Response-Preferred CP-080691 0006 1 Correction of the Reference of Supported Features CP-080691 0007 - Definition of RAT-Frequency-Selection-Priority CP-080691 0008 2 ME Identity Check CP-080703 0009 2 Gr alignment CP-080971 0010 3 Closed Subscriber Group CP-080691 0011 - AVP codes CP-080691 0012 1 MSISDN AVP CP-080691 0013 - Result codes CP-080691 0014 - Removal of Editor's note in ULA Flag CP-080691 0015 2 Duplicated AMBR AVP and Use of Called-Station-Id CP-080691 0017 - Change of AVP to carry the APN information CP-080691 0018 1 Reference to 3GPP-Charging-Characteristics CP-080691 0019 - Access Restriction Data Definition CP-080691 0020 - AMBR Definition CP-080691 0021 1 AVPs Encoding CP-080691 0022 1 PDN-GW Delete CP-080691 0023 1 Requesting Node Type Clarification CP-080691 0024 - Authn Session State AVP CP-080691 0026 2 Trace Session Activation and Deactivation CP-080691 0027 1 Context-Identifier in APN-Configuration-Profile CP-080691 0029 - APN-OIReplacement CP-080703 0032 - Access Restriction CP-080691 0033 1 Context Identifier clarification CP-080691 0034 1 APN-Configuration correction CP-080691 0037 - Removal of Supported RAT Types CP-080691 0039 1 Extension of the Terminal-Information AVP for non-3GPP accesses CP-080691 0040 - Conditionality of ULA-Flags and PUA-Flags AVPs CP-080691 0042 - Wrong Description for Complete APN Configuration Profile Withdrawal CP-080691 0043 - Purge UE Detailed Behaviour CP-080691 0044 1 MME/SGSN area restricted flag cleanup - TS number in cover page corrected 8.1.1 2009-03 CT#43 CP-090056 0048 2 Context Identifier for Update or Removal of PDN GW 8.2.0 CP-090046 0049 - Clarification of the relationship between Subscriber-Status and ODB CP-090046 0051 2 Context-Identifier in APN-Configuration-Profile CP-090024 0052 - Update of the AVP Codes CP-090236 0053 2 PDN GW update for Wildcard APN CP-090044 0054 1 Ready for SM CP-090046 0055 - ODB for SM CP-090044 0056 2 Handling LCS Subscription Data CP-090046 0057 2 Charging Characteristics CP-090046 0058 2 Regional-Subscription-Zone-Code AVP Correction CP-090046 0059 2 Trace Depth corrections CP-090046 0060 2 Delete Subscriber Data Request procedure CP-090046 0063 1 Coding definition for STN-SR CP-090046 0064 - Trace Reference in DSR CP-090046 0065 1 DSR-Flags CP-090046 0066 2 Clarification on All-APN-Configurations-Included-Indicator CP-090046 0069 - User-Name AVP contains only the IMSI CP-090046 0070 1 MIP6-Agent-Info Definition and Usage CP-090046 0075 1 Allocation Retention Priority CP-090046 0076 1 APN includes only the Network Identifier CP-090046 0077 - Error Codes and ABNF Corrections CP-090039 0078 4 User to HSS resolution CP-090046 0079 1 Introducing the Trace-Collection-Entity AVP CP-090046 0081 4 Usage of Immediate-Response-Preferred AVP CP-090044 0082 3 Handling SMS Subscription Data CP-090046 0083 - SCTP version CP-090046 0084 - RFC 5447 References 2009-06 CT#44 CP-090287 0086 1 Notification of SMS over IP Non-Delivery for E-UTRAN and UE Reachability 8.3.0 CP-090287 0087 1 Coding of Immediate Response Preferred AVP CP-090287 0088 - Trace Event List CP-090287 0089 - Removal of Requesting Node Type from AIR CP-090287 0091 - Regional-Subscription-Zone-Code clarification CP-090287 0092 - Clarification of PLMN encoding CP-090287 0093 - Diameter Command Codes for S6a/S6d/S13/S13' CP-090287 0094 - Update of Diameter Codes CP-090287 0095 1 Formatting of APN in Service-Selection AVP CP-090378 0096 3 User Data Download Indication CP-090315 0097 - Usage of Single-Registration-Indication CP-090495 0098 3 ULR processing enhancement 2009-09 CT#45 CP-090531 0100 2 Correction on APN-OI-Replacement 8.4.0 Cp-090726 0101 3 GPRS subscription data over S6d CP-090531 0102 1 Usage of DIAMETER_ERROR_UNKNOWN_EPS_SUBSCRIPTION CP-090531 0103 6 Cancel Location for Initial Attach CP-090531 0104 4 Subscriber Data Update CP-090531 0105 1 Usage of Single Registration Indication CP-090531 0106 2 Charging Characteristics Reference CP-090531 0107 1 Alerting Reason Behaviour CP-090531 0108 1 Wildcard APN CP-090531 0109 - Subscriber's NAM CP-090531 0111 - Trace ID length correction CP-090531 0112 1 Subscription-Data AVP in Update Location Answer CP-090531 0113 1 Default values for Allocation Retention Priority AVP CP-090531 0114 - Default APN and Wildcard APN CP-090531 0115 2 Correction in behavior of DSR-Flags CP-090531 0116 1 PDN Type CP-090531 0118 1 Clarification on the process of skip subscriber data flag in the HSS CP-090532 0119 1 Corrections on IDR ABNF and Service Type AVP CP-090532 0120 1 TS-Code AVP is missing in DSR command CP-090532 0123 1 Cleanup of the TS CP-090532 0124 1 Format of User-Id CP-090532 0125 1 GPRS Subscription Data Update CP-090532 0126 2 APN-Configuration-Profile CP-090532 0128 1 3GPP2-MEID AVP CP-090532 0129 1 MIP6-Agent-Info AVP CP-090532 0130 - Alignment of Supported Feature concept with 29.229 CP-090532 0133 1 EPS Subscribed QoS CP-090532 0137 1 Restruction of the TSÊ29.272 CP-090532 0138 1 Trace Depth per session CP-090532 0140 - Clarification of Unsigned32 bit flag AVPs CP-090532 0141 1 Extra Regional-Subscription-Zone-Codes CP-090532 0142 1 Clarification of Service-Selection AVP encoding CP-090532 0143 1 User to HSS identity resolution for Diameter Proxy Agents CP-090532 0144 - RFSP coding 2009-09 CT#45 CP-090556 0122 3 Optimization of Subscriber Data Update 9.0.0 CP-090562 0131 Emergency Support in S6a 2009-12 CT#46 CP-091030 0148 4 Clarification on Some Subscription Data List Handling in MME/SGSN 9.1.0 CP-090793 0149 1 APN level APN-OI-Replacement CP-090800 0150 2 ICS-Flag CP-090767 0152 2 RFSP alignment in 29.272 CP-090801 0153 1 Notify Request for Emergency Attached UEs CP-090767 0155 2 Wildcard APN CP-090767 0157 1 Lifetime of Charging Characteristics after Change CP-091030 0159 2 Correction on the UE initiated detach procedure CP-090767 0163 2 FQDN for S6a NOR CP-090767 0165 - HPLMN-ODB AVP correction CP-091032 0167 From GMLC-Address to GMLC-Number CP-091030 0171 1 Static PDN GW CP-091030 0177 1 Clarification on Usage of Re-Synchronization-Info AVP CP-091030 0179 1 Clarification on the Number of PDP-Contexts in the GPRS-Subscription-Data AVP CP-090767 0185 - APN-Configuration-Profile usage in IDR CP-091030 0187 2 IMEI encoding CP-091030 0189 1 APN-Configuration Service-Selection values CP-091030 0191 1 QoS attributes CP-090789 0196 1 Subscription-Data clarification for UE Reachability CP-091030 0198 2 Vendor Specific Application ID CP-090776 0200 1 Destination Realm CP-090767 0202 - Correction to fault recovery procedure and ME identity check procedure CP-090767 0204 - Reference of 3GPP-Charging-Characteristics CP-090767 0206 - Reset procedure MME/SGSN behavior 2010-03 CT#47 CP-100020 0181 2 Correction to Purge UE Detailed Behaviour 9.2.0 CP-100020 0210 HPLMN ODB CP-100048 0211 2 TADS support in S6a/S6d CP-100020 0217 Cancellation-Type clarifications CP-100020 0219 1 IETF References update CP-100020 0221 Static PDN GW CP-100046 0222 1 Addition of V-GMLC address for S6a CP-100020 0223 1 Handling of UE Reachability MME Parameter CP-100020 0227 Indication of PLMN ID of the selected PGW CP-100040 0228 Context-Identifier in NOR CP-100235 0230 5 EPS Subscriber State and Location Information Request CP-100040 0233 1 Reset to Combined MME/SGSN CP-100040 0234 1 NOR-Flags correction CP-100040 0236 2 Indication of LCS Capabilities support over S6a/S6d CP-100040 0238 1 Fix ambiguity on context id AVP 2010-06 CT#48 CP-100264 0241 1 Service-Selection values 9.3.0 0243 1 MIP6-Agent-Info 0245 2 Fix ambiguity on usage of the Supported-Features AVP 0260 1 Correction of Context-Identifier CP-100277 0247 1 Dynamic information update after a Reset procedure 0248 1 Notify command from unknown MME CP-100416 0249 4 S6a Error Codes CP-100279 0258 3 URRP for SGSN CP-100265 0262 3 MME mapping between Diameter error codes and NAS Cause Code values 2010-09 CT#49 CP-100456 0268 1 Restoration of the SGSN Number in the VLR 9.4.0 CP-100457 0272 QoS-Subscribed CP-100457 0273 Trace-Reference AVP encoding CP-100457 0284 Usage of MIP-Home-Agent-Host AVP CP-100457 0285 Correction on HSS behaviour about IMEI CP-100577 0275 2 NAS Cause Code values CP-100463 0276 LCS Privacy Features for MME CP-100443 0281 2 Correction to Delete Subscriber Data for SGSN CP-100443 0283 1 Unclear Cancel-Type Setting for Single Registration and Initial Attach 2010-09 CT#49 CP-100465 0267 1 Addition of SIPTO permissions in PS subscription data 10.0.0 2010-10 CT#50 CP-100689 0324 1 HSS Error Returned due to ODB 10.1.0 CP-100689 0316 1 Clarification on Access Restriction Data CP-100698 0297 1 Removal of Notify Messages during detach or last PDN connection deactivation via 3GPP access CP-100679 0303 1 Usage of Served Party IP Address AVP inside the APN Configuration CP-100679 0305 1 Usage of APN-OI-Replacement AVP CP-100679 0307 AMBR clarification CP-100679 0308 Store HSS Identity in MME/SGSN after successful ULA CP-100679 0315 3 Fix ambiguity in the LCS related indication CP-100679 0327 2 Unknown EPS Subscription CP-100688 0325 1 Periodic TAU/RAU timer in HSS subscription CP-100707 0313 1 Correction of Restoration flag CP-100707 0319 Default APN and Wildcard APN CP-100707 0322 1 Usage of PGW Allocation Type AVP CP-100699 0323 Usage of STN-SR AVP CP-100699 0291 3 Enhanced SRVCC CP-100687 0290 4 Addition of MPS Priority in Subscription Data CP-100683 0289 1 Addition of LIPA permission in Subscription Data CP-100684 0288 1 SIPTO Permission for Wildcard APN 2011-03 CT#51 CP-110087 0329 2 Minimization of Drive Tests (MDT) 10.2.0 CP-110042 0330 2 Feature Flags for UE Reachability Notification and State/Location Info Retrieval CP-110042 0337 3 Correction of error cause handling CP-110042 0339 2 Setting of M bit AVP flag CP-110042 0343 1 AMBR Correction CP-110073 0332 2 Correction on PGW PLMN ID CP-110088 0334 2 Relay Node Indicator CP-110051 0346 1 PDP Address correction CP-110051 0351 2 Ambiguity in IDR flags CP-110051 0353 Homogeneous Support for IMS Voice over PS AVP missing 2011-06 CT#52 CP-110351 0362 SGSN-Number AVP correction 10.3.0 CP-110380 0357 2 MDT user consent CP-110375 0363 1 Purge from Combined MME/SGSN 2011-09 CT#53 CP-110562 0372 1 Active-APN AVP definition 10.4.0 CP-110562 0374 Context-Identifier when interworking with GTPv1 CP-110562 0380 1 APN-AMBR for GPRS CP-110565 0377 Correction on DIAMETER_AUTHORIZATION_REJECTED CP-110699 0381 Correction of implementation error in TSÊ29.272, CR 324 2011-09 CT#53 CP-110581 0369 2 Behaviour of HSS in abnormal case of Immediate-Response-Preferred AVP 11.0.0 CP-110584 0370 3 Add vSRVCC updates to the S6a interface 2011-12 CT#54 CP-110787 0390 1 Unknown EPS Subscription over S6d/S6a 11.1.0 CP-110811 0387 2 Equivalent PLMN CSG Subscription Request CP-110787 0397 1 M-bit Handling 2012-03 CT#55 CP-120023 0409 1 GMLC-Number format 11.2.0 CP-120025 0399 3 Initial Attach Indication in CLR CP-120029 0406 T-ADS data request for detached UE CP-120029 0410 1 Removal of Subscribed Periodic TAU/RAU timer in HSS subscription CP-120037 0400 Clarification on UE-SRVCC-Capability AVP in ULR CP-120037 0402 ODB clarification CP-120037 0403 2 S6a location reporting 2012-06 CT#56 CP-120240 0401 3 CSG ID and Local Time for NPLI 11.3.0 CP-120413 0415 4 Ready for SM in MME CP-120249 0418 1 ULR handling for combined MME/SGSN CP-120249 0419 Clarification on Update of PGW ID 2012-09 CT#57 CP-120476 0382 10 VCSG procedures over S7a/S7d 11.4.0 CP-120476 0394 5 Delete CSG subscription Data over S7a /S7d CP-120476 0416 4 VCSG Reset procedure over S7a/S7d CP-120481 0404 5 PS additional number over S6a/S6d CP-120462 0421 - Single Registration Indication CP-120462 0422 - Zone Codes CP-120462 0423 - Clarification on Notification of UE Reachability CP-120462 0428 - CSG-Subscription-Data replacement CP-120462 0430 1 Update of Homogeneous Support of IMS Over PS Sessions CP-120462 0434 2 Mapping S6a and NAS cause code CP-120473 0429 4 SMS in MME CP-120473 0432 1 SMS in SGSN CP-120480 0433 2 Local Time Zone 2012-12 CT#58 CP-120722 0441 1 User-CSG-Information 11.5.0 CP-120713 0457 1 SGSN-Number AVP CP-120740 0436 1 Application ID for S7a/S7d CP-120740 0443 2 Empty VCSG Subscription Data CP-120742 0438 1 Notification Procedure clarification for UE with Emergency Bearer Services CP-120742 0445 - Inclusion of APN-OI Replacement in PDP Context CP-120742 0450 - Correction in the chapter of Reset-Answer (RSA) command CP-120742 0452 1 UE Time Zone CP-120742 0453 1 Corrections to Local Time Zone CP-120742 0454 2 Clarification on IDR-Flags CP-120742 0455 - Correction of General Description of Delete Subscriber Data CP-120742 0458 - DSR-Flags CP-120742 0461 1 Wrong implementation of the Daylight-Saving-Time AVP CP-120736 0446 1 A-MSISDN Correction CP-120732 0447 1 MME network condition to NAS cause code mapping CP-120732 0448 2 SGSN network condition to NAS cause code mapping CP-120732 0449 3 MME de-registration for ""SMS in MME"" CP-120732 0451 1 Correction on Update Location Request CP-120732 0459 1 Alignment of stage 3 SMS in MME with stage 2 CP-120741 0460 1 Use of Flag instead of Enumerated AVPs 2013-03 CT#59 CP-130022 0466 - Corrections to wrong references and command/AVP name 11.6.0 CP-130022 0467 1 Update to Subscription-Data-Flags CP-130022 0471 1 Values not allowed for QCI over S6a/S6d CP-130022 0472 1 Cause Code Mapping CP-130022 0470 1 Registration for SMS Request for SMS in SGSN CP-130025 0474 - MDT parameters 2013-03 CT#59 CP-130031 0442 3 Check of Serving Node for S6a Security 12.0.0 CP-130031 0468 1 MME name encoding over S6a CP-130156 0475 1 SGSN indicating support of Lgd interface to HSS 2013-06 CT#60 CP-130380 0490 1 Removal of SMS-Only AVP and Typo Corrections on Some AVP Definitions 12.1.0 CP-130380 0501 2 MME identity for restoration procedures CP-130380 0492 1 Definition of A New Feature-List CP-130380 0488 1 UE-SRVCC-Capability Update Clarification CP-130380 0483 - Reset clarification CP-130380 0481 2 AIR rejection CP-130380 0479 1 Storing Last known Location Information of purged UE in HSS CP-130380 0512 1 Maximum value for the subscribed periodic RAU TAU timer CP-130279 0497 1 Definition of SS Status for Call Barring CP-130378 0489 2 SIPTO permission for Local Network enhancements CP-130288 0487 - PS Location Info request with RAT-type CP-130309 0482 - CSS clarification CP-130295 0478 - Restoration Priority during SGW and PGW restoration procedures CP-130410 0508 1 HSS handling of T-ADS for detached subscriber 2013-09 CT#61 CP-130444 0515 - Correction to the restoration priority levels during SGW and PGW restoration procedures 12.2.0 CP-130450 0517 - HPLMN-ODB Correction CP-130463 0518 2 CancelLocation requesting reattach CP-130456 0519 1 Indication of Gdd support over S6d CP-130461 0520 2 Homogeneous Support Of Voice over IP CP-130461 0521 1 Definition of User-State values CP-130461 0522 1 Context Identifier Range Inconsistency 2013-12 CT#62 CP-130611 0528 1 Addtion of S6aS6d-Indicator in NOR 12.3.0 CP-130617 0533 1 MME Initiated Removal of MME Registration for SMS CP-130624 0523 1 Combined MME/SGSN indicating the support for optimized LCS procedure CP-130624 0526 1 Clarification on Description of Features for LCS CP-130644 0525 1 SMS in MME CP-130623 0529 1 Alert Service Center sent over S6c CP-130632 0530 1 Purge Clarification CP-130639 0531 1 SGSN CAMEL Subscription Indication 2014-03 CT#63 CP-140035 0534 2 Clarification on Current-Location-Retrieved and Age-of-Location-Information 12.4.0 CP-140035 0536 3 Mechanism to determine if the UE is served by the MME and SGSN parts of the same combined MME/SGSN CP-140035 0537 - Call-Barring-Info AVP CP-140035 0538 - Missing SGs-MME-Identity AVP in the ULR 2014-06 CT#64 CP-140257 0544 1 SS-Status AVP Definition 12.5.0 CP-140264 0555 3 Cause Mapping for ODB CP-140264 0556 2 NOR Error User Unknown CP-140254 0557 1 Enhancement for ProSe CP-140413 0558 - Correction on SGSN CAMEL Capability in Supported-Features CP-140243 0540 5 Diameter overload control mechanism CP-140243 0559 1 Diameter overload over S6a/d 2014-09 CT#65 CP-140523 0564 2 Clarification on ProSe Subscription Data 12.6.0 CP-140514 0565 2 WLAN offloadability defined in HSS CP-140506 0567 2 P-CSCF Restoration Indication 2014-12 CT#66 CP-140772 0569 2 Reset-ID 12.7.0 CP-140772 0581 3 M-bit setting of Supported-Features AVP CP-140764 0571 - MDT PLMN List CP-140764 0580 1 S6a/S6d-Indicator in NOR CP-140790 0575 1 Priority Consideration for Diameter Overload Control 2014-12 CT#66 CP-140765 0574 2 Roaming Subscription Corresponding to Specific RAT 13.0.0 CP-140759 0578 2 Stored HSS Identity for HSS Restoration Procedure 2015-03 CT#67 CP-150035 0582 1 Clarification on the usage of SV in IMEI check procedure 13.1.0 2015-06 CT#68 CP-150265 0583 1 Cleanup and small error corrections 13.2.0 CP-150263 0584 2 Access Restriction Data per PLMN CP-150279 0585 1 Alignment of using ProSe and ProSe services 2015-09 CT#69 CP-150427 0597 - Wrong Application-ID for S7a Diameter Application 13.3.0 CP-150454 0586 3 Subscription data for extended buffering at the SGW CP-150453 0587 2 Introducing IMSI-Group ID Lists to the subscription Info CP-150449 0588 3 Addition of CP parameters to subscription data 2015-12 CT#70 CP-150778 0590 9 Add MTC Monitoring support 13.4.0 CP-150778 0606 1 Roaming and interaction with the IWK-SCEF CP-150778 0607 4 Introducing a Bitmask to inform the HSS of the Monitoring capabilities of the MME/SGSN CP-150778 0609 2 Deletion of all Monitoring events assigned to a subscriber (UE) CP-150785 0598 1 DL-Buffering-Suggested-Packet-Count AVP CP-150781 0600 1 Retrieval of ""UE Usage Type"" over S6a/S6d CP-150762 0601 1 Clarification of precedence between UE-level ""HO to non-3GPP access"" access restriction, and APN-level ""WLAN-Offloadability"" CP-150768 0602 4 Diameter message priority over S6a/d CP-150771 0604 2 Introduction of validity time delete and replace procedure for CP sets CP-150755 0611 1 ProSe in combined MME/SGSN CP-150744 0614 Erroneous AVP code for some MDT parameters CP-150759 0614 1 Update reference to DOIC new IETF RFC CP-150776 0615 1 Mobile Terminating SMS handling for extended Idle mode DRX 2016-03 CT#71 CP-160029 0618 2 Notifying the status of MONTE event configuration at the IWK-SCEF to the HSS 13.5.0 CP-160043 0619 1 Fix the issue on HSS restart procedure CP-160039 0620 1 User Plane Integrity Protection Indicator CP-160029 0621 3 Configure Monitoring Event to Multiple Serving Nodes CP-160033 0623 1 Allow SMS for NB-IoT UE without Combined Attach CP-160045 0625 - Adjacent PLMNs CP-160045 0626 1 Invocation of Alert procedure by HSS after ULR CP-160023 0629 1 Diameter message priority over S7a/d, S13, S13' CP-160033 0630 2 Addition of NB-IoT radio access type to the Access-Restriction-Data feature CP-160033 0631 3 New PDN-Type for Cellular IoT 2016-03 Table 7.3.1/1 formatted 13.5.1 2016-06 CT#72 CP-160215 0643 1 Diameter requests for priority traffic during overload control mechanism 13.6.0 2016-06 CT#72 CP-160238 0628 3 Subscription Data for combined MME/SGSN 13.6.0 2016-06 CT#72 CP-160238 0632 1 Cause Mapping 13.6.0 2016-06 CT#72 CP-160238 0633 - Correction on Service-Selection 13.6.0 2016-06 CT#72 CP-160238 0639 2 Group-Service-Id 13.6.0 2016-06 CT#72 CP-160233 0635 - Renaming of Validity-Time AVP 13.6.0 2016-06 CT#72 CP-160228 0636 - Update SMS Support for NB-IoT 13.6.0 2016-06 CT#72 CP-160225 0637 2 SCEF realm 13.6.0 2016-06 CT#72 CP-160222 0638 2 Shared Subscription data update 14.0.0 2016-06 CT#72 CP-160217 0640 1 Support for Non-IP PDP types 14.0.0 2016-06 CT#72 CP-160221 0641 1 MSISDN Removal from Subscription Profile 14.0.0 2016-09 CT#73 CP-160423 0645 - PDN-Connection-Restricted flag 14.1.0 2016-09 CT#73 CP-160423 0647 1 Preferred Data Mode for an SGi PDN connection 14.1.0 2016-09 CT#73 CP-160428 0652 - CR implementation error on ECR and ECA commands 14.1.0 2016-09 CT#73 CP-160426 0658 2 Current Location Retrieval 14.1.0 2016-09 CT#73 CP-160437 0649 1 Removal of Editor's Note on non shareable subscription data 14.1.0 2016-09 CT#73 CP-160437 0650 - Removal of Editor's Note on detailed checks for shared subscription data update 14.1.0 2016-09 CT#73 CP-160437 0656 2 Solution to avoid high load resulting from shared subscription data update 14.1.0 2016-09 CT#73 CP-160433 0653 - Change of Network Access Mode 14.1.0 2016-09 CT#73 CP-160432 0654 - Usage of Supported Features 14.1.0 2016-09 CT#73 CP-160432 0655 - Handling of MSISDN removal from subscription profile 14.1.0 2016-12 CT#74 CP-160679 0659 4 Handover of Emergency PDN Connections 14.2.0 2016-12 CT#74 CP-160673 0660 1 Reset-ID AVP description for shared subscription data update 14.2.0 2016-12 CT#74 CP-160673 0671 1 Update of ""Homogeneous Support"" Status 14.2.0 2016-12 CT#74 CP-160673 0684 1 Missing S7a/S7d application identifier 14.2.0 2016-12 CT#74 CP-160654 0662 1 Communication-Pattern Feature 14.2.0 2016-12 CT#74 CP-160681 0666 1 Load Control 14.2.0 2016-12 CT#74 CP-160681 0677 1 Host Load 14.2.0 2016-12 CT#74 CP-160665 0668 1 Dynamic Removal of UE Usage Type 14.2.0 2016-12 CT#74 CP-160665 0674 1 Presence of UE Usage Type in Error Responses 14.2.0 2016-12 CT#74 CP-160657 0670 1 Undefined Bits in Access Restriction Data 14.2.0 2016-12 CT#74 CP-160678 0672 1 Add V2X Subscription Data to S6a Interface 14.2.0 2016-12 CT#74 CP-160664 0682 - Correction to change IETF drmp draft version to official RFC 7944 14.2.0 2016-12 CT#74 CP-160660 0683 1 Deletion of all monitoring events 14.2.0 2017-03 CT#75 CP-170028 0692 1 Maximum Response Time 14.3.0 2017-03 CT#75 CP-170039 0687 1 Enhanced Coverage 14.3.0 2017-03 CT#75 CP-170039 0688 1 Inter-RAT PDN-Continuity 14.3.0 2017-03 CT#75 CP-170044 0693 1 Emergency-Info AVP in ULA 14.3.0 2017-03 CT#75 CP-170043 0696 1 Correct UE-PC5-AMBR Format 14.3.0 2017-03 CT#75 CP-170036 0697 2 Removal of complete APN Configuration Profile 14.3.0 2017-03 CT#75 CP-170036 0698 1 Clarification of MDT User Consent 14.3.0 2017-03 CT#75 CP-170036 0699 1 Missing M/O values in several feature flags 14.3.0 2017-03 CT#75 CP-170036 0700 2 Subscription parameters for eDRX 14.3.0 2017-03 CT#75 CP-170036 0701 2 Support of long and short Macro eNodeB IDs 14.3.0 2017-03 CT#75 CP-170048 0704 - Update of reference for the Diameter base protocol 14.3.0 2017-03 CT#75 CP-170048 0705 - Handling of the Vendor-Specific-Application-Id AVP 14.3.0 2017-03 CT#75 CP-170048 0706 - Cardinality of the Failed-AVP AVP in answer 14.3.0 2017-06 CT#76 CP-171029 0707 1 External Identifier in Subscription-Data 14.4.0 2017-06 CT#76 CP-171021 0709 - Alignment of PDN-Connection-Restricted Flag handling on NAS specification 14.4.0 2017-06 CT#76 CP-171017 0713 1 Add MBSFN Area List to MDT Configuration parameters 14.4.0 2017-06 CT#76 CP-171184 0715 2 Communication Patterns without Expiry Time 14.4.0 2017-06 CT#76 CP-171029 0717 1 Loss Of Connectivity Reason in S6a/d IDA 14.4.0 2017-06 CT#76 CP-171018 0720 1 Support for signaling transport level packet marking 14.4.0 2017-06 CT#76 CP-171043 0718 1 Clarification of S6a/Notification-Request command for non-IP APNs 15.0.0 2017-06 CT#76 CP-171041 0721 - Removal of UE-Usage-Type 15.0.0 2017-09 CT#77 CP-172027 0727 1 Access Restriction to NR as Secondary RAT 15.1.0 2017-09 CT#77 CP-172027 0728 1 Extended QoS for 5G NR 15.1.0 2017-09 CT#77 CP-172018 0729 1 Acknowledgements of downlink NAS data PDUs 15.1.0 2017-09 CT#77 CP-172018 0730 1 Reliable Data Service 15.1.0 2017-09 CT#77 CP-172026 0731 1 Enhancements for NAPS on Idle Status Indication 15.1.0 2017-09 CT#77 CP-172013 0736 - Correction of DRMP Procedures 15.1.0 2017-12 CT#78 CP-173016 0743 1 Correction on subscribed eDRX parameter value 15.2.0 2017-12 CT#78 CP-173028 0740 1 Clarification of UE Reachability monitoring event over S6a/S6d 15.2.0 2017-12 CT#78 CP-173025 0741 - Error in the DIAMETER_ERROR_EQUIPMENT_UNKNOWN name 15.2.0 2017-12 CT#78 CP-173025 0744 3 Active Time in Insert Subscriber Data 15.2.0 2017-12 CT#78 CP-173035 0746 1 Access restriction to unlicensed spectrum as secondary RAT 15.2.0 2017-12 CT#78 CP-173036 0747 1 Access Restrictions to NR as Secondary RAT on MM Context 15.2.0 2018-03 CT#79 CP-180013 0755 2 Handling of Homogenous-Support-of-IMS-Voice-Over-PS-Sessions AVP 15.3.0 2018-03 CT#79 CP-180021 0756 - Service Gap Time 15.3.0 2018-03 CT#79 CP-180025 0757 1 Filtering the Report for Number of UEs in a Geographic Area 15.3.0 2018-06 CT#80 CP-181122 0758 - Bandwidth Clarification 15.4.0 2018-06 CT#80 CP-181122 0759 1 Supported-Services AVP code 15.4.0 2018-06 CT#80 CP-181122 0762 1 Subscription for Aerial UE in 3GPP system 15.4.0 2018-06 CT#80 CP-181124 0765 1 Subscription data for ciphering keys 15.4.0 2018-06 CT#80 CP-181133 0763 1 Access Restrictions 15.4.0 2018-09 CT#81 CP-182077 0766 - Update of Broadcast-Location-Assistance-Data-Types AVP 15.5.0 2018-09 CT#81 CP-182067 0767 2 Access Restriction Data for NR as Secondary RAT not supported by HSS 15.5.0 2018-09 CT#81 CP-182067 0774 - Applicable values for AMBR 15.5.0 2018-09 CT#81 CP-182075 0768 1 Handling of monitoring events in ULA 15.5.0 2018-09 CT#81 CP-182072 0769 1 Subscribed PTW length 15.5.0 2018-09 CT#81 CP-182072 0770 1 DSR-Flag for Active-Time 15.5.0 2018-09 CT#81 CP-182071 0771 2 DSR-Flag for eDRX-Cycle-Length 15.5.0 2018-09 CT#81 CP-182084 0773 - Access Restrictions 15.5.0 2018-12 CT#82 CP-183092 0775 4 Single Registration 15.6.0 2018-12 CT#82 CP-183092 0776 1 Interworking with 5GS indicator in APN Subscription 15.6.0 2018-12 CT#82 CP-183092 0789 2 MME_UPDATE_PROCEDURE 15.6.0 2018-12 CT#82 CP-183098 0785 1 Deletion of monitoring events when unknown in SCEF 15.6.0 2018-12 CT#82 CP-183098 0786 - Event configuration failure in ULA 15.6.0 2018-12 CT#82 CP-183098 0787 1 Idle-Status-Indication is missing in monitoring event report 15.6.0 2018-12 CT#82 CP-183098 0788 1 Applicability of Maximum Number of Reports 15.6.0 2018-12 CT#82 CP-183100 0784 3 Behavior of MME/SGSN upon reception of DIAMETER_UNABLE_TO_COMPLY for NOR 15.6.0 2018-12 CT#82 CP-183100 0790 1 Paging Time Window 15.6.0 2019-03 CT#83 CP-190034 0791 1 eDRX AVPs 15.7.0 2019-03 CT#83 CP-190038 0792 - Missing Maximum-UE-Availability-Time AVP 15.7.0 2019-03 CT#83 CP-190034 0794 1 Access Restriction to NR as Secondary RAT for SGSN 15.7.0 2019-03 CT#83 CP-190034 0795 - Paging-Time-Window AVP name 15.7.0 2019-03 CT#83 CP-190037 0796 1 Handling of multiple external IDs for the same UE 15.7.0 2019-06 CT#84 CP-191023 0797 - Service Gap Time Deletion 15.8.0 2019-09 CT#85 CP-192094 0804 2 draft-ietf-dime-load published as RFC 8583 15.9.0 2019-09 CT#85 CP-192121 0801 1 Communication pattern enhancement 16.0.0 2019-09 CT#85 CP-192122 0800 1 Event type PDN Connectivity Status 16.0.0 2019-09 CT#85 CP-192122 0802 - Ethernet PDN Type 16.0.0 2019-12 CT#86 CP-193024 0808 - Applicability of Core Network Restrictions 16.1.0 2019-12 CT#86 CP-193038 0809 1 Subscribed ARPI 16.1.0 2019-12 CT#86 CP-193038 0810 - LTE-M Access Restriction 16.1.0 2019-12 CT#86 CP-193038 0812 - Missing protocol code-point values 16.1.0 2019-12 CT#86 CP-193052 0807 1 Battery Indication for Communication pattern enhancement 16.1.0 2020-03 CT#87e CP-200027 0813 1 Addition of IAB-Operation-Permission to subscriber data 16.2.0 2020-03 CT#87e CP-200036 0814 1 Subscription data for NR V2X 16.2.0 2020-06 CT#88e CP-201053 0815 - Alignments on definitions 16.3.0 2020-06 CT#88e CP-201053 0816 - Supported Monitoring Events 16.3.0 2020-06 CT#88e CP-201053 0818 - Error cause handling 16.3.0 2020-06 CT#88e CP-201053 0819 1 Update of RAT restrictions 16.3.0 2020-06 CT#88e CP-201053 0821 1 Supported Features for combined MME/SGSN 16.3.0 2020-06 CT#88e CP-201049 0817 1 Subscribed PC5 QoS Parameters for NR V2X 16.3.0 2020-06 CT#88e CP-201033 0820 1 SGSN Interworking with 5G 16.3.0 2020-09 CT#89e CP-202109 0822 2 Monitoring Configurations in ULA 16.4.0 2020-09 CT#89e CP-202094 0823 - Immediate Event Report in IDA 16.4.0 2020-09 CT#89e CP-202094 0824 1 Corrections on Broadcast-Location-Assistance-Data-Types 16.4.0 2020-12 CT#90e CP-203032 0826 - Extended Reference ID 16.5.0 2020-12 CT#90e CP-203032 0825 1 Correction for implementation error 16.5.0 2021-03 CT#91e CP-210057 0828 - Default APN for Ethernet PDN types 16.6.0 2021-03 CT#91e CP-210053 0829 2 Cancellation Type for UDICOM 16.6.0 2021-03 CT#91e CP-210027 0827 1 Use of inclusive terminology 17.0.0 2021-09 CT#93e CP-212053 0830 - F Superfluous AVPs in re-used Diameter AVPs table 17.1.0 2022-03 CT#93e CP-220063 0832 - F Removal of Monitoring Events when External ID or MSISDN is deleted 17.1.0 2022-03 CT#93e CP-220093 0831 1 B Access Restriction for IoT Satellite Access 17.2.0 2022-06 CT#96 CP-221060 0834 - F Clarification on Withdrawal of eDRX Cycle Length 17.3.0 2022-06 CT#96 CP-221060 0836 1 F Withdrawal of Paging Time Window Subscription 17.3.0 2022-06 CT#96 CP-221060 0837 1 F Emergency service session continuity 17.3.0 2022-06 CT#96 CP-221066 0840 - A CR 0828 has not been correctly implemented 17.3.0 2022-09 CT#97e CP-222073 0842 2 F Update ULR flags in support of handover 17.4.0 2023-03 CT#99 CP-230054 0843 - F Skip Subscriber Data in ULR-Flags 18.0.0 2023-06 CT#100 CP-231063 0844 - F Reachability Cause in immediate reports 18.1.0 2023-12 CT#102 0847 1 A Preventing LTE to NR NTN handover for users without NR NTN subscription 18.2.0 3GPP TS 29.272 V18.2.0 (2023-12) 168 Release 18 3GPP 3GPP TS 29.272 V18.2.0 (2023-12) 14 Release 18 3GPP"