Difference between revisions of "ETSI-TS 100 974"
(Created page with "{{DISPLAYTITLE:ETSI TS 100 974 V7.15.0 (2004-03) }} ----------------------------------------------- %right%''Technical Specification''%% 3GPP TS 09.02 version 7.15.0 Release...") |
|||
| (43 intermediate revisions by one user not shown) | |||
| Line 1: | Line 1: | ||
{{DISPLAYTITLE:ETSI TS 100 974 V7.15.0 (2004-03) }} | {{DISPLAYTITLE:ETSI TS 100 974 V7.15.0 (2004-03) }} | ||
| − | |||
| − | |||
| − | + | '''Technical Specification''' | |
| − | + | ||
| − | + | 3GPP TS 09.02 version 7.15.0 Release 1998 <br/> | |
| − | + | ETSI TS 100 974 V7.15.0 (2004-03) <br/> | |
| − | + | ||
| − | + | '''Digital cellular telecommunications system (Phase 2+);<br/>Mobile Application Part (MAP) specification<br/>(3GPP TS 09.02 version 7.15.0 Release 1998)''' | |
| − | + | [[File:ETSI_header_logo.gif]]<br/> | |
| + | [[File:3GPP_TM_RD-8cd3d.jpg]]<br/> | ||
| + | [[File:gsm.jpeg]] | ||
| − | + | '''Reference''' | |
| + | *RTS/TSGN-040902v7f0 | ||
| + | '''Keywords''' | ||
| + | *GSM | ||
| + | '''ETSI''' | ||
| − | + | 650 Route des Lucioles<br/> | |
| − | + | F-06921 Sophia Antipolis Cedex - FRANCE<br/> | |
| + | Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16 | ||
| + | <br/> | ||
| + | Siret N° 348 623 562 00017 - NAF 742 C<br/> | ||
| + | Association à but non lucratif enregistrée à la<br/> | ||
| + | Sous-Préfecture de Grasse (06) N° 7803/88<br/> | ||
| − | |||
| − | |||
| − | ' | + | '''Important notice''' |
| − | + | Individual copies of the present document can be downloaded from: http://www.etsi.org <br/> | |
| − | + | ||
| − | + | ||
| − | + | The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.<br/> | |
| − | + | ||
| − | + | ||
| − | + | ||
| + | Users of the present document should be aware that the document may be subject to revision or change of status.<br/> | ||
| + | Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp<br/> | ||
| − | + | If you find errors in the present document, send your comment to: editor@etsi.org | |
| − | + | ||
| − | ' | + | '''Copyright Notification''' |
| − | + | No part may be reproduced except as authorized by written permission.<br/> | |
| + | The copyright and the foregoing restriction extend to reproduction in all media.<br/> | ||
| − | + | © European Telecommunications Standards Institute 2004.<br/> | |
| − | + | All rights reserved.<br/> | |
| − | ' | + | '''DECT'''<sup>TM</sup> , '''PLUGTESTS'''<sup>TM</sup> and '''UMTS'''<sup>TM</sup> are Trade Marks of ETSI registered for the benefit of its Members.<br/> |
| − | ' | + | '''TIPHON'''<sup>TM</sup> and the '''TIPHON'''<sup>TM</sup> logo are Trade Marks currently being registered by ETSI for the benefit of its Members.<br/> |
| − | + | ||
| − | ' | + | '''3GPP'''<sup>TM</sup> is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.<br/> |
| − | ' | + | |
| − | ' | + | '''Intellectual Property Rights''' |
| − | ' | + | |
| − | + | ||
| − | ' | + | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information | IPRs essential or potentially essential to the present document may have been declared to ETSI. The information | ||
| Line 76: | Line 66: | ||
server) which are, or may be, or may become, essential to the present document. | server) which are, or may be, or may become, essential to the present document. | ||
| − | + | '''Foreword''' | |
| − | + | ||
| − | This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). | + | This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). |
| + | The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. | ||
| + | The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp . | ||
| − | The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. | + | '''Foreword''' |
| + | |||
| + | This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). <br/> | ||
| + | |||
| + | The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. <br/> | ||
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under | The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under | ||
http://webapp.etsi.org/key/queryform.asp . | http://webapp.etsi.org/key/queryform.asp . | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). | This Technical Specification has been produced by the 3rd Generation Partnership Project (3GPP). | ||
| − | + | <br/> | |
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: | 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. | ||
| − | + | ==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. | 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. | ||
| Line 230: | Line 109: | ||
MAP consists of a set of MAP services which are provided to MAP service-users by a MAP service-provider. | MAP consists of a set of MAP services which are provided to MAP service-users by a MAP service-provider. | ||
| − | + | <center> | |
| − | + | [[File:Modelling_principles.png]]<br/> | |
| − | + | '''Figure 1.1/1: Modelling principles''' | |
| + | </center> | ||
Clauses 7 to 12 of the present document describe the MAP services. | Clauses 7 to 12 of the present document describe the MAP services. | ||
| Line 240: | Line 120: | ||
Clauses 18 to 25 describe the MAP user procedures which make use of MAP services. | Clauses 18 to 25 describe the MAP user procedures which make use of MAP services. | ||
| − | + | ==References== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The following documents contain provisions which, through reference in this text, constitute provisions of the present document. | The following documents contain provisions which, through reference in this text, constitute provisions of the present document. | ||
| Line 488: | Line 364: | ||
[109] ANSI T1.112 (1996 ): "Telecommunication – Signaling No. 7 – Signaling Connection Control Part (SCCP)". | [109] ANSI T1.112 (1996 ): "Telecommunication – Signaling No. 7 – Signaling Connection Control Part (SCCP)". | ||
| − | + | ==Abreviations == | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
Abbreviations used in the present document are listed in GSM 01.04. | Abbreviations used in the present document are listed in GSM 01.04. | ||
| − | |||
| − | |||
| − | + | ==Configuration of the mobile network== | |
| − | + | ===The entities of the mobile system=== | |
| − | + | ||
| − | + | ||
To provide the mobile service as it is defined, it is necessary to introduce some specific functions. These functional entities can be implemented in different equipments or integrated. In any case, exchanges of data occur between these entities. | To provide the mobile service as it is defined, it is necessary to introduce some specific functions. These functional entities can be implemented in different equipments or integrated. In any case, exchanges of data occur between these entities. | ||
| − | |||
| − | |||
| − | |||
| − | + | ====The Home Location Register (HLR)==== | |
This functional entity is a data base in charge of the management of mobile subscribers. A PLMN may contain one or several HLRs; it depends on the number of mobile subscribers, on the capacity of the equipment and on the | This functional entity is a data base in charge of the management of mobile subscribers. A PLMN may contain one or several HLRs; it depends on the number of mobile subscribers, on the capacity of the equipment and on the | ||
| − | organization of the network. All subscription data are stored there. The main information stored there concerns the location of each MS in order to be able to route calls to the mobile subscribers managed by each HLR. All management interventions occur on this data base. The HLRs have no direct control of MSCs. | + | organization of the network. All subscription data are stored there. The main information stored there concerns the location of each MS in order to be able to route calls to the mobile subscribers managed by each HLR. All management interventions occur on this data base. The HLRs have no direct control of MSCs.<br/> |
| − | + | <br/> | |
Two numbers attached to each mobile subscription are stored in the HLR: | Two numbers attached to each mobile subscription are stored in the HLR: | ||
| Line 533: | Line 398: | ||
The organization of the subscriber data is detailed in GSM 03.08. | The organization of the subscriber data is detailed in GSM 03.08. | ||
| − | |||
| − | + | ====The Visitor Location Register (VLR)==== | |
| − | + | ||
| − | + | ||
An MS roaming in an MSC area is controlled by the Visitor Location Register in charge of this area. When an MS appears in a location area it starts a location updating procedure. The MSC in charge of that area notices this registration and transfers to the Visitor Location Register the identity of the location area where the MS is situated. A VLR may be in charge of one or several MSC areas. | An MS roaming in an MSC area is controlled by the Visitor Location Register in charge of this area. When an MS appears in a location area it starts a location updating procedure. The MSC in charge of that area notices this registration and transfers to the Visitor Location Register the identity of the location area where the MS is situated. A VLR may be in charge of one or several MSC areas. | ||
| Line 553: | Line 415: | ||
The organization of the subscriber data is detailed in GSM 03.08. | The organization of the subscriber data is detailed in GSM 03.08. | ||
| − | + | ====The Mobile-services Switching Centre (MSC)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The Mobile-services Switching Centre is an exchange which performs all the switching functions for MSs located in a geographical area designated as the MSC area. The main difference between an MSC and an exchange in a fixed | The Mobile-services Switching Centre is an exchange which performs all the switching functions for MSs located in a geographical area designated as the MSC area. The main difference between an MSC and an exchange in a fixed | ||
| Line 565: | Line 423: | ||
* procedures required for hand-over (see GSM 03.09). | * procedures required for hand-over (see GSM 03.09). | ||
| − | + | ====The Base Station System (BSS)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The BSS is the sub-system of Base Station equipment (transceivers, controllers, etc...) which is viewed | The BSS is the sub-system of Base Station equipment (transceivers, controllers, etc...) which is viewed | ||
| Line 575: | Line 429: | ||
* by the SGSN through an interface (Gb-interface) with the functionality described in GSM 03.60. | * by the SGSN through an interface (Gb-interface) with the functionality described in GSM 03.60. | ||
| − | |||
| − | |||
| − | |||
| − | + | ====The Gateway MSC (GMSC)==== | |
In the case of incoming calls to the PLMN, if the fixed network is unable to interrogate the HLR, the call is routed to an MSC. This MSC will interrogate the appropriate HLR and then route the call to the MSC where the MS is located. The MSC which then performs the routing function to the actual location of the mobile is called the Gateway MSC. | In the case of incoming calls to the PLMN, if the fixed network is unable to interrogate the HLR, the call is routed to an MSC. This MSC will interrogate the appropriate HLR and then route the call to the MSC where the MS is located. The MSC which then performs the routing function to the actual location of the mobile is called the Gateway MSC. | ||
| Line 589: | Line 440: | ||
See also GSM 03.04. | See also GSM 03.04. | ||
| − | + | ====The SMS Gateway MSC==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The SMS GMSC is the interface between the Mobile Network and the network which provides access to the Short Message Service Centre, for short messages to be delivered to MSs. | The SMS GMSC is the interface between the Mobile Network and the network which provides access to the Short Message Service Centre, for short messages to be delivered to MSs. | ||
| Line 599: | Line 446: | ||
The choice of which MSCs can act as SMS Gateway MSCs is a network operator matter (e.g. all MSCs or some designated MSCs). | The choice of which MSCs can act as SMS Gateway MSCs is a network operator matter (e.g. all MSCs or some designated MSCs). | ||
| − | + | ====The SMS Interworking MSC==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The SMS IWMSC is the interface between the Mobile Network and the network which provides access to the Short Message Service Centre, for short messages submitted by MSs. | The SMS IWMSC is the interface between the Mobile Network and the network which provides access to the Short Message Service Centre, for short messages submitted by MSs. | ||
| Line 609: | Line 452: | ||
The choice of which MSCs can act as SMS Interworking MSCs is a network operator matter (e.g. all MSCs or some designated MSCs). | The choice of which MSCs can act as SMS Interworking MSCs is a network operator matter (e.g. all MSCs or some designated MSCs). | ||
| − | |||
| − | |||
| − | |||
| − | + | ====The VBS/VGCS Anchor MSC==== | |
The voice broadcast/group call anchor MSC obtains from the associated GCR all relevant attributes and controls in turn all cells in its area, VBS/VGCS Relay-MSCs and dispatchers belonging to a given group call. | The voice broadcast/group call anchor MSC obtains from the associated GCR all relevant attributes and controls in turn all cells in its area, VBS/VGCS Relay-MSCs and dispatchers belonging to a given group call. | ||
| − | |||
| − | + | ====The Equipment Identity Register (EIR)==== | |
| − | + | ||
| − | + | ||
This functional unit is a data base in charge of the management of the equipment identities of the MSs; see also GSM 02.16. | This functional unit is a data base in charge of the management of the equipment identities of the MSs; see also GSM 02.16. | ||
| − | + | ====The GSM Service Control Function (gsmSCF)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This functional entity contains the CAMEL service logic to implement OSS. It interfaces with the gsmSSF and the HLR; see also TS GSM 03.78. | This functional entity contains the CAMEL service logic to implement OSS. It interfaces with the gsmSSF and the HLR; see also TS GSM 03.78. | ||
| − | + | ====The VBS/VGCS Relay MSC==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The voice broadcast/group call relay MSC obtains from the associated anchor MSC all relevant attributes and controls in turn all cells in its area belonging to a given group call. | The voice broadcast/group call relay MSC obtains from the associated anchor MSC all relevant attributes and controls in turn all cells in its area belonging to a given group call. | ||
| − | + | ====The Group Call Register (GCR)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This functional unit is a data base in charge of the management of attributes related to the establishment of Voice Broadcast Calls and Voice Group Calls | This functional unit is a data base in charge of the management of attributes related to the establishment of Voice Broadcast Calls and Voice Group Calls | ||
| − | + | ====The Shared InterWorking Function Server (SIWFS)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
A Shared Inter Working Function is a network function that may be used by any MSC in the same PLMN to provide interworking for a data/fax call. Whereas an IWF can only be used by its MSC, the SIWF can be used by several other network nodes e.g. any MSC within the same PLMN (the concept is not limited to a certain number of MSCs). SIWF is applied to data services in GSM Phase 2 and GSM Phase 2+ (as defined in GSM 02.02, GSM 02.03 and GSM 02.34). | A Shared Inter Working Function is a network function that may be used by any MSC in the same PLMN to provide interworking for a data/fax call. Whereas an IWF can only be used by its MSC, the SIWF can be used by several other network nodes e.g. any MSC within the same PLMN (the concept is not limited to a certain number of MSCs). SIWF is applied to data services in GSM Phase 2 and GSM Phase 2+ (as defined in GSM 02.02, GSM 02.03 and GSM 02.34). | ||
| Line 668: | Line 489: | ||
SIWFS can be provided by a MSC (MSC/SIWFS) or by another network entity (stand alone SIWFS). | SIWFS can be provided by a MSC (MSC/SIWFS) or by another network entity (stand alone SIWFS). | ||
| − | + | ====The Serving GPRS Support Node (SGSN)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This functional unit keeps track of the individual MSs' location and performs security functions and access control; see also GSM 03.60. | This functional unit keeps track of the individual MSs' location and performs security functions and access control; see also GSM 03.60. | ||
| − | + | ====The Gateway GPRS Support Node (GGSN)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This functional unit provides interworking with external packet-switched networks, network screens and routing of the Network Requested PDP-context activation;see also GSM 03.60.4.2 "Configuration of a Public Land Mobile Network (PLMN)". | This functional unit provides interworking with external packet-switched networks, network screens and routing of the Network Requested PDP-context activation;see also GSM 03.60.4.2 "Configuration of a Public Land Mobile Network (PLMN)". | ||
| Line 688: | Line 501: | ||
In this configuration, all the functions are considered implemented in different equipments. Therefore, all the interfaces are external and need the support of the Mobile Application Part of the Signalling System No. 7 to exchange the data necessary to support the mobile service. From this configuration, all the possible PLMN organizations can be deduced. | In this configuration, all the functions are considered implemented in different equipments. Therefore, all the interfaces are external and need the support of the Mobile Application Part of the Signalling System No. 7 to exchange the data necessary to support the mobile service. From this configuration, all the possible PLMN organizations can be deduced. | ||
| − | + | ====The Number Portability Location Register (NPLR)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This functional unit provides routing information necessary in some Mobile Number Portability environments in order to route calls for ported mobile subscribers. For details see also GSM 03.66 [108]. | This functional unit provides routing information necessary in some Mobile Number Portability environments in order to route calls for ported mobile subscribers. For details see also GSM 03.66 [108]. | ||
| − | + | ====The Serving Mobile Location Center (SMLC)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
An SMLC is a database and processing entity that manages the procedures for obtaining the geographic location of a target MS in the coverage area served by the SMLC. In managing the location procedures, the SMLC chooses the positioning method and provides data and instructions to the LMUs or target MS that perform the actual location measurements associated with the chosen method. The SMLC also verifies any location estimate computed by the target MS or computes a location itself from measurements provided to it by the target MS or LMUs. | An SMLC is a database and processing entity that manages the procedures for obtaining the geographic location of a target MS in the coverage area served by the SMLC. In managing the location procedures, the SMLC chooses the positioning method and provides data and instructions to the LMUs or target MS that perform the actual location measurements associated with the chosen method. The SMLC also verifies any location estimate computed by the target MS or computes a location itself from measurements provided to it by the target MS or LMUs. | ||
| Line 711: | Line 516: | ||
management of its LMUs via interaction with one or more BSCs using the Lb interface. | management of its LMUs via interaction with one or more BSCs using the Lb interface. | ||
| − | + | ====The Gateway Mobile Location Center (GMLC)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The GMLC provides access to location services (LCS) for LCS clients external to a PLMN. A GMLC may also support access to location services from LCS clients internal to its own PLMN. The GMLC allows an LCS client to issue location requests for certain target MSs; it then conveys these requests to the VMSC currently serving each target MS and passes back the location results to the LCSclient. Any target MS whose location is requested may belong to either the GMLC’s own PLMN or another PLMN and may currently be served by either the GMLC’s own PLMN or another PLMN. | The GMLC provides access to location services (LCS) for LCS clients external to a PLMN. A GMLC may also support access to location services from LCS clients internal to its own PLMN. The GMLC allows an LCS client to issue location requests for certain target MSs; it then conveys these requests to the VMSC currently serving each target MS and passes back the location results to the LCSclient. Any target MS whose location is requested may belong to either the GMLC’s own PLMN or another PLMN and may currently be served by either the GMLC’s own PLMN or another PLMN. | ||
| − | + | ====The Location Measurement Unit (LMU)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The LMU is the logical network entity that performs location measurements in the VPLMN in order to either position a target MS or provide assistance data to be used in conjunction with other location measurements. An LMU is controlled by an SMLC in the VPLMN from which location commands can be received and to which any location measurements are returned. | The LMU is the logical network entity that performs location measurements in the VPLMN in order to either position a target MS or provide assistance data to be used in conjunction with other location measurements. An LMU is controlled by an SMLC in the VPLMN from which location commands can be received and to which any location measurements are returned. | ||
| − | + | <center> | |
| − | + | [[File:PLMN_config.png]]<br/> | |
| − | + | '''Figure 4.2/1: Configuration of a PLMN''' | |
| − | + | </center> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ===Void=== | |
| − | + | ===Interconnection between PLMNs=== | |
Since the configuration of a PLMN does not have any impact on other PLMNs, the signalling interfaces specified can | Since the configuration of a PLMN does not have any impact on other PLMNs, the signalling interfaces specified can | ||
be implemented both between the entities within a PLMN and between different PLMNs. | be implemented both between the entities within a PLMN and between different PLMNs. | ||
| − | |||
| − | + | ===The interfaces within the mobile service=== | |
| − | + | ====Interface between the HLR and the VLR (D-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This interface is used to exchange the data related to the location of the MS and to the management of the subscriber. The main service provided to the mobile subscriber is the capability to set up or to receive calls within the whole service area. To support that purpose the location registers have to exchange data. The VLR informs the HLR on the | This interface is used to exchange the data related to the location of the MS and to the management of the subscriber. The main service provided to the mobile subscriber is the capability to set up or to receive calls within the whole service area. To support that purpose the location registers have to exchange data. The VLR informs the HLR on the | ||
| Line 757: | Line 546: | ||
Exchanges of data may also occur when the mobile subscriber requires a particular service, when he wants to change some data attached to his subscription or when some parameters of the subscription are modified by administrative means. | Exchanges of data may also occur when the mobile subscriber requires a particular service, when he wants to change some data attached to his subscription or when some parameters of the subscription are modified by administrative means. | ||
| − | |||
| − | |||
| − | |||
| − | + | ====Interface between the HLR and the gsmSCF (J-interface)==== | |
This interface is used by the gsmSCF to request information from the HLR (via the Any-time Interrogation function) or to allow call independent related network- or user-initiated interaction between an MS and the gsmSCF (via the USSD function). Support of the gsmSCF-HLR interface is a network operator option. As a network operator option, the HLR may refuse to provide the information requested by the gsmSCF. | This interface is used by the gsmSCF to request information from the HLR (via the Any-time Interrogation function) or to allow call independent related network- or user-initiated interaction between an MS and the gsmSCF (via the USSD function). Support of the gsmSCF-HLR interface is a network operator option. As a network operator option, the HLR may refuse to provide the information requested by the gsmSCF. | ||
| − | + | ====Interface between the VLR and its associated MSC(s) (B-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The VLR is the location and management data base for the MSs roaming in the area controlled by the associated MSC(s). Whenever the MSC needs data related to a given MS currently located in its area, it interrogates the VLR. When a MS initiates a location updating procedure with an MSC, the MSC informs its VLR which stores the relevant information in its tables. This procedure occurs whenever a mobile roams to another location area. Also, for instance when a subscriber activates a specific supplementary service or modifies some data attached to a service, the MSC transfers (via the VLR) the request to the HLR, which stores these modifications and updates the VLR if required. | The VLR is the location and management data base for the MSs roaming in the area controlled by the associated MSC(s). Whenever the MSC needs data related to a given MS currently located in its area, it interrogates the VLR. When a MS initiates a location updating procedure with an MSC, the MSC informs its VLR which stores the relevant information in its tables. This procedure occurs whenever a mobile roams to another location area. Also, for instance when a subscriber activates a specific supplementary service or modifies some data attached to a service, the MSC transfers (via the VLR) the request to the HLR, which stores these modifications and updates the VLR if required. | ||
| Line 776: | Line 558: | ||
as an external interface. | as an external interface. | ||
| − | + | ====Interface between VLRs (G-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When an MS initiates a location updating using TMSI, the VLR can fetch the IMSI and authentication set from the previous VLR. | When an MS initiates a location updating using TMSI, the VLR can fetch the IMSI and authentication set from the previous VLR. | ||
| − | + | ====Interface between the HLR and the MSC (C-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When the fixed network is not able to perform the interrogation procedure needed to set up a call to a mobile subscriber, the Gateway MSC has to interrogate the HLR of the called subscriber to obtain the roaming number of the called MS (see GSM 03.04). | When the fixed network is not able to perform the interrogation procedure needed to set up a call to a mobile subscriber, the Gateway MSC has to interrogate the HLR of the called subscriber to obtain the roaming number of the called MS (see GSM 03.04). | ||
| Line 794: | Line 568: | ||
To forward a short message to a mobile subscriber, the SMS Gateway MSC has to interrogate the HLR to obtain the MSC number where the MS is located. | To forward a short message to a mobile subscriber, the SMS Gateway MSC has to interrogate the HLR to obtain the MSC number where the MS is located. | ||
| − | + | ====Interface between the MSC and the gsmSCF (L-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When one of the following Supplementary Services, CD, ECT or MPTY, is invoked in the MSC a notification shall be sent towards the gsmSCF. | When one of the following Supplementary Services, CD, ECT or MPTY, is invoked in the MSC a notification shall be sent towards the gsmSCF. | ||
| − | + | ====Interface between MSCs (E-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When a MS moves from one MSC area to another during a call, a handover procedure has to be performed in order to continue the communication. For that purpose the MSCs involved have to exchange data to initiate and then to realize the operation. | When a MS moves from one MSC area to another during a call, a handover procedure has to be performed in order to continue the communication. For that purpose the MSCs involved have to exchange data to initiate and then to realize the operation. | ||
| Line 814: | Line 580: | ||
This interface is also used to transfer information for inter-MSC VBS/VGCS calls . | This interface is also used to transfer information for inter-MSC VBS/VGCS calls . | ||
| − | + | ====Interface between the MSC and Base Station Systems (A-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The description of this interface is contained in the GSM 08-series of MSs. | The description of this interface is contained in the GSM 08-series of MSs. | ||
| Line 828: | Line 590: | ||
* location management. | * location management. | ||
| − | + | ====Interface between MSC and EIR (F-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This interface is used when an MSC wants to check an IMEI. | This interface is used when an MSC wants to check an IMEI. | ||
| − | + | ====Interface between VBS/VGCS Anchor MSC and GCR (I-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This is an internal interface. | This is an internal interface. | ||
| − | + | ====Interface between the MSC and the SIWF server (K-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When a MSC detects that it can not provide the requested IW function, resources from an SIWF server can be used. This interface is used to allocate resources in that SIWF server and establish required physical connections to that server. | When a MSC detects that it can not provide the requested IW function, resources from an SIWF server can be used. This interface is used to allocate resources in that SIWF server and establish required physical connections to that server. | ||
| − | + | ====Interface between SGSN and HLR (Gr-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The description of this interface is contained in the GSM 03.60. | The description of this interface is contained in the GSM 03.60. | ||
| − | + | ====Interface between SGSN and SMS-GMSC or SMS-IWMSC (Gd-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The description of this interface is contained in the GSM 03.60. | The description of this interface is contained in the GSM 03.60. | ||
| − | + | ====Interface between GGSN and HLR (Gc-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The description of this interface is contained in the GSM 03.60. | The description of this interface is contained in the GSM 03.60. | ||
| − | + | ====Interface between SGSN and EIR (Gf-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The description of this interface is contained in the GSM 03.60. | The description of this interface is contained in the GSM 03.60. | ||
| − | + | ====Interface between SGSN and BSC (Gb-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The description of this interface is contained in the GSM 03.60. | The description of this interface is contained in the GSM 03.60. | ||
| − | + | ====Interface between SGSN and MSC/VLR (Gs-interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The description of this interface is contained in the GSM 09.18. | The description of this interface is contained in the GSM 09.18. | ||
| − | + | ====Interface between SMLC and BSC (Lb interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This interface is used by a BSC when an SMLC is BSS based to request either the initiation of location procedures or the retrieval of location assistance data for a particular target MS in the coverage area served by the SMLC. The interface is also used to transfer LCS measurement and O&M information between an SMLC and LMU via the BSC. A description of this interface is contained in GSM 03.71 and GSM 09.31. | This interface is used by a BSC when an SMLC is BSS based to request either the initiation of location procedures or the retrieval of location assistance data for a particular target MS in the coverage area served by the SMLC. The interface is also used to transfer LCS measurement and O&M information between an SMLC and LMU via the BSC. A description of this interface is contained in GSM 03.71 and GSM 09.31. | ||
| − | + | ====Interface between SMLC and MSC (Ls interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This interface is used by the MSC when an SMLC is NSS based to request either the initiation of location procedures or the retrieval of location assistance data for a particular target MS in the coverage area served by the SMLC. The interface is also used to transfer LCS measurement and O&M information between an SMLC and LMU or BSC via the MSC. A description of this interface is contained in GSM 03.71 and GSM 09.31. | This interface is used by the MSC when an SMLC is NSS based to request either the initiation of location procedures or the retrieval of location assistance data for a particular target MS in the coverage area served by the SMLC. The interface is also used to transfer LCS measurement and O&M information between an SMLC and LMU or BSC via the MSC. A description of this interface is contained in GSM 03.71 and GSM 09.31. | ||
| − | + | ====Interface between SMLC and SMLC (Lp interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This interface is used by an SMLC to obtain LCS measurement information from an LMU controlled by another SMLC. A description of this interface is contained in GSM 03.71 and GSM 08.31. | This interface is used by an SMLC to obtain LCS measurement information from an LMU controlled by another SMLC. A description of this interface is contained in GSM 03.71 and GSM 08.31. | ||
| − | + | ====Void==== | |
| − | + | ====Interface between GMLC and HLR (Lh interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This interface is used by the GMLC to request the address of the visited MSC for a particular target MS whose location has been requested. | This interface is used by the GMLC to request the address of the visited MSC for a particular target MS whose location has been requested. | ||
| − | + | ====Interface between GMLC and MSC (Lg interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This interface is used by the GMLC to convey a location request to the MSC currently serving a particular target MS whose location was requested. The interface is used by the MSC to return location results to the GMLC. | This interface is used by the GMLC to convey a location request to the MSC currently serving a particular target MS whose location was requested. The interface is used by the MSC to return location results to the GMLC. | ||
| − | + | ====Interface between LCS Client and GMLC (Le interface)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
This interface is used by a client of the Location Services (LCS) to request location information from a GMLC for certain target MSs. The interface is used by the GMLC to provide location information to an LCS client. This interface is external to a PLMN and is not defined within GSM. | This interface is used by a client of the Location Services (LCS) to request location information from a GMLC for certain target MSs. The interface is used by the GMLC to provide location information to an LCS client. This interface is external to a PLMN and is not defined within GSM. | ||
| − | + | ===Splitting of the data storage=== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The data attached to each MS management, operation and location are stored in the Location Registers. Some data are duplicated in the HLR and in the VLR, but others may be stored only in one place. | The data attached to each MS management, operation and location are stored in the Location Registers. Some data are duplicated in the HLR and in the VLR, but others may be stored only in one place. | ||
| Line 964: | Line 658: | ||
The data associated with any client that uses a particular GMLC to access location services is stored in the GMLC. | The data associated with any client that uses a particular GMLC to access location services is stored in the GMLC. | ||
| − | + | ==Overload and compatibility overview== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ===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. | 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. | ||
| − | + | ====Overload control for MSC (outside MAP)==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
For the entity MSC the following two procedures (outside MAP) may be applied to control the processor load: | For the entity MSC the following two procedures (outside MAP) may be applied to control the processor load: | ||
* ISDN | * ISDN | ||
| − | + | CCITT Recommendation Q.764 (Automatic Congestion Control), applicable to reduce the mobile terminating traffic; | |
* BSSAP | * BSSAP | ||
| − | + | GSM 08.08 (A-interface Flow Control), applicable to reduce the mobile originating traffic. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ====Overload control for MAP entities==== | |
For all MAP entities, especially the HLR, the following overload control method is applied: | For all MAP entities, especially the HLR, the following overload control method is applied: | ||
| Line 1,006: | Line 684: | ||
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 which might be changed due to network operator/implementation matters. | 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 which might be changed due to network operator/implementation matters. | ||
| − | + | ====Congestion control for Signalling System No. 7==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The requirements of SS7 Congestion control have to be taken into account as far as possible. | The requirements of SS7 Congestion control have to be taken into account as far as possible. | ||
| Line 1,016: | Line 690: | ||
Means which could be applied to achieve the required traffic reductions are described in subclauses 5.1.1 and 5.1.2. | Means which could be applied to achieve the required traffic reductions are described in subclauses 5.1.1 and 5.1.2. | ||
| − | + | ===Compatibility=== | |
| − | + | ====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. | 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. | ||
| Line 1,040: | Line 706: | ||
When a signalling procedure can be supported by several application contexts which differ by their version number, the MAP-User needs to select a name. It can either select the name which 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 be minimized. | When a signalling procedure can be supported by several application contexts which differ by their version number, the MAP-User needs to select a name. It can either select the name which 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 be minimized. | ||
| − | + | ====Strategy for selecting the Application Context (AC) version==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
A method should be used to minimize 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 | A method should be used to minimize 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 which can be used mainly at transitory phase stage when the network is one of mixed phase entities. | an example which can be used mainly at transitory phase stage when the network is one of mixed phase entities. | ||
| − | + | =====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 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. | ||
| Line 1,061: | Line 719: | ||
The data for each destination will go through the following states: | 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 subclause 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. | |
| − | + | =====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 replace the old AC-name by the new one in the list of associated highest AC supported. | ||
| + | '''ELSE''' | ||
| + | It uses the AC-name which 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. | ||
| − | + | =====Optimizing 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: | 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: | ||
| Line 1,138: | Line 766: | ||
* 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 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. | |
| − | + | ==Requirements concerning the use of SCCP and TC== | |
| − | + | ===Use of SCCP=== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The Mobile Application Part makes use of the services offered by the Signalling Connection Control Part of signalling System No. 7. CCITT Blue Book or ITU-T (03/93) Recommendations Q.711 to Q.716 should be consulted for the full specification of SCCP. 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 Mobile Application Part makes use of the services offered by the Signalling Connection Control Part of signalling System No. 7. CCITT Blue Book or ITU-T (03/93) Recommendations Q.711 to Q.716 should be consulted for the full specification of SCCP. 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. | ||
| − | + | ====SCCP Class==== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
MAP will only make use of the connectionless classes (0 or 1) of the SCCP. | MAP will only make use of the connectionless classes (0 or 1) of the SCCP. | ||
| − | + | ====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 SSN for MAP are specified in GSM 03.03 [17]. | The Application Entities (AEs) defined for MAP consist of several Application Service Elements (ASEs) and are addressed by sub-system numbers (SSNs). The SSN for MAP are specified in GSM 03.03 [17]. | ||
| Line 1,178: | Line 790: | ||
When the SGSN emulates MSC behavior for processing messages (MAP-MO-FORWARD-SHORT-MESSAGE, MAP_CHECK_IMEI) 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 the SGSN emulates MSC behavior for processing messages (MAP-MO-FORWARD-SHORT-MESSAGE, MAP_CHECK_IMEI) 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. | ||
| − | + | ====SCCP addressing==== | |
| − | + | =====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. | 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. | ||
| Line 1,194: | Line 798: | ||
Only the entities which 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: | Only the entities which 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: | ||
| − | + | <nowiki> | |
| − | + | 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. | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | *** Routing indicator = 0 (Routing on | + | 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 GSM 03.66) 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). | ||
| + | </nowiki> | ||
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: | 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: | ||
| − | + | <nowiki> | |
| + | 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). | |
| − | + | </nowiki> | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
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. | 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, ie 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. | 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 subclauses 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 following subclauses 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 Shared Inter Working Function (SIWF); | |
| − | + | * the Serving GPRS Support Node (SGSN); | |
| − | + | * the Gateway GPRS Support Node (GGSN); | |
| − | + | * the Gateway Mobile Location Center (GMLC). | |
| − | + | =====The Mobile-services Switching Centre (MSC)===== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
There are several cases where it is necessary to address the MSC. | There are several cases where it is necessary to address the MSC. | ||
| − | + | ======MSC interaction during handover====== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The address is derived from the target Cellid. | The address is derived from the target Cellid. | ||
| − | + | ======MSC for short message routing====== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When a short message has to be routed to a MS, the GMSC addresses the VMSC by an MSC identity received from the HLR which complies with E.164 rules. | When a short message has to be routed to a MS, the GMSC addresses the VMSC by an MSC identity received from the HLR which complies with E.164 rules. | ||
| Line 1,322: | Line 892: | ||
For MS originating short message, the IWMSC address is derived from the Service Centre address. | For MS originating short message, the IWMSC address is derived from the Service Centre address. | ||
| − | + | ======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. | 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. | ||
| − | + | ======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. | 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. | ||
| − | + | =====The Home Location Register (HLR)===== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
There are several cases where the HLR has to be addressed: | There are several cases where the HLR has to be addressed: | ||
| − | + | ======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). | 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). | ||
| Line 1,356: | Line 910: | ||
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 which has MAP capabilities, e.g. local exchange, outgoing International Switching Centre (ISC), etc. | 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 which has MAP capabilities, e.g. local exchange, outgoing International Switching Centre (ISC), etc. | ||
| − | + | ======Before location updating completion====== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When a 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: | When a 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 | |
| − | + | * on an E.164 HLR address; or | |
| − | + | * in the case of intra-PLMN signalling, on 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. | 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. | ||
| Line 1,375: | Line 925: | ||
Recommendation E.214) is shown below: | 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. | deleting the least significant digits. | ||
| Line 1,386: | Line 936: | ||
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. | 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. | ||
| − | + | ======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 | 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 | ||
| Line 1,398: | Line 944: | ||
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). | 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). | ||
| − | + | ======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 | 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. | 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. | ||
| − | + | ======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 | 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 | ||
| Line 1,418: | Line 956: | ||
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: | 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. | 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. | ||
| − | + | ======Before GPRS location updating completion====== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When a MS registers for the first time in a 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: | When a MS registers for the first time in a 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: | ||
| Line 1,450: | Line 984: | ||
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. | 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. | ||
| − | + | ======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 | 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 | ||
| Line 1,461: | Line 991: | ||
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. | 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. | ||
| − | + | ======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. | 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. | ||
| − | + | =====The Visitor Location Register (VLR)===== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
There are several cases when the VLR needs to be addressed. | There are several cases when the VLR needs to be addressed. | ||
| − | + | ======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. | 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. | ||
| − | + | ======HLR request====== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The HLR will only request information from a VLR if it is aware that one of its subscribers is in the VLR's 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. | The HLR will only request information from a VLR if it is aware that one of its subscribers is in the VLR's 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. | ||
| Line 1,495: | Line 1,009: | ||
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. | 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. | ||
| − | + | =====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. | 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. | ||
| − | + | =====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. | The EIR address is either unique or could be derived from the IMEI. The type of address is not defined. | ||
| − | + | =====The Shared Inter Working Function (SIWF)===== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
When the Visited MSC detects a data or fax call and the IWF in the V-MSC can not handle the required service an SIWF can be invoked. The SIWF is addressed with an E.164 number. | When the Visited MSC detects a data or fax call and the IWF in the V-MSC can not handle the required service an SIWF can be invoked. The SIWF is addressed with an E.164 number. | ||
| − | + | =====The Serving GPRS Support Node (SGSN)===== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The HLR will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN's 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. | The HLR will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN's 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. | ||
| Line 1,530: | Line 1,028: | ||
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. | 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. | |
| − | + | =====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. | 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. | ||
| − | + | =====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. | 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. | ||
| − | + | =====Void===== | |
| − | + | ======Void====== | |
| − | + | ======Void====== | |
| − | + | =====The Gateway Mobile Location Center (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 from the HLR for a target MS. The E.164 address of the GMLC is also provided to a serving MSC when the GMLC requests the location of a target MS served by this MSC. | 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 from the HLR for a target MS. The E.164 address of the GMLC is also provided to a serving MSC when the GMLC requests the location of a target MS served by this MSC. | ||
| − | + | =====Summary table===== | |
| − | + | ||
| − | + | ||
| − | + | ||
| − | + | ||
The following tables summarize 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 | The following tables summarize 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 | ||
| Line 1,579: | Line 1,055: | ||
For a response, the originating address passed in the invoke is used as SCCP Called Party Adress. 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. | For a response, the originating address passed in the invoke is used as SCCP Called Party Adress. 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. | ||
| − | + | <center> | |
| + | '''Table 6.1/1'''<br/> | ||
| + | [[File:tabel611.png]]<br/> | ||
| + | [[File:tabel6111.png]]<br/> | ||
| − | + | '''Table 6.1/2'''<br/> | |
| − | + | ||
| − | + | [[File:tabel612.png]] | |
| + | </center> | ||
| − | + | ===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 | 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 | ||
| Line 1,610: | Line 1,083: | ||
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). | 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). | ||
| − | + | <center> | |
| + | '''Figure 6.2/1: Facilities for supporting the Mobile Application Part in Signalling System No.7'''<br/> | ||
| + | [[File:tabel621.png]] | ||
| + | </center> | ||
| − | + | ==General on MAP services== | |
| − | + | ===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. | 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. | ||
| − | + | ===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. | 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. | ||
| − | + | <center> | |
| + | [[File:tabel721.png]]<br/> | ||
| − | + | '''Figure 7.2/1: Modelling principles''' | |
| + | </center> | ||
Latest revision as of 16:46, 27 August 2013
Technical Specification
3GPP TS 09.02 version 7.15.0 Release 1998
ETSI TS 100 974 V7.15.0 (2004-03)
Digital cellular telecommunications system (Phase 2+);
Mobile Application Part (MAP) specification
(3GPP TS 09.02 version 7.15.0 Release 1998)
Reference
- RTS/TSGN-040902v7f0
Keywords
- GSM
ETSI
650 Route des Lucioles
F-06921 Sophia Antipolis Cedex - FRANCE
Tel.: +33 4 92 94 42 00 Fax: +33 4 93 65 47 16
Siret N° 348 623 562 00017 - NAF 742 C
Association à but non lucratif enregistrée à la
Sous-Préfecture de Grasse (06) N° 7803/88
Important notice
Individual copies of the present document can be downloaded from: http://www.etsi.org
The present document may be made available in more than one electronic version or in print. In any case of existing or perceived difference in contents between such versions, the reference version is the Portable Document Format (PDF). In case of dispute, the reference shall be the printing on ETSI printers of the PDF version kept on a specific network drive within ETSI Secretariat.
Users of the present document should be aware that the document may be subject to revision or change of status.
Information on the current status of this and other ETSI documents is available at http://portal.etsi.org/tb/status/status.asp
If you find errors in the present document, send your comment to: editor@etsi.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.
© European Telecommunications Standards Institute 2004.
All rights reserved.
DECTTM , PLUGTESTSTM and UMTSTM are Trade Marks of ETSI registered for the benefit of its Members.
TIPHONTM and the TIPHONTM logo are Trade Marks currently being registered by ETSI for the benefit of its Members.
3GPPTM is a Trade Mark of ETSI registered for the benefit of its Members and of the 3GPP Organizational Partners.
Intellectual Property Rights
IPRs essential or potentially essential to the present document may have been declared to ETSI. The information pertaining to these essential IPRs, if any, is publicly available for ETSI members and non-members, and can be found in ETSI SR 000 314: "Intellectual Property Rights (IPRs); Essential, or potentially Essential, IPRs notified to ETSI in respect of ETSI standards", which is available from the ETSI Secretariat. Latest updates are available on the ETSI Web server (http://webapp.etsi.org/IPR/home.asp). Pursuant to the ETSI IPR Policy, no investigation, including IPR searches, has been carried out by ETSI. No guarantee can be given as to the existence of other IPRs not referenced in ETSI SR 000 314 (or the updates on the ETSI Web server) which are, or may be, or may become, essential to the present document.
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP). The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables. The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp .
Foreword
This Technical Specification (TS) has been produced by ETSI 3rd Generation Partnership Project (3GPP).
The present document may refer to technical specifications or reports using their 3GPP identities, UMTS identities or GSM identities. These should be interpreted as being references to the corresponding ETSI deliverables.
The cross reference between GSM, UMTS, 3GPP and ETSI identities can be found under http://webapp.etsi.org/key/queryform.asp .
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.
[edit] 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.
This Technical Specification (TS) 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 which are provided to MAP service-users by a MAP service-provider.
Figure 1.1/1: Modelling principles
Clauses 7 to 12 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 which make use of MAP services.
[edit] 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] GSM 01.04: "Digital cellular telecommunications system (Phase 2+); Abbreviations and acronyms".
[2] GSM 02.01: "Digital cellular telecommunications system (Phase 2+); Principles of telecommunication services supported by a GSM Public Land Mobile Network (PLMN)".
[3] GSM 02.02: "Digital cellular telecommunications system (Phase 2+); Bearer Services (BS) Supported by a GSM Public Land Mobile Network (PLMN)".
[4] GSM 02.03: "Digital cellular telecommunications system (Phase 2+); Teleservices Supported by a GSM Public Land Mobile Network (PLMN)".
[5] GSM 02.04: "Digital cellular telecommunications system (Phase 2+); General on supplementary services".
[6] GSM 02.09: "Digital cellular telecommunications system (Phase 2+); Security aspects".
[7] GSM 02.16: "Digital cellular telecommunications system (Phase 2+); International Mobile station Equipment Identities (IMEI)".
[8] GSM 02.41: "Digital cellular telecommunications system (Phase 2+); Operator determined barring".
[9] GSM 02.81: "Digital cellular telecommunications system (Phase 2+); Line identification supplementary services - Stage 1".
[10] GSM 02.82: "Digital cellular telecommunications system (Phase 2+); Call Forwarding (CF) supplementary services - Stage 1".
[11] GSM 02.83 : "Digital cellular telecommunications system (Phase 2+); Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 1".
[12] GSM 02.84: "Digital cellular telecommunications system (Phase 2+); Multi Party (MPTY) supplementary services - Stage 1".
[13] GSM 02.85: "Digital cellular telecommunications system (Phase 2+); Closed User Group (CUG) supplementary services - Stage 1".
[14] GSM 02.86: "Digital cellular telecommunications system (Phase 2+); Advice of charge (AoC) supplementary services - Stage 1".
[15] GSM 02.88: "Digital cellular telecommunications system (Phase 2+); Call Barring (CB) supplementary services - Stage 1".
[16] GSM 02.90: "Digital cellular telecommunication system (Phase 2+); Unstructured supplementary services operation - Stage 1".
[17] GSM 03.03: "Digital cellular telecommunications system (Phase 2+); Numbering, addressing and identification".
[18] GSM 03.04: "Digital cellular telecommunications system (Phase 2+); Signalling requirements relating to routeing of calls to mobile subscribers".
[19] GSM 03.07: "Digital cellular telecommunications system (Phase 2+); Restoration procedures".
[20] GSM 03.08: "Digital cellular telecommunications system (Phase 2+); Organisation of subscriber data".
[21] GSM 03.09: "Digital cellular telecommunications system (Phase 2+; Handover procedures".
[22] GSM 03.11: "Digital cellular telecommunications system (Phase 2+); Technical realization of supplementary services".
[23] GSM 03.12: "Digital cellular telecommunications system (Phase 2+); Location registration procedures".
[24] GSM 03.20: "Digital cellular telecommunications system (Phase 2+); Security related network functions".
[25] GSM 03.38: "Digital cellular telecommunications system (Phase 2+); Alphabets and language specific information for GSM".
[26] GSM 03.40: "Digital cellular telecommunications system (Phase 2+); Technical realization of the Short Message Service (SMS) Point to Point (PP)".
[26a] GSM 03.71: “Digital cellular telecommunications system (Phase 2+); Location Services (LCS); Functional Description; Stage 2”.
[27] GSM 03.81: "Digital cellular telecommunications system (Phase 2+); Line identification supplementary services - Stage 2".
[28] GSM 03.82: "Digital cellular telecommunications system (Phase 2+); Call Forwarding (CF) supplementary services - Stage 2".
[29] GSM 03.83: "Digital cellular telecommunications system (Phase 2+); Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 2".
[30] GSM 03.84: "Digital cellular telecommunications system (Phase 2+); Multi Party (MPTY) supplementary services - Stage 2".
[31] GSM 03.85: "Digital cellular telecommunications system (Phase 2+); Closed User Group (CUG) supplementary services - Stage 2".
[32] GSM 03.86: "Digital cellular telecommunications system (Phase 2+); Advice of Charge (AoC) supplementary services - Stage 2".
[33] GSM 03.88: "Digital cellular telecommunications system (Phase 2+); Call Barring (CB) supplementary services - Stage 2".
[34] GSM 03.90: "Digital cellular telecommunications system (Phase 2+); Unstructured supplementary services operation - Stage 2".
[35] GSM 04.08: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 specification".
[36] GSM 04.10: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 Supplementary services specification General aspects".
[37] GSM 04.11: "Digital cellular telecommunications system (Phase 2+); Point-to-Point (PP) Short Message Service (SMS) support on mobile radio interface".
[37a] GSM 04.71: “Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 location services specification.
[38] GSM 04.80: "Digital cellular telecommunications system (Phase 2+); Mobile radio interface layer 3 supplementary services specification Formats and coding".
[39] GSM 04.81: "Digital cellular telecommunications system (Phase 2+); Line identification supplementary services - Stage 3".
[40] GSM 04.82: "Digital cellular telecommunications system (Phase 2+); Call Forwarding (CF) supplementary services - Stage 3".
[41] GSM 04.83: "Digital cellular telecommunications system (Phase 2+); Call Waiting (CW) and Call Hold (HOLD) supplementary services - Stage 3".
[42] GSM 04.84: "Digital cellular telecommunications system (Phase 2+); Multi Party (MPTY) supplementary services - Stage 3".
[43] GSM 04.85: "Digital cellular telecommunications system (Phase 2+); Closed User Group (CUG) supplementary services - Stage 3".
[44] GSM 04.86: "Digital cellular telecommunications system (Phase 2+); Advice of Charge (AoC) supplementary services - Stage 3".
[45] GSM 04.88: "Digital cellular telecommunications system (Phase 2+); Call Barring (CB) supplementary services - Stage 3".
[46] GSM 04.90: "Digital cellular telecommunications system (Phase 2+); Unstructured supplementary services operation - Stage 3".
[47] GSM 08.02: "Digital cellular telecommunications system (Phase 2+); Base Station System - Mobile-services Switching Centre (BSS - MSC) interface Interface principles".
[48] GSM 08.06: "Digital cellular telecommunications system (Phase 2+); Signalling transport mechanism specification for the Base Station System - Mobile-services Switching Centre (BSS - MSC) interface".
[49] GSM 08.08: "Digital cellular telecommunications system (Phase 2+); Mobile Switching Centre - Base Station System (MSC - BSS) interface Layer 3 specification".
[49a] GSM 08.31: “Digital cellular telecommunications system (Phase 2+); Location Services (LCS); Serving Mobile Location Center (SMLC) – Serving Mobile Location Center (SMLC); SMLC Peer Protocol (SMLCPP).”
[49b] GSM 08.71: "Digital cellular telecommunications system (Phase 2+); Location Services (LCS); Serving Mobile Location Centre - Base Station System (SMLC - BSS) interface Layer 3 specification".
[50] GSM 09.01: "Digital cellular telecommunications system (Phase 2+); General network interworking scenarios".
[51] GSM 09.02: "Digital cellular telecommunications system (Phase 1); Mobile Application Part (MAP) specification".
[52] GSM 09.03: "Digital cellular telecommunications system (Phase 2+); Signalling requirements on interworking between the Integrated Services Digital Network (ISDN) or Public Switched Telephone Network (PSTN) and the Public Land Mobile Network (PLMN)".
[53] GSM 09.04: "Digital cellular telecommunications system (Phase 2+); Interworking between the Public Land Mobile Network (PLMN) and the Circuit Switched Public Data Network (CSPDN)".
[54] GSM 09.05: "Digital cellular telecommunications system (Phase 2+); Interworking between the Public Land Mobile Network (PLMN) and the Packet Switched Public Data Network (PSPDN) for Packet Assembly/Disassembly facility (PAD) access".
[55] GSM 09.06: "Digital cellular telecommunications system (Phase 2+); 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] GSM 09.07: "Digital cellular telecommunications system (Phase 2+); 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] GSM 09.08: "Digital cellular telecommunications system (Phase 2+); Application of the Base Station System Application Part (BSSAP) on the E-interface".
[58] GSM 09.10: "Digital cellular telecommunications system (Phase 2+); 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] GSM 09.11: "Digital cellular telecommunications system (Phase 2+); Signalling interworking for supplementary services".
[59a] GSM 09.31: "Digital cellular telecommunications system (Phase 2+); Location Services (LCS); Base Station System Application Part LCS Extension (BSSAP-LE)”.
[60] GSM 09.90: "Digital cellular telecommunications system (Phase 2+); Interworking between Phase 1 infrastructure and Phase 2 Mobile Stations (MS)".
[61] GSM 12.08: "Digital cellular telecommunications system (Phase 2); 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".
[67] CCITT Recommendation E.164: "Numbering plan for the ISDN era".
[68] CCITT Recommendation E.212: "Identification plan for land mobile stations".
[69] CCITT Recommendation E.213: "Telephone and ISDN numbering plan for land mobile stations".
[70] CCITT Recommendation E.214: "Structuring of the land mobile global title for the signalling connection control part".
[71] CCITT Recommendation Q.669: "Interworking between the Digital Subscriber Signalling System Layer 3 protocol and the Signalling System No.7 ISDN User part".
[72] CCITT Recommendation Q.711: "Specifications of Signalling System No.7; Functional description of the signalling connection control part".
[73] CCITT Recommendation Q.712: "Definition and function of SCCP messages".
[74] CCITT Recommendation Q.713: "Specifications of Signalling System No.7; SCCP formats and codes".
[75] CCITT Recommendation Q.714: "Specifications of Signalling System No.7; Signalling connection control part procedures".
[76] CCITT Recommendation Q.716: "Specifications of Signalling System No.7; Signalling connection control part (SCCP) performances".
[77] CCITT Recommendation Q.721 (1988): "Specifications of Signalling System No.7; Functional description of the Signalling System No.7 Telephone user part".
[78] CCITT Recommendation Q.722 (1988): "Specifications of Signalling System No.7; General function of Telephone messages and signals".
[79] CCITT Recommendation Q.723 (1988): "Specifications of Signalling System No.7; Formats and codes".
[80] CCITT Recommendation Q.724 (1988): "Specifications of Signalling System No.7; Signalling procedures".
[81] CCITT Recommendation Q.725 (1988): "Specifications of Signalling System No.7; Signalling performance in the telephone application".
[82] CCITT Recommendation Q.761 (1988): "Specifications of Signalling System No.7; Functional description of the ISDN user part of Signalling System No.7".
[83] CCITT Recommendation Q.762 (1988): "Specifications of Signalling System No.7; General function of messages and signals".
[84] CCITT Recommendation Q.763 (1988): "Specifications of Signalling System No.7; Formats and codes".
[85] CCITT Recommendation Q.764 (1988): "Specifications of Signalling System No.7; Signalling procedures".
[86] CCITT 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] CCITT Recommendation Q.771: "Specifications of Signalling System No.7; Functional description of transaction capabilities".
[88] CCITT Recommendation Q.772: "Specifications of Signalling System No.7; Transaction capabilities information element definitions".
[89] CCITT Recommendation Q.773: "Specifications of Signalling System No.7; Transaction capabilities formats and encoding".
[90] CCITT Recommendation Q.774: "Specifications of Signalling System No.7; Transaction capabilities procedures".
[91] CCITT Recommendation Q.775: "Specifications of Signalling System No.7; Guide-lines for using transaction capabilities".
[92] CCITT Recommendation X.200: "Reference Model of Open systems interconnection for CCITT Applications".
[93] CCITT Recommendation X.208 (1988): "Specification of Abstract Syntax Notation One (ASN.1)".
[94] CCITT Recommendation X.209 (1988): "Specification of basic encoding rules for Abstract Syntax Notation One (ASN.1)".
[95] CCITT Recommendation X.210: "Open systems interconnection layer service definition conventions".
[96] GSM 09.02: "Digital cellular telecommunications system (Phase 2); Mobile Application Part (MAP) specification”.
[97] GSM 03.18: "Digital cellular telecommunications system (Phase 2+); Basic Call Handling".
[98] GSM 03.78: "Digital cellular telecommunications system (Phase 2+); Customised Applications for Mobile network Enhanced Logic (CAMEL) - Stage 2”.
[99] GSM 03.79: "Digital cellular telecommunications system (Phase 2+); Support of Optimal Routeing (SOR) - Stage 2”.
[100] GSM 03.68: "Digital cellular telecommunications system (Phase 2+); - Stage 2".
[101] GSM 03.69: "Digital cellular telecommunications system (Phase 2+); - Stage 2".
[102] ANSI T1.113: "Signaling System No. 7 (SS7) - ISDN User Part".
[103] GSM 03.54 "Digital cellular telecommunications system (Phase 2+); Stage 2 Description for the use of a Shared Inter Working Function (SIWF) in a GSM PLMN".
[104] GSM 03.60: "Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS) Description; Stage 2".
[105] GSM 09.60: "Digital cellular telecommunications system (Phase 2+), General Packet Radio Service (GPRS); GPRS Tunnelling Protocol (GTP) across the Gn and Gp Interface".
[106] GSM 09.18: "Digital cellular telecommunications system (Phase 2+); General Packet Radio Service (GPRS); Serving GPRS Support Node (SGSN) - Visitors Location Register (VLR); Gs interface layer 3 specification".
[107] GSM 03.93: "Digital cellular telecommunications system (Phase 2+); Technical Realization of Completion of Calls to Busy Subscriber (CCBS); Stage 2".
[108] GSM 03.66: "Digital cellular telecommunications system (Phase 2+); Support of Mobile Number Portability (MNP); Technical Realisation Stage 2".
[109] ANSI T1.112 (1996 ): "Telecommunication – Signaling No. 7 – Signaling Connection Control Part (SCCP)".
[edit] Abreviations
Abbreviations used in the present document are listed in GSM 01.04.
[edit] Configuration of the mobile network
[edit] The entities of the mobile system
To provide the mobile service as it is defined, it is necessary to introduce some specific functions. These functional entities can be implemented in different equipments or integrated. In any case, exchanges of data occur between these entities.
[edit] The Home Location Register (HLR)
This functional entity is a data base in charge of the management of mobile subscribers. A PLMN may contain one or several HLRs; it depends on the number of mobile subscribers, on the capacity of the equipment and on the
organization of the network. All subscription data are stored there. The main information stored there concerns the location of each MS in order to be able to route calls to the mobile subscribers managed by each HLR. All management interventions occur on this data base. The HLRs have no direct control of MSCs.
Two numbers attached to each mobile subscription are stored in the HLR:
- IMSI;
- MSISDN.
The data base contains other information such as:
- location information (VLR number);
- basic telecommunication services subscription information;
- service restrictions (e.g. roaming limitation);
- supplementary services; the tables contain the parameters attached to these services;
- GPRS subscription data and routeing information.
The organization of the subscriber data is detailed in GSM 03.08.
[edit] The Visitor Location Register (VLR)
An MS roaming in an MSC area is controlled by the Visitor Location Register in charge of this area. When an MS appears in a location area it starts a location updating procedure. The MSC in charge of that area notices this registration and transfers to the Visitor Location Register the identity of the location area where the MS is situated. A VLR may be in charge of one or several MSC areas.
The VLR also contains the information needed to handle the calls set up or received by the MSs registered in its data base (in some cases the VLR may have to obtain additional information from the HLR); the following elements can be found in its tables:
- the IMSI;
- the MSISDN;
- the TMSI, if applicable;
- the location area where the MS has been registered. This will be used to call the station;
- supplementary service parameters.
The information is passed between VLR and HLR by the procedures described in GSM 03.12.
The organization of the subscriber data is detailed in GSM 03.08.
[edit] The Mobile-services Switching Centre (MSC)
The Mobile-services Switching Centre is an exchange which performs all the switching functions for MSs located in a geographical area designated as the MSC area. The main difference between an MSC and an exchange in a fixed network is that the MSC has to take into account the impact of the allocation of radio resources and the mobile nature of the subscribers and has to perform, for example, the following procedures:
- procedures required for the location registration (see GSM 03.12);
- procedures required for hand-over (see GSM 03.09).
[edit] The Base Station System (BSS)
The BSS is the sub-system of Base Station equipment (transceivers, controllers, etc...) which is viewed
- by the MSC through an interface (A-interface) with the functionality described in GSM 08.02;
- by the SGSN through an interface (Gb-interface) with the functionality described in GSM 03.60.
[edit] The Gateway MSC (GMSC)
In the case of incoming calls to the PLMN, if the fixed network is unable to interrogate the HLR, the call is routed to an MSC. This MSC will interrogate the appropriate HLR and then route the call to the MSC where the MS is located. The MSC which then performs the routing function to the actual location of the mobile is called the Gateway MSC.
The choice of which MSCs can act as Gateway MSCs is a network operator matter (e.g. all MSCs or some designated MSCs).
If the call is a voice group/broadcast call it is routed directly from the GMSC to the VBS/VGCS Anchor MSC, based on information (VBS/VGCS call reference) contained in the dialled number. See also GTSs 03.68 and 03.69.
See also GSM 03.04.
[edit] The SMS Gateway MSC
The SMS GMSC is the interface between the Mobile Network and the network which provides access to the Short Message Service Centre, for short messages to be delivered to MSs.
The choice of which MSCs can act as SMS Gateway MSCs is a network operator matter (e.g. all MSCs or some designated MSCs).
[edit] The SMS Interworking MSC
The SMS IWMSC is the interface between the Mobile Network and the network which provides access to the Short Message Service Centre, for short messages submitted by MSs.
The choice of which MSCs can act as SMS Interworking MSCs is a network operator matter (e.g. all MSCs or some designated MSCs).
[edit] The VBS/VGCS Anchor MSC
The voice broadcast/group call anchor MSC obtains from the associated GCR all relevant attributes and controls in turn all cells in its area, VBS/VGCS Relay-MSCs and dispatchers belonging to a given group call.
[edit] The Equipment Identity Register (EIR)
This functional unit is a data base in charge of the management of the equipment identities of the MSs; see also GSM 02.16.
[edit] The GSM Service Control Function (gsmSCF)
This functional entity contains the CAMEL service logic to implement OSS. It interfaces with the gsmSSF and the HLR; see also TS GSM 03.78.
[edit] The VBS/VGCS Relay MSC
The voice broadcast/group call relay MSC obtains from the associated anchor MSC all relevant attributes and controls in turn all cells in its area belonging to a given group call.
[edit] The Group Call Register (GCR)
This functional unit is a data base in charge of the management of attributes related to the establishment of Voice Broadcast Calls and Voice Group Calls
[edit]
A Shared Inter Working Function is a network function that may be used by any MSC in the same PLMN to provide interworking for a data/fax call. Whereas an IWF can only be used by its MSC, the SIWF can be used by several other network nodes e.g. any MSC within the same PLMN (the concept is not limited to a certain number of MSCs). SIWF is applied to data services in GSM Phase 2 and GSM Phase 2+ (as defined in GSM 02.02, GSM 02.03 and GSM 02.34).
The usage of an SIWF requires no additional manipulation at the MS.
An IWF provides specific functions associated with the visited MSC for the interworking with other networks. It comprises signalling and traffic channel related functions. The traffic channel related functions are provided by an Inter Working Unit (IWU).
The SIWF concept is that it provides specific functions for the interworking with other networks. It comprises signalling and traffic channel related functions. Whereas the signalling related functions are associated with the visited MSC, the IWU providing the traffic channel related functions has another physical location.
The entity that contains all additional functions needed in the visited MSC to provide the SIWF is called SIWF Controller (SIWFC). The entity where the IWU is located is called SIWF Server (SIWFS). The Interface between a visited MSC and a SIWFS is called the K Interface.
SIWFS can be provided by a MSC (MSC/SIWFS) or by another network entity (stand alone SIWFS).
[edit] The Serving GPRS Support Node (SGSN)
This functional unit keeps track of the individual MSs' location and performs security functions and access control; see also GSM 03.60.
[edit] The Gateway GPRS Support Node (GGSN)
This functional unit provides interworking with external packet-switched networks, network screens and routing of the Network Requested PDP-context activation;see also GSM 03.60.4.2 "Configuration of a Public Land Mobile Network (PLMN)".
The basic configuration of a Public Land Mobile Network is presented in figure 4.2/1. In this figure the most general solution is described in order to define all the possible interfaces which can be found in any PLMN. The specific implementation in each network may be different: some particular functions may be implemented in the same equipment and then some interfaces may become internal interfaces. In any case the configuration of a PLMN must have no impact on the relationship with the other PLMNs.
In this configuration, all the functions are considered implemented in different equipments. Therefore, all the interfaces are external and need the support of the Mobile Application Part of the Signalling System No. 7 to exchange the data necessary to support the mobile service. From this configuration, all the possible PLMN organizations can be deduced.
[edit] The Number Portability Location Register (NPLR)
This functional unit provides routing information necessary in some Mobile Number Portability environments in order to route calls for ported mobile subscribers. For details see also GSM 03.66 [108].
[edit] The Serving Mobile Location Center (SMLC)
An SMLC is a database and processing entity that manages the procedures for obtaining the geographic location of a target MS in the coverage area served by the SMLC. In managing the location procedures, the SMLC chooses the positioning method and provides data and instructions to the LMUs or target MS that perform the actual location measurements associated with the chosen method. The SMLC also verifies any location estimate computed by the target MS or computes a location itself from measurements provided to it by the target MS or LMUs.
An SMLC also manages a set of LMUs in its coverage area whose purpose is to provide location measurements and location assistance data to the SMLC to compute, or assist in computing, location estimates for target MSs. Management functions performed by an SMLC on behalf of its LMUs include maintaining the status and current serving MSC of each LMU and supporting O&M procedures,
The database in an SMLC contains data necessary for choosing an appropriate position method and any parameters associated with this method for a target MS in any serving cell, for computing or verifying location estimates and for managing its LMUs.
An SMLC may be either NSS based or BSS based. An NSS based SMLC supports positioning and management of its LMUs via interaction with one or more MSCs using the Ls interface. A BSS based SMLC supports positioning and management of its LMUs via interaction with one or more BSCs using the Lb interface.
[edit] The Gateway Mobile Location Center (GMLC)
The GMLC provides access to location services (LCS) for LCS clients external to a PLMN. A GMLC may also support access to location services from LCS clients internal to its own PLMN. The GMLC allows an LCS client to issue location requests for certain target MSs; it then conveys these requests to the VMSC currently serving each target MS and passes back the location results to the LCSclient. Any target MS whose location is requested may belong to either the GMLC’s own PLMN or another PLMN and may currently be served by either the GMLC’s own PLMN or another PLMN.
[edit] The Location Measurement Unit (LMU)
The LMU is the logical network entity that performs location measurements in the VPLMN in order to either position a target MS or provide assistance data to be used in conjunction with other location measurements. An LMU is controlled by an SMLC in the VPLMN from which location commands can be received and to which any location measurements are returned.
Figure 4.2/1: Configuration of a PLMN
[edit] Void
[edit] Interconnection between PLMNs
Since the configuration of a PLMN does not have any impact on other PLMNs, the signalling interfaces specified can be implemented both between the entities within a PLMN and between different PLMNs.
[edit] The interfaces within the mobile service
[edit] Interface between the HLR and the VLR (D-interface)
This interface is used to exchange the data related to the location of the MS and to the management of the subscriber. The main service provided to the mobile subscriber is the capability to set up or to receive calls within the whole service area. To support that purpose the location registers have to exchange data. The VLR informs the HLR on the registration of a MS managed by the latter and provides it with the relevant location information. The HLR sends to the VLR all the data needed to support the service to the MS. The HLR then calls the previous VLR to inform it that it can cancel the location registration of this station because of the roaming of the mobile.
Exchanges of data may also occur when the mobile subscriber requires a particular service, when he wants to change some data attached to his subscription or when some parameters of the subscription are modified by administrative means.
[edit] Interface between the HLR and the gsmSCF (J-interface)
This interface is used by the gsmSCF to request information from the HLR (via the Any-time Interrogation function) or to allow call independent related network- or user-initiated interaction between an MS and the gsmSCF (via the USSD function). Support of the gsmSCF-HLR interface is a network operator option. As a network operator option, the HLR may refuse to provide the information requested by the gsmSCF.
[edit] Interface between the VLR and its associated MSC(s) (B-interface)
The VLR is the location and management data base for the MSs roaming in the area controlled by the associated MSC(s). Whenever the MSC needs data related to a given MS currently located in its area, it interrogates the VLR. When a MS initiates a location updating procedure with an MSC, the MSC informs its VLR which stores the relevant information in its tables. This procedure occurs whenever a mobile roams to another location area. Also, for instance when a subscriber activates a specific supplementary service or modifies some data attached to a service, the MSC transfers (via the VLR) the request to the HLR, which stores these modifications and updates the VLR if required.
However, this interface is not fully operational specified. It is strongly recommended not to implement the B-interface as an external interface.
[edit] Interface between VLRs (G-interface)
When an MS initiates a location updating using TMSI, the VLR can fetch the IMSI and authentication set from the previous VLR.
[edit] Interface between the HLR and the MSC (C-interface)
When the fixed network is not able to perform the interrogation procedure needed to set up a call to a mobile subscriber, the Gateway MSC has to interrogate the HLR of the called subscriber to obtain the roaming number of the called MS (see GSM 03.04).
To forward a short message to a mobile subscriber, the SMS Gateway MSC has to interrogate the HLR to obtain the MSC number where the MS is located.
[edit] Interface between the MSC and the gsmSCF (L-interface)
When one of the following Supplementary Services, CD, ECT or MPTY, is invoked in the MSC a notification shall be sent towards the gsmSCF.
[edit] Interface between MSCs (E-interface)
When a MS moves from one MSC area to another during a call, a handover procedure has to be performed in order to continue the communication. For that purpose the MSCs involved have to exchange data to initiate and then to realize the operation.
This interface is also used to forward short messages, to perform location for a target MS for which handover has occurred on an established call and to transfer LCS messages to and from an LMU for which handover of a signalling channel has occurred.
This interface is also used to transfer information for inter-MSC VBS/VGCS calls .
[edit] Interface between the MSC and Base Station Systems (A-interface)
The description of this interface is contained in the GSM 08-series of MSs.
The BSS-MSC interface carries information concerning:
- BSS management;
- call handling;
- location management.
[edit] Interface between MSC and EIR (F-interface)
This interface is used when an MSC wants to check an IMEI.
[edit] Interface between VBS/VGCS Anchor MSC and GCR (I-interface)
This is an internal interface.
[edit] Interface between the MSC and the SIWF server (K-interface)
When a MSC detects that it can not provide the requested IW function, resources from an SIWF server can be used. This interface is used to allocate resources in that SIWF server and establish required physical connections to that server.
[edit] Interface between SGSN and HLR (Gr-interface)
The description of this interface is contained in the GSM 03.60.
[edit] Interface between SGSN and SMS-GMSC or SMS-IWMSC (Gd-interface)
The description of this interface is contained in the GSM 03.60.
[edit] Interface between GGSN and HLR (Gc-interface)
The description of this interface is contained in the GSM 03.60.
[edit] Interface between SGSN and EIR (Gf-interface)
The description of this interface is contained in the GSM 03.60.
[edit] Interface between SGSN and BSC (Gb-interface)
The description of this interface is contained in the GSM 03.60.
[edit] Interface between SGSN and MSC/VLR (Gs-interface)
The description of this interface is contained in the GSM 09.18.
[edit] Interface between SMLC and BSC (Lb interface)
This interface is used by a BSC when an SMLC is BSS based to request either the initiation of location procedures or the retrieval of location assistance data for a particular target MS in the coverage area served by the SMLC. The interface is also used to transfer LCS measurement and O&M information between an SMLC and LMU via the BSC. A description of this interface is contained in GSM 03.71 and GSM 09.31.
[edit] Interface between SMLC and MSC (Ls interface)
This interface is used by the MSC when an SMLC is NSS based to request either the initiation of location procedures or the retrieval of location assistance data for a particular target MS in the coverage area served by the SMLC. The interface is also used to transfer LCS measurement and O&M information between an SMLC and LMU or BSC via the MSC. A description of this interface is contained in GSM 03.71 and GSM 09.31.
[edit] Interface between SMLC and SMLC (Lp interface)
This interface is used by an SMLC to obtain LCS measurement information from an LMU controlled by another SMLC. A description of this interface is contained in GSM 03.71 and GSM 08.31.
[edit] Void
[edit] Interface between GMLC and HLR (Lh interface)
This interface is used by the GMLC to request the address of the visited MSC for a particular target MS whose location has been requested.
[edit] Interface between GMLC and MSC (Lg interface)
This interface is used by the GMLC to convey a location request to the MSC currently serving a particular target MS whose location was requested. The interface is used by the MSC to return location results to the GMLC.
[edit] Interface between LCS Client and GMLC (Le interface)
This interface is used by a client of the Location Services (LCS) to request location information from a GMLC for certain target MSs. The interface is used by the GMLC to provide location information to an LCS client. This interface is external to a PLMN and is not defined within GSM.
[edit] Splitting of the data storage
The data attached to each MS management, operation and location are stored in the Location Registers. Some data are duplicated in the HLR and in the VLR, but others may be stored only in one place.
The data associated with any client that uses a particular GMLC to access location services is stored in the GMLC.
[edit] Overload and compatibility overview
[edit] 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.
[edit] 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
GSM 08.08 (A-interface Flow Control), applicable to reduce the mobile originating traffic.
[edit] 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 which might be changed due to network operator/implementation matters.
[edit] Congestion control for Signalling System No. 7
The requirements of SS7 Congestion control have to be taken into account as far as possible.
Means which could be applied to achieve the required traffic reductions are described in subclauses 5.1.1 and 5.1.2.
[edit] Compatibility
[edit] 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 functionalities (if possible).
When a signalling procedure can be supported by several application contexts which differ by their version number, the MAP-User needs to select a name. It can either select the name which 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 be minimized.
[edit] Strategy for selecting the Application Context (AC) version
A method should be used to minimize 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 which can be used mainly at transitory phase stage when the network is one of mixed phase entities.
[edit] 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 which 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 subclause 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 subclause 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.
[edit] 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 replace the old AC-name by the new one in the list of associated highest AC supported.
ELSE
It uses the AC-name which 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.
[edit] Optimizing 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.
[edit] Requirements concerning the use of SCCP and TC
[edit] Use of SCCP
The Mobile Application Part makes use of the services offered by the Signalling Connection Control Part of signalling System No. 7. CCITT Blue Book or ITU-T (03/93) Recommendations Q.711 to Q.716 should be consulted for the full specification of SCCP. 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.
[edit] SCCP Class
MAP will only make use of the connectionless classes (0 or 1) of the SCCP.
[edit] 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 SSN for MAP are specified in GSM 03.03 [17].
When the SGSN emulates MSC behavior for processing messages (MAP-MO-FORWARD-SHORT-MESSAGE, MAP_CHECK_IMEI) 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.
[edit] SCCP addressing
[edit] 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 which 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 GSM 03.66) 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, ie 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 subclauses 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 Shared Inter Working Function (SIWF);
- the Serving GPRS Support Node (SGSN);
- the Gateway GPRS Support Node (GGSN);
- the Gateway Mobile Location Center (GMLC).
[edit] The Mobile-services Switching Centre (MSC)
There are several cases where it is necessary to address the MSC.
[edit] MSC interaction during handover
The address is derived from the target Cellid.
[edit] MSC for short message routing
When a short message has to be routed to a MS, the GMSC addresses the VMSC by an MSC identity received from the HLR which complies with E.164 rules.
For MS originating short message, the IWMSC address is derived from the Service Centre address.
[edit] 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.
[edit] 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.
[edit] The Home Location Register (HLR)
There are several cases where the HLR has to be addressed:
[edit] 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 which has MAP capabilities, e.g. local exchange, outgoing International Switching Centre (ISC), etc.
[edit] Before location updating completion
When a 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
- on an E.164 HLR address; or
- in the case of intra-PLMN signalling, on 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.
[edit] 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).
[edit] 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.
[edit] 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.
[edit] Before GPRS location updating completion
When a MS registers for the first time in a 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
- on an E.164 HLR address; or
- in the case of intra-PLMN signalling, on 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.
[edit] 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.
[edit] 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.
[edit] The Visitor Location Register (VLR)
There are several cases when the VLR needs to be addressed.
[edit] 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.
[edit] HLR request
The HLR will only request information from a VLR if it is aware that one of its subscribers is in the VLR's 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.
[edit] 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.
[edit] 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.
[edit]
When the Visited MSC detects a data or fax call and the IWF in the V-MSC can not handle the required service an SIWF can be invoked. The SIWF is addressed with an E.164 number.
[edit] The Serving GPRS Support Node (SGSN)
The HLR will initiate dialogues towards the SGSN if it is aware that one of its subscribers is in the SGSN's 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.
When the GMSC initiates dialogues towards the SGSN the SGSN (MAP) SSN (See GSM 03.03) 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.
[edit] 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.
[edit] 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.
[edit] Void
[edit] Void
[edit] Void
[edit] The Gateway Mobile Location Center (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 from the HLR for a target MS. The E.164 address of the GMLC is also provided to a serving MSC when the GMLC requests the location of a target MS served by this MSC.
[edit] Summary table
The following tables summarize 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 Adress. 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
Table 6.1/2
[edit] 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 initialization 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).
Figure 6.2/1: Facilities for supporting the Mobile Application Part in Signalling System No.7
[edit] General on MAP services
[edit] 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.
[edit] 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
