See: Description
| Class | Description |
|---|---|
| MAPApplicationContexts |
Defines metadata for map's application contexts.
|
| MAPErrors |
Defines metadata for map's errors.
|
| MAPMAP_EXTENSION<ExtensionType> |
Defines metadata for a class of map's open type extensions.
|
| MAPOpenTypeExtensions |
Defines metadata for map's open type extensions.
|
| MAPOperations |
Defines metadata for map's operations.
|
The MAP API supports all application contexts defined in the specification.
See MAPApplicationContexts for an exhaustive list,
and the corresponding supported operations for each application context.
The MAP API supports not only the application contexts directly defined in
the particular release of the MAP specification, but also, via the compatibility rules
defined therein, the operations and errors of earlier versions of those
application contexts.
See MAPOperations for an exhaustive list.
Later versions of the same operation are implemented as extensions of earlier versions.
Beware that version 1 of operations is best avoided: some of them have some fields that
are irrelevant in later versions, there's little version 1 traffic out there, and we don't
want to encourage more; they are supported here for completeness (and so that OpenCloud's
earlier INCC product can be retired).
The following table highlights the major additions in each earlier release of MAP. Following phases 1 and 2, GSM then produced annual releases named after the year. 3GPP releases were then numbered sequentially from 4. 3GPP have forecast that release 11 will be stable in December 2012 [www.3gpp.org/releases viewed in November 2011].
| Release | Additions |
|---|---|
| Ph1 | The basics, including SMS |
| Ph2 | GPRS |
| 96 | Call control transfer and information enquiry contexts; extension containers |
| 97 | Support for Camel phase 2 |
| 98 | More location services |
| 99 | Support for Camel phase 3 |
| 4 | Deferred locations |
| 5 | Support for Camel phase 4 |
| 6 | Resource management |
| 7 | Voice group call |
| 8 | Closed subscriber groups; SMS over IP |
| 9 | Evolved packet system |
| 10 | Selected IP traffic overload permission |
Whilst we support one particular release of MAP, the party or parties with whom we communicate might support an earlier or a later release. Typically, things that are supported by the sending party but not the recipient are sent but ignored by the recipient, while things that are supported by the recipient but not by the sending party are not sent. Whether or not something is supported by a release is commented on in its documentation. To then determine whether that something might be supported by a particular version of an application context, refer to the following table.
| Application context name | GSM/3GPP Release number | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 10 | 9 | 8 | 7 | 6 | 5 | 4 | 99 | 98 | 97 | 96 | Ph2 | Ph1# | |
| anyTimeInfoEnquiry | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
||
| anyTimeInfoHandling | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||||
| authenticationFailureReport | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||||
| callCompletion | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||
| callControlTransfer | 4 |
4 |
4 |
4 |
4 |
4 |
4 |
4 |
4 |
3 |
3 |
||
| equipmentMngt | 3 |
3 |
3 |
3 |
3 |
3 |
2 |
2 |
2 |
2 |
2 |
2 |
1 |
| failureReport | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||
| gprsLocationInfoRetrieval | 4 |
4 |
4 |
4 |
4 |
4 |
4 |
3 |
3 |
3 |
|||
| gprsLocationUpdate | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||
| gprsNotify | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||
| groupCallControl | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||
| groupCallInfoRetrieval | 3 |
3 |
3 |
3 |
|||||||||
| handoverControl | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
2 |
2 |
2 |
1 |
| imsiRetrieval | 2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
|
| infoRetrieval | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
2 |
2 |
2 |
1 |
| interVlrInfoRetrieval | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
2 |
2 |
2 |
|
| istAlerting | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||||
| locationCancellation | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
2 |
1 |
| locationInfoRetrieval | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
1 |
| locationSvcEnquiry | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
||||
| locationSvcGateway | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
||||
| mm-EventReporting | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||||
| msPurging | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
2 |
|
| mwdMngt | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
2 |
1 |
| networkFunctionalSs | 2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
1 |
| networkLocUp | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
1 |
| networkUnstructuredSs | 2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
|
| reporting | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||
| reset | 2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
1 |
| resourceManagement | 3 |
3 |
3 |
3 |
3 |
||||||||
| roamingNumberEnquiry | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
1 |
| serviceTermination | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||||
| shortMsgAlert | 2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
2 |
1 |
| shortMsgGateway | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
1 |
| shortMsgMO-Relay | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
1* |
| shortMsgMT-Relay | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
1* |
| shortMsgMT-Relay-VGCS- | 3 |
3 |
3 |
3 |
|||||||||
| sIWFSAllocation | 3 |
3 |
3 |
3 |
3 |
||||||||
| ss-InvocationNotification | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||
| subscriberDataMngt | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
1 |
| subscriberDataModificationNotification | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
|||||
| subscriberInfoEnquiry | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
||
| tracing | 3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
3 |
2 |
1 |
* The shortMsgMO-Relay and shortMsgMT-Relay application contexts in phase 1 have been synthesized by OpenCloud as variants of the standard shortMsgRelayContext-v1 application context, to assist in distinguishing originating and terminating messages.
# The application contexts of phase 1 were defined retrospectively in phase 2. Some operations of phase 1 were not assigned to application contexts by phase 2, because they have never been needed, and hence those phase 1 operations are not supported by this API. For further details of those unsupported operations, see Annex C of phase 2.
The allocation of version numbers is as follows: everything in phase 1 has version number 1; everything in phase 2 has version number 2; everything newly added since phase 2 has version number 3; and everything that evolves has its version number incremented.