6 Requirements concerning the use of SCCP and TC
29.0023GPPMobile Application Part (MAP) specificationRelease 17TS
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).