17.1 General
29.0023GPPMobile Application Part (MAP) specificationRelease 17TS
This clause specifies the Abstract Syntaxes for the Mobile Application Part as well as the associated set of Operations and Errors, using the Abstract Syntax Notation One (ASN.1), defined in ITU-T Recommendations X.680 and X.681 with additions as defined in clause 17.1.4 on Compatibility Considerations and the OPERATION and ERROR external information object classes, defined in ITU-T Recommendation X.880.
The Abstract Syntax is defined for all interfaces specified in clause 4.4 except for the A- and B-interfaces.
The Mobile Application Part protocol is defined by two Abstract Syntaxes:
– one Abstract Syntax which encompass all Operations and Errors identified by the various MAP subsystem numbers.
This Abstract Syntax represents the set of values each of which is a value of the ASN.1 type TCAPMessages. TCMessage as defined in ITU-T Recommendation Q.773 with the component relationconstraint clauses resolved by the operation and error codes included in the ASN.1 modules MAP-*Operations and MAP-Errors. However, only the subset of this abstract syntax which is required by the procedures defined for an entity needs to be supported.
– one Abstract Syntax identified by the OBJECT IDENTIFIER value MAP-DialogueInformation.map-DialogueAS.
This Abstract Syntax represents the set of values each of which is a value of the ASN.1 type MAP-DialogueInformation.MAP-DialoguePDU. Such a value of the ASN.1 single-ASN.1-type element is contained within the user-information element of the TCAPMessages.DialoguePortion ASN.1 type. This Abstract Syntax name is to be used as a direct reference.
17.1.1 Encoding rules
The encoding rules which are applicable to the defined Abstract Syntaxes are the Basic Encoding Rules for Abstract Syntax Notation One, defined in ITU-T Recommendation X.690 with the same exceptions as in ITU-T Recommendation Q.773, clause 4 Message Representation.
When the definite form is used for length encoding, a data value of length less than 128 octets must have the length encoded in the short form.
When the long form is employed to code a length, the minimum number of octets shall be used to code the length field.
OCTET STRING values and BIT STRING values must be encoded in a primitive form.
There is no restriction to the use of empty constructors (e.g. an empty SEQUENCE type). That is, the encoding of the content of any data value shall consist of zero, one or more octets.
17.1.2 Use of TC
The mapping of OPERATION and ERROR to TC components is defined in ETS 300 287 (version 2) which is based on ITU-T Recommendation Q.773.
NOTE 1: The class of an operation is not stated explicitly but is specified as well in the ASN.1 operation definition.
Class 1: RESULT and ERROR appear in ASN.1 operation definition.
Class 2: only ERROR appears in ASN.1 operation definition.
Class 3: only RESULT appears in ASN.1 operation definition.
Class 4: both RESULT and ERROR do not appear in ASN.1 operation definition.
The field "ARGUMENT", "PARAMETER" or "RESULT" (for information objects of class OPERATION and ERROR) is always optional from a syntactic point of view. However, except when specifically mentioned with the ASN.1 comment "– optional" , the "parameter" part of a component has to be considered as mandatory from a semantic point of view.
When an optional element is missing in an invoke component or in an inner data structure while it is required by the context, an error component is returned if specified in the information object associated with the operation ; the associated type of error is "DataMissing". This holds also when the entire parameter of an invoke component is missing while it is required by the context.
NOTE 2: When a mandatory element is missing in the parameter or inner data structure of any component, a reject component is returned (if the dialogue still exists). The problem code to be used is "Mistyped parameter".
The Timer Values used in the operation definitions are indicated as ASN.1 comments. The Timer Value Ranges are:
s = from 3 seconds to 10 seconds;
m = from 15 seconds to 30 seconds;
ml = from 1 minute to 10 minutes;
l = from 28 hours to 38 hours.
17.1.2.1 Use of Global Operation and Error codes defined outside MAP
An entity supporting an application context greater than 2 shall be capable of receiving an operation or error code, within an application context defined in GSM 29.002, encoded as either an Object Identifier (as defined in ITU-T Recommendation X.690 ) or an integer value (as defined in clause 17.5). Related restrictions regarding the use of Object Identifiers are as follows:
– The length of the Object Identifier shall not exceed 16 octets and the number of components of the Object Identifier shall not exceed 16.
– Object Identifiers shall be used only for operations or errors defined outside of GSM 29.002.
– Global error codes may be sent only in response to a global operation. If a standard operation is received then a global error code shall not be sent in response.
Handling of an unknown operation codes by the receiving entity is defined in clause 15.1.1.
17.1.3 Use of information elements defined outside MAP
An information element or a set of information elements (messages) transparently carried in the Mobile Application Part but defined in other recommendations/technical specifications are handled in one of the following ways:
i) The contents of each information element (without the octets encoding the identifier and the length in the recommendation/technical specification where it is defined unless explicitly stated otherwise) is carried as the value of an ASN.1 type derived from the OCTET STRING data type. Additionally, the internal structure may be explained by means of comments. In case of misalignment the referred to recommendation/technical specification takes precedence.
ii) The complete information element (including the octets encoding the identifier and the length in the recommendation/technical specification where it is defined) or set of information elements and the identity of the associated protocol are carried as the value of the ExternalSignalInfo data type defined in the present document. Where more than one information element is carried, the information elements are sent contiguously with no filler octets between them.
17.1.4 Compatibility considerations
The following ASN.1 modules conform to ITU-T Recommendation X.680 and X.681 . An extension marker ("…") is used wherever future protocol extensions are foreseen.
The "…" construct applies only to SEQUENCE and ENUMERATED data types. An entity supporting a version greater than 1 shall not reject an unsupported extension following "…" of that SEQUENCE or ENUMERATED data type. The Encoding Rules from clause 17.1.1 apply to every element of the whole Transfer Syntax especially to the ASN.1 type EXTERNAL.
The extension container "privateExtensionList" is defined in this specification in order to carry extensions which are defined outside this specification. Private extensions can be defined by, for example, network operators, manufacturers, and regional standardisation bodies.
Private extensions shall:
1) if included in operations of an AC of V2, follow the extension marker and be tagged using PRIVATE tags up to and including 29.
NOTE: This type of extension is in most cases used only within a PLMN.
2) if included in operations of an AC of V3 or higher: be included only in the Private Extension Container that is defined in the specification.
NOTE: This type of extension can be used between PLMNs.
Private extensions shall not be included in v2 supplementary service operations.
Private extensions shall not be included within user error for RegisterCCEntry and EraseCCEntry operations.
PCS extensions shall be included in the PCS Extension Container that is defined in this specification.
In order to improve extensibility, a few error parameters have been defined as a CHOICE between the version 2 description and a SEQUENCE including the version 2 description and an extension container. Operations used in a v2-application-context must consider only the first alternative while operations used in a vn-application-context (n>2) must consider only the second alternative.
17.1.5 Structure of the Abstract Syntax of MAP
For each MAP parameter which has to be transferred by a MAP Protocol Data Unit (MAP message), there is a PDU field (an ASN.1 type) which has the same name as the corresponding parameter, except for the differences required by the ASN.1 notation (blanks between words are removed or replaced by hyphen, the first letter of the first word is capital and the first letter of each of the following words ise capitalised, e.g. "no reply condition time" is mapped to "NoReplyConditionTime"). Additionally some words may be abbreviated as follows:
bs basic service
ch call handling
cug closed user group
ho handover
ic incoming call
id identity
info information
mm mobility management
lcs location services
ms mobile service
oc outgoing call
om operation & maintenance
pw Password
sm short message service
ss supplementary service
The MAP protocol is composed of several ASN.1 modules dealing with either operations, errors, data types, and, if applicable, split into those dealing with mobile services, call handling services, supplementary services and short message services. For operations and errors the code values are given as parameters, in order to allow use of the defined information objects also by other protocols (e.g. 3GPP TS 24.080 [38]). The ASN.1 source lines are preceded by line-numbers at the left margin in order to enable the usage of the cross-reference in annex A.
The module containing the definition of the operation packages for MAP is:
1. MAP-OperationPackages.
The module containing the definition of the application contexts for MAP is:
2. MAP-ApplicationContexts.
The module containing the data types for the Abstract Syntax to be used for TCAPMessages.DialoguePortion for MAP is:
3. MAP-DialogueInformation.
The module containing the supported operations is:
4. MAP-Protocol.
The modules containing all operation definitions for MAP are:
5. MAP-MobileServiceOperations;
6. MAP-OperationAndMaintenanceOperations;
7. MAP-CallHandlingOperations;
8. MAP-SupplementaryServiceOperations;
9. MAP-ShortMessageServiceOperations;
10. MAP-Group-Call-Operations;
11. MAP-LocationServiceOperations.
The module containing all error definitions for MAP is:
12. MAP-Errors.
Modules containing all data type definitions for MAP are:
13. MAP-MS-DataTypes;
14. MAP-OM-DataTypes;
15. MAP-CH-DataTypes;
16. MAP-SS-DataTypes;
17. MAP-SS-Code;
18. MAP-SM-DataTypes;
19. MAP-ER-DataTypes;
20. MAP-CommonDataTypes;
21. MAP-TS-Code;
22. MAP-BS-Code;
23. MAP-ExtensionDataTypes;
24. MAP-GR-DataTypes;
25. MAP-LCS-DataTypes.
References are made also to modules defined outside of the present document. They are defined in the technical specification Mobile Services Domain, technical specification Transaction Capability and ITU-T Recommendation X.880 respectively:
MobileDomainDefinitions;
TCAPMessages, DialoguePDUs ;
Remote-Operations-Information-Objects.
17.1.6 Application Contexts
The following informative table lists the latest versions of the Application Contexts used in this specification, with the operations used by them and, where applicable, whether or not the operation description is exactly the same as for previous versions. Information in 17.6 & 17.7 relates only to the ACs in this table.
|
AC Name |
AC Version |
Operations Used |
Comments |
|---|---|---|---|
|
locationCancellationContext |
v3 |
cancelLocation |
|
|
equipmentMngtContext |
V3 |
checkIMEI |
|
|
imsiRetrievalContext |
v2 |
sendIMSI |
|
|
infoRetrievalContext |
v3 |
sendAuthenticationInfo |
|
|
interVlrInfoRetrievalContext |
v3 |
sendIdentification |
|
|
handoverControlContext |
v3 |
prepareHandover forwardAccessSignalling sendEndSignal processAccessSignalling prepareSubsequentHandover |
the syntax of this operation has been extended in comparison with release 98 version |
|
mwdMngtContext |
v3 |
readyForSM |
|
|
msPurgingContext |
v3 |
purgeMS |
|
|
shortMsgAlertContext |
v2 |
alertServiceCentre |
|
|
resetContext |
v3 |
reset |
|
|
networkUnstructuredSsContext |
v2 |
processUnstructuredSS-Request unstructuredSS-Request unstructuredSS-Notify |
|
|
tracingContext |
v3 |
activateTraceMode deactivateTraceMode |
|
|
networkFunctionalSsContext |
v2 |
registerSS eraseSS activateSS deactivateSS registerPassword interrogateSS getPassword |
|
|
shortMsgMO-RelayContext |
v3 |
mo-forwardSM |
|
|
shortMsgMT-RelayContext |
v3 |
mt-forwardSM |
|
|
shortMsgMT-VGCS-RelayContext |
v3 |
mt-forwardSM-VGCS |
|
|
shortMsgGatewayContext |
v3 |
sendRoutingInfoForSM reportSM-DeliveryStatus InformServiceCentre |
the syntax of this operation has been extended in comparison with release 96 version |
|
networkLocUpContext |
v3 |
updateLocation forwardCheckSs-Indication restoreData insertSubscriberData activateTraceMode |
the syntax is the same in v1 & v2 |
|
gprsLocationUpdateContext |
v3 |
updateGprsLocation insertSubscriberData activateTraceMode |
|
|
subscriberDataMngtContext |
v3 |
insertSubscriberData deleteSubscriberData |
|
|
roamingNumberEnquiryContext |
v3 |
provideRoamingNumber |
|
|
locationInfoRetrievalContext |
v3 |
sendRoutingInfo |
|
|
gprsNotifyContext |
v3 |
noteMsPresentForGprs |
|
|
gprsLocationInfoRetrievalContext |
v4 |
sendRoutingInfoForGprs |
|
|
failureReportContext |
v3 |
failureReport |
|
|
callControlTransferContext |
v4 |
resumeCallHandling |
|
|
subscriberInfoEnquiryContext |
v3 |
provideSubscriberInfo |
|
|
anyTimeEnquiryContext |
v3 |
anyTimeInterrogation |
|
|
anyTimeInfoHandlingContext |
v3 |
anyTimeSubscriptionInterrogation anyTimeModification |
|
|
ss-InvocationNotificationContext |
v3 |
ss-InvocationNotification |
|
|
groupCallControlContext |
v3 |
prepareGroupCall processGroupCallSignalling forwardGroupCallSignalling sendGroupCallEndSignal |
|
|
reportingContext |
v3 |
setReportingState statusReport remoteUserFree |
|
|
callCompletionContext |
v3 |
registerCC-Entry eraseCC-Entry |
|
|
istAlertingContext |
v3 |
istAlert |
|
|
ServiceTerminationContext |
v3 |
istCommand |
|
|
locationSvcEnquiryContext |
v3 |
provideSubscriberLocation subscriberLocationReport |
|
|
locationSvcGatewayContext |
v3 |
sendRoutingInfoForLCS |
|
|
mm-EventReportingContext |
v3 |
noteMM-Event |
|
|
subscriberDataModificationNotificationContext |
v3 |
noteSubscriberDataModified |
|
|
authenticationFailureReportContext |
v3 |
authenticationFailureReport |
|
|
resourceManagementContext |
v3 |
releaseResources |
|
|
groupCallInfoRetievalContext |
v3 |
sendGroupCallInfo |
|
|
vcsgLocationUpdateContext |
v3 |
updateVcsgLocation insertSubscriberData |
|
|
vcsgLocationCancelContext |
v3 |
cancelVcsgLocation |
NOTE (*): The syntax of the operations is not the same as in previous versions unless explicitly stated
In the word-text of ASN.1 Modules hidden text is used for marking the begin (.$modulename), interrupt (.#), continuation (.$) and end (.#END) of ASN.1 Source. This allows to automatically extract the ASN.1 Sources. These markers should not be deleted! In addition, hidden text is also used to overcome some compiler restrictions
In addition no line break should occur when printing a paragraph in ASN.1 source, otherwise the line-numbering of word is inconsistent with the line-numbering in Annex A.
For Completeness the module MAP-Frame is included as hidden text.
.$MAP-Frame
DEFINITIONS ::=
BEGIN
IMPORTS
Component,
TCMessage
FROM TCAPMessages
dialogue-as-id,
DialoguePDU
FROM DialoguePDUs
updateLocation
FROM MAP-Protocol
map-DialogueAS,
MAP-DialoguePDU
FROM MAP-DialogueInformation
map-ac
FROM MAP-ApplicationContexts
;
ZZZZ-Dummy ::= NULL
.#END